[time-nuts] Low-long-term-drift clock for board level integration?

[Brooke Clarke]

Hi Bill:

When the TRANSIT navigation satellites were put in orbit the receivers required Cesium clocks.  The system worked but 
was very expensive.
The GPS system was designed so that cheap clocks could be used in the receiver.  This requires getting a lock on 4 
satellites instead of the 3 that would be required for a 3D position fix.  The forth satellite allows determining the 
the receivers clock offset and rate.

You may be able to do a similar thing in your receivers.  For example if the master node were to send a timing message 
at known times (say once at the top of  every hour) the receivers could use that to determine their local clock offset 
and rate for those cases where the path was the same (or maybe even for a list of paths).  The offset and rate numbers 
can be used to correct the measured time to actual time without changing the clock's rate using simple math.  You can 
trade the receiver clock stability for the time between the timing messages.

Have Fun,

Brooke Clarke
http://www.PRC68.com
http://www.end2partygovernment.com/Brooke4Congress.html


Bill Woodcock wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Hi. This is my first posting to this list, and I'm not a timekeeping engineer, so my apologies in advance for my ignorance in this area.
>
> I'm building a small device to do one-way delay measurements through network.  Once I'm done with prototyping, I'm planning a production run of several hundred of the devices. They'll have a GPS receiver, probably a Trimble Resolution SMT, and they have a bit of battery so they can initially go outdoors for ~30 minutes to get a good fix, but then they get taken indoors and plugged into the network, and probably never get a clear view of a GPS or GLONASS satellite again.
>
> - From that point forward (and we hope the devices will have an operational life of at least ten years) they'll be dependent on their internal clock and NTP, but we really need them to stay synchronized to within 100 microseconds. 10 microseconds would be ideal, but 100 would be acceptable. And in order to be useful, they need to stay synchronized at that level of precision essentially forever.
>
> My plan, such as it is, was just to get the best clock I could find within budget, integrate it onto the motherboard we're laying out as the system clock, and depend on NTPd to do the right thing with it.
>
> Anyone have any thoughts or advice on clocks I could use that would be, say, under USD 300 in quantity 500, and would be optimized for minimal long-term drift?  Power-use is not particularly constrained.  It needs to be integrated onto our board, but space isn't too constrained either.
>
> I'm also happy to pay for a few consulting hours if people want to give me detailed advice on a professional basis.
>
> Thanks,
>
>                 -Bill
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJPQYw8AAoJEG+kcEsoi3+HfuUP/3+VVQs+dyRL4ToEoCaAI0eQ
> 8TMEV1PD7r775P/rSA0M1wWzFsTxAegixUbBHmQDvgc2ouaEiN0ZJvQrbNwBxR8M
> +b7QIuxB4h84JYyvw+Add6l8HjWWWttDW52YiUEdNmv228Q+XO7z/CMBrZ79c9bB
> VeZ5CEJl3zLcEDthpBKxgtEKtHFqURUCQ0b3uqWC4dTYld3yTJ9NB7/mt5bLDlEF
> IoA02IKurWBgkmNf92FU2SeC458mPejw2EiYaQ/acSv8mK23q56XJoo0O1ogNhAk
> qajdSBj/z9hlLTKgRH5jBorwNeRwr0TN8AoyPjBBqIRAI14Q1QHbLJu5twhy5C92
> oE78LzedFa93GBPg8+6mdxYgevG4Pm8v8qeB6CdlDBJVD8s91QF0m52Gce+l2H9V
> PUGO7ACWjhVdi7VIWSOeSYGlIlqsLV4C7UYLYS+4zy0+dnrgeLFeYf9A29i6Krhr
> BCrtPvE6XrC0JUr3oZ0gDzh/T9JPr0XFmWkA0w9JmOAK7D+YWfa7jTBS+vbSXemo
> 5XBpjK2Ioo9JBwKmUF1Gd8dOO7fSm7cclxfRYwmjjzvSGG+vXCihWhaLzJdwJz6Z
> PYf60+hk23Mhrfk4V2qjTi1hVg9FJtxxNA3oC0MRuuwU45tXGIFcUqpSw3F+FS6f
> IuLyIrTqwVzdakZL997f
> =PpgK
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> 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.
>
>