M9N for gpsd/chrony on Raspberry Pi 4

Hello everyone,

at the moment, I am trying to setup gpsd/chrony on the a Raspberry 4 Model B (running Raspian GNU/Linux 10 (buster)) with a Sparkfun M9N board (U.FL connector version) for accurate timing following this tutorial here primarily (https://austinsnerdythings.com/2021/04/ … d-pps-gps/), with some adjustments like for initial baudrate.

I connected the M9N using the GPIO-pins as follows:

M9N ---------- RPi

GND ---------- GND (Pin 6)

5V ---------- 5V (Pin 2)

RX/MOSI ---- TXD (Pin 8 / GPIO 14)

TX/MISO ---- RXD (Pin 10 / GPIO 15)

PPS ---------- Pin 12 / GPIO 18

I did not run the “sudo raspi-update” command in the tutorial, due to the advice not to use it as a regular update process. I did change the raspi-config disabling the console over serial option. Also I did change the init_uart_baud to 38400 in the /boot/config.txt because this is what u-center used to connect to the M9N over a FTDI-converter.

The setup does not run as expected, even though I was able to get the lon/lat displayed when running “cgps”, also I got the expected reply when running “sudo ppstest /dev/pps0”. Looking at the serial-port using “cat /dev/ttyS0” shows the funniest signs, but not NMEA messages, even though in u-center the monitor does display NMEA messages.

I tried by connecting a receiver featuring a M6N-chip. This setup (kind of - the GPS reception and accuracy leaves much to be desired in the tested location) worked with a gps-receiver of type M6N of which I know it sends NMEA messages and a baudrate of 9600. Chrony also accepted the NMEA as the timing source, even though it never seemed not to accept the pps as a source.

I hope the information is comprehensive enough for you to give me a pointer what to try next. At this point I am out of ideas and really appreciate your help.

Kind regards,

Sebastian

I have the same problem.

Is there any solutions?

Best regards

Hi EsKay/Mephilius, this is Austin from the blog. I saw a couple hits come from this forum and decided to investigate and found this post so I made an account. There could be a couple things going on here. I’m assuming gpsmon shows valid position data like CGPS does? The newer u-Blox modules in combination with GPSd will utilize the binary u-Blox protocol instead of NMEA. I suspect that’s what’s happening. Things to verify:

1 - does gpsmon show relevant position data for the M9N? If so, that’s a big step.

2 - GPSd more or less auto negotiates baud rate - try not setting it in /boot/config.txt (funny characters/signs in a serial stream are almost always a baud rate mismatch)

3 - I just looked up the SparkFun M9N board. if it is the one with USB (https://www.sparkfun.com/products/17285) use the USB as the main source (which will be converted to a serial stream). It’s a lot faster and easier than straight serial. You can still use the PPS output. I did something similar with a GT-U7 GPS module (I believe it is u-Blox 6 based, but with USB output) - https://austinsnerdythings.com/2021/09/ … or-12-usd/. Just the NMEA sentences over USB (via 57600 baud “serial”) I found will get you to +/- 5 milliseconds. I’ll be posting a youtube video of this soon.

4 - the fact that a M6N chip works more or less as expected but the M9N doesn’t further points to a protocol/baud mismatch. NMEA over 9600 baud is pretty bad for timing purposes. I’m not surprised it wasn’t selected as a timing source.

Hope this helps. I’ll monitor this thread for replies. Also feel free to post a comment on my blog post. If this next step of troubleshooting doesn’t get you anywhere, I’ll reply with my email and we can communicate directly.