Hi Sinan, > I have used 3 nodes. One of the nodes (reference node) broadcast a packet > using TimeSyncAMSend interface at every 0x500000 microseconds and the other > nodes which are in the broadcast range of the sender receive this message > and queries the corresponding local time transformation of the send time at > the reference node using "call TimeSyncPacket.eventTime(msg);". I'm still missing a couple of details: - How do you achieve 0x500000 microsecond periodicity? Is it some kind of a 32-bit alarm built on top of AlarmMicro16C? - When calling TimeSyncAMSend.send(). what is the event time you supply there? Is it simply a call to LocalTime.get()? Do you use LocalTimeMicroC as a source of microsecond precision local time.
> As seen, this difference changes a lot every time. For example for node 0x1 > we measure 0x4F05BD for the event_time(packet2) -event_time(packet1). > However, again for the node 0x1 we measure 0x500154 for the > event_time(packet3) -event_time(packet2). This is my problem. My guess is that the event time with which TimeSyncAMSend.send() is the culprit. If you're using a time source that's driven by the DCO, you'll going to see huge clock drifts. (This does not happen with the external 32kHz crystal, since that's much more stable.) To check if this is the case, do the following. Change the reference node's code such that a led is toggled when TimeSyncAMSend.send() is called. Program two nodes as reference nodes, place them right next to each other, reset them at the same time, and see if they keep blinking together. My guess is that they get desynchronized very soon. If this is the case, would you mind trying to use vu/tos/chips/msp430/timer/AlarmHybridMicro32C.nc as your triggering alarm? This one should have a much better stability, but still providing microsecond precision. Janos _______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
