\chapter{Teknisk Bakgrund}\label{kap:teknisk_bakgrund}
I detta kapitel redovisas de olika subsystem som projektet består av. Dessa delas upp logiskt i hårdvara och mjukvara.

%============================================%
%      Sec: Hårdvara                         %
%============================================%
\section{Hårdvara}
Här presenteras än översikt över de större hårdvarumodulerna som systemet i projektet består av. Detta ska ge en förståelse över vad de är och varför de är lämpade för ändamålet. En fullständig systembeskrivning hittas i kap. \ref{kap:systembeskrivning}.
%============================================%
%      Sub: Raspberry Pi                     %
%============================================%
\subsection{Raspberry Pi}
En Raspberry Pi (RPi) är en \textit{enkortsdator}\footnote{En enkortsdator (eng. \textit{single-board-computer}) skiljer sig från en vanlig dator i med att all hårdvara, även sådant som brukar finnas som insticksmoduler, som primärminne exempelvis, finns på samma kretskort. Detta har naturligtvis fördelen att hårdvaran kan minimeras, vilket gör den mer portabel.} som kör, bland annat, linuxbaserade operativsystem (OS) och därmed tillåter stor frihet att programmeras till användarens behov. Det används brett av många olika individer samt organisationer, och är utmärkt när det kommer till små eller mobila produkter som kräver beräkningskraft och/eller ett fullfjädrat operativsystem. Typiska användningar för en RPi är som egengjord säkerhetskamera eller som strömsnål webbserver. 

I praktiken så kan RPi användas både som en 'vanlig' dator med en grafisk miljö och periferikopplingar eller på ett antal andra sätt. Ett sätt att använda en RPi är som ett strömsnålt inbyggt system som kan styra utrustning på låg nivå med inbyggda hårdvarumoduler där kommunikationsprotokoll som SPI och seriell finns inbyggt i processorn eller för att styra en stor uppsättning GPIO (eng. \textit{General-Purpose Input/Output}) pinnar.

RPi har uppdaterats med nya versioner sedan den första lanseringen 2012, och versionen som planerades att användas i detta projekt var Raspberry Pi 3B+, som till skillnad från tidigare versioner har inbyggt WiFi och Bluetooth samt en variant på Cortex-A53 processorn, som implementerar ARMv8-A instruktionsuppsättningen, med högre nominell klockfrekvens\cite{raspi_3b+_specs}. 

%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 Model 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. %Flyttat till Genomförande i 'Allmänt arbetssätt'
%============================================%
%      Sub: Mikrokontroller                  %
%============================================%
\subsection{Mikrokontroller}
En mikrokontroller eller \textit{microcontroller unit} (MCU) är en programmerbar krets med hög flexibilitet som kan användas i många generella sammanhang där det inte förekommer extrema prestandakrav. Uppgifter som kräver extrem prestanda, till exempel grafikprocessering, betjänas oftast bättre ur ett tekniskt och ekonomiskt perspektiv av mer dedikerad hårdvara, som är per definition mindre flexibel.% Se \textit{digitala signalprocessorer} (DSP).

En stor skillnad mellan en MCU och en mer traditionell dator som RPi:en är att den inte kör något operativsystem eller kernel om inte man programmerar en på egen hand. 
%Koden som skrivs kompileras till instruktioner på maskinnivå som styr hårdvaran direkt. Denna närhet mellan mjukvara och hårdvara gör framförallt att den processortid som används till \textit{overhead} minskas, med andra ord operationer som inte direkt används för den uppgiften man vill utföra. 
Koden man skriver kompileras till instruktioner på maskinnivå och på en MCU utan OS kommer instruktionerna att exekveras direkt utan eventuella avbrott från ett OS. Denna närhet mellan mjukvara och hårdvara gör framförallt att man minskar den processortid som används till \textit{overhead}, med andra ord operationer som inte direkt används för den uppgiften man vill utföra.
På en MCU är det sällan man önskar arbeta på flera uppgifter parallellt. Ett undantag är flerkärniga MCU processorer där komplexiteten ökar avsevärt. Man undviker därmed overhead på grund av att processorn ska byta mellan olika program på grund av pseudo-parallell exekvering vilket innebär minskad latens\footnote{Latens är den tidsfördröjning mellan en insignal och motsvarande utsignal och är skild från datatakt. Om man, till exempel, önskar en låg svarstid för en tidskänslig uppgift så skall man ha låg latens, oberoende av övrig prestanda.} för IO (eng. Input/Output) operationer. Allt detta gör MCU:er lämpade för system med \textit{realtidskrav}, som hanterar tidskänsliga uppgifter.

En MCU kan användas för att komplettera ett OS-baserat system, som en RPi, med ett låglatens 'realtidsgränssnitt' och kan då ses som en buffer mellan realtids- och icke-realtidssystem. Den betjänar realtidssystemet enligt tidskraven och kan sedan överföra informationen till icke-realtidssystemet när både den och MCU:n har ledig processortid. Detta beskrivs mer utförligt i kap. \ref{kap:systembeskrivning}.


% används främst för att avlasta tidskänsliga uppgifter från RPi:en, som på grund av sitt linuxbaserade operativsystem inte kan hantera realtidsuppgifter.
%På så sätt kan den ses som en buffer mellan realtidskomponenterna och styrenheten.
Båda projektmedlemmarna har tidigare erfarenhet av Arduino hårdvaran samt utvecklingsplattformen och därför valdes mikrokontrollern Microchip ATmega 328P\cite{atmega328p_datasheet}. För att göra den elektriskt kompatibel med RPi så matas den med 3.3V systemspänning vilket även gör att klockfrekvensen måste sänkas 8~MHz från nominella 16MHz vid 5V. För detta projekt är det värdefullt att notera att den har inbyggda hårdvarumoduler för SPI, seriell kommunikation och externa interrupts, då det underlätta kommunicering med andra hårdvarumoduler. Ytterligare protokoller som inte har hårdvarustöd kan implementeras i mjukvara genom så kallad ’bit-banging’, det vill säga att ett kommunikationsprotokoll kan implementeras helt i mjukvara genom direkt styrning av GPIO pinnar.

%============================================%
%      Sub: ADC                              %
%============================================%
\subsection{Analog till Digital Omvandlare (ADC)}
En ADC är en krets avsedd att omvandla analoga signaler till en digital representation för att kunna bearbetas digitalt. 

Att mäta EEG signaler är av sin natur relativt svårt att göra eftersom de har en låg amplitud och lätt kan störas ut av brus, vilket ställer höga krav på ADC:n samt resten av den analoga datavägen. För att kunna göra systemet så robust och bruståligt som möjligt samtidigt som man integrerar så mycket av den analoga elektroniken som möjligt valdes en \textit{integrerad krets} (IC) från \textit{Texas Instruments}, ADS1299 \cite{ads1299}, som enligt tillverkaren är lämpad för just mätningar inom medicin och i synnerhet EKG och EEG. 

De flesta MCU:er har flertalet inbyggda ADC:er, men de är oftast begränsade i sin prestanda jämfört med dedikerade kretsar.

%============================================%
%      Sub: Batteri                          %
%============================================%
\subsection{Batteri}
En viktig del i systemet är batteriet och dess kapacitet och kraftleveransförmåga. RPi:n beräknades vara den mest strömkrävande delen i systemet. Den använder relativt lite ström  men kan, beroende av processorlasten och vilken slags kringutrustning som är ansluten, som kamera och mikrofon, dra mer ström än vad en 'vanlig' powerbank klarar att leverera. För att en RPi inte ska överbelasta strömkällan, så behöver den klara ca. 2A, vilket batteriet skulle behöva kunna tillföra. 
Batteriet som valts är av Deltaco:s modell, har en kapacitet på 6000mAh, och har en output på 5V och 2A. Spänningsregleringen på RPi kortet står för omvandling till 3.3V.

%============================================%
%      Sub: Kamera                           %
%============================================%
\subsection{Kamera}
Kameran, som i systemet används för att spela in video, ansluts direkt till RPi:n via ett \textit{CSI} (Camera Serial Interface)\footnote{CSI är en specifikation av MIPI (Mobile Industry Processor Interface) Alliance.} gränssnitt och är av typen \textit{Camera Module V2}. Fördelen med detta gränssnitt är att man slipper vissa mellanliggande kommunikationsprotokoller innan datan från kameran når processorn, vilket ger en stor prestandavinst.  

%============================================%
%      Sub: Mikrofon                         %
%============================================%
\subsection{Mikrofon}
Alla versioner av RPi saknar analog mikrofonanslutning och därför krävs en ADC krets, också kallad ljudkort i när det gäller en insticksmodul för ljudsignaler, för att omvandla mellan analoga signaler från mikrofonens 3,5mm kontakt till en digital signal som kan överföras via RPi:ns USB port. En enkel headsetmikrofon har använts i projektet då det varit oviktigt vilken typ eller modell som används.

%============================================%
%      Sub: PCB                              %
%============================================%
\subsection{PCB}
\textit{Printed circuit board} eller PCB (\textit{sv. mönsterkort}), är i enklaste fallet ett lager med isolerande material, oftast glasfiberepoxi, och ett tunt skikt med kopparfolie i ett visst mönster som utgör elektriska ledare i en krets. Kopparskikt kan finnas på båda sidorna av ett kretskort och även inne i det isolerande materialet för att få \textit{flerlagerskort}. Syftet med att använda en PCB gentemot andra former av prototypkrets såsom 'breadboards' och 'perfboards' är att det underlättar avsevärt i mera komplexa kretsar där komponenterna är mindre, har fler elektriska kopplingar och har en allmänt tätare integration. Genom att använda \textit{electrical design automation} (EDA) verktyg för PCB design så kan man också genom \textit{design rule checks} (DRC) verifiera kretsen på olika sätt innan den tillverkas.

\begin{figure}[ht]
    \centering
    \includegraphics[width=0.8\textwidth]{fig/diagram/PCB_layers_diagram.png}
    \cprotect\caption{Tvärsnitt av ett 4-lagers PCB med väsentliga områden markerade.\\Photo: Rainer Knäpper, Free Art License (\url{http://artlibre.org/licence/lal/en/}), \url{https://commons.wikimedia.org/wiki/File:Bga_und_via_IMGP4531_wp.jpg} }
    \label{fig:pcb_layers}
\end{figure}

I fig. \ref{fig:pcb_layers} ser man en typisk flerlagers PCB. Den har ett topp- och bottenskikt och två inre lager som inte syns utifrån. Olika lager kan kopplas genom att använda en \textit{via}, ett kopparplatterad borrhål som utgör en lodrät ledare. I figuren ser man hur lager 1 och bottenskiktet kopplas ihop. En via som enbart kopplar inre lager kallas för en 'buried' (sv. begravd) via då den inte kan kommas åt utifrån. Dessa brukar undvikas då de kan försvåra felsökning och dessutom inte kan åtgärdas ifall ett tillverkningsfel skulle uppstå.


%============================================%
%      Sec: Mjukvara                         %
%============================================%
\clearpage
\section{Mjukvara}
Detta kapitel går igenom de olika program mjukvaruverktyg som använts i projektet.

%============================================%
%      Sub: Python                           %
%============================================%
\subsection{Python}
Python är ett objektorienterat, interpreterad\footnote{Ett interpreterat programspråk behöver inte kompileras utan ’tolkas’ under själva körningen.} programmeringsspråk som är lättlärt och högt modulärt i sin dynamiska funktionalitet. Det finns många bibliotek i diverse tillämpningar. På grund av dess struktur i hur det är formerat, med dynamisk typsättning och det faktum att man inte behöver kompilera källkoden, gör att det är attraktivt som bland annat skriptspråk. På grund av de olika biblioteken som stöds, så är Python oerhört adaptivt i dess användning, vilket var en av anledning till att det valdes som språk för projektet. Tanken var att oavsett sätt som valdes att implementera lösningar, så skulle det vara relativt simpelt med ett språk som Python. \cite{python}

%============================================%
%      Sub: TkInter                          %
%============================================%
\subsection{Tk Interface (TkInter)}
TkInter är ett Python API för Tk GUI toolkitet. Det är en defakto standard för pythonbaserade GUI-applikationer och är det mest använda av sitt slag. Det är använt i programmet för att utveckla ett GUI för lättillgänglig användarvänlighet i programmets styrning. \cite{TkInter}

%============================================%
%      Sub: EDF+                             %
%============================================%
\subsection{European Data Format (EDF)}
EDF är ett relativt enkelt och flexibelt format för hantering av multikanaliga bioelektriska signaler. Det skapades för att kunna applicera sina sömnanalysalgoritmer på sin respektive data och så att resultaten av dessa sedan kunde jämföras med varandra. Sedan 1992 så har EDF varit standard för bland annat EEG data, samt Polysomnografi (PSG) data, men kan även användas för att lagra annan bioelektrisk data. Sedan den introducerades har formatspecifikationen uppdaterats till en ny version, EDF+, och har numera stöd för funktioner som anteckningar med inbyggda tidsstämplar och möjligheten att kunna pausa inspelning av data. \cite{teunis} 
\cite{KEMP20031755}

%============================================%
%      Sub: Linuxprogram                     %
%============================================%
\subsection{Linuxprogram}
Ett flertal program som installerats under RPi:ns linuxmiljö har använts, till exempel, {\tt raspivid} och {\tt arecord} för att spela in video, respektive audio och OMXPlayer för att spela upp video. Dessa program anropas av huvudprogrammet, som är skriven i Python, vilket gör att programmet för tillfället är linuxbundet. Pythonkoden kan relativt lätt anpassas till att använda vad som finns till hands i den aktiva miljön i framtida utveckling. 


En viktig del med OMXPlayer är att den är hårdvaruaccelererad, vilket innebär att den kan jobba emot dedikerad avkodningshårdvara och är ett krav om video skall kunna spelas upp i korrekt hastighet. Alternativet är att RPi:n avkodar videoströmmen med mjukvarubibliotek som ger mycket mer ’overhead’ samtidigt som RPi:n saknar processorkraften att utföra sådana komplexa beräkningar i realtid\cite{omxplayer}.

%============================================%
%      Sub: PyEDFlib                         %
%============================================%
\subsection{Python EDF Library (PyEDFlib)}
PyEDFlib är ett pythonbaserat EDF bibliotek som innehåller en mängd funktioner för att lätt kunna skriva Pythonbaserade applikationer som använder sig av EDF för att hantera signaler. Detta bibliotek är en inkapsling av det ursprungliga biblioteket EDFlib, skriven i C\cite{teunis_edflib}.

%Detta bibliotek är Pythonkonstruerade funktioner från programmeringsspråket C och det EDF bibliotek som existerar i det språket.

%\subsection{Testdriven utveckling}
%\subsection{Verifiering av komponentfunktionalitet}
%\subsection{Mätning mellan två punkter}
