Michael

@elecpower Thanks. I see three options: 1. don't implement upgrade -> users irritated with not being able to use new hardware -> bad 2. implement 8s upgrade without conversion ->...

@raphaelcoeffic Thanks for asking. I believe there is no open issue. Just a work required on the radio side for model data conversions. To summarize the history of this: the...

I second that. The way RSSI alarm us handled is a FrSky artefact misused for other protocols. Some protocols provide RSSI, some a strangely 0-100% scaled RSSI (my physics professor...

After further thinking I'd like to distance myself from my previous comment. To excuse myself here's my reasoning The current implementation: - relies on telemetry, i.e. works only if the...

> @mha1 thx for the very good summary! So the thing that would need fixing is actually the range of values that can be set, which is quite restricted right...

> > > @mha1 thx for the very good summary! So the thing that would need fixing is actually the range of values that can be set, which is quite...

Doesn't look like this discussion ended in some form of implementable specification, does it? If we want to cover all user requirements stated above I'd say it is necessary to...

@pfeerick googly eyes? what do you mean? you no like it? Here's the list of telemetry decoders that currently set the "RSSI" value. For most it is clear what they...

@pfeerick I think the UI part will be the more challenging. Twelve files use the RSSI value the telemetry deocders send with telemetryData.rssi.set(value). Remember this is most of the time...

Sure, I'd be happy to work on this as it is kinda confusing right now. But I sure need some assistance for the UI parts. Not only logic but also...