You are right, I should have added that.

Wait, wait, wait, I'm only changing the (fully static, so no ESC shenanigans) timing setting, are you guys telling me that from that, I could somehow get the approximate torque curve?!?

The only information I have at the moment is the max RPM (from the ESC), nothing else. Notably, I don't have the current, but I suppose I could get an ammeter and get that one relatively easily?

Now you've got me thinking a bit more. I don't think I was correct in saying it was necessary to know the number of turns or the winding style. Both Kv and Kt are directly related to the total enclosed magnetic flux, which is in turn dependent on the number of turns and the winding style. So I think that this would fall out of the calculations, and we would be left with needing only Kv and the resistance.

Yes, but as Jebarus stated it would only be approximate. All of our banter is based on a very simple motor model. That model implies that if you advance the timing, and the Kv increases, then the Kt decreases by the same amount, leaving the peak power output constant. We know that this is not true, and that's why we want to make a dyno!

The above implies that we can get an approximate optimum timing advance curve, where the optimum timing is that which gives a free-running speed of double the instantaneous speed of the motor. It's a good place to start.

For the benefit of other people following this thread, I repost my test results here:

http://i.imgur.com/tLzRMa5.png
http://i.imgur.com/FT41WPm.png
http://i.imgur.com/BxVzeve.png

The fit is not perfect, but it is the best I could do using such a simple model:

http://i.imgur.com/kND526I.png
http://i.imgur.com/nswC63T.pnghttp://i.imgur.com/4ySeqmY.png

I used the following constants:
KV: 800 (experimental)

Kt: 0.0119 N.m/Amp (derived from KV).

Req 0.3116 Ohm. (Experimental fit, actual resistance of one (phase) coil measured on our dyno: 0.1633ohm)

b: 7.3795e-008 N.m.s (Could be neglected)

I0: 0.33A Small effect, mostly important for correct efficiency at no load.

Consequently, Kv and Req are really the minimum, but as you can see the fit is not perfect, which is why you need a dyno for precise measurement.

If the motor is Y-wound, and "phase" means "coil", then these numbers are actually quite close; the ESC "sees" the motor terminal resistance, which is two coils in series. That's only about 5% difference.

Of course... Right now, my timing advance curve is purely based on guesswork, so even these completely theoretical torque curves are better than nothing! :lol:

I either still don't understand where the variations in efficiency (which cause the change in peak power, right?) come from, or I did back we exchanged when I was writing my articles, and now I forgot. ;)

I'm not sure of what you mean by the "instantaneous speed" of the motor?

In any case, I've got a train journey this weekend, I'll be playing around with gnuplot, see what this gives me. I tested the free-running RPM of my Reedy Sonic M3 10.5T motor for every 10°, from 0° to 90° yesterday (went from 12,500 to 69,000!).

I think I also discovered that my Reedy Blackbox 410R ESC might have a built-in limit of 60° to the dynamic timing it will apply, and I believe (but need to confirm) that other ESCs might not be so "shy"... Some people run their motor with 10-20° of static timing, but use 70-80° of total dynamic timing (hitting that maximum only briefly, on the straight, of course!). My attempts at similar setups tended to leave me behind on the straight, being good everywhere else, that limit might explain it.

I'm trying 30° of static timing tonight, and I'll ramp up the dynamic timing progressively to see how that goes, but now I'm wondering if this isn't too much timing at low RPMs... Hence my attempt to at least get a rough idea of the actual torque curves of my motor, to see how wrong I am. ;)

That would be simply the motor speed at any given point in time. For instance, if the motor is at 10000 RPM, then the dynamic timing should apply the timing setting that gives 20000 RPM with no load; if the motor is at 20000 RPM, then the dynamic timing should apply the timing that gives 40000 RPM at no load. Since the motor's peak power output occurs at 1/2 of the no-load speed, this will keep the motor generating maximum power regardless of its speed, much like a Continuously-Variable Transmission (CVT) would do. And just as a CVT has its limits for minimum and maximum ratios, we have our limits for timing advance-- namely, zero degrees minimum (for maximum torque) at stall, to X degrees maximum, where X is probably determined by efficiency considerations.

But you are already familiar with this, as shown in your excellent articles on motor timing!:
http://www.rctech.net/forum/radio-el...y-boosted.html

LOL! Yeah, I didn't get what you mean by "instantaneous speed", because I got confused by the "free-running speed that's the double", for some reason (I usually think of that spot as "half the free-running speed"). Silly me. :)

No, what I mainly meant when I said that I didn't understand is the reasons why there are those variations in efficiency when changing the timing, why the peak power isn't constant when changing the timing (just moving at what RPM it gets delivered), that sort of stuff...

It's time for a status report!

The SimpleDyno software has been giving some curious results. The shape of the power curve and the location of the power peak are quite a bit different than expected, and multiplying the reported torque and speed does not equal the reported power; I can scale the result so it is correct at one speed, but using the same scale at a different speed results in a power discrepancy. I have posted questions on the SimpleDyno forum, but have yet to receive any responses.

As a result, I did some further simulation work, which has revealed that my original guess at the number of revolutions for getting (what I consider to be) accurate readings was very conservative. I used a spreadsheet to generate an exponential curve for the velocity versus time during spool-up (which assumes zero losses due to friction and drag), and then calculated the time between each integer revolution of the motor. The time between each integer revolution of the motor simulates the data that will come from the actual motor and flywheel. I then used a simple linear interpolation for calculating the values of velocity, acceleration, and mechanical power output from the motor.

It turns out that a flywheel large enough for the motor to spin up in just ten revolutions will give calculated power results repeatable to better than 0.06%. In other words, the power calculated at the ninth or eleventh revolution (since we don't necessarily know at what angle the motor starts at) is within 0.06% of the power calculated at the tenth revolution.

The simulation also showed that the calculations require a very precise measurement of time between revolutions: a 1us change in the measured period corresponds to about 0.1% error in the power calculation. This does not bode well for SimpleDyno, because it uses the PC's microphone input to gather data, and the maximum sample rate is 44kHz (about 23us period). So it looks like I may need to create a little microprocessor gizmo to time the motor revolutions and send the results to the PC, where they can be processed in any manner desired.

I went back and read what I just wrote... The requirement for such precise measurement of time between motor revolutions got me very concerned about using gears, since they necessarily add some play/backlash in the system, and this could affect the time measurements. Direct coupling of the motor to flywheel would eliminate this concern, and maybe reduce the number of parts necessary to make the dyno, but also adds the interesting design problem of supporting the motor shaft so it won't whip about (or break!), while maintaining alignment and contributing little friction.

For a direct connection that can withstand some slight misalignment, what about speedometer cable or power seat cable with aluminum collars with set screws at both ends for attaching to the motor and cable? Speedometer cable may be harder to come by than the power seat part since it's been quite a while actually seeing one of those on a car.

That would certainly take care of misalignment, but I fear that the time data would be severely skewed due to twisting of the cable. 1us of time doesn't equate to much angle at these speeds; it's about 0.05 degrees at 8000 RPM. I'm guessing that the cable would probably twist at least an order of magnitude more than that.

I was thinking something similar to a third-bearing clutch support on a kart, with a solid connection between motor and flywheel, but with restriction on radial movement and wobble.

But first we will need to see the if the data from many runs with the gear reduction shows undue scatter, or if all of my worries are unfounded!

I still use the slave motor set up, I prefer a brushed motor as the s motor witj a voltmeter to read RPM. The most important part is the coupler (Make one if you can find one, do not use fuel tubing . It needs to be metal with grub screws) It then will be much more accurate

Tom

True. On top of that, the amount of twist as the motor ramps up would also probably not be consistent between different motors. A u-joint or CV joint could allow some slight misalignment and if kept to a minimum, maybe it would have a negligible affect on the results? Not sure how much the speed up/slow down effect would be if kept mostly straight.

Not familiar with that, but after looking at some pics, I think I see what way you are thinking. Using the bracket and bearing for a fairly frictionless middle support and alignment. The coupler at that point could possibly be an aluminum tube with the center drilled the size of the shaft(s) and set screw to tighten. The fun part would be getting the motor mount plate centered.

Keeping my fingers crossed. As before, you have me intrigued again with one of your projects. I really need to work on my electronics knowledge.

I'm liking this idea a lot! If the flywheel shaft and motor shaft are nearly collinear, then the losses and rotational error from just a simple dogbone would be negligible. And it eliminates the need for the very critical alignment of the third-bearing arrangement. It's time to start digging through the drivetrain parts!

Something like this?

http://www.euronet.nl/users/tooms/frituur/frituur4.jpg

http://www.euronet.nl/users/tooms/frituur/frituur6.jpg

http://www.euronet.nl/users/tooms/frituur/frituur15.jpg

I am busy with something else and made a short CVD shaft with 2 (standard) clamps to connect an engine to an electrical drive w/o a precise alignment.

Yes, that's the idea, Roelof!

That's very nice machining! I'm currently looking for some off-the-shelf pieces that will work.

I have lots of data from the Eagle Racing MD2 dyno if that helps anyone wanting to build a dyno. What's needed to make the MD2 dyno better is higher sample rate (it's only 50hz) and more accurate current/voltage measurement. If the sample rate was increased to say 500 hz with a larger flywheel you would really have something.

I really like the idea of a geared dyno. At least it keeps the flywheel RPM down and if you are using it to do your own comparisons errors due to gear friction would be irrelevant since you would use the same value for all tests. Apple to apple. I would expect the loss to be less than 5% for a single gear mesh but that's just a guess. A 1:1 drive with a much larger flywheel would also be good but the RPM for a low turn motor with boost would be terrifying. The MD2 dyno shuts off at 30000 RPM and that's a good thing IMO.

One thing to note is the torque output of a brushless motor is not linear particularly at higher timing settings. I have spent lots of time researching modeling DC Motors and you can get good agreement with a simple model for brushed motors. With brushless motors at higher timing settings all this goes out the window. If you look at the Silver Can graph below you can see the torque output is reasonably linear. Then look at the Orion Motor and you can see as the motor timing is increased the Torque output becomes much more non-linear.

Thanks for the excellent input and data, Bob!

I intend to count the time between successive revolutions to a resolution of at least 1us, which would be equivalent to sampling at 1MHz; anything less than that will not give me the accuracy I desire.

For the moment, I won't be doing any current measurement, so I won't be able to determine efficiency. But my main interest is determining power output vs timing.

I agree that gearing can keep the flywheel to sane speeds, and also reduce aerodynamic power losses (which increase as the cube of the speed). But I still need to establish that the data won't be compromised by the gear lash.

On another note, I have acquired a nice switching power supply (Meanwell RSP3000) which is adjustable over the full range of voltages equivalent to 1s through 3s LiPo. This should reduce voltage droop to negligible values during a run. But it does require 220V, so I need to unplug the clothes dryer if I want to run the dyno!

Scotty we need More power!!!!!! Crazy to think you need to use 220V to simulate a Lipo Battery.

Personally I prefer using the Lipo as the power source since that is what we use on track, voltage droop and all. When I create a model in RC3 I include the effect of battery internal resistance, wiring and ESC on resistance when creating the model. That way once the model is created I can just change the battery Internal resistance to zero and see the effect. The attached graphs provide a comparison between a typical Lipo pack with a total internal resistance of 20mOhm to an ideal voltage source with zero internal resistance hence zero voltage droop. Static voltage for both is 8V. The performance difference is huge in the lower RPM range and becomes progressively less as the motor current drops.

The thing that would concern me with the power supply is the initial current draw. It will be significantly higher than with a Lipo so it will certainly put more stress on the ESC. As you can see in this example of a 13.5T motor the initial draw goes from 150 to 250 amps. While it will be a short duration I would be cautious so you don't let the magic smoke out.

The point of the power supply is to eliminate the effects from using a battery, not to simulate the battery. My goal is to understand the motor behavior, and this is easiest when all of the variables that can be eliminated are eliminated.

I'm sure power supplies exist that will do what I want and still operate from 120V, but (as usual) I bought the cheapest one, which happens to need 220V.

By the way, can your program accept data from a flywheel dyno-- specifically, time to each successive revolution? I'm now busy writing code to send this data to a serial port. While I can process the data in a LibreOffice spreadsheet, it looks like your program has a bunch of useful features that may not be available in a spreadsheet.

The torque and power curves for the Orion look pretty gnarly above 15000 RPM, so I wouldn't draw any conclusions from the data. It definitely looks like the MD2 isn't nearly accurate enough up there. And the flat top on the power curve for file1 says it isn't accurate enough at lower speeds, either. Or are these artifacts from other processing of the data?

Sample rate is only 50hz so a lot can happen in .02 sec when the motor acceleration is high at the start. I do some linear averaging on the recorded data to help smooth out the results so sometimes you get a flat top. I normally do three consecutive runs to make sure the results are consistent. As I said earlier higher sample rates or slowing the acceleration by using a larger flywheel would help the MD2 but not solve everything. The MD2 is far from perfect but then what can you expect for $150.

I am still planning to get some larger flywheels made which will increase the number of samples at lower RPM and should help improve the accuracy. I look forward to seeing your results with the high sample rate. Should make for some interesting comparisons. If you share some data with me I'll process it through RC3 for you to compare with your torque and power calcs.

Are you measuring RPM directly off the motor terminals or using an external encoder or hall effect sensor?

I'm taking data from one of the motor's internal Hall sensors. I'm hoping they will be accurate enough, but they are awfully close to those coils, so there may be some skew depending on current draw.

Here's a status update for you kids!

I finished a first pass at the code for the data acquisition module, to measure the time to each successive motor rotation on spool-up. The module uses a PIC12F683, the same processor as I used for my transponders. It runs on a 20MHz crystal, so it does 5MIPS, and the internal timer is also clocked at 5MHz, giving it 0.2us resolution. That should be plenty! The code is arranged to capture the timer value for 16 consecutive sensor signal falling edges after the initial edge, convert the times to decimal, and spit them out on a serial port (done in software, since this processor doesn't have a UART). The data can then be processed on a spreadsheet (I'm using LibreOffice).

I initially tested the timing jitter using my "good" Siglent digital signal generator. The jitter was acceptable when sampling a 1kHz square wave, but when I went down in frequency-- giving longer periods to time-- the jitter increased. I checked the code and could see no reason for this, so I decided to swap out the signal generator with my old Madell analog generator. The jitter was much improved! I'll attribute this to the digital signal generator using a wavetable, with the pointer into the wave table not having enough resolution.

For further testing, I created a simple crystal-controlled 1Hz timebase generator, and the jitter is very good: the deviation is one count (0.2us).

Here is the data for the different signal sources:

http://i1191.photobucket.com/albums/...psoagct8hh.jpg

And here's a look at the 1Hz timebase generator (for which I temporarily borrowed my servo driver case and circuit) on the left, and the data acquisition module on the right. There's not much to either one!

http://i1191.photobucket.com/albums/...psz8leuabt.jpg

I did a few runs with the data acquisition module on a geared flywheel, and an ungeared flywheel (from my old Robotronics dyno). It appears that my fears of the gear lash affecting the data is well-founded; as you can see below, four runs on the geared flywheel resulted in quite a bit of noise in the power curves:

http://i1191.photobucket.com/albums/...ps5ywglu6g.jpg

In contrast, the curves below, for the ungeared flywheel, are much cleaner. There is a chance that at least some of this is due to the lower MOI of this flywheel, so I'll need to check again with a "beefier" flywheel.

http://i1191.photobucket.com/albums/...psf1tinwpt.jpg

anyone thought about using an arduino nano for data logging? (not even sure it can write to file) the arduino has lots of inputs/outputs and is TINY in nano format and runs on 5V....

I think that most of the Arduino boards would be great for this! I even have an Uno here that I have never used, and I might give that a try sometime when I need something to keep me busy. The only reason I used the PIC is because there is no learning curve for me.

The Arduino boards already have a USB port on board, which I assume can be used to dump data to a PC (after it is used to program the board). That would eliminate the need for an RS232-to-USB cable.

My telemetry system is based on an old datalogger and yes, people are telling me I could program it to make it work with the software of my telemetry system. Sadly I am no hero with an Arduino....

But looking arround there is something like an Arduino scope, it is an 6 channel oscilloscope
http://kll.engineering-news.org/kllf...p?article_id=8

Now that we are through the holidays, it's time for another status report!

I think I have found a suitable flywheel. It is a Gates V-pulley, #37360. It has an O.D of 2.75", and a width of about 0.62", with a 1/2" bore, no keyway, and a single set screw to lock it to the shaft. The V-pulley shape is not quite optimal, since mass is removed and surface area added near the edge, where velocity is highest. It is, however, cheap-- $9 shipped!-- and has good availability.

I also purchased a selection of shaft couplers and adapters to connect the flywheel to the 1/8" motor shaft. Unfortunately, all of them had substantial runout and/or wobble. My highest hopes were for the Master Airscrew prop adapter, #MA3200, which has a pretty accurate O.D. that matches the pulley bore (though this is not guaranteed the same on all adapters), but it also had a bunch of wobble. While runout and wobble between the 1/8" bore and the 1/2" diameter around it is not important in its intended use, the excessive runout and wobble is also present at the surfaces where the prop attaches, and that is disappointing. It's probably time to talk to my buddy that owns a CNC lathe!

Since I still wanted to take some data with the direct drive flywheel, but don't yet have the heavier one ready, I went back and did some runs with the one from my Robitronics dyno, but with resistance added in series with each motor terminal to reduce the motor power and increase the spool-up time. About 45 milliohms extra on each terminal of the 21.5T motor moved the calculated power peak to around the eighth revolution. Four successive runs showed about 0.36% total variation in the calculated power, so I'm definitely on the right track to getting the repeatability results I want!

After some thought, I have realized I can get more data from a single run by monitoring all three Hall sensors in the motor, and use this to enhance the repeatability (i.e., reduce the noise levels) of the data. While the alignment of the sensors in the motor is not nearly accurate enough to get useful information from the time between their signals, we can still process the data from each sensor independently (as if we had done three separate dyno runs to get it) and then average the results as a final step. (There may also be other information available from the sensors-- for instance, is the data from one consistently "noisier" than from the others?-- but that remains to be seen.)

To this end, I have ordered some PIC16F1825 microprocessors. The PIC16F1825 has enough pins to bring in the three sensor signals, enough memory to store the extra data, and dedicated capture/compare/PWM hardware timing "modules" for up to four signals. Since there are only three motor Hall sensors to monitor, the fourth module will generate the signal to control the ESC during a dyno run, eliminating the need for a servo driver or transmitter/receiver.

The PIC16F1825 is from a newer family of designs, so I also needed to order a new programmer for it. Of course, the data acquisition software needs to be changed to accommodate both the new microprocessor and the new functionality, and I have finished a first pass at this.

I have also changed the LibreOffice spreadsheet to accept the data from all three sensors.

News on the flywheel: I have been communicating with a machinist about machining a hub for the Gates V-pulley, or perhaps even creating the entire flywheel as a single piece. We'll try to keep the cost reasonable for those of you who want to make your own dyno!

It's time for another update!

Here is a photo of the data acquisition board with the new microprocessor. It runs at 4MHz, which gives a resolution of 1us on the sensor timing. The program now gathers data from all the sensors, and for 80 motor revolutions to give more information at high RPM, which makes it easier to estmate the maximum RPM via extrapolation. The toggle switch selects the correct pulse width when calibrating the ESC, and the push button starts a dyno run.

http://i1191.photobucket.com/albums/...psewki4z3f.jpg

Here is the system connected to the motor and ESC. The resistor bank makes the motor spool up slower since I'm still using the Robitronics flywheel. Unfortunately, the heavier flywheel is still in limbo. :cry: If anyone wants to machine one, let me know!

http://i1191.photobucket.com/albums/...ps18qd8vhn.jpg

Here is a screen capture of the updated spreadsheet. In addition to expanding it to accept data for 80 revolutions from the three sensors, I also re-arranged the graphs to get velocity on the X axis. As you can see, the torque and power curves are quite smooth, with the data for the three sensors very nearly superimposed on each other. The peak power occurs at almost exactly 1/2 of the free-running speed, which is reassuring. At the moment, none of the values are scaled to any particular units.

http://i1191.photobucket.com/albums/...psyysbiiuw.jpg

Hi all

here is my experimental stand-alone dyno based on a single arduino mini-pro board running at 16Mhz.

https://lh5.googleusercontent.com/-M...0-no/plant.jpg

https://lh3.googleusercontent.com/-9...0-no/curve.jpg

The photos are a test with an old rc car brushed motor.
The aluminium flywheel, with six optical sensing holes, is of about 50e-6 kgm^2.
The current/efficiency graph is yet missing; work in progress.

That's beautiful, augu!

New commercial dyno on the block, looks quite nice!

https://www.miniprousa.com/collectio...540-motor-dyno

Now that's a nice looking dyno.

Howard,

Have you thought about using a load cell / strain gauge in conjunction with a flywheel to directly measure torque? This way you dont need a high accuracy to calculate the flywheels second moment of inertia and also no need to accurately time its acceleration.

All you'd need is a load cell (lever mounted off motor housing) and a hall effect sensor on the flywheel to obtain rpm. With a simple 2 channel logger, you can easily obtain torque, rpm = power.

Maybe use an extra 2 channels to log amperage and voltage to obtain electric power, so you can use that to calculate mechanical efficiency at any given rpm.

http://i.ebayimg.com/images/g/seAAAO...Nl/s-l1600.jpg

http://www.ebay.com.au/itm/100g-Elec...kAAOSwImRYXQNl

http://www.ebay.com.au/itm/YZC-191-W...3D301706904557

http://www.ebay.com.au/itm/2-2-lbs-1...ro_PfdDOXo7Atw

I definitely want to stay away from the complexity of these extra devices. The beauty of a flywheel dyno is its simplicity. Another big plus is that a run can be done very quickly to avoid heating of the motor.

Accurate timing is much easier than any other measurement, and I've already made the data acquisition system to do it, as you can see from my previous posts.

On another note, I've recently obtained a flywheel of the correct inertia, thanks to Benjamin Fenton and a friend, so the next order of business is to make a proper support for the motor/flywheel combo.

Its not complex... and it is not changing your flywheel design... it just adds to it. All it does is allow you to measure torque directly as apposed to deriving it from acceleration... That will not be accurate. All rotating mass (including armature) will affect your result. A strain gauge is by far more accurate.

Also I dont think getting precision rpms is that simple... especially when you consider its high speed (30k+ rpms) and achieve peak power in less than a second.

I find it pretty hard to believe that motor dynos cant be bought any more. Surely there is something available out there (besides the ripoff mc crappy racing)

http://www.rctech.net/forum/attachme...ronic-dyno.jpg