FC tries to config GPS constantly when trying to arm in Loiter Mode

I got a very strange behaviour, when I try to arm in Loiter Mode, the system begins to display a message something like “GPS config … x800008”, and I am not able to arm (GPS has SATs, has HDOP, and Home is Set before). However, if I switch to Alt Hold or Stabilize Mode, and then arm, this message is not displayed and the copter arms without issues. I can then switch to Loiter mode, and GPS seems to be working fine.

I simply disabled GPS autoconfig and that did the trick, but I believe there is some bug here.

1 Like

Hi @Michail_Belov,

Thanks very much for the report.

Could you provide an onboard log and also please tell us which GPS you’re using? We do have another report of the GPS config pre-arm message coming up.

BTW arming in AltHold or Stabilize bypasses the GPS pre-arm checks. The GPS may be functioning but from an AP point of view, we still trigger the pre-arm check if AP is unable to configure the GPS.

Also, the GPS configuration can take a bit of time and especially Mission Planner can take a while to clear the pre-arm message so make sure you give it a minute or two to complete.

The behaviour is this: I try to arm with rudder (I do not use MP for in flight communications), the message is displayed during a long time, maybe 1 minute, then disappears. If I try again, same thing happens.

GPS in use is this: BZGNSS BZ-251 GPS with 5883 Compass - Speedy Bee

The message in OSD is exactly the same as reported by the other user.

One caveat: I have relatively long lines from GPS to FC, 25 cm, which in theory could cause problems at high data rates. However, during flight, I did not have any GPS related issues.

This GPS unit was previously connected to a different board, and it was run under 4.7 DEV, 4.6 and 4.5, but was not flown previously, so I think it was probably correctly configured during that time.

Hi @Michail_Belov,

Thanks for that. Any chance of getting an onboard load? The reason is that this will tell us many things including the exact model that AP thinks is being used. I can imagine that perhaps this GPS is masquerading as a Ublox when it actually isn’t. That’s just a random guess which is all we can do without a log

Txs again for testing the 4.6 beta and reporting back!

Do you need the log file? And for that log, the autoconfig should be turned on? The problem I think there is is that the log file starts once it is armed, and if it is not armed, then no data should be in the log file, or I am wrong?

I found one log, not sure if this is useful:

https://www.ecoterrenos.cl/GPS1.bin

@rmackay9 here is a bin of mine doing the same. If maybe you can help me figure out why I have a oscilliation in roll when I switch to loiter that would be great.

Hi @Michail_Belov,

Thanks for the log. If LOG_DISARMED = 1 then the vehicle will produce logs even while disarmed

looking at the log from Kevin we see:

MAV> messages blox
MAV> 2025-02-07 08:25:34.080 GPS 1: probing for u-blox at 230400 baud
2025-02-07 08:25:34.080 u-blox 1 HW: 000A0000 SW: ROM SPG 5.10 (7b202e)
2025-02-07 08:25:34.080 GPS 2: probing for u-blox at 230400 baud
2025-02-07 08:25:34.080 u-blox 2 HW: 000A0000 SW: ROM SPG 5.10 (7b202e)
2025-02-07 08:28:47.690 GPS 1: u-blox solution rate configuration 0x80008
2025-02-07 08:29:18.690 GPS 1: u-blox solution rate configuration 0x80008
2025-02-07 08:29:49.690 GPS 1: u-blox solution rate configuration 0x80008
2025-02-07 08:30:20.690 GPS 1: u-blox solution rate configuration 0x80008

this shows we do have bi-directional serial access to the GPS
The GPS fw hash matches one we run on a copter owned by @MichelleRos which doesn’t have this issue

1 Like

@prsh8ya please try this firmware:
http://uav.tridgell.net/tmp/copter-Pixhawk6C-bdshot-4.6.0-beta4-ublox-gps-test1.apj

this firmware does 2 things:

  1. it applies this fix to 4.6.0-beta4: AP_GPS: fixed the check for disabling CONFIG_RATE_SOL config by tridge · Pull Request #29320 · ArduPilot/ardupilot · GitHub
  2. it enables low level GPS logging. When you test you will get log files on the microSD card, gps1_000.log etc. After testing please provide both the bin log from the microSD card, plus the gps1_NNN.log files from the microSD card.

the above build is for Pixhawk6C-bdshot, I can do builds for other users to try if they tell me what build they need

1 Like

@Quadzilla,

I think over on the 4.6.0-beta4 thread you mentioned that you had also seen this GPS config error pre-arm check. If that’s still the case, do you think you could test Tridge’s fix? I’m sure either Tridge or I could produce a firmware for you if that helps (just tell us which autopilot to build for)

Things are working better but I can give it a shot. I use the Pix Racer pro almost exclusively. Was a early tester for Phillp Kocmoud.

1 Like

Yes some odd pre pre arm issues after a voltage change battery swap 4s to 6s. I rebooted the compass cal and was able to arm but then got the twitch/oscillations that i could not tune out as normal. Normally would fix it. https://www.youtube.com/watch?v=2YzIqk1vcG4

I just got around to flashing the FC .
Didn’t seem to fix it. Also its is showing up as a f9p and its just the holybro m10. GPS is set to auto config both units.
image

1 Like

@prsh8ya I’ve now reproduced the issue and fixed it. I’ve put a new firmware for you to test here:
http://uav.tridgell.net/tmp/copter-Pixhawk6C-bdshot-4.6.0-beta4-ublox-gps-test2.apj
please test!

@tridge That has fixed the arming issue for the gps. Thank you!!!

1 Like