BDSHOT EDT from AM32 ESCs not working in ArduSub

General Discussion
1

Hi. I’m trying to get BDSHOT EDT working in Ardusub. In Arducopter or -plane it’s working great - motors spin, telemetry is returned - but not when compiled for Sub.

Here’s the setup:

Version: master
Flight controller: MatekH743-SLIM
hwdef.dat: MatekH743-bdshot
ESC: AM32
Protocol: DShot300 or DShot600

This is what the S1 channel on the Matek looks like when its working (in copter or plane):

IMG_20250428_103932298_HDR
IMG_20250428_103932298_HDR1920×1440 255 KB

In sub:

IMG_20250502_114321520_HDR
IMG_20250502_114321520_HDR1920×1440 210 KB

The same, zoomed out:

IMG_20250502_114409136_HDR
IMG_20250502_114409136_HDR1920×1440 185 KB

If I turn the ESC off and on again, the Matek and the ESC seem to re-synchronise as follows:

IMG_20250415_140007338_HDR
IMG_20250415_140007338_HDR1920×1440 274 KB

To me, this looks like the output pin config setting (input, output, pull-up etc) is not synchronised with the BDSHOT pulse train. So the ESC is trying to pull the line low, but its still being driven high by the MATEK.

When hardware debugging, execution is clearly reaching the BDSHOT code as it should, but the DMA callback is not being called, so not data is being returned. MOTOR1 is not spinning either even though it’s being sent dshot pulses, so there may be a problem with how the motors are being initialised, and the BDSHOT failure may be a red herring.

There seem to be a lot of differences between the copter and sub objects, so there may be an elusive #define that’s not being set somewhere higher up during the waf configure step.

I’ve compared the respective params files for copter and sub in search of mystery parameters, also compared the TIM3 and GPIOA and B registers. TIM3 seems to updated dynamically (by DMA?) to generate the pulse trains, but I haven’t found any difference vs copter and sub.

I could dig further into the interrupt and DMA registers, but it might just be simple param or #define problem after all :grinning_face:

DSHOT is working fine for me in sub, btw, but not BDSHOT.

Anyone any ideas? Thanks in advance

2

Hi @BStiles -
As you’ve found, only PWM output is currently supported by ArduSub. This is typically because RC radios that may use other protocols don’t work underwater, as radio waves don’t penetrate water! BlueOS is setup to send and receive telemetry via TCP/IP. Sorry for the news…

3

Hi @BStiles,

This is sufficiently into the weeds of the firmware that it may be better raised as an Issue in the ArduPilot GitHub repository, where it can also be considered by other developers in the ArduPilot family, and can have its progress tracked when there’s a linked pull request fixing it (if it does turn out to be a bug) :slight_smile:

@williangalvani is the primary ArduSub maintainer, but I don’t expect he’ll have much experience with the motor output protocol code given Blue Robotics vehicles only use PWM control for motor outputs (so we normally don’t have to touch it). It’s possible he’ll be able to find a configuration difference / unexpected #define, but that seems similarly likely for other developers who are more familiar with that code, who are unlikely to see your forum post here.

@tony-white this is a general question about ArduSub ESC protocol support, so isn’t related to vehicle telemetry/control or BlueOS.