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

After some back and forth with Lewoski it now spins up and starts from start.

So It would not run with the high sample rate. Did all menus on auto complete and it worked, measurement no longer hung up.

Turns out the induction of the motor is around 600 uh according to the measurement. This would mean a high torque motor, or high voltage one. Very weird an high induction and 70 khz sample rate leads to the controller hanging, could you explain this Lewboski?

Due to this test I can now justify (not like there is a sane reason) to invest in creation of metal parts to adapt this motor to a vehicle for some good testing.

Right now running this code. Got to tweak it so its a cleaner start and regens smoothly, add-on potentiometer. Due to the high inertia compared to the tiny test motor this one takes a long time to spool down.

Code: 
0xB304	0x0D9B	0x0134	0x8FFE	0x1E75	0x0744	0x310B	0x0035
0x001A	0x0026	0x7FBC	0x018E	0x0000	0x0064	0x8000	0x01F2
0x00F9	0x03B2	0x03F5	0x03F3	0x03F2	0xAAAA	0xAAAA	0xAAAA
0x0BB7	0x04AF	0x008F	0x05DB	0x0006	0xE676	0x0380	0x0000
0x0000	0x0000	0x1000	0x0000	0x0000	0xFFFF	0xFFFF	0x00F3
0x026A	0x07CA	0x0063	0x07CA	0x022D	0x03E8	0x0258	0x0064
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0x0000	0x999A	0x0030	0x0000
0x01E0	0xFFFF	0x6666	0xFFD0	0x0000	0xFE20	0x0000	0x07AE
0x0030	0x0000	0x01E0	0xFFFF	0xF852	0xFFD0	0x0000	0xFE20
0x0003	0x0000	0x0078	0x0000	0x0000	0xFFFD	0x0000	0xFF88
0x0000	0x0000	0x0000	0x0000	0x0003	0x0000	0x00C8	0x0000
0x0000	0xFFFD	0x0000	0xFF38	0x0000	0x0000	0x000C	0x0000
0x00F0	0x0000	0x0000	0xFFF4	0x0000	0xFF10	0x05AB	0x2721
0x02EB	0x028E	0x0116	0x006D	0x01D4	0x7530	0x028E	0x0010
0x03BA	0x0042	0x0010	0x0E10	0x0000	0x03E8	0x00C8	0x2716
0x03B6	0x6000	0x018E	0x028F	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0x4000	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF
0xFFFF	0xFFFF	0xFFFF	0xFFFF	0xFFFF	0x0000	0x0000	0x0000
0x0032	0xFFFF	0xC519	0x764B	0x5482	0x41B3	0x35C3	0x2D7A
0x276B	0x22C9	0x1F1E	0x1C28	0x19B5	0x17A6	0x15E6	0x1463
0x1312	0x11EB	0x10E4	0x0FFB	0x0F28	0x0E6B	0x0DC0	0x0D23
0x0C94	0x0C10	0x0B97	0x0B27	0x0ABF	0x0A5F	0x0A05	0x09B1
0x0962	*
 
looks like you did not autocomplete the sampling freq but you halved it to 20 kHz ? If so, better chose 19 or 21 kHz as harmonics (multiples) of the pwm freq are better avoided.

Basically, for the small RC motor the controller needs to be able to respond quickly. How fast it responds depends on sample freq (higher is faster) and control loop
coefficients (higher is faster). So for you small motor I thought it better to recommend an increased sample freq as the standard coefficients are quite high.
For this big motor though, due to the inertia it is not a fast motor so a lower fsample is better.
 
I changed it back, because the motor has so many poles.
Might try increasing it more, to get the motor to spin to higher rpm's smoothly.
 
I know, and reset the erpm limits and the filter ect. I will do some turning next weekend. No time this week due to Carnaval. :D
 
I thought it would be interesting to measure the temperature of motor windings by measuring the winding resistance in run-time. The temp. coeff. of copper is 0.4%/°C, that seems fairly enough, and then an NTC sensor and wires are not needed. But I don't know if it is already implemented in a controller or not.
The sensorless FOC normally calculates the EMF, and based on it I could imagine 2 methods:
- the sine frequency multiplied by the motor constant should match the EMF, and if it is not the same as the EMF calculated from the phase voltages and currents, then it is due to the change of the resistance.
- in the FOC control loop if there is a permanent shift of the detected error signal, then it refers to the change of R if other parameters remain the same. The estimated R could be adjusted in very small steps in every control cycle with a heavy low-pass filter or by slow integration (similar to oversampling+LPF), because there are a lot of measurements compared to the slow change of the temperature.
Lebowski what do you think, does it makes sense and is it feasible?
 
As mentioned I was cooking up or rather baking something as a parmant fix to my proto board.

DSC_0311r.jpg
Baking, next to an old pcb of my BMS project used as standoff

DSC_0317r.jpg
Fresh out of the oven

DSC_0323r.jpg
All soldered up


And once again

The PCB contains only the bare essentials, as I want to run sensorless, so no input for hall sensors. The Left side connector is for the inputs/outputs; Throttles, Reset, reverse, Serial and canbus. Top connector are the gate drives, bottom is the current sensors. The pcb measures a mere 48mm wide by 65mm long, the reason for keeping it small is to be able to easily tuck it inside OEM inverters, without hacking off bits or the original pcb. Planning to test it this week and fit it in the Honda IMA inverter I have, for a true OEM look.
 
peters said:
I thought it would be interesting to measure the temperature of motor windings by measuring the winding resistance in run-time. The temp. coeff. of copper is 0.4%/°C, that seems fairly enough, and then an NTC sensor and wires are not needed. But I don't know if it is already implemented in a controller or not.
The sensorless FOC normally calculates the EMF, and based on it I could imagine 2 methods:
- the sine frequency multiplied by the motor constant should match the EMF, and if it is not the same as the EMF calculated from the phase voltages and currents, then it is due to the change of the resistance.
- in the FOC control loop if there is a permanent shift of the detected error signal, then it refers to the change of R if other parameters remain the same. The estimated R could be adjusted in very small steps in every control cycle with a heavy low-pass filter or by slow integration (similar to oversampling+LPF), because there are a lot of measurements compared to the slow change of the temperature.
Lebowski what do you think, does it makes sense and is it feasible?
Click to expand...

I've thought about this but would do it differenyly from what you describe. Using adaptive filtering i would process voltages and currents continuously and derive a running average of Kv, L and R. I expect all ofthem to be temperature dependent, not just the resistor. Assigning all variations to the resistor I think would not be correct. But adding this to the controller is not a priority for me, plus it would take a lot of processing power which would limit the max achievable erpm... i'm toying with the idea to go to a Cortex-M3 or M4 but dont like smd chips and the 3.3V they run on.
 
I will try to implement it if I get to it sometime. Would be good to have only the 3 phase wires to the motor and remove all the small wires.
I spent the last year with Atmel 8-bit uC-s, made a display connected on USB and CAN bus, a motor controller board also on CAN with a sensored FOC (synchronized to hall sensors) and bootloaders for firmware download via USB and CAN, which work nicely, but there are limitations and I had to realize if I want a smarter system then I have to change to a more modern platform. Then after considering many options finally I chose STM32F303. It runs at 72MHz, but almost fully pin compatible with the F4xx series that is 168MHz (but has some ADC noise problems according to an app note...)
 
Lebowski said:
izeman said:
Lebowski said:
... Reason for this can be that maybe the MAC is an unusually slow motor. Most motors I've seen have a L/R of about 1 millisecond, it might
be that your motor is slower (meaning it has a high inductance and a low resistance). For this the bandwidth of the control loops must be reduced (at the moment they are at about 300 Hz)
Click to expand...

resistance phase/phase is 0.045mOhm
inductance is 80mH

just in case you need those values ...
Click to expand...

so you measure 0.045mOhm between two phases with the 3rd hanging open ? This makes it 0.023mOhm per phase (in wye), L/R is then 3.5 msec.... slow motor indeed
Click to expand...


I'm going through all the threads for the Lebowski controller to gain knowledge for an upcoming "conversion" , and as I also have a MAC motor currently running on the Adaptto, this discussion from June 09 2015 8:00AM (page 49) interests me a lot.
In the last sentence, Lebowski seems to have assumed that the MAC is wired in WYE, but in fact it is wired in Delta.
So, it is probable that all the calculations that followed are not exact, but I'm not qualified enough to judge by how much.
Therefore, I wonder if Lebowski could re-visit this old conversation and comment on the applicability of the calculations for the Delta-wound motor.

Furthermore, I was planning to rewind my motor from a 12t to a 9t.
As the motor seems to have a lot of inductance, (each phase is wound as 4 groups of 3 adjacent poles), I wonder if it would be worthwhile to split each phase in two, and parallel both halves, thereby cutting the inductance in 4...

And in the event that the phases would be split in two like this, I assume that to conserve the same Kv as originally planned, the number of turns would have to be adjusted, but again I'm not knowledgeable enough to figure out by how much. :roll:
 
A motor can be wound in Delta or WYE, and INDEPENDENT of that you can chose to express the motor impedance in Delta or WYE.

Have a look at:
https://en.wikipedia.org/wiki/Y-%CE%94_transform

This wikipedia page explains how any network (like a motor) with 3 terminals (independent of how the network is build) can be modelled
by 3 components in a Delta configuration or 3 components in WYE configuration. Therefore, whenever you talk about motor inductance or
resistance you have to metion whether you're assuming the components to be in Delta or WYE.

So, the controller IC can work with both Delta and WYE motors, but when the controller IC displays motor resistance and inductance
the values are for the WYE configuration.

Winding the motor differently is not going to change its basic properties. L/R will not be affected. The only reason to re-wind would be to
make the motor better match the battery voltage you have in mind. Power and torque however will not change.
 
Thank you very much, Lebowski for this thorough explanation.
Your contribution on this forum is always outstanding!

I was aware that I couldn't change the power of my motor by going to a different Kv, however I'm still not sure that there would be an advantage in splitting and paralleling each phase to reduce the inductance. This motor is known to be difficult to drive, maybe that could be the solution... What do you think?

Thanks again!
 
@altair: i guess you're referencing to my findings with the MAC. well, as others have written: that's the motor from hell. some really strange things going on here. i sent leb a mac to test out and he made some very interesting findings. maybe he will post them here.
if you're intersted in this topic you may check posts in the 'kelly sine wave controller' thread as well. lots of info about problems there as well.
if someone can make a working controller that compensates all errors of the macs then it's lebowski. but i could understand if there never will be a working solution because of low demand compared to the mass of work involved.
 
Yes izeman !
I have read most of your posts regarding your problems with this motor (on different threads), and you have been very patient with this motor :wink:
One of the threads was "Converting a middrive hubmotor to a middrive motor" in which I posted.
I don't think I'll be as patient as you, but if indeed a miracle happens, it will probably come from no one else than Lebowski.
Keeping fingers crossed!
 
I'm working on it :D but at the moment I don't have that much time due to dayjob :(

What I found so far:
- motor runs and starts fine sensorless (no excessive 5th order harmonics, what I was expecting)
- to get it to do this an internal overflow has been fixed (compared to the old v2.40), overflow was due to more than 45deg field shift (see later)
- startup was not smooth but hickupy, fixed this by auto-reducing phase current when the controllers detects it's loosing sync.
- w.r.t. all the other motors I've seen the magnetic field from the permanent magnets is relatively weak, probably due to the gap between rotor and stator being large (about 1.5 to 2 mm)
- because of this, the magnetic field inside the stator teeth moves over 60 degrees when you apply up to 80A phase current (peak, so 50A RMS)
- this means that when the motor is standing still and you apply phase current, the field will move over 60 degrees and a different set of halls gets activated
- to make this work with a standard China controller the halls are pre-shifted 30 degrees (with respect to all the other motors I've seen)
- in the controller IC I will correct for the (momentary) magnetic field shift based on phase current and an auto-measured motor constant
 
This is like a thrilling detective story! If good parameters for the difficult MAC can be found, this will be helpful for other motors as well.
Thanks Lebowski for putting up the setup manual for v2.5 on page 1 of this thread.
 
Lebowski, your answers always blow my mind!
Having you on this forum is the best thing that could happen to the e-bike world :D
Can't wait for the rest of the story.

Izeman, you had modified the placement of your hall sensors at some point. Now I understand that this couldn't do much against the fact that the field moves too much when high current is applied.
I don't remember what is the gap in my motor, but to me it seemed quite large when I was working on it for the conversion to mid-drive.
Maybe the magnets themselves aren't the most powerful...
 
I made a video of the setup of the new v2.60 controller Ic, starting from a completely blank chip:

[youtube]57kRSoOrTxw[/youtube]

0:00 setup of the controller IC, v2.60
8:10 explanation of the motor impedance values
10:20 the new sequence for hall calibration
11:50 magnetic field shift explained
18:10 field weakening

Thanks to Izeman for lending me the innards of a MAC :!: The main thing I figured out was that the hall mode startup
was too fancy for it's own good, it's been replaced with a new much more robust startup and transition to sensorless.

The old hall mode was, while powering on halls, also looking at backemf information. At high phase current, currents
coming from (long) deadtime combined with too high control loop coefficients made the controller think the motor
was running and giving backemf info (while standing still). This triggered a false transition to sensorless, causing the
motor to shake and not spool up. The problem can be fixed by changing the control loop coefficients, but this made
the motor spool up too slowly for my taste. Therefore the new hall startup and transition method implemented in v2.60.

Lastly, the (not satisfactory) HF mode and all its settings have been removed.
 
WOW!
Excellent Lebowski.
Thanks for the explanations for the programming, there were a ton of things in that video that I would never have figured out by myself.
And just think that you updated the program yet another time, fantastic.
Now I have GOT to build your controller.
What is the best source for the PCB right now? Is there someone still selling it? Otherwise I'll have one made locally.

Thanks again!
 
"motor-from-hell"
HA HA ! :p
If the Lebowski can now drive a MAC motor, it will be able to drive ANY other motor.

Now what are you going to set your sights on next, Lebowski? Integrated BMS/Charger à la Adaptto? 8)
 
Well, having spent part of yesterday and this morning reading the threads by animalector and zombiess on their versions of this controller, I can now say that I would like to have a compact arrangement made-up of the CPU board stacked up on the power board. My ideal power board would be similar to zombiess' board, but I think that just one sextet of mosfets would be enough for the power I need. I would like that the current sensors be integrated on the power board to minimize the routing of large conductors.
So, zombiess' arrangement is quite ideal, and I also like its driver boards plugged into the main power board. I don't think that the booster is a necessity however.
I would use IRFP4368 or 4468 mosfets to have the smallest possible dissipation, hopefully eliminating the need for a heatsink.

Now, having well understood the complications inherent in the design of a good high-power board, I have the choice of either, waiting for zombiess to finalize the design of his boards in 6, 12, and 18 FET versions, or try to design my own, based on Lebowski ultra-simple and effective "pigtail" approach :)
My main problem is the lack of time, running my company all day long, and having my airplane in restoration/modification un-finished, and my new bike drivetrain project taking still more time !
Arrrrgh ! :( Oh and I forgot; Spending countless hours on this forum, too. :lol:

If PCboards meeting my needs were available, that would simplify my life. And I'm sure, hundreds of other's, too.
 
Altair said:
"motor-from-hell"
HA HA ! :p
If the Lebowski can now drive a MAC motor, it will be able to drive ANY other motor.

Now what are you going to set your sights on next, Lebowski? Integrated BMS/Charger à la Adaptto? 8)
Click to expand...

A new chip, v 3.00 , will be a 64 pins TQFP... double the processor speed... intended for 1 kA at 120V.
 
You must log in or register to reply here.

Similar threads

H
Modular ESC - Schematic/PCB Review wanted
Replies
10
Views
2,142
hightechasshole
H
Arlo1
Fuji 1MBI800U4B-120 IGBTs new for sale DISCOUNT! Updated September 9 2023
Replies
3
Views
1,679
Arlo1
Arlo1
Sparfuchs
reduce voltage drop between battery and controller
2
Replies
31
Views
4,521
jigs
J
mxlemming
    • Like
    • Doin' Science
GaN and IMS MESC controller boards
2
Replies
31
Views
6,617
mxlemming
mxlemming
argo
Resources for building the Lebowski open-source motor controller in 2020?
Replies
12
Views
7,883
amberwolf
amberwolf
Back
Top