[time-nuts] TCVCXO Adjustment

[Adrian Godwin]

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 <wayne.holder at gmail.com>
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 4.2.8p6 at 1.3265 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 -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>