WebbotLib: clockGetus() wrap every 7.1 or 71 minutes?

[jackp]

Hi,

I think there's a bug in the documentation for WebbotLib in the timer.h section, specifically for clockGetus().  It states that the TICK_COUNT returned will wrap...

           "...every 0xffffffff or 429,4967,295 microseconds ie every 429.5 seconds or every 7 minutes."

But I think it's meant to state every 71 minutes right? 

BTW, this is important to me because wrapping every 71 min is ok for my timing sensitive application but 7 min may not be.

Thanks
Jack

[Cristi_Neagu]

Apparently...yeah....  0xffffffff is 71.58 minutes.... Interesting... I always took 7.1 minutes for granted

[madsci1016]

From what Webbot has told me before, even though the clock is wrapping around in the background, the effect is not seen in the user's code. IE, you don't have to worry about it; the lib fixes the time if it wraps.

[Webbot]

You can "always" subtract values from two calls to 'clockGetus'. The clock code has been written explicitly to allow this to work around the 'wrap around' end points ie when the clock goes from 0xffffffff back to 0x0000000.

ie you can use it, for ever, to detect a delay of say 1 minute  - your code wont suddenly break due to the clock itself wrapping around.

The only time it will fail is if you are trying to measure an elapsed period greater than the total clock period - ie between two times: time 1 and time 2 irrespective of when 'switch on' happened.

Version 1 of the lib had this set as 7 min but I think it is now 71 min (cant remember without re-checking the code!). So what kind of delay are you trying to measure that would be longer than this - and why?

[jackp]

Thanks for replies and the clarification.  Good point about the wrap and delays as long as it is < 7 (or 71 min). 

It's actually not measuring incremental delay that may be my issue.  I'm measuring total time elapsed and with 71 minutes, I may not need to worry about wrapping (my board may not be on for that long) but if 7 min I have to track the number of times it wraps to compute total time elapsed.

BTW, if I wanted to use WebbotLib to measure when the wrap occurs, do I just set up my callback via timerOverflowAttach( g_heartbeat, &myCB, pMyData )?

Thanks
Jack

[Webbot]

Well its every 0xFFFFFFFF uS ie 4294967295 us
= about 71 minutes
If you want to trap the wrap around then do something like

Code: [Select]


TICK_COUNT prev;

TICK_COUNT appInitSoftware(TICK_COUNT loopStart){
 prev = loopStart; // Store start value for the clock
 .. rest of your code ..

}

TICK_COUNT appControl(LOOP_COUNT loopCount, TICK_COUNT loopStart){
  if( loopStart < prev ){
     // The clock has wrapped around
     
 }
 prev = loopStart;
 .. rest of your code ..
}

NB You cannot do it via a timer overflow as per question.
Coz the timer actually overflows a lot more frequently and this is used to update the clock.
So the clock is like a 'super prescaled' version of your crystal frequency.

[madsci1016]

Really though, if you want time keeping in the magnitude of tens of minutes to hours, isn't a RTC add-on a better option?

[jackp]

Webbot: Makes sense. Timer's only 16-bits max so loop wrap code at every appControl call is better way to detect wrapping.

Madsci1016: Real Time Clock may be overkill but I'll take a look.

Thanks
Jack

[Admin]

isn't a RTC add-on a better option?

Is there a chip for this?

[madsci1016]

isn't a RTC add-on a better option?

Is there a chip for this?

Sparkfun sells one, I will link it when I get to my computer. I think its i2c and can run for decades without external power.

[Webbot]

http://www.sparkfun.com/commerce/product_info.php?products_id=99

[madsci1016]

Thanks for posting the link.

Is this a hint that there will be a webbotlib driver fo it? ;-)

[Webbot]

Thanks for posting the link.

Is this a hint that there will be a webbotlib driver fo it? ;-)

 
Since its standard I2C stuff then it should be programmable in WebbotLib already.

To save me $20 it would be good for someone who buys one to write the first attempt - I can then WebbotLib'ify it and add it to Project Designer for easier use.

[Admin]

Sooooo whats the advantage of an external RTC for a robot? (beyond the timers already on the Axon)

[madsci1016]

Well, your robot would always know the absolute time of day instead of just the relative time since it was turned on.

And like webbot was saying subtracting calls is fixed, but if you were just recording events or timing something larger then the 71 minute timer wrap then you would have to use a rtc.

[Webbot]

Good examples would be:
- if you are creating log info then you could time stamp with the correct year, month, day, minute, seconds
- if you are using SDcards in WebbotLib then I could place a proper date/time stamp on each file for last modified date
- an RTC provides a timer that NEVER wraps around back to zero and so could measure delays greater than, say, 71 minutes - even between reboots

[Admin]

Whats the error buildup rate of an RTC? I glanced through the datasheet, didn't see anything. Probably depends on the external crystal and thermal aspects of the environment . . .

Even with a 0.1% error rate, thats 10 minutes a week, or 8 hours/year . . .

I'd probably need a 0.01% accuracy to do things I have in my head . . . and thats 40 minutes per year error.

[chelmi]

Whats the error buildup rate of an RTC? I glanced through the datasheet, didn't see anything. Probably depends on the external crystal and thermal aspects of the environment . . .

Even with a 0.1% error rate, thats 10 minutes a week, or 8 hours/year . . .

I'd probably need a 0.01% accuracy to do things I have in my head . . . and thats 40 minutes per year error.

I have this on my nightstand. It uses the same chip as the SF module. I bought it 2 months ago and so far I did not miss any meeting. I don't know exactly the accuracy, but I used my PC to set it up and they are still "perfectly" synchronized. Definitely less than 0.1% accuracy anyway.

Chelmi.