2012 EXPERIMENTEindverslagstage DATAACQUISITIEINHET HISPARC

E X P E R I M E N T Eindverslag stage 2012

r.d. kleiss

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 p e r i o d e:

Februari 2012 - Juni 2012

Mijn stage op het vond ik Nikhef erg leuk. Daarnaast was het erg leerzaam en interressant om mee te werken aan daadwerkelijk weten- schappelijk 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 ontwik- keling 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 (zo- als 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 me- ning. 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¹).

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 inschat- ten 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

1 h e th i s pa r c e x p e r i m e n t 3

1.1 Kosmische stralen . . . 3

1.2 Detectie . . . 3

1.2.1 Detectie stations . . . 4

1.2.2 Data acquisitie . . . 8

2 au t o m at i s c h e f p g a c o n f i g u r at i e 11 2.1 Ontwerp . . . 11

2.1.1 IPO-schema’s . . . 13

2.2 Implementatie . . . 16

2.3 Testen en resultaten . . . 17

3 c o n t r o l e g p s i n s t e l l i n g e n 19 3.1 Realisatie . . . 19

4 p y s pa r c 23 5 k l e i n e r e o p d r a c h t e n 25 5.1 Crash wanneer er in DAQ modus werd gegaan . . . 25

5.2 Fout in database communicatie . . . 25

6 c o n c l u s i e 27

1

1

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

HiSPARC is een project waarin middelbare scholen met wetenschap- pelijke 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 Nik- hef te Amsterdam. Zo vormen zij een groot, landelijk netwerk van meetopstellingen. In Nijmegen worden al sinds 2002 gegevens verza- meld (het NAHSA project) en in Amsterdam sinds 2004. Ook in de regio’s Eindhoven, Leiden, Enschede en Groningen staanHiSPARCde- tectoren.

1.1 k o s m i s c h e s t r a l e n

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 die- per 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 (fi- guur 1.1). Deze nieuwe deeltjes botsen op hun beurt met atoomker- nen 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 fi- guur 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 hetHiSPARC

experiment op zoek, omdat ze ons veel kunnen vertellen over de oor- sprong van het primaire deeltje.

1.2 d e t e c t i e

Figuur 1.2 toont een globaal overzicht van een HiSPARCdetectie sta- tion. 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 HiSPARCunit (rood omlijnt).

3

p π⁰

γ

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 be- reiken.

DeHiSPARCunits zijn via USB verbonden met een computer waar de data acquisitie software op draait (groen omlijnt). Deze data acquisi- tie software leest de data uit de HiSPARC units en verstuurt het naar een centrale database op het Nikhef.

1.2.1 Detectie stations

DeHiSPARCdetectie stations is een meetopstelling met daarin a) een scintillator plaat; b) een photomultiplier tube; en een c)HiSPARCunit.

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 scintil- lator 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.

Scintillator Photomultiplier tube ADCs

FPGA

GPS

USB

Controle paneel

Lokale database

HSMonitor Nagios

Centrale database

Figuur 1.2: Een schematisch overzicht van de opbouw van een HiSPARCde- tectie station met daarin de hardware (o.a. de scintillator plaat, photomultiplier tube enHiSPARCunit) en de data acquisitie soft- ware.

Scintillator Photomultiplier tube

Figuur 1.3: De inhoud van de ski-box van een detector in het HiSPARCpro- ject.

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´en 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 deHiSPARCunits verzonden. De combina- tie van de scintillator plaat waar de photomultiplier tube aan gekop- peld 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.

HiSPARCunits

Een HiSPARCunit (figuur 1.4) bestaat uit a) vier analoog-digitaal con- verters; b) een GPS ontvanger; c) een FPGA; en een d) USB chip.

a na l o o g-digitaal converters In eenHiSPARCunit 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₁en ADC₂op de op- en neergaande flank het PMT signaal uitle- zen. Dit betekend dat er effectief een sample frequentie van 400 MHz (of een sample tijd van 2.5 ns) wordt bereikt.

ADCs

FPGA

GPS

USB

Figuur 1.4: Schematisch overzicht van de inhoud van eenHiSPARCunit.

ADC₁ ADC₁ ADC₁ ADC₁

ADC2 ADC2 ADC2 ADC2

Crystal

Figuur 1.5: Timing diagram van de triggering van de ADCs in eenHiSPARC

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 ver- tekend signaal uitgelezen wat lijkt op een driehoeksgolf.

Het uitlijnen van de ADCs wordt door de software geregeld wan- neer het station ge¨ınstalleerd. Er worden intern verschillende referen- tie spanningen op de input van de ADC gezet, waarna wordt gecon- troleerd 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.

Het is mogelijk om een slave^HiSPARC unit aan te sluiten op een master HiSPARCunit. Een slave unit is een HiSPARCunit 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.

f p g a Het hart van een HiSPARC unit is een Altera Quartus FPGA. DezeFPGAleest 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 HiSPARCunit 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 tijde- lijke 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 coinci- dence 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.

g p s Wanneer er een event verstuurd wordt naar de computer wordt hier een timestamp aan gekoppeld die via GPS ontvangen is. Norma-

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 ver- schillende 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 hetHiSPARCproject 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 tijde- lijke data opslag en eerste analyse van de data. Via een ander proces

Configuratie Initializatie Process data Read bytes

Store data 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 in- terface voor het analyseren en configureren van een aantal aspecten van de hardware in deHiSPARC 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 voorge- daan 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 aan- tal 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 con- tact gezocht wordt met deHiSPARCelektronica.

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 ver- zonden is door deHiSPARCunit;

2. Het verwerken van de ingelezen data (de Process data thread) op zo’n manier dat het ge¨ınterpreteerd wordt als berichten vanuit deHiSPARCunit;

3. En het opslaan van de data in een lokale database (de Store data thread).

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 wor- den. 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 voor- waarden 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 hier- van 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 HiSPARCunits is een EEPROM chip aan- wezig waar deFPGAzijn firmware uit download wanneer deze opge- start 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 pro- grammeren van deHiSPARCunits maar het is niet gebruiksvriendelijk om iedere keer wanneer deHiSPARCunit 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 o n t w e r p

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¹kan dienen.

Het is met de SPI-interface mogelijk om deHiSPARC III FPGAte pro- grammeren ([1]). Om dit te doen moeten er echter wel een aantal stappen ondernomen worden, die het beste in een pseudocode kun- nen 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^HiSPARCunit (regel 5);

• Initializeren van eenHiSPARCunit (regel 6);

• Controleren of de FPGA klaar staat op firmware te ontvangen (regel 7);

• Uploaden van firmware naar deFPGA(regel 8);

• Controleren of deFPGAde firmware heeft ontvangen (regel 9);

1 MPSSE: Multi-Protocol Synchronous Serial Engine ([3])

11

Figuur 2.1: Huidige gebruikersinterface voor het programmeren van een

FPGAin deHiSPARCunits. Elke keer wanneer er opgestart wordt moet de gebruiker vanuit dit programma de firmware naar de

FPGAuploaden.

Algorithm 1Algoritme voor het programmeren vanHiSPARC IIIunits.

1: get number of connected USB devices

2: for allconnected devices do

3: get device details

4: ifHiSPARC IIIdevice then

5: open devices

6: initialize device

7: ifdevice is ready to receive firmware then

8: write firmware

9: ifdevice 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

• Sluiten van een handle naar de^HiSPARCunit (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 IPO- schema’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 mid- dels het get device count proces (figuur 2.2). Dit proces heeft geen in- puts en maar ´e´en output (count). De count output geeft het aantal verbonden USB apparaten terug waarbij geldt datcount≥_0.

Details van een USB apparaat

Get device details index

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´en 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 procesname,channelenlocation. De output namegeeft de naam van het apparaat terug, bijvoorbeeld HiSPARC III Masterin het geval van eenHiSPARC IIIMaster unit.

De output channel geeft het kanaal aan. Dit kan A of B zijn. De output locationgeeft de locatie van het apparaat op de USB stack van Windows aan. Dit is van belang omdat een aantal apparaten de- zelfde naam en kanaal kunnen hebben terwijl het toch verschillende apparaten zijn.

Openen van een handle naar eenHiSPARCunit

Open device name

channel location

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 enlocation; welke dezelfde functionaliteit hebben als beschreven bij het get device details proces.

Als output heeft het proceshandlewat 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. Wan- neerhandle>0 is de handle succesvol geopend.

Initializeren van eenHiSPARCunit

Initialize device handle

Figuur 2.5: Het initialize device proces

Het intializeren van een HiSPARC IIIunit gebeurd met het initialize de- vice 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 geo- pende handle naar deHiSPARC IIIunit. Er zijn verder geen outputs.

Controleren of deFPGAklaar staat op firmware te ontvangen

Device ready?

handle ready

Figuur 2.6: Het device ready? proces

Met het device ready? proces (figuur 2.8) kan gecontroleerd worden of eenHiSPARC IIIunit klaar staat om firmware te ontvangen. Het proces heeft de input handleen outputready. handleverwacht 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 deFPGA

Write firmware handle

firmware bytes written

Figuur 2.7: Het write firmware proces

Het uploaden van firmware naar deFPGAgebeurd met het write firm- ware proces (figuur 2.7). Als inputs heeft dit proces firmware en handle. De input firmware verwacht de data die naar de FPGA ge- schreven moet worden. De input handle verwacht een eerder geo- pende handle naar deHiSPARC IIIunit.

Als output heeft dit proces bytes written, die aangeeft hoeveel bytes er daadwerkelijk naar deFPGA geschreven zijn.

Controleren of deFPGAde firmware heeft ontvangen

Device ready?

handle 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 inputhandlever-

wacht een eerder geopende handle naar een FPGA. De output ready geeft aan of deFPGAde firmware correct heeft ontvangen.

Sluiten van een handle naar deHiSPARCunit

Close device handle

Figuur 2.9: Het device close proces

Een geopende handle naar een HiSPARC IIIunit kan gesloten worden met het close device proces (figuur 2.9). De input handlevan dit pro- ces verwacht de handle die gesloten moet worden. Het proces heeft verder geen outputs.

Het tonen van foutmeldingen aan de gebruiker

Print error 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 errorverwacht de foutmel- ding die aan de gebruiker getoond moet worden. Het proces heeft geen outputs.

2.2 i m p l e m e n tat i e

De eerder gedefine¨erde 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 ver- stuurd 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]. Wan- neer deFPGA dit commando begrepen heeft, wordt de CONF DONE lijn omlaag gebracht.

Zodra de CONF DONE lijn naar 0 is kan de firmware geschreven wor- den. De firmware moet in blokken van 64 kB geschreven worden, om- dat dit het maximum is wat via de FT2232H chip verzonden kan

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 ontvan- gen 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 t e s t e n e n r e s u ltat e n

De ontwikkelde LabVIEW VI’s zijn ge¨ımplementeerd in het bestaande LabVIEW programma waardoor deFPGAtijdens het opstarten van het programma geflashed wordt met de benodigde firmware. Een obsta- ken waar tegenaan gelopen werd was het gebruik van 64-bits proces- soren. 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

FPGAstaat, waardoor de firmware altijd naar deFPGAgeflashed 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).

3

C O N T R O L E G P S I N S T E L L I N G E N

Binnen hetHiSPARCexperiment wordt gebruik gemaakt van GPS om de locatie van HiSPARCunits te weten te komen en voor zeer nauw- keurige 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 r e a l i s at i e

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 da- tastroom 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 RS- 422 line drivers voor nodig zijn. Eens per second wordt over deze verbinding een aantal berichten verzonden. Het type bericht kan be- paald 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

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 configu- ratie data onderscheiden worden van de rest en kunnen de twee be- nodigde bits verkregen worden (figuur 3.2). Wanneer deze twee bits uitgelezen zijn, worden ze in de FPGA naar een intern signaal omge- zet.

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 bijge- plaatst (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.

b y t e b i t i t e m t y p e va l u e d e s c r i p t i o n

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 instellin- gen correct zijn.

4

P Y S PA R C

PySPARC¹ is een Python implementatie van het data acquisitie sys- teem binnen het HiSPARCexperiment. Dit project is gestart omdat er een fout zit in het uitlijnen van de ADCs in de derde versie van de

HiSPARCunits. Omdat er in de derde versie andere ADCs zitten dan in de tweede versie, moet het algoritme hiervoor andere waarden ge- bruiken. 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 wor- den zonder dat er veel tijd in het porten van de applicatie hoeft wor- den gestoken. Verder zijn er voor een heleboel taken bestaande libra- ries. Daardoor kunnen verschillende functionaliteiten een stuk sneller ge¨ımplementeerd worden. Een voorbeeld hiervan is wiskundige be- werkingen. Python heeft hiervoor de libraries NumPy en SciPy. Ook voor de interactie met de FTDI chip inHiSPARC IIIunits zijn libraries beschikbaar (PyFtdi). Met behulp van deze libraries is er in ´e´en week een werkende HiSPARC library ontwikkeld die voor het programme- ren van de HiSPARC IIIunits 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 be- wezen is wel dat het bestaande LabVIEW programma in principe te vervangen is door een Python programma.

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

23

5

K L E I N E R E O P D R A C H T E N

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

5.1 c r a s h wa n n e e r e r i n d a q m o d u s w e r d g e g a a n

Het LabVIEW programma heeft twee manieren waarop het uitge- voerd wordt:

• User mode

• DAQ mode

In user mode kan de gebruiker instellingen veranderen en daar di- rect 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 pro- gramma crashte¹.

Het LabVIEW progrogramma maakt intern veel gebruik van refe- renties. Referenties zijn vergelijkbaar met pointers in C en C++. Daar- naast worden alle controls op het front paneel ergens intern geregi- streerd. Wanneer een van deze controls nodig is, kan het worden op- gevraagd 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 ver- volgens werd opgevraagd werd er iets vergelijkbaars als een NULL- pointer 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 f o u t i n d ata b a s e c o m m u n i c at i e

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

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 crashde².

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 voor- doet. Als dit zo is, worden de queries genegeerd en wordt de data weggegooid.

Daarnaast wordt, wanneer de verbinding gesloten is, periodiek ge- probeerd 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

C O N C L U S I E

Gedurende de afgelopen periode op het Nikhef zijn de volgende op- drachten zijn het automatisch configuren van de FPGA en het contro- leren van de instellingen van de GPS module succesvol gerealiseerd.

Daarnaast zijn er verschillende kleine zaken van het LabVIEW pro- gramma 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 pro- blemen tijdens de communicatie met de FTDI chip in deHiSPARCunit is het vermoeden, de precieze oorzaak is nog niet gevonden. Een an- der 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 gerea- liseerd wat de uitlijning van de ADCs inHiSPARCunits, het program- meren van de FPGA zorgt en een basis data acquisitie verzorgt.

27

Figuur 1.1 Schematische weergaven van een cosmic ray air-

shower . . . 4

Figuur 1.2 Schematisch overzicht opbouwHiSPARCdetector 5 Figuur 1.3 De inhoud van de ski-box van een detector in hetHiSPARCproject. . . 6

Figuur 1.4 Schematisch overzicht van de inhoud van een HiSPARCunit. . . 6

Figuur 1.5 Timing diagram van de triggering van de ADCs in eenHiSPARCunit. . . 7

Figuur 1.6 Schematisch overzicht data acquisitie . . . 8

Figuur 1.7 Programmaflow controle paneel . . . 9

Figuur 1.8 Versturen van data naar de centrale database . 10 Figuur 2.1 Huidige gebruikersinterface voor het program- meren van eenFPGA . . . 12

Figuur 2.2 Het get device count proces . . . 13

Figuur 2.3 Het get device details proces . . . 13

Figuur 2.4 Het open device proces . . . 14

Figuur 2.5 Het initialize device proces . . . 14

Figuur 2.6 Het device ready? proces . . . 15

Figuur 2.7 Het write firmware proces . . . 15

Figuur 2.8 Het device ready proces . . . 15

Figuur 2.9 Het device close proces . . . 16

Figuur 2.10 Het print error proces . . . 16

Figuur 2.11 De implementatie van het device initialize proces 17 Figuur 2.12 Initialisatie van deFPGAzodat er nieuwe firm- ware geupload kan worden. . . 17

Figuur 3.1 De opbouw van de datastroom vanuit de GPS module. De byte waarin de benodigde confi- guratie bits staan is aangegeven in het rood. De start en stop bytes van het bericht zijn weerge- geven in het blauw. . . 20

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

Figuur 3.3 De LED op het controle paneel die aangeeft of de GPS instellingen correct zijn. . . 21

29

[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 Ac- quisition and Reconstruction of Shower Direction. PhD thesis, Nikhef Amsterdam, in voorbereiding.

[3] FTDI MPSSE Basics. Future Technology Devices International Li- mited (FTDI), Unit 1, 2 Seaward Place, Glasgow G41 1HH, United Kingdom, Maart 2010.

31