#Bidirectional DShot errors only when TX is connected to UART RX and dshot_bitbang=OFF

1 messages · Page 1 of 1 (latest)

normal badger
#

I have a BETAFPVF411RX (F4 1S 12A AIO SPI Fr-Sky) running BetaFlight 4.4.2. PID loop is at 3.2k and I am running DShot300. I have attached a HappyModel EP1 ELRS RX to UART 1 and enabled the "Serial RX" switch in the Ports tab. My Zorro connects and inputs appear to be received normally.

I noticed in the Motors tab that motor 1 bounces around 0.9% error, jumping as high as 1.4% (edit: as seen with cpu_overclock=OFF). Motor 2 sits at about half the errors of motor 1, and motors 3 and 4 sit at 0%. However, if I turn off my Zorro, all motors drop to 0% error. By default dshot_bitbang is disabled, but if I enable it, this behavior disappears (errors are always at 0%).

I also noticed if I disable receiver telemetry motor 1 drops to about 0.5% error, and motor 2 to 0%, so it seems to be correlated with UART usage. CPU usage is around 58%. Dropping the PID loop to 1.6k (which drops CPU usage to ~25%) has no effect.

Any tips on tracking this down? Should I just run with dshot bitbang enabled? My understanding is F4 is very CPU limited so I was trying to avoid that, especially since there doesn't seem to be a way to monitor CPU usage while flying and I don't have BB (please correct me if that is not the case). I tried 4.4.0 and 4.5.0 (commit b8855d3) and the behavior appears to be the same.

open anchor
#

However, if I turn off my Zorro, all motors drop to 0% error. By default dshot_bitbang is disabled, but if I enable it, this behavior disappears (errors are always at 0%).

@wanton quest

#

I tried 4.4.0 and 4.5.0 (commit b8855d3) and the behavior appears to be the same.

normal badger
#

Not sure if it's relevant but the motor direction wizard works for me on 4.4.2. ESCs are running Bluejay 0.19.2.

open anchor
#

Yes very relevant - because the fix for motor direction only comes with 4.3.2 (backport is pending).

#

Can you check if the motor errors are still there with 4.5.0 (also compare bitbang ON / OFF here)

open anchor
#

Also worth to note you were not affected by the the motor direction bug

wanton quest
#

I'm not hugely surprised, getting everything to play nicely with an spi rx on an f411 is quite the stretch. I don't actually have any FCs with spi rx so it's not something I have any first hand knowledge of. I wouldn't be too worried about ~1% errors on dshot telemetry, especially as it's likely to get better when not connected to the configurator

#

If bitbang works better then there's nothing wrong with using it. Both bitbang and the timer/pwm versions of dshot use dma and timers to achieve the result. One day I want to measure the relative performance and see how they really compare

open anchor
#

Yes this issue seems not related to the motor direction issue.

#

Or even affected by it

wanton quest
#

@normal badger what packet rate are you using for elrs?

normal badger
open anchor
#

did I miss something (now we are on ELRS instead of FrSky)

normal badger
#

It is an SPI Fr-Sky board but I have a HappyModel EP1 ELRS receiver attached to UART 1.

wanton quest
#

It would be interesting to see how changing to lower packet rates affects things? (Oh, sorry, I may have leapt to the wrong assumption - I always think elrs. Ohhhh - that's a bit different then)

#

That explains the comment about uarts 😅

#

all up there - I need to read better

normal badger
#

Lol yeah, it's a weird setup, no worries. Just what I had lying around. I'll test 4.5.0 bitbang on/off and the different packet rates.

wanton quest
#

That seems a bit more strange now, there are plenty of 411 running uart elrs, I wonder why this one is having a problem

normal badger
#

At 100hz/1:128 motor 1 sits around 0.15% error and motor 2 mostly 0% but occasionally jumps to 0.10%.

normal badger
#

I flashed 4.5.0 and tested the following:
4.5.0:
bitbang off:
100hz: 0.2%, 0%, 0%, 0%. Same when motors are spinning.
500hz: 0.9%, 0.3%, 0.3%, 0.3%. All drop slightly and jump around less when motors are spinning.
TX off: All usually at 0%, but occasionally all jump to ~0.03% in unison. Same when motors are spinning.
bitbang on:
100hz: 0.1%, 0%, 0%*, 0%*. All 0% when motors are spinning.
500hz: 0.2%, 0%, 0%**, 0%**. All 0% when motors are spinning.
TX off: All at 0%. Same when motors are spinning.
*Occasionally jump to 0.03% for 1 second.
**Occasionally jump to 0.10% for 1 second.

Temperature telemetry works with bitbang on, but not off.

normal badger
#

Also tested 4.4.2. In my OP, the error percentages I was seeing was with the battery unplugged. This was with the battery plugged in:
4.4.2:
bitbang off:
100hz: 0.1%, 0%, 0%*, 0%. Same when motors are spinning.
500hz: 0.55%, 0%**, 0%**, 0%**. Same when motors are spinning.
TX off: All are always at 0%.
bitbang on:
100hz: 0.07%, 0%, 0%*, 0%. All 0% when motors are spinning.
500hz: 0.2%, 0%, 0%*, 0%*. All 0% when motors are spinning.
TX off: All are always at 0%.

*Occasionally jump to 0.03% for 1 second.
**Occasionally jump to 0.07% for 1 second in unison.

Temperature telemetry works with bitbang off when the "enable motor control" slider is enabled, but stops updating after ~15 seconds until the slider is toggled off and on again. Does not work at all with bitbang on.

All tests done at 3.2K PID loop dshot 300.

wanton quest
#

Thanks for all the testing, looks like we definitely have something to clean up there if we can

normal badger
#

Sure thing. Let me know if you want me to try anything else.

torpid mica
normal badger
# torpid mica Can you post a CLI dump and the output of `status` and `dma show` in the CLI?

Sure, here's 4.4.2:

MCU F411 Clock=108MHz (PLLP-HSE), Vref=3.31V, Core temp=39degC
Stack size: 2048, Stack address: 0x2001fff0
Configuration: CONFIGURED, size: 3717, max available: 16384
Devices detected: SPI:1, I2C:0
Gyros detected: gyro 1 locked dma
GYRO=BMI270, ACC=BMI270
OSD: MAX7456 (30 x 13)
BUILD KEY: 33b2ce6ee7ab6fd84a041cc873f4fc7f (4.4.2)
System Uptime: 362 seconds, Current Time: 2023-06-17T18:52:19.772+00:00
CPU:50%, cycle time: 311, GYRO rate: 3215, RX rate: 497, System rate: 9
Voltage: 746 * 0.01V (2S battery - OK)
I2C Errors: 0
Arming disable flags: CLI MSP```

```dma show

Currently active DMA:
--------------------
DMA1 Stream 0: FREE
DMA1 Stream 1: MOTOR 3
DMA1 Stream 2: FREE
DMA1 Stream 3: MOTOR 4
DMA1 Stream 4: SPI_MOSI 2
DMA1 Stream 5: MOTOR 2
DMA1 Stream 6: FREE
DMA1 Stream 7: MOTOR 1
DMA2 Stream 0: SPI_MISO 1
DMA2 Stream 1: FREE
DMA2 Stream 2: FREE
DMA2 Stream 3: SPI_MOSI 1
DMA2 Stream 4: ADC 1
DMA2 Stream 5: FREE
DMA2 Stream 6: FREE
DMA2 Stream 7: FREE```
#

Huh, I just noticed the CPU is overclocked to 108 MHz by default. On my SPI ELRS version of this board I noticed the accelerometer twitched a lot when the CPU was overclocked, so I was curious what would happen here if I set cpu_overclock = OFF. Interestingly the errors are much worse now - 1.2%, 0.6%, 0.1%, 0.1% at idle with the transmitter on.

#

And, at cpu_overclock = 120MHz, 0% errors on all motors. But now I'm stuck with a "CALIBRATING" arming disable flag.

torpid mica
#

Yeah, bmi270 doesn't play well with the F411 at 120MHz

wanton quest
#

oh - anyone know why?

#

(wonder if that explains one of my bmi 270 builds being so bad)

torpid mica
#

Pre-4.4 I always OC'd my F411 builds to 120MHz. Never had an issue until I tried it on a board with the BMI270, which always gives a calib error.

#

They seem fine at 108 though

wanton quest
#

We're probably going to need Steve to pick through all this

#

411 is such a pain

normal badger
#

This board doesn't have BB so I'm not personally too attached to it or this issue. If no one else is experiencing this it's probably not worth the effort. Just figured it was worth posting about since I've seen some dshot timing related commits recently.