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
> >
> >
> >
>
