Definitie en ontwikkeling van een tijdsynchronisatiemechanisme voor het sensor testbed en sensor netwerkapplicaties

Definitie en ontwikkeling van een tijdsynchronisatiemechanisme voor het sensor testbed en sensor netwerkapplicaties Karlien Malfroid

Promotor: prof. dr. ir. Ingrid Moerman Begeleiders: Bart Jooris, Pieter De Mil Scriptie ingediend tot het behalen van de graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

Definitie en ontwikkeling van een tijdsynchronisatiemechanisme voor het sensor testbed en sensor netwerkapplicaties Karlien Malfroid

Promotor: prof. dr. ir. Ingrid Moerman Begeleiders: Bart Jooris, Pieter De Mil Scriptie ingediend tot het behalen van de graad van Master in de ingenieurswetenschappen: elektrotechniek

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Paul Lagasse Faculteit Ingenieurswetenschappen Academiejaar 2007-2008

Voorwoord Graag zou ik mijn promotor, professor Ingrid Moerman willen bedanken, evenals mijn begeleiders Bart Jooris, Pieter De Mil en Tim Allemeersch, bij wie ik steeds met vragen en problemen terecht kon. Ook Lieven Tytgat en Evy Troubleyn wil ik hierbij bedanken, voor de hulp bij enkele problemen. Ook zou ik mijn mede-thesisstudenten Stijn Van Goethem, Peter Ruckebusch, Ben Leers, Pieter Becue, Tom Van Nieulande en Jelle Boeckling willen bedanken voor het gezelschap tijdens de thesisuurtjes en de hulp bij vragen. Verder zou ik Nicolas Trangez en Femi Veys willen bedanken voor hun steun en de hulp bij verschillende Linux problemen. En als laatste wil ik ook Filip, Myriam, Kirsten en Kasper Malfroid bedanken voor de steun en de hulp bij het nalezen van mijn thesis.

Karlien Malfroid, 22 augustus 2008

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren 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 scriptie.”

Karlien Malfroid, 22 augustus 2008

Definitie en ontwikkeling van een tijdsynchronisatiemechanisme voor het sensor testbed en sensor netwerkapplicaties door Karlien MALFROID Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: elektrotechniek Academiejaar 2007–2008 Promotor: Prof. Dr. Ir. I. MOERMAN Scriptiebegeleiders: Bart JOORIS, Pieter DE MIL, Tim ALLEMEERSCH Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Trefwoorden Tijdsynchronisatie, Draadloos sensornetwerk, Testbed, Nauwkeurige timestamp, Atoomklokontvanger Code Alle code en verwerkte gegevens zijn terug te vinden op de cdrom toegevoegd in de achterkaft van deze scriptie.

Samenvatting Het is van groot belang voor de gebruiker van het testbed dat alle gebeurtenissen op de sensor nodes met een grote tijdsnauwkeurigheid worden geregistreerd. Dit testbed bestaat uit sensor nodes via USB verbonden met een controlecomputer, de iNode. Deze iNodes zijn via Ethernet verbonden tot een LAN. Het doel van dit afstudeerwerk is alle gebeurtenissen op de sensor nodes te voorzien van een nauwkeurige timestamp. Een minimale nauwkeurigheid van 500µs, en liefst kleiner dan 100µs, werd vooropgesteld. In het eerste deel wordt de nauwkeurigheid en stabiliteit onderzocht van bestaande protocollen zoals het Network Time Protocol (NTP) en het Precision Time Protocol (PTP of IEEE 1588). Het meest geschikte hiervan bleek het Precision Time Protocol te zijn, aangezien dit veel nauwkeuriger synchroniseert: het bereikt nauwkeurigheden van 10µs bij een LAN onder ideale netwerkomstandigheden tegenover 0, 2ms bij NTP. Na de PTP Linux implementatie ptpd op de iNodes ge¨ınstalleerd te hebben, werd de offset van hun klok tov de masterklok sterk gereduceerd. Na stabilisatie blijft deze offset onder de 5µs. Een tweede deel van de thesis onderzoekt de nauwkeurigheid van een timestamp op de sensor node geplaatst bij een bepaalde gebeurtenis. Wanneer bij het ontvangen van een draadloos bericht op applicatieniveau een timestamp geplaatst wordt, is deze zeer onnauwkeurig, met afwijking tot 2ms. Wanneer de timestamp net na de interrupt van een toekomend bericht geplaatst wordt, krijgen we een maximale afwijking van 93, 75µs en een gemiddelde afwijking van 2µs, wat heel wat minder is dan één 32kHz kloktik (= 31, 25µs). In een derde deel wordt een mechanisme ontwikkeld om een schatting te maken van de offset tussen de tijd van de iNode en zijn bijhorende sensor node. Hieruit kan ook de drift tussen beide klokken afgeleid worden. Naast deze drift vertoont de geschatte offset slechts afwijkingen van maximaal drie 32kHz kloktikken, wanneer de one-way-delay verwaarloosd wordt. Verder worden ook nog methodes onderzocht om de one-way-delay en de offset tussen de iNode en de sensor node te berekenen aan de hand van het doorverbinden van een seriële pin of audiosignaal. Wanneer deze vorige drie delen samen op het testbed uitgevoerd worden, kunnen we dus timestamps van gebeurtenissen op verschillende sensor nodes met elkaar vergelijken door bij de timestamp van een sensor node de offset bij te tellen, zodat we het tijdstip van deze gebeurtenis op de iNode bekomen. Wanneer we deze berekende tijdstippen op de iNode vergelijken met elkaar, verschillen zij maximaal drie 32kHz kloktiks. Het testbed is dus volledig gesynchroniseerd met een goede precisie van drie 32kHz kloktiks, wat minder is dan het vooropgestelde doel van 100µs. In een laatste deel wordt verder nog een mechanisme uitgelegd om de counters op de sensor nodes gelijktijdig te laten herstarten, namelijk op de dalende flank van de minuutmarkering van een ontvangen DCF77 atoomkloksignaal.

Definition and Implementation of a Time Synchronization Mechanism for the Test Environment for Wireless Sensor Networks and Sensor Network Applications Karlien Malfroid Supervisor(s): Ingrid Moerman, Bart Jooris, Pieter De Mil Abstract— This article explains a mechanism to synchronize all parts of the testing environment for wireless sensor networks installed by the department INTEC. It examines how to best synchronize LAN connected computers, and how to place an accurate timestamp on a sensor node. Furthermore, a mechanism is provided to estimate the offset and drift between a computer and its USB attached sensor node. Finally it explores the synchronization of sensor nodes using an atomic clock signal receiver. Keywords— Time synchronization, Wireless sensor network, Testing environment, Accurate timestamp, Atomic clock signal receiver

T

I. I NTRODUCTION

HE testing environment for wireless sensor networks is represented in picture 1. It consists of 200 wireless sensor nodes or devices under test (DUTs), Tmote Skys from Sentilla, which are each USB connected to a controle ALIX computer, the iNode. These iNodes are Ethernet connected in a LAN. Every time an event occurs on a sensor node, it should be timestamped very accurately. In order to compare this timestamp to other timestamps from other sensor nodes, all parts of the testing environment must be synchronized.

ers called strata. NTP uses a delay request and reply message between client and server to calculate the delay and offset, taking into account the send and receive time from these messages. The Precision Time Protocol or IEEE 1588, however, which under ideal network conditions reaches synchronization accuracies of 10µs in a LAN network, is a master-slave protocol based on clock strata. Using the best master clock algorithm, the most stable clock is picked as master. In contrast with NTP, the send timestamp is not sent in the message itself, but in a follow-up message. Thus, the send time is measured exactly, instead of being estimated before the actual sending. The PTP protocol is self-organizing and has very low resource usage. No special requirements are set for memory or CPU performance, and only minimal network bandwidth is needed. As PTP results in a better clock synchronization than NTP, combined with the advantages mentioned above, PTP will be chosen as the protocol for synchronizing the test environment iNodes. The PTP Unix deamon ptpd is installed on the iNodes. As can be seen in figure 2 the offset between slave and master diminishes exponentially. After stabilising, it remains under 5µs.

Fig. 1. Scheme of the testing environment. Fig. 2. Offset between slave and master during the ptpd process.

II. S YNCHRONIZATION OF THE I N ODES There are 2 important synchronization protocols: the Network Time Protocol (NTP) and the Precision Time Protocol (PTP). The Network Time Protocol reaches synchronization accuracies of 0.2ms in a LAN network under ideal network conditions. It is a client-server protocol that consists of multiple layK. Malfroid is a thesis student at the Information and Technology Engineering Department INTEC, Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

III. R ETREIVING THE B EST P OSSIBLE T IMESTAMP FROM THE S ENSOR N ODES The Tmote Sky sensor nodes are running TinyOS as operating system. The clock of the Tmote Sky is based on a 32kHz crystal; therefore, one clock tick equals 31, 25µs. To investigate the accuracies of the timestamps, wireless packets are sent every 100ms. At the reception of these wireless packets, a timestamp is taken on the application level. The inter packet arrival times

display a maximum deviation of 2ms and a mean deviation of 0.6ms, which is quite much compared to the clock tick interval. However, much better results are obtained when this timestamp is taken lower on the stack, at an interrupt generated by the arrival of a wireless packet or a pin input change, which is signalled through an event to the top-level application. The inter packet arrival times display a maximum deviation of 93, 75µs and a mean deviation of 2µs, which is less than one clock tick. IV. E STIMATING THE O FFSET AND D RIFT BETWEEN AN I N ODE AND ITS ATTACHED S ENSOR N ODE A. Offset and Drift Estimation Process Using the protocol pictured in figure 3, the offset between an iNode and a sensor node is calculated as follows: round trip delay = (tR2 − tS1) + (tR1 − tS2) of f set = tS2 − tR1 + one way delay (∗) (∗) no

(1)

division of the round-trip-delay by two due to an asymmetric delay.

B. Results When temporarily neglecting the one-way-delay, the calculated offset augments or decreases uniformly, which relates to a drift between the iNode clock and the 32 kHz sensor node clock. Apart from this drift, a mean deviation on the offset of about two 32kHz clock ticks can be noticed. The one-way-delay and the offset between a PC and a sensor node can be measured by wiring the serial DTR pin of the PC to the interrupt pin of the sensor node. This results in a one-waydelay of 76µs a second. The offset’s maximum deviation from its mean value is 50µs. On the iNode, however, the serial pin can not be used; a signal on the audio output is wired instead. By calculating the fixed time spent in the audio buffer, the offset can be derived. The output voltage of the iNode is not high enough to trigger the user interrupt pin of the sensor node. This problem can be solved by: • putting an amplifier on the iNode audio output and still using the precise timestamp at the digital user interrupt pin • connecting the iNode audio output to an ADC pin on the sensor node and comparing the ADC values periodically. Due to the long duration of the ADC reading process, however, the timestamp taken on the descending edge of the audio signal is remarkably less precise.

V. S YNCHRONIZATION OF THE S ENSOR N ODES ON BEHALF OF A DCF77 R ECEIVER A. DCF77 The DCF77 signal is a longwave time signal transmitted at 77.5kHz from Mainflingen, Germany. It is generated from a local atomic clock and transmits a time sequence every minute, which contains information about the time of the next minute. B. Resetting the Sensor Node’s Counter with the DCF77 Signal An implementation was made to reset the counters of different sensor nodes at exactly the same moment, i.e. on the descending edge of the minute mark. From this moment on, the counters only defer because of their clock drift, which is due to slightly different clock rates. VI. T HE COMPLETE S YNCHRONIZATION P ROCESS By combining PTP synchronization, accurate timestamping on the sensor node, and the offset and drift estimation process, the total test environment can be synchronized. When the corresponding offset is added to timestamps from different sensor nodes, placed when receiving an identical wireless message, the moment of this reception in the time base of the iNode can be retreived. As the iNodes are synchronized using the Precision Time Protocol, these obtained times on the iNodes should be approximately the same. In figure 4 the results of 10000 differences of these times on the iNodes are plotted. Figure 5 gives a better view on the distribution of these deviations. The rising tendency is caused by the drift, whereas the sudden jumps are caused by PTP. The deviation is centered around −35µs. 94% of the deviations are less than two 32kHz clock ticks and all deviations are less than three 32kHz clock ticks. These results prove that a very good overall synchronization has been obtained.

Fig. 4. Deviation between the calculated receive times on the iNodes.

Fig. 5. Distribution of the deviation between the calculated receive times on the iNodes. Fig. 3. Offset estimation process.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding 1.1

1.2

1

Situatieschets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.1

Testbed Zuiderpoort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.1.2

Tmote Sky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

1.1.3

TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

1.1.4

nesC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

1.1.5

Installatie van TinyOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

Doel van deze thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

1.2.1

6

Onderdelen van het onderzoek . . . . . . . . . . . . . . . . . . . . . . . .

2 Vergelijking van bestaande synchronisatieprotocollen

7

2.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2

Network Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

2.2.1

NTP implementatie voor Unix . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.2

Klok strata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.3

NTP timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.2.4

Hoe gebeurt synchronisatie via NTP? . . . . . . . . . . . . . . . . . . . .

10

IEEE 1588: Precision Time Protocol (PTP) . . . . . . . . . . . . . . . . . . . . .

11

2.3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.3.2

Werking van het IEEE 1588 protocol . . . . . . . . . . . . . . . . . . . . .

12

2.3.3

Beste master klok algoritme . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3.4

Tijdsynchronisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.3.5

Plaatsen waar de tijd kan gemeten worden . . . . . . . . . . . . . . . . . .

15

2.3

INHOUDSOPGAVE

2.3.6

ii

PTP architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.4

Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

2.5

Installatie van PTP op het testbed . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5.1

Linux PTP deamon: ptpd . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5.2

Installatie van ptpd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.5.3

Uitvoeren van ptpd

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.5.4

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.6

3 Nauwkeurig timestamps nemen op de sensor nodes 3.1

3.2

3.3

3.4

22

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.1

Aanpassingen aan het Java programma RadioPerf . . . . . . . . . . . . .

23

3.1.2

Hoe RadioPerf uitvoeren . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.1.3

Aangepaste RadioPerf nesC code . . . . . . . . . . . . . . . . . . . . . . .

24

3.1.4

Code op de sensor node plaatsen . . . . . . . . . . . . . . . . . . . . . . .

25

3.1.5

Opmerking: tijd wordt vanaf nu uitgedrukt in binaire eenheden . . . . . .

25

Test 1: Om de 100ms berichten verzenden, kijken om de hoeveel tijd ze toekomen 25 3.2.1

Opstelling Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.2.2

Resultaten Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2.3

Besluiten Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2.4

Aanpassen backoff-tijd zender . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.2.5

Resultaten Test 1 na het aanpassen van de backofftijd van de zender . . .

28

3.2.6

Besluiten Test 1 na aanpassen van de backofftijd van de zender . . . . . .

28

Test 2: Twee ontvangende sensor nodes . . . . . . . . . . . . . . . . . . . . . . .

29

3.3.1

Resultaten Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

3.3.2

Besluiten Test 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.3.3

Volgende testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

Test 3: Plaatsen van een timestamp bij een interrupt gegenereerd op een pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.4.2

Uitleg code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

INHOUDSOPGAVE

3.5

3.6

iii

3.4.3

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.4.4

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

Test 4: Timestamp bij aankomst van een draadloos bericht lager op stack nemen

36

3.5.1

Uitleg code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.5.2

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.5.3

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4 Synchronisatie tussen de sensor node en de bijhorende iNode

41

4.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2

Berekening van de offset tussen de sensor node en de bijhorende iNode . . . . . .

41

4.2.1

Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

4.2.2

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

4.2.3

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

Bepalen van de one-way-delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.3

4.3.1 4.4

4.5

4.6

Bepalen van de one-way-delay en de offset adhv het doorverbinden van een pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

Bepalen van de offset adhv een audiosignaal . . . . . . . . . . . . . . . . . . . . .

50

4.4.1

Het aan- en uitschakelen van LED2 en dus de DTR pin . . . . . . . . . .

50

4.4.2

Het genereren en afspelen van een blokgolf

. . . . . . . . . . . . . . . . .

50

4.4.3

Verwerking op de sensor node . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.4.4

Audio naar een ADC pin van de sensor node . . . . . . . . . . . . . . . .

52

4.4.5

Verwerking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.4.6

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.4.7

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

Onderzoek naar betere timers die kleinere resolutie hebben dan 32kHz . . . . . .

55

4.5.1

Klokken op de MSP430 chip . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.5.2

Aangepaste en toegevoegde bestanden . . . . . . . . . . . . . . . . . . . .

55

4.5.3

TimerA vs. TimerB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

4.5.4

ACLK vs SMCLK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

57

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

INHOUDSOPGAVE

iv

4.6.1

Berekening offset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.6.2

Nauwkeurigste klokbron . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

5 Alles op het testbed implementeren en testen

60

5.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

5.2

Code op testbed plaatsen en uitvoeren . . . . . . . . . . . . . . . . . . . . . . . .

60

5.3

Test 1: Elke 100 ms een draadloos bericht verzenden en een timestamp plaatsen op twee ontvangende sensor nodes . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.3.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

Test 2: Berekening van de drift adhv de offsetberekening . . . . . . . . . . . . . .

62

5.4.1

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

Test 3: Combinatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.5.1

Werkwijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.5.2

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.4

5.5

5.6

Resultaten

Resultaten

6 Synchronisatie van de sensor node dmv een atoomklokontvanger

66

6.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.2

Het DCF77 signaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

6.2.1

Voordelen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.2.2

Problemen bij ontvangst . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

6.2.3

Codering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

6.3

Atoomklokontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

6.4

Implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

6.4.1

Verbinden van de Tmote Sky en de DCF-ontvangersprintplaat . . . . . .

69

6.4.2

nesC implementatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

71

6.4.3

Het resetten van de timer . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.4.4

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.4.5

Opmerking: ontvangst . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

7 Besluit

74

A Installatie handleidingen

75

INHOUDSOPGAVE

A.1 Installatie van ptpd

v

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

A.2 Voyage Linux virtuele machine . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

A.3 Het Java programma RadioPerf configureren en uitvoeren . . . . . . . . . . . . .

76

A.4 Code op de sensor node plaatsen . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

A.5 Applicatie op een iNode en bijhorende sensor node draaien ipv op een PC en bijhorende sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

A.5.1 Installeren van RadioPerfCmdLine op de iNodes . . . . . . . . . . . . . .

77

A.5.2 Installatie van een applicatie op een sensor node vanaf een iNode . . . . .

77

A.5.3 Een C-programma op de iNode uitvoeren . . . . . . . . . . . . . . . . . .

78

B Code

79

B.1 Code uit Hoofdstuk 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

B.1.1 RadioPerf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

B.1.2 Pin Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

B.1.3 Timestamp bij toekomend draadloos bericht lager op de stack nemen . . .

80


83

B.2.1 Offset Berekening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

B.2.2 Bepalen one-way-delay en offset adhv het doorverbinden van een seriële pin 83 B.2.3 Bepalen van de delay op het afspeelcommando en effectief afspelen van een audiosignaal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

B.2.4 Bepalen van de offset adhv een audiosignaal . . . . . . . . . . . . . . . . .

83

B.2.5 Andere timer instellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83


84

B.3.1 Combinatie van de offsetberekening met het nauwkeurig plaatsen van een timestamp bij de ontvangst van een draadloos bericht . . . . . . . . . . .

84

B.4 Code Hoofdstuk 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

B.4.1 Atoomklok ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

B.4.2 Resetten van timerB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

INHOUDSOPGAVE

Lijst van gebruikte afkortingen ACLK: Auxilary clock BCD: Binary Coded Decimal DCF77: D: Deutschland, C: lange golflengte signaal, F: Frankfurt, 77: 77,5kHz DUT: Device Under Test (sensor node) GPS: Global Positioning System LAN: Local Area Network MCLK: Master clock MCU: MicroController Unit nesC: network embedded systems C NTP: Network Time Protocol PTP: Precision Time Protocol SMCLK: Sub-Main clock SNTP: Simple Network Time Protocol USB: Universal Serial Bus UTC: Coordinated Universal Time WAN: Wide Area Network

vi

INLEIDING

1

Hoofdstuk 1

Inleiding 1.1 1.1.1

Situatieschets Testbed Zuiderpoort

Figuur 1.1: Schematische voorstelling van het testbed. Het real-life testbed dat in 2007 werd uitgerold binnen de IBCN-gebouwen in de Zuiderpoort bestaat uit 200 modules. Een dergelijke module bestaat telkens uit een controle-PC en een daaraan via USB geconnecteerde sensor node (of DUT: Device Under Test). De controle-PC’s

1.1 Situatieschets

2

Figuur 1.2: Onderdeel van het testbed: een sensor node die via USB verbonden is met zijn bijhorende iNode.

Figuur 1.3: De iNodes van het testbed die gebruikt werden (in het geel onderlijnd).

zijn via een Ethernet-netwerk verbonden met elkaar. In figuur 1.1 wordt het testbed schematisch weergegeven. In figuur 1.2 is een foto te zien van één van deze modules. De controle PC of iNode is een ALIX computer waarop het besturingssysteem Voyage Linux1 draait. Voyage Linux is een op Debian gebaseerde distributie specifiek ontwikkeld voor ingebedde platformen zoals ALIX en heeft slecht 128MB nodig voor zijn installatie. De sensor nodes die gebruikt worden in het testbed zijn Tmote Sky’s (zie Sectie 1.1.2). In figuur 1.3 zijn de iNodes aangeduid waarop de testen in deze thesis zullen uitgevoerd worden.

1

http://linux.voyage.hk/

1.1 Situatieschets

3

Figuur 1.4: Onderdelen van de TMote-Sky.

1.1.2

Tmote Sky

De Tmote Sky[1][2], weergegeven in figuur 1.4, is een draadloze module met ultra laag vermogen voor gebruik in sensornetwerken, monitoring applicaties, en snelle applicatie prototyping. De Tmote Sky werd ontwikkeld door Moteiv, een bedrijf dat intussen werd overgenomen door Sentilla. De Tmote Sky zorgt ervoor dat industriestandaarden zoals USB en IEEE 802.15.4 perfect samenwerken met andere devices. Door industriestandaarden te gebruiken, vochtigheids-, temperatuuren lichtsensoren te integreren en een flexibele interconnectie met randapparaten te voorzien, maakt de Tmote Sky een brede waaier aan mesh netwerkapplicaties mogelijk. De Tmote Sky is een vervanging van de succesvolle Telos mote van Moteiv. Hij heeft een verbeterde performantie en een verhoogde functionaliteit en heeft out-of-the-box TinyOS support. De Tmote Sky is onderdeel van een lijn modules met sensoren op het bord, met een goede robuustheid, een lage kost en een kleine verpakkingsgrootte.

1.1 Situatieschets

4

De belangrijkste functionaliteit van de Tmote Sky zit vervat in de MSP430 chip. Verder zal er steeds naar deze Tmote Sky verwezen worden als de sensor node, of expliciet als de Tmote Sky.

1.1.3

TinyOS

TinyOS[3][4] is een vrij, open source componentgebaseerd besturingssysteem voor draadloze sensornetwerken. TinyOS is een embedded besturingssysteem geschreven in de programmeertaal nesC, en bestaat uit een set taken en processen. TinyOS ontstond uit een samenwerking tussen de Berkeley Universiteit in Californië en Intel Research. Erna is deze geëvolueerd naar een internationaal consortium, de TinyOS Alliantie. TinyOS applicaties worden geschreven in nesC, een dialect van de programmeertaal C, geoptimaliseerd voor de geheugenbeperkingen van sensornetwerken. Het wordt geleverd met een hele reeks supplementaire Java en shell script front-end toepassingen. Geassocieerde bibliotheken en toepassingen, zoals de nesC compiler, zijn meestal in C geschreven. TinyOS programma’s bestaan uit softwarecomponenten, waarvan er enkele hardware abstracties voorstellen. Deze componenten worden met elkaar geconnecteerd met behulp van interfaces. TinyOS levert interfaces en componenten voor veelgebruikte abstracties zoals pakketcommunicatie, routering, sensoren, actuatoren en het opslaan van elementen in het geheugen. De meeste componenten en interfaces staan beschreven in [5]. TinyOS is volledig non-blocking, het heeft één enkele stack. Hierdoor zijn alle I/O operaties die langer dan enkele honderden microseconden duren asynchroon, en wordt gebruik gemaakt van callbacks. Om de native compiler toe te staan beter te optimaliseren over de call-grenzen heen, gebruikt TinyOS de nesC eigenschappen om deze callbacks statisch te linken door middel van events. Non-blocking laat een hoge mate van parallel lopende code toe op één enkele stack, maar dit zorgt ervoor dat ontwikkelaars complexe logica moeten schrijven door vele kleine event handlers te gebruiken. Om langdurige berekeningen te ondersteunen, kan je in TinyOS ook tasks gebruiken, die overeenkomen met een uitgestelde procedure call. Een TinyOS component kan een task posten, en het besturingssysteem zal deze task schedulen om ze later uit te voeren. Tasks zijn non-preemptive 2 en worden in FIFO volgorde uitgevoerd. Dit simpele model is voldoende voor applicaties die voornamelijk I/O vergen, maar door problemen met zwaar CPU-belastende applicaties zijn er al verschillende voorstellen geopperd om threads in te bouwen in het besturingssysteem. TinyOS applicaties worden gecompileerd en statisch met de TinyOS bibliotheken gelinkt tot een kleine binaire module aan de hand van een aangepaste GNU toolchain. 2

Het besturingssysteem initieert nooit een context switch van een lopend proces naar een ander proces

1.1 Situatieschets

1.1.4

5

nesC

De programmeertaal nesC (network embedded systems C)[6] werd ontwikkeld om applicaties voor het TinyOS platform te bouwen en is een extensie op de programmeertaal C, gebaseerd op componenten die aan elkaar gelinkt worden (wiring) om applicaties op TinyOS te draaien.

1.1.5

Installatie van TinyOS

TinyOS kan ge¨ınstalleerd worden als pakket in een Linux omgeving. Uitleg over hoe dit precies moet kan gevonden worden in [7]. Het is ook mogelijk om TinyOS via een voorgeconfigureerd besturingssysteem, Xubuntos 3 te installeren. Dit kan eventueel ook als virtuele machine gedraaid worden. Voor deze thesis was dit echter niet aangewezen, aangezien er zeer nauwkeurige timestamps moeten genomen worden, en dit binnen een virtuele machine niet mogelijk is.

3

http://toilers.mines.edu/Public/XubunTOS

1.2 Doel van deze thesis

1.2

6

Doel van deze thesis

Het is van groot belang voor de gebruiker van het testbed dat alle gebeurtenissen op de sensor nodes met een grote tijdsnauwkeurigheid worden uitgevoerd. Het doel van dit afstudeerwerk is alle gebeurtenissen op de sensor nodes te voorzien van een nauwkeurige timestamp. Een minimale nauwkeurigheid van 500µs, en liefst kleiner dan 100µs, werd vooropgesteld.

1.2.1

Onderdelen van het onderzoek

Het eerste deel van de thesis zal de nauwkeurigheid en stabiliteit onderzoeken van bestaande protocollen zoals het Network Time Protocol en het Precision Time Protocol. Het meest geschikte hiervan zal dan op de iNodes geplaatst worden zodat de iNodes gesynchroniseerd worden ten opzichte van elkaar. Een tweede deel van de thesis zal onderzoeken hoe nauwkeurig timestamps bij een bepaalde gebeurtenis op de sensor nodes geplaatst worden. Een derde deel zal een schatting maken van de offset tussen de tijd van de iNode en zijn bijhorende sensor node. Samen met de vorige twee delen zullen dan de tijdstippen van gebeurtenissen in het testbed met elkaar vergeleken kunnen worden. In een laatste deel zal onderzocht worden of de sensor nodes kunnen gesynchroniseerd worden via extra hardware die een atoomkloksignaal ontvangt.

VERGELIJKING VAN BESTAANDE SYNCHRONISATIEPROTOCOLLEN

7

Hoofdstuk 2

Vergelijking van bestaande synchronisatieprotocollen 2.1

Inleiding

Interne klokken van computers verschillen dikwijls. Zelfs wanneer ze oorspronkelijk accuraat ingesteld werden, zullen reële klokken na een tijdje afwijken van elkaar ten gevolge van klokdrift, veroorzaakt door hun klokken die aan een licht verschillende snelheid tellen. Het is dus belangrijk om af en toe de klokken opnieuw te synchroniseren met elkaar. [8] In dit hoofdstuk zullen de twee belangrijkste synchronisatieprotocollen voor computers besproken worden, namelijk het Network Time Protocol (NTP) en het Precision Time Protocol (PTP), waarna het meest geschikte voor onze opstelling op het testbed zal uitgetest worden.

2.2

Network Time Protocol

Het Network Time Protocol (NTP)[9][11] wordt gebruikt om de tijd van een client- of servercomputer te synchroniseren met een andere server of met een referentie tijdsbron, zoals een radio- of satellietontvanger of modem. NTP levert nauwkeurigheden binnen de milliseconde bij LAN’s (Local Area Networks) en binnen enkele milliseconden bij WAN’s (Wide Area Networks) ten opzichte van de Coordinated Universal Time (UTC). NTPv4 (de laatste versie van NTP) kan meestal synchroniseren binnen de 10 milliseconden over het internet, en kan nauwkeurigheden bereiken tot 200 microseconden in LANs onder ideale netwerkomstandigheden. Typische NTP configuraties gebruiken meerdere redundante servers en verschillende netwerkpaden zodat ze een hoge precisie en betrouwbaarheid verkrijgen. [10]

2.2 Network Time Protocol

8

NTP synchroniseert computer klokken over packet-switched en variabele latency datanetwerken. Het protocol maakt gebruik van UDP op poort 123 als transportlaag. De voornaamste ontwerpreden van NTP was om de effecten van variabele vertraging (jitter) tegen te gaan. NTP levert enkel de UTC tijd en levert geen informatie over tijdszones of zomer- en wintertijd. Deze zaken kunnen manueel in de computer ingesteld worden. Het Network Time Protocol is één van de oudste internetprotocollen (van voor 1985) en wordt nog steeds gebruikt. Het werd ontworpen door Dave Mills van de universiteit van Delaware, die het ook nog steeds onderhoudt, samen met een team vrijwilligers. De volledige details van NTP worden beschreven in RFC 778, RFC 891, RFC 956, RFC 958 en RFC 1305. De huidige implementatie is versie 4 (NTPv4, 2005). Enkel de versies tot versie 3 (uit 1992) werden gedocumenteerd in RFC’s.

Simple Network Time Protocol (SNTP) Een minder complexe vorm van NTP die niet vereist dat informatie van vorige berekeningen opgeslagen wordt, is het Simple Network Time Protocol (SNTP). Het wordt gebruikt in embedded systemen en in applicaties waar zeer accurate timing niet nodig is. Het wordt beschreven in RFC 1361, RFC 1769, RFC 2030 en RFC 4330. Aangezien voor deze thesis een zeer accurate timing nodig is, wordt hier niet verder op ingegaan.

2.2.1

NTP implementatie voor Unix

De NTP Unix daemon is een user-level proces dat continu draait op een machine die NTP ondersteunt. Het protocol is grotendeels ge¨ımplementeerd in dit user proces. Om de beste performantie te krijgen van NTP, moet de NTP phase-locked-loop klok ge¨ımplementeerd zijn in de kernel van het besturingssysteem, wat betere resultaten geeft dan wanneer enkel de interventie van de externe NTP daemon gebruikt wordt. Alle recente versies van de Linux, *BSD en Solaris kernels bieden deze ondersteuning.

ntpd Een voorbeeldimplementatie is de NTP daemon ntpd. Deze kan op de meeste systemen via de standaard pakketbeheersoftware ge¨ınstalleerd worden. In [12] worden alle mogelijke opties en configuraties ervan uitgelegd.


9

Figuur 2.1: Verschillende stratum lagen bij NTP. Groene pijlen duiden op een directe connectie, rode op een netwerk connectie.

2.2.2

Klok strata

NTP gebruikt een hierarchisch systeem van ”klok strata”. De stratumniveaus definiëren de afstand van de referentieklok en voorkomen cycli in de hiërarchie.

Stratum 0 Dit zijn apparaten zoals atoomklokken (caesium, rubidium), GPS klokken of andere radioklokken. Stratum 0-apparaten worden niet met het netwerk verbonden. Ze worden lokaal geconnecteerd met één computer (bv. via een RS-232 connectie die een Pulse per second signaal gebruikt).

Stratum 1 Dit zijn de computers verbonden met Stratum 0 devices (bv. ntp.my-inbox.co.uk of ntp0. nl.net). Zij functioneren als servers voor timing requests van Stratum 2 servers via NTP. Deze


10

computers worden ook time servers genoemd. Veel Stratum 1 servers (voor NTPv3 en eerdere versies) opereren niet altijd met Stratum 1 precisie. Door nieuwe ontwikkelingen in het NTP protocol, zullen deze misleidende Stratum 1 servers automatisch een Stratum niveau dalen.

Stratum 2 Dit zijn computers die NTP requests verzenden naar Stratum 1 servers (bv. cismsun.univ-lyon1. fr). Normaal gebruikt een Stratum 2 computer verschillende Stratum 1 servers en gebruikt hij het NTP algoritme om de beste data over te houden en geen rekening meer te houden met Stratum 1 servers die duidelijk foutief blijken. Stratum 2 computers zullen informatie uitwisselen met andere Stratum 2 computers om een stabielere en robuustere tijd te bekomen voor alle onderdelen van zijn peer groep. Stratum 2 computers zullen normaal als server functioneren voor Stratum 3 NTP requests.

Stratum 3 Deze computers (bv. ntp.belnet.be) hebben exact dezelfde NTP functionaliteit van informatie uitwisselen en foute data filteren als Stratum 2 computers, en kunnen zelf dienen als servers voor lagere strata, mogelijk tot 16 niveaus diep. Er wordt aan gewerkt om in NTPv5, dat nog in ontwikkeling is, slechts 8 strata toe te laten. De meeste NTP client calls gebeuren op Stratum 2 servers, dus wordt verwacht dat gebruikers geen nadelen zullen ondervinden van het verlies aan granulariteit.

2.2.3

NTP timestamps

De 64-bit timestamps gebruikt door NTP bestaan uit een 32-bit seconde deel en een 32-bit fractioneel seconde deel, wat NTP dus een tijdsschaal geeft van 232 seconden (136 jaar) en een theoretische resolutie van 2−32 seconden (=0.233ns).

2.2.4

Hoe gebeurt synchronisatie via NTP?

Een client synchroniseren met een netwerk server gebeurt aan de hand van het versturen van verschillende request-reply pakketten. De client bewaart zijn tijd (start timestamp t1 ) wanneer hij een request pakket verzendt en stuurt deze timestamp ook mee met dit pakket[13]. Als een server zo’n pakket ontvangt, stuurt hij een bericht terug met daarin de tijd waarop hij het pakket ontving (receive timestamp t2 ) en de tijd waarop hij dit bericht verzendt (transmit timestamp t3 ). Als de client dit reply pakket ontvangt, registreert hij opnieuw een timestamp (t4 ). Dit proces wordt schematisch voorgesteld in figuur 2.2. De vertraging (of delay) wordt berekend door berichten te versturen en timestamps te nemen zoals in figuur 2.2. Uit deze timestamps

2.3 IEEE 1588: Precision Time Protocol (PTP)

11

Figuur 2.2: Berichten voor de delay berekening bij NTP.

wordt dan de vertraging geschat als volgt (ervan uitgaand dat deze vertraging symmetrisch is): 1 delay = [(t4 − t1 ) − (t3 − t2 )] 2 Uit deze tijdsverschillen kan ook de offset tussen de twee machines geschat worden, evenals de dispersie (maximale offset fout). Hoe korter en symmetrischer de round-trip tijd, hoe accurater de schatting van de huidige tijd. De systeemtijd wordt slechts aangepast na uitwisseling van meerdere pakketten en nadat de waarden met grootste afwijkingen hieruit verwijderd werden. Enkel als de reply berichten van de server aan de voorwaarden, gedefinieerd in de protocolspecificatie, voldoen, wordt de server als geldig beschouwd. Enkel bij een geldige server zal de tijd van de client hiermee gesynchroniseerd worden.

2.3 2.3.1

IEEE 1588: Precision Time Protocol (PTP) Inleiding

De IEEE Precision Time Protocol (PTP) standaard IEEE 1588 ([14] tem [27]) is een oplossing voor zeer precieze tijdsynchronisatie in een Ethernet netwerk. Het protocol werd oorspronkelijk ontwikkeld door Agilent voor gedistribueerde instrumentatieen controletaken. De techniek is gebaseerd op het werk van John Eidson, die als voorzitter van het standaardisatiecomité een grote verantwoordelijkheid had bij de goedkeuring van de standaard in november 2002. Met IEEE 1588 is het voor het eerst mogelijk om lokale klokken in sensoren, actuatoren en andere randapparaten die hetzelfde Ethernet netwerk gebruiken dat ook de data van het proces transporteert, met elkaar te synchroniseren in sub-microseconden bereik. IEEE 1588 werd


12

gedefinieerd om over alle datalinklaagprotocollen te werken in plaats van enkel over Ethernet. Zonder dit gestandaardiseerd synchronisatieprotocol zou het niet mogelijk zijn lokale klokken in randapparaten van verschillende producenten met elkaar te synchroniseren met deze precisie. Bestaande tijdsynchronisatieprotocollen zoals NTP en SNTP bereiken niet dezelfde nauwkeurigheid bij de synchronisatie en laten de klokken veel trager naar elkaar convergeren. Net zoals andere protocollen is PTP gebaseerd op het zo precies mogelijk vaststellen van het tijdstip waarop synchronisatiepakketten verzonden en ontvangen worden. In tegenstelling tot NTP wordt de verzendtijd niet getransporteerd in dit verzonden pakket zelf, maar in een volgend pakket. Op deze manier kan het meten van dit tijdstip ontkoppeld worden van het verzenden van dit tijdstip, zodat het moment van verzenden nauwkeuriger kan gemeten worden. Het PTP protocol werd ontworpen voor kleine homogene en heterogene lokale netwerken. De ontwikkelaars besteedden er ook de nodige aandacht aan om zo weinig mogelijk bronnen te gebruiken, zodat het protocol ook kan gebruikt worden voor goedkope randapparaten. Er worden geen vereisten gesteld qua geheugen of CPU-performantie, en het protocol heeft slechts een minimale bandbreedte nodig. Ook relevant is dat dit protocol weinig administratie van de gebruiker vereist. Redundante masters worden ook ondersteund, zodat een PTP domein zichzelf automatisch configureert adhv het beste master klok algoritme. De belangrijkste eigenschap van het protocol is dat het synchroniseert in het microseconden tot sub-microseconden bereik.

2.3.2

Werking van het IEEE 1588 protocol

De belangrijkste functionaliteit van PTP is dat de meest precieze klok in het netwerk alle andere gebruikers in het netwerk synchroniseert. Er zijn twee types klokken, Master en Slave klokken. In principe kan elke klok zowel master als slave zijn. De nauwkeurigheid van een klok wordt in categorieën verdeeld door het protocol, in strata (analoog als bij NTP). De hoogste klasse is een atoomklok met stratum waarde 1. De selectie van de beste klok in het netwerk gebeurt automatisch door het beste master klok algoritme uit te voeren. PTP is gebaseerd op multicast IP communicatie en is niet gelimiteerd tot Ethernet, maar kan op elk medium gebruikt worden dat multicasting ondersteunt. Multicast berichten bieden het voordeel van eenvoud: er dient geen rekening gehouden worden met IP adressen bij de implementatie op de PTP nodes. Hierdoor is PTP enorm schaalbaar en kan het voor een groot aantal PTP nodes gebruikt worden.


2.3.3

13

Beste master klok algoritme

Door het periodiek uitwisselen van sync-berichten bepaalt elke master klok via het beste master klok algoritme of hij master blijft of de masterstatus aan een andere master overlaat. Elke slave gebruikt eveneens het beste master klok algoritme om the bepalen of hij master wordt. Het beste master klok algoritme werkt als volgt[27]: 1. De master klok ’A’ kan Sync berichten ontvangen van andere kandidaat master klokken ’B’, ’C’,... 2. Klok ’A’ beslist welke van klokken ’B’, ’C’,... de beste klok is en of klok ’A’ zelf beter is dan de beste van deze andere klokken. Hiervoor gebruikt de master klok ’A’ het beste master klok algoritme: Klok ’A’ vergelijkt paarsgewijs de datasets die elk van de klokken beschrijven. Deze datasets bestaan uit: - het kloktype: is de klok als een geprefereerde klok aangeduid of niet - stratum waarde van de klok - de bron waarop de tijd gebaseerd is, bv. GPS, een lokale oscillator... - de nauwkeurigheid van de klok - de variantie op de klok (ruis op de klok) - de kloksoort: een Boundary klok (die subnetten overspant) of een gewone klok - de ’dichtste’ klok voor alle andere klokken zodat een minimum spanning tree gevormd wordt - en als laatste: de ID van de klok in het netwerk In deze volgorde worden de klokken eveneens vergeleken met elkaar. 3. Klok ’A’ krijgt na dit algoritme een geprefereerde klokstaat: ofwel master of slave. Aangezien alle klokken zich op dezelfde informatie baseren, verkiezen ze allen de goede master en nemen ze zelf de juiste staat aan.

2.3.4

Tijdsynchronisatie

Iedere slave synchoniseert zijn klok met de klok van zijn master door synchronisatieberichten uit te wisselen met deze master klok. Het synchronisatieproces bestaat uit twee fases. Eerst wordt het tijdsverschil tussen de master en de slave gecorrigeerd. Dit is de offsetcorrectie. Tijdens deze offsetcorrectie verzendt de master periodiek (standaard elke seconde) via multicast een synchronisatie (SYNC) bericht naar zijn slave klokken. Dit sync-bericht bevat een geschatte waarde van de exacte verzendtijd. Om een hoge nauwkeurigheid te verkrijgen wordt de tijd van het verzenden en ontvangen van PTP berichten gemeten zo dicht mogelijk bij de hardware, in het beste geval op het medium


14

zelf. Ook zouden de twee klokken dezelfde tijdsschaal moeten gebruiken: het tikinterval van hun klokken moet dus zo gelijk mogelijk zijn. Dit wordt bereikt door driftcompensatie: de klokrate van de slave wordt door een controlelus lichtjes versneld of vertraagd.

(a) Fase 1: offset berekening.

(b) Fase 2: delay berekening.

Figuur 2.3: Synchronisatie met PTP.

Figuur 2.4: Synchronisatie met PTP: offset en delay berekening.

In figuur 2.3(a) wordt een schema weergegeven van de eerste fase. De masterklok meet de exacte verzendtijd TM1 en de slave klok meet de exacte ontvangsttijd TS1. De master verzendt dan iets later een tweede bericht naar de slave klokken, het follow-up bericht, dat de exacte transmissietijd TM1 van het corresponderende sync-bericht bevat. Bij het ontvangen van dit sync-bericht en, voor een betere nauwkeurigheid, bij het ontvangen van het corresponderende follow-up bericht, berekent de slave de offset van zijn klok ten opzichte van de masterklok als volgt: de offset is gelijk aan de ontvangsttijd van het sync-bericht min de tijd die in het follow-up bericht zit. De slave klok moet dan met deze offset gecorrigeerd worden. Indien er geen vertraging zou zijn tijdens de transmissie, zouden beide klokken nu synchroon


15

lopen. De tweede fase van het synchronisatieproces berekent de vertraging tussen de slave en de master. Hiervoor zendt de slave klok een delay request pakket naar de master en neemt hierbij de exacte tijd van het verzenden van dit bericht TS3. De master meet de ontvangsttijd van dit pakket (TM3) en zendt deze tijd naar de slave in een delay response pakket (zie ook figuur 2.3(b)). Uit deze twee tijden kan de slave vervolgens de vertraging tussen master en slave berekenen: deze is gelijk aan het verschil tussen beide tijden. Samengevat krijgen we dus de berichten uit figuur 2.4 en als berekeningen voor de vertraging en de offset: Delay + Of f set = t2 − t1 Delay − Of f set = t4 − t3 Dus (t2 − t1) + (t4 − t3) 2 (t2 − t1) − (t4 − t3) Of f set = 2 Delay =

De delay berekening wordt onregelmatig uitgevoerd met een random tijd tussen twee berekeningen tussen 4 en 60s en op grotere tijdsintervallen dan de offset berekening. Zo worden het netwerk en het randapparaat niet te zwaar belast. Een symmetrische vertraging (dezelfde delay-waarde in beide richtingen) tussen de master en slave is wel cruciaal voor de delay berekening en zijn precisie. Door dit synchronisatieproces worden tijdsfluctuaties in de PTP-onderdelen zoals de protocol stack en de vertraging tussen de master en de slave geëlimineerd.

2.3.5

Plaatsen waar de tijd kan gemeten worden

In figuur 2.5 worden de verschillende plaatsen weergegeven waar het tijdstip kan vastgelegd worden in de stack bij het toekomen van het PTP bericht. Bij de hardware-aanpak wordt het tijdstip vastgelegd op de Medium Independent Interface (MII) tussen de MAC en PHY laag. De meeste apparaten en computers ondersteunen dit echter niet, zodat enkel op softwareniveau de tijd kan gemeten worden. Bij pure software-oplossingen wordt de tijd genomen in de Network Interface Card (NIC) driver of op applicatieniveau. Hoe hoger op de stack we gaan hoe minder nauwkeurig de gemeten tijd uiteraard. PTP haalt nauwkeurigheden bij de synchronisatie in de orde van 0, 1µs bij hardwaregegenereerde timestamps, en nauwkeurigheden kleiner dan 10µs wanneer de tijd binnen de kernel geregistreerd wordt[22].

2.4 Vergelijking

16

Figuur 2.5: Verschillende plaatsen waar de tijd kan gemeten worden bij PTP.

2.3.6

PTP architectuur

In figuur 2.6 wordt de architectuur van PTP weergegeven, waarbij de timestamp genomen wordt op kernelniveau. Ook de onderdelen om de berichten te versturen en te ontvangen, de klok te lezen en aan te passen, en het algoritme om de beste klok te zoeken worden hierin voorgesteld. Dit modulair softwareplatform maakt het mogelijk implementaties te maken van dit protocol voor Linux en Windows. Implementaties in Linux en Windows meten de tijden op softwareniveau, maar zelfs een zuivere software-implementatie haalt een precisie van ongeveer 100µs, en zelfs beter dan 10µs wanneer de tijd op kernelniveau genomen wordt in plaats van op applicatieniveau.

2.4

Vergelijking

In tabel 2.1 wordt een vergelijking weergegeven van de synchronisatieprotocollen NTP, PTP en GPS. GPS heeft het grote nadeel dat er binnenshuis geen ontvangst van het signaal mogelijk is, en is dus niet interessant om het testbed te synchroniseren. PTP is duidelijk in alle opzichten beter dan NTP om als synchronisatieprotocol voor het testbed te gebruiken. Het synchroniseert vele grootte ordes nauwkeuriger en heeft als bijkomend voordeel dat het zelforganiserend is. Het is ook geschikt voor kleine LAN’s en is enorm schaalbaar en zorgt ervoor dat klokken veel sneller convergeren dan bij NTP.

2.4 Vergelijking

17

Figuur 2.6: Schematische voorstelling van PTP

Het grote verschil in nauwkeurigheid van de synchronisatie wordt vooral veroorzaakt doordat bij PTP de timestamp bij het verzenden van het bericht niet op voorhand geschat wordt en al in het bericht zelf meegestuurd wordt, maar dat het moment van verzenden exacter bepaald wordt en pas in een volgend bericht wordt doorgezonden. We zullen dus PTP op het testbed installeren en kijken hoe nauwkeurig de iNodes gesynchroniseerd worden. NTP/SNTP

GPS

IEEE 1588

Toepassingsgebied

Groot gebied

Groot gebied

Enkele subnetten

Communicatie via

Internet

Satelliet

LAN

Nauwkeurigheid

enkele ms

< µs

< µs bij hardware timestamp < 10µs bij software timestamp

Manuele configuratie?

configuratie nodig

nvt

zelforganiserend

Speciale hardware nodig?

nee

ontvanger

eventueel

Tabel 2.1: Vergelijking van enkele synchronisatieprotocollen.

2.5 Installatie van PTP op het testbed

2.5 2.5.1

18

Installatie van PTP op het testbed Linux PTP deamon: ptpd

De PTP daemon (ptpd)[14][15][26] implementeert het Precision Time Protocol zoals het gedefinieerd werd door de IEEE 1588 standaard. Er bestaan ook nog andere implementaties van het Precision Time Protocol, zoals de implementatie van Real Time Systems[28], maar aangezien deze niet gratis verkrijgbaar is, verkiezen we te werken met ptpd. PTP werd ontwikkeld om zeer exacte tijdscoördinatie te leveren voor computers in een LAN netwerk. De IEEE 1558 specificatie legt het grootste deel van de werking van ptpd vast. In de broncode worden overal dezelfde termen als in deze specificatie gebruikt. Het ptpd programma wijzigt de locale klok door de effectieve tiksnelheid (slewing) van de klok aan te passen. Dit is een traag maar precies proces. Wanneer een lokale klok meer dan een seconde verschilt van de master klok, zal ptpd deze klok resetten in plaats van dit slewing proces uit te voeren. Wanneer deze plotse tijdssprongen problemen voor andere applicaties kunnen veroorzaken, kan dit gedrag uitgezet worden door de -x optie mee te geven. Het ptpd programma zou in staat moeten zijn om klokken met elkaar te synchroniseren met een afwijking kleiner dan enkele tientallen microseconden over een druk bezet medium, zelfs op zeer gelimiteerde platformen. De precisie van de synchronisatie via het ptpd programma hangt af van de de precisie van de timestamps die genomen worden bij het zenden en ontvangen van berichten. Ptpd heeft om nauwkeurige timestamps te nemen een Berkeley socket interface nodig die de SO TIMESTAMP socket optie implementeert. Alle huidige Linux versies ondersteunen dit normaalgezien. Ptpd gebruikt enkele platformspecifieke API’s om netwerk interfaces te vinden, maar kan werken op alle POSIX platformen die de ntp adjtime/adtimex system call van David Mills implementeren.

2.5.2

Installatie van ptpd

In bijlage A.1 wordt uitgelegd hoe ptpd kan ge¨ınstalleerd worden op de iNodes. Voordat het ptpd programma kon ge¨ınstalleerd worden moest echter eerst nog de C code van dit programma from source gecompileerd worden naar een uitvoerbare applicatie. Op de iNodes staat echter geen C compiler ge¨ınstalleerd. Er moest dus eerst een virtuele machine opgezet worden waar, net als op de iNodes, Voyage Linux1 opstond, zodat de ptpd code hierop gecompileerd kon worden. In bijlage A.2 staat uitgelegd hoe de Voyage Linux virtuele machine ge¨ınstalleerd kan worden. 1

http://linux.voyage.hk


19

Vervolgens werden de ptpd bestanden op deze virtuele Voyage Linux distributie gecompileerd. In de Makefile kan regel 5 uitgecommentarieerd worden om ptpd te compileren zodat er later debug info verschijnt bij het uitvoeren. De gecompileerde ptpd applicatie werd dan verplaatst naar de iNodes naar de mappen /tmp/ptpdMetDebug en /tmp/ptpdZonderDebug (respectievelijk met en zonder de debug flag gecompileerd). Let erop dat de op de iNodes geplaatste bestanden uitvoerbaar gemaakt worden.

2.5.3

Uitvoeren van ptpd

Het ptpd programma (gecompileerd met debug informatie) staat in de map /tmp/ptpdMetDebug en wordt als volgt uitgevoerd: ./ptpd -c -d De -c vlag zorgt ervoor dat het programma niet in de achtergrond draait. De -d vlag dient om debug informatie weer te geven. Deze vlag dient aan te staan om de geschatte offset en one-way-delay van de slaves te kunnen zien. Zonder verdere opties wordt de master automatisch verkozen, via een procedure die de stabielste klok kiest en hiervan de master maakt. Dit werd ook even getest door bijvoorbeeld het ptpd proces te stoppen op de gekozen master. Er wordt dan onmiddellijk een procedure opgestart die een nieuwe master verkiest, zodat er binnen de 5 seconden een nieuwe master verkozen wordt. Wanneer ptpd opnieuw aangezet wordt op de oorspronkelijke master, wordt deze machine opnieuw als master verkozen. Er kan ook manueel een master gekozen worden door deze de extra optie -p mee te geven (preferable clock), en iNodes kunnen ook expliciet slave gemaakt worden door de optie -g mee te geven. Om de uitvoer van dit programma naar een bestand weg te schrijven kunnen ook de extra opties -D -f filename.csv meegegeven worden.

2.5.4

Resultaten

In de debug output op de slave machines krijgen we elke seconde output zoals: state: slv, owd: 0.000063953, ofm: 0.000001952, drift: 5445, var: 0 Hierin wordt aangegeven of de machine master of slave is en worden de one-way-delay (owd) en de offset-from-master (ofm) in seconden, de klokdrift per seconde tussen de master en de slave klok in nanoseconden en de variantie hierop weergegeven.


20

Wanneer we het proces starten, merken we dat de offset-from-master aanvankelijk vrij groot is. De slave past zijn klok geleidelijk aan aan de klok van de master. Wanneer de offset aanvankelijk in de orde van 10ms ligt, zal hij binnen deze orde steeds met 1 verlagen, en pas erna verfijnen naar een orde 10 lager. De offset wordt dus exponentieel aangepast. De machines passen hun klok steeds beter aan de masterklok aan, wat kan gezien worden aan de dalende offset-from-master. Na een tijdje blijft deze offset-from-master stabiel en kunnen we besluiten dat de klokken niet preciezer op elkaar afgesteld kunnen worden. De offset-from-master blijft hier dan variëren tussen 0 en 4000ns. De klokken wijken dus maximaal 4µs van elkaar af. In de bestanden output89.xls en output94.xls 2 wordt de output van het programma op twee slave machines weergegeven. De resultaten zijn ook voorgesteld in figuren 2.7 en 2.8. Hierin is duidelijk de geleidelijke aanpassing van de offset te zien. Ook de drift blijft constant. Wanneer we enkel de laatste honderden samples bekijken wanneer de offset gestabiliseerd is (zie ook figuren 2.9 en 2.10), vinden we een gemiddelde offset-from-master van respectievelijk 2045, 76ns en 1571, 69ns met een standaardafwijking hierop van 1159, 09ns en 926, 87ns. De gemiddelde one-way-delay is respectievelijk 64795, 01ns en 64996, 94ns met een standaardafwijking hierop van 144, 84ns en 154, 02ns. Hieruit kan besloten worden dat de one-way-delay zeer stabiel is. De afwijkingen tussen de klokken zijn ook beperkt tot gemiddeld 2µs met hierop een standaardafwijking van 1µs. Buiten enkele zeer uitzonderlijke pieken die om de 300 seconden optreden, blijft deze offset onder de 5µs. Het netwerk van de iNodes wordt dus zeer nauwkeurig gesynchroniseerd.

Figuur 2.7: Offset tussen slave(iNode 89) en master(iNode 91) tijdens het ptpd proces.

Figuur 2.8: Offset tussen slave(iNode 94) en master(iNode 91) tijdens het ptpd proces. 2

te vinden op bijgevoegde cdrom

2.6 Besluit

21

Figuur 2.9: Offset tussen slave(iNode 89) en master(iNode 91) tijdens het ptpd proces: gestabiliseerde deel.

Figuur 2.10: Offset tussen slave(iNode 94) en master(iNode 91) tijdens het ptpd proces: gestabiliseerde deel.

2.6

Besluit

In dit hoofdstuk werden de twee belangrijkste bestaande synchronisatieprotocollen besproken en vergeleken, namelijk het Network Time Protocol (NTP) en het Precision Time Protocol (PTP). Hieruit bleek PTP duidelijk beter geschikt te zijn om op het testbed te implementeren. Het synchroniseert vele grootte ordes nauwkeuriger en is ook enorm schaalbaar doordat het zelforganiserend is door gebruik te maken van het Beste Master Klok Algoritme. De convergentie van de klokken gebeurt ook veel sneller dan bij NTP. Het grote verschil in de synchronisatienauwkeurigheid wordt vooral veroorzaakt doordat bij NTP slechts een schatting van het tijdstip van verzenden meegestuurd wordt in het verzendbericht zelf. Bij PTP wordt dit tijdstip in een volgend bericht doorgegeven zodat het moment van verzenden exacter bepaald kan worden. Er wordt dus een PTP implementatie, nl. het programma ptpd, op het testbed ge¨ınstalleerd. Wanneer de output van het ptpd programma uitgezet wordt in een grafiek, is duidelijk zichtbaar dat de klokken exponentieel naar elkaar toe convergeren. Na enkele minuten treedt een stabiele fase op waarin de afwijking tussen de klokken nog steeds varieert, maar wel onder de 5µs blijft. De iNodes zijn dus gesynchroniseerd ten opzichte van elkaar met een maximale afwijking van 5µs.

NAUWKEURIG TIMESTAMPS NEMEN OP DE SENSOR NODES

22

Hoofdstuk 3

Nauwkeurig timestamps nemen op de sensor nodes 3.1

Inleiding

In het vorige hoofdstuk synchroniseerden we de iNodes ten opzichte van elkaar. Zij zijn nu gesynchroniseerd ten opzichte van elkaar binnen de 5µs. Wanneer we van een event op een sensor node nauwkeurig het tijdstip willen bepalen waarop het optrad, zijn er echter nog veel plaatsen waar mogelijke vertragingen tussen het event zelf en de timestamp die erop geplaatst wordt kunnen optreden. Er zijn 2 mogelijke plaatsen waar we bij een event een timestamp kunnen nemen: • Op de sensor node • In een Java-applicatie op de controle PC In het eerste geval zal de nauwkeurigheid vooral afhangen van het moment waarop de timestamp genomen wordt in de stack op de sensor node. In het tweede geval, bij de Java-applicatie, zijn er veel mogelijke vertragende factoren tussen de sensor node en het moment van het nemen van de timestamp in Java. In figuur 3.1 zien we dat er zowel over de seriële USB verbinding vertraging kan optreden, evenals in de Java-applicatie zelf. Bij de testen plaatsen we op een sensor node een timestamp op het moment dat er een pakket op de draadloze interface toekomt. Erna zenden we onmiddellijk een pakket over de seriële verbinding naar de controle PC. Hierop draait het Java-programma RadioPerf (gemaakt door de onderzoeksgroep IBCN). Dit programma kan parameters wijzigen op de sensor nodes, en berichten die van de sensor nodes komen verwerken.

3.1 Inleiding

23

Figuur 3.1: Mogelijke vertragende factoren bij het plaatsen van de timestamp in een Javaapplicatie op de controle PC.

3.1.1

Aanpassingen aan het Java programma RadioPerf

De eerste aanpassingen die we maakten aan dit programma, zorgden ervoor dat we ook onze types berichten konden ontvangen. Met mig (message interface generator)[29] kon automatisch een Java-klasse gegenereerd worden, vertrekkend van het zelf gedefinieerde TimestampMsg bericht in de nesC code (zie Sectie 3.1.3). Dit TimestampMsg bericht, met AM-type 81, bevat een ID en een timestamp die op de sensor node geplaatst wordt. Generatie van deze Java-klasse: mig -o TimestampMsg.java -java-classname=TimestampMsg java RadioPerfMessages.h TimestampMsg Hiernaast werd code toegevoegd die aan elk inkomend bericht een timestamp toekent, namelijk op het tijdstip waarop het bericht door het systeem ontvangen werd. In RadioPerfModel.java komt een extra listener voor dit berichttype. In de MessageReceived functie wordt de systeemtijd bij het ontvangen van dit bericht genomen. Na controle of het AM-type correct was, worden de volgende gegevens toegevoegd aan een ontvangst file: • ID van het bericht • de timestamp uit het bericht (die op de sensor node geplaatst werd)

3.1 Inleiding

24

• de timestamp die net ervoor in Java genomen werd Deze gegevens kunnen dan verder verwerkt worden in Excel om er conclusies uit te trekken.

3.1.2

Hoe RadioPerf uitvoeren

In bijlage A.3 staat uitgelegd hoe het RadioPerf programma kan ingesteld en uitgevoerd worden. In al de volgende testen worden er om de 100ms pakketten verzonden met een grootte van 100 bytes en een inter-packet delay van 100ms.

3.1.3

Aangepaste RadioPerf nesC code

Voor testen verder in dit hoofdstuk werd een aangepaste versie van de nesC code van het programma RadioPerf op de sensor nodes geplaatst. De aanpassingen aan dit programma zorgen ervoor dat wanneer er een draadloos bericht toekomt op de sensor node, er een pakket naar de controle PC verzonden wordt. Er werd een nieuwe berichtstructuur TimestampMsg gedefinieerd in RadioPerfMessages.h met hierin een ID en een timestamp. Dit bericht krijgt AMtype 81. In RadioPerfC.nc werd een teller toegevoegd zodat de tijd nauwkeurig kan genomen worden. We gebruiken de teller op de sensor nodes met een resolutie van 32kHz, die gebaseerd is op een 32kHz kristal en dus zeer accuraat telt. Hiervoor worden volgende componenten gebruikt: components new CounterToLocalTimeC(T32khz) as CounterLocal; components Counter32khz32C; Verder werd ook een extra SerialAMSenderC component toegevoegd, om dit nieuw type bericht over de seriële USB-interface te verzenden en werden de nodige componenten aan elkaar gelinkt. In RadioPerfP.nc werd code toegevoegd aan het event event message_t *RadioReceive.receive(message_t *msg, void *payload, uint8_t len) dat opgeroepen wordt wanneer een bericht ontvangen wordt op de draadloze interface. Bij het optreden van dit event wordt een timestamp genomen, wordt de ID ge¨ıncrementeerd en wordt de functie opgeroepen waarin dit bericht verzonden wordt over de seriële verbinding: timestampMsg.timestamp = call TimestampTime.get(); timestampMsg.sendID = sendID++; timestampSender();

3.2 Test 1: Om de 100ms berichten verzenden, kijken om de hoeveel tijd ze toekomen

3.1.4

25

Code op de sensor node plaatsen

Om de geschreven nesC code op de Tmote Sky te plaatsen, kan de werkwijze uit bijlage A.4 gevolgd worden.

3.1.5

Opmerking: tijd wordt vanaf nu uitgedrukt in binaire eenheden

Alle precisies op de sensor nodes worden in binaire eenheden uitgedrukt ten opzichte van een seconde. Dit betekent dat één seconde 1024 binaire milliseconden bevat, 32768 binaire 32kHz tiks en 1048576 binaire microseconden[30]. Verder in dit hoofdstuk wordt overal in deze binaire eenheden gerekend, tenzij expliciet anders vermeld. Wanneer er timestamps op de controle PC genomen worden in plaats van op de sensor node, moeten deze overal gepast geschaald worden.

3.2

Test 1: Om de 100ms berichten verzenden, kijken om de hoeveel tijd ze toekomen

3.2.1

Opstelling Test 1

In de eerste test worden vanaf één sensor node draadloze berichten verzonden om de 100ms. Een andere sensor node ontvangt deze berichten, neemt een timestamp bij ontvangst en stuurt onmiddellijk een bericht door naar de RadioPerf Java-applicatie, waar ook een timestamp vastgelegd wordt. Figuur 3.2 illustreert dit nog eens.

Figuur 3.2: Testopstelling Test 1.


26

Het doel van deze test is na te gaan of berichten die om de 100ms verstuurd worden ook, zowel op de sensor node als in de Java-applicatie, om de 100ms ontvangen worden en hun timestamp bij ontvangst dus ook telkens 100ms verschilt.

3.2.2

Resultaten Test 1

De testresultaten zijn te bekijken in het bestand 100mstest.xls 1 . Er zijn drie tabbladen, voor resp 100, 1000 en 10000 berichten. Onderaan werden telkens wat gegevens erover berekend (gemiddelde, minimum, maximum en standaardafwijking). Ook staat telkens vermeld waar er berichten verloren zijn gegaan. Op deze plaatsen werd telkens manueel het tijdsverschil door twee gedeeld. In tabel 3.1 worden de resultaten vermeld van 10.000 verstuurde berichten. Er worden statistieken weergegeven van het verschil tussen de opeenvolgende timestamps genomen op enerzijds de sensor node en anderzijds de Java-applicatie. Verschil opeenvolgende

Verschil opeenvolgende

timestamps op Tmote Sky (ms)

timestamps in Java (ms)

gemiddelde

99,99949

gemiddelde

100,00037

minimum

84,78125

minimum

7,89276

maximum

114,81250

maximum

237,64792

standaardafwijking

4,01046

standaardafwijking

9,73135

Tabel 3.1: Resultaten Test 1

3.2.3

Besluiten Test 1

De verschillen tussen twee opeenvolgende timestamps genomen in het Java programma vertonen enorm grote afwijkingen. We verkrijgen hier ook enkele extreme waarden voor het minimum en maximum. Wanneer we deze waarden opzoeken in de testresultaten, merken we wel dat een zeer hoge waarde steeds gevolgd wordt door één of twee lage waarden, en omgekeerd, zodat er over een drietal samples gespreid toch nog een gemiddelde van ongeveer 100ms bekomen wordt. Het vastleggen van de timestamp in de Java-applicatie vertoont te grote afwijkingen en is niet nauwkeurig genoeg voor onze doeleinden. Daarom zullen we verder in dit hoofdstuk enkel nog focussen op de nauwkeurigheid van de timestamp op de sensor nodes, en later een methode beschrijven (in Hoofdstuk 4) om de offset tussen de sensor node en de controle PC te berekenen, zodat we hieruit het exacte tijdstip van een event kunnen bepalen. 1

te vinden op de bijgeleverde cdrom achteraan, net als alle verder vermelde Excel-bestanden


27

Figuur 3.3: Verdeling van de afwijking op de 100ms in tiks.

Ook bij de timestamps op de sensor nodes zijn er vrij grote afwijkingen. Er is een standaardafwijking van ongeveer 4ms op het 100ms verschil, maar de minimale en maximale afwijkingen blijven wel beperkt tot −14ms en +16ms afwijking tov het 100ms verschil. Een verdeling van de afwijkingen wordt weergegeven in figuur 3.3. Vermoedelijk wordt deze afwijking veroorzaakt door de verzender, die een backoff-tijd gebruikt om de draadloze pakketten te versturen, zodat deze niet exact om de 100ms verstuurd worden.

3.2.4

Aanpassen backoff-tijd zender

Aanvankelijk zullen we proberen deze backoff-tijd te reduceren en nagaan of we hierdoor betere resultaten verkrijgen. De RadioBackoff constanten kunnen worden aangepast via de interface RadioBackoff die verbonden is met de component CC2420TransmitC. Zowel de initialBackoff, de congestionBackoff en de lplBackoff worden op hun minimum waarde gezet (respectievelijk 10, 10 en 0). Deze waarden worden aan de CC2420Transmit component doorgegeven wanneer deze component ze opvraagt:

async event void RadioBackoff.requestCongestionBackoff(message_t *msg){ if(useCustomBackoffs==TRUE) call RadioBackoff.setCongestionBackoff(congestionBackoff) } async event void RadioBackoff.requestInitialBackoff(message_t *msg){ if(useCustomBackoffs==TRUE) call RadioBackoff.setInitialBackoff(initialBackoff);


28

} async event void RadioBackoff.requestLplBackoff(message_t *msg){ if(useCustomLPLBackoffs==TRUE) call RadioBackoff.setLplBackoff(lplBackoff); }

3.2.5

Resultaten Test 1 na het aanpassen van de backofftijd van de zender

Deze testresultaten zijn te bekijken in het bestand 100mstestaangepastebackoff.xls. Er zijn opnieuw drie tabbladen, voor resp 100, 1000 en 10000 berichten. Onderaan zijn telkens wat gegevens erover berekend (gemiddelde, min, max en standaardafwijking). In volgende tabel worden de resultaten na 10.000 verzonden berichten weergegeven van het verschil tussen de opeenvolgende timestamps zowel vanop de sensor node als vanuit de Javaapplicatie. Verschil opeenvolgende

Verschil opeenvolgende

timestamps op Tmote Sky (ms)

timestamps in Java (ms)

gemiddelde

99,999666

gemiddelde

99,999864

minimum

91,406250

minimum

12,592370

maximum

108,562500

maximum

221,228083

standaardafwijking

0,179475

standaardafwijking

6,730705

Tabel 3.2: Resultaten Test 1 met aangepaste backofftijd bij de zender Tmote Sky

3.2.6

Besluiten Test 1 na aanpassen van de backofftijd van de zender

Zowel bij het timestampverschil genomen op de Java-applicatie als dat genomen op de sensornode is de standaardafwijking enorm gedaald. Het verschil tussen opeenvolgende timestamps op de sensor node is in het merendeel van de gevallen exact 100ms. In figuur 3.4 wordt ook weergegeven hoe vaak er afwijkingen voorkomen op deze 10000 meetresultaten. De afwijkingen zijn telkens een meervoud van één 32kHz kloktik (=31, 25µs). Bij de verschillen in Java zijn er nog steeds grote onregelmatige afwijkingen. Hierna zullen we eerst proberen te bepalen of verschillende ontvangende sensor nodes op dezelfde tijdstippen afwijkingen vertonen op de 100ms. Indien dit zo zou zijn, kan daaruit afgeleid worden dat de timestamp bij ontvangst nauwkeurig genomen wordt, en ligt de onregelmatigheid volledig aan de zender die niet exact om de 100ms zendt. Deze testen zullen opnieuw met de willekeurige backofftijd van de zender uitgevoerd worden, zodat duidelijk zichtbaar is of de verschillen tussen de ontvangsttijden op beide ontvangende sensor nodes even groot zijn.

3.3 Test 2: Twee ontvangende sensor nodes

29

Figuur 3.4: Verdeling van de afwijking op de 100ms in tiks.

3.3

Test 2: Twee ontvangende sensor nodes

Bij deze test willen we nagaan of de soms voorkomende grote afwijkingen op de 100ms bij het ontvangen op een sensor node volledig aan de zender liggen. Om de 100ms worden vanaf één sensor node draadloze berichten verstuurd. Deze worden ontvangen op twee andere sensor nodes en krijgen onmiddellijk een timestamp in de RadioPerf applicatie op de sensor nodes. Nu willen we nagaan of de variatie op de 100ms bij beiden gelijk is. Indien dit zo is, is de onregelmatigheid volledig aan de zender te wijten en hebben we geen precisieprobleem bij het nemen van de timestamp bij ontvangst. In figuur 3.5 wordt de testopstelling weergegeven.

3.3.1

Resultaten Test 2

De resultaten van deze test zijn te bekijken in het bestand 100mstest verschil 2 ontvangende motes.xls. Per ontvangen bericht gaan we na of het verschil van de opeenvolgende ontvangsttijdstippen op de twee sensor nodes gelijk is. We berekenen dus het verschil van de timestampverschillen op de verschillende sensor nodes.

3.3 Test 2: Twee ontvangende sensor nodes

30

Figuur 3.5: Testopstelling Test 2.

In tabel 3.3 staan de bekomen statistieken na 1000 berichten. Verschil van de timestampverschillen op de twee sensor nodes (ms) gemiddelde

0,001750

minimum

-1,937500

maximum

1,718750

standaardafwijking

0,653021

Tabel 3.3: Resultaten Test 2: ontvangsttijden op twee sensor nodes vergelijken

3.3.2

Besluiten Test 2

Wat meteen opvalt is dat er een vrij grote standaardafwijking is, namelijk 0, 65ms. Dit komt ongeveer overeen met 20 tiks van de 32kHz klok (1 tik = 31, 25µs). De minimum- en maximumwaarden vertonen zelfs afwijkingen van meer dan 60 tiks. De variatie op de 100ms is dus niet gelijkaardig verdeeld over de twee sensor nodes. De onnauwkeurigheden worden dus niet enkel veroorzaakt door de zender. Hieruit kan er afgeleid worden dat de timestamp bij ontvangst van een draadloos bericht op een sensor node niet nauwkeurig genomen wordt. De grote afwijkingen op de 100ms worden wel duidelijk door de zender gegenereerd, aangezien de afwijking tussen de twee ontvangende sensor nodes veel kleiner is dan hun absolute afwijking

3.4 Test 3: Plaatsen van een timestamp bij een interrupt gegenereerd op een pin

31

tov de 100ms.

3.3.3

Volgende testen

Hierna zullen we twee testen uitvoeren om de nauwkeurigheid bij het nemen van een timestamp verder te onderzoeken en te verbeteren. Een eerste test zal nagaan hoe nauwkeurig een sensor node een timestamp kan plaatsen op een gebeurtenis. Hiervoor worden drie Tmote Sky’s gebruikt. Op één sensor node zal een pin periodiek hoog en laag geplaatst worden. Deze pin zal dan verbonden worden met een pin op beide andere sensor nodes. Op deze pin zal een interrupt gegenereerd worden en bij het optreden van deze interrupt wordt een timestamp geplaatst. Zo zullen we kunnen zien of deze interrupttimestamp dezelfde periode heeft als het signaal aangelegd op de eerste sensor node en of beide sensor nodes gelijkaardig reageren. Een tweede test zal vervolgens nagaan of we deze nauwkeurigheid ook kunnen verkrijgen bij de ontvangst van een draadloos bericht, door de timestamp lager op de stack te nemen in plaats van op het niveau van de RadioPerf applicatie op de sensor node.

3.4

Test 3: Plaatsen van een timestamp bij een interrupt gegenereerd op een pin

3.4.1

Inleiding

Aan de hand van deze test willen we nagaan met welke nauwkeurigheid op een sensor node de timestamp van een gebeurtenis kan vastgelegd worden. Hiervoor gebruiken we drie Tmote Sky’s. Op één sensor node wordt een pin periodiek hoog en laag gezet om de 50ms. Deze pin wordt dan verbonden met een pin op beide andere sensor nodes. Op deze pin wordt een interrupt gegenereerd bij een dalende flank van de pin en bij het optreden van deze interrupt wordt onmiddellijk een timestamp geplaatst. Uit de datasheet van de Tmote Sky kan afgeleid worden dat er interrupts kunnen gegenereerd worden wanneer het signaal verandert op pin 5 van de onderste 6, de user-interrupt pin. Deze pin komt op de MCU overeen met poort 27. Dit kan afgeleid worden uit figuren 3.6 en 3.7. We verbinden dus een pin op de eerste sensor node (we kiezen hier voor pin 4 van de 6, wat overeenkomt met poort 26) met de pinnen 5 op de andere sensor nodes waarop de interrupts moeten gegenereerd worden. Ook de aarding moet verbonden worden. Dit kan door pin 9 (=gnd pin) van alle sensor nodes met elkaar te verbinden. In figuur 3.8 wordt een foto van de testopstelling weergegeven.


Figuur 3.6: Pinnen op de Tmote-Sky.

Figuur 3.7: Poorten op de MCU van de Tmote-Sky.

32


33

Figuur 3.8: Testopstelling voor de interrupts via het signaal op de pinnen.

3.4.2

Uitleg code

Code van de sensor node die de puls aanlegt Deze code is terug te vinden in de bestanden PinInterruptZenderC.nc en PinInterruptZenderP.nc. In PinInterruptZenderC.nc wordt de User (de pin) uit de applicatie verbonden met de juiste IO poort. Er werd gekozen voor pin 4 van de 6 pinnen, die overeenstemt met poort 26 (zie figuur 3.6 en 3.7). //telosb pin PinInterruptZenderP.User -> HplMsp430GeneralIOC.Port26; In PinInterruptZenderP.nc wordt deze pin op output gezet, en laten we een timer lopen die om de 50ms een gebeurtenis genereert. In de code die wordt uitgevoerd bij zo’n gebeurtenis wordt het outputsignaal van de pin gewijzigd (van hoog naar laag of van laag naar hoog). event void Boot.booted() {


34

//Pin op output instellen call User.makeOutput(); //ChangePinTimer om 50ms laten firen. Om de 50ms hoog en laag, dus totale //periode 100ms call ChangePinTimer.startPeriodic(50); } // Als timer fired -> output pin laten toggle-en event void ChangePinTimer.fired() { call User.toggle(); }

Code van de sensor nodes die de puls ontvangen De code van de sensor nodes die het signaal ontvangen is te vinden in PinInterruptC.nc, PinInterruptP.nc en PinInterruptMessages.h. In PinInterruptC.nc wordt een Interrupt component op poort 27 (de UserInterrupt pin) geplaatst. // Telosb pin components HplMsp430InterruptC; PinInterruptP.User -> HplMsp430InterruptC.Port27; //tmote_sky_datasheet: pin 5 vd6, UserInterrupt, poort 27 In PinInterruptP.nc wordt eerst de ontvangende pin goed gezet, zodat de fired function opgeroepen wordt bij dalende flanken van het signaal. Verder wordt er een timestamp genomen op dit moment en een TimestampMsg bericht verstuurd over de seriële USB verbinding, op dezelfde manier als in de RadioPerf code ge¨ımplementeerd werd bij de eerdere testen. In PinInterruptMessages.h wordt nogmaals het TimestampMsg bericht gedefinieerd. event void Boot.booted() { // Pin goedzetten call User.disable(); call User.clear(); call User.edge(FALSE);//firen bij dalende flank call User.enable(); ... } async event void User.fired() //changed { call Leds.led1Toggle(); //timestamp plaatsen + nummeren


35

timestampMsg.timestamp = call TimestampTime.get(); timestampMsg.sendID = sendID++; //verzenden post SendSerialMessage(); //pin goedzetten call User.clear(); }

3.4.3

Resultaten

Op beide sensor nodes die het signaal op hun interrupt-pin ontvangen, worden de timestamps die genomen werden over 10000 periodes, weggeschreven naar een bestand. De verwerkte resultaten zijn zichtbaar in het bestand 100mstestpininterrupts.xls. In tabel 3.4 en 3.5 zijn de gemiddelden, maximum-, minimum- en standaardafwijkingwaarden gegeven van het verschil tussen opeenvolgende timestamps van respectievelijk de eerste en de tweede sensor node. In tabel 3.6 zijn de gemiddelden, maximum-, minimum- en standaardafwijkingwaarden gegeven van het verschil tussen de timestampverschillen tussen de twee sensor nodes op elk ogenblik. Verder vinden we ook een drift tussen beide klokken van 2, 78µs per seconde. Timestampverschillen op de eerste sensor node (ms)

Tabel 3.4:

gemiddelde

99,999197

minimum

99,96875

maximum

100,03125

standaardafwijking

0,005917

Resultaten Test 3: verschil tussen opeenvolgende timestamps op de eerste sensor

node

3.4.4

Besluit

Uit tabel 3.4 en 3.5 blijkt duidelijk dat de maximum- en minimumwaarden maximaal één kloktik van de 32kHz klok (= 31, 25µs) verschillen van 100ms. Ook uit tabel 3.6 blijkt dat op een bepaald ogenblik de timestampverschillen tussen de twee sensor nodes maximaal één kloktik verschillen. Hieruit kan dus geconcludeerd worden dat de timestamps zeer nauwkeurig genomen worden, meestal (in 94% van de gevallen) volledig correct tot op de kloktik, en met een maximale afwijking van één kloktik van de 32kHz klok.

3.5 Test 4: Timestamp bij aankomst van een draadloos bericht lager op stack nemen

36

Timestampverschillen op de tweede sensor node (ms) gemiddelde

99,99892

minimum

99,96875

maximum

100,03125

standaardafwijking

0,005740

Tabel 3.5: Resultaten Test 3: verschil tussen opeenvolgende timestamps op de tweede sensor node Verschil van de timestampverschillen op de twee sensor nodes (ms) gemiddelde

-0,000278

minimum

-0,031250

maximum

0,031250

standaardafwijking

0,008260

Tabel 3.6: Resultaten Test 3: ontvangsttijden op twee sensor nodes vergelijken De timestamps wijken dus maximaal één kloktik af van het echte tijdstip. Wanneer we een resolutie hanteren van twee kloktiks (=62, 50µs) zullen dus alle timestamps exact vastgelegd worden.

3.5

Test 4: Timestamp bij aankomst van een draadloos bericht lager op stack nemen

Aan de hand van deze test zal nagegaan worden of we deze nauwkeurigheid ook kunnen bekomen bij het ontvangen van een draadloos bericht, door het vaststellen van de timestamp lager op de stack uit te voeren, ipv op het niveau van de RadioPerf applicatie op de sensor node.

3.5.1

Uitleg code

In de map /tinyos-2.x/tos/chips/cc2420 werden volgende standaard TinyOS bestanden aangepast: • /receive/CC2420ReceiveC.nc • /receive/CC2420ReceiveP.nc • /interfaces/CC2420Receive.nc


37

• /transmit/CC2420TransmitP.nc

/receive/CC2420ReceiveC.nc Hier worden de nodige componenten toegevoegd om een 32kHz timestamp te kunnen nemen en worden de componenten correct aan elkaar gelinkt. components new CounterToLocalTimeC(T32khz) as CounterLocal; components Counter32khz32C; CC2420ReceiveP.TimestampTime -> CounterLocal; CounterLocal.Counter -> Counter32khz32C;

/receive/CC2420ReceiveP.nc In de bestaande functie: async event void InterruptFIFOP.fired() die opgeroepen wordt wanneer er een interrupt gegenereerd wordt doordat er een draadloos bericht toekomt, wordt volgende code toegevoegd, zodat er een 32kHz timestamp genomen wordt en er een event doorgestuurd wordt (signal ) naar de bovenliggende applicatie zodat er een timestampMsg serieel kan verzonden worden. timestamp = call TimestampTime.get(); signal CC2420Receive.getTimestamp(timestamp);

/interfaces/CC2420Receive.nc In de interface moest volgende functie worden toegevoegd: async event void getTimestamp(nx_uint32_t betterTimestamp)

/transmit/CC2420TransmitP.nc Hier moest CC2420Receive.getTimestamp ook ge¨ımplementeerd worden, aangezien dit bestand de interface CC2420Receive gebruikt.

Aanpassen van de RadioPerf code uit test 1 Op de cdrom2 zijn de nieuwe RadioPerf bestanden te vinden. 2

In de map /Hoofdstuk 3: Code/Test 4: aangepaste bestanden/RadioPerfBetterTimestamp


38

In RadioPerfC.nc worden de componenten voor de timestamps te nemen verwijderd (aangezien dat nu dieper op de stack gebeurt) en wordt de extra component CC2420ReceiveC toegevoegd en correct gelinkt: RadioPerfP.CC2420Receive -> CC2420ReceiveC;

In RadioPerfP.nc wordt de interface CC2420Receive toegevoegd. Verder wordt code toegevoegd die het event gegenereerd in het CC2420ReceiveP.nc bestand afhandelt: async event void CC2420Receive.getTimestamp(nx_uint32_t lowertimestamp){ timestampMsg.timestamp = lowertimestamp; //hier timestamp over serieel verzenden timestampMsg.sendID = sendID++; timestampSender(); } //Dit moet er bij omdat dit voorkomt in de interface CC2420Receive async event void CC2420Receive.receive( uint8_t type, message_t* message ){ } Als dit event plaatsvindt, wordt de timestamp die meegegeven werd samen met een ID in een TimestampMsg gestoken en verzonden over de seriële poort op dezelfde manier als eerder bij test 1.

3.5.2

Resultaten

We verzenden vanaf één sensor node 1000 draadloze berichten en ontvangen op twee andere sensor nodes die alles doorzenden naar de bijhorende controle PC waar de berichten naar bestanden uitgeschreven worden. De verwerking van deze gegevens is te bekijken in het bestand 100mstestradiobettertimestamp.xls. In tabel 3.7 en 3.8 zijn de gemiddelden, maximum-, minimum- en standaardafwijkingwaarden gegeven van het verschil tussen opeenvolgende timestamps van respectievelijk de eerste en de tweede sensor node. In tabel 3.9 zijn de gemiddelden, maximum-, minimum- en standaardafwijkingwaarden gegeven van het verschil tussen de timestampverschillen tussen de twee sensor nodes op elk ogenblik. In figuur 3.9 wordt de verdeling van deze afwijkingen weergegeven. We vinden verder ook nog een drift tussen beide klokken van 3, 75µs per seconde.

3.5.3

Besluit

Uit deze tabellen kan duidelijk afgeleid worden dat de afwijkingen op de 100ms uit de eerste twee tabellen duidelijk afkomstig zijn van de zender.


39

Timestampverschillen op de eerste sensor node (ms)

Tabel 3.7:

gemiddelde

99,99615

minimum

90,5625

maximum

108,6563

standaardafwijking

3,882937

Resultaten Test 4: verschil tussen opeenvolgende timestamps op de eerste sensor

node Timestampverschillen op de tweede sensor node (ms) gemiddelde

99,99578

minimum

90,56250

maximum

108,62500

standaardafwijking

3,883980

Tabel 3.8: Resultaten Test 4: verschil tussen opeenvolgende timestamps op de tweede sensor node Verschil van de timestampverschillen op de twee sensor nodes (ms) gemiddelde

-0,000375

minimum

-0,125000

maximum

0,187500

standaardafwijking

0,027015

Tabel 3.9: Resultaten Test 4: ontvangsttijden op twee sensor nodes vergelijken Tabel 3.9 toont dat de timestamps op de twee ontvangende sensor nodes maximaal zes 32kHz kloktiks van elkaar verschillen. De standaardafwijking is ook kleiner dan één 32kHz kloktik. In de meeste gevallen krijgen de ontvangen draadloze berichten dus een exacte timestamp. De maximale afwijking van zes kloktiks (= 187, 5µs) is de uiteindelijke bekomen nauwkeurigheid. Door de timestamp lager op de stack te nemen krijgen we dus een enorme verbetering tegenover de situatie ervoor. We hebben nu immers een standaardafwijking van 27µs tegenover een standaardafwijking van 653µs vastgesteld in test 2.

3.6 Besluit

40

Figuur 3.9: Verdeling van de afwijking van het verschil tussen de inter-arrival-tijden van de twee sensor nodes in tiks.

3.6

Besluit

Uit alle testen van dit hoofdstuk kunnen we concluderen dat het nemen van de timestamp bij het toekomen van een draadloos bericht veel nauwkeurigere resultaten levert wanneer dit lager op de stack gebeurt, namelijk bij het optreden van de interrupt bij ontvangst in plaats van op applicatieniveau. De nauwkeurigheid verbetert met een factor 25. In figuur 3.9 is duidelijk te zien dat de 70, 3% van de timestamps exact genomen worden en 23, 5% slechts één 32kHz kloktik verschillen. Verder kan ook geconcludeerd worden dat de zender sensor node slechts effectief op de gevraagde intervallen een bericht verzendt indien de backofftijd bij het verzenden expliciet op zijn minimumwaarde gezet wordt.

SYNCHRONISATIE TUSSEN DE SENSOR NODE EN DE BIJHORENDE INODE

41

Hoofdstuk 4

Synchronisatie tussen de sensor node en de bijhorende iNode 4.1

Inleiding

Het doel van dit hoofdstuk is de offset te berekenen tussen de sensor node en de bijhorende iNode. Samen met een nauwkeurige timestamp genomen op de sensor node kan hieruit dan de tijd waarop events plaatsvonden zo nauwkeurig mogelijk afgeleid worden.

4.2

Berekening van de offset tussen de sensor node en de bijhorende iNode

4.2.1

Werkwijze

In figuur 4.1 wordt de werkwijze die gevolgd werd om de offset tussen de iNode en de sensor node te bepalen schematisch weergegeven. Hierop staan de verschillende berichten die verstuurd worden, de plaatsen waar de tijd bepaald wordt en de velden die met een bericht meegestuurd worden. Om de 10 (binaire) seconden wordt deze berekening gestart op de sensor node. Er wordt een DelayRequestMsg verstuurd van de sensor node naar de iNode. Zowel bij het verzenden als bij de ontvangst wordt een timestamp genomen. De iNode stuurt hierop een antwoordbericht, AnswerDelayMsg, waarbij ook bij verzenden en ontvangst de tijd bepaald wordt. Even later verzendt de iNode zowel het tijdstip van ontvangst als het verschil tussen het verzen-

4.2 Berekening van de offset tussen de sensor node en de bijhorende iNode

42

Figuur 4.1: Schematische voorstelling van het protocol om de offset tussen de iNode en de sensor node te bepalen.

den van het reply bericht en het ontvangen van het request bericht. Dit bericht (RequestOffsetMsg) is tevens een aanvraag aan de sensor node om de offset terug te zenden. Nog even later verzendt de iNode een request om de delay te ontvangen (RequestDelayMsg). Deze twee request berichten zijn noodzakelijk omdat wanneer de sensor node twee berichten onmiddellijk na elkaar zendt, het tweede bericht verloren gaat. De sensor node beantwoordt deze berichten door respectievelijk de offset en de delay terug te zenden (OffsetMsg en DelayMsg). De delay en de offset tussen de iNode en de sensor node worden als volgt berekend door de sensor node: delay =

(tR2 − tS1) + (tR1 − tS2) (tR1 − tS1) − (tS2 − tR2) = 2 2 of f set = tR2 − tS1 − a · delay

De factor a werd toegevoegd omdat de delay niet symmetrisch bleek te zijn. Dit komt doordat er enorm veel variatie zit op timestamp tR2, wat betekent dat het variabele deel van de delay in het versturen van het bericht van de sensor node naar de iNode zit. Door a = 2 te kiezen


43

wordt deze instabiele timestamp geëlimineerd uit de berekening van de offset. Na uitrekenen verkrijgen we echter: (tR2 − tS1) + (tR1 − tS2) 2 = tR2 − tS1 − (tR2 − tS1) − (tR1 − tS2)

of f set = tR2 − tS1 − 2 · = tS2 − tR1

Op deze manier wordt de delay tussen tS2 en tR1 echter verwaarloosd. Er zal nu echter eerst getest worden hoe stabiel de offset tussen de PC en de sensor node is, wanneer er nog geen rekening gehouden wordt met de one-way-delay. Deze delay wordt voorlopig nog nul verondersteld en later in dit hoofdstuk zullen nog methodes uitgewerkt worden voor het bepalen van deze delay. Dit is immers niet mogelijk door enkel berichten over de USB-interface van PC naar sensor node te zenden.

4.2.2

Implementatie

De implementatie van dit protocol is te vinden in bijlage B.2.1. De applicatie op de iNode werd in C geschreven, omdat in C nauwkeurigere timestamps kunnen genomen worden dan in andere applicatietalen zoals Java. In het C programma wordt de tijd bepaald via de functie gettimeofday die de Unix-tijd[32] in een timeval structuur steekt. Deze structuur bestaat uit een uint32 t (unsigned int van 32 bit) secondendeel en een uint32 t microsecondendeel. Voor deze tijdstippen in een bericht doorgestuurd worden, worden ze eerst omgerekend naar binaire microseconden. Ook wordt slechts een deel van de timestamp meegezonden, aangezien de timestamp opgeslagen in de timeval structuur niet in één uint32 t past. Dit wordt echter later in de berekeningen opnieuw gecompenseerd. Hiervoor dient ook het min veld dat in de OffsetMsg meegestuurd wordt, om het minst beduidende cijfer van het niet meegezonden deel correct aan te passen. Op de sensor node worden alle berichten verwerkt en worden de delay en de offset berekend. Hiervoor worden de binaire 32kHz timestamps, genomen op de sensor node, eerst omgezet in binaire microseconden. Na de berekening worden de offset en de delay verzonden als antwoord op de request berichten. Deze offset en delay worden vervolgens op de iNode terug omgezet vanuit de byte array naar integers. Ze worden toegevoegd aan de bestanden offset.txt en delay.txt. In deze bestanden komen dus getallen in binaire microseconden terecht, waarbij bij de offset tevens nog geen rekening gehouden werd met het deel dat niet meegestuurd werd. In offsetCorrect.txt en delayCorrect.txt worden de offset en delay weggeschreven na omzetting naar microseconden en met het afgesplitste deel van de systeemtijd er opnieuw bijgevoegd.


4.2.3

44

Resultaten

Dit protocol werd getest tussen een PC en een sensor node. Opvallend is dat de delay enorm varieert tussen de 1000 en de 10000µs, maar dat de offset toch binnen een hierbij vergeleken heel beperkt interval blijft. Dit komt omdat de instabiele delay uit de offset weggewerkt werd door de factor a = 2. In 4 2 offsetendrifterop.xls en 4 2 offsetendrifteropMote2.xls zijn de resultaten van de offset en de delay voor twee verschillende sensor nodes weergegeven. In tabellen 4.1 en 4.2 worden de belangrijkste statistieken van de delay en het verschil tussen opeenvolgende offsetwaarden weergegeven. Wat duidelijk opvalt is dat beiden een gemiddelde steiging van de offset hebben van respectievelijk 76 en 63µs per 10 binaire seconden. Beide nodes vertonen dus drift tov de klok van de PC van 7, 42µs en 6, 15µs per seconde. Deze drift is mogelijk, aangezien telosb sensor nodes een klokdrift tot 40µs per seconde kunnen vertonen[33]. De offset vertoont een standaardafwijking op het verschil van de opeenvolgende samples (met als gemiddelde dus de drift) van 62, 00µs en 65, 36µs. De offset wordt dus nauwkeurig berekend tot op gemiddeld twee 32kHz kloktiks. Het verschil tussen de offsetwaarden van de opeenvolgende samples wordt ook voorgesteld in figuren 4.2 en 4.3 waarin we duidelijk kunnen zien dat dit offsetverschil schommelt rond één waarde, de drift waarde. Node 1 (µs)

Node 2 (µs)

gemiddelde

6046,73

6227,78

minimum

1010

1000

maximum

10215

10431

standaardafwijking

2345,81

2288,68

Tabel 4.1: Delay tussen een computer en twee verschillende sensor nodes. Node 1 (µs)

Node 2 (µs)

gemiddelde

76

56,25

minimum

-114

-76

maximum

237

434

standaardafwijking

62

78,35

Tabel 4.2: Verschil tussen opeenvolgende offsetwaarden tussen een computer en twee verschillende sensor nodes.


Figuur 4.2: Verschil tussen opeenvolgende offsetwaarden bij de eerste sensor node.

Figuur 4.3: Verschil tussen opeenvolgende offsetwaarden bij de tweede sensor node.

45

4.3 Bepalen van de one-way-delay

4.3

46

Bepalen van de one-way-delay

In het vorige onderdeel werd de offset berekend. Bij deze berekening werd voorlopig nog de oneway-delay verwaarloosd. Hier zullen enkele methodes onderzocht worden om deze one-way-delay te bepalen, waarna de offset hiermee gecompenseerd dient te worden.

4.3.1

Bepalen van de one-way-delay en de offset adhv het doorverbinden van een pin

Wanneer we op éénzelfde moment zowel aan de PC-zijde als aan de sensor node kant een timestamp kunnen vastleggen kan, na het verzenden van een bericht over de USB-interface, de one-way-delay bepaald worden. Deze twee timestamps geven ons ook onmiddellijk de offset, namelijk het verschil tussen beide. Het nemen van een timestamp op hetzelfde moment aan PC-zijde en sensor node zijde gebeurt door het laagplaatsen van de DTR pin van de seriële poort van de PC. Deze wordt dan verbonden met de interrupt pin van de sensor node. De PC plaatst dan een timestamp bij het moment waarop deze pin laag geplaatst wordt. De sensor node plaatst een timestamp op het moment dat er een interrupt bij dalende flank optreedt.

(a) Bepaling one-way-delay.

(b) Bepaling offset.

Figuur 4.4: Methode voor het bepalen van de offset door het laagzetten van de seriële DTR pin en deze door te verbinden met de interrupt pin op de sensor node. Aan de hand van deze methode kan dan zowel de one-way-delay (figuur 4.4(a)) als de offset (figuur 4.4(b)) berekend worden. Het hoogzetten van de seriële DTR pin werkt niet via een virtuele machine. Het is dus belangrijk deze test uit te voeren op een native linux machine die een seriële poort heeft.


47

Resultaten one-way-delay De resultaten zijn terug te vinden in het bestand 4 3 delayBerekening.xls. De gemiddelde delay na een 1000tal berekeningen met een pakket van 20 Bytes groot bedraagt 1529µs, met een standaardafwijking hierop van 21µs. Dit komt overeen met een delay van 76, 45µs per verzonden Byte. Wanneer we een grafiek en een histogram van de delayverdeling (figuren 4.5 en 4.6) bekijken, merken we dat de delay geconcentreerd is rond bepaalde waarden. 1518µs is de meest voorkomende delay (in 70% van de berekende waarden). De lijnen hierboven (26%) en onder (0, 8%) liggen op één kloktik afstand. Deze verschillen worden dus veroorzaakt door de sensor node die nauwkeurige timestamps neemt met een afwijking van één kloktik. De eigenlijke delay zal dus ergens tussen deze twee lijnen liggen (dichtst bij de laagste) en overeen komen met de gemiddelde delay. Verder zijn er nog enkele hogere waarden (3, 4%) die waarschijnlijk veroorzaakt worden door de timestamps aan de PC zijde, doordat er een ander proces voorrang kreeg op het delayberekeningprogramma en het nemen van de timestamp hierdoor vertraging opliep en dus verwaarloosd kunnen worden. Wanneer we de delay theoretisch uitrekenen bekomen we: delay =

aantalbits 20Bytes · 10bit/Byte = = 1736µs baudrate 115200bit/s

met hierin 10 bits per te verzenden Byte, namelijk 1 startbit, 8 databits, geen pariteitsbit en 1 stopbit. De theoretische delay is dus ongeveer gelijk aan de meest voorkomende experimentele delay. De eigenlijke baudrate is echter niet gelijk aan de theoretische. De baudrate op de Tmote Sky wordt berekend als volgt[31]: 1048567Hz = 115228Hz 9.1 Hierop kan nog een fout van 7% zitten. Dit zou een delay van 1622µs opleveren. Het bericht dat verstuurd wordt wordt echter verstuurd vanaf de PC. Seriële communicatie is enorm tolerant tov baudrate mismatches. De start bit zorgt er immers voor dat de UART zich synchroniseert met de baudrate van de verzender. Met 1 start bit, 8 data bits en 1 stop bit kan de verzender tot 10% afwijken[34]. De ontvanger zal zich dus aanpassen aan de baudrate van de verzender. Op een PC wordt de baudrate gegenereerd door 3000000Hz te delen door een factor (N+F), met N een integer en F 0, 0, 125, 0, 25 of 0, 5[35]. De waarden voor N en F om zo dicht mogelijk bij de theoretische baudrate van 115200Hz te komen zijn dan N=26 en F=0. 3000000Hz = 115384Hz 26 Dit levert een delay van 1733µs. Wanneer we rekening houden met de mogelijke afwijking van 10% kan dit een delay van 1576µs geven, wat zeer dicht bij de berekende delay ligt(47µs verschil ertussen).


48

Figuur 4.5: One-way-delay.

Figuur 4.6: One-way-delay: histogram.

Resultaten rechtstreekse berekening offset De resultaten zijn terug te vinden in het bestand 4 3 offsetBerekening.xls. Het decimale deel van de offset is weergegeven in figuur 4.7. De offset stijgt duidelijk in een rechte lijn, met als richtingscoëfficiënt de drift. We vinden per 3, 72s(=duur van één berekening) een drift van 74µs, wat dus resulteert in een drift van 20µs per seconde. In figuur 4.8 wordt ook nog het verschil van de opeenvolgende offsetwaarden uitgezet, waaruit dus ook duidelijk de drift zichtbaar is. Het verschil van de opeenvolgende offsetwaarden wijkt maximaal 50µs af van het gemiddelde, de driftwaarde. De offset wordt dus op elk moment berekend met een maximale afwijking van 50µs tov zijn gemiddelde en dus correcte waarde. Opmerking Berekeningen met floating point getallen dienen aan de PC zijde te gebeuren. Er dienen doubles ipv floats gebruikt te worden, aangezien een double een grotere opslagcapaciteit


49

heeft dan een float (8 tov 4 bytes). In TinyOS echter, zijn beide datatypes slechts 4 bytes groot zodat er een verlies aan precisie optreedt.

Figuur 4.7: Opeenvolgende offsetwaarden.

Figuur 4.8: Verschil tussen opeenvolgende offsetwaarden.

4.4 Bepalen van de offset adhv een audiosignaal

4.4

50

Bepalen van de offset adhv een audiosignaal

Met voorgaande methode kan zowel de offset als de one-way-delay tussen de PC en de sensor node bepaald worden. We kunnen deze methode echter niet toepassen om de offset te bepalen op het testbed, aangezien de seriële poort van de iNodes niet doorverbonden is met pinnen van de sensor node en de pinnen van de seriële poort ook niet rechtstreeks vanop de iNode kunnen veranderd worden. De offset kan wel berekend worden door de constante one-way-delay van 1529µs bij te tellen bij de offset die nog niet met de delay gecompenseerd werd uit sectie 4.2. In volgend gedeelte wordt een methode onderzocht om rechtstreeks de offset te bepalen tussen de iNode en de sensor node. De audio-uitgang van de iNode is immers wel doorverbonden met pinnen. Wanneer er een dalende flank als onderdeel van een blokgolf op de audio aangelegd wordt, kan deze dus opgemerkt worden door één van de pinnen van de sensor node. Er zit wel een vertraging op de C-instructie voor het aanleggen van de audio en het effectieve moment waarop de audio op de uitgang komt. Deze vertraging is constant wanneer de audiobuffer gevuld is op het moment dat het te detecteren signaal er naartoe gezonden wordt. Eerst wordt deze delay bepaald. Als er dan zowel bij het commando om de te detecteren audio af te spelen als bij het moment dat de flank op de sensor node gedetecteerd wordt een timestamp geplaatst wordt, dient deze enkel nog met deze vaste delay gecompenseerd te worden om de offset tussen de iNode en de sensor node te bepalen. Om deze vaste delay te bepalen, worden op één test-iNode LED2 en 3 doorverbonden met respectievelijk de DTR en RTS pin van de seriële poort. De DTR pin wordt dan doorverbonden naar de user interrupt pin op de sensor node. Ook de audio-uitgang wordt doorverbonden met de user interrupt pin van de sensor node. Door vier timestamps te nemen bij het aanleggen van de signalen en de interrupts op de sensor node kan dan de vaste delay tussen het geven van het c-commando om de audio af te spelen en het effectieve afspelen bepaald worden. Dit wordt ge¨ıllustreerd adhv figuur 4.9.

4.4.1

Het aan- en uitschakelen van LED2 en dus de DTR pin

De code hiervan is gebaseerd op het bestand testled.c van mijn begeleider Bart Jooris om de LED’s aan en uit te switchen. Deze code werd aangepast zodat er een timestamp geplaatst wordt bij het uitschakelen van LED2 (dus de DTR pin) en deze weggeschreven wordt naar een bestand.

4.4.2

Het genereren en afspelen van een blokgolf

Op de audio-uitgang moet een blokgolf verschijnen zodat de dalende flank een interrupt kan genereren op de sensor node. Het genereren van de blokgolf kan bvb op deze manier (deel van linux-package gstreamer ):


51

Figuur 4.9: Methode om de delay tussen het geven van het c-commando om de audio af te spelen en het effectieve afspelen ervan te bepalen. Aan de hand van deze delay kan dan door enkel een audioflank aan te leggen de offset tussen iNode en sensor node bepaald worden.

gst-launch-0.10 audiotestsrc wave=square freq=200 volume=1 ! audioconvert ! wavenc ! filesink location=outputlong.wav Hier wordt een wav bestand gegenereerd met erin een blokgolf met frequentie 200Hz en maximaal volume. Erna dient deze blokgolf nog ingekort te worden aangezien er slechts één dalende flank nodig is. Dit kan bvb adhv het programma audacity. In audacity kan dan ook stilte toegevoegd worden aan het begin van het bestand, zodat de audio-buffer reeds gevuld is op het moment dat de blokgolf er naartoe gestuurd wordt. Deze blokgolf kan dan afgespeeld worden met aplay (uit linux-package alsa-utils). aplay.c werd uitgebreid zodat er een timestamp genomen wordt wanneer de blokgolf naar de audio-uitgang geschreven wordt. Er wordt dus gecontroleerd wanneer de blokgolf naar de uitgang geschreven wordt, zodat de timestamp niet bij de stilte om de buffer te vullen genomen wordt. Deze timestamp wordt dan opgeslaan in een bestand. Om gebruik te maken van het aplay-programma dient ook het pakket libasound2 ge¨ınstalleerd te worden.

4.4.3

Verwerking op de sensor node

De sensor node plaatst bij zowel de dalende flank van de seriële DTR-pin als bij deze van de audio-uitgang een timestamp. Deze timestamps worden dan verzonden naar de iNode die hieruit dan de vaste audio-delay kan berekenen.


52

Het genereren van een interrupt op de user interrupt pin van de sensor node geeft geen problemen bij de dalende DTR flank. Bij de dalende flank van de audio-uitgang wordt er echter geen interrupt gegenereerd. Na controle met een oscilloscoop blijkt dat de audio-uitgang van de ALIX-iNode slechts een maximaal spanningsverschil kan genereren van 2, 8V . De user interrupt pin van de sensor node heeft echter een minimaal spanningsverschil van 3V nodig. De dalende flank van de audio kan dus niet via de user interrupt pin gedetecteerd worden. Er zijn twee mogelijke oplossingen voor dit probleem: • Het plaatsen van een versterker aan de audio-uitgang van de iNode. Om de offset in het testbed te berekenen, zou dit wel aan de audio-uitgang van elke iNode moeten toegevoegd worden. • De audio-uitgang verbinden met een ADC pin van de sensor node en periodiek controleren of de waarde ervan meer gedaald is dan een threshold-waarde. Eerst zal de tweede optie onderzocht worden en in het geval dat deze geen goede resultaten oplevert, zal er toch een versterker aan de audio-uitgang van de iNode toegevoegd dienen te worden.

4.4.4

Audio naar een ADC pin van de sensor node

De audio-uitgang wordt nu geconnecteerd met pin 5 van de 10-pin header van de sensor node. Op de sensor node wordt telkens de waarde van de pin gelezen adhv een ReadNow en een Resource interface. De uitgelezen data, die een bereik kan hebben van 0x000 tot 0xFFF, wordt dan vergeleken met de vorige gelezen pin-waarde. Indien deze nieuwe waarde meer dan een threshold lager ligt, wat overeenkomt met een dalende flank, wordt de cyclus gestopt, wordt er een timestamp geplaatst en wordt deze timestamp naar de iNode verzonden. Indien dit niet het geval is wordt er een nieuw Alarm gezet, die één 32kHz kloktik later afgaat en een nieuwe read-cyclus initieert. Om de dalende flank te detecteren op de analoge pin kan bvb volgende configuratie gebruikt worden: threshold = 0xFF vanaf PC: PCM moet volledig openstaan, master op ongeveer 50% vanaf iNode: PCM moet volledig openstaan, master: 81%, master mono: 84%, headphone: 81%, AUX: 84%

4.4.5

Verwerking

De twee timestamps genomen bij de detectie van de audioflank en de seriële flank worden dan naar de iNode verstuurd. Hier worden ze samen met de timestamps genomen bij het laagzetten van de seriële pin en het verzenden van de audio verwerkt. De delay tussen het nemen van


53

de timestamp in aplay en het toekomen van dit signaal op de sensor node kan dan als volgt berekent worden (notatie cfr. figuur 4.9): audiodelay = (T 4 − T 2) − (T 3 − T 1) Wanneer deze constant genoeg blijkt te zijn, kan deze gebruikt worden om de offset tussen de iNode en de sensor node op basis van een audiosignaal te berekenen.

4.4.6

Resultaten

De resultaten zijn terug te vinden in het bestand 4 4 DelayAudioNaarOutput.xls. Tabel 4.3 geeft enkele statistieken weer. In figuur 4.10 worden de resultaten weergegeven. Audio delay gemiddelde

0, 277470s

maximale afwijking op gemiddelde

0, 000704s

standaardafwijking

0, 000312s

Tabel 4.3: Delay tussen het aanleggen van een blokgolf op de audio-uitgang van een iNode en het detecteren ervan op de ADC pin van de sensor node.

Figuur 4.10: Delay tussen het aanleggen van een blokgolf op de audio-uitgang van een iNode en het detecteren ervan op de ADC pin van de sensor node.

De standaardafwijking op de audio delay is vrij groot. Dit kan verklaard worden doordat de read-cyclus op de ADC pin van de sensor node vrij lang duurt (ongeveer 700µs).

Offset In figuur 4.11 staat ook de offset tussen de iNode en de sensor node weergegeven die berekend werd enkel door het verzenden van het audiosignaal. De berekeningen zijn terug te vinden


54

in 4 4 OffsetBerekeningAudio.xls. Er is een drift van −170µs per seconde. Wanneer de offset gecompenseerd wordt met de drift, blijft er nog een gemiddelde afwijking op de offset over van 276µs. De maximale afwijking bedraagt 730µs. Deze grote afwijking kan opnieuw verklaard worden door de lange read-cyclus op de sensor node.

Figuur 4.11: Decimaal gedeelte van de offset.

4.4.7

Besluit

Het berekenen van de offset door het doorsturen van een audioflank van de audio-uitgang van de iNode naar de ADC pin van de sensor node geeft geen nauwkeurige resultaten, doordat de ADC read-cyclus te lang duurt. Nauwkeurige resultaten zullen enkel behaald kunnen worden door het bijplaatsen van een versterker aan de audio-uitgang van de iNode, zodat de flank van de blokgolf ook door de digitale user interrupt pin kan gedetecteerd worden, wat een veel nauwkeurigere timestamp op de sensor node zou opleveren. De digitale interrupt pin kan immers tot op de kloktik nauwkeurig een timestamp plaatsen, tegenover een nauwkeurigheid van slechts 730µs bij de ADC pin.

4.5 Onderzoek naar betere timers die kleinere resolutie hebben dan 32kHz

4.5

55

Onderzoek naar betere timers die kleinere resolutie hebben dan 32kHz

In dit onderdeel zal onderzocht worden of de gebruikte 32kHz klok de beste precisie geeft om een timestamp te nemen. Er zijn immers meerdere klokbronnen op de MSP430 chip die hier zullen vergeleken worden.

4.5.1

Klokken op de MSP430 chip

Het kloksysteem van deze chip[31] bestaat uit twee klokbronnen: • 32kHz kristal (LFXT1CLK): Laag- of hoogfrequente oscillator die afgeleid wordt uit een laagfrequent 32768Hz kristal • DCO (DCOCLK): Interne digitaal gecontroleerde oscillator met RC karakteristieken. Deze klok telt niet binair zoals de 32kHz kristal klok. Uit deze klokbronnen worden drie kloksignalen afgeleid: • ACLK: Auxiliary clock. De ACLK is de gebufferde LFXT1CLK klokbron. De ACLK kan via software geselecteerd worden om gebruikt te worden voor individuele randmodules. • MCLK: Master clock. De MCLK kan via software ingesteld worden om zowel de LFXT1CLK als de DCOCLK klok te gebruiken. De MCLK wordt gebruikt door de CPU en kan niet door randmodules gebruikt worden. • SMCLK: Sub-main clock. De SMCLK kan via software ingesteld worden om zowel de LFXT1CLK als de DCOCLK klok te gebruiken. De SMCLK kan via software geselecteerd worden om gebruikt te worden voor individuele randmodules. Na een reset van het systeem gebruiken de MCLK en SMCLK standaard de DCOCLK op 800kHz en gebruikt de ACLK de LFXT1 laagfrequente klokbron. De ACLK oscilleert met een 32768Hz kristal, wat een zeer stabiele tijdsbasis levert. De DCO daarentegen is een ge¨ıntegreerde ringoscillator met RC karakteristieken, wat als gevolg heeft dat zijn frequentie varieert met de temperatuur, met de voedingsspanning en ook per apparaat grote verschillen kan vertonen.

4.5.2

Aangepaste en toegevoegde bestanden

De aangepaste en nieuw aangemaakte counter bestanden uit de volgende delen zijn terug te vinden in /tinyos-2.x/tos/chips/msp430/timer/ en /tos/lib/timer (interfaces).


4.5.3

56

TimerA vs. TimerB

In TinyOS kunnen de klokken aangesproken worden via TimerA en TimerB. Standaard heeft TimerB een granulariteit van 32kHz (= 31, 25µs) en wordt afgeleid uit de ACLK klok, terwijl TimerA een granulariteit heeft van 1µs en afgeleid wordt uit de interne SMCLK klok. In vorige testen werd steeds gebruik gemaakt van de standaard TinyOS counter die TimerB gebruikt. We willen nu nagaan of het gebruik van een counter gebaseerd op TimerA betere resultaten geeft. Hiervoor wordt Msp430CounterMicroC.nc aangepast zodat gebruik wordt gemaakt van TimerA: configuration Msp430CounterMicroC { provides interface Counter as Msp430CounterMicro; } implementation { components Msp430TimerC , new Msp430CounterC(TMicro) as Counter ; Msp430CounterMicro = Counter; Counter.Msp430Timer -> Msp430TimerC.TimerA; } Het bestand CounterMicro32TimerAC.nc werd extra aangemaakt, waarin een 16bit counter omgezet wordt in een 32bit counter. configuration CounterMicro32TimerAC { provides interface Counter; } implementation { components Msp430CounterMicroC as CounterFrom; components new TransformCounterC(TMicro,uint32_t,TMicro,uint16_t,0,uint16_t) as Transform; Counter = Transform; Transform.CounterFrom -> CounterFrom; }

Deze counter wordt vervolgens gebruikt in het offsetberekeningsprogramma, waarin ook de omrekening van 32kHz naar microseconden dient weggelaten te worden. De verschillen tussen opeenvolgende offsets leveren ons de statistieken uit tabel 4.4 op. We merken een zeer onregelmatige daling van de offset, daarom zullen we eerst verder onderzoeken of TimerA, gebaseerd op de SMCLK klok, wel accuraat telt.


57

Verschil opeenvolgende offsetwaarden (µs) gemiddelde

-65011

minimum

-97699

maximum

37856

standaardafwijking

31762,27

Tabel 4.4: Verschil tussen opeenvolgende offsetwaarden tussen een computer en een sensor node met een TimerA microseconde counter.

4.5.4

ACLK vs SMCLK

Volgende bestanden (terug te vinden in bijlage B.2.5) werden aangemaakt: • in /tos/chips/msp430/timer: CounterMicro32C.nc, MicroClockSettingMsp430CounterP.nc en MicroClockSettingMsp430CounterC.nc • in /tos/lib/timer: MicroClockSettingCounter.nc en TransformCustomizedCounterC.nc Hiermee kan er naast de 32bit counter ook een functie opgeroepen worden in de boot sectie van de sensor node die het kloktype aanpast (setTimer functie). Dit kan immers niet via de counter gebeuren, aangezien deze niet rechtstreeks van een timer afgeleid is, maar een transformatie is van een 16bit counter die van deze timer afgeleid werd. Het kloktype van een timer kan als volgt geselecteerd worden: call Msp430Timer.setClockSource(MSP430TIMER_SMCLK); call Msp430Timer.setClockSource(MSP430TIMER_ACLK); Dit aanpassen van het kloktype gebeurt in het bestand MicroClockSettingMsp430CounterP.nc. De timer is een TimerA, zoals gedefinieerd in MicroClockSettingMsp430CounterC.nc. De structuur van deze counter en onderliggende modules wordt weergegeven in figuur 4.5.4. We bekijken het tijdsverschil van een timestamp die om de 10 binaire seconden (gebaseerd op de 32kHz klok) genomen wordt, met zowel de ACLK als de SMCLK. In tabel 4.5 worden de resultaten weergegeven. Aangezien de SMCLK klok niet binair telt, zou er dus een verschil tussen de samples moeten zitten van 10, 24s. Dit is duidelijk niet het geval. Uit de resultaten van de ACLK klok merken we duidelijk dat deze afgeleid is van dezelfde klok als de timer die elke 10 binaire seconden afloopt. Hier is het verschil namelijk exact 320000. Aangezien de verschillen van de SMCLK klok enorm afwijken van de 10, 24s kunnen we hieruit afleiden dat deze interne klok niet nauwkeurig loopt. Uit de User’s Guide van de MSP430


(a) CounterMicro32C

58

(b) MicroClockSettingMsp430CounterC

Figuur 4.12: Structuur van de modules die een 32bit counter bieden met mogelijkheid om een bepaald kloktype te selecteren. SMCLK

verschil SMCLK

10196908

ACLK

verschil ACLK

330445

20389421

10192513

650445

320000

30581873

10192452

970445

320000

40774470

10192597

1290445

320000

50966033

10191563

1610445

320000

61156718

10190685

1930445

320000

71346742

10190024

2250445

320000

81536663

10189921

2570445

320000

91726389

10189726

2890445

320000

Tabel 4.5: Timestamps bij verschillende timers na elke 10e binaire seconde. chip[31] wisten we immers ook al dat deze klok afhankelijk is van externe factoren zoals de voedingsspanning en de omgevingstemperatuur. Deze klok wordt wel door de CPU gebruikt, maar een CPU heeft enkel opeenvolgende tiks nodig om zijn stappen uit te voeren. Of er tussen deze tiks een al dan niet regelmatig interval zit, is niet van belang voor de werking van de CPU. Deze interne SMCLK klok wordt dus beter niet gebruikt voor het genereren van timestamps aangezien ze te onnauwkeurig tikt. Dit verklaart ook meteen de slechte resultaten van de offsetberekening gebaseerd op TimerA, die standaard deze SMCLK klok gebruikt.

4.6 Besluit

4.6 4.6.1

59

Besluit Berekening offset

In dit hoofdstuk werd een mechanisme ontwikkeld om de offset en drift tussen de iNode en de sensor node te bepalen. In een eerste fase wordt de one-way-delay genegeerd, waarbij een offset bekomen wordt met slechts een standaardafwijking van twee 32kHz kloktiks. In een tweede fase worden de one-way-delay en de offset bepaald door het laagzetten van de seriële DTR pin en deze door te verbinden met de sensor node. Op deze manier kan de offset bepaald worden met een maximale afwijking van 50µs. De gemiddelde one-way-delay bij het verzenden van een pakket van 20 Bytes bedraagt 1529µs en heeft slechts een standaardafwijking hierop van 21µs. Op de iNode kunnen we echter geen gebruik maken van de seriële pin. De offset kan hier nu op twee manieren bepaald worden: • De offset uit het eerste deel compenseren met de vaste one-way-delay van 1529µs. • Gebruik maken van de audio-uitgang op de iNode, die op het testbed doorverbonden is met de sensor node.

De audio-uitgang geeft echter een te laag maximaal spanningsverschil, zodat het signaal hierop niet gedetecteerd kan worden door de digitale user interrupt pin. Dit signaal werd dan gemeten aan de hand van de analoge ADC pin, waarop er periodiek gekeken werd of twee opeenvolgende waarden meer verschilden dan een threshold zodat de flank gedetecteerd kan worden. Eén read-cyclus duurt echter vrij lang (ongeveer 700µs), zodat de sensor node geen nauwkeurige timestamps teruggeeft. Om de offset wel nauwkeurig te berekenen aan de hand van het audiosignaal zal er dus gebruik gemaakt moeten worden van de digitale user interrupt pin. Hiervoor dient dan wel een versterker aan de audio-uitgang van de iNode geplaatst te worden.

4.6.2

Nauwkeurigste klokbron

Verder werd onderzocht of er nauwkeurigere resultaten behaald konden worden door een andere klokbron te gebruiken op de sensor node. Tot hiertoe werd steeds de ACLK klok gebruikt, die gebaseerd is op een 32kHz kristal. De MSP430 chip beschikt echter ook nog over een interne klok, de Digital Controlled Oscillator, waarvan de MCLK (voor de CPU) en SMCLK (voor randmodules) kloksignalen afgeleid zijn. Deze oscillator vertoont echter instabiel gedrag wegens zijn afhankelijkheid van voedingsspanning en temperatuur. De 32kHz klok is dus de meest stabiele klokbron waarmee de nauwkeurigste timestamps genomen kunnen worden.

ALLES OP HET TESTBED IMPLEMENTEREN EN TESTEN

60

Hoofdstuk 5

Alles op het testbed implementeren en testen 5.1

Inleiding

In dit hoofdstuk worden de testen die in de vorige twee hoofdstukken lokaal tussen een PC en hieraan geconnecteerde sensor nodes uitgevoerd werden, uitgevoerd op het testbed. Er zal ook onderzocht worden of een combinatie van de synchronisatie van de verschillende onderdelen van het testbed (iNodes onderling, nauwkeurige timestamp op het testbed en de offsetberekening tussen de iNode en de sensor node) goede resultaten geeft. Met deze drie onderdelen samen zou immers elke gebeurtenis op een sensor node, na omrekening via de offsetberekening naar een tijdstip op de iNode, vrij nauwkeurig met elkaar vergeleken moeten kunnen worden. Deze nauwkeurigheid zal bepaald worden in dit hoofdstuk.

5.2

Code op testbed plaatsen en uitvoeren

Hoe de code op het testbed geplaatst kan worden en uitgevoerd dient te worden staat beschreven in bijlage A.5.

5.3 Test 1: Elke 100 ms een draadloos bericht verzenden en een timestamp plaatsen op twee ontvangende sensor nodes

5.3

61

Test 1: Elke 100 ms een draadloos bericht verzenden en een timestamp plaatsen op twee ontvangende sensor nodes

In deze eerste test wordt test 4 uit hoofdstuk 3 uitgevoerd op het testbed. Er wordt dus vanaf één node om de 100ms een draadloos bericht verstuurd terwijl twee andere sensor nodes bij het ontvangen van dit bericht een timestamp plaatsen bij de ontvangst-interrupt.

5.3.1

Resultaten

De resultaten van deze test zijn terug te vinden in Testbed100mstest.xls. Hierin kijken we voor elk ontvangen bericht op de twee ontvangende sensor nodes hoe groot het tijdsverschil is met het vorige ontvangen bericht. De verschilwaarden van de twee sensor nodes worden dan vergeleken. Op 10000 ontvangen berichten, verstuurd om de 100ms, zijn deze verschillen in alle gevallen gelijk aan nul, behalve voor 5, 80% een absolute afwijking van één kloktik, voor 0, 13% een absolute afwijking van twee kloktiks, en 1 keer (=0, 01% van het totaal) een absolute afwijking van drie kloktiks. Er wordt dus in 94, 06% van de gevallen exact op dezelfde tik ontvangen op de twee sensornodes. Slechts in 5, 80% is er één kloktik verschil, en twee of meer kloktiks verschil komen slechts zeer zelden voor. Er is een gemiddelde afwijking van 2µs. Deze percentages zijn ook weergegeven in het histogram in figuur 5.1. Verder vertonen de klokken ook nog een onderlinge drift van 9µs per seconde.

Figuur 5.1: Afwijking op de interarrivaltijden tussen twee ontvangende sensor nodes: histogram.

5.4 Test 2: Berekening van de drift adhv de offsetberekening

5.4

62

Test 2: Berekening van de drift adhv de offsetberekening

In deze test berekenen we de drift voor drie verschillende sensor nodes. Deze drift kan afgeleid worden uit de offsetberekening.

5.4.1

Resultaten

De resultaten zijn terug te vinden in testbedOffsetberekening.xls. We merken een drift bij de drie sensor nodes van respectievelijk −243, 6µs, −243, 9µs en −276, 2µs per seconde. Dit is vrij veel tegenover de vroeger verkregen waarden die rond de 10µs schommelden. Een mogelijke verklaring hiervoor zou kunnen zijn, dat ondanks de iNodes wel ten opzichte van elkaar gesynchroniseerd zijn, hun klokrate afwijkt van externe klokken buiten het testbed die wel correct tellen. Om dit te controleren wordt een kleine extra test gedaan:

Drift van de iNode-klokken ten opzichte van echte tijd Op een bepaald moment wordt de systeemtijd vastgesteld op zowel de iNode 89 als op de PC waarop de voorgaande testen uitgevoerd werden en die dus geen grote drift vertoonde ten opzichte van de sensor nodes. Ongeveer een dag later wordt opnieuw de systeemtijd op beiden vastgesteld. Dit levert de resultaten uit tabel 5.1. Wat dus een verschil geeft van 19,9989s. time PC time iNode89

28/05, 15u36

29/05, 15u20

verschil

1211981739,730114 s

1212067233,281731 s

85493,5516 s

28/05, 15u36

29/05, 15u20

verschil

1211981356,877937 s

1212066830,430669 s

85473,5527 s

Tabel 5.1: Drift tussen iNode 89 en de PC. Wanneer we de drift per seconde van iNode 89 omrekenen naar een dag krijgen we: 243µs · 3600 · 24 = 20, 995200s, wat dus mooi overeenkomt met het bekomen verschil aangezien het verschil waartussen de metingen gedaan werden net iets minder bedroeg dan één dag. Hieruit kan dus afgeleid worden dat de klokrate op de iNodes iets trager ligt dan deze van een ideale klok.

5.5 Test 3: Combinatie

5.5

63

Test 3: Combinatie

Wanneer er vanaf één sensor node berichten verzonden worden en deze op twee andere sensor nodes ontvangen worden en hierbij een timestamp geplaatst wordt, kan bij deze timestamp de offset bijgeteld worden. Wanneer de offset uitgemiddeld wordt zodat de onregelmatige pieken eruit gefilterd worden, en met de drift rekening gehouden wordt, kan er op elk moment een nauwkeurige schatting van de offset berekend worden. Wanneer deze bij de timestamp van de sensor node bijgeteld wordt, zouden we op beide iNodes, die ook onderling via PTP gesynchroniseerd werden, een getal moeten uitkomen dat ongeveer gelijk is. Voor deze test wordt de offsetberekening uit sectie 4.2. Hierin werd de one-way-delay verwaarloosd. Bij deze test maakt dat echter niet uit aangezien het verschil tussen twee nodes vergeleken wordt. Bij het nemen van het verschil valt de one-way-delay immers weg: (t1 + of f set1 − delay) − (t2 + of f set2 − delay) = (t1 + of f set1) − (t2 + of f set2)

PTP geeft een maximale afwijking tussen de klokken van 5µs en de timestamp op de sensor node wijkt maximaal één 32kHz kloktik (= 31, 25µs) af. De uitgemiddelde offset wordt hier dan bijgeteld. De uiteindelijke precisie van het samengestelde proces zal blijken uit de test.

5.5.1

Werkwijze

Aan de nesC code van de offsetberekening wordt de code toegevoegd om bij ontvangst van een draadloos bericht een timestamp te plaatsen en dit door te zenden over de USB-interface naar de iNode. Deze samengestelde code is terug te vinden in bijlage B.3.1. De twee ontvangende sensor nodes worden dan met dit programma uitgerust. De verzendende node gebruikt gewoon de standaard RadioPerf code. Op de iNode draait dan gelijktijdig zowel de C-code van de offsetberekening als de commandline versie van het aangepaste RadioPerf Java-programma. Aangezien deze beiden filteren op AMtype zouden ze geen hinder mogen ondervinden van elkaars berichten.

5.5.2

Resultaten

Wat opvalt is dat de binnenkomende berichten echter wel hinder ondervinden doordat zowel het Java-programma als de C-code dezelfde USB-poort willen lezen. Gedurende het interval waarin de offsetberekening plaatsvindt, worden er geen berichten ontvangen in de Java applicatie. Zo ontbreken er dus elke 10 seconden een groot aantal berichten. Een mogelijke oplossing hiervoor is de offsetberekening eerst uit te voeren en deze te stoppen nadat er genoeg berichten binnengekomen zijn om de drift eruit te schatten. Wanneer pas hierna begonnen wordt met het doorsturen van draadloze berichten ondervindt de verwerking hiervan geen hinder meer door het offsetberekeningsprogramma. Na een tiental berichtuitwisselingen van de offsetberekening kunnen we al een zeer nauwkeurige schatting van de drift afleiden.

5.5 Test 3: Combinatie

64

De test wordt dus opnieuw uitgevoerd op deze manier. De code op de sensor nodes werd aangepast zodat de offsetberekening slechts 30 maal wordt uitgevoerd. Hier wordt de offset en de drift berekend en pas nadien worden de bij events geplaatste timestamps verzonden. De resultaten van deze twee stappen zijn te bekijken in het eerste en tweede tabblad van testbedOffsetEn100mstest.xls. De drift voor iNode 89 en 94 zijn respectievelijk −242, 5µs en −242, 7µs per seconde. Wanneer we de bekomen waarden van de offset compenseren door de drift ervan af te trekken, bekomen we een gemiddelde offset tussen de iNode en de sensor node van respectievelijk 1212097285, 466260s en 1212097291, 113610s. De standaardafwijking hierop is binnen deze 30 berekeningen slechts 17 en 32µs. De timestamps die de sensor nodes plaatsten zijn terug te vinden in het tweede tabblad. Aan de hand van deze gegevens wordt onderzocht of het toekomen van een bericht op beide sensor nodes op hetzelfde moment gebeurt. Hiervoor wordt de offset op dat moment (= de vaste offset + de drift per seconde vermenigvuldigd met het aantal verstreken seconden) bij de timestamps geteld en wordt nagegaan in hoeverre deze getallen op beide iNodes overeenstemmen. Na de berekeningen van het tijdstip van ontvangst in de tijdschaal van de iNodes worden deze waarden met elkaar vergeleken. Het verschil tussen deze waarden van de twee iNodes worden vergeleken in figuur 5.2. Hieruit valt duidelijk op dat het verschil in het merendeel van de gevallen onder de twee 32kHz kloktiks (= 62, 50µs) ligt en maximaal drie 32kHz kloktiks (= 93, 75µs) bedraagt. De stijgende trend wordt veroorzaakt door het systematisch toevoegen van de drift en offset, die beiden een gemiddelde zijn en dus slechts een schatting van de echte drift en offset op dat moment. De sprongen hierin worden veroorzaakt door het periodiek bijstellen van de klok door ptpd. In figuur 5.3 wordt een verdeling van deze waarden weergegeven aan de hand van een histogram. De afwijking tussen de berekende tijden op de iNodes is gecentreerd rond −35µs. 94% van de afwijkingen liggen onder de twee 32kHz kloktiks en alle afwijkingen liggen onder de drie 32kHz kloktiks. Hieruit kunnen we afleiden dat de volledige opstelling zeer goed gesynchroniseerd is. Een gebeurtenis op een sensor node kan een timestamp krijgen op de iNode met een nauwkeurigheid binnen de drie 32kHz kloktiks (=93, 75µs).

5.6 Besluit

65

Figuur 5.2: Verschil van de berekende tijdswaarden tussen de verschillende iNodes.

Figuur 5.3: Verdeling van de verschillen van de tijdswaarden tussen de verschillende iNodes.

5.6

Besluit

Het samenbrengen van de • synchronisatie van de iNodes onderling via ptpd • nauwkeurige timestamp op de sensor node • offset- en driftberekening tussen de iNode en de sensor node geeft een goede synchronisatie van het volledige testbed. Gebeurtenissen op het testbed kunnen met een nauwkeurigheid van drie 32kHz kloktiks (=93, 75µs) vastgelegd worden.

SYNCHRONISATIE VAN DE SENSOR NODE DMV EEN ATOOMKLOKONTVANGER

66

Hoofdstuk 6

Synchronisatie van de sensor node dmv een atoomklokontvanger 6.1

Inleiding

Het doel van dit onderdeel van de thesis is aan de hand van het gebroadcaste DCF77 atoomkloksignaal de sensor nodes verder te synchroniseren. Dit signaal zendt per minuut een tijdssequentie uit. Op de flank van het signaal, die exact op de minuut valt, willen we een interrupt genereren die de timer van de sensor node reset. Aangezien deze interrupt bij alle sensor nodes op hetzelfde moment plaatsvindt, zullen hun timers dus allemaal op eenzelfde moment gereset worden en allemaal gelijk beginnen tellen. Door hun onderlinge drift zullen de tellers wel terug uit elkaar lopen, maar deze drift is berekenbaar aan de hand van de offsetberekening uit het vorige hoofdstuk en is dus gekend.

6.2

Het DCF77 signaal

DCF77[36][37][38][39] is een tijdseinzender die vanuit Mainflingen in Duitsland via de lange golf op een frequentie van 77, 5kHz met een vermogen van 50kW een signaal uitzendt dat binnen een straal van meer dan 1500km te ontvangen is. De zender wordt beheerd door de ’PhysikalischTechnische Bundesanstalt’. In figuur 6.1 is het bereik van dit signaal weergegeven. DCF77 staat voor D=Deutschland, C=lang golflengte signaal, F=Frankfurt, 77=frequentie: 77, 5kHz.

6.2 Het DCF77 signaal

67

Figuur 6.1: Reikwijdte van het gebroadcaste DCF77 signaal.

6.2.1

Voordelen

Het grootste voordeel van synchronisatie via het DCF77 signaal is dat er op lange golflengte wordt uitgezonden. Door deze lange golflengte hebben deze signalen als grote voordeel ten opzichte van tijdstransmissie via satellieten, dat ze door gebouwen kunnen doordringen en dat de ontvangst van deze signalen niet gehinderd wordt door bijvoorbeeld bomen of hoge gebouwen. Ze kunnen zonder antennes buiten het gebouw ontvangen worden, een eenvoudige feriet antenne volstaat reeds, in tegenstelling tot GPS signalen die een antenne nodig hebben die buiten geplaatst is, met een line of sight naar de satelliet.

6.2.2

Problemen bij ontvangst

Door de grote golflengte van ongeveer 4 kilometer treedt er regelmatig storing op op het ontvangstsignaal[39][40][41]. De frequentie van 77, 5kHz wordt geregeld gestoord door interferentie van atmosferische storingen en elektromechanische bronnen zoals motoren en in de nabijheid van de ontvanger werkende beeldschermen. Ook tijdens onweer kan het nodig zijn de zender tijdelijk uit te schakelen. Verder zorgt ook de nabijheid van metalen vensterramen voor storing. In dergelijke gevallen moet de antenne zo ver mogelijk van de storingsbron opgesteld

6.2 Het DCF77 signaal

68

worden. Ook binnenin ruimtes met dikke muren errond zoals gewapend beton en stenen muren is er dikwijls een slechte ontvangst van het signaal doordat het te sterk verzwakt is.

6.2.3

Codering

Figuur 6.2: Onderdelen per minuut van het gebroadcaste DCF77 signaal. Het signaal wordt als volgt gedecodeerd: elke seconde wordt een gemoduleerd signaal ontvangen dat staat voor een binaire codering van tijd en datum. Een seconde mark met een duur van 0, 1s correspondeert met een binaire nul, een seconde mark met een duur van 0, 2s staat voor een binaire één. Elke minuut worden de minuut, het uur, de dag, de dag van de week, de maand en het jaar uitgezonden, gebaseerd op een BCD (Binary Coded Decimal) code. Dit wil zeggen dat elk cijfer van een getal apart gecodeerd wordt. Elke code bevat informatie over de volgende minuut. De amplitude van de DCF77 draaggolf wordt gemoduleerd per seconde: op het begin van elke seconde, behalve voor de laatste seconde van elke minuut om het begin van de volgende minuut aan te duiden, wordt de amplitude gedurende 0, 1s of 0, 2s verlaagd met ongeveer 25%. Dit wordt ge¨ıllustreerd in figuur 6.3

6.3 Atoomklokontvanger

69

Figuur 6.3: DCF77 signaal.

6.3

Atoomklokontvanger

Om het DCF77 signaal te ontvangen gebruiken we de DCF-ontvangersprintplaat van C-Control[42], weergegeven in figuur 6.4(a).

6.4 6.4.1

Implementatie Verbinden van de Tmote Sky en de DCF-ontvangersprintplaat

Pin 4 (van de 6 pinnen) op de Tmote Sky wordt hoog gezet en verbonden met de voedingsklem van de DCF-ontvangersprintplaat zodat deze een voedingsspanning krijgt. Ook wordt de massa van de Tmote Sky (pin 9) met de massa van de DCF-ontvangersprintplaat verbonden. De uitgangsklem waar het ge¨ınverteerde signaal op komt, wordt verbonden met de User Interrupt pin van de Tmote Sky (pin 5 van de 6).

6.4 Implementatie

70

(a) DCF-ontvangersprintplaat van C-Control.

(b) DCF-ontvangersprintplaat van C-Control: schema.

Figuur 6.4: DCF-ontvangersprintplaat van C-Control.

Figuur 6.5: Atoomklokontvanger verbonden met een sensor node.

6.4 Implementatie

71

Aangezien de signaaluitgang en de ge¨ınverteerde signaaluitgang een open collector vormen[43], moet er nog een weerstand tussen de voedingspin en deze uitgangen bijgeplaatst worden om de ontvangen signaalspanning te kunnen meten. Rekening houdend met een maximaal toelaatbare stroom van 1mA en met de opgelegde spanning via de pin van de Tmote Sky van 2, 9V , wordt er zowel tussen de voeding en de uitgangsklem als tussen de voeding en de ge¨ınverteerde uitgangsklem een weerstand van 10kΩ geplaatst. In figuur 6.5 wordt weergegeven hoe de DCF-ontvangersprintplaat verbonden wordt met de Tmote Sky.

6.4.2

nesC implementatie

De bedoeling van deze implementatie is om bij de interrupt gegenereerd op de dalende flank van de minuut, de timer op alle sensor nodes te herstarten. In het onderste deel van figuur 6.3 wordt deze flank weergegeven. Aangezien op seconde 59 geen puls gegenereerd wordt, maken we hiervan gebruik om bij de interrupts gegenereerd door de dalende flank te controleren of de vorige dalende flank al meer dan 1, 5s geleden was. Indien dit zo is, hebben we te maken met de dalende minuutmarkeringsflank, en wordt de functie om de timer te resetten opgeroepen. Verder wordt nog een extra vlag voorzien zodat we kunnen instellen of dit resetten van de timer gebeurt of niet. Na het resetten van de timer wordt deze standaard op false gezet, zodat het resetten slechts eenmaal wordt opgeroepen. Er is ook een extra controlevariabele start. Deze dient om de resetTimer functie nog niet op te roepen de eerste 5 seconden, omdat bij het opstarten van de sensor node de interrupts nog niet regelmatig optreden. Volgende code geeft de implementatie hiervan weer. async event void User.fired() { call Leds.led1Toggle(); timestampNieuw = call ResetCounter.get(); //if(timestampNieuw-timestampOud > 1,5s) -> nieuwe minuut -> timers resetten if(resetflag){ if(start>4){ if(timestampNieuw - timestampOud > 49152 )// = 1,5 s in binaire 32khz { //TimerB resetten call Leds.led0Toggle(); call ClockSettingCounter.resetTimer(); resetflag=FALSE; // zodat reset maar 1 keer wordt uitgevoerd } } else{ start++; } } timestampOud = timestampNieuw; //timestamp plaatsen + nummeren

6.4 Implementatie

72

timestampMsg.timestamp = timestampNieuw; timestampMsg.sendID = sendID++; //verzenden post SendSerialMessage(); //pin goedzetten call User.clear(); }

6.4.3

Het resetten van de timer

Op een analoge manier als in sectie 4.5.4 wordt er een nieuwe module aangemaakt die zowel een counter interface biedt als een interface waarmee de clear() functie van timerB kan uitgevoerd worden. De bestanden hiervan zijn terug te vinden in bijlage B.4.2. In figuur 6.4.3 worden de gelinkte bestanden weergegeven. Hierin moest er vooral op gelet worden dat, naast het resetten van timerB, eveneens de eerste 16 bits van de 32-bit counter moeten gereset worden. Dit gebeurt in de functie ClockSettingCounter.resetTimer() van TransformCustomizedResetCounterC.nc, de module die de 16-bit counter transformeert in een 32-bit counter, terug te vinden in bijlage B.4.2.

(a) ClockSettingMsp430CounterC.nc

(b) CounterMetReset32C.nc

Figuur 6.6: Structuur van de modules die een 32bit counter bieden met mogelijkheid om de counter te resetten.

6.4.4

Resultaten

Bij het ontvangen van een interrupt door een dalende flank op de user interrupt pin wordt de groene led geknipperd en wordt er ook een bericht met de genomen timestamp op dat ogenblik verzonden naar de corresponderende iNode. Er is duidelijk te merken dat er één keer per minuut geen verandering optreedt in de groene led. Dit correspondeert met de 59e seconde, waarop er geen flank optreedt. Op het resetmoment van de timer verandert ook de blauwe led. Via RadioPerf kunnen we dan

6.4 Implementatie

73

de doorgestuurde timestamps bekijken. Hier is duidelijk te zien dat de timestamps opnieuw vanaf 0 beginnen te tellen nadat de reset opgeroepen werd. Wanneer met verschillende sensor nodes een atoomklokontvanger verbonden wordt, beginnen de blauwe leds na een tijdje simultaan te branden, na het eenmalig niet herspringen van de groene led, dus op de minuutflank. De verschillende counters worden dus op hetzelfde moment gereset. Deze applicatie kan dus gebruikt worden om de counter van verschillende sensor nodes op eenzelfde moment, bij de dalende flank van de minuutmarkering van het ontvangen atoomkloksignaal, te herstarten zodat deze sensor nodes vanaf eenzelfde punt beginnen te tellen.

6.4.5

Opmerking: ontvangst

Deze testen werden op een andere locatie uitgevoerd dan in de gebouwen van de vakgroep van deze thesis, in de Zuiderpoort, aangezien er binnen deze gebouwen geen ontvangst mogelijk is van het DCF77 signaal. Het zal hierdoor niet mogelijk zijn de sensor nodes van het testbed uit te breiden met deze atoomklokontvanger.

BESLUIT

74

Hoofdstuk 7

Besluit Met de combinatie van • het synchroniseren van de iNodes via ptpd • een nauwkeurige timestamp plaatsen op de sensor node • een schatting van de offset en drift kan een goede vergelijking gemaakt worden tussen de tijd waarop verschillende gebeurtenissen plaatsvinden op het testbed. Wanneer één gebeurtenis op verschillende sensor nodes een timestamp krijgt en we hiervan, na de offset erbij op te tellen, het tijdstip op de iNode weten, wijken deze tijdstippen op de iNodes maximaal drie 32kHz kloktiks van elkaar af. Dit is dus minder dan het vooropgestelde doel van 100µs, waardoor we kunnen stellen dat het testbed zeer goed gesynchroniseerd kan worden. Verder werd ook nog de one-way-delay bij het verzenden van een bericht bepaald door het doorverbinden van het seriële DTR-signaal. Deze bedroeg voor een pakket van 20 bytes 1529µs, wat overeenkomt met een delay van 76, 45µs per verzonden byte. De offset werd ook op deze manier berekend en week maximaal 50µs af van haar gemiddelde waarde. Op de iNode kan de seriële DTR pin echter niet aangestuurd worden, dus deze methode werkt enkel tussen een PC met seriële poort en een sensor node. De offset kan ook berekend worden aan de hand van het doorverbinden van een signaal van de audio-uitgang van de iNode naar de sensor node. Dit geeft echter enkel nauwkeurige resultaten wanneer dit signaal een interrupt genereert op de user interrupt pin. De analoge ADC pin kan immers niet snel genoeg waarden uitlezen om een nauwkeurige timestamp te plaatsen. Hiernaast is er ook nog een mechanisme voorzien om de counters op de sensor nodes op eenzelfde moment te herstarten, door middel van een atoomklokontvanger. Deze implementatie levert eveneens de gewenste resultaten.

INSTALLATIE HANDLEIDINGEN

75

Bijlage A

Installatie handleidingen A.1

Installatie van ptpd

Inloggen op de iNodes Log in op de iNodes. De iNodes die gebruikt werden (2B1, 2B3, 2B6 en 2B9) zijn bereikbaar via een ssh gateway via respectievelijk poort 50089, 50091, 50094 en 50097. Deze gegevens zijn ook te vinden op http://10.10.5.226/motes-status.php (bereikbaar vanaf het netwerk in de Zuiderpoort). Inloggen kan zowel grafisch om bestanden erop te plaatsen (wat ook via scp gaat uiteraard) als via een ssh sessie op de commandline om commando’s uit te voeren: grafisch via bvb nautilus: ssh://[email protected]:50089 commandline: ssh -l WilabAdmin -p 50089 10.10.5.226 Met in bovenstaande poortnummers de 89 dan vervangen door de nodige poort. ptpd op iNodes plaatsen Maak een map voor ptpd: cd /tmp mkdir ptpd chmod 777 /ptpd Op pc vanwaar je bestand kopieert: kopieer ptpd naar de iNode: scp -P 50091 ptpd [email protected]:/tmp/ptpd Op iNode: maak het bestand uitvoerbaar:

A.2 Voyage Linux virtuele machine

76

cd /tmp/ptpd chmod 0755 ptpd

A.2

Voyage Linux virtuele machine

Mount de live cd in je virtuele machine. Inloggen kan met login root en paswoord voyage. Erna kan dit besturingssysteem als volgt ge¨ınstalleerd worden: 1. Creeer een map voor de installatie # mkdir /tmp/root # mount -o loop /live_media/casper/filesystem.squashfs # cd /tmp/root 2. Maak een mount punt voor de installatie # mkdir /tmp/cf 3. Formatteer de doellocatie # /usr/local/sbin/format-cf.sh /dev/sda 4. Start het voyage.update installatiescript # /usr/local/sbin/voyage.update

/tmp/root

Bij dit update script dienen enkel de defaults gevolgd te worden. Na het rebooten van de virtuele machine is Voyage Linux ge¨ınstalleerd. Met het commando remountrw kan lees- en schrijfrecht bekomen worden.

A.3

Het Java programma RadioPerf configureren en uitvoeren

In RadioPerfModel.java op regel 79 kan ingesteld worden naar welk bestand de gegevens uitgeschreven worden. Verder dient nog als argument de juiste poort meegegeven te worden. In Netbeans kan dit ingesteld worden door rechts te klikken op je project, Properties, Run, en hier bij Arguments: -comm serial@/dev/ttyUSBx:telos in te geven, met x te vervangen door het cijfer van de juiste USB poort. Voor de meeste pakketten willen we periodiek draadloze berichten verzenden. Dit kan ingesteld worden bij het uitvoeren van het programma, waarna in de GUI via enkele opties alle parameters kunnen ingesteld worden, zoals hoeveel pakketten verzonden dienen te worden, om de hoeveel tijd en met welke grootte.

A.4

Code op de sensor node plaatsen

Om de geschreven nesc code op de Tmote Sky te plaatsen, moet ze eerst gecompileerd worden. Ga in een terminal naar de juiste map en voer make telosb uit. Hiervoor moet wel TinyOS ge¨ınstalleerd zijn.

A.5 Applicatie op een iNode en bijhorende sensor node draaien ipv op een PC en bijhorende sensor node 77 Plaats de sensor nodes waar je de code wil opzetten in een USB-poort. Met het commando motelist verschijnt er een lijst met de poorten waarop een sensor node is aangesloten. De code kan dan op een sensor node geplaatst worden met het commando make telosb reinstall bsl,/dev/ttyUSB0, waar de 0 op het einde dient aangepast te worden naargelang de USBpoort waaraan de sensor node gekoppeld is. Deze twee commando’s kunnen ook in één keer uitgevoerd worden via het commando make telosb install bsl,/dev/ttyUSB0[44].

A.5

Applicatie op een iNode en bijhorende sensor node draaien ipv op een PC en bijhorende sensor node

A.5.1

Installeren van RadioPerfCmdLine op de iNodes

Maak een map aan om in te werken (bvb /tmp/commandline). Kopieer alle nodige bibliotheken naar de iNode met behulp van SCP: scp -P 50091 /usr/lib/libstdc++.so.5.0.7 [email protected]:/tmp/commandline/ scp -P 50091 /usr/lib/jvm/java-6-openjdk/jre/lib/i386/libtoscomm.so \ [email protected]:/tmp/commandline/ Kopieer het tinyos jar bestand naar de iNode: scp -P 50091 /opt/tinyos-2.x/support/sdk/java/tinyos.jar \ [email protected]:/tmp/commandline/ Kopieer het project jar bestand naar de iNode: scp -P 50091 dist/RadioPerfCommandline.jar [email protected]:/tmp/commandline/ Link de bibliotheken correct: ln -s libstdc++.so.5.0.7 libstdc++.so.5 Om de RadioPerf applicatie te laten lopen wordt volgend commando uitgevoerd (met aantal gelijk aan het aantal te versturen draadloze berichten): LD LIBRARY PATH=. CLASSPATH=RadioPerfCommandline.jar:tinyos.jar java RadioPerfCmdLine1x aantal

A.5.2

Installatie van een applicatie op een sensor node vanaf een iNode

Kopieer de applicatie naar de iNode: scp -P 50091 /opt/tinyos-2.x/apps/RadioPerfBetterTimestamp/build/telosb/main.ihex [email protected]:/tmp/RadioPerfBetterTimestamp Installeer de code op de sensor node: /usr/w-iLab.t/tos-bsl –telosb -c /dev/ttyUSB0 -r -e -I -p /tmp/RadioPerfBetterTimestamp/\

A.5 Applicatie op een iNode en bijhorende sensor node draaien ipv op een PC en bijhorende sensor node 78 main.ihex

A.5.3

Een C-programma op de iNode uitvoeren

Wanneer C-programma’s zoals ptpd en het offsetberekeningsprogramma op de iNodes moeten uitgevoerd worden, dienen zij eerst gecompileerd te worden op een machine die ook het Voyage Linux besturingssysteem draait, aangezien de iNodes niet over een compiler beschikken. Het offsetberekeningsprogramma steunt onder meer op TinyOS bestanden, dus dient eerst TinyOS ook op de Voyage Linux virtuele machine ge¨ınstalleerd te worden om dit te compileren. Dit gecompileerde bestand kan dan op de iNodes geplaatst worden en uitgevoerd worden.

CODE

79

Bijlage B

Code B.1 B.1.1

Code uit Hoofdstuk 3 RadioPerf

Java gedeelte programma RadioPerf RadioPerfModel.java

Zie cdrom.

nesC gedeelte programma RadioPerf RadioPerfMessages.h, RadioPerfC.nc, RadioPerfP.nc

B.1.2

Zie cdrom.

Pin Interrupt

Code van de sensor node die de puls aanlegt PinInterruptZenderC.nc, PinInterruptZenderP.nc Zie cdrom.

Code van de sensor nodes die de puls ontvangen PinInterruptMessages.h, PinInterruptC.nc, PinInterruptP.nc

Zie cdrom.

B.1 Code uit Hoofdstuk 3

B.1.3

80

Timestamp bij toekomend draadloos bericht lager op de stack nemen

Aanpassingen bij het toekomen van het draadloze bericht /tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveC.nc

Toegevoegde lijnen:

1 c o n f i g u r a t i o n CC2420ReceiveC { ... 3 } implementation { 5

... // Time f o r timestamp

7

components new CounterToLocalTimeC ( T32khz ) a s C o u n t e r L o c a l ; // K a r l i e n components Counter32khz32C ; // K a r l i e n

9

// Timer K a r l i e n CC2420ReceiveP . TimestampTime −> C o u n t e r L o c a l ; // K a r l i e n C o u n t e r L o c a l . Counter −> Counter32khz32C ; // K a r l i e n

11 }

Volledig bestand: zie cdrom. /tinyos-2.x/tos/chips/cc2420/receive/CC2420ReceiveP.nc Toegevoegde lijnen: module CC2420ReceiveP { 2

... // Timestamp K a r l i e n

4

u s e s i n t e r f a c e LocalTime a s TimestampTime ;

// K a r l i e n

} 6 implementation { ... 8

n x u i n t 3 2 t timestamp ; // K a r l i e n ...

10 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ InterruptFIFOP E v e n t s ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗/ 12

async e v e n t void InterruptFIFOP . f i r e d ( ) { i f ( m s t a t e == S STARTED ) {

14

timestamp = c a l l TimestampTime . g e t ( ) ; // K a r l i e n s i g n a l CC2420Receive . getTimestamp ( timestamp ) ; // K a r l i e n

16

18

beginReceive () ;

} else { m m i s s e d p a c k e t s ++;


81

}

20 } 22

... 24 }

Volledig bestand: zie cdrom. /tinyos-2.x/tos/chips/cc2420/interfaces/CC2420Receive.nc

Toegevoegde lijnen:

i n t e r f a c e CC2420Receive { 2

... // K a r l i e n

4

async e v e n t void getTimestamp ( n x u i n t 3 2 t betterTimestamp ) ; }

Volledig bestand: zie cdrom. /tinyos-2.x/tos/chips/cc2420/transmit/CC2420TransmitP.nc Toegevoegde lijnen: 1 module CC2420TransmitP { ... 3 } implementation { 5

... async e v e n t void CC2420Receive . getTimestamp ( n x u i n t 3 2 t lowertimestamp ) { }

7

... 9 }

Volledig bestand: zie cdrom.

Aanpassingen RadioPerf Enkel de aanpassingen tov RadioPerfC.nc en RadioPerfP.nc uit cdrom/Hoofdstuk 3: Code/RadioPerf Java worden hier getoond. RadioPerfC.nc 1

Volgende regels uit vorige versie uitcommentariëren:

// Time f o r timestamp //

components new CounterToLocalTimeC ( T32khz ) as C o u n t e r L o c a l ; // K a r l i e n


3 //

82

components Counter32khz32C ; ...

5

// Timer K a r l i e n RadioPerfP . TimestampTime −> C o u n t e r L o c a l ;

//

C o u n t e r L o c a l . Counter −> Counter32khz32C ;

7 //

Volgende code toevoegen: 1

components CC2420ReceiveC ;

3

RadioPerfP . CC2420Receive −> CC2420ReceiveC ;

RadioPerfP.nc

Volgende regels uitcommentariëren:

1 // Timestamp //

i n t e r f a c e LocalTime as TimestampTime ;

en in volgend event niets meer uitvoeren (geen timestamp meer nemen). e v e n t m e s s a g e t ∗ R a d i o R e c e i v e . r e c e i v e ( m e s s a g e t ∗msg , void ∗ payload , u i n t 8 t l e n ) { 2

}

En dan nog volgende code toevoegen: i n t e r f a c e CC2420Receive ; 2

4

/∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ Managing t h e r e c e i v i n g o f r a d i o messages

6 ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗/ //NIEUW 8

async e v e n t void CC2420Receive . getTimestamp ( n x u i n t 3 2 t lowertimestamp ) { timestampMsg . timestamp = lowertimestamp ;

10

// K a r l i e n : h i e r timestamp o v e r s e r i e e l v e r z e n d e n timestampMsg . sendID = sendID++;

12

timestampSender ( ) ; }

14 //NIEUW async e v e n t void CC2420Receive . r e c e i v e ( u i n t 8 t type , m e s s a g e t ∗ message ) { 16 }


B.2 B.2.1

83

Code uit Hoofdstuk 4 Offset Berekening

In de map 4 2 OffsetBerekening.

nesC code van de offset berekening voor op de sensor node OffsetberekeningMessages.h, OffsetberekeningC.nc, OffsetberekeningP.nc

Zie cdrom.

c code van de offset berekening voor op de INode Zie cdrom.

B.2.2

Bepalen one-way-delay en offset adhv het doorverbinden van een seri¨ ele pin

Zie cdrom, in de map 4 3 OneWayDelayEnOffset.

B.2.3

Bepalen van de delay op het afspeelcommando en effectief afspelen van een audiosignaal

Zie cdrom, in de map 4 4 AudioDelay. Uitleg bestanden in het bestand README.txt.

B.2.4

Bepalen van de offset adhv een audiosignaal

Zie cdrom, in de map 4 4 AudioOffsetBerekening. Uitleg bestanden in het bestand README.txt.

B.2.5

Andere timer instellen

In de map 4 5 Onderzoek naar nauwkeurigere timer. /tos/lib/timer/MicroClockSettingCounter.nc en TransformCustomizedCounterC.nc Zie cdrom. /tos/chips/msp430/timer/MicroClockSettingMsp430CounterC.nc en CounterMicro32C.nc Zie cdrom.


84

/tos/chips/msp430/timer/MicroClockSettingMsp430CounterP.nc Zie cdrom. In de functie MicroClockSettingCounter.setTimer() kan de geprefereerde timer ingesteld worden.

B.3 B.3.1

Code uit Hoofdstuk 5 Combinatie van de offsetberekening met het nauwkeurig plaatsen van een timestamp bij de ontvangst van een draadloos bericht

OffsetberekeningMessages.h, OffsetberekeningC.nc en OffsetberekeningP.nc

B.4

Code Hoofdstuk 6

B.4.1

Atoomklok ontvanger

AtoomklokontvangerMessages.h, AtoomklokontvangerC.nc en AtoomklokontvangerP.nc Zie cdrom.

B.4.2

Resetten van timerB

/tos/lib/timer/ClockSettingCounter.nc en ResetCounter.nc Zie cdrom. /tos/lib/timer/TransformCustomizedResetCounterC.nc

Zie cdrom.

/tos/chips/msp430/timer/ClockSettingMsp430CounterC.nc, ClockSettingMsp430CounterP.nc en CounterMetReset32C.nc Zie cdrom.

Zie cdrom.

BIBLIOGRAFIE

85

Bibliografie [1] Tmote Sky Brochure http://www.sentilla.com/pdf/eol/tmote-sky-brochure.pdf [2] Tmote Sky Datasheet http://www.sentilla.com/pdf/eol/tmote-sky-datasheet.pdf [3] Missie TinyOS http://www.tinyos.net/special/mission [4] http://en.wikipedia.org/wiki/TinyOS [5] TinyOS Documentatie http://www.tinyos.net/tinyos-2.x/doc/nesdoc/telosb/ [6] http://en.wikipedia.org/wiki/NesC [7] TinyOS Installatie http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos. html [8] http://en.wikipedia.org/wiki/Clock_synchronization [9] Officiële pagina NTP http://www.ntp.org [10] Uitleg over NTP http://www.eehomepage.com/query.php?Find=NTP [11] http://en.wikipedia.org/wiki/Network_Time_Protocol [12] Ntpd http://www.eecis.udel.edu/~mills/ntp/html/ntpd.html [13] NTP algoritme http://www.ntp.org/ntpfaq/NTP-s-algo.htm [14] Ptpd documentatie http://ptpd.sourceforge.net/doc.html [15] Ptpd http://ptpd.sourceforge.net/ [16] Officiële pagina IEEE 1588 http://ieee1588.nist.gov/ [17] Officiële pagina IEEE 1588 http://www.ieee1588.com/ [18] http://en.wikipedia.org/wiki/Precision_Time_Protocol [19] PTP Ines instituut http://ines.zhwin.ch/index.php?id=40&L=2 [20] PTPv2 http://ines.zhaw.ch/en/ieee-1588/software/ptp-version-2/page.html [21] A. McCarthy, “Special Focus: Understanding the IEEE 1588 Precision Time Protocol”, LabVIEW Special Edition issue of Instrumentation Newsletter, October 2005, http://zone.ni.com/devzone/cda/pub/p/id/130

BIBLIOGRAFIE

86

[22] D. Béchaz, H. Weibel, Zurich University of Applied Sciences, Institute of Embedded Systems (InES), “IEEE 1588: Implementation and Performance of Time Stamping Techniques”, 2004 Conference on IEEE 1588, September 2004, https://home.zhaw.ch/~wei/IEEE1588/PTP_Timestamping_Methods_Paper.pdf http://ines.zhaw.ch/uploads/media/PTP_Timestamping_Methods_03.pdf [23] T. M¨ uller, H. Weibel, A. Ockert, “PHYs and Symmetrical Propagation Delay”, 2004 Conference on IEEE 1588, September 2004, http://ines.zhaw.ch/uploads/media/PHYs_and_Symmetry_03.pdf [24] H. Weibel, Zurich University of Applied Sciences, Institute of Embedded Systems (InES), “IEEE 1588, Standard for a Precision Clock Synchronization Protocol”, 2005 Conference on IEEE 1588, July 2005, http://ines.zhaw.ch/uploads/media/IEEE_1588_Tutorial_engl_250705_01.pdf [25] H. Weibel, Zurich University of Applied Sciences, Institute of Embedded Systems (InES), “IEEE 1588 Tutorial”, 2006 Conference on IEEE 1588, October 2006, http://ines.zhaw.ch/uploads/media/2006_Conference_IEEE_1588_Tutorial_01.pdf [26] K. Correll, N. Barendt, M. Branicky, “Design Considerations for Software Only Implementations of the IEEE 1588 Precision Time Protocol”, 2005 Conference on IEEE 1588, October 2005, http://ptpd.sourceforge.net/ptpd_2005_1588_conference_paper.pdf [27] J. Eidson, “IEEE-1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, I&M Society IEEE 1588 Presentation, October 2005, http://ieee1588.nist.gov/tutorial-basic.pdf [28] PTP implementatie door RTS http://www.real-time-systems.com/ieee_1588/index. php [29] Message interface generator for nesC http://www.tinyos.net/tinyos-1.x/doc/nesc/ mig.html [30] C. Sharp, M. Turon, D. Gay, “Timers”, http://tinyos.cvs.sourceforge.net/*checkout*/tinyos/tinyos-2.x/doc/html/ tep102.html [31] “MSP430x1xx Family User’s Guide”, Hoofdstuk 4, 11 en 12, 2006 http://focus.ti.com/lit/ug/slau049f/slau049f.pdf [32] http://en.wikipedia.org/wiki/Unix_time [33] M. Maroti, B. Kusy, G. Simon, A. Ledeczi “The Flooding Time Synchronization Protocol”, 2004 https://www.isis.vanderbilt.edu/projects/nest/documentation/Vanderbilt_ NEST_TimeSynch.pdf [34] Baudrate ontvanger past zich aan aan baudrate verzender. http://forums.msdn. microsoft.com/en-US/netfxbcl/thread/29097d0c-9ec8-4fba-9361-bc9232ce8e2c/

BIBLIOGRAFIE

87

[35] Baudrate gegenereerd op een PC. http://www.mev.co.uk/usbbaud.htm [36] Officiële website van DCF77 http://www.ptb.de/en/org/4/44/442/dcf77_1_e.htm [37] Officiële website van DCF77 (Duits) http://www.dcf77.com/index.htm [38] http://en.wikipedia.org/wiki/DCF77 [39] http://nl.wikipedia.org/wiki/DCF77 [40] FAQ over DCF77 http://www.lacrossetechnology.fr/en/ R-2-A1-----frequently-asked-questions-radio-controlled-time.html [41] Synchronizing time with DCF77 and MSF60 http://www.compuphase.com/mp3/h0420_ timecode.htm [42] DCFontvangerprintplaat http://shop.conrad.nl/Elektronica,044_meetapparatuur/ Automatiseringstechniek/C,045control/C_Control_accessoires/641138.html [43] Elektronisch schema van de DCFontvangerprintplaat http://www2.produktinfo.conrad. com/datenblaetter/625000-649999/641138-sp-02-de-DCF-Empfaengerplatine.pdf [44] TinyOS Tutorial http://docs.tinyos.net/index.php/Getting_Started_with_TinyOS# Installing_on_telos-family_mote_.28telosa.2C_telosb.29

LIJST VAN FIGUREN

88

Lijst van figuren 1.1

Schematische voorstelling van het testbed. . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Onderdeel van het testbed: een sensor node die via USB verbonden is met zijn bijhorende iNode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

De iNodes van het testbed die gebruikt werden (in het geel onderlijnd). . . . . .

2

1.4

Onderdelen van de TMote-Sky. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1

Verschillende stratum lagen bij NTP. Groene pijlen duiden op een directe connectie, rode op een netwerk connectie. . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2

Berichten voor de delay berekening bij NTP.

. . . . . . . . . . . . . . . . . . . .

11

2.3

Synchronisatie met PTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.4

Synchronisatie met PTP: offset en delay berekening. . . . . . . . . . . . . . . . .

14

2.5

Verschillende plaatsen waar de tijd kan gemeten worden bij PTP. . . . . . . . . .

16

2.6

Schematische voorstelling van PTP . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.7

Offset tussen slave(iNode 89) en master(iNode 91) tijdens het ptpd proces. . . .

20

2.8

Offset tussen slave(iNode 94) en master(iNode 91) tijdens het ptpd proces. . . .

20

2.9

Offset tussen slave(iNode 89) en master(iNode 91) tijdens het ptpd proces: gestabiliseerde deel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.10 Offset tussen slave(iNode 94) en master(iNode 91) tijdens het ptpd proces: gestabiliseerde deel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.1

Mogelijke vertragende factoren bij het plaatsen van de timestamp in een Javaapplicatie op de controle PC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

3.2

Testopstelling Test 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.3

Verdeling van de afwijking op de 100ms in tiks. . . . . . . . . . . . . . . . . . . .

27

3.4

Verdeling van de afwijking op de 100ms in tiks. . . . . . . . . . . . . . . . . . . .

29

LIJST VAN FIGUREN

89

3.5

Testopstelling Test 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.6

Pinnen op de Tmote-Sky. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.7

Poorten op de MCU van de Tmote-Sky. . . . . . . . . . . . . . . . . . . . . . . .

32

3.8

Testopstelling voor de interrupts via het signaal op de pinnen. . . . . . . . . . . .

33

3.9

Verdeling van de afwijking van het verschil tussen de inter-arrival-tijden van de twee sensor nodes in tiks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

4.1

Schematische voorstelling van het protocol om de offset tussen de iNode en de sensor node te bepalen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

4.2

Verschil tussen opeenvolgende offsetwaarden bij de eerste sensor node. . . . . . .

45

4.3

Verschil tussen opeenvolgende offsetwaarden bij de tweede sensor node. . . . . . .

45

4.4

Methode voor het bepalen van de offset door het laagzetten van de seriële DTR pin en deze door te verbinden met de interrupt pin op de sensor node. . . . . . .

46

4.5

One-way-delay. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.6

One-way-delay: histogram.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.7

Opeenvolgende offsetwaarden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49

4.8

Verschil tussen opeenvolgende offsetwaarden. . . . . . . . . . . . . . . . . . . . .

49

4.9

Methode om de delay tussen het geven van het c-commando om de audio af te spelen en het effectieve afspelen ervan te bepalen. Aan de hand van deze delay kan dan door enkel een audioflank aan te leggen de offset tussen iNode en sensor node bepaald worden. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.10 Delay tussen het aanleggen van een blokgolf op de audio-uitgang van een iNode en het detecteren ervan op de ADC pin van de sensor node. . . . . . . . . . . . .

53

4.11 Decimaal gedeelte van de offset. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.12 Structuur van de modules die een 32bit counter bieden met mogelijkheid om een bepaald kloktype te selecteren. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

5.1

Afwijking op de interarrivaltijden tussen twee ontvangende sensor nodes: histogram. 61

5.2

Verschil van de berekende tijdswaarden tussen de verschillende iNodes. . . . . . .

65

5.3

Verdeling van de verschillen van de tijdswaarden tussen de verschillende iNodes.

65

6.1

Reikwijdte van het gebroadcaste DCF77 signaal. . . . . . . . . . . . . . . . . . .

67

6.2

Onderdelen per minuut van het gebroadcaste DCF77 signaal. . . . . . . . . . . .

68

6.3

DCF77 signaal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

6.4

DCF-ontvangersprintplaat van C-Control. . . . . . . . . . . . . . . . . . . . . . .

70

LIJST VAN FIGUREN

90

6.5

Atoomklokontvanger verbonden met een sensor node. . . . . . . . . . . . . . . . .

70

6.6

Structuur van de modules die een 32bit counter bieden met mogelijkheid om de counter te resetten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

LIJST VAN TABELLEN

91

Lijst van tabellen 2.1

Vergelijking van enkele synchronisatieprotocollen. . . . . . . . . . . . . . . . . . .

17

3.1

Resultaten Test 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

26

3.2

Resultaten Test 1 met aangepaste backofftijd bij de zender Tmote Sky . . . . . .

28

3.3

Resultaten Test 2: ontvangsttijden op twee sensor nodes vergelijken

. . . . . . .

30

3.4

Resultaten Test 3: verschil tussen opeenvolgende timestamps op de eerste sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

3.5

Resultaten Test 3: verschil tussen opeenvolgende timestamps op de tweede sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

3.6


. . . . . . .

36

3.7

Resultaten Test 4: verschil tussen opeenvolgende timestamps op de eerste sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.8

Resultaten Test 4: verschil tussen opeenvolgende timestamps op de tweede sensor node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

3.9


. . . . . . .

39

4.1

Delay tussen een computer en twee verschillende sensor nodes. . . . . . . . . . .

44

4.2

Verschil tussen opeenvolgende offsetwaarden tussen een computer en twee verschillende sensor nodes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4.3

Delay tussen het aanleggen van een blokgolf op de audio-uitgang van een iNode en het detecteren ervan op de ADC pin van de sensor node. . . . . . . . . . . . .

53

4.4

Verschil tussen opeenvolgende offsetwaarden tussen een computer en een sensor node met een TimerA microseconde counter. . . . . . . . . . . . . . . . . . . . .

57

4.5

Timestamps bij verschillende timers na elke 10e binaire seconde. . . . . . . . . .

58

5.1

Drift tussen iNode 89 en de PC.

62

. . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitie en ontwikkeling van een tijdsynchronisatiemechanisme voor het sensor testbed en sensor netwerkapplicaties

Recommend Documents