Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? -- George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB Mail: g...@inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. pgp1RtN0wFJRp.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? It is not the resolution of the time tag that matters, but the accuracy at which it can be received by an asynchronous serial port. You will probably require fudge configuration to calibrate it to an existing known-good source to get within 1ms of true time. With PPS it should be easy to get within 10us without calibration. I don't know what your requirements are, so it is difficult to judge if what you have now is good enough. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On Tue, Jan 20, 2015 at 6:51 AM, George Ross g...@inf.ed.ac.uk wrote: From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? No. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
It is not the resolution of the time tag that matters, but the accuracy at which it can be received by an asynchronous serial port. Ah, no, the timeousness of reading the timestamp isn't relevant, provided only that the driver doesn't hammer on the clock unit too hard (which it doesn't; once a second would be absolutely fine, and polling is less frequent than that). All that matters is that the kernel can toggle the leading edge of the timestamp-request data line reliably enough, and that the driver's timestamps taken before and after the ioctl() don't have much jitter. We regularly see our unit's jitter around 0.001, and the offsets to other timeservers in the low numbers of microseconds. You will probably require fudge configuration to calibrate it to an existing known-good source to get within 1ms of true time. The only fudge we should really apply is to the clock unit itself to account for the cable length. But we don't need to be accurate to the nanosecond, so we haven't bothered. The default value, which I don't have easily to hand, was good enough. I don't know what your requirements are, so it is difficult to judge if what you have now is good enough. It's way more than good enough for us, out of the box. The original poster to this thread will have to decide for their own situation. -- George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB Mail: g...@inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. pgpPSzNn_UlMQ.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On 2015-01-20, George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? ??? The question is not what the resolution of the time tag is. The question is how accurately you can get that time into your computer. Certainly sending over say a serial line (each bit of which takes 100 of microseconds, with fluctuations) making it impossible to get any kind of accuracy into the computer. The PPS triggers an interrupt which can be handled in the microsecond range of times. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
William Unruh un...@invalid.ca wrote: On 2015-01-20, George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? ??? The question is not what the resolution of the time tag is. The question is how accurately you can get that time into your computer. It turns out that the device has a mode where you can SEND a pulse at a moment you decide and then the device RETURNS the timestamp of that pulse you sent in a serial message. Presumably you can take a nanosecond timestamp and change the output line as closest together as possible, then read the returned timestamp and compare the two. That is equivalent in precision to receiving a PPS pulse, maybe even better. (because you don't have interrupt latency issues, the only issue is how close the pulse moment can be to the reading of the system time) The Datum we use has that option too, but I never tried it. Maybe soon. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On 2015-01-20, Rob nom...@example.com wrote: William Unruh un...@invalid.ca wrote: On 2015-01-20, George Ross g...@inf.ed.ac.uk wrote: --===2288611982837908707== Content-Type: multipart/signed; boundary===_Exmh_1421754685_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421754685_7720P Content-Type: text/plain; charset=us-ascii ... Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. From the Acutime 2000 user guide: The time tag provides a resolution of 320ns Is PPS going to be sufficiently better that it would outweigh the additional setup complexity? ??? The question is not what the resolution of the time tag is. The question is how accurately you can get that time into your computer. It turns out that the device has a mode where you can SEND a pulse at a moment you decide and then the device RETURNS the timestamp of that pulse you sent in a serial message. Presumably you can take a nanosecond timestamp and change the output line as closest together as possible, then read the returned timestamp and compare the two. That is equivalent in precision to receiving a PPS pulse, maybe even better. (because you don't have interrupt latency issues, the only issue is how close the pulse moment can be to the reading of the system time) OK, that would certainly be a different situation. You could presumably read the clock and toggle the pin to sub microsecond precision. You would presumeably want a daemon to read the clock and toggle the pin, perhaps with interrupts turned off for the microsecond required so that they could not get between the two. Not sure how long a pulse it requires. The Datum we use has that option too, but I never tried it. Maybe soon. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===6692172896629376392== Content-Type: multipart/signed; boundary===_Exmh_1421765608_7720P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421765608_7720P Content-Type: text/plain; charset=us-ascii It is not the resolution of the time tag that matters, but the accuracy at which it can be received by an asynchronous serial port. Ah, no, the timeousness of reading the timestamp isn't relevant, provided only that the driver doesn't hammer on the clock unit too hard (which it doesn't; once a second would be absolutely fine, and polling is less frequent than that). All that matters is that the kernel can toggle the leading edge of the timestamp-request data line reliably enough, and that the driver's timestamps taken before and after the ioctl() don't have much jitter. We regularly see our unit's jitter around 0.001, and the offsets to other timeservers in the low numbers of microseconds. Ah, you send a line toggle to the unit to be timestamped and the result to be sent back. That can be very accurate, yes. I know this option is present in some Datum GPSDO units that I use. My experience with other Trimble models that use the TSIP protocol is that one requests a time packet and the result reflects the current time and is valid at some defined point in the message (e.g. the leading edge of the start bit, I remember the exact detail). In such a protocol it is difficult to get it entirely right without tweaking with fixed offsets. (because there is some delay between the start bit edge and the moment the UART issues an interrupt) In itself, PPS interfacing is not that difficult. Usually it is sufficient to connect the PPS output BNC directly to the DCD input of the serial port. The kernel can then lock directly to the PPS, and the serial messages are only used for date/time and status information. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
William Unruh wrote: On 2015-01-20, Rob nom...@example.com wrote: It turns out that the device has a mode where you can SEND a pulse at a moment you decide and then the device RETURNS the timestamp of that pulse you sent in a serial message. Presumably you can take a nanosecond timestamp and change the output line as closest together as possible, then read the returned timestamp and compare the two. That is equivalent in precision to receiving a PPS pulse, maybe even better. (because you don't have interrupt latency issues, the only issue is how close the pulse moment can be to the reading of the system time) OK, that would certainly be a different situation. You could presumably read the clock and toggle the pin to sub microsecond precision. You would presumeably want a daemon to read the clock and toggle the pin, perhaps with interrupts turned off for the microsecond required so that they could not get between the two. Not sure how long a pulse it requires. No need for that! The easy fix is to simply read the local time twice, before and after toggling the bit: If those two readings are too far apart (i.e. more than a few us) then something happened, like a time slice running out or an interrupt handler taking over the current core, in which case you simply discard the current reading. You could also mark it with the timestamp distance so that it would be weighted less than a good sample. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On Tue, Jan 20, 2015 at 1:45 PM, William Unruh un...@invalid.ca wrote: You would presumeably want a daemon to read the clock and toggle the pin, perhaps with interrupts turned off That would be NTPd refclock 29 mode N where N select an event stamping receiver. Naturally doing this in user space increases latency. Someone should look and see if this is better than PPS. Not sure how long a pulse it requires. At least one microsecond for the Acutime 2000 and probably similar for the other devices. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
Shouldn't it show a 'o' rather than a '*' when it is locked to PPS in kernel mode? Ah, but it's not doing PPS. The driver waggles one of the control lines and the device transmits a timestamp in response. -- George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB Mail: g...@inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. pgpSAEv0PxGwp.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===2115662771273679884== Content-Type: multipart/signed; boundary===_Exmh_1421661606_7734P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421661606_7734P Content-Type: text/plain; charset=us-ascii Shouldn't it show a 'o' rather than a '*' when it is locked to PPS in kernel mode? Ah, but it's not doing PPS. The driver waggles one of the control lines and the device transmits a timestamp in response. Ok... the Trimble Thunderbolt outputs PPS as well, so I thought one would use that. It will be much more accurate, but you probably don't require that. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On Mon, Jan 19, 2015 at 2:57 AM, George Ross g...@inf.ed.ac.uk wrote: Is there anyone with the prior experience in getting these older Trimble units to work? We've had a Trimble Acutime 2000 running since 2005, at two separate sites. Although the Palisades driver has been extended to the Praecis, Thunderbolt and Acutime the document at http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver29.html is silent on what is now best practice for Trimble timing receivers. Presumably PPS was ignored because the event based timing packets yield reliable sub-millisecond offsets. The driver and document should be brought into the PPS era and be renamed the TSIP refclock rather than Palisades. Palisades/NMEA + ATOM is the way to use these receivers. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
George Ross g...@inf.ed.ac.uk wrote: --===8412338610136231777== Content-Type: multipart/signed; boundary===_Exmh_1421654265_8133P; micalg=pgp-sha1; protocol=application/pgp-signature Content-Transfer-Encoding: 7bit --==_Exmh_1421654265_8133P Content-Type: text/plain; charset=us-ascii Is there anyone with the prior experience in getting these older Trimble units to work? We've had a Trimble Acutime 2000 running since 2005, at two separate sites. As I recall we just plugged it in, ran the (Windows) configuration tool that came on the CD with it to check that it had a lock and that it was running in time sync mode, then connected up a Linux box, configured in the driver, and off it went. remote refid st t when poll reach delay offset jitter == *GPS_PALISADE(0) .GPS.0 l6 32 3770.0000.012 0.001 Shouldn't it show a 'o' rather than a '*' when it is locked to PPS in kernel mode? ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
Is there anyone with the prior experience in getting these older Trimble units to work? We've had a Trimble Acutime 2000 running since 2005, at two separate sites. As I recall we just plugged it in, ran the (Windows) configuration tool that came on the CD with it to check that it had a lock and that it was running in time sync mode, then connected up a Linux box, configured in the driver, and off it went. remote refid st t when poll reach delay offset jitter == *GPS_PALISADE(0) .GPS.0 l6 32 3770.0000.012 0.001 -- George D M Ross MSc PhD CEng MBCS CITP, University of Edinburgh, School of Informatics, 10 Crichton Street, Edinburgh, Scotland, EH8 9AB Mail: g...@inf.ed.ac.uk Voice: 0131 650 5147 Fax: 0131 650 6899 PGP: 1024D/AD758CC5 B91E D430 1E0D 5883 EF6A 426C B676 5C2B AD75 8CC5 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. pgpnhnAapSvRn.pgp Description: PGP signature ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
Oceanos Admin sysad...@cellmail.com wrote: Is there anyone with the prior experience in getting these older Trimble units to work? Most of the information dates back to the early 2000's or so. Our desire is to get away from using an external Internet based public NTP site to limit possible security issues. I think it will work with gpsd. At least try to experiment with that, as it provides much more debugging info and you can see what is working and what is not. Once you have a bit more experience with accessing the unit you can always decide if you want to stick with gpsd (in combination with ntpd) or again try to configure ntpd to directly access the Trimble. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Linux NTPd using a older Trimble Thunderbolt GPS Receiver
On Fri, Jan 16, 2015 at 7:49 PM, Oceanos Admin sysad...@cellmail.com wrote: Hi: We were looking to use an older Trimble Thunderbolt 8 channel GPS receiver for providing a Stratum 1 time reference The standard hobbyist T-Bolt management program is Lady Heather. It a windows (dos) program that will run under Wine. You can use it to completely manage a T-Bolt. It will also correctly initialize one. The Palisades driver has a bug that prevents correct set-up if you've managed to get it misconfigured. http://www.ke5fx.com/heather/readme.htm. While message timing variability is much better than your typical GPS you should use the PPS output via the ATOM/PPS refclock. You'll probably get some advice to switch to simpler, more modern GPS rather than an aging GPSDO. They are a reasonable alternative if only for reduced power consumption but given a standard serial port a T-Bolt is plug and play. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
