Adding FrSky Passthrough telemetry sensors with CRSF

[nstansbury]

Hi all,

Off the back of this discussion: yaapu/FrskyTelemetryScript#284 (comment)

I'd like to understand if it's possible to inject the aforementioned FrSky telemetry sensors when running in CRSF mode

Having looked briefly at the code in telemetry/telemetry_sensors.cpp it appears that the CROSSFIRE ifdefs pulls in telemetry/crossfire.h that defines the available CrossfireSensorIndexes

Is there a mechanism that would allow me to inject additional sensors from an FrSky telemetry stream when in CRSF mode, effectively creating custom sensors?

[raphaelcoeffic]

Is there a mechanism that would allow me to inject additional sensors from an FrSky telemetry stream when in CRSF mode, effectively creating custom sensors?

As of now, this is not the case. We're open to PRs if you see any way to achieve this.

[nstansbury]

Ok, I think I might be up for this, as an interesting & potentially useful intro the code for me.

Can I ask, are there any docs on the impl. behind the telem code? I'm intrigued why the telem sensor IDs are hardcoded. Is this a legacy OpenTX thing?

Off the top of my head it feels like some kind of abstract TelemetrySensorStream that could be subclassed might be a way forward?

[raphaelcoeffic]

Can I ask, are there any docs on the impl. behind the telem code? I'm intrigued why the telem sensor IDs are hardcoded. Is this a legacy OpenTX thing?

You mean apart from the code? :-D Sensors ID are hardcoded because they are defined this way in the respective protocols, so we need to be able to check that, right?

Off the top of my head it feels like some kind of abstract TelemetrySensorStream that could be subclassed might be a way forward?

Try to use composition where you can, virtual methods are not cheap on embedded.

[nstansbury]

Can I ask, are there any docs on the impl. behind the telem code? I'm intrigued why the telem sensor IDs are hardcoded. Is this a legacy OpenTX thing?

You mean apart from the code? :-D

Fair enough!

Sensors ID are hardcoded because they are defined this way in the respective protocols, so we need to be able to check that, right?

Hmm I see why on the surface, but I ask because I wrote this code: https://github.com/Tactory/Postman for a paraglider flight computer, to allow it to stream 100's of arbitrary telemetry values from any number of different sources and aggregate them together into a single composite 'stream'. It feels like a similar approach might work here.

Off the top of my head it feels like some kind of abstract TelemetrySensorStream that could be subclassed might be a way forward?

Try to use composition where you can, virtual methods are not cheap on embedded.

Yep understood