[Tinyos-help] Bug in CC2420 timestamp

[Jeongyeup Paek]

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: tinyos-help-bounces at Millennium.Berkeley.EDU
> [mailto:tinyos-help-bounces at Millennium.Berkeley.EDU] On Behalf Of Jeongyeup
> Paek
> Sent: Wednesday, October 31, 2007 9:37 AM
> To: Min Guo
> Cc: Federico Fiorentin; tinyos-help at 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 <f.fiorentin at gmail.com> 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 <mmaroti at math.u-szeged.hu>:
>>>> 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 <dmm at rincon.com> 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: tinyos-help-bounces at Millennium.Berkeley.EDU
>>>>> [mailto:tinyos-help-bounces at Millennium.Berkeley.EDU] On Behalf Of
> Federico
>>>>> Fiorentin
>>>>> Sent: Tuesday, October 30, 2007 6:39 AM
>>>>> To: tinyos-help at 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 at Millennium.Berkeley.EDU
>>>>>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>>>
>>>>> _______________________________________________
>>>>> Tinyos-devel mailing list
>>>>> Tinyos-devel at Millennium.Berkeley.EDU
>>>>>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>> _______________________________________________
>>> Tinyos-help mailing list
>>> Tinyos-help at Millennium.Berkeley.EDU
>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
>>>
>> _______________________________________________
>> Tinyos-help mailing list
>> Tinyos-help at 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