[time-nuts] TCVCXO Adjustment
kb8tq at n1k.org
Fri Apr 13 20:21:36 EDT 2018
With NTP (or any other timing system) you really need 3 or more sources to sort
things out. If you only have one source, eventually everything will converge on it.
That’s not to say that it will be correct, you simply will be 100% locked to it.
GPS modules are a “sub $20” sort of thing these days. You aren’t after super duper
precision. Simply drop one on your board and run it all the time ….
The alternative is to plug a USB GPS into the mac and do a bit of code to compare
things. If you want to pass the gizmo around to your friends …. that can be done. Pretty
good ones are “sub $10” delivered.
> On Apr 13, 2018, at 7:13 PM, 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?
> Yes, that's one of the lower cost commercial units available. Another is
> the NanoLockiIt by Ambient
> 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
> *usdal2-ntp-001. .GPSs. 1 u 428 1024 377 51.131 1.944
> 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=184.108.40.206,
> 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.
> 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.
More information about the time-nuts