I got the UART1 to work by adding
# UART to u-blox GNSS module
/dev/ttyS0 works, and I can receive NMEA data at 9600 baud.
Unfortunately, the Raspi UART docs explain that the baudrate of
ttyS0 is influenced by CPU core frequency, and it doesn’t work with default
core_freq=400. It is a bit unfortunate to have to sacrifice CPU performance for this UART to work.
Given that the GNSS module is connected to the FPGA already, it would be better to use another path to carry NMEA to the raspi and leave the core frequency at its default. Unless one is willing to solder the USB resistors (which I insist must be 27R and not 0R, as per my first post). It feels that my goal of using the GNSS module to discipline NTP got a bit more complicated…
But assuming running at the lower core frequency is acceptable, here’s how to do it:
gpsd. I disabled auto startup of gpsd because I couldn’t get it to work properly
sudo systemctl stop ntp
sudo systemctl disable gpsd
sudo systemctl disable gpsd.socket
sudo systemctl stop gpsd
sudo systemctl stop gpsd.socket
I added a udev rule to create a
/dev/gps0 symlink, because apparently that what NTP asks
/etc/ntp.conf, adding a driver 46 instance
server 127.127.46.0 mode 0 prefer
fudge 127.127.46.0 time1 0.0 time2 0.0 refid GPS
Ensure no gpsd is running, start it manually with
gpsd /dev/gps0, check with
cgps that it works, then start ntp. After a while, you should see it working:
remote refid st t when poll reach delay offset jitter
*GPSD_JSON(0) .GPS. 0 l 17 64 377 0.000 25.437 123.812
+smtp.irtech.ch 188.8.131.52 2 u 58 64 377 13.733 124.178 115.332
The fudge factors could be tweaked to remove some residual delay, but I’m not going to optimise it since I won’t use this approach. I hope this information can be useful to someone.
I’d be happy to add a note to the hw description wiki page (or on a more appropriate page) explaining how to use the GNSS UART from the CM3, but I don’t have an account. @andrewback Am I supposed to ask you?