On 3/2/13 12:30 PM, lists@lazygranch.com wrote:

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")

I had one for work a while back and asked the IT security guys about it and was
told that the change was on a fixed schedule but of course each fob was a little
different due to temperature, over time, etc and that the system automatically
"learned" the fobs and opened or tightened its tolerance for when the fobs
updated.  So if you had a slow one the system would adapt over time and just
learn to expect that but if the timing got too far off they would replace the
fob.  I suppose if you kept messing with the timing by leaving in the sun or
freezer eventually you would get rejected logins and your IT people would want
to replace it, unless they manually really loosened up the timing windows.  The
people I asked didn't mind my inquiries and seemed eager to chat but some places
might be a bit more paranoid.

On 3/2/2013 3:57 PM, Jim Lux wrote:

On 3/2/13 1:10 PM, Peter Gottlieb wrote:

The explanation in RSA's manuals is more like..

You set a tolerance window.. how many codes before/after are you willing
to accept.  When it accepts your code, it resynchronizes it's master
timer (for your fob) to whatever you just entered.    It doesn't go so
far as to try and adjust the "rate", just the "offset".

If you think about it, there would have to be some time correction if only because these fobs can't be all that accurate in maintaining time. That is, they would be no better than a watch.

I'm not so keen on wearing out the internal battery since these things are now $30 instead of $5 when paypal introduced them.
-----Original Message-----
From: Jim Lux jimlux@earthlink.net
Sender: time-nuts-bounces@febo.com
Date: Sat, 02 Mar 2013 13:18:36
To: time-nuts@febo.com
Reply-To: Discussion of precise time and frequency measurement
time-nuts@febo.com
Subject: Re: [time-nuts] webcam app to watch for and time stamp changes

On 3/2/13 1:10 PM, Peter Gottlieb wrote:

The explanation in RSA's manuals is more like..

You set a tolerance window.. how many codes before/after are you willing
to accept.  When it accepts your code, it resynchronizes it's master
timer (for your fob) to whatever you just entered.    It doesn't go so
far as to try and adjust the "rate", just the "offset".

time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

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@earthlink.net
To: time-nuts@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 1:29 PM, lists@lazygranch.com wrote:

mine is on all the time..

http://en.wikipedia.org/wiki/File:SecureID_token_new.JPG

I presume the battery will die in some number of years <10

On 3/2/13 2:52 PM, Tom Van Baak wrote:

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.

exactly

Thus you are not concerned with the actual numeric value

yes

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

Yes indeed..

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
hardware.

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.

Perhaps you can detect EMI from the device especially if you put it it a
shielded metal box with pickup antenna.  You might be able to get the clock
right from that.

On 3/2/2013 6:50 PM, Jim Lux wrote: