SystemTheory

I note some views of the pdf papers posted above, and decided to comment on the relevant equations. The math looks imposing but mostly it's derivation.

Paper: Motor Constant

Figure 1 is easy to visualize as the conventional brush motor coupled to a battery and a flywheel as on the Dyno. By design in a commercial system, the electrical time constant Eq. (17) is very small compared the mechanical time constant Eq. (15) or Eq. (16).

The electrical time constant is crucial to the speed control designer to select the proper PWM frequency. On the Dyno and out on the track, one detects the mechanical time constant as roughly the 1/5 the time to reach maximum speed. The roughly part is due to bearing friction, air drag, etc., which sap power and shorten the time to reach a reduced top speed.

SystemTheory

State of the Art Brushless Motor Efficiency

Easy to read article:

http://techon.nikkeibp.co.jp/english...090403/168295/

SystemTheory

Inrush Current Limiting

This page has a simplified discussion of inrush current limiting for a large brushless motor on electric bicycles.

http://www.ecospeed.com/motdet.html

Note there should be three figures, since the case where there is no current limiting in the early RPM range is described but not sketched.

These principles are appearing in the Dyno results posted by John and others. It appears the lower power motors have higher coil resistance and do not use inrush current limiting, while high power motors have very low coil resistance and employ some form of inrush current limiting. The reason is not just to get the efficiency up at low RPM, but may also serve to protect the MOSFETs and motor coils from thermal damage due to excessive current flow.

In racing when you limit inrush current, you also limit torque. If traction is available you limit acceleration on the track. This can be a benefit to match torque to available traction and reduce wheel spin, or a detriment if the tires support more g-rate acceleration than the motor generates at the drive axle.

I've added Figure 1 to discuss the slick condition on the first lap on the Velodrome. My model assumes traction would support 2 g's, but suppose the slick track supports only 1.2 g's. You would pick up at less than full throttle and ramp up the throttle as RPM increase in a straight line, supporting 1.2 g's acceleration at the drive axle with the current/torque output approximately flat as shown. You would hit full throttle (8.2V PWM) at the point of the knee in the curve, and then the reverse voltage in the motor would continue to increase, limiting the current draw from the battery, the output torque of the motor, and the g-rate of acceleration drops as RPM increase from there. In the time-based response these impacts are exponential curves.

SystemTheory

Waveforms in Brushless Motor Speed Control

These are the most informative of all waveforms I've seen in my web search for insight on the operation of brushless motor speed controls:

http://www.aerodesign.de/peter/2001/...DY-BL_eng.html

You can see the pulse width modulation and phase timing very clearly in the last two graphs. When the motor RPM changes, the spacing of the phase signals in time must change, which is frequency modulation.

dpero

Hello all. Not much going on here lately so I thought I would share what I have been doing.

I obtained a copy of the excel file from John. Thanks. Also thanks to all involved in the creation of the spreadsheet. Good job. I made some minor changes to suit my liking. One of which is adding a tab to the workbook which I import my data into.

I don’t have a Sentry but am using an Eagle Tree Micropower v2 for logging. It logs the same data as the sentry at 0.1 sec. intervals. One shortcoming is the 120A current limit. It’s rated for 100A so I’m pushing its limit. I purchased a 200A sensor and hope to install it soon. I need to analyze the output of the stock sensor first. There is a calibrate function in the software so I should be able to re-calibrate to the new sensor and not have to do any post processing. I may also mount it remotely like the Sentry.

One odd thing I found with the Micropower is that it logs the same RPM for the first 0.4 - 0.5 sec. There is an example attached. I manually correct those first data points to make the curve smooth. I suspect a bug in its software that under normal circumstances doesn’t matter.

I tried a couple different flywheels and settled on one which weighs 224g and has an OD of 2.5 in. There are a few balancing holes that I did not account for in the inertia calculation yet. They are small but I’m sure they do make a difference in the inertia.

I statically balanced it with the flywheel mounted to a 1/8 in dowel pin which had its ends ground to a point. Two strong magnets were placed into my milling machines vice with the assembly between them. This seemed to be a very low friction setup which gave repeatable results. I was surprised about how out of balance the flywheel was. Its run out, both axial and radial, is within 0.001 in. It would be nice to have it dynamically balanced.

I primarily run Castle Creations setups because of a retail price rule of $125 I have to abide by. I have not yet tested those because of the severe cogging. I do not race pan cars but do race off-road. I don’t notice the cogging on dirt (I’m just not that good). My primary reason for the dyno is for testing motors/ESCs for use in RC tractor pulling. Brushless was just allowed last year in some classes. The price limit of $125 rules out a lot of motors. However, the sensorless combos are doing just fine for tractor pulling. I'll also be testing brushed motors.

I plan to test each of the CM-36 series of motors. I have, and also borrowed, one of each kV. I also have one of each of their ESCs, Sidewinder, Mamba Max, and Mamba Monster. It will be interesting to see what the differences are.

In the meantime, I have tested a Novak Havoc 8.5, and two brushed motors; a P94 13T double and a Speed Gem 11T double. They were just pulled out of storage and are quite worn. If they were tuned up I’m sure the power output would be higher. I also tested 2 ESCs, a Novak Super Rooster and Dually. Very interesting. The Dually was limiting current to 71A. The current pot was turned up. I’m not sure if that’s normal for that ESC or if there is something wrong. I do have another one to test.

Anyways, check out the graphs. Comments and suggestions are welcomed.

Access

Have you got the absolute latest firmware in there from castle? There was one about a week or two ago that helps reduce / minimize the cogging and offers even finer tuning for the rest of the setup parameters.

John Stranahan

iTrader: (27)

dpero-Nice work.

I noticed a couple of small problems with the output. The torque in g-cm max does not agree with the torque in g-cm on the left y axis.
The max efficiency on the P94 13-2 motor blew up. Is this auto generated or just a manual input. I see that the efficiency graph spiked at the end. I guess this is the problem.

I see what you are talking about with the dually limiting current. This would be a serious limitation in a tractor pull.

I note the correction for not starting quite at zero time. Nice. I also see where the first four to five RPM points are messed up. Matt does some manual correction here on occasion as well.

access-I don't believe it is possible to prevent cogging with a sensorless motor. It was a serious limitation when I ran a castle in a wide pan on a low grip track. The stumbles actually caused spinouts on sections with delicate turning at hand. I see where it might be reduced a little with software.

Access

It has improved vastly, I remember when I was first getting into the hobby, my first brushless controller was a mamba-25 1/18th scale with the original firmware and it cogged like crazy. Other people with early-generation hacker ESCs had similar problems. From a dead stop, vehicles would take sometimes 1-2 seconds of weak, uncontrolled motion before significant power could be applied.

Today for instance this video I made over a year ago
http://www.youtube.com/watch?v=pKdRFDuyoVo

In this video, you can see the VXL sensorless cogs like crazy and is basically uncontrollable at speeds 10-20cm/sec or below. The castle has much cleaner starts, you barely notice any cogging at all (if setup properly). So I find it's largely based on the quality of the ESCs firmware and setup of any parameters.

Today their firmware is even better then when I made this video. I'm not saying it's perfect but it's definately come a long way. I still use Havocs for racing just b'cos I want to leave absolutely nothing to chance. But with the large improvements made over the years, there is no reason he shouldn't be using the absolute latest firmware in testing castle's sensorless setups.

dpero

No I don't. I think I'm on v1.2. Thanks for letting me know. It will be interesting to see if there is a difference.

dpero

Corrected... thanks.

It's auto generated. I should have noticed that though. I've been looking at max power mostly. I should have deleted 2 more lines of data. I had let off the throttle at that point... no current. I attached a new graph. As for the other spike... there is a current drop at that point for some reason.

So the Sentry has a similar issue?

John Stranahan

iTrader: (27)

The sentry starts RPM readings at about 500 RPM so the first couple of points may have erroneous RPM readings. I did not think they required correction for most of my work with the powerful motors. I did notice how this zero correction magically brought in Chris's sixth order curve to more exactly match RPM data. This was important with a light flywheel and stock motors.

I agree that sensorless motors have improved. I might make analogies to a car motor where we want crank position data. We could probably take a few years and a large team and develop software to do this from exhaust pulse data. It is so much more direct to just put a crank sensor on the motor.
With a sensor, you immediately eliminate 3 chronic problems with sensorless. Poor starts which include the reverse start 50% of the time. Losing timing with bumps to the board requiring a full stop. Poor light throttle consistency.
I had my Mamba pre and post an upgrade. No improvement noticed.

SystemTheory

dpero, nice graphs.

I am looking for evidence of ripple torque in the brushless motors versus little or no ripple in the brush motors. Also I note some motors start to show a gain in torque, power, and efficiency at high rpm, which is unlikely to occur in this region due to higher back-emf tending to limit current and torque.

If it is not too much trouble to make one or more graphs, it might be of interest to plot your raw (uncorrected) rpm data for the 13T, 11T, and 8.5 against time on the horizontal axis. Also, what is the net change in rpm at the nearly constant final value as logged in the raw data? Is it close to the +/- x.x rpm limit of the rpm sensor?

Access

I can't really argue with that. We ourselves know how things should be designed with the laziness principle and it makes perfect sense to us. But business is often a world in itself, businesses do not necessarily make decisions based on efficiency or efficient design / minimal work. In many cases the object of a management decision is to create (and/or justify) the maximum amount of work for oneself, one's peers, and one's own department. It's just like government or any other case where you are spending "other people's money", and the object is to secure even more money to spend for the future. When a business lacks an 'efficient culture', the only thing that ultimately keeps runaway management decisions in check is customer choice and business competition.

Contextually the castle of 6 or so years ago was coming into the car/truck market from the aircraft market where sensorless was already the norm and sensored was increasingly rare and largely unnecessary. They had already done the work to make sensorless work (in an aicraft), it just didn't carry over too well to cars/trucks where racing or anything that requires fine control at low speeds is concerned.

It is also worth noting that Castles next-generation Mamba Max Pro will have a sensor port for optional use. I don't know if their motors will have added sensors, however.

Anyways enough on that, looking forward to seeing how their motors test out relative to one another.

dpero

No trouble. I'm interested in your thoughts on the results. I put all tests on the same graph. Quite smooth looking. The only corrections are in the first 200 to 500 ms due to the problem with the logger as mentioned above.

The motors seemed to be still accelerating when I stopped the tests. Being my first usage, It was hard to tell when the max RPM was reached. That flywheel screaming away also makes me nervous. You can see where I let off on all but the 11 turn. Even though I let off early, the power curve still seems reasonable. I had the logging trigger set to 1000 RPM so no data below that. I'm going to lower it for next time to see if the RPM problem changes. I can also set the trigger to X amps.

I also attached RPM change graphs. I do not know, nor can find, the measuring accuracy or limit of the RPM sensor or or logger. The processing speed is not listed. The accuracy of the current and voltage seems to be...

I have the v2:
"Currently it is 0.12A and 0.07V, if I remember correct."
rcgroups.com/forums/showpost.php?p=8340861&postcount=17

v3:
"The internal resolution of the V3 is approximately 0.05A and 0.02V. There are also several enhancements to attain better accuracy and maintain it over time."
rcgroups.com/forums/showpost.php?p=8366306&postcount=25

I am using the infrared sensor with half the flywheel blackened. I do have a brushless sensor but since I'm testing brushed also, I figured the optical sensor would work better for me and be more accurate as it measures actual flywheel rotation as opposed to the signal to the poles.

I am currently working on my own system using an Arduino platform. I don't like not having control over the system. I should be able to get many more samples/s. I also will be able to measure up to 300A with the sensors I purchased. Cost will still be very low, probably cheaper than the Sentry or Micropower.

Brushed motors are still used in most of the tractor pulling classes so I'll still be doing a lot of testing with different setups. I've always wondered what effect timing has under heavy load and what would be the best to set to.

I'm also very curious as to what effect the different electronic timing settings in the Castle systems has.

SystemTheory

dpero, thanks, the graphs look great. I don't see any obvious evidence of torque ripple on the 8.5 compared to the brush motors, but it looks like the "steady-state" top speed region is cut off, where ripple would appear more obvious.

John tuned the Sentry Dyno to capture data around peak power and I think it is pretty accurate in the middle parts of the curves. I'll take a good look at the graphs later and if anything stands out, post comments.

If anyone is curious about Adruino here is a link with good information:

http://microcontrollershop.com/produ...oducts_id=2888

I am interested to follow the development path with the Adruino as you progess.