%============================================%
%      Kap: Genomförande                     %
%============================================%
\chapter{Genomförande}

%============================================%
%      Sec: Förberedelse                     %
%============================================%
\section{Förberedelse}
Början av projektet bestod till stora delar av påläsning om ämnet. Ämnet inkluderade delar så som vad EEG var, hur strömmarna i hjärnan agerar och existerar, samt hur man kan använda sig av denna information för medicinska ändamål. Det var under denna period som det upptäcktes att det finns en mängd specifika tillvägagångssätt när det kommer till mätning av hjärnaktivitet. 

Bland annat om vilken spänningsnivå det handlar om, på vilka ställen på ett huvud man ska göra mätningar, samt vilka svårigheter som finns när det kommer till att mäta otroligt små spänningar på ett så känsligt organ som hjärnan. En relevant del av dessa svårigheter gäller rörelse. Det är nämligen så att det är svårt att uppfatta korrekt data från EEG om muskler rör på sig, då den spänning som används för att manipulera musklerna genererar större spänningsnivåer än vad hjärnaktivitet gör, vilket orsakar stora störningar. 

En annan faktor är att det handlar om just små spänningsnivåer, som fyller väldigt lite av det dynamiska omfånget (eng. \textit{dynamic range}) av en typisk ADC och kan därmed inte omvandlas till en meningsfull digital representation utan att först förstärkas. Helst ska denna ADC även inkludera Delta-Sigma modulation för att motverka brus.
% En ADC kan i vanliga fall ha ett spänningsomfång på 5V medans typiska extrakraniala EEG signaler har en amplitud på omkring $10-100\mu V$. Signalerna fyller alltså bara 0.025\% av spänningsomfånget. För att detta ska kunna representeras digitalt behöver man alltså $> \log_2 (25000) \approx 15$ bitar. 






%============================================%
%      Sub: Allmänt arbetssätt               %
%============================================%
\subsection{Allmänt arbetssätt}
Arbete har främst skett genom samarbete på de flesta fronter, förutom vissa data- eller elektrospecifika delar av projektet, till exempel PCB-design, vilket hade kunskapskrav som fanns relativt strikt inom elektroteknik.

% Föjande stycke verkar onödig.
Relativt sent under projektets gång var man tvungen att byta RPi på grund av en kortslutning. All mjukvara och eventuella hårdvaruinställningar som fanns på sekundärminnet, ett microSD kort, kunde flyttas till en RPi av tidigare modell, en Raspberry Pi 2 Modell B Version 1.2. Man var dock tvungen att använda en trådad internetuppkoppling. Utvecklingsarbetet kunde med andra ord försätta obehindrat efter detta.

Under projektets gång så har det skett periodiska möten med projekthandledaren för att förbättra och strukturera projektets utveckling. Förutom de regelbundna mötena så har det även funnits kontakt vid akuta problem. Ett sådant var exempelvis när den originella RPi:n kortslöts och en ny behövdes akut.

Projektet består till stor del av egenutvecklad mjukvara, och till det var det lämpligt att använda Git och GitHub för versionshantering. Detta tillät en iterativ designmetod där man kunde implementera en viss funktionalitet, testa den och sedan sammanfoga den nya koden med kodbasen på Github. Man kunde också återställa koden till en tidigare version ifall något fel skulle upptäckas vid ett senare tillfälle.

\clearpage
%============================================%
%      Sec: Systemdesign                     %
%============================================%
\section{Systemdesign}\label{kap:systemdesign}
% I detta kapitel kommer designen av den PCB implementation som utvecklats beskrivas. 

%============================================%
%      Sub: Systembeskrivning                %
%============================================%
\subsection{Systembeskrivning}\label{kap:systembeskrivning}
I fig. \ref{fig:systembeskrivning} kan man se en övergripande bild av testsystemet som planerades. Man har en central styrenhet, i detta fall en Raspberry Pi, som styr flera periferienheter och som kan själv styras utifrån, genom ett trådlöst gränssnitt så som Bluetooth eller WiFi. Det är viktigt att skilja mellan olika spänningar i systemet då viss kringutrustning, speciellt analog elektronik som ADCs, kan behöva spänningskällor som inte finns i resten av systemet.

\begin{figure}[ht]
    \centering
    \includegraphics[width=\linewidth]{fig/diagram/systembeskrivning.pdf}
    \caption{Systembeskrivning. Pilarna beskriver dataflödet i systemet. Systemet är uppdelad med avseende på systemspänning, då en ADC kan kräva en bipolär spänningskälla för att även kunna mäta negativa spänningar.}
    \label{fig:systembeskrivning}
\end{figure}

Den grundläggande funktionaliteten som beskrivs i diagrammet är att ADC:n samplar in upp till 8 EEG-signaler samtidigt och annonserar för MCU:n att data finns att hämta, varvid MCU:n läser in datan via SPI-protokollet (Serial Peripheral Interface) och lagrar den. Innan nästa sampel skickar MCU:n datan vidare till RPi:n via en seriell länk (RS232). När data väl tas emot av RPi:n skall den använda PyEDFlib för att skriva datan löpande till en fil i EDF+ format.

Samtidigt som EEG data läses in så skall video och ljud spelas in vid RPi:ns kameramodul och USB-ljudkort med ansluten mikrofon, respektive. 

Alla submoduler ska kunna styras från ett GUI gränssnitt på RPi:n.

Enligt 10-20 systemet (se fig. \ref{fig:10-20}) så ingår 19 mätpunkter i en standard montage (öronloberna, A1 och A2, används enbart som en gemensam referenspunkt). Systemet som beskrivs i denna rapport är dock begränsad till 8 kanaler av den valda ADC:n. Varje kanal har en positiv och negativ input vilket innebär att 16 elektroder kan användas. Eftersom hjärnvågor är relativt lokaliserade så behövs dock inte en full uppsättning elektroder för att erhålla meningsfull data, givet att man placerar ut dem där man önskar mäta.

Ett fortsatt arbete skulle vara att utöka antalet kanaler för att täcka hela 10-20 specifikationen. Detta beskrivs mer utförligt i kap. \ref{kap:framtida_utveckling}. 


%============================================%
%      Sub: Datakommunikation inom systemet  %
%============================================%
\subsection{Datakommunikation inom systemet}
Mycket av designarbetet i projektet lades på att försöka lösa hur data skulle överföras mellan olika delar av systemet.

Det finns huvudsakligen två olika sätt att överföra digital information: parallellt och seriellt. Parallell överföring innebär att man använder flera kanaler för att skicka olika delar av meddelandet samtidigt, seriell överföring innebär att man använder en enda kanal för att skicka hela meddelandet, bit för bit. Det är uppenbart att man kan öka datatakten med parallell överföring, dock på bekostnad av hårdvaruresurser, men i detta projekt är datatakterna såpass låga (54 kbaud, enligt nedan) att det alternativet valdes bort tidigt som onödigt.

%============================================%
%      Subsub: SPI gränssnitt på ADS1299     %
%============================================%
\subsubsection{SPI gränssnitt på ADC ADS1299}
ADS1299 använder sig av 4-wire SPI, med en klocksignal (SCLK), en chip-select signal ($\overline{CS}$) och två envägs datasignaler (DIN och DOUT). ADS1299 är en slavenhet i SPI-sammanhang och kräver därmed att masterenheten (MCU:n Atmega 328p) utför läsningen och eventuella skrivningar. Den kan med andra ord inte 'skicka' den inlästa datan till masterenheten utan måste aktivt läsas genom att skicka en pulståg på SCLK signalen.

SPI-protokollet som ADS1299 använder har dock kompletterats med en extra flödeskontrollsignal, DRDY (Data Ready), för att annonsera för \textit{master}-enheten att data finns tillgängligt att läsa. 
ADS1299 har en data buffer i form av ett skift-register där datan lagras efter varje inläsning. Detta måste läsas innan nästa inläsning, annars skrivs den över och kan ej återskapas. Eftersom detta inte får ske, ställer det \textit{hårda}\footnote{I facklig litteratur ang. realtidssystem skiljer man mellan tidskrav som är \textit{hårda} och \textit{mjuka}. I system med hårda tidskrav så har en viss data bara värde inom en viss tid, och blir värdelös om \textit{deadline} överskrids. Med mjuka tidskrav så tappar datan värde enligt någon tidsfunktion. I detta fall, om deadline överskrids så samplar man fel data, därav hårda tidskrav.} tidskrav på systemet.\cite[kap.~1.1]{tindell1995real} 


% UPPREPNING. SE OVAN.
%För att masterenheten skall kunna läsa vid rätt tillfälle, när datan har lästs in och omvandlats helt av ADC:n, så har chippet en extra 'Data Ready' ($\overline{\text{DRDY}}$) signal för att komplettera övriga SPI signaler, som annonserar att data finns att läsas.

När ADS1299 annonserar sin data måste alltså masterenheten läsa av hela buffern seriellt inom en viss tidsram som bestäms av sampeltakten. I nominella fallet är datatakten 250 Hz. Detta innebär att hela läsningen måste utföras inom 4ms från den tidpunkt att datan blev tillgänglig.

Den seriella läsningen av varje sampel har också en datatakt som bestäms av enheten som utför läsningen. Detta kan kallas för bithastigheten, eller \textit{baudrate} på engelska, som innebär hur många informationssymboler som kommuniceras per tidsenhet. 

ADS1299 har 8 inläsningskanaler med 24 bitars upplösning på varje kanal. Datan från kanalerna skickas tillsammans med ett 'status' meddelande, även den 24 bitar lång. Tillsammans innebär det att varje sampel som skickas innehåller 216 bitar (27 bytes), och om detta ska skickas 250 gånger i sekunden motsvarar detta en 'throughput' \SI{54}{kbaud}.

Här bör det påminnas om att SPI överföringen styrs enbart av \textit{master}-enheten, i det här fallet MCU:n. MCU:n som användes, AtMega328p har en klockfrekvens på 8~MHz vid 3.3V, och har därför en högsta möjliga SPI-klocka på $f_{\text{osc}}/2 =$ 4~MHz, enligt databladet. Då tar överföringen av en sampel minst
\[
T\tss{osc} \cdot 27 \text{bytes} = 108\mu s
\]
där de första 3 bytes är statusmeddelandet och resterande 24 bytes är data. Statusmeddelandet innehåller information såsom tillståndet hos den inbyggda ”lead-off” detektorn\footnote{\textit{Lead-off detection} är en mekanism för att övervaka den elektriska impedansen hos en elektrod. Om impedansen är för hög så försämras signalkvaliten och beror oftast på den fysiska kopplingen mellan elektroden och huden. Impedansen kan av olika anledningar öka över tid vilket fordrar en periodisk läsning av tillståndet\cite{ti_appnote_leadoff-detection}. }, och kan eventuellt förkastas om den inte används. Eftersom den skickas innan datan så måste den ovillkorligen läsas. 

MCU SPI hårdvaran måste dock buffra och skicka en byte i taget, vilket ger en förhållandevis hög overhead. I praktiken har man, genom ett praktiskt experiment med testdata som ska motsvara det som ADC:n skickar i nominell datatakt, och som visas i fig. \ref{fig:SPI_serial_1sample}, uppmätt en överföringstid på ungefär $200 \mu s$. Detta motsvarar ungefär 1/20 av tidsbudgeten per sampel ($T_s = 250^{-1} \text{Hz} = 4ms$) vilket ger god marginal för att sedan skicka datan vidare till RPi:n via seriellänken.

\begin{figure}[ht]
    \centering
    \includegraphics[width=1\textwidth]{fig/traces/SPI_and_SERIAL_1sample.png}
    \caption{Vågformerna 2, 3 och 4 visar SPI signalerna SCLK, data och $\overline{\text{CS}}$, respektive. Vågform 1 visar samma data överfört via seriellänken. Övrig data i bilden, B1 och B2, är tolkning av datan i verifieringssyfte och kan bortses från.}
    \label{fig:SPI_serial_1sample}
\end{figure}

%============================================%
%      Sub: ADC                              %
%============================================%
\subsection{ADC}
% Unipolar and bipolar power supplies give the exact same performance and usage conditions, though the former requires biasing the common-mode voltage of the patient body (Ucm = (AVDD+AVSS)/2 ).
% The human boy is prone to common-mode drifts because noise easily couples onto the body, much like an antenna. These common-mode drifts may push the input CM-voltage out of the measurable range of the ADC.
% The purpose of the internal BIAS drive amplifier is to bias the patient to maintain the othe elctrode common-mode voltages within the valid range.
% The valid input common-mode range is given by eq.(4).
% The input differential dynamic range is given by eq.(5). 2Vref/Gain 

% See 
% http://e2e.ti.com/support/data-converters/f/73/p/777781/2875264#2875264
% and
% http://e2e.ti.com/support/data-converters/f/73/p/272254/950977#950977

På flera sätt den viktigaste komponenten i systemet är analog-till-digital omvandlaren ADC:n. Det är komponenten som ska läsa in information från den yttre miljön, i detta fall elektroder på huvudet, och omvandla den till en digital representation som kan behandlas av resten av systemet.

Det finns många olika sätt att implementera en ADC och de flesta metoder har både för- och nackdelar. Utmaningen blir då att välja den implementationen som har egenskaper som gynnar den specifika tillämpningen. Speciellt när man ska mäta känsliga, i den bemärkelsen att signalen lätt kan störas av brus, signaler, så är det mycket viktigt att välja en lösning som noggrant kan mäta signalen utan att själv införa för mycket brus. 

Tidigt så bestämdes det att man skulle använda en lösning som innefattar lågpass filter, analog \textit{instrumentförstärkare} och en \textit{sigma-delta} ($\Sigma \Delta$) ADC. Resonemanget är att LP-filtret sållar bort all information utanför frekvensbandet av intresse vid ca. 0-120Hz. Signalen som blir kvar för-förstärks sedan till en nivå som enklare kan mätas av en ADC. Ofta så har en ADC en fix spänningssving; ju mer av spannet signalen utnyttjar, desto noggrannare blir mätningen, sett till signal-to-noise ratio (SNR). 

Det ADC som valdes till systemet var Texas Instruments (TI) ADS1299. Den har enligt fig. \ref{fig:FBD_ADS1299} upp till 8 parallella inläsningskanaler, med varsin inställningsbar PGA, programmerbar förstärkare, (eng. programmable gain amplifier) och $\Sigma \Delta$-omvandlare. Varje kanal har 24-bitars upplösning. Varje sampel läser alltså in upp till 8 oberoende signaler med 24 bitars upplösning. ADC:n skickar dessutom ett extra dataord på 24 bitar för varje sampel som innehåller status på olika subsystem som exempelvis ’lead-off detection’. Detta innebär en 'throughput' (sv. genomströmning, alltså data som strömmas genom systemet per tidsenhet) på $$9\cdot 24b = 216b $$ per sampel, där B är byte\footnote{En byte rymmer som bekant 8 bitar. Det är dock viktigt att skilja på bit och byte när man sedan använder prefixer. En kB eller kilobyte är alltså 8 kb eller kilobit.}. Vid en nominell sampelhastighet på 250Hz, så innebär detta en throughput på $$54\text{kbaud} = 6.75\text{kB}$$

$\Sigma \Delta$ använder \textit{oversampling}, alltså att ADC:n samplar i en betydligt högre frekvens än Nyquistfrekvensen\footnote{Nyquistfrekvensen är enligt Nyquist-Shannon teoremet den samplingsfrekvens som krävs för att kunna återskapa signalen, vilket gör att ingen signalinformation går förlorad. Nyquistfrekvensen är två gånger högre än den högsta frekvenskomponenten i signalen.
\[ f_N > 2\cdot f_{s_\text{max}} \] }. Fördelen med oversampling är att det gör att inherenta bruskällor, som \textit{kvantiseringsbrus}, kraftigt minskas. 

Kvantiseringsbrus är den momentana skillnaden mellan den riktiga analoga signalen och dess digitala representation i ADC:n. Om $\Delta$ är skillnaden mellan två digitala 'nivåer' så är det maximala kvantiseringsfelet alltså $\frac \Delta 2$. Brus som uppstår på det här viset kan anses vara 'vitt', alltså att det lägger sig uniformt på över alla frekvenser inom frekvensbandet av intresse. Det som $\Delta \Sigma$ metoden ger möjlighet till är \textit{noise shaping}, att skifta bruskomponenter från lägre frekvenser till högre frekvenser, utanför signalbandet, där de sedan kan filtreras bort med ett digitalt filter, eftersom signalen är samplad vid det här laget.\cite[kap. 6]{franco_maloberti_2007}

\begin{figure}[ht]
    \centering
    \includegraphics[width=\linewidth]{fig/diagram/FBD_ADS1299.pdf}
    \caption{Blockdiagram över I/O på ADS1299. Från vänster till höger: differentiella inputkanaler, multiplexer med valbara bias- och testsignaler, programmerbara förstärkare, biaseringssignalmultiplexer, $\Sigma \Delta$-omvandlare och SPI gränssnitt. Hämtad från datablad\cite{ads1299}.}
    \label{fig:FBD_ADS1299}
\end{figure}

\clearpage

%============================================%
%      Sub: PCB Design                       %
%============================================%
\subsection{PCB Design}
I början av arbetet var förutsättningen att all hårdvara skulle byggas på \textit{breadboards}/prototypkort med diskreta, hålmonterade komponenter. Detta visade sig dock inte vara möjligt då komplexiteten och tätheten hos elektroniken, i synnerhet ADC:n och dess många kringkomponenter, skulle visa sig kräva en mer sofistikerad lösning. En annan avgörande faktor var signalintegritet. För ett system som mäter små, bruskänsliga signaler så vill man försöka minimera effekterna av induktiv och kapacitiv koppling så mycket som möjligt. Detta görs oftast genom att orientera komponenter och ledningar rätt och minska arean och omkretsen hos ledare. Detta kan styras mycket mer noggrant på en PCB än på andra sorters prototypkort.

I detta projekt var man begränsad både av tid men också kostnad. För att tillverkningskostnaden för en PCB ska hållas inom rimliga gränser så måste huvudparametrarna så som storlek, antal lager och strömkapacitet i ledare
inskränkas. Det beslutades därför innan designarbetet påbörjades att PCB:n skulle vara dubbelsidig, alltså ha två lager. Detta är vanligen det minsta antalet som behövs för att icke-triviala kretsar ska kunna kopplas utan att behöva \textit{jumpers}, vilket är korta ledare som monteras på i efterhand och som 'hoppar över' andra ledare. Jumpers försvårar ofta designarbetet och kan möjligtvis sänka signalintegriteten. % Behövs det en källa, tro? 

%============================================%
%      Subsub: EDA verktyg                   %
%============================================%
\subsubsection{EDA verktyg och Prototyp-PCB}
%Mångfalden hos EDA program för PCB design är stor men är ofta lämpade för olika sortens design och industrier. Ett alternativ skulle ha kunnat vara Altium Designer, som används i professionella sammanhang och har flest funktioner, men bedömdes efter ett möte med en expert inom området vara för komplicerad för att lära sig att använda inom tiden som vi hade allokerat. 

De första försöken till en PCB design gjordes med ett browser-baserat program vid namnet \textit{EasyEDA}\cite{easyeda} som ägs av företaget \textit{Shenzhen JLC Electronics} som även driver PCB-tillverningsföretaget \textit{JLCPCB}\cite{jlcpcb} och elektronikkomponentåterförsäljaren \textit{LCSC}\cite{lcsc}. Detta gör att EasyEDA har kunnat integrera ett komponentbibliotek över komponenter från LCSC, samt automatiskt skapa en \textit{bill of materials} (BOM) och en direktbeställning genom JLCPCB. Det förstnämnda är speciellt intressant då ett bibliotek över verifierade komponent 'footprints', kopparmönster som stämmer överens med ledarna på komponenten, kan avsevärt minska designtiden. Alternativet är att manuellt försöka hitta dessa 'footprints' hos komponenttillverkaren eller rita/infoga dem direkt från komponentdatabladets paketbeskrivning. 

Tyvärr fanns det begränsningar i EasyEDA som gjorde det svårt eller omöjligt att växla mellan olika rutnät för olika komponenter, skapa 'keep-out' områden, där alla form av ledare exkluderas, och skapa icke-typiska hålformer genom PCB:n. Den sistnämnda funktionen behövdes för att kunna leda kameramodulens flatkabel igenom kortet enligt designen för Raspberry Pi HATs \cite{raspberrypi_hats_2019}.

För att åtgärda dessa problem byttes designarbetet till programmet KiCad\cite{kicad}. KiCad är en open-source PCB design programsvit som innefattar följande kärnprogram: schemaritningsverktyget Eeschema, layoutverktyget PcbNew och Gerbervisaren GerbView. Det finns även program som utökar funktionaliteten, som en speciell komponenteditor för att själv skapa och infoga komponenter utifrån ritningar. Ytterligare funktionalitet kan erhållas med insticksmoduler i form av Python-skript

KiCad har sammanfattningsvis funktioner som gör den jämförbar i vissa fall med rent kommersiell mjukvara utan den ingående komplexiteten som program som riktar sig åt experter har, som Altium Designer, både på gott och ont.

KiCad användes för att skapa en prototyp på ett kretskort som skulle kunna monteras på RPi:n på samma sätt som en HAT och förbinda den med ADC:n, elektroder, MCU och eventuellt ytterligare periferienheter. Kretsschemat finns i bilaga \ref{bilaga:schema}. En 3D-rendering på PCB:n finns i fig. \ref{fig:pcb_render}.

\begin{figure}[ht!]
    \centering
    \includegraphics[width=\linewidth]{fig/pcb_renders/pcb_render.png}
    \caption{3D-rendering av PCB-prototypen. Anslutningspunkter för ADC modul mitterst, ADC in- och utsignaler med filtrering nederst, ADC spänningsreglering till vänster och Atmega-328p modul högst upp till vänster. Monteringshål, hål för kameramodulens flatkabel, EEPROM och RPi GPIO anslutning finns, enligt RPi HAT standarden, längst upp till höger. }
    \label{fig:pcb_render}
\end{figure}


%============================================%
%      Par: Git och KiCad                    %
%============================================%
\paragraph{Versionshantering av KiCad filer med Git}
KiCad har, i version~5.0.1 som användes under detta arbete, inget stöd för att välja sparfil, utan man har jobbat ständigt mot en och samma sparfil genom hela projektet. Detta gör det omöjligt att spara projektet vid ett visst tillstånd eller jobba på flera olika instanser samtidigt. För detta problem har Git varit en naturlig lösning, med \textit{commits} som fångar projektets tillstånd vid en viss tidpunkt och \textit{branches} som tillåter flera olika 'förgreningar' av samma grundtillstånd.

Kicad sparar sin data i läsbar form, precis som källkod, vilket gör att Git även kan använda funktioner för att lösa konflikter mellan inkompatibla filversioner. 

%============================================%
%      Par: BOM                              %    % Ska detta med??!
%============================================%
%\paragraph{Bill of Materials (BOM)}
%En s.k. \textit{Bill of Materials} är vanligtvis en lista över de komponenter som ingår i en design, vad de kostar och eventuellt en länk till en möjlig återförsäljare. PCB kostnaden ingår inte av skälet att priset kan variera kraftigt mellan olika fabriker och vilken slags beställning man ger då fabriker ger ofta mer förmånliga priser ju enklare PCB designen är att tillverka. En mängdbeställning som utnyttjar en hel skiva av PCB råmaterial ger ofta en bättre pris per enhet än små beställningar.

%============================================%
%      Sec: Mjukvarudesign                   %
%============================================%
\clearpage
\section{Mjukvarudesign}
Detta kapitel ämnar att beskriva programmet och dess komponenter och hur dessa fungerar och agerar.
De huvudsakliga delarna av programmet är följande:
\begin{itemize}
    \item Initialisering av data och vissa inställningar samt tilldelning av vissa startvärden.
    \item Inspelning av ljud och bild.
    \item Inläsning av EEG-data.
    \item Dataskrivning, fokuserat kring interaktion med PYEDFlib och med den senast skapade filen.
    \item Videouppspelning via OMXplayer för att visa flödande bild och ljud
    %något som inte fungerande bra i början med det program som användes då, vilket var FFPlay.
\end{itemize}

Programmet är uppdelat i ett par olika delar beroende på klass, men det mesta är fokuserat i GUI-klassen och dess funktioner.
De olika knapparna i GUI:t aktiverar de primära funktionerna, så som starta inspelning, skriva annotering och sätta upp patientdata, också kallad headerdata, samtidigt som de primära funktionerna använder sig av flera av de mindre funktionerna, för att hålla systemet igång på rätt sätt.

\subsection{MobileEEG\_app} %% Escape underscores (and other special characters such as $) with \.
MobileEEG\_app är huvudklassen för själva GUI:t samt alla dess relevanta funktioner så som Record, Sync och Videoplay. 
Den är uppbyggd genom att tillämpa TkInter för att sätta upp det fönster man får upp när programmet startas, samt koden för de funktioner som knapparna i fönster aktiverar.

\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.7\linewidth]{fig/MobileEEG_app/GuiStart.png}
    \caption{Bild på hur vad hur programmet ser ut när det startas.}
    \label{fig:GuiStart}
\end{figure}

\subsection{AnnotationWindow}
AnnotationWindow är en simpel klass, vars mål är att verka som struktur och uppbyggnad av fönstret som kommer fram när man vill göra en annotering.

\subsection{HeaderWindow}
HeaderWindow sätter upp fönstret för datahämtning från användaren gällande den information som man vill att EEG-inspelningen ska ha.

\subsection{StoppableThread}
Klass som lägger in en Trace i en tråd som håller koll på när tråden skall stoppas/avslutas.

\subsection{Record}
En av GUI:ts huvudfunktioner, den som innehåller koden för att starta inspelning för ljud och bild, samt skapar subprocesser för dem, och även kallar på ReadEDF för insamlingen av EEG-datan. Resultatet av Record är tre separata filer, en för ljud, en för bild och en för EEG-datan.

\subsection{Sync}
Sync använder sig av avconv, för att sammanföra ljud- och bildfilerna till en enda mp4-fil. Detta gör så att ljud och bild spelas upp tillsammans, som en video. Avconv är en video- och audiokonverterare som finns tillgängligt i Linux.

\subsection{EDFFunction}
Detta är en av huvudfunktionerna, den spelar in endast EEG-data och inte varken ljud eller bild. Funktionen är till för den som endast vill använda produkten som ett EEG, och inte är intresserad av något annat än EEG datan.

\subsection{ReadEDF}
En simpel funktion som ser till att det finns headerdata, och som startar en tråd av EDFFunction, för att kunna köras pseudoparallellt med ljud och bild subprocesserna.

\subsection{Videoplay}
Videoplays uppgift är att använda omxplayer för att spela upp den senaste sammanfogade versionen av ljud och bild, samt att den spelas upp i en viss storlek och position på skärmen.

\subsection{Videostop}
Videostop är till för att stoppa den video som spelas upp för tillfället, den gör detta genom att stänga av alla processer som körs med omxplayer.

\subsection{Popup}
Funktion som sätter upp en instans av ett annoteringsfönster, för att kunna skriva en annotering.

\subsection{PyEDFlib}
Det är med hjälp av det tidigare etablerade pythonbaserade biblioteket PyEDFlib, med sina EDF-specifika funktioner, som 
programmet lätt kan skriva data enligt EDF-formatet. 

Funktionerna som används har för uppgift att bland annat; skriva den data som användaren av GUI:t anger som headerdata till filen, skriva annoteringar till filen med annoteringsdatan, samt att sätta upp allting enligt EDF-formatet.


\subsection{Inspelning}
Inspelning av information, både ljud, bild och EEG data, är en central del av projektet. För detta så har det utvecklats flera olika funktioner, som har hand om varsin del, och som körs parallellt med hjälp av trådhantering. 
Både ljud och bild var relativt lätta att implementera, då det fanns färdig funktionalitet i operativsystemet Debian för RPi's. Då detta är Linux-baserat så finns det standard Linux-verktyg tillhands att implementera och nästla tillsammans med GUI-paketet TkInter.

Till EEG-inspelningen så var det en klart större och svårare uppgift, då detta handlar om att samla biofysisk data från elektroder. Detta behövs göras via en ADC för omvandling från analog till digital, samt en mikrokontroller för att kunna skicka denna datan på ett pålitligt, snabbt och säkert sätt. Som tidigare nämnts, så är detta den del som inte blev klar, däremot så finns det både design och prototyp för hur det skulle kunna fungera.

Ett problem för projektet var att det inte fanns en färdig lösning för EEG-inspelning att använda sig av tillsammans med den utvalda ADC:n. Detta gjorde att mycket fick göras från grunden, så som design av ett PCB-kretskort för just ADS1299, vilket inte var något som planerades från start, och gjorde, tillsammans med andra problem, att projektet inte blev klart i tid.


\subsection{Start och Stopp}
Huvudfunktionen i GUI:t är att kunna starta samt stoppa en inspelning av såväl ljud och bild som data. Implementationerna av de olika inspelningarna genererar processer samt trådar, vilket gör att för att kunna avsluta dem krävs det att man hanterar processerna samt trådarna på rätt sätt. 

Det finns många sätt för systemet att stanna, när den bestämda tiden tagit slut, att man klickat på stopp eller om programmet skulle krascha. Oavsett anledning så behöver systemet hantera detta och avsluta programmet på ett korrekt sätt för att inte någon data ska bli korrupt, att processer inte ligger kvar i bakgrunden och kör eller att minnesläckor orsakas.

Genom att analysera programmet och se vilka platser i koden där programmet ska eller kan avslutas, så kan införa hantering av både trådar och processer och se till att de stängs av på rätt sätt.


\subsection{Synkronisering av ljud och bild}
För att maximera prestandan vid inspelning av olika slags data så används olika program som är speciellt lämpade för ändamålet. För att spela in från kameran så används programmet \textit{raspivid} som är speciellt anpassat för hårdvaran i RPI:en och tillåter viss hårdvaruaccelerering. För att spela in ljud används programmet \textit{arecord} som finns att användas i samband med \textit{ALSA} ljudkortsdrivrutinen. 

Båda programmen är relativt 'lågnivå' och genererar data i 'raw'-format, 'wav' för ljud och 'h264' for bild, vilket skulle kunna användas direkt, men eftersom minneskapaciteten på RPI:en är begränsat så sammanflätas de olika dataströmmarna till en komprimerad 'mp4'-fil. Detta görs med programmet \textit{avconv}.


\subsection{Uppspelning}
Från början var tanken att man direkt skulle kunna se EEG-datan, samt video samtidigt i en nästlat videospelare, tillsammans med ett sätt att interagera med datan. Under utvecklingen så kom insikten att det skulle bli mycket jobb, för en visuell del som inte är högst relevant för projektet, utan snarare extra funktionalitet. Detta gjorde att det lades endast fokus under korta perioder, främst för att få en simpel videouppspelnig att fungera, och inte mer. 

En fördel är att alla filer kan nås genom att ansluta till RPi:en via till exempel SSH, och sedan kan de föras över till en PC eller laptop. Det finns inget komplicerat databassystem, utan de skapas som simpla filer som kan hanteras fritt av användare.

Uppspelningen är relativt primitiv, då det inte finns alternativ att spola eller hoppa fram och tillbaka i uppspelningen eller att välja fil, utan endast start och stop. Det funktionen knappen kallar på gör är att den letar upp den senast skapade videofilen, den som är resultatet av synkroniseringen av ljud och bild, och spelar den.


\subsection{Annotering}
Annotering är att man kan lägga in kommentarer under inspelningen av EEG-datan. Detta gör att den som hanterar GUI:t kan, om någon specifik extern stimulus till synes påverkar datan, lägga in en kommentar om vad som orsakade det eller någon annan relevant information. 

Detta implementerades genom att använda bakgrundstrådar, samt popuprutor från TkInter. Tanken var först att man skulle lägga in en kommentar samtidigt som man tryckte på annoteringsknappen, men denna ide frångicks av två anledningar: först så var tanken att en popupruta potentiellt skulle distrahera från datan som spelades in under tiden man skrev kommentaren, samt att det skulle bli komplicerat att implementera. Komplikationen är att specifikationer i EDF-formatets implementation i biblioteket som användes tillåter inte att annoteringar läggs in under inspelning. Istället gjordes beslutet om att man får trycka på knappen, så sparas en tidsstämpel för när annoteringen ville läggas in, och efter inspelning så får man upp en popupruta för varje tryck man gjort, då man senare kan skriva de kommentarer man velat. 

I efterhand så skulle förmodligen en implementation där man får skriva kommentaren direkt vara bättre, då en EEG-inspelning brukar vara minst 30 minuter och vanligen 60 minuter, under vilken tid man lätt kan glömma vad man ville skriva vid en specifik tidpunkt. Samt att det är potentiellt inte så relevant eller skadligt om man blir distraherad under den korta period det tar att skriva en kommentar, då EEG-data kollas bäst i efterhand då man kan gå igenom datan noga med hög precision.

\begin{figure}[!ht]
    \centering
    \includegraphics[width=0.5\linewidth]{fig/MobileEEG_app/AnnotationWindowEvent.png}
    \caption{Här visas den rutan som visas när man ska göra en annotering efter en inspelning.}
    \label{fig:AnnotationWindowEvent}
\end{figure}

\clearpage
\subsection{Metadata}
EDF-formatet vill gärna ha en rad olika information, så som namn på patient, namn på den som utför EEG-testet, patientkod, bakgrundsinformation, och många fler. Det bestämdes därmed att detta skulle implementeras. 

Det realiserades genom att skapa en egen popuprute-klass för TkInter, vilket hade textfält för all data. Information skrivs in i EDF-formatet via funktioner från PyEDFlib, dock så är det ett krav från funktionerna att detta görs innan inspelning påbörjas för att datan ska skrivas in korrekt. 
Följden av detta kravet, tillsammans med den mänskliga faktorn, gjorde att det implementerades en simpel säkerhetsåtgärd så att knappar som startar processer som kan störa det som körs för tillfället deaktiveras.


\begin{figure}[h]
    \begin{subfigure}{0.5\linewidth}
        \centering
        \includegraphics[width=0.7\linewidth]{fig/MobileEEG_app/SetHeaderEmpty.png}
        \label{fig:SetHeaderEmpty}
        \subcaption{Dialogruta med tomma fält.}
    \end{subfigure}
    \begin{subfigure}{0.5\linewidth}
        \centering
        \includegraphics[width=0.7\linewidth]{fig/MobileEEG_app/SetHeaderFilled.png}
        \label{fig:SetHeaderFilled}
        \subcaption{Dialogruta med exempel på giltig indata.}
    \end{subfigure}

    \caption{Bilden till vänster visar hur det ser ut när man skriver in sin metadata. Den högra bilden visar ett exempel på hur datan ser ut när den är ifylld. Dialogrutor för att fylla i headerdata i EDF+ filen.}
    \label{fig:SetHeader}
\end{figure}
