Re: [ntp:questions] Fw: NTP and Trimble TSIP
On 2016-02-16 19:28, Paul wrote: On Tue, Feb 16, 2016 at 7:40 PM, Brian Inglis mailto:brian.ing...@systematicsw.ab.ca>> wrote: This module specs don't mention frequency output other than 1PPS which is specced within 60ns, so much better than almost all. If it also supports TRAIM and sawtooth correction, the driver can improve on that. I was referring to his current Copernicus II, which also seems to support Static 2-D position hold mode, TRAIM, and runs from a 16.384MHz+/-5kHz TCXO +/-60ns, so pretty decent for the money. See http://www.trimble.com/timing/ICM-SMT-360.aspx. This is $50 quant. 1 Resolution SMT with a $2 TCXO (the 10MHz is presented on pin 23). It's GPSDO but it's not a T-bolt E. 24 hour hold-over 100x10^-9 vs 1x10^-12 . Looked at that, pretty nice, but holdover is only specced up to 300s, +/-7us for 60s, so +/-117ppb: YMMV depending on antenna quality, location, and sky view, LNA and cable length matching to receiver optimum, and cable delay compensation accuracy. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Fw: NTP and Trimble TSIP
On Tue, Feb 16, 2016 at 7:40 PM, Brian Inglis < brian.ing...@systematicsw.ab.ca> wrote: > > This module specs don't mention frequency output other than 1PPS which is > specced within 60ns, so much better than almost all. If it also supports > TRAIM and sawtooth correction, the driver can improve on that. See http://www.trimble.com/timing/ICM-SMT-360.aspx. This is $50 quant. 1 Resolution SMT with a $2 TCXO (the 10MHz is presented on pin 23). It's GPSDO but it's not a T-bolt E. 24 hour hold-over 100x10^-9 vs 1x10^-12 . ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Fw: NTP and Trimble TSIP
On 2016-02-16 08:57, Paul wrote: On Tue, Feb 16, 2016 at 7:48 AM, Neil Green wrote: Hi, yes, timepps.h is in my source tree. I can make the Copernicus II output NMEA all day long but I'm considering buying one of these: You should use driver 29 (GPS_PALISADE) except two years on and there's been no interest in supporting newer Trimble devices (Resolution etc.). I can send you a patch (which also fixes the smal bug in the Thunderbolt code) that I'd expect to work with the ICM if you like. Note that the consensus is that 10Mhz from from a GPS module is pretty bad. Regular GPS modules using DDS to generate 10Mhz may be bad, but other Trimble products are used as secondary references, and their Thunderbolts are designed as GPSDOs with drifts below 10^-12: check out time-nuts list posts about them. Only H maser, Rb, Cs primary references by HP/Agilent/Keysight have better reps. This module specs don't mention frequency output other than 1PPS which is specced within 60ns, so much better than almost all. If it also supports TRAIM and sawtooth correction, the driver can improve on that. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP and Trimble TSIP
On 16 Feb 2016, at 3:57 pm, Paul wrote: > You should use driver 29 (GPS_PALISADE) except two years on and there's been > no interest in supporting newer Trimble devices (Resolution etc.). I can > send you a patch (which also fixes the smal bug in the Thunderbolt code) that > I'd expect to work with the ICM if you like. > > Note that the consensus is that 10Mhz from from a GPS module is pretty bad. I didn’t know that about 10MHz. There are similar versions half the price without that feature, so I’ll now consider one of those. The patch would be gratefully received, thank you. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Fw: NTP and Trimble TSIP
On Tue, Feb 16, 2016 at 7:48 AM, Neil Green wrote: > Hi, yes, timepps.h is in my source tree. I can make the Copernicus II > output NMEA all day long but I'm considering buying one of these: You should use driver 29 (GPS_PALISADE) except two years on and there's been no interest in supporting newer Trimble devices (Resolution etc.). I can send you a patch (which also fixes the smal bug in the Thunderbolt code) that I'd expect to work with the ICM if you like. Note that the consensus is that 10Mhz from from a GPS module is pretty bad. -- Paul ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] How to measure the quality of NTP server
Hey, Before synching to a server, I would like to define some criteria for a good NTP source. If I query ntp server: ntpq> associations ind assid status conf reach auth condition last_event cnt === 1 36430 961a yes yes none sys.peersys_peer 1 ntpq> rv associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, version="ntpd 4.2.6p5@1.2349-o Mon Jan 25 14:08:27 UTC 2016 (1)", processor="x86_64", system="Linux/2.6.32-431.el6.x86_64", leap=00, stratum=3, precision=-24, rootdelay=183.660, rootdisp=63.268, refid=109.226.40.40, reftime=da6da105.8ad1ef23 Tue, Feb 16 2016 15:22:13.542, clock=da6da4db.d53c285b Tue, Feb 16 2016 15:38:35.832, peer=36430, tc=10, mintc=3, offset=0.584, frequency=-17.995, sys_jitter=0.000, clk_jitter=0.472, clk_wander=0.106 ntpq> * What should be decent values for : precision, rootdelay, rootdisp, frequency, sys_jitter, clk_jitter, clk_wander? I don't want to start syncing with in accurate source (and I have limitations to sync only to one server, which usually as I understand is less recomanded) I am trying to find some benchmarks for a good quality ntp server. * The association rv=0, is it reflect the system clock? (I am a bit confused...) I know that other associations if exist reflect the state to a specific refid Appreciate any help, 10x, Natalie ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP and Trimble TSIP
Hi, yes, timepps.h is in my source tree. I can make the Copernicus II output NMEA all day long but I'm considering buying one of these: http://www.dpieshop.com/trimble-icm-smt-360-gpsgnss-timing-receiver-with-10mhz-clock-carrier-p-1640.html Which like the Copernicus II will output TSIP and NMEA, but recommends TSIP for full timing diagnostic information. Before buying, I wanted to see if using TSIP with NTP was feasible. Besides which, because it's there. From: Joachim Fabini Sent: 16 February 2016 12:22 To: Neil Green; questions@lists.ntp.org Subject: Re: [ntp:questions] NTP and Trimble TSIP Is there any specific reason for insisting on TSIP? I have some Copernicus II receivers operating accurately using NMEA over a serial interface at 4800 8N1 on a Linux Desktop. You can change the Copernicus II output with little effort using Trimble's GPS Studio (Windows PC required). One typical pitfall is the missing timepps.h - did you copy it to your source tree before configuring/compiling ntp? Joachim On 16.02.2016 12:56, Neil Green wrote: > I'm trying, and failing, to get ntp to talk to a Trimble Copernicus II > receiver outputting TSIP at 38400 over GPIO on a Raspberry Pi. NTP was > compiled with: > > --- > > ./configure --enable-TRIMTSIP --enable-SHM --disable-ipv6 --enable-linuxcaps > --enable-GPSD --enable-NMEA --enable-ATOM > > --- > > > My ntp.conf: > > --- > > driftfile /var/lib/ntp/ntp.drift > > logfile /var/log/ntp.log > > leapfile /home/pi/leap-seconds.3661632000 > > > enable calibrate > > disable bclient > > tos mindist 0.0002 > > > server 80.5.182.144 iburst > > server 89.16.173.64 iburst > > server 143.210.16.201 iburst > > server 217.114.59.3 iburst > > server 158.43.128.66 iburst > > server 129.215.42.240 iburst > > > server 127.127.8.0 mode 138 minpoll 4 maxpoll 4 iburst prefer > > fudge 127.127.8.0 refid TSIP flag2 0 flag3 1 > > > restrict -4 default kod notrap nomodify nopeer noquery > > > restrict 127.0.0.1 > > --- > > > And NTP sees the TSIP output: > > --- > > associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, > > version="ntpd 4.3.91@1.2483-o Mon Feb 15 23:41:44 UTC 2016 (3)", > > processor="armv7l", system="Linux/4.1.17-v7+", leap=00, stratum=3, > > precision=-19, rootdelay=22.680, rootdisp=21.143, refid=80.5.182.144, > > reftime=da6d88a4.d07d578a Tue, Feb 16 2016 11:38:12.814, > > clock=da6d89d1.39d90431 Tue, Feb 16 2016 11:43:13.225, peer=6872, tc=6, > > mintc=3, offset=0.154387, frequency=-7.677, sys_jitter=0.722466, > > clk_jitter=1.027, clk_wander=0.008, tai=36, leapsec=20150701, > > expire=20161228 > > remote refid st t when poll reach delay offset jitter > > == > > *80.5.182.14410.178.5.138 2 u 34 64 177 16.308 -1.325 2.405 > > 89.16.173.64.STEP. 16 u- 6400.0000.000 0.000 > > 143.210.16.201 .STEP. 16 u- 6400.0000.000 0.000 > > 217.114.59.3.STEP. 16 u- 6400.0000.000 0.000 > > +158.43.128.66 193.67.79.2022 u 37 64 177 20.338 -0.721 1.413 > > 129.215.42.240 .STEP. 16 u- 6400.0000.000 0.000 > > 127.127.8.0 .TSIP. 0 l- 1600.0000.000 0.000 > > ntp_gettime() returns code 0 (OK) > > time da6d89d1.55f19d68 Tue, Feb 16 2016 11:43:13.335, (.335718994), > > maximum error 178483 us, estimated error 1026 us, TAI offset 36 > > ntp_adjtime() returns code 0 (OK) > > modes 0x0 (), > > offset 47.530 us, frequency -7.677 ppm, interval 4 s, > > maximum error 178483 us, estimated error 1026 us, > > status 0x2001 (PLL,NANO), > > time constant 6, precision 0.001 us, tolerance 500 ppm, > > pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, > > intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. > > associd=0 status=0015 1 event, clk_bad_date, > > device="Trimble GPS (TSIP) receiver", timecode="\x10\x82\x07\x10\x03", > > poll=28, noreply=0, badformat=0, baddata=1, fudgetime1=20.000, stratum=0, > > refid=TSIP, flags=4, > > refclock_ppstime="da6d89d1.00ea7be3 Tue, Feb 16 2016 11:43:13.003", > > refclock_time="", refclock_status="PPS; (PPS SIGNAL)", > > refclock_format="Trimble TSIP", > > refclock_states="*ILLEGAL DATE: 00:07:22 (100.00%); running time: 00:07:22", > > gps_position_ext(LLA)="lat 52.919398 N, lon 1.488431 W, alt 51.04m", > > trimble_receiver_health="doing position fixes, Battery backup failed", > > trimble_status="machine id 0
[ntp:questions] Fw: NTP and Trimble TSIP
Hi, yes, timepps.h is in my source tree. I can make the Copernicus II output NMEA all day long but I'm considering buying one of these: http://www.dpieshop.com/trimble-icm-smt-360-gpsgnss-timing-receiver-with-10mhz-clock-carrier-p-1640.html Which like the Copernicus II will output TSIP and NMEA, but recommends TSIP for full timing diagnostic information. Before buying, I wanted to see if using TSIP with NTP was feasible. Besides which, because it's there. From: Joachim Fabini Sent: 16 February 2016 12:22 To: Neil Green; questions@lists.ntp.org Subject: Re: [ntp:questions] NTP and Trimble TSIP Is there any specific reason for insisting on TSIP? I have some Copernicus II receivers operating accurately using NMEA over a serial interface at 4800 8N1 on a Linux Desktop. You can change the Copernicus II output with little effort using Trimble's GPS Studio (Windows PC required). One typical pitfall is the missing timepps.h - did you copy it to your source tree before configuring/compiling ntp? Joachim On 16.02.2016 12:56, Neil Green wrote: > I'm trying, and failing, to get ntp to talk to a Trimble Copernicus II > receiver outputting TSIP at 38400 over GPIO on a Raspberry Pi. NTP was > compiled with: > > --- > > ./configure --enable-TRIMTSIP --enable-SHM --disable-ipv6 --enable-linuxcaps > --enable-GPSD --enable-NMEA --enable-ATOM > > --- > > > My ntp.conf: > > --- > > driftfile /var/lib/ntp/ntp.drift > > logfile /var/log/ntp.log > > leapfile /home/pi/leap-seconds.3661632000 > > > enable calibrate > > disable bclient > > tos mindist 0.0002 > > > server 80.5.182.144 iburst > > server 89.16.173.64 iburst > > server 143.210.16.201 iburst > > server 217.114.59.3 iburst > > server 158.43.128.66 iburst > > server 129.215.42.240 iburst > > > server 127.127.8.0 mode 138 minpoll 4 maxpoll 4 iburst prefer > > fudge 127.127.8.0 refid TSIP flag2 0 flag3 1 > > > restrict -4 default kod notrap nomodify nopeer noquery > > > restrict 127.0.0.1 > > --- > > > And NTP sees the TSIP output: > > --- > > associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, > > version="ntpd 4.3.91@1.2483-o Mon Feb 15 23:41:44 UTC 2016 (3)", > > processor="armv7l", system="Linux/4.1.17-v7+", leap=00, stratum=3, > > precision=-19, rootdelay=22.680, rootdisp=21.143, refid=80.5.182.144, > > reftime=da6d88a4.d07d578a Tue, Feb 16 2016 11:38:12.814, > > clock=da6d89d1.39d90431 Tue, Feb 16 2016 11:43:13.225, peer=6872, tc=6, > > mintc=3, offset=0.154387, frequency=-7.677, sys_jitter=0.722466, > > clk_jitter=1.027, clk_wander=0.008, tai=36, leapsec=20150701, > > expire=20161228 > > remote refid st t when poll reach delay offset jitter > > == > > *80.5.182.14410.178.5.138 2 u 34 64 177 16.308 -1.325 2.405 > > 89.16.173.64.STEP. 16 u- 6400.0000.000 0.000 > > 143.210.16.201 .STEP. 16 u- 6400.0000.000 0.000 > > 217.114.59.3.STEP. 16 u- 6400.0000.000 0.000 > > +158.43.128.66 193.67.79.2022 u 37 64 177 20.338 -0.721 1.413 > > 129.215.42.240 .STEP. 16 u- 6400.0000.000 0.000 > > 127.127.8.0 .TSIP. 0 l- 1600.0000.000 0.000 > > ntp_gettime() returns code 0 (OK) > > time da6d89d1.55f19d68 Tue, Feb 16 2016 11:43:13.335, (.335718994), > > maximum error 178483 us, estimated error 1026 us, TAI offset 36 > > ntp_adjtime() returns code 0 (OK) > > modes 0x0 (), > > offset 47.530 us, frequency -7.677 ppm, interval 4 s, > > maximum error 178483 us, estimated error 1026 us, > > status 0x2001 (PLL,NANO), > > time constant 6, precision 0.001 us, tolerance 500 ppm, > > pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, > > intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. > > associd=0 status=0015 1 event, clk_bad_date, > > device="Trimble GPS (TSIP) receiver", timecode="\x10\x82\x07\x10\x03", > > poll=28, noreply=0, badformat=0, baddata=1, fudgetime1=20.000, stratum=0, > > refid=TSIP, flags=4, > > refclock_ppstime="da6d89d1.00ea7be3 Tue, Feb 16 2016 11:43:13.003", > > refclock_time="", refclock_status="PPS; (PPS SIGNAL)", > > refclock_format="Trimble TSIP", > > refclock_states="*ILLEGAL DATE: 00:07:22 (100.00%); running time: 00:07:22", > > gps_position_ext(LLA)="lat 52.919398 N, lon 1.488431 W, alt 51.04m", > > trimble_receiver_health="doing position fixes, Battery backup failed", > > trimble_status="machine id 0
Re: [ntp:questions] Align PPS to UTC or GPS?
On Wed, 10 Feb 2016, juergen perlinger wrote: On 02/10/2016 07:24 PM, Neil Green wrote: I'm configuring a Skytraq Venus GPS module and have the option to align the PPS output to GPS or UTC. Which one is best for use over serial with NTP? IMHO that's a funny configuration option, as the difference between UTC and GPS time scale is an integral number of seconds, by definition. So it should not matter for a true PPS, that is, 1 pulse per second. While it does not matter as far as ntp is concerned, the difference betweeen UTC and GPS consists in an integral number of seconds AND a handful of ns, which is computed after some parameters transmitted in the GPS navigation message ; so the option is not that funny for applications below the 1 us range since the icd-gps-200 states : " The OCS (control segment) shall control the GPS time scale to be " within one microsecond of UTC (Modulo one second). That being said, a quick look at the BIPM circular T will show that in practice the UTC-GPSTime offset has been almost continuously within the 10 ns range for at least the last 6 years : ftp://ftp2.bipm.org/pub/tai/publication/utcgnss/utc-gnss So really not a concern for ntp, but this is the rationale for the presence of this option. (The january 26th incident was a bug affecting the nav parameters that resulted in a 13 usec bogus estimation of this offset) This *might* be a difference if the 'PPS' is given every n-th second (say, every 5 or 10 seconds) and you want one pulse at second zero of the minute. Since NTPD syncs to UTC(*), I would suggest the UTC option, and don't be afraid to have the pulse every second, because it shouldn't make a difference anyway in that case. Unless I failed to grasp something?!? (*) The truth is more complicated, but for all practical purposes it's easiest to assume NTPD works with UTC. Cheers, Pearly ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions -- François MeyerTel : (+33) 3 81 66 69 27 Mob : 6 27 28 56 83 Observatoire de Besancon - BP1615 - 25010 Besancon cedex - FRANCE Institut UTINAM * Universite de Franche-Comte * CNRS UMR 6213 *** ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] NTP and Trimble TSIP
Is there any specific reason for insisting on TSIP? I have some Copernicus II receivers operating accurately using NMEA over a serial interface at 4800 8N1 on a Linux Desktop. You can change the Copernicus II output with little effort using Trimble's GPS Studio (Windows PC required). One typical pitfall is the missing timepps.h - did you copy it to your source tree before configuring/compiling ntp? Joachim On 16.02.2016 12:56, Neil Green wrote: > I'm trying, and failing, to get ntp to talk to a Trimble Copernicus II > receiver outputting TSIP at 38400 over GPIO on a Raspberry Pi. NTP was > compiled with: > > --- > > ./configure --enable-TRIMTSIP --enable-SHM --disable-ipv6 --enable-linuxcaps > --enable-GPSD --enable-NMEA --enable-ATOM > > --- > > > My ntp.conf: > > --- > > driftfile /var/lib/ntp/ntp.drift > > logfile /var/log/ntp.log > > leapfile /home/pi/leap-seconds.3661632000 > > > enable calibrate > > disable bclient > > tos mindist 0.0002 > > > server 80.5.182.144 iburst > > server 89.16.173.64 iburst > > server 143.210.16.201 iburst > > server 217.114.59.3 iburst > > server 158.43.128.66 iburst > > server 129.215.42.240 iburst > > > server 127.127.8.0 mode 138 minpoll 4 maxpoll 4 iburst prefer > > fudge 127.127.8.0 refid TSIP flag2 0 flag3 1 > > > restrict -4 default kod notrap nomodify nopeer noquery > > > restrict 127.0.0.1 > > --- > > > And NTP sees the TSIP output: > > --- > > associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, > > version="ntpd 4.3.91@1.2483-o Mon Feb 15 23:41:44 UTC 2016 (3)", > > processor="armv7l", system="Linux/4.1.17-v7+", leap=00, stratum=3, > > precision=-19, rootdelay=22.680, rootdisp=21.143, refid=80.5.182.144, > > reftime=da6d88a4.d07d578a Tue, Feb 16 2016 11:38:12.814, > > clock=da6d89d1.39d90431 Tue, Feb 16 2016 11:43:13.225, peer=6872, tc=6, > > mintc=3, offset=0.154387, frequency=-7.677, sys_jitter=0.722466, > > clk_jitter=1.027, clk_wander=0.008, tai=36, leapsec=20150701, > > expire=20161228 > > remote refid st t when poll reach delay offset jitter > > == > > *80.5.182.14410.178.5.138 2 u 34 64 177 16.308 -1.325 2.405 > > 89.16.173.64.STEP. 16 u- 6400.0000.000 0.000 > > 143.210.16.201 .STEP. 16 u- 6400.0000.000 0.000 > > 217.114.59.3.STEP. 16 u- 6400.0000.000 0.000 > > +158.43.128.66 193.67.79.2022 u 37 64 177 20.338 -0.721 1.413 > > 129.215.42.240 .STEP. 16 u- 6400.0000.000 0.000 > > 127.127.8.0 .TSIP. 0 l- 1600.0000.000 0.000 > > ntp_gettime() returns code 0 (OK) > > time da6d89d1.55f19d68 Tue, Feb 16 2016 11:43:13.335, (.335718994), > > maximum error 178483 us, estimated error 1026 us, TAI offset 36 > > ntp_adjtime() returns code 0 (OK) > > modes 0x0 (), > > offset 47.530 us, frequency -7.677 ppm, interval 4 s, > > maximum error 178483 us, estimated error 1026 us, > > status 0x2001 (PLL,NANO), > > time constant 6, precision 0.001 us, tolerance 500 ppm, > > pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, > > intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. > > associd=0 status=0015 1 event, clk_bad_date, > > device="Trimble GPS (TSIP) receiver", timecode="\x10\x82\x07\x10\x03", > > poll=28, noreply=0, badformat=0, baddata=1, fudgetime1=20.000, stratum=0, > > refid=TSIP, flags=4, > > refclock_ppstime="da6d89d1.00ea7be3 Tue, Feb 16 2016 11:43:13.003", > > refclock_time="", refclock_status="PPS; (PPS SIGNAL)", > > refclock_format="Trimble TSIP", > > refclock_states="*ILLEGAL DATE: 00:07:22 (100.00%); running time: 00:07:22", > > gps_position_ext(LLA)="lat 52.919398 N, lon 1.488431 W, alt 51.04m", > > trimble_receiver_health="doing position fixes, Battery backup failed", > > trimble_status="machine id 0x01, Battery Powered Time Clock Fault, > Superpackets supported", > > trimble_satview="mode: 3D-AUTO, PDOP 2.73, HDOP 1.70, VDOP 2.14, TDOP 1.73, 6 > satellites in view: 02, 05, 07, 09, 30, 06", > > trimble_tracking_status[02]="ch=0, acq=ACQ, eph=1, signal_level= 27.00, > elevation= 32.18, azimuth= 228.37", > > trimble_tracking_status[05]="ch=1, acq=ACQ, eph=1, signal_level= 29.00, > elevation= 58.26, azimuth= 289.16", > > trimble_tracking_status[13]="ch=7, acq=ACQ, eph=1, signal_level= 23.00, > elevation= 23.72, azimuth= 257.97, collecting data", > > trimble_tra
[ntp:questions] NTP and Trimble TSIP
I'm trying, and failing, to get ntp to talk to a Trimble Copernicus II receiver outputting TSIP at 38400 over GPIO on a Raspberry Pi. NTP was compiled with: --- ./configure --enable-TRIMTSIP --enable-SHM --disable-ipv6 --enable-linuxcaps --enable-GPSD --enable-NMEA --enable-ATOM --- My ntp.conf: --- driftfile /var/lib/ntp/ntp.drift logfile /var/log/ntp.log leapfile /home/pi/leap-seconds.3661632000 enable calibrate disable bclient tos mindist 0.0002 server 80.5.182.144 iburst server 89.16.173.64 iburst server 143.210.16.201 iburst server 217.114.59.3 iburst server 158.43.128.66 iburst server 129.215.42.240 iburst server 127.127.8.0 mode 138 minpoll 4 maxpoll 4 iburst prefer fudge 127.127.8.0 refid TSIP flag2 0 flag3 1 restrict -4 default kod notrap nomodify nopeer noquery restrict 127.0.0.1 --- And NTP sees the TSIP output: --- associd=0 status=0618 leap_none, sync_ntp, 1 event, no_sys_peer, version="ntpd 4.3.91@1.2483-o Mon Feb 15 23:41:44 UTC 2016 (3)", processor="armv7l", system="Linux/4.1.17-v7+", leap=00, stratum=3, precision=-19, rootdelay=22.680, rootdisp=21.143, refid=80.5.182.144, reftime=da6d88a4.d07d578a Tue, Feb 16 2016 11:38:12.814, clock=da6d89d1.39d90431 Tue, Feb 16 2016 11:43:13.225, peer=6872, tc=6, mintc=3, offset=0.154387, frequency=-7.677, sys_jitter=0.722466, clk_jitter=1.027, clk_wander=0.008, tai=36, leapsec=20150701, expire=20161228 remote refid st t when poll reach delay offset jitter == *80.5.182.14410.178.5.138 2 u 34 64 177 16.308 -1.325 2.405 89.16.173.64.STEP. 16 u- 6400.0000.000 0.000 143.210.16.201 .STEP. 16 u- 6400.0000.000 0.000 217.114.59.3.STEP. 16 u- 6400.0000.000 0.000 +158.43.128.66 193.67.79.2022 u 37 64 177 20.338 -0.721 1.413 129.215.42.240 .STEP. 16 u- 6400.0000.000 0.000 127.127.8.0 .TSIP. 0 l- 1600.0000.000 0.000 ntp_gettime() returns code 0 (OK) time da6d89d1.55f19d68 Tue, Feb 16 2016 11:43:13.335, (.335718994), maximum error 178483 us, estimated error 1026 us, TAI offset 36 ntp_adjtime() returns code 0 (OK) modes 0x0 (), offset 47.530 us, frequency -7.677 ppm, interval 4 s, maximum error 178483 us, estimated error 1026 us, status 0x2001 (PLL,NANO), time constant 6, precision 0.001 us, tolerance 500 ppm, pps frequency 0.000 ppm, stability 0.000 ppm, jitter 0.000 us, intervals 0, jitter exceeded 0, stability exceeded 0, errors 0. associd=0 status=0015 1 event, clk_bad_date, device="Trimble GPS (TSIP) receiver", timecode="\x10\x82\x07\x10\x03", poll=28, noreply=0, badformat=0, baddata=1, fudgetime1=20.000, stratum=0, refid=TSIP, flags=4, refclock_ppstime="da6d89d1.00ea7be3 Tue, Feb 16 2016 11:43:13.003", refclock_time="", refclock_status="PPS; (PPS SIGNAL)", refclock_format="Trimble TSIP", refclock_states="*ILLEGAL DATE: 00:07:22 (100.00%); running time: 00:07:22", gps_position_ext(LLA)="lat 52.919398 N, lon 1.488431 W, alt 51.04m", trimble_receiver_health="doing position fixes, Battery backup failed", trimble_status="machine id 0x01, Battery Powered Time Clock Fault, Superpackets supported", trimble_satview="mode: 3D-AUTO, PDOP 2.73, HDOP 1.70, VDOP 2.14, TDOP 1.73, 6 satellites in view: 02, 05, 07, 09, 30, 06", trimble_tracking_status[02]="ch=0, acq=ACQ, eph=1, signal_level= 27.00, elevation= 32.18, azimuth= 228.37", trimble_tracking_status[05]="ch=1, acq=ACQ, eph=1, signal_level= 29.00, elevation= 58.26, azimuth= 289.16", trimble_tracking_status[13]="ch=7, acq=ACQ, eph=1, signal_level= 23.00, elevation= 23.72, azimuth= 257.97, collecting data", trimble_tracking_status[06]="ch=8, acq=ACQ, eph=1, signal_level= 20.00, elevation= 8.61, azimuth= 190.83", trimble_tracking_status[20]="ch=2, acq=ACQ, eph=0, signal_level= 23.00, elevation= 10.48, azimuth= 306.67, collecting data", trimble_tracking_status[07]="ch=3, acq=ACQ, eph=1, signal_level= 31.00, elevation= 63.74, azimuth= 91.16", trimble_tracking_status[09]="ch=5, acq=ACQ, eph=1, signal_level= 28.00, elevation= 33.34, azimuth= 80.90", trimble_tracking_status[30]="ch=6, acq=ACQ, eph=1, signal_level= 44.00, elevation= 58.63, azimuth= 164.76", gps-message="" --- My ntp.log shows: --- PARSE receiver
