Elapsed time reset after about 10 hours

I may be dreaming but in 2 ultras last year my Specialized Pro computer's elapsed time was showing
about 2 minutes somewhere right around 10 hours into the event. I suppose you could chalk it up to
"key bounce" but a friend had a similar experience with a Cateye. It is possible that the register
size in these chips is insufficient to represent more than 10 hours? Of course this screws up you
average speed too. Can any electronics savvy types out there set me straight or suggest a unit
without this problem?

Phil. Ann Arbor, MI

 

> It is possible that the register size in these chips is insufficient to represent more than 10
> hours? Can any electronics savvy types out there set me straight or suggest a unit without this
> problem?

Thinking out loud...

Consider the display around the 10 hour mark, say 09:59:59. A simple possibility is that the 0 in 09
is hardwired. That is, it's wired to display nothing but 0, so the counting is fixed to never go
beyond that. Terribly sloppy engineering if so! Or a bit of cost cutting.

Or, it may be an odd 15 bit register chip of which I'm not aware.

Or, it may be a 16 bit register to count seconds, with 1 bit reserved for something else, so 15 bits
for counting. 2^15=32768 seconds,
32768/60/60 = 9.1 hours. The reserved bit could possibly be used for the wheel spin status. That is,
1 if the wheel is turning, 0 if not.

Or, it may be a 32 bit register with 15 bits for counting and the other 17 required for the other
functions.

Or, it may have a counter for each unit (hrs/mins/secs), 3 counters in total. The 09 needs 4 bits.
But 4 bits allows up to 15 to be displayed. So no reason to be stuck at 09, unless again sloppy
engineering or cost cutting. The mins and secs in a case like this would each need 6 bits. Notice
4+6+6=16, so 3 separate counters would fit in a 16 bit register.

Or, with 3 counters again, the hours use 3 bits, which allows up to 8 hours. Are you sure it doesn't
roll over after 07:59:59?

There are other ways to represent the count, but nothing leaps out at me as an obvious limitation.
Any other engineers out there with ideas?

Doug