Ah sorry you right. I wrote down the ntp.conf by memory and not by copy/pasting (I wasn’t home when I did it), your ntp.conf syntax is the correct one.

Looking at your post, I think the problem was that PPS was disabled outright. Looking at your post, I see:

Sysctl output shows that pps_mode was originally 0 before the change.

The bit values for pps_mode can be found in the include files sys/dev/uart/uart_ppstypes.h: 0x0 = disabled, 0x1 = pps_cts, 0x2 = pps_dcd, …..

Glad it’s working now, have fun with your GPSDO 😊

From: Adam Kumiszcza akumiszcza@gmail.com
Sent: Wednesday, 30 October, 2019 15:07
To: Fiorenzo Cattaneo fio@cattaneo.us; Discussion of precise time and frequency measurement time-nuts@lists.febo.com
Subject: Re: [time-nuts] GPSDO+PC as a NTP server

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 http://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 http://ntp.wide-net.pl  194.146.251.101  2 u    6  64    7  85.966  -2.331  0.223
ntp2.pl http://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 http://SunSITE.icm.edu  210.100.177.101  2 u    4  64    7  34.776    4.662  7.338
46.175.224.7.ma http://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 http://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 mailto: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 https://www.freebsd.org/cgi/man.cgi?query=uart&sektion=4&manpath=freebsd-release-ports &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 mailto:akumiszcza@gmail.com > wrote:



HI again!

On Wed, Oct 23, 2019 at 9:37 PM Fiorenzo Cattaneo <fio@cattaneo.us mailto:fio@cattaneo.us > wrote:

[...]

(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 https://www.freebsd.org/cgi/man.cgi?query=sio&sektion=4 &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

On Wed, 23 Oct 2019 12:37:24 -0700
Fiorenzo Cattaneo fio@cattaneo.us wrote:

Some organization being military or not does not matter when it comes
service quality. Unless you had been in the military, then you would
distrust anything that says "military grade"... but that's a different
story.

As far as reliability goes, Galileo is more reliable then GPS had
been in its early days. Of course, they have an easier job with todays
technology and lots of know-how available from maintaining satellite
systems. But considering that they only had one major incident, which
immediately flagged all satellites as faulty, it is actually quite good.
Compare this to GPS' 2016 incident, where the satellites weren't flagged
as unhealthy. Not to mention that this was caused by a known bug in
the controll software. The worst performer in terms of reliability
is GLONASS. After the fall of the iron curtain, the GLONASS system
went from full constellation of 24 satellites (just achieved in 1995)
to only 12 operational in 2008 (i.e. they couldn't even provide basic
service within all Russia, which requires 18 satellites). And that
was after the decree of 2001 to restore full operational status
of GLONASS by 2009! GLONASS has restored full constellation in
December 2015 and has been operating decently well, with a few
glitches here and there.

I don't know enough about Beidu to comment on it.

So, which one would I trust?
None :-)
Mistakes and accidents will always happen. If you build your system
with blind trust in any of the GNSS systems, you are likely to have
your system fail at some point in time. As always: any external system
input should always be validated and cross-checked.

In terms of received ground performance, Galileo has been outperforming
GLONASS for a few years already. And that even though they only have 20
fully operational satellites (instead of the 24 of the full constellation).
Full constellation for Galileo is planned for somewhen in 2021, after
which it will be the one system that provides the highest location and
time accuracy to civilian users. In terms of theoretical performance,
it will beat even the GPS Block III signals, which, most likely, will
not be fully available within the next decade. Whether this performance
is actually deliverd to the receivers, is yet to be seen, though.
For all practical purposes, my guess would be that with an E5/L5
single-band receiver, Galileo would outperform GPS slightly, due to
better multi-path supression (the much wider E5a+b signal helps with
that tremendously). For multi-band receivers, the difference is probably
insignificant. On E1/L1-only, both should perform the same.

The major issue with GLONASS is that it uses FDMA. This gives slight
offsets in terms of atmospheric delay and delays within the receiver.
Thus is the biggest source of performance degradation for GLONASS
(after multi-path and ionospheric) and is the reason why Galileo
has been the major reason why Galileo has been outperforming GLONASS
so quickly. There have been plans to change the GLONASS frequency
plan such that they also operate as CDMA system, but sofar there
is only a test signal on L3 (on top of E5b) and only from the
two GLONAS-K satellites. There are plans to extend the CDMA signal
to L1 and L2 with satellites launched by 2023, but I would not
hold my breath for those.

Combining different GNSS systems is known to improve performance.
But it is not easy to do it correctly.

		Attila Kinali

--
<JaberWorky> The bad part of Zurich is where the degenerates
throw DARK chocolate at you.