(14-Apr-2023, 11:11 AM)SnowLeopardFPV Wrote: Thanks for your hard work and documenting everything. Based on your findings I think I am finally ready to update to Betaflight 4.4.1.

It was unclear if the improvements in PR #12343 had been merged into the Betaflight 4.4.1 maintenance release because that PR was only merged into the master (Betaflight 4.5) branch and it's not mentioned anywhere in the Betaflight 4.4.1 release notes, but digging deeper I can now actually see that it was committed to the 4.4-maintenance branch on 8th March 2023 under a different PR (#12413), so that improvement did actually make it into Betaflight 4.4.1 after all  But PR #12413 isn't listed anywhere in the Betaflight 4.4.1 release notes either 

Yes, it's a bit of chaos, but we're probably used to it, what can we do about it, nothing. I also assume that it will eventually change a bit in version 4.5 and beyond, but now I know how to bring it up so that I'm satisfied..

How to do it?

GPS Rescue is a really long story, it is a complex system dependent on many settings and parameters. It only takes one thing out of many to be broken or misconfigured and it doesn't behave as expected. Everything that needs to be looked at is really a long story, luckily there is a detailed wiki description now available, which is a job well done and you have to thank for it (to Chris Thompson aka ctzsnooze):

https://betaflight.com/docs/wiki/archive...escue-v4-4

And also Limon's youtube:


This is really a must read and see. And not everything is written and seen in it yet. There are two different terms "functional GPS Rescue" and "smooth GPS Rescue" and they are not the same thing! Follow the instructions on the wiki and youtube to get GPS Rescue working. If you want a really smooth GPS rescue, you have to solve not GPS rescue, but GPS itself and if you use a barometer, a properly functioning barometer with active vario.

GPS rescue is now extremely dependent on a working GPS module, if it is not working properly GPS rescue will not work well:
- in the first case, there must be a GPS module with absolutely stable reception, you must not randomly lose satellites due to external interference, you should have HDOP less than 1, which is usually impossible to achieve with less than about 10 satellites, rather you need even more, which depends on constellation of satellites,
- the measurement rate of the GPS module is absolutely essential, if the measurement frequency is too small, the GPS rescue algorithm does not receive GPS data often enough, which leads to a rescue process that will not be smooth, I can recommend a 10 Hz rate, which is a measurement every 100 ms, it leads for a really smooth process (how it is set is another story, you cannot set it in betaflight),
- the communication rate is equally important, even if you have a measurement rate of 10 Hz and a communication rate of only 9600 bps, you will end up bad again because you are not sending data often enough, this is still a problematic thing in BF for those who are not familiar with this issue, the BF parameter auto baud behaves strange, that's why I don't use it, it should connect according to how the GPS module is set internally (I think it is, but I couldn't find the description), if you can set the communication rate in the GPS module (how it is set is another story, in betaflight cannot be set), I recommend turning off auto baud and manually setting the communication rate in the ports tab to the value set in the GPS module, an error in this setting here or there leads to a low communication rate, if the GPS module will communicate at all, and the behavior is also related to that GPS icon in betaflight, you can't really trust it,
- GPS rescue works even without a barometer, the altitude is taken only from the GPS module, but if you do not have a low HDOP, the altitude will be inaccurate and the behavior will be more or less bouncy and, therefore, not smooth.
- of course, the barometer must first be activated in BF, but everything is different in version 4.4 and higher, the barometer in disarm state does not have a filtered output, each barometer behaves a little differently, that's for a longer discussion,
- the least stable output has the BMP280, on the contrary, the overstabilized output has the QMP6988, the currently often used SPL06-001 (used as DPS310) has a stable output and at the same time reacts quickly to the change in altitude, it follows that each barometer must be filtered a little differently in order to have altitude measurement fast enough and at the same time stable and non-jumpy, on some FCs the barometer can be interfered, which makes its successful function impossible, but that is another story, how to solve it,
- version BF 4.4 and following by default does not display vario in the OSD at all, you need to make a custom build with the VARIO activation parameter in custom defines, you need to see VARIO during flight, otherwise you have no chance to check whether the barometer and the GPS Rescue subsequently works as it should or not, you fly at a constant altitude and VARIO including ALTITUDE must be stable, values should not jump by more than about 0.5 m up and down, it is best monitored on VARIO,
- if these values are unstable or, on the contrary, they change too slowly and do not react to the change in altitude (yes, it can happen either way), it is necessary to adjust the settings of the barometer filters, which are always used only after arming the quad, two low pass filters are used only, floating averaging is no longer used as it was before, altitude is filtered by lpf with cuttoff frequency specified in altitude_lpf CLI parameter and vario in altitude_d_lpf parameter, both cutoff default values can be small for some barometers and large for others,
- for the QMP6988 barometer, I recommend setting it to the highest possible values so that it does not filter at all, it is internally filtered more than enough, similarly I recommend setting the DPS310 (SPL06-001) to the same values, i.e. not filtering, both are filtered too much at the default values, BMP280 in any case needs to filter and here it is necessary to filter a bit more than the default settings,
- and finally GPS rescue PIDs, the last essential thing. This is where I got burned, never use a backup of an older version of BF, older versions of BF used absolutely different PIDs that were set to a completely different way of processing signals with different filters and are extremely high. Always use the default settings for GPS Rescue with the current version, now from version 4.4.1. The current default PIDs are compromise well set and are very low, of course they can be easily adjusted due to the size and inertia of the drone, which is of course for someone who knows what they are doing.

PS: Note actually related to everything already written, all GPS Rescue default values (not only those available directly in the configurator) are set for an overpowered 5 inch freestyle drone! If you have a quad with a different character, these default values may not be perfectly suitable, and the LR quad is completely different from a freestyle quad ... so some values should be adjusted (this is again for some further explanation and I've explained more than enough, I'm probably boring), above all, hover value, speed, ascent, descent and for a really smooth as silk process also GPS rescue PIDs.

That's about all in a nutshell. And I get it, it's more than enough, I've spent an incredible amount of time on testing and tunning the GPS rescue on my 4 LR quads.

How to say it, unfortunately, there are still quite a few problems. I won't go into detail here, but it's still too early to fully rely on the new GPS Rescue. There are quite a lot of PRs that solve quite a few problems. And those problems are not primarily with GPS Rescue, but primarily with the GPS modules themselves. The only thing that works almost without problems is the Matek M8Q, anything else can have or rather has problems, which are given by the communication between the module and the BF. The new M10 modules have even more problems because they support different command sets, a bunch of things are just emerging, like overflowing the altitude value from the GPS module, and other basically trivial bugs.

As I wrote earlier, the most important thing is the perfect functionality of the GPS module. Until now, it was the case that the GPS module was essentially only used with minimal requirements, most users were happy to display one or another value of distance, height or speed, and it didn't really matter that the values were more or less wrong and everyone was happy, until recently no one even knew, what is HDOP, and when is 3Dfix actually safe in BF (it does not completely match the one detected in the module). Now the situation is completely different, a non-functioning GPS module immediately means a problem in GPS rescue.
4.5 should have a lot of things fixed, but I don't think it will be ironed out in 4.5. So far, the barometer and vario have not been solidly solved in PR at all ... that is a problem in itself.

Progress takes time. Sooner or later it will work as intended. We are all learning as we go on this one. Please keep us updated as you go, I find your posts very valuable.

(08-Jan-2023, 01:03 PM)MomoBrut Wrote: Ok, I'm done. It was quite a lot of work, I won't go into any further details. BF 4.3 is set, default PIDs and my rates. If anyone is interested in anything, be sure to ask. In the end, I really like it, what do you think? On the fact that it is from leftover spare parts. 

It doesn't even look much smaller next to the FR7.

Another beautiful and clean build that will cause me psychological problems
Well done !!!