D ATA A C Q U I S I T I E I N H E T H I S PA R C E X P E R I M E N T. Eindverslag stage r.d. kleiss

Transcriptie

1 D ATA A C Q U I S I T I E I N H E T H I S PA R C E X P E R I M E N T Eindverslag stage 2012 r.d. kleiss

2 R.D. Kleiss: Data acquisitie in het HiSPARC experiment c 22 juni 2012 begeleiders: Drs. Ir. Ewout Boks Hogeschool van Arnhem en Nijmegen Embedded Systems Engineering ewout.boks@han.nl Prof. Dr. Ing. Bob van Eijk Nikhef HiSPARC vaneijk@nikhef.nl periode: Februari Juni 2012

3 V O O RW O O R D Mijn stage op het vond ik Nikhef erg leuk. Daarnaast was het erg leerzaam en interressant om mee te werken aan daadwerkelijk wetenschappelijk onderzoek. Voordat ik aan mijn stage begon had ik niet echt een idee wat er allemaal bij wetenschappelijk onderzoek komt kijken. Tijdens mijn stage heb ik geleerd dat dit niet alleen uit ontwikkeling bestaat. Er moet ook veel georganiseerd en geplanned worden met veel verschillende contactpersonen. Ik heb tijdens mijn stage veel met LabVIEW gewerkt, terwijl ik hier aan het begin van mijn stage niet veel ervaring mee had. Na hier een half jaar vrij intensief mee gewerkt te hebben kan ik zeggen dat ik LabVIEW helemaal niets vind voor de ontwikkeling van applicaties. Een veel gehoord argument voor het gebruik van LabVIEW is dat het voor beginners makkelijk te leren is. Dit vind ik maar ten dele waar. Wanneer een applicatie groot wordt is het lastig om alles goed bij te houden en LabVIEW werkt hier niet aan mee. Omdat voor elke VI die geopend wordt twee extra vensters erbij komen, raakt je beeldscherm erg snel vol en raak je meteen kwijt wat voor variabelen er in en uit de VI gaan. Daar komt nog bij dat documentatie van zelfgemaakte VI s niet makkelijk te maken/vinden is, in tegenstelling tot plain-text source code. Het argument dat LabVIEW makkelijk voor beginners is, vind ik dus alleen waar wanneer het gaat om kleine tools. Het is in dat geval inderdaad makkelijk om snel even een applicatie in elkaar te zetten om wat dingen te testen omdat LabVIEW een heleboel dingen (zoals een serieële verbinding openen) voor je kan afhandelen zodat je dit niet zelf hoeft te doen. De applicatie die in het HiSPARC project wordt gebruikt is té groot geworden voor LabVIEW, naar mijn mening. Helaas is er niet de tijd om deze te porten naar een andere programmeeromgeving. Ondanks het gebruik van LabVIEW vond ik mijn stage nog steeds er leuk en vond ik het ook fijn dat er naar mijn suggesties geluisterd werd (bijvoorbeeld het gebruik van git en GitHub 1 ). Een van de dingen waarvan ik heb gemerkt dat ik er erg moeite mee had (en nog steeds heb) is plannen. Ik kan niet zo goed inschatten hoe lang het duurt om een bepaalde functie te implementeren in, bijvoorbeeld, LabVIEW. Ik denk wel dat dit voor een groot deel komt omdat ik er nog niet zo veel ervaring mee had. Dit is wel iets waar ik op moet letten. 1 iii

4

5 I N H O U D S O P G AV E 1 het hisparc experiment Kosmische stralen Detectie Detectie stations Data acquisitie automatische fpga configuratie Ontwerp IPO-schema s Implementatie Testen en resultaten controle gps instellingen Realisatie pysparc 23 5 kleinere opdrachten Crash wanneer er in DAQ modus werd gegaan Fout in database communicatie conclusie 27 1

6

7 H E T H I S PA R C E X P E R I M E N T 1 HiSPARC is een project waarin middelbare scholen met wetenschappelijke instellingen samenwerken om kosmische stralen met extreem hoge energie te detecteren en meten. Op de daken van deelnemende scholen staan meetopstellingen die via het internet verboden zijn met een centrale database op het Nikhef te Amsterdam. Zo vormen zij een groot, landelijk netwerk van meetopstellingen. In Nijmegen worden al sinds 2002 gegevens verzameld (het NAHSA project) en in Amsterdam sinds Ook in de regio s Eindhoven, Leiden, Enschede en Groningen staan HiSPARC detectoren. 1.1 kosmische stralen De aarde wordt continu gebombardeerd door deeltjes vanuit de ruimte. Het grootste deel van deze deeltjes is afkomstig van de zon en heeft een relatief lage energie. Een klein deel van de deeltjes die de aarde bombarderen heeft echter een hogere energie en is afkomstig van dieper uit de ruimte. Deze deeltjes worden primary cosmic rays genoemd en bestaan voornamelijk uit protonen (84%) en alpha deeltjes (12%)[2, p. 3]. Wanneer deze deeltjes botsen met de atmosfeer ontstaan er nieuwe deeltjes die in dezelfde richting bewegen als het primaire deeltje (figuur 1.1). Deze nieuwe deeltjes botsen op hun beurt met atoomkernen in de atmosfeer waarbij er weer nieuwe deeltjes ontstaan. Dit proces gaat door totdat er voornamelijk muonen (µ + en µ ) over zijn die het aardoppervlak bereiken. Het grootste deel van de energie van het primaire deeltje (in figuur 1.1 een proton) wordt geabsorbeerd door de atmosfeer. Een klein deel bereikt echter het aardoppervlak (in de figuur in de vorm van muonen en elektronen). Naar deze deeltjes is men in het HiSPARC experiment op zoek, omdat ze ons veel kunnen vertellen over de oorsprong van het primaire deeltje. 1.2 detectie Figuur 1.2 toont een globaal overzicht van een HiSPARC detectie station. Het blauw omlijnde deel is het deel van de meetopstelling wat op het dak van een deelnemende school wordt geplaatst. Dit is een ski-box met daarin een scintillator plaat en photomultiplier tube. Deze zijn met coax-kabels verbonden met een HiSPARC unit (rood omlijnt). 3

8 4 het hisparc experiment p γ π 0 π π + e + e ν µ ν ν µ + µ Figuur 1.1: Een schematische weergave van een cosmic ray airshower. In deze figuur is het primaire deeltje een proton (p). Wanneer deze op de atmosfeer botst ontstaan hierbij nieuwe deeltjes. Uiteindelijk zijn het vooral elektronen en muonen die het aardoppervlak bereiken. De HiSPARC units zijn via USB verbonden met een computer waar de data acquisitie software op draait (groen omlijnt). Deze data acquisitie software leest de data uit de HiSPARC units en verstuurt het naar een centrale database op het Nikhef Detectie stations De HiSPARC detectie stations is een meetopstelling met daarin a) een scintillator plaat; b) een photomultiplier tube; en een c) HiSPARC unit. In figuur 1.2 zijn deze onderdelen blauw en rood omlijnt. Photomultiplier tube en scintillator plaat De photomultiplier tube en scintillator plaat (figuur 1.3) zijn twee van de belangrijkste onderdelen van een detectie station. De scintillator plaat is een plaat van een speciaal soort plastic. Wanneer een energetisch deeltje door dit plastic gaat, verliest het een deel van zijn energie en gaat het materiaal van de scintillator plaat fluorceren. De fotonen die hierbij ontstaan worden door aluminium folie wat om de plaat gewikkeld zit de plaat terug in gereflecteerd. Hierdoor worden de fotonen in de plaat verstrooid totdat ze op de photomultiplier tube (fotoversterkerbuis) vallen.

9 1.2 detectie 5 Scintillator Photomultiplier tube ADCs GPS FPGA USB Controle paneel Lokale database HSMonitor Nagios Centrale database Figuur 1.2: Een schematisch overzicht van de opbouw van een HiSPARC detectie station met daarin de hardware (o.a. de scintillator plaat, photomultiplier tube en HiSPARC unit) en de data acquisitie software.

10 6 het hisparc experiment Scintillator Photomultiplier tube Figuur 1.3: De inhoud van de ski-box van een detector in het HiSPARC project. De photomultiplier tube (of PMT) zet de energie van de fotonen met behulp van een foto-elektrisch effect om in een elektrische stroom. Omdat de stroom van één of een aantal fotonen op zich moeilijk te meten is, wordt de stroom van de fotonen ook versterkt (met behulp van secundaire emissie). Het versterkte signaal wat hierbij ontstaat wordt via coax-kabels naar de HiSPARC units verzonden. De combinatie van de scintillator plaat waar de photomultiplier tube aan gekoppeld is wordt in zwart plastic folie gewikkeld om er voor te zorgen dat er zo min mogelijk fotonen van buitenaf op de photomultilpier tube valt. Het geheel wordt in een ski-box ingebouwd en op het dak van een deelnemende school geplaatst. HiSPARC units Een HiSPARC unit (figuur 1.4) bestaat uit a) vier analoog-digitaal converters; b) een GPS ontvanger; c) een FPGA; en een d) USB chip. analoog-digitaal converters In een HiSPARC unit zitten vier AD converters, per kanaal twee (een HiSPARC unit kan het signaal van twee photomultiplier tubes ontvangen). Deze ADCs ontvangen een kloksignaal van een externe 200 MHz klok waarbij respectievelijk ADC 1 en ADC 2 op de op- en neergaande flank het PMT signaal uitlezen. Dit betekend dat er effectief een sample frequentie van 400 MHz (of een sample tijd van 2.5 ns) wordt bereikt. ADCs GPS FPGA USB Figuur 1.4: Schematisch overzicht van de inhoud van een HiSPARC unit.

11 1.2 detectie 7 ADC 1 ADC 1 ADC 1 ADC 1 Crystal ADC 2 ADC 2 ADC 2 ADC 2 Figuur 1.5: Timing diagram van de triggering van de ADCs in een HiSPARC unit. Omdat er gebruik wordt gemaakt van twee ADCs om een signaal uit te lezen, is het van belang dat de ADCs correct zijn uitgelijnd. Wanneer de ADCs niet dezelfde grondlijn hebben, wordt er een vertekend signaal uitgelezen wat lijkt op een driehoeksgolf. Het uitlijnen van de ADCs wordt door de software geregeld wanneer het station geïnstalleerd. Er worden intern verschillende referentie spanningen op de input van de ADC gezet, waarna wordt gecontroleerd of deze na uitlezen overeenkomen met de verwachte waarde. Na het uitlijnen hebben de ADCs een bereik tussen de 113 mv en 2222 mv. Omdat de ADCs een 12bit output hebben betekend dat dat ze na het uitlijnen een resolutie van 0.57 mv per bit hebben. Het omrekenen van de output naar een spanning kan met de formule U =.57x + 133[2] waarbij x het aantal ADC counts is. fpga Het hart van een HiSPARC unit is een Altera Quartus FPGA. Deze FPGA leest de outputs van de ADCs uit en combineert het waarna de data opgeslagen wordt in een circulaire buffer. Tegelijkertijd wordt er een eerste analyze over de data gedaan om te controleren of er een coïncidentie tussen twee detectoren is opgetreden. Het tijdsbestek van een event is maximaal 10 µs, wat overeen komt met 4000 samples. De AD converters hebben een output van 12 bit (of 1.5 B) per sample en een HiSPARC unit heeft een maximum van 2 kanalen heeft, waardoor de maximale grote van een event 12 kb is Als er een event optreedt, wordt de data opgeslagen in een tijdelijke buffer van 36 kb waarna ze via USB verstuurd worden naar de computer. Als er niet genoeg ruimte in de buffer is om een event op te slaan, wordt het event genegeerd en gaan de gegevens verloren. De standaard waarde voor het pre-trigger window is 1 µs, het coincidence window is 1.5 µs en het post-trigger window is 6.5 µs wat in totaal overeenkomt met 11 µs. Met deze instelling kan de interne buffer 5 events opslaan. Het is mogelijk om een slave HiSPARC unit aan te sluiten op een master HiSPARC unit. Een slave unit is een HiSPARC unit waar de GPS functionaliteit uit verwijderd is. Door een slave unit aan te sluiten is het mogelijk om het signaal van vier scintillator platen te ontvangen. gps Wanneer er een event verstuurd wordt naar de computer wordt hier een timestamp aan gekoppeld die via GPS ontvangen is. Norma-

12 8 het hisparc experiment Controle paneel Lokale database HSMonitor Nagios Figuur 1.6: Schematisch overzicht van de modules die gebruikt worden voor data acquisitie. liter wordt GPS gebruikt om locatie gegevens mee te ontvangen, maar het is ook en manier om overal tijdsgegevens te ontvangen met een nauwkeurigheid van 5 ns Data acquisitie De software van het HiSPARC experiment bestaat uit een aantal verschillende modules (figuur 1.6): Het controle en aanstuur programma; Een lokale database; Het HSMonitor proces die de data die is opgeslagen in de lokale database uitleest en verstuurd naar het Nikhef; en een Nagios proces welke gebruikt wordt om informatie over de computer door te geven aan het Nikhef om op deze manier op een afstand diagnostiek van de computer in te kunnen zien. Controle en aansturing Binnen het HiSPARC project wordt een LabVIEW programma gebruikt om de data vanuit de FPGA te lezen en op te slaan. Dit programma draait op een PC die op locatie bij elke meetopstelling aanwezig is. De uitwisseling van de data gebeurd via een USB verbinding tussen de PC en de HiSPARC unit(s). Het programma zorgt voor een tijdelijke data opslag en eerste analyse van de data. Via een ander proces

13 1.2 detectie 9 Data Read bytes Configuratie Initializatie Process data Store data Figuur 1.7: De programmaflow van het controle en aansturings programma wat ontwikkeld is in LabVIEW. (HSMonitor) wordt de data vervolgens verstuurd naar een centrale database bij het Nikhef. Daarnaast biedt het programma een user interface voor het analyseren en configureren van een aantal aspecten van de hardware in de HiSPARC unit. Ook kan er met deze interface real-time gekeken worden naar de kwaliteit van de binnenkomende data en kan er gecontroleerd worden of er zich een fout heeft voorgedaan in de unit. De loop van het programma is parallel en wordt gedreven door de verzamelde data (zie figuur 1.7). Het programma heeft een aantal standaard configuratie waarden die gebruikt worden wanneer er geen expliciete waarden door de gebruiker opgegeven worden. Met deze startwaarden wordt het HiSPARC II proces gestart. Wanneer het programma start begint de hardware initialisatie waarbij via USB contact gezocht wordt met de HiSPARC elektronica. Wanneer de hardware initialisatie succesvol is wordt de hoofdlus van het programma gestart. In deze lus zal het programma blijven totdat de gebruiker aangeeft dat er gestopt moet worden of totdat er een fout in het programma optreed die niet goed afgehandeld kan worden. In dat geval wordt er geprobeerd opnieuw te starten met het uitvoeren van het programma vanaf de eerste configuratie. Wanneer het programma in de hoofdlus is zijn er drie taken waar het programma zich mee bezig houdt, die alle drie in verschillende threads worden uitgevoerd: 1. Het inlezen van de data (de Read bytes thread) die via USB verzonden is door de HiSPARC unit; 2. Het verwerken van de ingelezen data (de Process data thread) op zo n manier dat het geïnterpreteerd wordt als berichten vanuit dehisparc unit; 3. En het opslaan van de data in een lokale database (de Store data thread).

14 10 het hisparc experiment Centrale database Figuur 1.8: De data die opgeslagen is in de lokale database wordt door het HSMonitor programma verstuurd naar de centrale database op het Nikhef. Om deze verschillende threads dezelfde data te laten behandelen wordt er gebruik gemaakt van een aantal queues. Deze worden in de ene thread gevuld en in de andere thread uitgelezen. Omdat er multi-threading wordt gebruikt wordt er ook gebruikt gemaakt van semaforen. Zo wordt er voorkomen dat, bijvoorbeeld, de Read bytes thread bezig is met een queue vullen terwijl de Process data thread op hetzelfde moment de queue aan het uitlezen is. Wanneer dit gebeurd, is er een kans dat de data corrupt wordt en zinloos is. Opslag Het HSMonitor proces verzorgt de daadwerkelijke verzending van de data die ontvangen wordt vanuit de HiSPARC unit(s). De data wordt uitgelezen door het LabVIEW programma waarna het wordt opgeslagen in de lokale MySQL database. Het HSMonitor proces controleert periodiek of er nieuwe data in de database staat. Als dit het geval is wordt de data uitgelezen en worden een aantal aspecten van de data gecontroleerd. Als de data hier aan voldoet wordt de data over een beveiligde VPN verbinding via een HTTP POST-request naar het Nikhef verstuurd (figuur 1.8). Controle Het Nagios proces geeft periodiek informatie over de computer door aan het Nikhef zodat de computer op afstand gecontroleerd kan worden. De informatie behelst onder andere of alle nodige processen draaien, wat de temperatuur van de CPU is en hoeveel ruimte er nog vrij is op de harde schijf. Wanneer een van de ontvangen aspecten niet aan bepaalde voorwaarden voldoet (het HSMonitor proces draait bijvoorbeeld niet) wordt er een verzonden aan de persoon die verantwoordelijk is voor de specifieke computer. Daarnaast wordt ook de projectleiding hiervan op de hoogte gesteld. Op deze manier is het mogelijk om het netwerk draaiend te houden zonder dat er constant iemand hoeft op te letten.

15 A U T O M AT I S C H E F P G A C O N F I G U R AT I E 2 In de tweede versie van de HiSPARC units is een EEPROM chip aanwezig waar de FPGA zijn firmware uit download wanneer deze opgestart wordt. Bij de derde versie van de units is deze chip niet meer aanwezig en moet de FPGA zijn programma via de USB verbinding aangeleverd krijgen wanneer deze opgestart wordt. Er bestaat een applicatie (figuur 2.1) die geschreven is voor het programmeren van de HiSPARC units maar het is niet gebruiksvriendelijk om iedere keer wanneer de HiSPARC unit start handmatig de firmware met behulp van deze applicatie te moeten uploaden. Om het proces voor de gebruiker te vereenvoudigen (en daarmee de kans op fouten te verkleinen) was het nodig om de functionaliteit van deze applicatie direct in LabVIEW te implementeren zodat vanuit daar de firmware automatisch naar de FPGA geupload kan worden wanneer dit nodig is. 2.1 ontwerp De HiSPARC III units hebben een FT2232H USB chip van FTDI Chip. Dit is een speciale USB chip die twee kanalen heeft (kanaal A en B) waarbij kanaal A als MPSSE-interface 1 kan dienen. Het is met de SPI-interface mogelijk om de HiSPARC III FPGA te programmeren ([1]). Om dit te doen moeten er echter wel een aantal stappen ondernomen worden, die het beste in een pseudocode kunnen worden uitgedrukt (algoritme 1). De beschreven pseudocode kan worden opgedeeld in een aantal blokken met ieder zijn eigen functionaliteit: Het opvragen van het aantal verbonden USB apparaten (regel 1); Opvragen van details van een USB apparaat (regel 3); Openen van een handle naar een HiSPARC unit (regel 5); Initializeren van een HiSPARC unit (regel 6); Controleren of de FPGA klaar staat op firmware te ontvangen (regel 7); Uploaden van firmware naar de FPGA (regel 8); Controleren of de FPGA de firmware heeft ontvangen (regel 9); 1 MPSSE: Multi-Protocol Synchronous Serial Engine ([3]) 11

16 12 automatische fpga configuratie Figuur 2.1: Huidige gebruikersinterface voor het programmeren van een FPGA in de HiSPARC units. Elke keer wanneer er opgestart wordt moet de gebruiker vanuit dit programma de firmware naar de FPGA uploaden. Algorithm 1 Algoritme voor het programmeren van HiSPARC III units. 1: get number of connected USB devices 2: for all connected devices do 3: get device details 4: if HiSPARC III device then 5: open devices 6: initialize device 7: if device is ready to receive firmware then 8: write firmware 9: if device did not received firmware then 10: print error 11: end if 12: else 13: print error 14: end if 15: close device 16: end if 17: end for

17 2.1 ontwerp 13 Sluiten van een handle naar de HiSPARC unit (regel 15); En het tonen van foutmeldingen aan de gebruiker (regel 10 en 13) IPO-schema s De eerder benoemde functionele blokken zijn in feite de namen van de verschillende processen die uitgevoerd moeten worden om de FPGA te configureren. Hiermee kunnen dan ook de benodigde IPOschema s ontworpen worden. Opvragen van het aantal verbonden USB apparaten Get device count count Figuur 2.2: Het get device count proces Het opvragen van het aantal verbonden USB apparaten gebeurd middels het get device count proces (figuur 2.2). Dit proces heeft geen inputs en maar één output (count). De count output geeft het aantal verbonden USB apparaten terug waarbij geldt dat count 0. Details van een USB apparaat index Get device details name channel location Figuur 2.3: Het get device details proces De details van een verbonden USB apparaat (bijvoorbeeld de naam) worden opgevraagd met het get device details proces (figuur 2.3). Dit proces heeft één input, index. Met index kan worden aangegeven van wélk apparaat de details moeten worden opgevraagd. Deze input moet voldoen aan de voorwaarde index < count waarbij count de waarde is die is opgevraagd met het get device count proces. Als outputs heeft het proces name, channel en location. De output name geeft de naam van het apparaat terug, bijvoorbeeld HiSPARC III Master in het geval van een HiSPARC III Master unit.

18 14 automatische fpga configuratie De output channel geeft het kanaal aan. Dit kan A of B zijn. De output location geeft de locatie van het apparaat op de USB stack van Windows aan. Dit is van belang omdat een aantal apparaten dezelfde naam en kanaal kunnen hebben terwijl het toch verschillende apparaten zijn. Openen van een handle naar een HiSPARC unit name channel location Open device handle Figuur 2.4: Het open device proces Een handle naar een USB apparaat kan geopend worden met het open device proces (figuur 2.4). Dit proces heeft als inputs name, channel en location; welke dezelfde functionaliteit hebben als beschreven bij het get device details proces. Als output heeft het proces handle wat de handle naar het apparaat terug geeft. Wanneer voldaan wordt aan de voorwaarde handle = 0 betekend dit dat er een fout is opgetreden tijdens het openen. Wanneer handle > 0 is de handle succesvol geopend. Initializeren van een HiSPARC unit handle Initialize device Figuur 2.5: Het initialize device proces Het intializeren van een HiSPARC III unit gebeurd met het initialize device proces (figuur 2.5). Met initializeren wordt bedoeld dat de FPGA het signaal krijgt dat er nieuwe firmware verzonden gaat worden. Het proces heeft alleen een input, handle. Dit is de eerder geopende handle naar de HiSPARC III unit. Er zijn verder geen outputs.

19 2.1 ontwerp 15 Controleren of de FPGA klaar staat op firmware te ontvangen handle Device ready? ready Figuur 2.6: Het device ready? proces Met het device ready? proces (figuur 2.8) kan gecontroleerd worden of een HiSPARC III unit klaar staat om firmware te ontvangen. Het proces heeft de input handle en output ready. handle verwacht een eerder geopende handle naar een HiSPARC III unit. ready geeft aan of het apparaat klaar staat om firmware te ontvangen. Uploaden van firmware naar de FPGA handle firmware Write firmware bytes written Figuur 2.7: Het write firmware proces Het uploaden van firmware naar de FPGA gebeurd met het write firmware proces (figuur 2.7). Als inputs heeft dit proces firmware en handle. De input firmware verwacht de data die naar de FPGA geschreven moet worden. De input handle verwacht een eerder geopende handle naar de HiSPARC III unit. Als output heeft dit proces bytes written, die aangeeft hoeveel bytes er daadwerkelijk naar de FPGA geschreven zijn. Controleren of de FPGA de firmware heeft ontvangen handle Device ready? ready Figuur 2.8: Het device ready proces Met het device ready proces (figuur 2.8) kan gecontroleerd worden of een FPGA de firmware correct heeft ontvangen. De input handle ver-

20 16 automatische fpga configuratie wacht een eerder geopende handle naar een FPGA. De output ready geeft aan of de FPGA de firmware correct heeft ontvangen. Sluiten van een handle naar de HiSPARC unit handle Close device Figuur 2.9: Het device close proces Een geopende handle naar een HiSPARC III unit kan gesloten worden met het close device proces (figuur 2.9). De input handle van dit proces verwacht de handle die gesloten moet worden. Het proces heeft verder geen outputs. Het tonen van foutmeldingen aan de gebruiker error Print error Figuur 2.10: Het print error proces Een foutmelding kan aan de gebruiker getoond worden middels het print error proces (figuur 2.10). De input error verwacht de foutmelding die aan de gebruiker getoond moet worden. Het proces heeft geen outputs. 2.2 implementatie De eerder gedefineërde processen zijn, vanwege de opzet van Lab- VIEW 1-op-1 om te zetten naar de interface van een VI. Een voorbeeld hiervan is het initialize device proces (figuur 2.11). Deze VI verstuurd een signaal naar de FPGA wat aangeeft dat er nieuwe firmware verstuurd gaat worden. Om aan te geven dat er nieuwe firmware naar de FPGA geupload gaat worden, moet de nconfig lijn getoggled worden[1, p. 9-34]. Wanneer de FPGA dit commando begrepen heeft, wordt de CONF DONE lijn omlaag gebracht. Zodra de CONF DONE lijn naar 0 is kan de firmware geschreven worden. De firmware moet in blokken van 64 kb geschreven worden, omdat dit het maximum is wat via de FT2232H chip verzonden kan

21 2.3 testen en resultaten 17 Figuur 2.11: De implementatie van het device initialize proces nconfig STATUS CONF DONE Figuur 2.12: Initialisatie van de FPGA zodat er nieuwe firmware geupload kan worden. worden. Wanneer de FPGA de firmware in zijn geheel heeft ontvangen en geprogrammeerd is gaat de CONF DONE lijn weer terug naar 1 en gaat de FPGA in user mode. User mode betekend niets meer dan dat hij zijn ingeprogrammeerde functionaliteit uitvoert. 2.3 testen en resultaten De ontwikkelde LabVIEW VI s zijn geïmplementeerd in het bestaande LabVIEW programma waardoor de FPGA tijdens het opstarten van het programma geflashed wordt met de benodigde firmware. Een obstaken waar tegenaan gelopen werd was het gebruik van 64-bits processoren. Om de een of andere rede werkt het schrijven naar de FPGA niet goed op dit type processoren. De oorzaak hiervan is vooralsnog onbekend. Op 32-bits systemen werkt het echter naar behoren. Een nadeel is wel dat er niet gecontroleerd kan worden of de firmware al in de FPGA staat, waardoor de firmware altijd naar de FPGA geflashed wordt tijdens het opstarten, ook al is dit niet nodig. Dit is echter geen groot probleem, aangezien het niet veel tijd kost om de firmware te flashen (enkele seconden).

22

23 C O N T R O L E G P S I N S T E L L I N G E N 3 Binnen het HiSPARC experiment wordt gebruik gemaakt van GPS om de locatie van HiSPARC units te weten te komen en voor zeer nauwkeurige tijdsbepaling. De GPS module die hiervoor gebruikt wordt is een GPS module op basis van een Texas Instruments DSP. Het zeer precies kunnen bepalen van de tijd is erg belangrijk omdat de toleranties hiervoer slechts enkele nanoseconden zijn. Echter kan de tijd weergegeven zijn in zowel de GPS- als UTC-tijdsaanduiding. Dit is afhankelijk van de configuratie van de FPGA module. Het is belangrijk om te weten in welke modus de module is ingesteld omdat de verschillende tijdsaanduidingen een verschil van enkele seconden hebben. De GPS module geeft iedere seconde een aantal gegevens door aan de FPGA, waaronder een byte waarin de huidige configuratie van de GPS weergegeven wordt. De FPGA moest deze byte gaan uitlezen en de relevante informatie over de configuratie van de GPS over een USB verbindinging doorgeven aan het LabVIEW programma. Het LabVIEW programma moet ook aangepast worden om deze nieuwe informatie correct te verwerken. Er moet een weergave bij komen zodat de gebruiker kan zien in welke tijdsconfiguratie de GPS module staat en of deze mogelijk aangepast moet worden. 3.1 realisatie Om de instellingsbyte van de GPS module te kunnen verwerken was het nodig het bestaande FPGA programma zodanig aan te passen dat de bewuste byte ook wordt uitgelezen. De byte wordt in een datastroom vanuit de GPS module die wordt uitgelezen door de FPGA mee gezonden (zie figuur 3.1) maar de instellingsbyte op zich werd nog niet uitgelezen. De GPS module zit in de HiSPARC unit verbonden met de FPGA door middel van een seriële verbinding die direct aangestuurd wordt door de UART op de GPS ontvangen zonder dat hier RS-232 of RS- 422 line drivers voor nodig zijn. Eens per second wordt over deze verbinding een aantal berichten verzonden. Het type bericht kan bepaald wordne door de eerste bytes van het bericht. Voor elk type bericht is er een bekende serie bytes (figuur 3.1) en is het bekend welke gegevens hier in staat (tabel 3.1). Daarnaast zijn de delimiters vooraf afgesproken, zodat makkelijk bepaald kan worden wanneer een bericht afgelopen is. 19

24 20 controle gps instellingen 8F AB XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX Figuur 3.1: De opbouw van de datastroom vanuit de GPS module. De byte waarin de benodigde configuratie bits staan is aangegeven in het rood. De start en stop bytes van het bericht zijn weergegeven in het blauw. 539 if MESSAGE_SELECT = "1" and SAMPLE_COUNT = 144 and STUFFED_BYTE = 0 then 540 case DECODER_BYTE_COUNT is 541 when 9 => GPS_FLAGS <= DECODE_BYTE1; 542 when 10 => GPS_SEC <= DECODE_BYTE1; 543 when 11 => GPS_MIN <= DECODE_BYTE1; 544 when 12 => GPS_HOUR <= DECODE_BYTE1; 545 when 13 => GPS_DAY <= DECODE_BYTE1; 546 when 14 => GPS_MONTH <= DECODE_BYTE1; 547 when 15 => GPS_YEAR1 <= DECODE_BYTE1; 548 when 16 => GPS_YEAR2 <= DECODE_BYTE1; 549 when other => 550 end case; 551 end if; Figuur 3.2: Een deel van de VHDL code voor het lezen van de GPS data. Op regel 541 wordt de byte met de GPS configuratie data (de negende byte in het bericht) opgeslagen in een variabele om later verwerkt te worden. Op deze manier kan uit het bericht de byte met de GPS configuratie data onderscheiden worden van de rest en kunnen de twee benodigde bits verkregen worden (figuur 3.2). Wanneer deze twee bits uitgelezen zijn, worden ze in de FPGA naar een intern signaal omgezet. Dit interne signaal is verbonden aan het blok van de FPGA code wat verantwoordelijk is voor de communicatie met de computer. In dit blok moeten de twee extra bits verwerkt worden in een bericht wat iedere seconde verzonden wordt om de LabVIEW applicatie te informeren over de status van de GPS. Op deze manier is het mogelijk om de twee extra bits met de datastroom naar de LabVIEW applicatie. In LabVIEW is ook voor een deel de bestaande structuur gebruikt voor het uitlezen van de data. Omdat de VI s die nodig zijn voor het lezen van de data die over de USB verbinding van de HiSPARC unit komt reeds bestaat, is deze aangepast om de extra bits goed af te handelen. Daarnaast is er op het controle paneel een extra LED bijgeplaatst (figuur 3.3) die aangeeft of de GPS instellingen correct zijn of niet. Verder wordt er in het log een bericht gelogged die aangeeft dat de instellingen van de GPS module niet correct zijn als dit het geval is.

25 3.1 realisatie 21 byte bit item type value description 0 Subcode UINT8 0xAB 1:4 Time of week UINT32 GPS seconds of week 5:6 Week number UINT16 GPS week number 7:8 UTC Offset SINT16 UTC Offset (seconds) 9 0 Timing flag bit field 0 GPS time 1 UTC time 1 0 GPS PPS 1 UCT PPS 2 0 time is set 1 time is not set 3 0 have UTC info 1 no UTC info 4 0 time from GPS 1 time from user 10 Seconds UINT8 0:59 Seconds 11 Minutes UINT8 0:59 Minutes 12 Hours UINT8 0:23 Hours 13 Day of month UINT8 1:31 Day of month 14 Month UINT8 1:12 Month 15:16 Year UINT16 Four digits of year Tabel 3.1: In deze tabel is weergegeven welke informatie te vinden is in het data pakket wat gekenmerkt wordt door de start bytes 8F AB Figuur 3.3: De LED op het controle paneel die aangeeft of de GPS instellingen correct zijn.