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

[neptronix]

Awesome! thank you!

 

[markz]

Those are my guesses below (without skimming the thread), which are probably just stating features already listed.

More permanent increments on the weight.
I do like it that its both kg and lbs.

Last guess for me: More permanent higher increments of power, along with Custom Power.

But like I said these are likely just stating what you already did, but maybe, just maybe I got it.

 

[justin_le]

More permanent increments on the weight.
I do like it that its both kg and lbs.
Last guess for me: More permanent higher increments of power, along with Custom Power.

Well, we did indeed do both of those things in the last couple days, including you'll notice soon (not yet uploaded) more default options for the wheel size too. But those are minor little enhancements to the existing feature and not a whole new feature like I am talking about. Really I thought I gave a super good hint with this:

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

!
(note you do need to open system B on the simulator page to see the difference naturally)

 

[markz]

I think maybe I got it.
My last throw (mainly because no one else is going along)
Best logical answer....
Moveable Y Axis B: Cursor Bar on System B

dashed vertical cursor that coincides with the point where the output power of the motor intersects the load line of the vehicle. This is the expected steady-state cruising speed for that particular arrangement with no human pedal input. The table underneath the simulator shows the numeric performance values of the system at this point.

Where as the original never had the B Cursor on 2 motor comparison.

 

[justin_le]

I think maybe I got it.
My last throw (mainly because no one else is going along)
Best logical answer....
Moveable Y Axis B: Cursor Bar on System B

dashed vertical cursor that coincides with the point where the output power of the motor intersects the load line of the vehicle. This is the expected steady-state cruising speed for that particular arrangement with no human pedal input. The table underneath the simulator shows the numeric performance values of the system at this point.

Where as the original never had the B Cursor on 2 motor comparison.

Hey Mark and thanks for continuing to play! Indeed that was one of the new additions but it's something that I already talked about in the very first initial post,

What I'm looking for is something we included in an update last week that I haven't mentioned anywhere here. I really thought people would have found and been excited playing with it (I sure was) but maybe my expectations are misplaced. I'll give it through the weekend in any case and then spill the final beans on monday.

 

[amberwolf]

Not sure if this is a bug or a problem at my end, but it happens in FF 37.02 (even after clearing cache/etc) and in Opera 45 (which I never opened the new simulator in before this test):


If I setup A as
clyte 5304
58v 0.01ohms
35a aot460 controller
throttle 44%
35c motor temp
kvadjust 1
tailwind 0
20" wheel
elf bike car
204kg/450lbs
0w human power
0% grade

and B as
mxus 4503
58v 0.01ohms
35a aot460 controller
throttle 44%
35c motor temp
kvadjust 1
tailwind 0
20" wheel
elf bike car
204kg/450lbs
0w human power
0% grade

then set them up as Add, I get this URL
http://www.ebikes.ca/tools/simulator2.html?motor=M5304&batt=cust_58_0.01_40&human=125&cont=C35&wheel=20i&grade=0&motor_b=MX4503&batt_b=cust_58_0.01_40&cont_b=C35&wheel_b=20i&human_b=125&grade_b=0&wind_b=0&frame=ELF&mass=204&hp=0&temp=35&wind=0&blue=Lbs&axis=mph&black=load&throt=44&hp_b=0&mass_b=204&frame_b=ELF&throt_b=44&temp_b=35

But if I open that URL in a new tab in ff (with teh old still open too), or in a totally new browser session in opera, the display is wrong (with or without clicking Simulate):
--There is no graph drawn.
--no motor is shown in either dropdown a or b
--is indicated to be in compare mode, not add, has two pointer bars (one for a and one for b)
--shows 20" custom wheel on system b, not simply 20" wheel as was picked on the original

If I re-pick the motors, and click Simulate, it gives a chart, but the results in the chart and the boxes below it are different from the original, even though all the parameters look like they are the same. See the attached images for the Simulation Original setup, then the blank version, then the "reactivated" version after reselecting the motors.

 

[markz]

This feature only shows when you do a side by side comparison is that right Justin?
The "Net" :wink: result is unkown for me.

 

[grindz145]

Gah! That's awesome! I've been manually backing out the human power by moving the slider around to account for the difference between the load line and motor output, but this is way easier and precise!

 

[justin_le]

But if I open that URL in a new tab in ff (with teh old still open too), or in a totally new browser session in opera, the display is wrong (with or without clicking Simulate):
--There is no graph drawn.
--no motor is shown in either dropdown a or b

Oh that's just because you have motors selected from the "show all" list rather than just the active motors listing. Since the dropdown motor menu by default populates with the active motors only then it can't show the motor in the URL since it isn't on the list of available motors. This is something that is going to get fixed soon.

Also, I should mention too that at the moment the simulatior2.html results are not going to be super accurate on most of the simulated hubs as the motor resistance values we have in the database are working resistances when the core is ~80 degrees, rather than room temperature resistance. So when you have the motor temp slider at 25 degrees it's actually showing the results from a much warmer motor core, and the default setting of 60oC corresponds to a core that is more like 100-110 degrees. Once we're ready to go live with the code at simulator2.html then I'll update all the motor characteristics to have the room temp winding resistance for the motor core.

I'm just back from a weekend trip and still no one has called out the last big feature...

 

[cycborg]

I'm just back from a weekend trip and still no one has called out the last big feature...

I'm sure I could see it if the wind weren't blowing this dust in my eyes...

 

[amberwolf]

Oh that's just because you have motors selected from the "show all" list rather than just the active motors listing. Since the dropdown motor menu by default populates with the active motors only then it can't show the motor in the URL since it isn't on the list of available motors. This is something that is going to get fixed soon.

Ah, ok. I had thought it might be something like that, but since it does have the A & B motors in the URL itself, I was surprised that it didn't work anyway (that the page code didn't just parse the data in the URL and instead did whatever it is actually doing).

That's why I wasn't sure if it was just me.

URL broken down just so I can see what's in it:
<snip>http://www.ebikes.ca/tools/simulator2.html?
motor=M5304&
batt=cust_58_0.01_40&
human=125&
cont=C35&
wheel=20i&
grade=0&
motor_b=MX4503&
batt_b=cust_58_0.01_40&
cont_b=C35&
wheel_b=20i&
human_b=125&
grade_b=0&
wind_b=0&
frame=ELF&
mass=204&
hp=0&
temp=35&
wind=0&
blue=Lbs&
axis=mph&
black=load&
throt=44&
hp_b=0&
mass_b=204&
frame_b=ELF&
throt_b=44&
temp_b=35

 

[markz]

Patiently waiting for this "new" overlooked feature in the 2nd panel.
I tried and tried, even read current features AGAIN :lol: compared a few other things from orig.-sim to sim2 maybe my eyes went wonky due to looking at the sun for a very brief period. 8)

 

[justin_le]

I'm just back from a weekend trip and still no one has called out the last big feature...

I'm sure I could see it if the wind weren't blowing this dust in my eyes...

Yay!! Cycborg get's all 100 simulation points.

There's now a wind speed slider that you can use to see the effects of headwinds and tailwinds on your ride. For some reason I was a bit reluctant to add this earlier, but it's been quite fun to see the effect on the vehicle load line and it really helps put into perspective the amount of variation you can experience with the same setup and slightly different wind conditions. Like a mild 10 kph breeze, barely enough wind to fly a kite or move a sailboat. With a decently fast system like the H3540 motor and 52V battery pack, you'll cruise 55kph rolling with the wind consuming 20 wh/km, while going the other direction you'd be doing 43kph and using 28 wh/km, so 22% slower and 43% worse mileage.
View attachment 3

You can also do some fun stuff like see how fast the you'd get pushed from a tailwind alone, or just how little motor power is needed to go fast in a good wind, say like you'd have drafting a large vehicle.


You can also see the total futility of riding fast into a strong headwind. For instance to do just 41 kph into a 30km headwind (ie -30kph tailwind) I'd need to dump 2350 watts into the same hub motor, consuming an abysmal 56.8 wh/km.


If I then pedal my ass off pumping 300 additional watts into the wheel, it only increases the speed by 2kph. Meanwhile if I don't pedal but just crouch into a tuck position, the speed increases by almost 5 kph.

Patiently waiting for this "new" overlooked feature in the 2nd panel.
I tried and tried, even read current features AGAIN :lol: compared a few other things from orig.-sim to sim2 maybe my eyes went wonky due to looking at the sun for a very brief period. 8)

Well now you can go "how'd I miss THAT!"
Hopefully the wait was worth it.

 

[justin_le]

Well guys, it's now officially live as the main ebikes.ca simulator link, so anyone NOT wanting to see phase current limiting, wind speed, human watts, updated URL's etc. you are out of luck!

The URL fields now only update when you press the "simulate" button rather than at each time a parameter is changed, the URL link works with all motors rather than just those in the active motor list, there are a number of additional dropdown wheel sizes, there's a reset button to wipe the URL and clear everything back to defaults. We've also added the motor RPM as one of the cursor fields so you don't need to switch the 'X' axis back and forth between kph/mph units and RPM units.

But the main substantial update is that the motor simulator is now doing the same thermal modeling as we developed for the trip simulator app based on wind tunnel data, rather than the first order thermal model on the previous simulator which didn't take into account effects of wind and motor RPM on various core to shell and shell to ambient thermal conductivities.


Instead of a single field for "overheat in", there is now an additional field for the final predicted steady state core temperature too. The Overheat in point is the time it should take the motor to go from the initial motor temperature (as set by the motor temp slider) to 150 degrees celcius, while the Final Temp shows what the core is at after 2 hours of constant operation at that load point.

This has added a fair bit of additional processing overhead on the simulator since it can't solve these values in closed form and has to do an additional thermal simulation loop for each datapoint on the graph. People with slower computers might find a bit of lag after they hit the simulate button before the graph shows up, but on most modern machines it still feels responsive enough. It also means that temperature info is only shown for motors that have been thermally tested in the wind tunnel. Those motors for which we don't have this wind tunnel data will say N/A in the fields. Over the next few days I'll be making it so that you can select motors with and without Statorade in the dropdown list as now the simulator tool will be able to show a meaningful difference, not on the motor output curve but in the final temp and overheat times.

 

[thunderstorm80]

This is so awesome Justin.
The first-order heat transfer model was significantly incorrect at times.
I remember you said that the heat transfer model is for DD motors and not for geared. Is it still the case?

Here are my takes:
1. There is still a significant overheating time inconsistency between the Motor-Simulator and the Trip-Simulator in regards to geared motors. I got 9.5min on the new motor simulator vs 14min on the Trip-Simulator when testing with the ezee motor. If it's still only modelled for DD motors I understand - and in that case - can I rely on the results from Trip-Simulator?

2. What about adding the Phaserunner to the controller's list?

3. When modelling two motors and combining the thrust, the number figures get so high up the graph doesn't scale correctly:
http://www.ebikes.ca/tools/simulator.html?bopen=true&motor=M3525&batt=cust_82.5_0.1_20&hp=0&cont=cust_90_90_0.02&grade=10&mass=130&motor_b=MEZEE250&cont_b=cust_90_50_0.02&batt_b=cust_82.5_0.1_20&mass_b=130&hp_b=0&grade_b=10&add=true&blue=Lbs&wheel=29i&throt=100

4. Is Vancouver in Canada or in Texas?
I understand that when you combine two motors it's more meaningful to show the linear forces rather than torques, but why use obsolete imperial units such as "LibraForce" instead of KilogramForce or Newton? :lol:
If it will make your Southern neighbors angry, just allow to choose the units of measurement.

5. Even the newer motor simulator still doesn't allow simulation in most regen conditions, except in the scenario where you descend above the unloaded speed of the motor. In order to simulate the regen performance at lower speeds, one must change the battery voltage.
The Trip-Simulator is a much better tool for simulating regen at all the speed spectrum, but the Trip-Simulator works by steady-state basis. That's how it's designed to and it's fine, but it would be very useful on the Motor-Simulator if it was possible to get your deceleration values vs the speed you are at and the brake torque you request from the motor, just as they are accurate when accelerating. (As I said, currently for regen it would be possible only beyond the unloaded speed)
This is something which would be very useful for a person like me that has grades of 12% in his city...

6. Trip-Simulator related: I think the human-output should be automatically ignored when going downhill, otherwise it makes the calculations quite incorrect...
No one would pedal downhill on a -10% grade and at the same time apply a strong regen torque from a motor up to the plug-braking point. Well, most of us wouldn't
This can be solved easily by allowing the user to select a minimum grade, which below it the TripSimulator would assume human-power as zero. (for example for grades more negative than -2%. Some like to pedal downhill on a small grade against the wind for example)

 

[justin_le]

This is so awesome Justin.

Thanks! I also wanted to thank both yourself and Teklektik who suggested a lot of the ideas over the years which made it into this suite of improvements. It felt good to finally get them all checked off.

I remember you said that the heat transfer model is for DD motors and not for geared. Is it still the case?

That's true since we are dividing the motor into two distinct thermal masses, while in a geared hub there are 3 (the stator, the rotor, and the shell). But we can still do a reasonable approximation of the geared motor heating with this 2 mass model. You can see for instance that the MAC motors have a preliminary thermal model in them and have temperature prediction, but I want to do some further studies before I implement this across the board.

Here are my takes:
1. There is still a significant overheating time inconsistency between the Motor-Simulator and the Trip-Simulator in regards to geared motors. I got 9.5min on the new motor simulator vs 14min on the Trip-Simulator when testing with the ezee motor. If it's still only modelled for DD motors I understand - and in that case - can I rely on the results from Trip-Simulator?

You need be very particular in setting up the conditions on the trip simulator to match the same load point as the motor simulator. Did you set the motor temp slider from the default 60oC down to 25 degrees to match the same stating conditions as in the trip sim? Did you make sure that the motors are spinning at the same RPM, with the same wind speed, and the same phase current?
We find that it's usually consistent within a few degrees. One thing that the motor simulator doesn't do is update the load curve as the winding heats up over the course of the thermal simulation. In practice, as the motor heats up, resistance increases, and the phase amps will decrease at that particular RPM in the motor simulator graph (unless you are at a phase amps limited point of the graph). So there will always be minor differences from the different approach.

2. What about adding the Phaserunner to the controller's list?

Since both the phase current and battery current are not fixed but user configured, it didn't make any sense to have a default in there. Anyone with a phaserunner can just use a custom controller and set the phase amps and battery amps to match the settings that they've programmed into the PR.

3. When modelling two motors and combining the thrust, the number figures get so high up the graph doesn't scale correctly:

Ha yeah, that's true, I think that the graph scaling is still coming from the max of the larger of system A and B, rather than the sums of system A and B. I'll see that this gets addressed soon.

4. Is Vancouver in Canada or in Texas?
I understand that when you combine two motors it's more meaningful to show the linear forces rather than torques

Correct, we made it automatically switch to a thrust graph since there is no meaning to summing the two motor torques when they can have different wheel sizes

, but why use obsolete imperial units such as "LibraForce" instead of KilogramForce or Newton? :lol:
If it will make your Southern neighbors angry, just allow to choose the units of measurement.

kg isn't a proper unit of force, and newtons is not a number that feels natural to people. I guess the real reason is that in Canada we're still a bit of a mix, people measure their height in feet and inches, their weight in pounds, but their distance in km, speed in kph, and groceries are priced per kg, and I've been similarly influenced.

5. Even the newer motor simulator still doesn't allow simulation in most regen conditions, except in the scenario where you descend above the unloaded speed of the motor. In order to simulate the regen performance at lower speeds, one must change the battery voltage.

Yes, that is correct. You just change the battery voltage. There are a lot of reasons why this is unlikely to be changed but one reason has to do with the fact that there is no standard way that the controller's regen behavior is implemented or characterized. With a phaserunner it's easy (set the max regen phase amps), but all other controllers have their own unique regen amps vs velocity characteristic that depends on many factors.

The Trip-Simulator is a much better tool for simulating regen at all the speed spectrum, but the Trip-Simulator works by steady-state basis. That's how it's designed to and it's fine, but it would be very useful on the Motor-Simulator if it was possible to get your deceleration values vs the speed you are at and the brake torque you request from the motor, just as they are accurate when accelerating. (As I said, currently for regen it would be possible only beyond the unloaded speed)
This is something which would be very useful for a person like me that has grades of 12% in his city...

I hear you. And I'll give this some thought.

6. Trip-Simulator related: I think the human-output should be automatically ignored when going downhill, otherwise it makes the calculations quite incorrect...
No one would pedal downhill on a -10% grade and at the same time apply a strong regen torque

I do that all the time!

from a motor up to the plug-braking point. Well, most of us wouldn't

OK, you got me, not to the point of plug braking Anyways at the time we did this it came up in discussion and I chose to deliberately keep the human watts active during the entire trip run, since indeed many people do pedal while doing downhill with regen active, and anyone who doesn't can separately model the downhill section with 0 human watts if they wanted.

This can be solved easily by allowing the user to select a minimum grade, which below it the TripSimulator would assume human-power as zero. (for example for grades more negative than -2%. Some like to pedal downhill on a small grade against the wind for example)

That's true. We're not doing trip simulator work right now but in a couple months it might get a similar treatment, and it's own thread here on ES, and the removal of the -BETA descriptor.

 

[cycborg]

... people measure their height in feet and inches ... distance in km...

At the risk of wandering off topic, I visited Vancouver a few years ago and took a ride on the Grouse Mountain gondola. I got a laugh when I saw the promotional poster there which said the ride "ascends x feet in y kilometers" (don't remember the actual numbers). I'm sure a big reason these archaic units persist there is that you have to deal with us...

 

[justin_le]

... people measure their height in feet and inches ... distance in km...

At the risk of wandering off topic, I visited Vancouver a few years ago and took a ride on the Grouse Mountain gondola. I got a laugh when I saw the promotional poster there which said the ride "ascends x feet in y kilometers" (don't remember the actual numbers).

Indeed that's Canada for ya! We had a great metricization movement in 1970's but it didn't quite get to 100% before a conservative gov't canned things (see https://en.wikipedia.org/wiki/Metrication_in_Canada), still much farther than the US progressed in the same time period.

Anyways to steer somewhat back on topic, while I'm allowing of some imperial units where they are fairly firmly entrenched (like bicycle wheel sizes, 20", 24", 26" etc) and generally provide an option for miles or km since speed and distance familiarity is hard to shake, the line if firmly drawn when it comes to temperature readings. There's no way I can get myself to show degrees farenheit, either in any of these simulator web apps we're discussing here or as a temperature option on the Cycle Analyst. At some point if you are savvy and tech enough to want to understand what's going on thermally in a motor, you better know your way around the Celcius scale.

 

[justin_le]

3. When modelling two motors and combining the thrust, the number figures get so high up the graph doesn't scale correctly:
http://www.ebikes.ca/tools/simulator.html?bopen=true&motor=M3525&batt=cust_82.5_0.1_20&hp=0&cont=cust_90_90_0.02&grade=10&mass=130&motor_b=MEZEE250&cont_b=cust_90_50_0.02&batt_b=cust_82.5_0.1_20&mass_b=130&hp_b=0&grade_b=10&add=true&blue=Lbs&wheel=29i&throt=100

OK, this should scale properly now so that you always see the max power. If it doesn't, you just need to high cntrl + F5 to clear the browser cache of the previous simulation files


We also fixed a bug in the temperature predictions if you used the "KV Adjustment" slider, as this wasn't properly changing the winding resistance used in the thermal modelling part of the code as it should have been. That business all seems to work good now. However, in testing with your setup link I've realized that with geared motors that freewheel if you are going faster than the unloaded motor speed, even though all the electrical stats and power stats are correct at showing just the no-load amps draw, the wh/km consumption field is still assuming that the motor is in regen territory for some reason. It goes negative rather than staying above zero. Another minor update in order.


If anyone spots any other clear errors like this let us know while we're in the swing of things. I realize too looking at this graph above that we could and should still show system efficiency in the regen realm, rather than just forcing it to 0%. There is a small window just after the unloaded rpm where you have negative mechanical power but positive electrical power and efficiency is not defined, but after that when both motor + battery powers are negative we should show the number again.

 

[thunderstorm80]

2. What about adding the Phaserunner to the controller's list?

Since both the phase current and battery current are not fixed but user configured, it didn't make any sense to have a default in there. Anyone with a phaserunner can just use a custom controller and set the phase amps and battery amps to match the settings that they've programmed into the PR.

It's true, but the effort to simulate a Phaserunner's behaviour is exhausting when it's the interface is in "Grinfineon" form:
The throttle slider is useless when you use a phaserunner, you should allow a "Phaserunner mode" where your slider changes from throttle slider to phase-current slider.
Without that, you need to go to "custom controller" and change the phase-current value for each simulation and it takes a long time.
I would have liked to see also a separate slider for regen phase current, which can allow simulation with the PR during regen.
When you have such "Phaserunner" mode, simulating regen conditions would become very simple, instead of the currently only above the unloaded speed. (Also, instead of brake-drag, you will see the acceleration/declaration which is pretty useful and neat!)

4. Is Vancouver in Canada or in Texas?
I understand that when you combine two motors it's more meaningful to show the linear forces rather than torques

Correct, we made it automatically switch to a thrust graph since there is no meaning to summing the two motor torques when they can have different wheel sizes

, but why use obsolete imperial units such as "LibraForce" instead of KilogramForce or Newton? :lol:
If it will make your Southern neighbors angry, just allow to choose the units of measurement.

kg isn't a proper unit of force, and newtons is not a number that feels natural to people. I guess the real reason is that in Canada we're still a bit of a mix, people measure their height in feet and inches, their weight in pounds, but their distance in km, speed in kph, and groceries are priced per kg, and I've been similarly influenced.

But hey, you just said on your latest message that you would never allow "F" to measure temperature, since someone who understands motor temperature behaviour is a person who prefers SI units. Like you said: "You better know". It goes the same for Libra-force. Libra is not a unit for force. Newton is. It's a simple multiplication between the total vehicle mass and the acceleration - both shown in on the simulator in their SI units, so it's just as natural for it to be the unit of thrust, and can be directly understand rather than how many Libras (The original model masses in some UK palaces) are accelerating and how fast.

5. Even the newer motor simulator still doesn't allow simulation in most regen conditions, except in the scenario where you descend above the unloaded speed of the motor. In order to simulate the regen performance at lower speeds, one must change the battery voltage.

Yes, that is correct. You just change the battery voltage. There are a lot of reasons why this is unlikely to be changed but one reason has to do with the fact that there is no standard way that the controller's regen behavior is implemented or characterized. With a phaserunner it's easy (set the max regen phase amps), but all other controllers have their own unique regen amps vs velocity characteristic that depends on many factors.

Like I said above - if you allow "Phaserunner mode", you have solved all those issues, AND, allow us to have a phase-current slider which is much more intuitive for PR users.

6. Trip-Simulator related: I think the human-output should be automatically ignored when going downhill, otherwise it makes the calculations quite incorrect...
No one would pedal downhill on a -10% grade and at the same time apply a strong regen torque

I do that all the time!

from a motor up to the plug-braking point. Well, most of us wouldn't

OK, you got me, not to the point of plug braking Anyways at the time we did this it came up in discussion and I chose to deliberately keep the human watts active during the entire trip run, since indeed many people do pedal while doing downhill with regen active, and anyone who doesn't can separately model the downhill section with 0 human watts if they wanted.

I totally disagree, for the reason that the Trip-Simulator is meant to work along with Google-maps and Anallogger data. You aren't supposed here to split your trip to several parts and model them separately... If you have to do so, than why do I need the map or the Analogger data here?
I will use it, for example, to plan a long-distance journey where I would prefer to save my energies on downhills: Working against a loaded motor downhill in such case, even if it's far from the plug-braking zone, is just a totally wasteful approach: You just dump all the extra human power here to copper losses, and move the motor to a lower eff zone so you actually lose more than what you input with your legs.
Remember that battery's energy density is still the major drawback for long distance tours, and only few of us would want to simulate a human-power also on downhills.

This can be solved easily by allowing the user to select a minimum grade, which below it the TripSimulator would assume human-power as zero. (for example for grades more negative than -2%. Some like to pedal downhill on a small grade against the wind for example)

That's true. We're not doing trip simulator work right now but in a couple months it might get a similar treatment, and it's own thread here on ES, and the removal of the -BETA descriptor.

I look forward to see that happen!

I will now comment on your recent post:
I think you should allow a toggle switch to allow regen for geared motors or not. If not, it should freewheel and be modelled like it used to be. With the growing interest in geared motors without freewheels, I think we reached the time that this should be allowed. It will also solve that Wh/Km problem you talked about.

Another suggestion I had, for two systems comparison mode:
If you can toggle a switch that will match the thrust output of both systems rather than "throttle slider", you can then directly compare which motor is more efficient and which one will overheat quicker, etc....

 

[justin_le]

Well, one last item that was on the long to-do list is a mode where the the throttle level is automatically set to the level that would achieve a given steady state speed, so speed sets the throttle rather than throttle setting speed. It happens very often that people move the graph cursor left and right to see the behavior at different speeds and get perplexed that at higher speeds their energy consumption goes down, while at lower speeds the consumption goes way up, without realizing that they are looking at points of transient behavior. The right way to see low speed behavior is to reduce the throttle percentage, which is explained in the FAQ text, but that seems to be seldom read)

Now there is an "auto throttle" checkbox option, and when this is selected if you click the graph to move the cursor to a new location, then the throttle level is iteratively recomputed to a value that results in this steady state speed instead of showing you the transient data:



You can use the checkbox to enable or disable this feature and I'm curious to hear feedback from others on it. The computations haven't been fully optimized yet so there is some extra delay in this mode, but the hope is that it would make it easier for people to appreciate the overall system behavior at various speeds. If you click a speed faster than the max steady state speed for the motor then the cursor will be clamped at the max, while if you click below the speed that your human power alone will achieve then it will increase to the human power only speed.

 

[amberwolf]

FAQ text,

What's a FAQ? We have to read?

Now there is an "auto throttle" checkbox option, and when this is selected if you click the graph to move the cursor to a new location, then the throttle level is iteratively recomputed to a value that results in this steady state speed instead of showing you the transient data:
<snip>
You can use the checkbox to enable or disable this feature and I'm curious to hear feedback from others on it.

It's definitely an improvement over manually messing with the slider to get the speed one wants to simulate, especially with a two-motor system. Definitely useful for me. No glitches yet, that I've noticed.

I do notice that if in A/B mode, if you switch from compare to add, it will set both throttles to 100% and move the speed line. Switching back doesn't go back to how it was, either--it leaves both at 100% and puts the speed lines where they would be for each system. Manually moving the speed line back to where I had it causes autothrottle to set correctly again.


Something that would be interesting, although I don't know how much use it would see, is a torque control throttle, where you set the Nm/ft-lbs instead of speed. This would remove the Net Thrust line from the graph and replace it with a speed line.

Similarly a power throttle, where you set the watts instead of speed. This would remove the Net Power line from the graph and replace it with a speed line.


Both can be done manually, fiddling with the regular throttle and speed line until they show the torque or watts you want, but it's not quite the same.




BTW, are there any "simple" aero simulators one can sketch a basic shape and get a rough CdA/Cr out of? I realize any numbers that come out of such a simulation could be wildly off from reality due to flaws in the sketch, but it might still give a rough idea of directions to go in for improvements to aero with quick changes to the sketch.

I know there are ones that take a full cad shape and work with it, but it's a fair bit of work and time to build full models.

 

[justin_le]

[
It's definitely an improvement over manually messing with the slider to get the speed one wants to simulate, especially with a two-motor system. Definitely useful for me. No glitches yet, that I've noticed.

Well there's definitely a small glitch in that the simulator doesn't currently support 0% throttle settings, so when you click the graph below the min speed achieved by human power only it ends up choosing some arbitrary low throttle which is high enough to still show a plot.

Something that would be interesting, although I don't know how much use it would see, is a torque control throttle, where you set the Nm/ft-lbs instead of speed. This would remove the torque line from the graph and replace it with a speed line.
Similarly a power throttle, where you set the watts instead of speed. This would remove the watts line from the graph and replace it with a speed line.

This is similar to what thunderstorm was asking for with a phaserunner controller mode and I think we'll add this to this list. So when you choose a custom controller you can choose if the throttle control is a PWM (ie voltage) throttle, a battery current (ie power) throttle, or a phase current (ie torque) throttle. If nothing else it would also help enormously in explaining the nature of these different throttle modes and make it easy to generate graphics to illustrate the difference; when we explain why for instance you might want to use a CA3 as a current throttle instead of pass-thru etc.

Consider it on the nearterm list!

BTW, are there any "simple" aero simulators one can sketch a basic shape and get a rough CdA/Cr out of? I realize any numbers that come out of such a simulation could be wildly off from reality due to flaws in the sketch, but it might still give a rough idea of directions to go in for improvements to aero with quick changes to the sketch.
I know there are ones that take a full cad shape and work with it, but it's a fair bit of work and time to build full models.

I'm not sure that there is much value in doing a simple 2D sketch for CdA modeling since airflow around any vehicle is very much 3 dimensional. Are there sites that you have found which let you upload 3D cad files to get aerodymanic drag predictions? I always thought that level of modeling was still only available in expensive FEA packages. One thing that's on our long-long-term sights is to develop on online tool that would attempt to extrapolate CdA and Cr coefficients from logged ebike trip data that includes GPS and CA power consumption info, along with a basic knowledge of the motor details. Such a tool already exists for regular cyclists with a powermeter device here:
http://www.fastaerolab.com/Home/Analyse

And in principle you could do a reasonable extraction of this info from the logged power consumption of an ebike on a known terrain.

Here's another good site with info on actual numbers for bicycle air drag coefficients,
https://www.cyclingpowerlab.com/CyclingAerodynamics.aspx

Like most studies in this nature the focus is very much on race cycling, while there isn't much to guide initial values on say cargo bikes, longtail bikes, fatbikes etc. or other common ebike platforms.

 

[Alan B]

Excellent improvements.

I was thinking of a mode where the horizontal axis was throttle, and every point on the graph was therefore valid steady state operation. It would take a bit longer to compute, but it would show efficiency correctly at all speeds.

 

[justin_le]

Excellent improvements.

I was thinking of a mode where the horizontal axis was throttle, and every point on the graph was therefore valid steady state operation. It would take a bit longer to compute, but it would show efficiency correctly at all speeds.

I don't know about having the horizontal axis being the throttle setting, but leaving it as a speed axis and having the throttle computed to the steady state throttle for that speed would be very cool. So basically the entire plot would be a steady state plot, with the motor power curve exactly following the load line curve minus the human power offset. At the moment it would require a radically different approach to the motor computation sequence versus what we're doing now, but it should in principle be possible to do this in a way that it would compute the entire sequence just as fast.

I really like this idea and will keep it in mind, since that would really be the best way to have in just a single graph image the performance map of a given setup versus speed, and would reallly help dispel this "peak efficiency" misunderstandings that are frequently perpetuated about always wanting to ride at close to the unloaded speed.

It's a rather different graph altogether, and I could see showing things like Wh/km as a graph plot rather than just as numeric data in that case. I'm gonna mull on this, thanks for the suggestion Alan!