[time-nuts] webcam app to watch for and time stamp changes
jimlux at earthlink.net
Sat Mar 2 18:50:01 EST 2013
On 3/2/13 2:52 PM, Tom Van Baak wrote:
> 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:
> More recently I used the same webcam to capture AC mains wall clock
> time vs. a cesium clock:
> Now, it may seem very old-fashion and crude to use a web cam to
> capture data.
I've used that scheme more than once.. as well as similar approaches of
spinning wheels or counters driving LEDs to measure camera shutter timing.
> But, if I understand correctly, in your case, you are more interested
> using the external LCD display as a *proxy* for the internal crystal
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
> 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).
That's what I was thinking.. the segments are pretty small, though, so
some optics and fixturing would need to be fabricated. The idea of
"point webcam at RSA fob and run software" was pretty appealing.
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.
I can't think of a good reason why they would decouple the segment mux
from the underlying clock (unless there's some built in RC oscillator in
the chip doing the mux, separate from the timekeeping).
Actually, there's probably some information around on the internal
design of the fob.. After all, the security is in the algorithm, not the
> 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
> 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.
Even better, there's a little segment that blinks on and off every
second, as well as a stack of 6 that go away, one every 10 seconds, and
then, finally, the 6 digits. If I rig up an optical system, the 1 pps
segment is the logical one to look at.
Time to look for some suitable optics.
More information about the time-nuts