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

[Branislav Kusy]

Guys,

sorry it took so long, but I was gone for a month.

The patches looked fine for the most part. I modified them somewhat, 
tested that everything works for TMilli, T32khz with LPL on/off on 
telosb. Thomas, please take a look and let me know if I butchered something.

To summarize:

Thomas Schmid 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
i reorganized the tests/TestFtsp directory to contained all ftsp tests. 
note that T32k timesync will only work on certain platforms. i'm not 
sure if this is ok, but i let it slide for now. if people think 
otherwise, i can revert TestFtsp/FtspLpl to use TMilli timesync.

> 
> 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)
as per miklos's comments later in this thread, more elegant solution is 
to restore the event time after it is sent by the radio. i tested it 
with telosb(with LPL) and it works ok.

i believe i kept the remaining parts of the patch unmodified:
> - 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 :)
the same for me. however, when i stress-tested just timestamping, i 
still saw the problem of mis-timestamped packets due to misaligned (SFD, 
packet) pairs. both on the receiver and transmitter side. it happens 
infrequently and FTSP should take care of it.

cheers,
brano