It won’t, only passthrough won’t be available. If you need to configure that ESC temporarily connect it to an output that supports it and make the changes you need.
Excellent - that’s exactly what I needed to know.
I need to study up on passthrough.
Passthrough just uses the Flight Controller as a conduit to another application thru the USB port. Like BLHelisuite.
Also when we are not all great at reading the HWDEF files nor understanding the internals of the MCUs, you can just try setting DSHOT up and look in messages for some thing like
RCOut: PWM:1-8 DS600:9-12 PWM:13-14
If you dont get a DSHOT entry then the config is not compatible.
Then use the ESC startup sounds to verify they are receiving DSHOT or PWM
Caveat:
I’ve got a CUAV V5 Nano that says something like
RCOut: DS600:1-8 (and so on)
but the Motor1 output definitely wont do DSHOT, only PWM. All the other outputs are OK considering the timer group limitations. I just had to move my physical connections along 1 position and start from Motor2 output.
Helpful - thank you.
I’m in mid-assembly right now - but got far enough along to do a Mission Planner motor test with one motor - worked fine.
Interesting - the motor sounds a bit different with the new 4-in-1 ESC using Dshot than the previous PWM ESCs.
…and they can run surprisingly slow too - it looks a bit freaky when you are used to old PWM ESCs having a minimum rotational speed of nearly takeoff levels.
It’s quite handy to set the SPIN ARM to very low, so you can see all the spin directions every time you arm, in case anything has gone bad or a config has changed as if by magic.
Still set the SPIN MIN to something reasonable, producing just enough thrust for stability during free fall 
1 Like
I’ve noticed the same, I have a Pixhawk1 with the full 2mb available (although it was running generic fmuv3, I just reflashed to Pixhawk1, it would be good to try bdshot on a full fat pixhawk.
Bdshot is the best way to drive the Dynamic notch filter. Much faster data update than serial telemetry.
I have a quadrotor currently flying a CubeOrange. I would love to use Bi-Directional DShot and Passthrough to update the four ESC’s firmware if possible in the future.
A few facts I would love to confirm:
- I need to use the AUX outputs instead of MAIN outputs.
- The CubeOrange has six AUX outputs (AUX1-6).
- The six AUX outputs form two groups with their own timers (AUX1-4 and AUX5-6).
- Each group of AUX outputs needs to be using the same protocol within the group (e.g. PWM vs Bi-Directional DShot).
- There is a hardware issue with the CubeOrange that prevents Passthrough specifically on AUX1.
I could configure my quad to use Bi-Directional DShot on AUX1-4, but then I am missing Passthrough on just AUX1, which is a tad annoying. This seems to be what others have successfully done already.
Or, I could configure Bi-Directional DShot on AUX1-4 and AUX5-6, map the motors to AUX2-5. I would then get Passthrough on all four ESC’s, but at the expense of AUX1 and AUX6 needing to be running Bi-Directional DShot, which might limit their use for anything else.
Is this possible, or am I missing key facts?
I believe you are correct with everything.
So - is passthrough important enough to sacrifice two spare AUX connections ?
There’s some BLHELI settings in Arducopter, like reversing motor direction with a bitmask, so passthrough is less important. You’ll probably never change ESC settings once they are correct.
I would set all the ESCs the same using passthrough, or an arduino, then use the Arducopter params without passthrough, and use the 2 spare AUX ports for something else 
Then using Mission Planner motor test to get the spin direction correct, adjust:
SERVO_BLH_RVMASK
Dont forget to check
SERVO_BLH_POLES
For BLHELI32 settings in the ESCs I suggest:
Low RPM Power Protect = OFF
Temperature Protection = 100
Low Voltage Protection = OFF
and set up voltage and current monitoring via your normal power brick. I find all the ESCs report different voltages so I dont rely on them - you certainly dont want an ESC cutting out if it thinks the voltage is too low, allow the flight controller to make those choices.
I also turn on Sine Modulation, but that doesn’t seem to be widely used - I’ve never had an issue with it and ESCs have worked LONG and HARD
While it’s probably not best practice, I have had multiple successes with passthrough on AUX1 with a Cube Orange, including firmware updates.
EDIT: To be clear, this experience has been with 4.1 through 4.3 series Copter bdshot firmware, two Cubes, and 3 different 4-in-1 ESCs (Hobbywing XRotor 40A and 60A along with a Lumenier 60A).
Can we get builds for the full fat 2m Pixhawk/FMUv3, it seems odd that the 1M Pixhawk/FMUv2 has them but not the 2M. I noticed 4.4 added Bidirectional BDShot to a fair few more boards so thought now would be a good time to ask. Thanks
1 Like
Perfect thanks, even more reason to get my rebuild done so I can test this.
I’m curious if there will be support for bdshot on the Kakute H7 Mini board. It’s capable of bdshot, and the full size Kakute H7 has a bdshot fw available, but none for the mini I’m using.
Also, FWIW the link to docs on the OP is no longer working.
It’s built right in - there is no separate target. I am flying one with bdshot
1 Like
Awesome thanks! I assumed the OP was still correct where it says, “Bi-directional dshot (BDShot) is only supported on some boards, mostly ending in -bdshot”. That must be based on older info, or the Kakute h7 mini just happens to not be part of that “mostly” crowd.
If your config allows you to set SERVO_BLH_BDMASK then its supported. It’s also documented in the README and wiki for each board
Gotcha, yes I was able to set SERVO_BLH_BDMASK, and there is a mention of bidirectional capability in the wiki for the board. I just wasn’t sure since the full size Kakute h7 v2 does actually have a ‘bdshot’ target and a non dshot target.
Generally if I do the initial port I try and make sure it has bdshot from the get go
1 Like