I am currently using two u-blox F9P serial GPS modules for a moving baseline setup. I have configured the GPS_DELAY_MS to 200 ms by default for both units.
However, upon reviewing the log, I noticed a discrepancy in the GPS-DELTA values—one unit consistently shows 200 ms, while the other shows 1000 ms.
Is this expected behavior in a moving baseline configuration?
I’ve attached a snapshot and log files for your reference. Your assistance in identifying the cause of this issue would be greatly appreciated.
I resolved the delta issue with the Serial Variant GPS by setting GPS1_RATE_MS to 200 (5 Hz).
For testing with two DroneCAN GPS modules (also set to 5 Hz) in a moving baseline configuration, the base GPS maintains a steady delta of 200 ms. However, the rover side shows irregular spikes, averaging around 400 ms, similar to the snapshot I shared earlier for the Serial variant.
Both DroneCAN GPS units work normally when not used in moving baseline mode, each holding an average delta of 200 ms. The irregular spikes appear only on one GPS when it’s configured for moving baseline support.
I’ve been testing a few scenarios using the Holybro F9P Rover Lite (serial variant) GPS for a moving baseline setup with ArduPilot.
When both GPS units are connected via serial, everything works fine — the delta values for both GPS1 and GPS2 remain stable at around 200ms.
However, when I connect the same GPS units through two separate MatekL431 CAN nodes (one GPS per node), I start noticing discrepancies. GPS1 shows a slightly lower delta (~204ms), while GPS2 averages around 250ms, with occasional peaks reaching up to 800ms.
Could you help me understand why this behavior is occurring when the GPS units are connected via CAN nodes?
I’ve attached the logs and some snapshots for your reference.
Best guess is that you’re saturating the CAN bus by talking to two nodes and forwarding a lot of data. As far as I know, you should be able to connect both modules to the same node.
Hello @Yuri_Rage Sir,
I’m currently using two separate CAN nodes, one for each GPS, to replicate a setup similar to the Here4 configuration—where two Here4 units are connected to a single CAN node on the flight controller.
In my setup, connecting both GPS units to the same Matek CAN node would likely lead to saturation, as you pointed out. That’s why I initially opted for two separate nodes.
I’ve attached a diagram of my current setup for reference. I’ll also test connecting both GPS units to a single Matek CAN node and will get back to you with the results.
From the hardware report it seems like there is enough bandwidth for his application, but I wonder if there’s a way to get CAN interface statistics like frame errors that would rule out can bus errors being a source of missed messages.
More obvious cause is that the F9P firmware is outdated, which caused issues like this. I can’t see the hash in the log messages, but I already recommended to make sure it’s up to date.
@Yuri_Rage@Joshua_Kordani
Very Sorry for the late reply.
I have tested with multiple u-blox firmware versions (1.13, 1.32, and 1.51), but I still haven’t been able to identify what is causing the discrepancy in the CAN communication.
Do you get the same behavior if you connect each GPS directly to the two different CAN ports on the Cube? That might give you better error statistics if the issue is related to CAN. At the moment, there are no apparent CAN issues that the Cube can see, but if there is a problem between the Matek nodes it’s not clear if you would notice that.
You can also try increasing CAN_LOGLEVEL and see if that is illuminating.
Along a different track, can you use u-center to explicitly confirm what constellations are configured in each device? I’ve been having issues with autoconfiguration of Here4’s over CAN lately.
I’ve configured the same constellations for both GPS units, each with its own CAN node. The issue might be related to the Matek CAN nodes. I’ll also try increasing the CAN_LOGLEVEL to debug.
