[time-nuts] webcam app to watch for and time stamp changes

Tom Van Baak tvb at LeapSecond.com
Sat Mar 2 22:52:32 UTC 2013


Hi  Jim,

I had a similar challenge a while ago. I ended up capturing a 4-digit, 7-segment display with a USB/LAN webcam, converting the JPG to BMP, analyzing pixel gradients, matching the image with heuristic masks, and appending an ascii log file with the 4 decimal digit result once a minute. It worked amazingly well. I can send you the C source code (contact me off-line). See also these legacy links:
    http://leapsecond.com/webcam/
    http://tycho.usno.navy.mil/ptti/ptti2003/paper35.pdf

More recently I used the same webcam to capture AC mains wall clock time vs. a cesium clock:
    http://leapsecond.com/pages/tec/mains-clock-ani.gif

Now, it may seem very old-fashion and crude to use a web cam to capture data. But the reality is that not all devices expose their internal state via convenient analog test points, or through digital I2C, RS232, GPIB, USB, or LAN protocols. So the last resort is simply a web cam on a visual (LED or LCD) display.

But, if I understand correctly, in your case, you are more interested using the external LCD display as a *proxy* for the internal crystal oscillator. Thus you are not concerned with the actual numeric value that the LCD segments are displaying; you are simply interested in measuring the time at which the LCD digits and segments change -- because that corresponds to the phase/frequency of the internal oscillator.

Measuring clock drift and tempco would be very easy and would produce interesting results. The higher the rate of web cam capture the finer the resolution of your TIC detection. Note that multiplexed displays are not a problem; in fact, if you're clever it can actually improve your resolution by observing the segment transition times. That is, instead of *polling* the display, you use *changes* in the display as your timing trigger. Edge detection. You move from a world of periodic/gated frequency counters to a world of a reciprocal period counters, or even time-stamping counters.

In other words, since you are interested in the underlying clock performance rather than the RSA algorithm itself, just focus a few photo-transistor(s) on the LCD segment(s). The transition from light/dark/light/dark will exactly correspond to some internal crystal clock phase/frequency, from which you can gather precise long-term phase, frequency, and stability information. Edges are always better than polling.

The idea is that segment *transition* instants rather than periodic observation of segment *state* provides much greater accuracy. What you want to do is measure the time of transition of individual segments. I would use time-stamping rather than polling or time interval or frequency measurement. That is, use a CNT-91, or picPET (www.leapsecond.com/pic).

If you look at a 7-segment digit encoding table (http://en.wikipedia.org/wiki/Seven-segment_display) you can see that focusing on segment 'e' gives you 8 transitions out of every 10, and using two opto-detectors on segments 'a' and 'e' will allow you to generate a timing event for every change in LCD digit. This will be several orders of magnitude more precise than using a web cam. You don't need photo-transistors on all segments.

/tvb

----- Original Message ----- 
From: "Jim Lux" <jimlux at earthlink.net>
To: <time-nuts at febo.com>
Sent: Saturday, March 02, 2013 12:57 PM
Subject: Re: [time-nuts] webcam app to watch for and time stamp changes


> On 3/2/13 12:30 PM, lists at lazygranch.com wrote:
>> My fob only outputs a code on demand, that is after I push the button.
>>
>> Any of the motion detection programs that use webcams would detect the change in display, but with a multiplexed  display, I'm not sure how well.
> 
> Interesting point.. mine only has the 6 digit (7-segment) display, but 
> I'm sure it's multiplexed (digit/segment)..
> 
> But, the mux rate is fairly high, compared to the "transition time" for 
> the segments.  So maybe I can average over some (short) time...
> 
> What I want to do is see what the temperature dependence is.  (prompted 
> by leaving the fob in the sun, and having the code rejected, presumably 
> because it was "slightly ahead")





More information about the Time-nuts_lists.febo.com mailing list