This should reduce current spikes, particularly on high voltage setups.
This should help to avoid overheating and failure in the event that power is still requested but the motor cannot turn. After about a minute, we will give up entirely and start beeping instead, which may help for recovery.
Take 2 in d58be3e made some motors better and other cases, like the MT3506, worse. It is a little sad how much logic is required, but I have tried for weeks to find a more simple approach. Nothing else is able to work as well as this with all of the motors I have to test. Previously, the demagnetization path disabled power only during the zero crossing wait. This did reduce the amount of current slightly, which did help, but in many cases the timeout would keep recurring for some time, reducing output power until the back-EMF was high enough. We now disable power and align, which allows for faster acceleration even with timeouts. The remaining timeouts can probably be solved by a smoother timing_duty limit. This also restores the 240 degree zero crossing timeout which helps with motors with unbalanced windings and the ZMR RCX 1804 2400KV.
42 degrees allows a bit of recovery from stumbling under sudden acceleration from slow speeds on some motors such as the MT3506.
This allows negative TIMING_OFFSET values. Thanks, Owen!
The approach in 7e76349 was to just limit the maximum amount of backtracking that the ZC filtering will do while running. A counter is initialized based on the timing period and must reach zero to consider the ZC complete. If the comparator output is the wrong level, the counter may build back up to the value it started with. We simply set the "value it started with" to a fixed smaller number while in running state. This works well on the Multistar 4225 390KV 16-pole motor when dragging by hand at moderate PWM, but there are some problems. The previous long filtering method worked much better with tracking of stalled motors and motors transitioning from starting to running (or starting where the motor is already spinning). So, with the change, it can be quite easy to get ahead of the actual back-EMF and align to the electrical properties of the motor. When this occurs, we typically spiral up to maximum timing, making a squeak or squealing sound. Eventually, a zero-crossing timeout occurs or TIMING_MAX is hit enough times for it to shift the power down to 0 (part of the RPM limiter) and a zero-crossing timeout occurs. In some cases, such as with brushless gimbal motors, this happens repeatedly and it is not possible to actually run the motor unless accelerated externally. Higher maximum backtracking values help for the gimbal motor, but we then re-introduce the original problem with the 390KV. This approach reuses the late demagnetization timer as a trigger for changing the filtering backtracking whenever timing is slow enough that the backtracking value is higher than ZC_CHECK_FAST. This idea is based on the observation that there are no early transitions due to noise, only late erroneous backtracking, which is what prompted the original demag_timeout handling. So, after 24 degrees, we now detect more easily that a ZC has occurred. This method seems to have the same improvement with the 390KV, while still working fairly well with the gimbal motor (not quite as good as before, but once it is running, it is OK). Dragging the the 390KV slowly still causes the detected ZC to become late, but it doesn't seem to be a problem anymore for rapid acceleration and this only seems to happen at very low speeds. The filtering backtracking limit can also be adjusted (ZC_CHECK_FAST) to help. In the same conditions, wii-esc with fixed-time ZC filtering seems to show similar problems. Once the 390KV is started, it continues to trip the sync recovery code continuously until accelerated past a certain speed. This turns off power at every commutation, making it easily visible on the 'scope. The result seems to be reduced torque until sufficient speed is reached.
This seems to further help rapid direction changing since the ZC filter backtracing was limited.
The back-EMF from some motors when clipping through the high side body diode seems to create noise that can significantly delay the ZC filter and lead to significantly retarded timing that can then blind the next commutation event due to the blanking period and not completing until after the zero crossing has already passed. This tends to be a problem at lower speeds and higher currents. For example, dragging the bell of the 16 pole Multistar (HengLi) 4822 390KV at about 30% duty cycle at 16V would cause significant current draw and broken timing. Heavy acceleration would also cause synchronization loss that even the demag_timeout handler could not help with. Limiting the backtracking (the amount at which we will "back off") from an accepted zero crossing point seems to greatly help here. This also seems to help other cases such as switching directions as quickly as possible. The tendency for some motors to get stuck in slow rotation in the wrong direction also seems to be fixed. The only downside seems to be that the unbalanced filtering now seems to have more tendancy to align to magnetic harmonics than actual motor timing. This causes a squeak or squeal until the power level is changed or the motor moves slightly, affecting the inductance. Traces on the oscilloscope seem to look very much like those from a micro motor in this case, so it seems difficult to avoid. Please report any such cases where this is a problem.
power off. When power off is requested, POWER_ON is cleared and the on duty is set to 0 cycles. This does not completely stop power, however, as the pwm_on interrupt will still occur and pwm_off will be scheduled to be called immediately after. This sets up a case where pwm_on will switch on the FET and then the AVR will execute one non-interrupt instruction before executing the next interrupt (which could be either pwm_off or int0 and pwm_off). If this instruction happens to be the "cli" of a commutation block that would advance to the next PWM FET, the FET on state would be copied to the new one, but the FET flags would be left cleared, leaving the PWM interrupt with nothing to do, resulting in the equivalent of full power until either the high side FET is turned off at the next commutation or (worse) power is requested again and the correct FET flag is set two commutations later. Instead of only setting a 0 duty cycle, always track the FET that should be PWMed, and make set_new_duty_zero set pwm_on_ptr to pwm_off so that power is immediately cut, but can still be restored without waiting until the next cycle.
…ias. In most cases, the comparator output will stay low or high when the motor is not spinning. Normally this is not a problem as the motor will be perturbed enough by the next commutation to start to get a reasonable signal. However, in some cases, the motor may not move enough and we will just stay in the state of skipping every other commutation until some external force helps generate enough back-EMF to sway the comparator output. Ideally, it would be nice to have an "equal" output from the comparator, but this is not available. The start timeout min/max were intended to assist pushing motors that might otherwise not align without increasing the commutation rate, but this has never really been the problem. What we really need instead is a delay for at least long enough to allow the magnetic field to build up and move the motor before continuing to the next step. The problem with a fixed START_DELAY_US (as introduced in b86dc7c) is that too long a delay will cause problems starting low-mass motors or motors at high voltage, since we may wait too long and miss the zero crossing. So, here we introduce a delay which starts at START_DELAY_US and builds up in steps until we two successful zero crossings. The default delay wraps around in a byte and will reach a maximum of 2ms. This should fix the starting of any motor that might sometimes vibrate or buzz when stopped in certain cogging positions.