GPSDO+PC as a NTP server
Hi!
I just bought my first GPSDO (BG7TBL dated 2019-08-03 with Trimble 73090
and u-blox 7 series GPS chip – more info here:
https://www.eevblog.com/forum/testgear/bg7tbl-gpsdo-master-reference/msg2749310/#msg2749310).
I intend to connect it to a PC and use it as NTP and maybe PTP server, and
additionally share the 1PPS signal directly to additional computers in the
same room (max 2 more). I would like to know about best practices of doing
this project.
-
The GPS chip onboard can be set via RS232C, for instance by u-center
program. I currently set stationary mode, disabled SBAS, 3D fix mode only,
minimum elevation 20 degrees, position and time accuracy masks of 40
meters, C/No threshold 20 dbHz. All of this filters out some satellites
and increases DOP, but my understanding is it also removes some errors and
makes the GPS more suitable for timing? Unfortunately, this chip can only
use only 1 constellation of satellites at once. The question here is then:
is it better to have less precise, high DOP fix or more precise fix that
can be absent from time to time? I guess the precision of OCXO disciplined
by GPS is an overkill anyway for my intended use. -
I would like to get both NMEA and PPS signal from it on the NTP server.
Currently PPS is on pin 8 (CTS) but according to
http://doc.ntp.org/4.1.1/driver22.htm and
https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
rather be on pin 1 (DCD). Is it possible to use it anyway on Linux NTP
servers, or is it better to split it to 2 different COM ports – one for
NMEA, second for PPS? Or maybe is it better to use PPS from BNCs or get
some additional device and use 10MHz signal? -
I'm thinking of using Linux as the NTP server with recompiled kernel
options for some better precision. But maybe there is a Linux/FreeBSD/other
system distribution prepared especially for NTP servers? I will probably
install additional Intel i210 network card for future PTP usage.
Do you have any other suggestions for the hardware/software of NTP server?
Thank you all in advance,
Adam Kumiszcza
I also have a BG7TBL, version 2019-03-25, and I use it with a small
embedded X64_64 pcengines box with a dedicated mPCI RS232 receiver.
See picture attached, the PCENGINES box is the black box below the
GPSDO.
- The GPS chip onboard can be set via RS232C, for instance by u-center
program. I currently set stationary mode, disabled SBAS, 3D fix mode only,
minimum elevation 20 degrees, position and time accuracy masks of 40
meters, C/No threshold 20 dbHz. All of this filters out some satellites
and increases DOP, but my understanding is it also removes some errors and
makes the GPS more suitable for timing? Unfortunately, this chip can only
use only 1 constellation of satellites at once. The question here is then:
is it better to have less precise, high DOP fix or more precise fix that
can be absent from time to time?
GPS and GLONASS are the best GNSS around, they are operated by the
military as a military operation and have the best reliability record.
Beidu is fairly new, and Galileo is operated by civlian agencies.
They've had major operational issues. So this leaves GPS and GLONASS.
GLONASS tends to have better coverage on the polar regions, but
otherwise I think GPS is better, and GPS has better time and space
accuracy. Although I'm not that with the accuracy of RS232 interrupt
handling it would be possible to even tell the time differenbce.
between UTS(GPS) and UTC(GLONASS).
I'm not even sure than running GLONASS and GPS together will give you
a better time solution, although it will definitely improve
availability.
- I would like to get both NMEA and PPS signal from it on the NTP server.
Currently PPS is on pin 8 (CTS) but according to
http://doc.ntp.org/4.1.1/driver22.htm and
https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
rather be on pin 1 (DCD).
Well actually the PPS RFC https://tools.ietf.org/html/rfc2783
while referring to "DCD implementations for serial line" does not
specify at all which signals should be used. Which makes sense because
is PPS for parallel port as well. At any rate, I've seen that most
GPSDOs (including the two I have, BG7TBL and Oscilloquarts STAR 4) use
CTS, whereas the use of DCD typically applies for standalone GPS
receivers. There are two things you could one of these:
(1) build your own RS232 cable and hook the PPS signal from the GPSDO
db9 pin 8 (CTS) to the db9 pin 1 (DCD) on the other side.
(2) recompile the RS232 driver and swap DCD with CTS in Linux
(3) use FreeBSD instead, which supports runtime configuration of
either DCD or CTS for PPS
I use the latter, as I am big fan of FreeBSD
Is it possible to use it anyway on Linux NTP
servers, or is it better to split it to 2 different COM ports – one for
NMEA, second for PPS? Or maybe is it better to use PPS from BNCs or get
some additional device and use 10MHz signal?
Even if you are distributing the PPS signal you are still distributing
a clock with strict timing requirements. Clock termination is very
complex especially if you are distributing it. You are probably better
off at using either an RS232 buffer or a TTL buffer and have two
separate outputs. But you should probably seek other opinions here,
and I am not hugely familiar with the analog aspect of clock
distribution.
- I'm thinking of using Linux as the NTP server with recompiled kernel
options for some better precision. But maybe there is a Linux/FreeBSD/other
system distribution prepared especially for NTP servers?
As mentioned above, I am big fan of FreeBSD despite of -- or perhaps
because of -- having done kernel development on both. To answer your
specific question, there is no distro especially "tuned" to for NTP.
PPS support is standard on both. Which kernel, OS and distro you
should use is a matter of preference, unless you want to use FreeBSD's
already built-in runtime configuration for DCD/CTS support.
I will probably
install additional Intel i210 network card for future PTP usage.
This is a great idea. I've been thinking to do the same, provide both
NTP and PTP time services. Note that PTP can also be implemented with
a pure software stack, although you'll use hardware timestamping, and
so it'll be less accurate than a pure hardware solution.
Do you have any other suggestions for the hardware/software of NTP server?
My TOP recommendation would be to avoid using the PC's built COM
port, as many implementations rely internally on an ISA bus instead of
PCI, which has higher interrupt latencies. Personally I use a separate
RS232 port on PCI-e (PCI express), which also has the added advantage
of proving either 12V or 5V on the pin 9 RING signal, so you can use
it to directly power a GPS receiver like the Garmin 18 with serial
output.
I use this one for a PC:
https://cdn.cnetcontent.com/53/1c/531c2b50-18a9-416a-967b-2104530b205f.pdf
You can buy it on Amazon for about $35
If you decide to go to a smaller embedded box like PCENGINES, you can
use this mPCI RS232 card:
https://www.sybausa.com/index.php?route=product/product&path=64_77_189_81&product_id=719
Another advantage is that these chipsets typically support higher baud
rates (which I hope translate into higher rise time detection for
DCD/CTS) as well as accepting TIA-RS232-F signalling, which is to say
TTL signals with 0V = false, 5V = true. One of the other stratum-1
servers I have uses one of these cards with the Garmin 18x LVC, which
outputs TIA-RS32-F signals.
The biggest problem for using RS232 for PPS input is interrupt
latency. Generally speaking it is in the order of approximately 10
microseconds (from PPS signal assertion to the kernel's interrupt
handler which records the pps event). I just modified the UART driver
in FreeBSD to support PPS_ECHOASSERT and PPS_ECHOCLEAR. Right after
recording the timestamp the interrupt handler echoes DCD to DTR, or
CTS to RTS, depending on how CTS/DCD is configured. This be used to
get an accurate measure of the interrupt latency. You will still have
interrupt latency jitter, but you can at least eliminate the delay.
I just wrote the code and tested it with an RS232 led dongle. I'm
going to then use the oscilloscope to measure my interrupt latency.
Even though I haven't done this yet, I'll happily share the source
code. I'd just need to put in my github repo.
Bets of luck :-)
Thank you all in advance,
Adam Kumiszcza
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
From: Fiorenzo Cattaneo
[]
GPS and GLONASS are the best GNSS around, they are operated by the
military as a military operation and have the best reliability record.
Beidu is fairly new, and Galileo is operated by civlian agencies.
They've had major operational issues. So this leaves GPS and GLONASS.
GLONASS tends to have better coverage on the polar regions, but
otherwise I think GPS is better, and GPS has better time and space
accuracy. Although I'm not that with the accuracy of RS232 interrupt
handling it would be possible to even tell the time differenbce.
between UTS(GPS) and UTC(GLONASS).
I'm not even sure than running GLONASS and GPS together will give you
a better time solution, although it will definitely improve
availability.
---======
GPS, GLONASS and Galileo have /all/ had operational difficulties, and
possibly BeiDou too. For precision timekeeping Galileo has the best
on-board sources, but using GPS and Galileo is perhaps the best combination
of accuracy and reliability. The offset between GPS time and UTC, and
Galileo time and UTC is regularly reported (possibly in the satellite feed
itself). It's nanoseconds, and very unlikely to affect a system using a PPS
signal from a typical amateur cost source.
I think you underrate Galileo, certainly in suggesting GLONASS above
Galileo.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6308660/
https://www.itnews.com.au/news/satellite-failure-caused-global-gps-timing-anomaly-414237
https://www.theverge.com/2019/7/15/20694395/europe-galileo-satellite-navigation-system-offline-outage-technical-incident
Cheers,
David
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
Hi
The “ideal” solution (at least to me) would be a setup that let you estimate the time based
on each system independently. Even things like survey locations vary a bit system to system.
Give each one the “fix” that it thinks is best and go from there. Then report the output PPS time
offset for each of them. Let “higher authority” decide what to make of the results.
Taking this a step further, correction information is available real time for various systems. The
quality (and availability) of these streams is not 100%. The same “give it to me both ways”
approach likely makes sense there as well.
Redundancy is fine when you actually have independent outputs. Getting it all mashed together
in some unknown / hidden fashion …. yikes ….
Bob
On Oct 24, 2019, at 2:30 AM, David J Taylor via time-nuts time-nuts@lists.febo.com wrote:
From: Fiorenzo Cattaneo
[]
GPS and GLONASS are the best GNSS around, they are operated by the
military as a military operation and have the best reliability record.
Beidu is fairly new, and Galileo is operated by civlian agencies.
They've had major operational issues. So this leaves GPS and GLONASS.
GLONASS tends to have better coverage on the polar regions, but
otherwise I think GPS is better, and GPS has better time and space
accuracy. Although I'm not that with the accuracy of RS232 interrupt
handling it would be possible to even tell the time differenbce.
between UTS(GPS) and UTC(GLONASS).
I'm not even sure than running GLONASS and GPS together will give you
a better time solution, although it will definitely improve
availability.
---======
GPS, GLONASS and Galileo have /all/ had operational difficulties, and possibly BeiDou too. For precision timekeeping Galileo has the best on-board sources, but using GPS and Galileo is perhaps the best combination of accuracy and reliability. The offset between GPS time and UTC, and Galileo time and UTC is regularly reported (possibly in the satellite feed itself). It's nanoseconds, and very unlikely to affect a system using a PPS signal from a typical amateur cost source.
I think you underrate Galileo, certainly in suggesting GLONASS above Galileo.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6308660/
https://www.itnews.com.au/news/satellite-failure-caused-global-gps-timing-anomaly-414237
https://www.theverge.com/2019/7/15/20694395/europe-galileo-satellite-navigation-system-offline-outage-technical-incident
Cheers,
David
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
Twitter: @gm8arv
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Bob wrote:
The “ideal” solution (at least to me) would be a setup that let you estimate the time based
on each system independently. Even things like survey locations vary a bit system to system.
Give each one the “fix” that it thinks is best and go from there. Then report the output PPS time
offset for each of them. Let “higher authority” decide what to make of the results.
Well, heck, if you can count on divine guidance, what do you need the
GPSDOs for? ;-)
Best regards,
Charles
Hi!
Thanks for all the responses. As I wrote, the chip can use only 1
constellation, and I'm not sure it can use Galileo at all, so I'm sticking
to GPS only. As I understand it, GPS errors here smooth out anyway while
disciplining internal OCXO, so it's not so important to have the best chip
available. I guess u-blox zed-f9t with a bad ocxo would be worse than
normal u-blox 7 with a better ocxo? I intend to run it 24h/day BTW.
As for FreeBSD, I like this system a lot, too. Especially for proper native
ZFS support. I use it mainly for NAS now, but experimented with different
versions before, so I guess I'll go this route. Does Lady Heather compile
on FreeBSD? And is it possible to run it together with NTP for the same
rs232 port? I found this:
https://www.febo.com/pipermail/time-nuts/2010-February/044476.html – but
it's for thunderbolt and at "very early, rough stage". I would like to
attach a small monitor and have LH run there constantly.
BTW, Fiorenzo Cattaneo, I did not get the picture of your set with
pcengines box. Probably got cut by mailing list.
Best regards,
Adam Kumiszcza
On Fri, Oct 25, 2019 at 2:01 AM Charles Steinmetz csteinmetz@yandex.com
wrote:
Bob wrote:
The “ideal” solution (at least to me) would be a setup that let you
estimate the time based
on each system independently. Even things like survey locations vary a
bit system to system.
Give each one the “fix” that it thinks is best and go from there. Then
report the output PPS time
offset for each of them. Let “higher authority” decide what to make of
the results.
Well, heck, if you can count on divine guidance, what do you need the
GPSDOs for? ;-)
Best regards,
Charles
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
Hi
There are a number of GPS errors that turn into “long period” disturbances. A normal
OCXO (even a good one) runs with a fast enough loop that they do appear in the output
of the GPSDO. One (of many) sources of this sort of error is the 12/24 hour cyclical nature
of GPS orbits. Another is the 24 hour cycle the ionosphere goes through …..
Bob
On Oct 25, 2019, at 2:09 AM, Adam Kumiszcza akumiszcza@gmail.com wrote:
Hi!
Thanks for all the responses. As I wrote, the chip can use only 1
constellation, and I'm not sure it can use Galileo at all, so I'm sticking
to GPS only. As I understand it, GPS errors here smooth out anyway while
disciplining internal OCXO, so it's not so important to have the best chip
available. I guess u-blox zed-f9t with a bad ocxo would be worse than
normal u-blox 7 with a better ocxo? I intend to run it 24h/day BTW.
As for FreeBSD, I like this system a lot, too. Especially for proper native
ZFS support. I use it mainly for NAS now, but experimented with different
versions before, so I guess I'll go this route. Does Lady Heather compile
on FreeBSD? And is it possible to run it together with NTP for the same
rs232 port? I found this:
https://www.febo.com/pipermail/time-nuts/2010-February/044476.html – but
it's for thunderbolt and at "very early, rough stage". I would like to
attach a small monitor and have LH run there constantly.
BTW, Fiorenzo Cattaneo, I did not get the picture of your set with
pcengines box. Probably got cut by mailing list.
Best regards,
Adam Kumiszcza
On Fri, Oct 25, 2019 at 2:01 AM Charles Steinmetz csteinmetz@yandex.com
wrote:
Bob wrote:
The “ideal” solution (at least to me) would be a setup that let you
estimate the time based
on each system independently. Even things like survey locations vary a
bit system to system.
Give each one the “fix” that it thinks is best and go from there. Then
report the output PPS time
offset for each of them. Let “higher authority” decide what to make of
the results.
Well, heck, if you can count on divine guidance, what do you need the
GPSDOs for? ;-)
Best regards,
Charles
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.
HI again!
On Wed, Oct 23, 2019 at 9:37 PM Fiorenzo Cattaneo fio@cattaneo.us wrote:
- I would like to get both NMEA and PPS signal from it on the NTP
server.
Currently PPS is on pin 8 (CTS) but according to
http://doc.ntp.org/4.1.1/driver22.htm and
https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
rather be on pin 1 (DCD).
[...]
(3) use FreeBSD instead, which supports runtime configuration of
either DCD or CTS for PPS
I use the latter, as I am big fan of FreeBSD
I'm trying to make it work on FreeBSD.
I put hint.uart.0.flags="0x10000" in /boot/device.hints as per
https://www.freebsd.org/cgi/man.cgi?query=sio&sektion=4 (0x10000 PPS
timestamping on CTS instead of DCD).
I recompiled the kernel with PPS support.
My devfs.conf has the following:
link cuau0 gps0
link cuau0 refclock-0
link cuau0 pps0
But I still don't seem to get PPS (no "o" in ntpq -np). Which driver do you
use? 127.127.22.0 or 127.127.20.0 or both? I'm only able to use 22.0, which
is GPS_NMEA, but on some webpages it's the only one mentioned after
discussing PPS.
Thanks in advance,
Adam Kumiszcza
Hmm that is odd. I haven't seen the sio man page, I refer and use the directions in uart man page
https://www.freebsd.org/cgi/man.cgi?query=uart&sektion=4&manpath=freebsd-release-ports
And set this sysctl variable in /boot/loader.conf (note that the uart man page is also wrong, you can only set pps_mode for specific devices and not for all devices):
dev.uart.0.pps_mode=0x10
To test it without having to reboot, use sysctl command.
Maybe the sio feature has been added recently, IDK, I still use FreeBSD kernel 11.1. What I know for sure is that the sysctl is actually implemented in the code -- see uart_core.c source.
For ntp.conf, I only use the NMEA refclock #20. I always had trouble with the PPS refclock #22.
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
The entry is something like this:
Server 127.127.20.0 mode 17 flag1 1
Mode 17 tells ntpd to process RMC only and use 9600 bps. Default is 4800 bps. If you want to process all supported sentences at 9600 bps, use mode 16.
Flag1 tells ntpd to use PPS. Default is no PPS.
I also set max poll to 4.
If you are still having trouble, you can troubleshoot like this:
- set boot verbose mode in loader.conf, it will print the actual UART pps configuration.
- use cu first to double check that you are using the correct line at the correct speed, for instance:
cu -l /dev/gps0 -s 9600
If you see NMEA sentences correctly, then you know you have the correct device at 9600bps - download, build and run ppstest program to make sure PPS is setup correctly.
If you see NMEA sentences, but you don't see PPS, there are two possibilities (1) PPS capture is still set to the default DCD (2) PPS output from GPS receiver is disabled. The latter should not be the case with the GPSDO.
good luck!
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
On Oct 30, 2019, at 02:02, Adam Kumiszcza akumiszcza@gmail.com wrote:
HI again!
On Wed, Oct 23, 2019 at 9:37 PM Fiorenzo Cattaneo fio@cattaneo.us wrote:
- I would like to get both NMEA and PPS signal from it on the NTP server.
Currently PPS is on pin 8 (CTS) but according to
http://doc.ntp.org/4.1.1/driver22.htm and
https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
rather be on pin 1 (DCD).
[...]
(3) use FreeBSD instead, which supports runtime configuration of
either DCD or CTS for PPS
I use the latter, as I am big fan of FreeBSD
I'm trying to make it work on FreeBSD.
I put hint.uart.0.flags="0x10000" in /boot/device.hints as per https://www.freebsd.org/cgi/man.cgi?query=sio&sektion=4 (0x10000 PPS timestamping on CTS instead of DCD).
I recompiled the kernel with PPS support.
My devfs.conf has the following:
link cuau0 gps0
link cuau0 refclock-0
link cuau0 pps0
But I still don't seem to get PPS (no "o" in ntpq -np). Which driver do you use? 127.127.22.0 or 127.127.20.0 or both? I'm only able to use 22.0, which is GPS_NMEA, but on some webpages it's the only one mentioned after discussing PPS.
Thanks in advance,
Adam Kumiszcza
My ntp.conf was very similar:
server 127.127.20.0 mode 17 minpoll 4 maxpoll 4 prefer
fudge 127.127.20.0 flag1 1 flag3 1 time2 0.15698
Are you sure flag1 comes after server, not fudge? It gives me syntax error
in /var/log/messages. Time2 calculated experimentally by the awk script.
ntpq -c kerninfo
associd=0 status=042d leap_none, sync_uhf_radio, 2 events, kern,
pll offset: 2.54041
pll frequency: -65.3446
maximum error: 7.453
estimated error: 0.2
kernel status: pll ppsfreq ppstime nano
pll time constant: 4
precision: 0.001
frequency tolerance: 495.911
pps frequency: -65.153
pps stability: 0
pps jitter: 0.000
calibration interval 4
calibration cycles: 0
jitter exceeded: 0
stability exceeded: 0
calibration errors: 0
As you can see, pps data looks broken. No calibration.
"cu -l /dev/gps0 -s 9600" gives me proper NMEA
I could not find ppstest for FreeBSD (pps-tools), but I compiled ppsapitest
(https://github.com/freebsd/freebsd/tree/master/tools/test/ppsapi).
kenv hint.uart.0.flags="0x10"
./ppsapitest -v /dev/cuau0
Supported modebits: CAPTUREASSERT CAPTURECLEAR OFFSETASSERT OFFSETCLEAR
CANWAIT TSPEC
^C
root@gpsdo:~/ppsapitest # sysctl dev.uart.0.pps_mode=0x01
dev.uart.0.pps_mode: 0 -> 1
root@gpsdo:~/ppsapitest # ./ppsapitest -v /dev/cuau0
Supported modebits: CAPTUREASSERT CAPTURECLEAR OFFSETASSERT OFFSETCLEAR
CANWAIT TSPEC
1572471715 .999207702 8 1572471715 .050547992 8
1572471715 .999207702 8 1572471716 .050923133 9
1572471716 .998764118 9 1572471716 .050923133 9
1572471716 .998764118 9 1572471717 .051208066 10
1572471717 .999071162 10 1572471717 .051208066 10
ntpq -p
remote refid st t when poll reach delay offset
jitter
---============
oGPS_NMEA(0) .GPS. 0 l 1 16 377 0.000 0.001
0.010
*192.168.0.200 80.50.231.226 2 u 12 64 7 0.064 1.272
0.010
pool.ntp.org .POOL. 16 p - 64 0 0.000 0.000
0.000
ntp2.tktelekom. 80.50.231.226 2 u 10 64 7 34.972 5.244
0.614
ntp.wide-net.pl 194.146.251.101 2 u 6 64 7 85.966 -2.331
0.223
ntp2.pl 194.146.251.101 2 u 8 64 7 23.816 1.304
0.997
162.159.200.123 10.73.8.83 3 u 8 64 7 42.993 -7.413
1.570
162.159.200.1 10.73.8.83 3 u 4 64 7 43.889 -6.966
0.912
SunSITE.icm.edu 210.100.177.101 2 u 4 64 7 34.776 4.662
7.338
46.175.224.7.ma 193.106.216.30 3 u 1 64 7 49.671 -0.098
1.377
ip-159-253-242- 194.146.251.100 2 u 6 64 3 38.582 6.277
1.151
old.histeria.pl 212.160.106.226 2 u 4 64 3 30.292 1.609
1.325
afrodyta.comple 210.100.177.101 2 u - 64 3 33.259 2.214
1.533
ntpq -c kerninfo
associd=0 status=041d leap_none, sync_uhf_radio, 1 event, kern,
pll offset: 0.009016
pll frequency: -63.8877
maximum error: 941.687
estimated error: 0.003
kernel status: pll ppsfreq ppstime ppssignal nano
pll time constant: 4
precision: 0.001
frequency tolerance: 495.911
pps frequency: -63.8877
pps stability: 0.342499
pps jitter: 0.001
calibration interval 32
calibration cycles: 17
jitter exceeded: 1
stability exceeded: 0
calibration errors: 2
As you can see, pps data appeared and I have my "o" in front of GPS_NMEA!
:) I did not change ntp.conf, time2 offset is now ignored, I guess.
Offset and jitter from ntpq -crv after less than an hour now is even lower
than my Raspberry Pi with better gps chip and running non stop, but I need
more testing, of course.
Thank you again for your help! dev.uart.0.pps_mode=0x01 did wonders.
Adam Kumiszcza
On Wed, Oct 30, 2019 at 9:01 PM Fiorenzo Cattaneo fio@cattaneo.us wrote:
Hmm that is odd. I haven't seen the sio man page, I refer and use the
directions in uart man page
https://www.freebsd.org/cgi/man.cgi?query=uart&sektion=4&manpath=freebsd-release-ports
And set this sysctl variable in /boot/loader.conf (note that the uart man
page is also wrong, you can only set pps_mode for specific devices and not
for all devices):
dev.uart.0.pps_mode=0x10
To test it without having to reboot, use sysctl command.
Maybe the sio feature has been added recently, IDK, I still use FreeBSD
kernel 11.1. What I know for sure is that the sysctl is actually
implemented in the code -- see uart_core.c source.
For ntp.conf, I only use the NMEA refclock #20. I always had trouble with
the PPS refclock #22.
https://www.eecis.udel.edu/~mills/ntp/html/drivers/driver20.html
The entry is something like this:
Server 127.127.20.0 mode 17 flag1 1
Mode 17 tells ntpd to process RMC only and use 9600 bps. Default is 4800
bps. If you want to process all supported sentences at 9600 bps, use mode
16.
Flag1 tells ntpd to use PPS. Default is no PPS.
I also set max poll to 4.
If you are still having trouble, you can troubleshoot like this:
- set boot verbose mode in loader.conf, it will print the actual UART pps
configuration. - use cu first to double check that you are using the correct line at the
correct speed, for instance:
cu -l /dev/gps0 -s 9600
If you see NMEA sentences correctly, then you know you have the correct
device at 9600bps - download, build and run ppstest program to make sure PPS is setup
correctly.
If you see NMEA sentences, but you don't see PPS, there are two
possibilities (1) PPS capture is still set to the default DCD (2) PPS
output from GPS receiver is disabled. The latter should not be the case
with the GPSDO.
good luck!
-- Fio Cattaneo
Universal AC, can Entropy be reversed? -- "THERE IS AS YET
INSUFFICIENT DATA FOR A MEANINGFUL ANSWER."
On Oct 30, 2019, at 02:02, Adam Kumiszcza akumiszcza@gmail.com wrote:
HI again!
On Wed, Oct 23, 2019 at 9:37 PM Fiorenzo Cattaneo fio@cattaneo.us wrote:
- I would like to get both NMEA and PPS signal from it on the NTP
server.
Currently PPS is on pin 8 (CTS) but according to
http://doc.ntp.org/4.1.1/driver22.htm and
https://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html it should
rather be on pin 1 (DCD).
[...]
(3) use FreeBSD instead, which supports runtime configuration of
either DCD or CTS for PPS
I use the latter, as I am big fan of FreeBSD
I'm trying to make it work on FreeBSD.
I put hint.uart.0.flags="0x10000" in /boot/device.hints as per
https://www.freebsd.org/cgi/man.cgi?query=sio&sektion=4 (0x10000 PPS
timestamping on CTS instead of DCD).
I recompiled the kernel with PPS support.
My devfs.conf has the following:
link cuau0 gps0
link cuau0 refclock-0
link cuau0 pps0
But I still don't seem to get PPS (no "o" in ntpq -np). Which driver do
you use? 127.127.22.0 or 127.127.20.0 or both? I'm only able to use 22.0,
which is GPS_NMEA, but on some webpages it's the only one mentioned after
discussing PPS.
Thanks in advance,
Adam Kumiszcza