[ntp:questions] Fw: NTP and Trimble TSIP

Neil Green ncguk at hotmail.co.uk
Tue Feb 16 12:48:41 UTC 2016


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 <joachim.fabini at tuwien.ac.at>
Sent: 16 February 2016 12:22
To: Neil Green; questions at 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 at 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=201507010000,
>
> expire=201612280000
>
>      remote           refid      st t when poll reach   delay   offset  jitter
>
> ==============================================================================
>
> *80.5.182.144    10.178.5.138     2 u   34   64  177   16.308   -1.325   2.405
>
>  89.16.173.64    .STEP.          16 u    -   64    0    0.000    0.000   0.000
>
>  143.210.16.201  .STEP.          16 u    -   64    0    0.000    0.000   0.000
>
>  217.114.59.3    .STEP.          16 u    -   64    0    0.000    0.000   0.000
>
> +158.43.128.66   193.67.79.202    2 u   37   64  177   20.338   -0.721   1.413
>
>  129.215.42.240  .STEP.          16 u    -   64    0    0.000    0.000   0.000
>
>  127.127.8.0     .TSIP.           0 l    -   16    0    0.000    0.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="<UNDEFINED>", 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 #0: initializing PPS to ASSERT
>
> ---------------------------------------------------------------------------
>
>
> But NTP never "locks onto" the TSIP output. What am I missing?
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>


More information about the questions mailing list