• Howdy! we're looking for donations to finish custom knowledgebase software for this forum. Please see our Funding drive thread

Lebowski's motor controller IC, schematic & setup, new v2.A1

I think I need to clarify a bit more what the control loop coefficients do. This is taken from v2.10:
Code:
  phase control loop, drive 2
e) 1st order:320
f) 2nd order:16
g) 3rd order:0.4
  amplitude control loop
h) 1st order:120
i) 2nd order:6.0
j) 3rd order:0.15

Lets assume a f_sample of 40kHz

Every cycle of f_sample (so 40000 times a second) the controller decides by how much to upgrade the phase and amplitude of the 3 signals driving the motor. The coefficients e to g are the maximum updates for the phase loop, the coefficients h to j the max updates for the amplitude loop. To make the algorithm fast to calculate, an update is either to add the coefficients or subtract the coefficients from the internal variables.

The internal phase is called phi. phi has a range from 0 to 65535 (32 bit, with 16 before the comma and 16 after) representing 0 to 360 degrees.

The internal amplitude is called ampli (inventive, ey ?) and has a range from -32767 to +32767 (again 32 bit with 16 after the comma), with 32767
being the maximum voltage to the motor (with Vbat lets say 60V at max ampli (so 32767) the sines to the motor will have 1.15*60 = 69 V peak to peak).
The controller uses moving-midpoint, meaning it can output sine waves with a peak-peak 15% larger than the supply, this is the reason for the 1.15.
The output voltage are like the tips of a 3-prong propellor blade, the moving midpoint means the center of the propellor moves up and down. All very
much like the rotor in a Wankel engine.

Every cycle the controller determines whether to increase or decrease phi and ampli (so phase and amplitude of the 3 motor signals).

e: every cycle this coefficient is added or subtracted from the phase phi, but it's contribution will be forgotten by the next cycle. It is kind of a momentary jump in phase, one which will be forgotten by the next cycle. It is a coefficient necessary for loop stability, it's minimum value is 20 times coefficient f. The value 320 represents (320/65536)*360 = 1.76 degrees

f: every cycle this coefficient is added to or subtracted from the phase phi but its contribution is not forgotten, it represents the phase advance (or retreat) every cycle. When a motor is running you need a constant phase advance, as the back emf sine waves keep advancing and the controller needs to keep up with this. The value of 16 represents (16/65536)*360 = 0.09 degrees.

g: every cycle the phase phi is also increased by a constant phase increase which I call phi_int. Phi_int is updated every cycle by the value of coefficient g. So if phi_int for instance is 100, it means every cycle the phase phi is automatically advanced by 100 (/65536 * 360 = 0.55 degrees). This automatic advance comes on top of the advance of coefficient f. For stability g must be less than 1/40th of f.

When the motor is running at a constant speed, all contributions from coefficients e and f will average out to 0. The phase advance of the internal variable phi purely comes from its automatic updating with phi_int. When the motor slows down or speeds up, the controller will immediately respond with phase updates from coefficient e and f, but coefficient g means also the automatic phase update phi_int will increase (speed up) or decrease (slow down).
Phi_int is a measure of motor speed. With phi_int = 100, phi will be increase 40000 times a second with 100, so a total phase advance of (100 * 40000) / 65536 times 360 = 21.97 times 360
degrees, so 21.97 e-rotations per second (times 60 for per minute = 1318 erpm)

the amplitude coefficients work the same.

h: is added to the amplitude every cycle but will be forgotten by the next. With 60V battery, 120 represents a peak-peak increase/decrease of (120/32767) * 1.15 * 60 = 0.253 V
i: is the update for the amplitude variable that will not be forgotten from cycle to cycle, 6 represents 12.6 mV
j: and this coefficient accumulates in the automatic amplitude update variable which will be added to the amplitude every cycle...

hope this clarifies things a bit...
 
I have just read what you explained, Lebowski, but I don't understand it all.

I think I need to have some basics confirmed to understand things. Like, what is amplitude? I think it is the sine peak-peak voltage, and a low amplitude makes the motor run slow (the motor have low torque) and a high amplitude makes the motor run fast (more torque). But if this is incorrect, I need it explained.

And what is phase advance? Is this the timing of the sine waves? I know the sine waves will have to be applied to the motor phases at the correct motor position to make optimal torque, but why does the phase advance/timing change all the time? Doesn't it only change when the motor is changing it's speed (accelerating or decelerating)?

Edit: I just read the added portion of your thread. From what I understand of it, the values determine how fast the controller can change the speed of the motor, or rather how fast the motor can change speed and the controller can keep up. So if the motor changes it's speed faster than what the controller can follow, an error occurs, like if the motor is accelerating too fast (no load) or spinning down too fast (sudden high load).

Am I getting close?
 
Lebowski said:
point by point:
1. the controller IC runs several controll loops, the speed at which these respond to changes depend on the setting (they kinda have to 'spool' up and down). Incorrect settings make the response slow, but it will never be able to respond properly to locking up the wheel at speed (as this is a practically instant event). That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make upto around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.
Cant you just let it watch the motor position(s) for a length of time then softly ramp up the current again after the motor starts to turn again??
 
Arlo1 said:
Lebowski said:
point by point:
1. the controller IC runs several controll loops, the speed at which these respond to changes depend on the setting (they kinda have to 'spool' up and down). Incorrect settings make the response slow, but it will never be able to respond properly to locking up the wheel at speed (as this is a practically instant event). That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make upto around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.
Cant you just let it watch the motor position(s) for a length of time then softly ramp up the current again after the motor starts to turn again??
if it were that simple....
 
Lebowski said:
Arlo1 said:
Lebowski said:
point by point:
1. the controller IC runs several controll loops, the speed at which these respond to changes depend on the setting (they kinda have to 'spool' up and down). Incorrect settings make the response slow, but it will never be able to respond properly to locking up the wheel at speed (as this is a practically instant event). That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make upto around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.
Cant you just let it watch the motor position(s) for a length of time then softly ramp up the current again after the motor starts to turn again??
if it were that simple....
Well I can tell you when I'm flying though the air on my Motorcross bike and I have the front end to high I need to hit the brakes and lock up the rear wheel for a bit to bring the front down. But I need to have power again before I land....
So something will need to be done to make this work.
 
A lot to digest there.

I guess I'll try moving to V2.10 since V1.21 development is done and see if some of the issues such as locking the rear wheel and then having the motor try to restart while coasting still happens.
 
Lebowski said:
Lets assume a f_sample of 40kHz
Apologies - one small question, perhaps it's been asked before: Why 40 kHz and not 44 or 48? I ask from the perspective of audio frequency, being that CD players sample at twice the human hearing limit... of which for most of us is below 22 kHz. :) Does it have to do with performance and loss?

Just curious.

Thanks! KF
 
Switching losses increase with increasing frequency. There is a balance between switching losses, current ripple losses, and motor switching noise. That balance point is usually between 12 and 100khz...but there are no set rules.
 
zombiess said:
A lot to digest there.

I guess I'll try moving to V2.10 since V1.21 development is done and see if some of the issues such as locking the rear wheel and then having the motor try to restart while coasting still happens.

I guess if the throttle is closed, when you lock the wheel it will fault to drive 0 but because the motor is stopped (locked) and the throttle is closed it will go to drive 1 .
Motor stopped and throttle closed are the safety things I built in, so that it doesn't accidentally lock the motor if it faults out to drive_0, also it prevents accidents for
when you switch on the controller while accidenlty giving full throttle.

which mode have you tried ? sensorless push start ? try a low current but a high % (oh man I already forgot how all this stuff is called). You can also try
sensorless self start, its not that different from push start.
 
Kingfish said:
Lebowski said:
Lets assume a f_sample of 40kHz
Apologies - one small question, perhaps it's been asked before: Why 40 kHz and not 44 or 48? I ask from the perspective of audio frequency, being that CD players sample at twice the human hearing limit... of which for most of us is below 22 kHz. :) Does it have to do with performance and loss?

Just curious.

Thanks! KF
its a variable the user can set so, no specific reason for 40 kHz. In 2.10 it auto completes this value by using f_sample = 2 * f_pwm - 1 kHz, but limited to 45 kHz.
 
big thumb up to Lebowsky for the immense controller evolution, I just finished to read the thread
up from start in the last few days. :D
Umbelievable features squeezed inside that tiny controller brain. :D
Looks like top notch research is made available to the layman, at popular price and effort.
I see that totally silent operation is tailored perfectly to ebike general use, but my question is, for high power
motorbike use, is it not convenient to have a bit of motor noise, pleasurable noise, to help people noticing the veichle
approaching at perhaps 130kmph? I assume that driving with sinewave a sinewave motor would imply
to spend a bit of power in harmonics to make the noise, but possibly someone would be happy :p
Just some thoughts,
have fun and thank you for the effort!
 
Hi Lebowski,

Lebowski said:
That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make up to around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.

Arlo1 said:
Well I can tell you when I'm flying though the air on my Motorcross bike and I have the front end to high I need to hit the brakes and lock up the rear wheel for a bit to bring the front down. But I need to have power again before I land....

So something will need to be done to make this work.
Could you have a manual reset button?
 
MitchJi said:
Hi Lebowski,

Lebowski said:
That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make up to around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.

Arlo1 said:
Well I can tell you when I'm flying though the air on my Motorcross bike and I have the front end to high I need to hit the brakes and lock up the rear wheel for a bit to bring the front down. But I need to have power again before I land....

So something will need to be done to make this work.
Could you have a manual reset button?
When it loses control or thinks its about to lose it, it goes to drive 0 , which is the same as a reset... but you can always manually reset of course
 
what are the criteria for "thinks it is about to lose control" ?
 
Does version 2.10 allow for recovery of a locked rear wheel?

Does foc work well without the battery pack being brought onto the brain board, you previously mentioned it works, but is better when it know the pack voltage? I do not like having the traction pack connected to the brain board unless it's isolated. Do you have a method to communicate the pack voltage to the chip through an isolated connection, or do I need to invent a voltage monitor that's optically coupled to the brain board which does A->D->opto->D->A to pin 6. Chip would measure pack voltage then communicate it by serial protocol over an opto isolator then another chip would translate it back to an analog signal. Sounds complicated, but isolating the traction pack from the brain board is pretty important.
 
current error to big, do you mean the PI regulator is saturated?
 
Hi Lebowski,
Lebowski said:
MitchJi said:
Lebowski said:
That it doesn't restart in drive_0 unless you come to a complete stop, I know how to restart on the fly but the 30F microcontroller doesn't offer the necessary features for this on it's PWM module (it would need to be able to make up to around 100 usec deadtime which it cant). In absence of this, the only way to restart safely is to wait for the motor to come to a complete stop.

Arlo1 said:
Well I can tell you when I'm flying though the air on my Motorcross bike and I have the front end to high I need to hit the brakes and lock up the rear wheel for a bit to bring the front down. But I need to have power again before I land....

So something will need to be done to make this work.
Could you have a manual reset button?
When it loses control or thinks its about to lose it, it goes to drive 0 , which is the same as a reset... but you can always manually reset of course
Is this something that Arlin could use with a button on his handle bars to reset it on the fly?

If that would work how long would it take to complete the reset and restore power to the wheel?
 
HighHopes said:
current error to big, do you mean the PI regulator is saturated?
No, that doesn't saturate. And it's not PI, it's PI I^2 :D 3rd order systems.

As you probably know, higher order controll loops can track a system very accurately but cannot respond instantly.
So, when due to an external force the motor speeds up or slows down instantly, the loops don't respond fast
enough (based on coefficients), the controller sees this and it releases the motor. Another reason would be
when,for whatever reason, there's too much noise on the signals.
 
zombiess said:
Does version 2.10 allow for recovery of a locked rear wheel?

Does foc work well without the battery pack being brought onto the brain board, you previously mentioned it works, but is better when it know the pack voltage? I do not like having the traction pack connected to the brain board unless it's isolated. Do you have a method to communicate the pack voltage to the chip through an isolated connection, or do I need to invent a voltage monitor that's optically coupled to the brain board which does A->D->opto->D->A to pin 6. Chip would measure pack voltage then communicate it by serial protocol over an opto isolator then another chip would translate it back to an analog signal. Sounds complicated, but isolating the traction pack from the brain board is pretty important.

What you have to realise is that a sine wave converter supplies power to all 3 motor terminals and that, in order for the motor to spin 'freely', the controller actually
has to exactly match all three phase voltages so that no effective current is flowing. If you want to catch a spinning motor (because the wheel was brake locked but the vehicle
is still moving) you will need to match the motor voltages exactly, but you have no information...

Anyways, no special attention was paid to this for v2.10 , it has the HF startup (much improved over v2.00) and an improved 'normal' sensorless start. The HF is definately not suited
for re-starting a spinning motor as it will lock the motor in a pre-set position (for about 1 to 2 seconds). The normal sensorless is now so good I can actually drive away on this
from standstill (up a 1% incline even), but I do have some slack in the chain and a freewheel, making this posible. It now has 2 separate sets of coefficients for start and normal
running, I can imagin you have a chance of capturing a running motor when you use extra large coefficients in the phase loop.

You can omit the link from battery voltage to the chip but this will make the FOC less accurate. Again, inside it calculates the necessary voltages, and to translate these correctly
to PWM dutycycles it needs to know the battery voltage. I have no issues or recervations about bringing the battery voltage to teh brainboard.
 
Futterama said:
Lebowski, what are the requirements to ripple voltage on the 5V supply for the dsPIC?

I mean, how much ripple voltage is allowed for the dsPIC to still function properly?

You need a lot of caps on the 5V supply, at least one pair of 47uF / 100nF at each supply pin (there are 4).
The chip runs internally at 120 MHz, takes 200mA of current from 5V. This is not a small processor.

I believe brown-out is set at 4.2 V...
 
The reason I'm asking is because I'm going to use a LTC3630A "High Efficiency, 76V 500mA Synchronous Step-Down Converter" and the Excel sheet I got from a Linear Tech person has a calculation for output ripple voltage vs. output capacitance at full load (that's at 500mA). The converter runs at 200kHz nominal. I was thinking 50-100mV ripple would be okay for a PIC but I'm just not sure because I don't know what is going on inside your chip, if there is anything supply voltage dependent.

Regarding your comment about 4 supply pins, do you count AVDD/AVSS as a supply pin set? Otherwise I can only see pins 11/12, pins 20/21 and pins 31/32 = 3 sets of supply pins.
 
Back
Top