While it might not give an accurate reading, you can still get a precise one (as in, repeated measurements give you the same result), and this is sufficient to tune a given motor, optimizing the dynamic timing advance of your ESC to maximize power output, say.

There's this one now, looks good, but not cheap (and Howard prefers a direct flywheel, without belt/gears): https://www.miniprousa.com/

It is more complex than you realize. If the strain gauge measures torque during the spool-up, then it must read the torque at almost exactly the same times as the RPM is measured in order to calculate the instantaneous power at each data point. Coordinating the simultaneous measurement of both RPM and torque is much more difficult than simply calculating the torque from the exact same data points used for the RPM calculation, where the data is intrinsically simultaneous.

Another big problem with the strain gauge is its frequency response. It needs to be free of mechanical resonances (which is problematic, since it is a spring!), and the bridge amplifier must have sufficient frequency response to make negligible the settling time to a value within the required error band.

Given all of the above, I'd say the strain gauge will likely be less accurate (and certainly less repeatable) than calculating torque from acceleration. Calibrating the calculated result to any given units might be more bothersome. But, as Mr. Phaneuf stated, that step isn't necessary to tune a motor, or compare motors.

It seems simple to me, since I have already done it. There is virtually no hardware required: the motor's existing Hall sensors, and one counter inside a microprocessor. Every other way of doing it seems more complicated.

Yeah, I saw that link before.

The good thing about the belt drive is that since it has some elasticity, it will help to filter out any vibrations or intermittent accelerations... or perhaps one would want to see that for diagnosis purposes.

Though I'm not really liking their design. Especially the motor mount. And for the price... its pretty impractical and unrealistic.

I was actually going to use my (automotive) engine data logger to capture the data points.

With a big enough flywheel, I dont think discrepancies in data latencies would be of much concern. My 2 variables would be torque and rpm. Yours would be rpm and elapsed time. I think your issue may be with your data loggers resolution when taking so many data points in such a short period of time.

However you have a point with mechanical resonance... but thats still going to be an issue regardless. You can only dampen that with a larger flywheel and an external damper on the strain gauge.

Personally speaking, I just wanted to obverve torque directly, not calculated indirectly.

The strain gauge method is still very doable. Its pretty much industry standard for automotive engine dynos (w/ water brake)

The other alternative to a strain gauge to avoid its spring like harmonics is to use a different kind of load cell instead. i.e. compression instead of bending

Something like this:

https://lh3.googleusercontent.com/-_...oAssembly1.JPG

https://endless-sphere.com/forums/vi...=36803&start=0

As I stated in previous posts, I'm taking a total of 240 data points. Each has a resolution of 1us.

I'm guessing that your automotive logger operates as a sampled system, as most loggers do. Then the concern is: What is the sample rate? If the sample rate is 100Hz, then the time resolution is 10000us. That's useless for a flywheel dyno.

What kind of load cell are you referring to? They are all essentially springs with means to measure deflection, or active force-balancing designs (e.g. electromagnetic "voice-coil" types) with means to measure drive current or voltage.

http://au.omega.com/subsection/minia...oad-cells.html

Not all strain gauges rely on measuring deflection. Some use variances in the dielectric properties of the material when placed under mechanical stress. Since I'm only a mechanical engineer, not electrical, sensor operation is not really my expertise.

you could also utilise rubber joints to absorb some more vibration too

As I said before, the sample rate is somewhat irrelevant with a large enough flywheel and directly measured torque + rpm

You are correct! That's the old Setra patent stuff. I completely forgot about it, which shows just how long it's been since I designed scales. (I did that for 13 years!)

Again, correct, although once the flywheel gets to a certain size, it would be more expedient to just make a brake dyno. Keeping the flywheel as small as possible reduces the problem of motor heating, which is always a problem with our RC motors on brake dynos.

A brake dyno in theory works... however 2 machines will never be calibrated the same. The levels of friction vary to much, and not to mention heating of the friction material causes more inconsistencies. It worked back in the day without computers. Now days a water brake is used instead... however I don't think that could be scaled down to our application. It would be hella cool though ;)

Regarding motor temperatures, I see it as a good point. As it will give you a better understanding of how the motor will behave under heavy load. You wont be making pull after pull as that would be unnecessary. I believe there is enough thermal mass in the motor, wires, heat sinks and a solid metal frame to make this negligible.

Hi all

I made some improvements, now measuring current, voltage and efficiency.
Some problem of noise remains.

Attached images: new display view and measure setup.

That's beautiful!

How many data points or what sampling rate are you using?

Graph has about twelve points, equispaced in rpm. Sampling is interrupt driven.

... about twenty points, pardon. The limit is the memory.

Inertia will only affect the spin up time of the flywheel. Couple things it could be, correcting RPM for your pulley ratio or the voltage you are testing at. Image below is a 13.5T motor tested with 2S batt, direct drive flywheel (inertia is 63 gm-mm2). Hope this helps.https://cimg4.ibsrv.net/gimg/www.rct...8dcf25251b.png

If you want email me a data file I'll see if I can process it. Send it to [email protected].

Maybe take a close look at your pulley system. Pullies are notoriously inefficient. It may seem small, but compared to direct drive, and the fact you are looking at high rpm may be a factor. Also double check where inertia is used in your power calculations. The reflected inertia of a flywheel is affected by the square of the gear ratio. With a 2:1 ratio, that would mean the inertia observed by the motor shaft is 1/4 the flywheel inertia. Use Google and the search term "reflected inertia" to see the concept (if you are unfamiliar), and to check my work.

Hobby Motor Inertia Dyno
 

Hi guys! I would like to know what you think about the Hobby Motor Inertia Dyno by MiniPro, as far as analysing and setting up you motor. I have been involved with nitro engines the past 20 years and now trying to find my way in electric 1:10 off road...
Thank you for your time!

The sampling rate on the MiniPro is far too slow. This results in raw data that is very noisy, which severely compromises accuracy.

Take a look at post #73 in this thread. It shows a graph of raw data using a sampling rate that is many orders of magnitude higher than the MiniPro. As you can see, the data is very smooth and free of noise. If you find a graph of raw data from the MiniPro, it will show so much noise that the graph will be unrecognizable. No amount of data smoothing will fix that.

Let me start by saying 20 samples per second on a rc car dyno is enough but should and could be more. it does calculate efficiency and plots current as well so it has that going for it. But what I would like to ask is what does a power curve do and how does it help?

from a mechanical power perspective these electric motor applications spend close to no time at peak power or peak efficiency. So how does a power curve help? Serious question. you probably have the ability to explain it in terms that other rc enthusiasts can understand.

the car accelerates 10 times for every 1 time it hits peak power. I don’t have nefarious intentions but there is a concept i’m working towards a step at a time. I’m not trying to unveil heat or efficiency as some proof of intelligence but it is the constraint that can be quantified in simple terms with the right skipper giving directions.

Digging up and old thread here since it seems like a better place to post the stuff I have been working on. I have also been using the Simple Dyno software even though the developer no longer supports it. I use an Arduino to record the RPM, voltage and current data. I have been working on an improved way to record the data but I need to get an Arduino with more RAM (currently using an Arduino Nano). I plan to record the time for each revolution of the flywheel. I have done this with the Nano but run out of space after 1 second or so. My flywheel design usually results in 5 or 6 second runs. I will post some pics and data when I get home.

If you want to stick with Atmega chip, use the 2560. This is the Arduino Mega.

Out of curiosity, how are you running out of space?

One version of my code dumps all the data into an array and then at the end of the run, streams it to the serial port. This setup measures the rotational time for every rotation of the flywheel and has to record RPM, Voltage and Current for each data point. This differs from how most setups work where the data is streamed live to the serial port. I found that the serial can not be used without causing missed interrupts for the RPM measurement. My plan is to try an Arduino Minima board which has 16x the memory.

This isn't a problem when using the provided sketch from the Simple Dyno software but that setup works a little bit differently. It takes data at fixed intervals and measures the next rotation of the flywheel. The problem being that I am trying to take data from 0 rpm and if the interval is too fast, you will get 2 of the same data point. To counter this, I have set the data taking interval to 20msec which is borderline in terms of resolution.

Pic of my dyno
https://cimg8.ibsrv.net/gimg/www.rct...56eb246dfd.jpg

For a quick build I did, I used the sensor cable and measured the time between rising edges of the hall sensors. I used input polling for this instead of interrupts. This allowed 3 measurements per rotation. It was a bit erratic after about 10k RPM, but I never went back and revisited it. I like some of the things with the R4, but the Reneses MCU isn't the most user friendly. I was considering going to an STM32. Of course I have an Arduino Giga R1 that is not being used...

What are you using for the inertial load? Eventually I was going to go back and work on a dyno again, but the things that stop me are the inertial load and the front end software.

My very first test did the same thing with the sensors in the BL motor. I decided to do an external measurement instead because I wanted brushed motor capability. I also did the input polling but wasn't satisfied with the higher rpm performance. I found that dumping the data to an memory array works well but you do need enough memory to hold the whole run.

The flywheel load is homemade from a piece of 6061 aluminum. It is 3" diameter, 1 inch thick and weighs 324g. The MOI is around 0.0002334 kg-m^2.

So the next question. Are you doing this in an "open source" fashion or just posting about a homemade dyno?

I built my dyno using information from Bob Wright and use his software (RC Crew Chief) to process it. Unfortunately Bob is no longer with us.
The dyno uses an arduino uni that is read using Bob's software. RPMs are read using a disc with 16 holes in it using an opto.
I also built a driver to drive the esc so I don't need to use my radio to do the tests.

I don't have code on gethub or anything but I don't mind sharing what I am doing as long as people don't try to use my stuff for profit.

Can you tell if his software is measuring number of ticks in a given period of time or time between ticks?

My intentions would be to help contribute to an open source platform. But, making something open source opens the doors for others to take the information and make what they will out of it. You kind of just have to accept that going in, or don't do it.



Uses interrupts to measure the time between pulses from an optical sensor and an encoder wheel.
Same measuring method as the MiniPro

That must be a fairy new thing on the minipro. It used to measure number of ticks per 50msec or 100msec time period.

As far as open source, all my 3d printed parts are public on Tinkercad.

That is pretty sweet!!! Nice job!

Actually I made the assumption that the MiniPro measures time between ticks, as I think the other way is prone to error... Just because the sample rate says 10Hz, doesn't mean it is counting the ticks for 100ms. Just could be the reading at 100ms. My setup was obviously measuring time between ticks, and I was spitting out the reading every 100ms.

I agree that a 10Hz sample rate doesn't indicate which way it works. My friend bought their dyno several years ago and was able to determine that it was counting ticks instead of time between ticks. He wrote the company to convince them that the data was pretty bad because of this mode of measurement. They weren't willing to work with him on a fix at that time.

Here is an example of timing every revolution and dumping it into an array of RAM.
https://cimg8.ibsrv.net/gimg/www.rct...5ec5109a14.png