How to debug GPS PPS?
xyz-2041
GPS_NMEA(1) .GPS. 0 l - 64 0 0.000
0.000 0.001
ntpq> rv
assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/
strat_chg,
version="ntpd 4.2...@1.1607-o Wed Dec 16 07:24:35 UTC 2009 (1)",
processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
precision=-20, rootdelay=53.694, rootdispersion=31.936, peer=3269,
refid=18.26.4.105,
reftime=ceda45a9.1bda1b54 Mon, Dec 21 2009 13:06:17.108, poll=8,
clock=ceda4a7b.9a36d363 Mon, Dec 21 2009 13:26:51.602, state=4,
offset=-3.784, frequency=-47.665, jitter=2.066, noise=3.569,
stability=0.026, tai=0
# ntptime
ntp_gettime() returns code 0 (OK)
time ceda48c0.01611ba4 Mon, Dec 21 2009 13:19:28.005, (.005388419),
maximum error 445680 us, estimated error 3569 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
modes 0x0 (),
offset -3119.252 us, frequency -47.665 ppm, interval 4 s,
maximum error 445680 us, estimated error 3569 us,
status 0x2001 (PLL,NANO),
time constant 8, precision 0.001 us, tolerance 496 ppm,
pps frequency -47.445 ppm, stability 0.000 ppm, jitter 0.000 us,
intervals 0, jitter exceeded 0, stability exceeded 0, errors 0.
What to check next?
unruh
> ntpq> pe GPS line reads:
>
> GPS_NMEA(1) .GPS. 0 l - 64 0 0.000
> 0.000 0.001
>
>
> ntpq> rv
> assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/
> strat_chg,
> version="ntpd 4.2...@1.1607-o Wed Dec 16 07:24:35 UTC 2009 (1)",
> processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
> precision=-20, rootdelay=53.694, rootdispersion=31.936, peer=3269,
> refid=18.26.4.105,
> reftime=ceda45a9.1bda1b54 Mon, Dec 21 2009 13:06:17.108, poll=8,
> clock=ceda4a7b.9a36d363 Mon, Dec 21 2009 13:26:51.602, state=4,
> offset=-3.784, frequency=-47.665, jitter=2.066, noise=3.569,
> stability=0.026, tai=0
Is the gps plugged into the serial port? Is the PPS line operating ( eg
does it have an led on it to let you know that it is working)? And
serial interrupts turned on?
xyz-2041
> On 2009-12-21, xyz-2041 <xyz2...@gmail.com> wrote:
>
>
>
> > ntpq> pe GPS line reads:
>
> > GPS_NMEA(1) .GPS. 0 l - 64 0 0.000
> > 0.000 0.001
>
> > ntpq> rv
> > assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/
> > strat_chg,
> > processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
> > precision=-20, rootdelay=53.694, rootdispersion=31.936, peer=3269,
> > refid=18.26.4.105,
> > reftime=ceda45a9.1bda1b54 Mon, Dec 21 2009 13:06:17.108, poll=8,
> > clock=ceda4a7b.9a36d363 Mon, Dec 21 2009 13:26:51.602, state=4,
> > offset=-3.784, frequency=-47.665, jitter=2.066, noise=3.569,
> > stability=0.026, tai=0
>
> Is the gps plugged into the serial port?
Yes. I may have to get out the volt meter to
see which pin is giving the pulse.
Is the PPS line operating ( eg
> does it have an led on it to let you know that it is working)?
Yeppers. Blinks once a second in sync with WWV.
>And
> serial interrupts turned on?
How would I check on FreeBSD?
David J Taylor
news:3e8fc6d9-d4e2-4eb8...@d20g2000yqh.googlegroups.com...
[]
> How would I check on FreeBSD?
My FreeBSD notes - from some years ago - are here:
http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm
If they help, great, if not I can't help further with that OS.
Cheers,
David
xyz-2041
computer running WinOncore12 v1.0 (Build 37):
http://www.google.com/#q=WinOncore12Installation.exe
Seemed to work without any problems. Generated
all sort of graphs and charts. Let it run and it
told me exact latitude, longitude and height above
sea level.
Used an analog volt meter and from pin 5 (supposed
to be ground), I only noticed voltage on pins 2 and 3.
Pin 2 was going erratically negative once a second.
I believe that this must be received data as per
standards. Pin 3 was +5 volts, but dropping to
-5 volts once per second.
I've changed my configs a bit, /var/log/ntp.log and
/var/log/ntpd.log don't show any errors.
However, "ntpq -c pe" still doesn't show any response:
GPS_NMEA(0) .GPS. 0 l - 16 0 0.000
0.000 0.001
PPS(0) .GPS. 0 l - 16 0 0.000
0.000 0.001
GPS_ONCORE(0) .GPS-. 0 l - 16 0 0.000
0.000 0.001
Also:
ntpdc -c kerninfo
pll offset: -0.00539973 s
pll frequency: -46.079 ppm
maximum error: 0.097522 s
estimated error: 0.003708 s
status: 2201 pll ppsjitter nano
pll time constant: 8
precision: 1e-09 s
frequency tolerance: 496 ppm
pps frequency: -9.224 ppm
pps stability: 0.000 ppm
pps jitter: 0 s
calibration interval: 4 s
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0
Here is what I have done so far:
- Edit new kernel config file:
cd /usr/src/sys/i386/conf/
nano PPS-Generic
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Generic kernel configuration with PPS_SYNC option
#
include GENERIC
ident PPS-GENERIC
# Enable support for the kernel PLL to use an external PPS signal,
# under supervision of [x]ntpd(8)
# More info in ftp://ftp.udel.edu/pub/ntp/kernel.tar.Z
options PPS_SYNC
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Build and compile the new kernel:
cd /usr/src
ls -lt /usr/src/sys/i386/conf
make buildkernel KERNCONF=PPS-GENERIC
This should take 10 mins to 2 hours depending
on the speed of your computer.
Check to see that it was created:
cd /usr/obj/usr/src/sys/PPS-GENERIC
ls -lta | more
- Install the new kernel:
cd /usr/src
make installkernel KERNCONF=PPS-GENERIC
Check that the new kernel is installed:
cd /boot
ls -lta
These directories should be there:
kernel
kernel.old
Go into each directory and notice
the time stamps of the "kernel"
files:
cd /boot/kernel
ls -lta | grep kernel
-r-xr-xr-x 1 root wheel 10204732 Dec 19 13:44 kernel
-r-xr-xr-x 1 root wheel 31172114 Dec 19 13:44 kernel.symbols
cd /boot/kernel.old
ls -lta | grep kernel
-r-xr-xr-x 1 root wheel 10201628 May 1 2009 kernel
-r-xr-xr-x 1 root wheel 31167198 May 1 2009 kernel.symbols
Reboot:
shutdown -r now
- Check if new kernel running
After rebooting and logging in:
uname -a | grep PPS
You should get a readout of the kernel
name which should include "PPS"
- Create Oncore config file
cd /etc
nano ntp.oncore0
MODE 1
LON -75.7479
LAT 39.6632
HTGPS 67 FT
DELAY 30 NS
- Create symbolic links:
ln -s /dev/cuad0 /dev/oncore.pps.0
ln -s /dev/cuad0 /dev/oncore.serial.0
ln -s /dev/cuad0 /dev/gps0
ln -s /dev/cuad0 /dev/pps0d
- Create /etc/devfs.conf links:
link cuad0 pps0
link cuad0 gps0
link cuad0 oncore.pps.0
link cuad0 oncore.serial.0
- Check them:
ls -lta /dev | more
- Edit /etc/ntp.conf:
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# This is the configuration file for NTP
# (Network Time Protocol). More info at
# www.NTP.org
#
# /etc/ntp.conf
# This computer will act as a stratum 2 time
# server, by referencing the following 4 or
# more stratum 1 time servers:
server ntp2.netwrx1.com iburst # WI
server otc1.psu.edu iburst # PA
server t2.timegps.net iburst # CA
server tick.usask.ca iburst # CAN
# GPS NMEA (numbers seconds only)
# server 127.127.20.0 prefer minpoll 4 maxpoll 4
server 127.127.20.0 minpoll 4 maxpoll 4
#flag3 Controls the kernel PPS discipline: 0 for disable (default), 1
for enable.
# fudge 127.127.20.0 flag3 1
fudge 127.127.20.0 flag3 0
# GPS PPS
server 127.127.22.0 prefer minpoll 4 maxpoll 4
#flag3 Controls the kernel PPS discipline: 0 for disable (default), 1
for enable.
fudge 127.127.22.0 flag3 1
fudge 127.127.22.0 refid GPS
# GPS Oncore driver
server 127.127.30.0
fudge 127.127.30.0 refid GPS-Oncore
# Since the clock on most PCs drifts around
# significantly, let's use a file to
# keep track of that drift and compensate
# for it:
driftfile /etc/ntp.drift
# This server will broadcast NTP timing signals
# over the Local Area Network (LAN):
broadcast 192.168.1.255
# Let's setup a log file for NTP:
logfile /var/log/ntp.log
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Does anyone have any idea what I might check next?
David Lord
The oncore driver mentions binary protocol is required and yet
you are also using NMEA driver. That doesn't seem correct.
Is your oncore setup for binary or NMEA?
It's easy enough to display MNEA using Minicom.
For looking at PPS signal you may not be lucky. It would
normally be on DCD, pin 1 of serial connector, and if only 1us
(I'm not familiar with oncore) then you'll not see it and
probably neither will FreeBSD without using a pulse stretcher.
I use a dual monostable as pulse stretcher for MSF timecode
to remove the intermediate data pulses and generate a single
50ms at start of each second. I set this up using radioclkd2
program in debug mode (not its intended purpose but far easier
than using a scope).
I'd forget about PPS until you have either the oncore driver
or NMEA working. My Garmin gps18x-LVC with NMEA driver gives
around 70us offset on a good day then about 1us with PPS.
Data on pin-2 is RxD and on pin-3 is TxD, which may be from
the NMEA driver.
David
Thomas Laus
> Plugged in the GPS unit's serial cable into a Windows
> computer running WinOncore12 v1.0 (Build 37):
>
> http://www.google.com/#q=WinOncore12Installation.exe
>
> Seemed to work without any problems. Generated
> all sort of graphs and charts. Let it run and it
> told me exact latitude, longitude and height above
> sea level.
>
> Used an analog volt meter and from pin 5 (supposed
> to be ground), I only noticed voltage on pins 2 and 3.
> Pin 2 was going erratically negative once a second.
> I believe that this must be received data as per
> standards. Pin 3 was +5 volts, but dropping to
> -5 volts once per second.
>
your computer or it's model number. I use one of the TAPR boards and
Oncore UT+ combination. The NTP refclock driver for the Oncore includes
the code for receiving the PPS signal on the computer DCD pin.
> I've changed my configs a bit, /var/log/ntp.log and
> /var/log/ntpd.log don't show any errors.
>
> However, "ntpq -c pe" still doesn't show any response:
>
> GPS_NMEA(0) .GPS. 0 l - 16 0 0.000
> 0.000 0.001
> PPS(0) .GPS. 0 l - 16 0 0.000
> 0.000 0.001
> GPS_ONCORE(0) .GPS-. 0 l - 16 0 0.000
> 0.000 0.001
>
You should not be using GPS_NMEA or PPS. The type 30 refclock
communicates with the receiver using Motorola Binary protocol. You may
need to use WinOncore to set your receiver communications to use the
binary protocol or even better, reset the receiver to factory defaults.
Your config files already have your position defined, so there is no
need to have anything in your receiver at startup. The almanac will be
received while NTP is settling down after startup. You will need to
configure at least 4 other NTP servers to speed up the initial startup.
The refclock code wants to have a synchronized NTP server before adding
itself to the peer selection. I find about 30 minutes after a cold
start my PPS LED will start to flash and I observe that my Oncore gets
selected.
> - Create symbolic links:
>
> ln -s /dev/cuad0 /dev/oncore.pps.0
> ln -s /dev/cuad0 /dev/oncore.serial.0
> ln -s /dev/cuad0 /dev/gps0
> ln -s /dev/cuad0 /dev/pps0d
>
> - Create /etc/devfs.conf links:
>
> link cuad0 pps0
> link cuad0 gps0
> link cuad0 oncore.pps.0
> link cuad0 oncore.serial.0
>
>
I think that you will find that the symbolic links in /dev are not required and
only the /etc/devfs.conf entries are all you will need. You won't need
either pps0 or gps0 entries for anything. Only the oncore* stuff is
needed for the refclock type 30.
Tom
---
Public Keys:
PGP KeyID = 0x5F22FDC1
GnuPG KeyID = 0x620836CF
cl...@nwlink.com
mentions (Oncore GPS, TAPR interface board); but have been using the NMEA
driver and trying to hack the Linux kernel (Ubuntu) to do PPS.
This seems like perhaps an easier way - Tom, can you post the details on
the OnCore driver?
Thanks in advance!
Clay
N7QNM
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>
>
xyz-2041
> On 2009-12-28, xyz-2041 <xyz2...@gmail.com> wrote:
>
> > Plugged in the GPS unit's serial cable into a Windows
> > computer running WinOncore12 v1.0 (Build 37):
>
> > http://www.google.com/#q=WinOncore12Installation.exe
>
> > Seemed to work without any problems. Generated
> > all sort of graphs and charts. Let it run and it
> > told me exact latitude, longitude and height above
> > sea level.
>
> > Used an analog volt meter and from pin 5 (supposed
> > to be ground), I only noticed voltage on pins 2 and 3.
> > Pin 2 was going erratically negative once a second.
> > I believe that this must be received data as per
> > standards. Pin 3 was +5 volts, but dropping to
> > -5 volts once per second.
>
> You did not mention how your Oncore receiver was being interfaced to
> your computer or it's model number.
GT+. Serial port.
>I use one of the TAPR boards and
> Oncore UT+ combination. The NTP refclock driver for the Oncore includes
> the code for receiving the PPS signal on the computer DCD pin.
It doesn't need pulse stretching?
> > I've changed my configs a bit, /var/log/ntp.log and
> > /var/log/ntpd.log don't show any errors.
>
> > However, "ntpq -c pe" still doesn't show any response:
>
> > GPS_NMEA(0) .GPS. 0 l - 16 0 0.000
> > 0.000 0.001
> > PPS(0) .GPS. 0 l - 16 0 0.000
> > 0.000 0.001
> > GPS_ONCORE(0) .GPS-. 0 l - 16 0 0.000
> > 0.000 0.001
>
> You should not be using GPS_NMEA or PPS.
OK. Turned both of those off.
>The type 30 refclock
> communicates with the receiver using Motorola Binary protocol. You may
> need to use WinOncore to set your receiver communications to use the
> binary protocol or even better, reset the receiver to factory defaults.
OK. Used WinOncore to default. Made sure that it was
set to Motorola/binary. Power cycled. Hooked back
up to FreeBSD server. This is what was produced--for
a while:
remote refid st t when poll reach delay
offset jitter
======================================================
GPS_ONCORE(0) .GPS. 0 l 99 16 40 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 200 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 418 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 636 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 938 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 1167 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 1226 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 1352 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 2028 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 61m 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 67m 16 0 0.000
192.362 0.002
GPS_ONCORE(0) .GPS. 0 l 176m 16 0 0.000
192.362 0.002
Re-defaulted. Now back to this:
GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
0.000 0.002
> Your config files already have your position defined, so there is no
> need to have anything in your receiver at startup. The almanac will be
> received while NTP is settling down after startup. You will need to
> configure at least 4 other NTP servers to speed up the initial startup.
Got those.
> The refclock code wants to have a synchronized NTP server before adding
> itself to the peer selection. I find about 30 minutes after a cold
> start my PPS LED will start to flash and I observe that my Oncore gets
> selected.
PPS LED was flashing, but NTP never synchronized.
>
> > - Create symbolic links:
>
> > ln -s /dev/cuad0 /dev/oncore.pps.0
> > ln -s /dev/cuad0 /dev/oncore.serial.0
> > ln -s /dev/cuad0 /dev/gps0
> > ln -s /dev/cuad0 /dev/pps0d
>
> > - Create /etc/devfs.conf links:
>
> > link cuad0 pps0
> > link cuad0 gps0
> > link cuad0 oncore.pps.0
> > link cuad0 oncore.serial.0
>
> I think that you will find that the symbolic links in /dev are not required and
> only the /etc/devfs.conf entries are all you will need. You won't need
> either pps0 or gps0 entries for anything. Only the oncore* stuff is
> needed for the refclock type 30.
OK.
Well, this just doesn't seem to be working. Does anyone have other
suggestions on how to get this GT+ working?
If not, does anyone have some other suggestions? Would I be able
to use this Motorola antenna with another GPS unit? Other low-cost
ways of getting GPS accuracy on this FreeBSD/NTP box?
David Lord
> On Dec 28, 7:59 am, Thomas Laus <lau...@acm.org> wrote:
>> On 2009-12-28, xyz-2041 <xyz2...@gmail.com> wrote:
>>
>>> Plugged in the GPS unit's serial cable into a Windows
>>> computer running WinOncore12 v1.0 (Build 37):
>>> http://www.google.com/#q=WinOncore12Installation.exe
>>> Seemed to work without any problems. Generated
>>> all sort of graphs and charts. Let it run and it
>>> told me exact latitude, longitude and height above
>>> sea level.
>>> Used an analog volt meter and from pin 5 (supposed
>>> to be ground), I only noticed voltage on pins 2 and 3.
>>> Pin 2 was going erratically negative once a second.
>>> I believe that this must be received data as per
>>> standards. Pin 3 was +5 volts, but dropping to
>>> -5 volts once per second.
>> You did not mention how your Oncore receiver was being interfaced to
>> your computer or it's model number.
>
> GT+. Serial port.
>
>
>> I use one of the TAPR boards and
>> Oncore UT+ combination. The NTP refclock driver for the Oncore includes
>> the code for receiving the PPS signal on the computer DCD pin.
>
> It doesn't need pulse stretching?
I'm not familiar with the oncore but you mentioned checking
levels on serial pins but didn't state what you found on pin 1.
Can you check this for the pps signal?
Try a large setting for mindist.
tos mindist 0.05
Also remove any minpoll/maxpoll from your server line or set
to minpoll 6.
David
unruh
> xyz-2041 wrote:
>> On Dec 28, 7:59 am, Thomas Laus <lau...@acm.org> wrote:
>> If not, does anyone have some other suggestions? Would I be able
>> to use this Motorola antenna with another GPS unit? Other low-cost
>> ways of getting GPS accuracy on this FreeBSD/NTP box?
the standard is the Garmin GPS18xLVC unit. Cost about $60, plus some
soldering of a serial port and usb port plug(for power) onto the
wires.
Richard B. Gilbert
This is the first I've heard of "Winoncore 12" "Oncore" used to be a
Motorola trademark for a GPS receiver. IIRC it was a Motorola Oncore
M12+T. Motorola got out of the GPS business years ago; they sold the
business to (I think) SiRF.
Your ntp.conf file mentions being a Stratum 2 server. If you are using
GPS your stratum is 1 because you are getting your time from an atomic
clock on one of the Navstar satellites!
How to "debug" it depends on what sort of a bug it is. If you said why
you think you have a bug, I missed it!
Your biggest problem may be that Windows is not exactly the world's
greatest time keeper! The clock "ticks" every 17 milliseconds!
David Lord
Mine was good for 1us during period I had it setup in summer
but when I tested more recently PPS was very erratic, I suspect
because it's TTL level with borderline pull down when temperature
drops (can also see this from MSF receiver also TTL outputs). So
depending on serial port of pc it may need PPS signal converting
to rs232.
David
David Woolley
> Your biggest problem may be that Windows is not exactly the world's
> greatest time keeper! The clock "ticks" every 17 milliseconds!
>
Did you mean to write 1ms? I'm not sure if the latest actually go down
to 500 microseconds. Still poor compared with the sub-microsecond
precision on most recent Unix and Linux systems.
However that is all irrelevant as it is quite clear that ntpd is NOT
running on Windows in this case!
David J Taylor
news:FbGdnYtRs_jzfqbW...@giganews.com...
[]
> Your biggest problem may be that Windows is not exactly the world's
> greatest time keeper! The clock "ticks" every 17 milliseconds!
Whilst this is correct and, yes, FreeBSD can do better, it may be
misleading because with care Windows does much better than 17ms for
running NTP. Here is data I've gathered from my own GPS-synced Windows
PCs:
PC Feenix - offset typically better than 250 microseconds:
http://www.satsignal.eu/mrtg/feenix_ntp_2.html
PC Stamsund - offset typically much better than 250 microseconds:
http://www.satsignal.eu/mrtg/stamsund_ntp_2.html
PC Bacchus - offset typically better than 250 microseconds, except when
the CPU suddenly changes from 0% to 100% CPU usage for an hour, and causes
a considerable temperature rise:
http://www.satsignal.eu/mrtg/bacchus_ntp-b.html
Cheers,
David
Thomas Laus
> On Dec 28, 7:59?am, Thomas Laus <lau...@acm.org> wrote:
>> On 2009-12-28, xyz-2041 <xyz2...@gmail.com> wrote:
>>
>> > Plugged in the GPS unit's serial cable into a Windows
>> > computer running WinOncore12 v1.0 (Build 37):
>>
>>
>> > Seemed to work without any problems. ?Generated
>> > all sort of graphs and charts. ?Let it run and it
>> > told me exact latitude, longitude and height above
>> > sea level.
>>
>> > Used an analog volt meter and from pin 5 (supposed
>> > to be ground), I only noticed voltage on pins 2 and 3.
>> > Pin 2 was going erratically negative once a second.
>> > I believe that this must be received data as per
>> > -5 volts once per second.
>>
>> You did not mention how your Oncore receiver was being interfaced to
>
> GT+. Serial port.
>
>
>>I use one of the TAPR boards and
>> the code for receiving the PPS signal on the computer DCD pin.
>
> It doesn't need pulse stretching?
>
>
>> > I've changed my configs a bit, /var/log/ntp.log and
>> > /var/log/ntpd.log don't show any errors.
>>
>> > However, "ntpq -c pe" still doesn't show any response:
>>
>> > 0.000 ? 0.001
>> > ?PPS(0) ? ? ? ? ?.GPS. ? ? ? ? ? ?0 l ? ?- ? 16 ? ?0 ? ?0.000
>> > 0.000 ? 0.001
>> > ?GPS_ONCORE(0) ? .GPS-. ? ? ? ? ? 0 l ? ?- ? 16 ? ?0 ? ?0.000
>> > 0.000 ? 0.001
>>
>> You should not be using GPS_NMEA or PPS. ?
>
> OK. Turned both of those off.
>
>
>>The type 30 refclock
> set to Motorola/binary. Power cycled. Hooked back
> up to FreeBSD server. This is what was produced--for
> a while:
>
> remote refid st t when poll reach delay
> offset jitter
>======================================================
> GPS_ONCORE(0) .GPS. 0 l 99 16 40 0.000
> 192.362 0.002
>
> GPS_ONCORE(0) .GPS. 0 l 200 16 0 0.000
> 192.362 0.002
>
> GPS_ONCORE(0) .GPS. 0 l 418 16 0 0.000
> 192.362 0.002
>
comunicate with your Oncore. You might get some insight by enabling
some of the statistics. You add them to /etc/ntp.conf
# NTP Statistics
statsdir /var/log/ntp/
statistics clockstats loopstats peerstats
filegen clockstats file clockstats type day enable
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
NTP will write events to these files when it runs. The satellites that
are in view will be listed by PRN number. It also will show any RS-232
handshaking issues. I had to change the flag for reading the PPS pin
because it was triggering on the trailing edge instead of the leading
edge. My TAPR board pulsewidth was OK and did not require 'stretching'.
> Re-defaulted. Now back to this:
>
> GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> 0.000 0.002
>
>
There is still nothing in the 'reach' column, you are not talking at all
to your Oncore receiver. Even if the PPS was incorrect, you should
still get data from the Oncore as soon as your NTP has synced with your
other hosts. Your LED shows that your receiver has an almanac, position
and is synced to the satellites. It is just the RS-232 link is not
working between your TAPR board and your computer. A breakout box would
be handy in this case, but enabling the statistics may give enough
insight into the problem.
The Oncore / TAPR board is the gold standard of home user time sync
using the GPS constellation. Myself and others have been using this
combination for many years successfully. Does your PC have a 'real'
serial port or are you using a USB to serial adapter? My billboard
looks like this:
ntpq -c pe
remote refid st t when poll reach delay offset jitter
==============================================================================
-198.186.191.229 64.147.116.229 2 u 38 64 377 88.338 17.680 0.609
-tantalum.srvcs. 192.43.244.18 2 u 6 64 377 112.759 -29.145 3.168
+null-routed.net 198.153.152.52 2 u 42 64 377 79.333 1.590 0.792
+packman-1.isc.o 204.152.184.72 2 u 2 64 377 77.789 -8.314 2.418
*GPS_ONCORE(0) .GPS. 0 l 10 16 377 0.000 -0.016 0.001
Tom
--
xyz-2041
OK, done:
cd /var/log
mkdir ntp
cd /etc
nano /etc/ntp.conf
Seems to be talking to the unit:
http://www.A7H.com/~stuph/clockstats-Edited-2010-Jan-1-1300.txt
Nothing in peerstats or loopstats showing anything Oncore-GPS related.
> NTP will write events to these files when it runs. The satellites that
> are in view will be listed by PRN number. It also will show any RS-232
> handshaking issues. I had to change the flag for reading the PPS pin
> because it was triggering on the trailing edge instead of the leading
> edge. My TAPR board pulsewidth was OK and did not require 'stretching'.
Oncore GT+: does it need a pulse stretcher?
> > Re-defaulted. Now back to this:
>
> > GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> > 0.000 0.002
>
> There is still nothing in the 'reach' column, you are not talking at all
> to your Oncore receiver. Even if the PPS was incorrect, you should
> still get data from the Oncore as soon as your NTP has synced with your
> other hosts. Your LED shows that your receiver has an almanac, position
> and is synced to the satellites. It is just the RS-232 link is not
> working between your TAPR board and your computer. A breakout box would
> be handy in this case, but enabling the statistics may give enough
> insight into the problem.
>
> The Oncore / TAPR board is the gold standard of home user time sync
> using the GPS constellation. Myself and others have been using this
> combination for many years successfully. Does your PC have a 'real'
> serial port or are you using a USB to serial adapter?
DB9, no USB.
>My billboard
> looks like this:
>
> ntpq -c pe
>
> remote refid st t when poll reach delay offset jitter
> ==============================================================================
> -198.186.191.229 64.147.116.229 2 u 38 64 377 88.338 17.680 0.609
> -tantalum.srvcs. 192.43.244.18 2 u 6 64 377 112.759 -29.145 3.168
> +null-routed.net 198.153.152.52 2 u 42 64 377 79.333 1.590 0.792
> +packman-1.isc.o 204.152.184.72 2 u 2 64 377 77.789 -8.314 2.418
> *GPS_ONCORE(0) .GPS. 0 l 10 16 377 0.000 -0.016 0.001
Wish mine did.
Thomas Laus
>>
>> comunicate with your Oncore. ?You might get some insight by enabling
>> some of the statistics. ?You add them to /etc/ntp.conf
>>
>> # NTP Statistics
>> statsdir /var/log/ntp/
>> statistics clockstats loopstats peerstats
>> filegen clockstats file clockstats type day enable
>> filegen loopstats file loopstats type day enable
>> filegen peerstats file peerstats type day enable
>
> OK, done:
>
>
> cd /var/log
> mkdir ntp
>
> cd /etc
> nano /etc/ntp.conf
>
> Seems to be talking to the unit:
> http://www.A7H.com/~stuph/clockstats-Edited-2010-Jan-1-1300.txt
>
> Nothing in peerstats or loopstats showing anything Oncore-GPS related.
>
communicating via the RS-232 port on your PC. Do you know for sure if
your GT+ has a valid almanac? When you connect to your Oncore using
WinOncore12 under the Navigation window, does the receiver status show
that it has a 'bad almanac'? Whenever switching mine from NMEA to
Motorola protocol, I have to reload the almanac and re-enter the
receiver information using the pushbuttons on the top. They all seem to
init themselves in the NMEA mode, but require some manual intervention
when switching to Motorola Binary. Does the status show the number of
satellites in view and are most of them 'tracked'?
> Oncore GT+: does it need a pulse stretcher?
>
None of mine ever needed any pulse stretching.
Another item to note, when NTP initializes your Oncore, does the PPS LED
stop blinking? Mine stops until the other peers get synced and then the
Oncore driver sends the receiver command to start polling sequence for
the time. I guess this is to allow the receiver to initialize, check
the almanac for validity and then put the receiver in the '0D' Mode.
About 10 minutes after restarting NTP, my PPS LED starts blinking again.
I see that you have a 'real' serial port, this is good.
There is a wealth of information on the TAPR website including the
Motorola manuals that give meaning to all of those @@x commands. Having
those manuals and using WinOncore has allowed me to get all of my
problems resolved.
xyz-2041
shape or form. I bought a DB9 LED tester like this:
<http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260546635257>
Had PPS going to pin 1, DATA OUT to pin 2, and DATA IN to pin 3.
Still
no good.
Bought a Garmin GPS 25-LVC, put it in an enclosure, commented
out the Oncore driver and added to ntp.conf:
# Garmin / PPS driver:
server 127.127.20.0 prefer
fudge 127.127.20.0 refid GPS
Restarted:
/etc/rc.d/ntpd restart
Checking the status:
# ntpq -c pe
remote refid st t when poll reach delay
offset jitter
==========================================================
xGPS_NMEA(0) .GPS. 0 l 15 64 377 0.000
-716.52 105.934
Looks like it is being read, but is off by quite a bit. Any ideas on
how
to get it to behave?
David J Taylor
with an offset of -716ms, NTP is unlikely to sync to it. Any chance that
you are syncing to the wrong edge of the PPS signal, and that you need to
use one of the fudge settings to invert the polarity?
http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
"flag2 0 | 1
If PPS signal processing is enabled, capture the pulse on the rising
edge if 0 (default); capture on the falling edge if 1. "
Just a suggestion.
Good luck,
David
David Lord
For my gps18x-LVC I have following config:
tos orphan 10
tos mindist 0.4 # I could reduce this now
server 127.127.20.0 mode 1 prefer
fudge 127.127.20.0 time1 0.651 refid GPSb
server 127.127.22.0 minpoll 4 maxpoll 6
fudge 127.127.22.0 refid PPSb flag3 1
server serv1
server serv2
server serv3
ntpq -p me6000
remote refid poll reach offset jitter
+GPS_NMEA(0) .GPSb. 64 377 -12.625 21.361
oPPS(0) .PPSb. 16 377 0.002 0.002
serv1 64 377 0.039 0.660
serv2 64 377 -0.532 0.513
serv3 64 377 -2.486 0.639
Note the GPS_NMEA is all over place. I only just changed to
above config (looks to be giving lower PPS offset/jitter) and
restarted ntpd but yesterday with almost same config
peer_summary has:
ident cnt mean rms max
127.127.22.0 5238 0.003 0.031 0.066
127.127.20.0 1339 8.017 21.307 92.970
David
David Lord
Might be useful to install and run gpsd. The debug mode
is useful. Also worth trying that with your Oncore as
you stated upthread having had that working from windows.
Also outputs from /var/log/ntp/ntp.log (or wherever you
log to) and ntpd lines in /var/log/messages might give
some help.
David
Thomas Laus
> OK. Couldn't get the Oncore unit to work in any way
> shape or form. I bought a DB9 LED tester like this:
>
> <http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260546635257>
>
> Had PPS going to pin 1, DATA OUT to pin 2, and DATA IN to pin 3.
> Still
> no good.
>
tester LED's flicker as expected? Was there data passing in both
directions from and to the computer? Was the PPS LED flashing one time
per second?
Your previous post to this group stated that your Oncore was working
with the Motorola WinOncore utility. Did the observed satellites ever
show 'Locked' in the display? The last time that I had to re-initialize
an Oncore, I found that the almanac file that shipped with WinOncore was
too old to be of any use with the current constellation. My Oncores
seem to grab a new almanac quicker when placed in the NMEA mode. I let
my receiver run until all satellites in view showed lock status and then
saved the almanac to a disk file. I reinitialized my receiver in the
Motorola binary mode and loaded the new almanac that was just saved.
The receiver showed that it was locked within about 5 minutes. Once it
was working correctly using the Motorola binary protocol, I connected it
to my FreeBSD time server and restarted NTPD. Everything worked as
expected.
xyz-2041
Tried Garmin software to try to talk to the unit on a
Windows box:
<https://buy.garmin.com/shop/store/downloadsUpdates.jsp?
product=010-00124-00&cID=170&pID=70>
None of these 3 programs worked.
Tried MS Hyperterminal. No good.
Tried RealTerm (<http://realterm.sourceforge.net/>). Got to see
the messages once I got it working at 4800. RealTerm shows
the dataflow just like a breakout box. Saw that it is *not* sending
PPS on pin 1. Just sending messages on pin 2.
Tried to send a message to change to 9600, and turn PPS on.
Ignored messages because of improper syntax. Needs
proper checksum.
Does anyone know of software that actually works with this
unit?
David Lord
> Thanks for your responses, guys. Will reply in the future.
>
> Tried Garmin software to try to talk to the unit on a
> Windows box:
>
> <https://buy.garmin.com/shop/store/downloadsUpdates.jsp?
> product=010-00124-00&cID=170&pID=70>
>
> None of these 3 programs worked.
>
> Tried MS Hyperterminal. No good.
>
> Tried RealTerm (<http://realterm.sourceforge.net/>). Got to see
> the messages once I got it working at 4800. RealTerm shows
> the dataflow just like a breakout box. Saw that it is *not* sending
> PPS on pin 1. Just sending messages on pin 2.
What sentences is it sending NMEA or binary?
How do you have the unit wired to the serial port?
The JST has pins 1-12 1=TxD2 2=RxD2 3=PPS 4=TxD1 5=TxD2
6=PD 7=AuxBat 8=GND 9/10=3.6 to 6V 11=nc 12=NMEA-out(cmos)
You need to check on below, it's best I can work out
ie JSTpin D9pin
3 --------- 1
4 --------- 2
5 --------- 3
8 ---+----- 5
|
+---- 0V
10 -------- +3.6 to +6V
CMOS generated RS232 levels should be ok but depends on
serial port of your pc. PPS out to DCD is given as 700mVp-p
into 50r so will need converting to rs232.
> Tried to send a message to change to 9600, and turn PPS on.
> Ignored messages because of improper syntax. Needs
> proper checksum.
I have a gwbasic program for working out required messages.
GPSD will do it for you. Garmin site also have a windows
utility for generating required commands with checksum.
>
> Does anyone know of software that actually works with this
> unit?
GPSD?
David
David Lord
Going back to your previous reply I can see NMEA driver
looks to be working ok and you just need to trim out
the offset. GPSD + SHM driver might work ok for this
without PPS to give you about 10ms offset or with PPS
any of GPSD + SHM, NMEA or NMEA + ATOM should get you
in low us range for offset.
David
xyz-2041
Changed back to the Oncore:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# GPS Oncore driver
# server 127.127.30.0 prefer
server 127.127.30.0
fudge 127.127.30.0 refid GPSo
# PPS driver:
server 127.127.22.0 prefer
fudge 127.127.22.0 refid PPS
# Generic NMEA GPS Receiver:
# server 127.127.20.0
# fudge 127.127.20.0 time1 0.752 refid NMEA
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pin 1 = PPS (Light is blinking once per second
for about 200 ms)
Pin 2 = Data: GPS -> PC (Light blinks once per second--after pin 1--
for about 300-400 ms)
Pin 3 = Data: PC -> GPS
Pin 5 = Ground
Installed:
pkg_info | grep gpsd
gpsd-2.90 Daemon that monitors one or more GPSes attached to
a host c
# ls -lta /dev | grep cua
crw-rw---- 1 uucp dialer 0, 41 Feb 15 00:33 cuad0
lrwxr-xr-x 1 root wheel 5 Feb 14 15:42 gps0 -> cuad0
lrwxr-xr-x 1 root wheel 5 Feb 14 15:42 oncore.pps.0 -
> cuad0
lrwxr-xr-x 1 root wheel 5 Feb 14 15:42 oncore.serial.
0 -> cuad0
lrwxr-xr-x 1 root wheel 5 Feb 14 15:42 pps0 -> cuad0
lrwxr-xr-x 1 root wheel 5 Feb 14 15:42 refclock-0 ->
cuad0
crw-rw---- 1 uucp dialer 0, 42 Feb 14 15:42 cuad0.init
crw-rw---- 1 uucp dialer 0, 43 Feb 14 15:42 cuad0.lock
gpsd outputs nothing at all:
# /usr/local/sbin/gpsd /dev/cuad0
#
# /usr/local/bin/gpscat -s 9600N1 /dev/cuad0
Get some HEX output once per second:
\x08'\xa2\x03\x08#\xa2\x06\x00\x00 \x08\x081\xa2\x17\x00\x00\x00\x1c
\x00\x00\x00\x08*
@@Ea\x02\x0f\x07\xda\x004+\x00\x02\xea\xb1\x08\xce,\xbf\xec>
\x0f0\x00\x00N\xb3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
remote refid st t when poll reach delay
offset jitter
==============================================================================
...
GPS_ONCORE(0) .GPSo. 0 l - 16 0 0.000
0.000 0.001
PPS(0) .PPS. 0 l - 64 0 0.000
0.000 0.001
How can it be getting data on the serial port but NTP
can't seem to see it?
David Lord
Wrong baud rate and/or Oncore set to a config that
gpsd doesn't support?
If it still works from Windows is it possible to reset
to defaults that are supported by gpsd or NMEA drivers.
David
Thomas Laus
thing to keep in mind is that the serial baudrate changes from 9600 when
defaulted in Motorola binary to 4800 when defaulted in the NMEA mode.
Is gpsd looking for Motorola binary protocol or NMEA sentences? The HEX
output that you are seeing when you look at /dev/cuad0 tells me that
your Oncore is sending Motorola binary.
>>
>> # /usr/local/sbin/gpsd /dev/cuad0
>> #
>>
>>
>> # /usr/local/bin/gpscat -s 9600N1 /dev/cuad0
>>
>> Get some HEX output once per second:
>>
>> \x08'\xa2\x03\x08#\xa2\x06\x00\x00 \x08\x081\xa2\x17\x00\x00\x00\x1c
>> \x00\x00\x00\x08*
>> @@Ea\x02\x0f\x07\xda\x004+\x00\x02\xea\xb1\x08\xce,\xbf\xec>
>> \x0f0\x00\x00N\xb3\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01
>>
The \0x08'\.... is not in my book. The \@@Ea\xa2\x03\.... line is a position
status message in Motorola binary. It is sending month, day, year,
hours, minutes, seconds, fractional seconds. The rest of the line is
supposed to show your position (latitude followed by longitude). Your
message seems to be showing zero's. I would guess that your receiver has
not yet found itself. The Oncore driver executes a receiver self test
when started and then looks for a position and a valid almanac. It will
put the receiver in the 'site survey' mode for about 2 hours to get an
idea of your antenna current position. The receiver will wait for a
valid almanac before starting the site survey. If your /ntp/oncore file
has a mode statement and the results of a previous site survey, the
receiver only requires a valid almanac before ntp uses it for a
reference. This could take 30 minutes if there isn't one in your
receiver. The latest development version of the ntp software is a lot
more verbose than the released version. All of the Oncore startup
events are now sent to the syslog. You can see when the self test is
complete and when it grabs the almanac and completes the self survey.
Reg Clements has done a good job in making the Oncore driver send more
reports for receiver problem troubleshooting.
xyz-2041
> receiver. The latest development version of the ntp software is a lot
> more verbose than the released version.
Installed:
15 Feb 14:37:36 ntpd[680]: ntpd 4.2....@1.2108-o Mon Feb 15 20:10:40
UTC 2010 (1)
No reach:
remote refid st t when poll reach delay
offset jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
0.000 0.000
PPS(0) .PPS. 0 l - 64 0 0.000
0.000 0.000
>All of the Oncore startup
> events are now sent to the syslog.
# find / -name "syslog"
#
Where is that? Something to set up?
Dave Baxter
@d27g2000yqn.googlegroups.com>, xyz...@gmail.com says...
Try Garmin's "Sensor Config" software, for the GPS25 series, found at:-
http://www8.garmin.com/support/collection.jsp?product=010-00124-00
or
https://buy.garmin.com/shop/store/downloadsUpdates.jsp?product=010-
00124-00&cID=170&pID=70
Get the SNSRXCFG program, and read it's instructions. Or the earlier
SNSRCFG program, if it supports your device.
The SNSRCFG_320.exe program for the GPS16's I have, does also list the
GPS25 series as a base model it supports.
I'm sure if you dig arround Garmin's site, you'll find what you need.
If not, let me know.
Regards.
Dave Baxter.
E-Mail Sent to this address will be added to the BlackLists
>> All of the Oncore startup
>> events are now sent to the syslog.
>
> # find / -name "syslog"
> #
>
> Where is that? Something to set up?
In windows?
eventvwr.exe
Application
properties (Application) -> filter: Event Source (NTP)
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
Dave Hart
> xyz-2041 wrote:
> >> All of the Oncore startup
> >> events are now sent to the syslog.
>
> > # find / -name "syslog"
> > #
Pretty spectacular.
> > Where is that? Something to set up?
>
> In windows?
>
> eventvwr.exe
Stunning.
Next up: recompiling your Windows kernel for the ultimate experience!
Cheers,
Dave Hart
xyz-2041
BlackLists <N...@BlackList.Anitech-Systems.invalid> wrote:
> xyz-2041 wrote:
> >> All of the Oncore startup
> >> events are now sent to the syslog.
>
> > # find / -name "syslog"
> > #
>
> > Where is that? Something to set up?
>
> In windows?
I was hoping for some insight on "syslog"
on FreeBSD.
Does "syslog" send data anywhere else than ntp.log or ntpd.log?
>
> eventvwr.exe
>
> Application
>
> properties (Application) -> filter: Event Source (NTP)
>
> --
> E-Mail Sent to this address <BlackL...@Anitech-Systems.com>
David Lord
> On Feb 15, 3:29 pm, E-Mail Sent to this address will be added to the
> BlackLists <N...@BlackList.Anitech-Systems.invalid> wrote:
>> xyz-2041 wrote:
>>>> All of the Oncore startup
>>>> events are now sent to the syslog.
>>> # find / -name "syslog"
>>> #
>>> Where is that? Something to set up?
>> In windows?
>
> I was hoping for some insight on "syslog"
> on FreeBSD.
>
> Does "syslog" send data anywhere else than ntp.log or ntpd.log?
>
Look in /etc
ls -l /etc | grep "log"
Sorry I've forgotten where in FreeBSD, on NetBSD it's
syslog.conf for what/where logged and newsyslog.conf for
log rotation.
David
Dave Hart
> I was hoping for some insight on "syslog"
> on FreeBSD.
"man syslog.conf"
> Does "syslog" send data anywhere else than ntp.log or ntpd.log?
If you've configured a log file for ntpd (using -l/--logfile or the
ntp.conf "logfile" directive) ntpd switches from logging to syslog to
the configured logfile during startup. The switch happens a little
earlier with ntpd -l/--logfile vs. ntp.conf.
Cheers,
Dave Hart
Thomas Laus
> On Feb 15, 9:03?am, Thomas Laus <lau...@acm.org> wrote:
>
>> receiver. ?The latest development version of the ntp software is a lot
>> more verbose than the released version. ?
>
> Installed:
>
> 15 Feb 14:37:36 ntpd[680]: ntpd 4.2....@1.2108-o Mon Feb 15 20:10:40
> UTC 2010 (1)
>
> No reach:
> remote refid st t when poll reach delay
> offset jitter
>==============================================================================
> GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> 0.000 0.000
> PPS(0) .PPS. 0 l - 64 0 0.000
> 0.000 0.000
>
>
>
>>All of the Oncore startup
>
> # find / -name "syslog"
> #
>
> Where is that? Something to set up?
>
don't otherwise have a home. It gets displayed when you read the contents
of '/var/log/messages'.
E-Mail Sent to this address will be added to the BlackLists
> anonymous wrote:
>> xyz-2041 wrote:
>>>> All of the Oncore startup
>>>> events are now sent to the syslog.
>>
>>> # find / -name "syslog"
>>> #
>
> Pretty spectacular.
>
>>> Where is that? Something to set up?
>>
>> In windows?
>>
>> eventvwr.exe
>
> Stunning.
>
> Next up: recompiling your Windows kernel for the ultimate experience!
Doesn't everyone wish.
(Shrug)
I saw the
xyz-2041 wrote:
> Plugged in the GPS unit's serial cable into a Windows
> computer running WinOncore12 v1.0 (Build 37) ...
> Seemed to work without any problems.
> Generated all sort of graphs and charts...
> Does anyone have any idea what I might check next?
Guessed that might be what he was looking for,
since it is different from /etc/syslog.conf, /etc/rsyslog.conf
/var/adm/messages, /var/log/messages,
tail -f /var/adm/messages, ...
Then again perhaps he meant the
/etc/ntp.oncore
STATUS /var/log/ntp/ONCORE
(Shrug)
David Woolley
> The system log "syslog" is the default destination for all event logs that
> don't otherwise have a home. It gets displayed when you read the contents
> of '/var/log/messages'.
The actual log files depend on the exact variant of Unix and are
configurable. By default, some syslog events are not logged at all, and
some may go to other files.
However, this is all Unix Junior System Administration 101, and the
existence of syslogd ought to be well known to anyone trying to install
ntpd on a Unix-like system.
xyz-2041
> On 2010-02-15, xyz-2041 <xyz2...@gmail.com> wrote:
>
> > On Feb 15, 9:03?am, Thomas Laus <lau...@acm.org> wrote:
>
> >> receiver. ?The latest development version of the ntp software is a lot
> >> more verbose than the released version. ?
>
> > Installed:
>
> > UTC 2010 (1)
>
> > No reach:
> > remote refid st t when poll reach delay
> > offset jitter
> >==============================================================================
> > GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> > 0.000 0.000
> > PPS(0) .PPS. 0 l - 64 0 0.000
> > 0.000 0.000
>
> >>All of the Oncore startup
> >> events are now sent to the syslog. ?
>
> > # find / -name "syslog"
> > #
>
> > Where is that? Something to set up?
>
> The system log "syslog" is the default destination for all event logs that
> don't otherwise have a home. It gets displayed when you read the contents
> of '/var/log/messages'.
>
> Tom
>
> --
> Public Keys:
> PGP KeyID = 0x5F22FDC1
> GnuPG KeyID = 0x620836CF
Thanks, Tom and guys. I really appreciate your help!
Looks like something is going on with the Oncore:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ntpq -c pe
remote refid st t when poll reach delay
offset jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
0.000 0.000
xPPS(0) .PPS. 0 l 11 64 377 0.000
-3.085 0.017
192.168.2.255 .BCST. 16 u - 64 0 0.000
0.000 0.001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ntpq -c rv
assID=0 status=0615 leap_none, sync_ntp, 1 event, event_clock_reset,
version="ntpd 4.2....@1.2108-o Mon Feb 15 20:10:40 UTC 2010 (1)",
processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
precision=-20, rootdelay=44.827, rootdisp=44.339, refid=192.43.244.18,
reftime=cf25709c.1130eea8 Tue, Feb 16 2010 13:29:32.067,
clock=cf257657.3d54896e Tue, Feb 16 2010 13:53:59.239, peer=54924,
tc=10, mintc=3, offset=-4.877, frequency=-49.876, sys_jitter=1.658,
clk_jitter=2.179, clk_wander=0.056
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"precision=-20" how does one interpret this?
Why wouldn't the PPS be taken as preferred?
/var/log/ntp/clockstats:
http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-16.txt
Contained in /etc/ntp.conf:
Thomas Laus
One note about your configuration, I don't think that you can
have two 'prefer' statements. It was discussed recently in this
newsgroup and my memory of recent events is not as good as it used to
be. Try restarting your Oncore without the pps driver. Mine seems to
see the receiver pps without having that statement in my /etc/ntp.conf
file. It still looks like your Oncore receiver is not seeing the data
being requested by the ntp refclock driver. Can you post the Oncore
related lines of your syslog? The driver does a lot of setup work after
a restart and the results are sent to the log. It may provide some
insight into what is happening. Your Oncore pps on the DCD pin is doing
something, but the rest of the data is still not getting seen by the
daemon. Precision of -20 is what I see on my setup.
xyz-2041
> On 2010-02-16, xyz-2041 <xyz2...@gmail.com> wrote:
>
> > Thanks, Tom and guys. I really appreciate your help!
>
> > Looks like something is going on with the Oncore:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > # ntpq -c pe
> > remote refid st t when poll reach delay
> > offset jitter
> >==============================================================================
> > GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> > 0.000 0.000
> > xPPS(0) .PPS. 0 l 11 64 377 0.000
> > -3.085 0.017
> > 192.168.2.255 .BCST. 16 u - 64 0 0.000
> > 0.000 0.001
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > # ntpq -c rv
> > assID=0 status=0615 leap_none, sync_ntp, 1 event, event_clock_reset,
> > processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
> > precision=-20, rootdelay=44.827, rootdisp=44.339, refid=192.43.244.18,
> > reftime=cf25709c.1130eea8 Tue, Feb 16 2010 13:29:32.067,
> > clock=cf257657.3d54896e Tue, Feb 16 2010 13:53:59.239, peer=54924,
> > tc=10, mintc=3, offset=-4.877, frequency=-49.876, sys_jitter=1.658,
> > clk_jitter=2.179, clk_wander=0.056
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> > "precision=-20" how does one interpret this?
>
> > Why wouldn't the PPS be taken as preferred?
>
> > /var/log/ntp/clockstats:
> >http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-16.txt
>
> > Contained in /etc/ntp.conf:
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > # GPS Oncore driver
> > # server 127.127.30.0 prefer
>
> One note about your configuration, I don't think that you can
> have two 'prefer' statements. It was discussed recently in this
> newsgroup and my memory of recent events is not as good as it used to
> be.
Right. Commented one of them out--shown in previous post.
> Try restarting your Oncore without the pps driver. Mine seems to
> see the receiver pps without having that statement in my /etc/ntp.conf
> file.
OK. Edited:
# GPS Oncore driver
# server 127.127.30.0 prefer
server 127.127.30.0 prefer
fudge 127.127.30.0 refid GPSo
# PPS driver:
# server 127.127.22.0 prefer
# fudge 127.127.22.0 refid PPS
# Generic NMEA GPS Receiver:
# server 127.127.20.0
# fudge 127.127.20.0 time1 0.752 refid NMEA
and restarted:
/etc/rc.d/ntpd restart
# ntpq -c pe
remote refid st t when poll reach delay
offset jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
0.000 0.000
192.168.2.255 .BCST. 16 u - 64 0 0.000
0.000 0.001
# ntpq -c rv
assID=0 status=0615 leap_none, sync_ntp, 1 event, event_clock_reset,
version="ntpd 4.2....@1.2108-o Mon Feb 15 20:10:40 UTC 2010 (1)",
processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=2,
precision=-20, rootdelay=48.985, rootdisp=7.101, refid=68.248.203.43,
reftime=cf269d00.775aa0dc Wed, Feb 17 2010 10:51:12.466,
clock=cf269d18.be4e82f0 Wed, Feb 17 2010 10:51:36.743, peer=1901,
tc=7,
mintc=3, offset=-2.549, frequency=-50.209, sys_jitter=1.232,
clk_jitter=2.539, clk_wander=0.020
> It still looks like your Oncore receiver is not seeing the data
> being requested by the ntp refclock driver. Can you post the Oncore
> related lines of your syslog?
OK. Did yesterday:
http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-16.txt
This is today's output:
http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-17--1025.txt
> The driver does a lot of setup work after
> a restart and the results are sent to the log. It may provide some
> insight into what is happening. Your Oncore pps on the DCD pin is doing
> something, but the rest of the data is still not getting seen by the
> daemon.
I wonder why that is. Is there some kind of tool to look at
the raw output in FreeBSD command line mode? No X-windows
on this box.
>Precision of -20 is what I see on my setup.
What does this mean exactly?
Thanks again for your help, Tom.
Thomas Laus
>
> OK. Did yesterday:
> http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-16.txt
>
> This is today's output:
> http://www.a7h.com/~stuph/var--log--ntp--clockstats-2010-Feb-17--1025.txt
>
>
complaints about your serial port. This is mine:
FreeBSD 7.3-PRERELEASE (MAIL) #2: Sat Feb 13 12:33:25 EST 2010
This is the contents of my /etc/devfs.conf:
SSH Secure Shell 3.2.9 (Build 283)
Copyright (c) 2000-2003 SSH Communications Security Corp -
http://www.ssh.com/
This copy of SSH Secure Shell is a non-commercial version.
This version does not include PKI and PKCS #11 functionality.
Last login: Wed Feb 17 2010 12:31:50 -0500 from laust2
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 7.3-PRERELEASE (MAIL) #2: Sat Feb 13 12:33:25 EST 2010
Welcome to FreeBSD!
These are the Oncore related entries in my syslog:
iFeb 13 18:29:48 mail ntpd[536]: ntpd 4.2...@1.2122-o Mon Jan 4 14:52:18 UTC 2010 (1)
Feb 13 18:29:48 mail ntpd[537]: proto: precision = 1.117 usec
Feb 13 18:29:50 mail ntpd[537]: ONCORE[0]: ONCORE DRIVER -- CONFIGURING
Feb 13 18:29:50 mail ntpd[537]: ONCORE[0]: state = ONCORE_NO_IDEA
Feb 13 18:29:50 mail ntpd[537]: ONCORE[0]: ONCORE: Can't open SHMEM file
Feb 13 18:29:50 mail ntpd[537]: ONCORE[0]: ONCORE: Can't open shmem
Feb 13 18:29:50 mail ntpd[537]: ONCORE[0]: state = ONCORE_CHECK_ID
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: @@Cj
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: COPYRIGHT 1991-1996 MOTOROLAINC.
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: SFTW P/N # 98-P36830P
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: SOFTWARE VER # 8
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: SOFTWARE REV # 8
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: SOFTWARE DATE 06 Aug 1996
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: MODEL # B4121Z1115
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: HDWR P/N # _
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: SERIAL # SSG0228726
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: MANUFACTUR DATE 7E22
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: OPTIONS LIST IBC
Feb 13 18:29:51 mail ntpd[537]: ONCORE[0]: state = ONCORE_CHECK_CHAN
Feb 13 18:29:54 mail ntpd[537]: ONCORE[0]: state = ONCORE_HAVE_CHAN
Feb 13 18:29:55 mail ntpd[537]: ONCORE[0]: Oncore: Resend @@Cj
Feb 13 18:29:55 mail ntpd[537]: ONCORE[0]: state = ONCORE_TEST_SENT
Feb 13 18:30:03 mail ntpd[537]: ONCORE[0]: GPS antenna: OK
Feb 13 18:30:03 mail ntpd[537]: ONCORE[0]: state = ONCORE_INIT
Feb 13 18:30:11 mail ntpd[537]: ONCORE[0]: Oncore: Resend @@Cj
Feb 13 18:30:11 mail ntpd[537]: ONCORE[0]: state = ONCORE_ALMANAC
Feb 13 18:30:13 mail ntpd[537]: ONCORE[0]: Bd: Almanac LOADED, week =35, t = 36, 30 SVs: fefffffe
Feb 13 18:30:16 mail ntpd[537]: ONCORE[0]: Have now loaded an ALMANAC
Feb 13 18:30:16 mail ntpd[537]: ONCORE[0]: state = ONCORE_RUN
Feb 13 18:30:16 mail ntpd[537]: ONCORE[0]: SSstate = ONCORE_SS_DONE
Feb 13 18:30:16 mail ntpd[537]: ONCORE[0]: ONCORE: Detected TRAIM, TRAIM= ON
Feb 13 18:38:53 mail ntpd[537]: ONCORE[0]: Set peer.leap toLEAP_NOWARNING
Feb 13 19:08:53 mail ntpd[537]: ONCORE[0]: Set peer.leap toLEAP_NOWARNING
Feb 13 20:04:11 mail ntpd[537]: ONCORE[0]: Bd: Almanac LOADED, week =35, t = 57, 30 SVs: fefffffe
> I wonder why that is. Is there some kind of tool to look at
> the raw output in FreeBSD command line mode? No X-windows
> on this box.
>
The entries in your log indicate that you are communicating with your
Oncore receiver. It sees the firmware information very well. The
message:
55242 74297.142 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp,error serial pps
Seems to be indicating a problem in your serial interface. Are you
using an interface board to connect your Oncore TTL signals to RS-232?
I use one of the TAPR boards for that purpose. Your tester shows data
being sent on all appropriate pins because all LED's are blinking.
Right now, I am stumped! Someone with more knowledge is welcome to
chime into this discussion.
>
>>Precision of -20 is what I see on my setup.
>
> What does this mean exactly?
>
From the NTP Project documentation page:
In NTP precision is determined automatically, and it is measured as a
power of two. For example when ntpq -c rl prints precision=-16, the
precision is about 15 microseconds (2^-16 s).
It looks like yours and my NTP clocks are good to 2^-20s.
xyz-2041
> The entries in your log indicate that you are communicating with your
> Oncore receiver. It sees the firmware information very well. The
> message:
>
> 55242 74297.142 127.127.30.0 ONCORE[0]: ONCORE: oncore_get_timestamp,error serial pps
>
> Seems to be indicating a problem in your serial interface. Are you
> using an interface board to connect your Oncore TTL signals to RS-232?
> I use one of the TAPR boards for that purpose. Your tester shows data
> being sent on all appropriate pins because all LED's are blinking.
> Right now, I am stumped! Someone with more knowledge is welcome to
> chime into this discussion.
Thanks Tom, et. al. for helping me get this going.
The box is now running as Stratum 1.
The problem apparently was the serial port on the
Gigabyte motherboard. It started working properly
after ordering and installing a PCI card:
I ordered this from Buy.com:
<http://www.buy.com/prod/cables-unlimited-1-port-db9-serial-
netmos-9820-chipset-pci-i-o-card-1/q/loc/101/207595862.html>
Cables Unlimited 1 Port DB9 Serial Netmos 9820 PCI
<http://www.google.com/products?q=Cables+Unlimited+1+Port+DB9+Serial
+Netmos+9820+PCI&scoring=p>
But I was sent this with the MOSchip MCS9865:
http://www.google.com/products?q=SY-PCI15003
Found this driver:
http://www.google.com/#q=MCS9865_V1.0.0.1.tar.gz
<http://forums.freebsd.org/attachment.php?
attachmentid=506&d=1259682366>
Compiled:
cd /usr/src/sys/dev/uart
mkdir MosChip-9865
cd MosChip-9865
tar xvzf MCS9865_V1.0.0.1.tar.gz
cd MCS9865_V1.0.0.1
ls -lta
total 158
drwxr-xr-x 3 root wheel 512 Feb 27 15:50 ..
drwxr-xr-x 2 root kalauser 512 Oct 25 23:59 MCS9865_isa
drwxr-xr-x 2 root kalauser 512 Oct 25 23:59 MCS9865_parallel
drwxr-xr-x 5 root kalauser 512 Oct 25 23:58 .
-rwxr-xr-x 1 root 500 365 Oct 22 07:25 ReleaseNotes
drwxr-xr-x 2 root kalauser 512 Oct 22 07:18 MCS9865_serial
-r-x--x--x 1 root kalauser 148140 Oct 13 06:37 minicom
cd MCS9865_serial
make
make ld
cd /usr/src/sys/dev/uart/MosChip-9865/MCS9865_V1.0.0.1/
MCS9865_serial
kldload -v ./mcs9865_uart.ko
Loaded ./mcs9865_uart.ko, id=3
cp -p mcs9865_uart.ko /boot/modules
cd /boot
cp -p loader.conf loader.1.bak.conf
nano loader.conf
# mcs9865_uart.ko
mcs9865_uart_load="YES"
shutdown -r now
ls -lta /dev | grep cua
Found a "cuau4" even though I was expecting "cuad1".
Why is that?
Edited /etc/devfs.conf:
cd /etc
nano devfs.conf
# Links for NTP Oncore GPS 0
link cuad0 pps0
link cuad0 oncore.pps.0
link cuad0 oncore.serial.0
# Links for NTP Oncore GPS 1
link cuau4 pps1
link cuau4 oncore.pps.1
link cuau4 oncore.serial.1
Rebooted:
shutdown -r now
On reboot ntpd gave the following error:
"ONCORE[0]: Oncore: No response from @@Cj,
shutting down driver"
This is reasonable since there is nothing
connected to that port.
It took about half and hour or so, but NTP
recognized the Oncore unit and is now running
as Stratum 1:
# ntpq -c pe
remote refid st t when poll reach delay
offset jitter
==============================================================================
GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
0.000 0.000
PPS(0) .PPS. 0 l - 64 0 0.000
0.000 0.000
oGPS_ONCORE(1) .GPS. 0 l 5 16 377 0.000
-0.001 0.002
xPPS(1) .PPS. 0 l 53 64 377 0.000
-0.001 0.002
192.168.2.255 .BCST. 16 u - 64 0 0.000
0.000 0.002
# ntpq -c rv
assID=0 status=0415 leap_none, sync_uhf_clock, 1 event,
event_clock_reset,
version="ntpd 4.2....@1.2108-o Mon Feb 15 20:10:40 UTC 2010 (1)",
processor="i386", system="FreeBSD/7.2-RELEASE", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=0.282, refid=GPS,
reftime=cf3fbf58.24220c39 Mon, Mar 8 2010 12:24:24.141,
clock=cf3fbf5a.525eaae2 Mon, Mar 8 2010 12:24:26.321, peer=56242,
tc=4, mintc=3, offset=-0.001, frequency=-49.760, sys_jitter=0.002,
clk_jitter=0.002, clk_wander=0.000
Thanks again, Tom and guys. I hope this
documentation helps the next guy having
problems--especially with a bogus serial port.
xyz-2041
# mcs9865_uart.ko
mcs9865_uart_load="YES"
shutdown -r now
Edited /etc/devfs.conf:
cd /etc
nano devfs.conf
# Links for NTP Oncore GPS(0)
link cuad0 pps0
link cuad0 oncore.pps.0
link cuad0 oncore.serial.0
# Links for NTP Oncore GPS(1)
link cuau4 pps1
link cuau4 oncore.pps.1
link cuau4 oncore.serial.1
Edited /etc/ntp.conf:
cd /etc
cp -p ntp.conf ntp.5.bak.conf
nano ntp.conf
Added a 2nd group:
# GPS Oncore driver 0
server 127.127.30.0
fudge 127.127.30.0 refid GPS0
# PPS driver:
server 127.127.22.0
fudge 127.127.22.0 refid PPS0
# GPS Oncore driver 1
server 127.127.30.1
fudge 127.127.30.1 refid GPS1
# PPS driver:
server 127.127.22.1 prefer
fudge 127.127.22.1 refid PPS1
Rebooted:
shutdown -r now
On reboot ntpd gave the following error:
"ONCORE[0]: Oncore: No response from @@Cj,
shutting down driver"
This is reasonable since there is nothing
connected to that port.
It took about half an hour or so, but NTP
problems with a serial port.
Thomas Laus
> The box is now running as Stratum 1.
>
> link cuad0 pps0
> link cuad0 oncore.pps.0
> link cuad0 oncore.serial.0
>
>
> # GPS Oncore driver 0
> server 127.127.30.0
> fudge 127.127.30.0 refid GPS0
>
> # PPS driver:
> server 127.127.22.0
> fudge 127.127.22.0 refid PPS0
>
> remote refid st t when poll reach delay
> offset jitter
>==============================================================================
> GPS_ONCORE(0) .GPS. 0 l - 16 0 0.000
> 0.000 0.000
> PPS(0) .PPS. 0 l - 64 0 0.000
> 0.000 0.000
> oGPS_ONCORE(1) .GPS. 0 l 5 16 377 0.000
> -0.001 0.002
> xPPS(1) .PPS. 0 l 53 64 377 0.000
> -0.001 0.002
> 192.168.2.255 .BCST. 16 u - 64 0 0.000
> 0.000 0.002
>
installation. They both show a '0' in the reach column. This means
that NTP is not using either of those two devices for timekeeping. You
can delete them from your configuration files. You are also not getting
any benefit from your broadcast client. There are many references in
the NTP Documenatiuon about broadcast client configuration, especially
in the area of authentication and key exchange. I hope that you also
include some Internet timeservers in your installation to check the
sanity of your GPS clock. The recomendation is to have at least 4 time
sources, including your GPS clock. That lets the majority outvote a
'falseticker'.
xyz-2041
Hi Tom,
>
> The Oncore 0 andPPS0 entries are not doing anything for your ntp
> installation. They both show a '0' in the reach column. This means
> that NTP is not using either of those two devices for timekeeping. You
> can delete them from your configuration files.
Yeppers. I think I'll leave them there to remind me of that
bad serial port.
>You are also not getting
> any benefit from your broadcast client.
Hmmm. I use it to keep my other FreeBSD and Windows
boxes in sync. Seems to be working for me.
>There are many references in
> the NTP Documenatiuon about broadcast client configuration, especially
> in the area of authentication and key exchange.
Yep. It's only broadcasting to my Local Area Network. I
figure if they get inside my firewall, timekeeping would be
the least of my worries.
>I hope that you also
> include some Internet timeservers in your installation to check the
> sanity of yourGPSclock. The recomendation is to have at least 4 time
> sources, including yourGPSclock. That lets the majority outvote a
> 'falseticker'.
Yeppers, again. I did forget to mention that I have other
Stratum 1 servers that I use for that very purpose.
>
> Tom
Thanks, again.