motor tech - Brownout reset issues and proven workaround on 20A Opto Afro with SimonK

Up to this point everything I have tested and used under the Hy-Con umbrella has been run on the same trusty pair of Afro 20A controllers (BEC version, though I don't use the BEC in my system) on their stock flash of whatever version of SimonK. They have served up thousands and thousands of rounds without a single fault and weathered numerous violent stalls and shredded darts during the cage's evolution. They're rated a bit lower than my overbuilding mind would like, but hell, they have proven themselves.

I went to buy more controllers, and the old trusties were sold out. So I bagged a bunch of the "opto" (really just non-BEC... with no real optocoupler anywhere to be found... like most "opto" ESCs...) version instead. Putting my lucky pair of controllers safely aside, I began using them for firmware experiments, starting with stock latest release SimonK.

First discovery: These Opto Afros die and reboot every single time if you send them a hard throttle step while the motors are spinning down and reach low enough speed. Oh, not this again!

Preliminary poking around revealed absolutely zero difference in the logic power supply arrangement between the two versions. Firmware was also cloned from my old lucky 20A Afros to the test pair of new resetting ones with no change, so it doesn't seem to be a SimonK version or parameter difference. I tried a wide range of SimonK versions, with both low-speed/startup duty cycle management strategies (the old variant that did discrete hard shifts in duty at set speeds, and the newer smooth-ramping one) without improvement.

That leaves two hardware and one low-level software possibilities to explain the different behavior between these two nearly identical drives that ought to behave identically:

* The inverter MOSFETs are different components between the two models. The BEC one has Toshiba TPCA8087 (rated for 56Adc and 168A transient, incidentally). The "Opto" one has a visibly different, so-far unreadably labeled, device. So this could be a lower Rds(on) or other different properties, and maybe make the startup current transients nastier.

* The stock DC link capacitors are different. Both are Haicap brand, 35V, 220uF (IIRC, but both are the same ratings) but the one on the "Opto" has a longer can. We would expect longer = lower ESR = better; but perhaps not. Insufficient buscap can cause all kinds of hell with motor drives, and seriously, who is "Haicap" anyway?? Replacing these with something BIG and GOOD as a test is on the list.

* The ATMega fuse bytes may be set differently, resulting in a lower brownout detection voltage on the working drives. In this case, the resetting ones may be behaving properly, while the "working" drives may be running the ATMega8 out of spec for Vcc at 16MHz. This is bad. Recommended BOD settings exist for reasons. The microcontroller could crash from the Vcc sags. If it crashed with the motor underway, very bad things could happen! That will be investigated once I have the right ISP socket to read the fuses on them.

Anyway though, what I noticed while testing was that the brownouts corresponded with what looks like a MASSIVE current transient. My phase wires were jumping around from the magnetic fields, like the leads on my battery welder! This gives pause. It is entirely possible that the usual fix - throw an increasingly mahoosive battery at it until it stops rebooting - will cover the issue up, and changing to stabilized logic power WILL cover it up, but if there is actually an unexpected gigantic current excursion going on here, that really needs to be addressed. That's not supposed to happen and especially with a 0.077 ohm phase-to-phase motor and a tightly sized drive here, the inverter mosfets may get blown sky high if it's getting hammered with 100% duty at low speed and that isn't mitigated - it certainly isn't nice to any of the equipment including the battery.

Duty at very low speed should be limited to POWER_RANGE/4. Should. I suspect a bug - especially because hard throttle steps from 0 rpm never cause any symptoms, only hard throttle steps from low but nonzero speed while the rotor angle is still being tracked.

A solid workaround found was to enable SLOW_THROTTLE. This is something that sounds wrong after the history in this hobby of chasing more and more current and torque and the most aggressive possible responses from every component, but it doesn't seem to affect startups.

Per my understanding, enabling SLOW_THROTTLE won't even affect the duty (hence current and torque) profile of a 0 rpm startup with an inertial load attached (like a flywheel) as:

* the minimum duty SLOW_THROTTLE permits is POWER_MIN_START anyway;

* the TIMING_RANGE (frequency-based) duty scheduling strategy used in the startup process should always result in lower duty slew rates when accelerating an inertial load than SLOW_THROTTLE's restriction that the duty may only double in a single cycle and no more... at least from what I can tell.

Now, SLOW_THROTTLE really ought to not affect a start from such a low speed with a turning motor, either, because the TIMING_RANGE based duty schedule ought to still be enforced as part of the update_timing* routines. So why DOES turning SLOW_THROTTLE on matter? Hell, how does such a fast duty ramp (as doubling per-cycle from a starting minimum of POWER_RANGE/6, thus going to 100% in 4 commutations... I think) even help our issue by itself? Yes, this warrants further investigation and dissection of SimonK. SLOW_THROTTLE has given flawless operation and great results so far on 3S and 4S and will be part of my official SimonK variant for the Hy-Con/Production T19 for now, but it's a kludge fix.