Demag events
The controller software monitors three events which occur during rotor rotation. These three events are Commutation, Demagnetization, and Zero Crossing. These events always happen in a set sequence.
The Commutation event (C-event) occurs when the controller steps to the next phase. The act of commutating to the next step will cause a voltage spike in the just-turned-off phase to appear due to the winding inductance.
For a low-side driven phase, the spike is positive – a diode above the supply voltage. For a high-side driven phase, the spike is clamped to just below ground. The voltage is limited by the intrinsic diodes of the inverter MOSFETS.
The voltage spike will remain as long as the current in that phase is decaying. The controller waits until this inductive current has dissipated before monitoring this phase for BEMF.
Otherwise, this inductive spike looks like a zero crossing event has already occurred and messes up everything. This wait time is the Demagnetization event (or D-event).
The next event in the sequence is the Zero Crossing event (or Z-event). The controller monitors the unused phase to determine when the BEMF crosses zero (or near zero) Volts. This event tells the controller where the rotor is.
With timing based on rotor speed, the controller determines when to perform the next commutation (or C-event). The controller repeats the sequence of C-event, D-event, Z-event (and back to C-event) to keep the rotor spinning.
Relationship between Commutation, Demagnetization, and ZeroCrossing Events.
In the image T1 & T4 are the demagnetization events when back EMF is monitored with a scope. Phase commutation event is produced at the beginning of T1 and T4. Zero crossing event is produced when back EMF crosses the middle point between vmin and vmax. Effects produced by PWM commutation are discarded.
Demagnetization event time T1 & T4 length vary depending on the current and speed. T1 & T4 times can be a meassure of the load when the kwad is hovering. If the kwad load is high T1 and T4 will be longer, because it has to generate more thrust (hence motors need to handle more current) to be in the air.
Depending on the maneuver the kwad is performing the motors will need to generate more thrust and handle more current, so for this reason some times T1 & T4 times will be longer.
In order to be able to understand how commutation works it is important to know how dependent is of demag event time. If T1 and T4 times are too long they will step over zero cross event, so the ESC cannot calculate the correct timing to perform calculation, and desyncs happen.
TBD
Demag event times depend on the current the motor is handling. Bigger motors can handle more current, but also if the motor spins slower T1 & T4 have less chance to step over zero cross event, so bigger propeller pitch may help.
Demag event times can be high on hard acceleration, because motor draws more current during accelerations to fight against increasing air drag and rotor and propeller inertia. In that case Bluejay allows to control the rate at which the speed builds up setting RPM Power Protection (rampup). Reducing it may help with desyncs during motor accelerations at the expense of performance.
Bluejay keeps internally a demag metric to check how well demag events lengths are. This metric is used to recognize desyncs using the demag compensation threshold, so setting Demag Compensation to high may help with desyncs, at the expense of performance, because when no demag event followed by a zero cross is found in a commutation step what happens is that power is cut until next dshot frame arrives.
Using EDT (extended dshot telemetry) Bluejay sends demag metric together with other telemetry data like temperature and max inflight demag metric. Demag metric can be monitored and logged, so this way it is possible to know if the motors and propellers are suitable for our application.
Demag metric is mapped into ESC stress level signals in frames 6 and 7 of EDT (extended dshot telemetry): https://github.com/bird-sanctuary/extended-dshot-telemetry#edt-frames
David Swanson, Embedded.com