Changing FOC Switching frequency

Well, dyno now has external current, voltage and rpm measurement. Current measurement is calculated using the formula on Pololu’s website, but reads ~10% higher than vesc’s current measurement. I could fudge the measured reading to line up with the vesc readings. Not sure which is correct, however. Each run is capturing data from both sources simultaneously. I did add a filter cap to bring the current sensor’s bandwidth down to smooth spikes.

Ignoring the offset for now, the dotted lines are the externally measured voltage and current, and the solid the ones calculated from vesc’s internal voltage and current. There is also an external RPM sensor, but that tracks very cleanly to the vesc rpm. Both use the same load cell reading for torque, of course.

Somewhat amazingly, the 20khz setting was unstable for the tested motor. It hunted quite a bit. Redetection helped that out, but made it an apples to oranges comparison to the other plots, perhaps.

Not really conclusive yet. Thoughts? I’ll do more testing soon (gonna annoy the neighbours if i continue tonight). Just wanted to share what i’d got today. More data should make it more clear what’s going on. Will try other motors too, of course.

inconclusive

2 Likes

Very interesting, the VESC back calculates current pull from battery based off of motor amps so I suppose it doesn’t account for the draw of all the passive stuff (something like 0.1 amp) what current ranges are you operating in? Regarding your filter cap, did you add a RC passive filter? In theory this would only lower the analog value which wouldn’t make sense why the current pull was actually higher. The data seems pretty noisy to make any real conclusions off of.

With the Vesc tool doing no-load testing I’ll get slight increases in current drawn going faster until I hit 95% duty cycle and then it will drop and maybe even half an amp lower. Why? Are esc losses included?

There is a dedicated filter pad for the pololu current meter. https://www.pololu.com/product/2199 I’m using the chart from the datasheet to get 0.1khz (1000nF cap) bandwidth. I’m sure they didn’t create a pin on the IC for this if it’d modify the reading accuracy.

The 0.1khz is still 10x higher than i’m actually sampling at, which means some artifacts from fast changing current could get through. I guess i’ll add some buffering and averaging in the arduino code to get 10x samples per sample from the pc to arduino, which itself is already doing 10 samples per point on the graph. This may or may solve it, but i don’t think it could hurt. Wanted to keep all the smarts in the computer and have the arduino just be a dumb data collector (no math, constants or conversions).

I just added a watt meter i had laying around to the setup, so there is an LCD display giving voltage and current. I’m seeing 40mA to 60mA for the vesc and the current sensor with voltage divider. Not accurate at this low level i’d imagine, but it’s something. There current difference i’m seeing is upto a couple amps, so it’s not the quiescent current. Current range is 15a (at 30v = 450 watts). With this third measurement device i’m hoping to get a consensus. Which is wrong? Vesc or pololu current sensor? Likely i’ll get a third opinion, because of course i will.

Stay tuned.

3 Likes

Initial reading from the external LCD current measurement show it and the pololu agreeing, leaving the vesc pretty far off :-/ All readings were pretty stable, bouncing a couple hundred mA or so. For this sample measurement 50% duty chosen on the test motor, 15a of braking on the brake motor.

I’m manually doing the same math the script does (since it’s kinda buried in there). Depending on what i choose as the current reading from the arduino (559 or 558) the value is pretty close. Serial monitor in background to show readings from the arduino, “c=xxx” is the current part. pololu_current

Photo of the watt meter. IMG_20181202_123441

Photo of VESC-tool’s current meter. IMG_20181202_123434

4 Likes

Which also means the efficiencies i was seeing are way too high. The motors are in the 85% range, not the 92% range. Another frowny face due here. Better to know than not though, of course. Means heat dissipation calculations/simulations i’ve done are also way off. (Just for fun, since it’s off topic, here’s a CFD airflow simulation of airflow in a submerged pod in water. Motor assumed to create 50watts of waste heat (450watts input * 90% efficiency) heat_flow__submerged_pod

5 Likes

Ps, thanks everyone for the support on my progress on this project. I’m hoping the data helps the VESC community, but it’s also a selfish desire to improve my own knowledge. Apologies for anyone angry that i seem to have highjacked this thread. I only wanted to share those initial findings, but the conversation lead me/us toward more questions that mattered, and lead to improvements in the techniques and data collected.

Anyhow, Ran outta battery juice, recharging. So far the new data looks like this. This is only the externally measured data, which seems to be smoother now than the vesc reported data. The arduino is doing 10 point moving average of the measured voltage and current. Python script averaging over 10 samples too. I’m also using a median average, rather than a mean, so it’s much more spike/error tolerant, which are visible in the mean averaged data.

beginning_foc_switching

Interestingly, on this motor, with only a few runs done, it seems like 15khz isn’t any worse than 20khz. 25khz is pretty bad though. Not only is it less efficient, the curve shape is different, and peak efficiency for that curve is at a much lower rpm. 22khz might be slightly better, but it’s not clear with so few runs. Getting interesting…

As always, more data required, and i’ve got shit to do in the real world, so it’ll be at least a couple days until i can work on this some more.

3 Likes

Are u solely getting data on motor eff or also the esc included?

It’s system wide. It’s the motor and controller together. There are a couple bearings in the system too, so each of those is robbing a little power in heat. Three bearings in the dyno plus the two in the brake motor (though the motor ones do contribute a little in the torque reading).

Mechanical power out / Electrical power into esc

1 Like

Is the Vesc data logging including the esc losses? I’ll get a drop in no load current when I get to 95% duty

In theory, the only thing the VESC isn’t measuring is it’s own power draw, i think, which is minimal. I’m seeing that the VESC’s current measurement from the battery leave a lot to be desired, so take any measurements you do via the ESC with a pinch of scepticism. Maybe put a meter in the circuit for no-load current, it’ll only be an amp or two. Can compare results that way.

3 Likes

Interesting, if your data is good, it’s seens to be motor dependent to a really high degree, really want to finish my board to try this in real life

I thought 100% duty would be more eff w no switching (if 100% duty even possible) but 95%?

VESC tops out a 95% duty

I know on the Vesc 95% is max duty cycle but why the current draw is about half an amp less at that. Is it because at 95 it’s ON consistently throughout the commutation and no pwm? I’m guessing that’s why

2 Likes

Me trying to understand everything that’s being said in this thread :

image

13 Likes

Looks like vedder is doing similar testing on his new VESC.

4 Likes

The VESC adc sampling is tied to the switching frequency, so as you drop switching frequency (increases efficiency) you also drop sensor resolution, which can introduce control errors.

1 Like

We are talking about dropping the freq on sensorless motors.

This is a very special motor, putting max strain onto the ESC. 70kHz switching! We use 20kHz for our motors. This turbine is the worst case scenario. The 75/300 is probably the only controller in the world being able to run it in FOC at full power. Good news: A lot of the 75/300 tech will be part of the next generation VESC SIX design. Be surprised!

1 Like