[Tinyos-devel] 2.0.2 CC2420
J. Ryan Stinnett
jryans at rice.edu
Wed Jul 4 13:25:59 PDT 2007
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.
>
> Another way around this case is to do what the BaseStationCC2420 does, which
> is override a module from the CC2420 stack with a version that does what you
> want. I've made it fairly easy to do: there's an FCF_LENGTH parameter in
> CC2420ReceiveP which is currently set to 2 (because the FCF is 2 bytes). By
> setting it to 7, Receive will make sure the packet's length is at least 7
> bytes, read those 7 bytes and SACK, then continue reading the rest of the
> packet. Because we're reading in 7 bytes from the header before SACK'ing
> instead of 2, the destination address will be available and we can check it.
> (attached, this file isn't tested).
I'm not sure I understand how reading these 7 bytes works around the
issue of reading extra bytes in the paragraph above this one. I can see
how having to download the entire packet before SACK would degrade
performance, however if it can be done by getting only a few more bytes
to check the address, I think that's great and should be available *as
an option* but not be the default, since as you say it is not optimal.
- Ryan
>
> If other users agree that this really isn't an edge case and we should see
> this software address check version as the default, then by all means it
> should be in there. However, SACK's do not perform as well as hardware
> ack's, and it's been my focus to get them optimized as much as possible.
>
> -David
>
>
>
>
>
> -----Original Message-----
> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
> Sent: Wednesday, July 04, 2007 11:20 AM
> To: David Moss
> Cc: tinyos-devel at millennium.berkeley.edu
> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
>
>> .... If you want the base
>> station to disable address recognition to sniff all packets, and also send
>> out SACK's when it receives a packet with its address, that's another
> issue.
>> -David
>>
>
> I think this could be useful. In addition, adding address check should
> not affect the two applications you mentioned: base station and sniffer.
> Any thoughts?
>
> Thanks
>
> Mike
>
>> -----Original Message-----
>> From: J. Ryan Stinnett [mailto:jryans at rice.edu]
>> Sent: Tuesday, July 03, 2007 10:45 PM
>> To: David Moss
>> Cc: 'Chieh-Jan (Mike) Liang'; tinyos-devel at millennium.berkeley.edu
>> Subject: Re: RE: [Tinyos-devel] 2.0.2 CC2420
>>
>> Does this have any effect on snooping with CC2420? Just to confirm, the
>> address recognition feature needs to be disabled as in BaseStationCC2420
>> before snooping will work, is that correct?
>>
>> Thanks,
>> Ryan
>>
>> David Moss wrote:
>>> Yup - there's a good reason for this. The destination address is checked
>>> automatically by hardware while receiving the packet transmission. So by
>>> the time the uC gets the signal that a new packet has arrived, the packet
>>> has already gone through the address/pan check. Therefore, we don't need
>> a
>>> second address check in software before issuing a SACK.
>>>
>>> -David
>>>
>>>
>>> -----Original Message-----
>>> From: David Moss [mailto:dmm at rincon.com]
>>> Sent: Tuesday, July 03, 2007 9:45 PM
>>> To: 'Chieh-Jan (Mike) Liang'
>>> Cc: 'tinyos-devel at Millennium.Berkeley.EDU'
>>> Subject: RE: [Tinyos-devel] 2.0.2 CC2420
>>>
>>> Yup - there's a good reason for this. The destination address is checked
>>> automatically by hardware while receiving the packet transmission. So by
>>> the time the uC gets the signal that a new packet has arrived, the packet
>>> has already gone through the address/pan check. Therefore, we don't need
>> a
>>> second address check in software before issuing a SACK.
>>>
>>> -David
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Chieh-Jan (Mike) Liang [mailto:cliang4 at cs.jhu.edu]
>>> Sent: Tuesday, July 03, 2007 7:41 PM
>>> To: David Moss
>>> Cc: tinyos-devel at Millennium.Berkeley.EDU
>>> Subject: Re: [Tinyos-devel] 2.0.2 CC2420
>>>
>>> Something about SACK in the new CC2420 stack is not clear to me. In the
>>> old implementation, before SACK is strobed, the mote ID is compared with
>>> the packet destination address. However, this check is not performed any
>>> more. Is there any reason behind this?
>>>
>>> Thank you
>>>
>>> Mike
>>>
>>> David Moss wrote:
>>>> Just updated the CC2420 stack in preparation for 2.0.2. The file
>>>> architecture has been re-arranged a little bit, making it easier to see
>>>> how the stack is put together. As a result, the .platform files that
>>>> reference the cc2420 were updated.
>>>>
>>>>
>>>>
>>>> Test results are included. Let me know if you have any issues.
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Recent Updates (from the readme):
>>>>
>>>> * New chip SPI bus arbitration working with Receive and Transmit.
>>>>
>>>>
>>>>
>>>> * Applied TUnit automated unit testing to CC2420 development
>>>>
>>>> > Caught lots of bugs, especially through regression testing
>>>>
>>>> > Source code in tinyos-2.x-contribs/tunit/
>>>>
>>>>
>>>>
>>>> * Applied TEP115 behavior to CC2420 SplitControl in Csma and Lpl
>>>>
>>>>
>>>>
>>>> * Updated ActiveMessageAddressC to provide the ActiveMessageAddress
>>>> interface
>>>>
>>>> > Updated CC2420ConfigP to handle
>>>> ActiveMessageAddress.addressChanged() and
>>>>
>>>> sync automatically upon address change events.
>>>>
>>>>
>>>>
>>>> * Updated CC2420Config interface to enable/disable sw/hw
> acknowledgements
>>>>
>>>>
>>>> * Updated CC2420ConfigP to share register editing through single
>> functions
>>>>
>>>>
>>>> * Acknowledge after packet length and FCF check out valid.
>>>>
>>>> > The destination address is confirmed in hardware, so we don't need
>>>>
>>>> to download the entire header before acking.
>>>>
>>>>
>>>>
>>>> * Moved the getHeader() and getMetadata() commands to an internal
>>> interface
>>>> called CC2420PacketBody, provided by CC2420PacketC
>>>>
>>>>
>>>>
>>>> * Separated core functionality into different sub-packages/directories
>>>>
>>>> > Updated micaz, telosb, intelmote2 .platform files
>>>>
>>>> > Logically organizes code
>>>>
>>>>
>>>>
>>>> * Updated some LPL architecture
>>>>
>>>> > Removed continuous modulation because it didn't work 100% and I
>>>> don't have
>>>>
>>>> time to make it work.
>>>>
>>>> > Decreased backoffs and decreased on-time for detects, saving energy.
>>>>
>>>>
>>>>
>>>> * Updated to the new AMPacket interface; made the radio set the outbound
>>>>
>>>> packet's destpan after send().
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Tinyos-devel mailing list
>>>> Tinyos-devel at Millennium.Berkeley.EDU
>>>>
>> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>>
More information about the Tinyos-devel
mailing list