GPS HDOP value display on Qx7 screen from INAV telemetry if possible.

[ninja-zx11]

[teckel12]

@ninja-zx11 This is a tough one to explain. I've already built in the HDOP value in INAV S.BUS telemetry. The Tmp2 telemetry value's hundreds position is the GPS accuracy (0 = lowest, 9 = highest).

I had hoped that this would allow me to show a GPS accuracy in LuaTelemetry. However, once you get a 3D GPS lock, it's already at the highest HDOP value of 9. So, there's little point always showing a value of 9 as it's always the same. I don't think INAV allows you to launch until the HDOP is at the highest level of 9.

Basically, my intention was to show HDOP or some kind of GPS lock accuracy. But in reality it's always at the highest level anyway so there's little point showing it.

[ninja-zx11]

Thanks teckel12 for explaining the situation.
Recently my INAV quad got crashed while doing RTH even tho RTH worked flawlessly other times.Only thing i did different was to fly as soon as i got 'ready to fly' message.Unfortunately i didn't log it.I noticed same behaviour earlier too where i armed as soon as inav allowed to arm.I am suspecting not having enough GPS accuracy while arming.Also i found that while cold starting the GPS , despite having good number of Satellites,GPS takes a little time to achieve good positioning accuracy.

That's why i thought It would be nice to see the GPS's positioning accuracy in 'meters' or HDOP on the Tx before initiating the flight.

[teckel12]

Before you can arm it's already at the highest HDOP accuracy of 9. You can see the HDOP accuracy by looking at telemetry sensor Tmp2. But like I said, it will always be 9 once ready to fly.

Changing the minimum satellites to 8 or more will help, also, monitoring the GPS altitude and speed before launching. If these values are jumping around a lot, it doesn't have a good GPS fix, even if it thinks it does.

[ninja-zx11]

Good point of monitoring the GPS altitude and speed for jumping values.Thanks.

One more thing,Would drone disarm itself midair if the no. of satellites gets below the stated minimum no. of satellites while flying?

[teckel12]

No, it wouldn't disarm. I could set an alarm if armed and it loses 3D lock, HDOP drops below 9, or the number of satellites goes below 6. But, I've literally never seen any of this ever happen. I'll look at some logs to verify.

[ninja-zx11]

Thanks.
I found one more thing after comparing my M8n data from INAV with u-centre that INAV is actually displaying PDOP value as HDOP.

u-centre was giving me PDOP of 1.3 and HDOP of .7 whereas INAV was displaying HDOP of 1.3.Is there typo in the inav configurator?

[teckel12]

@ninja-zx11 Not familiar with u-centre. And when you say INAV is displaying HDOP do you mean on the OSD? I've seen values like 1.3 on the OSD for HDOP but have kind of ignored them because it doesn't seem useful (as once flying there always seems to be a very good GPS lock). Anything 2 or less is excellent, and I've never seen it go about 2 so I've turned off displaying it in the OSD.

From Wikipedia: DOP lower is better. 1-2 is excellent and below 1 is ideal. It seems that HDOP, PDOP, etc. are different ways of calculating DOP (also referred to as GDOP). INAV seems to use the HDOP calculation because that's what the GPS sensor outputs.

For S.Port telemetry, we take the HDOP and flip it so 9 is the best and 0 is the worst. So, higher values are better. A value of 1 or higher is a 9 while 0 is the worst (a HDOP of 9 or more). This was done so higher values are better (like the rest of the GPS information) and so it only uses one digit (which are scarce for telemetry).

The Tmp2 telemetry is broken down as follows from the INAV manual:

Tmp2 : GPS lock status, accuracy, home reset trigger, and number of satellites. Number is sent as ABCD detailed below. Typical minimum GPS 3D lock value is 3906 (GPS locked and home fixed, HDOP highest accuracy, 6 satellites).

• A : 1 = GPS fix, 2 = GPS home fix, 4 = home reset (numbers are additive)
• B : GPS accuracy based on HDOP (0 = lowest to 9 = highest accuracy)
• C : number of satellites locked (digit C & D are the number of locked satellites)
• D : number of satellites locked (if 14 satellites are locked, C = 1 & D = 4)

So, when you first power up your model, Tmp2 has a value of 0. After a while it starts getting satellite locks so it may go to something like 1002 meaning it has a GPS fix with 2 satellites with a low GDOP (0 = 9 or higher). After a bit more, it will go to something like 2005 meaning 5 locks and a GPS home fix. Then, something like 3508 which means it has a 3D GPS fix, 8 satellites, but still the GDOP is too low (5 meaning a GDOP of 4 [9-4=5]). Even though there's 8 satellites, INAV won't allow you to arm because the GDOP is also out of range. Finally, you'll get a Tmp2 value of something like 3911 which at this point INAV allows you to launch because now the GDOP is at a value of 1 or lower.

Maybe there could be more granularity with the GDOP value for telemetry, but like I've said, I've never seen it have a problem while in flight. However, I'm not flying between buildings in a city or under trees in the forest either. I can't imagine those situations are any good for GPS anyway because return to home would probably be catastrophic anyway.

Basically, HDOP is being sent in telemetry but Lua Telemetry isn't displaying it because as soon as the HDOP is at a level 9 (1 or less for the actual HDOP value) INAV also reports that it's ready to fly and Lua Telemetry announces it's ready to fly. If the HDOP would fall, INAV would disable arming and report that via telemetry to Lua Telemetry which would indicate it on the transmitter.

I believe the problem you had is that the HDOP value isn't that useful. GDOP would be much more useful for knowing the GPS accuracy as GDOP takes into consideration the angle of the satellites (the wider the angle the better the GDOP value). But, we don't have that luxury as the GPS doesn't calculate GDOP, it only gives us HDOP which isn't really a good indicator of GPS accuracy in all situations.

I would suggest raising the minimum satellite count to 8 and waiting till the altitude settles and the speed never changes. I've had poor GPS locks and noticed my altitude was hundreds of feet off from what the real altitude is. I've also noticed sometimes my speed (before arming) will show 1 or 2 MPH. I believe INAV also looks at the speed and doesn't allow arming if it's moving (or the GPS thinks it's moving). Not sure about the GPS altitude changing if INAV will disable arming or not, may be a good thing to test.

Anyway, if you can think of something that could work better I'd love to hear it, I'm just not aware of anything that could be done to insure a better GPS lock as it seems the limiting factor is the GPS itself.

[teckel12]

@ninja-zx11 I added a GPS fix indicator graph in the next release of Lua Telemetry PR #117 It's not overly useful currently because of the way INAV outputs the HDOP on the S.Port. But, I'll look into modifying INAV so it outputs more granular HDOP data.

[ninja-zx11]

That's great!! Sure it will be useful in future.Thanks for your work towards LUA telemetry.