[Tinyos-devel] Patches to FTSP and CC2420 for 32kHz sync and LPL functionality

[Razvan Musaloiu-E.]

Hi!

On Sat, 27 Jun 2009, Omprakash Gnawali wrote:

> On Sat, Jun 27, 2009 at 10:41 AM, Philip Levis<pal at cs.stanford.edu> wrote:
>>
>> On Jun 26, 2009, at 6:35 PM, Razvan Musaloiu-E. wrote:
>>
>>> I update the default-lpl-new branch to use a
>>> SystemLowPowerListeningC instead of DefaultLplSettingsC. The new
>>> interface is like this:
>>>
>>> interface SystemLowPowerListening
>>> {
>>> 	command void setLocalSleepInterval(uint16_t interval);
>>> 	command void setRxSleepInterval(uint16_t interval);
>>> 	command void setDelayAfterReceive(uint16_t interval);
>>>
>>> 	command uint16_t getRxSleepInterval();
>>> 	command uint16_t getDelayAfterReceive();
>>> }
>>>
>>> The setX calls are used by the user application while the getX are
>>> used by LplAMSenderP and DefaulLplP. One drawback of this is the
>>> fact that it doesn't prevent the user from calling the setX at the
>>> wrong time. :|
>>
>> This looks good -- I think my one comment would be to change
>> RxSleepInterval to DefaultDestinationSleepInterval. That seems clearer
>> to me.
>>
>> I agree on the issues with the set calls. One solution here is that
>> you have an error_t return value, with can return FAIL if done at the
>> wrong time (e.g., radio is on).
>
> This might preclude something like NoSE which sets different sleep
> intervals at different times. Here is a link:
> http://www.tik.ee.ethz.ch/~beutel/pub/MWWBT2009.pdf
>

An application can still use the normal LowPowerListening interface to 
tweek the settings for each packet. So NoSE should still be able to do 
its job.

My initial idea of a default lpl was to make it very easy for an 
application to be compiled either in lpl or non-lpl mode. My initial 
proposal was exactly that. This SystemLowPowerListening we end up with is 
more complicated and more open to interpretation and misuse.

--
Razvan ME