Motor Glitch Issues Kakute F7 w/ Tekko32 4in1

For those following this is still not fixed. I have tried cap on 5v, 3.3v and vbat rail on flight control. Now have batteries numbered to see if its perhaps a bad cell in a battery pack. Also going to cut apart xt60 connection on one of the packs to see quality of solder joint. I have two brand new luminier 3s 1500 packs. And besides being cold out really not pushing that hard. And cells do stay balanced even when bringing down to 10.5v under load.

Tracking down intermittent trons is my least favorite thing to do I think.

Not fixed. Still have intermittent motor glitches. Last test config was AC 4.0.2 rc3 with 1000uf cap on battery input and 470uf cap on 5v bus. If its a power issue it’s more than a cap or two will solve. This has occurred on two separate sets of kakute and tekko. Two different batteries.

Now moving on to installing something different as a few bucks saved running cheaper hardware is not worth the time or effort imo.

image image

I suspect that is EMI from SD card to motors output, because motor connector is very close to card.
I have tried put off card or switch off logging and motors didn’t stop.
I will test this more.

Now you mention it, I had some odd stuff on a F7 AIO that seemed to be resolved by removing the SD card. I never took any time to look into it properly was more than a year ago.

I really liked the stack. Just had to stop using it it since I never figured out what it was. I was running sd card and logging. Never tried without. (789.6 KB)

I have the same problem. kakute f7 & tekk32 4in1, pwm_type=dshot150
It always happens on my mini quad. I enable ESC telem and it seems motor just stop running & back

As @tuuzdu and @iampete suggested, I do some tests about SD card. all tests fly 2 full battery

  1. remove SD card: motor glitch did not happen
  2. have SD card but disable logging ( LOG_BACKEND_TYPE = 0): motor glitch did not happen
  3. have SD card , enable logging but reduce logging to CTUN only, LOG_BITMASK=16): motor glitch did not happen
  4. have SD card , enable logging, default LOG_BITMASK: motor glitch happened

I suspect that logging may somehow interference dshot timing.

this thread seems have the same problem

The telemetry logging is done in the fast loop for every cycle. It creates a lot of log traffic at high trates, I wonder if this is related. I have a fix but I’m not convinced this will solve your problem.

You don’t have auto telemetry on on BLHeli do you? If so turn it off.

Thank you @andyp1per

You don’t have auto telemetry on on BLHeli do you? If so turn it off.

It was off in my build

I just propose a PR to fix this problem. Would you be able to help testing it? Thank you very much

Very cool! I can but won’t be able to do so for a couple more weeks due to current project taking all my time.

Thank you. I will look forward to hear from you :slight_smile:

I also encountered a similar problem. Ready to test Your change, where can I get the finished firmware?

Have never built from source. Tried it today. Able to get sitl to build. I do not see anything close to kakutef7 listed with ./waf list_boards. Tried chibios but it throws an AttributeError in

Sorry, I do not have time right now to troubleshoot in depth. There does seem to be a difference between your PR repo directory structure and master.

Hi @AndreyI @cglusky Thank you very much
this is firmware for kakute f7
Please feel free to ask if you need anything.

Thank you, I will test it soon.

1 Like

On firmware 4.0.4 RC4, the engines sometimes seem to shut down. The copter when it twitches. Sometimes strongly, sometimes almost imperceptibly. If you select the oneshot Protocol, the copter flies smoothly.
With this fix, there are no jerks, the motors are running smoothly. But I haven’t flown with this firmware yet, I only checked it in my hands. In this fix, telemetry data from ESC 1 is not recorded correctly. How safe is it to fly on the “dev” firmware?

4.0.4-RC4 is not dev firmware, it is a tentative release candidate that will most probable be declared stable (without any changes whatsoever) on this weekend.

Dev firmware is 4.1-dev (a.k.a. git master branch) and that one is a hole other animal.

Now the battery flew off, everything went perfectly.
I hope responsible people will include this fix in the next update…

Fixed firmware (link above), compiled from 4.1-dev.
On firmware 4.0.4 RC4, motors with the dshot Protocol are buggy.

1 Like

I casually asked in the github thread if this same issue could maybe be affecting the Omnibus nano FC as well. And, I think it is. I was getting a big motor twitch on every flight… Around the same time every flight.
I disabled logging and have been flying all weekend (maybe 10 flights) and it has not twitched at all.

Be good to try the same fix. Anecdotally the lack of DMA on UART1 this causes may be increasing CPU load as I now see logging failures with FFT enabled, so it would be nice if we had a proper fix - but anything is better than copters falling out of the sky!