Dynamic switching of VTX power based on RSSI

[jabacz]

Most pilots are using VTX power more than 25mW because of flying in challenging areas with trees, buildings etc.
VTX power set to, perhaps 200mW, causes interference to your friends sitting near to you when you start or approach landing.

Detect close proximity to pilot using RSSI and switch VTX power according RSSI detected using SA.

Example (subject to user configuration, if agreed). When RSSI shows value over 80, keep VTX at 25mW using SA command. When RSSI drops bellow 80, use SA command to switch VTX to 100mW (200mW). When RSSI comes back over 80, fallback to 25mW. Some spike filtering would be needed to avoid random switching. Perhaps last few seconds average can do the job.

[jflyper]

I think requests for this feature has been brought up multiple times in the past, but never got implemented. It was probably considered a bad idea.

Oh, btw, I believe vtx access is inhibited while armed to avoid wasting cpu cycles.

[mikeller]

In addition to avoiding the waste of CPU cycles, I am also not sure if changing the output power will work for all VTX hardware that is out there without causing a momentary drop out of the video signal, happening at a time that the pilot has no control over, which sounds like a recipe for a crash.

[jabacz]

To the flicker during the change: Did you ever fly in woods? :-)
The momentary video dropouts are "normal" feature of every FPV. I doubt you will distinguish VTX power change from going behind a tree. At least when I was trying this manually through BF stick config with TBS Unify I did not notice any major video dropout.
To the CPU cycles: Maybe this was true with F1/F3 CPU. I doubt, the RSSI evaluation is a big overhead to displaying the same value in the OSD. Especially with F4/F7 computing power.
In addition, I had a word about this with a friend going long range. The GPS distance can be another trigger for VTX power change.

[mikeller]

@jabacz: There is a difference between dropouts that are unavoidable and dropouts that are avoidable. Also, we don't know how long the dropout will be, which is a crucial part of how likely it will result in a crash.

[SchonRichtig]

VTX Power by RSSI would be nice,
if it is too much, maybe we can use a switch, not only for pit mode we already have.
A 3-position switch for 25-200-800mw.
or a potentiometer, that i have on the taranis and have no other use for it :)

The TBS Unify MMCX switches without a Dropout,
my HGLRC GTX226 V2 and GTX585 also have no Dropout while switching the power.

[jabacz]

Confirmed. I have TBS Unify, Unify HV, Unify race, Unify nano and EWRF Mini e7082TM. All do switch without noticeable disruption, or just a flicker. No such thing like dropout worth crashing.

I can agree with free channel switching instead of RSSI. The automatic would be better, but if it's too complicated, or whatever, the switching like pitmode ON/OFF on RC command could be easier to deploy.

[SchonRichtig]

Using a Switch/poti solution, you can implement the RSSI switching in your Radio (Open-TX)
and maybe others, if you want to.

[mikeller]

To me the switch solution looks a whole lot better - even in the presence of a blackout during a switch this will give the pilot the liberty to choose at what time the blackout happens.

[SchonRichtig]

yeah, I’ve hoped this was implemented in the past but that was the pit mode solution :)
I don’t know if it is possible to use one mode for VTX Power, or one mode for each power level?
Ideally there is also a short notification in the OSD

[jflyper]

I'm beginning to recall the past discussion. RSSI based switching is not good because

1. RC RSSI is not directly related with VRX reception (these often run in different frequencies and different reception conditions including antenna topology),

2. RC RSSI characteristic is different by frequency bands and RC technology deployed, and

3. current RSSI implementation for some RC technology is not linear response; it is even a simulated RSSI in some case that present abrupt drop of RSSI value at the edge of reception.

So, RSSI based dynamic switching of VTX output power is not a good idea in general.
However, it may work in some cases and nothing prevents it from being implemented by a volunteer.

[jabacz]

Hi jflyper,

1. of course it's not directly related, but generally it correlates. For reason mentioned it has not to be 100% precise.

2+3) Yes, I know, if RC system reports RSSI wrong way, the user should not use this feature :-)

Anyway we could start by adapting current "Pitmode on switch" to "VTX power on the switch". This can help to situation mentioned in the first post of this thread as well.
Understand: having 25mW -> XXX mW on the switch the same way as we now have Pit_mode -> XXX mW

[mikeller]

@jabacz: I am a big supporter of 'function chaining', and implementing VTX power as an adjustment range (i.e. use an RC channel to select one of all available power levels) sounds like a good candidate for this. If desired it will be easy for users to build their own 'RSSI based VTX power' function on the TX with this, and even more, they can still have an 'override switch' allowing them to boost VTX power if the RSSI value is not an accurate representation of the required VTX power level.

[ghostface]

For the switch solution I fixed a lua script todo exactly this: https://gist.github.com/ghostface/b7de909b24fc7ce4b4c75de515c0ae46

[SchonRichtig]

@ghostface
Great Solution, but you said that the switching can be ignored if I switch to fast through the power levels?
And for your solution you must have a telemetry receiver.
I think a BF integrated solution is better, it will work with every brand and every receiver, and
there also could be a OSD popup with the selected power level

[ghostface]

@SchonRichtig yeah I agree built in would be nice. Yes it requires a telemetry receiver. It does have the advantage of not taking up an additional channel of the 8 available (8 to get minimum latency).

The ignoring when switching too fast might have something todo with it trying to send another telemetry command before the first one is done but I am not sure, it might also be the vtx who simply rejects/ignores additional instructions while it is still processing one.

A delay between sending the command or something like that would probably fix it in the lua script.or maybe something else is wrong - I am not a lua expert and I just debugged the original script and fixed it up till it worked :)

[jabacz]

Hi.
I have an update. I have made a personal progress in GIT usage. I can clone Betafilght locally, I can run a build with working output. I was digging into the VTX code. I have tried some changes, but I've got lost in cross reference of modules and variables.
Is here anyone, possible the author of previous VTX code, to give me a helping hand to understand the consequences?
BR
JaBa

[Klaus-Michael]

The ability to change the VTX midflight on a Switch is the one feature I'm missing since moved to Betaflight from Kiss.
I would love to see this implemented-

[Hawxxer]

Progress on this one?

[wrenfpv]

Any update on this ?

[SchonRichtig]

Unfortunately, no

I still think that this would be an useful option
But I’m not a programmer, I have no idea how complicated it is to
Implement a mode for the vtx power levels.
Shout be simple, but I could be soo wrong 😊

[yoodog]

cool, that would be great add on!