Hi, Is it possible that while a packet is being received, another packet arrives? How does CC2420X stack deal with this case? Thanks.
On Mon, Nov 19, 2012 at 10:45 AM, Janos Sallai <janos.sal...@vanderbilt.edu>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 <xiao...@wayne.edu> 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 <xiao...@wayne.edu> 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 < >>> janos.sal...@vanderbilt.edu> 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 <xiao...@wayne.edu> wrote: >>>> >>>>> Hi, >>>>> >>>>> Thanks again. Still one question in line. >>>>> >>>>> On Thu, Nov 15, 2012 at 3:35 PM, Janos Sallai < >>>>> janos.sal...@vanderbilt.edu> 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 <xiao...@wayne.edu>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 < >>>>>>> janos.sal...@vanderbilt.edu> 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 <xiao...@wayne.edu>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 >>>>>>>>> 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
