Hi,
I am working on project for which we need time synchronization with
accuracies in range of 10-20 microsecond,we are using custom zigbit boards
for this.
I have tested FTSP protocol in range of milliseconds in a small single hop
network with 6 nodes and I got mean absolute deviation to be close to 1 ms.
However, since it has already been tested at level of accuracies of
microsecond, I wanted to test this at precision of microseconds. I have made
the following changes to include support for Microsecond level of
synchronization in FTSP for Zigbit modules. ( I am using Internal RC
oscillator and modules are running at 8MHz, this gives us Timer 3C to be
roughly 1 MHz if prescaler of 8 is chosen)
Similar to TimeSync32kC, I have defined TimeSyncMicroC :
I have replaced occurrence of TMilli for precision with TMicro and I am
using TimeSyncAMSendRadio instead of TimeSyncAMSendMilli, for local time I
am using LocalTimeMicroC component and wiring it to LocalTime of TimeSyncP.
LocalTimeMicroC is implemented like this :
configuration LocalTimeMicroC
{
provides interface LocalTime<TMicro>;
}
implementation
{
components CounterThree16C;
components new TransformCounterC(TMicro, uint32_t, TMicro, uint16_t,
0, uint32_t);
components new CounterToLocalTimeC(TMicro);
LocalTime = CounterToLocalTimeC;
CounterToLocalTimeC.Counter -> TransformCounterC;
TransformCounterC.CounterFrom -> CounterThree16C;
}
I have modified TestFtsp program to use TimeSyncMicroC component instead of
TimeSyncC. I am using TIMESYNC_RATE of 1 seconds .
However, when I run FtspDataLogger java application :
It seems the nodes are getting synchronized , however,the global time stamps
it seems are two decimal larger than what they should be, for instance when
I switch on the nodes and after a second, when the global time stamp should
be lets say 123456 microseconds, I am instead getting 12345678 . There are
two additional digits at the end. Is this because we don't exactly have 1Mhz
and this represents fractional part? or is there anyother reason for this ?
A Sample output ( Taken 10-15 seconds after switching on two nodes ):
1316289798632 1 10862 123875602 0
1316289798640 2 10862 123877248 0
1316289798876 1 10863 125779640 0
1316289798880 2 10863 125782999 0
1316289799116 2 10864 127696422 0
1316289799128 1 10864 127692081 0
1316289799364 1 10865 129618795 0
1316289799368 2 10865 129623388 0
1316289799608 1 10866 131552548 0
1316289799612 2 10866 131556963 0
1316289799852 1 10867 133461952 0
1316289799856 2 10867 133466610 0
1316289800096 1 10868 135392969 0
1316289800100 2 10868 135398599 0
1316289800344 1 10869 137331991 0
1316289800348 2 10869 137338190 0
1316289800588 1 10870 139256495 0
1316289800592 2 10870 139263078 0
1316289800828 1 10871 141149451 0
1316289800832 2 10871 141154505 0
1316289801072 1 10872 143077883 0
1316289801076 2 10872 143083971 0
1316289801316 1 10873 144992362 0
1316289801320 2 10873 144999012 0
1316289801564 1 10874 146945885 0
1316289801808 1 10875 148867941 0
1316289801812 2 10875 148874823 0
1316289802050 2 10876 150790668 0
1316289802059 1 10876 150784937 0
Also if we discard last two digits, and assume the rest to be microsecond
representation of when the broad-casted message was received ( Beaconing
rate 250ms) by node, the errors it seems is more than few microseconds,
which I assume is because of using Internal RC oscillator and not external
crystal to maintain time and problem with stability. is there anything I can
do to improve this ? as zigbit modules have not exposed pin of Atmega1281
for having external crystal to drive MCU clock or 32KHz crystal to maintain
time.
Thanks,
Ambuj Varshney
Research Engineer
Embedded systems and Wireless Sensor Group
DAIICT, India
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
