I am already running my bmx at 100v and have been for 2 years for now my plan was ~150v for colossus this will get it into the nice rpm range it needs to make big hp and run at its most efficient levels The kv will be 50-75 when im done. It has 8uH inductance wound at 75kv so..... If you want to run it at 70 volts you will have it always below its peak efficiency there for you Midas well get a more suited motor for what you want. I'm not stupid with connectors and wiring etc. What I build will be safe.Alan B said:
Not simple BLDC controller It RUNS! :)
- Thread starter Arlo1
- Start date
Alan B
100 GW
Arlo1, I wonder if you are confusing me with someone else, I don't have a Colossus.
zEEz
1 kW
Arlo1 said:
Sorry Arlo if I gave you misguided hope ... Unfortunately that fet is nothing incredible ... even at 75v
And for the records, I never managed to get one to test, since no distributor even answered me ... :|
The big players are IXYS and IR here, and it seems -as I already
discussed with lfp- that nobody has more effective parts,
considering performance/price, than what we already use
as to220 and to264 ...
This is SAD, but it is going to be the reality until a big company decide that the world has a need for a
DECENT MOSFET with good capability, enhanced power dissipation and convenient case ...
As it came out from my talk with lfp, the DirectFET from IR -their new baby- is kind of deprecated to
be used in power hungry applications by the producer itself and their engineers suggest to use
to264 devices instead ... WTF is going on there
have fun!
Well the nice thing is this design is modular. I can use something to get it running then just whip up a new power stage when somehting better comes!
So Back on task. I will be programing in C and right now I am using microchips free C compiler but is there something better for free? Or pirated....? Its my understanding the more expensive compilers make the code more efficient so they save space.
So Back on task. I will be programing in C and right now I am using microchips free C compiler but is there something better for free? Or pirated....? Its my understanding the more expensive compilers make the code more efficient so they save space.
zEEz
1 kW
Arlo1 said:
Do you have already a sketch of the code you want to use? and more importantly: have you chosen a
microchip part that provide at least 6 PWM hardware channels and 4 ADC?
I'm telling you this because I would like to avoid you the frustration ... to reinvent a wheel that you
discover is not getting out circular but a square ... or a triangle
C is to me a good choice, but you should consider you need to program a bold RT device ... :lol:
This means your C will have to be very effective already when written out ... 8)
...this means the compiler flavor is not really something to bother with at the initial stage ...
good luck!
I have the PIC18 as posted on the first page but upgraded to DisPIC30.... As bigmoose recomended on the first page. And not started on code so now is the time to get a compiler i will use for a while or just stick with the free version!
zEEz
1 kW
Arlo1 said:
From what I see on the MicroChip site, you need a part with minimum 64pins TQFP
if you want to profit from the 8 hardware pwm ports that are quite a must have
for your controller ... like the dsPIC30F5011 .... 8)
That is what you have???
zEEz
1 kW
Arlo1 said:
I saw the nice board of bigmoose, unfortunately that chip has only 2 pwm hardware output.
I presume some clever trick need to be done at the programming stage to circumvent the convenience
to have enough free hardware pwm outputs to be able to assign one to each mosfet driver...
have fun!
zEEz
1 kW
Arlo1 said:
You are right, they have a typo in the main site, but on the product
page and on datasheet it is written correct: 6 pwm outputs .... 8)
So, looks like you have my blessing too, for what it is worth
have fun!
Oh i will!zEEz said:Arlo1 said:
You are right, they have a typo in the main site, but on the product
page and on datasheet it is written correct: 6 pwm outputs .... 8)
So, looks like you have my blessing too, for what it is worth
have fun!
i just put a sweet workbench together in my basement so i can work where its warm all winter with internet access!hardym
100 W
I'll chime in here again about PIC chips. My understanding is that the lower end chips (e.g. PIC16F2431) have a free C-compiler and the higher end chips (ds-series) do not.
My strong recommendation is to NOT use assembly to get started with PIC. You will pull your hair out trying to figure out when and why you need to switch banks. It's a loony design on the bottom. The great news is that the free microchip hi-tech C compiler and MPLAB is great, the pickit2 is about $30, and If you have a good starting point, it's easy to add on stuff.
For getting started with a BLDC controller usign PIC processor, I'd highly suggest the PIC16F2431, as it is in DIP format (no SMT) and has a free C compiler... AND ... I have already posted a working software set on page 4 of this thread, complete with serial status output to a mini-display.
This software is sensored (based on use of hall-effect sensors), and I recall the origination point of all this was to be un-sensored, so it's not what you want, but its an easy way to get started with PICs and BLDC.
edit: It looks like the original files are no longer available on my first post. So here they are again:
View attachment 1
View attachment Brain-18F2431.zip
Mark.
My strong recommendation is to NOT use assembly to get started with PIC. You will pull your hair out trying to figure out when and why you need to switch banks. It's a loony design on the bottom. The great news is that the free microchip hi-tech C compiler and MPLAB is great, the pickit2 is about $30, and If you have a good starting point, it's easy to add on stuff.
For getting started with a BLDC controller usign PIC processor, I'd highly suggest the PIC16F2431, as it is in DIP format (no SMT) and has a free C compiler... AND ... I have already posted a working software set on page 4 of this thread, complete with serial status output to a mini-display.
This software is sensored (based on use of hall-effect sensors), and I recall the origination point of all this was to be un-sensored, so it's not what you want, but its an easy way to get started with PICs and BLDC.
edit: It looks like the original files are no longer available on my first post. So here they are again:
View attachment 1
View attachment Brain-18F2431.zip
Mark.
Thanks i have. Pickit3 and have a free C compiler that will work with the dsPIC chip which i already have the smd is not a big deal so once again i am 100% going to use the disPICchip i already have!!! I would like to take this time to say to everybody please dont tell me to use a differtnt chip then I already have in my hands!
Lebowski
10 MW
hardym said:
Hi Mark
I looked at your code, it seems hall-sensor based and then a direct switching of the output MOS transistors
with some PWM inserted ?
I'm going a totally different direction, my controller will have:
- calibration to determine relation between hall-sensors and back-emf, for correction of erroneous hall-sensor placement / connections
- sine wave output to motor (actually: amplified back-emf to motor)
- automatic timing advance to compensate for 'delay' in inductor
- current (or torgue) based throttle
- automatic switchover from sensored to unsensored above a certain RPM
Not looking at Regen yet cause my motor setup has a freewheel preventing the wheel from driving the motor.
A 16F or 18F is not powerfull enough for this, a dsPIC 30F should be OK. I never had any problems with bank-switching
in the 16F (assembly) designs I did. As far as programming in assembly and bank-switching and such, I have the
feeling the 30F is actually easier to program than the 16F (due to more registers, on-board multiplier/divider,
do / repeat instructions, a high number of conditional branching instructions and no bank switching). The DSP
part of the 30F will come in handy during the calibration part (for computing the cross-correlations between different
hall sensor / back-EMF signals and FIR-filtering the back-EMF for waveform capture)
bigmoose
1 MW
Hat's off to you Lebowski! Great feature set, all running at the speed of light in your choice of assembler. It's clear you have "been there and done that." Your code will change the landscape of what is possible!
zEEz
1 kW
Lebowski said:
Hi Leb, are you perhaps a freak mind teleporting expert from CIA?
You got your points exactly laid out how I would have liked to do my controller (with MSP430, anyway)...
I would have set probably for a modified sine to motor to decrease mosfet dissipation ... 8)
but beside that I think this kind of controller (particularly with the concurrent hall sensor and backemf
sampling strategy to optimize drive of any motor attached) will make any e-builder not using
off the shelf boring high inductance motors very happy and lucky
Far less burned things, reduced dissipation, optimized power transfer and no timing problems ....
You great guys, have fun!
Lebowski
10 MW
:? first useful output from my fooling around with the 30F4011... Got one of my hallsensors glued in backwards 
Thinking about it after the fact, it fits, wasn't paying attention. Halls are now setup for a 60 degree motor.
Every line is a measurement. I call my sensors hall1, hall2 and hall3. First colum: rising edge hall 1 (and since
this automatically resets the 8.5 usec timer it is by definition 0 degrees), Next colum: falling edge hall 1
(which comes after about 48% of period time as the count is 48% of first colum). After that rising
edge hall 2 (67% of period time), falling hall2, rising hall3 and falling hall3.
Hall 3 seems to be the most off by about 3% (or 10 degrees). And one of them is glued in backwards
To get the numbers i give the motor a whirl and press a key on the laptop. The algorithm captures the content
of a timer on rising/falling edges of hall sensors. The rising edge of hall 1 is used as a reference. To
make sure the measurement is valid the algorithm runs a 2nd order prediction filter to make sure the
measured period time makes sence, else the measurement is discarded. The prediction filter is
2nd order so it can predict constant speed and constant decellaration without error (measurements
are discarded if the prediction is more than 3% wrong)....
For the controller there'll be no issue as I plan not to relate the hall sensors to the motor phases. Switching
of motor phases will be dictated by the prediction filter (which can also extrapolate to accurately switch
inbetween 2 hall sensor edges) , the halls are there for synchronisation. To make sure that
in my mind I don't relate the halls with the motor phase, I call those phase A, B and C (got this
idea from a comedian, in a sketch one team was team 1, the other team A so non would
feel inferior)
Thinking about it after the fact, it fits, wasn't paying attention. Halls are now setup for a 60 degree motor.
Every line is a measurement. I call my sensors hall1, hall2 and hall3. First colum: rising edge hall 1 (and since
this automatically resets the 8.5 usec timer it is by definition 0 degrees), Next colum: falling edge hall 1
(which comes after about 48% of period time as the count is 48% of first colum). After that rising
edge hall 2 (67% of period time), falling hall2, rising hall3 and falling hall3.
Hall 3 seems to be the most off by about 3% (or 10 degrees). And one of them is glued in backwards
To get the numbers i give the motor a whirl and press a key on the laptop. The algorithm captures the content
of a timer on rising/falling edges of hall sensors. The rising edge of hall 1 is used as a reference. To
make sure the measurement is valid the algorithm runs a 2nd order prediction filter to make sure the
measured period time makes sence, else the measurement is discarded. The prediction filter is
2nd order so it can predict constant speed and constant decellaration without error (measurements
are discarded if the prediction is more than 3% wrong)....
For the controller there'll be no issue as I plan not to relate the hall sensors to the motor phases. Switching
of motor phases will be dictated by the prediction filter (which can also extrapolate to accurately switch
inbetween 2 hall sensor edges) , the halls are there for synchronisation. To make sure that
in my mind I don't relate the halls with the motor phase, I call those phase A, B and C (got this
idea from a comedian, in a sketch one team was team 1, the other team A
so non wouldfeel inferior)
salty9
1 kW
Lebowski,
I not sure but I think you may have discovered a "poor-boy" storage scope. You could take your data, read it into a spreadsheet file, and display it as a chart or graph to make it more meaningful to those of us who are unwashed mathematically. Thanks.
I not sure but I think you may have discovered a "poor-boy" storage scope. You could take your data, read it into a spreadsheet file, and display it as a chart or graph to make it more meaningful to those of us who are unwashed mathematically. Thanks.
Lebowski
10 MW
bit more progress to report
I reached the point where:
-the system now auto calibrates the hall sensors. During calibration it asks you to spin the motor. The 30f will
then measure all hall edges and determine their position relative to each other and the rotor. How you connect the
hall sensors or whether you have one or more inverted (
) doesn't matter.
- after calibration the info from the hall sensors is used to determine the rotor position. This will typically yield
one out of 6 positions (360 divided by 3 and divided by 2 edges (rising and falling as produced by hall). These
are, in the ideal world, 60 degrees apart. Here however the system knows the relative position of each hall,
the distance in degrees is typically far from 60 degrees and depends on how good the hall sensors are positioned.
- while the rotor is spinning the 30F tries to determine the rotation time (based on info from the hall sensors,
their distance to each other in degrees and info from an internal Timer). When the rotation time is known the
30F jumps to a mode where the rotor position is determined by the last hall signal edge, the time since
this edge and the rotation time.
this is shown in this plot. On the x-axis is time, 1000 points per second. On the y-axis is the rotor
position (0 to 1 corresponds to 0 to 359 degrees). The first 0.3 seconds the system doesn't have an accurate
prediction yet of the rotor speed, therefore it outputs the position based on the hall sensors. This is why it's
one out of 6 levels. After 0.3 however the system 'has lock', now interpolation is used to calculate the position
also inbetween the hall sensors, this is why the line is linear rising instead of being 1 out of 6 levels.
In the mean time the system will keep monitoring how good it knows the rotor position. If something unexpected
happens (like massive deceleration, only possible by locking a wheel or something catastrophic like that) or
the rotation just becomes too slow (were talking 10 rpm here) the system loses 'lock' and will switch
back to using the info from the hall sensors again (so it goes back to the 6 levels). An example when this
happens: when you've come to a stop at a traffic light....
I reached the point where:
-the system now auto calibrates the hall sensors. During calibration it asks you to spin the motor. The 30f will
then measure all hall edges and determine their position relative to each other and the rotor. How you connect the
hall sensors or whether you have one or more inverted (
) doesn't matter.- after calibration the info from the hall sensors is used to determine the rotor position. This will typically yield
one out of 6 positions (360 divided by 3 and divided by 2 edges (rising and falling as produced by hall). These
are, in the ideal world, 60 degrees apart. Here however the system knows the relative position of each hall,
the distance in degrees is typically far from 60 degrees and depends on how good the hall sensors are positioned.
- while the rotor is spinning the 30F tries to determine the rotation time (based on info from the hall sensors,
their distance to each other in degrees and info from an internal Timer). When the rotation time is known the
30F jumps to a mode where the rotor position is determined by the last hall signal edge, the time since
this edge and the rotation time.
this is shown in this plot. On the x-axis is time, 1000 points per second. On the y-axis is the rotor
position (0 to 1 corresponds to 0 to 359 degrees). The first 0.3 seconds the system doesn't have an accurate
prediction yet of the rotor speed, therefore it outputs the position based on the hall sensors. This is why it's
one out of 6 levels. After 0.3 however the system 'has lock', now interpolation is used to calculate the position
also inbetween the hall sensors, this is why the line is linear rising instead of being 1 out of 6 levels.
In the mean time the system will keep monitoring how good it knows the rotor position. If something unexpected
happens (like massive deceleration, only possible by locking a wheel or something catastrophic like that) or
the rotation just becomes too slow (were talking 10 rpm here) the system loses 'lock' and will switch
back to using the info from the hall sensors again (so it goes back to the 6 levels). An example when this
happens: when you've come to a stop at a traffic light....
bigmoose
1 MW
Ditto Lebowski! Congrats, great progress, and a great feature! Auto learn Hall position, couldn't ask for more!
oldswamm
100 W
Ditto from me too, Lebowski.
I've been working on add on circuitry for commercial controllers and slow (hub) motors, which will have auto sensored/sensorless switching, as well as auto hall sensor learning.
Other functions I intend to implement are serial to/from the controller units, handlebar unit, lighting controller, BMS, and any other functions (such as a brake interface).
The handlebar unit will include the basic CA functions, the ability to 'reprogram' the controller units, and inputs for more controls than almost anyone could want. I'm also working on interfacing to LED arrays such as in 'moving' signs (bright green, red, or orange 2-1/2" characters) as an alternative to the standard LCD interface.
A board in the hub for an interface for the halls as well as 3 thermistors, 2 in the windings, a fan control, and 6 tach inputs for fans. (edit: using the 3 hall wires as a 3bit parallel interface, and 12v on the red wire)
I want the ability to control 2WD and 3way (intelligently :wink: . )
Lighting control , including turn signals.
Thermal current limiting (temp sensors on the mosfets too).
I would also LIKE to implement skid/spin control (what I got interested in controller design for !), eventually including electronic brake control, integrating regen and electric brakes. Would include AFB (anti flip braking ), and a wheelie eliminator (selectable). I think I would need use hall sensors on the suspensions. Can't see a G sensor (tilt/tip) working (at least not easily).
edit: Forgot about timing, which will partially compensate for processing the halls through 2 processors, as well as poorly timed halls.
Bob
I've been working on add on circuitry for commercial controllers and slow (hub) motors, which will have auto sensored/sensorless switching, as well as auto hall sensor learning.
Other functions I intend to implement are serial to/from the controller units, handlebar unit, lighting controller, BMS, and any other functions (such as a brake interface).
The handlebar unit will include the basic CA functions, the ability to 'reprogram' the controller units, and inputs for more controls than almost anyone could want. I'm also working on interfacing to LED arrays such as in 'moving' signs (bright green, red, or orange 2-1/2" characters) as an alternative to the standard LCD interface.
A board in the hub for an interface for the halls as well as 3 thermistors, 2 in the windings, a fan control, and 6 tach inputs for fans. (edit: using the 3 hall wires as a 3bit parallel interface, and 12v on the red wire)
I want the ability to control 2WD and 3way (intelligently :wink: . )
Lighting control , including turn signals.
Thermal current limiting (temp sensors on the mosfets too).
I would also LIKE to implement skid/spin control (what I got interested in controller design for
!), eventually including electronic brake control, integrating regen and electric brakes. Would include AFB (anti flip braking ), and a wheelie eliminator (selectable). I think I would need use hall sensors on the suspensions. Can't see a G sensor (tilt/tip) working (at least not easily).edit: Forgot about timing, which will partially compensate for processing the halls through 2 processors, as well as poorly timed halls.
Bob