[Tinyos-devel] 2.0.2 CC2420

[Philip Levis]

On Jul 4, 2007, at 11:48 AM, David Moss wrote:

> I would be very hesitant to allow the baseline CC2420ReceiveP to  
> perform its
> former software address check to support this edge case because
> acknowledgement performance may suffer as a whole, which we've  
> already seen
> and quantified to some degree.
>
> There are a few timing issues going on with acks in the background  
> to take
> into consideration:  After the Tx mote sends its packet, the SPI  
> bus must be
> acquired by the Rx mote.  This resource acquiring may add  
> significant delay
> depending on what else is going on with the SPI bus (flash, other task
> handling).  By the time the Rx mote acquires its SPI resource and  
> is able to
> download the packet, the Tx mote's ack wait period is winding  
> down.  The Rx
> mote must SACK as fast as possible to ensure the ack is received by  
> the Tx
> mote within the ack wait window.  The fastest way to SACK is to  
> download the
> first byte (length) and the second byte (fcf) to see if A) we have  
> a valid
> packet and B) if the packet requested an ack.  If we wanted to test  
> for the
> address, we'd have to download several more bytes before being able  
> to see
> the destination address.  True, it's only a few more bytes, but it's
> certainly not optimized.

David,

The way Jung Il did this was to start an alarm after the SFD  
interrupt. This alarm would fire after the first few bytes of the  
packet. When this alarm fired, his stack would read the header and if  
the destination matched, SACK it. Basically, this takes advantage of  
the latency of receiving the payload to try to improve the ACK  
response time. Of course, if something like the flash has acquired  
the SPI, there's not much you can do. But basically this approach  
issues the SACK as soon as the header is received, such that the  
actual SPI reading latency is not particularly important.

Phil