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

[rabbitambulance-ra]

This would be an amazing initiative! CRSF is the de-facto RC link wire protocol standard, so memorializing it, formally documenting it, and extending it in a thoughtful collaborative way would be a huge benefit to the entire FPV community, and further cement TBS as a thought and market leader in the hobby!

[ZZ-Cat]

I am absolutely backing this, 100%. I would love to see CRSF properly listed (perhaps in its own repository?) with its own documentation (regarding specifications on control data, telemetry data, configurations etc) as an open-source protocol.

FPV pilots are not the only ones that use CRSF & (by extension) Crossfire & ExpressLRS.
I am among the few helicopter pilots that use this protocol either with Crossfire or ELRS hardware.

I know for a fact that Spektrum did precisely this with their SRXL2 protocol.
If they can do it, so can you. If more manufacturers listed their RC protocols under open-source licenses (Such as the GPL) & released the appropriate source material for it, there would be no need for anyone to reverse-engineer the protocols. All someone would need to do is look the protocol up on GitHub & build their project from there.

At this point, it's a win-win for everyone. =^/.~=

[wvarty]

I know for a fact that Spektrum did precisely this with their SRXL2 protocol. If they can do it, so can you.

Similar case with mavlink as well:
https://github.com/mavlink/c_library_v2

They even have code generators for a range of other languages, and a full online developer docs wiki.

[ZZ-Cat]

I know for a fact that Spektrum did precisely this with their SRXL2 protocol. If they can do it, so can you.

Similar case with mavlink as well: https://github.com/mavlink/c_library_v2

They even have code generators for a range of other languages, and a full online developer docs wiki.

Noice. =^/,..,^=

[damosvil]

Hi all,

Please, we from Bluejay team would like to add some telemetry signals per motor, up to 8 motors. By order of priority we would like to add the signals below to the CRSF protocol telemetry. ESC status, ESC temperature, and ESC current are the most prioritary ones.

• ESC status: 8bit
  -- Demag event: 1bit
  -- Desync event: 1 bit
  -- Stall event: 1 bit
  -- Gap: 1bit
  -- Max demag metric: 4bit [0-15]: It gives a clue on how well a ESC is doing commutation. [0-5] good, [6-10] average, [11-15] bad
• ESC temperature: 8bit [0-255]ºC
• ESC current: 8bit [0-255]A
• ESC demag metric: 8bit [0-255]: Current demag metric
• ESC voltage: 8bit [0-255]: 0-63,75V step 0,25V
• ESC debug/custom value 1: 8bit [0-255]
• ESC debug/custom value 2: 8bit [0-255]

We have defined an open spec for extended DSHOT telemetry here: betaflight/betaflight#12170 (comment)

Now status information from ESCs can be sent to the flight controller and blackbox. We think that it may be very useful that this info can be also sent and logged in the radio, so pilots can know when something wrong is happening to the motors during/post flight.

[tbs-trappy]

I'm down, and we're open to adding functionality as well as define some rules around how it all must work, predominantly revolving around how frames should be structured when leaving your ecosystem and entering another.

I am stretched incredibly thin at this moment (it should improve in about 2 weeks 😂) and thus I will simply not be able to devote a lot of time to the discussions.

As a general guideline we will not reserve ranges for certain projects but focus on the use case itself - tribalism is toxic and the protocol should reflect a solid stance against it. E.g. There are no ardupilot reserves in the project, but there are reserved ranges in mavlink.

So, I like the Bluejay proposal but it should be discussed with other ESC projects and consider their needs. Then drafts can then be published online and/or sent to me and I will make some time to sit together on a zoom call with those involved in the proposal to hash out some details. Then we move from there.

Sounds fair?

[sugaarK]

We are up for this too over at Betaflight. It makes sense to have its own repo

[JyeSmith]

Great news... and 2 weeks is a good time frame :D

100% any proposals needs to be discussed with users to get the best out of any additions to the protocol. This is where a public repo will be beneficial. Proposals like above from BJ can then be bashed out with other ESC developers.

[CapnBry]

I'm all for collaboration on this as well. I had written up some protocol documentation mostly because people kept asking about it and it was easier to direct them to a webpage (and never hear from them ever again) than to explain it (and never hear from them again). All information was just from reverse engineering and existing source code, so it is possible it isn't fully accurate.
https://github.com/ExpressLRS/ExpressLRS/wiki/CRSF-Protocol

We've also internally started a document about items that need new telemetry IDs and structures as well, so there's even more to contribute in that respect. I also coerced EdgeTX into supporting a non-CRSF-standard extension to the Baro Altitude item to optionally include VSpd in it as well to increase the update rate by not having to send two different telemetry items. We could also consider making other items variable length as well like maybe the battery status one to be VBAT [CURR [FUEL [CAP]]] or not going up to 3276.8V and instead having two decimal places if the high bit is set.

Look at me going on about ideas prematurely. Anyway, I am here to help and have written 4 or 5 different CRSF parser implementations in different languages to assist other projects, so I've got a decent amount of experience to contribute. Also +1 to Trappy's sentiment about "reserved ranges for projects" as I have been strongly opposed to making ExpressLRS-specific extensions to CRSF. The beauty of it is that so many projects support the protocol and if it starts to get splintered by over-eager developers just changing things willy-nilly, then everyone suffers a patchwork of partial support and Bad Experience(tm).

[andyp1per]

@tbs-trappy sounds great! Do you think it would be possible to publish the existing CRSF spec?

[hydra]

As a person deeply involved with the FPV/RC scene across many different projects and as a manufacturer (SPRacing) I would like to see CRSF publicly documented, improved and iterated upon.

As a general guideline we will not reserve ranges for certain projects but focus on the use case itself - tribalism is toxic and the protocol should reflect a solid stance against it.

@tbs-trappy I fully agree with this, to a point where I would like to also see the 0x7A MSP_Request, 0x7B MSP_Response and 0xAA CRSF MAVLink envelope be renamed to Passthrough Request, Passthrough Response and Passthough Chunk (respectively) as technically not just for MSP or MAVLink but any data you care to send through the link. There would not need to be any changes to existing users of the packets. The documentation could hint at, or reference, existing projects that use these packets.

Additionally, I would also like to see reference implementations of the protocol published. Referring to all the various implementations of the protocol is no-good.

Please, we from Bluejay team would like to add some telemetry signals per motor, up to 8 motors. By order of priority we would like to add the signals below to the CRSF protocol telemetry. ESC status, ESC temperature, and ESC current are the most prioritary ones.

@damosvil what I can foresee happening here is the same thing that happened with MSP and other telemetry protocols (ltm, frsky, smartport, hott, etc), in that over time the data that you want in the telemetry will change, and then people will need to add more things to it and old legacy items will remain around for a long time with no clear deprecation path and lots of code to handle various different iterations of the protocol, which is also a nightmare for testing too.

Also, you're forgetting the single MCU, single-uart, 4-in-1 ESC use-case.

There are better ways to do this:
a) use pre-existing pass-though command (as above) and define your own telemetry packets and pass them through to the client end, no protocol changes required.
b) define a list of things that /can/ be sent, perhaps with a 4 byte identifier for each item, then add generic telemetry discovery request/response, telemetry selection, telemetry broadcast, telemetry request and telemetry response to the protocol, which once written will never need to change in the protocol itself, which is then low-maintenance and future-proof. Only the list of things will be added to, and then it's up to implementors of CRSF devices to send/receive/support just the items from the list that they want to.

e.g.

FC -> Sends Telemetry Discovery Request.
ESC -> Responds with Telemetry Discovery Response with a list of things it /can/ send and how many of them there are: for a single ESC this might be [(ESCN, 1), (EDMG, 1), (EDSY, 1), (ETC8, 1), (EC16, 1), (EV16, 1)], for a 4-in-1 ESC this might be [(ESCN, 4), (EDMG 4), (EDSY, 4), (ETC8, 1), (EC16, 1), (EV16, 1)].
FC -> Sends one or more Telemetry Selection Request, with an index, the frequency of the telemetry packet or zero to have it sent when the event occurs, and a list of the things the FC wants in each telemetry packet [(identifer, index), ...].
ESC -> Remembers each Telemetry Selection Request.
ESC -> Periodically sends a Telemetry Broadcast packets, with the index, and the payload contains the items requested, in the order they were requested, as a bit sequence.

then later, the FC may:

FC -> Send a Telemetry Request with a reference, and list of specific items from the list.
ESC -> Responds with a Telemetry Response with the same reference, and the list of specific items.

Some telemetry need to be sent at a high rate, some things can be sent less frequently so that flight controllers can manage the workload better, some things need to be sent when they happen.

Length-in-bits could be included for each item in the Telemetry Section Request so that if future ESC firmware does not support that identifier it can still create the response packet with all the bits set to zero. e.g. [(identifer, index, length-in-bits), ...]. This could help with compile-time requirements on the receiver/FC side. e.g. use of C structures for unpacking.

The latter use-case would be for a disarm stats page on the OSD or for recording into flight logs.

For your example of an ESC telemetry packet, it can be constructed exactly as you want it, bit-for-bit, given appropriate telemetry items.

-ASCII 4 byte identifier-	-Length in bits-	-Description-
ESCN	8	ESC number (for example, a 4 in 1 ESC would use numbers 0-4 by default)
EDMG	1	1 = Demag event, 0 = No event
EDSY	1	1 = Desync event, 0 = No event
ETC8	8	ESC temperature, in C with a 50 degree positive offset, e.g. 0=50 Degrees C. (u8)
EC16	16	ESC current, in mA, (u16)
EV16	16	ESC voltage, 0 = 0.00V, 1 = 0.01V (u16)

and so on.

Using a u16 instead of u32 (4 ascii bytes) for the identifier would be ok, but then any code that needed to display the identifiers (like EdgeTX, transmitter modules/backpacks/etc) would need to maintain a list of the identifiers in ASCII (4 bytes) and the corresponding 2 bytes for the u16 identifier which takes up more flash space on already-space-constrained devices.

The only hard part is agreeing what should be on the list, but the list can have a reserved range or IDs for development purposes, e.g. 0xF0000000 to 0xFFFFFFFF.
The items on the list can be updated, released and versioned INDEPENDENTLY from the main protocol and frame formats.

Remember that protocols are hard to change once designed, and that there is a high cost to any change to it, as such the protocol should be flexible and future proof.

[hydra]

Further to the idea of passthough request/response packets, here's a short conversation from discord.

[8:22 PM]Rodrigo Maia: Your pass-through packet idea makes a lot of sense. This way, any use-case specific data could be sent through those packets without needing to change the “macro” protocol.
[8:24 PM]hydra: yeah, I think the only thing missing would be an initial 2 or 4-byte slot for the 'protocol identifier', so that recipients of any 'passthough packet' could know what is being sent, and process/ignore it as appropriate  a bit like a TCP port number I guess. 
[8:25 PM]hydra: the 'protocol identifier' list could be a known thing, e.g. 1 = BF MSP, 2=MAVLINK, etc.
[8:25 PM]hydra: maintained along with the telemetry identifiers list from my example.
[8:26 PM]hydra: again, no protocol changes required for any future things that might need to be sent.
[8:26 PM]Rodrigo Maia: Exactly!!
[8:26 PM]Rodrigo Maia: This also effectively “offloads” the implementation of these specific packets to whoever needs them, the original protocol maintainers (and also all the other users) don’t need to worry about it.
[8:26 PM]hydra: just a web-site update to add the new identifier.
[8:26 PM]hydra: yes, exactly @Rodrigo Maia
[8:26 PM]hydra: less work on faffing around with protocol changes = more time to do more cool stuff.
[8:27 PM]Rodrigo Maia: For sure!!

"hydra: yeah, I think the only thing missing would be an initial 2 or 4-byte slot for the 'protocol identifier', so that recipients of any 'passthough packet' could know what is being sent, and process/ignore it as appropriate  a bit like a TCP port number I guess."
[8:28 PM]Rodrigo Maia: Yeah, I agree! Unless that could be somehow sent together with the payload bytes…
[8:28 PM]Rodrigo Maia: I mean, as part of the payload.
[8:31 PM]hydra: No, it would need to be sent for each chunk.  as a passthough item can be split over multiple frames, so each frame needs <protocol><sequence> in order to be either recombined or ignored.
[8:32 PM]Rodrigo Maia: Oh yes, that’s true, you are totally right!

[hydra]

For those following along with the telemetry side of things, I wrote a proposal for how to solve the same problem on the DShot telemetry side of things here:

bird-sanctuary/extended-dshot-telemetry#4

[hydra]

After thinking about my suggestion, for telemetry, that the approach to the FC telling the devices that can send telemetry what telemetry to send, and how frequently, it occurs to me that the exact same approach can also be taken for the RX channels, basically imagine that conceptually there is no difference between 4x 13-bit RC channels being sent 500 times a second to 4x 4in1 ESC RPM values being sent at 1000 times a second, nor is there any difference between an RC digital switch change event being sent when it occurs to an ESC Desync event being sent when it occurs.

Thus, an FC could say to a CRSF receiver:

1. 'I want 4x 13bit RX channels at 500Hz, reference 1'.
2. 'I want AUX1 to be sent when it changes, reference 2'.
3. 'I want AUX2-AUX8 to at 25hz, reference 3'.

This removes all the processing overhead of looking at the CRSF_FRAMETYPE_SUBSET_RC_CHANNELS_PACKED packet to see what it contains and conditionally branching to extract bits from difference places (i.e. this code: https://github.com/betaflight/betaflight/blob/master/src/main/rx/crsf.c#L518-L555), as it would /know/ what the data was when it receives 'reference 1' as it told the RX what to send, and this also reduces the load on the FC so it doesn't have to process AUX channels at the same rate as STICK channels.

EDIT:

FC would have to choose from a short-list (via discovery) with regards to RC data rates.
i.e. TX says -> use 500Hz for OTA, Rx says, you can have 500Hz or 250Hz or 125Hz or 50Hz, choose.
or TX says -> use 250Hz for OTA, Rx says, you can have 250Hz or 125Hz or 50Hz, choose. (500Hz is missing).

The OTA link would be unaffected if the FC picks a lower rate and the RX would downsample/filter/average as-appropriate.

Note that gyros sensors do this kind of thing via the Output Data Rate (ODR) registers which allows greater application flexibility.

[hydra]

Based on very little experience at all with CRSF, here's my shortlist of a plan for a potential V4.

1. remove all the old protocol-specific passthrough request/response frame types.
2. remove all the old RX frame stuff.
3. remove all the old telemetry frames.
4. deprecate all the old TBS device addresses with a permanent removal 1 year from now, fully define a complete list of device ids for future improvements.
5. add discovery/subscribe/request/response for TLM
6. add discovery/subscribe/request/response for RX.
7. clearly define baud rate negotiation and fallback for both RX and FC, including how to communicate successful negotiation with the user prior to any arming, in addition to adding telemetry items for RX->FC baud rate and negotiation status that can be sent back to the user's TX.
8. ensure that RX baud-rate negotiation can be completely disabled if the user wants to. e.g. in RX firmware, FC firmware, or communicated OTA from TX to RX.
9. add new passthrough frame types with a protocol id that work for ANY data.
10. define a shortlist of protocol ids.
11. define the list of telemetry items based on all existing items so that data for telemetry frames can be converted, with example data for each.
12. define the list of RX items based on all existing items so that data for RX frames can be converted, with example data for each.
13. include the protocol version in the heartbeat frame.
14. clarify naming of RX/TX/Uplink/Downlink/Statistic telemetry items. e.g. not 'rssi_db' but 'rssi_uplink_db' and 'rssi_downlink_db'.
15. ensure that all frame could be represented as packed structures with bitfields in C code, inlike the 'Subset RC channels Packed' frame which cannot and always has to be manually extracted which means the programmer has to write code to do it, instead of defining a structure that 'just works' when compiled. Also applies to frames than can be received after a subscription, also C allows only one variable length item allowed at the end of the structure.
16. provide a reference implementation in C for everything.
17. clear documentation on routing capabilities, e.g. data flow and example packets from accessory sensor connected to an RX all the way though to the TX module and to the TX itself.
18. clear and valid example packets for every frame.

[damosvil]

@tbs-trappy Hello Trappy,
how are you?
please, could you give us all any update?

[tbs-trappy]

I am in the middle of something quite major here, as I indicated above. I have privately messaged hydra already. My thing here could take quite some time to resolve, but I will post the highlights of my opinion on this here.

1. I do not believe that existing CRSF implementation should be changed at this moment. Also, I do not agree that historically implemented message types should see any modifications in terms of scope. There is a lot of legacy code, and that is the core value of the protocol. So, while I do see the technical value, expansion of scope and growth of the protocol has been considered and there are plenty of ways to expand on the protocol without alienating legacy systems. So, fundamentally new ideas should be applied to NEW frames, and deprecation much further down the road.

2. Removal and deprecation of functionality or devices/device addresses is neither necessary nor desirable. It will force users to upgrade, which is not what they want (I have the death threats to prove it :) ).

Everything else is a great idea, and I'm definitely for it. Just please keep in mind that there are a large amount of use cases outside of our fairly niche hobby, and CRSF has expanded well into other areas.

Apologies for being brief, I will commit more attention as time allows.

[damosvil]

@tbs-trappy Thanks for your answer.

Then I think that we all could continue building a proposal, and then if you want to add something later you could still do.

[wvarty]

I am in the middle of something quite major here, as I indicated above. I have privately messaged hydra already. My thing here could take quite some time to resolve, but I will post the highlights of my opinion on this here.

1. I do not believe that existing CRSF implementation should be changed at this moment. Also, I do not agree that historically implemented message types should see any modifications in terms of scope. There is a lot of legacy code, and that is the core value of the protocol. So, while I do see the technical value, expansion of scope and growth of the protocol has been considered and there are plenty of ways to expand on the protocol without alienating legacy systems. So, fundamentally new ideas should be applied to NEW frames, and deprecation much further down the road.
2. Removal and deprecation of functionality or devices/device addresses is neither necessary nor desirable. It will force users to upgrade, which is not what they want (I have the death threats to prove it :) ).

Everything else is a great idea, and I'm definitely for it. Just please keep in mind that there are a large amount of use cases outside of our fairly niche hobby, and CRSF has expanded well into other areas.

Apologies for being brief, I will commit more attention as time allows.

I agree with both of your points.
The intent of this thread is primarily to create a place where we can start having these discussions, alongside a well documented protocol spec, where people can start raising git issues for discussions, and pull requests for suggested changes, which can then be reviewed by TBS as well as the community that use the protocol.
The first (and relatively simple) step is to get the protocol spec up onto github.

1. Is this something that TBS would like to own as a github repo? Or shall we look at kicking something off?
2. Is there anything we can do (as the OS community) to help build the existing spec documentation?
3. Is this a valid approach?

[tbs-trappy]

Agreed. If I could do this right now, I would. If I could give the reasons for why I can't, I would. I need a bit of time, please continue on the new proposals for now I'll be back to my old self hopefully soon.

[andyp1per]

• I do not believe that existing CRSF implementation should be changed at this moment. Also, I do not agree that historically implemented message types should see any modifications in terms of scope. There is a lot of legacy code, and that is the core value of the protocol. So, while I do see the technical value, expansion of scope and growth of the protocol has been considered and there are plenty of ways to expand on the protocol without alienating legacy systems. So, fundamentally new ideas should be applied to NEW frames, and deprecation much further down the road.

• Removal and deprecation of functionality or devices/device addresses is neither necessary nor desirable. It will force users to upgrade, which is not what they want (I have the death threats to prove it :) ).

Agreed.

I actually have much more modest goals than loads of new features - I just want us all to converge first on what exists rather than diverging. A great example is ELRS baudrate vs CRSF baudrate - simple stuff, but convergence benefits us all. Otherwise I have to spend loads of time fixing bugs because of divergence. Simply publishing the spec will pretty much solve this 😄

[hydra]

Another one for my CRSF v4 list is:

• make the 'frame length field' match the actual length of the frame, rather than the length of the frame excluding some parts of the frame - it's caused bugs; is not well described in the spec; and wastes cpu cycles and code/flash space by having to check both the minimum (2) and maximum (62) value of it when decoding frames; wastes cpu cycles and code/flash space when calculating it when creating frames; lends to needing a unnecessary constants; and that the maximum value isn't the same value as the buffer size one needs to store a complete frame (64).

The spec says:

Broadcast Frames:
<Device address or Sync Byte> <Frame length> <Type><Payload> <CRC>
Extended header frames:
<Device address or Sync Byte> <Frame length> <Type><Destination Address> <Origin
Address> <Payload> <CRC>

Frame length:                         Amount of bytes including Type, Destination and
                                      Origin address for Extended header frames frames,
Payload and                           CRC (uint8_t). Valid range is between 2 and 62. If this
                                      uint8 value is out of valid range,the frame must be discarded.

Note: TBS document formatting makes it even harder to grok!

Here's an example bug: CapnBry/CRServoF#28

😒

If there was a good reason for it being the way it is, I'd love it hear it.

[andyp1per]

• make the 'frame length field' match the actual length of the frame

This is pointless breakage. Frame length is perfectly clear and works well - its everything apart from sync and frame length. So when you are decoding it represents the rest of the bytes you have to decode.

Making changes like this would create a different protocol and the whole point here is to converge on the existing protocol.

[hydra]

@andyp1per yeah, I'm aware that would be a breaking change for sure. Just throwing it out there really. I understand that it represents the rest of the bytes you have to decode, if you're receiving into a buffer you have to calculate offsets from the start of the buffer based on the frame length minus 2, which is annoying as the -2 is an operation that is unnecessary. you also have similarly issues when you're encoding. When you're validating the frame length you can't just write bool valid = frame_length <= 64 you have to go bool valid = frame_length > 2 && frame_length <= 64-2. Sure the 64-2 is compile time, but the > 2 and the && are not, they are extra operations, extra instructions, extra code to maintain and ensure is correct, extra tests to write, slower compile times, slower execution times, etc. It's not optimal.

I guess the question in my head is "When is a frame length not a frame length", which with CRSF is currently "100% of the time", as opposed to "never", the latter being the correct answer to the question in my head. Maybe I'm weird, but that's how I see it.

[JyeSmith]

1. Is this something that TBS would like to own as a github repo? Or shall we look at kicking something off?

2. Is there anything we can do (as the OS community) to help build the existing spec documentation?

Not wanting to let this become stale should we look at starting a community repo? There appears to be a few discussions/PRs referencing this thread and a heap of interest.

We can open a repo and invite a number of other project members to be a part of it, including TBS as an owner. Addition would require 3-4 approvals to make sure changes are well discussed and thought out?

[hydra]

Not wanting to let this become stale should we look at starting a community repo? There appears to be a few discussions/PRs referencing this thread and a heap of interest.

We can open a repo and invite a number of other project members to be a part of it, including TBS as an owner. Addition would require 3-4 approvals to make sure changes are well discussed and thought out?

@JyeSmith Just start it, I'm sure the community here and TBS will follow. It's also possible to transfer ownership of a repo on github if needed.

[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 betaflight/betaflight#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 => #26 (comment)

[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 betaflight/betaflight@d5af7d2

[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.

[radio-mistress]

https://github.com/tbs-fpv/tbs-crsf-spec/blob/main/crsf.md

648 days, Mercury has a day length of about 58.65 Earth so this took about 2 weeks on Mercury.