The ACK delay was increased from ~128 (or lower) from earlier versions of the CC2420 to 256 simply to handle these types of cases. Functional tests show this delay works well for 'normal' networks of multiple nodes and unaltered CSMA backoffs; however, modifying the CSMA behavior may necessitate changes to the ACK delay. The ACK delay, like many parameters in the stack, was chosen based on the results of functional testing (with no SPI0 DMA).
I'm not sure off the top of my head what the SPI throughput is, but it can also vary based on DMA settings. Adding SPI0 DMA support greatly increases the throughput. -David -----Original Message----- From: Liusand [mailto:[EMAIL PROTECTED] Sent: Monday, March 17, 2008 8:08 AM To: David Moss; tinyos-help@millennium.berkeley.edu Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? Hi David, Thanks for the explanation. The treatment of packets already in the RXFIFO queue is definitely reasonable to the receiver. But if we use SACK to issue acknowledgements like in CC2420ReceiveP.nc, the 3rd packet may wait quite some time before the ack for it is sent, and hence the deadline at sender side may have been missed. The delay before ack timer fires is CC2420_ACK_WAIT_DELAY = 256, so does it take the delay in reading RXFIFO into consideration? What is the SPI speed in TelosB or TmoteSky? Thanks, Sha -------------------------------------------------- From: "David Moss" <[EMAIL PROTECTED]> Sent: Monday, March 17, 2008 10:21 AM To: "'Liusand'" <[EMAIL PROTECTED]>; <tinyos-help@millennium.berkeley.edu> Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS 2.0.2? > Hi Sha - > > You're right, we are missing a check for RXFIFO overflow. Right now the > maximum default CC2420 packet size in TinyOS is 41 bytes (including CRC). > The RXFIFO is 128 bytes, which means you'd be able to fit 3 full packets > in > the RXFIFO before an overflow occurs. Although I think it may be unlikely > that you'd spontaneously receive 3+ full packets in the RXFIFO due to CSMA > backoffs and transmit delays, it can still happen. > > But imagine this scenario: you receive 3 maxed-out packets that are valid, > and get a fourth packet that causes an RXFIFO overflow, and is therefore > corrupted. Do you flush the RXFIFO at that point and lose the 3 valid > packets that are already in there? Or do you wait until you're reading > out > the fourth packet that is corrupted before flushing it? In the current > scenario, you read out the amount of data as specified by the fourth > packet > and see that the CRC doesn't check out. Upon reading the next packet, the > length is found to be invalid and the RXFIFO is flushed. > > Putting in an explicit check for RXFIFO overflow may be more desirable, > but > the question is, when is the best time to flush the RXFIFO? Right when > the > error occurs? Or after you get any remaining valid packets out? > > -David > > > > -----Original Message----- > From: Liusand [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2008 10:33 PM > To: David Moss; tinyos-help@millennium.berkeley.edu > Subject: Re: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS > 2.0.2? > > Thanks, David. > > I have some questions concerning RXFIFO overflow. In CC2420ReceiveP.nc, > RXFIFO is flushed only when the length byte is invalid. So where is RXFIFO > overflow taken care of? Can reading bytes from RXFIFO automatically clear > the overflow status? > > Also, in CC2420TransmitP, RXFIFO overflow status is not checked before > issuing the STXONCCA or STXON strobe. So if RXFIFO has already overflowed, > there will be no more space for ack frame. TinyOS 1.1.15 does do this > check > before sending and flush RXFIFO accordingly even though I'm not sure if it > is for this purpose. > > Thanks, > > -Sha > > > -------------------------------------------------- > From: "David Moss" <[EMAIL PROTECTED]> > Sent: Friday, March 14, 2008 5:26 PM > To: "'Liusand'" <[EMAIL PROTECTED]>; > <tinyos-help@millennium.berkeley.edu> > Subject: RE: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS > 2.0.2? > >> The TX FIFO is preloaded with data. The data is not being transmitted to >> the CC2420 as the transmission is taking place, unlike other chips. >> Because >> of the preload, it is impossible for the CC2420 to produce a TXFIFO >> UNDERFLOW. All the data to send is available on the chip when transmit >> occurs. >> >> Due to the rules of the CSMA and Transmit modules, a new packet cannot be >> uploaded to the TX FIFO until the previous packet in the TX FIFO was >> transmitted. This should guarantee that the TX FIFO be empty when the >> next >> transmit occurs. If a cancel occurs, a quick SFLUSHTX empties the >> contents >> of the TX FIFO. >> >> -David >> >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] >> [mailto:[EMAIL PROTECTED] On Behalf Of Liusand >> Sent: Friday, March 14, 2008 12:45 PM >> To: tinyos-help@millennium.berkeley.edu >> Subject: [Tinyos-help] TXFIFO underflow not taken care of in TinyOS >> 2.0.2? >> >> Hi, >> >> When I was studying CC2420TransmitP.nc, I noticed that TXFIFO is never >> flushed and underflow status is never checked. In CC2420RadioM.nc from >> TinyOS 1.1.15, TXFIFO is flushed in startSend() every time before it is >> written data to. >> >> It might be too conservative in TinyOS 1.1.15, but why overflow is never >> taken care of in TinyOS 2.0.2? >> >> Another related question is, in which situations TXFIFO underflow may >> happen? >> >> Thanks, >> >> Sha >> >> _______________________________________________ >> 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
