I've also seen issues with incorrect timestamps. Like David says, a problem may be how a packet can be identified as dropped (by the address recognition), because currently this is done by calculating the time between rising and falling SFD (which may not be a 100% reliable approach). I have two additional remarks (the second may affect the timestamping issue): - in CC2420ReceiveP when StdControl.stop is called it should check whether it owns the SPI and if so give it up, otherwise there can be a deadlock (this is done in CC2420TransmitP.StdControl.stop by default) - it might be helpful to flush the respective FIFO in the StdControl.stop commands
Jan On 11/1/07, Jeongyeup Paek <[EMAIL PROTECTED]> wrote: > Thanks for explaining the edge cases. > > Yes, what I've described earlier was incorrect, and that was one > of the several things that I tried out to get around the problem. > Right now, what I am doing is filtering out the timestamps > by taking another timestamp when packet receive event is > signaled and comparing them; discard when diff is greater than > some threshold. (~150 ticks ~= 5ms) > > Thanks > > - jpaek > > > David Moss wrote: > > 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
