All,
I'm looking for some guidance on how to further troubleshoot an issue
I've seemingly always had with several Motorola Oncore UT/GT+ receiver
modules that I use for some hobbyist time keeping fun. From day one
tinkering with this receiver module, I don't think I've ever been
successful in getting the 1PPS source to not be a falseticker.
My offset and jitter numbers look really good for both the Oncore GPS
and 1PPs. The parallel channels on the receiver always have decent
amount of satellite locks/tracking counts in the 'clockstats'. It
usually takes about 15-45min for the offset and jitter to stabilize out.
Any fine-tuning to get more accuracy and bring down the offset a bit,
I've used with fudge 'time1' in the ntp configuration.
-------------------------------
snipit of peers listing
-------------------------------
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) .LOCL. 8 l 8h 64 0 0.000 0.000
0.000
*GPS_ONCORE(0) .GPS. 0 l 8 16 377 0.000 -1.184
0.265
xPPS(0) .PPS. 0 l 39 64 377 0.000 -1.121
0.045
+nist1-lnk.binar .ACTS. 1 u 44 64 377 32.239 4.060
0.684
+nisttime.carson .ACTS. 1 u 58 64 377 39.005 -3.028
0.245
-nist1-chi.ustim .ACTS. 1 u 49 64 377 86.275 5.273
1.751
-------------------------------
-------------------------------
snipit of `ppstest` for 1PPS
-------------------------------
# /opt/ntpgps/src/linux-2.6.24.2-wocket/Documentation/pps/ppstest
/dev/pps0
trying PPS source "/dev/pps0"
found PPS source "/dev/pps0"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1352494210.001566983, sequence: 68698 - clear
1352494209.199970280, sequence: 68696
source 0 - assert 1352494210.001566983, sequence: 68698 - clear
1352494210.200019671, sequence: 68697
source 0 - assert 1352494211.001566566, sequence: 68699 - clear
1352494210.200019671, sequence: 68697
source 0 - assert 1352494211.001566566, sequence: 68699 - clear
1352494211.200077897, sequence: 68698
source 0 - assert 1352494212.001565263, sequence: 68700 - clear
1352494211.200077897, sequence: 68698
source 0 - assert 1352494212.001565263, sequence: 68700 - clear
1352494212.200130696, sequence: 68699
source 0 - assert 1352494213.001566734, sequence: 68701 - clear
1352494212.200130696, sequence: 68699
source 0 - assert 1352494213.001566734, sequence: 68701 - clear
1352494213.200182691, sequence: 68700
source 0 - assert 1352494214.001564762, sequence: 68702 - clear
1352494213.200182691, sequence: 68700
source 0 - assert 1352494214.001564762, sequence: 68702 - clear
1352494214.200234787, sequence: 68701
#
-------------------------------
On the hardware size, I'd say it's fair my setup is pretty basic and
hackish: <Oncore Receiver> --> TTL5v-to-RS232-DB9-male ---> serial
cable --> onboard serial port on server/PC (x8664). The 1PPS from the
Oncore receiver I have wired and soldered straight into the carrier
detect pin of the DB9-male. The serial port configuration with
'setserial' is set for 16550A, with low_latency on.
On the OS, I am using a pretty old kernel (to date), 2.6.24.2 patched
with PPSAPI (from 2/2008, sounds even more dated when I type it even!).
NTP version I am using is fairly bleeding edge on the devel side,
ntp-dev-4.2.7p316.
A snipit of my ntp.conf for this receiver is as follows:
-------------------------------
ntp.conf
-------------------------------
### Kernel PPS Selection
enable pps
pps /dev/oncore.pps.0 hardpps
server 127.127.30.0 minpoll 6
fudge 127.127.30.0 time1 0.1988
# shmpps (PPS refclock)
server 127.127.22.0 minpoll 6
fudge 127.127.22.0 time1 0.00055
tos mindist 0.010
# Additional time sources
server nist1-lnk.binary.net
server nisttime.carsoncity.k12.mi.us
server nist1-chi.ustiming.org
-------------------------------
As far as to have extra outside time keeping candidates to help
identify 'falsetickers', I've got three servers listed in my
configuration as well (see above). The 'tos mindist' I thought would
help as a crackshot to widen the jitter range, but there really isn't a
lit of jitter anyway from that source, so I was really just grasping at
that point.
I've tried a lot of the steps listed on the ntp.org TroubleShooting
pages, and any tidbits I could find on this NTP list and tried some
adjustments with 'tos', as mentioned from the PPS reference clock page
(http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver22.html)
Again, that's kind of where I'm at in a nutshell. If anyone has any
wisdom to share as to where to focus the troubleshooting at, I'd greatly
appreciate it.
Thanks!
-Adam
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
