Automatic video transmitter power change according to distance

[Zerakul]

Current Behavior

When the FC disarmed the video transmitter set to the lowest power. After arming it set to pre-defined power.

Desired Behavior

!!!In addition to current behavior!!! When the FC armed, the video transmitter power output will be regulated by the FC according to pre-defined distance and power configuration

Suggested Solution

In the Inav configuration we will have option to chose automatic video transmitter power mode. Then we can configure the desired distance range to each power level. for example from 0-1km --> 100mw (power level 2) 1-3km -->250mw (power level 3) 3-5km -->400mw (power level 4) The range above is just a numerical example and do not represent the desired ranges. The range should be configurable by the user and according to the transmitter specifications. 5.8 Ghz will require totally different configurations than 1.3-1.2 Ghz video transmitters.

Who does this impact? Who is this for?

All users will benefit from this feature, including Plane/Copter/Rover/Boat. It will be helpful to beginners and more advance users not to worry about transmitter power, not to lose video feed during the flight, and not to overheat transmitter and drain battery when flying close.

Additional context

Similar feature exist in DragonLink v3/v3-slim transmitters (not video) but they are changing the power level according to RSSI and not range.

[Jetrell]

@Zerakul iNav has had this feature from 2.4. Its part of the Global Functions. Although, at present it doesn't work with 2.5RC2 and is awaiting a patch to make it operational again before full release.

Here is some Global Functions for VTX power level setup links - https://www.youtube.com/watch?v=mTPy5-xOaMk https://www.youtube.com/watch?v=fmOxB7QSLUk

[Zerakul]

@Jetrell Thank you very much for the info and links. Although you can implement the desired feature by logical operators, IMHO it should be stand alone feature. I consider Painless360 to be a very advanced user. However even he in his video stated that this is to much complicated to implement via the logical operators (but it is possible) and he even used the help of INAV developer to achieve this. Using a designated GUI in the configurator will be much much easier to everyone...

BTW, changing the power level when armed/disarmed also can be done by logical operators, but it has his own GUI configuration section :)

Again, IMHO, making this feature more accessible and simple to configure to the average/beginner user, will benefit for all of us.

[MrD-RC]

My problem with most of the implementations of this is that they only take distance from home in to consideration, which is a line along the ground. Ideally, altitude should also be taken in to consideration. As you could be flying 500m away but 1500m up, yet in the example in the main post, that would only be on the 2nd power level.

I have a logical switch/global function setup that works with both, but ideally a little bit of trigonometry would be used to get a correct distance from home to the model in 3D space, rather than just along the ground, or what I do which is adding the distance along the ground to the altitude.

[CertainBot]

I agree with @MrD-RC, thats a very good approach. A 3D distance from home will be the best implementation which is basicaly the hyptenuse of the right triangle where ground distance and the absolute altitude are both catetes.

[avsaase]

I agree with @MrD-RC, thats a very good approach. A 3D distance from home will be the best implementation which is basicaly the hyptenuse of the right triangle where ground distance and the absolute altitude are both catetes.

This was added as a logic condition in 2.6, see #6226.

[CertainBot]

Thanks @avsaase, had not came upon #6226!

[avsaase]

@Mateyhv I was going to refer you to the release notes but I see it isn't listed.

[rb1205]

As a reference, my ruleset is as follow:

Limit distances are specified from rule 1 to 3, powers are from 7 to 10. NOT buffers are used as edge detection to determine which limit is current. It also does a sanity check agains locked GPS sats to discard poor distance readings while GPS fix is unstable. As far as I tested it seems to work correctly.

logic 0 1 -1 2 2 8 0 8 0
logic 1 1 0 2 2 31 0 50 0
logic 2 1 0 2 2 31 0 500 0
logic 3 1 0 2 2 31 0 1000 0
logic 4 1 0 12 4 1 0 0 0
logic 5 1 1 12 4 2 0 0 0
logic 6 1 2 12 4 3 0 0 0
logic 7 1 4 25 0 2 0 0 0
logic 8 1 5 25 0 3 0 0 0
logic 9 1 6 25 0 4 0 0 0
logic 10 1 3 25 0 5 0 0 0

EDIT: uploaded better screenshot, added console commands

[avsaase]

So if the number of satellites falls below 8 VTx power is reduced to level 2? Sounds like a bad idea. This raises the broader issue how these logic conditions behave when gps signal is lost. Does it assume the home distance is zero and thus reduced power to the lowest setting? Or does it use the last known home distance and keep the power at the original level? @DzikuVx do you know?

[rb1205]

Quite the opposite: TX power is not changed unless sats are >8. I added that check precisely because I'm not sure how distance is affected by loss of GPS fix.

[avsaase]

If there are less that 8 sats, then LC0 is false, so LC4 is true. But then LC7 is true and VTX power is set to level 2. Am I missing something?

[rb1205]

No, if LC0 is false then LC4 is false as well because it has LC0 as "active" condition

[avsaase]

Sorry, it took me a while to wrap my head around how you used the active conditions. This is a really clever way to deal with a possible GPS loss when flying far away. When powering up the model and until it gets a gps fix, does it keep the last set VTx power, or does it default the the lowest value?

[rb1205]

Yes it's a bit convoluted but it works. At first I used a bunch of ANDs to combine the conditions, but then I realized I could save slots by combining them with the active condition, it works just like a chained AND condition.

The VTX power at startup defaults to what is set in the EEPROM.

[avsaase]

Here is my version with four power levels:

# logic
logic 0 1 -1 2 2 8 0 5 0
logic 1 1 0 2 2 31 0 50 0
logic 2 1 0 2 2 31 0 1000 0
logic 3 1 0 2 2 31 0 5000 0
logic 4 1 0 12 4 1 0 0 0
logic 5 1 0 9 4 1 4 2 0
logic 6 1 0 9 4 2 4 3 0
logic 7 1 4 25 0 1 0 0 0
logic 8 1 5 25 0 2 0 0 0
logic 9 1 6 25 0 3 0 0 0
logic 10 1 3 25 0 4 0 0 0

[CertainBot]

I get your point on the GNSS sanity check but didn't the position remain on the last known location?

[rb1205]

I expect it does but a check is better than no check. In the past I had a faulty GPS that occasionally lost the fix, and I remember seeing strange numbers in the distance meter when this happened so I invested a LC slot just for that.

[MrD-RC]

I've got around to testing this. I did this on my bench using GVars to watch the number of satellites and ground speed. I got a connection, then used an ammo box lid to block the signal. If you want to repeat this test, I had to be pretty quick with the ammo box lid, or the GPS would not lose signal. First attempt I had the ammo box lid, bat safe box, VAS pepperbox, and metal sheet on top of the GPS, and it maintained 6 sats and was sending back data.

Below around 4-5 satellites, the readings become unreliable. At 3 they were wildly out. At 0 satellites, the current readings stay persistent. So gradual satellite loss will get flaky results, then keep the last result before regaining a fix.

More interesting is what happens if you just yank out the GPS, as if there is a hardware failure or a wire comes loose. The readings are persistent still, but that includes the satellite count. I think that is something that should be changed, so that things in the programming can error check. I can understand keeping all the other values persistent, as they are useful (last known coords for example). But satellite count should go down to 0 if the GPS module fails to update. There's no real reason for that not to only be the true, real-time count. If the module is gone, that is 0.

[rb1205]

Nice test, it shows that a sat check is definitely useful.

Also what you wrote makes me wonder if an hardware failure to the GPS during an autonomous flight mode is detected or not.

[MrD-RC]

This is a good question. I would hope that the core of iNav would be able to deal with the lost sensor. But have not looked at this at all.

I have added a request for sat count to be set to 0 if the GPS is lost. I think this would be much better for sanity checking. https://github.com/iNavFlight/inav/issues/6474

[DzikuVx]

Since it's possible to to it with Programming Framework, I'm closing this one