1 Ontwerp en implementatie van een draadloos communicatieprotocol voor sensor netwerken Bert Vanhoutte Promotor: prof. dr. ir. Jan Doutreloigne Begele...
Ontwerp en implementatie van een draadloos communicatieprotocol voor sensor netwerken Bert Vanhoutte
Promotor: prof. dr. ir. Jan Doutreloigne Begeleiders: ir. Benoît Huyghe, ir. Thomas Vervust Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek
Vakgroep Elektronica en informatiesystemen Voorzitter: prof. dr. ir. Jan Van Campenhout Faculteit Ingenieurswetenschappen Academiejaar 2009-2010
VOORWOORD
ii
Voorwoord Na jaren studiewerk met een sterke theoretische inslag, komt er een moment om de opgedane kennis in praktijk om te zetten. Het integreren van die kennis en deze toetsen met de praktijk, kan idealiter in een thesis. Door de veelzijdigheid van een thesis leer je niet alleen je sterke en zwakke punten kennen, je leert er ook mee omgaan! Zelfstandig een project tot een goed einde brengen blijkt niet altijd even gemakkelijk te zijn. Gelukkig sta je niet alleen bij het maken van je thesis, maar kan je steeds terugvallen op bepaalde personen. In eerste instantie denk ik aan Ir. Benoˆıt Huyghe, die mij het hele jaar door zeer goed heeft begeleid! Bij vragen of problemen kon ik steeds bij Benoˆıt terecht, die me altijd met de glimlach heeft geholpen. Ik wil hem dan ook graag bedanken voor de ondersteuning die hij me gedurende het hele jaar heeft gegeven! Uiteraard gaat er ook een woord van dank uit naar Prof. Jan Doutreloigne, die me de kans en het vertrouwen heeft gegeven. Daarnaast wil ik alle mensen van de vakgroep ELIS-CMST bedanken die achter de schermen geholpen hebben aan de realisatie en uitwerking van mijn thesis. Natuurlijk komt er naast het technische werk nog heel wat kijken. Ik zou dan ook mijn ouders en vrienden willen bedanken, die me dit jaar enorm veel steun bezorgd hebben. In momenten van stress of problemen kon ik steeds op hen rekenen, wat ik ten zeerste apprecieer! Dit proefschrift vormt dan ook het sluitstuk van mijn “carri`ere” als student en slaat meteen de brug naar een nieuwe toekomst in het bedrijfsleven.
Bert Vanhoutte, mei 2010
TOELATING TOT BRUIKLEEN
iii
Toelating tot bruikleen
“De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”
Bert Vanhoutte, mei 2010
Ontwerp en implementatie van een draadloos communicatieprotocol voor sensor netwerken door Bert Vanhoutte Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek Academiejaar 2009–2010 Promotor: Prof. Dr. Ir. J. Doutreloigne Begeleiders: Ir. B. Huyghe, Ir. T. Vervust Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Elektronica en informatiesystemen Voorzitter: Prof. Dr. Ir. J. Van Campenhout
Samenvatting In deze scriptie wordt een communicatieprotocol ontwikkeld voor een draadloos sensor netwerk. Het netwerk wordt gebruikt om menselijke bewegingen te reconstrueren. Een vereiste hierbij is dat er minstens 15 sensor nodes moeten kunnen opereren in het netwerk. Deze nodes moeten elk 100 samples per seconde doorsturen naar een centrale ontvanger. Verder is het de bedoeling dat het netwerk volledig dynamisch is en dat het falen van ´e´en node de andere nodes niet be¨ınvloedt. Zoals bij de meeste batterijgevoede applicaties speelt het stroomverbruik een centrale rol bij het ontwerp van het netwerkprotocol.
Design and Implementation of a Wireless Communication Protocol for Sensor Networks Bert Vanhoutte Supervisor(s): Prof. dr. ir. Jan Doutreloigne, ir. Benoˆıt Huyghe Abstract—This paper presents the design of a low-power communication protocol for a wireless sensor network. The network will be used for human posture tracking and the sensor nodes contain accelerometers and magnetomers. The human body can be approximated as a rigid body consisting of 15 links [1]. For this purpose, the network must support at least 15 sensor nodes, each transmitting 100 samples per second. Monitoring several people on one PC requires the design of a new receive node. The resulting network protocol is fully dynamic and has a capacity of 19 sensor nodes. The protocol is based upon TDMA, resulting in an average power consumption of less than 3 mA for each sensor node. The time slots are dynamically assigned, making the network plug-and-play. To allow for synchronization, one of the nodes is assigned the role of master, while the others are slaves. The network protocol makes sure there is always exactly one master node. Keywords— Wireless sensor network, low-power, dynamic network protocol
I. I NTRODUCTION UMAN posture tracking can be used in a number of applications. In the medical world, eppileptic seizure detection is a possible application, but the gaming industry is also looking for posture tracking systems. In both of these examples, the goal is to design a system, that is as unobtrusive as possible for the user. A wireless network consisting of sensor nodes with inertial sensors could be the solution. In epileptic seizure detection, electroencephalogram (EEG) measurements combined with camera images are commonly used [2]. In contrast to these systems, posture tracking with inertial sensors could offer realtime detection and, since no cameras are involved, the patient could move about in a much larger area. This paper describes the design and implementation of a communication protocol for a sensor network, used for human posture tracking. The main challenges are the dynamic nature of the protocol, a minimum of 15 sensor nodes on each person and the ability to monitor several people on the same computer. The designed protocol is based on the work of Huyghe [3]. His network was able to monitor 10 nodes, each at a rate of 100 samples/s. One problem was that this protocol was fully static, which means that one node could cause the entire network to fail. The goal is to design a protocol that is fully plug-andplay, which means that the network must work, no matter which nodes are switched on. Exactly one node is the master, while the others are slaves. When the master is down, the network chooses exactly one slave to become master. To avoid dangerous situations, where multiple masters are operating in the same network, some failure-mechanisms are implemented, making it possible for the network to repair itself. Besides the network protocol, the receiver node also needed to be redesigned to support the monitoring of more than one person on the same computer. The receiver node is a central element in the network, which receives all data from the sensor nodes and passes this data to the PC.
H
II. S OFTWARE The protocol is custom made for the given application. Since low-power is one of the key issues, a TDMA-based multiplexing scheme is an ideal solution. In a TDMA-scheme, each node is assigned its own time slot, in which all data is sent. This means that the nodes can use sleepmodes in between subsequent time slots. One must carefully define the time slots and make sure the slots of different sensor nodes don’t overlap. To do so, all nodes need to be synchronized. This is accomplished by using one special sensor node, the master, which is used as a reference for the protocol. All other nodes are slaves and they synchronize their data transmission to that of the master. The network protocol is dynamic, which means that every node can either be a slave or a master, depending on the situation. At startup, a node checks if there is a master in its vicinity. To do this, it simply listens on the master channel for 50 ms. If no data is received during this period, the node becomes master. If a master is already operating in the network, the node becomes slave. At this point the node doesn’t know which timeslot to use and due to the dynamic nature of the protocol, time slots have to be chosen on-the-fly. This is executed by listening on the slave channel and marking al used time slots. Every slave sends its time slot number in each data package, allowing the other nodes to choose a free slot. Fig. 1 shows the flowchart of the initialization procedure. To avoid conflict situations, such as multiple active masters or slaves using the same time slot, a variable delay is introduced at startup. To ensure this delay is different for each node, a unique delay is calculated based on the node’s sensor number. This sensor number is the only difference between all nodes and is necessary for identification.
Initialize
Master detected?
Listen on master channel
Listen on slave channel: detect all used timeslots
NO
YES Become master
Become slave, use free timeslot
Fig. 1. Flowchart of the initialization procedure.
A. Master The master node doesn’t need to synchronize with any other node, it simply transmits a data packet every 10 ms, based on an internal timer. Fig. 2 shows the flowchart of the master node operation.
C. Receiver
Initialize
Reset timer Send data
Wait in LPM until timer = 10 ms
Perform measurement
Fig. 2. Flowchart of the master node.
A problem arises when two (or more) masters are active in the same network. This can occur due to interference or other unpredictable situations. If this happens, the network needs to repair itself and maintain only one of the masters. The master conflict function configures the master(s) to listen on the master channel every 5 to 10 seconds (variable). This way, a master can detect if other sensor nodes are transmitting on the master channel.
A third type of node is used to receive al data from the sensor nodes and to send this data to the PC. This node can communicate with the PC using 3 different interfaces: USB, Ethernet or Bluetooth. The Ethernet and Bluetooth interfaces allow the extension to monitor more than one person. The flowchart of its operation is shown in Fig. 4. The software for this node needs to be designed very carefully, as time is critical here. The reason that time is more critical in this node than in the sensor nodes is because the receiver has to receive all time slots and send these to the PC, whereas the sensor nodes only need to send one packet every 10 ms. As can be seen on the flowchart, only one interface is used at a given time. Switches on the receive node are used to select the interface.
B. Slave A slave node has the same purpose as the master node, but uses a different frequency channel than the master. The synchronization with the master is accomplished by listening on the master channel until a data package is detected. This master packet marks the beginning of a new frame (period of 10 ms in which every node sends exactly one packet). After reception, the slaves configure their transceiver to send data on the slave channel and every slave waits until its time slot occurs. If this synchronization would be done each frame, the slaves consume way more power than the master, as their transceiver is turned on twice every frame: once to detect the master and once to send their own data. To overcome this problem, synchronization is done every 256 frames. In between synchronizations, the slaves transmit their data in an autonomous way, just like the master node. This can be done because the sensor nodes are driven by a very precise watch crystal (20 ppm). This means that the error will be smaller than 51 µs and cannot cause two time slots to overlap. Furthermore, slaves need to have a procedure to become master if the current master node stops working. The synchronization with the master is the ideal time to check if the master is still alive. When the slaves wait for the master synchronization packet, they start a timer. The value of the timeout is different for every slave, to ensure only one slave becomes master. The slave operation is shown in Fig. 3.
Change RF to RX N = 0 on master freq.
Timer interrupt
Initialize
Reset timer
Wait in LPM for RX master data
Wait in LPM for timeslot
Start timer with interrupt after (52+timeslot*20) ms
Send data
Wake-up source ?
Perform measurement
Change RF to TX on slave freq.
Send UDP packet
Send BT packet
UDP
Interface ?
Send USB packet
Read out data
Wait in LPM for RX master data
Change RF to duo-RX on slave frequencies
Reset timer
Wait in LPM for RX slavedata
BT
USB
Read out data Interrupt when timer = 7.5 ms
Fig. 4. Flowchart of the receive node.
III. R ESULTS The resulting protocol is fully dynamic and supports 19 sensor nodes, each at a rate of 100 samples/s. The average power consumption of a sensor node is less than 3 mA. To support all necessary extensions, the receive node had to be redesigned (Fig. 5). This receiver has 3 interfaces to the PC: USB, Bluetooth and Ethernet. The Bluetooth interface makes it possible for the receiver to be placed on the body and supports monitoring of several people on the same PC.
N++
Wait in LPM until timer = 10 ms
Fig. 5. PCB of the receive node.
R EFERENCES
Master data Become master
Change RF to RX on master freq.
Initialize
N = 256 ?
YES
Fig. 3. Flowchart of the slave node.
NO
[1] E. P. Hanavan A Mathematical Model of the Human Body, Aerospace Medical Res. Lab., Wright-Patterson Air Force Base, TR-64-102, 1964 [2] P. Buteneers, B. Schrauwen, D. Verstraeten, D. Stroobandt Real-time Epileptic Seizure Detection on Intra-Cranial Rat Data Using Reservoir Computing, http://biblio.ugent.be/record/721867 [3] B. Huyghe, J. Vanfleteren, J. Doutreloigne Design of Flexible, Low-Power and Wireless Sensor Nodes for Human Posture Tracking Aiding Epileptic Seizure Detection,
Detectie van epileptische aanvallen gebeurt meestal door een electroencephalogram-meting (EEG) in combinatie met video monitoring [1]. Deze aanpak heeft een aantal grote nadelen. Vooreerst is het niet praktisch haalbaar om een dergelijk systeem te gaan gebruiken bij pati¨enten thuis. De kostprijs van deze systemen is namelijk niet te verantwoorden voor priv´e-gebruik. Daarnaast is het systeem allesbehalve gebruiksvriendelijk. De pati¨ent heeft zo goed als geen bewegingsvrijheid, daar hij steeds in het zicht van de camera moet blijven. Dit wil zeggen dat de detectie ook kan verstoord worden door objecten die zich tussen de camera en de pati¨ent bevinden. Een ander probleem is dat de detectie niet real-time kan gebeuren. De reden hiervoor is dat de opgemeten data moet geanalyseerd en verwerkt worden door een PC. Een heel andere aanpak is het gebruik van bewegingssensoren [2],[3], zoals accelerometers, magnetometers en gyroscopen [4]. Door een aantal sensor nodes te plaatsen op verschillende lichaamsdelen kan de beweging van een persoon worden gereconstrueerd. Het menselijk lichaam kan worden voorgesteld als een star lichaam, bestaande uit 15 beweegbare delen [5]. Als elk van deze lichaamsdelen voorzien wordt van een dergelijke sensor node, kan de volledige beweging van een persoon worden nagegaan. Figuur 1.1 toont het principe van bewegingsreconstructie met behulp van bewegingssensoren.
Figuur 1.1: Principe van bewegingsreconstructie met ´e´en sensor node.
2 Doelstelling
2
Het is uiteraard de bedoeling dat de pati¨ent niet gehinderd wordt door deze nodes, zodat hij zonder problemen zijn dagdagelijkse activiteiten kan verderzetten. Dit betekent dat het systeem draadloos moet zijn. . . Een draadloos systeem is sowieso al een grote uitdaging. Bij het ontwerp van een dergelijk systeem staat vermogenverbruik steeds centraal. Om een goede ontvangst te garanderen moet er anderzijds wel voldoende vermogen worden uitgezonden. Daarnaast is het gebruik van een foutendetecterende code een must, maar het is logisch dat meer data verzenden gepaard gaat met een hoger vermogenverbruik. . . Verder moet er ook rekening gehouden worden met de wetgeving. De 2.4 GHz ISM-band mag vrij gebruikt worden (zonder licentie), op voorwaarde dat er voldaan is aan de wetgeving. Deze wetten leggen precies vast welke frequenties gebruikt mogen worden en hoeveel zendvermogen er maximaal mag worden uitgestraald. Een andere key-factor is “co-existentie”. Doorheen de jaren zijn er tal van draadloze systemen ontwikkeld die gebruik maken van de 2.4 GHz ISM-band. Voorbeelden zijn WiFi [6],[7], Bluetooth [8],[9], ZigBee [10],[11],. . . Door geschikte frequenties te kiezen kan interferentie ten gevolge van andere draadloze netwerken geminimaliseerd worden.
2
Doelstelling
Zoals het onderwerp van deze thesis doet vermoeden is het voornaamste doel de ontwikkeling van een protocol voor een draadloos sensor netwerk. Dit netwerk bestaat uit 15 sensor nodes, uitgerust met een 3D-accelerometer en een 3D-magnetometer. Elke node moet minstens 100 samples per seconde doorsturen, om een goede reconstructie van de bewegingen te verkrijgen. De bedoeling is dat het netwerk volledig plug-and-play is en dat de sensor nodes onafhankelijk kunnen opereren. Het falen van ´e´en node mag er dus niet voor zorgen dat de data van andere nodes ook verloren gaat. Dit project is een uitbreiding van een reeds bestaand protocol, dat ontworpen werd door mijn begeleider Benoˆıt Huyghe. Het bestaande protocol was echter volledig statisch en voorziet in maximaal 10 sensor nodes. Naast de uitbreiding tot minimaal 15 sensor nodes, moet het systeem ook worden aangepast, zodat er meerdere personen (met elk 15 sensor nodes) kunnen gevolgd worden op ´e´en PC. Hiervoor volstaat het niet om enkel de software aan te passen, maar moet er ook een deel van de hardware worden uitgebreid. Zoals verder in deze thesis besproken wordt, is het de ontvangstnode die moet worden aangepast om deze uitbreiding te ondersteunen. Het design van deze node is eveneens een deel van dit eindwerk.
NETWERKPROTOCOL
3
Hoofdstuk 2
Netwerkprotocol 1
Inleiding
In dit hoofdstuk wordt het netwerkprotocol besproken, die zorgt voor de communicatie tussen de verschillende sensor nodes en de ontvanger. In eerste instantie worden de vereisten en specificaties van het sensor netwerk opgesomd. Daarna wordt het protocol uitgelegd aan de hand van flowcharts. Hoe dit protocol ge¨ımplementeerd werd in de microcontrollers, wordt besproken in Hoofdstuk 4: “Embedded software”. Zoals reeds besproken werd in hoofdstuk 1, moet het netwerk in staat zijn om de informatie van 15 sensor nodes door te sturen naar een centrale ontvanger. Voor een goede reconstructie van de bewegingen is het noodzakelijk dat er voldoende samples worden verstuurd. Concreet hebben we zeker 100 samples per seconde nodig per sensor node. De gegevens van de 15 nodes worden allemaal ontvangen op de centrale node, die verbonden is met de PC. Elke sensor node is voorzien van een 3D-magnetometer en een 3D-accelerometer. Zoals besproken wordt in het hardware gedeelte (Hoofdstuk 3) werd gekozen voor de YAS529 magnetometer van Yamaha en de LIS302DL accelerometer van ST Microelectronics. Deze twee sensoren hebben het voordeel dat ze digitaal uitgelezen kunnen worden door middel van een I2 C-connectie en dat ze een zeer laag vermogenverbruik hebben. De accelerometer zet de analoge waarde van elke as om in een 8-bit digitale waarde, terwijl de magnetometer 16 bits per as gebruikt. De data van de twee sensoren is dus negen bytes groot. Deze bytes worden samen met het sensor nummer en het time slot verzonden naar de centrale ontvanger. Elk verzonden pakket is dus 11 bytes groot. Rekening houdende met de eis dat er 100 samples per seconde verstuurd moeten worden, komen we uit op een netto communicatiesnelheid van 132 kbps. Theoretisch mag dit geen enkel probleem zijn, maar we moeten uiteraard in het achterhoofd houden dat het hier gaat om 15 verschillende nodes. Dit zorgt dat we rekening moeten houden met vertragingen en marges, waardoor de communicatiesnelheid hoger moet liggen om deze vertragingen te compenseren.
2 Bestaande software
4
Een ander belangrijk punt is het vermogenverbruik. De sensor nodes zullen namelijk voorzien worden van stroom door een batterij. Zoals dit meestal het geval is in dergelijke applicaties is de batterij een zwakke schakel. Als het systeem een te lage autonomie heeft, wordt het systeem niet alleen onhandig, maar eveneens duur en onbetrouwbaar. Batterijen blijven namelijk een relatief duur onderdeel! Wat heeft de betrouwbaarheid hiermee te maken? Het mag wel duidelijk zijn dat het systeem zal falen als de batterijen (van ´e´en of meerdere nodes) leeg zijn. Als dit zeer frequent gebeurt kunnen we moeilijk spreken van een stabiel en betrouwbaar systeem . . . Om het vermogenverbruik te minimaliseren is het niet voldoende om de juiste hardware te kiezen, ook de software is hierbij een niet te onderschatten aandachtspunt! Wat de hardware betreft, wordt zoveel mogelijk gewerkt met low-power componenten. De software wordt geoptimaliseerd door gebruik te maken van low-power modes.
2
Bestaande software
Zoals reeds werd aangehaald, is deze thesis een uitbreiding van een reeds bestaand systeem [12]. In dit deel wordt de software van het initi¨ele ontwerp besproken. Omdat deze software de basis vormt voor de volgende software-versies wordt hieraan toch de nodige aandacht besteed. Hieruit zal ook duidelijk worden waarom uitbreiding noodzakelijk is.
2.1
Algemene werking en opbouw van het sensor netwerk
De structuur van het netwerk is relatief simpel. In feite kunnen we spreken van een sternetwerk, waarbij de 15 nodes hun data verzenden naar de centrale ontvanger. Deze ontvanger is de schakel tussen het sensor netwerk en de PC en speelt dus ook een zeer belangrijke rol in het systeem. Een voorstelling van deze topologie is te zien in figuur 2.1.
Receiver
Sensor node
Figuur 2.1: Topologie van het sensor netwerk.
2 Bestaande software
5
De figuur laat duidelijk zien dat het hier gaat om unidirectionele communicatie. De 15 sensor nodes doen dus niets anders dan de data van hun sensoren inlezen en verzenden naar de ontvangstnode. Om de communicatie in goede banen te leiden is er uiteraard nood aan een soort “communicatie schema”. De meest voor de hand liggende keuze is een vorm van TDMA, waarbij de sensor nodes elk om beurt een tijdslot krijgen toegewezen om hun data te verzenden naar de ontvangstnode. In principe hebben we hiervoor dus maar ´e´en frequentieband nodig (in tegenstelling tot FDMA, waar we er 15 zouden gebruiken), wat de hardware niet onnodig complex maakt. Een ander groot voordeel van TDMA is dat een node (in het bijzonder de transceiver) niet continu actief moet zijn. De transceiver moet enkel aangeschakeld worden tijdens het toegewezen tijdslot. Dan zal de node zijn data verzenden en kan hij vervolgens weer overgaan in slaapmode. Dit kan het vermogenverbruik enorm reduceren! Zoals daarnet reeds vermeld werd, zullen de nodes niet naar elkaar luisteren (het betreft immers unidirectionele communicatie). Natuurlijk zal een dergelijk communicatie schema enkel correct kunnen werken als alle nodes perfect gesynchroniseerd zijn. Ze moeten exact weten wanneer hun tijdslot voorkomt en mogen enkel dan zenden. Als dit niet het geval is zullen er problemen optreden doordat verschillende nodes tegelijk op dezelfde frequentie uitzenden. Om toch enige vorm van synchronisatie te voorzien, wordt ´e´en van de sensor nodes aangeduid als master, alle andere nodes zijn slaves. Deze master mag niet gezien worden als een compleet andere node! Hardwarematig is de node exact dezelfde en zijn functie is eveneens gelijk aan die van de andere sensor nodes, namelijk sensor data uitlezen en verzenden naar de centrale ontvangstnode. De vraag is nu hoe deze master node dan kan gebruikt worden om het netwerk te synchroniseren . . . Om te beginnen moet figuur 2.1 worden aangepast. E´en van de sensor nodes vervult nu namelijk een speciale rol, de master. De aangepaste topologie is te zien in figuur 2.2.
Receiver Slave
Master
Figuur 2.2: Aangepaste topologie van het sensor netwerk.
2 Bestaande software
6
Het belangrijkste verschil tussen master en slaves zit in de synchronisatie. Normaal wordt in een TDMA-schema maar ´e´en frequentie gebruikt, maar hier hebben we dus een master kanaal en een slave kanaal. De master doet in feite niets anders dan een data pakket verzenden om de 10 ms (100 samples/s). Hij houdt hierbij geen rekening met de slaves, maar gebruikt gewoon een interne klok die telkens een interrupt genereert om de 10 ms, waarop hij zijn data verzendt. De slaves zullen, in tegenstelling tot de master, niet autonoom verzenden. Ze wachten telkens op het masterpakket (ieder eerste tijdslot van een frame, voor het gemak aangeduid als tijdslotnummer nul) om te detecteren wanneer een nieuw frame begint. De slaves zijn niet ge¨ınteresseerd in de data die in het pakket zit, maar enkel in het tijdstip waarop het pakket aankomt! Als een masterpakket gedetecteerd wordt, zal de slave zijn transceiver configureren voor verzending in het slave kanaal. De slave moet nu enkel nog wachten tot zijn tijdslot voorkomt. Dit doet hij uiteraard wel met een interne klok. Het principe van dit protocol is te zien in figuur 2.3. Timeslot 0
Timeslot 1
Timeslot 2
…
Timeslot n-1
Timeslot n
Slave 1
Slave 2
…
Slave n-1
Slave n
Timeslot 0
Timeslot 1
Timeslot 2
…
Timeslot n-1
Timeslot n
Slave 1
Slave 2
…
Slave n-1
Slave n
Timeslot 0
[Channel] Master channel
Master
Slave channel
0 ms
Master
Master
10 ms
20 ms
[t]
Figuur 2.3: Principe van het communicatieprotocol.
De figuur toont duidelijk dat de master een eigen kanaal heeft, dat verschilt van het slave kanaal. Verder is te zien dat iedere node (zowel master als slaves) om de 10 ms een tijdslot krijgt, waarin hij zijn sensor data kan verzenden. De rode pijl van master naar slave 1 verwijst naar de synchronisatie. De slaves verzenden hun data pas nadat ze een masterpakket gedetecteerd hebben. De master is onafhankelijk van andere nodes en regelt zijn eigen timing met behulp van een interne klok. In wat volgt wordt de werking van de verschillende nodes in wat meer detail bekeken.
2 Bestaande software 2.1.1
7
Master sensor node
De werking van de master node kan eenvoudig worden uitgelegd aan de hand van de flowchart uit figuur 2.4.
Initialize
Reset timer
Send data
Wait in LPM until timer = 10 ms
Perform measurement
Figuur 2.4: Flowchart van de master sensor node.
De eerste stap is de initialisatie van de timers, interrupts, SPI,. . . Na deze ´e´enmalige stap komt de master in een oneindige loop terecht, waarbij er elke 10 ms een pakket wordt verzonden. Tussen twee verzendingen in wacht de master in low-power mode. E´en van de timers is zo ingesteld dat hij een interrupt genereert elke 10 ms. In de interrupt routine wordt de master uit de slaapstand gehaald, waarna hij zijn pakket verzendt, een nieuwe meting uitvoert en opnieuw in slaapstand gaat. Merk op dat de timer telkens gereset wordt in het begin van de lus en dat de duur van de slaapmode dus niet 10 ms bedraagt! Opvallend is ook dat het blokje “Send data” voor het blokje “Perform measurement” komt. De data die verzonden wordt is dus telkens afkomstig van de vorige keer dat de lus doorlopen werd. Optimalisatie is op deze manier veel eenvoudiger, want het is niet nodig om te weten hoe lang de meting juist duurt, zolang ze maar minder dan 9 ms in beslag neemt.
2 Bestaande software 2.1.2
8
Slave sensor node
De slave nodes hebben in wezen dezelfde taak als de master, namelijk de sensoren uitlezen en deze data verzenden om de 10 ms. De master node wordt echter gebruikt als referentie. Het eerste tijdslot in een frame is dat van de master. De slaves, die hun data op een ander kanaal verzenden, luisteren eerst op het master kanaal tot het masterpakket gedetecteerd wordt. Daarna gaan ze in slaapmode, tot hun tijdslot begint. Op dat moment wordt de slave gewekt door een interrupt en verzendt hij zijn data op het slave kanaal. Doordat de slaves telkens luisteren op het master kanaal tot de master zijn data verzendt, weet elke slave exact wanneer een nieuw frame begint. De flowchart van zo’n slave is te zien in figuur 2.5.
Initialize
Reset timer
Wait in LPM for RX master data
Wait in LPM for timeslot
Change RF to TX on slave freq.
Send data
Change RF to RX on master freq.
Perform measurement
Figuur 2.5: Flowchart van de slave sensor node.
Het probleem van deze aanpak is dat elke slave twee keer zijn transceiver moet activeren per frame. De eerste keer in ontvangstmode, om het masterpakket te detecteren en een tweede keer om zijn data te verzenden op het slave kanaal. Dit leidt tot een onnodig hoog vermogenverbruik! Een verbeterde versie is te zien in de flowchart van figuur 2.6.
2 Bestaande software
N=0
9
Initialize
Reset timer
Wait in LPM for RX master data
Wait in LPM for timeslot
Change RF to TX on slave freq.
N++
Wait in LPM until timer = 10 ms
Send data
Perform measurement
Change RF to RX on master freq.
N = 256 ?
NO
YES Figuur 2.6: Flowchart van de slave sensor node.
Het grote verschil in deze flowchart is dat de synchronisatie (detectie van een pakket van de master) nu niet elk frame gebeurt. Iedere 256 frames wordt een slave gesynchroniseerd met de master, daartussen werkt hij volledig autonoom. Bij deze manier van werken wordt vertrouwd op de precisie van de lokale oscillator. Doordat deze oscillator wordt gestuurd door een zeer precies “watch crystal” (20 ppm) is deze werkwijze aanvaardbaar. Nu moet elke slave maar ´e´en keer om de 256 frames synchroniseren, waardoor hij bij de overige 255 frames zijn transceiver maar ´e´en keer moet activeren. Tijdens deze 255 autonome tijdslots bevindt de slave zich in een lus die zeer gelijkaardig is aan die van de master node. Er zijn echter twee verschillen: De lus is eindig (wordt 255 keer doorlopen) ´en er is ´e´en extra blokje te zien in de lus, namelijk “wait in low-power mode for timeslot”. Dit blokje geeft aan dat een slave moet wachten op zijn eigen tijdslot vooraleer hij mag verzenden.
2 Bestaande software 2.1.3
10
Ontvanger
Een derde belangrijk onderdeel in het netwerk is de ontvangstnode. Deze node staat centraal in het netwerk en ontvangt de data van alle sensor nodes, zowel slaves als master dus. De werking van deze node is relatief eenvoudig en is te zien in figuur 2.7.
Initialize
Read out data
Wait in LPM for RX master data
Change RF to RX on slave freq.
Reset timer
Wait in LPM for RX slavedata
Change RF to RX on master freq.
Read out data
Interrupt when timer = 9.5 ms
Figuur 2.7: Flowchart van de receiver node.
Zoals dat ook het geval is bij de andere nodes begint de ontvanger met een initialisatie stap. Daarna zal hij op het master kanaal luisteren tot er een pakket wordt ontvangen. Nadat het pakket ontvangen is, wordt de interne timer gereset. Deze timer zal 9.5 ms later een interrupt genereren. Het ontvangen pakket wordt vervolgens doorgegeven aan de PC via UART. Daarna zal de ontvanger zijn transceiver instellen voor ontvangst op het slave kanaal. Hij blijft slavepakketten ontvangen tot de interrupt wordt gegenereerd (na 9.5 ms). Op dat moment weet de ontvanger dat hij terug moet omschakelen naar ontvangst op het master kanaal, omdat het volgende pakket van de master even later toekomt. In de flowchart is de verzending van de data niet expliciet weergegeven. In principe gebeurt de verzending in het blokje “Read out data”. De datapakketten worden dus ontvangen en meteen doorgestuurd naar de PC. De tijd die nodig is voor deze verzending bepaalt dus de duur van een tijdslot! De tijdslots werden zodanig gekozen dat de ontvanger n´et de tijd heeft om de data door te sturen voordat een nieuw datapakket toekomt.
2 Bestaande software
2.2
11
Tekortkomingen
Hoewel het voorgaande protocol behoorlijk blijkt te werken vertoont het toch een aantal tekortkomingen. Eerst en vooral is het aantal nodes beperkt tot 10. Dit is te wijten aan de vertragingen die verkregen worden doordat de transceiver telkens moet opstarten. Figuur 2.8 toont het stroomverbruik van een sensor node tijdens het verzenden van pakketten.
Figuur 2.8: Stroomverbruik van een sensor node tijdens verzenden.
De figuur toont een duidelijke piek van ongeveer 0.7 ms, die kan toegeschreven worden aan de transceiver. Deze component is namelijk een grote stroomverbruiker in dit systeem en moet dus zo veel mogelijk in low-power mode gezet worden! Anderzijds is het net door het gebruik van de low-power mode dat het 0.7 ms duurt om een pakket van 88 bits te verzenden. Dit betekent dat de effectieve bitrate maar zo’n 125 kbps bedraagt, terwijl de transceiver wel degelijk is ingesteld op een transmissiesnelheid van 250 kbps . . . Dit verlies is eenvoudigweg toe te schrijven aan de vertragingen die ontstaan door de transceiver eerst uit low-power mode te halen vooraleer hij kan verzenden. Tussen de timeslots van de verschillende nodes moet er uiteraard ook een kleine “marge” voorzien worden. Dit is logisch, aangezien de nodes niet perfect gesynchroniseerd zijn en dat er genoeg tijd moet zijn voor de ontvangstmodule om de data te verzenden naar de PC tussen twee tijdslots in! Hierdoor wordt de duur van een tijdslot vastgelegd op 1 ms. Doordat er 100 samples per seconde moeten worden verzonden is het duidelijk dat er niet meer dan 10 nodes in het netwerk kunnen opereren. Zoals gezegd in het begin van dit hoofdstuk is er nood aan 15 sensor nodes om de menselijke houding te kunnen reconstrueren. Het grootste probleem is echter dat het netwerk volledig statisch is. De timeslots zijn hardgecodeerd in de software en ook de master node wordt vooraf vastgelegd. Dit wil zeggen dat de code van de master en de slaves verschillend is. Indien de master om een of andere reden wegvalt, zullen de slaves gewoon blijven wachten op een synchronisatie pakket en dus valt het hele netwerk in elkaar. Er is dus nood aan een dynamisch protocol, waar elke node zowel master als slave kan zijn en waar een slave de rol van master kan overnemen als deze wegvalt. Deze tekortkomingen worden aangepakt in de volgende versies van de software.
3 Eerste versie
3
12
Eerste versie
Het belangrijkste probleem met de bestaande versie was het statisch karakter van het protocol. In de eerste versie was het dan ook de bedoeling om de code uit te breiden, zodanig dat het netwerk volledig dynamisch is. In een dynamisch protocol moet elke node in staat zijn om: zowel master als slave te zijn automatisch een keuze te maken tussen master of slave operatie bij opstart automatisch te detecteren welke tijdslots nog beschikbaar zijn en zichzelf kunnen configureren om ´e´en zo’n vrij tijdslot te gebruiken de rol van master op zich te nemen als de master wegvalt
Een eerste belangrijke toevoeging is de automatische configuratie van een node bij opstart. Als een sensor node opgestart wordt is het nog niet bepaald of hij master of slave is (in tegenstelling tot de bestaande software). Een node zal daarom eerst een soort scan doen om te controleren of er al een master aanwezig is in het netwerk of niet. Dit gebeurt simpelweg door de transceiver van de node in te stellen op ontvangst op het master kanaal. Op dat moment wordt er eveneens een timer gestart, die een interrupt genereert na 50 ms. Als er een master aanwezig is, zou hij binnen deze periode vijf pakketten moeten ontvangen van deze master. Theoretisch is het dus voldoende om deze scan periode te beperken tot 10 ms, maar een veiligheidsmarge is hier zeker aan te raden. Dit is om tegen te gaan dat verschillende nodes master zouden worden als de communicatie bijvoorbeeld even zou verstoord worden waardoor een pakket niet ontvangen wordt. Als er geen pakket ontvangen is tijdens deze 50 ms, dan beslist de node dat hij de rol van master op zich zal nemen. Hij configureert zichzelf als master en begint sensor data te verzenden op het master kanaal. Als er wel een masterpakket gedetecteerd wordt weet de node dat hij slave moet worden. Wat hij echter nog niet weet is welke slaves er reeds aanwezig zijn in het netwerk en dus welke tijdslots er nog beschikbaar zijn! Om dit te achterhalen zal de node nu (enkel in het geval hij slave wordt) een tweede scan doen. Dit keer wordt de transceiver ingesteld op ontvangstmode in het slave kanaal. De node maakt een eenvoudige lijst op die aangeeft welke tijdslots er reeds bezet zijn. Na afloop van de slave scan weet de node dus welke tijdslots er nog beschikbaar zijn. Hij configureert zichzelf vervolgens als slave en gebruikt het tijdslot met het kleinste rangnummer. Dat hij altijd het kleinste rangnummer kiest is een voor de hand liggende keuze. Dit zorgt ervoor dat de slave die het eerst actief wordt het eerste tijdslot inneemt, de volgende slave die actief wordt neemt het tweede tijdslot in,. . . Deze initialisatie procedure is te zien in figuur 2.9.
3 Eerste versie
13
Initialize
Listen on master channel
NO
Master detected?
YES Listen on slave channel: detect all used timeslots
Become master
Become slave, use free timeslot
Figuur 2.9: Initialisatie procedure van de sensor nodes.
De werking van een master node is principieel dezelfde als die van de bestaande versie (zie figuur 2.4). De slaves moeten in het dynamisch protocol echter in staat zijn om het falen van de master op te merken en te zorgen dat er exact ´e´en slave de rol van master overneemt. De aangepaste flowchart voor de slaves is te zien in figuur 2.10
Initialize
N=0
Timer interrupt
Wait in LPM for RX master data
Reset timer
Start timer with interrupt after (52+timeslot*20) ms
Wait in LPM for timeslot
Wake-up source ?
Master data Become master
N++
Wait in LPM until timer = 10 ms
Send data
Perform measurement
Change RF to TX on slave freq.
Change RF to RX on master freq.
N = 256 ?
YES
Figuur 2.10: Flowchart van de slaves.
NO
3 Eerste versie
14
Het rode kader toont de toegevoegde blokken tegenover het bestaande protocol. In de bestaande software wachten de slaves gewoon in low-power mode op een masterpakket. Ze konden enkel uit de slaapmodus gehaald worden door ontvangst van zo’n masterpakket, wat dus ook betekende dat ze bleven wachten als er geen master aanwezig was in het netwerk. In het dynamisch netwerkprotocol is er een tweede interrupt bron toegevoegd. Deze extra interrupt wordt gestuurd door een timer, waarvan de periode afhankelijk is van het tijdslot welke de slave gebruikt. Concreet zal de timer een interrupt genereren na “52 ms + 20*timeslot ms”. De verdere werking van de slave is nu afhankelijk van welke interrupt het eerst optreedt. Als de slave uit slaapstand wordt gehaald door de ontvangst van een masterpakket, dan is er niets aan de hand en is de master nog steeds online. De slave gaat gewoon door met zijn normale werking en verzendt 255 autonome pakketten. Stel dat de slave uit slaapstand wordt gehaald door de timer interrupt, dan wil dat zeggen dat er al 52 ms + 20*timeslot ms geen masterpakket is gedetecteerd. De slave kan nu veronderstellen dat de master weggevallen is en hij neemt de rol van de master over. De periode vooraleer de timer een interrupt genereert is dus afhankelijk van het tijdslot. Op die manier wordt voorkomen dat meerdere slaves op hetzelfde moment opmerken dat de master weggevallen is. Dit zou leiden tot een conflictsituatie, waarbij er opeens meerdere masters in het netwerk aanwezig zouden zijn. Daar de code exact hetzelfde is voor alle nodes, leek het gebruik van het tijdslotnummer een ideale keuze om te garanderen dat de interrupt van meerdere slaves nooit op hetzelfde moment kan gebeuren. Bovendien blijft de opbouw van het netwerk zeer logisch en voorspelbaar op deze manier. Als de master wegvalt is het altijd de slave die het eerst volgt op de master die zijn rol zal overpakken. In figuur 2.11 is een voorbeeld te zien van een netwerk dat bestaat uit een master, vier slaves en een ontvanger.
M
M 1
4
1 4
R
4
R
2 3
M R
2 3
1
2 3
2
3
1 2
M 4
4
R
4
R
R M
M
2
3
3
3 4
5
Figuur 2.11: Voorbeeld van de arbitrage bij het wegvallen van de master.
6
3 Eerste versie
15
De node met de letter “M” is de master en de cijfers in de groene bollen (de slaves) geven het nummer aan van het tijdslot van die slave. In de eerste stap zijn alle nodes actief. In de tweede stap valt de master weg (aangeduid met het zwarte kruis). De slave met rangnummer 1 is de eerste die opmerkt dat de master weggevallen is en wordt dus master. Als de nieuwe master ook wegvalt zal slave 2 master worden . . . De slave die het eerst opmerkt dat de master offline is, heeft dus 20 ms de tijd om zichzelf te configureren als master en zijn eerste masterpakket te verzenden. De andere slaves weten dus in principe niet dat de master nu een andere node is, maar dat hoeft ook niet. Stel dat de twee nodes die weggevallen zijn terug online komen, dan zullen ze opnieuw de initialisatie procedure doorlopen (figuur 2.9). Ze merken op dat er reeds een master aanwezig is in het netwerk en scannen het slave kanaal af op vrije tijdslots. Doordat slave 1 master geworden is in stap 3 is tijdslot 1 dus vrijgekomen. Hetzelfde geldt voor tijdslot 2 in stap 5. De twee nodes zullen dus deze twee tijdslots gebruiken en zo komt de situatie van stap 6 tot stand.
4 Tweede versie
4
16
Tweede versie
De uitbreidingen in de eerste versie hadden betrekking op het dynamisch maken van het protocol. In de tweede versie lag de focus op de uitbreiding naar 15 nodes. Zoals reeds werd uitgelegd is de beperking tot 10 nodes te wijten aan de vertragingen die ontstaan door telkens de modules te moeten opstarten (uit slaapmode halen) voordat er kan verzonden worden. Dit beperkt de effectieve datarate tot 88 kbps, terwijl er nood is aan 132 kbps. De vraag is nu hoe we meer nodes kunnen opnemen in het netwerk (of met andere woorden, hoe kan de effectieve datarate verhoogd worden) zonder het vermogenverbruik van de nodes aan te tasten. De slaapmodes minder of niet benutten is dus geen optie! Een elegante oplossing is om een tweede slave kanaal in gebruik te nemen. Het idee is om de voorgaande versie uit te breiden naar twee slave kanalen, zodanig dat er nog negen extra nodes opgenomen kunnen worden. Wat de slaves betreft is dit geen enkel probleem. Het aantal slave kanalen is in principe onbeperkt voor de slaves, aangezien de slaves enkel verzenden en dus niet moeten luisteren naar andere slaves. Het probleem zit hem echter aan de ontvangstzijde. . . Als er meerdere kanalen gebruikt worden moet de ontvanger in staat zijn om meerdere frequenties in parallel te ontvangen. De gebruikte transceiver, de nRF2401A, is uitgerust met twee min of meer onafhankelijke receivers. Dat wil zeggen dat de transceiver tegelijkertijd data op twee kanalen kan ontvangen. De ontvangen data komt terecht in twee aparte ontvangstbuffers en de uitlezing door de microcontroller gebeurt ook via twee aparte SPI-interfaces. De communicatie met twee slave kanalen is te zien is figuur 2.12.
[Channel] Master channel
Master
Master
Master
Slave channel 1
Slave 1
Slave 2
…
Slave 8
Slave 9
Slave 1
Slave 2
…
Slave 8
Slave 9
Slave channel 2
Slave 10
Slave 11
…
Slave 17
Slave 18
Slave 10
Slave 11
…
Slave 17
Slave 18
0 ms
10 ms
20 ms
[t]
Figuur 2.12: Principe van het communicatieprotocol met twee slave kanalen.
Zoals de figuur laat zien, zenden er telkens (indien het netwerk zijn volledige capaciteit benut) twee slaves in parallel. Buiten het feit dat de slaves met nummers 10 tot en met 18 een andere frequentieband gebruiken, is hun werking exact dezelfde. Dit wil zeggen dat die slaves ook op dezelfde master synchroniseren. Uiteraard is er ook een kleine uitbreiding nodig voor de intitialisatieprocedure. De nodes zullen bij opstart eerst luisteren op slave kanaal ´e´en (als er een master aanwezig is). Als ze zien dat de tijdslots met nummers ´e´en tot en met negen allemaal in gebruik zijn, dan weet de node dat het kanaal volledig bezet is. In dat geval herhaalt hij de slavescan-procedure, maar deze keer op slave kanaal twee. Principieel verandert er dus niets, buiten het feit dat er nu twee kanalen zijn en dat de tijdslots nu doorlopen tot nummer 18 in plaats van 9.
5 Receiver
5
17
Receiver
De software voor de receiver wordt bewust in een apart deeltje besproken, omdat deze eigenlijk “los” staat van de code van de sensor nodes. Deze node staat centraal in het netwerk en ontvangt de data van alle sensor nodes. Hij geeft die data via ´e´en of andere interface door aan de PC voor visualisatie en verdere verwerking. Het is dus duidelijk dat de ontvangstnode de schakel vormt tussen het sensor netwerk en de PC en een niet te onderschatten rol speelt in het geheel. Als deze node niet naar behoren functioneert gaat alle data van de sensor nodes verloren, zelfs al werken die nodes perfect. Eigenlijk verandert er niet zo veel aan de flowchart van de ontvangstnode. Dat wil echter niet zeggen dat de software hetzelfde blijft! De taak van de ontvanger blijft gewoon data ontvangen van het netwerk en deze doorgeven aan de PC. De ontvangstnode zal nu data op twee parallelle kanalen ontvangen, wat moeilijk weer te geven is op de flowchart. . . Figuur 2.13 toont de aangepaste versie van de flowchart. Het verschil is dat er nu drie interfaces zijn tussen de ontvangstnode en de PC, terwijl er bij de eerste ontvanger slechts via USB gecommuniceerd kon worden.
Initialize
Read out data
Wait in LPM for RX master data
Change RF to duo-RX on slave frequencies
Reset timer
Wait in LPM for RX slavedata
Read out data Interrupt when timer = 7.5 ms
USB
Interface?
BT
UDP Send USB packet
Send UDP packet
Send BT packet
Change RF to RX on master freq.
Figuur 2.13: Flowchart van de ontvangstnode.
Merk op dat de timer interrupt nu staat ingesteld op 7.5 ms, in plaats van 9.5 ms! Dit is nodig omdat alle datapakketten nu in ´e´en groot pakket naar de PC worden verzonden, terwijl de vorige versie telkens een pakket ontving en dit meteen doorstuurde naar de PC. Dit wordt in detail uitgelegd in hoofdstuk 4, sectie 1.2.
HARDWARE
18
Hoofdstuk 3
Hardware In dit hoofdstuk wordt er specifiek gesproken over de hardware. Hierbij komen zowel de pcb’s van de sensor node en de ontvangstnode aan bod, maar ook de componenten zelf worden besproken. De sensor node werd reeds ontworpen door Benoˆıt Huyghe, maar het ontwerp van de ontvangstnode was wel een onderdeel van deze thesis. Om die reden wordt er toch iets dieper ingegaan op deze module. Omdat een aantal componenten dezelfde zijn voor de twee nodes worden alle componenten samen besproken.
1
sensor node
Zoals reeds werd aangehaald in het hoofdstuk over het netwerkprotocol (Hoofdstuk 2), is er hardwarematig geen verschil tussen de master en de slaves. In dit hoofdstuk wordt er dan ook geen onderscheid gemaakt tussen deze twee en wordt er gewoon gesproken over sensor nodes. Deze sensor nodes zijn voorzien van twee types sensoren, een accelerometer en een magnetometer. Met behulp van een 3D-accelerometer kan de zwaartekracht worden gemeten in de drie hoofdrichtingen. Figuur 3.1 toont de ori¨entatie van de drie richtingen.
Figuur 3.1: 3 hoofdrichtingen van de accelerometer.
1 sensor node
19
Zoals de figuur duidelijk laat zien liggen de x- en de y-as evenwijdig met het aardoppervlak (in de veronderstelling dat de sensor effectief zo gemonteerd is). De rotatie rond de x- en de y-as zijn dus eenvoudig te bepalen. Voor het bepalen van de rotatie rond de z-as treedt er wel een probleem op. Als de chip evenwijdig blijft met het aardoppervlak en hij draait rond de z-as, dan zal de gravitatiekracht van de drie assen onveranderd blijven en kunnen we dus onmogelijk de rotatie rond de z-as in kaart brengen. Om dit probleem op te lossen wordt een tweede sensor ge¨ıntroduceerd, de magnetometer. Deze sensor geeft informatie over de richting van het noorden. Als de magnetometer dus eveneens zijn z-as loodrecht op het aardoppervlak heeft staan, kan de output van de magnetometer gebruikt worden om de rotatie rond de z-as te bepalen. Het probleem van deze aanpak is dat de accelerometer niet enkel de gravitatiekracht meet, maar eveneens alle andere versnellingen waaraan de component onderhevig is [13]. Hierdoor kan de rotatie dus niet nauwkeurig berekend worden als er beweging wordt ge¨ıntroduceerd. De magnetometer heeft dan weer het probleem dat de meting kan verstoord worden door de aanwezigheid van magneten of magnetische materialen [14]. Om deze problemen op te lossen is er in principe een derde sensor nodig, een gyroscoop. Omdat de sensor nodes geen gyroscoop gebruiken wordt er dan ook niet dieper op ingegaan.
1.1
Specificaties van de sensor node
Om een verantwoorde keuze te kunnen maken voor de componenten van de sensor node is het belangrijk om de eisen en specificaties op een rijtje te zetten. Belangrijke eigenschappen van deze node zijn: Minimaal vermogenverbruik! Zo klein mogelijk. Minstens 100 samples/s. 2.4 GHz transceiver ´en bijhorende antenne. Microcontroller met voldoende interfaces voor de uitlezing van de sensoren en genoeg rekenkracht (snelheid) om te voldoen aan de vereisten.
Impliciete randvoorwaarden zijn natuurlijk een minimale kostprijs, vlot leverbare componenten, betaalbare ontwikkeltools. . . Deze voorwaarden zijn echter niet enkel van toepassing op dit ontwerp, maar spelen veelal een rol.
1 sensor node
1.2
20
Schema en layout
Een blokschema van de sensor node is te zien in figuur 3.2. De twee sensoren zijn beiden verbonden met de MCU door middel van een I2 C-bus. De transceiver wordt aangestuurd met SPI. De werking van SPI en I2 C worden besproken in Appendix A.
Magnetometer Accelerometer
I²C
MCU
SPI
2.4 GHz transceiver
Figuur 3.2: Blokschema van de sensor node.
Het circuit (Benoˆıt Huyghe) van de sensor node is te zien in figuur 3.3. Doordat zowel de sensoren als de transceiver zeer weinig randcomponenten nodig hebben, is het schema redelijk eenvoudig. Alle componenten worden gevoed door de 3 V voedingsregelaar. De gebruikte regelaar is de MCP1700, een low dropout regelaar. De layout van de sensor node is te zien in figuur 3.4.
1 sensor node
21
Figuur 3.3: Schema van de sensor node.
Links van de microcontroller (figuur 3.3) is de JTAG-connector te zien. Deze JTAG-interface wordt gebruikt om de controllers te programmeren en te debuggen. Zoals te zien is in de figuur is de connector rechtstreeks verbonden met de JTAG-pinnen van de MCU, zonder enige randcomponenten.
1 sensor node
22
Figuur 3.4: Layout van de sensor node.
Het uiteindelijke resultaat is de sensor node die te zien is in figuur 3.5. Op de figuur zijn ook de afmetingen van de sensor node weergegeven. Deze node meet amper 2.4 op 5.5 cm.
5.5 cm
2.4 cm
Figuur 3.5: PCB van een sensor node.
2 Ontvangstnode
2 2.1
23
Ontvangstnode Specificaties van de ontvangstnode
De ontvangstnode is de centrale node in het netwerk. Het is deze node die alle data verzamelt van de verschillende sensor nodes en deze data vervolgens doorzendt naar de PC. Dit werd reeds uitgelegd in een voorgaand hoofdstuk, maar wordt hier even kort herhaald. Wel wordt nu uiteraard de nadruk gelegd op de hardware. Figuur 3.6 toont nogmaals de voorstelling van het netwerk, inclusief de koppeling met de PC.
Receiver Slave
Master
Figuur 3.6: Algemene netwerk topologie.
Het sensor netwerk heeft een stertopologie, waarbij de ontvangstnode de centrale schakel is. Dat de pijlen maar in ´e´en richting wijzen benadrukt dat het gaat om unidirectionele communicatie. Strikt gezien zullen de slave nodes ook soms werken in ontvangstmode, maar dit heeft alleen te maken met synchronisatie. Door de unidirectionaliteit moet de ontvangstnode geen data of informatie verzenden naar de nodes. Hij verzendt uiteraard w´el data naar de PC, maar de interface tussen de ontvangstnode en de PC staat volledig los van de interface tussen de ontvanger en het sensor netwerk. In het begin van het project lag de focus voornamelijk op het protocol voor de sensor nodes. Daar er nog geen speciale hardware ontwikkeld was voor de ontvangstnode, werd er gewerkt met een testbordje (zie figuur 3.7).
2 Ontvangstnode
24
Figuur 3.7: Testbord dat gebruikt werd als ontvangstnode in de eerste fase van het project.
Dit testbord is uitgerust met dezelfde transceiver als de sensor nodes. De koppeling met de PC gebeurt door middel van USB. Het is echter de bedoeling dat het systeem wordt uitgebreid, zodat er meerdere personen te volgen zijn op dezelfde PC. Dit is onmogelijk met het huidige systeem, tenzij we de ontvangstnode aanpassen. In het begin van het project was het zo dat de sensor nodes op de persoon aanwezig zijn, maar de ontvangstnode niet. De ontvanger bevond zich bij de PC. Het is natuurlijk mogelijk om verschillende van deze ontvangstnodes aan de PC te hangen, elk op een andere USB-poort, maar dat is allerminst een elegante oplossing! Een betere aanpak is om ervoor te zorgen dat alle personen kunnen worden ontvangen op ´e´en interface van de PC. Dit kan verwezenlijkt worden door de ontvangstnode effectief te zien als een deel van het sensor netwerk. De rol van deze node blijft exact hetzelfde, alleen is de ontvanger nu ook aanwezig op de persoon zelf en wordt de point-to-point verbinding van de ontvangstnode naar de PC (de USB-verbinding) vervangen door een tweede netwerk. De ontvangstnode is dus gewoon een tussenschakel met twee interfaces (op twee verschillende netwerken), die data van het ene netwerk naar het andere doorgeeft. Nu is de vraag welk netwerkprotocol gebruikt wordt voor de koppeling tussen de ontvangstnode en de PC. . . Omdat de ontvanger nu ook op de persoon aanwezig is moet het ook een draadloos protocol zijn. Bovendien moet de datarate voldoende groot zijn, zodat er wel degelijk meerdere personen opgenomen kunnen worden in het netwerk! Natuurlijk moet er nog steeds rekening gehouden worden met het vermogenverbruik, daar de ontvangstnode nu eveneens batterijgevoed is. Verder zou het ook een groot voordeel zijn moest er geen speciale hardware nodig zijn op de PC zelf. Rekening houdende met dit laatste puntje lijkt het kiezen tussen WiFi en Bluetooth. De keuze is gevallen op Bluetooth. Niet alleen is het een eenvoudiger en goedkoper
2 Ontvangstnode
25
protocol, het is ook meer geschikt voor draadloze sensor netwerken omdat het vermogenverbruik een stuk lager ligt dan bij WiFi. Figuur 3.8 toont de uitbreiding van het netwerk naar meerdere (in de figuur twee) personen.
Receiver Slave Master
Persoon 1
Persoon 2
Figuur 3.8: Netwerktopologie voor het traceren van meerdere personen.
In dit netwerk kan iedere persoon dus gezien worden als een subnetwerk. De verschillende subnetwerken worden allemaal met dezelfde PC verbonden via Bluetooth. Om het geheel eenvoudiger te testen en om de ontvangstnode zo algemeen mogelijk te maken werd geopteerd om naast Bluetooth nog steeds een USB-connectie te voorzien. Bovendien werd ook een Ethernet-interface voorzien. Er zijn dus verschillende mogelijkheden om het netwerk met een PC te verbinden. Dit wordt voorgesteld door het eenvoudig blokschema in figuur 3.9. USB
Sensor node Sensor node …
Ontvangstnode
Ethernet
PC
Sensor node Sensor node
Bluetooth
Figuur 3.9: Eenvoudig blokschema van het netwerk en de verschillende interfaces van de ontvangstnode.
In deze voorstelling wordt nogmaals benadrukt dat de ontvangstnode een soort tussenschakel is tussen het netwerk en de PC. Links in de figuur hebben we een aantal sensor nodes, die hun data (blauwe pijlen) verzenden naar de ontvangstnode. Die kan dan via ´e´en of meerdere interfaces worden verbonden met de PC om deze data door te zenden.
2 Ontvangstnode
2.2
26
Schema en layout
Een blokschematische voorstelling van de ontvangstnode is te zien in figuur 3.10. Op de figuur zijn alle belangrijke blokken weergegeven en ook welke interfaces gebruikt worden om de verschillende componenten te verbinden. Tussen de MCU en de transceiver zijn nu twee SPIverbindingen te zien, omdat de ontvangstnode gebruik maakt van de zogenaamde DuoCeiver (zie 3.2.4). Tussen de MCU en de PC zijn drie verschillende communicatiemogelijkheden. Net zoals bij het testbordje, die als voorlopige receiver gebruikt werd, is er een UART-USB brug aanwezig, zodat communicatie via USB mogelijk is. Daarnaast is nu ook een Ethernet-chip en een Bluetooth module aanwezig. Om al deze componenten aan te sturen zijn er twee UARTinterfaces en drie SPI-interfaces nodig, terwijl de MCU maar vier communicatie-interfaces aan boord heeft. Vandaar dat de twee UART-interfaces gecombineerd worden en zodoende moet de gebruiker hardwarematig kiezen tussen Bluetooth of USB middels een schakelaar op het bordje.
Ethernet
Ethernet-chip
SPI
SPI
PC
USB
Bluetooth
UART-USB bridge
UART
Bluetooth module RN-41
UART
MCU
SPI
2.4 GHz transceiver
Figuur 3.10: Blokschema van de sensor node.
Het elektrisch schema is te zien in figuur 3.11. De blokken uit figuur 3.10 zijn eenvoudig te identificeren. De twee schakelaars rechts van de microcontroller zorgen voor de keuze tussen Bluetooth en USB. De ene schakelaar werkt in principe als een demultiplexer en verbindt de UART-pinnen van de MCU met ´e´en van de twee chips. De andere switch is verbonden met een interrupt-pin van de MCU en zorgt ervoor dat de MCU op de hoogte is van de huidige keuze (USB of BT), zodat de juiste data kan worden verzonden over de UART. Als deze laatste switch wordt weggelaten, zou de keuze niet “on-the-fly” kunnen gewijzigd worden, maar zou de MCU telkens geherprogrammeerd moeten worden . . .
2 Ontvangstnode
27
Figuur 3.11: Schema van de ontvangstnode.
2 Ontvangstnode
28
De layout van de ontvangstnode is te zien in figuur 3.12. Deze figuur is sterk vergroot, want de print meet ongeveer 5.8 cm op 7.1 cm.
Figuur 3.12: Layout van de ontvangstnode.
Doordat er twee 2.4 GHz transceivers aanwezig zijn op de print, moest deze zeer zorgvuldig ontworpen worden! De Bluetooth module is helemaal links geplaatst op de print, terwijl de antenne van de nRF2401 helemaal rechts gepositioneerd werd. Verder is getracht om zoveel mogelijk ongebruikte plaats aan de bovenzijde van de pcb op te vullen met grondvlak. De onderkant van de print werd vooral gebruikt als VCC-vlak, uitgezonderd onder de nRF2401transceiver, de RN-41 (Bluetooth module) en de antenne. Het voedingsgedeelte is rechts onderaan te zien in de figuur, met daarnaast de relatief grote MAG-Jack Ethernet connector. Links onderaan zijn een aantal testpinnen aanwezig. Deze maken het mogelijk om enkele signalen gemakkelijk te kunnen uitmeten, want door de minimale afmetingen van de PCB zou het behoorlijk lastig zijn om deze signalen te meten. De microcontroller is het centrale element, dat gekoppeld is met alle andere componenten. Om deze reden is de MCU ook redelijk centraal geplaatst op de print. De andere componenten werden rond deze MCU geplaatst, waarbij getracht werd om de lengte van de interconnecties zo klein mogelijk te houden.
3 Componenten
3
29
Componenten
E´en onderdeel van het ontwerpen van een pcb is de keuze van de componenten. Hier worden de belangrijkste componenten van de sensor module en de ontvangstmodule besproken en waarom ze ideaal zijn voor deze toepassing. De transceiver, de microcontroller en de voedingsregelaar zijn gelijk voor de twee nodes. De accelerometer en de magnetometer zijn uiteraard enkel aanwezig op de sensor node. De UART-USB brug, de Bluetooth-module en de Ethernet-chip zijn dan weer te vinden op de ontvangstmodule en niet op de sensor nodes. . .
3.1
Microcontroller
De microcontroller is een zeer belangrijke component in deze (en veel andere) applicatie(s). Niet alleen zorgt de MCU voor de aansturing van alle periferie (uitlezing van de de sensoren, sturen van de transceiver,. . . ), het is ook veelal een grote verbruiker. Daarom is het van belang dat een goede keuze wordt gemaakt voor de microcontroller. Er wordt dus een lowpower MCU gezocht, die toch voldoende I/O heeft en een aanvaardbare rekenkracht biedt. De component moet ook zeer eenvoudig te programmeren zijn (geen speciale hardware of dure software nodig). Al deze wensen in beschouwing genomen, viel de keuze op de MSP430F249 van Texas Instruments [15]. MSP430 staat voor een reeks microprocessoren die omschreven worden als ultralow-power MCU’s. Het betreft een 16-bit RISC mixed-signal processor (MSP) architectuur. Deze kenmerken maken deze processor-familie zeer interessant voor batterijgevoede applicaties! Bovendien is er een zeer breed gamma binnen de MSP430-familie. De MSP430x2xx serie kan werken met kloksnelheden tot 16 MHz, maar garandeert nog steeds een zeer laag vermogenverbruik.
Figuur 3.13: TI MSP430F249
De MSP430F249 kan gevoed worden met spanningen tussen 1.8 V en 3.6 V. Deze lage voedingsspanning is eveneens compatibel met de andere gebruikte componenten (zie verder) en verlaagt uiteraard het vermogenverbruik. Zoals algemeen bekend is, is het dynamisch vermogenverbruik evenredig met de kwadratische voedingsspanning! Anderzijds is dit vermogenverbruik ook evenredig met de klokfrequentie, waardoor men er alle baat bij heeft deze frequentie zo laag mogelijk te kiezen (uiteraard snel genoeg om de vereiste performantie te bieden). Er werd gekozen voor 3 V voedingsspanning en een klokfrequentie van 1 MHz. Bij deze waarden is het stroomverbruik in de actieve mode amper 400 µA! In low-power mode kan het stroomverbruik zelfs beperkt worden tot enkele micro-amp`eres. . . Doordat de wake-up tijd zo kort is (minder dan 1 µs) kunnen de slaapmodes ook optimaal gebruikt worden.
3 Componenten 3.1.1
30
Functionaliteit
Voedingsspanning: 1.8 V - 3.6 V Zeer laag vermogenverbruik: ± 400µA in actieve mode/<1µA in slaapmode Zeer snelle wake-up: Wake-up uit slaapmode in minder dan 1µs 16-bit RISC architectuur Klokfrequenties tot 16 MHz Twee 16-bit timers met in totaal 10 capture/compare registers 4 USCI (Universal Serial Communication Interfaces) communicatie interfaces: Ondersteuning voor I2 C, SPI, IrDA en UART
3.1.2
Blokschema
Figuur 3.14 toont een vereenvoudigd blokschema van de MSP430F249. De verschillende onderdelen zijn verbonden met de CPU volgens de von Neumann architectuur. De interconnectie bestaat uit twee bussen, de memory adress bus (MAB) en de memory data bus (MDB), die gedeeld worden door de data en de instructies.
Figuur 3.14: Blokschema van de TI MSP430F249.
3 Componenten
3.2
31
Transceiver
De keuze voor de transceiver is gevallen op de Nordic nRF2401A [16], een 2.4 GHz singlechip transceiver. De nRF2401 is speciaal ontwikkeld voor sensor-applicaties en heeft dan ook enkele grote voordelen voor onze toepassing. De aansturing door de microcontroller gebeurt via SPI, een interface die aanwezig is op de meest gangbare MCU’s en zoals net gezien, ook op de MSP430F249. Tevens voorziet deze transceiver in een shockburst mode, waarbij alle data eerst gebufferd wordt in de chip en dan in ´e´en keer wordt verzonden. Het grote voordeel is dat de transmissiesnelheid van de SPI-verbinding niet bepalend is voor de draadloze transmissiesnelheid! Deze shockburst-mode wordt verder iets meer in detail uitgelegd. Een andere belangrijke functie van de nRF2401 is dat deze beschikt over een zogenaamde DuoCeiver. Zoals de naam doet vermoeden heeft de transceiver twee receivers aan boord, die gelijktijdig op een ander kanaal kunnen ontvangen! Deze functie kan handig gebruikt worden voor het ontvangerbord, zodat het mogelijk is om tot 19 nodes op te nemen in het netwerk. In figuur 3.15 is de nRF2401A te zien. Zoals deze figuur duidelijk aantoont is het een zeer kleine chip. Het is de bedoeling dat de sensor nodes zo klein mogelijk zijn, zodat ze de gebruiker niet hinderen! Daarom zijn de kleine afmetingen, vooral voor de sensor nodes, een pluspunt.
Figuur 3.15: Nordic nRF2401A
3.2.1
Functionaliteit
Voedingsspanning: 1.9 V - 3.6 V Single-chip 2.4 GHz GFSK transceiver Datarate: 0-1 Mbps Zeer weinig randcomponenten 125 kanalen: Switchen tussen kanalen in 200 µs, dus frequencyhopping mogelijk. DuoCeiver: Ontvangst van 2 kanalen mogelijk. Shockburst mode: Laag vermogenverbruik en geen zware eisen voor de MCU. Stroomverbruik in RX: 18 mA Stroomverbruik in TX: 10.5 mA Sensitiviteit RX: -90 dBm
3 Componenten 3.2.2
32
Blokschema
Figuur 3.16 is een eenvoudig blokdiagram van de nRF2401 transceiver. Het is niet de bedoeling om al de onderdelen van dit blokschema te bespreken. Hiervoor wordt verwezen naar de datasheet van de nRF2401A [16]. Het belangrijkste in dit schema zijn de I/O-pinnen, die allemaal aan de linkerkant van het schema getekend zijn.
Figuur 3.16: Eenvoudig blokschema van de Nordic nRF2401 transceiver.
Pin
Functie
Beschrijving
CE
digitale input
Chip Enable: activeert RX/TX-mode
CS
digitale input
Chip Select: activeert configuratie-mode
PWR UP
digitale input
Power Up
DR1
digitale output
Data Ready 1: data ontvangen op kanaal 1
DR2
digitale output
Data Ready 2: data ontvangen op kanaal 2
DATA
digitale I/O
RX/TX datakanaal 1
CLK1
digitale input
Klok voor kanaal 1
DOUT2
digitale output
RX/TX datakanaal 2
CLK2
digitale input
Klok voor kanaal 2
Tabel 3.1: Belangrijkste pinfuncties van de nRF2401.
3 Componenten 3.2.3
33
Shockburst mode
De shockburst mode is ´e´en van de grote voordelen van de nRF2401! Het principe is redelijk eenvoudig. De transceiver beschikt over een verzendbuffer, waar eerst alle data kan worden ingeklokt en pas daarna wordt verzonden. Op die manier is de snelheid van de SPIcommunicatie met de MCU volledig onafhankelijk van de on-air transmissiesnelheid. Het is dus mogelijk om een zeer goedkope microcontroller te gebruiken of gewoon een lage klokfrequentie. Doordat de klokfrequentie bepalend is voor het dynamisch vermogenverbruik zal de MCU minder vermogen verbruiken. Daarnaast is het ook niet noodzakelijk dat de nRF’s front-end continu aangeschakeld is. Hij kan de data eerst binnenklokken en dan heel even de transceiver aanschakelen om de data in de buffer te verzenden aan een hoge snelheid, om vervolgens de transceiver weer uit te schakelen. Doordat de RX/TX-operaties nu eenmaal veel vermogen verbruiken zal een burstverzending een zeer gunstige invloed hebben op het verbruik! Als de nRF2401 ingesteld is op Shockburst mode, dan zal hij ook automatisch de preamble en de CRC toevoegen. Bij ontvangst van data zal hij een signaal geven op de DR-pin (Data Ready pin), die gekoppeld wordt met een interrupt-pin van de MCU. Ook deze functies verlagen het vermogenverbruik enorm, want de MCU moet enkel de data zelf verzenden (geen CRC berekening en toevoegen van preamble. . . ) ´en er wordt een interrupt gegenereerd bij ontvangst van data, zodat hij uit slaapstand kan gehaald worden. Het mag wel duidelijk zijn dat al deze functies samen zorgen voor een veel lager vermogenverbruik. In de praktijk moet elke sensor node ´e´en pakket versturen per 10 ms. Zo’n verzending duurt ongeveer 0.7 ms, zodat de transceiver meer dan 9 ms in standby staat. 3.2.4
DuoCeiver
Het begrip DuoCeiver spreekt voor zich, de nRF2401 beschikt intern over twee receivers. De tweede receiver is niet volledig onafhankelijk, in die zin dat zijn ontvangstfrequentie exact 8 MHz (acht kanalen) hoger is dan de frequentie van de eerste ontvanger. Dit wordt voorgesteld in figuur 3.17.
Figuur 3.17: DuoCeiver operatie van de nRF2401.
Deze functie wordt enkel gebruikt voor de ontvangstnode, zodat er meer dan 10 sensor nodes in het netwerk opgenomen kunnen worden. Zoals reeds gezegd werd, kan enkel gebruik gemaakt worden van de DR-pinnen, als de transceiver ingesteld is in shockburst mode.
3 Componenten
3.3
34
Accelerometer
Wat de accelerometer betreft, werd gekozen voor de LIS302DL van ST Microelectronics [17], een 3D MEMS-sensor met digitale uitlezing. Ook deze component is zeer klein en meet amper 3 op 5 mm. Net zoals de andere componenten betreft het een low-power component. De uitlezing van de sensor gebeurt digitaal via I2 C, waardoor de MCU geen verdere bewerking meer moet doen op de sensor data. Veel sensoren geven namelijk een analoge waarde door aan de MCU, waardoor er nog een AD-omzetting moet gebeuren door de microcontroller. De LIS302DL is te zien in onderstaande figuur.
Figuur 3.18: LIS302DL
3.3.1
Functionaliteit
Voedingsspanning: 2.16 V - 3.6 V Vermogenverbruik: <1 mW Bereik: Dynamisch instelbaar voor ±2g/±8g Interface: Digitale uitlezing met SPI of I2 C Bandbreedte: Instelbaar als 50 Hz of 200 Hz
3.3.2
Blokschema
Figuur 3.19: Blokschema van de LIS302DL
3 Componenten
3.4
35
Magnetometer
De Yamaha YAS529 [18] is de kleinste 3D geomagnetische sensor ter wereld. Hij meet amper 2 x 2 x 1 mm! Figuur 3.20 toont de YAS529 samen met een meetlat, waarop duidelijk te zien is hoe klein deze sensor wel is.
Figuur 3.20: Yamaha YAS529
Net als de accelerometer gebeurt de uitlezing digitaal met het I2 C protocol. Op die manier zijn de twee sensors uit te lezen via dezelfde interface. Hoewel de component wordt aangegeven als low-power is deze chip toch een relatief grote verbruiker. Gelukkig geldt dit grote verbruik enkel tijdens de meting zelf. Tussen twee metingen in verbruikt hij maar 1 µA (mogelijks iets meer, afhankelijk van de temperatuur). 3.4.1
Functionaliteit
Voedingsspanning: 2.5 V - 3.6 V Vermogenverbruik: ≈12 mW Bereik: ± 300 µT Resolutie: ≤ 0.6 µT/count voor X,Y en ≤ 1.2 µT/count voor Z Duur van een meting: ≤ 10 ms Digitale uitlezing: I2 C (100 kbps/400 kbps) Power-down: Mogelijkheid tot automatische power-down na een meting GPO: General Purpose Output pin, kan bijvoorbeeld gebruikt worden om de externe accelerometer in power-down te brengen
3 Componenten 3.4.2
36
Blokschema
Figuur 3.21: Blokschema van de Yamaha YAS529.
In dit schema zijn links de drie magnetische sensoren te zien, samen met de test- en initialisatiespoelen. De initialisatie spoelen zorgen voor een magnetisch veld, waarmee de magnetische sensoren kunnen ge¨ınitialiseerd worden als de originele karakteristieken niet meer voldoen. Dit is het geval als het magnetisch veld zeer hoog is. De testspoelen wekken eveneens een magnetisch veld op en laten toe om de magnetische sensoren op een eenvoudige manier te testen. De uitgang van de sensoren is verbonden met een bufferversterker, die enkel actief is als er een meting gebeurt. Bovenaan zijn er drie analoge ingangen te zien: AIX, AIY en AIZ. Aan deze pinnen kan een externe accelerometer worden verbonden met een analoge uitgang. Op deze manier kan de accelerometer ook gebruik maken van de interne AD-convertor van de YAS529 en kan hij dus digitaal uitgelezen worden. Deze functie wordt niet gebruikt, daar de gekozen accelerometer reeds een digitale uitgang heeft. Onder de bufferversterker is ook nog een temperatuursensor te zien. Deze kan gebruikt worden om de temperatuurskarakteristieken van de magnetische sensoren te corrigeren. Al deze analoge signalen (externe accelerometer, uitgang bufferversterker en temperatuursensor) kunnen geselecteerd worden als ingang voor de interne ADC. Rechts van de ADC is nog wat digitale logica te zien. Het gaat onder andere over de registers, de digitale data-interface en de powerdown-control.
3 Componenten
3.5
37
UART-USB brug
Om de microcontroller van de ontvangstnode te laten communiceren met de PC via een USBverbinding wordt gebruik gemaakt van een UART-USB brug. Op die manier is er geen nood aan een complexe MCU met USB-interface. Uiteraard is de snelheid van deze virtuele USBinterface beperkt, maar de datarate is voldoende voor deze toepassing. De chip die hiervoor gekozen werd is de FT232RL van FTDI chip [19].
Figuur 3.22: FTDI FT232RL UART-USB brug.
3.5.1
Functionaliteit
Voedingsspanning: 3.3 V - 5.25 V (kan m.a.w. gevoed worden door de USB-bus) Vermogenverbruik: ≈ 78 mW Datarate: 300 baud - 3 Mbaud Ontvangstbuffer: 128 byte Verzendbuffer: 256 byte Configureerbare CBUS I/O pinnen LED-indicatie voor verzenden en ontvangen USB 2.0 full-speed compatibel Volledig USB-protocol on-chip
3 Componenten 3.5.2
38
Blokschema
Een blokschema van de FT232RL is te zien in figuur 3.23. Het wordt al snel duidelijk dat deze chip toch nog behoorlijk wat digitale logica aan boord heeft. De FT232RL beschikt ook over een interne 3.3 V spanningsregelaar. Deze stabiele 3.3 V wordt ook naar buiten gebracht, zodat ze bijvoorbeeld kan gebruikt worden voor andere componenten. De chip voorziet ook in zijn eigen klok. Er is namelijk een 12 MHz klokgenerator aan boord, die geen externe kristal nodig heeft! De 48 MHz klok die nodig is voor de baudrate generatie, wordt bekomen door deze 12 MHz te verviervoudigen. Ook dit gebeurt allemaal on-chip.
Figuur 3.23: Blokschema van de FTDI FT232RL UART-USB brug.
3 Componenten
3.6
39
Spanningsregelaar
Om een stabiele spanning van 3 V te voorzien voor de IC’s op de sensor node (3.3 V voor de ontvangstnode) werd gekozen voor een MCP1700 LDO-spanningsregelaar [20]. Het voordeel van een LDO-regelaar is dat de spanning aan de ingang niet veel hoger moet liggen dan de gewenste spanning aan de uitgang. Bij een conventionele spanningsregelaar staat er bijgevolg meer spanning over de regelaar, wat uiteraard niet gewenst is in batterijgevoede sensor applicaties. 3.6.1
Functionaliteit
Ingangsspanningsbereik: 3.2 V (3.5 V voor de 3.3 V-regelaar) - 6.5 V Uitgangsstroom: max. 250 mA Spanningsval: typisch 178 mV Kortsluitbeveiliging Temperatuursbeveiliging
3.6.2
Blokschema
Figuur 3.24: MCP1700 LDO-regelaar.
De werking van zo’n LDO-regelaar is eigenlijk redelijk eenvoudig. Zoals te zien is in bovenstaande figuur is de basis component een P-type FET. Deze FET wordt gestuurd door een OpAmp, waarvan de negatieve ingangspin verbonden is met een zeer stabiele bandgapreferentie. De positieve ingang meet de spanning over een soort sense-weerstand”. Deze ” spanning wordt dus vergeleken met de bandgap-spanning en de OpAmp zal deze fout trachten weg te regelen door de gate van de PMOS meer of minder te sturen. Het voordeel van deze configuratie is een zeer stabiele spanning ´en een zeer lage spanningsval, die gelijk is aan de saturatiespanning (kan ook meer zijn uiteraard, ten minste de saturatiespanning) van de PMOS. Er staat nog een beveiligingsdiode parallel op het kanaal van de PMOS.
3 Componenten
3.7
40
Ethernet chip
Verschillende ontvangers kunnen ook aangesloten worden op dezelfde PC met het Ethernetprotocol. Met een snelheid van 10 Mbps kunnen zonder probleem meerdere ontvangers worden aangesloten op dezelfde bus. Als Ethernet-chip werd gekozen voor de Microchip ENC28J60 [21]. Deze Ethernet-controller ondersteunt het IEEE 802.3 Ethernet-protocol tot op MACniveau. De communicatie met de MCU gebeurt via de SPI-interface. Er worden kloksnelheden tot 20 MHz ondersteund voor deze SPI-connectie, wat meer dan voldoende is. Een typische connectie van de ENC28J60 is te zien in figuur 3.25.
Figuur 3.25: Microchip ENC28J60 Ethernet chip aansluiting.
Op het ontvangstbord moet er uiteraard ook een RJ45-connector worden voorzien. Er werd gekozen voor een Amphenol RJMG163218101NR [22] met twee ingebouwde status-leds, die rechtstreeks gestuurd worden door de Ethernet-chip (LEDA en LEDB). De ENC28J60 en de RJ45 Jack worden getoond in onderstaande figuren.
Figuur 3.26: Microchip ENC28J60 ethernet chip.
Figuur 3.27: Amphenol RJ45-connector.
3 Componenten
3.8
41
Bluetooth module
De zoektocht naar een geschikte Bluetooth-chip verliep minder vlot dan verwacht. Na wat research werd al snel duidelijk dat er complete single-chip oplossingen op de markt beschikbaar zijn. Voorbeelden hiervan zijn de BlueMoon UniCellular serie van Infineon, de BlueCore-reeks van CSR en de STA2500 van ST Microelectronics. Deze chips zijn meestal speciaal ontwikkeld voor toepassingen in mobiele telefoons en sensor applicaties met Bluetooth. Hierdoor zijn deze chips meestal behoorlijk klein en hebben ze een laag vermogenverbruik, wat ideaal is voor onze toepassing. Het grote voordeel van deze chips is dat ze zeer weinig randcomponenten nodig hebben. Buiten een kristal, enkele condensatoren en een antenne is alles voorzien on-chip! Figuur 3.28 toont een schematische voorstelling van de BlueCore 4 van CSR [23].
Figuur 3.28: BlueCore 4 Bluetooth-chip van CSR.
Zoals de figuur laat zien zijn deze chips veel meer dan enkel en alleen een Bluetooth transceiver! Naast de 2.4 GHz radio heeft deze chip ook een 16-bit RISC microcontroller aan boord. Deze MCU implementeert de Bluetooth software-stack en zorgt eveneens voor de aansturing van de verschillende interfaces. Er is ook 48 KB RAM-geheugen aan boord die gebruikt kan worden door de MCU om data of spraak te bufferen. De firmware wordt bewaard in het interne ROM-geheugen van 4 Mb. Programmeren van het ROM-geheugen gebeurt met een SPI-verbinding, terwijl de UARTinterface toelaat om de chip aan te sturen met een HOST-processor. De BlueCore heeft nog tal van andere eigenschappen, die niet nodig zijn voor onze toepassing en worden dus niet besproken. Opvallend is ook dat de meeste single-chip Bluetooth IC’s vrij goedkoop zijn, terwijl het toch behoorlijk complexe componenten zijn. De BlueCore 4 ROM is al te verkrijgen vanaf 5 dollar. Een groot nadeel van al deze chips is dat de fabrikanten zeer karig zijn met informatie. Van sommige IC’s was zelfs geen datasheet te verkrijgen, tenzij voor klanten. . . Naast het feit dat informatie moeilijk te verkrijgen was, is er nog een vrij groot probleem. Als
3 Componenten
42
zo’n BlueCore-chip wordt gebruikt in het systeem, moet hij door de host-MCU worden aangestuurd via de UART-interface. De commando’s die gebruikt worden voor deze communicatie zijn echter HCI-commando’s. Dat wil zeggen dat de host-MCU eveneens een Bluetooth-stack aan boord moet hebben tot op HCI-niveau. Een dergelijke stack schrijven neemt heel wat tijd in beslag en het is absoluut niet de focus van deze thesis. Mogelijke oplossingen waren de implementatie van een minimale stack, waarin enkel de gebruikte functies van de stack geschreven zijn of het aankopen van een stack. Na wat meer zoekwerk werd nog een ander alternatief gevonden: een Bluetooth-module. Een BT-module is in essentie niets anders dan een PCB’tje met daarop zo’n Bluetooth-chip, inclusief alle randcomponenten (zelfs de antenne) en waarvan de BT-chip zo geprogrammeerd is dat hij op een hoog niveau kan aangestuurd worden door een host-microcontroller via de UART-interface. De commando’s die gebruikt worden voor de aansturing zijn ATcommando’s (Bijlage B). De module die werd gekozen is de RN-41 van Roving Networks [24]. Deze module is uitgerust met de BlueCore 4 EXT en voorziet alle randcomponenten voor deze chip: flash-geheugen, balun, antenne, kristal,. . . De RN-41 is te zien in figuur 3.29 en meet amper 13.4 mm op 25.8 mm!
Figuur 3.29: Roving networks RN-41 Bluetooth module.
3 Componenten 3.8.1
43
Functionaliteit
Voedingsspanning: 3.0 V - 3.6 V Gemiddeld stroomverbruik: 30 mA in normale werkingsmode Sensitiviteit: Typisch -80 dBm RF TX vermogen: 12 dBm Afstand: ± 100 m Bluetooth 2.0 + EDR Klein formaat: 13.4 mm x 25.8 mm x 2 mm On-board RF-antenne Interfacing: Bestuurbaar via UART met AT-commando’s
3.8.2
Blokschema
Figuur 3.30: Blokschema van de RN-41 Bluetooth module.
EMBEDDED SOFTWARE
44
Hoofdstuk 4
Embedded software In hoofdstuk 2 werd de werking van het netwerkprotocol uitgelegd. Hoe dat nu juist wordt ge¨ımplementeerd en hoe de verschillende IC’s worden aangestuurd door de microcontroller werd daar niet vermeld. In dit deel wordt het geheel eerder bekeken vanuit het standpunt van de microcontroller. Het is niet de bedoeling om hele pagina’s code te kopi¨eren uit de software. Bepaalde stukjes code worden wel getoond, als ze relevant zijn voor de bijhorende uitleg. Het hoofdstuk wordt gesplitst in twee grote delen, implementatie en netwerkprotocol” en ” aansturing van de componenten”. In het eerste deel worden bepaalde aspecten besproken van ” het netwerkprotocol en de algemene implementatie. Hoe worden de pakketten opgebouwd, het gebruik van low-power modes,. . . In het tweede deel worden de randcomponenten besproken en de aansturing ervan.
1 1.1
Implementatie en netwerkprotocol Opbouw van een pakket van een sensor node
In figuur 4.1 is de opbouw van een masterpakket te zien. Zoals de figuur laat zien is zo’n pakket 11 bytes groot. 1 byte
1 byte
3 bytes
Counter
Sensor
Accelerometer
6 bytes
Magnetometer
Figuur 4.1: Opbouw van een masterpakket.
De eerste byte is de counter en is in wezen niks anders dan een cyclisch pakketnummer. Na 256 pakketten, zal de teller gewoon weer op 0 springen. Deze counter is gesynchroniseerd voor alle nodes, zodat alle slaves ook op hetzelfde moment een synchronisatie doen met de master. In de bestaande versie was dit niet het geval. Iedere node had een teller die telkens tot 255 telde, maar het was perfect mogelijk dat de tellers van de verschillende nodes niet overeenkwamen. Bij het dynamisch maken van het protocol was dit echter nodig. Het is namelijk zo dat er
1 Implementatie en netwerkprotocol
45
een synchronisatie gebeurt met de master als deze teller overflowt en terug op 0 springt. Het is ook op dat moment dat er gedetecteerd wordt of de master weggevallen is. Moesten de tellers niet gelijk lopen, dan zullen de verschillende slaves op andere momenten deze controle doen. Zoals uitgelegd werd in hoofdstuk 2, is het de bedoeling dat de slave met het kleinste tijdslot het falen van de master eerst opmerkt. Dit wordt verwezenlijkt door een variabele wachttijd in te lassen. Als de tellers niet synchroon lopen, heeft dit totaal geen zin en zal het “toeval” uitwijzen welke slave eventueel master wordt. Het grootste probleem hierbij is dat er een kans bestaat dat verschillende slaves op ongeveer hetzelfde moment opmerken dat de master weggevallen is. Hierdoor kan het zijn dat er opeens meerdere slaves master worden! Dat deze kans bestaat is zeer eenvoudig in te zien. De variabele wachttijd, vooraleer een slave beslist dat de master weggevallen is bedraagt (52 + 20*timeslot) ms. Stel dat slave 1 en slave 2 niet hetzelfde pakketnummer hebben, maar dat slave 1 exact twee nummers achter loopt op slave 2. In dat geval zal slave 1 twee masterpakketten later (20 ms) synchroniseren dan slave 2. Het resultaat is dat de timer die zorgt voor de variabele wachttijd, op hetzelfde moment afloopt voor de twee slaves! Slave 1 ´en 2 worden beiden master. . . De volgende byte bevat het sensor nummer. Dit nummer is hardgecodeerd in het flashgeheugen van elke node. Dit is nodig, omdat het anders onmogelijk is om te bepalen van welke sensor node de ontvangen data komt (of met andere woorden, van welk lichaamsdeel). De volgende drie bytes bevatten de accelerometer data. De X-,Y- en Z-as worden dus elk gecodeerd in ´e´en byte. De volgende zes bytes bevatten de magnetometer data. De magnetometer gebruikt dus twee bytes per as. De opbouw van een slavepakket is bijna identiek, met dat verschil dat de eerste byte niet meer het pakketnummer voorstelt, maar nu het nummer van zijn tijdslot is. Doordat alle nodes een gesynchroniseerde teller hebben, is dit geen enkel probleem en is het voldoende dat enkel de master deze informatie verzendt. De reden dat de slaves het nummer van hun tijdslot verzenden heeft te maken met de opstartprocedure. Zoals reeds werd uitgelegd in hoofdstuk 2, zullen de slaves een soort slavescan doen bij opstart. Hierdoor kan er dynamisch een slot worden toegekend aan elke slave. Deze slavescan houdt dus gewoon in dat de slave gedurende een bepaalde tijd luistert op het slave kanaal. Bij elk ontvangen pakket zal hij aan de hand van de eerste byte van dit pakket weten in welk tijdslot het pakket verzonden werd. Dit slotnummer wordt vervolgens gemarkeerd in een eenvoudige tabel. Na de slavescan procedure kan uit deze tabel afgeleid worden welke tijdslots nog vrij zijn. De opbouw van een slavepakket is te zien in figuur 4.2. 1 byte
1 byte
3 bytes
Timeslot
Sensor
Accelerometer
6 bytes
Magnetometer
Figuur 4.2: Opbouw van een slavepakket.
Doordat enkel de eerste byte verschillend is, worden de andere bytes niet meer besproken. Let wel dat de pakketten nog worden aangevuld met een preamble, een adres en een CRC. De preamble en de CRC worden echter automatisch toegevoegd door de transceiver.
1 Implementatie en netwerkprotocol
1.2
46
Opbouw van een pakket van de ontvangstnode
De taak van de ontvangstnode is om alle sensor data door te geven aan de PC. In de originele code gebeurde dit redelijk direct: Er werd enkel een ’S’-karakter (synchronisatie karakter) toegevoegd voor elk pakket, waarna de ontvangen pakketten onveranderd werden doorgegeven via de UART. De ontvanger deed dus niks anders dan pakketten ontvangen en deze direct doorsturen tussen twee timeslots in. Dit is schematisch weergegeven in figuur 4.3. Receive master
Send master
Receive slave 1
Send slave 1
Receive slave 2
Send slave 2
…
Receive slave 9
Send slave 9
Free time
10 ms Figuur 4.3: Tijdsschema van de ontvangstnode voor het originele protocol.
Hierbij is de duur van een tijdslot zodanig ingesteld dat de ontvangstmodule net genoeg tijd heeft tussen twee ontvangen pakketten, om de data naar de PC door te sturen. De duur van een tijdslot is dus ’experimenteel’ vastgelegd en bedraagt ongeveer 0.8 ms. Het blokje ’free time’ duurt ongeveer 0.9 ms en wordt gebruikt om de ontvanger terug in te stellen op ontvangst op het masterkanaal. Bij de huidige ontvangstmodule is dit niet meer mogelijk, daar de ontvanger nu (als er meer dan 10 nodes aanwezig zijn) twee slave kanalen in parallel moet ontvangen. De MCU heeft geen tijd om tussen twee timeslots alle data te verzenden! Een elegantere oplossing bestaat erin om de timeslots zo dicht mogelijk tegen elkaar te leggen. Dit kan nu aangezien er geen tijd meer moet gelaten worden tussen twee tijdslots om te verzenden naar de PC. Door de tijdslots sneller na elkaar te laten volgen is er een periode op het einde van elk frame (na ontvangst van alle sensor nodes), waar er geen pakketten meer toekomen. Deze periode wordt nu gebruikt om alle ontvangen pakketten in ´e´en keer te verzenden naar de PC. Dit is weergegeven in onderstaande figuur (figuur 4.4). Receive master
Receive slave 1
Receive slave 2
…
Receive slave 9
Send big packet
Free time
10 ms Figuur 4.4: Tijdsschema van de ontvangstnode voor het huidige protocol.
Alle pakketten worden nu in ´e´en keer verzonden naar de PC, op het einde van elk frame. De ontvangstmodule heeft nu ongeveer 2 ms de tijd om alle data te verzenden. In principe is er voor de USB-interface niet zo’n groot verschil, omdat alle pakketten nu aan elkaar geplakt worden en de totale zendtijd ongeveer gelijk blijft. Voor de Ethernet-interface is er echter w´el een winst door deze manier van werken. Omdat de UDP-pakketten aangevuld worden met headers en er telkens een checksum moet berekend worden voor elk pakket moet dit maar ´e´en keer gebeuren per frame!
1 Implementatie en netwerkprotocol
1.3
47
Low-power modes
Omdat low-power modes zo belangrijk zijn voor batterijgevoede applicaties wordt er toch iets dieper op ingegaan. De meeste microcontrollers beschikken over ´e´en of meerdere low-power modes. In deze operatiemodes worden bepaalde delen van de controller uitgeschakeld, wat kan leiden tot een significant verschil in het vermogenverbruik! De grootste energieverbruiker binnen een microcontroller is normaal gezien de CPU zelf. Andere vermogensintensieve delen zijn de klokken en de klokgenerators. Door deze delen uit te schakelen als ze niet gebruikt worden zal het gemiddeld vermogenverbruik veel lager liggen. De MSP430F249 beschikt over vijf low-power modes (LPM’s). Afhankelijk van de gebruikte LPM worden meer of minder onderdelen uitgeschakeld. Tabel 4.1 geeft een overzicht van de vijf LPM’s en de actieve mode met een beschrijving van de actieve en inactieve delen. Hoe hoger het nummer van de low-power mode, hoe meer onderdelen worden uitgeschakeld en hoe lager het vermogenverbruik.
Mode
Beschrijving
Actief
CPU actief, alle geconfigureerde klokken actief
LPM 0
CPU, MCLK inactief SMCLK, ACLK actief
LPM 1
CPU, MCLK inactief, DCO inactief indien niet gebruikt voor SMCLK ACLK actief
LPM 2
CPU, MCLK, SMCLK, DCO inactief ACLK, DC generator actief
LPM 3
CPU, MCLK, SMCLK, DCO, DC generator inactief ACLK actief
LPM 4
CPU en alle klokken inactief Tabel 4.1: Overzicht van de low-power modes.
De tabel laat zien dat de CPU enkel aangeschakeld is in de actieve mode. Dit wil zeggen dat er sowieso geen berekeningen of andere operaties kunnen gebeuren in gelijk welke low-power mode. In LPM0 tot en met LPM3 blijft de ACLK actief. Deze ACLK wordt gedreven door een zeer precies extern horlogekristal met een frequentie van 32.768 kHz. In de code wordt de ACLK ingesteld als klok voor de timers. Deze timers worden gebruikt om de tijdslots te defini¨eren en moeten de microcontroller dus kunnen wekken als het juiste tijdslot voorkomt. Overgaan van een low-power mode naar actieve mode kan door middel van een interrupt. Als een bepaalde interrupt voorkomt, dan kan de werkingsmode worden aangepast in de interrupt routine. Een timer interrupt genereren kan uiteraard alleen als de timer nog actief is, waardoor LPM4 niet gebruikt kan worden. . .
1 Implementatie en netwerkprotocol
48
LPM3 is ideaal voor onze toepassing, omdat dan bijna alle onderdelen zijn uitgeschakeld, behalve ACLK. Hierdoor kan de MCU steeds gewekt worden door een timer-interrupt. Om een idee te geven van het stroomverbruik, wordt in figuur 4.5 het stroomverbruik getoond voor de werkingsmodes bij een klokfrequentie van 1 MHz (zoals het geval is bij de nodes) en voor voedingsspanningen van 2.2 V en 3 V.
350
300
ICC [µA] bij 1 MHz
300
250
200
VCC = 3 V
200
VCC = 2,2 V
150
100
55 32
50
17
11
0,9
0,7
0,1
0,1
0
AM
LPM 0
LPM 2
LPM 3
LPM 4
Operatie mode Figuur 4.5: Stroomverbruik voor de verschillende werkingsmodes.
De microcontroller op de sensor nodes wordt gevoed met 3 V, omdat deze spanning compatibel is met alle componenten op de module. Figuur 4.5 laat zien dat het stroomverbruik in LPM3 in dit geval amper 0.9 µA is. Dit zo’n 330 keer minder dan in actieve mode!!
2 Aansturing van de componenten
2
49
Aansturing van de componenten
2.1
Nordic nRF2401A transceiver
De nRF2401A werd reeds deels besproken in het hardware-gedeelte. Hier wordt de transceiver vanuit een ander oogpunt bekeken. De interface-pinnen van deze component werden al besproken, maar hoe de aansturing nu juist gebeurt in de software is hetgeen hier uit de doeken wordt gedaan. 2.1.1
Interface met de MCU
In het vorige hoofdstuk werd gezegd dat de aansturing van de component gebeurt met een SPI-connectie. Normaal biedt een SPI-connectie mogelijkheid tot full-duplex communicatie. Hiervoor worden er 2 datalijnen gebruikt en ´e´en kloklijn (Appendix A, sectie 3). Verder wordt normaal ook een lijn gebruikt als chip-enable. De nRF2401 heeft echter maar ´e´en datalijn, waardoor enkel half-duplex communicatie mogelijk is. Om deze interface toch aan te sturen met een standaard SPI-interface van de MCU moeten de MOSI- en MISO-pinnen van de microcontroller kortgesloten worden. De DR-pinnen van de transceiver worden verbonden met een interrupt-pin van de MCU, zodat deze gewekt kan worden bij ontvangst van data. Op die manier moet de MCU niet continu actief blijven om eventuele data te ontvangen. Een voorwaarde is uiteraard dat de transceiver gebruikt wordt in shockburst mode, zodat het DR-signaal gebruikt kan worden (in direct mode kan het DR-signaal niet gebruikt worden!). De CS-, CE- en PWR UP-pinnen van de nRF2401 worden verbonden met een gewone I/O-pin van de MCU. Figuur 4.6 toont een blokschema van de interface tussen de MCU en de Nordic nRF2401. In deze figuur wordt maar ´e´en kanaal getoond. Indien gebruik gemaakt wordt van de DuoCeiver, dan zijn er nog drie extra pinnen nodig op de MCU (voor een tweede SPI-interface).
MOSI MISO CLK
MCU DR CE CS PWR_UP
DATA CLK
nRF2401 DR CE CS PWR_UP
Figuur 4.6: Interface van de Nordic nRF2401 transceiver met de microcontroller.
2 Aansturing van de componenten 2.1.2
50
Configuratie
Configuratie van de nRF2401 gebeurt door te schrijven naar het 15 bytes lange configuratiewoord. Schrijven naar dit register kan door middel van dezelfde SPI-verbinding. Om onderscheid te maken tussen TX/RX-operatie en configuratie, worden de extra lijnen CE en CS gebruikt. Tabel 4.2 somt de verschillende werkingsmodi van de nRF2401 op en toont hoe de lijnen CE, CS en PWR UP hiervoor moeten worden gebruikt.
Mode
PWR UP
CE
CS
Actief
1
1
0
Configuratie
1
0
1
Stand by
1
0
0
Power down
0
X
X
Tabel 4.2: Verschillende werkingsmodi van de nRF2401.
Zoals te zien is in de tabel moet CS hoog geplaatst worden om de nRF2401 in configuratiemode te brengen. Onderstaand codefragment toont hoe de configuratie van de transceiver gebeurt door de microcontroller. De eerste stap is het hoog zetten van de CS-lijn. Vervolgens wordt de configuratiedata doorgegeven via de SPI-verbinding. Als alle bytes geschreven zijn, wordt CS terug laag gebracht. Op dat moment wordt de nieuwe configuratie actief. void Config_Nordic(void) { int i; P4OUT |= (1<=0;i--) { SPI_Send(nordic_config[i]); } DELAYU(5); P4OUT &= ~(1<
// Set Chip Select to enter configuration mode // MSB first // Send all bytes of configuration word // THIS DELAY NEEDED !!!!!! // Set CS low
Figuur 4.7: Config Nordic-procedure.
2 Aansturing van de componenten
51
Algemene configuratie
Shockburst configuratie
Het configuratiewoord is te zien in tabel 4.3. Bitpositie
Aantal bits
Naam
Beschrijving
143:120
24
TEST
Gereserveerd voor testen
119:112
8
DATA2 W
Lengte van data payload RX kanaal 2
111:104
8
DATA1 W
Lengte van data payload RX kanaal 1
103:64
40
ADDR2
Tot 5 bytes voor adres op kanaal 2
63:24
40
ADDR1
Tot 5 bytes voor adres op kanaal 1
23:18
6
ADDR W
Aantal adresbits (voor beide kanalen)
17
1
CRC L
8 of 16 bit CRC
16
1
CRC EN
On-chip CRC-berekening inschakelen
15
1
RX2 EN
1
14
1
CM
Communicatie mode (Direct mode/Shockburst mode)
13
1
RFDR SB
RF data rate (16 MHz kristal nodig voor 1 Mbps operatie)
12:10
3
XO F
Kristal frequentie
9:8
2
RF PWR
RF uitgangsvermogen
7:1
7
RF CH#
Frequentie-kanaal
0
1
RXEN
RX/TX operatie
Tabel 4.3: Overzicht van het configuratiewoord van de Nordic nRF2401 transceiver [16].
Er werd reeds aangehaald dat de transceiver twee communicatiemodes heeft, de direct mode en de shockburst mode. Als de transceiver gebruikt wordt in direct mode, zijn enkel de twee laagste bytes (algemene configuratie in de tabel) relevant. In direct mode moet de microcontroller namelijk zelf de CRC berekenen en de preamble meegeven als data. In shockburst mode kan de transceiver dit automatisch doen.
2 Aansturing van de componenten 2.1.3
52
Communicatie
De nRF2401 wordt ingesteld in shockburst mode. De voordelen hiervan zijn reeds uitvoerig besproken. E´en van de voordelen was de verminderde complexiteit voor de microcontroller. De microcontroller wordt namelijk verwittigd wanneer er een datapakket is toegekomen (DRpin). Daarnaast hoeft de MCU zich niet bezig te houden met het berekenen van CRC’s en het toevoegen van de preamble bij elk te verzenden pakket! De adressen worden in het configuratiewoord geladen (zie tabel 4.3). De transceiver zal dus enkel paketten doorgeven aan de MCU als het adres klopt (in direct mode niet!). Het adres wordt ook uit het pakket verwijderd door de transceiver, vooraleer het wordt doorgegeven aan de MCU. We veronderstellen hier dat de nRF2401 reeds volledig ingesteld is voor RX/TX in shockburst mode. Figuur 4.8 toont de flowchart voor de verzending van data in shockburst mode.
Shockburst TX mode? (CE hoog)
NEE
JA Adres en data verzenden naar de nRF2401 via SPI
CRC berekenen
CE laag?
NEE
JA Preamble toevoegen
Shockburst pakket verzenden
JA
Verzending compleet?
NEE
Figuur 4.8: Flowchart voor verzending in shockburst mode.
2 Aansturing van de componenten
53
In principe zijn er in de flowchart een 4-tal stappen te onderscheiden: 1. De MCU zet de CE-lijn hoog als hij data wil verzenden. 2. 5 µs later kan de MCU beginnen met het verzenden van het adres en de data via de SPI-verbinding. De datarate over de SPI-verbinding wordt volledig bepaald door de MCU (shockburst). 3. Als alle data is doorgegeven aan de transceiver, moet de MCU nogmaals 5 µs wachten en vervolgens de CE-lijn terug laag zetten. 4. De transceiver zal de CRC berekenen en toevoegen aan het pakket, net als de preamble. Het volledige datapakket wordt nu verzonden aan 250 kbps (of 1 Mbps). Na de verzending gaat de nRF terug over op stand-by. De ontvangst van data in shockburst mode, zoals voorgesteld in de flowchart van figuur 4.9, is op te delen in de volgende stappen: 1. De MCU zet de CE-lijn hoog om RX te activeren. 200 µs later is de nRF2401 klaar om datapaketten te detecteren. 2. Als een geldig pakket wordt ontvangen (correct adres en CRC), zal de nRF2401 de preamble, het adres en de CRC verwijderen. 3. De MCU wordt op de hoogte gebracht van de ontvangst, doordat de DR-lijn hoog gezet wordt door de nRF. 4. Op dat moment kan de MCU de CE-lijn laag zetten (en dus RX deactiveren), of hoog laten staan als er nog data ontvangen moet worden. 5. De MCU klokt de data binnen. Als alle data is ingelezen, zet de nRF de DR-lijn terug laag. Indien CE nog steeds hoog staat, kan nu onmiddellijk nieuwe data ontvangen worden. Als hij in de vorige stap laag gezet werd, moet de volledige procedure opnieuw doorlopen worden.
2 Aansturing van de componenten
54
Shockburst RX mode?
NEE
JA nRF2401 detecteert preamble en data
Adres correct?
NEE
JA Data ontvangen en CRC controleren
NEE CRC correct?
JA nRF2401 zet DR-lijn hoog
MCU neemt ontvangen data binnen
NEE
nRF2401 register leeg?
JA nRF2401 zet DR-lijn terug laag
Figuur 4.9: Flowchart voor ontvangst in shockburst mode.
2 Aansturing van de componenten
2.2
55
LIS302DL accelerometer
De accelerometer is verbonden met de MCU door middel van een I2 C-interface. Doordat er geen gebruik gemaakt wordt van de interruptpinnen van de LIS302DL, zijn er maar twee lijnen nodig voor de interface: SDA en SCL. 2.2.1
Configuratie
De configuratie van de accelerometer is uiterst eenvoudig. De LIS302DL beschikt over een aantal configuratie-registers, die geschreven en gelezen worden via de I2 C-interface. Er kunnen heel wat instellingen gewijzigd worden, maar voor onze toepassing is er eigenlijk maar ´e´en configuratie-register van belang: Ctrl Reg1 (tabel 4.4).
Naam DR PD FS STP,STM Zen Yen Xen
Beschrijving Datarate selectie, standaard 0 0: 100 Hz, 1: 400 Hz Powerdown control, standaard 0 0: power down mode, 1: actieve mode Full scale selectie, standaard 0 Self test enable, standaard 0 0: normale mode, 1: zelftest actief Z-as actief, standaard 1 0: niet actief, 1: actief Y-as actief, standaard 1 0: niet actief, 1: actief X-as actief, standaard 1 0: niet actief, 1: actief Tabel 4.4: Ctrl Reg1
Initialiseren van de accelerometer is in feite niets anders dan PD, Zen, Yen en Xen op logische 1 te zetten. Hierdoor is de LIS302DL ingesteld in actieve mode en zijn de drie sensoren actief. Omdat 100 samples/s voldoende is, mag DR gewoon op logische 0 blijven staan.
2 Aansturing van de componenten 2.2.2
56
Uitlezen van de sensor data
Na iedere meting wordt de opgemeten data van elke as weggeschreven in een register van de LIS302DL. De drie registers (OUT X, OUT Y en OUT Z) kunnen uitgelezen worden door de microcontroller via de I2 C-interface. De drie output-registers zijn elk ´e´en byte groot en bevinden zich op de volgende adressen in het geheugen: Register OUT X OUT Y OUT Z
Adres 0x29 0x2B 0x2D
Tabel 4.5: Registeradressen van de output-registers.
De drie assen kunnen allemaal samen uitgelezen worden, volgens een “multiple bytes read”operatie. De LIS302DL zal hierbij automatisch het registeradres verhogen, zolang de master een bevestiging stuurt. In tabel 4.5 is wel te zien dat de drie registers geen opeenvolgende adressen hebben. Er zit namelijk telkens ´e´en register tussen! Het is dus noodzakelijk dat er vijf opeenvolgende registers worden gelezen. . . De readAcc()-procedure is te zien in onderstaand codefragment. Eerst wordt het I2 C-adres van de LIS302DL ingesteld. Daarna wordt het commando gegeven om vijf bytes te lezen, startend bij het register OUT X. Uiteindelijk wordt de data van de drie assen in de verzendbuffer geplaatst. void readAcc(void) { unsigned char TxData[1]; Set_I2CAddress(AccAddress);
Net als de accelerometer wordt de magnetometer aangestuurd met behulp van I2 C. Deze I2 Cinterface wordt dus gedeeld door de twee sensoren. Lezen of schrijven naar een bepaalde sensor kan doordat elk I2 C-device een uniek adres heeft. De aansturing van de magnetometer is wel een stuk ingewikkelder dan de accelerometer. Helaas mag deze component niet uitgebreid besproken worden, daar er een NDA ondertekend werd. In de datasheet van de YAS529 is jammer genoeg bijna niets terug te vinden over de werking. De registers en de configuratie worden allemaal besproken in de application manual. . .
2.4
RN-41 Bluetooth module
In het hardware gedeelte (Hoofdstuk 3) werd reeds toegelicht waarom een Bluetooth module werd gekozen. De reden was dat de meeste Bluetooth-IC’s redelijk moeilijk aan te sturen zijn. In principe moet er een Bluetooth-stack geschreven worden voor de MCU, wat op zich geen eenvoudige taak is. De RN-41 is niets anders dan een module met een Bluetooth IC (figuur 3.30), voorzien van alle randcomponenten en die zo geprogrammeerd is dat de aansturing gebeurt met eenvoudige AT-commando’s. Deze commando’s zijn gewone ASCII-karakters, die verzonden worden over de UART en dus toelaten om bepaalde instellingen te doen van de module. 2.4.1
Configuratie
Om de module in te stellen moet deze eerst in command-mode gebracht worden. Dit gebeurt door de karakters “$$$” te verzenden naar de module. Dit kan zowel lokaal (via de UART) als op afstand (via Bluetooth) gebeuren. De module beantwoordt deze aanvraag met “CMD”. Om de command-mode te verlaten moeten de karakters “---” worden gezonden. Hierbij staat voor een carriage return, voorgesteld door de ASCII code 0x0D. Indien de module met succes is teruggekeerd naar de data mode, beantwoordt hij deze aanvraag met “END”. Als de module in de command-mode staat, kunnen instellingen gelezen en geschreven worden. Een lijst met alle commando’s is terug te vinden in appendix B. De module heeft ook enkele PIO-pinnen. Sommige van deze pinnen kunnen ook gebruikt worden om de module in te stellen. Tabel 4.6 geeft een overzicht van de instellingen die op deze manier kunnen gebeuren.
Functie Fabrieksinstellingen Auto discovery/pairing Auto-connect Baudrate
Tabel 4.6: Instellingen door middel van de PIO-pinnen.
2 Aansturing van de componenten
58
Als de ontvanger in Bluetooth-mode wordt gezet (door de schakelaar op het bordje), dan gebeurt er eerst een configuratie. Deze configuratie zorgt in eerste instantie voor het instellen van de UART-interface van de MCU. Daarna wordt de module in command-mode gezet en worden een aantal instellingen aangepast van de BT-module zelf. De uitgewisselde commando’s tussen de microcontroller en de RN-41 zijn als volgt: MCU: $$$ RN-41: CMD MCU: SU,92 RN-41: AOK MCU: SQ,16 RN-41: AOK MCU: SM,0 RN-41: AOK MCU: ST,255 RN-41: AOK MCU: - - - RN-41: END Het eerste commando zorgt ervoor dat de RN-41 in command-mode wordt gebracht. Dit commando moet binnen de 60 seconden na aanschakelen van de module gebeuren, tenzij de standaard instelling van de configuratie-timer wordt aangepast. Indien de module in command-mode zit, zal hij beantwoorden met “CMD”. Eens de RN-41 in command-mode zit, kunnen configuratie-commando’s gestuurd worden. SU,92: Baudrate instellen op 921 kbps, de maximale snelheid van de module. SQ,16: De module wordt ingesteld om data te verzenden met een zo klein mogelijke delay. Hierdoor wordt voorkomen dat pakketten worden uitgesmeerd over een te lange tijd, waardoor er problemen optreden aan de ontvangstzijde. SM,0: De RN-41 wordt ingesteld als slave. Hierdoor kan de RN-41 van op afstand geconfigureerd worden en beslist de PC wanneer er een verbinding wordt gemaakt. ST,255: De configuratie-timer staat standaard ingesteld op 60 seconden. Door de timer in te stellen op 255, is de configuratie-mode altijd toegankelijk. - - -: Na dit commando zal de module de configuratie-mode verlaten en terugkeren naar datamode.
2 Aansturing van de componenten 2.4.2
59
Communicatie
Communicatie is behoorlijk eenvoudig. De te verzenden data wordt rechtstreeks naar de module verzonden via UART. Doordat de verbinding een SPP-connectie is, zien we de RN-41 op de PC als een virtuele COM-poort, net als de USB-verbinding. Buiten de lagere baudrate ziet de connectie er dus identiek uit voor de PC, waardoor de applicatie op de PC zo goed als ongewijzigd kan blijven. Net als bij USB, wordt ieder datapakket voorafgegaan door een ’S’-karakter. Dit karakter dient als synchronisatie-karakter voor de PC-applicatie. Ter illustratie wordt de procedure getoond die zorgt voor de verzending van een pakket naar de RN-41. Deze functie wordt ´e´en keer opgeroepen om de 10 ms, waarbij alle datapakketten na elkaar worden verzonden zoals werd uitgelegd in sectie 1.2. void Send_Big_BT_Packet(void) { for(j=0;j<sensorcounter1;j++) { putchar(’S’); // synchronizer byte DELAYU(10); for (i=0; i
Figuur 4.11: Send Big BT Packet procedure.
De functie zorgt ervoor dat alle pakketten na elkaar worden verzonden, met daartussen telkens een synchronisatie-byte. De delay’s van 10 µs en 7 µs zijn noodzakelijk! Zonder deze delay’s wordt de data niet ontvangen aan de PC-zijde. De functie laat ook zien dat er twee databuffers zijn. Databuffer ´e´en bevat de master en alle slaves uit slave kanaal ´e´en. De tweede databuffer bevat alle slaves die in slave kanaal twee zitten.
2 Aansturing van de componenten
2.5
60
ENC28J60 Ethernet controller
De ENC28J60 is een stand-alone Ethernet-controller, die aangestuurd wordt via een SPIinterface. De controller voorziet ondersteuning tot op Ethernet-niveau, wat de belasting voor de MCU niet onnodig zwaar maakt. In dit deel wordt kort besproken hoe de ENC28J60 geconfigureerd wordt en hoe pakketten verzonden worden. De opbouw van de pakketten zelf wordt hier niet toegelicht, maar is terug te vinden in de appendix. 2.5.1
Configuratie
Het intern geheugen van de ENC28J60 is ingedeeld in drie onderdelen: Controle-registers PHY-registers Ethernet-buffer
De controle-registers worden gebruikt voor de configuratie en aansturing van de ENC28J60. Er zijn ook enkele registers te vinden die statusinformatie bevatten. De PHY-registers worden eveneens gebruikt voor configuratie, aansturing en status-informatie, maar dan specifiek voor de PHY-module van de controller. De Ethernet buffer is ingedeeld in een ontvangstbuffer en een verzendbuffer en is in totaal 8 kB groot. De grootte van beide buffers is configureerbaar en kan dus optimaal gekozen worden voor iedere toepassing. 1. Controle-registers: De controle-registers zijn zeer belangrijk bij de aansturing van de Ethernet-controller. Lezen en schrijven van de controle-registers gebeurt rechtstreeks via SPI. De controleregisters kunnen worden ingedeeld in drie groepen: Ethernet (ETH) registers Medium Access Control (MAC) registers Media Independent Interface (MII) registers
De controle-registers zijn verdeeld over vier geheugenbanken. Elke bank is 32 bytes lang en wordt dus geadresseerd met vijf bits. Om een bepaald register te lezen of te schrijven moet de juiste bank eerst worden ingesteld. De vijf laatste bytes van elke geheugenbank bevatten echter dezelfde registers. Deze registers zijn belangrijk bij de aansturing van de Ethernet-controller en kunnen op die manier altijd direct aangesproken worden. De controle-registers zullen hier niet allemaal besproken worden, daar ze direct teruggevonden kunnen worden in de datasheet van de component.
2 Aansturing van de componenten
61
2. PHY-registers: In totaal zijn er negen PHY-registers, die elk 16 bits lang zijn. In tegenstelling tot de controle-registers zijn deze registers niet direct toegangkelijk via de SPI-interface. Om de PHY-registers te lezen of te schrijven moet gebruik gemaakt worden van een aantal MII controle-registers. Het lezen van een PHY-register gebeurt als volgt: (a) Schrijf het adres van het PHY-register in het MIREGADR controle-register. (b) Zet de MIIRD-bit van het MICMD-register hoog. Op dit moment start de leesoperatie en wordt de BUSY-bit van het MISTAT-register hoog gezet. (c) Wacht 10.24 µs en controleer vervolgens de waarde van de BUSY-bit. Deze bit zal automatisch gewist worden als de leesoperatie afgerond is. (d) Wis de MIIRD-bit in het MICMD-register. (e) De inhoud van het PHY-register is nu aanwezig in de controle-registers MIRDH en MIRDL. Deze kunnen vervolgens rechtstreeks gelezen worden via de SPI-interface. Om een PHY-register te schrijven moet de volgende sequentie uitgevoerd worden: (a) Schrijf het adres van het PHY-register in het MIREGADR controle-register. (b) Schrijf de acht minst significante bits in het MIWRL-register. (c) Schrijf vervolgens de 8 meest significante bits naar het MIWRH-register. Na het schrijven van dit register wordt de operatie automatisch gestart en zal de BUSYbit hoog geplaatst worden. Net zoals bij de leesoperatie wordt deze BUSY-bit automatisch gewist na afloop van de operatie (10.24 µs). 3. Ethernet buffer: De Ethernet-buffer bevat de ontvangst- en verzendbuffer van de ENC28J60. Zoals reeds werd gezegd is de grootte van deze twee buffers instelbaar en is de totale buffer 8 kB groot. Om de buffergrootte in te stellen moet de ontvangstlogica inactief zijn! De controle-registers ERXSTH:ERXSTL en ERXNDH:ERXNDL bepalen het start- en eindadres van de ontvangstbuffer. Het gedeelte van de Ethernet-buffer die geen ontvangstbuffer is, wordt ingesteld als verzendbuffer.
2 Aansturing van de componenten 2.5.2
62
Pakketten verzenden
De vorm van een Ethernet pakket is weergegeven in figuur 4.12. De preamble en de start of frame delimiter worden automatisch toegevoegd door de ENC28J60. De FCS kan ook automatisch toegevoegd worden door de controller. Hiervoor moet de CRCEN-bit van het ERXFCON controle-register hoog gezet worden. Het resultaat is dat de MCU en de ENC28J60 MAC-frames uitwisselen. Hoe deze MAC-frames worden opgebouwd is terug te vinden in appendix A, sectie 4. 7 bytes 1 byte Preamble SFD Synchronization header
6 bytes 6 bytes Destination address Source address MAC header
2 bytes Type/length
variabel Data Padding Data payload
4 bytes FCS CRC
Figuur 4.12: Opbouw van een Ethernet pakket.
Om een MAC-pakket te verzenden moeten de volgende stappen ondernomen worden door de MCU: 1. Stel de ETXST-pointer in, zodat deze verwijst naar een vrije locatie in de verzendbuffer. Een schrijfoperatie naar de Ethernet-buffer zal beginnen op deze locatie. 2. Schrijf de “per packet control byte” naar de Ethernet-buffer, gevolgd door het MACpakket. 3. Stel de ETXND-pointer in om het einde van het te verzenden pakket in te stellen in de buffer. Deze pointer ligt dus op “ETXST+datalengte”. 4. Wis de TXIF-vlag en zet de TXIE- en INTIE-vlaggen hoog om een interrupt te genereren na afloop van de transmissie. 5. Zet de TXRTS-bit (ECON1-register) hoog om de transmissie te starten. Onderstaand codefragment toont de functie die zorgt voor de verzending van een pakket over de Ethernet-interface. In het codefragment zijn de vijf stappen duidelijk te herkennen (voor de duidelijkheid expliciet aangegeven in commentaar). Indien gewenst kan de functie nog aangevuld worden om te controleren of het pakket goed verzonden werd.
2 Aansturing van de componenten
63
short unsigned int MACWrite(unsigned char * ptrBuffer, short unsigned int ui_Len) { volatile short unsigned int i; volatile short unsigned int address = TXSTART; unsigned char bytControl; bytControl = 0x00; /* STEP 1 -------------------------------------------------*/ // Select Bank 0 BankSel(0); // Write ptr to start of Tx packet WriteCtrReg(ETXSTL,(unsigned char)( TXSTART & 0x00ff)); WriteCtrReg(ETXSTH,(unsigned char)((TXSTART & 0xff00)>>8)); // Set write buffer to point to start of Tx Buffer WriteCtrReg(EWRPTL,(unsigned char)( TXSTART & 0x00ff)); WriteCtrReg(EWRPTH,(unsigned char)((TXSTART & 0xff00)>>8)); /* STEP 2 -------------------------------------------------*/ // Write per packet control byte WriteMacBuffer(&bytControl,1); address++; // Write packet. Assume correct formating src, dst, type WriteMacBuffer(ptrBuffer, ui_Len);
+ data
/* STEP 3 -------------------------------------------------*/ address += ui_Len; // Tell MAC when the end of the packet is WriteCtrReg(ETXNDL, (unsigned char)( address & 0x00ff)); WriteCtrReg(ETXNDH, (unsigned char)((address & 0xff00)>>8)); /* STEP 4 -------------------------------------------------*/ ClrBitField(EIR,EIR_TXIF); SetBitField(EIE, EIE_TXIE |EIE_INTIE); // Macro erratafix: set and clear ECON1_TXRST to reset transmit logic ERRATAFIX; /* STEP 5 -------------------------------------------------*/ // Set TXRTS to start transmission SetBitField(ECON1, ECON1_TXRTS); // Wait for transmission to end do { }while (!(ReadETHReg(EIR) & (EIR_TXIF))); ClrBitField(ECON1, ECON1_TXRTS); }
Figuur 4.13: MACWrite-functie: deze functie zorgt voor de verzending van een MAC-pakket.
2 Aansturing van de componenten
2.6
64
FT232R UART-USB brug
De FTDI FT232R is een zeer eenvoudig aan te sturen component. Er zijn een aantal configuratiemogelijkheden voor de CBUS-pinnen, maar dat is optioneel en wordt ook niet gebruikt. Het is voldoende om de TXD- en RXD-pin te verbinden met de UART-pinnen van de MCU en UART-pakketten te sturen. De component regelt voor de rest alles zelf. De UART wordt ingesteld op 2 Mbps (ongeveer de maximale snelheid van de FT232R): void UART_USB_Config(void) { //UART settings for PC-USB TX/RX on USCA0 P3SEL |= (1<
Figuur 4.14: UART-configuratie voor het aansturen van de FT232R.
Configuratie en verzending via UART wordt iets uitgebreider besproken in appendix A, sectie 2.
RESULTATEN
65
Hoofdstuk 5
Resultaten In dit hoofdstuk wordt een overzicht gegeven van alle resultaten. Het voornaamste doel van dit eindwerk was het ontwikkelen van een robuust, dynamisch en low-power netwerkprotocol voor het sensor netwerk. Dit protocol moest het mogelijk maken om meer dan 10 nodes op te nemen in het netwerk en het dynamisch karakter zou zorgen voor een stabieler en meer geavanceerd sensor netwerk. Een ander doel was de uitbreiding naar een systeem waarin meerdere personen op dezelfde PC gevolgd kunnen worden. Om dit te verwezenlijken volstaat het niet om enkel de software aan te passen, maar moest vooral de ontvangstnode aangepakt worden. Het eerste werk was hierbij het ontwikkelen van een nieuwe ontvangstnode. Daarna moest uiteraard ook de software van die node worden opgebouwd. Om te beginnen wordt de software toegelicht. Het gaat hier enerzijds om de software van de sensor nodes (het netwerkprotocol) en anderzijds de software die draait op de ontvangstnode. Als extraatje werd ook een applicatie geschreven voor een Windows Mobile PDA, die toelaat om de Bluetooth-module van op afstand (en zonder PC) in te stellen en zelfs sensor data uit te lezen. Het handige van deze applicatie is dat deze ook op een gewone Windows-PC werkt. Ook deze applicatie wordt kort besproken. Daarna wordt ook kort gesproken over de ontwikkelde hardware. Is het gewenste resultaat bereikt? Zijn er fouten aanwezig in het design? Wat kan er nog veranderen? Het zijn allemaal vragen die daar worden beantwoord. Daarna worden een aantal testen uitgevoerd en besproken. Om de werking van het protocol toch enigsinds te visualiseren wordt het stroomverloop gemeten van een sensor node en de ontvangstnode in werking. Een tweede test behelst het in kaart brengen van de error rate. Deze test moet een beeld geven van de effici¨entie en de robuustheid van het netwerk.
1 Software
1 1.1
66
Software Netwerkprotocol
Figuur 5.1 toont een flowchart van het volledige netwerkprotocol. Dit protocol werd reeds uitvoerig besproken in het hoofdstuk Netwerkprotocol”. De werking van de verschillende ” functies wordt verduidelijkt door de testen later in dit hoofdstuk. Initialize
Variable startup delay Listen on master channel
Yes
Master detected?
No
Scan slave channel: detect all used timeslots Initialize slave: use free timeslot
N=0
Timer interrupt
Initialize master
Wait in LPM for RX master data
Reset timer
Start timer with interrupt after (52+timeslot*20) ms
Wait in LPM for timeslot
Wake-up source ?
Send data
N++
Wait in LPM until timer = 10 ms
Reset timer
Send data
Master packet Become master
Change RF to TX on slave freq.
Change RF to RX on master freq.
Perform measurement
Yes
N = 256 ?
Perform measurement
No
Figuur 5.1: Flowchart van de sensor nodes.
Wait in LPM until timer = 10 ms
1 Software
1.2
67
Software ontvangstmodule
De flowchart van de ontvangstmodule is in wezen niet zo veel veranderd tegenover de originele ontvanger, wat niet wil zeggen dat de node zelf onveranderd is gebleven. . . De taak van deze node is gelijk aan die van de originele node, maar de hardware voorziet nu drie interfaces naar de PC: USB, Ethernet en Bluetooth.
Initialize
Read out data
Wait in LPM for RX master data
Change RF to duo-RX on slave frequencies
Reset timer
Wait in LPM for RX slavedata
Read out data Interrupt when timer = 7.5 ms
USB
Interface?
BT
UDP Send USB packet
Send UDP packet Change RF to RX on master freq.
Figuur 5.2: Flowchart van de ontvangstnode.
Send BT packet
1 Software
1.3
68
PDA applicatie
Om de Bluetooth-module eenvoudig te kunnen configureren zonder telkens een PC nodig te hebben werd een applicatie geschreven voor Windows Mobile PDA’s. Het voordeel hiervan is dat de applicatie ook werkt op een gewone Windows-PC. De applicatie kan verbinden met de module en gegevens lezen en zelfs instellingen aanpassen via Bluetooth. Er is ook een mogelijkheid om de sensor data weer te geven op de PDA, net zoals in de gewone PCapplicatie (een vereenvoudigde versie uiteraard). In figuur 5.3 is te zien hoe de instellingen vanuit de module worden gelezen op afstand. Het commando D” werd verzonden. De module ” beantwoordt deze vraag met zijn naam, baudrate,. . . De rechtse afbeelding toont hoe sensor data wordt uitgelezen op de PDA. De afbeeldingen werden gemaakt met een applicatie om screenshots te nemen op een Windows Mobile toestel.
Figuur 5.3: Opvragen van instellingen met een PDA (links) en sensor data weergeven (rechts).
2 Hardware
2
69
Hardware
Het ontwerp van de ontvangstmodule werd besproken in het hardware-gedeelte. Het resultaat is te zien in figuur 5.4. De module is redelijk compact gebleven, zoals te zien is in de figuur. De module is geprogrammeerd en werkt volledig. Alle interfaces zijn functioneel en de pakketten van de sensor nodes worden probleemloos ontvangen. Ook het gebruik van de DuoCeiver (wat niet gebruikt werd in de eerdere ontvanger) werkt feilloos. E´en klein probleempje was dat de Ethernet-functie behoorlijk veel tijd inneemt. Doordat er geen switch is voorzien op de module die aangeeft dat de verzending via Ethernet moet gebeuren had de MCU tijd te kort. Hij moest altijd de Ethernet-functie ´en de USB- of Bluetooth-functie doorlopen. De reden dat er een switch is voor USB-Bluetooth is omdat deze twee interfaces dezelfde UART-interface gebruiken. Het probleem met de Ethernet-interface was in principe moeilijk te voorspellen op het moment dat de PCB getekend werd. . . Een eerste oplossing was het gebruik van het intern statusregister van de Ethernet-chip, waar de staat van de Ethernet-link kan worden teruggevonden. Als de Ethernet-kabel aangesloten is, dan is de status up”, anders is ze down”. Door deze statusbit telkens op te vragen kan ” ” beslist worden of de Ethernet-functie moet opgeroepen worden of niet. Deze elegante oplossing leek in eerste instantie te werken, maar de betrouwbaarheid van de statusbit was onvoldoende. Soms staat de statusbit op 0, terwijl de Ethernet-kabel wel degelijk is aangesloten! Een voorlopige oplossing is het gebruik van de testpinnen op de module. Er werden een 4-tal meetpinnen voorzien, om debuggen mogelijk te maken. Op ´e´en van deze pinnen wordt een logische 1 gezet. De pin ernaast wordt gecontroleerd. Indien er een jumper geplaatst wordt op de twee pinnen, dan krijgt de andere pin ook een logische 1 en wordt de Ethernet-interface geselecteerd. Is er geen jumper aanwezig, dan wordt de USB-interface gebruikt. Indien de module in de toekomst zou worden herzien, kan dit eleganter worden opgelost. In plaats van een schakelaar met twee posities kan gebruik gemaakt worden van een schakelaar met drie posities. Daarnaast kan de andere switch (die de UART schakelt naar ofwel de USB, ofwel de BT) vervangen worden door een analoge switch. Daardoor zouden de twee schakelaars vervangen worden door ´e´en enkele schakelaar.
Figuur 5.4: PCB van de ontvangstmodule.
3 Testen
3
70
Testen
3.1
Stroommetingen
Door de aard van de applicatie is het niet zo eenvoudig om de werking van het netwerkprotocol in beeld te brengen. De correcte werking kan wel worden vastgesteld doordat de gegevens effectief toekomen op de PC, maar het visualiseren van het netwerkprotocol is niet zo evident. Een manier om de werking toch te kunnen nagaan is het meten van het stroomverbruik van een node. Telkens een node zendt of ontvangt zal er een duidelijke stroompiek optreden. In het labo werden een serie testen gedaan waarbij de stroom door de sensor nodes in een aantal toestanden werd opgemeten. 3.1.1
Master sensor node
De masternode zendt om de 10 ms een pakket, zonder dat hij moet synchroniseren met een andere node. Figuur 5.5 toont twee tijdslots van de masternode. Zoals de figuur laat zien liggen de tijdslots 10 ms uit elkaar, wat overeenkomt met de samplerate van 100 samples/s. Merk op dat dezelfde plot verkregen wordt voor een slave, tussen synchronisaties in, waar een slave immers ook autonoom zendt. Het gemiddeld stroomverbruik van de master is ongeveer 2.6 mA. 25
Current (mA)
20
15
10
5
0 0
2
4
6
8
10
12
14
16
18
Time (ms)
Figuur 5.5: Stroomverloop bij verzenden van pakketten van de masternode.
20
3 Testen 3.1.2
71
Synchronisatie slave sensor node
Een slave node moet om de 256 pakketten een synchronisatie met de master uitvoeren. Deze synchronisatie is niets anders dan luisteren op het masterkanaal tot een pakket wordt gedetecteerd. Dit is te zien in figuur 5.6. De grote piek, die start rond 12 ms is de eigenlijke synchronisatie: de slave zit hier in ontvangstmode op het masterkanaal. De figuur laat duidelijk zien dat het stroomverbruik in ontvangstmode hoger ligt dan in verzendmode. Net na de grote stroompiek is een kleinere piek te zien, waar de slave terug in verzendmode zit op het slave kanaal. De synchronisatie is in deze situatie dus perfect verlopen: de master is nog steeds actief. Doordat de synchronisatie maar ´e´en keer om de 256 pakketten moet gebeuren is het gemiddeld stroomverbruik van de slave node amper hoger dan dat van de master.
35
30 Synchronize with master
Send data
Current (mA)
25
20
15 Magnetometer 10 Low power 5
0 0
2
4
6
8
10
12
14
16
18
20
Time (ms)
Figuur 5.6: Synchronisatie van de slave: synchronisatie verloopt perfect.
Op de figuur zijn nog een aantal andere gebeurtenissen te zien. Net na iedere verzending is er een periode van een drietal milliseconden, waar de microcontroller in low-power mode zit en er toch zo’n 4 mA verbruikt wordt. Dit is het moment waar de magnetometer een nieuwe meting uitvoert. De datasheet van de YAS529 geeft inderdaad een stroomverbruik van 4 mA aan tijdens een meting. Na de meting van de magnetometer is er een periode waar alle componenten in low-power mode zitten. Ongeveer 1 ms voordat er een masterpakket toekomt zal de MCU gewekt worden en wordt de transceiver ingesteld voor ontvangst op het masterkanaal. Misschien is het moeilijk op het zicht te zien, maar de ontvangstpiek duurt maar zo’n 0.75 ms. De reden hiervoor is dat de transceiver 200 µs nodig heeft om vanuit stand-by naar RX-mode te gaan.
3 Testen 3.1.3
72
Synchronisatie slave sensor node: ´ e´ en masterpakket gemist
In het geval van figuur 5.6 verloopt de synchronisatie perfect. Het kan echter gebeuren dat een masterpakket niet ontvangen wordt. Een tijdelijke storing of een probleem met de master kan aan de basis liggen van deze situatie. Als er maar ´e´en pakket verloren gaat zullen de slaves nog niet ingrijpen. Er moeten ten minste 7 pakketten verloren gaan voordat ´e´en van de slaves zichzelf master maakt. Figuur 5.7 toont wat er gebeurt als er ´e´en masterpakket gemist wordt. 35 10 ms, until next master packet arrives
30
Current (mA)
25 Missed master packet 20
15
10
5
0 0
2
4
6
8
10
12
14
16
18
Time (ms)
Figuur 5.7: Synchronisatie van de slave: er wordt ´e´en masterpakket niet ontvangen.
Doordat de master maar ´e´en pakket verzendt elke 10 ms, duurt de synchronisatie 10 ms langer dan normaal.
3 Testen 3.1.4
73
Master weggevallen: slave neemt over
In de vorige gevallen slaagde de slave erin om te synchroniseren. Indien de master echter niet meer actief is, of verstoord wordt, dan zal de slave na een bepaalde tijd beslissen dat de master weggevallen is en neemt hij de rol van master op zich. Zoals uitvoerig werd besproken in het deel Netwerkprotocol” zal de slave met het kleinste tijdslotnummer master worden. ” De overname gebeurt immers na (52 + 20*tijdslot) ms, zodat het laagste tijdslot het snelst ingrijpt. In de situatie van figuur 5.8 wordt het stroomverloop getoond van de slave met tijdslotnummer ´e´en, de eerste opvolger indien de master wegvalt. . .
30
25
Send first packet as master
Current (mA)
20
≈ 72 ms
15
10
5
0 0
20
40
60
80
100
120
Time (ms)
Figuur 5.8: Masternode valt weg: slave neemt over.
We zien inderdaad dat de slave ongeveer 72 ms wacht en daarna de rol van master overneemt. Net na de brede stoompiek (ontvangstmode, te zien aan de grote stroom) komt onmiddellijk een nieuw stroompiekje. Deze stroompiek is kleiner dan de brede piek, wat erop wijst dat het gaat om een verzending. Wanneer de slave beslist dat de master inactief is, zal hij zelf master worden en zo snel mogelijk een eerste pakket verzenden, om te voorkomen dat de slave met tijdslotnummer twee ook master zou worden. In principe heeft hij dus 20 ms de tijd om zichzelf master te maken en zijn eerste pakket te verzenden.
3 Testen 3.1.5
74
Master conflict check
Een ander belangrijk mechanisme in het dynamisch protocol is de master conflict check. Doordat elke node nu master kan worden moet er ergens een controlemechanisme zijn die zorgt dat er nooit meerdere masters aanwezig zijn. In het ideale geval is dit niet mogelijk, maar dit komt zeker voor in de praktijk. Stel dat er een tijdelijke storing is op het masterkanaal, waardoor de slaves de master niet ontvangen, dan kan een slave master worden, terwijl de eigenlijke master nog steeds online is! Er zijn op dat moment twee masters aanwezig, wat leidt tot conflicten! Een andere reden kan zijn dat een slave tijdelijk buiten het bereik van de master is (te ver van elkaar), waardoor de slave master wordt. Als hij terug binnen het bereik van de originele master komt zijn er eveneens twee masters in het netwerk. De oplossing voor dit probleem is een procedure, waar de master periodisch even luistert op het masterkanaal om te detecteren of er geen andere masters aanwezig zijn. Deze procedure gebeurt ´e´en keer om de vijf `a tien seconden (gedeeltelijk random). Figuur 5.9 toont het verloop van deze procedure. Net voor de conflict check zal de master nog een laatste pakket verzenden. Onmiddellijk na dit pakket schakelt hij over op ontvangstmode op het masterkanaal. Hij luistert gedurende 10 ms op het masterkanaal: aangezien iedere node om de 10 ms een pakket zendt, zal een tweede (eventuele) master zeker gedetecteerd worden binnen deze periode. 40
Master conflict check 35
Current (mA)
30
25
Send data 20
15
10
5
0 0
2
4
6
8
10
12
14
16
18
20
22
Time (ms)
Figuur 5.9: Master conflict procedure.
Opvallend is dat het stroomverbruik in het begin van de master conflict check hoger ligt. De reden is dat de magnetometer een meting uitvoert. Een andere belangrijke opmerking is dat de master ´e´en pakket overslaat na de master conflict check. Om er zeker van te zijn dat er geen andere masters aanwezig zijn moet de master namelijk 10 ms luisteren op het masterkanaal, waardoor hij het volgende pakket niet op tijd kan verzenden. Doordat deze controle maar ´e´en keer om de 10 seconden gebeurt is dit niet zo’n groot probleem.
3 Testen
3.2
75
Packet error rate
Een andere nuttige test is de packet error rate (PER), die bepaalt hoeveel procent van de pakketten verloren gaan. Als we deze PER uitzetten in functie van de afstand, zien we de betrouwbaarheid van het netwerk voor verschillende afstanden. Door een bepaalde randvoorwaarde op te leggen voor deze PER kan op deze manier de maximale werkafstand worden bepaald. 3.2.1
Testcode voor de ontvangstmodule
Om deze test uit te voeren werd een aparte testcode geschreven voor de ontvangstmodule. In de code kan een waarde worden ingesteld, die de duur van de meting vastlegt. Deze wordt uitgedrukt als een veelvoud van 10 ms en is dus in ideale omstandigheden (100 % ontvangst) gelijk aan het aantal pakketten die ontvangen worden. Na elke meetcyclus wordt het aantal effectieve pakketten doorgegeven in een UDP-pakket. Delen we dit getal door het aantal pakketten in ideale omstandigheden, dan krijgen we het percentage van de verzonden pakketten die goed worden ontvangen. 3.2.2
De test
De eerste test werd gedaan op een pleintje, waar er een directe “line of sight” is. Anderzijds zijn er wel een aantal bomen aanwezig en de afstand tot de huizen is niet zo groot. Hierdoor zal er toch enige invloed zijn van reflecties, maar vooral WiFi zou wel eens voor problemen kunnen zorgen. De afstand tot de dichtstbijzijnde WiFi-bron bedraagt amper een 10-15 m en deze bron lijkt redelijk sterk uit te zenden. Het resultaat is te zien in figuur 5.10. 100 Meetdata Lineaire interpollatie
Ontvangen pakketten [%]
90
80
70
60
50
40
30 0
5
10
15
20
25
Afstand [m]
Figuur 5.10: Aantal ontvangen pakketten (relatief) in functie van de afstand tot de receiver.
3 Testen
76
Bovenstaande figuur toont het aantal pakketten (relatief tegenover het aantal verzonden pakketten) die goed ontvangen werden. Figuur 5.11 toont de PER van deze meting. Binnen een straal van 5 m gaat er maximaal 30% van de samples verloren, maar eens de afstand 15 m of meer bedraagt gaat het sampleverlies snel de hoogte in. Bij een afstand van 20 m gaat reeds 60 % van de pakketten verloren.
70
60
PER (%)
50
40
30
20
10
0 0
5
10
15
20
25
Afstand [m] Figuur 5.11: PER in functie van de afstand.
Opvallend is de meting bij een afstand van 10 m, waar opeens weer meer pakketten worden ontvangen dan op 5 m afstand. Dit is een indicatie dat de meting misschien niet helemaal betrouwbaar is door de externe invloeden. Daarom werd beslist een tweede meting uit te voeren in een open veld, ver weg van huizen en bij afwezigheid van allerhande stoorbronnen. Bij de vorige meting werden er telkens 500 pakketten verzonden en werd elke meting 10 keer herhaald. Om de meting nog exacter te doen, werden voor de tweede meting telkens 1000 pakketten verzonden en werd iedere meting 15 keer herhaald. Het resultaat is te zien in figuren 5.12 en 5.13.
3 Testen
77
100 Meetdata Lineaire interpollatie
Ontvangen pakketten [%]
90 80 70 60 50 40 30 20 10 0 0
10
20
30
40
50
60
70
80
90
Afstand [m]
Figuur 5.12: Aantal ontvangen pakketten (relatief) in functie van de afstand tot de receiver.
100 90 80
PER [%]
70 60 50 40 30 20 10 0 0
10
20
30
40
50
60
70
80
90
Afstand [m]
Figuur 5.13: PER in functie van de afstand.
Zoals de figuren laten zien is er een zeer groot verschil met de eerste metingen! Op het platteland wordt op een afstand van zo’n 65 m nog ongeveer de helft van de pakketten goed ontvangen. In een bebouwde omgeving wordt er vanaf 30 m zo goed als niets meer ontvangen. . . Het verschil is te wijten aan een aantal factoren. Op het platteland was er altijd een directe line of sight, waren er zo goed als geen objecten die voor reflectie konden zorgen, waren er geen huizen in de nabije omgeving (dus ook geen last van WiFi en andere),. . .
BESLUIT
78
Hoofdstuk 6
Besluit 1
Besluit
De bedoeling van dit eindwerk was het ontwerp en de implementatie van een netwerkprotocol voor een draadloos sensor netwerk. Het sensor netwerk wordt gebruikt voor de reconstructie van menselijke bewegingen. Om deze bewegingen met een voldoende nauwkeurigheid te kunnen opvolgen zijn er minimaal 100 samples per seconde nodig. Verder is het zo dat het menselijk lichaam bij benadering kan voorgesteld worden als een star lichaam bestaande uit 15 beweegbare delen [5]. Het netwerk moet dus minimaal 15 nodes kunnen laten communiceren, elk aan een samplerate van 100 samples per seconde. Het originele netwerk voorzag in maximaal 10 sensor nodes.
1.1
15 sensor nodes
Omdat elk tijdslot ongeveer 1 ms inneemt en er sowieso 100 samples per seconde nodig zijn kunnen er niet meer dan 10 nodes worden opgenomen in het netwerk. Om deze uitbreiding toch mogelijk te maken werd de DuoCeiver-functie van de transceiver gebruikt. Deze DuoCeiver-functionaliteit laat toe om data te ontvangen op twee frequentie-kanalen op hetzelfde moment met dezelfde antenne. Hierdoor kan het huidige protocol maximaal 19 nodes laten communiceren. De lezer verwacht misschien eerder 20 nodes, daar er nu twee kanalen zijn en er voordien 10 nodes aanwezig waren. . . Zoals figuur 6.1 laat zien zijn er twee slave kanalen en per slave kanaal kunnen er negen slaves opereren. Het tweede kanaal synchroniseert immers ook op dezelfde master!
[Channel] Master channel
Master
Master
Master
Slave channel 1
Slave 1
Slave 2
…
Slave 8
Slave 9
Slave 1
Slave 2
…
Slave 8
Slave 9
Slave channel 2
Slave 10
Slave 11
…
Slave 17
Slave 18
Slave 10
Slave 11
…
Slave 17
Slave 18
0 ms
10 ms
Figuur 6.1: Principe van 2 slave kanalen.
20 ms
[t]
1 Besluit
1.2
79
Dynamisch protocol
Een andere vereiste is dat het netwerkprotocol volledig dynamisch is. Dat wil zeggen dat: De MCU van alle nodes exact dezelfde software bevat (dus geen hard gecodeerde tijdslots of andere parameters). Er wordt bij opstart van het netwerk automatisch ´e´en node geselecteerd die de rol van master krijgt. Indien een node bij opstart slave wordt (als er reeds een master aanwezig is), dan wordt er automatisch een vrij tijdslot gekozen. Als de master om ´e´en of andere reden wegvalt, neemt exact ´e´en slave de rol van master over. Mocht er door een storing of een ongewone situatie een toestand ontstaan, waarin er meer dan ´e´en master in het netwerk aanwezig is, dan moet dit automatisch worden opgelost. Na verloop van tijd moet het netwerk zichzelf dus terug hersteld hebben naar de staat waarin er exact ´e´en master is.
Het ge¨ımplementeerde netwerkprotocol voldoet aan al deze eisen en mag dus wel degelijk “dynamisch” genoemd worden.
1.3
Meerdere personen opvolgen
Een laatste belangrijke uitbreiding was het opvolgen van meerdere personen op dezelfde PC. Het mag wel duidelijk zijn dat dit niet zo vanzelfsprekend is, gezien we al moeite moesten doen om meer dan 10 nodes op te nemen in het netwerk! Het is dus sowieso uitgesloten om dezelfde frequentieband te gebruiken voor elke persoon. Het is wel mogelijk om elke persoon een andere frequentie te geven, zodat de netwerken elkaar niet verstoren. Zonder verdere uitbreiding zou dit echter leiden tot ´e´en ontvangstmodule per persoon op de PC. Dit is misschien haalbaar voor twee of drie personen, maar deze werkwijze wordt al snel onbruikbaar. . . Een beter oplossing is het gebruik van een ander standaard draadloos netwerkprotocol, zoals Bluetooth. In de eerdere versies was de ontvangstnode fysiek aanwezig bij de PC. Als we dit idee laten varen en deze node op de persoon zelf aanbrengen, dan kan de ontvangstnode alle data van de sensoren ontvangen en in grote pakketten doorsturen naar de PC. Deze grote pakketten verstuurt hij dan via Bluetooth, die een hogere datarate heeft dan het sensor netwerk zelf. Het voordeel van Bluetooth is dat er geen speciale hardware nodig is op de PC zelf. De meeste laptops hebben reeds een Bluetooth ontvanger aan boord. Een ander alternatief is het gebruik van Ethernet. Met een eenvoudige switch, kunnen er direct meerdere ontvangers op het netwerk aangesloten worden. Elke PC op het netwerk ontvangt nu deze data, wat ook een groot voordeel kan zijn. Zoals besproken werd bij de resultaten is er een ontvangstmodule ontwikkeld, die via USB, Ethernet of Bluetooth kan gekoppeld worden met een PC. Er kunnen dus zonder probleem meerdere personen opgevolgd worden.
2 Future work
2
80
Future work
In theorie zijn alle doelstellingen bereikt die in het begin van het project werden vastgelegd. Toch zijn er nog een aantal punten, die voor verbetering vatbaar zijn. Momenteel wordt de Bluetooth-link gebruikt als SPP (Serial Port Profile). Hierdoor kan niet de maximale snelheid gehaald worden die de Bluetooth-specificatie voorschrijft. Om Bluetooh optimaal te benutten zou er eigenlijk een eigen HCI-stack geschreven moeten worden. Dit zou toelaten om de gewone Bluetooth HCI-mode te gebruiken in plaats van de tragere SPP. . . Daarnaast zou de ontvangstmodule beter voorzien worden van ´e´en enkele interface, in plaats van drie zoals nu. Deze redundantie was nodig om alle interfaces te kunnen testen, maar als de module effectief op de persoon moet worden aangebracht is de node misschien iets te groot. De USB- en Ethernet-interface zijn uiteindelijk toch overbodig als de node op de persoon aangebracht wordt. . .
INTERFACES EN COMMUNICATIEPROTOCOLLEN
81
Bijlage A
Interfaces en communicatieprotocollen 1 1.1
I2 C De I2 C-bus
De Inter-Integrated Circuit bus, of I2 C-bus, is een communicatiebus die bestaat uit twee lijnen: een kloklijn(SCL) en een datalijn(SDA). Het I2 C-protocol is iets ingewikkelder dan het SPIprotocol (zie verder), daar er maar 1 datalijn is en er eveneens geen selectielijn aanwezig is. Op de I2 C-bus kunnen er zelfs meerdere masters aanwezig zijn. Om de verschillende toestellen aan te spreken wordt er gebruik gemaakt van een uniek adres. De I2 C-bus is te zien in figuur A.1.
Figuur A.1: De I2 C-bus.
De twee lijnen zijn open-drain, zoals te zien is in figuur A.2. De verschillende devices kunnen de lijn enkel laag trekken, niet hoog. Vandaar is het nodig dat er pull-up weerstanden voorzien worden. De meeste IC’s zijn echter intern voorzien van een pull-up weerstand, waardoor de designer hier veelal geen rekening moet mee houden.
1 I2 C
82
Figuur A.2: De fysische opbouw van de I2 C-bus.
1.2
Datatransmissie
Een device kan ofwel master of slave zijn. Net zoals bij SPI is het de master die bepaalt wanneer een datatransmissie plaatsvindt. Een groot verschil van I2 C tegenover SPI is dat er maar ´e´en datalijn is, zodat verzenden en ontvangen niet in parallel gebeuren. Als een master een transmissie wil starten, plaatst hij de startconditie op de lijnen. Daarna adresseert hij een bepaalde slave met het 7-bit lange slave-adres, gevolgd door ´e´en enkele bit die aangeeft als het gaat om een lees- (1) of schrijfoperatie (0). Bij een schrijfoperatie zendt de master byte per byte door naar de slave. De slave zal na iedere byte een ACK zenden, ter bevestiging van ontvangst. Indien het een leesoperatie betreft, zendt de slave byte per byte door. Na iedere byte moet de master een ACK op de lijnen plaatsen, om aan te geven dat hij de data ontvangen heeft en dat hij nog meer data wil ontvangen. Wil de master geen nieuwe data meer ontvangen, dan zendt hij gewoon geen ACK meer. De startconditie bestaat uit het laag trekken van de SDA-lijn, terwijl de SCL-lijn hoog staat. De stopconditie is net het omgekeerde: een stijgende flank van SDA, terwijl SCL hoog staat. Beide condities zijn te zien in figuur A.3.
Figuur A.3: De start- en stopcondities op de I2 C-bus.
1 I2 C
83
Het verloop van datatransmissie op de I2 C-bus is te zien in figuur A.4. Zoals te zien is in de figuur bestaat een ACK uit het laag trekken van de SDA-lijn. De SDA-lijn wordt gelezen als SCL hoog is, zodat het veranderen van de waarde op de SDA-lijn enkel mag als SCL laag is! Doordat de lijnen open-drain zijn kan elke device de lijn laag trekken. Dat wil zeggen dat een ontvanger (dus ook een slave) de SCL-lijn kan laag trekken na het ontvangen van een byte, zodat de zender moet wachten met het verzenden van de volgende byte. Op die manier wordt voorkomen dat de ontvanger de data niet tijdig kan verwerken en dat er conflicten optreden.
Figuur A.4: Datatransmissie op de I2 C-bus.
Een iets overzichtelijkere weergave van de datatransmissie over de I2 C-bus is te zien in figuur A.5. In deze figuur staat S voor de startconditie, P voor de stopconditie en R/W is de bit die bepaalt of de master wil lezen of schrijven.
Figuur A.5: Datatransmissie op de I2 C-bus.
Bij I2 C kunnen er meerdere masters op de bus aanwezig zijn. De master die als eerste een startconditie op de lijnen zet heeft de volledige controle over de bus, tot het moment dat hij een stopconditie verzendt. Stel dat een master de bus niet wil vrijgeven, maar wel een andere slave wil aanspreken, of hij wil overschakelen van zend- naar ontvangstmode of omgekeerd, dan kan hij gebruik maken van een repeated start-conditie. In plaats van een stopconditie te zenden zendt de master opnieuw een start-conditie, gevolgd door het adres en de R/W bit. Op die manier verzekert de master zich ervan dat hij de buscontrole niet verliest. Het timingdiagram van deze situatie is te zien in figuur A.6.
Figuur A.6: Datatransmissie op de I2 C-bus: repeated start-conditie.
1 I2 C
1.3
84
Implementatie op de MSP430F249
De MSP430F249 beschikt over een dedicated I2 C-module”. Hierdoor is het gebruik van de ” I2 C-interface niet zo moeilijk. Een blokschema van de I2 C-module is te zien in figuur A.7.
Figuur A.7: Blokschema van de I2 C-module van de MSP430F249.
De werking van de I2 C-module is gemakkelijk te begrijpen aan de hand van het blokschema. Het onderste deel van het schema is de klokgenerator. Zowel de klokbasis als de klokdeler kan worden ingesteld om de juiste kloksnelheid te bekomen. Deze klok wordt gebruikt voor de SCL-lijn, maar ook voor de interne schuifregisters. Deze schuifregisters moeten immers data binnenklokken/uitklokken aan het ritme van deze klok. Als een volledige byte ontvangen is zal deze worden overgebracht naar de ontvangstbuffer. Om een byte te verzenden wordt de verzendbuffer geladen. De controller zal deze data vervolgens overbrengen naar het TXschuifregister om ze daarna te verzenden. De initialisatie van de I2 C-module bestaat uit het instellen van de mode(I2 C), het type (master/slave) en de kloksnelheid. Dit gebeurt door onderstaand codefragment.
De snelheid wordt zo dicht mogelijk bij 400 kHz ingesteld, de maximale snelheid op de I2 Cbus. Om een datatransmissie te starten met een bepaalde slave moet het slave-adres eerst in het slave-adres register geschreven worden (zie blokschema). Dit gebeurt met behulp van de Set I2CAddress-functie: void Set_I2CAddress(unsigned char Address) { UCB0CTL1 |= UCSWRST; UCB0I2CSA = Address; UCB0CTL1 &= ~UCSWRST; IE2 |= UCB0TXIE | UCB0RXIE; }
Daarna wordt de functie Send I2C opgeroepen, met als argumenten de TxData en het aantal te verzenden bytes. In de functie wordt een pointer ingesteld op het startadres van de TxData en wordt de bytecounter geladen. Daarna wacht de functie, indien nodig, tot de vorige data volledig verzonden is. Vervolgens wordt de startconditie op de lijnen geplaatst en gaat de MCU in low-power mode. De verdere afhandeling van de transmissie gebeurt in de interrupt routine (zie straks). void Send_I2C(unsigned char TxData[], unsigned char BytesToSend) { PTxData = (unsigned char *)TxData; // TX array start address TXByteCtr = BytesToSend; // Load TX byte counter while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent UCB0CTL1 |= UCTR | UCTXSTT; // I2C TX and start condition __low_power_mode_0(); // Enter LPM0 w/ interrupts // Remain in LPM0 until all data // is TX’d }
Figuur A.10: Send I2C procedure.
Om data te ontvangen wordt de Receive I2C-functie opgeroepen. Deze functie is zeer gelijkaardig aan de Send I2C-functie. void Receive_I2C(unsigned char BytesToReceive) { PRxData = (unsigned char *)RxBuffer; // Start of RX buffer RXByteCtr = BytesToReceive; // Load RX byte counter while (UCB0CTL1 & UCTXSTP); // Ensure stop condition got sent UCB0CTL1 &= ~UCTR; // Set to receiver mode UCB0CTL1 |= UCTXSTT; // I2C start condition __low_power_mode_0(); // Enter LPM0 w/ interrupts // Remain in LPM0 until all data // is RX’d }
Figuur A.11: Receive I2C procedure.
1 I2 C
87
Er wordt een interrupt gegenereerd als de TX-buffer vrij is, of als de Rx-buffer nieuwe data bevat. In de ISR wordt vervolgens bepaald of er nog data verzonden/ontvangen moet worden, of als de stop-conditie op de lijnen moet geplaatst worden. #pragma vector = USCIAB0TX_VECTOR __interrupt void USCIAB0TX_ISR(void) { if (UCB0CTL1 & UCTR) { if (TXByteCtr) { UCB0TXBUF = *PTxData++; TXByteCtr--; } else { UCB0CTL1 |= UCTXSTP; IFG2 &= ~UCB0TXIFG; __low_power_mode_off_on_exit(); } } else { RXByteCtr--; if (RXByteCtr) { *PRxData++ = UCB0RXBUF; if (RXByteCtr == 1) UCB0CTL1 |= UCTXSTP; } else { *PRxData = UCB0RXBUF; __low_power_mode_off_on_exit(); } } }
// I2C stop condition // Clear USCI_B0 TX int flag // Exit LPM0
// Decrement RX byte counter
// Move RX data to address PRxData // Only one byte left? // Generate I2C stop condition
// Move final RX data to PRxData // Exit LPM0
Figuur A.12: I2C ISR.
Indien de controller in verzendmode zit en er moeten nog bytes verzonden worden, wordt de verzendbuffer geladen met de volgende byte en wordt de bytecounter gedecrementeerd. Als alle bytes verzonden zijn, zal de stopconditie op de lijnen geplaatst worden en wordt de TX interrupt vlag gewist (bij verzenden van data gebeurt dit automatisch, enkel de laatste keer moet dit manueel gebeuren). Ontvangst van data is vrij gelijkaardig: lees de ontvangen data uit de buffer en plaats de stopconditie als alle bytes ontvangen zijn.
2 UART
2 2.1
88
UART UART-interface
De afkorting UART staat voor Universal Asynchronous Receiver Transmitter. In tegenstelling tot de SPI-interface en de I2 C-interface is de UART geen busprotocol. Met een UARTinterface wordt een rechtstreekse connectie gemaakt tussen twee componenten. De UARTconnectie is daardoor zeer eenvoudig en bestaat slechts uit 2 lijnen: RXD en TXD. Figuur A.13 toont een UART-connectie tussen twee IC’s. De lijnen worden uiteraard kruiselings verbonden.
Figuur A.13: UART-connectie tussen twee devices.
2.2
Datatransmissie
Als er geen transmissie bezig is, dan staat de TXD-lijn hoog (Idle). Om transmissie te starten wordt de startbit op de TXD-lijn geplaatst. Deze startbit is altijd een 0, zodat de ontvanger de startbit kan detecteren (In idle toestand staat de lijn immers hoog). Daarna worden de 7 of 8 databits verzonden (afhankelijk van de instelling). Doordat er geen kloklijn aanwezig is, moeten beide toestellen voorzien zijn van een interne klok, die ingesteld is op dezelfde baudrate. Na de databits volgt een pariteitsbit (optioneel) en ´e´en of twee stopbits. De stopbits zijn steeds 1, zodat de lijn na deze stopbit(s) weer in de idle mode terecht komt. Figuur A.14 toont de vorm van zo’n UART-frame. In de figuur zijn er 8 databits te zien (kan ook 7 zijn), een pariteitsbit en ´e´en stopbit.
Figuur A.14: UART frameformaat.
2 UART
2.3
89
Implementatie op de MSP430F249
De MSP430F249 beschikt over een UART-module, wat de implementatie uiterst eenvoudig maakt. Bij initialisatie moeten een aantal instellingen gebeuren, zoals de baudrate, het aantal databits per transmissie (7/8), de pariteit en het aantal stopbits. Onderstaand codefragment zorgt bijvoorbeeld voor de configuratie van de UART-interface tussen de MCU en de FT232Rchip. void UART_USB_Config(void) { //UART settings for PC-USB TX/RX on USCA0 P3SEL |= (1<
Figuur A.15: UART configuratie.
Verzenden van data via de UART is zeer eenvoudig. Er wordt gewacht tot de vorige verzending afgelopen is en vervolgens wordt de nieuwe data in de verzendbuffer geplaatst, zoals onderstaande code laat zien. void putchar(int c) { while ((IFG2 & UCA1TXIFG) == 0); UCA1TXBUF = (unsigned char)c; }
Figuur A.16: UART verzending.
Voor de ontvangst van data kan een interrupt ingesteld worden. Bij ontvangst van data wordt gesprongen naar de interrupt routine, waar de data van de RX-buffer gelezen wordt van zodra de ontvangst is afgelopen. #pragma vector = USCIAB1RX_VECTOR __interrupt void USCI1RX_ISR(void) { while (!(UC1IFG&UCA1RXIFG)); rec = UCA1RXBUF; }
// USCI_A1 RX buffer ready?
Figuur A.17: UART ontvangst.
3 SPI
3
90
SPI
3.1
De SPI-interface
SPI staat voor Serial Peripheral Interface, een standaard voor full-duplex synchrone seri¨ele communicatie. De verschillende apparaten communiceren volgens een master-slave structuur, waarbij de master de communicatie controleert. Een standaard SPI-interface bestaat uit 4 lijnen: MOSI: Master Out Slave In MISO: Master In Slave Out SCLK: Serial Clock SS: Slave Select
Doordat er gewerkt wordt met een selectie-signaal, kunnen er meerdere slaves op dezelfde bus aangesproken worden zonder dat er adressering nodig is. Figuur A.18 toont een SPI-bus met 1 master en 3 slaves. De verschillende slaves worden aangesproken door het juiste slave select signaal laag te brengen.
Figuur A.18: SPI-bus met meerdere slaves.
Als er maar 1 slave aanwezig is, dan is het selectie-signaal overbodig. Dit wordt soms ook een 3-pin mode” SPI-interface genoemd. Dit is ook de mode die in dit project gebruikt wordt. ”
3.2
Datatransmissie
De communicatie wordt volledig beheerd door de master. Als de master data wil verzenden/ontvangen activeert hij de slave en start hij de klok. Tijdens iedere klokperiode wordt er zowel data verzonden als ontvangen. Master en slave zullen afwisselend elk een bit verzenden. Afhankelijk van de instellingen zal de master zijn data verzenden op de stijgende of dalende klokflank op de MOSI-lijn. Ontvangst van data op de MISO-lijn gebeurt op de andere klokflank. In principe hebben de master en de slave elk een schuifregister die in een ring geschakeld zijn (figuur A.19).
3 SPI
91
Figuur A.19: Principe van datatransmissie bij SPI.
Uit deze figuur is duidelijk dat de master altijd data moet verzenden, zelfs als hij enkel data wenst te ontvangen van de slave. In dat geval zal de master gewoon don’t care data” ” verzenden. SPI-communicatie kan in principe software-matig tot stand gebracht worden, maar de meeste MCU’s beschikken over een communicatie-interface die SPI-mode ondersteund. Een blokschema van de SPI-interface van de MSP430F249 is te zien in figuur A.20.
Figuur A.20: Blokschema van de SPI-interface van de MSP430F249.
De werking van deze module is zeer gelijkaardig aan het eenvoudige principeschema van figuur A.19. De SPI-module beschikt wel over een aparte verzend- en ontvangstbuffer, elk met hun eigen schuifregister. Om transmissie tot stand te brengen wordt het TX-schuifregister geladen met de inhoud van de TX-buffer. Daarna wordt de data uit het verzendregister uitgeklokt, terwijl data van de slave wordt binnengepakt in het ontvangstregister. Als een byte volledig is verzonden/ontvangen wordt de hele inhoud van het ontvangstregister overgebracht naar de ontvangstbuffer. Als de data uit de TX-buffer overgebracht is naar het TX-schuifregister wordt een vlag gezet, die aangeeft dat het veilig is om nieuwe data naar de TX-buffer te schrijven. Er wordt eveneens een vlag gezet als de data uit de ontvangstbuffer gelezen mag worden.
3 SPI
3.3
92
Implementatie op de MSP430F249
SPI-communicatie op de MSP430F249 is zeer eenvoudig, daar deze MCU beschikt over een USCI-module met SPI-mode. Om deze module in te stellen zijn een aantal registers voorzien in de MCU. Onderstaand codefragment toont de configuratie van ´e´en van de SPI-modules. Eerst worden de 3 gebruikte pinnen ingesteld als peripheral-pinnen”. De module wordt vervolgens ” ingesteld in 8-bit SPI master mode. Vervolgens wordt ingesteld welke klok gebruikt wordt, en of deze al dan niet gedeeld moet worden om een lagere baudrate te bekomen. Aangezien deze module gebruikt wordt voor de SPI-communicatie met de transceiver wordt de baudrate ingesteld op 1 MHz, de maximale snelheid die de transceiver aankan. void SPI_Config(void) { //SPI settings for nRF TX/RX on USCB0 P3SEL |= (1<<SIMOB0)|(1<<SOMIB0)|(1<
// // // // // //
SIMOB, SOMIB and CLK1 as peripheral 3-pin, 8-bit SPI master SMCLK Clock devider = 16 => 1 MHz **Initialize USCI state machine**
Figuur A.21: SPI Config procedure.
Om data te verzenden wordt er gewacht tot de TXIFG-vlag hoog komt, wat erop wijst dat de TX-buffer klaar is om geladen te worden met nieuwe data. Daarna wordt de te verzenden data in de TXBUF geladen en de SPI-controller regelt verder de volledige communicatie. Dit is te zien in het volgend codefragment: void SPI1_Send(unsigned char data) { while ((IFG2 & UCB0TXIFG) == 0); UCB0TXBUF = data; }
// Wait for previous character to be fully transmitted // Put the new data in the buffer
Figuur A.22: SPI1 Send procedure.
Ontvangst van data is eveneens redelijk eenvoudig. Zoals reeds gezegd werd is het nodig om data te verzenden, zelfs als er niks nuttigs te verzenden is. Daarom wordt er gewoon don’t care data verzonden (in dit geval het karakter x”). Als de data ontvangen is, wordt de ” RXIFG-vlag gezet door de SPI-controller. Op dat moment is het veilig om de ontvangstbuffer uit te lezen.
Clear RX interrupt flag Send don’t care data while receiving Wait for complete reception Return the received data
Figuur A.23: SPI1 Get procedure.
4 User Datagram Protocol (UDP)
4
94
User Datagram Protocol (UDP)
Naast USB- en Bluetooth-pakketten kan de ontvangstmodule ook via UDP-segmenten communiceren met de PC. Het UDP-protocol is ´e´en van de netwerkprotocollen uit de Internet Protocol Suite (TCP/IP). Het UDP-protocol staat op hetzelfde niveau als het TCP-protocol en bevindt zich dus in de transportlaag (4e laag van het OSI-systeem). De UDP-segmenten worden vervolgens verpakt in IP-datagrammen (netwerklaag van het OSI-systeem). Transport van de IP-datagrammen gebeurt met behulp van Ethernet-frames. De Ethernet (IEEE 802.3) standaard definieert de twee onderste lagen van het OSI-systeem, namelijk de MAClaag (datalinklaag) en de PHY-laag. Figuur A.24 toont het algemene OSI-model (links) en de gebruikte lagen (rechts). De onderste twee lagen worden hardwarematig ondersteund door de ENC28J60 Ethernet-controller. De netwerklaag en de transportlaag worden softwarematig ge¨ımplementeerd in de microcontroller. De hogere lagen worden niet gebruikt en worden dan ook niet verder besproken.
Applicatie Presentatie Sessie
Transport
UDP
Netwerk
Ipv4
Datalink
Ethernet:
Fysiek
geïmplementeerd door ENC28J60
Algemeen OSI-model
Specifiek
Figuur A.24: OSI-model.
De verschillende lagen van het OSI-systeem (figuur A.24) zijn duidelijk aanwezig in de code. Elke laag werd in een ander bestand gemaakt, waardoor de code overzichtelijk blijft en later nog uitgebreid kan worden indien nodig. Voor de Ethernet-communicatie zijn er vier bestanden aangemaakt: UDP.c: Opbouw van een UDP-segment. IP.c: Opbouw van een IP-datagram. MAC.c: Opbouw van een MAC-frame (enkel de MAC header en de data payload). enc28j60.c: Aansturing van de Ethernet-controller.
4 User Datagram Protocol (UDP)
95
Om data te verzenden wordt eerst een UDP-segment opgebouwd. De inhoud van zo’n segment is te zien in figuur A.25. De data van zo’n UDP-segment is de sensor data zelf. Er wordt geen gebruik gemaakt van een UDP-checksum (instellen op 0). Source port
Destination port
Length
Checksum
Data
Figuur A.25: Inhoud van een UDP-segment.
Nadat het UDP-segment is opgesteld, wordt een functie opgeroepen die een IP-datagram samenstelt. Het UDP-segment wordt als argument meegegeven aan deze functie, want de data-payload van een IP-datagram is uiteraard een UDP-segment. Figuur A.26 toont de vorm van een IP-datagram.
Figuur A.26: Inhoud van een IP-datagram.
4 User Datagram Protocol (UDP)
96
Zoals bovenstaande figuur aantoont is een IP-datagram een stuk uitgebreider dan een UDPsegment. De verschillende onderdelen van zo’n IP-datagram zijn: Version: IP versie, in dit geval wordt gewerkt met IPv4, gecodeerd als 4. Header length: Dit veld wordt ook soms de IHL (Internet Header Length) genoemd. Deze IHL is gelijk aan het aantal 32-bit woorden in de IP header. Indien er geen opties gebruikt worden, zoals in dit project, dan is deze lengte gelijk aan vijf (160 bits). Type of Service: Dit veld is 8 bits groot en bepaalt de prioriteit van het pakket, de delay,. . . Total length: Totale lengte van het datagram, uitgedrukt in bytes. Identification: Identificatie van een IP-fragment. Dit wordt niet gebruikt en is gewoon ingesteld op 0x0000. Flags: Instellingen voor fragmentatie. Indien geen fragmentatie gebruikt wordt, is deze byte ingesteld op 0x40. Fragment offset: Gezien er geen fragmentatie gebruikt wordt speelt dit veld geen rol en bevat deze byte weerom 0x00. Time To Live: Tijd in seconden, die bepaald hoe lang een IP-datagram blijft bestaan. Dit voorkomt dat een datagram oneindig lang blijft rondcirkelen. Protocol: Bepaalt welk transportprotocol gebruikt wordt. In ons geval UDP, gecodeerd als 0x11. Header checksum: Deze checksum controleert de header op fouten. Source address: IP-adres van de bron. Destination address: Bestemmingsadres, in ons geval het broadcast adres 255.255.255.255, waardoor de data op elke interface ontvangen wordt die zich op het netwerk bevindt. Options: Niet gebruikt. Data: De data van een IP-datagram is een UDP-segment.
4 User Datagram Protocol (UDP)
97
Het transport van de IP-datagrammen gebeurt met behulp van Ethernet-frames. De opbouw van een Ethernet-frame is te zien in figuur A.27. Doordat de controller het Ethernet-protocol ondersteunt, moet er geen rekening gehouden worden met de synchronisatie header en de FCS. Enkel de MAC-header en de data payload moeten worden verzonden naar de ENC28J60. Op netwerkniveau wordt gewerkt met het IPv4-protocol, waardoor het type-veld wordt ingesteld op 0x0800 (hexadecimaal). De adressen op Ethernet-niveau zijn MAC-adressen en zijn bijgevolg 6 bytes lang. Het bestemmingsadres wordt ingesteld op FF-FF-FF-FF-FF-FF, het broadcast adres. 7 bytes 1 byte Preamble SFD Synchronization header
6 bytes 6 bytes Destination address Source address MAC header
2 bytes Type/length
variabel Data Padding Data payload
4 bytes FCS CRC
Figuur A.27: Opbouw van een Ethernet pakket.
Onderstaande figuur toont de totale inhoud van een Ethernet-frame. Hierin wordt de relatie tussen de verschillende OSI-lagen duidelijk zichtbaar.
Ethernet frame Preamble
SFD
MAC header
IPv4 header
UDP header
Sensor data
UDP segment IP datagram Figuur A.28: Transport van een UDP-segment met Ethernet-frames.
FCS
RN-41 COMMANDO’S
98
Bijlage B
RN-41 commando’s 1
Set commands Command S7,<1,0> SA,<1,0> SB, SC, SD, SE,<1,0> SF,1 SI, SJ, SL,<E,O,N> SM,<0,1,2,3,4,5> SN, SO, SP, SR, SS, ST, SU, SW, SX,<1,0> S˜,<0-4> SZ, S?,<0,1>
Description 7 bit data mode enable/disable Authentication enable/disable Send BREAK Service class Device class Encryption enable/disable Factory defaults Inquiry scan window Page scan window Parity Operation mode Name Connect/disconnect status string Pin code Remote address Service name Config timer Baudrate SNIFF rate Bonding Profile setting Raw baudrate Enable/disable role switch
