Modular, Multi-Platform, 300A ESC
- Thread starter badgineer
- Start date
badgineer
10 W
Hi,
the gs* are gate signal test points. here example for the 2 gsA test points. The other 3 are probably all gnd. I must admit i did not invest much effort into making the labels nice and readable
br,
Dayanul Alam
10 mW
Just a few questions: is there any downsides to adding bus bar holes at the ends of the board? Also is there any use of the holes on each mosfet? Is it safe to remove them?Hi,
the gs* are gate signal test points. here example for the 2 gsA test points. The other 3 are probably all gnd. I must admit i did not invest much effort into making the labels nice and readable
View attachment 334086
br,
Dayanul Alam
10 mW
Honestly using all that solder might be a bit messy if some people dont have a fancy pcb oven. What if I added multiple holes on the battery terminals and interconnected them with the bus bars? I mean yes not much contact compared to soldering a large copper rectangle onto the board. I'm basically doing this in a way similar to the phase connections. There are 3 holes in each phase terminal and I'm thinking of adding 3 screws and interconnecting each of them with multiple copper plates that are within that size. This is what I am trying to approach with the battery terminals.
owhite
100 W
- Joined
- Aug 3, 2020
- Messages
- 285
Regarding this and your previous post about busbar holes -- I dont claim to know the best way to do it all and, without seeing a picture it is a bit hard to comment. Go ahead and try some things and report back. The main issue is that soldering and fabrication are more impactful with these boards, at least in comparison to other projects.
Dayanul Alam
10 mW
I mean like this. We are basically viewing the pcb horizontally. That long line is the vbat terminal.
From post #7,
Jrbe said:
BD - "So i left this for last because it's the juicyest bit
First - SMD Pads, because the TH bump on the other side would force us to mout the FETs far from board - which is not what I hope."
(Sorry for bad formatting..)
Mosfets will be in the way of thru holes for battery unless you juggle things.
If you do add a through hole for wires consider the via stitched version to help keep it attached to the board,
Thecoco974
10 W
- Joined
- Dec 7, 2016
- Messages
- 94
Hi everyone, just passing by to do a little report on the MP2 I build and adding to the recent discussion on bus bar issue.
I just did a weekend of race with it : 5H endurance race and 3 x 20min speed race. In total something like 250km of hard riding.
The motor was my weak link and could not push the MP2 that hard but still managed to draw an average of 2kw with pics at 6kw (using a 14s li-ion battery ). At that power the fets stayed at 54° max.
Here a logging of one speed race :
The only issue I had was ABS max current error mostly on wheel lifting/taking speed/ taking grip sudently events, and a few time a BRK event. THE BRK is the most annoying one since it doesn't recover without a power reset. Maybe there is a way to make it recoverable as the ABS error with a fault stop timer ?
To add to the current discussion, soldered bus bars has caused no issue on my build so far (mine is the last picture on the busbar guide on github). I had not much trouble soldering them without a thermal oven, for soldering them I shielded the bottom part component with aluminum and using solder paste I heated the whole PCB (minus the bottom part) uniformally to around 200°C with a heat gun then focussing on the bus bar them self.
It also seems to be strong enough since after a hard fall (around the 600's second on previous plot) I had the whole controler dangling over his phases and bus wires, zip ties are not always the best solution !
I just did a weekend of race with it : 5H endurance race and 3 x 20min speed race. In total something like 250km of hard riding.
The motor was my weak link and could not push the MP2 that hard but still managed to draw an average of 2kw with pics at 6kw (using a 14s li-ion battery ). At that power the fets stayed at 54° max.
Here a logging of one speed race :
The only issue I had was ABS max current error mostly on wheel lifting/taking speed/ taking grip sudently events, and a few time a BRK event. THE BRK is the most annoying one since it doesn't recover without a power reset. Maybe there is a way to make it recoverable as the ABS error with a fault stop timer ?
To add to the current discussion, soldered bus bars has caused no issue on my build so far (mine is the last picture on the busbar guide on github). I had not much trouble soldering them without a thermal oven, for soldering them I shielded the bottom part component with aluminum and using solder paste I heated the whole PCB (minus the bottom part) uniformally to around 200°C with a heat gun then focussing on the bus bar them self.
It also seems to be strong enough since after a hard fall (around the 600's second on previous plot) I had the whole controler dangling over his phases and bus wires, zip ties are not always the best solution !
mxlemming
100 kW
- Joined
- Jul 17, 2020
- Messages
- 1,122
Great logs coco. 55 degrees c with a decent amount of use and quite a long race!Hi everyone, just passing by to do a little report on the MP2 I build and adding to the recent discussion on bus bar issue.
I just did a weekend of race with it : 5H endurance race and 3 x 20min speed race. In total something like 250km of hard riding.
The motor was my weak link and could not push the MP2 that hard but still managed to draw an average of 2kw with pics at 6kw (using a 14s li-ion battery ). At that power the fets stayed at 54° max.
Here a logging of one speed race :
View attachment 334360
View attachment 334361
The only issue I had was ABS max current error mostly on wheel lifting/taking speed/ taking grip sudently events, and a few time a BRK event. THE BRK is the most annoying one since it doesn't recover without a power reset. Maybe there is a way to make it recoverable as the ABS error with a fault stop timer ?
To add to the current discussion, soldered bus bars has caused no issue on my build so far (mine is the last picture on the busbar guide on github). I had not much trouble soldering them without a thermal oven, for soldering them I shielded the bottom part component with aluminum and using solder paste I heated the whole PCB (minus the bottom part) uniformally to around 200°C with a heat gun then focussing on the bus bar them self.
It also seems to be strong enough since after a hard fall (around the 600's second on previous plot) I had the whole controler dangling over his phases and bus wires, zip ties are not always the best solution !
Can i suggest for the BRK fault you put a 10nF capacitor between the USB shell and pb12? I see you have a fairly old pill. Newer ones have this filtering on them already and it completely solves the BRK issue.
badgineer
10 W
Mxlemming already beat me to the punch, but i'll add some explanations around. There's 2 possibilities.
1) the BRK is triggered by really a spike in phase current that really exceeds the hardware limit. I'd recommend against disabling that. Magic smoke is even more annoying (at least to most people) than a power reset.
2) the BRK is triggered by noise that the pill pin PB12 catches from the high current (and thus high intensity fields) around. This is an inherent disadvantage of the pill based design.
If 2) is the problem (and it was in mxlemmings case) filtering the PB12 signal with a capacitor is a workable solution.
Here a pic of how it looks, (from mxlemming, who came up with and tested it)
PS: there is a second way of reducing the noise the pin picks up. Don't use removable headers, but solder the pill as close as possible to the board. The shorter the pins, the less inductance they have, the less noise they piuck up. This helps on ALL pins. But giving up modularity has some downsides also.
Also, this is not tested, unlike mxlemmings cap. It should theoretically reduce the noise a bit, but filtering will probably be better
Br,
owhite
100 W
- Joined
- Aug 3, 2020
- Messages
- 285
Greetings people.
A set of performance plots for the MP2.
Results are based on the latest MESC firmware build with field weakening. Firmware used for testing was developed by @mxlemming and is available here [LINK] . MESC documentation is available [HERE], questions about firmware operation should be referred to @mxlemming. We tried several field weakening values for parameterization and 90 was selected for plotting. Data for these plots can be found at github release [Github: 9b2d6f5] in the "datasets" repository. Plots are generated using matplotlib in python.
Data is collected by exporting serial information off of the F405 pill using the MESC serial. Briefly, this involves reconfiguring the MESC code to use UART1, connecting an ESP32 board to the UART1 pins, and sending data via bluetooth to a smartphone. The MESC code establishes a terminal with smartphone using "Another Term", a very nice vt100 emulator for androids. To get json output from the MP2 type: "status json" in the terminal. To complete logging data type "status stop". All the values that can be set using the terminal are displayed with "get". Values can be set using the command "set value number" so for example to set field weakening current type "set fw_curr 90".
Some settings in the code are as follows:
curr_max was set to 300 in the MESC terminal.
The motor used for testing: QS165, V1.0. The MOSFETs for the MP2: IPP026N10NF2S. Bike platform is shown here [LINK]. CAD files for the bike are here: [LINK]. The overall gear ratio is 9.8, the bike has 26 inch wheels, and to convert ehz to MPH divide by 13.996. Max speed for today was 54 MPH or 87 KPH. During testing I was never able to get the MP2 temperature to raise to a noticeable level -- probably as a result a big heat sink plate that gets a lot of airflow on the bike. The specific branch of the MESC firmware used for testing is here: [LINK].
Values shown in the plots refer in part to Id and Iq, which are important mathematical values relating to the amperages applied to the d-axis and q-axis of the motor. One relationship between these amperages is that phase Amps = sqrt( (iq^2) + (id^2) ), described by "phase A" in the plots. Other values plotted are:
Enjoy.
Many thanks to @mxlemming for his patient guidance and the MESC code, @badgineer for the MP2 platform, and @netzpfuscher for the incredible MESC terminal!
A set of performance plots for the MP2.
Results are based on the latest MESC firmware build with field weakening. Firmware used for testing was developed by @mxlemming and is available here [LINK] . MESC documentation is available [HERE], questions about firmware operation should be referred to @mxlemming. We tried several field weakening values for parameterization and 90 was selected for plotting. Data for these plots can be found at github release [Github: 9b2d6f5] in the "datasets" repository. Plots are generated using matplotlib in python.
Data is collected by exporting serial information off of the F405 pill using the MESC serial. Briefly, this involves reconfiguring the MESC code to use UART1, connecting an ESP32 board to the UART1 pins, and sending data via bluetooth to a smartphone. The MESC code establishes a terminal with smartphone using "Another Term", a very nice vt100 emulator for androids. To get json output from the MP2 type: "status json" in the terminal. To complete logging data type "status stop". All the values that can be set using the terminal are displayed with "get". Values can be set using the command "set value number" so for example to set field weakening current type "set fw_curr 90".
Some settings in the code are as follows:
#define MAX_IQ_REQUEST 200.0f
#define ABS_MAX_BUS_VOLTAGE 80.0f
#define QS165 // I think this no longer matters
#define MIN_IQ_REQUEST 0curr_max was set to 300 in the MESC terminal.
The motor used for testing: QS165, V1.0. The MOSFETs for the MP2: IPP026N10NF2S. Bike platform is shown here [LINK]. CAD files for the bike are here: [LINK]. The overall gear ratio is 9.8, the bike has 26 inch wheels, and to convert ehz to MPH divide by 13.996. Max speed for today was 54 MPH or 87 KPH. During testing I was never able to get the MP2 temperature to raise to a noticeable level -- probably as a result a big heat sink plate that gets a lot of airflow on the bike. The specific branch of the MESC firmware used for testing is here: [LINK].
Values shown in the plots refer in part to Id and Iq, which are important mathematical values relating to the amperages applied to the d-axis and q-axis of the motor. One relationship between these amperages is that phase Amps = sqrt( (iq^2) + (id^2) ), described by "phase A" in the plots. Other values plotted are:
- ehz = RPM * 60 / polepairs
- iq = Iq, explained above
- -id = the inverse of Id
- iqreq = iq "requested" by the user based on turning the throttle
- vbus = Battery voltage
- Vd = voltage vector associated with the d-axis
- Vq = voltage vector associated with the q-axis
Enjoy.
Many thanks to @mxlemming for his patient guidance and the MESC code, @badgineer for the MP2 platform, and @netzpfuscher for the incredible MESC terminal!
Last edited:
mxlemming
100 kW
- Joined
- Jul 17, 2020
- Messages
- 1,122
A few notes on Owhite's post above. I'll update this post later but excitement getting the better of me.
The first and most important thing to realise on this is that Owhite's bike is geared in a way that makes the base speed of the motor unacceptable, attains only about 30mph at a push. Probably less. So field weakening isn't just a bonus, it's a necessity.
Roughly 300 to 400ehz is the free spin speed without field weakening, and the available torque stops off from less... About 250ehz (where the -id curve kicks in). This is because the battery voltage is too low to push the current against the BEMF and resistance.
So effectively, the motor is being run up to about 2x base speed under field weakening and would have spun up significantly faster without load.
This is the constant power region, which you can see from the battery voltage - it sags by a constant amount indicating a constant power draw throughout the field weakening region.
At the start of field weakening point, the iq achieved deviates from the iq requested because it cannot be achieved without breaking the power limit and there isn't enough voltage left to actually drive the current into the motor.
Below this point, owhite simply isn't applying so much throttle, unsure why. Hopefully because it lifts the front wheel with such a low gear ratio and light bike.
I'm really quite pleased with this, because stable field weakening up to ++2x base speed is quite difficult. It took quite a few iterations of algorithms to get there and several rounds of field testing from Owhite. Previously I'd been developing "on the bench"and the subtleties and difficulties under full power were elusive, and it has been brutal on my power supplies which don't like it when the algorithm fails and the flux supression collapses.
The system is running sensorless with hall sensor startup (up to roughly 5% speed).
EDIT:
Further discussion with Elwinboots suggests that there is literally no more power to be got from this motor. Basically, all the voltage is being used just to create a rotating current vector pushing against the inductance. The resistance of the motor is barely relevant, it is the inductance causing the limitation as (at 500eHz):
Vphase = Vbus/sqrt3*max duty = 64V/1.73*0.95 = ~35V
Iphasemax = Vphasemax/jwL = 35/(500*2pi*90uH) = 123.8A... which is approximately what we are getting.
Contribution of resistance at this speed is roughly 123A*6.5mohm = 0.8V out of 35V. Relevant, but not the limiting factor.
To get more power out of this motor, we need higher voltage. To get more power out of ANY motor, we need lower inductance or to be able to run with lower eHz, so fewer pole pairs helps.
This is where the QS165V2 shines. It is ~65uH instead of ~100uH and is 5 instead of 7 pole pair. This means you can push roughly
7/5*100/65 = 2.15x as much current into it at voltage saturated speeds, so it will pull about the same initially, but will carry on and on pulling for twice as long.
The Lightningrods xxl motor (same ~8kg weight for comparison) is roughly 80uH and 5PP, so we could expect it to take
7/5*100/80 = 1.75x as much current for the same erpm. Much nicer form factor motor.
The first and most important thing to realise on this is that Owhite's bike is geared in a way that makes the base speed of the motor unacceptable, attains only about 30mph at a push. Probably less. So field weakening isn't just a bonus, it's a necessity.
Roughly 300 to 400ehz is the free spin speed without field weakening, and the available torque stops off from less... About 250ehz (where the -id curve kicks in). This is because the battery voltage is too low to push the current against the BEMF and resistance.
So effectively, the motor is being run up to about 2x base speed under field weakening and would have spun up significantly faster without load.
This is the constant power region, which you can see from the battery voltage - it sags by a constant amount indicating a constant power draw throughout the field weakening region.
At the start of field weakening point, the iq achieved deviates from the iq requested because it cannot be achieved without breaking the power limit and there isn't enough voltage left to actually drive the current into the motor.
Below this point, owhite simply isn't applying so much throttle, unsure why. Hopefully because it lifts the front wheel with such a low gear ratio and light bike.
I'm really quite pleased with this, because stable field weakening up to ++2x base speed is quite difficult. It took quite a few iterations of algorithms to get there and several rounds of field testing from Owhite. Previously I'd been developing "on the bench"and the subtleties and difficulties under full power were elusive, and it has been brutal on my power supplies which don't like it when the algorithm fails and the flux supression collapses.
The system is running sensorless with hall sensor startup (up to roughly 5% speed).
EDIT:
Further discussion with Elwinboots suggests that there is literally no more power to be got from this motor. Basically, all the voltage is being used just to create a rotating current vector pushing against the inductance. The resistance of the motor is barely relevant, it is the inductance causing the limitation as (at 500eHz):
Vphase = Vbus/sqrt3*max duty = 64V/1.73*0.95 = ~35V
Iphasemax = Vphasemax/jwL = 35/(500*2pi*90uH) = 123.8A... which is approximately what we are getting.
Contribution of resistance at this speed is roughly 123A*6.5mohm = 0.8V out of 35V. Relevant, but not the limiting factor.
To get more power out of this motor, we need higher voltage. To get more power out of ANY motor, we need lower inductance or to be able to run with lower eHz, so fewer pole pairs helps.
This is where the QS165V2 shines. It is ~65uH instead of ~100uH and is 5 instead of 7 pole pair. This means you can push roughly
7/5*100/65 = 2.15x as much current into it at voltage saturated speeds, so it will pull about the same initially, but will carry on and on pulling for twice as long.
The Lightningrods xxl motor (same ~8kg weight for comparison) is roughly 80uH and 5PP, so we could expect it to take
7/5*100/80 = 1.75x as much current for the same erpm. Much nicer form factor motor.
Last edited:
owhite
100 W
- Joined
- Aug 3, 2020
- Messages
- 285
with more throttle the torque on the back wheel is such that it loses traction and screech/spins on the tarmac.
Last edited:
hunting for a schematic, i see a post with part of one where is the main schematic ?
MP2-ESC/CCC_ESC.pdf at main · badgineer/MP2-ESC here
MP2-ESC/CCC_ESC.pdf at main · badgineer/MP2-ESC here
Last edited:
andrewwinter
10 µW
Hi
I made some progress with my testing, I managed to solve my opamp issues, BEMF looks good. However VESC reports wrong inductance and resistance values. The sound is good, detection finishes without a problem, but the values are wrong. I use a power supply set to 43V, 3.2A limit, Xaircraft A12 motor. MP2 reports these values:
If I set my correct motor parameters my motor spins, the charts look a bit weird though, currents seem unbalanced and don't really have sine shape, BEMF is nice. I assume that the issues share the same root cause. Do you have any idea what can cause that? I have an oscilloscope to check anything, but I don't know where to start
Thanks
Andrew
I made some progress with my testing, I managed to solve my opamp issues, BEMF looks good. However VESC reports wrong inductance and resistance values. The sound is good, detection finishes without a problem, but the values are wrong. I use a power supply set to 43V, 3.2A limit, Xaircraft A12 motor. MP2 reports these values:
- Motor resistance 1846,19mOhm
- Motor inductance 634,7uH
- Inductance difference 229,39uH
- Motor resistance 114,6mOhm
- Motor inductance 45,34uH
- Inductance difference 4,28uH
If I set my correct motor parameters my motor spins, the charts look a bit weird though, currents seem unbalanced and don't really have sine shape, BEMF is nice. I assume that the issues share the same root cause. Do you have any idea what can cause that? I have an oscilloscope to check anything, but I don't know where to start
Thanks
Andrew
Attachments
Dayanul Alam
10 mW
Is the esc build only for qsmotor or can I use it on a Lightning Rods mid drive?
mxlemming
100 kW
- Joined
- Jul 17, 2020
- Messages
- 1,122
I doubt it is your problem, but if you solder 6/18 FETs, you should do the middle ones since the current sense lines are there.
Using 1/3 FETs means you get higher current measurements than reality if you solder the middle ones, and lower than reality if you solder the outer ones. This could cause some deviation in RL but I do not think to the extent you are getting.
Unfortunately, VESC tool does not plot the actual phase currents. They are selected from the best two measurements (by a specific duty cycle metric) and transmitted as two instead of three numbers. They are then reconstructed by the tool. This means you cannot actually use them to debug the opamps, you need to resort back to your multimeter and oscilloscope.
The chances are you still have soldering errors or broken parts resulting from powering on with soldering errors.
It is also possible (but unlikely) that by having 1/3 MOS you are switching at a speed that causes excessive noise. I have seen this on other people's designs.
Using 1/3 FETs means you get higher current measurements than reality if you solder the middle ones, and lower than reality if you solder the outer ones. This could cause some deviation in RL but I do not think to the extent you are getting.
Unfortunately, VESC tool does not plot the actual phase currents. They are selected from the best two measurements (by a specific duty cycle metric) and transmitted as two instead of three numbers. They are then reconstructed by the tool. This means you cannot actually use them to debug the opamps, you need to resort back to your multimeter and oscilloscope.
The chances are you still have soldering errors or broken parts resulting from powering on with soldering errors.
It is also possible (but unlikely) that by having 1/3 MOS you are switching at a speed that causes excessive noise. I have seen this on other people's designs.
As you can see by the other messages in this thread, we have used the MP2 for at least 10 different motors at this stage. Personally I have run it with 6 different motors including 4 RC outrunners, an inrunner and a servo drive, Owhite has 2 different ones, Netzpfuscher has at least 4, Thecoco has at least 2, it has been run successfully on a QS273, a Surron original... These are just the ones I am aware of. It will definitely work with a Lightning rods mid drive using either MESC or VESC. They are very good high quality motors. Ask LR for the phase resistance and inductance (check it is phase not phase to phase) and flux linkage.
owhite
100 W
- Joined
- Aug 3, 2020
- Messages
- 285
@andrewwinter - I've mentioned this before but be sure to have a look at our docs for testing the MP2 to check for potential problems.
@mxlemming - I wonder if we could also generate some docs to help people debug/test their opamps.
Dayanul Alam
10 mW
Are there any fan headers on the MP2? IIf not, could I just add + and - traces to the MP2 connecting from the buck converters to a header?
Moreover, does the board have capabilities to connect to a Bluetooth module, just like with other open source ESCs?
Moreover, does the board have capabilities to connect to a Bluetooth module, just like with other open source ESCs?
Last edited:
owhite
100 W
- Joined
- Aug 3, 2020
- Messages
- 285
Regarding a fan header, yes you certainly could solder to 12v and gnd on the underside coming off of the low side of buck converter.
I have bluetooth on mine. I dont use VESC but in my case I connected it to one of the serial ports and it worked without problems. Flipsky ships a BT board (and there are many others) just BE SURE to check if youre using the proper pins connections on MP2 schematic. They are not necessarily identical to flipsky boards.
badgineer
10 W
Hi.
No, there are no fan headers. If you wire a fan to 12v, make sure your total load, including fan, does not exceed what your buck converter can deliver. As in, get a beefy one
Dayanul Alam
10 mW
I'm actually thinking of implementing arduinos, fans and temperature sensors to develop a cooling system on a seperate board. Hopefully this is more efficient. Looking forward for advice and suggestions. I will have it monitor the batteries, controller, etc. I'll release the details in another thread once it's done. Of course, it will be open source.Hi.
No, there are no fan headers. If you wire a fan to 12v, make sure your total load, including fan, does not exceed what your buck converter can deliver. As in, get a beefy one
Dayanul Alam
10 mW
In the image attached, regarding the exposed unmasked gold pads to the pins from the bus bars and phase pads circled by blue, is it necessary? Or it it alright if I get rid of it and and just keep the through hole and high current pads?
It's that I'm trying to make the pcb larger so that busbars can be easily mounted with screws because I'll be ordering the boards presoldered and as mentioned in the documents in the github repo, it was recommended to solder on the busbars first in a reflow oven or a hot plate.
I'll also make the phase pads larger so that the 3 screw holes can be utilized for better current sharing as well as more current sharing from the phase busbars contacting the exposed unmasked phase pads.
But since I won't be using solder to join the busbars but will use screws, will it cause any problems such as arcing and/or improper powerflow? It would be helpful to use some advise and suggestions so that I can go forward with this idea.
Once finished, it should make life easy, which is why I'm deciding to make a version of the board where I basically just scale it up. Another potential issue, I don't know if it will cause significant interference as ill be stretching the traces, so anyone please do let me know and provide feedback and suggestions if that is the case.
I'm thinking however since the traces are good conductors and the lengths aren't like hundreds of feet long which would have a high power loss.
It's that I'm trying to make the pcb larger so that busbars can be easily mounted with screws because I'll be ordering the boards presoldered and as mentioned in the documents in the github repo, it was recommended to solder on the busbars first in a reflow oven or a hot plate.
I'll also make the phase pads larger so that the 3 screw holes can be utilized for better current sharing as well as more current sharing from the phase busbars contacting the exposed unmasked phase pads.
But since I won't be using solder to join the busbars but will use screws, will it cause any problems such as arcing and/or improper powerflow? It would be helpful to use some advise and suggestions so that I can go forward with this idea.
Once finished, it should make life easy, which is why I'm deciding to make a version of the board where I basically just scale it up. Another potential issue, I don't know if it will cause significant interference as ill be stretching the traces, so anyone please do let me know and provide feedback and suggestions if that is the case.
I'm thinking however since the traces are good conductors and the lengths aren't like hundreds of feet long which would have a high power loss.
Attachments
There are 8mil trace for gate driver. Is it enought for 4amps peak current? How much parasitic inductance will such a thin trace create? Could it be a problem?
I used to use 15-25mil trace for gate driver and see no issue, just wonder how far it can go until reach the limit. 8mil trace will buy much more free space for sure.
I used to use 15-25mil trace for gate driver and see no issue, just wonder how far it can go until reach the limit. 8mil trace will buy much more free space for sure.
