ardupilot icon indicating copy to clipboard operation
ardupilot copied to clipboard

Forcing serial GPS speed to 115200 by GPS_DRV_OPTIONS 4 doesn't work

Open RBirdie001 opened this issue 3 years ago • 7 comments

Bug report

Issue details

When GPS_DRV_OPTIONS is set to 4 to use GPS auto negotiated baudrate 115200, FC keeps using GPS serial speed 230400.

Version Arduplane 4.2.2 and 4.2.3 Not tested on other.

Platform [ ] All [ ] AntennaTracker [ ] Copter [ X ] Plane [ ] Rover [ ] Submarine

Airframe type Standard motorized plane (Mini Talon and Twin Star).

Hardware type Matek F405 Wing and Omnibus F4V3 GPS: Beitian BN-880 and VK2828U8G5FTTL

Logs Ground test on my balcony: https://drive.google.com/file/d/1-70XVDE_sKAOR9hMBg2LZjTfHAOXREYU/view?usp=sharing

Discussion: https://discuss.ardupilot.org/t/is-it-possible-to-limit-maximal-negotiated-gps-serial-bitrate-tbeacon-stopped-working-after-upgrading-to-plane-4-2/88011

RBirdie001 avatar Sep 02 '22 20:09 RBirdie001

This is normal, 230400 is required for proper GNSS operation. The FC firmware is protecting you against yourself :)

amilcarlucas avatar Sep 05 '22 11:09 amilcarlucas

This is normal, 230400 is required for proper GNSS operation. The FC firmware is protecting you against yourself :)

You are very incorrect. I have made 4.2 work with GPS on 115200 after some struggle. But I am unable to reproduce it. I just remember, it was not straightforward. GNSS is working well. I understand advantages of faster baudrate for GPS. But for airplanes, faster GPS is not necessary.

kolins-cz avatar Sep 06 '22 16:09 kolins-cz

I agree with kolins-cz. I don't understand why 230k would be "required for proper GNSS operation", especially on planes. All versions under 4.2 were using 115k without problems. I don't ask for forcing 115k just for the fun but for good reasons, because important feature stopped working for me. I still think it's only a bug. Once the setting is existing (marked "for advanced users") so I don't think we need to be so much protected.

RBirdie001 avatar Sep 06 '22 21:09 RBirdie001

The EKF needs GPS position updates at more than 5Hz, otherwise it complains. This is for all vehicles.

Nowadays it is common to receive more that 20 satellites, and it takes datarate to transfer all that information. Congrats on finding a way to put all that in 115200. But most users are not able to do that. So to reduce support problems we auto set the baudrate on most GPS receivers to 230400.

I hope it makes it clearer now?

amilcarlucas avatar Sep 08 '22 07:09 amilcarlucas

The EKF needs GPS position updates at more than 5Hz, otherwise it complains. This is for all vehicles.

It needs 5Hz, we are fine with that. 10Hz is ideal for the EKF at the moment admittedly.

Nowadays it is common to receive more that 20 satellites, and it takes datarate to transfer all that information. Congrats on finding a way to put all that in 115200. But most users are not able to do that. So to reduce support problems we auto set the baudrate on most GPS receivers to 230400.

This is a over simplification. If you aren't doing RTK/Moving baseline/raw data there's easily enough bandwidth at 115200 once we've turned stuff off. However if you are doing either of those scenarios we do rapidly run into a problem. Higher baud rates also allow us to reduce the latency on the GPS information which is always nice.

Regarding the actual 115200 feature not working, I'm unsure at this point. I haven't had time to look at it yet.

WickedShell avatar Sep 08 '22 16:09 WickedShell

I didn't measure yet how big part of serial bandwidth is occupied with GPS data, but e.g. common UBLOX GPS serial protocol is very effective so I'm almost sure even 10Hz update will fit to 115k. I can try to test it eventually. See it this way: there is existing "advanced" parameter GPS_DRV_OPTIONS = 4, it is described in the documentation so it should work. If not, it's a bug, isn't it? I don't see any big risk that some beginner will set it by mistake and have problem with GPS data. Someone who needs 115k for some important reason should be able to do it on his own risk and it's up to him to test it and accept consequent risks. Developers shouldn't "protect us against ourselves" as amilcarlucas said too much. That the feature doesn't work can be seen in the log I posted originally. In the discussion I explained why I need it and what I already tested.

RBirdie001 avatar Sep 08 '22 20:09 RBirdie001

To be sure I did a test how big part of available serial bandwidth occupies standard Ublox 8 serial GPS at different speeds. Results are very convincing for me: there is a LOT of free bandwith at 230k and so it is at 115k as well! I let arduplane 4.2.3 to autoconfigure BN-880 GPS module to the settings which software decided to use. (Messages and rates which FC needed at 230k speed.) Then I recorded 25 seconds of RAW serial messages into a file and it produced 8139 bytes. Then I reduced serial speed to 38k (so 6 times less) and recorded another 25s file. This file has 7998 bytes, I measured time by a stopwatch and started and stopped recording manualy so a little difference I assign to a human inacuracy. I'm quite sure that 115k is far enough bandwith for a standard GPS if even 38k still works. I understand that higher speed means lower latency, but for planes it's really unimportant. In the other hand support of tbeacon is really important for me (and others who use it). Please correct this bug! Thanks!

RBirdie001 avatar Sep 11 '22 21:09 RBirdie001

@RBirdie001 Set GPS_TYPE 2. Your log file has it as auto, ublox will only be detected at 115200 if the GPS type is specified as ublox. If that doesn't work let me know and feel free to reopen this. (The 115200 option only works for ublox at this time).

WickedShell avatar Oct 04 '22 22:10 WickedShell