Skip to content

Tags: TeXniKK/tgy

Tags

2014-01-19

Toggle 2014-01-19's commit message
Limit zero crossing filter backtracking, take 3.

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.

2013-09-20

Toggle 2013-09-20's commit message
Limit zero crossing filter backtracking, take 2.

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.

2013-09-11

Toggle 2013-09-11's commit message
Squeaky clean release

2013-09-09

Toggle 2013-09-09's commit message
Fix regression since 675ee37 which rarely causes a full power blip at

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.

2013-05-15

Toggle 2013-05-15's commit message
Fix typo breaking brake options since 71a8141.

2013-04-24

Toggle 2013-04-24's commit message
Enable hardware checking.

2013-01-25

Toggle 2013-01-25's commit message
Turn off brake before beacon beeping to avoid short circuit.

Regression since beacon merge (a9c3372), when MOTOR_BRAKE enabled.

2012-11-03

Toggle 2012-11-03's commit message
Use elif instead of elseif to keep avrasm2 happy.

2012-09-30

Toggle 2012-09-30's commit message
Disable DC bias cancellation by default. It does not seem to be worth…

… it.

At the same time, double the default ZC timeout to 240 degrees as it used
to be. This helps when DC bias is extreme, motor windings are mismatched,
or the ZC filtering gets slightly fooled with weak back-EMF. Just
continue running rather than dropping to start mode as quickly.

2012-06-10

Toggle 2012-06-10's commit message
Add static start demagnetization wait and reduce TIMING_MAX interval.

This should stop the screaming on start at higher duty cycles with higher
inductance motors. The reduced TIMING_MAX interval should catch any case
where the timing is still fooled by the demagnetization and spirals up to
near TIMING_MAX. The PWM limit (sys_control) will be halved until it hits
zero or the current is reduced enough that the there is nothing to fool
the zero-crossing sense.

Higher KV motors at higher voltage with no drag might reach the RPM limit
more easily now. This is probably a more practical limit anyway -- the old
limit was probably skewing timing significantly by the time it got there.