VESC Prov2 hybred?

[TRS300]

One of the things I like about this site is all the experienced and creative people here. I had a damaged Flipsky 75200 Pro V2.0 and I took it apart to look at it. The way the control board is completely separate from the power drive board I thought was kinda cool. But of course it got my brain turning...
The control board is connected to the power board by 4 sets of 4pins that are used like pedistals...
If you made a custom PCB that connected the pedestal pins from two power boards, and connected a single control board to the two interconnected power boards, could it work like a 75400 pro V2?
I understand that the temp and current sensors might be off, but you could manage that via setting right?
Curious to what others think about this idea...

 

[A-DamW]

could it work like a 75400 pro V2?

Might need a few more mosfets to conduct that much current.

But, sure, they are just PCB's and you can specify any parameters you want in the HW conf, and compile.

 

[TRS300]

Might need a few more mosfets to conduct that much current.

But, sure, they are just PCB's and you can specify any parameters you want in the HW conf, and compile.

There would be twice as many mosfet because you'd be driving two power boards with one control board.

 

[scianiac]

I don't think it would really be worth it due to the amount of effort and the not amazing quality of these anyway. The issues though are the mosfet driver chips can only drive so many mosfets and extending those drive wires too long causes issues. I honestly don't know if those are real issues in this case though, it depends on so many unknown factors. But hey if you really want to give it a go I have a 75200 Pro V2 with a blown control board you can have for real cheap, I had planned on repairing or maybe using the parts but probably won't have the time.

 

[TRS300]

The issues though are the mosfet driver chips can only drive so many mosfets and extending those drive wires too long causes issues..

I'd like to acknowledge what you are saying before diving into anything... So this gate driver is what you are saying is a weak link? Is that because the chip is not good or is it because of what I'm proposing in this query?
As far as wire length, understand that what I envision is two power boards side by side. Both boards joined together by a custom connecting board that would be soldered to the power board(s) standoff pins. And the connection board would have its own standoff pins for the control board to connect to, tying together all three vesc boards. (hopefully that makes sense). The gate pins on the power fets don't consume power. So I'm not sure why the driver chip can't handle the extra fet gates? Maybe there's something more I'm missing here. I might be interested in that power board if I decide to try something...

 

[scianiac]

I'd like to acknowledge what you are saying before diving into anything... So this gate driver is what you are saying is a weak link? Is that because the chip is not good or is it because of what I'm proposing in this query?
As far as wire length, understand that what I envision is two power boards side by side. Both boards joined together by a custom connecting board that would be soldered to the power board(s) standoff pins. And the connection board would have its own standoff pins for the control board to connect to, tying together all three vesc boards. (hopefully that makes sense). The gate pins on the power fets don't consume power. So I'm not sure why the driver chip can't handle the extra fet gates? Maybe there's something more I'm missing here. I might be interested in that power board if I decide to try something...

Ah but the gate pins on Mosfets do consume power, you have to think about time. Yes those gates are just tiny capacitors so take a tiny bit of current to fill and empty to turn the FET on and off and the gate driver is what does that but it has to do that very very fast, not providing enough current (yes we are talking about small amounts of current but it's all relative) to slam that gate on and off fast enough means the FET spends just a little bit longer in that period of time where it's half off and half on, where it's resistance is high and heat is generated. And you are doing this, well I mean I guess you are doing it at whatever speed you set the frequency at in the VESC which is usually around 20-50khz. And the wire length is just a thing about adding capacitance, resistance and inductance to those gate wires which can cause issues.

Now will any of this actually effect this VESC hardware, I have no idea, it could work totally fine. I mean these boards are not exactly masterpieces of circuit design in the first place.

 

[TRS300]

So this is exactly why I like to think about stuff like this. It helps me learn about things I wasn't aware of. So due to Scianiac's points I learned about the bootstrap voltage pump for the high side NPN fets (which has always had me wondering how a NPN fet could be used on the supply side of the drive circuit). Now I understand the concerns raised better...

 

[scianiac]

I mean there are numerous options for better built VESC units, Flipsky is tied for the worst VESCs with Makerbase. Makerbase does tend to try more interesting designs but with often a complete lack of testing so new designs don't work on arrival. Flipsky seems to iterate and improve, hence the Pro V2 is idk what version at this point and I can say it does work a bit better. Now the better brands do cost somewhere from slightly more money to way way more money, most are well scaled in terms of quality though. Like yeah a VESC Labs unit is way way more money but is also way better built.

Regardless of all that I think I have the trick, the biggest issue with these cheap VESCs is where the hardware and design quality actually effects performance. These things will take plenty of power without overheating, FETs driving becoming unstable or any of the power side stuff really having issues. Where they have issues is the sensing side, lack of filtering, poor ADCs, poor circuit design, etc, etc mean they are noisy and have issues running in sensorless leading to instability and overcurrent cutouts at best and cooked controllers at worst when trying to push them. But here is the thing, we can just install an absolute encoder for like a few bucks and most of that becomes totally irrelevant. No issues with sensorless sensing when there is no sensorless operation going on. This is really easy on shaft motors but for hub motors I have searched and searched and have no easy solution. Ring magnetic encoders exist but idk if they are supported and they are much more rare. Other type of encoder wheel options also may work, maybe with a sin-cos output?

 

[TRS300]

But here is the thing, we can just install an absolute encoder for like a few bucks and most of that becomes totally irrelevant....

So I'd like to hear more on this... The ME1616 I'm using came with a sin/cos position sensor. I replaced it with a custom made magnet ring and a hall sensor unit from a Surron. The surron motor and the me1616 have the same construction profile. I switched the position sensor to a hall type because it is more simple to set up and seems to work fine in this use case.
Also, related to this is the vesc has a setting on what erpm to switch to sensorless mode. Couldn't we just bump that setting up to a higher rpm and keep the vesc in sensored operation mode?
I don't fully understand the benifits you are trying to obtain with the comment I highlighted...

 

[scianiac]

VESC supports sin cos encoders natively although many of these encoders you need to have the correct pins free and there needs to be no filters on the hall inputs which there probably is in basically every flipsky ESC, although they are easy to remove.

So basically when we use a suitable encoder type that will run at the needed RPM we do just set the sensorless transition higher than the motor will ever spin. At very high RPMs beyond which we normally use in our applications many encoders won't work but that's more like for stuff like prop driven things. Hall sensors though do not handle higher RPMs well and start to run into issues pretty soon into the RPM range that we operate at, they start to suffer from things like delay where the signals are shifted in time, some of these may be better with a magnet ring and hall sensors vs using the motor's magnets where your hall sensors are in a much more extreme magnetic environment idk but generally when using hall sensors the "set it super high and use those all the time" doesn't work well, it may run just inefficiently.

The other thing to consider is yes sensorless operation is I think one of the largest issues with low quality VESCs but it also depends on the motor a lot. Something like a RC outrunner will run pretty well in sensorless even with crap hardware, hub motors run OK, IPM motors generally run like shit and honestly don't run well at high power levels even with the best hardware. I've tried too much and seen too many people try and fail at this point every IPM motor I'm just planning on installing an encoder from the start. Also all of these issues are power related, if you drive a motor at a low power sensorless often works way better but if you want to push a motor hard it starts to fall apart. Encoders are generally easy to fit, cheap and I like being able to run motors hard. The only maybe slightly annoying part is the digital ones you have to have good wiring as it's a pretty high bandwidth digital signal that is easily disrupted by noise.

 

[TRS300]

... some of these may be better with a magnet ring and hall sensors vs using the motor's magnets where your hall sensors are in a much more extreme magnetic environment idk but generally when using hall sensors the "set it super high and use those all the time" doesn't work well, it may run just inefficiently.

How would I know if it's working well or not? The sensors and all of the sensor wiring is outside of the motor case and the magnet ring is hug on the end of the shaft protruding outside the case. So I don't think noise will be a big issue. As far as delay I don't expect this motor to be spinning higher than 4500rpm (if even that fast). Is this beyond what halls can handle?

I'm asking these questions because I don't want to try and fix something that I can't even sense is working poorly. In other words, how do I measure how well things are operating?

 

[A-DamW]

I'm asking these questions because I don't want to try and fix something that I can't even sense is working poorly. In other words, how do I measure how well things are operating?

You will have to do a bit of searching, but Benjamin Vedder's YT channel is a wealth of information.

Benjamin Vedder

Share your videos with friends, family, and the world

www.youtube.com

 

[scianiac]

From my understanding which certainly is far from complete hall sensors just have more phase delay, as in the time the magnet passes them to the time the signal is sent out is long enough that it can start to cause issues and when combined with the hall sensors having low resolution, they only send a signal when the magnet passes by. I think though a few VESC versions ago there was some features added to improve hall performance but still I've never seen anybody who knows what they are talking about suggest trying to use hall sensor operation at much higher ERPM than the VESC defaults.

I mean every type of sensor will run into the same issue, it's just that many encoders run into it far later because they have less phase delay and higher resolution.

If the issue was really a problem you would start to see unstable current in data views, basically where the VESC thinks the rotor is and where it actually is are slightly off at least at first and so it's estimate for how much voltage to apply is off and more or less current than it was aiming for is driven. Before that though efficiency would start to suffer for the same reason. Just in general though cleaner the data logs the better, even not knowing exactly what you are looking at it's pretty clear smooth lines are better, sine waves are better than jagged messes and so on, that being said the motor will run just fine with a fair bit of noise so if the data is a bit noisy at some point you just have to no worry about it.

 

[TRS300]

From my understanding which certainly is far from complete hall sensors just have more phase delay, as in the time the magnet passes them to the time the signal is sent out is long enough that it can start to cause issues and when combined with the hall sensors having low resolution, they only send a signal when the magnet passes by. I think though a few VESC versions ago there was some features added to improve hall performance but still I've never seen anybody who knows what they are talking about suggest trying to use hall sensor operation at much higher ERPM than the VESC defaults.

I mean every type of sensor will run into the same issue, it's just that many encoders run into it far later because they have less phase delay and higher resolution.

If the issue was really a problem you would start to see unstable current in data views, basically where the VESC thinks the rotor is and where it actually is are slightly off at least at first and so it's estimate for how much voltage to apply is off and more or less current than it was aiming for is driven. Before that though efficiency would start to suffer for the same reason. Just in general though cleaner the data logs the better, even not knowing exactly what you are looking at it's pretty clear smooth lines are better, sine waves are better than jagged messes and so on, that being said the motor will run just fine with a fair bit of noise so if the data is a bit noisy at some point you just have to no worry about it.

Thanks for taking the time to write that out. I put an oscilloscope on one phase wire last night to see what it looked like. And did the same on a hall signal. The hall signal looked pretty clean even when spinning up to full speed. One thing to keep in mind is that this being a heavy build with a gearbox I'm not likely to be spinning the motor much past 4k rpm anyway due to the torgue decline at lower voltage. I'm considering running 18s instead of 20s as well. Which gives the vesc more safety margin on voltage and allows for more amps for more torque. Anyway, thanks again for all the effort to help. Much appreciated.

 

[scianiac]

What version of VESC are you running, I think it was 6.02 where some of the hall sensor code was improved, although some of the improvements dealt more with hall to sensorless transition. Assuming your scope has two channels I would run both of those at the same time and watch for their sync, does the time between them change, although given that the VESC is driving the motor off the hall signal maybe that wouldn't work, you might have to spin the motor via an external source which would be a pain for such a large motor to get to a high speed.

There are disadvantages though of running the motor slowly, running it slowly at high amps will be less efficient than fast at less amps. Although in practice this often is not really an issue as for most vehciles you don't spend that much time at that high amp area, only during acceleation so assuming the motor can output the cruising power at well below it's max power gearing the motor to run a bit slow can be more efficient which given the size of your motor is probably the case.

 

[TRS300]

What version of VESC are you running, I think it was 6.02 where some of the hall sensor code was improved,

Both VESCs are running 6.05 (no hardware limits) 75_300_R2

you might have to spin the motor via an external source which would be a pain for such a large motor to get to a high speed.

I'm not sure what doing that would show... I'm not really sensing that things are running poorly. And I think the vesc would throw an error if the phases were out of balance for some reason.

during acceleation so assuming the motor can output the cruising power at well below it's max power gearing the motor to run a bit slow can be more efficient which given the size of your motor is probably the case.

Bottom line is with a gearbox I'll probably spin the motor as fast as possible to maintain speed. My tests so far have been slower speeds but with some incline. I've noticed it seems to move along pretty well on flat ground. I'm inching up the build little by little.

Keep in mind this is sort of a strange configuration. Each VESC is driving half of the motor which has been split into two. So the phase windings for each vesc are not connected. The position sensor (regardless of what type I use) is shared by each vesc. So they always see the same signal. So far this setup seems to be working fairly well....