How to support new telemetry sensors?

[raphaelcoeffic]

Thanks a lot for publishing this document. I strongly believe this will help interoperability between existing implementations.

Regarding telemetry sensors, I still see a huge pain point for users, and for the eco-system in general. As of now, CRSF is strongly focused on very specific use cases (mostly drones and planes including a flight controller). This is the main blocker for CRSF adoption outside the drone world.

Users would love to be able to profit from the growing eco-system and new types of telemetry sensors. However, I don't really see how new types of sensors can be added (possibly using specific ranges of IDs for DIY or 3rd party vendors).

A few examples here:

• single cell measurements (up to 12S)
• multiple current measurements (ex: servo current, either grouped or by single servo)
• airspeed (currently only GPS based ground speed available)
• motor / turbine metrics (current draw, RPM, pump voltage, etc)

The next concern I have is from EdgeTx's point of view: if projects / vendors all get their own ID ranges, we will probably end-up implementing a lot of redundant things, which will strongly inflate the firmware sizes.

So I believe there are strong incentives for offering a few new common generic sensors, while also allowing for specific implementations to use CRSF to transparently transmit some payload types.

In EdgeTx case, we would implement the generic commons in the protocol itself (as is now for all supported sensors), while transparently transmitted packets would only be understood by LUA scripts which could then set sensor values.

[tbs-fpv]

Agreed.

For sensors, please send a proposal list of sensors you'd like to support or that are missing, we'd be happy to add them to align with EdgeTX capabilities. long term, this will allow vendors to pipe sensor values through CRSF from the aircraft to the radio more easily.

And don't worry, we wouldn't support a vendor-specific sensor or message type just for transmitting values. That wouldn't make any sense. the only case where it does make sense to provide vendor-specific ranges (other than legacy) is when the projects are open source and end to end, which wouldn't impact any other projects or increase their burden for support.

[CapnBry]

I feel like there is a problem with the fact that there can be literally 100 different sensors that want to get added, look for example at RotorFlight, which runs its own telemetry protocol using a single CRSF packet type and each individual item gets a unique 16-bit ID. This is just one type of data that would need to be conveyed natively, just for helis, and also falls short due to it expecting there's only one instance of any item.

I would say it is therefore unfeasible to consider adding new CRSF packet IDs for each one.

I proposed the concept of creating "compound sensors" sort of like CRSF has currently, except all operating under a single CRSF packet ID, and allowing multiple compound sensors per packet. The IDs and payload structures would still need to be sanctioned by some approving body but the structure allows for a firmware to skip past unknown IDs so a newer telemetry emitter would still be backward compatible with an older telemetry consumer, just as the current one-set-of-values-per-CRSF-ID telemetry items do.

As far as EdgeTX bloat, a list of ID -> structure definitions could be stored on the SD card independent of the firmware and processed on demand during sensor discovery to store the structure unpacking definition in the model settings. This is would be a single one-time hit to EdgeTX firmware size regardless of how many sensors exists in the world, and a fixed RAM/storage size for the currently active model's telemetry unpackers. The unpacker definitions can be maintained outside the EdgeTX source and allow the user to update their unpacker definitions independent of EdgeTX version.

It doesn't matter to me if that concept is considered at all, but I will say that 100% for sure it is a folly to consider that individual CRSF packet IDs for the sheer number of sensor types that people want to add. You can hardly have this conversation without people immediately showing up and asking individually for a dozen different things to be added. If anything is to be considered it should:

• All by handled by a single CRSF packet ID, using some sort of sub-id to indicate the telemetry type (e.g. "ESC 1 information")
• Support instancing in some manner rather than creating redundant IDs with the same telemetry structure. That is, there isn't an ESC 1 Info ID, and ESC 2 info ID, and ESC 3 info ID, all with the same values. You'll always find someone who wants just one more than the spec accounted for,
• Backward compatibility. A telemetry emitter sending unknown IDs to a consumer must still be able to be bypassed by the consumer without breaking the stream.

[3djc]

Fully agree with CapnBry (with the exception of SD storage of data reference, experience has demonstrated that users simply cannot cope correctly with that basic task). We are phasing out radio with 512 Mb FLASH anyway, so that aspect shouldn't be a concern anyway). Happy to be helping with ETX side.