I had some problems with GPS on three of my quads with GPS rescue all season. I have to say that it picked me up for the whole season, but there was no time to solve it. Unfortunately, everything leads to the Chinese mess ... Recently much more often than usual ...

I have been sitting and testing there for 5 hours today. There are more problems.

HGLRC supplies the M80 GPS module, always sells it as the same type, they lie ... Until you have it in your hand, you do not know what you got, there are two completely different modules with a different chip and PCB, those scumbags sell it under the same name! The modules actually behave quite differently, have different support of satellite systems. A version that supports UBLOX, can do GLONNAS and can't BDS, a version that can only NMEA, can't GLONNAS and can BDS. From Europe, the BDS satellite cannot be locked anyway, so it is useless, on the contrary, GLONNAS can be locked without a problem.

So the NMEA version can only lock GPS satellites in Europe, other systems can not be locked because they have a weak signal or the module does not support them and that is a damn problem. In addition, BF does not support GALILEO system if the protocol is set to NMEA. So in Europe you lose more than half of the satellites. What to add is just a total shit.

But that's not all.
BF does not communicate with the GPS module correctly if it is set to NMEA protocol. Individual satellites detected in BF do not correspond to reality, there is always a shorter satellite list than it is actually detected. The trouble is that the absolutely absurd number of locked satellites for 3D fix is reported. BF with NMEA can not recognize if the satellite is locked. It always announces a GPS fix with a much larger number of satellites than what is the fact, the number is greater than the number of satellites in the list, just crazy! E.g. BF reports 14 satellites and 3D fix, in fact only 6 satellites are locked, and there are only 10 satellites in the list !!!!!!!!!! What follows, it makes no sense to describe, the result is the chaotic behavior of quad at the GPS rescue, at best, because the position is most likely inaccurate and probably fluctuating ...

The UBLOX version gets a 3D fix slower, but the number of reported as fixed satellites is correct! And quad behaves significantly better with GPS rescue and is fixed to a much larger number of satellites. Lock is on the satellites of GPS, GALILEO, GLONNAS and sometimes SBAS systems.

What goes out of it, well quite a lot of things. I pull out the important ones, BF has a problem with NMEA protocol, and a significant problem, it's dangerous!
HGLRC company became absolutely untrustworthy for me.

My questions:
1. Is the GALILEO support in BF possible if the NMEA communication protocol is set? Apparently it can only be set for UBLOX protocol only. Or how it works, it is absolute chaos !!!!! The list of satellites is wrong, so actually one does not know what types of satellites are there ... after a lots of testing, it apears only GPS satelites are listed ... Anybody knows, how is this?
2. How can you know if the GPS module chipset supports other than preset communication protocol? For some modules it is said that it can be changed, but personally I do not think that this NMEA HGLRC module will work with anything other than NMEA.
3. Where is the clear info, how the GPS is implemented in BF? What is and what is not supported, it is a bloody mess ...

I did all tests in "gpspassthrough" mode on the separate GPS analyzer.

Does anyone here use GPS? I expected some debate and nothing? Have you ever tested GPS, I mean really tested, not what BF shows ...

I can't answer your specific questions but I swear by the Matek M8Q-5883 GPS modules using the UBLOX protocol and the Gallileo option enabled. They're expensive modules compared to others but they "just work". Matek are a respected brand and widely used by long range wing pilots. Most of their hardware is generally considered to be good quality so I tend to trust their gear. I'm a true believer that you get what you pay for. When I put an expensive quad in the air, I want the best most reliable GPS module on it that I can afford.

I don't use my Matek GPS modules in anger and I've not tested them with a GPS analyser but I have tested them with GPS Rescue enough to have the confidence that they will work as I want them to in the case of an emergency. They usually get a satellite lock within 30 seconds of powering on and where I fly I usually get 15+ satellites, often more than 20 depending on the weather and the time of day that I fly. Between battery changes it re-acquires a GPS lock within just a few seconds.

By contrast I also have a cheap Beitian BN-180 on one of my old analog quads and it's a complete PITA. It takes forever to get an initial GPS lock and between battery changes it takes ages to regain a 3D lock again.

My advice would therefore be to avoid any of the cheap GPS modules unless you are happy to spend (waste) hours of your time trying to configure and troubleshoot them.

I also have a Matek M8Q-5883 GPS and I know it works well. I just wanted to go deeper into the problem of why GPS modules are such a problem in BF. And I found out what I wrote. I often find information that someone advises to use NMEA, others like to use UBLOX, it's absolute chaos, those who give such advice do not know what they are talking about, their advice is simply based on the trial and error method. E.g. Bentian modules sometimes use NMEA, other times UBLOX, total chaos. At the same time, changing the communication protocol leads to an absolutely different function in BF, in the case of NMEA a faulty function, poorly detected satellites, the inability to detect alternative satellite systems, etc.

I was just looking at what is available for purchase, the specifications of the communication protocol are often unclear or wrong. And this information is absolutely crucial to how BF works. Manufacturers change the chips used and thus the protocol completely arbitrarily, e.g. HGLRC, it's a terrible mess.

A little while ago I was on the phone with my local supplier, he confirmed that the last delivery of the HGLRC M80 uses the original M8030 chip and the UBLOX protocol.

So as I understand it, no one actually knows how the GPS interface is implemented in BF. I looked for some documentation on github, I didn't find anything useful.

Most of the Betaflight documentation that exists has come from Baseflight and Cleanflight with additions being added along the way, but a lot of it is still out of date and there is no real in-depth technical design documentation which can often be the case with open-source projects which provide minimal or "just enough" documentation.

If you want to understand how GPS functionality has been implemented in Betaflight you either need to try and get in contact with the devs who originally wrote the code or who now maintain it (usually just a few individuals are responsible for various different parts of the Betaflight code base), or you have to roll up your sleeves and start digging through the code to try and reverse engineer and debug what is going on. That's not an easy task and can be extremely time consuming if you're not a skilled / experienced embedded C programmer, which is likely why a lot of end users of Betaflight just resort to trial and error.

Manufacturers using sub-par or knock-off components probably aren't helping the situation either. Maybe Betaflight itself has implemented the GPS protocols correctly but the poor quality GPS modules haven't and thus cannot exchange data properly with Betaflight. Without looking through code it's impossible to say.

Also keep in mind that for Betaflight 4.4 (still in development) the GPS functionality has been completely overhauled / re-written. If you've not already done so it might be worth trying one of the nightly Betaflight 4.4 builds to see if it resolves any of the issues you've been having. The dev who re-wrote the code might have made a better job of the overall implementation.

I tested with BF 4.2, 4.3 and 4.4 beta. Honestly, in practical situation is very hard to find differences, with NMEA it always work weird and with 4.4 it even should be capable of landing, but I newer allow the drone to land, the GPS Rescue was erratic more than is acceptable for safe landing ...

For anyone interested in GPS Rescue in the new version 4.4, all there is to find is this.

https://github.com/betaflight/betaflight...ue-for-4.4

It's nothing technical, so one won't learn anything as detailed. But they basically require UBLOX and the best GPS module M8Q to be used. Other modules are not even considered...
And that matches my findings that NMEA is, to put it mildly, problematic. If it were up to me, I'd just disable NMEA in BF, for someone who wants to use GPS Rescue. If NMEA is used, the values in the GPS telemetry will most likely be rather inaccurate numbers, but someone can be happy with those numbers to see them in the goggles, even if they are nonsense.

My 2c.
I have based on SnowLeapardFPV's (extensive practical experience with gps) and several BF developers/testers recommendation invested in 2x Matek M8Q-5883 and 1x M10-5883 for my quads and never looked back. Even though or especially because i have little experience with actual RTH and rescue behaviour (luckily)
I gave my cheap Breitan to the dogs after comparing sat fix , cold boot and keep sat fix behaviour.
I am using Betaflight 4.4 bestas, the devs have tested for months and months extensively to seriously enhance GPS Rescue functionality which resulted in much better performance including auto lands at the end of a RTH.  And they also recommend the Matek.
So why would i even try another brand .  I did for a second before i new this and it worked as expected like crap.
Also i dont want to cut costs on one of the most important things to save my quad. Same as i did with my fire detection system at home and fire extinguishers.
I only want the best for stuff i need exclusively when it counts and when it counts it has to be the best of the best.
Anything less gives you a false sense of security, which is worse then no security.  You will be sad to find your cheap and only fire extinguisher does not work if your house around you is on fire.

Does not mean btw that investigating in the technical details is not valid. Absolutely, i love technical details , but in this specific case pure for the knowledge as we already know what works best with BF out of experience and by word of the builder of BF. So pick the best / recommended if you value you quad.

There are btw already a few youtubes i saw in the past with extensive comparisons between gps modules and the cheap once do not come out pretty good. So its not knew info. You get what you pay for or in typical google translatian : more money is more better 

p.s. I would suggest to connect to the betaflight discord channel and try to get into contact with a few developers who where/are coding the gps part . That would be a good point to start digging deeper in the stuff. Also the whole new RTH besides that its beta , requires a whole lot of properly set parameters including a proper trimmed accelerometer, propery set hover throttle value , aux channels values on initiation of gps resque etc etc . Missing out on just one if these things can already mean the diff between a nice landing or some crappy rth behavior. But it remains work in progress and absolutely amazing work these guys are doing.

Perfect timing for this thread. I recently just purchased a used long range drone with GPS attached. I don't know the brand of GPS but I'm excited to dive into long range now. This is great information.
What are the thoughts on the original DJI NAZA-M GPS module? Are those even useful in today's flight controllers? They were very accurate and very reliable 10 years ago

(28-Nov-2022, 04:19 PM)fpvapnea Wrote: My 2c.
I have based on SnowLeapardFPV's (extensive practical experience with gps) and several BF developers/testers recommendation invested in 2x Matek M8Q-5883 and 1x M10-5883 for my quads and never looked back. Even though or especially because i have little experience with actual RTH and rescue behaviour (luckily)
I gave my cheap Breitan to the dogs after comparing sat fix , cold boot and keep sat fix behaviour.
I am using Betaflight 4.4 bestas, the devs have tested for months and months extensively to seriously enhance GPS Rescue functionality which resulted in much better performance including auto lands at the end of a RTH.  And they also recommend the Matek.
So why would i even try another brand .  I did for a second before i new this and it worked as expected like crap.
Also i dont want to cut costs on one of the most important things to save my quad. Same as i did with my fire detection system at home and fire extinguishers.
I only want the best for stuff i need exclusively when it counts and when it counts it has to be the best of the best.
Anything less gives you a false sense of security, which is worse then no security.  You will be sad to find your cheap and only fire extinguisher does not work if your house around you is on fire.

Does not mean btw that investigating in the technical details is not valid. Absolutely, i love technical details , but in this specific case pure for the knowledge as we already know what works best with BF out of experience and by word of the builder of BF. So pick the best / recommended if you value you quad.

There are btw already a few youtubes i saw in the past with extensive comparisons between gps modules and the cheap once do not come out pretty good. So its not knew info. You get what you pay for or in typical google translatian : more money is more better 

p.s. I would suggest to connect to the betaflight discord channel and try to get into contact with a few developers who where/are coding the gps part . That would be a good point to start digging deeper in the stuff. Also the whole new RTH besides that its beta , requires a whole lot of properly set parameters including a proper trimmed accelerometer, propery set hover throttle value , aux channels values on initiation of gps resque etc etc . Missing out on just one if these things can already mean the diff between a nice landing or some crappy rth behavior. But it remains work in progress and absolutely amazing work these guys are doing.

After all, the discussion is not about who pays how much money for what they use, it's really not a discussion about that, so I don't see the point in the long post about the fire extinguisher. And it is certainly not new information that one gets what one pays for. I also wrote that I have a Matek M8Q-5883, and I didn't write a single word about it that GPS Rescue wouldn't work with it. What I wrote about can be read by everyone and it is simply a problem that is not taken into account anywhere and most do not even know about it.

And as for the BF discord server, I spent a lot of time there and didn't learn anything new about the GPS issues, maybe there wasn't anyone there to deal with it. The last info is perhaps from August, when the main work on the new GPS Rescue in version 4.4 ended.

Ok i get it (and i missed that you had a Matek, my bad) As nobody aparently knows or is able to tell you what you need to hear, i am happy to follow this thread where hopefully you will inform us all about how it actualy works and how your detailed investigation leads you to info that will help betaflight developers make betaflight even better then its is now. Thats in the end what its all about. If the info is not there you will figure it out and share it with us.
If its just complaining then i will pass.... I hope for the first

(28-Nov-2022, 02:10 PM)SnowLeopardFPV Wrote: Most of the Betaflight documentation that exists has come from Baseflight and Cleanflight with additions being added along the way, but a lot of it is still out of date and there is no real in-depth technical design documentation which can often be the case with open-source projects which provide minimal or "just enough" documentation.

Well, then of course parts of the code can be old, and probably the NMEA protocol interface wasn't even fully implemented and finished, it was just taken over and moved on. On the contrary, the UBLOX protocol works very well, and in the latest versions of BF it shows the GNSS type for each detected satellite ID, including information on whether it is already locked or not.

Today I found the rest of the time to devote to it and also tried Ublox U-center, a software GNNS analyzer that is free to download https://www.u-blox.com/en/product/u-center You need to download the version v22.07 for older versions of GPS modules. This software analyzer and configurator can read both UBLOX and NMEA protocols. Enable gpspassthrough in the CLI and you can inspect your GPS module.

The results are exactly the same as what I wrote earlier, no special HW analyzer is needed.

The UBLOX protocol in BF version 4.3 and higher works great, the BF interface shows whether a specific satellite is locked or not, the number of detected satellites in BF is actually the number of really locked satellites, all statuses of satellites are listed, in the BF interface it is whether a specific satellite is locked or unlocked, the type of all GNSS system (GPS, Galileo, Glonnas, BDS ...) is displayed. There is simply no problem with the UBLOX protocol, tested with Matek M8Q and HGLRC M8030 UBLOX GPS modules.

NMEA works like this... it doesn't actually work:
- the number of detected satellites in BF is the same or sometimes even higher than the number of all satellites including unlocked ones that the analyzer can detect, while the analyzer detects satellites of all GNSS systems that the module supports,
- the number of detected satellites in BF is typically higher than the number of satellites in the list of satellites in the BF interface, according to the ID numbers it seems that only GPS satellites are displayed in BF interface, but I cannot confirm this, because the types of GNSS systems with the NMEA protocol cannot be displayed in the BF interface,
- the number of detected satellites in BF has nothing to do with the number of really locked satellites, if the possibility of an arm for a safe number of satellites is derived from this number in BF, the position, altitude and speed will not be precisely determined, i.e. these parameters of the quad will not be determined with sufficient accuracy, probably it will not even be stable. There is far less number of satellites really locked than shown in BF interface, typically less than one half.

Anyone can check it, nothing special is needed, just time. This is the reality, make of it what you will.