BLHeli32 32.7.2 on Tekko32 F3 35A: Bidirectional DSHOT300 not detected by ESC

[SJChannel]

Flight controller: Holybro Kakute F7 AIO, Betaflight 4.2.3
ESCs: Holybro Tekko32 F3 35A individual ESCs, Furling32 32.7.2

On this HW/SW, the ESCs consistently fail to recognize DSHOT300 signaling when bidirectional DSHOT (i.e., inverted DSHOT) is enabled in the flight controller. Oscilloscope traces show that the flight controller is sending valid inverted DSHOT, the signal is clean, and the timing of the pulses is exactly correct for DSHOT300. But the ESCs fail to reply with DSHOT telemetry, and they will not spin the motors when commanded to do so.

These failures do not occur with BLHeli32 32.7. However, because of Issue #468, BLHeli32 32.7 is not a viable option for F3 ESCs if bidirectional DSHOT is to be used.

With BLHeli32 32.7.2, the failures happen exactly the same whether the flight controller is running Betaflight 4.2.3 or 4.1.7.

If I change the speed to DSHOT600, the failures still happen fairly often, but not every time as they do with DSHOT300.

If I disable bidirectional DSHOT in the flight controller, the ESCs work reliably regardless of the DSHOT speed.

With bidirectional DSHOT300: If I first power the flight controller with the USB port and then connect a LiPo, the ESCs detect bidirectional DSHOT300 reliably, and they send back DSHOT telemetry as expected. If I then go into the Motors tab of Betaflight Configurator, it shows 0% telemetry errors on all four motors. The motors spin correctly when I activate them in this scenario.

On the other hand, if I connect the LiPo first and then attach the USB cable, the oscilloscope shows no DSHOT telemetry coming back from the ESCs. The Motors tab in BF Configurator shows 100% errors on all four motors, and the motors do not spin when commanded to do so.

I have tried to duplicate the problem using a custom program on a Nucleo-F746ZG board, but I haven't been able to replicate the failures that way.

I am proficient with embedded HW/SW and would be happy to help with any tests you would like me to do.

[sskaug]

Thank you for the detailed failure report.

So the failure happens when you connect the lipo to the FC (and no USB) - then you see no bidir dshot response from the ESCs on the oscilloscope? For all the ESCs? Always?
Do you power up the FC and the ESCs with the same power plug - at the same time?

Lots of questions now.... I did try to replicate your error, but without success. I did not have your exact FC, though, I used another F7. I have a Holybro Kakute F7 AIO on order, should be here in a couple of weeks

[SJChannel]

@sskaug

So the failure happens when you connect the lipo to the FC (and no USB) - then you see no bidir dshot response from the ESCs on the oscilloscope? For all the ESCs? Always?

That is correct: all ESCs always fail to respond when the FC is configured for bidirectional DSHOT300. When the speed is changed to DSHOT600, each ESC fails sometimes, but not always.

Do you power up the FC and the ESCs with the same power plug - at the same time?

Yes, it is the usual AIO wiring. The LiPo is connected to the FC, and the ESCs take their power from the pads on the corners of the FC. So everything gets powered up simultaneously.

A few more details on the wiring: I have a 470 uF capacitor wired across the LiPo pads on the FC. There are no external capacitors on the individual ESCs, and there is not a separate signal ground wire for the ESCs. However, the ESC wires are short (much less than 1 inch), and the signal looks very clean when probed at the ESC pads with a 200 MHz scope. Because DSHOT600 works better than DSHOT300, and because unidirectional DSHOT works reliably at either speed, it seems doubtful that we're looking at a noise problem. But I can try adding a capacitor at the ESC and wrapping a grounded shield around the signal wire if you wish.

This all started when I tried turning on bidirectional DSHOT600 on this quad which had been flying well for at least a year. When I tried to arm it, it refused to arm because of RPMFILTER. In an effort to find out which ESC was causing the problem, I modified Betaflight slightly so that when the RPMFILTER disarm flag was set then it would emit a beep code indicating which ESC(s) were failing to respond. To my surprise, it was almost always several ESCs, but not always the same ones. At that point I tried reducing the speed to DSHOT300, and then the beep code indicated consistently that all four ESCs were failing to respond. That's when I turned to the oscilloscope.

[sskaug]

Now I looked into it. And created this test code: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Test%20code
Would be great if you could test it.

It has two fixes beyond 32.7.2:

• Waiting one more place before detecting dshot (to allow HW/FW to sync to input signal without creating bad frames)
• Also requiring low number of bad frames for multishot detection, in order for bidir dshot300 not to potentially be qualified as multishot

[SJChannel]

Now I looked into it. And created this test code: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Test%20code
Would be great if you could test it.

It has two fixes beyond 32.7.2:

• Waiting one more place before detecting dshot (to allow HW/FW to sync to input signal without creating bad frames)
• Also requiring low number of bad frames for multishot detection, in order for bidir dshot300 not to potentially be qualified as multishot

Thanks! I will test it right now.

[SJChannel]

Your test code seems to have solved the problem! With the FC configured for bidirectional DSHOT300, I power-cycled the quad 10 times and was able to arm it and spin the motors from the radio every time. I then changed the FC to DSHOT600 and power-cycled the quad 10 more times, again with success every time. (USB was disconnected for all of these tests.)

Next, I powered the craft from the LiPo, then connected the USB cable and went to the Motors tab in BF Configurator. It showed 0% errors on all four motors, and when I spun the motors the RPM readings changed accordingly.

I did see one thing on the oscilloscope which seemed strange, but may not be a real problem. I set my scope to trigger on the first falling edge of the signal, and saved a relatively large number of samples. Even at the end of the trace, 50 msec after the trigger, it was still not showing any DSHOT telemetry coming back from the ESC. However, when I manually triggered another trace a few seconds later, the DSHOT telemetry was present and looked good.

Also, I should have mentioned before that on this particular quad there is something strange going on with the ESC start-up tones. (This predates my attempts to use RPM filters.) All of the ESCs emit the first 3 tones at the same time. But the final 2 tones, which I guess indicate recognition of the protocol, often come out at different times from the four ESCs. Sometimes the final set of 2 tones from the "slowest" ESC is heard 1-2 seconds later than the set of 2 tones from the "fastest" ESC. Again, I was seeing this even long ago.

I can't fly it today (winds gusting to 50 MPH here), but whenever the weather improves I'll give it a try.

Thanks again for looking into this!

[sskaug]

Great that it works now!
Signal detection takes a lot longer than 50ms (starting with 1-2ms pwm etc), so it is not strange that you do not see any response in your 50ms capture. I will continue to try to understand why signal detection times vary so much between ESCs.

[sskaug]

Ok, so new testcode posted on github (same location, same name...).
Hopefully now startup time is consistent.
Also, the latest bits and pieces of improvement planned for Rev32.8 are included.

[SJChannel]

Thanks! I'll try it today and will let you know how it works for me.

[SJChannel]

I flashed your latest test code and then powered up the quad 20 times. 3 times out of 20, an ESC started up slightly later than the others. The rest of the times, they all started up perfectly together. That's a big improvement.

There was no recurrence of the original problem with recognizing bidirectional DSHOT.

[sskaug]

Good to hear - thank you for testing!

[SJChannel]

And thank you for the quick responses! I'll be happy to do any further testing that you might need.

I'm not sure how soon the weather will permit me to try flying with the new code, but I'll follow up here afterwards.

[SJChannel]

I flew two packs today with your test code, and everything is working great with RPM filters enabled in Betaflight. Thanks!