Rereading the various posts received, I think there is a big misunderstanding.
The ELSR protocol only defines the communication protocol between the transmitters and the receivers, not between the receivers and the flight controllers.
ELSR receivers use as their communication protocol with the flight controllers (Bus interface), the Crossfire protocol that is already implemented and working in our controllers.
Kind of like Futaba which uses various radio frequency communication protocols between transmitters and receivers (Fasst, Fasstest, FHSS, T-FHSS, etc.) but always uses the same S.Bus protocol (or S.Bus2 with telemetry) between the receivers and flight controllers.
Therefore, our flight control units are already able to work with transmitters and receivers functioning with ELSR radio frequency protocol.
Some users have already tested and verified:
https://www.helifreak.com/showthread.php?p=8540949&highlight=ELRS#post8540723
Of course, there are also for ELSR the usual limitations: maximum number of channels 12 (to use all the functions of our flight control units you may need 13 / 14 channels and with reproductions you may need other channels managed directly from the outputs of the receivers), limited number of telemetry parameters manageable, impossibility to manage a LUA app for Integration with the flight controller.
This is in addition to the fact that it is not a protocol from a company that guarantees its operation but is a very recent Open Source protocol and for which firmware updates are continuously released to fix the many bugs as they are released.
There also remains the usual problem that if the transmitter has problems in the power supply that could disconnect and reconnect, the first initialization of the transmitter module takes a long time and consequently you lose control of the model for long times with risks to property, animals and people.
In addition to this, it is a Long Range protocol designed for FPV flight with Drones/quadricopters, which is totally unnecessary with RC helicopters of which one has to constantly check the attitude by keeping the models at "sight" (those who have never flown RC helicopters but only Drones may not realize this).
Even the lower latency of the protocol is completely useless with RC eli which have to wait for a 90° rotation of the rotor in order to change attitude and in which the attitude change is slowed down by the strong gyroscopic effect of the rotor itself which is much larger than that of drones, and by the indispensable PID filtering of the gyro signals.
Most importantly (we repeat), despite strong insistence by "some" users, since we started releasing firmware with Crossfire protocol, only 4 users have used it so far.
For all these reasons, in addition to the already made purchase of TBS transmitter modules and receivers, we are NOT going to spend on purchasing more ELSR transmitters (or ELSR transmitter modules) and ELSR receivers in order to be able to do testing, verification, possible new implementations, and provide the support.
We have repeated here some things we have said before but we hope that now put all together, our position is now clearer.
If in the future we were to implement for our FCUs a SW/FW dedicated for use for drones/quadricopters, then we will come back to the topic, but for us the matter is closed here for now.
With the recent Firmware version 3.4.122, Integration with the flight controller from the transmitter (menu on the transmitter screen to read and change flight controller configuration parameters) has also been implemented for the TBS Crossfire protocol.
The ELRS protocol unlike the TBS protocol does not handle the transmission of broadcast frames from the transmitter to the flight controller through the LBT receivers. Therefore, Integration cannot actually work with ELRS receivers in Europe (LBT) but only with TBS.
Since the range of the TBS and ELRS protocol are very similar, Between TBS and ELRS we recommend to european users the use of TBS because in addition to bidirectional telemetry that enables Integration, the data packets containing radio channel information are transmitted and received with a constant frame rate and never interruptions, so the pilot's commands are constantly updated, whereas with ELRS LBT receivers, failures of radio channel data packets are very frequent and frame rates double, triple, quadruple with considerable frequency. This causes the constant and continuous slowdowns in the updates of the commands sent by the pilot; in fact, very high values of Fades are generated during flights. The only way to avoid this slowdown of commands received by the model is to use "D250" as the Packet Rate (with the limitation of 12 maximum channels handled).
