Morning all,
With a couple of aircraft we are getting the “Bad GPS Health” warning. I know that this comes from a less the 5Hz update rate (specifically a delta of greater the 250ms between messages) as the flight controller sees them.
I have identified two different symptoms which may or may not be related.
The delta raises above the 250ms limit if the satellite count on said GPS is above 18. Scoped the data lines when we have had this happening and the bus isn’t anywhere near full.
Both the cable and the GPS unit has been replaced in the aircraft with the same results.
That GPS unit has shown the same slow message freq on a bench test cube that had a clean install of latest stable on it.
Message freq has been upped from the default 5Hz to 10Hz and once the sat count was over 18 there again was delays in the message freq over the threshold.
This has all been captured when not in flight. To continue with other testing we have relied on the second (CAN) GPS only.
I have run some more bench tests with a brand new HERE and a HERE2, the HERE shows the same halving in freq symptom but the HERE2 does not.
Firmware? I would expect this to happen at some point with any receiver. The more sv’s the more data to transfer. I think you could raise the elevation mask and patch the issue. I do not mean to point out the obvious I was just thinking as I read your post.
GPS’s are running 3.01 as from factory, bench test cube is arducopter 3.6.9.
I was initially thinking I could just not report on some of the constellations to reduce the satellite count but unless the root cause is to many messages then reducing the amount of data being transmitted doesn’t really fix the problem.
Scoping the serial line when the issue is actively causing pre-arm warnings shows roughly 30% bus usage so I’m pretty confident that is not the problem. The cube for same reason may not be phrasing the data fast enough or the data being sent is not readable/relevant.
We have been using cubes and HERE GPS’s for quite a while now and haven’t seen this issue before which made me originally think it may have been a hardware issue with these specific units.
I am going to run an extended test on the HERE2 to confirm if it does or does not show the same issue after a certain time period.
The Zubax GNSS 2 that is the second GPS in the aircraft is CAN, both the HERE and HERE2 are being run with serial. The bench test setup only has one GPS on it at a time to narrow down the variables at fault.
Left there HERE2 attached for a couple of hours yesterday and had none of the previous issues.
Sat count never got as high as previous test so a little inconclusive given the >~20 satellite then it fails hypothesis.
Found an original HERE to test as well as the new HERE. Difference externally is the LED lenses are frosted white on the early ones and clear on the latter ones.
I did this to test weather the fault was present with both units, in the past using the original units we had not seen this fault before.
Both units where set up exactly the same and run through the bench test. Both units failed with the same Bad GPS Health message which only occurred once the GPS count was greater then ~20.
Looking through historical logs to see if this had been happening to any degree in the past I discovered the GPA Delta field was not a field that was recorded until recently.
I’m leaning towards the conclusion that the GPS message freq has always suffered when the satellite count got high, but until recently the FC did not act on that metric and just continued as if nothing was amiss.
To work around this I limited the GNSS channels in the HERE GPS (using U-Centre) to 17 which is the minimum that can be set.
After this change I have not had any Bad GPS Health messages but will continue to monitor.
This doesn’t solve the root cause of the problem as the GPS module and FC should be compatible out of the box and nerfing the GNSS count is just limiting otherwise useful functionality. On the flip side “it
doesn’t, not work” now.
In u-center the default for the elevation sv mask is 5 deg. That is far too low use 10 deg min, I use 13 deg. The data from the low sv’s will not help position mostly because of ionosphere interference.
Sorry for the late reply, must have completely missed the notification email.
The aircraft in question may have had some non standard logging settings which might be the cause.
But the bench test was a fresh install on default params which also showed the same error.
Same here please. i updated from 3.6.11 which worked fine to 4.0.0 which is currently latest official. Suddenly mission planner every few seconds says BAD GPS SIGNAL HEALTH. I tried to look at GPSA delta from logs and the values are approximately 200ms ± 20ms, maybe little higher. Here have a look.
I tried with two different GPS here2 units, both set to can, both had the same problem. Both have the latest can firmware available.
What is going on please. I do have a satcount arround 14, and hdop somehow aproxiamtely 1.5
I tried to update to 4.0.1 rc3 BETA. With this firmware it doesnt says BAD GPS SIGNAL HEALTH, yet GPA delta is now 200ms±30ms. So i think in beta this error message is solved, but i really dont feel comfortable running this expensive machine with beta firmware.
When will be this firmware released as alpha?
I’ve had one Here2 where the HDOP would stay at 1.5-1.6, and throw errors, including a GPS Glitch that had me worried. I’ve set it for I2C and used a FTDI interface to connect u-center to the M8N module. I’ve reset its configuration to default, saved and rebooted, then proceeded with manual setting: port speed, protocol, constellation, update frequency and power management.
Lo and behold, after reinstalling on copter, HDOP went to the usual 0.8-0.9 and errors disappeared.
normally when using with ardupilot and via i2c/serial, ardupilot would configure the gps. maybe you turned these settings off? as it would normally try config on every boot
I have many HERE2 units and almost all of them give me high HDOP messages using CAN. I have set the hdop_good value to 180, so that I can use them, but sometimes I get even higher HDOP values. I don´t want to switch to serial/i2c because the leads are quite long. I am going to try to reconfigure using u-center, but it would be nice to have them configured correctly out of the box.
edit. Ok, I might have a possible explanation. For some reason the PDOP value gets reported as the HDOP value in Arducopter, when using CAN.
When I connect the M8N directly to u-center, I get exactly the same PDOP values as the HDOP values are in MissionPlanner. Could anyone verify this? @philip@Michael_Oborne
