CRSF Passthrough telemetry sensors not discovered/visible

[nstansbury]

TX16S Mk2 running EdgeTX v2.11
DBR4 Gemini ELRS RX running ELRS 3.5.5
Radio packet rate is X100 Full, with 1:2 telem ratio

Yaapu is installed, running, and working correctly, it appears to report/display/alert all additional sensors as expected.
However no additional passthrough sensors appear in the EdgeTX telemetry screen Eg. ARM or VFAS, even though the widget is displaying those sensors states.

Updated to FrskyTelemetryScript-pr-lua53 and no change in behaviour

Tried manually adding sensors in telemetry screen as per this doc: https://github.com/yaapu/FrskyTelemetryScript/wiki/Telemetry-sensors-discovery Eg. ARM at 060F, 1 and no sensor is added/active

[yaapu]

Hi, the widget does not use sensors, that's the reason why you don't see them.
It uses a customn telemetry stream created by ardupilot and decoded by the widget.
The widget then injects "fake" sensors into edgetx for end users to be used by edgetx for alerts, scripts and so on.
An ARM sensor is not supported as a CRSF sensor and that's why I do not inject it

[nstansbury]

Hi yes sorry, I should have called them "synthetic sensors".

Are there any docs on what sensors should be injected with CRSF, as I get no more telem sensors than I did before I installed the script.

Out of interest, if CRSF doesn't support an ARM sensor, how doe the Yaapu UI show the ARMED/DISARMED state of the vehicle? Ultimately the ARM state and the VFAS value was what I was hoping for to use with custom functions etc

[yaapu]

Hi to get telemetry updates it decodes custom frames sent by ardupilot and injected into the CRSF telemetry stream
https://docs.google.com/spreadsheets/d/1oFv5zSl10wyR0LOcCChDdy9peIRNkbaEBrsHDQ0ZdmE/edit?gid=0#gid=0

[nstansbury]

Thank you for that link, very interesting.

Apologies if I'm being dim here. I was under the impression that the EdgeTX telem sensors are just arbitrary named data fields that can be created with the call to setTelemetryValue()? So I'm wondering what stops those values at the various bit offsets from that sheet being injected into the EdgeTX telemetry screen?

I'm just wondering if I can hack this in myself

[yaapu]

TBH I don't remenber why I did not inject those values, you might try yourself for sure, it might even work.
Sensors are not arbitrary they have to comply with the telemetry protocol used which in turn imposes restrictions, frsky sensors offer quite a lot of options, crsf much less,
You should check EdgeTX source code in the telemetry section, take a look at the protocol header files, valid sensor IDs are listed there

[nstansbury]

Thank you for that 'in'. With a quick read, it looks like the ifdefs in https://github.com/EdgeTX/edgetx/blob/main/radio/src/telemetry/telemetry_sensors.cpp pull in https://github.com/EdgeTX/edgetx/blob/main/radio/src/telemetry/crossfire.h which defines the CrossfireSensorIndexes available when you call TelemetryItem.setValue(...). I'll ask over there to see if it's possible to somehow use the https://github.com/EdgeTX/edgetx/blob/main/radio/src/telemetry/frsky_defs.h

[nstansbury]

For completeness, the discussion at EdgeTX: EdgeTX/edgetx#6445

[yaapu]

thanks a lot for your help!
In the end I had good reasons for not injecting them :-)

[nstansbury]

Yep sad times!
I'm going to pull the EdgeTX code and try to understand how the telem code all works. It doesn't feel right to me that the sensors available are strictly tied to some underlying protocol definition. IMO we should be able to add any type of "synthetic" telemetry value, even values that are dynamically computed from other sensors sources. We shall see...

[twistedwings]

I have added the line

setTelemetryValue(0, 0, 5, telemetry.statusArmed*100, 0 , 0 , "ARM")

in function setSensorValues() and it works very well.

So I don't think it's an EdgeTX issue.