Application specific data flow

[kobelev-dev]

Hi everybody,

Imagine I have some equipment installed on board (ozone level checker, whatever else, does not really matter) plus some custom code/application on the ground. I would like these parts to communicate in both directions. Essentially I want to use ELRS/CRSF as a radio modem. Modem is not understanding the meaning of the data that it transfers. This is what I want.

What is the best strategy for this? Grab any unused extended packet type and use CRSF_ADDRESS_RADIO_TRANSMITTER and CRSF_ADDRESS_FLIGHT_CONTROLLER as source/dest fields? Can I be sure that my payload will be delivered in both directions without disrupting anything else in transmitter/receiver? Or, is there any better solution?

Requirement of this type is not new. In the good old days of Win32 there was a message WM_USER+offset. Sender was able to send data to a window handle in format that is specific to this particular window class. Window was processing standard messages (WM_SIZE, WM_PAINT, etc.) plus custom messages of this particular application. This was something very useful and it was widely used. I want to have something similar in this protocol.

Would it be possible to define this here?

Thanks,
Kirill

[wimalopaan]

Are you looking for a transparent radio-modem? Maybe ELRS airport mode may be of interest.

[kobelev-dev]

Thanks for your prompt reply. The AirPort mode is a kind of but still not exactly what I want. Here are some points that are missing in theAirPort mode for the solution that I want:

• They do not have the Sync/Length/Packet-Type/CRC concept that I in fact need. I want to send packets and not an even data stream. Why should I reinvent the wheel? I do not see any major issues in what they have in the CRSF now.
• I would like to have access to features like CRSF_FRAMETYPE_PARAMETER_READ, CRSF_FRAMETYPE_PARAMETER_WRITE and maybe others.
• If I still need a regular RC link with CRSF_FRAMETYPE_RC_CHANNELS_PACKED, I will have to reinvent the wheel.

The AirPort mode makes sense when you want to use some already existing software packages on both sides of the communication line and when these packages are difficult/impossible to modify. When you want to develop something new, then it might not be the best choice.

I understand that if I would like to use some standard software like PX4 or iNav, I will need to have support for these CRSF protocol extensions there. How to support custom extensions in all those different systems is a subject of its own big discussion. Maybe not for this thread.