I’ve been sorting though docs and threads to try to get my hands around using bi-directional DSHOT.
I can’t find anywhere in the wiki that really talks about enabling and configuring bi-directional DSHOT.
I had some false starts because I didn’t realize that the connectivity and configuration requirements for “regular” DSHOT were different than “Bi-directional” DSHOT.
I’m currently using a Holybro 4-in-1 ESC and DSHOT-600 on AUX 1-4 - on an Orange Cube.
I want to change that so it’s bi-directional DSHOT-600 - so I can feed the RPM telemetry into the notch filter.
In some message threads that were a bit confusing - I’m not even 100% sure ArduPilot’s bi-directional DSHOT is supported on the Orange Cube.
To confirm it’s working, disable any serial ESC telemetry and review a .bin log for RPM data (can do it on the ground using motor test and LOG_DISARMED=1).
Using serial telemetry and BDSHOT concurrently is not a problem if you want to enable both (and is often preferable to get the best of both worlds).
I use it on all of my Cube Orange powered Copters.
Incidentally, I’ve gotten BlHeli32 passthrough to work via Aux1 on some ESCs. It’s always worth a try before reconfiguring to use Aux2-5 to set up BlHeli32 (and then re-reconfiguring to use Aux1-4 for flight).
You can look at the firmware repository for what’s supported with Dshot.
Here is Copter Stable Copter Stable
Any target with -bdshot which includes most cubes and both versions of Orange. So, that’s the 1st step is to flash that version of the firmware. Download the .apj file and use Mission Planners Load custom firmware button the 1st time. Then follow the Wiki as Yuri posted.
I didn’t realize that. I have been setting the Motor Test run time to a minute and then jumping over to the Tuning graph on the Data tab before the time ran out! Thanks!!
I had no idea that bi-directional dshot required a specific version of the firmware. I’m a bit embarrassed that I didn’t know this.
There is a tacit mention of the capability to install alternate firmwares in the wiki - but it’s not very detailed. And I don’t recall seeing anything about it in the wiki pages about dshot.
There may be some more technical reasons for it, but very simply, it’s code bloat. Adds something like 10k of flash requirement to the build that is completely unnecessary if you’re not using it (and may eat some RAM even if it’s not in active use).
It is for all but one FC that I know that for some reason has Dshot native support. I’m not sure why both targets are being created anymore as you can use the Bdshot version w/o using Bdshot. Dr. Piper probably has the answer!
Ah, yes. What Yuri said makes sense. Flash is like going back 10yrs with hard disk space. “Oh no, I can’t imagine needing more than 1T of space, whatever for?” And now my server needs a couple more 4Tb drives…
bdshot changes the DMA allocation and usually changes the PWM timer allocation. In particular it cannot use complimentary timer channels which some manufacturers use to make timer/pin allocation easier. Switching from complimentary timers to regular timers usually involves a timer that is currently used for something else (e.g. the buzzer). For non-H7 finding a good DMA allocation can be a merry dance involving many changes. These are fairly fundamental changes that change both the configuration of the board and the features available and which we didn’t feel was wise to try and make to production configurations. That is mostly why they are separate firmwares. When I write the hwdefs I try and make sure they have bdshot from the outset - but not everybody is comfortable doing this. In general new H7-based copter-focused boards should always have bdshot.
Thank you @andyp1per - I appreciate your explanation of these details.
As all of my quads use Orange cubes - which have H7 processors - can I assume that they will all function properly in all other ArduPilot aspects as they did before using the bdshot firmware? If not - what should I monitor or change?
Also - what, if any, limitations or restrictions apply on the Orange cube regarding which ports can be used for the motors? For example, are the motors required to use non IOMCU (Aux) port?
Restrictions of only using Aux ports of course would limit an Orange cube to only 6 bdshot motors.
Also - are the pairing of ports still significant? If so, which port pairs are allowed for a quad, hex or octo configuration?
I think if the Ardupilot wiki had more detailed information about this - it would benefit other users. I’ll be happy to contribute to the wiki if it would be helpful.
As the main reason for migrating to bdshot is to benefit the notch filter, can you comment on any benefits or detriments of using both the bdshot and the ESC telemetry port to have both RPM signals available to the firmware? As noted in this thread above, @Yuri_Rage says he uses both for redundant rpm signals sources.
Lastly, does the Orange+ version of the Cube offer any benefits for bdshot over the regular Orange Cube?
I’m intrigued that in FPV quads running Betaflight now use bdshot is the norm. (as far as I’ve read) Such applications perhaps place lower demands on the flight controller than ArduPilot - so as to not tax the processor so severely.
You can only use (bd)shot on the AUX pins. Using telemetry as well as bdshot is only to get info other than rpm (e.g. voltage) there is no redundancy advantage and the rpm update rate from bdshot is much higher than regular telemetry. Orange+ I believe has some hardware changes that make it better suited to (bd)shot but still (currently) only on the AUX pins. The CubeOrange-bdshot has no other changes.
Hi!
Do we need to use addition wire from esc to fc (uart) with ESC BLHELI32 for tuning a nocht-filter, or bdshot can allowed to tune filters without using uart-connection?
