Motor Controller with Customizable Electronics, easy DIY and repair OpenSource

badgineer said:
Hi

Thanks for the explanation. This was unexpected! I thought I did a decent homework on this :D
I took the topology from here:
https://ocw.mit.edu/courses/media-arts-and-sciences/mas-836-sensor-technologies-for-interactive-environments-spring-2011/readings/MITMAS_836S11_read02_bias.pdf
(first schematic on page 4) and did not give it much thought.

MIT material used to be the bible of engineering design, can't find any clue of this very weird C2. it could be typo, and it could be good to check with the author about it. none of other opamp has this capacitor in the whole material.

to find a similar size 100/12 Vdc module is not very easy, I don't think it has marketing value from manufacturer point of view. I list the votol EM-50s chips for your design reference, hope it helps.
ref.JPG
battery(up to 96V claimed) to 12V - SD4936
http://www.silan.com.cn/en/product/details/151.html
12V to 6V - 78L06
6V to 3.3V - 1117

again I suggest consider using linear regulator for 12V to 5V, can lower the noise instead of adding capacitor on opamp output :wink:
 
another famous board Lishui, which a wonderful open source FOC firmware developed by stancecoke is based on, applies 78M05 for 12/5 VDC conversion.
https://www.pedelecforum.de/forum/index.php?threads/open-source-firmware-fuer-lishui-controller.61113/
 
Hi

flute2k3@hotmail.com said:
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)

For 12-5V there are plenty of options! mini360, mini560, and the MP1584N we currently plan to use (just because it has a fixed voltage version which is easier and less error prone to work with. )

Br,
 
At this time the Max Volts is 72 (at which the 12V DC-DC module dies) This is the main bottleneck - we could not find a good solution for a small 12V DC module that takes a bigger input. If anybody knows of any small 100 to 12 V DC-DC module, please tell! This is the main barrier i think to making it a 100V max (~20s) controller.
I am working on a controller that takes up to 100v input and I have had good results with the LM5017MR and MP9486 buck ICs. I used to use the former until it went out of stock. You have to lay out the supporting components yourself but the reference designs are fairly simple and perform very well.

The power and ground traces running to your FETs have way too much inductance. I encountered these issues on https://endless-sphere.com/forums/viewtopic.php?f=30&t=94443 my first attempt at a controller and the solution is to run the power and ground traces as close as possible with (1206 1uf 100v) ceramic capacitors close to the FETs for decoupling.
Something like this:FETs-6.png
Each FET is 3 black squares, Red is front copper, Black is back copper, and the gray rectangles are the CAPs. It wouldn't hurt to put CAPs on the back as well as the front.

I would also replace the IRF540 with something a bit beefier - 3077s or 4110s are not too expensive and will do several times more current than the IRF540s. Keep the legs as short as possible to reduce heating and inductance.

Although I have moved on to bigger projects and can't help with this full-time, I love the idea of a low-power controller that anyone can slap a STM32/Arduino/Teensy into and run stuff with.
 
thorlancaster328 said:
At this time the Max Volts is 72 (at which the 12V DC-DC module dies) This is the main bottleneck - we could not find a good solution for a small 12V DC module that takes a bigger input. If anybody knows of any small 100 to 12 V DC-DC module, please tell! This is the main barrier i think to making it a 100V max (~20s) controller.
I am working on a controller that takes up to 100v input and I have had good results with the LM5017MR and MP9486 buck ICs. I used to use the former until it went out of stock. You have to lay out the supporting components yourself but the reference designs are fairly simple and perform very well.
Search LM5017 here before deciding to use it (short version is it doesn't last near 100v.) Seems like you will end up stuck at the same voltage if you try to implement it.
 
thorlancaster328 said:
The power and ground traces running to your FETs have way too much inductance. I encountered these issues on https://endless-sphere.com/forums/viewtopic.php?f=30&t=94443 my first attempt at a controller and the solution is to run the power and ground traces as close as possible with (1206 1uf 100v) ceramic capacitors close to the FETs for decoupling.
Thanks for sharing all this details. @badgineer is the only one designing the next board (we are discussing ideas on a Telegram channel), and for what I can understand, it is almost finished, maybe the week we will have the board ready to buy on JLCPCB -- last images that were shared:

The board will be very compact, through hole components on top side; one DC-DC assembled on top of the other and the custom electronics board will be placed on top of the Bluepill, using the same pins of Bluepill:



Surface mount components on bottom layer, all of size at least 0805 to be easy to solder:







And the firmware is ready and tested, the only missing parts is really this new board :)

Firmware running on previous board prototype, driving M365 EScooter motor:

[youtube]NelnB91Vqgw[/youtube]

Firmware running on the M365 motor controller, driving EBike TSDZ2 mid drive motor:

[youtube]ueGZx3Urf0c[/youtube]
 
Hi Jrbe,

Jrbe said:
The power and ground traces running to your FETs have way too much inductance. [.....]

I would also replace the IRF540 with something a bit beefier - 3077s or 4110s are not too expensive and will do several times more current than the IRF540s. Keep the legs as short as possible to reduce heating and inductance.

Thanks for the input. Yes, the power and GND has undergone a complete redesign. That was the first thing to be changed.
We also redesigned most other aspects (new fets, new gate drives, new opamps, etc etc etc)
Will publish a lengthy list soon.

The Mosfet was not really suited for power, we are going for MDP10N027 which seems to be a good budget power mosfet. I will also provide a list of possible alternatives.

However 3077 and 4110 are on the list with examples what NOT to use. These are dinosaurs. They were top dog during their time, but nowadays belong in a museum.
OK, OK, i'm exaggerating, but hear me out: They have a major drawback: huge Crss, and thus tiny Ciss/Crss ratio.
Example: 3077 has Ciss/Crss ratio of about 25, 4110 has about 37, and the MDP10N027 has >200. This means that the MDP10n027 will hardly ring or have parasitic turn-on in the same circumstances where both phenomena could make the other 2 basically unusable.
Designing around this needs extra gs caps to increase the ratio (for example), which has significant side effects (slower switching).
Much of this I don't fully understand myself honestly. But big Crss is bad! :)

What do you think about the new design (pictures from casainho?) Please note that the ground plane is completely missing (4 layer board, left it for last step), and that the gnd "strip" on the bottom side (green) will be about double the width in the picture.

I do not completely understand your picture though...

casainho said:
Thanks for sharing all this details. @badgineer is the only one designing the next board (we are discussing ideas on a Telegram
@mxlemming is also contributing ***significantly*** to most design decisions, credit where credit's due. For example the whole Ciss/Crss ratio thing (actually Cgs/Cds, but they're almost identical in good modern mosfets) I know from him.

Br,
 
badgineer said:
Hi Jrbe,

Jrbe said:
The power and ground traces running to your FETs have way too much inductance. [.....]

I would also replace the IRF540 with something a bit beefier - 3077s or 4110s are not too expensive and will do several times more current than the IRF540s. Keep the legs as short as possible to reduce heating and inductance.
Thorlancaster328's quote, not mine.. Some messed up formatting / quoting there.

Some of the original:
casainho said:
thorlancaster328 said:
The power and ground traces running to your FETs have way too much inductance. I encountered these issues on https://endless-sphere.com/forums/viewtopic.php?f=30&t=94443 my first attempt at a controller and the solution is to run the power and ground traces as close as possible with (1206 1uf 100v) ceramic capacitors close to the FETs for decoupling.
Thanks for sharing all this details. @badgineer is the only one designing the next board (we are discussing ideas on a Telegram channel), and for what I can understand, it is almost finished, maybe the week we will have the board ready to buy on JLCPCB -- last images that were shared:

The board will be very compact, through hole components on top side; one DC-DC assembled on top of the other and the custom electronics board will be placed on top of the Bluepill, using the same pins of Bluepill:
 
Jrbe said:
Thorlancaster328's quote, not mine.. Some messed up formatting / quoting there.
I wish we didn't have to basically edit HTML to produce well-formatted posts, hopefully the new forum software handles this better. :?

badgineer said:
The Mosfet was not really suited for power, we are going for MDP10N027 which seems to be a good budget power mosfet. I will also provide a list of possible alternatives.

However 3077 and 4110 are on the list with examples what NOT to use. These are dinosaurs. They were top dog during their time, but nowadays belong in a museum.
OK, OK, i'm exaggerating, but hear me out: They have a major drawback: huge Crss, and thus tiny Ciss/Crss ratio.
Example: 3077 has Ciss/Crss ratio of about 25, 4110 has about 37, and the MDP10N027 has >200. This means that the MDP10n027 will hardly ring or have parasitic turn-on in the same circumstances where both phenomena could make the other 2 basically unusable.
Designing around this needs extra gs caps to increase the ratio (for example), which has significant side effects (slower switching).
Much of this I don't fully understand myself honestly. But big Crss is bad! :)

An earlier prototype of mine used 3077 FETs and it suffered from the ringing you are describing. External cGS helped a bit but it still liked to oscillate due to package inductance and the resulting LC circuit. I could never get current sharing working well on my 18-FET TO-220 prototype, this is probably one of the reasons why. I agree with your choice of going to lower Miller FETs, it should make the switching a lot cleaner.

What do you think about the new design (pictures from casainho?) Please note that the ground plane is completely missing (4 layer board, left it for last step), and that the gnd "strip" on the bottom side (green) will be about double the width in the picture. .
It looks pretty good to me.
The design is similar to my first successful TO-247 controller that I designed, with the new low Miller FETs you are using it should work great, just make sure to add a few uF of ceramic across the supply rails next to each FET. If you create identical VBATT and GND zones on the inner two layers it will further reduce inductance. Order should be front=VBATT, in1=PGND, in2=VBATT, in3=PGND. Make sure to connect the inner layers to the ceramic caps as well.

I do not completely understand your picture though...
It appears that you understood it enough to implement it, the power and ground planes are routed the same way as the picture.
 
Jrbe said:
Search LM5017 here before deciding to use it (short version is it doesn't last near 100v.) Seems like you will end up stuck at the same voltage if you try to implement it.

From my experience, the LM5017 has had no problems running at up to 20s. It is, however, quite sensitive to voltage spikes and bad layout. The one time I blew a 5017, the layout was sub-optimal and the VIN was connected directly to the positive supply rail. This seems to be the case with other users blowing 5017s as well.

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. Note that the ferrite bead is optional (it filters RF and helped with my ADC readings) and the zener is purely for protection if the 5017 fails short.
12vSMPS-v1.png
100v-SMPS-layout-v1.png
Since the LM5017 is out of stock, I switched to the MP9486 and did basically the same thing. I haven't done much testing with the latter IC but I haven't blown one of those yet either.
 
Jrbe said:
Thorlancaster328's quote, not mine.. Some messed up formatting / quoting there.

Hi. Apologies to both of you for the mixup. My bad. Have not ideea how I managed :)

thorlancaster328 said:
just make sure to add a few uF of ceramic across the supply rails next to each FET. If you create identical VBATT and GND zones on the inner two layers it will further reduce inductance. Order should be front=VBATT, in1=PGND, in2=VBATT, in3=PGND. Make sure to connect the inner layers to the ceramic caps as well.

We have a pair of 2.2 uF ceramics near each fet pair.
The zones of GND and VBATT are not identical though. The external area on both sides is VBAT, and GND extends in the thinner inner layers all the way completely overlapping VBAT.
But GND has another hefty strip (the horisontal green strip in the middle of the board) - which will also be about 2x bigger than in the picture on the finished design (in the picture just the part that will be exposed copper is there). I tried to optimize the inherent DC capacity of the board like this.

thorlancaster328 said:
My current 5017 based power supply includes a resistor inline with the VIN and separate 1uf (ceramic) and 47u (electrolytic) decoupling capacitors.

Hmmm. Hmmm. Very interesting.
On one hand I dislike the fact that that resistor will dissipate a fair amount of power (doesn't it overheat?). So lower efficiency for the 12v submodule.
On the other hand, that R, together with the C, creates a hefty Low Pass Filter, which probably filters out any voltage spikes -> hence the LM5017 is protected.

And at the end of the day, a mediocre efficiency 12v DC DC that works is better than a high efficiency 12v DC DC that is burned....

I'll remember this ideea! Thanks!

Edit: I calculated - the LPF in your schematic has 480 HZ cutoff frequency. This depends on the nature of the spikes, and I have no ideea, (assumption alert!) but my gut feeling tells me we can probably protect the Buck converter also with much higher cutoff freq (so lower series resistor, so lower losses)

Br,
 
badgineer said:
On one hand I dislike the fact that that resistor will dissipate a fair amount of power (doesn't it overheat?). So lower efficiency for the 12v submodule.
On the other hand, that R, together with the C, creates a hefty Low Pass Filter, which probably filters out any voltage spikes -> hence the LM5017 is protected.

And at the end of the day, a mediocre efficiency 12v DC DC that works is better than a high efficiency 12v DC DC that is burned....

Assuming you are drawing 300ma from the 12v rail with an 85% PSU (excl. resistor) efficiency, you will be drawing 59 mA from the (72v) supply rail. The 6.8 ohm resistor will have 400mv across it and will be dissipating 25 milliwatts. Even if the rail voltage is 33v, the resistor only dissipates 112 milliwatts. The resistor also helps protect the ignition switch (if present) from arc damage.
 
thorlancaster328 said:
Jrbe said:
Search LM5017 here before deciding to use it (short version is it doesn't last near 100v.) Seems like you will end up stuck at the same voltage if you try to implement it.

From my experience, the LM5017 has had no problems running at up to 20s. It is, however, quite sensitive to voltage spikes and bad layout. The one time I blew a 5017, the layout was sub-optimal and the VIN was connected directly to the positive supply rail. This seems to be the case with other users blowing 5017s as well.

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. Note that the ferrite bead is optional (it filters RF and helped with my ADC readings) and the zener is purely for protection if the 5017 fails short.
12vSMPS-v1.png
100v-SMPS-layout-v1.png
Since the LM5017 is out of stock, I switched to the MP9486 and did basically the same thing. I haven't done much testing with the latter IC but I haven't blown one of those yet either.

Hi Thor. Good to see you back here!

I'm intrigued by your lm5017 protection, I did similar but with only 2r2 and 4.7uF and they still die prematurely. I also add an 84Vtvs. They still die.

My theory is it's not actually over voltage but huge ripple/rapid change on the input messing with the control loop causing them to commit suicide.

I've ordered a pile of mps parts and diodes... Shall see how they work out.

Isn't your D3 backwards in the schematic above?
 
@mxlemming I'm glad to be back on the 'Sphere as well. Had some other projects that I got interested in for a while.

D3 is a zener diode. The SMPS IC needs a voltage rail (to switch its internal FET) that must be between 8 and 12 volts. Normally the SMPS IC uses an integrated linear regulator for this but it is inefficient.

The Zener diode is used so that the IC doesn't fail if the output voltage is set above 12v. Also you are correct about the external diode, if you don't add one the SMPS may fail to start. Definitely add a diode in the other direction.

The MP9486 needs no such diode circuit.
 
Hi everybody.

After what feels like an eternity, I think the next version is ready to see the light of day. I call it v0.5
Highlights:
* Complete redesign
* Much smaller (72x48mm)
* Better components
* Better layout
* Has an actual name: "EasyDIY ESC"
* Low cost parts

Here 3D renders:
3D_TH_Side.png
3D_SMD_Side.png

Schematic, pcb, gerber files, bom, pick&place, extensive readme file, - all on github: https://github.com/EBiCS/EasyDIY-ESC

PS: just in case it's not merged yet, check the branch.

Br,
 
great work badgineer :bigthumb:

I see a significant reduction on size, many changes/improvement on various details, the next step is to verify your great work by suitable firmware.

what I can see from the pin mapping is, you can not simply spin the motor without modifying the v2 or v3 firmware since they are all based on m365 hardware, would like to see a tuition on how to modify and compile the v2 or v3 to make it work.
 
flute2k3@hotmail.com said:
great work badgineer :bigthumb:

I see a significant reduction on size, many changes/improvement on various details, the next step is to verify your great work by suitable firmware.

what I can see from the pin mapping is, you can not simply spin the motor without modifying the v2 or v3 firmware since they are all based on m365 hardware, would like to see a tuition on how to modify and compile the v2 or v3 to make it work.
Yes, great work from badgineer!! I am really happy with the new size of the board, I was not expecting to be possible like that while I value, and I think other will also value, a board small size.

About the pin mapping and having firmware for this board. At his base, this board is a motor controller only, where you can expand the board on top of the Bluepill, to implement a custom application like an EBike motor controller or EScotter motor controller.

The V3 that you mention, is composed of 2 parts:
1. motor controller firmware
2. M365 EScooter firmware

The 1. motor controller firmware is a gitsubmodule, it is like a library of firmware that is located on another repository, this one: https://github.com/EBiCS/EBiCS_motor_FOC

And this firmware is already easy to customize the pins for the motor controller, see:



And the 2. M365 EScooter firmware already uses the 1. motor controller firmware, here is running on the EasyDIY ESC previous version, driving the M365 motor: https://youtube.com/shorts/NelnB91Vqgw

I bought the boards of this new small version of the boards, I will be fully assembling by hand and I will make the firmware working!!
 
And this firmware is already easy to customize the pins for the motor controller,/

All the more reason to switch to the black pill. According to hacakaday, it's now hard to get a blue pill with a genuine ST chip and if any of the FOC code is based on ST libraries, they are not licensed to use on counterfeit chips.

See the article here https://hackaday.com/2021/01/20/blue-pill-vs-black-pill-transitioning-from-stm32f103-to-stm32f411/
 
Woly said:
And this firmware is already easy to customize the pins for the motor controller,/

All the more reason to switch to the black pill. According to hacakaday, it's now hard to get a blue pill with a genuine ST chip and if any of the FOC code is based on ST libraries, they are not licensed to use on counterfeit chips.

See the article here https://hackaday.com/2021/01/20/blue-pill-vs-black-pill-transitioning-from-stm32f103-to-stm32f411/
I already bought some no genuine STM32F103, and it is assumed by the seller they are not but they should be compatible. I see this as a strong point, of being so popular that are other options that are compatible.

My idea is to use code that is not dependent of a manufacturer, as there is OpenSource FOC firmware that are not. For instance, I just bought a Bafang M500 EBike mid drive motor where the controller uses a NXP ARM Cortex M4, and I hope to reuse the firmware on it, so strategically the firmware should be OpenSource and not tied to some manufacturer library or tools.
 
casainho said:
And this firmware is already easy to customize the pins for the motor controller, see:



And the 2. M365 EScooter firmware already uses the 1. motor controller firmware, here is running on the EasyDIY ESC previous version, driving the M365 motor: https://youtube.com/shorts/NelnB91Vqgw

I bought the boards of this new small version of the boards, I will be fully assembling by hand and I will make the firmware working!!

I talked to stancecoke in another thread and I got to know simply modify the Lishui FOC firmware (which v3 is based on) by reassign pins will not work refer to the discussion here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=106862&p=1666236#p1666236

anyway good to know maybe some of my understanding is not correct according to you description, will have a try.

I'm not good at stm32 coding, is looks to me your work is under VScode? because I can find the typical cubeMX, keil/cubeIDE files in the folder you shared such as ".cproject/.project/.ico". if that is the case, could you elaborate a few key steps?

Thanks again for all of your great work to make it happan :thumb:
 
badgineer said:
Hi everybody.

After what feels like an eternity, I think the next version is ready to see the light of day. I call it v0.5
Highlights:
* Complete redesign
* Much smaller (72x48mm)
* Better components
* Better layout
* Has an actual name: "EasyDIY ESC"
* Low cost parts

Here 3D renders:

View attachment 1

Schematic, pcb, gerber files, bom, pick&place, extensive readme file, - all on github: https://github.com/EBiCS/EasyDIY-ESC

PS: just in case it's not merged yet, check the branch.

Br,
hello guys I want to support the project

Enviado desde mi M2101K7BL mediante Tapatalk

 
flute2k3@hotmail.com said:
casainho said:
And this firmware is already easy to customize the pins for the motor controller, see:



And the 2. M365 EScooter firmware already uses the 1. motor controller firmware, here is running on the EasyDIY ESC previous version, driving the M365 motor: https://youtube.com/shorts/NelnB91Vqgw

I bought the boards of this new small version of the boards, I will be fully assembling by hand and I will make the firmware working!!

I talked to stancecoke in another thread and I got to know simply modify the Lishui FOC firmware (which v3 is based on) by reassign pins will not work refer to the discussion here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=106862&p=1666236#p1666236

anyway good to know maybe some of my understanding is not correct according to you description, will have a try.

I'm not good at stm32 coding, is looks to me your work is under VScode? because I can find the typical cubeMX, keil/cubeIDE files in the folder you shared such as ".cproject/.project/.ico". if that is the case, could you elaborate a few key steps?

Thanks again for all of your great work to make it happan :thumb:
See here how I configure Code Studio to flash a nd debug the firmware using GNU Debugger: https://github.com/OpenSourceEBike/TSDZ2_wireless/blob/master/EBike_wireless_remote/documentation/development-flash_and_debug_firmware.md

I always do the same way on all the projects.
 
flute2k3@hotmail.com said:
by reassign pins will not work refer to the discussion here
Casainho tried to make the pin assignment user settable. But with the submodule, I wasn't able to make the motor run on the Lishui hardware. Something's wrong with the phase current reading in injected ADC mode obviously.
I ported Casainhos submodule example from VSCode back to the CubeIDE:
https://github.com/stancecoke/LishuiOnCubeIDE

I have no idea, why the code with the submodule doesn't work on the Lishui hardware. I ported the improvements from the M365 V3 back to EBiCS manually, that works properly.
https://github.com/EBiCS/EBiCS_Firmware/tree/m365_improvements

Of course it would be much smarter to have a submodule that can be used in several projects, then you could improve the motor core in the submodule and there would be no need to port the improvements to the other projects...


regards
stancecoke
 
@stancecoke good to have you here to discuss this pin issue which puzzled me a lot :D

hope we have a workable and unified v3 version, easy to copy/paste on some existing and similar product with only pin assignment different.
 
stancecoke said:
flute2k3@hotmail.com said:
by reassign pins will not work refer to the discussion here
Casainho tried to make the pin assignment user settable. But with the submodule, I wasn't able to make the motor run on the Lishui hardware. Something's wrong with the phase current reading in injected ADC mode obviously.
I ported Casainhos submodule example from VSCode back to the CubeIDE:
https://github.com/stancecoke/LishuiOnCubeIDE

I have no idea, why the code with the submodule doesn't work on the Lishui hardware. I ported the improvements from the M365 V3 back to EBiCS manually, that works properly.
https://github.com/EBiCS/EBiCS_Firmware/tree/m365_improvements

Of course it would be much smarter to have a submodule that can be used in several projects, then you could improve the motor core in the submodule and there would be no need to port the improvements to the other projects...


regards
stancecoke

do you think it could be the driver polarity difference of Lishui hardware(IRS2003) vs M365 (MT8006A)? check here:
https://endless-sphere.com/forums/viewtopic.php?f=30&t=114537&start=25
 
Back
Top