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

[swbluto]

Mine heads towards 100% as you approach the no-load speed and then it crashes to negative infinity at the no-load speed(no motor power output, in other words), whereas ebikes.ca's simulator seems to approach optimal efficiency shortly before the no-load speed and then takes a sharp curve downward. I've heard that the closer you are to the no-load speed, the better the efficiency, so maybe my calculation is more accurate? :lol: ).

Seems like it's not factoring in the no load torque? The curve should start to turn down at around 10% of no load speed, for BLDC motors.

I was going to take a closer look at that. It doesn't directly do the Torque = I*k - (windage_torque and other counteracting torque which ebikes.ca does a second order approximation on) calculation, but it's a direct mathematical recreation of the CA's simulator torque curve when the only resistance present is in the motor and there is effectively no battery-current limit. So assuming *that* torque curve factored in the windage torque(and what not) already, it seems like further calculations based on that should remain equally replicated. But it doesn't(Just fairly accurately so for most parameters over the normal operating range)...

Custom values don't even account for the windage torque and motor cogging, though, which can be important(The effect is usually negligible, until you start calculating efficiency near the no-load speed.). The problem mainly is that it requires "special tools" to directly measure, which most potential users don't have, and manufacturers/retailers don't be seem to be keen about giving this data. Maybe this can be inferred from the "no load current" that's sometimes given by retailers/manufacturers? Are there any known "motor cogging and windage torque" relationships or rules-of-thumb that'd make it simple to estimate?

Eh. It just seems like this data can't be too easily found by a normal user(Including me, rofl).

 

[swbluto]

Hey, Tostino, how do you add scrollbars to the existing panel(Just for those who have their resolution too small)? I tried adding the existing panel to a scroll-bar panel but that messed up the underlying code somehow(and entirely messed up the layout): I didn't upload it, so I just re-downloaded the previous revision and now I'm back at square 1.

 

[michaelplogue]

Not to bust in on the programing conversation here, but I have a question.
Would it be possible to include chain drive motors plus a front & rear sprocket field so those of us working with non-hub motors could use this great tool? I would think that you would be able to use the same system for both types of motors. You would just put a 1 in both the front and rear sprocket field if you were calculating for a hub motor. You could then also include pre-set data for the most common motors like Etek-r and RT, Perp PMG-130, Lemco's three motors, Some of the D&D and even some of the RC motors that folks are using now.

Just a though.....

.

 

[swbluto]

Not to bust in on the programing conversation here, but I have a question.
Would it be possible to include chain drive motors plus a front & rear sprocket field so those of us working with non-hub motors could use this great tool? I would think that you would be able to use the same system for both types of motors. You would just put a 1 in both the front and rear sprocket field if you were calculating for a hub motor. You could then also include pre-set data for the most common motors like Etek-r and RT, Perp PMG-130, Lemco's three motors, Some of the D&D and even some of the RC motors that folks are using now.

Just a though.....

.

Hehe. It already does via the "gear ratio"(I think that's only in the unreleased version, though, which I don't think I've uploaded.), but if it's not apparent enough, I didn't do a good-enough job - So, changing it so that you enter in the front and rear sprocket value(or whatever else) sounds like a perfectly able and really easy thing to do and it'd make it a lot clearer which makes it far easier to use. So, no problem, I'll add that(I was thinking about the "easiest"/best way of asking for the gear ratio and that sounds like one of the easiest.).

Do you know if there's a database of popular motors and their values, though? I could go hunting down these values to add the motors to the list(or create a new list), but I don't really know what the "popular motors" are and I'm sure there are hundreds of different types of suitable motors out there.

 

[michaelplogue]

Here's a few of the larger motors that to get started with. I honestly couldn't say which of the RC motors are common.

Perm PMG-132
resistance: 0.025 Ohms
50.2 rpm per volt

Perm PMG-080
resistance: 10 milli-ohms
285 rpm per volt


Etek-R
resistance: .033 ohms
72 rpm per volt

Etek-RT
resistance: UNK (might be .033 ohms, but can't find any reference yet)
51.4 rpm per volt


MARS BRUSHLESS (PMAC Motor)
resistance: 10 milli-ohms
70 rpm per volt


Magmotor S28-400
resistance: .042 Ohm
204 rpm per volt

 

[tostino]

I think I have a solution to the motor stats issue. Lets not hard code them into the program, but instead have it read an external file for motor name, winding resistance, and k. That way users can keep the program up to date with commonly used motors even if this program does end up un-supported in the future.

Umm I will look into adding a scroll bar to the program, and will post up some instructions when I find out how to do it properly.

Also on a side note, I think there is an issue with the efficency calculation when adding in pedal power. It seems pretty accurate without it in the equation, but with it, everything seems to go out of wack.

 

[swbluto]

Ok, I'll see what I can add.

Anyways, I'm now adding wh/(distance) consumption and range boxes that'll be contingent on battery capacity(provided by user). This will be the TOTAL WH/mi., which includes the energy used by the battery due to internal resistance.

 

[swbluto]

I think I have a solution to the motor stats issue. Lets not hard code them into the program, but instead have it read an external file for motor name, winding resistance, and k. That way users can keep the program up to date with commonly used motors even if this program does end up un-supported in the future.

That sounds fine(Sounds a bit neater as well). I think adding another column to the array(or whatever data structure) to indicate "hub motor" would be helpful for cluing in the program that it's hub motor or something else. How would the file be read in applet form, though? I thought applets couldn't... like... obtain an ordinary server's resources unless it was hosted on a server environment that allowed it(I think I may just eventually host it on a specialized host, with TomCat(or whatever), anyways just so adding the GnuPlot graphing back-end will be an easy port.).

Anyways, I'll check out the efficiency formula in greater depth. I thought it seemed pretty accurate with the latest revision, but I'll check that specific concern later after coding in the range, wh/mi consumption, and sprocket's code.

 

[swbluto]

Also on a side note, I think there is an issue with the efficency calculation when adding in pedal power. It seems pretty accurate without it in the equation, but with it, everything seems to go out of wack.

I just checked out some sample input and it seems to "operate as planned". Can you provide more exact symptoms? Possibly a screen-shot and/or a few pertinent numbers that are thought to be out of whack.

(The problem is is that it doesn't take into account windage torque or cogging torque and so its efficiency doesn't drop dramatically near the no-load speed like ebikes.ca's, so the current algorithm just assumes the RPM at 85% of the no-load RPM is where the peak efficiency is located which may be off by 7% or so from the true peak efficiency. Between 85% of the no-load RPM and the no-load RPM, it does a linear extrapolation towards 0 efficiency at the no-load RPM. To get the windage and cogging torque would require motor-specific knowledge, that doesn't appear easy to get without specific measuring tools, or some semi-accurate "guesstimate" which I don't have enough knowledge to guess on.)

 

[tostino]

Hrmm. I am not liking the front/rear sprocket to calculate gear ratio at the moment. My motor runs through a jackshaft, than down to the bottom bracket, and through the 21 gears. I am thinking about doing something like I did to calculate "K" down below for the front and rear sprocket to get the gear ratio.

Any objections?

 

[swbluto]

Hrmm. I am not liking the front/rear sprocket to calculate gear ratio at the moment. My motor runs through a jackshaft, than down to the bottom bracket, and through the 21 gears. I am thinking about doing something like I did to calculate "K" down below for the front and rear sprocket to get the gear ratio.

Any objections?

Weeeeeelll, this program was hoping to be designed to accommodate the greatest range of users as possible without too much clutter for the greatest range of users, so I was thinking there could be an educational link about calculating the "front and back" sprocket value for different arrangements to conform(I don't personally like that idea, though, as it doesn't make it easy enough for everyone) or, possibly, instead of creating special calculating boxes for every possible unique configuration which would be many, I'm guessing(I've seen a few!), perhaps a combo-box that allows the user to choose their particular configuration and then the appropriate boxes appears dependent on the selection? This would help keep down the clutter while retaining versatility.

In that spirit, what do you think about using radio boxes to allow people to choose to use K or Kv for the current K box? I think it'd help increase the amount of screen-space available which has becoming rare as of late. :lol:

 

[swbluto]

I think I should incorporate armature temperature as part of Miles' suggestion. This link has an excellent explanation, but is it really linear? The explanation "This means if the temperature increases 1°C the resistance will increase 0.393%." would suggest R_f=R_o*(1.00393)^(change_in_temperature).

Program development update: units added to the right of the boxes to easily indicate the units being requested. I can't update it now since my laptop can't connect to the internet in my current location(Won't be able to upload it until around 5-6 hours from now).

 

[Mathurin]

Kreuzotter gives funky results when you go near absolute zero:

 

[swbluto]

Okay, here's a preview! it's a stand-alone application and you also need the Java Runtime Environment installed for your system to make it work. It's not completely organized and some tooltips need to be updated, but the barebone functionality seems to work great so far. I just haven't fixed the "too high of a tail-wind" problem which can cause inaccurate answers and it's likely to give wrong answers if you go too much faster than the "no load speed" since I doubt it accurately captures the motor's back-current too-far into the regen region and the corresponding power. You'll know you're in the no-load region if the efficiency says "0" percent. Anyways, the variables explanations can be found on the first page I linked to in the original post.

Edit: It appears you can't upload .jar files; I'll post as a file link later.

OK, here it is. And, yes, this is also vulnerable to the temperature ~= absolute zero attempts. I *might* add in more advanced error-checking later, but I trust those worthy of using this program in its current state should be able to operate it fine(Given the caveats above).

 

[swbluto]

Ok, I found out why it doesn't work on macs. It's because macs are stuck back in JDK 1.5(it's latest one currently available for the mac, officially.) which doesn't include the swing library. To download the program with the needed libraries, I've packaged it away in this zip file and it just needs to be extracted so that the folder structure is preserved.

Edit: I've deleted it since it apparently doesn't work.

 

[voicecoils]

Ok, I found out why it doesn't work on macs. It's because macs are stuck back in JDK 1.5(it's latest one currently available for the mac, officially.) which doesn't include the swing library. To download the program with the needed libraries, I've packaged it away in this zip file and it just needs to be extracted so that the folder structure is preserved.

Still no luck, error message is:

===== Wednesday, 22 October 2008 9:11:45 PM Australia/Sydney =====
Exception in thread "main" java.lang.NoClassDefFoundError: javax/swing/GroupLayout$Group

Running OS X 10.4.11, supposedly Java 1.5 should be all ready to go, I'm not sure how to check this however...

 

[swbluto]

Hmmmm. Well, the only other possible action that I think I could take to correct this problem is to convert the whole program to java 1.5 technology. While that wouldn't have problems with the program's "core", that would require a lot of effort to revert as the whole program was built around Java 6 technology with Apple being the only major system that doesn't seem to support it. Until I get my hands on a mac so I can do 1-on-1 testing(Which probably won't happen), I'll have to delay my efforts to get it working on mac-based systems for now. Sorry macsters!

Edit: I think I found the solution. I'll have to implement it later and see what happens(I probably won't have access to a mac until tomorrow, if then.). In the middle of the exhaustive conversion, I'll try to ensure there's scroll bars built into the pane and... I might abandon swing technology altogether(for applet interoperability, although I may be wrong about swing library's incompatibility with applets.) which will get rid of that "Native look and feel", but that's not entirely a goal of mine anyways: The current version doesn't seem to have Window's "look" . Anyways, I'm not expecting anything substantial to change for at least a week.

 

[swbluto]

Before I proceed with mac-conversion, could I have a mac user test out the following file? I want to make sure it's right before investing a ton of time. The folder structure must be preserved for it to work correctly, that is if it were to work correctly.

 

[voicecoils]

Before I proceed with mac-conversion, could I have a mac user test out the following file? I want to make sure it's right before investing a ton of time. The folder structure must be preserved for it to work correctly, that is if it were to work correctly.

This is what I am seeing:

 

[swbluto]

That's good. Does one of the buttons serve as an "exit" button? They all seem the same color.

 

[voicecoils]

That's good. Does one of the buttons serve as an "exit" button? They all seem the same color.

(from left to right) exit, minimse, maximise. They highlight when you mouse over them. They all work w/ your window as well

 

[swbluto]

That's awesome!

Anyway, here's the skeletal structure of the program with scroll bars and menu items. If someone on a mac could test it out and could PC testers test out the scroll-bar, that'd be great! Once I get an OK on this, I'll add the code that'll make the menu items work and the labels more realistic(And everything else). That could take anywhere from a day to a week.

 

[voicecoils]

That's awesome!

Anyway, here's the skeletal structure of the program with scroll bars and menu items. If someone on a mac could test it out and could PC testers test out the scroll-bar, that'd be great! Once I get an OK on this, I'll add the code that'll make the menu items work and the labels more realistic(And everything else). That could take anywhere from a day to a week.

Lookin' good
Drop down menu works, seems fine. So do top and bottom scroll bars.

 

[swbluto]

Awesome! I just got done with the duplication and the only thing that now needs to be duplicated is the tool-tips. I might start adding those sometime in the near future.

Anyways, currently planned features include design/parameter optimization and graphing capabilities. I suspect I might get design/parameter optimization done within 4-7 days and the graphing part done in 2 weeks to a month(I need to learn how to use the graphing engine! ). Design/parameter optimization basically is... "I want to optimize this "green box" feature varying *this* parameter". For example, you might want to know how to get the top speed with the right gear-ratio and you can tell it to automatically find it. Or you might want the top-efficiency varying the gear ratio. Or really anything. More complicated versions of design optimization might be the varying of multiple parameters or wanting to optimize multiple "green box" predictions or adding constraints(Like, say, efficiency must be above a certain percentage). By the way, I still need to include the no-load-current so the efficiency can be accurately calculated.

And, for all those who use netbeans, the "align" option makes alignment SO much easier if you know how to use it. I just learned how to and it's amazing.

 

[swbluto]

Newest update:

A Kv option was added on and so is the no-load current! Now efficiency and heat generation can be calculated accurately!

This thing is being made so that now any single PM-motor powered vehicle can be accurately calculated! The only thing that now needs to be calculated is the hub motors. Does anyone happen to know where the no-load currents can be found on those?

Anyways, the calculations for efficiency were based on www.aveox.com/dc.aspx, an electric motor manufacturer.

Also, I'm planning on reverting back to the original gear ratio box and offer a versatile gear-ratio calculator based on the set-up chosen.