2 edge cases: 1) A packet is received, generating a timestamp. The packet is dropped internally to CC2420 hardware, while a second packet is received which generates a second timestamp. The older timestamp is applied to the newer packet.
2) A corrupted packet is received, forcing the CC2420 driver to flush out the RX FIFO. The timestamp queue is possibly not flushed. The next packet received gets a corrupted timestamp. Both of these edge cases can be reproduced on a single node through the use of unit tests. After reproducing the errors with unit testing, we can engineer a solution and use those tests to know when the problem has been solved. One possible solution, which is what you may have been leading to: We can generate a second timestamp for the "end of frame" SFD interrupt. Comparing the SFD with EFD timestamps, we know if the duration of the packet was too short and discard the timestamp. There are probably more reliable solutions though. How does comparing msg->time to the CC2420Receive.sfd( uint16_t time ) 'time' value tell you that the timestamp should be discarded? That 'time' value from the SFD interrupt gets stored in the timestamp queue before being propagated to msg->time. Is there a 3rd issue here where msg->time is not being set correctly to the latest value from the timestamp queue? -David -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeongyeup Paek Sent: Wednesday, October 31, 2007 9:37 AM To: Min Guo Cc: Federico Fiorentin; tinyos-help@Millennium.Berkeley.EDU Subject: Re: [Tinyos-help] Bug in CC2420 timestamp I am also having the same problem: incorrect timestamps. This happens more often when there are more nodes sending more packets. (which means more more sfd interrupts) As Miklos said, the problem is not overflow but mismatch between the timestamp(at sfd interrup) and the received packet. As Federico said, the incorrect time is always in the past. From these experience, we can guess that something is going wrong in the management of timestamp_queue[] in CC2420ReceiveP.nc. One way to check whether I have a wrong time or not is, - when I get receive sfd signal, write down the 'uint16_t time16'. - later, when I get a packet, compare 'time16' with 'msg->time'. If they do not match, something went wrong... should discard. One thing I am going to try today is to increase the size of "timestamp_queue[] in CC2420ReceiveP.nc": 8 --> 32; since it might just be because of queue wrapping around. Right now, there is no protection for 'head' and 'tail' pointers for timestamp_queue[]. Thanks - jpaek Min Guo wrote: > Hi Federico, > > I met the same problem. I've written a time synchronization component > for TinyOS 2.x. Currently some (very few) synchronization messages are > discarded because of the error of metadata->time (earlier than > expected). > > Hope some one can point out the reason. > > Regards, > Min > > On 10/31/07, Federico Fiorentin <[EMAIL PROTECTED]> wrote: >> Hi all. >> The issues is the 16-bit timestamp in the received packet somethimes >> results incorrect, in that case the time result always less than what >> I aspect. >> Probably the the timestamp refers to the previous SFD signal. >> >> I tried to compare that timestmap against the time argument of the >> RadioTimeStamp.receivedSFD(uint16_t time){ }. When the timestamp is >> correct generally they are equal, in the other cases the >> RadioTimeStamp result more precise. >> >> Using: >> RadioTimeStamp.receivedSFD(uint16_t time){ } >> Now the problem is how can I determine to which kind of packet the SFD >> event is referred. >> >> Federico >> >> 2007/10/30, Miklos Maroti <[EMAIL PROTECTED]>: >>> Hi David, >>> >>> The problem is not that it overflows, but it contains an inccorect >>> value. In certain situations there are more packets in the RXFIFO and >>> we do not know how to pair up the timestamps made for the SFD and the >>> data packets. This is especially problematic if for some reason some >>> of those packets get lost or not even get into the RXFIFO. >>> >>> We should start a discussion on the Timestamping interface. I think it >>> should be allowed for the radio stack to say that it could not >>> properly timestamp the packet (just a flag) and the time synch apps >>> should check for that flag. >>> >>> Miklos >>> >>> On 10/30/07, David Moss <[EMAIL PROTECTED]> wrote: >>>> I haven't done much work with the timestamps in the CC2420 apart from >>>> Jonathan's original implementation, nor have I used it enough to have >>>> experienced any type of erratic behavior. Is the issue here that the 16-bit >>>> timestamp rolls over to 0 periodically? Would a 32-bit timestamp be better? >>>> >>>> -David >>>> >>>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Federico >>>> Fiorentin >>>> Sent: Tuesday, October 30, 2007 6:39 AM >>>> To: tinyos-help@Millennium.Berkeley.EDU >>>> Subject: [Tinyos-help] Bug in CC2420 timestamp >>>> >>>> I'm working on time synchronization with tmote sky motes and TinyOS2. >>>> >>>> I'm using a poller that sends a PollPacket every X milliseconds and a >>>> set of clients that timestamp the arrival time of the PollPacket. >>>> I found that the 16 timestamp in the time field of the Metadata are >>>> somethimes incorrect ( CC2420Packet.getMetaData(msg)->time ). >>>> >>>> This affects the 1% of the TimeStamps per mote. >>>> I compared the value "timestamp(n) - timestamp(n-1)" of two different motes. >>>> >>>> Is there any patch or a way to fix it? >>>> >>>> I appreciate any advice >>>> _______________________________________________ >>>> Tinyos-help mailing list >>>> Tinyos-help@Millennium.Berkeley.EDU >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>> >>>> >>>> _______________________________________________ >>>> Tinyos-devel mailing list >>>> [EMAIL PROTECTED] >>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel >>>> >> _______________________________________________ >> Tinyos-help mailing list >> Tinyos-help@Millennium.Berkeley.EDU >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > _______________________________________________ > Tinyos-help mailing list > Tinyos-help@Millennium.Berkeley.EDU > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help -- Jeongyeup Paek Ph.D. student Embedded Networks Laboratory Department of Computer Science University of Southern California http://enl.usc.edu/~jpaek _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
