Could you use the "pips" instead of a PPS signal, again comparing them some weeks apart to give a long reference time ?
https://en.wikipedia.org/wiki/Greenwich_Time_Signal If your local radio broadcaster doesn't play something like them, they could probably be generated with a web application. On Sat, Apr 14, 2018 at 12:13 AM, Wayne Holder <[email protected]> wrote: > Again, thanks for all the great feedback and suggestions. > > > Are you familiar with these devices which I just found this week? > > https://tentaclesync.com/products > > Yes, that's one of the lower cost commercial units available. Another is > the NanoLockiIt by Ambient > <https://www.bhphotovideo.com/c/product/1333498-REG/ambient_ > recording_acn_nl_nanolockit_miniature_timecode_synchronizer.html>, > which is company that's been making timecode products for many years. > Compared to more traditional prices for timecode generators, these are > relatively inexpensive at about $300. However you need at least two, or > more generators to be useful, so that adds up pretty fast for an amateur > videographer, or starving film school student. In contrast, BOM for the > design I'm working on is less than $30 (the TCVCXO being, by far, the > most expensive part.) > > My plan is to also write a desktop application, probably in Java to make it > portable, that the person building the devices could use to perform the > initial calibration and also setup various options. So, the NTP-based > solution is attractive in that it doesn't require any additional hardware. > I'm a Mac user so, after a bit of reading the NTP implementation on the > Mac, I tried a few experiments. Typing "ntpq -p" in the terminal > app produced this response: > > remote refid st t when poll reach delay offset > jitter > > ============================================================ > ================== > > *usdal2-ntp-001. .GPSs. 1 u 428 1024 377 51.131 1.944 > 1.153 > > and typing "ntpq -c rl" printed out: > > associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, > > version="ntpd [email protected] Fri Feb 5 17:38:17 UTC 2016 (124.60.2~39)", > > processor="x86_64", system="Darwin/16.7.0", leap=00, stratum=2, > > precision=-20, rootdelay=51.131, rootdisp=34.160, refid=17.253.2.125, > > reftime=de7ba9c1.937e5f86 Fri, Apr 13 2018 15:12:17.576, > > clock=de7badf7.39f8d36a Fri, Apr 13 2018 15:30:15.226, peer=7077, tc=10, > > mintc=3, offset=1.944153, frequency=25.163, sys_jitter=0.000000, > > clk_jitter=0.745, clk_wander=0.001 > > I believe that the "precision" of -20 value on the 4th line is supposed to > be interpreted as 2^-20 seconds which, if my math is correct, works out to > be a precision of about 1 PPM. Is that correct? If so, it would seem like > I should be able to use my system's internal clock to perform a "tweak" in > around 10,000 seconds, or a little less than 3 hours. Does this seem > correct, or have I missed something? > > Alternately, if I included a GPS receiver in the design, the whole process > could be done within the device, which would probably be the easiest > approach to calibration for the person building one. This would increase > the cost and make the device larger, but users could then maintain > calibration by periodically keeping them plugged in for a few hours. Or, > perhaps I could just design a 2nd board for a GPS "calibrator" module that > could be plugged into the timecode generators to calibrate them. Hmm... > lots to think about. > > Wayne > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
