[Tinyos-help] Bug in CC2420 timestamp

Jeongyeup Paek jpaek at usc.edu
Wed Oct 31 09:37:19 PDT 2007


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


More information about the Tinyos-help mailing list