build your very own Lebowski controller !

This is all very interesting, but well over my head. How does this differ from Xie Chang controller, or others?

I've been trying to find out the advantages and disadvantages of this controller.
The first page on this thread topic had some, plus this statement in another thread.
My intention and interest is to develop my controller IC further and to include power
startup with full torque at motor standstill, without hall sensors.

But over-all it would be nice to get a list in point form.
 
New version 2.70 available ! :D

This version has the option to save the chip status at the moment an error is detected, to ease debugging, see also

https://endless-sphere.com/forums/viewtopic.php?f=30&t=57877&start=200#p1191527
 
Yesterday I started to build my very own Lebowski controller... and failed already at the power supply :(

The 5V part is perfect. It is constant from 20V to 36V input. And it is constant with or without any load :D

But ---
the 15V output rises with a rising Input voltage. When about 36V input it is around 18V and the Vcc of the mosfet driver U12 has 20.5 V which already killed one of the chips.
Well - the 15V part is regulating. The output voltage does not change when a load is connected. Also the zero time of the mosfet gate is increasing when the input voltage rises. But not enough...

My battery will be a lifepo4 16s. So when full loaded there will be a voltage near 60V.

Any hints what is going wrong?
 
Have a look at the two stacked zener diodes and the resistor. Did you calculate the resistor for 60 V ? Did you put zenerdiodes and not (accidently) a normal diode ? All diodes the right way around ? And finally, it is better to have a little bit of load, so did you put both power indicator LEDs in ?
 
Lebowski said:
Have a look at the two stacked zener diodes and the resistor. Did you calculate the resistor for 60 V ? Did you put zenerdiodes and not (accidently) a normal diode ? All diodes the right way around ? And finally, it is better to have a little bit of load, so did you put both power indicator LEDs in ?

Yes - the zeners and the resistor are right. But i calculated the resistor R82 to the minimum voltage of 48V (22k). But the power LEDs are very old ones. They are on when input voltage is more then 20V. But when i measure then voltages at the zeners it is 3.5V and 13.5V. So I double controlled if they are realy 5V and 10V and they are. Maybe I should try to change the LEDs to newer ones.
 
Also have a look at the 15V feedback resistor divider. It is the resistive divider that takes in the 15V and feeds it back to the 12F. The control loop is such that the 12F wants to see 0.6V on its feedback pin. If the 15V is always about half the battery voltage, it looks as if the 12F is always getting less than 0.6V and is hence constantly pulsing the NMOS power transistor.

Both the 5V and 15V resistive divider are on the right side of the 12F on the PCB.
 
izeman said:
@lebowksi: do you see any disadvantage to use 200A sensors instead of 100A ones? resolution is twice as good for the smaller ones - 20mv/A compared to 10mV/A, but does that really matter? i don't know if i need 100A+, but it can't hurt to have the possibility.
not ideal but as you want to run more than 100A you will use the 200A for more than 50% of the range... should be OK.
 
Lebowski said:
Starting with v2.60 the controller IC uses the hall signals directly. From Izeman's MAC I have seen the hall sensors or their wiring pick up a lot of noise as the phase current increases, to the point where the hall sensor signals become complete garbage. Therefore I recommend to rplace the pull up resistors with the following analog filter in each hall signal:

As all analog filters have a delay, with the above components the delay is 10 degrees at 5 k-erpm.
In 2.60: the calibration speed is half the max speed set with options a and b in the erpm menu. Best to set these to around 10k-erpm, as not to have too big an error in the hall measurement due to the analog delay.
For existing PCB's: the capacitors can also be to 5V, so on the board you can replace the resistors to 5V with capacitors. The resistors can then be added in the hall wiring.

Errata from a few days later: i have the feeling this circuit brings too much delay and it is better to stick with just the original pull up resistors...
I'm revising my files... And I see you are back and forth on this. :)

Getting a clean hall signal to the brain in the first place is the #1 order or priority then try to clean it up a bit more if needed. Why no run a voltage divider on the hall signals holding them at 2.5v a 2k2 to positive and a 2k2 to negative. then about a 10nf cap on each signal to ground to minimize delay in the signal.??
 
this won't work if your hall sensors are open collector output. In that case you need the schematic I posted, as the hall sensor itself cannot produce a positive output voltage.

With my setup here I have seen the delay from the external filter, I get like 15 degree difference in the hall position readings between forward and reverse at a few k-erpm. This is not good.
The problem comes from the analog external filter also being in the signal path during hall calibration.

If you skip the external filter the chip only has its internal digital filter, and this digital filter is not used for hall calibration. So even if the digital filter gives delay it does not affect the calibration.
The tau (R*C for analog, so 150usec for 2200 ohm and 68nF) of the digital filter is 4 / f_sample, or also 150usec for 27kHz f_sample. So, the RC filter helps a bit but does not do a lot more
than the digital filter already does, but with calibration error. So therefore I decided maybe its better not to have an external analog filter...
 
Animalector said:
:mrgreen: :mrgreen: :mrgreen: but then again maybe it is :mrgreen: :mrgreen: :mrgreen:


or then again maybe its not...... :mrgreen:

LMFAO
 
One think with my experience I can say. I can feel the timing advance when the system transitions to sensor less with the filter as thats what I used on the YSR controller.

But with the Simple pull up resistors the transition is smooth from sensored to sensorless. I just got some sheilded cable last night and in the next few days I hope to test that and shield the noise out of the halls. My problem right now is I can not give it much power in sensored operation and I bet its the sensor signals getting noise.
 
Lebowski said:
The controller will work at 48V, the only thing affected by this is the power supply. I haven't tested it at these low voltages. I imagine the 1.5mH inductor must be reduced, I would try 470uH for 48V. I haven't tested this though so cannot be sure it'll be OK.

ps. i can probably upload a second program for the 12f617 that does work for low voltages (24 to 48) and the schematic as is, all that needs changing i think is the pulse width for the 4115 / 4110

I have the power supplies set up on 14s (49.9V atm). They look good but they're only running an LED - maybe they will fail at bottom of charge and with the load of the FET drivers ? Could you give an idea how to modify your code to change the pulse width of the 4115 / 4110 for low voltage running of the circuit as is?

Thanks, Paul
 
I know you programmed the 12F yourself... have a look again at the first posts of this thread. Just yesterday I uploaded two hex files for the 12F, one for 36V to 80V and one for 60V to 150V . If you use the 36 to 80V one you should be OK at 49V.

The difference between the two is the maximum duty cycle it will use for controlling the NMOS power supply transistor (33% and 50%, dependent on high or low voltage version). The supply will work when V_battery * (33% or 50%) is higher than 15V.
 
Ahh, Cracking!
I didn't look since yesterday - was busy re-reading the thread.
Yes I did program the 12F myself. It was my first time programming a PIC. I run Ubuntu on an old dell machine, I found a program called pk2cmd which drives the Pickit2 in a terminal. It did take me a bit of time to get that installed due to some files requiring to be updated, but following a couple of web posts (see below) I finally managed it and can now program devices with a hex file directly from the command line.
So your modified hex file is perfect for me. Thanks again :)

Edit:
These are the web pages I used to get pk2cmd installed on Ubuntu:
http://hsblog.mexchip.com/en/2010/07/how-to-use-the-pickit2-programmer-under-linux/
http://www.waveguide.se/?article=programming-pics-using-the-pickit2-and-pk2cmd
http://hackaday.com/2010/11/03/how-to-program-pics-using-linux/
 
Next question..

So I now have the power supplies nice and tight, 15.5V and 5.2V.
This afternoon I put the last of my components on the board, then I put in the 30F4011, powered up and saw the drive 0 led lit. It lives, great!
Next I put a toggle switch on the setup and reset jumpers, connected the Ugreen RS232 - USB converter lead. I installed gtkterm and after selecting the correct port and changing configuration settings as in the manual, I did get communication with the chip :); but, strangely, the formatting is all out of alignment..? All the menu seems to be there ( I have changed the battery voltage), its just difficult to read. I'm not sure how to post a screen shot, so, it seems to be printing a new line not at the LHS but from underneath the last character of the line above.

Has anyone seen this before and what to do to get it looking like page 1 of this thread?

Anyway, its a buzz to see it live after all this time.
 
pguk said:
Next question..

So I now have the power supplies nice and tight, 15.5V and 5.2V.
This afternoon I put the last of my components on the board, then I put in the 30F4011, powered up and saw the drive 0 led lit. It lives, great!
Next I put a toggle switch on the setup and reset jumpers, connected the Ugreen RS232 - USB converter lead. I installed gtkterm and after selecting the correct port and changing configuration settings as in the manual, I did get communication with the chip :); but, strangely, the formatting is all out of alignment..? All the menu seems to be there ( I have changed the battery voltage), its just difficult to read. I'm not sure how to post a screen shot, so, it seems to be printing a new line not at the LHS but from underneath the last character of the line above.

Has anyone seen this before and what to do to get it looking like page 1 of this thread?

Anyway, its a buzz to see it live after all this time.

See if you have any option to enable "line feed" in the terminal emulator. That did it for me.
 
Line feed, CR and LF are the sort of terms you are looking for, each terminal is different but they all have an option to automatically add the line feed after a CR character.

Enjoy
 
Hi Lebowski,

Great to see V2.7 out. Just wondering if it's possible to get live data out of the controller? And if so, what parameters?

Additionally, myself and my brother will be in Switzerland in December and would love to meet you if you're around.

Cheers,

James
 
Really an amazingly great job Lebowski. I am pulling my hat. But I still have a question. Maybe I was just too stupid to find it in the posts, but....how does the controller behave ? Is it a pure torque control or speed control ? I am currently using a Kelly KBX which also claims to support "torque", but in reality it is not a real torque mode. As I am using it in an electric trial bike the following happens: Open throttle -> Motor accelerates (so far not too bad :)) Close throttle completely, motor runs freewheel (perfect). But if I do not close the throttle completely the controller brakes the motor. Before I start to build a controller, I want to be 100% sure that the controller behaves 100% torque controlled. Means Opening the throttle accelerates, closing the throttle has no braking effect. Thanks a lot for any experience or feedback.
 
FelixSphere said:
Really an amazingly great job Lebowski. I am pulling my hat. But I still have a question. Maybe I was just too stupid to find it in the posts, but....how does the controller behave ? Is it a pure torque control or speed control ? I am currently using a Kelly KBX which also claims to support "torque", but in reality it is not a real torque mode. As I am using it in an electric trial bike the following happens: Open throttle -> Motor accelerates (so far not too bad :)) Close throttle completely, motor runs freewheel (perfect). But if I do not close the throttle completely the controller brakes the motor. Before I start to build a controller, I want to be 100% sure that the controller behaves 100% torque controlled. Means Opening the throttle accelerates, closing the throttle has no braking effect. Thanks a lot for any experience or feedback.
Torque control. That's the way to do it. Controlling current in the motor and the power switches is how you protect the motor and power switches from being fed to much current. And it just so happens the current in in the power switches and motor is what controls torque.
Speed control is not required for many applications as you will end up with uncontrollable torque until you achieve the speed. Which makes for a shitty riding/driving experience and typically causes unnecessary stress on motors and switching components.
 
Back
Top