%============================================%
%      Kap: Resultat                         %
%============================================%
\chapter{Resultat}
Mycket arbete har utförts för att få en fungerande prototyp, dock ej fulländad, av ett mobilt EEG. Funktionalitet som saknas inkluderar implementation av kretskort (PCB) och därmed en fulländad produkt, samt design och produktion av en form av huvudbonad för produkten. Kretskortet för att sammanfoga Raspberry Pi:n med ADC:n var tvungen att designas och produceras på egen hand, vilket det inte fanns tid till att göra vid denna tidpunkt då det var i slutet av tiden för projektet när detta blev relevant. Projektet har tyvärr inte uppnått alla delmål som sattes vid projektets start, vilket kommer att diskuteras och förklaras i följande kapitel.

%============================================%
%      Sec: Summering av svar                %
%============================================%
\section{Summering av svar på frågeställningar}
%Den frågeställning som framställts för detta projekt har besvarats i längd i tidigare kapitel.
\subsection{Vilket programmeringsspråk bör användas?}
För detta projekt så valdes programmeringsspråket Python, då det troddes kunna uppfylla de behov som fanns. Behov som fanns var bland annat realtidskrav, samt förmåga att implementera ett GUI för användarvänlighet. Språk valdes efter användarvänlighet och flexibilitet istället för uppfyllande av systemkrav, vilket fick vissa konsekvenser för utvecklingen, främst i form av behov av extra lösningar för att hantera problem. Python är ett 'långsamt' språk, vilket innebär att det tar längre tid att exekvera jämfört med andra språk och därmed gjort det svårt att realisera en lösning med hjälp av Python. Ett annat språk bör ha valts, så som C som är mer maskinnära och är ett språk anpassat till uppgifter med realtidskrav. Detta tas upp mer detaljerat i kap. 7 \ref{kap:diskussion}, Diskussion.

%\subsection{Vilken upplösning krävs för att en ADC skall kunna representera all information inom det dynamiska omfånget med tillräcklig precision}


\subsection{Vilken samplingsfrekvens bör användas för EEG signalerna.}
Ofta när man tänker på mätning av dynamiska signaler så kan man ha den naiva föreställning att signalen skall mätas så ofta som möjligt för att maximera den informationen man kan urvinna. I litteraturen som studerades inför projektet upptäcktes det att de vågformsklasser som är relevanta för EEG endast har en frekvensinnehåll på $<100$~Hz, vilket innebär enligt Shannon-Nyquist samplingsteoremet att man endast måste läsa signalen med en frekvens på ca. 200~Hz för att den ursprungliga signalen skall helt kunna återskapas digitalt. Det visade sig senare att det lägsta samplingsfrekvensen som hade stöd i ADC:n var 250~Hz. 


\subsection{Vad finns det för dataformat som är lämpade för EEG signaler? Vilket bör användas i denna tillämpning?} % (filformat, komprimeringsmetoder osv.)
Det finns många dataformat, men det som valdes är EDF-formatet. Detta för att det är en defakto standard, och det finns dedikerade bibliotek för programmeringsspråk som C och Python för att enkelt applicera data till det formatet. EDF-formatet beskrivs i mer detalj i kap. \ref{kap:teknisk_bakgrund}, Teknisk Bakgrund.
 
\subsection{Klarar systemet alla beräkningsbehov?} %Behöver vissa delar avlastas till dedikerad hårdvara och i så fall, vilka delar och hur?
Teoretiskt sätt så uppfyller systemet alla beräkningsbehov, dock så finns det problem i den praktiska implementationen som gör det svårt. Den mest uppenbara anledningen till detta är, i härledning till detta projektet, hur ADC:n kommunicerar när den gör redo sin data, samt att en RPi inte är förutsägbar i sin interruptsvarstid. Med detta menas att den är inte deterministisk, och kan därmed inte realisera de hårda tidskraven på att hämta datan i tid. Detta har gjort att det system som projektet resulterade i, inte är en färdig produkt. Det finns en prototyp av en lösning, som dock inte är integrerad med resten av systemet. Mer förklaring kring problemet finns i Teknisk Bakgrund för RPi, ADC samt MCU och även i Diskussion i dess respektive problemsektioner.


\section{Mål som uppnåtts}

\begin{itemize}
    \item{Ett simpelt men funktionellt GUI.}
    \item{Kan köras med hjälp av batteri.}
    \item{Skriva data i EDF-formatet.}
    \item{Bild- och ljudinspelning.}
    \item{Både design och prototyp av EEG inläsning.}
    \item{Enkla säkerhetsåtgärder.}
\end{itemize}

\section{Mål som ej uppnåtts}
\begin{itemize}
    \item{En komplett implementation av EEG-inläsningen.}
    \item{En design och konstruktion av en huvudbonad samt hållare för all hårdvara.}
\end{itemize}

% Följande stycke är egentligen upprepning. Men OK.
\section{Modell av lösning på överförning}
Kretskortet för att sammanfoga RPi:n med ADC:n var tvunget att designas och produceras på egen hand. 

Att läsa data från ADC:n till Rasperry Pi:n visade sig vara ett omfattande problem då varje sampel som ADC:n producerar måste läsas innan en vis tid innan den skrivs över med nästa sampel. Sampelhastigheten som behövdes för att infånga tillräckligt med data för att inte orsaka informationsförluster sattes enligt Nyquist-Shannons samplingsteorem i ett tidigt skede till 250 Hz. Detta krävde alltså att ADC:n lästes av 250 gånger i sekunden, eller var 4:e millisekund. Det förutsattes att RPi:n, med en systemklocka på 1 GHz skulle klara detta krav, men när man väl försökte implementera kommunikationen så uppenbarades det att datorsystem med linuxbaserade operativsystem behandlar interrupt signaler efter en kort men varierande tid beroende last och processer i kerneln. Experimentellt mättes en sämsta responstid på tiotals millisekunder. Linux är i sitt grundutförande alltså inget realtidssystem och lämpar sig inte för tidskänslig IO behandling. 

Lösningen på detta var att implementera en slags buffer, en enhet som hade realtidsmöjligheter och som samtidigt kunde kommunicera med RPi:n via ett icke-tidskänsligt protokoll. För detta valdes mikrokontrollern Atmega 328-PU. Detta beskrivs i detalj i kap. \ref{kap:systemdesign}.

Ett alternativ som hittills inte tagits upp är att modifiera själva Linuxkerneln för att stödja realtidsmekanismer och på så sätt få en minskad interruptlatens. Det är just detta som kerneltillägget {\tt CONFIG\_PREEMPT\_RT}\cite{preempt_rt} ämnar sig att göra och beskrivs närmare i kap. \ref{subsec:preempt_rt}.

Detta alternativ behandlades inte i detta projekt men är en intressant möjlig lösning till problemet med interruptlatens, och kanske en källa till fortsatt arbete. 








\clearpage
\section{Användning av Mobilt EEG}
%Detta kanske hör hemma nån annanstans
%Det finns både planer och simpla prototyper för anslutningen mellan Raspberry Pi, mikrokontroller samt ADC, men är inte implementerade i produkten i den aktuella versionen på grund av att PCB-kortet inte är producerat. PCB-kortet är dock färdigdesignat och redo att produceras, men projektets kontakt för denna produktion hann inte få designen i tid för deadline.
Den produkt som utvecklats är den mjukvaran och implementation som finns på projektets RPi. För att kunna använda programmet så har ett användargränssnitt skapats. Detta användargränssnitt använder sig av funktionalitet från Pythonbiblioteket PyEDFlib för att kunna utföra specifika dataskrivningar, samt andra funktioner, till skapade EDF-filer. I den aktuella prototypen så är datan simulerad med Pythonbiblioteket NumPy\cite{numpy}, men ska i framtiden kunna hämta in data från en mikrokontroller, och skriva den informationen på EDF-formatet. 

\begin{figure}[!ht]
    \centering
    \tcbox[colframe=black,colback=white, boxsep=0pt, arc=2pt,boxrule=0.5pt]{
    \includegraphics[width=1\linewidth,angle=90]{fig/diagram/ExjobbFlodesdiagram.jpg}
    }
    \caption{Flödesdiagram över Mobilt EEG programmet.}
    \label{fig:flow_diag_Mobilt_EEG}
\end{figure}


Fig. \ref{fig:flow_diag_Mobilt_EEG} visar vyn efter man startat programmet. Det som visas är programmets användargränssnitt. De olika knapparna är enkelt markerade med text för att hänvisa till sin funktion. Som exempel så måste man ha fyllt i metadata via SetHeaderData innan man kan klicka på Record eller Record EEG.



