Bi-directional dshot - testers wanted

Ok I have found a solution. If we drop support for external SPI the DMA assignment becomes manageable. I have it working on Pixhawk1

Pixhawk4 updated and build available at the link above

Whats the difference between Blheli32 bidirectional Dshot and Blheli_S bidirectional Dshot. Have tried googling but canā€™t find much info.
When using this code do I need to connect the telemetry pad on the Blheli32 to a rx pin on the fc?

BLHeli_s is for ESCs without STM32 chips. It was a temporary phase after BLHeli and was quickly abandoned with the move to STM32 and BLHeli32.

You donā€™t need to connect your telemetry pad

Thanks for the info, there is a Blheli_s firmware that has bidirectional Dshot implemented, have used it with Betaflight.
Thatā€™s why Iā€™m asking if there are dialects of this protocol?

First, I donā€™t have a ā€œbuildingā€ environment, so Iā€™ll need the .apj or .hex.
Then motors are on Aux 1-4, with latest BlHeli32 on the ESCs, correct ?
Pixhawk4 has IOMCU so my BDMASK should be 3840, correct ?

Just FMY, are Aux 5-6 still capable of doing PWM ? I used to have a gimbal there with pitch control and trigger.
I may have flying weather thursday.

Right did you see the link above to builds for various boards? They are all apj files.

Yes correct.

PWM should be fine on those channels

Got it partly working on the Matek405, if I set BDMASK = 3 I get the first two channels working. if set to 7 or 15 it reverts to PWM output and nothing works. So it seems there is something going on with channel 3 and 4.
This is now tested with the BLHELI_S special DSHOT bidirectional fw, the two channels that works works great. Iā€™m getting rpm and no com errors.
Sttill waiting for the BLHELI32 to arrive

Great work @andyp1per, this looks very promising!

Hi,
nice to hear about bi-dshot :sunglasses:
Would Pixracer work?
Cheers

Yes I would think so if you are willing to test.

I will need to do a hwdef.dat however

no hurry, just saw that Iā€™ll have to do a hardware update BlHeli_S -> 32

Do you think there are some tweaks needed in the hwdef to get channel 3 and 4 working on Matek?
Have got the build environment working so I could test if you give me a hint were to look.
Or are there any debug info from my system that will help?

Thanks

Could easily be - Iā€™ll have another look at the hwdef.dat

You are right - there was a problem with the DMA channel allocation. I think I have corrected this and have rebuilt the firmware - can you try again?

Thanks very much!
Now it works great on all 4 channels
Still testing with the updated BLheli_S ESC so they are definitely a candidate for use

http://www.multirotorguide.com/guide/how-to-flash-blheli_s-firmware-with-bidirectional-dshot-rpm-filtering/

Thatā€™s great news. The reason I am reluctant to explicitly support BLheli_S is because apparently the timing is more finicky and you have to have this special version of the firmware. But I know the protocol is the same, so if it works for you - great!

Ok, yea the BLheli32 will probably arrive beginning next week.
I will continue testing

And again big thanks for your work!

Iā€™m thinking of now setting up the dynamic notch filter do you think thatā€™s to early?

And I donā€™t think the custom firmware works for all BLHeli_S ESCā€™s even the ones they have .hex files for. I tried it on a C-H-25,16.7 and it worked (Dshot). On a C-H-15,16.7 it didnā€™t. Both Spedix ESCā€™s, different models. I donā€™t consider this a big deal just that BLHeli_S is in the rear view mirror.

I think you need 16.73 to get it to work. I have it running on a C-H-15 with 16.73. But I agree its probably much less margin to a fail compared to a BLHeli32

Thanks Patrik, I may try that.