In the meantime, the fact that automatic recognition of the protocol is now possible makes life easier for users.
The SRXL v2 protocol is already automatically recognized by selecting a single icon that allows users to automatically recognize if the connected receiver is:
Multiplex SRXL 12ch
Multiplex SRXL 16ch
Old Spektrum SRXL (no telemetry: unidirectional)
New Spektrum SRXL v2 (with also telemetry: bidirectional)
FrSky F.Port (with also telemetry: bidirectional)
Unfortunately, to maintain backward compatibility with other protocols, in the setup of our controllers we still have to leave several other icons to be able to select protocols not automatically recognizable. However, it is not certain that in the future we will be able to implement automatic recognition of all types of receivers that can be connected to our units by selecting a single “discover” icon.
One of the benefits is that, this serial protocol will provide the “tools” for a flight controller to be able to use multiple telemetry receivers instead of just 1, as it will allow it to choose which receiver has the right to “reply” at any given time while telling the others to stay quiet. This means not just receiving diversity with multiple receivers, but also telemetry diversity.
In addition to this there is a possible increase in performance because if all the devices connected to the bus responded that they can go to 400,000 bps instead of the default 115.200bps, you could transfer much more data in a shorter time and then faster.
However, we will have to wait until Spektrum starts releasing new bus-connectable sensors that work with this new protocol and work at 400,000bps (For this reason, for now, we have not yet implemented in our controllers the operations at 400,000bps).
However, there is one more thing that can be read between the lines of the documentation:
The actual channels frame rate from 11ms probably could drop to 5ms if communicating at 400,000bps.
This would be the fastest frame rate currently available on the market with a very high data exchange.
So more and more “real time” and a higher feeling of being directly connected to the model.
In addition to this, the new protocol is open to new and future implementations.
It may therefore be that in the future the telemetry protocol can become bi-directional (currently the telemetry data travel in one direction only from the receiver to the transmitter and from the transmitter to the receiver travel only the data of the radio channels). This would allow to transmit also the status of the buttons, of the roller and of other commands that can be carried out on the transmitter (Like Jeti, Graupner and FrSky). As a consequence, also the navigation, for example in the integration menus for our unit or for sensors connected on the SRXL v2 bus, would be simpler and easier than the current navigation, which, for now, can be carried out only by means of stick movements.