Update files Lebowski controller IC, latest: v2.A1

Lebowski

10 MW
Joined
Jun 27, 2011
Messages
3,412
Location
beautiful Zurich, Switzerland
v2.80: CHECKSUM : B24B 3867 47BD

View attachment toggle280_281_.txt
v2.81: CHECKSUM : 7264 BE01 B468

View attachment toggle281_290_.txt
v2.90: CHECKSUM : 3EC3 EE8D 97A5

View attachment toggle290_291_.txt
v2.91: CHECKSUM : 3844 C681 5810

View attachment toggle291_292_.txt
v2.92: CHECKSUM : 353F C0F3 EF83

View attachment toggle292_293_.txt
v2.93: CHECKSUM : 2396 D075 CE9F

View attachment toggle293_2A0_.txt
v2.A0: CHECKSUM : 5C7A C69C 5C9F

View attachment toggle2A0_2A1_.txt
v2.A1: CHECKSUM : 9D76 A98F 25C6
 
Love this Idea Bas, no more sending our IC back to Switzerland each time (unless we brick them of course :( )
 
Thanks Bas, impressive... Is the update possible only from 2.71 to 2.80 or also from lower versions (in my case v2.50 to 2.80)?
Are you planning to make the update files available here in this thread?
 
Yes, when available I will place the update (or toggle) files in the first post of this thread, together with their correct checksums.

Just mail me the chips you have and I will flash them to v2.80 , after that you can use the updating process as outlined above :D

Am by the way still working on the 1000 A controller idea, but keep getting side-tracked by the controller IC....
 
Brilliant, I will send them. A bit out of topic, but now that you mentioned it... Do you think that the kA-powerstage will be compatible with the actual controller or will it need a faster chip and different layout?
 
emmgee said:
Brilliant, I will send them. A bit out of topic, but now that you mentioned it... Do you think that the kA-powerstage will be compatible with the actual controller or will it need a faster chip and different layout?
I'm working there with a different chip (faster, more memory, 64 pins tqfp), so basically everything is different :D
 
Awesome!
 
Lebowski said:
emmgee said:
Brilliant, I will send them. A bit out of topic, but now that you mentioned it... Do you think that the kA-powerstage will be compatible with the actual controller or will it need a faster chip and different layout?
I'm working there with a different chip (faster, more memory, 64 pins tqfp), so basically everything is different :D
i hope this won't conflict too much with the further development of the actual chip.
 
Tja, there is the normal controller IC to (continuously) develop.. then there is the version for the kA controller.... next to this I sometimes am thinking about a low cost version for limited phase current (50A peak, 30A RMS) which uses shunt resistors and has the controller parts for at least one possibly two DCDC converters also in the controller IC. And lastly I would love to get my hands on a nice Switched Reluctance motor (one without magnets, one where the coils attract iron poles on the rotor) as I am 99% sure that with some modifications I can run those in sensorless FOC too..
 
Although the fascinating switched reluctance motors are not (as far as I know) available on the market in our desired size, compatibility with the lebowski controller would be nice.

My wish for the low cost version would be: Max. 80mm wide instead of 100mm for better compatibility with bicycle frames, maybe stacked brain/power boards, either shunt or hall (ACS758 costs only ~USD 5.- but needs more space) for current measurement. A little more Amps wouldn't hurt...
 
my controller is only 60 - 70mm wide and stacked as you suggest..

Where do you get your ACS758 for $5??? Digikey is $7.58 in low volume and in Australia they're like $13 each That makes a difference on cost.

I'm trying to review my parts list to make my micro-lebowski a bit more affordable. plus a re-design of my CPU board to include the temperature sensing

Andy
 
Andy, you are right: When I ordered 30 units of the ACS758 the price was at EUR 5.54, so in USD it would be a bit more.
Is your smaller board using the components of the original lebowski board, just splitting the board in two sections? As far as I remember you use the smaller controller IC and a different layout, or am I wrong?
 
just wanted to let anyone know, that lebowski sent me a test file and i successfully upgraded the controller IC.
worked w/o any issues, and once you did it, it's really straight forward.
well done! thank you!
this is such a BIG PROGRESS over sending the controller/IC to switzerland and back.
 
first update file published: upgrade to v2.81 .

This update should fix stability issues at high current levels. Quite a major update as far as internal mechanisms and variables goes, so hope I didn't make any mistakes :D
 
I updated 1 of mine and it worked perfectly. Great work. not only that V2.81 might be perfect!!! Very excited.
 
Yesterday evening I posted the new v2.90 update in the first post of this thread. This version includes many fundaments changes for improving stability (less changes of cookouts), a new hall to sensorless transition method (using an observer to see if all goes OK), a better field weakening mechanism and cleaner ramping for the erpm limiter and regen.

The main changes as far as setup:

in the erpm menu there are new settings for the throttle ramping:
Code:
a) erpm limiter (forward) rampdown start, range: 49.97, 2.99 k-erpm
b) erpm limiter (reverse) rampdown start, range: 39.99, 4.97 k-erpm
c) regen rampup start, range: 799, 495 erpm
d) accept direction change below: 78 erpm
e) erpm boundary between dr2 & dr23: 1485 erpm
f) erpm boundary between dr23 & dr3: 3987 erpm

The erpm limits now have a ramp down start and range setting. In the example above, for forward direction the IC will start ramping down the throttle starting at 50 k-erpm over a range of 3 k-erpm. This means that until 50 k-erpm you have 100% throttle. Above 50k-erpm throttle will be linearly reduced to 0% at 50 + 3 (the range setting) = 53k-erpm. In the same way, for reverse throttle is 100% till 40 k-erpm and then reduces to 0% at 45 k-erpm. Final motor speed will depend on motor load but will be somewhere in the 50 and 53 k-erpm forward or 40 and 45 k-erpm reverse (with the settings above).

Regen is now also ramped, such that below regen ramp start (800 erpm in the example above) there is no regen. At 800 erpm regen ramps up from 0% to 100% regen at 800+500 = 1300 erpm.

The transitions between drive 2 and 3 are regulated using options e and f. There is no hysteresis anymore, with the settings above the controller will be in drive 2 below 1500 erpm, in the transition drive mode 23 between 1500 and 4000 erpm and in drive 3 above 4000 erpm.

In hall mode now the PWM and motor control will be shut down when the throttle is closed and erpm drops below the value of option d. PWM off is indicated by the drive 0 LED coming on (next to the already lit drive 2 LED).

Automatic field weakening now works slightly differently:
Code:
  amplitude control loop
h) 1st order: 100
i) 2nd order: 5.0000
j) maximum amplitude: 100 %
k) invoke fieldweakening at amplitude: 95 %
In the control loop coefficients menu it now has a new 'invoke field weakening at amplitude' setting.
Previously the controller IC would ramp up the controller output voltage to the value of option j, and then start ramping up the field weakening current. Doing this however means the controller can no longer adjust the controller output voltage, which can lead to problems with stability.
In 2.90 the controller IC wil ramp up the output voltage till it has reached the setting of option k (95%). Then it will start ramping up the field weakening current. Once maximum field weakening current is reached, the controller IC will ramp up the output voltage further till option j has been reached (100%). WHEN USING FIELD WEAKENING, IN A PROPER SETUP THE CONTROLLER WILL NEVER REACH THE MAXIMUM AMPLITUDE (100%), HAVING RUN INTO THE ERPM LIMITER BY THEN. This to maintain the capability to adjust the output voltage and to maintain proper stability. When you don't use field weakening you will not notice option k (95%).

The transition between hall and sensorless mode (when using hall sensors) is performed in drive_23. In this drive mode the controller will smoothly transition between hall sensor info and sensorless info. An observer was added which can dial back and forth between sensored and sensorless, based on how good things are going:
Code:
b) toggle hall usage
c) magnetic field shift compensation: 0 %
d) calibrate hall mode: yes
e) erpm for hall calibration: 4.97 k-erpm
f) PLL bandwidth: 30 Hz
g) PLL damping factor: 0.71
h) speed filter dr23 50% time: 5.00 msec
i) max speed difference dr23: 5.0 %
'how good things are going' is based on the speed difference the controller observes between hall sensored speed and mixed hall/sensorless speed. When the observed speed difference is lower than the % of option i, the observer dials more towards sensorless and away from sensored. When the speed difference is higher than the % it dials back towards more sensored and less sensorless. Before comparing the two speeds the speed info is filtered with option h.

In the chip status menu there is now an option indicating how far the observer has dialed to sensorless info:
Code:
status bits:               
drive LEDS:                ....
time spent:                0.000 sec
throttle:                  0 %
wanted_i_torque:           0.0 A
wanted_i_fieldweak:        0.0 A
filter_i_torque:           0.0 A
filter_i_fieldweak:        0.0 A
filter_i_error:            0.0 A
Vout_real:                 0 %
Vout_imag:                 0 %
backemf_usage:             0 %
speed_sensorless:          0.00 k-erpm
filter_speed:              0.00 k-erpm
accelleration:             0 %
'Backemf_usage' indicates how much the control loop depends on backemf, as opposed to sensored info. When no hall sensors are used the controller is of course fully dependent on backemf info...
 
updated to v2.91, main change being the better hall drive23 transition mode. In addition there is an extra parameter in the loop coefficients menu:

Code:
  miscellaneous
n) additional motor phase compensation: -2 deg

Keep unless your motor runs bad in drive_3, do not change this value from default (which is 0 deg). It will take from -180 to 180 but useful range is -90 to 0.
If you want to see if the motor runs better with a different value, recommended is to try 0, -15, -30, -45 and -60 .
 
Lebowski said:
updated to v2.91, main change being the better hall drive23 transition mode. In addition there is an extra parameter in the loop coefficients menu:

Code:
  miscellaneous
n) additional motor phase compensation: -2 deg

Keep unless your motor runs bad in drive_3, do not change this value from default (which is 0 deg). It will take from -180 to 180 but useful range is -90 to 0.
If you want to see if the motor runs better with a different value, recommended is to try 0, -15, -30, -45 and -60 .
This is drive 3 so its for sensorless?

What does it actually change?
 
I think I got it. You go 2.8- 2.81 then 2.81 to 2.9 then 2.90 to 2.91......
 
Arlo1 said:
I think I got it. You go 2.8- 2.81 then 2.81 to 2.9 then 2.90 to 2.91......
yep. sometimes it a pit... aehhh time consuming :) but as it works so flawlessly i don't mind those extra effort.
lebowski seems to have implemented a really clever upgrade mechanism that was fool proof so far - well even i didn't manage to ruin a cpu :)
 
Hi bas
We just tried to update v2.80 to v2.81 & have stopped the micro working.
On windows - termite did not have a "dump a file" option so we got tera-term working.
Followed the procedure, row of dots appeared eventually ending in a *
Happy days we thought.
But no more comms to the chip.
There was a "check box" in teraterm labelled "send binary" which we left unchecked- was this our mistake?
Should we try again with this checked on another chip?
Can we send the "bad" one back to be programmed correctly again?
Thanks
Bob
 
bobc said:
Hi bas
We just tried to update v2.80 to v2.81 & have stopped the micro working.
On windows - termite did not have a "dump a file" option so we got tera-term working.
Followed the procedure, row of dots appeared eventually ending in a *
Happy days we thought.
But no more comms to the chip.
There was a "check box" in teraterm labelled "send binary" which we left unchecked- was this our mistake?
Should we try again with this checked on another chip?
Can we send the "bad" one back to be programmed correctly again?
Thanks
Bob
Did you change the baud rate back to 11500xxx?
 
Back
Top