New 2017 updates to ebikes.ca motor simulator to try out

Hey guys, we're doing a small round of updates to the motor simulator web app and have it at a point where it's ready to people try out. You can access it from this URL here:
http://www.ebikes.ca/tools/simulator2.html

When you're in single system mode, you'll notice now that there is a "show advanced" link, and if you click this it will expand to give you two additional tweaks:



Motor Temperature: This lets you set the motor winding temperature to see the effect on motor performance. You can easily see the decrease in performance when say the motor core is at 120 celcius compared to room temp. At the moment most of the models in the database have the motor winding temperature adjusted to 60-80oC so that it's more or less representative of average temps, but we'll be updating this soon so that the resistances in the database are all room temp resistance, and then you use this slider to see what happens when that increases. Notice that we are only modeling the increased copper winding resistance here, not any reduction in performance from hotter magnets.

KV Adjust (rpm/V): This slider lets you take the existing motor from the drop-down menu, and see what the performance would be like if you did an ideal tweak to the motor winding to a different KV or RPM/V. So if you increase the RPM/V by a factor of 2, the motor's RPM/V will be twice as fast, and the winding resistance and winding inductance would both decrease by a factor of 4. With this way, you can use the simulator to look at motors that are similar to but identical to the ones on the database. Just choose the nearest motor in terms of size, type (geared vs DD), and power level, and then tweak the KV adjuster until it matches your unloaded RPM.

Then in the vehicle parameters list, there is one more field available:



Human Power Input: Previously if you wanted to see your power consumption/range/speed of an ebike with human power taken into account, you'd have to drag the cursor to the right from the default position to a place where the difference between the load power and the motor power equaled the amount of your human input, and this wasn't very intuitive for people to figure out or understand. Now you can directly select the human power level and the default cursor will be located at the speed where the human power + motor power matches the load curve. So you just hit simulate, and it will take you on the graph where you'll be at steady state cruising speed with that level of human power input and let you read the numeric stats directly at that location.

Where things get even more interesting is in the System 'B' behavior. First thing you'll notice is that the first time you open a new System B now, it automatically copies all the options and parameters from system 'A' into the System B fields. Then you can very easily see the effect of changing just one thing (like the controller current, winding temperature, battery voltage etc.) without having to set up all the other fields to match first.


Once you've opened System B, you'll also notice that there are now TWO cursors visible on the plot chart. This was a great source of confusion for people in the past when we just had one cursor, as people would look at the stats for System A and System B and not realize that these are being compared at the same kph point on the graph, rather than being compared at their respective predicted cruising speeds. So now both system A and system B will default to have a cursor located where motor power + human power matches the load power to move the vehicle


You can then individually move each cursor to the left and right, just hover your mouse over the cursor you want to move and the icon will change to a slider arrow and then you can click to drag it to any other location on the graph.

And, most exciting for some people but way confusing for others, there is now an option to ADD the outputs of both motor systems onto a single ebike rather than just comparing them side by side. When you select the "Add" mode, then the 2nd vehicle parameters are greyed out, and the simulator assumes that both system A and system B are hooked up to the same vehicle. The graph then shows the combined thrust of both motors, the combined power, and the net effective efficiency of the dual motors combined.


In the data table on the bottom, there is an additional column in the graph data showing the net combined results, but you can still also see the individual output performance of each systems A and B and how they contribute to the total.

At the moment, each system is treated as having its own battery pack, the way the calcs are done with battery internal resistance we don't have an easy way of running the simulation assuming that both motor systems are pulling from the same battery. But it's easy enough to just add the Ah from the battery in system A and system B to see the total Ah pack that you are simulating.

Super cool add-ons.....wish it had the super high powered stuff though. Like QS 205's and 273's although as I can tell you from personal experience you just know they are going to be bad ass. (205 anyway.....maybe the 273 one day just because I want to try it.)

Thanks for all you do.

Tom

Those new features are great. Thanks for your work Justin.

What do you think about adding iron saturation?
Now, crazy high currents lead to crazy high torque as far as i could see
IIRC you did some tests about saturation on a 9C motor. If extrapolated to larger 205 types, like the MXUS 3k and such, i think it would be still quite accurate.
calling it "end of linear kT at .... phase amps" as example. or maximum torque per 1mm stator width for the calculation.

Nice, I like it.

The MAC 10T data seems to have an error in it somewhere, but thats been around a while.

litespeed said:

Super cool add-ons.....wish it had the super high powered stuff though. Like QS 205's and 273's although as I can tell you from personal experience you just know they are going to be bad ass.

Click to expand...

We've actually got the the 4 turn Cromotor on there (Cromo 5004 in the list) thanks to Sterling at Bend Electric Bikes who shipped us up a sample last year. So for a similar 50mm wide motor you can use that and then take advantage of the KV slider adjustment to tweak it for the same RPM/V as your 205mm QS motor. That said, it looks like QS motors is interested to offer Statorade and Cycle Analyst's as options from their shop and in that case almost for sure I'll be getting ahold of a sample or two for doing thermal and dyno analysis here, and you'll see them listed both on the motor simulator here and the way more sophisticated trip simulator.

Triketech said:

The MAC 10T data seems to have an error in it somewhere, but thats been around a while.

Click to expand...

Ah thanks, indeed it looks like the phase resistance was set to 0.009 ohms rather than 0.090 ohms in the database table. Thanks for catching that, it should work OK now!
There is still an issue that if you try to simulate a low resistance/inductance motor (like the MACs) at high voltages with high amp low resistance controllers it can cause the the equation set to fail. It's not so much that there is an error in the data but that the equation solver that we wrote for determining the performance at each point doesn't handle situations where the motor has very low inductance and resistance and fails to converge. For instance if you run the MAC10T at 72V with our stock 40A controller option it renders OK:


But if you use a custom 40A controller with just 0.01 ohms of controller lead and mosfet resistance, then it blows up


In practice most real world setups never run into this but if you're goofing around with hypotheticals and the graph just stops or oscillates like crazy this is why.

madin88 said:

Those new features are great. Thanks for your work Justin.
What do you think about adding iron saturation?

Click to expand...

The issue here is that I don't really have enough data or the means to get data for characterizing the performance of the motors when they are in this realm. If you look back at the setup I did when measuring this on the early 9C, BMC, and eZee motors
https://endless-sphere.com/forums/viewtopic.php?p=216194#p216194

The testing was all done when the motors were static rather than rotating and I'd quickly run into the issue of the windings overheating and insulation melting before I could have time to collect the higher amperage datapoints. In order to actually have 100+ phase amps flowing through the motors while they are spinning we'd need to build a very different test apparatus. Probably the most ideal would be an inertial dyno arrangement where we can do the motor spin-up from a standstill with crazy high current motor controllers and then look at the dyno acceleration curve to extrapolate the motor torque / phase amps relationship.

Now, crazy high currents lead to crazy high torque as far as i could see

Click to expand...

Indeed, and the fact that people continue to see this and believe this continues to nag me all the time. I've been tempted to simply have the simulator graph not display anything in the areas where we know that motor saturation is coming into effect, both to say in some sense "don't operate your motor here" and so that there is no false performance data presented.

But first we'll be implementing a controller phase current limit into the simulation and this might address the issue well enough. Right now the simulator is only doing battery current limiting and so with low resistance motors it will often predict way higher phase amps and motor torque off the line than you have in practice. With the controller phase current limit in the picture, this wouldn't happen since the default phase amp limits would generally be below the motor saturation point.

justin_le said:

Ah thanks, indeed it looks like the phase resistance was set to 0.009 ohms rather than 0.090 ohms in the database table. Thanks for catching that, it should work OK now!

Click to expand...

Works really well. Through June we put over 400 miles through mountain trails, gathered a lot of data/GPS/Video. I use a Phaserunner @ 30A, 48V (53.5) LiFePO4 battery.

In various scenarios, numbers were pretty close between the simulator and real world; not dead nuts, but fabulous for a simulator. Thanks!

justin_le said:

litespeed said:

Super cool add-ons.....wish it had the super high powered stuff though. Like QS 205's and 273's although as I can tell you from personal experience you just know they are going to be bad ass.

Click to expand...

We've actually got the the 4 turn Cromotor on there (Cromo 5004 in the list) thanks to Sterling at Bend Electric Bikes who shipped us up a sample last year. So for a similar 50mm wide motor you can use that and then take advantage of the KV slider adjustment to tweak it for the same RPM/V as your 205mm QS motor. That said, it looks like QS motors is interested to offer Statorade and Cycle Analyst's as options from their shop and in that case almost for sure I'll be getting ahold of a sample or two for doing thermal and dyno analysis here, and you'll see them listed both on the motor simulator here and the way more sophisticated .

Click to expand...

Well that is pretty darn cool. Cromotor has a kv of 9.35 and mine is 14.31 so multiplying by 1.53 gives me a really close 14.305. That shows a top speed of 52 mph.......mine is a bit higher in real life on a full pack but putting in full tuck is so close it's amazing what you have done with this.

I always think about that monster QS 273 with a 600 amp phase controller but I'm really just kidding myself.....that would definitely get me hurt in a hurry! What I have is as quick as most cars/motorcycles with a top speed in the 60's....on a bicycle even and that is before any MaxE over volting which I'm sure would get me into the 70's.

Thanks again for all you have done for us.

Tom

litespeed said:

View attachment 4Super cool add-ons.....wish it had the super high powered stuff though. Like QS 205's and 273's although as I can tell you from personal experience you just know they are going to be bad ass.

Click to expand...

Awesome, I love you you have chosen to show the %grade option rather than the default load line for the vehicle.

At the time I had this implemented I was thinking it would be the coolest thing just to see at a glance what your speed will be going up any given grade hill just from a single graph, but I found that most people had trouble making sense of it so we left load line as the default and I didn't know that anyone was really making use of this feature. Anyways it made me realize that we hadn't taken into account the Human Power part of the equation when showing the black plot as the %grade line so I'll see that this detail is updated.

Here's an example of using this plot option with new motor temperature feature to compare the performance of a Crystalyte H3540 motor when the core is at room temp vs with it heated to 120 degrees as it will get on a long hill climb. If I slide both the 'A' and 'B' cursors to the speed where they show a 10% grade hill, you can see that the cooler motor climbs at a ~10% faster speed (25.4 kph vs 22.6 kph) and with ~10% lower battery consumption (50.6 wh/km vs 55.0 wh/km) than the hot motor core.


It's cool to see these things quantified like that and can help answer a lot of hypotheticals about motor cooling. So if you had say a high velocity forced air motor cooling circuit that consumed 100 watts of power to run, then in this case climbing at ~22 kph it is adding just under 5 watt-hours/km to your energy needs, more or less negating the improved efficiency you'd otherwise experience from the cooler hub. But if the active air cooling only needs 20 watts, then the extra energy it consumes is way more than offset by the reduced energy needs from the cooler motor in this example.

It's probably silly of me, but of course I had to be different, and try using just human power to get a chart on the graph...not unexpectedly that doesn't work, AFAICT.

Other than that, I like the new addition(s).

Oh, and I almost forgot--the Chart Options box is overlapped by the bottom "frame"? with the "Shop Learn Grin Tech Products Products (cont) Tools Grin Tech" stuff, regardless of how I size the browser or change the font size (ctrl+/-), etc. Firefox 37.0.2, Windows10. (same with all addons disabled or not)

I can access the dropdowns for the invisible chart options (blue and black lines) by tabbing to them from the top visible one, which forces things to scroll to show them.

The regular simulator page doesn't have this issue (and also has all the explanation/instruction stuff below the simulator, which the new one does not).

amberwolf said:

I can access the dropdowns for the invisible chart options (blue and black lines) by tabbing to them from the top visible one, which forces things to scroll to show them.

Click to expand...

Try fully refreshing your browser cache. People using Chrome who've recently used the normal simulator will similarly have issues and you need to push ctrl + F5 and it should render correctly. I just opened and used it in firefox with no issues.

And for simulating just human power, it's true that if you set the throttle to 0% it doesn't render anything but if you put a low throttle value it will work just fine and show accurate results. Like here it is with a Crystalyte H3540 motor with 200 watts of human power and the throttle set to a point where the motor is providing no power. The simulator accurately shows that at 24.7 kph, the load from air+wheel drag is 175 watts, while the motor has 24 watts of cogging resistance, and so this is the speed where the combined cogging + drag losses match the human input of 200W



This should be a reminder to people too that you can use the simulator as a tool to see the cogging drag of various motors and in different wheel diameters to look at the effect on your speed. You can see in the graph above that if the motor had zero drag, then pedaling with no assist at 200 watts you'd do a little over 26 kph rather than 24.7 kph, so you can conclude that the drag resistance from the Crysatlyte motor has slowed you down by ~1.5 kph when under pedal only power.
You can see this exactly if you select a geared motor from the dropdown list (like the eZee hub) instead of a DD motor, it shows in that case zero cogging drag as it is modeling the internal freewheel and you can see the speed in this case would be 26.2 kph.

Alright guys, click on
http://www.ebikes.ca/tools/simulator2.html

and then hit ctrl+F5 to refresh your browser cache if you visited this page earlier. There are now three pretty huge new additions to the feature set since I first posted this link a week ago. The first person to point out all 3 of them gets, I dunno, 100 simulation points!

Excellent improvements, haven't had time to try them out yet, but great work!

Thanks!

justin_le said:

Alright guys, click on
http://www.ebikes.ca/tools/simulator2.html

and then hit ctrl+F5 to refresh your browser cache if you visited this page earlier. There are now three pretty huge new additions to the feature set since I first posted this link a week ago. The first person to point out all 3 of them gets, I dunno, 100 simulation points!

Click to expand...

OK, well it seems nobody was all too interested collecting the simulation points so I'll spill the beans here :wink:

1) Controller Phase Current Limit: Now we've got motor controller phase current limiting fully implemented, which will help tame otherwise false low-end torque predictions and also let people simulate vehicle performance when using a torque controlled motor controller like the Phaserunner. The difference with low resistance motors is pretty significant, here for instance is a 350rpm eZee motor with a 20A controller, showing what happens with a realistic 50A phase current limit vs what would previously be predicted, at 2kph the difference is a substantial 42Nm vs 66Nm:

So now when you input a custom controller now you can separately set the max phase current and battery current.

This can be really handy if you want to simulate the behavior of a system running a torque throttle controller, as you can custom set your phase amps to match a given throttle setting. If you have a Phaserunner with 80A max phase current limit, then to see the motor behavior at 25% throttle and at 50% throttle, you'd just set the controller phase amps limit to 20A and 40A respectively.


A presentation of the graphs this way also helps to bury the perception that hub motors only have a narrow range of good efficiency close to the unloaded RPM. That is totally not the case, as you can see when you plot the graph with constant motor torque (rather than dumping excessive power into the motor at low speeds) the region of high efficiency covers a huge swath of cruising speeds, from 12kph to 48kph in this example here.

Did anyone spot improvements #2 and #3?

Totally cool Justin!
I cant move my Grade slider, but I will scroll throw this thread a few more times.

Be cool to get the new MXUS 5K on the list. Just need the one turn count as we can adjust the KV now.

Just to be sure, can you confirm

1kv x 2V x 1A = 2kv x 1V x 2A

This way we keep the same rpm and same torque

It's just the the kv adjustment is limited and wish to experiment a hub as mid drive
maybe wind it with 1T instead of 5T but gear it inversly
I can generate then 5x the power knowing that a motor is torque machine
What is a conservative electrical frequency for a 2705 ?
is 1000Hz still ok ?

markz said:

Totally cool Justin!
I cant move my Grade slider, but I will scroll throw this thread a few more times.

Click to expand...

Are you testing it out with a mobile device or on an actual computer? The slider works fine on all the browsers we tested, so if you could give more details on your system that'd be good (and don't forget to refresh the cache)

Joe90 said:

Just to be sure, can you confirm
1kv x 2V x 1A = 2kv x 1V x 2A
This way we keep the same rpm and same torque

Click to expand...

Exactly correct. I should also remind you that to properly normalize things the controller resistance should change by a factor of 4 to have the same total controller losses, and similarly the internal resistance of the battery packs need to differ by a factor of 4. So the full details would be:
1kv x 2V (0.1 ohm IR) x 1A (0.04 ohm Rc) = 2Kv x 1V (0.025 ohm IR) x 2A (0.01 ohm Rc)

If you don't do this and just naively choose say a 72V battery and 20A controller vs a 36V battery and 40A controller at twice the KV, you can see some pretty divergent results like this:


If I fix a custom controller and custom battery that are appropriately scaled then the two curves line up perfectly as we'd expect

It's just the the kv adjustment is limited and wish to experiment a hub as mid drive
maybe wind it with 1T instead of 5T but gear it inversly
I can generate then 5x the power knowing that a motor is torque machine

Click to expand...

Don't forget that your eddie current core losses increase at the square of the RPM. So it may be a torque machine but the no load power just to spin the motor at 2000 rpm would be upwards of 300 watts, that's just waste heat to spin the motor that fast with no torque output.

What is a conservative electrical frequency for a 2705 ?
is 1000Hz still ok ?

Click to expand...

That's a question for the motor controller and has nothing to do with the motor itself. 1000 Hz is (1000 * 60 sec/min / 23 polepairs ) = 2600 rpm. There would be a mechanical RPM point where if you don't properly balance the motor it would wind up having a ton of vibration, and for a low cost chinese motor like the 2705 it's gonna have wobble for sure so you'd want to have it dynamically balanced with weight added/removed so that the CG is perfectly centered on the axis.

justin_le said:

Did anyone spot improvements #2 and #3?

Click to expand...

Well still no takers on this! Here's one of them in case you were all too obsessed with the output graph to notice what was going on on the browser bar itself. Now when you customize the fields of the simulator the URL of the browser updates to reflect the choices so you can create a URL link of the exact simulation profile.

For example here's what happens if I choose a 9C 2707 motor with a 48V battery, 35A controller in a 24" wheel climbing a 2% grade with 125watts of human power


Rather than doing screen captures and whatnot, you can just copy and send the URL to have all those values prefilled. Try it out:
http://www.ebikes.ca/tools/simulator2.html?motor=M2707&batt=B4812_MH&human=125&cont=C35&wheel=24i&grade=2

At the moment it doesn't work yet with custom controllers or custom batteries but that will be fixed shortly. And it works for system 'B' parameters too if you want to save a comparison of two setups. One consequence of this addition which has both pros and cons is that every time you change a setting in the simulator it becomes a new page in the browser history. So you can use the browser's back button to get to a previous simulation that you did. That can be handy at times but also a bit annoying if you got to the simulator via a link, played around for a bit, and then wanted to get back to the original page you came from with the browser's back button. We could also have it so you need to click a "get link" button to get the complete URL and not have this behavior, and we're open to your feedback between the two approaches.

Now for the 3rd big simulator improvement of last week, surely even a mildly astute user could tell what the difference is between system A and system B here?
http://www.ebikes.ca/tools/simulator2.html?motor=M2707&batt=B4812_MH&human=125&cont=C35&wheel=24i&grade=2&motor_b=M2707&batt_b=B4812_MH&cont_b=C35&wheel_b=24i&human_b=125&grade_b=2&wind_b=-30

You can add A+B ?

This way a 2wd system can be analysed

Thanks for taking time to educate me (I did not take time to do thorough tough about the whole system)

Joe90 said:

You can add A+B ?
This way a 2wd system can be analysed

Click to expand...

Nope. That was already discussed in the 2nd post here:
https://endless-sphere.com/forums/viewtopic.php?p=1309981#p1309981

By now someone must have spotted and played with the final new feature.

Custom Frame Type?

markz said:

Custom Frame Type?

Click to expand...

Nope, that's been there since 2011 (https://endless-sphere.com/forums/viewtopic.php?p=435047#p435047 ) although it is the case that as of today the custom vehicle CdA / Cr is shown in the URL properly, along with custom batteries and custom controllers.

Anybody else?

justin_le said:

We could also have it so you need to click a "get link" button to get the complete URL and not have this behavior, and we're open to your feedback between the two approaches.

Click to expand...

I vote for the make-a-complete-url-every-time-a-parameter-is-changed version--that would be nice to have. Been wishing I could do something to easily save the parameters of various simulations for a long time, so thanks for this!

For those that do need to "go back" several pages, in at least some browsers, simply rightclick on the back button and it gives a history list of the several most recent pages to pick from.

amberwolf said:

I vote for the make-a-complete-url-every-time-a-parameter-is-changed version--that would be nice to have. Been wishing I could do something to easily save the parameters of various simulations for a long time, so thanks for this!
For those that do need to "go back" several pages, in at least some browsers, simply rightclick on the back button and it gives a history list of the several most recent pages to pick from.

Click to expand...

Yup, although it doesn't take too much messing around with the simulator to have the entire back history on a right click be of the simulator page


On playing with this some more I've realized that perhaps the best solution would be to have the URL only update when you click the "simulate" button, while right now it changes every time you change any selection item regardless of whether or not you've run the simulation on it. I'll see if we can do it that way.

Anyways I'm still waiting on someone to get this!
https://endless-sphere.com/forums/viewtopic.php?p=1312607#p1312607

justin_le said:

Nope. That was already discussed in the 2nd post here:
viewtopic.php?p=1309981#p1309981
By now someone must have spotted and played with the final new feature.

Click to expand...