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

[Thomas Schmid]

Hi Miklos,

This was my first attempt at an LPL application using tinyos 2.x. And
honestly, I got very confused about it. I don't understand why each
and every component has to wire to the low power listening interface
anyway. FTSP is a good example. It should work if the radio uses LPL
or not. But in the current implementation, FTSP has to set the
LPL_INTERVAL every time it sends a message. Shouldn't the LPL layer
take care of this?

For example, if LPL is enabled, every message should by default get
the LPL_INTERVAL set as the RxSleepInterval. Is there any purpose on
why this isn't that way? Or is it already like that, but I just didn't
find the right line in the code?

Thanks,

Thomas

On Wed, Jun 17, 2009 at 3:19 PM, Miklos Maroti<mmaroti at math.u-szeged.hu> wrote:
> Dear Thomas,
>
> Thanks for sharing your patch with us. I will look at that part of it
> which is CC2420 independent.
>
> I have seen that you are using the LowPowerListening interface at a
> few places, and you have wired it only for the CC2420. Certainly your
> changes could work for the RF230 radio, and it would make sense to do
> it platform independently. I think it is high time for providing the
> LowPowerListening interface in ActiveMessageC when the hardware
> supports it. I have seen way to many IFDEFS about the
> LowPowerListening interface.
>
> Miklos
>
> On Wed, Jun 17, 2009 at 6:09 PM, Thomas Schmid<thomas.schmid at ucla.edu> wrote:
>> Hey all,
>>
>> I have two patches vs. the current CVS tree. They fix several problems
>> that I discovered in handling time stamping and FTSP. I will try to explain
>> most of the changes in this email.
>>
>> http://projects.nesl.ucla.edu/~thomas/ftsp_patch_apps
>> this contains two applications to test the implementation
>>
>> http://projects.nesl.ucla.edu/~thomas/ftsp_patch_tos
>> this contains modifications to the 'tos' directory
>>
>> to apply the patches, use "patch -p1 < patchfile" in the TOSROOT directory.
>>
>> - I added a configuration to allow 32kHz time sync called
>> TimeSync32kC. It uses the same underlying TimeSyncP, and thus is just
>> some changes in wiring.
>>
>> - I added a eventTime field to the cc2420 metadata structure. This is
>> necessary for LPL mode, since else the event time would get
>> decremented every time a message gets sent out. we separately have to
>> store this value in the metadata and can't reuse the eventtime field at
>> the end of the data section (current implementation)
>>
>> - I removed the reset of the timesync field in the CC2420CsmaP
>> component. This reset broke FTSP for LPL mode!
>>
>> - In order to improve accuracy, I changed the Msp430TimerCapComP
>> default capture configuration to non synchronous capture mode. The
>> synchronous mode introduces a disambiguity of +/-1 tic. In addition,
>> it can introduce a HUGE delay for treating the SFD (up to 1/32768
>> second). changing this to async introduces a concurrency issue...
>> which has to be noted! However, chances of hitting this problem are very
>> small, and FTSP would most likely detect the problem. A better
>> implementation would be that the CC2420 driver doesn't assume the
>> default configuration for the CaptureSFD is good, and sets this field itself!!!!
>>
>> - I added LPL capabilities to FTSP. Now, to test the LPL mode, you
>> can't use the regular RadioCountToLed application anymore, since a
>> simple broadcast message gets sent out continuously for the amount
>> of the LPL INTERVAL time. Thus, the we don't know which one of the
>> messages the receiving nodes received. To fix this, I wrote a simple
>> TestFtsp32kLplBeaconer application (copy of RadioCountToLed with some
>> modifications). Instead of the normal AMSend interface, it uses the
>> TimeSyncAMSend interface and sets a event time. Now, if the receiving
>> nodes receive the message, they calculate the event time and thus
>> everyone actually translates the same event time into global time. It
>> doesn't matter anymore which one of the bcast messages the receiver
>> got, since the event time gets updated in each and every one of them
>> by the CC2420 driver.
>>
>> Guess that is it. If someone could apply these patches to CVS, that
>> would be great. In my small tests, I saw accuracies at about the
>> jiffies level :)
>>
>> Cheers,
>>
>> Thomas
>>
>>
>>
>> --
>> "Don't complain; Just work harder" - Randy Pausch
>>
>> Thomas Schmid, Ph.D. Candidate
>> Networked & Embedded Systems Laboratory (NESL)
>> University of California, Los Angeles (UCLA)
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
>



-- 
"Don't complain; Just work harder" - Randy Pausch

Thomas Schmid, Ph.D. Candidate
Networked & Embedded Systems Laboratory (NESL)
University of California, Los Angeles (UCLA)