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

[Thomas Schmid]

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)