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.read exclusively
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.
CoryOn 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,
HarishOn 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
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
