CRSF baud rate is incorrect.

[hydra]

Describe the bug

The baudrate for CRSF is defined as 420,000baud. This is incorrect. Trappy from TBS confirmed to me today that CRSF uses 416,666 and always has. I've not verified this statement however.

When the wrong baud rates are uses (e.g. RX/FC mismatch) then FCs will get framing errors, data corruption, CRC mismatches and packet loss for RC channel data. (Verified by inspecting UART ISR register and looking at the FE flag).

Related information:

• Old official TBS CRSF documentation (at least up to version 7) specified a 400,000baud ("400kbaud") which was corrected in revision 10 to be 416,666baud.
• ELRS has a default baud rate of 420,000baud.

Code:
BF - https://github.com/betaflight/betaflight/blob/master/src/main/rx/crsf_protocol.h#L30
ELRS - https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/lib/OPTIONS/options.cpp#L84

Rev10 CRSF docs:

Rev7 CRSF docs:

To Reproduce

Use mismatched baud rates on RX and FC.

Expected behavior

No data corruption or packet loss for users of both TBS and ELRS receivers.

• Agreement with BF, ELRS and TBS on the correct baud rate to use.
• Notification to users that it's changed, if/when it changes.
• Added to the list of known-issues until corrected.

Support ID

N/A

Flight controller

N/A

Other components

No response

How are the different components wired up (including port information)

No response

Add any other context about the problem that you think might be relevant here

No response

[hydra]

Note that users of ELRS using SPI-based RX will be unaffected by any baud rate changes as there's no CRSF UART involved.

[hydra]

After a bit more digging, CRSF V3 users may be less affected because the baud rate is auto-negotiated, and the Rx tells the FC what baud rate to use.

However, for CRSF V3, if there are 3 CRC errors in a row after baud-rate negotiation BF will drop-back to the pre-negotiated baud rate without the receiver knowing and the receiver somehow has to handle it, but from the little information I have (in the official specs) it's unclear how the receiver is supposed to handle a baud-rate-change on the FC, if at all.

It can also do this during flight, after arming, as I couldn't find any arming status check before dropping back to the pre-negotiated baud rate.
See also:

• crc check and counter increment - https://github.com/betaflight/betaflight/blob/master/src/main/rx/crsf.c#L459-L474
• setCrsfDefaultSpeed -

  betaflight/src/main/telemetry/crsf.c

  Lines 129 to 137 in 1a6fa4d

  	void setCrsfDefaultSpeed(void)
  	{
  	crsfSpeed.hasPendingReply = false;
  	crsfSpeed.isNewSpeedValid = false;
  	crsfSpeed.confirmationTime = 0;
  	crsfSpeed.index = BAUD_COUNT;
  	isCrsfV3Running = false;
  	crsfRxUpdateBaudrate(getCrsfDesiredSpeed());
  	}

• crsfRxUpdateBaudrate - https://github.com/betaflight/betaflight/blob/master/src/main/rx/crsf.c#L661-L666
• default error threshold of 3 - https://github.com/betaflight/betaflight/blob/master/src/main/rx/crsf.c#L64

[klutvott123]

Yes, it's true that the correct baud rate is 416666.
For CRSF V3, the receiver uses telemetry from the FC to detect a mismatch. If telemetry is disabled, the FC will send heartbeat frames instead, and if the telemetry wire isn't connected it wouldn't be able to negotiate the baud rate anyway. Both incomplete frames and crc errors are counted as errors.

[hydra]

Looks like Kiss V1 was also affected by this, at least according to this comment in the ELRS codebase (link below), perhaps @fedorcomander can confirm what baud rate new KISS firmware is using for CRSF these days?

https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/user_defines.txt#L48-L50

[fedorcomander]

Kiss 400000 Ultra 400000 and 2000000 v2/v3 auto negotiation. (afair on KISS F3 cpus its 1000000 max, but frankly never seen it), follow TBS protocol specs. With auto negotiation. All my ERLS works fine ;)

…

On 21 Feb 2023, at 21:18, Dominic Clifton ***@***.***> wrote: Looks like Kiss V1 was also affected by this, at least according to this comment in the ELRS codebase (link below), perhaps @fedorcomander <https://github.com/fedorcomander> can confirm what baud rate new KISS firmware is using for CRSF these days? https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/user_defines.txt#L48-L50 <https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/user_defines.txt#L48-L50> — Reply to this email directly, view it on GitHub <#12398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQBCCXN4XYAJHQSPWU2MUTWYUPINANCNFSM6AAAAAAVC6S4UI>. You are receiving this because you were mentioned.

[fedorcomander]

In fact receiver may request any baud rate. :) on v3.

…

On 21 Feb 2023, at 21:18, Dominic Clifton ***@***.***> wrote: Looks like Kiss V1 was also affected by this, at least according to this comment in the ELRS codebase (link below), perhaps @fedorcomander <https://github.com/fedorcomander> can confirm what baud rate new KISS firmware is using for CRSF these days? https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/user_defines.txt#L48-L50 <https://github.com/ExpressLRS/ExpressLRS/blob/c5f67bd28a9f559a0bba3a4bcf509a4340445df5/src/user_defines.txt#L48-L50> — Reply to this email directly, view it on GitHub <#12398 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQBCCXN4XYAJHQSPWU2MUTWYUPINANCNFSM6AAAAAAVC6S4UI>. You are receiving this because you were mentioned.

[howels]

Do you need to customise ELRS to use the 400K baud rate on RX or is that automatic too?

[hydra]

follow TBS protocol specs. With auto negotiation.

@fedorcomander Which version of the spec document did you follow? As the baud rate changed between Rev 7 and Rev 10, see OP above.

[fedorcomander]

oh. interesting. i was not aware of that. will poke trappy. thanks. so far none of my clients had any issues btw. ---Cheers,AlexOn 22 Feb 2023, at 19:58, Dominic Clifton ***@***.***> wrote: follow TBS protocol specs. With auto negotiation. @fedorcomander Which version of the spec document did you follow? As the baud rate changed between Rev 7 and Rev 10, see OP above. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[fedorcomander]

anyhow. tbs is tad faster then 400kb. but it works fine on 400 withing range. since i dont have any issues with og devices - nog gonna change it. ---Cheers,AlexOn 22 Feb 2023, at 20:05, Alex Fedorov ***@***.***> wrote:oh. interesting. i was not aware of that. will poke trappy. thanks. so far none of my clients had any issues btw. ---Cheers,AlexOn 22 Feb 2023, at 19:58, Dominic Clifton ***@***.***> wrote: follow TBS protocol specs. With auto negotiation. @fedorcomander Which version of the spec document did you follow? As the baud rate changed between Rev 7 and Rev 10, see OP above. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[SteveCEvans]

@hydra please post links to the TBS CRSF specifications.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

[github-actions]

Issue closed automatically as inactive.

[hydra]

@haslinghuis Please can you re-open this, official confirmation from TBS is here:

tbs-fpv/freedomtx#26 (comment)

Edit: and ideally pin this, until it's resolved somehow, rather than automatically closed by a bot.

[KissUltra]

My doc from 14.08.2017 Rev 07 doc says 416kbaud :) Lol...

[klutvott123]

we should just change it

[hydra]

we should just change it

this is my feeling too, it's currently incorrect and should be corrected.

I'm not sure how happy other projects will be about it though, as they will have to communicate this to their users.

Suggest co-ordinating the change with the devs of at least the ELRS project.

[fedorcomander]

i plan to make it configurable on ultra. ;) just in case ;) may be you should do the same. ---Cheers,AlexOn 26 Sep 2023, at 13:11, Dominic Clifton ***@***.***> wrote: we should just change it this is my feeling too, it's currently incorrect and should be corrected. I'm not sure how happy other projects will be about it though, as they will have to communicate this to their users. Suggest co-ordinating the change with the devs of at least the ELRS project. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[hydra]

i plan to make it configurable on ultra. ;) just in case ;) may be you should do the same.

Not sure if that's a good idea, traditionally all RX protocols, that I can remember, have used a fixed baud rate associated with the protocol.

Every additional option only serves to complicate things, confuse the user and generate more support issues.

[KissUltra]

you dont say ;) still. run on 400 with zero issues for last 6 years. i think uart allows 5% error easy. ok. shutting up. game changes dramatically if cpu clocked internally. especially h7. ask me how i know. ;)---Cheers,AlexOn 26 Sep 2023, at 13:25, Dominic Clifton ***@***.***> wrote: i plan to make it configurable on ultra. ;) just in case ;) may be you should do the same. Not sure if that's a good idea, traditionally all RX protocols, that I can remember, have used a fixed baud rate associated with the protocol. Every additional option only serves to complicate things, confuse the user and generate more support issues. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[ctzsnooze]

Closing because the difference is small. ELRS deals running their baud rate report no errors. A project to refresh CRSF is underway. This specific issue can be laid to rest for now.

[hydra]

why not just correct it in BF if the difference is so small that the error difference will not be noticable? it's kinda silly to drift off-spec like this and currently just serves to confuse people.

[ledvinap]

@ctzsnooze : There may be other error sources (internal RC and possibly others). Wasting baudrate margin is not a good idea

[howels]

@ctzsnooze : There may be other error sources (internal RC and possibly others). Wasting baudrate margin is not a good idea

The current situation provably works and eLRS and others have standardised on 420K as this was the observable implementation of CRSF at the RX. So please can we close this and move on? This is pedantry and not related to observable issues. 420K is an easy to use number already implemented without issue.

[faryna1993]

I have a request, add the following command.
set serialrx_baund 115200

[KissUltra]

eLRS and others have standardised on 420K

Unfortunately only @hydra makes sense here. Pedantry to keep to the standard instead of reinventing your own square wheel and call it OK :) That is not pedantry. Thats laziness and ignorance. God luck. :)

[faryna1993]

It seems that this is too difficult a task for you. Therefore, it is easy to attribute it to pedantry. Good luck. :)

[KissUltra]

i can say exactly the same about your task. ;)

[hydra]

The current situation provably works and eLRS and others have standardised on 420K as this was the observable implementation of CRSF at the RX. So please can we close this and move on? This is pedantry and not related to observable issues. 420K is an easy to use number already implemented without issue.

In my recent testing here, as the hardware designer of at least 4 UART based ELRS RX's now, using both the ESP32 Pico D4 and the ESP32S3 I can 100% say that you DO notice observable errors and corruption of the data when using the wrong baud rate.

[haslinghuis]

@hydra did you try #13614

[hydra]

@hydra did you try #13614

no, but happy to see the PR!

[KissUltra]

Thank you @hydra and @haslinghuis

[SunjunKim]

The current situation provably works and eLRS and others have standardised on 420K as this was the observable implementation of CRSF at the RX. So please can we close this and move on? This is pedantry and not related to observable issues. 420K is an easy to use number already implemented without issue.

In my recent testing here, as the hardware designer of at least 4 UART based ELRS RX's now, using both the ESP32 Pico D4 and the ESP32S3 I can 100% say that you DO notice observable errors and corruption of the data when using the wrong baud rate.

Do you have any data showing how serious the problem is?

[fedorcomander]

i have arc error counter on the osd. at some flight was more then 1000 errors. apparently some packets were OK after arc check, but had WRONG channel data, so it was affecting flights.

…

Do you have any data showing how serious the problem is?

[CapnBry]

i have arc error counter on the osd

What is the "arc error counter" that can be placed on the OSD?

EDIT: Or wait, are you referring to while running at 400k baud? We need to separate out "getting errors at 400k baud" vs "getting errors at 420k baud".

[KissUltra]

crc---Cheers,AlexOn 8 May 2024, at 16:42, Bryan Mayland ***@***.***> wrote: i have arc error counter on the osd What is the "arc error counter" that can be placed on the OSD? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[SunjunKim]

crc---Cheers,AlexOn 8 May 2024, at 16:42, Bryan Mayland @.> wrote: i have arc error counter on the osd What is the "arc error counter" that can be placed on the OSD? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>

Sorry this is not much informative.. the conversation is like it’s A. -> what is it? -> it’s A.

Providing your gear setup comprehensively will be better helpful. Also please explain what that “arc error counter” means and how it’s measured will be even better.

Ah you mean CRC!!! sorry that part was hard to spot.

[hydra]

Just commenting that #13614 does not fix/complete this issue and that BF is not following the CRSF specification outlined in the OP here: #12398 (comment)

Users wanting a build of BF that follows the CRSF spec have to add #define USE_CRSF_OFFICIAL_SPEC as it is not, currently, the default.

Additionally the authors (@tbs-trappy) of CRSF and the spec commented here https://github.com/betaflight/betaflight/pull/13614/files#r1596251113

| tl;dr: suggest to fix problem at the source. 416.6 is correct