CRSF Protocol Repo

[JyeSmith]

Hi @tbs-fpv

Over time there have been a number of requests to make additions to the CRSF protocol. Most recently in mind was the addition of the 50mW to power level. Since then there have been more suggestion from various project maintainers, and it will be great to have a central location where these additions can be raised and discussed.

Is TBS interested in opening a repo which outlines the protocols frame type, address etc? Project maintainers from Betaflight, Ardu, ELRS, Rotorflight, BlueJay and more can then open PRs for discussion. It will also be a central point of truth for the protocol which maintainers can reference.

Looking forward to hearing your thoughts.

Cheers Jye

[hydra]

While I did say there were things that could be done, setting up an organization to collect donations is so very far from what I suggested.

yeah, wasn't so much regarding any monetary, more of a place where the spec can be published and that vendors using the spec pledge that they will co-operate with others and won't sue other vendors using the spec or who make kit that's interoperable with their stuff. In the past, vendors who use proprietary protocols with trademarks, etc, have gone after companies making compatible equipment which is exactly what we don't want for CRSF.

I feel like if you're in this conversation and you don't know what you don't like about CRSF so much that you need to see a formal document to pick apart, you may be in this conversation a little early. I think it would be better to start with people who have worked with the protocol long enough to already have a plan for what they believe will provide the greatest benefit.

Indeed, I documented a bunch of things that popped into my head earlier in this thread here: https://github.com/tbs-fpv/freedomtx/issues/26#issuecomment-1438530057 some of which obviously aren't practical, but it's a list containing food for thought none-the-less.

@tbs-trappy thanks for the update. Would it be possible to make the draft specification, as it stands today, available somewhere, e.g. as a PR, so that it can be commented on and amended as appropriate?

[kamik2]

quick update: we are getting closer. imho just some fine-tuning in the document and we are done

[ZZ-Cat]

quick update: we are getting closer. imho just some fine-tuning in the document and we are done

Excellent work. Looking forward to seeing it. =^/,..,^=

[raphaelcoeffic]

@tbs-trappy @kamik2 at EdgeTX, we had to change a few things to make the parsing more robust while receiving things based on USART IRQs (lots of pressure when the baud rate gets higher). So we discussed a few boundaries on what can be done to improve framing, considering that we have no safe frame begin nor end. Loosing a couple one or two byte due to overrun can lead to disaster with multiple frame in a row being lost to finding new frame boundaries in a reliable way.

See here for more details on implications for the transport of fragmented frames: https://github.com/EdgeTX/edgetx/blob/605718acd8bcbc960aa25afb6bc1cb5d2cc21983/radio/src/pulses/crossfire.cpp#L155-L203

Please note: this code use the IDLE line detection interrupt to process complete chunks (continuous block of bytes on the transmitted at once on the wire) at once rather than an indeterminate stream of bytes without any timing /chunk context. This also allows for cutting some delay in the processing of such frames rather than using polling of the UART buffers.

[olliw42]

@tbs-trappy @kamik2

I don't want to poke into the same holes as in the above, but there is one simple basic question which I think you could answer and settle once-and-for all with less than 5 min effort, which however is SUPER annoying to not know for sure (and seems to cause continuous issues accross several projects, from small scale to large scale):

What is the baudrate for CRSF on TBS receivers?

• [x] 416666 baud
• [ ] 420000 baud

(pl click the respective check box)

Depending on the source of info, the receiver side baudrate is specified as 416666 baud or as 420000 baud. Obviously, not both can be true. The value of 416666 I mainly infer from ArduPilot, while the value of 420000 seems to be found mostly in, let's call it, "FPV related" codes, like BetaFlight, INAV, ELRS. However, it's known that TBS and ArduPilot were working closely together on the CRSF v3 implementation, which should give ArduPilot's value quite some credibility, while the code files which indicate 420000 baud include a number of false calculations which makes them appear less trust worthy. The difference is small and may not cause issues for most of the time, but situations were reported where it did/does.

The answer should be really simple for you, so I hope that you may settle this question, I would very much appreciate if you could.

Olli

(unfortunately I don't own TBS/CRSF gear, otherwise I would just measure)

[tbs-trappy]

it's 416666. The number was hashed out between OpenTX devs and the original crossfire devs in the early days, and it has never changed. We're aware of the incorrect implementations and I believe it was mentioned a few times, but "it works like that" was the general consensus :)

PS: If you need some TBS gear just shoot me an email, I'll have it sent out to you.

[olliw42]

FANTASTIC !!!

finally some official statement one can refer to. And very quick too. So much appreciated.

PS: many thx concerning the TBS gear offer, very much appreciated, I'll keep it in mind :)

[hydra]

Yeah, I raised an issue in BF regarding this, and also mentioned it to the ELRS guys who have a default of 420000.

[CapnBry]

420k baud is the most TBS baud rate I could think of. I would have put money on it.

[olliw42]

and Bertrand Russel is the Pope :D

[JyeSmith]

Gentle bump since this PR popped up https://github.com/betaflight/betaflight/pull/13119

[howels]

quick update: we are getting closer. imho just some fine-tuning in the document and we are done

Please post the protocol as we are seeing PRs like the one mentioned above which appears to reference details from the CRSF spec that aren't documented publicly and need to be verified.

[pfeerick]

@tbs-trappy I hear crickets... any movement on this?

[kamik2]

i had a talk with him about this yesterday - they are working on it

[raphaelcoeffic]

i had a talk with him about this yesterday - they are working on it

So basically the same situation as ever :-D

[David-OConnor]

I'll write a spec. We can call it CRSFv2. It will be the doc the ELRS team wrote up (CB?), but with the new additions in question, and it will be a single source of truth.

[CapnBry]

If anything should be written up, it should be exactly what the current spec is, and then what the formal process should be for making additions with a system of peer review and comments-- like RFCs.

Just dumping everyone's ideas directly into a new spec is utter chaos and good luck having any sort of support for new things any more because the spec is so wild that every RX / TX / Handset / FC / Telemetry Monitor supports some of it maybe. Nobody currently understands the protocol but they're going to immediately add things to it?

There's also already a CRSFv2, and I believe CRSFv3 (partial). Unless you were making a joke about that.

[David-OConnor]

I agree with you.

This thread is unproductive, and I'm astonished anyone's taking it seriously.

[haslinghuis]

As I like the way TBS CRSF works very much here is my personal opinion on this:

• Have seen request for official TBS API documentation for a long time.
• As ERLS is using CRSF protocl TBS could benefit from development on expanding CRSF protocol and vice versa.
• ELRS should use it's own protocol implementation with all the freedom to extend or change at will.

[raphaelcoeffic]

Ok, we've just started a draft. I hope we can get everyone on board: https://github.com/crsf-wg/crsf

[DzikuVx]

A note from my side. To make is swift, in a series of bullet points ;)

1. I'm all onboard for extending the CRSF specification and practically converting it into an open standard
2. INAV will have no problems adopting a new/extended protocol, however I can't promise swift development. You all know how open source works and when devs have time to do stuff
3. However, I'm convinced that the new/extended protocol should NOT be called CRSF. Reason is quite simple, CRSF name is tightly coupled with the TBS and brand of Crossfire. And this opens an area of questions on how much right to the name and protocol itself TBS has. Especially to the name CRSF itself. Even if it's not, the name CRSF should be treated as reserved name to avoid any legal implications. I'm not saying there will be legal implications but as long as TBS does not officially opens the protocol and the CRSF name, it have to threated as tightly coupled to the TBS. And this, considering the fact, that ELRS, BF, Ardupilot and INAV and open source projects, should be a crucial aspect

[sugaarK]

As I like the way TBS CRSF works very much here is my personal opinion on this:

• Have seen request for official TBS API documentation for a long time.
• As ERLS is using CRSF protocl TBS could benefit from development on expanding CRSF protocol and vice versa.
• ELRS should use it's own protocol implementation with all the freedom to extend or change at will.

I agree take the Current elrs implementation and expand on it. With our cloud builder it’s very easy for it to diverge from CRSF

[offer-shmuely]

is there any progress with extending the CRSF (or ELRSF/ELRS_PROT) extended telemetry and hopefully a dynamic telemetry?

[pfeerick]

This is the current WiP => https://github.com/tbs-fpv/freedomtx/issues/26#issuecomment-1858920550

[SV-Zhan-Qiyu]

@tbs-trappy Sorry, This may be a bit presumptuous,I want to know if TBS has any plans to release a new radio

[haslinghuis]

@offer-shmuely can you elaborate on what telemetry extensions.

Added https://github.com/betaflight/betaflight/commit/d5af7d2254a4c6ed04853859b3494cb33cf45fd8

[offer-shmuely]

The crsf protocol is missing a lot of telemetry sensors for heli and planes (for quad it may be enough)

For planes

• 2x6 cells voltage (like frsky)
• Voltage with 2 digits after the dot

For heli

• Flight status
• Governor status
• BEC Voltage
• Real time controller load
• Throttle
• ESC Temperature
• Headspeed (rpm)
• MCU Temperature
• vibration on roll (for heli)
• vibration on pitch (for heli)
• vibration on yaw (for heli)

I think it really need to be dynamic i.e. the tx will ask the flight controller while setup the model (discover new sensor in edgeTx) FC will respond with an array of sensors, each with all the info

• id that chosen by the fc
• name for the tx to display
• units (v/rpm/deg/...)
• precision (1/0.1/0.01)
• min
• max

So there is no extra data during flight There is no extra steps on rf connection, But the FC software (heli in mind) can expose any sensor it like to

[haslinghuis]

Would need a reference manual for implementation on betaflight firmware side.

[acbates]

For planes

* 2x6 cells voltage (like frsky)
* Voltage with 2 digits after the dot

...there's more. Need at least two temperature sensors for cylinder heads on large gassers, which is my current issue with CRSF telemetry. Four cylinder engines are less common, but two cylinders are very common. There should also be multiple current sensors; electric powertrain and other systems like radio.

A comment as much to be a nudge on the issue, but more than one temp sensor for sure needed.