I didn't mean that you should use the PPS signal from a consumer GPS rx
(though you might do that). I was thinking that you'd instead track the
difference between TCXO-maintained time and GPS time over long periods -
weeks or months - and use those to adjust the TCXO.
This would only work if the TCXO was constantly maintaining a clock, which
I'd thought would be the case. If it's in a USB stick that might not be
true and so it wouldn't work as you wouldn't get the long baseline
measurement needed to compare with GPS time.
PCs are a bit of a problem. They may well have the sound chip on USB and
they also have a considerable amount of latency due to buffering in the DAC
and filtering. They're also, somewhat surprisingly, a pain in the neck for
application writing. They might have plenty of development tools, but
you'll find you have to constantly modify it to meet the current operating
system specs, produce Mac, Linux and Windows variants, multiple languages,
etc etc. Unless you're in that business and can get some of that effort
back through sales, it's a mess.
On Fri, Apr 13, 2018 at 3:30 AM, Wayne Holder <wayne.hol...@gmail.com>
> First, thanks for all the comments and suggestions, It's given me a lot to
> think about and research.
> Based on the feedback I've received, I've started to investigate using the
> server approach suggested by Chris Caudle. I also found this NIST Paper
> <https://tf.nist.gov/service/pdf/calibrations.pdf> to be very useful, as
> gave me some insight into the measurement period needed to achieve a given
> accuracy in the DUT given a certain level of deviation in the reference
> used. But, I think further reading will be required before I can reduce
> this approach to a plan. I anyone knows of additional info on using NTP to
> calibrate precision oscillators, I'd appreciate hearing about it.
> The basic unit of measurement for Longitudinal Timecode is the video frame
> rate, or approximately 30 fps, depending on the video medium in use.
> Current commercial Timecode Generators make claims like having a drift
> of only 1 frame over 24 hours, so that's been my target for my design.
> on my math, I think a drift of only 1/30th of a second in 24 hours is
> perhaps +/-0.5 PPP, or so, but someone please correct me if I'm wrong.
> Another solution used with older, less accurate timecode generators is to
> periodically resync (or "Jam Sync") the different timecode generators to
> the master timecode generator thoughout the day but, while I'm not a video
> production expert, I think think this is a less desirable solution.
> Using a GPS, as suggestion by Adrian Godwin, is also an option, as the PPS
> signal could be used as a calibration reference. Cheap, consumer GPS
> modules have gotten quite cheap and, based on my own experience
> using various uBlox modules, some can even function fairly well indoors
> under some conditions. However, I seem to recall some discussion here some
> time back about the relative reliability of the PPS signal in some
> situations. I'll have to dig back though the archives and see if I can
> learn anything from those threads.
> To provide some additional details on my project for those that
> are interested, the current plan is to build everything into a USB Stick
> form factor. The USB connection would be used to configure internal
> options (frame rate, etc.), charge the internal Li-Poly battery and
> also, potentially, perform the calibration. The time code signal would
> be output from a 3.5mm phone connector, so the suggestion to connect this
> to the audio input of the computer doing the calibration also makes sense,
> as this would take USB latency out of the picture (assuming that the sound
> interface in the PC is not just implemented via a chip on the USB bus.)
> time-nuts mailing list -- email@example.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> and follow the instructions there.
time-nuts mailing list -- firstname.lastname@example.org
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.