[Myxa] Current limiting behavior

myxa

(Evan1010) #1

I think this bears some relevancy to the power balance explanation, and perhaps understanding of listed settings and any hard-coded limits.

I have been experimenting with a Myxa running Telega v0.2, to see how much power I could squeeze out of it, within the (peak) limits as I understood them. The particular unit is dedicated to the test bench, so I could afford some risk.
Whereas I am able to configure max_current (phase current) with values up to 60A, there appears to be a hard-coded limit of 30A on the derived DC link current.

As soon as the DC Current in the GUI reaches 30A (Phase current peaks around 42A), I receive a “DC Overcurrent” Alert, the system throttles down and begins to oscillate with a downward trend. I also start to see “CSSW Saturation” engaged and “Hardware Overload” messages. Is this DC Current limit configurable behavior, or a static safety-related limit? Or am I missing something else entirely given the messages?

If more information is needed, I have some screenshots (I don’t wish to unnecessarily clutter this topic).


Quick start guide for Myxa v0.1
(Pavel Kirienko) #2

Myxa does not apply any implicit setpoint constraints in the software. ESCs which do (e.g., any no-name) are flawed and are fundamentally unfit for use in flying vehicles.

Practically that means that once commanded to reach a particular setpoint, Myxa will attempt to do so regardless of its state (temperature, current limits, etc). An exception applies to the last-resort hardware protection against extreme overload which exists only to prevent the device from catching fire (as opposed to mildly overheating), which is exactly what you seem to be observing judging by the message “Hardware Overload”. The hardware overload protection is the very last line of defence which is activated independently of the control software directly by an analogue circuit in the power stage. Reaching this stage indicates that you are overloading the device dramatically (which does seem to be the case here: at 30Adc*50Vdc you would be approaching 1.5 kW of steady-state power output). Regarding the downward trend, it is difficult to say what exactly is happening in your case, but my educated guess is that once the hardware overload protection is activated, its limiting behavior interferes with the motor control logic, increasing the phase error, which in turn leads to an even higher power dissipation in the drive. The positive feedback causes the downward trend.

The solution is to avoid such high currents or to switch to a more powerful controller. Speaking of which, are you aware that we have OpenMyxa rated for up to ~2.5 kW and a new upcoming design Voguerode rated for up to 7 kW? They run the same firmware. If you’d like to learn more about those, please email my colleague dmitry.ramensky@zubax.com.


(Evan1010) #3

Thank you for moving this into its own topic - I wasn’t sure it was sufficiently novel, but now I can supply more information without cluttering the old thread.

At this point I can accept the standard Myxa falling short of supplying the necessary current, and I will contact your colleague regarding the OpenMyxa design. I have been reviewing the design these past couple days, as it seems to fit our power requirement perfectly - I mistakenly assumed that it was not yet ready for testing.

That said, in the interest of not sounding crazy (putting 1.5kW through a Myxa level of crazy), here’s some hardware information:

Battery: 6s (25.2V max) Lithium Ion pack
Motor: KDE4215XF-465

  • 22 Magnetic Poles
  • Motor Constant of 465Kv
  • Winding Resistance of 0.052 Ohm

Propeller: Graupner E-Prop 15" x 8"
ESC: Myxa A (3D-Printed Case)

I’ve reviewed the video I recorded, and the peak phase current I witnessed was 47.4A (775W).
Do you know off hand what shunt current would trip the hardware overload? Perhaps the GUI sampling was missing the peaks.

I have read up on some of your other posts, and wonder if this excerpt may have bearing:

Considering the reported RPM and known Kv of the motor, that is.

It may be a rather inconvenient medium, but I have attached a screen recording of my testing. I apologize for the periods of inactivity, as the test stand was in a protected enclosure and slowed down the testing. DC Overcurrent is first reported at the 2:45 mark, and gets more interesting from there.

vokoscreen-2019-05-01_14-26-39.mkv (4.2 MB)

Thank you for addressing my concerns - at this point I mainly wish to know what triggered the behavior in my case.


(Pavel Kirienko) #4

The overload protection is based on the voltage drop across the low-side bridge transistors, and as such, the threshold tends to float quite a bit. It is designed so that the lower boundary is to be above 40 A.

First, the hardware overload protection activates at around 40-50 A. The protection is very invasive; while active, it directly modifies the PWM signal pattern carefully constructed by the sophisticated control logic, which you can mentally picture as throwing a wrench into the motor control loop. The control logic perceives this as a very strong external disturbance and attempts to recover; while the recovery is in progress, the phase error oscillates wildly, randomly causing the protection to trip again, throwing the control loop back into square one. The process repeats some dozens of milliseconds later unless the demand is reduced.