New Open Source E-Bike/E-vehicle calculator & simulator

[swbluto]

Awwwwww, thanks for the appreciation and your welcome. To tell you the truth, I had a grandeur vision of this tool being widely recognized and used but I'm no longer delusioned. It seems it has evolved into something that's meant more for "designers"(Including amateurs, like myself!) than the casual electric-bike-shopper and so that's probably limited its broad appeal. That and it doesn't seem easy to port to an online format without heavy bandwidth costs.

I've actually committed a cardinal sin of technological nature: I've stopped adding to its evolution, so it'll probably wither away while advanced species / new software comes to take its place. I plan to open the source, but I need to take the time to copy and paste the open-source licensing agreement and getting the necessary documents. Another time.

[methods]

I have spent many thousands of hours working on things that no one ever even looked at.

I understand what you mean.

-methods

[mikebikerad]

this would be a great tool to show people that are just getting into Ev's some basics. You should include a section where you determine the % of time spent in aerodynamic tuck position.

[Doctorbass]

Nice work Swbluto,

I've used it and i'm so surprized about how it is accurate comparing to the real world test!!!

Thanks.. it'a a very usefull tool for me and my crazy lab!!

Doc

[methods]

yea... I have been thinking about why it is not really catching on.
I must admit I have only used the tool once. It was very accurate. I just punched in some numbers that I was familiar with and Bam - got my Ah/Mile right on the money.

I find myself using the simulator on ebikes.ca quite often even though it usually wont give me exactly what I want.
I end up playing silly games to extract whatever data I need.

A lot of it is the online convenience aspect.
A good deal of it is "old habits die hard".
The software is also a bit intimidating. It has quite a few options. That is not really an excuse though because it only took me a minute to figure out how to use it without reading any sort of directions.

I think the biggest reason that I have not used the software is because my 5305 blew up like a week after I found this thread and I was in a funk for months

I am going to make an effort to move a copy to my work computer (where I am always desperate for distraction ) and spend more time getting familiar.
I have received news that my monster motor is almost done. Astro 3220 with hall sensors and all 6 phase wires popping out
I will be wanting to do some simulations and I can guarantee that I wont find what I need for this setup with the ebikes.ca simulator.

I am excited to start working on a new project with a proper set of tools.

-methods

[steveo]

Hey everyone

Someone should stickify this thread .. this is a excellent calculator!

Maybe a mini manual would be helpfull to understand all the options!!

-steveo

[pdf]

OK. So I came to the party late. However, this calculator provides a very useful function that I have not found elsewhere with all its pieces integrated together as they are here.

I have several questions, if anyone is following this thread. It looks like the no-load current, motor resistance, and "K" value uniquely specify the different motors. Does anyone know what order approximation this is? Where did the program author come up with these values for the included motors? Is it as simple as measuring these values for a motor? I only know enough about electrical power/motors to be dangerous.

I am working with a group of university undergraduates who are, in essence, designing a small two person commuter vehicle, most likely based on hub motors. They are interested in extending the program to some different motors that have come out since the program was written.I have suggested they use this tool to help select appropriate motors and batteries.

So the program lives on. I, for one, encourage the author to keep up the good work.

[swbluto]

I have several questions, if anyone is following this thread. It looks like the no-load current, motor resistance, and "K" value uniquely specify the different motors. Does anyone know what order approximation this is? Where did the program author come up with these values for the included motors? Is it as simple as measuring these values for a motor? I only know enough about electrical power/motors to be dangerous.

It is. The internal resistance is a constant depending on temperature (You can adjust the armature temperature in the calculator), the kV is a constant that determines the torque constant, and the no-load current summarizes the "no-load" losses of the motor like the cogging torque, eddy losses, bearing losses, etc.. In real life, the losses will be less than the no-load losses as the losses are a function of motor RPM and you're unlikely to go the no-load RPM in real life, but the effect of that will be minimal on most predicted values. However, since the no-load current is a function of RPM, it will change depending on how fast the motor will spin which usually changes with higher voltages. With the hub motors I have quoted, I believe that was derived for voltages of 36 volts and higher voltages will entail a higher no-load current than what's suggested. The custom option lets you change whatever you think may be different with your particular situation.

If you want to get much more precise with each individual loss and performance characteristic, first, you'll have to make the variation in product quality much lower than it already is. If you have the motor, you can measure it.

[Miles]

If you want to be precise, you have to measure a motor with a specific controller & set-up. Also, the way that controllers simulate the effect of voltage change, makes a difference to the real world performance at partial throttle settings.....

[swbluto]

If you want to be precise, you have to measure a motor with a specific controller & set-up. Also, the way that controllers simulate the effect of voltage change, makes a difference to the real world performance at partial throttle settings.....

Indeed. The simulation doesn't take into account "timing advances" or any controller pecularities, it's just modeled as a voltage drop (of a diode) and simple resistor and simple linear PWM behavior. Despite that, though, it's been within 10% accuracy for many members here. If you don't have a motor, I suspect you'll get larger variation from the motor itself than the controller behavior as I believe most brushless motors are made by hand and they're not "precise", it seems. Many HXT motors seem to have true kV values that deviate within 10-20% of the stated value (it's usually higher).

[pdf]

Thanks for the reply.

I only know a little about motors and power, but do tinker quite a bit with various things. I am working with students with very little practical experience (as much of a paradox as it might seem, such is the current nature of the majority of even engineering students). The "K" value is obvious and I suspect easily available from a manufacturer. A few questions about other parameters:
1) Is measuring the "motor resistance" as simple as putting a meter across the windings? I am working with a group of students writing a proposal to fund the building of an electric vehicle and we don't currently have any motors to test. I know only the very basics of brushless motors, but I understand there are multiple windings and that the motor is made to rotate by cycling the current through the windings, which is timed by sensors in the motor to determine where the rotor and stator are relative to each other. So what resistance is relevant? They are, presumably, in parallel to each other but only one is active at a time so I am assuming the resistance of a single winding is the relevant resistance.
2) Same basic questions about no-load current. Do you simply run the motor through an ampmeter or a clamp meter and check the current through one set of windings? Would this not vary with the voltage applied if the resistance is fixed?
3) Is a manufacturer likely to communicate this information?

A 10% good number for speed and power required are more than sufficient. Actually, that degree of accuracy would be highly unusual with such an easy-to-use simulator in my line of work (chem. eng. reserach) and would be highly welcomed.

The reason for these questions is that we don't have a large budget and don't want to do a lot of costly experimentation with different motors, so the simulator will be a primary tool for limiting motor choices. If motors are rated by the vendor in terms of power, it is probably a highly subjective measurement since one has no idea how the number was determined and if it is max power, continuous, etc. If we could boil the motor parameters down to a small set of quantifiable values like those required by the simulator, we could at least see at what conditions the power ratings are reached and then make a judgement about if a motor from a particular vendor is likely to run continuously at that power or if not, try to judge for how long the motor might stand up to it. We are building a vehicle for a hilly area and while the distance for which the vehicle is being designed is not long, it is a series of hills and not a flat drive. Because our budget is limited we want to make an appropriate choice. In particular, the students seem excited about the offerings by Golden Motor, esp. the heralded "MP"; GM sells motors rated at 1000W at 48V much cheaper than about any other vendor I have seen, but I don't know what that power rating means. As we expect to need on the order of 1500W peak for times on the order of a minute, if that figure is continuous, that is probably fine. If it is peak power or close to it, it will not work. Now I know there is a good deal of positive and negative sentiment on this board with respect to GM, but if we had some objective numbers that quantify the motor design, we could judge for ourselves what to expect. Some of their larger motor designs have some potentially useful characteristics for us so we don't want to eliminate their products out of hand based only on negative PR. However, we do need to be mindful of "due diligence" and do what work we can up front to be sure our selections are likely to be approproiate choices.

Thanks for any help.

[patrickza]

I've also been kept up nights playing with this toy. I find it to be almost exactly spot on with what I find in the real world. Have you plugged in the 5306 data yet, I've been toying with the idea of getting one, but I'm curious to see what the differences would be compared to my 5305.

[justin_le]

I have several questions, if anyone is following this thread. It looks like the no-load current, motor resistance, and "K" value uniquely specify the different motors.

This is more or less true in the case of DC motors or brushless motors where the L/R time constant is small compared to the commutation period, and so for the Crystalyte motors with just 8 or 12 poles it is good enough. But as the commutation period gets closer to this time constant, as we see with the 23 pole NC motors, and especially with the 80 effective pole (16 x 5:1 gear ratio) of the eZee/BMC motors, then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

You can try and 'hack' the simple model above by increasing the resistance so that the torque/RPM slope better matches what is measured over the RPM range of interest, but then you end up with the model showing a worse efficiency and higher input power than you would measure in practice, even though the output power is close.

Justin

[justin_le]

then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

To illustrate this point, the graph below shows how you would predict the performance of an eZee motor at 48V/20A if using only the motor constant 'K', the winding resistance, and the no-load current as your motor model:

Predicted eZee motor at 48V, using model that doesn't take winding inductance into account

eZee graph no inductance.gif (22.45 KiB) Viewed 1145 times

Meanwhile, the actual data matches much more closely with the graph below, which has exactly the same parameters for R and Kv but where the effect of motor inductance and commutation events are taken into consideration:

eZee 48V 20A simulator curve with inductance modeling

eZee graph with inductance.gif (22.12 KiB) Viewed 1141 times

Compare the predicted power output at 40 kph, the winding inductance reduces the output watts by more than a factor of 2. But at really low speeds, where the commutation period is significantly longer than the L/R time constant for the motor windings, then the two graphs converge and ultimately show the same stall torque.
-Justin

[swbluto]

then the winding inductance has a very large effect. A model that is based only on motor resistance and 'K' will show much higher power and torque values at speed than you would measure in practice. This gets more and more pronounced the higher the RPM that you are simulating at.

To illustrate this point, the graph below shows how you would predict the performance of an eZee motor at 48V/20A if using only the motor constant 'K', the winding resistance, and the no-load current as your motor model:

eZee graph no inductance.gif

Meanwhile, the actual data matches much more closely with the graph below, which has exactly the same parameters for R and Kv but where the effect of motor inductance and commutation events are taken into consideration:

eZee graph with inductance.gif

Compare the predicted power output at 40 kph, the winding inductance reduces the output watts by more than a factor of 2. But at really low speeds, where the commutation period is significantly longer than the L/R time constant for the motor windings, then the two graphs converge and ultimately show the same stall torque.
-Justin

Thanks for the illustration. I was recently under the impression that the caveat you brought up affected performance in the region of 5-10%, but it certainly seems to be fairly important.

By the way... can you tell me how the "commutation" period is so long at low speeds?

It seems obvious that the phases are activated for longer periods of time at lower RPM, but it also seems that you're encountering PWM at the lower speeds due to current limiting. Is the "commutation period" of the PWM waveform not particularly important (Once current limited has deceased at higher speeds, the PWM disappears and the phase waveform becomes the only one existent), and it's mostly just the phase current's period?

[justin_le]

Thanks for the illustration. I was recently under the impression that the caveat you brought up affected performance in the region of 5-10%, but it certainly seems to be fairly important.

Yes, well the level of importance really depends on the motor and RPM under question. But when the inductive impedance of the windings at the commutation frequency starts to reach the same order as the ohmic resistance, then the effect can be very significant, and as illustrated with the geared eZee/BMC motors it is more than a factor of 2. If you look at an oscilloscope trace of the waveform, the current never comes close to leveling out at the value predicted by (V-emf)/R. It is still ramping up when the commutation event takes place, then it takes a big hit during the commutation as the current steers away from one phase to the other. The graph here shows a Nine Continent motor spinning at 510 RPM, with both the actual drive voltage when the controller is on (pink) and the back-emf voltage when it is off (green) showing. The blue line is the phase current when the controller is on.

BLDC Motor Waveforms.jpg (38.88 KiB) Viewed 1708 times

Notice how the current through the phase is always ramping upwards? With a sinusoidal motor driven by a 6-step controller as is the case here, we would expect the current waveform to look a bit like a 'w', but here it is a 'w' on a pretty big slant.

By the way... can you tell me how the "commutation" period is so long at low speeds?
It seems obvious that the phases are activated for longer periods of time at lower RPM, but it also seems that you're encountering PWM at the lower speeds due to current limiting. Is the "commutation period" of the PWM waveform not particularly important (Once current limited has deceased at higher speeds, the PWM disappears and the phase waveform becomes the only one existent), and it's mostly just the phase current's period?

I think on my 6th read over that I see what you're getting at! In the context above, by "commutation period" I just meant the time period between one commutation event and the next, not the actual time duration that it takes the current to switch over from the non-driven phase to the newly driven phase. The actual time required for the commutation to take place is dependent on a) the current through the windings, b) the inductance of the windings, c) the back emf voltage, and c) the supply voltage.

I'm completely ignoring PWM in all of this, it's not part of the equation at all. At PWM frequencies the winding inductance is assumed to be for all intents and purposes infinite, and that approximation seems fine.

-Justin

[swbluto]

Ok, I've gone through the steps for licensing and dedicating an SVN space to the open source movement. This software is now GPL licensed and ready for open sourcing to allow improvement or modification to the software by anyone who wishes to contribute. All improvements and derivatives must be open source under the same license as part of the terms for GPL licensing.

The SVN is http://svn2.assembla.com/svn/ebikecalculatoropen .

If you just want to browse or have a look around the space, the url is http://code.assembla.com/ebikecalculato ... sion/nodes .

Here's the directions for developing this.

This project was built using the NetBeans IDE for the GUI Builder and code editing and JDK 5 to maintain compatibility with Mac Systems. It also uses JFreeChart in order to create graphs and all those cool things.

What I would suggest is find JDK 5 as offered by Sun, download it bundled with netbeans and install it. If you want to contribute to the above project, please send your email address to me and I'll add you as a member to the group so that you can add to the project directly, otherwise you can check it out anonymously and create a derivative work. After installing it, checkout the project using the subversion feature of netbeans and, if you wish to contribute directly, add your member login info there. Once you've checked it out, make sure to add JDK 5 so that the project can use it and find and download JFreeChart-1.0.11 from sourceforge and add the libraries to Java's lib folder, and add to the folders to the project inside netbeans. After that's done, you should be able to compile and edit the project freely and you would commit changes to the source code by right clicking the project and clicking commit.

Some things that might be desired to change/add

-Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

-Add in a motor current limit so that motor-current limited controllers like Kelly controllers can be accurately simulated.

-Modify it so that it'd be possible to use more than one motor in the same drive-train. That honestly sounds like a lot of work to keep relatively simple.

-Include a drive-train loss box so that one could include drive-train losses into the simulation. A percentage may be the most intuitive.

-Add in inductance so that high inductance motors can be accurately simulated in the high RPM range.

-Get rid of the antiquated efficiency linear-interpolation code for hub motors, since the efficiency calculations now work.

...Some superficial things for maintainability reasons...

-Capitalize the "Final Int" variables to distinguish it as a constant used for the general motor's data array for array item access.

[swbluto]

Just changed the title.

[damcard]

it doesn't seem easy to port to an online format without heavy bandwidth costs.

Bandwidth should be minimal. I could see doing this app two ways to get it online. I could do either one fairly easily and would be glad to so I can loose my "lurker" status.

The first is with servlets and a html form via jsp's. The bandwidth would be comparable to any simple web application. Infact, it would only have a single main form with a few popups. The charts themselves are fairly small. Do people use the zoom functionality in the charts? The issue here is you would need a servlet engine such as Tomcat to run it. But it would work for limited devices like an Iphone.

The second would be to port the whole thing to actionscript3 (flash). For this application I would prefer to do that. The cool thing doing it that way is all the graphs could be dynamically updated as you change values in the form. It would be the most responsive. You could serve it from any web server as static content such as in a post on this forum. All the calculations and graphing would happen on the client. The bandwidth would be small as the user would simply download the swf and not interact with the server anymore. The downside is you need the flash player use it. For normal web browsers, its not an issue. But, it would not work on limited devices such as an Iphone.

Is anyone interested in making this a web application?

[wshi]

Ok, I've gone through the steps for licensing and dedicating an SVN space to the open source movement. This software is now GPL licensed and ready for open sourcing to allow improvement or modification to the software by anyone who wishes to contribute. All improvements and derivatives must be open source under the same license as part of the terms for GPL licensing.

The SVN is http://svn2.assembla.com/svn/ebikecalculatoropen .

If you just want to browse or have a look around the space, the url is http://code.assembla.com/ebikecalculato ... sion/nodes .
.....

Well done! I would like to checkout and have a look. What's the username and password for read only access anyway?

[damcard]

Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

How were you going to do this exactly? Would you have a folder with the files it could load? That is, where would the csv files be held? A form could be used to load custom csv's I suppose. If it is a hosted app or if it connected to a service I could see how users could add motors.

I ported Motor.java to Flash(as3). I will finish up the others once I can get read access to the repository and check out the entire project. Thanks -David.

[swbluto]

Quick response.

It appears they classify two types of people:

"watchers" and "members".

Under permissions for each type of the above user, they offer "read", "edit" and "all". Currently, watchers have read access and members have edit accesses. If the "watchers" category doesn't allow checkout, then I don't know how to offer anonymous access without also offering the ability to commit. It appears that checkout is tied up with commit abilities.

So if anyone has any insight into what can be done to allow anonymous checkout without commit abilities, please let me know.

[swbluto]

Ok, I've created a watcher and maybe watchers will be "special" since they have a password.

Username: anonymous_1359
password: anony

This user has read access which might allow checkout, methinks.

Hmmmmm... it appears I changed something relevant because it seems eclipse checked out the project without a user logon, while also not presenting the commit option. It appears "anonymous checkout" has been somehow enabled.

[swbluto]

Change the built in 2d array for the motors so that it can read that information from an external CSV spreadsheet or some other database. This way, the motors can be added in the future without requiring compiling the program and so anyone could add motors to the motor database.

How were you going to do this exactly? Would you have a folder with the files it could load? That is, where would the csv files be held? A form could be used to load custom csv's I suppose. If it is a hosted app or if it connected to a service I could see how users could add motors.

I ported Motor.java to Flash(as3). I will finish up the others once I can get read access to the repository and check out the entire project. Thanks -David.

I have no idea how a csv would be situated.

I was just thinking of a simple comma-separated-value(csv) sheet that contained the motor database. Basically, each line contains a distinct motor, and each comma separated value is a distinct value (Motor Name, kv, resistance, io, whatever else.). If you're creating it online, you could connect it to whatever database schema you want, with maybe something like mySql.

[wshi]

Have you looked at Google code project hosting? It's pretty cool and support SVN.

http://code.google.com/opensource/