Difference between revisions of "PacketTimeStamp CC2420 bug"
(→Evidence) |
(→Evidence) |
||
| Line 27: | Line 27: | ||
the problem is clearly on the rx side: eg. mote 1 transmitted msg 27 and the receiver 2 timestamped it with a value 337 jiffies (about 10ms) higher than expected. | the problem is clearly on the rx side: eg. mote 1 transmitted msg 27 and the receiver 2 timestamped it with a value 337 jiffies (about 10ms) higher than expected. | ||
| − | [[ | + | [[PacketTimeStamp_CC2420_bug_log1_full]] |
| − | [[ | + | [[PacketTimeStamp_CC2420_bug_log1_errors_only]] |
Revision as of 13:43, 12 August 2008
Contents
PacketTimeStamp Bug in CC2420 radio chip
Parent Project: FTSP
Related TEP: PacketTimeStamp TEP
Description of PacketTimeStamp
PacketTimeStamp interface provides accurate timestamping of radio messages low in the radio stack (MAC layer). this is required to allow for accurate time-synchronization algorithms built on top of PacketTimeStamp interface.
CC2420 radio chip implementation of PacketTimeStamp uses SFD interrupt for both reception and transmission timestamps. Time difference between the SFD interrupt firing at sender and receiver is less then 1 microsecond, theoretically allowing for sub-microsecond accuracy. To eliminate interrupt handling delays, mote platforms connect capture timer to the SFD interrupt line, recording the timestamp irrespective of when the interrupt is handled in software. MicaZ uses Timer1 (driven by external 32khz oscillator). Telos uses TimerX (driven by xxx).
Timestamps recorded at SFD interrupt are saved in cc2420_metadata_t.timestamp and are not transmitted in the air. Specifically, saving timestamps is done using PacketTimeStamp.set() in tos/chips/cc2420/CC2420TransmitP.nc (TX side) and tos/chips/cc2420/CC2420ReceiveP.nc (RX side). Client application can read this timestamp from Receive.receive() or AMSend.SendDone() events.
One problem is that multiple messages may be received before the client application has a chance reading the timestamp in receive() event. Therefore, CC2420ReceiverP.nc maintains a FIFO buffer for all received timestamps and serves them to the client app as needed.
Bug Description
The bug is related to the FIFO buffer with received timestamps: it seems that sometimes timestamps are not dropped from FIFO, even though the message corresponding message was dropped.
Evidence
Test application: TestPacketTimeStamp
Setup: 4 micaz nodes (ids=1,2,3,9) running TestPacketTimeStamp application, 1 micaz running BaseStation
each TestPacketTimeStamp node periodically timestamps and transmits radio messages using PacketTimeStamp<T32khz> (1 jiffy=30.5us), tx timestamp is embedded in the transmitted message. when the node receives a timestamped radio message, it reports both TX and RX timestamps to the base station. i wrote a simple java app which looks at the timestamps and tries to find inconsistencies. time errors can be found by looking at time offsets of clocks of 2 nodes. these offsets change very little over time - if there is a big jump (ie. more than a few clock ticks), we have a problem. i report all errors over 5 jiffies and i only look at messages transmitted by node 1 in the log bellow. i calculate 2 errors RXTX is between receiver and transmitter (ie. using both tx and rx timestamps), and RXRX error between 2 receivers who timestamped the same message (ie. using 2 rx timestamps).
the problem is clearly on the rx side: eg. mote 1 transmitted msg 27 and the receiver 2 timestamped it with a value 337 jiffies (about 10ms) higher than expected.
