UBLOX galileo auto configuration not working reliably

[giacomo892]

I have two machines running master , both configured with GPS_GNSS_MODE = 71 , so GPS+SBAS+GLONASS+GALILEO should be enabled on the GPS units.

On the Beitian BN-880, running on COPTER, galileo gets enabled without any issue as I could have checked using serial passthrough after letting the FC configure the module:

On the Beitian BN-220, running on PLANE, galileo is NOT enabled.

If I disable auto configuration and manually enable it on the BN-220, the setting sticks, and galileo shows as enabled.

Both modules are running : u-blox 1 HW: 00080000 SW: ROM CORE 3.01 (107888)

Tridge suggested me to tag @WickedShell in order to have a look in this

I'm here ready to give every other needed detail and info.

[WickedShell]

Do the GPS arming checks pass with auto configure? It doesn't look like we configured the GPS in either of these cases, as the minimum channels listed do not match how we setup the GPS.

[giacomo892]

I can arm without any issues any of my machines, expecially the ones I've posted here.

I can see the modules get configured at boot time since the led pace changes from 1Hz to 10Hz when the FC actually sets up the GPS unit with auto configure. So at least the RATE configuration works.

Regarding the configuration I get on u center after I let the FC configure the GPS for a minute, it should be accurate even if the serial passthrough is kinda loosing lot of data when I am using it.
I poll the GNSS configuration message many times till I get a valid packet.

[rain-er]

Somehow this looks to be the same thing: https://discuss.ardupilot.org/t/cant-set-gps-gnss-mode-for-galileo-on-ublox-sam-m8q/20136
I had no luck to activate Galileo with ardupilot on any of my Neo-M8N or SAM-M8Q devices I used so far from mRo or Drotek. Always had to activate Galileo manually with u-center. Same for plane, copter, rover.

[shellixyz]

It doesn't work for me either: GPS BN-220

[Pedals2Paddles]

Running 3 constellations on any of the M8 UBLOX GPS units is not recommended. The solution rate will drop below the 5hz rate ArduPilot requires. It will function, but the results may be unpredictable and mess with the EKF. You're also not going to get better position accuracy by doing this. Best practice is to pick the best two constellations for your location. GPS and GLONASS are typically the best anywhere. If you're in Europe, you can try using Galileo instead of GLONASS if you want.

Nothing to do with the problem you're describing, but worth mentioning.

[giacomo892]

@Pedals2Paddles I've took a look at logs coming from two different machines. One runs 2 GNSS (broken autoconfiguration) and the other runs a full manual configuration with 3 GNSS enabled.
The GPA.Delta shows some spikes on both cases, is mostly spot on 10Hz with worse case being 7Hz between updates.
Do you think that those updates are not real but UBLOX tricks us in case of using 3 GNSS?

[Pedals2Paddles]

Well that's the convoluted problem. The GPS will still continue sending data to the autopilot at or above the ArduPilot required 5hz minimum. But the GPS isn't actually calculating a new position at that rate anymore. With three constellations enabled, it creates more work for the GPS, so it actually takes it longer to come up with a new position solution. According to UBLOX, that solution rate can drop to 3hz.

So the GPS can only update it's position solution at 3hz, but is sending position data to the autopilot at 5hz or more. The spec sheets do not say what it sends when the solution hasn't updated but it sends an update to the autopilot anyway. Is it sending an identical position? Does it send something meaningless? Does it send something estimated? It's not documented and UBLOX won't answer when you ask them.

With 3 systems enabled, you position will not be functionally any more accurate than it was with two. You won't acquire a usable 3D fix functionally any faster than with two. And you risk sending worse position data due to the reduced solution rate. This is why every UBLOX chip shipped from the factory is set for two constellations by default.

Again, this is probably unrelated to the configuration issue you're having so I don't go too far off topic with it. But you might as well set it for two while you're at it to avoid this problem all together.

[Pedals2Paddles]

Also, please bear in mind that GPS you're using is a knockoff, likely unlicensed, likely non-genuine (fake) UBLOX M8030. This may very will be a factor in your configuration issues. This is an inherent risk using such products unfortunately. Also, the M8030 is not designed or intended for unmanned vehicles. They're more for cars, cell phones, etc. This can contribute to position problems.

[giacomo892]

@Pedals2Paddles Didn't know chinese were actually cloning the UBLOX chip and its baseband.
On the other hand, manual configuration via u-center works, so AP auto configuration should work too.

[rain-er]

I checked the PR #13853 with Rover 4.1.0dev
GPS_GNSS_MODE 71 was set correctly on a SAM-M8Q
I really would like to see this PR in master, because it helps a lot with SAM-M8Q devices, which forget the config after some days when the backup battery is empty.

[giacomo892]

@rain-er The PR is ready and working fine on all my builds and @shellixyz ones. Waiting for @WickedShell (or someone else) to take a look so we can hopefully merge it in master

[anbello]

I would like to say that I tested the PR both on SAM_M8Q and on BN-880 and, as I wrote on PR comments, it works really good.

I also would like to signal that in this u-blox document it is stated that the Max navigation update rate is near double on M8Q respect to M8N (page 6). I don't understand why, the M8Q should be the same as M8N but without flash memory.

Lastly, Even if I understand @Pedals2Paddles concerns I was using 3 constellation (GPS_GNSS_MODE 71) in latest flight and I had no problems, on the contrary lots of sats and low hdop.

[giacomo892]

@anbello I'm flying with this PR for months now.
Some days ago I even had the pleasure to fly with 31 sats locked for 30 minutes with an HDOP of 0.46 and zero issues :)

[anbello]

NEO M9N is interesting.

Page 4