On my current project, I’ve found I have to use dshot-300 instead of the more standard dshot-600.
The only thing different from my previous builds where I use dshot-600 is that this build has a HolyBro Pixhawk 6C Mini flight controller instead of an Orange Cube or Cube+.
I use Aux-1 through Aux-4, and I’m not using bi-directional dshot.
The problem that I experience using dshot-600 is some stuttering of the motors when the esc’s are powered up.
I’m ok using dshot-300 - and even just using pwm is OK too. But I’m curious to know if there might be some other parameter I should check that would allow dshot 600 to work.
Also - as the wiki suggests dshot issues with DMA, maybe there’s something different with this Pixhawk that’s a limiting factor.
As I mentioned, I’m using AUX ports - so not using IOMCU.
So I am surprised that I can’t use dshot 600.
I’m interested in your comment about BDSHOT. I’m curious about the advantages you’re thinking about.
For these builds, I was going to stick with FFT harmonic notch filters - and didn’t see the need for RPM. And as far as I know, BDSHOT still has the issue with BLHeli pass-through on AUX-1. (Maybe that’s just a Cube Orange thing - it might be OK on a Pixhawk.)
Pixhawk6C doesn’t label anything as aux. It’s either FMU or IOMCU (which is also true of the Cube Orange as far as the actual hardware is concerned, but CubePilot chooses an odd label, IMHO).
FFT filters are only really appropriate when RPM is not available or when harmonics don’t follow RPM. Typical electric multirotors tend to benefit more from RPM following rather than FFT calculated filtering. Even a throttle following filter can work better than FFT when set up properly.
Passthrough config should work fine (and often works fine even on the Cube’s AUX1, despite the warning, though some ESCs do not seem to play nicely, which I can’t fully explain, but I guess that’s why we have a warning).
Yes - I’ve had pass-through work once or twice on AUX-1 - but not reliably.
BTW - I think the wiki uses the terms “main” and “aux” - which is why I’m using those terms. And as most of my flight controllers are CubePilot products - it’s consistent with their labeling.
But I get it - HolyBro doesn’t label them that way.
I’m hoping that CubePilot follows CUAV and others and dumping the IOMCU all together.
Just yesterday I saw that there’s a parameter where it can be disabled. I thought that was interesting. I wonder if it makes those ports capable of GPIO input.
I think I recall that there’s some sort of DMA issue that requires using AUX-1, 2, 3 and 4 together when using dshot (or bd-shot) Maybe using 1, 3,5 and 7 as you suggest will work - but there’s nothing in the wiki about it.
I recall this issue when I considered using AUX-2-5 for dshot - so I could reliably use AUX-2 for passthrough. I recall learning that that option didn’t work - you had to keep the four motors together in the AUX1-4 group. But I never tested it.
So when on my copters using BLHeli and passthrough, I use AUX1-4 for the motors - but simply move the “1” connection over to the “5” connection (and re-define the servo functions to match) so I can use Aux 2 for pass-through.
Kinda a nuisance - but it’s reliable, and you don’t really need to use pass-through very often.
So I’m still wondering why DSHOT-600 isn’t working on my motors connected to AUX1-4 (FMU 1-4) as suggested in the wiki.
It makes me wonder if maybe there’s something amiss in the Copter target for the Pixhawk 6C mini.
It should work, usually these kinds of issues relate to noise on the line or some kind of ground issue, but difficult to say what without a scope. Check that the motor cables aren’t going past some significant source of interference.
We’ve had the problem with a couple different esc’s.
This copter works fine with PWM - and dshot-300 is just gravy. But I wanted to make sure I wasn’t missing anything in the proper configuration - and to alert the DEVs in case there was a small chance that it’s a firmware issue.