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 NTP 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 it 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. Based 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.) Wayne _______________________________________________ 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.