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

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

c 22 juni 2012 R.D. Kleiss: Data acquisitie in het HiSPARC experiment begeleiders: Drs. Ir. Ewout Boks Hogeschool van Arnhem en Nijmegen Embedded Systems Engineering [email protected] Prof. Dr. Ing. Bob van Eijk Nikhef HiSPARC

[email protected] periode: Februari 2012 - Juni 2012

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¨ele 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´e 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 GitHub1 ). 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 http://github.com/HiSPARC

iii

I N H O U D S O P G AV E

1 het hisparc experiment 1.1 Kosmische stralen . . . . . 1.2 Detectie . . . . . . . . . . . 1.2.1 Detectie stations . . . . 1.2.2 Data acquisitie . . . . .

. . . .

3 3 3 4 8

. . . .

11 11 13 16 17

3 controle gps instellingen 3.1 Realisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19 19

4

23

2 automatische fpga 2.1 Ontwerp . . . . . . . 2.1.1 IPO-schema’s . . . 2.2 Implementatie . . . . 2.3 Testen en resultaten .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

configuratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

pysparc

5 kleinere opdrachten 5.1 Crash wanneer er in DAQ modus werd gegaan . . . . . . 5.2 Fout in database communicatie . . . . . . . . . . . . . . . .

25 25 25

6

27

conclusie

1

1

H E T H I S PA R C E X P E R I M E N T

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 2004. Ook in de regio’s Eindhoven, Leiden, Enschede en Groningen staan HiSPARC detectoren. HiSPARC

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

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. 1.2.1

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.

1.2 detectie

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.

5

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 e´ e´ 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 ADC1 en ADC2 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.

1.2 detectie

ADC1

ADC1

ADC1

7

ADC1

Crystal ADC2

ADC2

ADC2

ADC2

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. gps Wanneer er een event verstuurd wordt naar de computer wordt hier een timestamp aan gekoppeld die via GPS ontvangen is. Norma-

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.

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. 1.2.2

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

1.2 detectie

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).

9

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 e-mail 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.

2

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

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-interface1 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

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

2.1 ontwerp

• Sluiten van een handle naar de HiSPARC unit (regel 15); • En het tonen van foutmeldingen aan de gebruiker (regel 10 en 13). 2.1.1

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 e´ e´ 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 e´ e´ n input, index. Met index kan worden aangegeven van w´elk 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.

13

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.

2.1 ontwerp

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-

15

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¨erde processen zijn, vanwege de opzet van LabVIEW 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

2.3 testen en resultaten

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).

17

3

CONTROLE GPS INSTELLINGEN

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¨ele verbinding die direct aangestuurd wordt door de UART op de GPS ontvangen zonder dat hier RS-232 of RS422 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

20

controle gps instellingen 8F AB XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 10 03 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 540 541 542 543 544 545 546 547 548 549 550 551

if MESSAGE_SELECT = "1" and SAMPLE_COUNT = 144 and STUFFED_BYTE = ’0’ then case DECODER_BYTE_COUNT is when 9 => GPS_FLAGS <= DECODE_BYTE1; when 10 => GPS_SEC <= DECODE_BYTE1; when 11 => GPS_MIN <= DECODE_BYTE1; when 12 => GPS_HOUR <= DECODE_BYTE1; when 13 => GPS_DAY <= DECODE_BYTE1; when 14 => GPS_MONTH <= DECODE_BYTE1; when 15 => GPS_YEAR1 <= DECODE_BYTE1; when 16 => GPS_YEAR2 <= DECODE_BYTE1; when other => end case; 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.

3.1 realisatie

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)

Timing flag

bit field

9

0

1

2

3

4

0

GPS time

1

UTC time

0

GPS PPS

1

UCT PPS

0

time is set

1

time is not set

0

have UTC info

1

no UTC info

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.

21

4

P Y S PA R C

PySPARC1 is een Python implementatie van het data acquisitie systeem binnen het HiSPARC experiment. Dit project is gestart omdat er een fout zit in het uitlijnen van de ADCs in de derde versie van de HiSPARC units. Omdat er in de derde versie andere ADCs zitten dan in de tweede versie, moet het algoritme hiervoor andere waarden gebruiken. De code hiervoor is in het LabVIEW programma echter zo ingewikkeld en onduidelijk, dat besloten is om dit eerst in Python te implemteren waarna het in LabVIEW ge¨ımplementeerd kan worden. Een voordeel van het gebruik van Python is dat het cross-platform is. Het kan dus op zowel Linux, Windows en Mac OSX gebruikt worden zonder dat er veel tijd in het porten van de applicatie hoeft worden gestoken. Verder zijn er voor een heleboel taken bestaande libraries. Daardoor kunnen verschillende functionaliteiten een stuk sneller ge¨ımplementeerd worden. Een voorbeeld hiervan is wiskundige bewerkingen. Python heeft hiervoor de libraries NumPy en SciPy. Ook voor de interactie met de FTDI chip in HiSPARC III units zijn libraries beschikbaar (PyFtdi). Met behulp van deze libraries is er in e´ e´ n week een werkende HiSPARC library ontwikkeld die voor het programmeren van de HiSPARC III units zorgt, het uitlijnen van de ADCs en een basis van data acquisitie. PySPARC is echter (op korte termijn) niet bedoeld als vervanging voor het LabVIEW programma. Er is op dit moment niet genoeg tijd om het LabVIEW programma in zijn geheel te ontvangen. Maar bewezen is wel dat het bestaande LabVIEW programma in principe te vervangen is door een Python programma.

1 http://github.com/HiSPARC/PySPARC

23

5

KLEINERE OPDRACHTEN

Naast de eerder beschreven grote opdrachten heb ik gedurende mijn stage ook verschillende kleinere opdrachten uitgevoerd. Dit waaren vooral problemen met het LabVIEW programma voor HiSPARC III. 5.1

crash wanneer er in daq modus werd gegaan

Het LabVIEW programma heeft twee manieren waarop het uitgevoerd wordt: • User mode • DAQ mode In user mode kan de gebruiker instellingen veranderen en daar direct het effect op de meetgegevens van zien. In DAQ mode is het voor de gebruiker niet mogelijk om instellingen te veranderen en worden gemeten gegevens naar de lokale MySQL database gestuurd. In de derde versie van het LabVIEW programma zat een fout wat ervoor zorgde dat, wanneer DAQ mode werd opgestart, het programma crashte1 . Het LabVIEW progrogramma maakt intern veel gebruik van referenties. Referenties zijn vergelijkbaar met pointers in C en C++. Daarnaast worden alle controls op het front paneel ergens intern geregistreerd. Wanneer een van deze controls nodig is, kan het worden opgevraagd middels een aparte VI. Om de controls intern te registreren werden de referenties van de controls gedowncast naar een referentie waarna de referentie met een naam werd opgeslagen. Het bleek dat een aantal controls verkeerd werden gedowncast, waardoor het opvragen ervan niet werkte. Wanneer de control vervolgens werd opgevraagd werd er iets vergelijkbaars als een NULLpointer in C terug gegevens waar vervolgens wel mee gewerkt werd. Als oplossing heb ik de downcasts van de controls vervangen door een ander type downcast waarna het geheel w´el werkte. 5.2

fout in database communicatie

Het HiSPARC LabVIEW programma maakt gebruik van ODBC voor het communiceren met lokale MySQL database. Wanneer er een fout optreedt bij een query, wordt de verbinding gesloten. Het LabVIEW 1 Issue tracker URL: https://github.com/HiSPARC/labview/issues/10

25

26

kleinere opdrachten

programma hield dit niet in de gaten, wat ervoor zorgde dat, wanneer er weer een query werd uitgevoerd, het programma met een gesloten verbinding aan het communiceren was. Dit zorgde ervoor dat er een heleboel data in het geheugen van LabVIEW bleef hangen, waardoor het geheugen uiteindelijk op raakte en het programma crashde2 . Dit heb ik opgelost door de VI die het schrijven naar database te refactoren. Tijdens mijn inspectie bleek dat deze VI monsterlijk groot was geworden en er niet op fouten werd gecontroleerd. Daarnaast werden de MySQL queries zowel in de VI opgesteld als verstuurd, wat geen goed design pattern is. Als oplossing heb ik een aparte VI gemaakt die de queries opstelde. Deze VI wordt niet aangeroepen binnen de VI die de communicatie met de MySQL database doet. Alle opgestelde queries worden verzameld in een array waarna ze in een for-loop een voor een worden weggeschreven naar de MySQL database. Ondertussen wordt er gecontroleerd of er een fout voordoet. Als dit zo is, worden de queries genegeerd en wordt de data weggegooid. Daarnaast wordt, wanneer de verbinding gesloten is, periodiek geprobeerd de verbinding opnieuw te openen. Zodra dit gelukt is kan de VI die de communicatie met de MySQL database doet weer zijn data wegschrijven.

2 Issue tracker URL: https://github.com/HiSPARC/labview/issues/4

6

CONCLUSIE

Gedurende de afgelopen periode op het Nikhef zijn de volgende opdrachten zijn het automatisch configuren van de FPGA en het controleren van de instellingen van de GPS module succesvol gerealiseerd. Daarnaast zijn er verschillende kleine zaken van het LabVIEW programma opgelost. Het automatisch configureren van de FPGA heeft veel tijd in beslag genomen, daarom zijn andere opdrachten niet succesvol gerealiseerd, zoals de uitlijn procedure van de ADCs in HiSPARC III units (deze opdracht is er ook pas laat tijdens de stage bijgekomen). Een oorzaak hiervan was het gebruik van 64-bits processoren. Dit zorgde voor problemen tijdens de communicatie met de FTDI chip in de HiSPARC unit is het vermoeden, de precieze oorzaak is nog niet gevonden. Een ander struikelblok hierbij was de limit van 64 kB bij het verzenden van data naar de FPGA. Dit stond als opmerking in de documentatie van de FTDI chip verborgen en niet duidelijk gemeld. Hierdoor werd er maar een deel van de data verzonden en liep het programma vast. Verder is er succesvol een proof of concept Python programma gerealiseerd wat de uitlijning van de ADCs in HiSPARC units, het programmeren van de FPGA zorgt en een basis data acquisitie verzorgt.

27

L I J S T VA N F I G U R E N

Figuur 1.1 Figuur 1.2 Figuur 1.3 Figuur 1.4 Figuur 1.5 Figuur 1.6 Figuur 1.7 Figuur 1.8 Figuur 2.1 Figuur 2.2 Figuur 2.3 Figuur 2.4 Figuur 2.5 Figuur 2.6 Figuur 2.7 Figuur 2.8 Figuur 2.9 Figuur 2.10 Figuur 2.11 Figuur 2.12 Figuur 3.1

Figuur 3.2

Figuur 3.3

Schematische weergaven van een cosmic ray airshower . . . . . . . . . . . . . . . . . . . . . . . . Schematisch overzicht opbouw HiSPARC detector De inhoud van de ski-box van een detector in het HiSPARC project. . . . . . . . . . . . . . . . . Schematisch overzicht van de inhoud van een HiSPARC unit. . . . . . . . . . . . . . . . . . . . . Timing diagram van de triggering van de ADCs in een HiSPARC unit. . . . . . . . . . . . . . . . . Schematisch overzicht data acquisitie . . . . . Programmaflow controle paneel . . . . . . . . Versturen van data naar de centrale database . Huidige gebruikersinterface voor het programmeren van een FPGA . . . . . . . . . . . . . . . Het get device count proces . . . . . . . . . . . . Het get device details proces . . . . . . . . . . . . Het open device proces . . . . . . . . . . . . . . . Het initialize device proces . . . . . . . . . . . . Het device ready? proces . . . . . . . . . . . . . Het write firmware proces . . . . . . . . . . . . . Het device ready proces . . . . . . . . . . . . . . Het device close proces . . . . . . . . . . . . . . . Het print error proces . . . . . . . . . . . . . . . De implementatie van het device initialize proces Initialisatie van de FPGA zodat er nieuwe firmware geupload kan worden. . . . . . . . . . . . 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. . . . . . . . . . . . . . . . . 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. . . . . . . . . . . . . De LED op het controle paneel die aangeeft of de GPS instellingen correct zijn. . . . . . . . . .

4 5 6 6 7 8 9 10 12 13 13 14 14 15 15 15 16 16 17 17

20

20 21

29

BIBLIOGRAFIE

[1] Altera Cyclone 3 Handbook. Altera, 101 Innovation Drive, San Jose, CA 95134, December 2011. [2] D.B.R.A Fokkema. The HiSPARC Cosmic Ray Experiment: Data Acquisition and Reconstruction of Shower Direction. PhD thesis, Nikhef Amsterdam, in voorbereiding. [3] FTDI MPSSE Basics. Future Technology Devices International Limited (FTDI), Unit 1, 2 Seaward Place, Glasgow G41 1HH, United Kingdom, Maart 2010.

31