Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Jan 12, 2019

Conversation

Projects
None yet
2 participants
@digitalentity
Copy link
Member

commented Jan 12, 2019

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

@digitalentity digitalentity added this to the 2.1 milestone Jan 12, 2019

@digitalentity

This comment has been minimized.

@ghost

This comment has been minimized.

Copy link

commented Jan 12, 2019

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

@digitalentity

This comment has been minimized.

Copy link
Member Author

commented Jan 12, 2019

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

@ghost

This comment has been minimized.

Copy link

commented Jan 12, 2019

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

Sure - Omnibus F4 Pro

@digitalentity

This comment has been minimized.

Copy link
Member Author

commented Jan 12, 2019

@ghost

This comment has been minimized.

Copy link

commented Jan 12, 2019

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

@digitalentity digitalentity merged commit 831216b into development Jan 12, 2019

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@digitalentity digitalentity deleted the de_ubx_gps_autobaud_fix branch Jan 12, 2019

@leeph

This comment has been minimized.

Copy link

commented Jan 29, 2019

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

This comment has been minimized.

Copy link

commented Jan 29, 2019

@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

This comment has been minimized.

Copy link

commented Jan 29, 2019

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

@ghost

This comment has been minimized.

Copy link

commented Feb 12, 2019

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.

capture

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

This comment has been minimized.

Copy link
Member Author

commented Feb 12, 2019

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

@ghost

This comment has been minimized.

Copy link

commented Feb 13, 2019

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.
capture

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.
capture
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

This comment has been minimized.

Copy link

commented Feb 16, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Feb 17, 2019

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

@ghost

This comment has been minimized.

Copy link

commented Feb 20, 2019

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 comment has been minimized.

Copy link
Member Author

commented Feb 21, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.