4.2 Implementatie
4.2.4 Het upper-mac
Het upper-mac dient ter ondersteuning van het lower-mac. Het upper-mac reageert wanneer hogere lagen een pakket willen versturen. Het past statusinformatie aan en geeft het pakket door aan het lower-mac. Analoog worden binnenkomende pakketten van het lower-mac verwerkt en doorgegeven aan hogere lagen. Reports zijn een extra mechanisme waardoor het lower-mac extra informatie aan het upper-mac kan geven. Deze worden door het upper-mac afgehandeld. De belangrijkste functies die het upper-mac vervult zijn als volgt:
• Gedetecteerde buren worden bijgehouden in een burentabel. Buren worden slechts tijdelijk bijgehouden en worden verwijderd indien deze een vaste periode niet meer werden gede- tecteerd. Bij het ontvangen van Hello pakketten wordt de buur toegevoegd aan de tabel of wordt de timeout geüpdatet. De burentabel wordt gebruikt voor te bepalen met wie er aan afstandsbepaling wordt gedaan. In de implementatie doet elke node aan afstandsbepaling
4.2. IMPLEMENTATIE 49 met alle buren die een lager ID hebben. Tussen elk paar in elkaars bereik wordt periodiek de afstand bepaald, dezelfde node van een paar zal steeds master zijn.
• Tijdens afstandsbepaling speelt het upper-mac ook een cruciale rol. Wanneer het lower-mac de TDMA-chain start, moet het upper-mac achterhalen of de node master of slave is. Dit wordt via reports aangegeven, waarmee het upper-mac het type van de drie TDMA-slots instelt.
Verder wordt er via reports achterhaald welk van de drie slots actief is. Het upper-mac achterhaalt het type van dit slot en verstuurt een UWB-pakket indien het een TX-slot is. Welk slot actief is, is ook van belang voor het opslaan van gerapporteerde timestamps. Zowel het type als de index van het slot zijn nodig voor timestamps te linken aan een ADS-TWR interactie. Eens de zes timestamps na drie slots bekomen zijn, wordt de afstand berekend.
5
Testing
In dit hoofdstuk wordt de implementatie getest. Eerst wordt de testconditie beschreven. Ver- volgens wordt bepaald hoe lang één afstandsbepaling duurt, waarmee het maximum aantal afstandsbepalingen per seconde wordt geschat. Daarna wordt nagegaan hoeveel afstandsbepa- lingen per seconde de implementatie werkelijk haalt onder verschillende omstandigheden. Extra invloeden zoals het versturen van Hello berichten worden hierbij in achting genomen. Het voor- gestelde single-CPU TDMA ontwerp wordt ook theoretisch vergeleken met de implementatie. Als laatste worden ook hidden-node collisions en het energieverbruik geanalyseerd.5.1 Testconditie en assumpties
De implementatie wordt uitgevoerd en getest op Lopos-chips. Dit zijn uitgebreide DWM1001C- chips [6] die naast een UWB- en een Bluetooth-antenne ook een subGHz-antenne bevatten. De Bluetooth-antenne wordt niet gebruikt door de implementatie. Zowel de DWM1001C- als de uitgebreide Lopos- chip worden getoond in figuur 5.1. De Lopos-chip bestaat uit drie belangrijke componenten:
• een DW1000 UWB-radiochip van DecaWave [32]. De gebruikte configuratie gebruikt ka- naal 5, met als centrale frequentie 6.5 GHz en een bandbreedte van 500 MHz. Verder is
5.1. TESTCONDITIE EN ASSUMPTIES 51
(a) DWM1001C chip [54]
(b) Lopos chip
Figuur 5.1: Een Lopos chip is een uitgebreide DWM1001C chip en bevat ook nog een subGHz- antenne.
de preambule 512 bits lang en is de PRF 64 MHz. De datarate is beperkt tot 850 kbps. • een cc1200 subGHz-radiochip van Texas Instruments[52]. Bij de gebruikte configuratie is
de centrale frequentie ingesteld op 868 MHz. De bitrate is beperkt tot 150 kbps, het uitzendvermogen tot 14 dBm. De synchronisatieheader is 5 bytes groot.
• een nRF52832 MCU van Nordic Semiconductor[53]. Dit is een general-purpose ”System on a Chip”en bevat vele componenten. Belangrijk is de Arm Cortex-M4 CPU, 64 KB RAM geheugen en 256 KB flash geheugen. Het bevat ook andere componenten waaronder een Bluetooth-radio die niet wordt gebruikt.
Bij het testen worden deze radioconfiguraties niet gewijzigd. De resultaten zijn onder ideale om- standigheden bekomen. Daarbij worden de chips naast elkaar gelegd zodat de signalen optimaal worden ontvangen. CRC-fouten en dergelijke worden ook niet in achting genomen tenzij er ab- normaal veel fouten optreden. Experimentele resultaten worden bekomen door de uitvoerpinnen van de Lopos chip te analyseren. TAISC regelt deze uitvoer en zet bepaalde pinnen hoog onder bepaalde omstandigheden.
De chips kunnen geen CCA-checks verrichten. Anekdotisch komt dit omdat Lopos chips slechts een beperkt aantal interruptlijnen hebben waardoor er slechts een beperkt aantal soorten inter- rupts kunnen worden gedefinieerd. Bepaalde versies van TAISC (waaronder ook de gebruikte
Tabel 5.1: De tijd (µs) voor pakketten op te sturen. Berichten gaan altijd een preambule vooraf. voor subGHz berichten is dit subGHz-pre, analoog voor UWB berichten UWB-pre. messages UWB-pre UWB-ranging subGHz-pre HELLO INIT ACK CONFIRM
size (bytes) 64 23 5 13 13 5 21
time (µs) 601 216 265 689 689 265 1113
versie) gebruiken deze interruptlijnen voor andere, belangrijkere events. Doordat er geen CCA- checks kunnen gebeuren, is het mogelijk dat een chip een pakket begint te versturen terwijl er een ander pakket wordt ontvangen. Hierdoor crasht de chip. Deze crashes worden ook niet in achting genomen.
Bij het testen konden slechts drie chips gebruikt worden. Een netwerk met meerdere nodes wordt gesimuleerd door één chip veel meer Hello en InitRanging berichten te laten versturen dan de andere twee chips.
De snelheid waaraan opeenvolgende afstandsbepalingen tussen hetzelfde paar nodes plaatsvindt, wordt de afstandsbepalingsperiode genoemd. In de implementatie voert elk paar evenveel af- standsbepalingen uit en is de afstandsbepalingsperiode gelijk voor alle paren. De snelheid waar- aan nodes Hello berichten versturen, wordt de Hello berichtperiode genoemd. Beide waarden moeten op voorhand hardgecodeerd worden op de chips.