Hopefully this will be soon. Im getting ready to buy a 700 class heli and I want to use a CRSF connection.
just a note ... another company which i will not mention just release a new update that supports CRSF protocol.
just a note ... another company which i will not mention just release a new update that supports CRSF protocol.
If the other company that released support for the CRSF protocol released support only for receiving radio channels but not support for transmitting telemetry data, then it would have done a totally unnecessary thing because to receive only radio channels without being able to transmit telemetry data as well, it is enough to set in the Crossfire receivers the PPM or S.Bus output protocol (all TBS receivers can do this) and select in the flight controllers the decoding of these serial communication protocols between receivers and flight controllers.
From the point of view of operation and performance, there is no real difference, real advantage, or real improvement between receiving channels via the S.Bus serial protocol or the Crossfire serial protocol.
@customercare Any Update on the CRSF protocol Support Date?
Im flying crossfire on brain units for over 2 years. Just use SBUS connection, works perfectly.
Has any progress been made incorporating CRSF and Telemetry with MSH? The original request was nearly 1.5 years ago. ExpressLRS has made some amazing gains in that time including 1000hz packet rates, 16 fully proportional channels. ExpressLRS hardware is getting serious now with dual antenna receivers, and now true dual receivers.
ELRS with CRSF should now be considered not only mainstream, but more advanced than other--more stagnant--protocols. Please offer some guidance as to when CRSF will be available.
Thanks
The CRSF protocol with associated telemetry has already been developed and tested and will be released with the next firmware and software update that we are still working on for other things.
This is even though we do not understand the interest in a "Long Range" protocol which in the Eli RC sector is not needed since Eli RCs are inherently unstable and therefore one must always keep them partially close in order to distinguish their attitude and be able to constantly correct it.
Also, during development we noticed that unlike all other radio systems, when removing and re-energizing the transmitter, there is no "Fast reconnect" as with other protocols but the time to reconnect between transmitter and receivers is very, very long and therefore the time to lose control of the model is long enough to cause a crash which sometimes could happen on things or people. Therefore, it only takes a short glitch in the transmitter or transmission module power supply or receiver power supply to cause secure damage.
We have also seen with different transmitter modules and with different receivers that with the current firmware approximately every 200 transmitted frames there is a total absence of an entire frame. If there are radio disturbances at that time the absence of an entire frame that could compensate for disturbances in the data of previous and subsequent frames would reduce the possibility of data reconnection.
Also with regard to the ESC telemetry data that can be transmitted from the model to ground, it is extremely limited compared to all other protocols: No RPM, no ESC Temperature, no ESC Power Output, no Global Vibrations, etc.
But above all, the maximum resolution of the control channels is very low: 10 bits (1024 steps) compared to other radio systems that have a quadruple resolution with 12 bits (4096 steps)
The request for CRSF isn't for long range, it's primarily due to the rapid rise in good quality and inexpensive transmitters and receivers using the open-source RC link known as ExpressLRS. They have expanded into conventional aircraft recently with 8, 12, and 16 channel full resolution modes that operate at up to 333hz packet rate.
Radiomaster is including it as an option for the primary RF module in their newest line of radios, such as the TX16S Mark 2, TX12 Mark 2, and Zorro. In addition to several small and cheap ELRS CRSF receivers, they have also released a pair of PWM receivers for use in conventional fixed wing aircraft.
To keep everything simple and efficient, ExpressLRS only uses CRSF (except for the PWM receivers, of course). So CRSF is needed to use this very appealing RC link.
Thank you for continuing to work on it even if you disagree with the premise.
@customercare it looks like the list of available sensors in CRSF is limited to 22 sensors, i wonder how are you going to implement the other Brain2 sensors like: RPM, Global Vibrations, ESC Temperature, Throttle Input, Power Output, Etc.
The lag to connect should really only happen on first connect. The Rx cycles through all the packet rates till it finds the tx rate. If you build your Rx firmware with lock on first connection checked. It should relink fast if you failsafe, which you really shouldn't happen.
There's also a change coming for Rx to save your packet rate and make initial connection way faster. I tested this morning and it's very fast on initial connect.
Thanks again for adding crsf support. I super appreciate it.
Concerning telemetry, all I need is current.
Hi Does anyone use crossfire with msh brain? Does the telemetry work well?
I am also very interested in an update of CRSF with Telemetry support.
Not because of Crossfire, but because of ELRS (ExpressLRS). I wanted to build my new heli on ELRS, but the lack of support in Brain makes this a hard decision.
I do not want to buy a different FBL, but at the same time I really wanted to test ELRS.
This is even though we do not understand the interest in a "Long Range" protocol which in the Eli RC sector is not needed since Eli RCs are inherently unstable and therefore one must always keep them partially close in order to distinguish their attitude and be able to constantly correct it.
ELRS has many advantages which are NOT long-range related. For me, the ones I am interested in are:
- very highly configurable protocol, allowing me to fine tune the RF link as I want (both uplink and downlink)
- high packet rates
- stable open-source protocol with many RX (and TX) modules on the market (availability)
As an example, using ELRS "Full Res 12ch Mixed" mode at 333Hz packet rate is perfect for a helicopter - I get 3ms latency (for example, Spectrum DSMX works in best cases at 11ms, but is channel limited in that mode).
In this mode I would get low latency and great link quality since distance is not a factor with Helis.
The only thing missing here is support for telemetry over CRSF (the Brain -> RX protocol) in Brain.
We feel it is necessary, correct, and proper to be clear from the outset with users who have to decide whether or not to use our flight controllers:
As a result of numerous requests sent to us by a small group of users, we had decided to purchase TBS modules and receivers and invested many, many, many hours of work in the development and testing of the CRSF protocol reception and related telemetry.
The CRSF protocol was released with version 3.4.081 in early October 2022.
Today, more than three months after the release, we see that out of several tens of thousands of active flight controllers (those that compared to all those sold are still being updated by users) only 4 users are using this protocol.
Consequently, for now we will not invest more money and man-hours for a "sub-protocol" of Crossfire requested by only a couple of users.
I am also like to move many of may stuff to ExpressLRS,
I do not fly long range, but I found this protocol to be very reliable, match more that the currently used (FrSky ACCST)
and some of the receiver deliver "true diversity" , meaning the receiver choose the antenna with the best quality all the time instead of just before control lost.
however, having said that, I think that expressLrs is NOT yet ready for planes and Heli (my opinion)
it lacks many telemetry sensors (not RPM, only one temp, no vibration,...)
it does not have failsafe (the developers do not like to add it into the RX itself)
it would be nice to have it for the future, as the missing part in ELRS will be implemented
JMHO
it does not have failsafe (the developers do not like to add it into the RX itself)
ELRS has failsafe of course. Through CRSF, it sets the failsafe flag correctly, so Brain knows there is a failsafe.
What you mean I assume is that you can not set channel values during a failsafe.
This is completely fine - Brain IGNORES channel values during failsafe anyway.
Brain FAQ Q24: https://www.msh-electronics.com/faq/
So failsafe is not an issue and will work like with any other RX.
it lacks many telemetry sensors (not RPM, only one temp, no vibration,...)
Telemetry is an issue - and is what is being discussed in this topic.
I think the MSH team is being very short-sighted in deciding to ignore ELRS.
The industry is clearly headed towards ELRS as the main RC communication protocol.
If you look at quads and planes, ELRS is used in a majority of new builds.
