Hi, I'm aware of the timing issue in the default CC2420 stack, e.g., timestamping under heavy load as this figure<http://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg> shows. Consequently, FTSP is yielding up to 200 jiffies error when integrated into my protocol which generates heavy traffic, not precise enough. One choice would be fixing the timestamping bug in CC2420 and I'm trying to see how CC2420*X* avoids the bug, which may give me some hint. Thus the previous question about CC2420*X.*
Another choice would be get microsecond timestamping and FTSP, but I'm not sure how much sync error this can help reduce given the timestamping bug. Any comment on this? Thanks all for your replies. -Xiaohui Liu On Mon, Nov 19, 2012 at 7:42 PM, Eric Decker <[email protected]> wrote: > > > On Mon, Nov 19, 2012 at 4:21 PM, Xiaohui Liu <[email protected]> wrote: > >> Hi, >> >> Is it possible that while a packet is being received, another packet >> arrives? How does CC2420X stack deal with this case? Thanks. >> > > that would have to stack in the fifo in the cc2420. > > I'm not sure how the driver and the cc2420 deals with being able to see > the packet boundary. > > there are numerous timing issues and I'm not sure that the corner cases > have been dealt with. > > > good question though. I like the way you think. > > >> >> On Mon, Nov 19, 2012 at 10:45 AM, Janos Sallai < >> [email protected]> wrote: >> >>> The two stacks differ in how the SFD interrupts are handled on the >>> receiver, and in when the received packet is downloaded from the radio >>> chip's FIFO. The default stack saves the SFD timestamp in a queue. After >>> the SFD interrupt, the default stack waits until the entire packet is >>> received into the radio chip's FIFO buffer. Only after the entire packet >>> has been received does it start downloading it to a message_t structure in >>> the MCU's RAM. When the download of the packet is complete and the CRC is >>> OK, the corresponding timestamp is removed from the queue and placed in the >>> metadata of the message_t structure. In the default stack, FIFO download of >>> one packet may overlap with the reception of a subsequent packet. Of >>> course, if something goes wrong during reception (e.g. length byte >>> corrupted, bad CRC, etc.) the timestamp corresponding to the SFD event of >>> that particular bad message must be discarded. This timestamp might not be >>> at either end of the timestamp queue. Peope suspect that this what's done >>> wrong in the CC2420 code, because the timestamp mixup only happens under >>> heavy load, when the timestamp queue is "long". >>> >>> The CC282X stack, on the other hand, doesn't maintain a timestamp queue. >>> If an SFD event occurs, it stays in interrupt context until the entire >>> packet is downloaded from the radio chip's FIFO buffer. The bytes are >>> downloaded as they are received (vs. the default stack, where the download >>> starts after the entire packet is received). This way, if the message >>> reception is complete, we can be sure that the correct timestamp is >>> associated with the buffer. >>> >>> Janos >>> >>> >>> On Sun, Nov 18, 2012 at 9:23 PM, Xiaohui Liu <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> According to this >>>> figure<http://www.cs.wayne.edu/xliu/downloads/offset_vs_local_time.jpg>, >>>> there is definitely some bug for timestamping in the default CC2420 radio >>>> stack, especially under heavy load. Can you please tell me how timestamping >>>> is done in CC2420X and how it avoids the potential bug CC2420 stack has? >>>> Thanks. >>>> >>>> >>>> On Thu, Nov 15, 2012 at 4:00 PM, Xiaohui Liu <[email protected]> wrote: >>>> >>>>> Thanks. >>>>> >>>>> Anyone else wants to share some experience implementing microsecond >>>>> ftsp on TelosB? >>>>> >>>>> -Xiaohui Liu >>>>> >>>>> On Thu, Nov 15, 2012 at 3:49 PM, Janos Sallai < >>>>> [email protected]> wrote: >>>>> >>>>>> You will probably have to change the clock source (change T32khz to >>>>>> TMicro). I'm not familiar with the code, so I can't tell you where this >>>>>> has >>>>>> to be done in the code. >>>>>> >>>>>> Also, you'll have to prevent the MCU from sleeping, because the >>>>>> TMicro clock stops when the mote goes to sleep. >>>>>> >>>>>> Janos >>>>>> >>>>>> >>>>>> On Thu, Nov 15, 2012 at 2:39 PM, Xiaohui Liu <[email protected]>wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Thanks again. Still one question in line. >>>>>>> >>>>>>> On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> > So essentially, ftsp only works with cc2420x stack, not cc2420. >>>>>>>> The cc2420 stack has a timestamping bug, so it won't work well. >>>>>>>> >>>>>>>> > What are the changes to the default cc2420 stack if the fix is to >>>>>>>> be ported to it? >>>>>>>> I can't tell that. I found the cc2420 stack to be very complicated. >>>>>>>> Instead of trying to figure out how to fix the timestamping bug, I >>>>>>>> wrote a >>>>>>>> complete new stack from scratch. >>>>>>>> >>>>>>>> > I find something under $TOSDIR/platforms/telosa/chips/cc2420x/ >>>>>>>> and $TOSDIR/chips/cc2420x, but not sure which files to look at. >>>>>>>> The file that contains the cc2420x timestamping implementation >>>>>>>> is tos\chips\cc2420x\CC2420XDriverLayerP.nc. >>>>>>>> >>>>>>>> >>>>>>>> > Provided that the fix solves the timestamping issue, what else >>>>>>>> has to be changed to make microsecond ftsp work with cc2420 stack? >>>>>>>> If you can fix the timestamping issue on the cc2420 stack, then >>>>>>>> FTSP should work correctly. >>>>>>>> >>>>>>> 32khz and millisecond ftsp should work. What about *microsecond*ftsp? >>>>>>> What changes are necessary? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>> > BTW, can you please also help answer my previous >>>>>>> > question<http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html> >>>>>>> > related >>>>>>>> to timestamping? >>>>>>>> That question is related to the cc2420 stack, so I can't answer >>>>>>>> this. I more than happy to answer questions related to the cc2420x >>>>>>>> stack, >>>>>>>> though. >>>>>>>> >>>>>>>> Janos >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 15, 2012 at 2:12 PM, Xiaohui Liu <[email protected]>wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> So essentially, ftsp only works with cc2420x stack, not cc2420. >>>>>>>>> >>>>>>>>> What are the changes to the default cc2420 stack if the fix is to >>>>>>>>> be ported to it? I find something under >>>>>>>>> $TOSDIR/platforms/telosa/chips/cc2420x/ and $TOSDIR/chips/cc2420x, >>>>>>>>> but not >>>>>>>>> sure which files to look at. >>>>>>>>> >>>>>>>>> Provided that the fix solves the timestamping issue, what else has >>>>>>>>> to be changed to make microsecond ftsp work with cc2420 stack? >>>>>>>>> >>>>>>>>> BTW, can you please also help answer my previous >>>>>>>>> question<http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2012-October/055927.html> >>>>>>>>> related >>>>>>>>> to timestamping? >>>>>>>>> >>>>>>>>> Your help is sincerely appreciated. >>>>>>>>> >>>>>>>>> -Xiaohui Liu >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Nov 15, 2012 at 2:12 PM, Janos Sallai < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> There is weird bug in the timestamping code in the cc2420 stack. >>>>>>>>>> Sometimes packets get timestamps that should be associated with a >>>>>>>>>> different >>>>>>>>>> packet. A few people tried to fix it, yet unsiccessfully. That was >>>>>>>>>> the >>>>>>>>>> primary reason why the cc2420x stack was created. >>>>>>>>>> >>>>>>>>>> Janos >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Thu, Nov 15, 2012 at 10:48 AM, Xiaohui Liu >>>>>>>>>> <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>>> Hi everybody, >>>>>>>>>>> >>>>>>>>>>> I'm working on a TDMA protocol which requires high precision, >>>>>>>>>>> even 32khz ftsp does not work for me. I can get microsecond >>>>>>>>>>> precision if >>>>>>>>>>> cc2420x stack is used instead of the default cc2420 based on the >>>>>>>>>>> discussions like >>>>>>>>>>> here<http://mail.millennium.berkeley.edu/pipermail/tinyos-help/2011-April/050745.html> >>>>>>>>>>> and >>>>>>>>>>> here<http://ftsp%20microseconds%20synchronization%20usign%20telosb/>. >>>>>>>>>>> However, there are many changes of the default cc2420 driver I >>>>>>>>>>> made, so >>>>>>>>>>> it's much easier for me to stick to cc2420 than to apply all >>>>>>>>>>> changes to >>>>>>>>>>> cc2420x. Is microsecond-level ftsp implemented on TelosB using >>>>>>>>>>> default >>>>>>>>>>> cc2420? If not, what changes are necessary to have it? Thanks for >>>>>>>>>>> any hint >>>>>>>>>>> in advance. >>>>>>>>>>> >>>>>>>>>>> -Xiaohui Liu >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Tinyos-help mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> Tinyos-help mailing list >> [email protected] >> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > > > -- > Eric B. Decker > Senior (over 50 :-) Researcher > > >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
