Boomerang keeps a shallow queue of timestamps to avoid exactly this problem.
-Joe On 9/28/06, Brano Kusy <[EMAIL PROTECTED]> wrote:
guys, cory is right - the problem is not related to reading TimerB. there is one more problem with our timesync (both telos/micaz) that relates to a timestamping bug in the CC2420 implementation. arriving radio messages are timestamped from an SFD interrupt (provided as RadioReceiveCoordinator.startSymbol() by CC2420RadioM.nc). however, CC2420 is so fast, that a new SFD interrupt can come before the previous message has been handled and its timestamp has been stored in the message data structure. if you look at your bogus timestamps, you'll see that the timing error is not random, but the incorrect times are always larger than expected. this would be hard to explain as a timer bug. this problem can be solved by buffering SFD interrupts in the radio driver. it has been supposedly implemented in tinyos-2.x and boomerang but i haven't checked it out. certainly vanderbilt timestamping implementation is buggy under high message or CPU load. brano Cory Sharp wrote: > Harish, > > I really think the chance of reading timer errors from TimerB is > infintesimal. Not zero, so I wouldn't guarantee it, but not occuring so > much as to be anything more than a very very rare occurence. If you're > still getting errors, I recommend you assure yourself the errors are not > coming from somewhere else, such as maybe RAM or radio corruption. > > I wouldn't recommend using Timer A as it can be used with special ADC > modes. > > Cory > > On 9/26/06, harish prabhu <[EMAIL PROTECTED]> wrote: >> >> Hi Cory, >> I was continuing my experiment and I do observe that there are bogus >> timestamps despite the fix and as you mention, they are less frequent >> than >> before. >> >> I understand that the problem arises because of trying to read the >> timer >> (based on >> an async clock source) when it is running. >> TimerM component ultimately uses Timer B of the MSP430. >> >> Is it possible to use Timer A and provide a new >> LocalTime.readexclusively >> for the purpose of FTSP ? Is Timer A used in any important component ? >> ( I notice that it is used by LocalTimeMicroC/some ADC component - can >> this be done away with if I do not use it in my application ?) >> >> If I can use Timer A exclusively, will the following steps work ? : >> 1. Start timer A in continuous mode using TimerA.setMode(). >> 2. Set the mode to halted using TimerA.setMode() >> 3. Read the TAR register using TimerA.read() >> 4. Restart timer A in continuous mode using TimerA.setMode() >> >> Thanks and Regards, >> Harish >> >> >> >> On 9/26/06, Cory Sharp <[EMAIL PROTECTED]> wrote: >> > >> > I would be very hesitant to say anything is an absolute guarantee. >> > Brano from Vanderbilt identified a note in the MSP430 User's Guide >> regarding >> > potentially corrupt readings of a timer based on a asynchronous clock >> > source. This seemed like the likely source of errors in corrupt time >> > values. The user's guide indicated the workaround is to take a >> majority >> > vote of the timer readings to determine a valid reading. With that >> fix and >> > without a deeper analysis of the issue, it seems like there is still an >> > infinitesimal chance getting of a corrupt reading, though a corrupt >> reading >> > is at least significantly less likely than before. Asserting anything >> > stronger than that would require a longer study which I have not >> performed. >> > >> > Cory >> > >> > On 9/25/06, harish prabhu < [EMAIL PROTECTED]> wrote: >> > >> > > Hi Cory, >> > > >> > > This is with reference to the volcano monitoring paper of Matt >> Welsh >> > > and his team (mentioned below). >> > > In this paper, two problems have been mentioned with regards to >> > > FTSP. >> > > 1) The problem with the clock driver (apparently seen only on >> > > Tmotes) that seems >> > > to return bogus timestamps. >> > > 2) FTSP does not check validity of time sync messages. >> > > >> > > The first seems to have been fixed in the change to TimerM.nc in >> > > /tos/platform/msp430 >> > > done in February 2006. >> > > Does this guarantee that there will be no bogus timestamps anymore ? >> > > >> > > Given the fact that this fix has been done, can we assume that the >> > > time filtering/time >> > > rectification approach mentioned in the paper is not required >> anymore >> > > ? >> > > >> > > Regards, >> > > Harish >> > > >> > > >> > > On 9/20/06, Omprakash Gnawali <[EMAIL PROTECTED] > wrote: >> > > > > >> > > > > >> > > > > Matt Welsh and his group has an OSDI paper: >> > > > > Fidelity and Yield in a Volcano Monitoring Sensor Network >> > > > > >> http://www.eecs.harvard.edu/~mdw/papers/volcano-osdi06.pdf<http://www.eecs.harvard.edu/%7Emdw/papers/volcano-osdi06.pdf> >> >> > > > > >> > > > > in which they report similar error. You might want to read that >> > > > > paper >> > > > > if you are trying to use FTSP on Tmotes because the paper talks >> > > > > about >> > > > > different techniques they used to get FTSP to work well. >> > > > > >> > > > > - om_p >> > > > > >> > > > > >> > > > > > Hi All, >> > > > > > Has anyone tried FTSP on Tmotes ? >> > > > > > If yes, what was the accuracy obtained ? Is it of the >> order of >> > > > > > micro-seconds ? >> > > > > > I was trying it but I cannot see better than millisecond >> > > > > accuracy. >> > > > > > Regards, >> > > > > > Harish >> > > > > >> > > > >> > > > >> > > >> > > _______________________________________________ >> > > Tinyos-help mailing list >> > > [email protected] >> > > >> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >> > > >> > > >> > > >> > >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________ Tinyos-help mailing list [email protected] https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
