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

[Vlado Handziski]

The default in Msp430TimerCapComP should definitely remain in sync mode. If
timer clients want to override this, they are free to use the
MSPTimerControl.setControlAsCapture(). Until proper arbitration for the
timers is implemented, you will have to make sure to configure it back to
the defaults after use, on StdControl.stop, etc.

Vlado


On Wed, Jun 17, 2009 at 18:09, 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<http://projects.nesl.ucla.edu/%7Ethomas/ftsp_patch_apps>
> this contains two applications to test the implementation
>
> http://projects.nesl.ucla.edu/~thomas/ftsp_patch_tos<http://projects.nesl.ucla.edu/%7Ethomas/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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090618/3ed415b4/attachment.htm