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!!!

2 Likes

Just wanted to note here for posterity (and Google) that this also fixes a problem with getting a satellite fix on the Qiotek M10S GPS. @Qiotek

2 Likes

I have two planes with M10 GPS in them. One seems to have been “fixed” by this PR, the second still struggles to get satellites. Sitting on the ground next to each other, one will get 20+ satellites, the other struggles to get 7.

More information. Running master (with the fix included), my plane with QioTek M10S GPS could not get a fix after 10 minutes running off battery - zero satellites. This was the next day after the previous test and at a different location. I flashed 4.5.7 and immediately got 10 satellites as soon as it booted. Two logs (LOG_DISARMED) here,

Master no fix after 10 minutes: https://www.dropbox.com/scl/fi/yvwtu3d6mhgrid0u3iglp/log_186_2023-10-7-18-44-42.bin?rlkey=ed2292z48nje632bln22jycum&dl=0

4.5.7 10 satellites immediately after booting: https://www.dropbox.com/scl/fi/ok0295xdotlyzvvncgata/log_188_2025-3-5-13-10-12.bin?rlkey=m7bm8w4dn3ftsw3sgycssic50&dl=0

I have some older apj files lying around on my hard drive and as far as I can see the last time this kind of worked was after 4.6.0 beta 2 back in December. In other words.

4.6.0 beta 2 (from my build on 23 Dec 2024) is kind of working - it gets 12 satellites whereas 4.5.7 gets 24 in the same location.

subsequent builds after beta 2 (still investigating) are not working

Hi @tridge - can you explain how I can do a build with this low level GPS logging so I can help you to see what’s going on with my QioTek M10S GPS?

VT Bird
I have a different plane that I haven’t powered on in about a week. It’s running 4.6.0 beta 4 - after power on I got 11 satellites after about 2 minutes, but it won’t get any more than 14 satellites (Acc 2.24/3.03) even after waiting 10 minutes. Without moving the plane, I installed master including the fix above and got 15 satellites immediately on power up (Acc 2.54/2,92), but after 10 minutes peaked at 17 satellites (Acc 2.33/2.59), before dropping back to 14-15.

Next I installed 4.5.7, rebooted (power off) and instantly got 17 satellites (Acc 2.94/2.37), 17 satellites after 2 minutes and 18 satellites (Acc 2.320/2.20) after 10 minutes and 20 satellites (Acc 2.05/2.69) after about 30 minutes. This is also subjectively better as looking at the map in Mission Planner the plane is showing as sitting pretty much where it really is and not moving as much as with the more recent firmwares.

9:45 Log with 4.6.0 beta 4: https://www.dropbox.com/scl/fi/uvf6sikd6y9fbyfk58d0y/log_185_2025-3-6-09-45-06.bin?rlkey=z7ev3j56asle7mjifz3vq8yuv&dl=0
10:55 Log with 4.70 master with fix: https://www.dropbox.com/scl/fi/kdxft6wn3anudjlmpi1o3/log_186_2025-3-6-09-55-04.bin?rlkey=s40oti1rri3go2onnplz1kic0&dl=0
11:05 Log with 4.5.7 official: https://www.dropbox.com/scl/fi/qnbfmv5i0ruqjc1l7ic26/log_187_2025-3-6-10-05-30.bin?rlkey=4npq65cu8wbi734h37ribs06j&dl=0

I’ve installed master on this plane and powered off. Will wait 24 hours to power on again and report back.

12:55 After about 16 hours, powered on - came up with zero sats, but very quickly up to 15/16 (Acc 1.8/2.0) -. Map location looks good. After 10 minutes up to 19 satellites Acc 1.6/2.1. Map has drifted to about a 5-6m error from reality.

After 30 minutes, settled in at 20 sats Acc 1.6/1.9 and map location within 2-3m with a slow drift around the true location. Peaked at 20 after about 40 minutes, then slowly decreasing to 18 with a good real location.

Log here: https://www.dropbox.com/scl/fi/kdxft6wn3anudjlmpi1o3/log_186_2025-3-6-09-55-04.bin?rlkey=s40oti1rri3go2onnplz1kic0&dl=0

Djapana
Powered on after some weeks with 4.6.0 Beta 4 onboard. Started quite quickly and 15 sats (Acc .6/.8) after 2 minutes. Location on Mission Planner drifting all over the place at least 4-6 meters from the true location of the plane. After about 10 minutes it drifted back to about the right location but never got more than 16 sats.

I installed 4.5.7 It came up with 17 sats and started going up and settled in at 19 (Acc .6/,7). Location looked good on the map.

Installed 4.7.0 master fix - came up with 19 sats (Acc 0.8,/0.9). The map location looked good to start but then started drifting to 4-6 m from true location after about 10 minutes, but settled in nicely after 15 minutes with 18 sats (Acc 0.6/0.8)

Installed 4.6.0 beta 2 came up with 19 sats (Acc 1.05/1.25), good map location after about 1 minute. Then started drifting after about 5 minutes. But then drifted back to a good location after about 10 minutes. Got up to 21 Sats after 20 minutes.

Installed 4.5.7 again came up with 20 sats Acc 1.1/1.2 maps within 2m

Installed 4.7.0 master rebooted. Came up with 20 sats Acc .9/1.2 but the map was way off - maybe 10m from the real location. Dropped back to 17 sats after a 5 minutes map drifted closer to the try location.

Put 4.5.7 back on again came up with 21 sats. Acc 1.0/1.1 probably 10m off on the map. drifted back to a good location, 21/22 sats and Acc .6/.7 within 2 or 3 minutes

Put 4.7.0 Master back on again came up with 21 sats Acc 1.2/1.4 and 10m off on the map, but drifted back to a good location witiin about 2 minutes. Dropped back to 17/18 sats and a less stable fix on the map. After more than 1/2 hour it had dropped back to a very steady 15 sats and a very unstable fix on the map.

In this log you can see the satellites drift lower and lower over time.
3:10: log: https://www.dropbox.com/scl/fi/w0bjrp7qxt5bi0lw7u56b/log_163_2025-3-6-15-11-10.bin?rlkey=l58burihlj3xu5abe08q5sz7s&dl=0

Put 4.5.7 back on again - came up with 16 sats and a good map location. Acc 0.8/1.1, after 5 minutes was up to 18 sats Acc 0.6/0.8 and a steady correct location on the map. And after 30 minutes back up to 20. And a steady correct location on the map. Sorry no log.

Put 4.7.0 master back on again shut down for 8 hours. Came up at 9:25 with 10 satellites - up to 14 after 2 minutes. 18 sats after about 10 minutes.

Log: https://www.dropbox.com/scl/fi/ig6ax2gistvq7tcvs4mpk/log_188_2025-3-7-13-54-12.bin?rlkey=pyv96pwklp1ug92uz3qtzkq7z&dl=0

Powered off for about 4 hours, rebooted, got 0 sats initially (it was a bit scary), then 4 then 6 after about 2-3 minutes. 10 satellites after 10 minutes (Acc 1.0/1.2) took about 30 minutes to get a solid fairly stable and correct fix with 19 satellites.

Just saying 30 minutes is a long time to wait for a good fix!

White Shark
I powered on after about 12 hours powered down, running 4.6.0 beta 2 (I think tbc) - started with zero sats at 9:10, stuck on zero sats.

10:05 installed 4.7.0 master with the fix. Power off reboot. came up with zero satellites. Still zero after 10 minutes. Rebooted at 10:15. Still showing zero sats. Rebooted at 10:18 with transmitter on. Still zero satellites.

10:20 flashed back to 4.5.7 - came up immediately with 10 satellites. But it’s all over the place on the map, up to 10-15 m from the true location with wild swings of up to 5-10 meters in different directions. After an hour I had 9 sats and drifting all over the place. Starting to wonder if this is a bad device.

11:25 installed 4.7.0 master. Power off reboot. Came up with 13 sats. Immediately started going up and down - all over the place. Got a “GPS Home acquired” the first time today I think.

Redback Spider
EDU 650 running Cube Red Primary with Here4 GPS - last night on 4.5.7 was running up to 28 Satellites. I flashed 4.7.0 master and this this morning after 8 hours powered down, I’m slowly getting 20 - 22 after about 30 minutes up to 28 sats. And showing 3-4m from true location on the map, but a very steady fix, not drifting. After an hour 30 sats and a very correct fix on the map with little drift.

Tridge says the compile option I need is AP_GPS_DEBUG_LOGGING_ENABLED

Here’s the video about how to use ucenter via CAN passthrough. https://www.youtube.com/watch?v=Dh8hrsp1c9A&t=995s
The idea seems to be something like moving the config backwards and forwards between the two GPSs.

1 Like

Is there any commit including this patch on github?
It seems I have the same GPS problems.

Hi @Paul_Paku,

The fix is in master (aka latest, aka “4.7.0-dev”) and will be released for beta testing with -beta5 which should go out within a week hopefully.

This is the PR with the fix