Get a KR Governor/Timer and a cheep speed controller (Or the Castle Ice 50 is good).  Make sure the speed controller is in the non-governing mode and let the KR set the RPMs.  If you have a prop strike the KR Will turn the motor off and save everything.  My KR timer cost $50-$60 bucks (includes program card).  My speed controller cost $25 or so and all is working great.  PS I don't have data logging but I am not that serious (yet).  All I track is battery recharge amount.  Overload a slimer and it shouts off.  Overload an electric and you get smoke.

PS RSM has im    http://www.rsmdistribution.com/index-2.htm

   

Wynn and John,
 I can't speak for any Castle firmware version above 3.20. But I have seen at least a half a dozen prop strikes or crashes locally with Castle controllers, with everyone of them set to normal sensitivity,and every single one of them has shut down properly. I am slow to update, as I will not update if all is working well. In fact my son went a little too low while doing an outside just last Saturday and skidded the plane inverted along the grass. The Phx 35 shut right down. I do not know why Tim's did not. I do like the fact that the KR timer shuts the motor down based on RPM and not peak current. That is something that i wish the Castles would do. I am not a software engineer but I wonder how hard it would be for Castle to write that into their program.
William

Wynn and John,
 I can't speak for any Castle firmware version above 3.20. But I have seen at least a half a dozen prop strikes or crashes locally with Castle controllers, with everyone of them set to normal sensitivity,and every single one of them has shut down properly. I am slow to update, as I will not update if all is working well. In fact my son went a little too low while doing an outside just last Saturday and skidded the plane inverted along the grass. The Phx 35 shut right down. I do not know why Tim's did not. I do like the fact that the KR timer shuts the motor down based on RPM and not peak current. That is something that i wish the Castles would do. I am not a software engineer but I wonder how hard it would be for Castle to write that into their program.
William

the Phoenix series ARE ok - its the ICE series that burn up.......I should have made that more clear in my first post

As a guy who does this sort of thing for pay (a big part of my current business at the moment is a motor controller, albeit not brushless) I find this very frustrating.

You cannot control a brushless motor without knowing how fast it's going and where the armature is in relation to the magnets -- it just won't work if you don't get that right.

So if you do know that the motor has stopped, there's no excuse for not going limp, or back into "motor start" mode.

And the usual way of telling where the motor is, is pretty easy to implement.

All I can think of is that whatever combination of hardware and software Castle uses is pigheaded about not believing that a motor, once spinning, has stopped.  Or something.

(It would be interesting to know if Kieth Renicle's software gets messed up by a Castle ICE Lite controller -- depending on just what the controller's failing to do, it could inadvertently spoof Kieth's software.  If it doesn't, then the ESC knows exactly how fast the motor is (or isn't) going, and has no excuse).

C'mon guys.  Get it right.

Keiths timer works with CC escs - so long as you turn off the governor.  His timer is hard wired to one of the motor leads and feeds back info that way.

Real world learning shows that the CC ICe lites do not shut down and burn up ....if you dont believe me - I'll send you two of mine that have done it.  I no longer use CC ESCs as 1 - they are relatively expensive and 2 - I have had 2 burn out from prop strike - as has a friend of mine down here - so it gets expensive.
I have yet to burn out an ESC with keiths timers - and we have done testing by stopping props etc - the system shuts down instantly.........

I am not hasseling CC - they are what I used initially and I have had many good flights with them - but as they say "always give someone a second chance, but never a third"   

(It would be interesting to know if Kieth Renicle's software gets messed up by a Castle ICE Lite controller -- depending on just what the controller's failing to do, it could inadvertently spoof Kieth's software.  If it doesn't, then the ESC knows exactly how fast the motor is (or isn't) going, and has no excuse).

C'mon guys.  Get it right.

A KR timer could care less what the controller is doing.  It has a wire attached to one of the motor leads to sense RPMs.  If RPMs go too low timer turns off.  The only problem that can accrue is when the controller is also in the set RPM mode.  Now you have two electronics fighting each other and it probably won't work correctly.  However I don't think it will burn up anything.

On the subject of having the speed controller shout down on low RPM doesn't work because all speed controllers are designed to work with a throttle.  In the set RPM mode at full throttle you could have the feature kick in but at less than full throttle it would have to turn itself off.  Besides RC folks (if they don't panic) turn off the throttle upon crashing etc.

A prop hung in the grass at full throttle in kinda a controll line problem - So to me the fix should be in the timer - like in the KR Governor/Timer.

 

As a guy who does this sort of thing for pay (a big part of my current business at the moment is a motor controller, albeit not brushless) I find this very frustrating.

You cannot control a brushless motor without knowing how fast it's going and where the armature is in relation to the magnets -- it just won't work if you don't get that right.

So if you do know that the motor has stopped, there's no excuse for not going limp, or back into "motor start" mode.

And the usual way of telling where the motor is, is pretty easy to implement.

All I can think of is that whatever combination of hardware and software Castle uses is pigheaded about not believing that a motor, once spinning, has stopped.  Or something.

(It would be interesting to know if Kieth Renicle's software gets messed up by a Castle ICE Lite controller -- depending on just what the controller's failing to do, it could inadvertently spoof Kieth's software.  If it doesn't, then the ESC knows exactly how fast the motor is (or isn't) going, and has no excuse).

C'mon guys.  Get it right.

Whether Castle does it right or not is immaterial.  The important thing is that we're getting Tim fired up in the direction of making integrated timer-controllers to our requirements.  The optimal case would be if he only makes a few prototypes and lets me use them. 

Whether Castle does it right or not is immaterial.  The important thing is that we're getting Tim fired up in the direction of making integrated timer-controllers to our requirements.  The optimal case would be if he only makes a few prototypes and lets me use them. 

You know, normally you guys who spent their entire careers working in safety-critical applications and your expectations for reliability analysis and testing are a royal pain in the neck.  But I can see how this might be turned to my advantage.  I mean, I'd been wondering where I'd get some disposable planes to burn up with the first few test articles.  I guess I know now.

With all due respect, what Keith's timer senses is the voltage on the wire flapping around.  If the ESC is confused and thinks the motor is still spinning, it'll make the motor wire voltages flap around in a way that would be very difficult to distinguish from correct operation.  This would not only fool Keith's timer, but it would make lots of ESC- and motor-burning current flow through the circuit.

Presumably that is not happening, although what is happening (absolutely anything that burns up a motor or ESC, in my opinion) isn't appropriate.

Hi Tim, I don't read voltage, I simple read the pulses on the motor wire of one of the coils and use this info in my external governor program. I therefore sense rpm and it's quite easy to set a trigger point that serves as a low rpm detector for prop strikes and/or dropping in rpm due to the batteries going down. The Jeti spins also burn easily if something goes wrong and I guess that the CC Ice is similar. Either way, the simple Chinese esc's are a lot cheaper if they do blow. The real El-Cheapo's are not great however because the throttle resolution is low. Hobbywing, ZTW and some Turnigy's all work fine. Having said all that I will most likely get myself a CC Ice because of the data recorder. I have an Eagle Tree recorder but the CC is much simpler.

The initial problem is that the ESC doesn't output anything to the timer; two leads are the 5 volt power leads and the signal/throttle input to the ESC. The current FM-9 doesn't use a connection to a motor wire, although it could in the future. There are some other possible approaches to the problem:

I could put a 3-wire lead on the timer and connect it to a tiny transistor-size temperature sensor. For example, there's one that goes for $1.25 (in quantities of ten or more) and would put out a voltage from 0 to the supply voltage for temperatures from 0 to 100 degrees C. This could lead to one of the unused pins on the microcontroller and it could be set to turn off the motor when the temperature exceeded a desired value. The microcontroller has plenty of time between generating the throttle pulses to monitor the temperature and could respond in a millisecond or less. The sensor should be epoxied to the rear of the motor, probably.

Another possibility would be to sense propeller rotation. This is easy to do if one puts something on the propeller, like a little magnet, but not so easy using an optical sensor because the amount of light getting through the propeller varies so much.

Another possibility would be to sense the cessation of airplane motion, or a high-g encounter (think airbag sensors). This might not work so well for takeoff on grass but it could work well for a "hard" landing. This might not be too expensive or too difficult; I'll check up further on it.

I think (a dangerous thing for me) the missing link in this thread is how the speed controller interfaces with the motor.  As I understand it, the speed controller does not just throw out a bunch of pulses and hope the motor keeps up.  The speed controller, in fact, puts out a pulse on two of the three wires.  The amount of energy contained in the pulse is controlled by the throttle setting - the Tx in the case of RC and the timer in the case of control line.  This pulse of energy causes the motor to turn.  The controller is looking at the third wire to sense where the motor's rotor is located in relation to the magnets in the motor.  This can be done because the un-driven wire acts as a generator so the speed controller can see the magnets go by as a changing voltage.  Based on this information the controller switches the drive circuits between the three motor leads to keep the current flowing in such a manner that the motor is forced to turn.  So in normal operation the speed controller is not just flailing around hoping the motor keeps up. By the way in the olden days with the brushed DC motors the controller did put out energy to the motor and hope the motor can keep up. Now, what I don't know is how the modern three wire speed controller handles start up.  I would assume that the controller's software starts a blind sequence of pulses and looks to see if the motor is responding.  Once it sees a response it switches to the synchronous mode and tracks the motor. The other thing I don’t know is how a speed controller responds when the rotor stops.

Now lets look at why speed controller/motor burns up when you get grass in the prop.  As described above the speed controller applies a voltage to a winding in the motor.  The resistance in the path through which the current is flowing determines the amount of current.  The DC resistance component is determined by the internal resistance of the battery + the ON resistance of the FETs in the speed controller + the resistance of all the wire in the loop (battery leads, controller 's PCB resistance, motor leads, and motor windings).  By design all of these values are kept very low so that if this were the only current limiting factor the current would be in the 100+ amp range.  The other current inhibitor is the back EMF of the motor.  This is a reverse voltage built up in the motor leads due to the motor windings passing through the magnetic field of the motor magnets.  This is a function of number of turns in the windings and the RPMs of the motor.  So if the motor can't turn - no back EMF is generated and the current heads to 100+ amps and smoke commences.

So the question is why can't the speed controller sense current and shut down before things smoke.  Well the answer is it can but it takes a lot of hardware and software to accomplish this.  Hardware wise it takes a current sensing circuit in the speed controller.  Measuring the voltage drop across a known value resistance can do this, or perhaps a hall affect probe could do the job.  One would think that a data logging speed controller has this circuit built in.  Software wise, to do it right, it gets a little complicated.  The problem is that you can't just detect peak current.  On start up the current peaks very high until the motor comes up to speed.  Also when making that sharp turn from horizontal to vertical (as in the start of a wing over) the current jumps momentarily.  So the software has to do a time/current measurement so that you don't get a motor shut down from a spike of high current.

Next lets consider the speed controller doing the turn off when RPMs are at a wrong value.  Once again this is a RC vs CL issue.  In the RC mode (throttle active) RPMs are all over the place.  In the fixed RPM mode at full throttle software could turn on a check mode and look at the RPMs.  For RC this is primarily for helicopters.  Helicopter pilots don’t like sudden motor stoppage so they may not want the feature.  On the other hand CL stunt pilots always want to run in the wide open set RPM mode.  So for them low RPM motor shout down would be a good feature.  Once again RC and CL have different requirements.  Considering the volume of RC sales vs the volume of CL sales why would a speed controller manufacturer spend money on a CL requirement?

What’s the bottom line?
1:  Most speed controllers do not have over current protection or they use a high current/time combination to sense over current and shout down.
2:   Low RPM sensing could be incorporated in a speed controller while it is in the wide-open set RPM mode.  RC folks don’t really need this so it probably won’t happen.
3:   CL electric stunt needs a timer that controls total run time, controls RPMs, and protects the motor and speed controller when you have a prop strike.
4:  The KR timer fills all of item #3’s requirements.
5:  It is possible that a motor speed controller could go into some kind of a goofy mode that confuses a KR timer and prevents it from protecting against a burnout.  However, how likely is this?  Personally I am not going to lose any sleep over the possibility.
6:  CL electric stunt has special requirements.  The most likely way to satisfy all of these requirements is to incorporate them into a product that is intended for CL use only.

And that folks is all I to say about the subject.  And remember my opinion is worth what it cost you.    

         

One good way to handle the hard landing/crash problem is to monitor the temperature of the motor or the ESC.

Looking at motor temperature limits, I see that Plettenberg specifies 100C (212F), E-Flite specifies 220F, Rimfire says its magnets are OK up to 302F, and Scorpion says that "..anything over 130F will seem very hot but up to 200F is considered safe.."

The non-rotating part of our outrunners is normally at a lower temperature than the rotating outer part, of course, but is quickly heated up when the motor stops. I made some measurements on my test stand of an E-Flite 25 motor, powered by an ICE Lite 50, at about 12,000 RPM, for 6  minutes. The measured temperature increased during the "flight" from room temperature to about 90F; after the motor stopped, they increased to around 100F. The outer part felt warm, but not hot, after the run.

I do now offer a version of the FM-9 (the FM-9t) that monitors the motor or ESC temperature through a tiny (transistor-size) sensor that should be epoxied to the motor or ESC. It adds about 1/4 oz to the timer system. It will immediately shut down the motor if the measured temperature exceeds the programmed value. I've tried it with a setting of 130F, but it would be desirable to measure the actual temperatures right after landing on a hot day and use this to set the shut-down temperature.