Handling Timer Rollover

[jgcode]

Howdy

I am interrogating a serial device and want to record its time-source to determine a period of time.

During this, the Timer may rollover.

The manual states that the Timer will rollover ~218 seconds (helpful I know ).

So the problem is, without knowing exactly when the rollover occurs, I don't know how to accurately calculate the dt at that rollover.

As, even though the Sample Rate is set in the EEPROM, the dt (calculated from the Timer) returned can vary slightly between samples e.g. normally 0.01s dt, but can be 0.02s up to 0.05s.

Here is some actual data from when the rollover occurs:

I am finding it hard not to introduce errors into the timestamp by guessing/asumming the dt at the rollover!

Has anyone dealt with this before / got an ideas?

Cheers

-JG

[Yair]

Run it many times (overnight), see what's the maximum value you get and then use that as the max value. It won't be accurate, but it will be approximate.

[crelf]

So the problem is, without knowing exactly when the rollover occurs, I don't know how to accurately calculate the dt at that rollover.

That's *exactly* what your problem is - if you don't know when the rollover is, then you don't know when the rollover is I'd try to talk to the vendor to find out the exact rollover value. Yair's right - you can approximate it (and the more times you run it, the closer ou'll get), but if you can find out the exact value then you're golden.

[ShaunR]

There's probably a better mathematical solution, but this works as a practical approximation for this sort of thing (certainly for repeatability at least).

As Yair said. Take loads of readings. Then calculate the mean and variance of your data.

Plug those value into the probably density function for a truncated normal distribution and solve of X (note that b in this case is infinity).

It is flawed in that it assumes your data is normally distributed (which it isn't its 1/2 of a normal distribution). But it will give a much better approximation.

Edited November 18, 2010 by ShaunR

[Francois Normandin]

Do you have a crystal oscillator on this EEPROM?

If so, then the company cannot provide a more accurate answer than ~218 seconds because each embedded crystal will be slightly different. The specs must say something like "Oscillating frequency = x kHz ± 5 ppm".

If you can calculate accurately the actual frequency of your crystal, then you can calculate what is the roll-over for this particular EEPROM based on the number of bits of resolution.

[Christian_L]

I would assume the time returned is based on some counter and the time rollover is based on the rollover of the counter. The time returned is the count value times dt (dt = 1/counter frequency).

Determine the smallest increment in the time value returned, which should be your dt. Looks like it will be 0.0006427 or a fraction thereof.

Do the math to determine the size of the counter , i.e. 218.45 /dt . Most likely the counter range will be a power of 2.

Do the exact math to determine the actual maximum value.

Assuming your device has a 32-bit counter... >> For example if your device uses a 19.6608 MHz clock source and a 32 bit counter, your dt will be 5.08626e-8 and your maximum time will be 218.4533, all within the error of the clock source of course. 19.6608 MHz was the closet common timing chip/crystal I could find based on your values and the assumption of a 32-bit counter.

If you can open up the serial device you may be able to easily identify the clock source and lookup its frequency. Be aware of voiding any warranty.

[jdunham]

Assuming your device has a 32-bit counter... >> For example if your device uses a 19.6608 MHz clock source and a 32 bit counter, your dt will be 5.08626e-8 and your maximum time will be 218.4533, all within the error of the clock source of course. 19.6608 MHz was the closet common timing chip/crystal I could find based on your values and the assumption of a 32-bit counter.

If you can open up the serial device you may be able to easily identify the clock source and lookup its frequency. Be aware of voiding any warranty.

Lest we forget the obvious, you _have_ already rung up the company's technical department and asked them, right?

[jgcode]

Cheers everyone.

Lest we forget the obvious, you _have_ already rung up the company's technical department and asked them, right?

Well, no - I prefer to query the minds of the geniuses here on LAVA first, or at least in parallel

19.6608 MHz was the closet common timing chip/crystal I could find based on your values and the assumption of a 32-bit counter.

Wow - you're good.

I have now got more info and that is correct!