search

tbs-fpv / freedomtx

FreedomTX custom firmware for Transmitters
GNU General Public License v2.0
61 stars 8 forks source link

CRSF Protocol Repo #26

Open JyeSmith opened 1 year ago

JyeSmith commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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.

We have defined an open spec for extended DSHOT telemetry here: https://github.com/betaflight/betaflight/pull/12170#issuecomment-1377629914

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 commented 1 year ago

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 commented 1 year ago

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

JyeSmith commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

hydra commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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:

https://github.com/bird-sanctuary/extended-dshot-telemetry/issues/4

hydra commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

tbs-trappy commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

  • 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 commented 1 year ago

Another one for my CRSF v4 list is:

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: https://github.com/CapnBry/CRServoF/issues/28

😒

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

andyp1per commented 1 year ago
  • 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 commented 1 year ago

@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 commented 1 year ago 
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 commented 1 year ago

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.

tbs-trappy commented 1 year ago

give me a few more days please. I'm literally at the tail end of "this thing" that I need to get taken care of.

hydra commented 1 year ago

@tbs-trappy What's the latest?

hydra commented 1 year ago

@tbs-trappy What's the latest? A 'few more days' was over a month ago now.

@JyeSmith It's been 3 months since your thought about starting a community repo, perhaps now is time?

Please note I'm not trying to be pushy here, just that the community needs to see some movement on this before the community goes 'rogue' and TBS will be left in the position of following community-based standards instead of helping to create them.

tbs-trappy commented 1 year ago

There has been a major shakeup here at TBS the past 12 months (this week is basically the first time I can even publicly acknowledge it) and I've been cleaning up the aftermath of it for the last 2 months, running 120+ hour weeks (will do a livestream going into a bit more detail as soon as the new studio is set up).

It's not on the back-burner, I'm just not sleeping much (or well) these days and I've got obligations that do not come with a negotiable timeline. Someone is working on a draft, and my goal is to have it ready before I depart for IO in 4 days. Speaking of which - anyone going? I'm looking forward to the 18 hour flight to get some sleep :)

JyeSmith commented 1 year ago

Sounds like a plan. 4 more days and the community will have a repo to start discussing contributions :ok_hand:

limonspb commented 1 year ago

There has been a major shakeup here at TBS the past 12 months (this week is basically the first time I can even publicly acknowledge it) and I've been cleaning up the aftermath of it for the last 2 months, running 120+ hour weeks (will do a livestream going into a bit more detail as soon as the new studio is set up).

It's not on the back-burner, I'm just not sleeping much (or well) these days and I've got obligations that do not come with a negotiable timeline. Someone is working on a draft, and my goal is to have it ready before I depart for IO in 4 days. Speaking of which - anyone going? I'm looking forward to the 18 hour flight to get some sleep :)

Hello Sir! I'm coming to IO and can't wait! Looking forward to shake your hand! :) But I'm from Betaflight, not edge tx/freedom tx, so maybe you won't want lol

tbs-trappy commented 1 year ago

Hello Sir! I'm coming to IO and can't wait! Looking forward to share your hand! :) But I'm from Betaflight, not edge tx/freedom tx, so maybe you won't want lol

eeew, betaflight! lol j/k. see you there!

CapnBry commented 1 year ago

Argh, both Trappy and Limon gonna be at IO? (figures out how long it will take to drive there) 😣

kamik2 commented 1 year ago

short update: i'm working on the public version. should be online in the next few days (md formatting is a PITA)

tbs-trappy commented 1 year ago

lol was just about to dm you on whatsapp to give an update here. thanks! let me know when it's ready, the software devs need to give it a final once-over to see if it's all correct.

hydra commented 1 year ago

@kamik2 @tbs-trappy Any update?

kamik2 commented 1 year ago

its in review atm. shouldn't take too long now

sugaarK commented 1 year ago

its in review atm. shouldn't take too long now

2 weeks ?

kamik2 commented 1 year ago

iirc raphael on vacation atm. so 2 weeks could be correct^^

howels commented 1 year ago

2 weeks?

CapnBry commented 1 year ago

For all the people really leaning on someone else to get this started, what are you waiting for? Where is the collaborative system we're all going to be working to revise? Where are your RFC documents explaining the extensions to CRSF you'd like to add, their packet structures and definitions of payload fields? I do not count a google doc that is just a list of 3 word ideas.

If the whole point of this is to create some sort of forum, discussion, and process for requesting your changes to the protocol then that shouldn't rest on TBS's shoulders. You're (we're) asking for changes to something that currently has very wide adoption and the implementations for which are feature complete on almost every platform. This is going to be a slow process-- it may take a year or more from an idea to that idea being implemented in a release firmware for many of the projects that needs to support it. Great care must be taken or else CRSF will just become a patchwork of maybe-supported things across different firmwares that then creates a terrible user experience as they try to figure out how device X implements feature Y if at all.

So for everyone who keeps asking "when?" shut the fudge up and start doing your part already, and as part of that, work with each other create the necessary organizational structure, proposed ratification process, wishlist tracker, specifications trackers, future documentation repositories, etc. I don't think just a Github repo and a shared google doc is enough. The ball is also currently in your court, but it seems you're just waiting for someone else to do it all for you and keep complaining about it not happening fast enough.

howels commented 1 year ago

For all the people really leaning on someone else to get this started, what are you waiting for? Where is the collaborative system we're all going to be working to revise? Where are your RFC documents explaining the extensions to CRSF you'd like to add, their packet structures and definitions of payload fields? I do not count a google doc that is just a list of 3 word ideas.

If the whole point of this is to create some sort of forum, discussion, and process for requesting your changes to the protocol then that shouldn't rest on TBS's shoulders. You're (we're) asking for changes to something that currently has very wide adoption and the implementations for which are feature complete on almost every platform. This is going to be a slow process-- it may take a year or more from an idea to that idea being implemented in a release firmware for many of the projects that needs to support it. Great care must be taken or else CRSF will just become a patchwork of maybe-supported things across different firmwares that then creates a terrible user experience as they try to figure out how device X implements feature Y if at all.

So for everyone who keeps asking "when?" shut the fuck up and start doing your part already, and as part of that, work with each other create the necessary organizational structure, proposed ratification process, wishlist tracker, specifications trackers, future documentation repositories, etc. I don't think just a Github repo and a shared google doc is enough. The ball is also currently in your court, but it seems you're just waiting for someone else to do it all for you and keep complaining about it not happening fast enough.

I was really only hoping for TBS to document the current CRSF protocol according to their expectations, or bless the version available at https://github.com/ExpressLRS/ExpressLRS/wiki/CRSF-Protocol.

hydra commented 1 year ago

I was really only hoping for TBS to document the current CRSF protocol according to their expectations, or bless the version available at https://github.com/ExpressLRS/ExpressLRS/wiki/CRSF-Protocol.

yeah, same here, I'm waiting for the official version of the spec to be published so that others can then clearly describe the changes (RFCs) that they want to implement so that discussions can be had around proposed changes by interested parties, that is specifically what /I'm/ pushing for every so often.

@CapnBry is correct in saying that there are other things that can be done, such as setting up not-for-profit community-run organization to which pledges can be made by hardware and software vendors, such as is done via the likes of OpenPLEB (https://openpleb.org/). Would TBS commit to something like that?

David-OConnor commented 1 year ago

My 2c:

Trappy said no.

It's up to the ELRS team (and others?) if they want to exclusively use CRSF (in its current form) indefinitely. The answer appears to be yes. There's, perhaps not a compelling advantage to breaking compatibility with FC firmwares like BF, AP, and PX4, who would have to be lobbied and won over re any change. (Maybe not too difficult, but hard to say, and on what timeline)

In my devices where applicable, I'm implementing dual protocols, configurable as to which to use: The standard (eg DroneCAN), and custom ones when I think they offer value.

Another thing to consider: Let's say Trappy is on board for a change; relevant documents get updated or created declaring an update to the spec; IMO that is not the critical part. You'd still need to get the FC firmware stakeholders on board. I think an official update from CRSF would make that easier, but it's neither necessary nor sufficient.

CapnBry commented 1 year ago

@CapnBry is correct in saying that there are other things that can be done, such as setting up not-for-profit community-run organization to which pledges can be made by hardware and software vendors

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. Nobody should do that. I'm saying there is no infrastructure or anyone even proposing any sort of system for coordinating. You don't need a formal spec or donated money to propose a solution. A git repo is not really a collaborative work environment apart from code, and this isn't code, it is a protocol definition.

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.

f a good system is put in place it will be easier to evaluate proposals in a manner that is more comprehensive than a GitHub issue list.

kamik2 commented 1 year ago

short update:

atm i don't get any reply from him so I guess he is on his "vacation" (mentioned in the last lounge episode)

andyp1per commented 1 year ago

He is definitely on vacation - back soon

damosvil commented 1 year ago

After listening Trappy in their recent interviews, for a company that has to pay the salaries of their employees, and that is in process of diversifying their products, I don't know to what extent they may be interested in dedicating resources pushing a standard for a product that may not be the start of revenue.

I think that CRSF is a protocol that has gained enough critical mass that it no longer has to be managed by the creator of it. Maybe this is the time TBS can let it go but continue collaborating to enrich it.

In my opinion more than trying to implicate TBS to extend CRSF protocol the community should try to find a place to centralize the improvements efforts.

tbs-trappy commented 1 year ago

Answer is pretty simple: most of it is ready, but I'm desperately trying to get some days off. it's my first time I get some R&R in over 6 months (that includes weekends), and of the 10 days I've been on holidays I've only spent 4 days not working. I land on Friday night 10pm and will be back to the office by 10:30pm, and I'll be spending time to get this finally out the door then.

The current status: the standard has been properly converted to MD format (was way more work than expected :( ) and while I've been away my team has been looking over this stuff, and they will have feedback by the time I get back that we will integrate and then we'll publish the standard as it stands.

In the meantime, as others have mentioned, the process of how changes are to get drafted, discussed, voted, implemented is still unclear. I have been looking into how other standards do this stuff, but I'm happy to take suggestions into consideration before we set that in stone.

Thanks for your patience on this and sorry for not delivering on time. Life has been a rollercoaster lately, and I'm trying to navigate my body through all of this without too much permanent damage. I will say Europe has been a blast but I'm looking forward to go back to a faster pace of life :)