Motor Controller with Customizable Electronics, easy DIY and repair OpenSource

[stancecoke]

the accurate position shall be the center of between the "entering" and "leaving" of the hall sensor.

?! my philosophy is different. I always look at the transition from one hallstate to the next. With this I always have the exact rotorposition and the spinning direction. In this example: if you enter sector 6 clockwise, you are at 60 deg, if you enter sector 6 anticlockwise, you are at 120 deg. So I always take the old and the new hallstate to get the exact rotor position.

ui8_hall_case=ui8_hall_state_old*10+ui8_hall_state;
...
//6 cases for forward direction
		case 64:
			q31_rotorposition_hall = Hall_64;
...
//6 cases for reverse direction
		case 46:
			q31_rotorposition_hall = Hall_64;

regards
stancecoke

 

[mxlemming]

Just built one of these (casainho sent me r1 board)

Seems to switch nicely at very preliminary glance and is pretty small. Fsesc75100 for scale.


I need to go to sleep so hopefully tomorrow we get some spinny spinny.

 

[flute2k3@hotmail.com]

Just built one of these (casainho sent me r1 board)

Seems to switch nicely at very preliminary glance and is pretty small. Fsesc75100 for scale.

the board looks really nice and neat!
maybe you can try my comparison and verify the current consumption @ same rpm.

 

[mxlemming]

Just built one of these (casainho sent me r1 board)

Seems to switch nicely at very preliminary glance and is pretty small. Fsesc75100 for scale.

the board looks really nice and neat!
maybe you can try my comparison and verify the current consumption @ same rpm.

Thanks. I was pretty pleased with how well it went together. I haven't soldered 0805 for ages, it's so easy I could do it with a lighter.

Main problem is there is not quite enough room for caps but i think badgineer is fixing this for the next version.

You mean with the hall sensor angle tests? I'm not even going to solder the hall input resistors on. I'm running it sensorless.

I don't really need to repeat your measurements regarding the hall sensors, it's kinda obvious that if they're offset by many degrees it's going to be less efficient. You just need to get them right by whatever means.

 

[mxlemming]

Built, running MESC FOC firmware on F401CC black pill board.

[youtube]qFH7duzY3uM[/youtube]
https://youtu.be/qFH7duzY3uM

The current sense waveforms are really nice TBH, very clean for a low side shunt. Nicer than my MESC board for sure.


The switching in this is only at about 20A, but it seems to not vary much with current; the overshoot is identical at 0 and 20A. Will get some double pulse tests later.

This is basically fine. No cause for concern really. Might want some snubbing.





Parts list:
Magnachip MDP10N027 MOSFETs from Aliexpress
On Semi NCP5106 gate drivers I had left over
On Semi NCS20034 opamp from RS I had left over
1mohm shunts from Aliexpress
only 2x150uF capacitors (way too low, needs about 2x as much minimum)
3x 4.7uF 100V ceramics from Aliexpress.
Left over 12-5V DCDC I bought years ago and found in a drawer
Blackpill F401CC from Aliexpress
No heatsink atall so far. Need to get out the drill and blocks of aluminium. Got a case on it's way...

Firmware running is true FOC at 20kHz PWM. 2500rads-1 current bandwidth, 22V input (the motor really does not want much more than this with this PSU)

Nice little performer, and really really easy to build.

Only needs some bigger caps and perhaps phase voltage sensing and it would be perfect. Quite pleased with it.

Draws 0.4W standstill.

 

[flute2k3@hotmail.com]

the accurate position shall be the center of between the "entering" and "leaving" of the hall sensor.

?! my philosophy is different. I always look at the transition from one hallstate to the next. With this I always have the exact rotorposition and the spinning direction. In this example: if you enter sector 6 clockwise, you are at 60 deg, if you enter sector 6 anticlockwise, you are at 120 deg. So I always take the old and the new hallstate to get the exact rotor position.

Hall Sectors.png

ui8_hall_case=ui8_hall_state_old*10+ui8_hall_state;
...
//6 cases for forward direction
		case 64:
			q31_rotorposition_hall = Hall_64;
...
//6 cases for reverse direction
		case 46:
			q31_rotorposition_hall = Hall_64;

regards
stancecoke

@stancecoke, what I mean is the 𝜃 used in park/clarke transformation. the measured d axis timing tc is in the center point of of t1 and t2 slot. but later on I realized you use PLL to lock the angle after start up so there shall be no issue.

 

[flute2k3@hotmail.com]

Stator resistance and inductance should be used to tune the PI loop for the current controller

I always tune the PI parameters by trial and error, not by the mathematical/physical theory

it will be much less accurate since it relies on single point detection

Yes that's right, the autodetct routine could be improved a lot, but the accuracy is sufficient at the moment, so I'm not motivated to that :wink:

That gives you the centre angle of each hall sensor.

So you have to add/substract 30 deg in the hallsensor interrupt to get the real rotor position, depending on the rotor rotation direction ?!

regards
stancecoke

The mathematical way is easier once you've had to do it more than once.

Indeed, if you have a pll, you can get away with mediocre accuracy.

You don't add/subtract 30 degrees to get the end points, you add/subtract half the width of that hall sensors angle (half the "count" I described above). It will be close to 30 degrees but my experiments have found motors where the hall sensor states occupy at much as 90 degrees and as little as 45...

for MCSDK in hall_speed_pos_fdbk.c, it simply add 30 degree without advanced calculation

 

[stancecoke]

I realized you use PLL to lock the angle after start

The PLL has nothing to with the angle logic.
It only makes a smoother run, as it avoids hard jumps in the estimated rotor position.
It's just a matter of definition. At the moment, where the transition from one hall sector to the next happens, the physically rotor position is in the edge of the sector, not in the middle. So you can add 30 deg to get the middle, like the MCWB does, or you can take it directly as definition for the edge, like I do. Both leads to the same result. My solution is easier for the direction detection an does a plausibility check, as I can filter transitions that are physically not senseful...

regards
stancecoke

 

[mspider65]

The PLL has nothing to with the angle logic.
It only makes a smoother run, as it avoids hard jumps in the estimated rotor position.
It's just a matter of definition. At the moment, where the transition from one hall sector to the next happens, the physically rotor position is in the edge of the sector, not in the middle. So you can add 30 deg to get the middle, like the MCWB does, or you can take it directly as definition for the edge, like I do. Both leads to the same result. My solution is easier for the direction detection an does a plausibility check, as I can filter transitions that are physically not senseful...

regards
stancecoke

If you want to get a precise estimate of the rotor position based on the Hall sensors, it is not enough to think in spatial terms (angle) but time must also be considered.
Otherwise, as the rotor speed increases, the estimation error can become significant.
For example in my tests on the TSDZ2, the delay with which the Hall 1->0 transition is detected is about 80us and 160us for the 0->1 transition (about 30 deg at 500 erps!).

 

[stancecoke]

the delay with which the Hall 1->0 transition is detected is about 80us

Hm, you may be right. But I don't know any project beside yours, that takes this effect into account.

Would be interesting, if it is possible to validate this difference by running sensorless and log the angle from the observer and from the hall extrapolation/PLL.
I did this several years ago, but I don't remember at wich speed this log was.... Should be about 180 erps, (about 90 sample points per revolution @ 16kHz sampling rate)

regards
stancecoke

 

[mspider65]

Would be interesting, if it is possible to validate this difference by running sensorless and log the angle from the observer and from the hall extrapolation/PLL.

Yes, it would be possible to calculate the delay value running the motor at different speeds and record the difference between the two detected angles. The difference should increase with the motor speed.
Of course you should use the HW interrupt to detect the Hall transition. Otherwise, a random error would occur that can reach up to the PWM period which could be comparable to the delay value to be calculated.

I don't have experiences with other motors but in the case of TSDZ2 another important effect is the big difference between Hall Trise and Tfall delay.
I became aware of this effect while trying to calculate the exact angular position of the Hall sensors. I was measuring the number of clock ticks of each hall state by running the motor at a fixed speed.
What happened is that by carrying out the measurement with different speeds, the relative amplitude of the different states varied with the speed of the motor. In particular, by increasing the speed, the relative amplitude of the states starting with a falling edge increased while for those starting with a rising edge it decreased by the same percentage.

 

[flute2k3@hotmail.com]

If you want to get a precise estimate of the rotor position based on the Hall sensors, it is not enough to think in spatial terms (angle) but time must also be considered.
Otherwise, as the rotor speed increases, the estimation error can become significant.
For example in my tests on the TSDZ2, the delay with which the Hall 1->0 transition is detected is about 80us and 160us for the 0->1 transition (about 30 deg at 500 erps!).

your observation is absolutely correct, I noticed the same. the computing burden increases with speed, it becomes even worse for bluepill without FPU. fine tune by taking delay into consideration is good, but not good for future migration. I believe the best way is to optimize the high frequency loop algorithm, convert float to integral calculation (S16), etc, to achieve the max performance of the given type mcu.

when shifting the rotor electrical angle, it is interesting to see a slight difference on efficiency, 90 degree is the real degree I measured, while the 138 is ST MCWB default value. the real angle shows good tracking at low speed, but getting worse at high speed, which could imply the calculation burden increase with the speed, make the tracking delay/worse.

 

[mspider65]

I noticed the same. the computing burden increases with speed, it becomes even worse for bluepill without FPU. fine tune by taking delay into consideration is good, but not good for future migration. I believe the best way is to optimize the high frequency loop algorithm, convert float to integral calculation (S16), etc, to achieve the max performance of the given type mcu.

Yes, for medium/high speeds, the difference between the time T1 in which the quantity you use for the calculations is sampled (phase current or Hall sensor) and the time T2 in which you apply the result of the calculations is also important, because during this time interval the rotor is moving and the angle it travels increases with speed.

A good way to overcome this problem is to split the PWM algorithm into two steps and activate the PWM interrupt twice each PWM cycle (PWM center-aligned). In the first interrupt the calculations are performed and the result is applied at the beginning of the second interrupt. In this way the interval (T2-T1) is fixed and the angle drift can be corrected precisely

 

[spelling14]

Nice project! I am willing to try it for my DIY esk8 controller.
But what kind of IDE and firmware are you using? Sorry im not familiar with software.
Seems like theres several different firmware in this thread. I read them but still no idea where to start with.

 

[spelling14]

BTW Heres a cheap options for 100v step down module: search "xl7015 module" in aliexpress.
The maximal input voltage marked by seller is 80v but its 100v accoring the datasheet.

 

[casainho]

Nice project! I am willing to try it for my DIY esk8 controller.
But what kind of IDE and firmware are you using? Sorry im not familiar with software.
Seems like theres several different firmware in this thread. I read them but still no idea where to start with.

See here info for developers: https://opensourceebike.github.io/development/

Do you have a link to your DIY esk8 controller that I can see about it, just for curiosity?

 

[spelling14]

Nice project! I am willing to try it for my DIY esk8 controller.
But what kind of IDE and firmware are you using? Sorry im not familiar with software.
Seems like theres several different firmware in this thread. I read them but still no idea where to start with.

See here info for developers: https://opensourceebike.github.io/development/

Do you have a link to your DIY esk8 controller that I can see about it, just for curiosity?

Thanks for reply.
Thats the toolchain and enviroment setting right? And how about the firmware?
Is it this one? https://github.com/EBiCS/EBiCS_motor_FOC

Regarding my own controller, I designed a VESC6 compatible board but havent test yet. With another hat I can use f103 as mcu.
After some test I might made a more powerful one for the esk8.

 

[qwerkus]

I ve been following this from the start. Also very interested into a version with larger caps (think heavy dd hubs) and I would definitely join any group order in Europe.
Interesting how the move to stm32 spawned controller projects. From very few options, we now have plenty and also very good firmwares to runs them. Thanks to all involved!

 

[casainho]

Nice project! I am willing to try it for my DIY esk8 controller.
But what kind of IDE and firmware are you using? Sorry im not familiar with software.
Seems like theres several different firmware in this thread. I read them but still no idea where to start with.

See here info for developers: https://opensourceebike.github.io/development/

Do you have a link to your DIY esk8 controller that I can see about it, just for curiosity?

Thanks for reply.
Thats the toolchain and enviroment setting right? And how about the firmware?
Is it this one? https://github.com/EBiCS/EBiCS_motor_FOC

Unfortunately I am short of time and I was not working anymore on this project on last months.

 

[larsb]

Hi

I list the votol EM-50s chips for your design reference, hope it helps.

Thanks! 100+ V capable 12V output DC-DC converters are few and hard to find in stock these days, so nice to know about an additional option!
For this design we are targeting DIY friendliness so we are searching for a module - and I could only find one, that's sold on ebay and out of stock on aliexpress... So not a wise choice. (https://www.aliexpress.com/item/33024129019.html)

How large can the options be? I could find >100V to 12V dc-dc on tme.eu

https://www.tme.eu/se/en/katalog/dc-dc-converters_100320/?s_field=1000014&page=1&products_with_stock=1&mapped_params=364%3A1450066%3B624%3A1880816%2C1822202%2C1876019%2C1737377%2C1786300%2C1883321%2C1584730%2C1584853%2C1737359%2C1883315%2C1709624%2C1883322%2C1835180%2C1523659%2C1813738%3B

 

[badgineer]

BTW Heres a cheap options for 100v step down module: search "xl7015 module" in aliexpress.
The maximal input voltage marked by seller is 80v but its 100v accoring the datasheet.

Hi Spelling14. your suggestions seemed nice.. Until i read the reviews of the first hit, and everybody was complaining that it does not work with more than 55V .
So did you test such a module with ~84V ? if yes and it worked, please post a link? Thanks!


Ow, and general update. The project is mostly on ice now, since casainho does not have time for the software part, I also stopped working on the hardware. Let's see what the future brings

Br,

 

[badgineer]

Hi Thorlancaster328

My current 5017 based power supply includes a resistor inline with the VIN and separate 1uf (ceramic) and 47u (electrolytic) decoupling capacitors. Since implementing this circuit I am yet to blow a 5017.

Just wanted to go on record saying that despite my initial skepticism, I have come to like this idea, and started using it . Still looks to me like a bit of a "hack", but if it looks stupid but works, it's not stupid
So thanks!

Br,

 

[yepi.graffer]

Here are the images of fully assembled last version (v0.5_2022-03-19). Well, is missing / yet to be assembled, the battery wires as also the BIG capacitor on the battery wires.

The board needs to be a slightly larger to have more room for the hall sensor connectors / red capacitors and that 3 big capacitors.

The board was not yet tested, I will test it probably on next days:

Hello, what files do I use and what display do you use?

Enviado desde mi M2101K7BL mediante Tapatalk

 

[afzal]

KiCad (6) adaptation of this project - https://github.com/intible/ede

Custom KiCad libraries are maintained in a separate repo - https://github.com/intible/kicad-lib

Directory structure & naming:
ede (clone main project)
`|- lib (clone Custom KiCad library with this directory name & checkout to master branch)
`````|- fp
`````|- sym

Another way is to clone the above mentioned main project & then run git submodule update --init (it will clone custom KiCad libraries at the appropriate location with appropriate commit)

And if downloading as zip, copy unzipped library contents to "lib" folder inside main project, in case of doubt refer directory structure mentioned above. Or else edit fp-lib-table & sym-lib-table to point to the theunzipped library path.

R19 & R20 swapped in the layout as compared to EasyEDA project so that schematic & layout are in sync.

Note: Licensed used is CC BY-SA 4.0. AFAIU, GPL's are suitable for pure software work. Existing EasyEDA project license is GNU Affero General Public License v3, which is meant specifically for networking software. CC BY-SA 4.0 is compatible with GPLv3. Intention behind using this license is to use the most appropriate one, if the consensus is that this is not the right license, I will change. As an aside KiCad libraries use CC BY-SA 4.0, so does VESC project.

Thanks to everyone involved, especially casainho, badgineer, mxlemming, Andrii.

 

[casainho]

KiCad (6) adaptation of this project - https://github.com/intible/ede

Custom KiCad libraries are maintained in a separate repo - https://github.com/intible/kicad-lib

That is great!!

Would you mind to put your files on https://github.com/OpenSourceEBike organization? and I would consider this version the latest version of hardware and the previous one was a step to get to this point.

And do you plan to assembly and test the board?

Then you could also put some notes / document on https://opensourceebike.github.io/, writing a specific page(s) for this hardware.

I am sorry but I can not help on the firmware side. I am being to busy on my life.