Testing GPS_RATE_MS=125 (8HZ) - seems to have reverted to 200ms mid flight

This is a follow-on to my post yesterday about if changing the parameter GPS_RATE_MS to prevent EKF warnings of BAD GPS HEALTH is a good approach.

As I understand the docs, EKF issues the warning “GPS BAD HEALTH” if the GPS refresh rate falls below 5HZ. (200ms) And 200ms this is the default setting. My test flights yesterday got several spikes of refresh rates of 400ms - which seem to trigger the several EKF warnings.

Today, in an effort to eliminate the GPS BAD HEALTH warning from EKF, I lowered GPS_RATE_MS from “200” to “125”. (Increasing the GPS refresh rate from 5HZ to 8HZ)

Graphing the refresh rate in flight (gpa.delta) it appears that about halfway into the flight the GPS rate dropped from 125ms (8HZ) to 200ms (5HZ). And there are spikes of up to 300ms (3.3HZ) These spikes from 200ms to 300ms triggered only one EKF warning GPS BAD HEALTH.

In some of the old forum threads about the EKF warning GPS BAD HEALTH there is a caution about setting GPS_RATE_MS to something faster than 5HZ. Maybe this is the reason why. But as this rate can be set much higher - I’m wondering about that. Especially since we have more capable autopilots and GPS than were available when those posts were published.

I’d appreciate it if anyone could suggest why the GPS refresh rate seems to have changed mid-flight - and if there’s something that can be done to prevent it.

There’s another parameter GPS_DELAY_MS with very little information about it in the docs. I’d like to know more about it - especially if it relates to this issue.

Thank you for any and all thoughts and comments!

https://www.dropbox.com/s/35aqy8mhj5i1h8b/2022-08-11%2016-06-18.bin?dl=0

I cant say for sure (correlation is not necessarily causation) but when your number of sats climbs above about 22 or 23 the update rate changes. I couldn’t see anything else around that time.
I suggest you set GPS_GNSS_MODE,3 to limit the number of constellations in use, that should help the update rate.

Actually, if you pull up the map (in MissionPlanner log browser) you see the red and blue lines rarely align, indicating GPS position and IMU calculated position are not the same.
Usually this is bad vibrations, but in this case it might be bad GPS update rate??? since your vibrations look OK.

Yes, as mentioned by Shawn, it can be better limiting your GPS to a few satellites and getting good data than having all available satellites and having GPS struggle to keep up.
Also if you want to stop settings change automatically you’ll need to set GPS_AUTO_CONFIG=0
But I would only do that if you know what you are doing.
Also, there are some GPS modules out there that have outdated firmware on it. Those units benefit from a firmware upgrade in order to improve / solve issues like you describe.
U-blox GPS units can be upgraded with “u-center”

Shawn,

Thank you for taking the time to look into this with me. You’re right about the correlation between gps.nsats and higher gpa.delta.

I’m using a Holybro F9P Helix - updated to the latest firmware 1.32. I’m thinking I should post a question to the uBlox support group to see if there’s a known issue around satellite locks and refresh rate.

I’d really hate to have to reduce the constellations. I’ve gone to a lot of trouble to get F9P RTK up and running.

In the mean time, I may try increasing the rate again - from 8HZ to 10HZ. I was wondering about possibly over taxing the Orange Cube’s processor - but it’s running at about 35 percent - so hopefully can handle the higher data stream.

You’re right about the divergence of the “blue line” and “red line” - but it only happens when the status changes from “float” and “fixed”. I’ve posted about this issue in a separate thread.

Here’s a the red and blue lines during the constant “fixed” status:

And here it is where there are fluxuations:

Seems to me that this is an EKF issue - it doesn’t keep up when the GNSS receiver is rapidly changing from “float” to “fixed”.

Once again - thanks Shawn for lending me a hand on these issues.

Thanks for taking a look at this Karl.

I’m using a Holybro F9P Helix gnss receiver - with the latest firmware - 1.32.

I’m going to post a question to the uBlox support groups to see if there’s an issue about the number of satellites and the refresh rate.

I’ve gone to a lot of trouble to get F9P RTK to work - I’d hate to have to use fewer constellations.

Once again - thank you!

I’ve posted a query about this issue with the uBlox support portal.

https://portal.u-blox.com/s/question/0D52p0000CgBFoDCQW/f9p-refresh-rate-reverting-to-slower-frequency

Thanks for your reply and keeping me / us informed about your progress.
Another thing that has been mentioned over the years is the benefit of shielding under the antenna / receiver unit. This reduces interference from the electronic equipment & motors and also effects of signal “bounce back”
I’ve done some research myself as I prefer the practical approach over just relying on theoretical information.
Essentially it shows how shielding improves signal quality which in turns improves quality and speed of data stream from GPS unit.

Here is a test I’ve done:

I’m using a Holybro F9P Helix. Did your tests with shielding include helix antenna?

@jstroup1986
No, just just a regular GPS unit I had sitting around.
The point wasn’t to test the various antennas available but to answer / proof of what affect shielding has on GPS receivers and the signal quality.
There is also a test that Tridge has done which compares the various GPS units. That I understand that was just a comparison out of the box over a few hours to compare results. No shielding was used in that test. …At least can’t see any in the photos.

Thank you Karl - I had read Andrew’s review of GPS some time ago - and again just recently.

It’s interesting - I get the feeling that there’s not been a lot of work done with F9P RTK.

For example - as I’ve waded into all this, I finally discovered that there is a large array of uBlox parameters that you can set in Ardupilot to set on a uBlox receiver. I knew that ArduPilot set some basic parameters - but I didn’t realize so many were under our control as operators.

I’m also beginning to realize that with 32 satellite locks afforded by F9P receivers, RTK corrections may be beyond the receiver’s capability. For example over on the uBlox support portal I’ve recently learned that there is a refresh rate limitation of 7hz at 32 satellites. I may have to reduce to only 2 or 3 constellations to have my F9P receiver operate reliably. Not what I was hoping for. I’d be disappointed to find that an 8th generation uBlox receiver can provide as good of RTK performance as a 9th generation receiver. Of course with the ability to lock 32 satellites, a 9th generation dual-band receiver will be superior in non-RTK operation.

Thanks for staying in the loop as I work through all this.

The F9P is likely the MOST tested and reliable RTK capable receiver available in the ArduPilot ecosystem.

All I know is that I’ve seen no other references to the phenomena I’ve experienced.

I’ve recently learned that uBlox firmware 1.32 is limited to 7hz when using 4 constellations. Since EKF3 requires refreshes at 200ms (5hz) and the next available selection using ArduPilot parameters is 8hz, the only workaround for increasing receiver output is to reduce to fewer constellations.

You may find this thread interesting:

https://portal.u-blox.com/s/question/0D72p00000Bv9xFCAR/f9p-refresh-rate-reverting-to-slower-frequency?s1oid=00D200000001ogf&s1nid=0DB2p0000008PMD&emkind=chatterCommentNotification&s1uid=0052p00000CFukE&emtm=1660518866749&fromEmail=1&s1ext=0

I’ve seen nothing along these lines in the ArduPilot discourse.