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

[Miklos Maroti]

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
>