[GPS] Change autobaud logic for UBX protocol to send baud change command in bulk

[digitalentity]

Change autobaud behavior on UBLOX/UBLOX7 protocols. Intended to fix #4178

[digitalentity]

Tested on https://inavflight.com/shop/s/bg/1225211 and https://inavflight.com/shop/s/ae/32509281424

[ghost]

Thank you Konstantin, for your efforts.
When RC2 is released, we'll give it a go with the SAM M8Q and report back.

[digitalentity]

@kardon18 I can give you a hex to test if you tell me which target you need

[ghost]

@kardon18 I can give you a hex to test if you tell me which target you need

Sure - Omnibus F4 Pro

[digitalentity]

Here you are inav_2.1.0_OMNIBUSF4PRO.hex.zip

[ghost]

You did good 👍
Its faster and better than before !!
Soon as I power the quad and click connect on the configurator, the GPS icon is BLUE.
It has NO timeouts at all now.
Frequency is still at 10hz 95% of the time and 9.9hz the other 5%. So it all looks good.

Thank you

[leeph]

Hi guys - any chance I could test this on MATEKF722SE target please? The GPS behaviour is somewhat impeding a test build of mine and it'd be really useful to remove this unwanted behaviour.

Many thanks in anticipation :)

[ghost]

@leeph
It was found the bug was related to the Matek SAM-M8Q GPS module.
The fix was included in RC2.
I have tried RC2 with another FC that I'm using a NON compass, Matek SAM M8Q with. And it also has no problems now.

I was under the impression that you were using the Matek SAM M8Q + Compass as well, from your post on the issue ?

[leeph]

Yes that's correct - I didn't realise RC2 had just been released. Flashing now, many thanks.

[ghost]

Hi Konstantin. I loaded RC3 today.
And have found this delayed response of the Matek SAM MQ8, both with and without Mag, is back again.
Not sure if something was merged, that has affected it again.
The delay is not as bad as the original 45 seconds, before this fix.
But its still around 25 seconds, before the flight controller will recognize the GPS. As can be seen from the timeouts.

I have rolled it back to RC2, which had the fix. And there was no delay.
So it does appear to be related to a merge that has affected this in RC3.

[digitalentity]

Interesting, didn't notice anything in my tests. Will test again.

[ghost]

Interesting, didn't notice anything in my tests. Will test again.

I decided to do a bit more testing around this matter.
I re-flashed RC3 again. And did not load my setting from RC2 this time. And I found the results were mixed.
It would have a delay of 15 to 25 second every few cycles of the Configurator and FC, and get many TIMEOUTS.

While other times the GPS and FC would start talking within 10 seconds and only get 4 TIMEOUTS.
And not get any communication errors in the field, according to the OSD, when it had a Sat lock, and I did a power cycle reboot.

I also tested RC3 firmware with RC2 configurator (just to be sure). And the result were the same with both configurators.

It isn't as fast and consistent as it was with the fix in this PR. When it had zero TIMEOUTS, and instant communication between the two.
BUT, it isn't as bad as it was before you wrote this fix.

[ghost]

Interesting, didn't notice anything in my tests. Will test again.

Any word Konstantin? Did you get around to doing other tests with the SAM M8Q, to confirm or deny the issue is back with RC3?

[digitalentity]

I was unable to reproduce on two modules I have here. Test on SAM M8Q still pending.

[ghost]

I was unable to reproduce on two modules I have here. Test on SAM M8Q still pending.

When you say pending. Do you mean Matek has one coming in the mail for you?

Something else I found with the SAM M8Q.
It will run at 5.0Hz occasionally when its connected, according to the GPS statistics. And continue to do so until the FC and GPS is rebooted.
I always use Ublox7, so it should be 10Hz.

[digitalentity]

This is odd. On my random Chinese M8N it works flawlessly, on Matek SAM-M8Q it takes a while until it configures correctly.

I'll try figuring out why this is happening, but this is not a blocking bug for 2.1