Debug NEO-M9N module on TimeHAT V2

[geerlingguy]

I received a newer TimeHAT kit to match the one shipping from Tindie, and instead of swapping that into my existing grandmaster Pi, I've upgraded the TimeHAT to the V4 model, but taken the M.2 NEO-M9N-OOB-00 (M2 NEO-M9N V3) board and inserted that into my TimeHAT V2.

However, I can't get any GPS data through it.

I've set the following in /boot/firmware/config.txt:

dtoverlay=pciex1-compat-pi5,mmio-hi
dtparam=uart0=on

I've removed console=serial0,115200 from /boot/firmware/cmdline.txt.

And I've installed the gpsd tooling. But if I ensure gpsd is stopped and the socket is gone, and I use gpsmon /dev/ttyAMA0, I get no output. Same with just listening to that socket, there's no raw data coming across at all.

I see the i226V on the TimeHAT V2, and I can set a manual IP address and force a 1 Gbps network connection, but I can't get packets to flow on there, even though the same HAT/i226 had worked on another Pi.

So far the only difference is the NEO-M9N (instead of the other board with the ZED-F9T), and using the included white non-impedance-matched PCIe FFC that was included with the TimeHAT V4 kit.

I may try swapping the PCIe FFC for one of my Pineboards ones, but it seems like that might only change things regarding the NIC, not the GPS modem. Unless it's a power issue?

[geerlingguy]

Ah... according to the NEO-M9N datasheet, default data rate (baud) is 38400.

I had it set to 115200, which seemed to work on the ZED-F9T. But maybe that was reconfigured because the ZED-F9T datasheet also mentions a 38400 baud default...

Finally, found on the Tindie page that I had to add a symlink:

sudo ln -s /dev/ttyAMA0 /dev/ttyS10

Testing that now.

[geerlingguy]

That works, but the symlink doesn't persist across reboots. So when I try running cgps I get nothing, until I quit out of there, run sudo ln -s /dev/ttyAMA0 /dev/ttyS10 again, then run sudo systemctl restart gpsd.

Then I get data through cgps:

[geerlingguy]

I'll add a script to do those things at boot. Seems like ttyAMA0 is working for me now, as long as I have the appropriate baud settings.

Now, after letting GPS run a while, I have a 3D fix, and I see the following in dmesg:

[  560.242275] pps_ldisc: PPS line discipline registered

However, the antenna is still indoors, and cgps -s is showing distance errors in the 15-30m range, along with time offsets around 0.12-0.15s. Thus, chrony seems to indicate it is an unreliable time:

pi@mini-time:~ $ chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#x GPS                           0   4   377    22   +179ms[ +174ms] +/- 1366us
^+ rn-03.koehn.com               2   7   377   128    +14ms[+3873us] +/-   45ms
^+ nu.binary.net                 2   7   377    69    +11ms[ +267us] +/-   52ms
^* time-h.den.codehof.net        2   6   377     1    -41ms[  -46ms] +/-   47ms
^+ 149.28.200.179.vultruser>     2   8   377     2  +8599us[+3819us] +/-   45ms

[geerlingguy]

Re-checking on the original Time Pi board, I see the ZED-F9T is set to 115200 baud. Looking if there's an easy way to configure the u-blox through the Pi itself so they can both use the same baud setting instead of having to break it out by host.

Would I have to use something like https://www.u-blox.com/en/product/u-center ?

[geerlingguy]

Might be possible to set the baud using ubxtool.

# Get the protocol version ('PROTVER')
ubxtool -p MON-VER
...
UBX-MON-VER:
  swVersion EXT CORE 4.04 (7f89f7)
  hwVersion 00190000
  extension ROM BASE 0x118B2060
  extension FWVER=SPG 4.04
  extension PROTVER=32.01
...

# Set the version in ubxtool options
export UBXOPTS="-P 32.01"

# Set the baud rate to 115200
ubxtool -S 115200

[geerlingguy]

That worked! But... after a reboot, it seems like I can't see it now with cgps -s, nor can I set the baud again:

$ ubxtool -S 115200
{"class":"ERROR","message":"Type of /dev/ttyAMA0 is unknown."}

I have to go back into /etc/default/gpsd and re-set the baud back to 38400, then I can use ubxtool again to change the baud back to 115200 again, then tweak and restart gpsd again.

How to get the baud setting to persist???

[geerlingguy]

Ah, a comment on this blog post on GPS/PPS/time on Pi that helped me find the fix to persist the data:

ubxtool -S 115200
ubxtool -p SAVE

Then change the /etc/default/gpsd file to use the new baud rate, and restart gpsd.

Verify the baud rate on PortID 1 / UART1:

$ ubxtool -p CFG-PRT
UBX-MON-VER:
  swVersion EXT CORE 4.04 (7f89f7)
  hwVersion 00190000
  extension ROM BASE 0x118B2060
  extension FWVER=SPG 4.04
  extension PROTVER=32.01
  extension MOD=NEO-M9N
  extension GPS;GLO;GAL;BDS
  extension SBAS;QZSS

UBX-CFG-PRT:
 PortID 1 (UART1) reserved1 0 txReady 0x0
  mode 0x8c0 baudRate 115200
  inProtoMask 0x3 outProtoMask 0x3
  flags 0x0 reserved2 0
    inProtoMask (UBX NMEA)
    outProtoMask (UBX NMEA)
    flags ()
...

After a reboot... it goes back to 38400.

So I'm not sure how to get the baud rate setting to persist in flash yet. Need to figure out the magical incantation.

[tim292stro]

You want to hit the UBX-CFG-CFG command, look at PDF page 56 of the Ublox M9 protocol document: https://content.u-blox.com/sites/default/files/u-blox-M9-SPG-4.04_InterfaceDescription_UBX-21022436.pdf?#page=56

Just walking through the gpsd/ubxtool source, it looks like the SAVE function has an optional flag for the target device, try:

ubxtool -s 115200
ubxtool -c SAVE -f devFlash

I've never done this kind of configuration outside of the Ublox u-Center, so take my syntax with a grain of salt.

[geerlingguy]

I'll try that later, thanks!

[unn]

I have to go back into /etc/default/gpsd and re-set the baud back to 38400, then I can use ubxtool again to change the baud back to 115200 again, then tweak and restart gpsd again.

While not ideal, this seems to work well enough to confirm the hat is installed and gps is connecting.

[geerlingguy]

devFlash was not found, but:

$ ubxtool -p MON-VER -P 32.01
UBX-MON-VER:
  swVersion EXT CORE 4.04 (7f89f7)
  hwVersion 00190000
  extension ROM BASE 0x118B2060
  extension FWVER=SPG 4.04
  extension PROTVER=32.01
  extension MOD=NEO-M9N
...

$ ubxtool -S 115200
$ ubxtool -p SAVE -P 32.01
$ ubxtool -p COLDBOOT -P 32.01

After the coldboot, it seem to restart the GPS module and was at the proper baud rate. But the true test is a power off/on cycle... doing that now.

[geerlingguy]

Yay! After a full system reboot, it seemed to persist the 115200 setting:

$ ubxtool -p CFG-PRT
UBX-CFG-PRT:
 PortID 1 (UART1) reserved1 0 txReady 0x0
  mode 0x8c0 baudRate 115200
  inProtoMask 0x23 outProtoMask 0x23
  flags 0x0 reserved2 0
    inProtoMask (UBX NMEA RTCM3)
    outProtoMask (UBX NMEA RTCM3)
    flags ()

[geerlingguy]

Added notes in the README directing people here if needed.