Sergio Ballestrero

An update with good news. After much messing around, I seem to have at least a workaround: using gpsd v3.25 I have built the latest upstream version 3.25 of gpsd, from the original sources at http://download-mirror.savannah.gnu.org/releases/gpsd/. It seems to do a better job at auto-detection of the GPS module, trying more combinations of serial port settings and possibly being more forgiving of communication errors. And it does that even if you've set the port speed (like stty -F /dev/ttyS1 9600), as long as you don't enforce the --speed option of gpsd. I did try also a rebuild of gpsd v3.22, but it behaved identically to the Debian package v3.22, nothing unexpected there. Then, using gpsd v3.25, I was able to get the correct identification as u-blox, and to use ubxtool root@orangepizero3-01:~# gpsctl /dev/ttyS1 /dev/ttyS1 identified as a u-blox SW ROM CORE 3.01 (107888),HW 00080000 at 9600 baud. root@orangepizero3-01:~# ubxtool -p CFG-PRT ::/dev/ttyS1 | grep -m1 --after-context=30 UBX-CFG-PRT: | grep -m1 --before-context=30 '^$' UBX-CFG-PRT: PortID 1 (UART1) reserved1 0 txReady 0x0 mode 0x8c0 baudRate 9600 inProtoMask 0x7 outProtoMask 0x3 flags 0x0 reserved2 0 inProtoMask (UBX NMEA RTCM2) outProtoMask (UBX NMEA) flags () With this I've been able to configure the GPS module for binary mode and 19200baud. After doing that, the module becomes reasonably stable even with the default gpsd v3.22, using the correct --speed 19200 option. In the end, I have not figured out why the serial UART on the OrangePi Zero 3 + Armbian does not work as well as on the RasPi4, and I'd still love it if someone had an explanation; but the above is enough to let things work well enough for me. And I hope it can help others running into the issue 😊

I'm trying to setup a GPS-based time server on an Orange PI Zero 3, running Armbian 24.8.0-trunk.495, kernel 6.6.43-current-sunxi64. I have the exact same hardware setup working fine on a RaspberryPI 4b, running RPI OS / Debian 11 (bullseye) , kernel 6.1.21-v8+ #1642. On the RPI4, gpsd recognises the (cheap chinese "M8N") GPS module as u-blox and keeps working in a stable way root@rpi4:~# gpsctl /dev/ttyS0 /dev/ttyS0 identified as a u-blox SW ROM CORE 3.01 (107888),HW 00080000 at 9600 baud. the /boot/config.txt has these two lines for the UART config enable_uart=1 init_uart_baud=9600 On the OPIZ3 I configured /boot/armbianEnv.txt for UART5; I didn't find any setting for the initial UART speed overlays=uart5-ph The resulting /dev/ttyS1 is mostly working but not really well. "gpsd --nowait --debug 1 --speed 9600 /dev/ttyS1" works, but it (usually) does not recognise the module as u-blox, and remains on the NMEA text protocol, meaning I can't use ubxtool. And it logs a constant stream of "bad checksum" and other errors, and disconnect/reconnect cycles, which aren't nice for the clock stability. root@orangepizero3-01:~# gpsctl /dev/ttyS1 /dev/ttyS1 identified as a NMEA0183 at 9600 baud. root@orangepizero3-01:~# journalctl -u gpsd ... Aug 12 18:57:49 orangepizero3-01.home gpsd[5223]: gpsd:WARN: bad checksum in NMEA packet; expected 23. Aug 12 18:57:49 orangepizero3-01.home gpsd[5223]: gpsd:WARN: NMEA0183: malformed GPGSV - fieldcount 19 % 4 != 0 ... Aug 12 18:57:53 orangepizero3-01.home gpsd[5223]: gpsd:WARN: bad checksum in NMEA packet; expected 2C. Aug 12 18:57:53 orangepizero3-01.home gpsd[5223]: gpsd:WARN: device read of /dev/ttyS1 returned error or packet sniffer failed sync (flags {ERROR}) Aug 12 18:57:53 orangepizero3-01.home gpsd_hook[10889]: start args: /dev/ttyS1 DEACTIVATE Aug 12 18:57:53 orangepizero3-01.home gpsd_hook[10893]: start args: /dev/ttyS1 ACTIVATE Aug 12 18:57:54 orangepizero3-01.home gpsd[5223]: gpsd:WARN: bad checksum in NMEA packet; expected 3C. ... Once in a while, seemingly randomly, restarting gpsd seems "lucky" and it does recognise the module as u-blox and for a while it's a bit more stable, using the binary UBX protocol, to fail again after some hours. So, I'm wondering if it's an issue with the OPIZ3 GPIO/UART, or with the Armbian kernel, or what. Has anybody seen the same or similar issue? Or if you have some suggestion on how to debug this (if possible without an oscilloscope), it would be much welcome. Cheers, Sergio