Unable to Receive GNSS data Using pygnssutils with ZED-F9P/F9H Modules

[amirt23]

First, thank you again for maintaining and actively updating this package. I truly appreciate the work that goes into it.

I'm currently facing an issue where I'm unable to receive valid location data from my GNSS modules using the pygnssutils ecosystem packages. I'm unsure whether this is due to a misconfiguration, a software/firmware mismatch, or a hardware fault.

Problem Description:

running the following command: gnssstreamer --port /dev/ttyACM0 --baudrate 9600 --timeout 5 --quitonerror 1 --protfilter 1 --msgfilter GNGGA
results in an "empty" NMEA message (see bellow), indicating that the antenna is not acquiring a fix. Similarly, using linux packages gpsd, and ubxtool coupled with and even a direct read via sudo cat /dev/ttyACM0 yields the same result.

<NMEA(GNGGA, time=, lat=, NS=, lon=, EW=, quality=0, numSV=0, HDOP=99.99, alt=, altUnit=, sep=, sepUnit=, diffAge=, diffStation=)>

Setup Details

Hardware:

1. MiniPC with Jetson Orin NX (JetPack 6.2.1)
2. GNSS Modules: Ublox ZED-F9P and ZED-F9H
3. Antenna with a clear line of sight to the sky (confirmed working on another machine)
4. Swapping antennas did not resolve the issue

Software Versions:

pygnssutils 1.1.20
pygpsclient 1.5.18
pynmeagps 1.0.55
pyqgc 0.1.2
pyrtcm 1.1.9
pysbf2 1.0.3
pyserial 3.5
pyspartn 1.0.8
pyubx2 1.2.59
pyubxutils 1.0.5

Firmware Info (via ubxtool -p MON-VER):

ZED-F9P:
swVersion: EXT CORE 1.00 (0fa0ae)
hwVersion: 00190000
FWVER: HPG 1.32
PROTVER: 27.31
GNSS: GPS;GLO;GAL;BDS;SBAS;QZSS

ZED-F9H:
swVersion: EXT CORE 1.00 (f10c36)
hwVersion: 00190000
FWVER: HDG 1.13
PROTVER: 31.12
GNSS: GPS;GLO;GAL;BDS;SBAS;QZSS

Both modules return UBX-NAV-RELPOSNED with all zero values and flags x0.

Additional Notes

• I had to run sudo stty -F /dev/ttyACM0 sane between cat and gnssstreamer calls to release the serial port, otherwise it remained locked.
• The antenna is confirmed to be functional on another system.
• Changing antennas did not help.
• The modules appear to be communicating, but no fix is acquired.

Before concluding that this is a hardware fault (e.g., damaged antenna port or GNSS module), I’d like to rule out any software, firmware, or configuration issues. Has anyone encountered a similar issue?

Could this be related to:

• A mismatch between firmware and Linux kernel/driver?
• Incorrect serial configuration, port handling or a wrong I/O parameters configuration for the zed-f9p module?
• A required GNSS initialization step I might be missing?

Any insights or suggestions would be greatly appreciated.

[semuadmin]

HI @amirt23 ,

I have no particular experience with Jetson Orin NX or JetPack 6, but assuming it behaves much like any other Debian-based Linux distro in this context, you just need to work the issue methodically. Here are a few observations:

1. Does your F9 have factory default settings (to the best of your knowledge)? Note that the default UART baudrate for most u-blox devices is 38400, not 9600. Have you tried using this default baud rate? There are any number of configuration settings on an F9 which, if non-default, could cause NMEA output to be 'empty' e.g. geofence mask, signal mask, satellite mask, output protocol filter. etc. etc.
2. Have you ensured that no other processes are running which might contend for the same serial port e.g. gpsd or ubxtool? THIS IS PROBABLY THE BIGGEST SINGLE CAUSE OF CONNECTION ISSUES ON LINUX PLATFORMS. You need to shut these utilities down altogether. If you're having to use stty -F /dev/ttyACM0, that suggests you may have a contention issue (though that wouldn't ordinarily explain why you're still receiving well-formed but 'empty' NMEA data).
3. Try using a different antenna and/or antenna connecting cable, if you have one available. This will eliminate any cabling issues. Out of interest, what type of antenna are you using? Does it need a ground plane (e.g. ANN-MB) and - if so - have you provided one?
4. Try testing the same GNSS device and antenna on another more conventional platform e.g. a Windows or Apple laptop? This will eliminate any host platform issues.
5. How are you physically connecting to the F9 module? Via UART or USB? Are you using any kind of UART-USB adapter (e.g. FTDI) or other intermediate device? Cheap adapters can be flaky.
6. Have you checked you have the correct privileges to access the /dev/ttyACM0 device on this platform? Typically you need to be a member of the dialout or tty groups on most Linux distros.
7. Obvious question, but how long have you waited to get a position fix? In adverse conditions this may take 15 minutes or more?

Try running gnssstreamer without the message filters and with maximum verbosity for a few seconds (having waited at least 15 mins for a fix) e.g.

gnssstreamer -P /dev/ttyACM0 --baudrate 38400 --timeout 5 --verbosity 3 > capture.txt

Cut and paste the contents of capture.txt into a follow-up comment and I'll take a look. My best guess would be a baudrate or serial port contention issue.

[amirt23]

Thank you so much for your quick response—I really appreciate it. I’ve been away from the setup for the past two days, so I wasn’t able to follow up earlier. I’ll run the tests you suggested over the next few days and share an update once I have the results.

[amirt23]

@semuadmin Thank you for your detailed suggestions. Following your questions, here’s what I’ve checked so far:

1. I believe that the default baud rate is 9600 for the zed-f9p, but regardless, I’ve tested all available baud rates (including 38400) without success.
2. I verified using lsof /dev/ttyACM0 that no other process beside gnssstreamer is holding that port.
3. I tested with two antennas — the 2J Medusa and the Taoglas Colosseum X Active. Both have integrated ground planes and don’t require external ones. Assuming that both antennas are not faulty suggests that cabling isn’t the issue.
4. Unfortunately, I don’t have direct access to the GNSS module itself. It’s embedded inside a rugged miniPC that I can’t open, so I’m unable to test the module on a different host machine.
5. For the same reason, I can’t confirm whether any adapter is used internally. From the host side, the module appears to be exposed via USB.
6. My user account is a member of the dialout group, so I should have the necessary privileges to access /dev/ttyACM0.
7. I’ve waited approximately ~10 minutes for a fix with no change.

I’ve attached the log file generated using the command you provided. Do you have any further direction or recommendations based on this output?

capture.txt

[semuadmin]

I believe that the default baud rate is 9600 for the zed-f9p

From the u-blox ZED-F9P Integration Manual section 3.8.1:

Your particular installation may be set to 9600, but this is not the default, which begs the question as to how many other settings may be non-default? 9600 is certainly sub-optimal for the F9P, especially if you're expecting to use RTK or PPP corrections, though I'm not necessarily suggesting that's the issue here. In any event I would strongly recommend increasing this to at least 115200.

Your capture.txt indicates that you are successfully receiving the standard cohort of NMEA sentences, but that you have no RF signal whatsoever? I'm afraid I'm at a loss to suggest why that might be - the obvious answer would be a faulty RF cable or antenna, but you appear to have discounted that (unless it's an interval wiring or PCB problem, which is not unheard of).

I take it the module is responding to UBX commands ? You mentioned you have successfully received a UBX-NAV-RELPOSNED message. Have you had successful responses to other UBX commands?

I'm clutching at straws here, but you could try polling the following settings (via CFG-VALGET) to make sure there's no signal, elevation or geofence mask in place that might restrict your ability to arrive at a navigation solution:

• CFG-GEOFENCE-* (restrictions by receiver location)
• CFG-NAVMASK-* (restrictions by satellite elevation)
• CFG-SIGNAL-* (restrictions by signals received and processed)
• CFG-NMEA-FILT-* (restrictions by GNSS constellation)
• CFG-HW-ANT-* (which might shed light on any antenna issues)
• try enabling CFG-MON-SPAN and see if there's any kind of RF spectrum there - it should look something like this:

The only other thing I could suggest - and again, this is a long shot - is some kind of electrical incompatibility between the F9P and your active antennae, which typically need a specific DC bias voltage to be fed via the RF coax cable. Do you have access to something like a u-blox ANN-MB3 or SparkFun SPK6618H, which are known to be 100% compatible with the F9P?

It might be worth posting a query on the u-blox support forum to see if anyone can suggest any other diagnostic tests that might shed light on your issue.

[semuadmin]

PS if anyone from Nvidia is listening and would care to disburse 0.00000002% of your current market cap to help a conscientious member of the open-source GNSS community test on a wider variety of platforms, your largess would be much appreciated 😗.