Yes you could. If you are listening to them by ear, something in the ~100 ms
is probably a good guess in terms of precision. There are also propagation
that may come in with a broadcast system.
If you are still after 0.1 ppm, that gets you out to a million seconds per
attempt. Roughly two weeks between attempts is about where that would put you.
At that sort of time period you *would* get a lot of local temperature profile
into the result. I’d say that’s a good thing.
One very basic question on all of this: If the TCXO is the expensive part of
and GPS modules are (relatively) cheap …. why use the TCXO at all? Simply run a
crystal as the reference. Do a drop / add to keep things running right. When
has lock, you have perfect time sync, When it drops out, you go to the crystal
If microsecond level accuracy *is* what the goal is, the TCXO, even when it’s
is not a really good way to do that ...
> On Apr 13, 2018, at 9:02 PM, Adrian Godwin <artgod...@gmail.com> wrote:
> Could you use the "pips" instead of a PPS signal, again comparing them some
> weeks apart to give a long reference time ?
> 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.hol...@gmail.com>
>> 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 firstname.lastname@example.org 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=18.104.22.168,
>> 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 -- 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.
time-nuts mailing list -- email@example.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.