FP1 FP2 F3 F4 C3 C4 P3 P4 O1 O2 F7 F8 T3 T4 T5 T6 FZ CZ PZ E PG1 PG2 A1 A2 T1 T2 10:18:44 (0:00:02) 10 sec ma0844az 1-1+.edf 1234567 M 09-APR-1955 L. Smith 15 sep 2005 2 Kesteren Nihon Kohden EEG-1100C V01.00 Mobilt Elektroencefalografi Examensarbete i Data och -Informationsteknik JOHN CROFT CHRISTOFFER OLSSON Institutionen för Data och -Informationsteknik CHALMERS TEKNISKA HÖGSKOLA GÖTEBORGS UNIVERSITET Göteborg, Sverige 2019 EXAMENSARBETE Mobilt Elektroencefalografi JOHN CROFT CHRISTOFFER OLSSON Institutionen för Data och -Informationsteknik CHALMERS TEKNISKA HÖGSKOLA GÖTEBORGS UNIVERSITET Göteborg, Sverige 2019 Mobilt Elektroencefalografi JOHN CROFT CHRISTOFFER OLSSON c© JOHN CROFT, CHRISTOFFER OLSSON, 2019 Examinator: Peter Lundin Institutionen för Data och -Informationsteknik Chalmers Tekniska Högskola/Göteborgs Universitet SE-412 96 Göteborg Sverige Telefon: +46 (0)31-772 1000 The Author grants to Chalmers University of Technology and University of Gothenburg the non-exclusive right to publish the Work electronically and in a non-commercial purpose make it accessible on the Internet. The Author warrants that he/she is the author to the Work, and warrants that the Work does not contain text, pictures or other material that violates copyright law. The Author shall, when transferring the rights of the Work to a third party (for example a publisher or a company), acknowledge the third party about this agreement. If the Author has signed a copyright agreement with a third party regarding the Work, the Author warrants hereby that he/she has obtained any necessary permission from this third party to let Chalmers University of Technology and University of Gothenburg store the Work electronically and make it accessible on the Internet. Omslag: Typisk elektroencefalogram. Institutionen för Data och -Informationsteknik Göteborg, Sverige 2019 Mobilt Elektroencefalografi JOHN CROFT CHRISTOFFER OLSSON Institutionen för Data och -Informationsteknik Chalmers Tekniska Högskola/Göteborgs Universitet Examensarbete Sammanfattning Dagens teknologi fortsätter alltjämt att utvecklas. För att fortsätta denna trend p̊a samma sätt, s̊a ämnar detta projekt att skapa en produkt för att möjliggöra en mobil implementation av ett EEG. Projektet är gjort hos Institutionen för Data- och Informationsteknik p̊a Chalmers. Ett elektroencefalografi (EEG) används för att detektera och mäta jonströmmar i hjärnans nervceller. Dessa kan mätas genom att fästa spänningskänsliga elektroder vid skalpen, och används för att fastställa olika tillst̊and i hjärnan s̊a som epilepsi, koma och hjärndödhet. Tanken bakom projektet är att dess mobilitet och lättillgänglighet kan öppna upp möjligheten till ett stort utbud av data. Denna datamängd kan potentiellt användas för att analysera hur människan katalogiserar det hon lär sig och hur olika extern stimuli p̊averkar denna process. Grundkrav inkluderar att det ska fungera precis som ett vanligt EEG, samt att det ska finnas ett enkelt sätt att interagera med mjukvaran. Det skall ocks̊a finnas ett sätt att spela in ljud och bild fr̊an användarens perspektiv. Projektet har följaktligen utvecklat en h̊ardvarudesign för att samla in EEG-data, samt utvecklat ett GUI för att lätt använda systemet. Projektets utveckling är tyvärr en ofulländad produkt, och en del av de mål som sattes fr̊an början har ej uppn̊atts. Utvecklingen av projektet har resulterat i kunskap om EEG och datainsamlingssystem, och de begränsningar som finns med programmeringsspr̊ak och h̊ardvara i att realisera ett digitalt system med realtidskrav. Resultaten har använts som kunskapsbas till ett annat projekt, och ämnar användas till flera likasinnade utvecklingar i framtiden. Nyckelord: EEG, Python, Raspberry Pi, tkInter, ADC, EDF+ i Abstract Today’s technology is constantly undergoing new innovations and evolutions. In keeping with this trend, this project aims to take the well-established measuring technique of electroencephalography (EEG) and create a mobile implementation. The project has been performed at Chalmers. An Electroencephalography (EEG) is used to detect and measure ion currents in the brains nerve cells. These can be measured by attaching voltage sensitive electrodes on the scalp, and is used to determine difference conditions in the brain, such as epilepsy, coma and brain death. The idea behind the project is that its mobility and availability can open an opportunity for large amounts of data. This large data set can potentially be used to analyse how humans catalogue what she learns, and how varying external stimuli affects this process. Basic requirements include that it should function as a normal EEG, as well as there should exist a simple way to interact with the software. The project has consequently developed hardware to collect EEG-data, as well as created a GUI for easy use of the system. The project development is unfortunately an unfinished product, and some of the initial goals have not yet been completed. The results of the project has resulted in a more in-depth knowledge of what an EEG is, and also the limitations that exists in programming languages and hardware when one tries to create a real time system. The results have been used as a knowledge base for another project, and aims to be used for more like-minded projects in the future. Keywords: EEG, Python, Raspberry Pi, tkInter, ADC, EDF+ ii Terminologi Σ∆-modulation Metod som gör det möjligt att skifta bruskomponenter fr̊an lägre frekvenser till högre frekvenser, utanför signalbandet, där de sedan kan filtreras bort med ett digitalt filter. ADC Analog-to-Digital Converter. Omvandlar analoga signaler till en digital representa- tion. ADS1299 Analog-till-digital omvandlare fr̊an Texas Instruments avsedd för biopotentiala mätningar. ALSA Advanced Linux Sound Architecture. En linux kernelmodul som ger tillg̊ang till ett programmeringsgränssnitt för ljudkortsdrivrutiner. Baud Ett mått p̊a datatakt. Enheten är symboler per sekund, där en symbol är en unik signalkodning. I digitala system används uteslutande binär representation p̊a information och därmed kan baud tolkas som bitar per sekund i s̊adana sammanhang. BOM Bill of Materials. Lista över komponenter som ing̊ar i en design. Genereras ofta automatiskt av EDA verktyg och kan eventuellt inneh̊alla mer information s̊asom pris, länk till återförsäljare mm. CAD Computer Aided Design. Ett generellt begrepp p̊a datorprogram som används för att skapa tekniska ritningar eller modeller i 2D och/eller 3D. CSI Camera Serial Interface. Standardiserad gränssnitt mellan en kameramodul och en processor. EDA Electronic Design Automation. Ett löst begrepp p̊a olika datorprogram vars syfte är att underlätta design av elektroniska system, speciellt PCB design. EDF+ European Data Format. Filformat som används för lagring av bioelektriska signaler, speciellt elektroencefalografiska signaler. EEG Elektroencefalografi. Mätning av elektriska signaler i hjärnan. EKG Elektrokardiografi. Mätning av elektriska signaler i hjärtat. GUI Grafiskt användgränssnitt (eng. Graphical user interface) Half-cell potential DC-spänning som utvecklas över gränssnittet mellan hud och elektrod. MCU Mikrokontroller. Förkortning p̊a engelskans microcontroller unit. OS Operativsystem. PCB Mönsterkort (eng. Printed circuit board). PGA Programmerbar förstärkare (eng. Programmable Gain Amplifier). En förstärkare där förstärkningskvoten kan ställas in digitalt. RPi Raspberry Pi. En s.k. enkortsdator med processor och all kringutrustning p̊a en och samma krets. Kör ett fullfjädrat Linux operativsystem (Debian). SNR Signal-brusförh̊allande (eng. Signal-to-noise ratio) SPI Serial Peripheral Interface. Ett seriellt, synkront, tv̊a-vägs kommunikationsprotokoll SSH Secure Shell. Ett protokoll för säker anslutning till fjärrdatorer över internet. iii iv Inneh̊all Sammanfattning i Abstract ii Terminologi iii Inneh̊all v 1 Inledning 1 1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.3 Mål . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 Teknisk Bakgrund 3 2.1 H̊ardvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.2 Mikrokontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1.3 Analog till Digital Omvandlare (ADC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.4 Batteri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.5 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.6 Mikrofon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.7 PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Mjukvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Tk Interface (TkInter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.3 European Data Format (EDF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.4 Linuxprogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.5 Python EDF Library (PyEDFlib) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Metod 7 3.1 Agila metoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Git och GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3 Kunskapsinhämtning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4 Teoretisk Bakgrund 9 4.1 Elektroencefalografi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2 Biopotentialer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3 Biopotentiala Elektroder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4 Kliniskt EEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5 Genomförande 12 5.1 Förberedelse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1 Allmänt arbetssätt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2 Systemdesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.1 Systembeskrivning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2.2 Datakommunikation inom systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.2.1 SPI gränssnitt p̊a ADC ADS1299 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2.3 ADC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.4 PCB Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2.4.1 EDA verktyg och Prototyp-PCB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3 Mjukvarudesign . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.1 MobileEEG app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.2 AnnotationWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.3 HeaderWindow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 v 5.3.4 StoppableThread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.3.5 Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.6 Sync . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.7 EDFFunction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.8 ReadEDF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.9 Videoplay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.10 Videostop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.11 Popup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.12 PyEDFlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.3.13 Inspelning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.14 Start och Stopp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.15 Synkronisering av ljud och bild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.16 Uppspelning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.3.17 Annotering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3.18 Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 Resultat 25 6.1 Summering av svar p̊a fr̊ageställningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.1 Vilket programmeringsspr̊ak bör användas? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.2 Vilken samplingsfrekvens bör användas för EEG signalerna. . . . . . . . . . . . . . . . . . . . . . 25 6.1.3 Vad finns det för dataformat som är lämpade för EEG signaler? Vilket bör användas i denna tillämpning? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1.4 Klarar systemet alla beräkningsbehov? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.2 Mål som uppn̊atts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3 Mål som ej uppn̊atts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4 Modell av lösning p̊a överförning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.5 Användning av Mobilt EEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 7 Diskussion 28 7.1 Diskussion av resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2 Genomg̊ang av problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.1 Antaganden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.1 Biologiska problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.2 Kunskap om hjärnan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.3 Programmeringsspr̊ak inte spelar n̊agon roll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.4 Pröva olika ADC:er . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.5 Databas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.1.6 Externt beräkningsprogram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2.1.7 Streama Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2.2 Oförutsedda problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2.2.1 Raspberry Pi ej lämpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2.2.2 Python ej lämpad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.2.2.3 Saknad av färdig ADC-lösning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2.2.4 Extra h̊ardvara . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.2.2.5 Huvudbonad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.3 Miljö och Etik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.4 Övriga tankar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5 Möjliga Lösningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.1 En enda mikrokontroller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.2 Interrupt knapp som startar b̊ada h̊ardvaran samtidigt . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.3 Extern lagring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.5.4 Extern buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.5 DMA (Direct Memory Access) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.6 Tr̊adlös överföring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.7 Realtids-OS för RPi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.5.8 Realtidstillägget CONFIG PREEMPT RT för Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 vi 8 Framtida Utveckling 34 9 Bilagor 35 9.1 PCB-kretsschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Referenser 37 vii viii 1 Inledning 1.1 Bakgrund Nuförtiden används elektroencephalografi (EEG) för att, ofta i samband med andra metoder, diagnostisera och karakterisera olika hjärnsjukdomar som, framförallt, epilepsi men ocks̊a hjärninflammation och koma. Andra diagnostiska metoder som MRI (Magnetic Resonance Imaging) och CT (Computed Tomography Scan) är i m̊anga avseenden överlägsna, men är begränsade rent praktiskt av tyngden och storleken p̊a utrustningen och kan oftast bara utföras vid en fast installation. Eftersom EEG inte nödvändigtvis drabbas av detta problem finns det potential att skapa en mobil implementation. Ett mobilt EEG av detta slag skulle teoretiskt kunna genomföras under andra omständigheter och p̊a andra platser än p̊a ett sjukhus, vilket eventuellt kan öppna upp outforskad data för framtida forskning inom biofysik och andra relevanta fält. Förhoppningsvis s̊a kommer den mobila aspekten även medföra en minskning i den tid som det tar att applicera elektroderna p̊a en patient. Exakt hur människan lär sig, hur vi tar in och katalogiserar information, är fortfarande relativt okänt och är ett aktivt forskningsomr̊ade. Ett mobilt EEG skulle exempelvis kunna användas för att försöka anpassa studietekniker, utbildning och miljö för optimala förh̊allanden. Projektet genomfördes hos Institutionen för Data- och Informationsteknik p̊a Chalmers. 1.2 Syfte Projektet syftar till att besvara fr̊agan hur man p̊a ett lämpligt sätt kan konstruera ett mobilt system för att utföra EEG-test. Systemet skall designas utifr̊an vissa förutsättningar för att sedan konstrueras till ett fungerande system. 1.3 Mål Målet med projektet är att utveckla ett EEG-system som är lättanvänt, funktionellt samt mobilt. Man vill att systemet samtidigt skall spela in extern stimuli genom användningen av en monterad kamera och mikrofon, samt logga all data för alla anslutna elektroder. Denna information skall samlas parallellt med varandra och sedan tidsstämplas för varje sampel, för att korrelera hjärnaktivitet med extern stimuli. Följande delm̊al gäller initialt för projektet: • Att ha ett simpelt interaktivt GUI som har funktionalitet för att starta och stoppa inspelning. • Köras p̊a batteri. Det ska även fungera med sladd. • Läsa in EEG-data fr̊an elektroder med känd testsignal för att bekräfta funktionalitet hos ADC och eventuellt kalibrera den. • Läsa in EEG-data fr̊an elektroder anslutna till occipitalloben p̊a en patient. Occipitalloben ger av sig en stark, tydlig signal som kan användas för att bekräfta funktionalitet av elektroder och eventuell förfiltrering. [31, s.172] • Läsa in EEG-data fr̊an elektroder anslutna till övriga hjärnomr̊aden. • Skriva data p̊a EDF-formatet. 1 • Fungerande ljud- och bildinspelning samt omkodning till lämplig container1-format. • Förena h̊ardvaran s̊a att det blir en produkt, i form av en mössa för elektroder, samt ett paket för resterande h̊ardvara som kan placeras n̊agonstans p̊a kroppen. Med detta kan man ställa vissa fr̊agor som skall besvaras. • Vilket programmeringsspr̊ak bör användas för mjukvaruutvecklingen? • Vilken samplingsfrekvens bör användas för EEG signalerna? • Vad finns det för dataformat som är lämpade för EEG signaler? Vilket bör användas i denna tillämpning? • Klarar systemet alla beräkningsbehov? 1.4 Avgränsningar De avgränsningar som finns för detta projekt är: • Det ing̊ar ej i projektet att tolka EEG-datan, d̊a speciell kunskap samt träning krävs. • Det ing̊ar ej i projektet att filtrera eller p̊a annat sätt behandla eventuell digital data. 1En container (sv. beh̊allare) är en metafiltyp som beskriver hur olika slags data struktureras i en datafil. I det här fallet gäller det ljud- och videodata. Typiska exempel är .mp4 och .avi filer. 2 2 Teknisk Bakgrund I detta kapitel redovisas de olika subsystem som projektet best̊ar av. Dessa delas upp logiskt i h̊ardvara och mjukvara. 2.1 H̊ardvara Här presenteras än översikt över de större h̊ardvarumodulerna som systemet i projektet best̊ar av. Detta ska ge en först̊aelse över vad de är och varför de är lämpade för ändam̊alet. En fullständig systembeskrivning hittas i kap. 5.2.1. 2.1.1 Raspberry Pi En Raspberry Pi (RPi) är en enkortsdator1 som kör, bland annat, linuxbaserade operativsystem (OS) och därmed till̊ater stor frihet att programmeras till användarens behov. Det används brett av m̊anga olika individer samt organisationer, och är utmärkt när det kommer till sm̊a 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̊al webbserver. I praktiken s̊a kan RPi användas b̊ade som en ’vanlig’ dator med en grafisk miljö och periferikopplingar eller p̊a ett antal andra sätt. Ett sätt att använda en RPi är som ett strömsn̊alt inbyggt system som kan styra utrustning p̊a l̊ag niv̊a med inbyggda h̊ardvarumoduler där kommunikationsprotokoll som SPI och seriell finns inbyggt i processorn eller för att styra en stor uppsättning GPIO (eng. 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̊an tidigare versioner har inbyggt WiFi och Bluetooth samt en variant p̊a Cortex-A53 processorn, som implementerar ARMv8-A instruktionsuppsättningen, med högre nominell klockfrekvens[26]. 2.1.2 Mikrokontroller En mikrokontroller eller 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̊ardvara, som är per definition mindre flexibel. En stor skillnad mellan en MCU och en mer traditionell dator som RPi:en är att den inte kör n̊agot operativsystem eller kernel om inte man programmerar en p̊a egen hand. Koden man skriver kompileras till instruktioner p̊a maskinniv̊a och p̊a en MCU utan OS kommer instruktionerna att exekveras direkt utan eventuella avbrott fr̊an ett OS. Denna närhet mellan mjukvara och h̊ardvara gör framförallt att man minskar den processortid som används till overhead, med andra ord operationer som inte direkt används för den uppgiften man vill utföra. P̊a en MCU är det sällan man önskar arbeta p̊a flera uppgifter parallellt. Ett undantag är flerkärniga MCU processorer där komplexiteten ökar avsevärt. Man undviker därmed overhead p̊a grund av att processorn ska byta mellan olika program p̊a grund av pseudo-parallell exekvering vilket innebär minskad latens2 för IO 1En enkortsdator (eng. single-board-computer) skiljer sig fr̊an en vanlig dator i med att all h̊ardvara, även s̊adant som brukar finnas som insticksmoduler, som primärminne exempelvis, finns p̊a samma kretskort. Detta har naturligtvis fördelen att h̊ardvaran kan minimeras, vilket gör den mer portabel. 2Latens är den tidsfördröjning mellan en insignal och motsvarande utsignal och är skild fr̊an datatakt. Om man, till exempel, önskar en l̊ag svarstid för en tidskänslig uppgift s̊a skall man ha l̊ag latens, oberoende av övrig prestanda. 3 (eng. Input/Output) operationer. Allt detta gör MCU:er lämpade för system med 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̊aglatens ’realtids- gränssnitt’ och kan d̊a 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̊ade den och MCU:n har ledig processortid. Detta beskrivs mer utförligt i kap. 5.2.1. B̊ada projektmedlemmarna har tidigare erfarenhet av Arduino h̊ardvaran samt utvecklingsplattformen och därför valdes mikrokontrollern Microchip ATmega 328P[15]. För att göra den elektriskt kompatibel med RPi s̊a matas den med 3.3V systemspänning vilket även gör att klockfrekvensen m̊aste sänkas 8 MHz fr̊an nominella 16MHz vid 5V. För detta projekt är det värdefullt att notera att den har inbyggda h̊ardvarumoduler för SPI, seriell kommunikation och externa interrupts, d̊a det underlätta kommunicering med andra h̊ardvarumoduler. Ytterligare protokoller som inte har h̊ardvarustöd kan implementeras i mjukvara genom s̊a kallad ’bit-banging’, det vill säga att ett kommunikationsprotokoll kan implementeras helt i mjukvara genom direkt styrning av GPIO pinnar. 2.1.3 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̊art att göra eftersom de har en l̊ag amplitud och lätt kan störas ut av brus, vilket ställer höga krav p̊a ADC:n samt resten av den analoga datavägen. För att kunna göra systemet s̊a robust och brust̊aligt som möjligt samtidigt som man integrerar s̊a mycket av den analoga elektroniken som möjligt valdes en integrerad krets (IC) fr̊an Texas Instruments, ADS1299 [1], 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. 2.1.4 Batteri En viktig del i systemet är batteriet och dess kapacitet och kraftleveransförm̊aga. 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̊a 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̊a 6000mAh, och har en output p̊a 5V och 2A. Spänningsregleringen p̊a RPi kortet st̊ar för omvandling till 3.3V. 2.1.5 Kamera Kameran, som i systemet används för att spela in video, ansluts direkt till RPi:n via ett CSI (Camera Serial Interface)3 gränssnitt och är av typen Camera Module V2. Fördelen med detta gränssnitt är att man slipper vissa mellanliggande kommunikationsprotokoller innan datan fr̊an kameran n̊ar processorn, vilket ger en stor prestandavinst. 2.1.6 Mikrofon Alla versioner av RPi saknar analog mikrofonanslutning och därför krävs en ADC krets, ocks̊a kallad ljudkort i när det gäller en insticksmodul för ljudsignaler, för att omvandla mellan analoga signaler fr̊an 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̊a det varit oviktigt vilken typ eller modell som används. 3CSI är en specifikation av MIPI (Mobile Industry Processor Interface) Alliance. 4 2.1.7 PCB Printed circuit board eller PCB (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̊a b̊ada sidorna av ett kretskort och även inne i det isolerande materialet för att f̊a flerlagerskort. Syftet med att använda en PCB gentemot andra former av prototypkrets s̊asom ’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 electrical design automation (EDA) verktyg för PCB design s̊a kan man ocks̊a genom design rule checks (DRC) verifiera kretsen p̊a olika sätt innan den tillverkas. Figur 2.1: Tvärsnitt av ett 4-lagers PCB med väsentliga omr̊aden markerade. Photo: Rainer Knäpper, Free Art License (http: // artlibre. org/ licence/ lal/ en/ ), https: // commons. wikimedia. org/ wiki/ File: Bga_ und_ via_ IMGP4531_ wp. jpg I fig. 2.1 ser man en typisk flerlagers PCB. Den har ett topp- och bottenskikt och tv̊a inre lager som inte syns utifr̊an. Olika lager kan kopplas genom att använda en via, ett kopparplatterad borrh̊al 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̊a den inte kan kommas åt utifr̊an. Dessa brukar undvikas d̊a de kan försv̊ara felsökning och dessutom inte kan åtgärdas ifall ett tillverkningsfel skulle uppst̊a. 5 http://artlibre.org/licence/lal/en/ https://commons.wikimedia.org/wiki/File:Bga_und_via_IMGP4531_wp.jpg https://commons.wikimedia.org/wiki/File:Bga_und_via_IMGP4531_wp.jpg 2.2 Mjukvara Detta kapitel g̊ar igenom de olika program mjukvaruverktyg som använts i projektet. 2.2.1 Python Python är ett objektorienterat, interpreterad4 programmeringsspr̊ak som är lättlärt och högt modulärt i sin dynamiska funktionalitet. Det finns m̊anga bibliotek i diverse tillämpningar. P̊a 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̊ak. P̊a grund av de olika biblioteken som stöds, s̊a är Python oerhört adaptivt i dess användning, vilket var en av anledning till att det valdes som spr̊ak för projektet. Tanken var att oavsett sätt som valdes att implementera lösningar, s̊a skulle det vara relativt simpelt med ett spr̊ak som Python. [2] 2.2.2 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. [3] 2.2.3 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̊a sin respektive data och s̊a att resultaten av dessa sedan kunde jämföras med varandra. Sedan 1992 s̊a 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. [4] [20] 2.2.4 Linuxprogram Ett flertal program som installerats under RPi:ns linuxmiljö har använts, till exempel, raspivid och 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̊ardvaruaccelererad, vilket innebär att den kan jobba emot dedikerad avkodningsh̊ardvara 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̊adana komplexa beräkningar i realtid[23]. 2.2.5 Python EDF Library (PyEDFlib) PyEDFlib är ett pythonbaserat EDF bibliotek som inneh̊aller 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[5]. 4Ett interpreterat programspr̊ak behöver inte kompileras utan ’tolkas’ under själva körningen. 6 3 Metod Arbetet har utförts i en dedikerad labbsal p̊a Chalmers, vilket gjort det lätt för handledare att mötas upp och diskutera projektets fortsatta utveckling. I början av projektet s̊a lades stor tid p̊a att försöka planera, läsa p̊a och först̊a ämnet. Det lades även tid p̊a att lära sig programspr̊aket Python, n̊agot som ingen av projektets medlemmar var särskilt bekant med sedan tidigare. Till en mindre grad lades även tid p̊a att lära sig CAD-programmet KiCad, för att kunna skapa ett mönsterkortprototyp. Efter att ha f̊att en viss bekantskap med ämnet, startade arbetet en process av idéer och beslut gällande olika aspekter av den färdiga produkten. Beslut fattades om saker som vilken h̊ardvara och mjukvara som skulle användas, hur GUI:t skulle se ut och vilka funktionaliteter som programmet skulle ha och i vilken ordning de skulle implementeras. 3.1 Agila metoder Agila metoder är ett speciellt arbetssätt vilket främjar utveckling och förbättring i olika ändamål. Detta tillämpas d̊a det sker regelbundna möten med b̊ade medlemmar i arbetsgruppen, samt produktägare, för att f̊a en kontinuerlig ström av feedback och information som används för att den tidigare nämnda utvecklingen ska fortskrida p̊a ett bra sätt och inte stagnera. Dessa regelbundna mötet har skett med handledare, för att diskutera utvecklingen just d̊a, samt bestämma ett lämpligt nästa steg. I m̊anga fall s̊a har dessa tillfällen använts för att diskutera de aktuella problemen, d̊a det var främst de som stod i vägen för en fortskrida utveckling. 3.2 Git och GitHub Projektets versionshantering har skett med programmet git med GitHub som hostingplatform1. Att versions- hantera innebär att man har en metodik kring hur man h̊aller reda p̊a förändringar i ett system eller i kod. Detta utförs vanligen genom att man har en huvudstam med den aktuella koden, och utvecklingsgrenar. Dessa grenar skapas fr̊an stammen när man vill utveckla nya funktionaliteter, och när den specifika funktionen anses klar s̊a sammanfogar man den grenen med den fungerande koden. P̊a detta sätt s̊a har man en centralt fungerande kod, samtidigt som flera olika utvecklare kan sitta i separata utvecklingsgrenar, beroende p̊a m̊al eller funktion. Det kan ocks̊a användas som backup om n̊agot skulle g̊a snett vid en integrering av en gren, d̊a man lätt kan backa tillbaka till den versionen av koden som fungerade innan man försökte sammanfoga grenen med stammen, eller ännu längre bak i utvecklingen om man s̊a vill det. Där finns Master branchen, samt de olika utvecklingsfokuserade brancher som använts under utveckling. Med hjälp av Github s̊a kan man se hur utvecklingen g̊att framåt, vilka delar som utvecklats när och i vilken ordning. Det finns en fullständig versionshantering av projektet, vars versioner uppdaterats när n̊agot mindre mål uppn̊atts. Vid standardinställningar är kommentarer obligatoriska vid varje uppdatering av koden vilket uppmuntrar till tydlighet. 1GitHub är, enkelt sammanfattat, en central server som distribuerade användare jobbar emot genom Git. 7 3.3 Kunskapsinhämtning När det kommer till kunskap om EEG och hjärnan generellt s̊a finns det ett enormt utbud av information, men samtidigt inte s̊a m̊anga svar som man skulle vilja ha. Det finns fortfarande mycket som är okänt när det kommer till hjärnan, och att kunna veta hur den därmed fungerar kan vara en sv̊ar sak. Däremot s̊a finns det relativt väldokumenterat om de joniska strömmarna i hjärnan, vilket är vad EEG använder sig av. Det finns konstant aktivitet i hjärnan som genererar joniska strömmar, därmed s̊a kan det vara sv̊art att veta exakt vilka strömmar som speglade vad en individ s̊ag eller upplevde under n̊agon tidpunkt. För att först̊a de bioelektriska mekanismer i kroppen som ger upphov till elektriska signaler och hur man p̊a bästa sätt mäter dem, användes en del litteratur om bioelektriska signaler och dess klassificeringar, samt bioelektriska mätsystem med beskrivningar av verkliga implementationer. I synnerhet har boken Medical Intrumentation: application and design av J. G. Webster och J. W. Clark[31] varit till stor hjälp under arbetet för att först̊a ämnet. För att först̊a olika tekniska koncept som används i ADC kretsar, som Σ∆-modulering, har man använt tidigare kursböcker, speciellt Elektriska Mätsystem och Mätmetoder av Lars Bengtsson[16], samt s̊a kallade Application Notes, beskrivande texter ämnade åt ingenjörer som ofta inneh̊aller implementationsdetaljer utöver den abstrakta konceptbeskrivningen. Information har även samlats in fr̊an olika vetenskapliga och tekniska journaler när det gäller specifika fr̊agor eller koncept. Vid programmering av Raspberry Pi har man utnyttjat det officiella forumet[25] i många fall för att besvara praktiska fr̊agor och vid programmering av mer maskinorienterade enheter som mikrokontroller har man använt sig av relevanta datablad samt även där utnyttjat relevanta forum s̊asom Arduino forumet[14] och Texas Instruments ’data converter’ forum[28]. 8 4 Teoretisk Bakgrund Detta avsnitt beskriver den underliggande teorin för hur EEG fungerar och hur det utförs i praktiken. 4.1 Elektroencefalografi Elektroencefalografi (EEG) används för att detektera och mäta jonströmmar i hjärnans nervceller, särskilt s̊a kallade neurala oscillationer, genom att fästa elektroder vid skalpen, vanligtvis med en ledande elektrolytgel och eventuellt n̊agon slags huvudbonad som fysiskt h̊aller dem p̊a plats. V̊agformerna kan sedan användas för att göra bedömningar kring en individs hjärna och dess tillst̊and, s̊a som att fastställa niv̊a p̊a koma, epilepsi eller om en patient är hjärndöd. Mätning sker ofta med en sampelfrekvens p̊a mellan 200-500 Hz, men man kan mäta upp till flera kHz, beroende p̊a kapabilitet av systemet och önskad frekvensupplösning. 4.2 Biopotentialer När man talar om olika bioelektriska signaler i kroppen och mätningarna därav s̊a brukar man förknippa dem med olika organ: elektroencephalografi (EEG) syftar p̊a mätningar av biopotentialer i hjärnan medans elektrokardiografi (EKG) gäller mätningar i hjärtat. Övriga mätningar som ofta är av intresse är elektroneurografi (ENG) direkt i nerver, elektromyografi (EMG) i muskler och elektroretinogram (ERG) i näthinnan.[31] Bioelektriska potentialer, eller biopotentialer, skapas av en elektrokemisk process som förekommer hos en viss sorts celler, huvudsakligen hos nervceller. Dessa celler är i ett ’vilotillst̊and’ tills de blir tillräckligt stimulerade och genererar en ’aktionpotential’. En s̊adan cell har en elektrisk potential mellan den intracellulära och extracellulära miljön hos cellen. Detta kallas för membranpotentialen och är i vilotillst̊and ca -70mV. Figur 4.1: Spänningstransienter i en nervcell. Cellmembranet överg̊ar fr̊an ’vilotillst̊andet’ -70mV, till en aktionpotential när den tar emot stimuli som n̊ar ett visst tröskelvärde. Cellmembranet depolariseras, och depolariseringen propagerar längs nerven. Efter en kort tid återg̊ar membranpotentialen till vilotillst̊andet. 9 Fig. 4.1 visar att när en nervcell blir stimulerad med en potential som överskrider ett visst tröskelvärde s̊a orsakas en aktionpotential, en transient i membranpotentialen, även kallad depolarisering p̊a grund av att membranpotentialen byter riktning, som utbreder sig längs membranet. Enstaka nervceller är givetvis sv̊ara att mäta och ointressanta sett till hela organet. Det är när m̊anga nervcellers aktionpotentialer inträffar samtidigt som man kan f̊a mätbara resultat med EEG. P̊a hjärnans ytmembran kan man mäta upp till 10mV; utanför kraniet ligger dock magnituden oftast inom spannet 10-100 µV 4.3 Biopotentiala Elektroder Elektroder i biotekniska sammanhang används för att omvandla joniska strömmar orsakade av aktionpotentialer i vävnad till elektrisk ström, med elektroner som laddningsbärare, som används i elektroniken som ska mäta den. En elektrod är med andra ord en transducer, som omvandlar mellan tv̊a olika former av energi. Ström passerar gränssnittet mellan elektrolyt, huden och eventuellt elektrolytgel för att minska impedansen, och elektrod genom en kemisk reaktion. Atomer i elektroden oxiderar och skapar fria elektroner och positiva joner (cationer) som förflyttas till elektrolyten. Elektrolytens negativa joner (anioner) förflyttas samtidigt mot elektroden och förser den med elektroner. En viktig sidoeffekt av den kemiska reaktionen är att en spänning skapas över elektrolyt-elektrod gränssnittet, som kallas half-cell potential. Detta uppenbarar sig som en DC spänning i EEG resultaten. Av denna anledning används ofta elektroder av materialet silver/silver-klorid (Ag/AgCl) som har en l̊ag half-cell potential p̊a ca. 220mV.[21] Det är viktigt att minimera denna DC spänning d̊a den p̊averkar den användbara spänningsomf̊anget i ADC:n som mäter signalerna. 4.4 Kliniskt EEG För att skapa reproducerbara och jämförbara EEG resultat s̊a måste man ha ett enhetligt system för hur man placerar elektroder, i förh̊allande till huvudets orientering och i förh̊allande till andra elektroder. Den dominerande kliniska standarden för elektrodplacering är 10-20 systemet, som visas i fig. 4.2, som använder vissa anatomiska referenspunkter, nasion (vid näsan) och inion (vid nacken), för att placera ut elektroderna och kompensera för olika huvudstorlekar. Namnet syftar p̊a att mellanrummet mellan intilliggande elektroder är antingen 10% eller 20% av det totala avst̊andet fr̊an nasion till inion.[31, p. 175] Ju högre upplösning som önskas, desto kortare procentuellt avst̊and mellan elektroderna behöver man ha. Det har getts förslag p̊a att utöka standardupplösningen till 5% och 10%, i praktiken ett ’5-10 system’.[24] Cz T4C4C3T3 Pz Fz T6 O2 T5 F7 F8 O1 Fp1 Fp2 F4F3 P3 P4 A1 A2 INION NASION Figur 4.2: Illustration p̊a hur elektroder placeras p̊a huvudet vid användning av 10-20 systemet samt namnkon- ventionerna för individuella elektroder. Sedd ovanifr̊an. 10 När elektroder väl är utplacerade s̊a finns det frihet i hur man använder dem för att utföra mätningar, till exempel, om man vill mäta skillnaden mellan Fp1 och Fp2 eller mäta b̊ada tv̊a med avseende p̊a A1 (se fig. 4.2 för elektrodpositioner). Den valda definitionen kallas för en montage inom 10-20 systemet. I en bipolär montage s̊a mäts skillnaden mellan tv̊a intilliggande elektroder, i en referentiell montage s̊a mäts skillnaden mellan en elektrod och en referenselektrod, vanligtvis p̊a örsnibben. Det finns även mer avancerade montager som mäter med avseende p̊a den genomsnittliga spänningen av alla intilliggande elektroder. För att f̊a s̊a l̊ag impedans mellan huden och elektroden som möjligt s̊a bör man förbehandla huden för att f̊a bort torrt eller gammalt hud. Högre impedans ger en större DC spänning i mätningarna. Med bra hudkontakt s̊a brukar ligger impedansen p̊a ca. 5 kΩ men kan i vissa fall ligga s̊a högt som 500 kΩ. 11 5 Genomförande 5.1 Förberedelse Början av projektet bestod till stora delar av p̊aläsning om ämnet. Ämnet inkluderade delar s̊a 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̊angssätt när det kommer till mätning av hjärnaktivitet. Bland annat om vilken spänningsniv̊a det handlar om, p̊a vilka ställen p̊a ett huvud man ska göra mätningar, samt vilka sv̊arigheter som finns när det kommer till att mäta otroligt sm̊a spänningar p̊a ett s̊a känsligt organ som hjärnan. En relevant del av dessa sv̊arigheter gäller rörelse. Det är nämligen s̊a att det är sv̊art att uppfatta korrekt data fr̊an EEG om muskler rör p̊a sig, d̊a den spänning som används för att manipulera musklerna genererar större spänningsniv̊aer än vad hjärnaktivitet gör, vilket orsakar stora störningar. En annan faktor är att det handlar om just små spänningsniv̊aer, som fyller väldigt lite av det dynamiska omf̊anget (eng. 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. 5.1.1 Allmänt arbetssätt Arbete har främst skett genom samarbete p̊a 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. Relativt sent under projektets g̊ang var man tvungen att byta RPi p̊a grund av en kortslutning. All mjukvara och eventuella h̊ardvaruinställningar som fanns p̊a 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̊adad internetuppkoppling. Utvecklingsarbetet kunde med andra ord försätta obehindrat efter detta. Under projektets g̊ang s̊a 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̊a har det även funnits kontakt vid akuta problem. Ett s̊adant var exempelvis när den originella RPi:n kortslöts och en ny behövdes akut. Projektet best̊ar 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̊a Github. Man kunde ocks̊a återställa koden till en tidigare version ifall n̊agot fel skulle upptäckas vid ett senare tillfälle. 12 5.2 Systemdesign 5.2.1 Systembeskrivning I fig. 5.1 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̊an, genom ett tr̊adlöst gränssnitt s̊a som Bluetooth eller WiFi. Det är viktigt att skilja mellan olika spänningar i systemet d̊a viss kringutrustning, speciellt analog elektronik som ADCs, kan behöva spänningskällor som inte finns i resten av systemet. Styrenhet Kameramodul Lagring USB  ljudkort Mikrofon Elektroder/ förfiltrering Högtalare Fjärrdator för att styra systemet eg. via WiFi, Bluetooth 5V/2A från batteri/powerbank Unipolär 5V (direkt batterikoppling) eller bipolär +/-2.5V via spänningsomvandlare 4, 6 eller 8 parallella kanaler (beroende på modell) Mikrokontroller Atmega 328p SPI RS232 SSH via Ethernet/WiFi Styrenhet Raspberry Pi Kameramodul Lagring ADC TI ADS1299 USB  ljudkort Mikrofon Elektroder/ förfiltrering Högtalare Fjärrdator 5V/2A från batteri/powerbank Unipolär 5V (direkt batterikoppling) eller bipolär +/-2.5V via spänningsomvandlare 4, 6 eller 8 parallella kanaler (beroende på modell) Figur 5.1: Systembeskrivning. Pilarna beskriver dataflödet i systemet. Systemet är uppdelad med avseende p̊a systemspänning, d̊a en ADC kan kräva en bipolär spänningskälla för att även kunna mäta negativa spänningar. 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̊a skall video och ljud spelas in vid RPi:ns kameramodul och USB-ljudkort med ansluten mikrofon, respektive. Alla submoduler ska kunna styras fr̊an ett GUI gränssnitt p̊a RPi:n. Enligt 10-20 systemet (se fig. 4.2) s̊a ing̊ar 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̊agor är relativt lokaliserade s̊a behövs dock inte en full uppsättning elektroder för att erh̊alla 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 13 mer utförligt i kap. 8. 5.2.2 Datakommunikation inom systemet Mycket av designarbetet i projektet lades p̊a att försöka lösa hur data skulle överföras mellan olika delar av systemet. Det finns huvudsakligen tv̊a 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̊a bekostnad av h̊ardvaruresurser, men i detta projekt är datatakterna s̊apass l̊aga (54 kbaud, enligt nedan) att det alternativet valdes bort tidigt som onödigt. 5.2.2.1 SPI gränssnitt p̊a ADC ADS1299 ADS1299 använder sig av 4-wire SPI, med en klocksignal (SCLK), en chip-select signal (CS) och tv̊a envägs datasignaler (DIN och DOUT). ADS1299 är en slavenhet i SPI-sammanhang och kräver därmed att masteren- heten (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̊aste aktivt läsas genom att skicka en pulst̊ag p̊a 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 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̊aste läsas innan nästa inläsning, annars skrivs den över och kan ej återskapas. Eftersom detta inte f̊ar ske, ställer det h̊arda1 tidskrav p̊a systemet.[29, kap. 1.1] När ADS1299 annonserar sin data m̊aste allts̊a 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̊aste utföras inom 4ms fr̊an den tidpunkt att datan blev tillgänglig. Den seriella läsningen av varje sampel har ocks̊a en datatakt som bestäms av enheten som utför läsningen. Detta kan kallas för bithastigheten, eller baudrate p̊a engelska, som innebär hur m̊anga informationssymboler som kommuniceras per tidsenhet. ADS1299 har 8 inläsningskanaler med 24 bitars upplösning p̊a varje kanal. Datan fr̊an kanalerna skickas tillsammans med ett ’status’ meddelande, även den 24 bitar l̊ang. Tillsammans innebär det att varje sampel som skickas inneh̊aller 216 bitar (27 bytes), och om detta ska skickas 250 g̊anger i sekunden motsvarar detta en ’throughput’ 54 kbaud. Här bör det p̊aminnas om att SPI överföringen styrs enbart av master -enheten, i det här fallet MCU:n. MCU:n som användes, AtMega328p har en klockfrekvens p̊a 8 MHz vid 3.3V, och har därför en högsta möjliga SPI-klocka p̊a fosc/2 = 4 MHz, enligt databladet. D̊a tar överföringen av en sampel minst T osc · 27bytes = 108µs där de första 3 bytes är statusmeddelandet och resterande 24 bytes är data. Statusmeddelandet inneh̊aller information s̊asom tillst̊andet hos den inbyggda ”lead-off” detektorn2, och kan eventuellt förkastas om den inte används. Eftersom den skickas innan datan s̊a m̊aste den ovillkorligen läsas. MCU SPI h̊ardvaran m̊aste dock buffra och skicka en byte i taget, vilket ger en förh̊allandevis 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. 5.2, uppmätt en överföringstid p̊a ungefär 200µs. Detta motsvarar ungefär 1/20 av tidsbudgeten per sampel (Ts = 250−1Hz = 4ms) vilket ger god marginal för att sedan skicka datan vidare till RPi:n via seriellänken. 1I facklig litteratur ang. realtidssystem skiljer man mellan tidskrav som är h̊arda och mjuka. I system med h̊arda tidskrav s̊a har en viss data bara värde inom en viss tid, och blir värdelös om deadline överskrids. Med mjuka tidskrav s̊a tappar datan värde enligt n̊agon tidsfunktion. I detta fall, om deadline överskrids s̊a samplar man fel data, därav h̊arda tidskrav. 2Lead-off detection är en mekanism för att övervaka den elektriska impedansen hos en elektrod. Om impedansen är för hög s̊a försämras signalkvaliten och beror oftast p̊a den fysiska kopplingen mellan elektroden och huden. Impedansen kan av olika anledningar öka över tid vilket fordrar en periodisk läsning av tillst̊andet[18]. 14 Figur 5.2: V̊agformerna 2, 3 och 4 visar SPI signalerna SCLK, data och CS, respektive. V̊agform 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̊an. 5.2.3 ADC P̊a flera sätt den viktigaste komponenten i systemet är analog-till-digital omvandlaren ADC:n. Det är kompo- nenten som ska läsa in information fr̊an den yttre miljön, i detta fall elektroder p̊a 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̊ade för- och nackdelar. Utmaningen blir d̊a 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̊a ä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̊a bestämdes det att man skulle använda en lösning som innefattar l̊agpass filter, analog instru- mentförstärkare och en sigma-delta (Σ∆) ADC. Resonemanget är att LP-filtret s̊allar 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̊a som enklare kan mätas av en ADC. Ofta s̊a 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. 5.3 upp till 8 parallella inläsningskanaler, med varsin inställningsbar PGA, programmerbar förstärkare, (eng. programmable gain amplifier) och Σ∆-omvandlare. Varje kanal har 24-bitars upplösning. Varje sampel läser allts̊a in upp till 8 oberoende signaler med 24 bitars upplösning. ADC:n skickar dessutom ett extra dataord p̊a 24 bitar för varje sampel som inneh̊aller status p̊a olika subsystem som exempelvis ’lead-off detection’. Detta innebär en ’throughput’ (sv. genomströmning, allts̊a data som strömmas genom systemet per tidsenhet) p̊a 9 · 24b = 216b 15 per sampel, där B är byte3. Vid en nominell sampelhastighet p̊a 250Hz, s̊a innebär detta en throughput p̊a 54kbaud = 6.75kB Σ∆ använder oversampling, allts̊a att ADC:n samplar i en betydligt högre frekvens än Nyquistfrekvensen4. Fördelen med oversampling är att det gör att inherenta bruskällor, som kvantiseringsbrus, kraftigt minskas. Kvantiseringsbrus är den momentana skillnaden mellan den riktiga analoga signalen och dess digitala represen- tation i ADC:n. Om ∆ är skillnaden mellan tv̊a digitala ’niv̊aer’ s̊a är det maximala kvantiseringsfelet allts̊a ∆ 2 . Brus som uppst̊ar p̊a det här viset kan anses vara ’vitt’, allts̊a att det lägger sig uniformt p̊a över alla frekvenser inom frekvensbandet av intresse. Det som ∆Σ metoden ger möjlighet till är noise shaping, att skifta bruskomponenter fr̊an 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.[22, kap. 6] 3En byte rymmer som bekant 8 bitar. Det är dock viktigt att skilja p̊a bit och byte när man sedan använder prefixer. En kB eller kilobyte är allts̊a 8 kb eller kilobit. 4Nyquistfrekvensen är enligt Nyquist-Shannon teoremet den samplingsfrekvens som krävs för att kunna återskapa signalen, vilket gör att ingen signalinformation g̊ar förlorad. Nyquistfrekvensen är tv̊a g̊anger högre än den högsta frekvenskomponenten i signalen. fN > 2 · fsmax 16 DRDY CLK CLKSEL START MUX Oscillator Power-Supply Signal SPI DVDD DGNDBIAS INV BIAS OUT BIAS REF Lead-Off Excitation Source GPIO1 GPIO4 GPIO3 CS SCLK DIN DOUT GPIO2 IN8P IN8N IN7P IN7N IN6P IN6N IN5P IN5N IN4P IN4N IN3P IN3N IN2P IN2N IN1P IN1N Low-Noise PGA1 DS ADC1 Temperature Sensor Input BIAS Amplifier Reference VREFP VREFN Control PWDN RESET DS ADC2 DS ADC3 DS ADC4 DS ADC5 DS ADC6 DS ADC7 DS ADC8 AVDD AVDD1 AVSS AVSS1 Test Signal B IA S IN S R B 2 S R B 1 Low-Noise PGA8 Low-Noise PGA7 Low-Noise PGA6 Low-Noise PGA5 Low-Noise PGA4 Low-Noise PGA3 Low-Noise PGA2 A D S 1 2 9 9 -6 a n d A D S 1 2 9 9 O n ly A D S 1 2 9 9 O n ly 19 ADS1299, ADS1299-4, ADS1299-6 www.ti.com SBAS499C –JULY 2012–REVISED JANUARY 2017 Product Folder Links: ADS1299 ADS1299-4 ADS1299-6 Submit Documentation FeedbackCopyright © 2012–2017, Texas Instruments Incorporated 9.2 Functional Block Diagram Figur 5.3: Blockdiagram över I/O p̊a ADS1299. Fr̊an vänster till höger: differentiella inputkanaler, multiplexer med valbara bias- och testsignaler, programmerbara förstärkare, biaseringssignalmultiplexer, Σ∆-omvandlare och SPI gränssnitt. Hämtad fr̊an datablad[1]. 17 5.2.4 PCB Design I början av arbetet var förutsättningen att all h̊ardvara skulle byggas p̊a breadboards/prototypkort med diskreta, h̊almonterade komponenter. Detta visade sig dock inte vara möjligt d̊a 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̊a, bruskänsliga signaler s̊a vill man försöka minimera effekterna av induktiv och kapacitiv koppling s̊a 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̊a en PCB än p̊a andra sorters prototypkort. I detta projekt var man begränsad b̊ade av tid men ocks̊a kostnad. För att tillverkningskostnaden för en PCB ska h̊allas inom rimliga gränser s̊a m̊aste huvudparametrarna s̊a som storlek, antal lager och strömkapacitet i ledare inskränkas. Det beslutades därför innan designarbetet p̊abörjades att PCB:n skulle vara dubbelsidig, allts̊a ha tv̊a lager. Detta är vanligen det minsta antalet som behövs för att icke-triviala kretsar ska kunna kopplas utan att behöva jumpers, vilket är korta ledare som monteras p̊a i efterhand och som ’hoppar över’ andra ledare. Jumpers försv̊arar ofta designarbetet och kan möjligtvis sänka signalintegriteten. 5.2.4.1 EDA verktyg och Prototyp-PCB De första försöken till en PCB design gjordes med ett browser-baserat program vid namnet EasyEDA[6] som ägs av företaget Shenzhen JLC Electronics som även driver PCB-tillverningsföretaget JLCPCB [7] och elektro- nikkomponent̊aterförsäljaren LCSC [8]. Detta gör att EasyEDA har kunnat integrera ett komponentbibliotek över komponenter fr̊an LCSC, samt automatiskt skapa en bill of materials (BOM) och en direktbeställning genom JLCPCB. Det förstnämnda är speciellt intressant d̊a ett bibliotek över verifierade komponent ’foot- prints’, kopparmönster som stämmer överens med ledarna p̊a komponenten, kan avsevärt minska designtiden. Alternativet är att manuellt försöka hitta dessa ’footprints’ hos komponenttillverkaren eller rita/infoga dem direkt fr̊an komponentdatabladets paketbeskrivning. Tyvärr fanns det begränsningar i EasyEDA som gjorde det sv̊art eller omöjligt att växla mellan olika rutnät för olika komponenter, skapa ’keep-out’ omr̊aden, där alla form av ledare exkluderas, och skapa icke-typiska h̊alformer 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 [9]. För att åtgärda dessa problem byttes designarbetet till programmet KiCad[10]. 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̊an ritningar. Ytterligare funktionalitet kan erh̊allas 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̊aende komplexiteten som program som riktar sig åt experter har, som Altium Designer, b̊ade p̊a gott och ont. KiCad användes för att skapa en prototyp p̊a ett kretskort som skulle kunna monteras p̊a RPi:n p̊a samma sätt som en HAT och förbinda den med ADC:n, elektroder, MCU och eventuellt ytterligare periferienheter. Kretsschemat finns i bilaga 9.1. En 3D-rendering p̊a PCB:n finns i fig. 5.4. 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̊and eller jobba p̊a flera olika instanser samtidigt. För detta problem har Git varit en naturlig lösning, med commits som f̊angar projektets tillst̊and vid en viss tidpunkt och branches som till̊ater flera olika ’förgreningar’ av samma grundtillst̊and. 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. 18 Figur 5.4: 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̊al, h̊al för kameramodulens flatkabel, EEPROM och RPi GPIO anslutning finns, enligt RPi HAT standarden, längst upp till höger. 19 5.3 Mjukvarudesign Detta kapitel ämnar att beskriva programmet och dess komponenter och hur dessa fungerar och agerar. De huvudsakliga delarna av programmet är följande: • Initialisering av data och vissa inställningar samt tilldelning av vissa startvärden. • Inspelning av ljud och bild. • Inläsning av EEG-data. • Dataskrivning, fokuserat kring interaktion med PYEDFlib och med den senast skapade filen. • Videouppspelning via OMXplayer för att visa flödande bild och ljud Programmet är uppdelat i ett par olika delar beroende p̊a klass, men det mesta är fokuserat i GUI-klassen och dess funktioner. De olika knapparna i GUI:t aktiverar de primära funktionerna, s̊a som starta inspelning, skriva annotering och sätta upp patientdata, ocks̊a kallad headerdata, samtidigt som de primära funktionerna använder sig av flera av de mindre funktionerna, för att h̊alla systemet ig̊ang p̊a rätt sätt. 5.3.1 MobileEEG app MobileEEG app är huvudklassen för själva GUI:t samt alla dess relevanta funktioner s̊a som Record, Sync och Videoplay. Den är uppbyggd genom att tillämpa TkInter för att sätta upp det fönster man f̊ar upp när programmet startas, samt koden för de funktioner som knapparna i fönster aktiverar. Figur 5.5: Bild p̊a hur vad hur programmet ser ut när det startas. 5.3.2 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. 5.3.3 HeaderWindow HeaderWindow sätter upp fönstret för datahämtning fr̊an användaren gällande den information som man vill att EEG-inspelningen ska ha. 5.3.4 StoppableThread Klass som lägger in en Trace i en tr̊ad som h̊aller koll p̊a när tr̊aden skall stoppas/avslutas. 20 5.3.5 Record En av GUI:ts huvudfunktioner, den som inneh̊aller koden för att starta inspelning för ljud och bild, samt skapar subprocesser för dem, och även kallar p̊a 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. 5.3.6 Sync Sync använder sig av avconv, för att sammanföra ljud- och bildfilerna till en enda mp4-fil. Detta gör s̊a att ljud och bild spelas upp tillsammans, som en video. Avconv är en video- och audiokonverterare som finns tillgängligt i Linux. 5.3.7 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̊agot annat än EEG datan. 5.3.8 ReadEDF En simpel funktion som ser till att det finns headerdata, och som startar en tr̊ad av EDFFunction, för att kunna köras pseudoparallellt med ljud och bild subprocesserna. 5.3.9 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̊a skärmen. 5.3.10 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. 5.3.11 Popup Funktion som sätter upp en instans av ett annoteringsfönster, för att kunna skriva en annotering. 5.3.12 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. 21 5.3.13 Inspelning Inspelning av information, b̊ade ljud, bild och EEG data, är en central del av projektet. För detta s̊a har det utvecklats flera olika funktioner, som har hand om varsin del, och som körs parallellt med hjälp av tr̊adhantering. B̊ade ljud och bild var relativt lätta att implementera, d̊a det fanns färdig funktionalitet i operativsystemet Debian för RPi’s. D̊a detta är Linux-baserat s̊a finns det standard Linux-verktyg tillhands att implementera och nästla tillsammans med GUI-paketet TkInter. Till EEG-inspelningen s̊a var det en klart större och sv̊arare uppgift, d̊a detta handlar om att samla biofysisk data fr̊an elektroder. Detta behövs göras via en ADC för omvandling fr̊an analog till digital, samt en mikrokontroller för att kunna skicka denna datan p̊a ett p̊alitligt, snabbt och säkert sätt. Som tidigare nämnts, s̊a är detta den del som inte blev klar, däremot s̊a finns det b̊ade 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̊an grunden, s̊a som design av ett PCB-kretskort för just ADS1299, vilket inte var n̊agot som planerades fr̊an start, och gjorde, tillsammans med andra problem, att projektet inte blev klart i tid. 5.3.14 Start och Stopp Huvudfunktionen i GUI:t är att kunna starta samt stoppa en inspelning av s̊aväl ljud och bild som data. Implementationerna av de olika inspelningarna genererar processer samt tr̊adar, vilket gör att för att kunna avsluta dem krävs det att man hanterar processerna samt tr̊adarna p̊a rätt sätt. Det finns m̊anga sätt för systemet att stanna, när den bestämda tiden tagit slut, att man klickat p̊a stopp eller om programmet skulle krascha. Oavsett anledning s̊a behöver systemet hantera detta och avsluta programmet p̊a ett korrekt sätt för att inte n̊agon 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̊a kan införa hantering av b̊ade tr̊adar och processer och se till att de stängs av p̊a rätt sätt. 5.3.15 Synkronisering av ljud och bild För att maximera prestandan vid inspelning av olika slags data s̊a används olika program som är speciellt lämpade för ändam̊alet. För att spela in fr̊an kameran s̊a används programmet raspivid som är speciellt anpassat för h̊ardvaran i RPI:en och till̊ater viss h̊ardvaruaccelerering. För att spela in ljud används programmet arecord som finns att användas i samband med ALSA ljudkortsdrivrutinen. B̊ada programmen är relativt ’l̊agniv̊a’ och genererar data i ’raw’-format, ’wav’ för ljud och ’h264’ for bild, vilket skulle kunna användas direkt, men eftersom minneskapaciteten p̊a RPI:en är begränsat s̊a sammanflätas de olika dataströmmarna till en komprimerad ’mp4’-fil. Detta görs med programmet avconv. 5.3.16 Uppspelning Fr̊an 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̊a 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̊a en simpel videouppspelnig att fungera, och inte mer. En fördel är att alla filer kan n̊as 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̊a 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̊a gör är att den 22 letar upp den senast skapade videofilen, den som är resultatet av synkroniseringen av ljud och bild, och spelar den. 5.3.17 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̊agon specifik extern stimulus till synes p̊averkar datan, lägga in en kommentar om vad som orsakade det eller n̊agon annan relevant information. Detta implementerades genom att använda bakgrundstr̊adar, samt popuprutor fr̊an TkInter. Tanken var först att man skulle lägga in en kommentar samtidigt som man tryckte p̊a annoteringsknappen, men denna ide fr̊angicks av tv̊a anledningar: först s̊a var tanken att en popupruta potentiellt skulle distrahera fr̊an 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̊ater inte att annoteringar läggs in under inspelning. Istället gjordes beslutet om att man f̊ar trycka p̊a knappen, s̊a sparas en tidsstämpel för när annoteringen ville läggas in, och efter inspelning s̊a f̊ar man upp en popupruta för varje tryck man gjort, d̊a man senare kan skriva de kommentarer man velat. I efterhand s̊a skulle förmodligen en implementation där man f̊ar skriva kommentaren direkt vara bättre, d̊a 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̊a relevant eller skadligt om man blir distraherad under den korta period det tar att skriva en kommentar, d̊a EEG-data kollas bäst i efterhand d̊a man kan g̊a igenom datan noga med hög precision. Figur 5.6: Här visas den rutan som visas när man ska göra en annotering efter en inspelning. 23 5.3.18 Metadata EDF-formatet vill gärna ha en rad olika information, s̊a som namn p̊a patient, namn p̊a den som utför EEG-testet, patientkod, bakgrundsinformation, och m̊anga 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̊an PyEDFlib, dock s̊a är det ett krav fr̊an funktionerna att detta görs innan inspelning p̊abö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̊atgärd s̊a att knappar som startar processer som kan störa det som körs för tillfället deaktiveras. (a) Dialogruta med tomma fält. (b) Dialogruta med exempel p̊a giltig indata. Figur 5.7: Bilden till vänster visar hur det ser ut när man skriver in sin metadata. Den högra bilden visar ett exempel p̊a hur datan ser ut när den är ifylld. Dialogrutor för att fylla i headerdata i EDF+ filen. 24 6 Resultat Mycket arbete har utförts för att f̊a 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̊a egen hand, vilket det inte fanns tid till att göra vid denna tidpunkt d̊a det var i slutet av tiden för projektet när detta blev relevant. Projektet har tyvärr inte uppn̊att alla delm̊al som sattes vid projektets start, vilket kommer att diskuteras och förklaras i följande kapitel. 6.1 Summering av svar p̊a fr̊ageställningar 6.1.1 Vilket programmeringsspr̊ak bör användas? För detta projekt s̊a valdes programmeringsspr̊aket Python, d̊a det troddes kunna uppfylla de behov som fanns. Behov som fanns var bland annat realtidskrav, samt förm̊aga att implementera ett GUI för användarvänlighet. Spr̊ak 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̊angsamt’ spr̊ak, vilket innebär att det tar längre tid att exekvera jämfört med andra spr̊ak och därmed gjort det sv̊art att realisera en lösning med hjälp av Python. Ett annat spr̊ak bör ha valts, s̊a som C som är mer maskinnära och är ett spr̊ak anpassat till uppgifter med realtidskrav. Detta tas upp mer detaljerat i kap. 7 7, Diskussion. 6.1.2 Vilken samplingsfrekvens bör användas för EEG signalerna. Ofta när man tänker p̊a mätning av dynamiska signaler s̊a kan man ha den naiva föreställning att signalen skall mätas s̊a 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̊agformsklasser som är relevanta för EEG endast har en frekvensinneh̊all p̊a < 100 Hz, vilket innebär enligt Shannon-Nyquist samplingsteoremet att man endast måste läsa signalen med en frekvens p̊a 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. 6.1.3 Vad finns det för dataformat som är lämpade för EEG signaler? Vilket bör användas i denna tillämpning? Det finns m̊anga 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̊ak som C och Python för att enkelt applicera data till det formatet. EDF-formatet beskrivs i mer detalj i kap. 2, Teknisk Bakgrund. 6.1.4 Klarar systemet alla beräkningsbehov? Teoretiskt sätt s̊a uppfyller systemet alla beräkningsbehov, dock s̊a finns det problem i den praktiska implemen- tationen som gör det sv̊art. 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̊arda tidskraven p̊a 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. 25 6.2 Mål som uppn̊atts • Ett simpelt men funktionellt GUI. • Kan köras med hjälp av batteri. • Skriva data i EDF-formatet. • Bild- och ljudinspelning. • B̊ade design och prototyp av EEG inläsning. • Enkla säkerhets̊atgärder. 6.3 Mål som ej uppn̊atts • En komplett implementation av EEG-inläsningen. • En design och konstruktion av en huvudbonad samt h̊allare för all h̊ardvara. 6.4 Modell av lösning p̊a överförning Kretskortet för att sammanfoga RPi:n med ADC:n var tvunget att designas och produceras p̊a egen hand. Att läsa data fr̊an ADC:n till Rasperry Pi:n visade sig vara ett omfattande problem d̊a 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̊anga 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̊a att ADC:n lästes av 250 g̊anger i sekunden, eller var 4:e millisekund. Det förutsattes att RPi:n, med en systemklocka p̊a 1 GHz skulle klara detta krav, men när man väl försökte implementera kommunikationen s̊a 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̊a tiotals millisekunder. Linux är i sitt grundutförande allts̊a inget realtidssystem och lämpar sig inte för tidskänslig IO behandling. Lösningen p̊a 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. 5.2. Ett alternativ som hittills inte tagits upp är att modifiera själva Linuxkerneln för att stödja realtidsmekanismer och p̊a s̊a sätt f̊a en minskad interruptlatens. Det är just detta som kerneltillägget CONFIG PREEMPT RT[19] ämnar sig att göra och beskrivs närmare i kap. 7.5.8. 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. 26 6.5 Användning av Mobilt EEG Den produkt som utvecklats är den mjukvaran och implementation som finns p̊a projektets RPi. För att kunna använda programmet s̊a har ett användargränssnitt skapats. Detta användargränssnitt använder sig av funktionalitet fr̊an Pythonbiblioteket PyEDFlib för att kunna utföra specifika dataskrivningar, samt andra funktioner, till skapade EDF-filer. I den aktuella prototypen s̊a är datan simulerad med Pythonbiblioteket NumPy[11], men ska i framtiden kunna hämta in data fr̊an en mikrokontroller, och skriva den informationen p̊a EDF-formatet. Figur 6.1: Flödesdiagram över Mobilt EEG programmet. Fig. 6.1 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̊a m̊aste man ha fyllt i metadata via SetHeaderData innan man kan klicka p̊a Record eller Record EEG. 27 7 Diskussion Resultatet kommer att diskuteras och därefter de val som gjorts under projektets g̊ang. Kapitlet avslutas med etiska och miljöaspekter av projektet och n̊agra förslag p̊a möjliga lösningar p̊a de problem som tas upp här. 7.1 Diskussion av resultat Ett fungerande Mobilt EEG var huvudm̊alet med projektet, men den slutgiltiga produkten saknar den viktiga funktionen av att kunna läsa signaler fr̊an elektroder och överföra denna data till Raspberry Pi:n. Detta p̊a grund av de problem som uppst̊att under projektets g̊ang, samt en relativt overklig bild av hur mycket tid olika delar av projektet skulle ta. Under utvecklingen har vissa beslut tagits, främst för att f̊a arbetet att kunna fortskrida och inte stanna av. Utvecklingen av ett mobilt EEG anses ej vara klart. Däremot s̊a kan det anses vara p̊a 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̊a varför inte en komplett produkt är klar, s̊a finns det flera saker som behöver undersökas innan det finns ett passande svar. I början av åtagandet s̊a var visionen helt annorlunda än vad verkligheten tillät. Det fanns vissa delar av utvecklingen som antogs enkla eller inte s̊a tidskrävande, delar som missades helt och även en del problem som direkt resulterades fr̊an val som gjorts under utvecklingsprocessen. 7.2 Genomg̊ang av problem Projektet var öppet för val om hur man skulle utveckla produkten. Början av projekttiden spenderades p̊a att välja ett passande spr̊ak, lämplig h̊ardvara 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. • Det skulle finnas problem p̊a grund av den biologiska naturen av projektet, speciellt med avseende p̊a brus. • Det skulle behövas först̊aelse om hur neural aktivitet p̊averkar de biologiska processer som ger upphov till de joniska strömmar som ett EEG mäter. • P̊a grund av att man har inbyggd h̊ardvarustöd för I/O operationer s̊a p̊averkar inte operativsystem eller programspr̊ak tidsaspekter i I/O operationer nämnvärt. • Det borde finnas tid till att pröva flera olika ADC:er • Det borde skapas en funktionell databas för att lagra de olika resulterande filerna och h̊alla ordning p̊a tidsstämpling. • 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. • Kunna streama data till en extern display. Bara en av dessa visade sig stämma, att det skulle finnas problem p̊a grund av biologin hos en människa. 28 7.2.1 Antaganden 7.2.1.1 Biologiska problem Det skulle finnas problem p̊a grund av den biologiska naturen av projektet. Detta är korrekt, men det best̊ar främst av hur man sätter upp elektroder enligt 10/20 systemet, samt att rörelse av muskler orsakar starkt brus p̊a den niv̊a att de joniska strömmarna för EEG blir näst intill oläsbara. D̊a projektet inte lyckades att pröva det fysiskt s̊a 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. 7.2.1.2 Kunskap om hjärnan Det skulle behövas först̊aelse om hur neural aktivitet p̊averkar de biologiska processer ger upphov till de joniska strömmar som ett EEG samplar. Det var ett stort missförst̊and att det skulle behövas mycket p̊aläsning om hur det fungerar. P̊a grund av detta gick m̊anga dagar till spillo, d̊a tiden spenderades p̊a att läsa i böcker och p̊a internet efter information, istället för att arbeta p̊a projektet. 7.2.1.3 Programmeringsspr̊ak inte spelar n̊agon roll P̊a grund av att man har inbyggd h̊ardvarustöd för I/O operationer s̊a p̊averkar inte operativsystem eller programspr̊ak tidsaspekter i I/O operationer nämnvärt. När det undersöktes hur h̊ardvarukrävande projektet skulle vara, s̊a sa EEG litteraturen att signalerna kunde inneh̊alla frekvenser uppemot 100Hz, vilket innebär en sampeltakt p̊a ca. 200Hz för att inf̊anga hela signalen. D̊a en processor i en Raspberry Pi modell 2 g̊ar mot en processorhastighet mot nästan 1 GHz, och senare modeller är uppe i 1,4 GHz, och har inbyggt h̊ardvarustöd för externa interrupts samt en mängd kommunikationsprotokoller, s̊a antogs det att oavsett hur l̊angsamt ett spr̊ak än var s̊a skulle en snabb processor och h̊ardvarustöd tillsammans göra s̊a att det inte längre skulle vara ett problem. 7.2.1.4 Pröva olika ADC:er Det skulle finnas tid till att pröva flera olika ADC:er. Tanken var fr̊an 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̊a. ADC:n är en integrerad del i systemdesignen att det skulle bli ett omfattande arbete att anpassa systemet till flera olika ADC:er p̊a grund av skillnader i kommunikationsprotokoll och drivrutin, med andra ord, hur man programmerar ADC:n och tolkar datan man läser p̊a bit-niv̊a. Andra ADC:er skulle eventuellt även kräva anpassning av övrig h̊ardvara som spänningsregulatorer för att erh̊alla andra matningsspänningar. 7.2.1.5 Databas Det skulle skapas en funktionell databas. En databas var originellt en bra tanke, d̊a det skulle genereras en mängd data som skulle behöva sparas n̊agonstans. Problemet var att det skulle potentiellt bli komplicerat att lägga in och hämta data. Under utvecklingens g̊ang, när funktioner för att spela in testades, s̊a 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̊a skulle det räcka att de lagras direkt i mappen, med specifika namn beroende p̊a 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. 29 7.2.1.6 Externt beräkningsprogram 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̊ardvara endast för att köra beräkningsprogram för att inte överbelasta RPi:n, vilket skulle komplicera kommunikationsprocessen samt överföring, eller s̊a skulle det köras direkt p̊a RPi:n, men d̊a det inte längre ske n̊agon avlastning. Istället s̊a 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̊a interface för dataöverföring och därmed hanterar kommunikationen mellan ADC och RPi. RPi f̊ar 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. 7.2.1.7 Streama Data 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̊a 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̊ags överflödigt för s̊a simpel mjukvara. Det skulle även kräva implementationen av ett grafiskt ramverk för uppvisning av v̊agformen, ett betydande arbete i sig. Dock s̊a kan det p̊apekas att detta aldrig var ett krav eller m̊al fr̊an början, bara en intressant idé p̊a n̊agot som skulle kunna utvecklas. 7.2.2 Oförutsedda problem Det finns även en lista av problem som inte föruts̊ags. • Raspberry Pi ej s̊a lämpad för ändam̊alet. • Python ej lämpat för snabb responstid gentemot h̊ardvara-mjukvara. • Saknad av färdig lösning för vald ADC (PCB, kommunikationsstruktur etc). • Extra h̊ardvara utifall n̊agot kortslöts eller gick sönder. • P̊a grund av tidsbrist s̊a prioriterades huvudbonadens modellering bort. 7.2.2.1 Raspberry Pi ej lämpad Raspberry Pi ej s̊a lämpad för ändam̊alet. Problemet är att en RPi är för generell, och är inte specialbyggd för signalprocessering. Med detta s̊a 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̊a lämpad för just detta projektet. 7.2.2.2 Python ej lämpad Python ej lämpat för snabb responstid gentemot h̊ardvara-mjukvara Även om h̊ardvaran i Raspberry Pi är utrustad med h̊ardvarustöd för interrupts s̊a orsakar Linux kerneln en viss latens tills en interrupt kan behandlas 30 av program som kör i s̊a kallad userspace, program som körs av användare. Valet av programmeringsspr̊ak 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̊ak, en relativt hög s̊adan latens. Ett interpreterad spr̊ak innebär att källkoden inte kompileras utan evalueras vid körning. Istället för Python s̊a kunde ett mer maskinnära programmeringsspr̊ak ha valts, s̊a som C. Detta hade gjort det potentiellt sv̊arare 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̊ang tid. 7.2.2.3 Saknad av färdig ADC-lösning Saknad av färdig lösning för vald ADC (PCB, kommunikationsstruktur etc). Vid projektets början s̊a var det ett flertal ADC:er som passade projektet, men den som ans̊ags passa bäst var den som valdes, TI ADS1299. Trots teknisk lämplighet, var det ett omfattande arbete att försöka f̊a en fungerande prototypdesign d̊a den krävde mycket kringutrustning. Man var ocks̊a tvungen att skriva en drivrutin för att hantera dess ovanliga tidskrav. För att hantera komplexiteten i ADC-relaterad h̊ardvara, kom man fram till insikten att ett PCB skulle behövas d̊a komponenterna var för sm̊a och för m̊anga för att koppla ihop för hand inom rimlig tid. PCB design är en icke-trivial uppgift med en förh̊allandevis l̊ang inlärningsfas, vilket tog tid ifr̊an projektet. 7.2.2.4 Extra h̊ardvara Extra h̊ardvara utifall n̊agot 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̊a tid p̊a att vänta p̊a en ny beställning. 7.2.2.5 Huvudbonad P̊a grund av tidsbrist s̊a prioriterades huvudbonadens modellering bort. Planen var att en 3D-printer p̊a Chalmers skulle användas till att tillverka en huvudbonad för att h̊alla elektroder p̊a plats, som beskrivet i kap. 4.1, som skulle skapas tillsammans med utvecklingen av projektet. Med tanke p̊a tidsbristen som fanns, tillsammans med det faktum att ingen av projektets medlemmar tidigare skapat tekniska 3D-ritningar med CAD, fick detta l̊ag prioritet. 7.3 Miljö och Etik Syftet med ett EEG är att samla in och tolka hjärnv̊agor. En mobil implementation, som är lättillgänglig, lättanvänd och kan användas oberoende p̊a plats öppnar upp möjligheten till ett stort utbud av data. Eftersom EEG data kan inneh̊alla information om medicinska och mentala tillst̊and, s̊a m̊aste de betraktas som känsliga uppgifter. Enligt en studie[17], s̊a 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̊an intr̊ang, d̊a 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̊a kan lagras av privatpersoner som inte nödvändigtvis respekterar detta ansvar. Ett stort utbud p̊a 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̊allanden för inlärning. Detta skulle i sin tur kunna leda till 31 en potentiellt högre allmän utbildning världen över, d̊a mycket av exakt hur människan lär sig och tar in information fortfarande är relativt okänt. P̊a 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̊a, d̊a en miljö anpassad efter att hitta lugn hos en person med hjälp av EEG kan identifiera saker som p̊averkar en individ p̊a det sättet. 7.4 Övriga tankar I grund och botten s̊a är ett av de större problemen att projektet siktade p̊a 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. • Valde Raspberry Pi, skulle valt en enhet med l̊ag och förutsägbar interruptlatens, som en Arduino eller annan mikrokontroller. • Valde Python, skulle valt n̊agot mer maskinnära som C eller C++. Man kan därmed beskriva projektet som att det redan fr̊an början s̊ag mörkt ut. Å andra sidan s̊a finns det en produkt, med en prototyp p̊a 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̊alen blev uppfyllda. 7.5 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̊a ett annat sätt. 7.5.1 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̊asom 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. 7.5.2 Interrupt knapp som startar b̊ada h̊ardvaran samtidigt Man skulle kunna dela upp systemet i tv̊a oberoende delar, en som utför inspelning av ljud och bild och en annan som styr och lagrar data fr̊an ADC:n. Datan skulle d̊a extraheras och sammanfogas ’för hand’ efter en körning. En nackdel är att en interruptsignal kan mottas med olika fördröjningar p̊a olika system och under olika körningstillst̊and, vilket gör att datan fr̊an de olika delarna blir n̊agot osynkroniserat. Detta g̊ar troligtvis att mildra men inte eliminera. Man kan troligtvis försumma interruptfördröjningen p̊a en mikrokontroller under de flesta omständigheter. RPi:n har en typisk interruptfördröjningstid för program i userspace, till skillnad fr̊an kernelspace som användare inte kan p̊averka, som man skulle kunna utnyttja. Denna fördröjningstid har dock stor spridning, allts̊a att den med l̊ag sannolikhet avviker avsevärt fr̊an normalvärdet, vilket gör den mindre p̊alitlig [12]. 7.5.3 Extern lagring För att undvika att behöva kommunicera mellan mikrokontroller och RPi under tidsbegränsning s̊a kan mikrokontrollern istället skriva sensordata direkt till n̊agon form av extern lagring, som ett SD-kort. Detta har fördelen att man inte är beroende av n̊agot annat system och kan garantera att all data sparas. 32 7.5.4 Extern buffer En rimlig lösning p̊a 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[30], som implementerar en Linked-List som skriver över första minnesaddressen när den allokerade minnet tar slut. Den skriver allts̊a över den äldsta datan först och p̊a s̊a sätt kan aldrig