[Tinyos-devel] 2.0.2 CC2420

Wed Jul 4 13:21:10 PDT 2007

David Moss wrote:
> There are two settings for acknowledgements in CC2420ControlP:
> enable/disable auto acknowledgements, and make hardware or software
> acknowledgements the default.  These can be configured, as they were before,
> with preprocessor #defines, and now can also be configured through a
> software interface (CC2420Config) at runtime.  CC2420_NO_ACKNOWLEDGEMENTS
> disables ack's completely, which is what the base station has set in its
> Makefile.  So, the base station will continue to sniff packets because its
> address recognition and auto acknowledgements are disabled.
>  
> Since the software address check would have only affected the SACK being
> issued, it should have no effect on the base station.  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.

This sounds like a useful feature to me, not for the base station 
necessarily, but for general motes.  I'm currently working on a routing 
protocol which can make use of data from overheard packets, but I don't 
want to give up the acknowledgment functionality in order to also snoop 
packets.  For my current application, this would be the optimal setup, 
so I wouldn't call it an edge case at all.

> 
> There is another case people have had issues with where they want the base
> station to be address X and acknowledge packets.  In my opinion, we should
> have two apps here:  BaseStationCC2420 (change it's functionality to enable
> address recognition and acks), and Sniffer (which accepts all packets and
> doesn't ack).  Would it make sense to create another app directory to
> separate these two distinct pieces of functionality?  Any
> thoughts/suggestions?

I'd agree that both of those cases have their uses, so giving each its 
own directory could be useful.  However, it seems to me that it would 
simpler from the user's standpoint to make address recognition 
configurable just as acks currently are (whether via #defines or an 
interface) so that a separate CC2420ControlP isn't needed.

- Ryan

> 
> Thanks for bringing up the BaseStation, I forgot to update its
> CC2420ControlP file which I'll do right now.
> 
> -David
> 
> 
> 
> 
> -----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
>>
>>
> 
> 
> 
> 