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

[ninja-zx11]

No description provided.

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

[teckel12]

@ninja-zx11 Submitted a PR to INAV to make GPS accuracy (HDOP) more granular with FrSky telemetry. The PR can be found here: iNavFlight/inav#3446

Not sure if it will be included in INAV v2.0 as it appears it's getting close to being released. But I'll try to get it merged in. This along with the (not yet released) Lua Telemetry 1.3.2 should provide more valuable GPS signal quality visual and audio confirmations.

Thanks for the suggestion!

[ninja-zx11]

That's awesome!! Thanks my friend.

[teckel12]

@ninja-zx11 Changes to INAV pertaining to this were merged into development. They'll be included in INAV 2.0.0 RC2 (if RC2 is released which I'm guessing it will be) and the release 2.0.0.

[ninja-zx11]

That's great teckel12!!
Do you think that highest value of 9 should represent hdop around 1 or 1.5 instead of 2? Saying it because if i wait enough for the GPS to acquire signal properly,I get 22 to 23 sats with Hdop 1 to 1.5 most of the time.Was just wondering.Thanks for your work!!

[teckel12]

HDOP of 2.0 or better (4 bars in Lua Telemetry) should be plenty for what would be considered an excellent GPS signal lock. Even an HDOP of 2.7 (2 bars in Lua Telemetry) is only off by maybe 10 feet at most and would trigger a warning.

The number of satellites doesn't really factor into the HDOP calculation, it's how wide-spread they are. My testing concluded that there was little difference between an HDOP of 2.0 and 1.0 (actually, I could never get above a 1.3).

Basically, if you wait till you get 4 bars in Lua Telemetry (an HDOP of 2.0 or lower) you're accurate to a couple feet. Plenty good for a home lock and proper RTH. Things could always be tweaked further later, but it seems to provide useful information now and my testing was very successful. I'd wait till you try INAV 2.0.0 RC2 and Lua Telemetry 1.3.2 before making anymore changes.

[ninja-zx11]

Sounds good.

[teckel12]

@ninja-zx11 I could compile you a version of INAV 2.0.0 RC1 that includes the HDOP changes so you could try it and Lua Telemetry 1.3.2 together. All I need is the INAV target flight controller you're running.

[ninja-zx11]

Sure i will test it out.I am using INAV/AIRBOTF4 target.

[teckel12]

@ninja-zx11 INAV 2.0.0 RC1 with the HDOP telemetry changes: inav_2.0.0RC1-HDOP_AIRBOTF4.hex.zip

Download Lua Telemetry v1.3.2

With the INAV upgrade, dump all first, install the new firmware with full chip erase, reload/save the previous dump, set your mixer and re-calibrate. (I believe you need to set the mixer, but not 100% sure).

With the Lua Telemetry upgrade, just install the iNav.lua file on top of the existing one in your transmitter's \SCRIPTS\TELEMETRY\ folder.

[ninja-zx11]

Thanks teckel12!! Will test it soon.

[teckel12]

INAV 2.0.0 RC2 is out now as well which should include the HDOP changes for FrSky telemetry.

https://github.com/iNavFlight/inav/releases/tag/2.0.0-RC2

[ninja-zx11]

I will test it tomorrow and will report back.Can't wait to test.:)

[teckel12]

The decimal HDOP value in LuaTelemetry will be rounded to the nearest 0.5 and 1.8 is as low as it can go.

Basically, INAV isn't sending the actual HDOP value, it's sending a single digit from 0 to 9 and that's all. A 0 is an HDOP of higher than 6.0, a 9 is 2.0 or lower. LuaTelemetry displays the HDOP value between as an estimation. So a HDOP of 2.0 or less always shows as 1.8. If it drops to below 2.0 it shows as 2.3.

So it's a close estimation, rounded in half HDOP steps as it only has 10 steps to work with.

This was a compromise on a GPS accuracy value in telemetry that's been around for years. To do a actual HDOP, a totally new telemetry sensor would need to be added, which slows telemetry down, and could make other scripts incompatible that are looking at the old GPS accuracy data.

In other words, this was the best I could do without compromising other things. And I believe it's much more useful as it can show and insure your GPS accuracy is within your comfort range.

[ninja-zx11]

Thanks teckel12.That's more than enought.Now we can fly confidently after checking the graph.Great work!!

[teckel12]

I was kinda surprised the first time I used it that INAV was ready to fly but I only had 2 bars of GPS accuracy. Sure, it was "good enough" for the GPS to work, but it also explains why one time RTH landed on the roof of my house instead of my actual launching driveway. I now wait for 4 bars or move further from the house to get 4 bars, then launch. I guess it makes sense as my house is 3 stories high and therefore blocks satellites from an entire hemisphere.

[teckel12]

After flying with INAV 2.0 and LuaTelemetry 1.3.2 I've decided to change HDOP a bit. The graph is now 6 bars instead of 4 and the best HDOP is 0.8 instead of 1.8. This should make more sense for first-time users and allow more low-HDOP granularity.

Goal is to release 1.3.2 right after INAV 2.0 is released.

[ninja-zx11]

Awesome.Can i test the latest modified version with 6 bars?Thanks.

[teckel12]

I'll need to compile you a target for INAV RC2 with the changes. I'll get you everything in a couple hours when I'm at the computer that can do the build.

[teckel12]

The instructions are the same to get the latest development build of Lua Telemetry with the 6 bar HDOP:

1. iNav.lua - To your \SCRIPTS\TELEMETRY\ folder which replaces the current iNav.lua file
2. config.luac - To your \SCRIPTS\TELEMETRY\iNav\ folder, this is a new file

You'll also need a new INAV build to go along with this latest Lua Telemetry build. If you want to upgrade Lua Telemetry first it will work, but the HDOP numbers and graph will be wrong until you also flash a new INAV build that I'll get you in a couple hours.

[teckel12]

And here's INAV 2.0.0 RC2 with the latest HDOP changes: inav_2.0.0RC2-HDOP_AIRBOTF4.hex.zip

[ninja-zx11]

Thanks Tim.I will load it tonight.:)

[ninja-zx11]

So now the max 6 bars will be for actual Hdop(that's displayed on the Inav configurator) of .8?

[teckel12]

@ninja-zx11 Correct.

Previously it left a little bit unmeasured < 2.0 that probably should be shown. It also makes it easier this way to describe it as it rounds to the nearest 0.5 HDOP, without having to explain that the lowest it could show was 1.8.

I flew last night and today with the latest versions and the lowest HDOP I could achieve was 1.0, so the best I could get was 5 bars. My battery rests right against the GPS antenna, so I imagine other people can get lower than 1.0 HDOP and achieve 6 bars. Lower than 1.0 is also considered ideal.

What the lowest HDOP that you get?

[ninja-zx11]

Installed it and worked as expected!!Yes it looks better now.Great work!!I got 5 bars inside(HDOP1.2) and normally i get .9 but sometimes .8 outside.So it means i will get 6 bars outside.
For some reason inav configurator was displaying packet error on the bottom left and the numbers were increasing rapidly and it was slowing down the configurator.I couldn't fly test as i am waiting for my barometer's voltage regulator.Will test fly in 2-3 days.
One more thought.Can INAV output GPS's EPH value as well?

[teckel12]

I was getting the same problem in RC2 configurator. I should probably see if it's a reported problem.

The EPH is an estimate based on HDOP, it's not passed from the GPS and INAV doesn't create an estimation. I think the accuracy graph is a better way to show accuracy anyway.

[ninja-zx11]

Yes that was your great idea to show it as a graph.It takes very little space on qx7's small screen and it's easily readable.Now I know that I have good GPS and it's safe to fly if screen is showing 5 to 6 bars.

[ninja-zx11]

I tried to flash RC-2 (that's available on github) from the inav configurator and i did not get packet errors.Then again i tried to flash inav_2.0.0RC2-HDOP_AIRBOTF4.hex.zip posted few posts above,it started to give packet errors again.Could you please check it.Thanks

[teckel12]

The packet errors are because my build was between RC1 and RC2. I compiled a fix for you but forgot to upload it. I'll upload the fix tonight.

[teckel12]

Here's the INAV firmware that's v2.0.0 RC2 including the HDOP branch:

inav_2.0.0_RC2_HDOP_AIRBOTF4.hex.zip

Sorry about the hybrid RC1/RC2 firmware that yielded all the packet errors.

[ninja-zx11]

No worries Tim and thanks for re sending it .I will test it today or tomorrow.

[ninja-zx11]

I just installed it and no more packet errors.All good now!!

One question please.I want to calibrate my current sensor but i am not able to set display on my qx7 to show Mah.It always shows %.I tried to edit the sensor by changing it to mah instead of % and then it starts showing mah values in the sensor edit screen (if i set set smartport_fuel_unit = MAH) but it still keeps on showing % on the actual telemetry screen.Could you please guide me.Thanks

[teckel12]

LuaTelemetry is designed to only work with smartport_fuel_unit = PERCENT. If it's set to MAH it has no way of knowing what 100% and 0% are, as battery capacity is set in INAV.

But to calibrate you can set smartport_fuel_unit = MAH and then view the FUEL sensor on a custom screen. However, what I do is just use my OSD which shows the MAH used after landing. That way you can keep smartport_fuel_unit = PERCENT

There's a process to go through to calibrate the current sensor. It starts on the bench. I use a multimeter to get the actual current for before arming and while spinning motors while anchored to my table. This gets me really close. I then use the MAH in the OSD to tweak it during a few flights.

[ninja-zx11]

I would have used OSD but my quad is setup with connex prosight.So i can't see OSD :(

Yes i have already setup my scale quite close with Fluke i1010 current sensor and just want to fine tune the mah readings by measuring total mah put back by my charger.I will try to use fuel sensor on a custom screen.Thanks for the suggestion.

[teckel12]

@ninja-zx11 See pull request #131 v1.3.2 allows you to select the fuel unit to display mAh or mWh used instead of the default Percent. It's still highly suggested to use the default Percent so you get fuel low warning messages that are more accurate as opposed to voltage which sags and is therefore not a good measurement.

You can use the same instructions to upgrade to the latest development build of v1.3.2:

1. iNav.lua - To your \SCRIPTS\TELEMETRY\ folder which replaces the current iNav.lua file
2. config.luac - To your \SCRIPTS\TELEMETRY\iNav\ folder, this is a new file

[ninja-zx11]

That's very nice Tim.I will update Lua script on my Qx7 to the above mentioned link soon.Thanks a lot!!

[ninja-zx11]

Thanks.I just updated it and it's perfect.Now i can change fuel to Mah!!

[teckel12]

Note that you lose fuel notifications as a result.

[ninja-zx11]

I am going to leave it to percent as its more useful.I changed it to mah just to calibrate my current sensor but its nice to have option for mAh and mWh now.
Please take this for what it's worth--,How about changing name from fuel to Batt and setting up notifications according to the option selected.eg when selected % then notifications should work like before for fuel.If option set to Mah then it should warn if reaching below specific mah value.Just a thought.Please ignore it if its too much as i can't think like a coder. :) I am quite happy what you have already given and really thankful to you.