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

[Omprakash Gnawali]

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.

- om_p