%% Redovisa för de erfarenheter och slutsatser som man kommit fram till. 
%% Diskussion kring resultat och även kring moment som misslyckats eller ej genomförts 

\chapter{Diskussion}\label{kap:diskussion}
Resultatet kommer att diskuteras och därefter de val som gjorts under projektets gång. Kapitlet avslutas med etiska och miljöaspekter av projektet och några förslag på möjliga lösningar på de problem som tas upp här.


\section{Diskussion av resultat}
Ett fungerande Mobilt EEG var huvudmålet med projektet, men den slutgiltiga produkten saknar den viktiga funktionen av att kunna läsa signaler från elektroder och överföra denna data till Raspberry Pi:n. Detta på grund av de problem som uppstått under projektets gång, samt en relativt overklig bild av hur mycket tid olika delar av projektet skulle ta. 


%Det har uppkommit en rad olika problem som man fått lösa genom att ta ett beslut av en av flera saker, så som GUI bibliotek, på vilket sätt vi skulle få tag i ett PCB för vår ADC, hur den slutliga designen skulle se ut, och därmed anpassa designen av PCB kortet och positionering av sladdar och andra enheter.

Under utvecklingen har vissa beslut tagits, främst för att få arbetet att kunna fortskrida och inte stanna av. Utvecklingen av ett mobilt EEG anses ej vara klart. Däremot så kan det anses vara på grund av gjorda val, och inte en omöjlighet i sig, vilket gör att denna utveckling istället kan användas för att främja framtida utveckling istället för att realisera en egen produkt. 

För att förstå varför inte en komplett produkt är klar, så finns det flera saker som behöver undersökas innan det finns ett passande svar. 

I början av åtagandet så var visionen helt annorlunda än vad verkligheten tillät. Det fanns vissa delar av utvecklingen som antogs enkla eller inte så tidskrävande, delar som missades helt och även en del problem som direkt resulterades från val som gjorts under utvecklingsprocessen.

\section{Genomgång av problem}
Projektet var öppet för val om hur man skulle utveckla produkten. Början av projekttiden spenderades på att välja ett passande språk, lämplig hårdvara och försöka planera vad man potentiellt skulle behöva göra under utvecklingsprocessen.

Det fanns flera saker som, vid början av projektet, antogs skulle vara sanna.

\begin{itemize}
    \item{Det skulle finnas problem på grund av den biologiska naturen av projektet, speciellt med avseende på brus.}
    \item{Det skulle behövas förståelse om hur neural aktivitet påverkar de biologiska processer som ger upphov till de joniska strömmar som ett EEG mäter.}
    
    \item{På grund av att man har inbyggd hårdvarustöd för I/O operationer så påverkar inte operativsystem eller programspråk tidsaspekter i I/O operationer nämnvärt.}
    
    \item{Det borde finnas tid till att pröva flera olika ADC:er}
    \item{Det borde skapas en funktionell databas för att lagra de olika resulterande filerna och hålla ordning på tidsstämpling.}
    \item{Använda ett externt beräkningsprogram som Matlab eller Mathematica för att avlasta signalhantering/processering av data, vilket skulle underlätta för Raspberry Pi samt ADC.}
    \item{Kunna streama data till en extern display.}
\end{itemize}

Bara en av dessa visade sig stämma, att det skulle finnas problem på grund av biologin hos en människa.

\subsection{Antaganden}
\subsubsection{Biologiska problem}
\textit{Det skulle finnas problem på grund av den biologiska naturen av projektet.} %Kapitlet för att lägga in varför vi inte inkluderade funktionen att mäta ögonrörelse i framtida rättning.

Detta är korrekt, men det består främst av hur man sätter upp elektroder enligt 10/20 systemet, samt att rörelse av muskler orsakar starkt brus på den nivå att de joniska strömmarna för EEG blir näst intill oläsbara. Då projektet inte lyckades att pröva det fysiskt så hann detta heller inte bli ett direkt problem, utan är ett problem för framtida utveckling. Det finns metoder för att mildra detta, men av allt att döma är det ett stort arbete i sig.

\subsubsection{Kunskap om hjärnan}
\textit{Det skulle behövas förståelse om hur neural aktivitet påverkar de biologiska processer ger upphov till de joniska strömmar som ett EEG samplar.} 

Det var ett stort missförstånd att det skulle behövas mycket påläsning om hur det fungerar. På grund av detta gick många dagar till spillo, då tiden spenderades på att läsa i böcker och på internet efter information, istället för att arbeta på projektet. 

\subsubsection{Programmeringsspråk inte spelar någon roll}
\textit{På grund av att man har inbyggd hårdvarustöd för I/O operationer så påverkar inte operativsystem eller programspråk tidsaspekter i I/O operationer nämnvärt.} 
% Utveckla kanske!
När det undersöktes hur hårdvarukrävande projektet skulle vara, så sa EEG litteraturen att signalerna kunde innehålla frekvenser uppemot 100Hz, vilket innebär en sampeltakt på ca. 200Hz för att infånga hela signalen. Då en processor i en Raspberry Pi modell 2 går mot en processorhastighet mot nästan 1 GHz, och senare modeller är uppe i 1,4 GHz, och har inbyggt hårdvarustöd för externa interrupts samt en mängd kommunikationsprotokoller, så antogs det att oavsett hur långsamt ett språk än var så skulle en snabb processor och hårdvarustöd tillsammans göra så att det inte längre skulle vara ett problem.

\subsubsection{Pröva olika ADC:er}
\textit{Det skulle finnas tid till att pröva flera olika ADC:er.} 
%Det är säkert förstått vid detta laget att tiden var bland det största problemet i slutändan. Detta tidsproblem gjorde att det var en rad flera saker som inte hanns med. 
Tanken var från början att flera ADC:er skulle jämföras i hur bra det var för data-överföring, men det slutade med att endast ett beställdes och började arbetas på.

ADC:n är en integrerad del i systemdesignen att det skulle bli ett omfattande arbete att anpassa systemet till flera olika ADC:er på grund av skillnader i kommunikationsprotokoll och drivrutin, med andra ord, hur man programmerar ADC:n och tolkar datan man läser på bit-nivå. Andra ADC:er skulle eventuellt även kräva anpassning av övrig hårdvara som spänningsregulatorer för att erhålla andra matningsspänningar. 

\subsubsection{Databas}
\textit{Det skulle skapas en funktionell databas.} 

En databas var originellt en bra tanke, då det skulle genereras en mängd data som skulle behöva sparas någonstans. Problemet var att det skulle potentiellt bli komplicerat att lägga in och hämta data. Under utvecklingens gång, när funktioner för att spela in testades, så skapade dessa funktioner filer, som lagrades enkelt i den mapp som programmet körde i. Vi bestämde oss därmed att istället för att skapa en databas för alla filer, så skulle det räcka att de lagras direkt i mappen, med specifika namn beroende på datatyp. Detta för att spara tid, gör det enkelt att komma åt data, och underlätta för de egna funktionerna.

EDF-formatet som används för lagring av EEG signaler har redan en pseudo-databasstruktur och tjänar ett av huvudsyftena med att använda en databas, nämligen tidsstämpling av data. 

\subsubsection{Externt beräkningsprogram}
\textit{Använda Matlab eller Mathematica för att avlasta signalhantering/processering av data, vilket skulle underlätta för Raspberry Pi samt ADC.} 

Det fanns en tro att ett dedikerat beräkningsprogram skulle lösa de problem om att hantera signaldata och även en enkel grafisk representation för datan. 

Detta visade sig senare vara fel. Det skulle antingen behövas ytterligare hårdvara endast för att köra beräkningsprogram för att inte överbelasta RPi:n, vilket skulle komplicera kommunikationsprocessen samt överföring, eller så skulle det köras direkt på RPi:n, men då det inte längre ske någon avlastning. 

 Istället så skulle det finnas ett simpelt system för hantering av datan. 
 ADC läser av, och skickar den till en mikrokontroller. Mikrokontrollern kommunicerar med RPi:n och skapar en länk med två interface för dataöverföring och därmed hanterar kommunikationen mellan ADC och RPi. RPi får in data, och lagrar den i EDF-formatet med hjälp av den utvecklade mjukvaran. Detta är vad som i slutändan finns design och simulerad fungerande prototyp av, men ej en fysisk implementation.



\subsubsection{Streama Data}
\textit{Kunna streama data till en extern display}. 

Att kunna skicka datan till en extern skärm var och är en möjlighet, däremot så bestämdes det relativt tidigt i utvecklingsskedet att det är en relativt onödig funktion. Det skulle behöva en hel del kommunikation mellan olika enheter för att överföra datan, vilket ansågs överflödigt för så simpel mjukvara. Det skulle även kräva implementationen av ett grafiskt ramverk för uppvisning av vågformen, ett betydande arbete i sig.

Dock så kan det påpekas att detta aldrig var ett krav eller mål från början, bara en intressant idé på något som skulle kunna utvecklas. 

\subsection{Oförutsedda problem}
Det finns även en lista av problem som inte förutsågs.

\begin{itemize}
    \item{Raspberry Pi ej så lämpad för ändamålet.}
    \item{Python ej lämpat för snabb responstid gentemot hårdvara-mjukvara.}
    \item{Saknad av färdig lösning för vald ADC (PCB, kommunikationsstruktur etc).}
    \item{Extra hårdvara utifall något kortslöts eller gick sönder.}
    \item{På grund av tidsbrist så prioriterades huvudbonadens modellering bort.}
\end{itemize}

\subsubsection{Raspberry Pi ej lämpad}
\textit{Raspberry Pi ej så lämpad för ändamålet.} 

Problemet är att en RPi är för generell, och är inte specialbyggd för signalprocessering. Med detta så menas att den begränsade beräkningskraft och processhastighet som RPi:n besitter, är skapad för att vara en generell lösning. Nackdelen är att signalhantering kräver inte ett datorkort med anständig kompetens i det generella perspektivet, utan har specifika krav som kommunikationshastighet mellan signalinhämtning, processering och lagring. RPi:n är därmed inte så lämpad för just detta projektet.

\subsubsection{Python ej lämpad}
\textit{Python ej lämpat för snabb responstid gentemot hårdvara-mjukvara} 
Även om hårdvaran i Raspberry Pi är utrustad med hårdvarustöd för interrupts så orsakar Linux kerneln en viss latens tills en interrupt kan behandlas av program som kör i så kallad \textit{userspace}, program som körs av användare. Valet av programmeringsspråk visade sig lägga till en extra latens som kunde göra att systemet inte längre klarade sina tidskrav. Python har, av sin natur som interpreterad språk, en relativt hög sådan latens. Ett interpreterad språk innebär att källkoden inte kompileras utan evalueras vid körning.

% Valet av Python var i eftertanke inte ett smart val. Det är främst på grund av latens i \textit{kernel} när den ska behandla input från I/O, vilket har en mängd 'overhead' i Python, då det är ett skriptbaserat språk. Följden av problemet gör att den tänkta throughputten på överföring fick en extra statisk fördröjning på millisekunder, när gränsen var som värst ca 4 millisekunder per sampel för att kunna överföra all data i tid. 
Istället för Python så kunde ett mer maskinnära programmeringsspråk ha valts, så som C. Detta hade gjort det potentiellt svårare att skapa samma funktionalitet som i Python, men det skulle inte ha samma statiska fördröjning, vilket skulle förmildra problemet med att överföringen av data skulle ta för lång tid.

\subsubsection{Saknad av färdig ADC-lösning}
\textit{Saknad av färdig lösning för vald ADC (PCB, kommunikationsstruktur etc).}

Vid projektets början så var det ett flertal ADC:er som passade projektet, men den som ansågs passa bäst var den som valdes, TI ADS1299. Trots teknisk lämplighet, var det ett omfattande arbete att försöka få en fungerande prototypdesign då den krävde mycket kringutrustning. Man var också tvungen att skriva en drivrutin för att hantera dess ovanliga tidskrav.

För att hantera komplexiteten i ADC-relaterad hårdvara, kom man fram till insikten att ett PCB skulle behövas då komponenterna var för små och för många för att koppla ihop för hand inom rimlig tid. PCB design är en icke-trivial uppgift med en förhållandevis lång inlärningsfas, vilket tog tid ifrån projektet.



% Det fanns ingen färdig lösning för att kommunicera med denna ADC. I dess tidigare applikation så hade kommunikationsdelen alltid specialdesignats av utvecklarna, något som hade missats. Detta fick till följd att det togs tid av projektet för att försöka utveckla en sådan kommunikationsdel.

\subsubsection{Extra hårdvara}
\textit{Extra hårdvara utifall något kortslöts eller gick sönder.} 

Raspberry Pi 3 Modell B+ som beställdes blev kortsluten under testning av I/O pinnar, och bara en hade beställts. Den fick ersättas av en Raspberry Pi 2, en modell äldre men som fortfarande var funktionellt duglig, i brist på tid på att vänta på en ny beställning.

\subsubsection{Huvudbonad}
\textit{På grund av tidsbrist så prioriterades huvudbonadens modellering bort.}

Planen var att en 3D-printer på Chalmers skulle användas till att tillverka en huvudbonad för att hålla elektroder på plats, som beskrivet i kap. \ref{sec:Elektroencefalografi}, som skulle skapas tillsammans med utvecklingen av projektet. Med tanke på tidsbristen som fanns, tillsammans med det faktum att ingen av projektets medlemmar tidigare skapat tekniska 3D-ritningar med CAD, fick detta låg prioritet.


%===============================================%
%              Miljö och Etik                   %
%===============================================%
\section{Miljö och Etik}
Syftet med ett EEG är att samla in och tolka hjärnvågor. En mobil implementation, som är lättillgänglig, lättanvänd och kan användas oberoende på plats öppnar upp möjligheten till ett stort utbud av data. 

Eftersom EEG data kan innehålla information om medicinska och mentala tillstånd, så måste de betraktas som känsliga uppgifter. Enligt en studie\cite{sciencedaily_2016}, så har man även kunnat, med hög precision, identifiera individer med EEG, precis som med andra biometriska metoder som ansikts- och fingeravtrycksigenkänning. Detta gör det allt viktigare att se till att dessa uppgifter skyddas ordentligt från intrång, då det potentiellt skulle öppna upp ett nytt sätt för identitetsstöld.

Lättillgängligheten som nämndes innan har därmed en negativ aspekt i att dessa känsliga uppgifter då kan lagras av privatpersoner som inte nödvändigtvis respekterar detta ansvar. 

% Flummigt. Kanske man ska citera ngt.
Ett stort utbud på EEG-data skulle, å andra sidan, potentiellt kunna användas för att lära sig mer om hur individer tar in och katalogiserar information i en utbildningsmiljö, för att kunna anpassa studietekniker, utbildning och en bra miljö för optimala förhållanden för inlärning. Detta skulle i sin tur kunna leda till en potentiellt högre allmän utbildning världen över, då mycket av exakt hur människan lär sig och tar in information fortfarande är relativt okänt. På samma sätt skulle man även kunna lära sig om och anpassa sociala miljöer, vilket skulle kunna användas för att reducera stressnivå, då en miljö anpassad efter att hitta lugn hos en person med hjälp av EEG kan identifiera saker som påverkar en individ på det sättet.


\section{Övriga tankar}
I grund och botten så är ett av de större problemen att projektet siktade på att skapa en lösning för ett specifikt fall, med generella lösningar. Det som hände var att de generella lösningarna var för generella för att kunna uppfylla de specifika krav som visade sig finnas för ett EEG med komplex signalhantering.

\begin{itemize}
    \item Valde Raspberry Pi, skulle valt en enhet med låg och förutsägbar interruptlatens, som en Arduino eller annan mikrokontroller.
    \item Valde Python, skulle valt något mer maskinnära som C eller C++.
    %\item Valde TkInter för Python, skulle kanske valt något annat GUI-bibliotek.
\end{itemize}

Man kan därmed beskriva projektet som att det redan från början såg mörkt ut. Å andra sidan så finns det en produkt, med en prototyp på signalhämtning och leverans till programmet. Den stora nackdelen är dock att den förmodligen inte skulle vara snabb nog för stora mängder data även om målen blev uppfyllda.


\section{Möjliga Lösningar}
Här kommer ett par alternativa lösningar presenteras. Dessa är tankar som möjligtvis hade antingen gjort att projektet lyckats, eller löst samma problem på ett annat sätt. 

\subsection{En enda mikrokontroller}
Genom att använda en betydligt kraftigare mikrokontroller kan man möjligtvis integrera många funktioner som RPi:n utför, såsom kamera- och mikrofoninspelning. 

Många mer moderna mikrokontrollers har dessutom stöd för USB och kan därmed kommunicera i en högre hastighet.

\subsection{Interrupt knapp som startar båda hårdvaran samtidigt}
Man skulle kunna dela upp systemet i två oberoende delar, en som utför inspelning av ljud och bild och en annan som styr och lagrar data från ADC:n. Datan skulle då extraheras och sammanfogas 'för hand' efter en körning. 
En nackdel är att en interruptsignal kan mottas med olika fördröjningar på olika system och under olika körningstillstånd, vilket gör att datan från de olika delarna blir något osynkroniserat. Detta går troligtvis att mildra men inte eliminera. Man kan troligtvis försumma interruptfördröjningen på en mikrokontroller under de flesta omständigheter. RPi:n har en typisk interruptfördröjningstid för program i \textit{userspace}, till skillnad från \textit{kernelspace} som användare inte kan påverka, som man skulle kunna utnyttja. Denna fördröjningstid har dock stor spridning, alltså att den med låg sannolikhet avviker avsevärt från normalvärdet, vilket gör den mindre pålitlig \cite{measuring_interrupt_response_times_2019}. 

%\subsection{Kontrollenhet för att koordinera mikrokontroller och Raspberry Pi}
%Denna lösning är egentligen en vidareutveckling av lösningsförslaget innan. En extern mikrokontroller som styrdon skulle både kunna generera interruptsignaler och även mäta responstiden och därmed få en bra uppfattning av fördröjningen. Att blanda in ytterligare en mikrokontroller ökar dock komplexiteten hos systemet.

\subsection{Extern lagring}
För att undvika att behöva kommunicera mellan mikrokontroller och RPi under tidsbegränsning så kan mikrokontrollern istället skriva sensordata direkt till någon form av extern lagring, som ett SD-kort. Detta har fördelen att man inte är beroende av något annat system och kan garantera att all data sparas.

\subsection{Extern buffer}
En rimlig lösning på problemet med asynkron överföring av relativt stora datamängder är att använda en buffer mellan den skrivande (skapande) och den läsande (konsumerande) enheterna.
En vanlig typ av buffer är en cirkulär buffer\cite{wada_2019}, som implementerar en Linked-List som skriver över första minnesaddressen när den allokerade minnet tar slut. Den skriver alltså över den äldsta datan först och på så sätt kan aldrig överskrida det allokerade minnet, vilket är viktigt på minnesbegränsade enheter som mikrokontrollers.
Som exempel på minnestyper som kan användas finns \textit{EEPROM}- och \textit{Flash}minne. Eftersom minnet blir en delad resurs som kräver \textit{mutual exclusion} (sv. ömsesidig uteslutning), det vill säga att bara en enhet får använda resursen i taget, så måste någon form av åtkomstprotokoll implementeras.

\subsection{DMA (Direct Memory Access)}
DMA är ett sätt att läsa primärminnet på en enhet utan att processorn behöver vara inblandad. Följden är att man inte binder upp processorn som därmed kan utföra andra tidskänsliga funktioner.
Detta skulle vara ett effektivt sätt att hantera envägskommunikation (simplex) av stora mängder med data. Det krävs dock, som i de flesta realtidssammanhang, att man är försiktig så att primärminnet inte förändras under tiden man läser den. Dedikerad DMA hårdvara finns på många moderna mikrokontrollers.

\subsection{Trådlös överföring}
Inbyggd hårdvara för trådlös kommunikation, som Bluetooth, IEEE~802.11~WiFi, finns hos i princip alla moderna mobiltelefoner. Dessa standarder är beprövade och robusta och skulle kunna användas för att styra en mikrokontroller, förutsatt att även mikrokontrollern har inbyggt stöd eller kan kompletteras med en adapter av något slag. Dessa protokoll har fördelen att de är mycket mer sofistikerade än både SPI och RS-232 och därmed möjligtvis kan abstrahera en del av designarbetet, genom att använda verifierade bibliotek.

% Möjlig RT-OS för raspberry pi
\subsection{Realtids-OS för RPi}
Realtidsoperativsystem för RPi:n undersöktes inte som alternativ under själva arbetet. Det finns dock exempel på detta som ChibiOS/RT\cite{chibios} som påstås implementera ett fullfjädrat realtidskernel på RPi. Med det skulle man kunna ta bort MCU:n från designen helt och garantera att RPi uppfyller alla realtidskrav. Av större betydelse är dock det man tappar: linuxmiljön och drivrutiner för periferienheter. Det skulle också innebära ett stort paradigm-skifte för programmeringen, något som kostar i tid och arbete. Det kan också argumenteras att, ska ett RTOS användas i systemet, så är en enhet som RPi grovt överpresterande för ändamålet.

\subsection{Realtidstillägget {\tt CONFIG\_PREEMPT\_RT} för Linux}\label{subsec:preempt_rt}
Något likt förslaget ovan, så skulle man kunna modifiera själva Linuxkerneln för att stödja realtidsmekanismer. På så sätt kan man bevara tidigare funktionalitet och drivrutiner medans man får realtidsbeteende.

Med {\tt CONFIG\_PREEMPT\_RT} realtidstillägget för Linuxkerneln så kan man lägga till stöd för prioriteter. Detta kräver en omkompilering av kerneln och innebär att processer med högre prioritet kan 'ta över' processorn  från processer med lägre prioritet (i vad som, på engelska, kallas \textit{preemption}) med syftet att processer med högst prioritet alltid skall betjänas först. 

Detta skall kunna leda till lägre latenser om man förutsätter att IO operationer, som interrupts, har en hög prioritet och därmed exekveras innan andra, lägre prioriterade, processer.

Den latensminskning som man kan få i verkligheten med realtidstillägget varierar givetvis beroende på processorhårdvara, arkitektur, kernelversion och fler faktorer, men enligt den officiella hemsidan så är det möjligt att få interruptlatenser på under en millisekund\cite{preempt_rt}, vilket skulle kunna vara tillräckligt lågt för att kommunicera med ADC:n i denna rapport. Ett exempel på en RPi som kör Linux~4.19.8 med realtidstillägget visar med testprogrammet {\tt cyclictest}  en minskning av den maximala latenstiden från 5ms till 200$\mu$s\cite{cyclictest_blog}. 





% \begin{itemize}
%     \item En enda ihopbakad hårdvara.
%     \item Interrupt knapp som startar båda hårdvaran samtidigt, men som som synkar i framtiden.
%     \item Styr-µCU för att kordinera µCU och Raspberry Pi.
%     \item Extern Lagring.
%     \item Extern Buffer (Flash)
%     \item DMA (Direct Memory Access)
%     \item Skicka trådlöst (Bluetooth) via µCU, och utveckla applikationen.
% \end{itemize}

