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 -- [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.
