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

[Philip Levis]

On Jun 28, 2009, at 11:39 AM, Omprakash Gnawali wrote:

> On Sat, Jun 27, 2009 at 12:27 PM, Razvan Musaloiu-E.<razvanm at cs.jhu.edu 
> > wrote:
>> 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.
>
> Why not making it call-at-most-once type of configuration? That way if
> there are multiple calls from multiple Booted, we would catch that by
> looking at the error value, even when the radio is off.

Hunh -- the only way to do this would be to expose it as a generic  
with per-client IDs, and then throwing an error on all IDs except 0.  
This seems kind of weird. Another, simpler, approach is to simply say  
that you should only call this from a top-level application component.  
I.e., nothing in tos/ should call it.

Phil