too many questions for a quick paragraph answer

Suggest you google digital control of small DC motors to start search for in depth know how. Digging fully into this subject could fill several textbooks.

DCC uses a high frequency on the track, as it doubles as the packet communication system, and needs a high data rate to send enough info to as many as 256 locos in real time.  Without DCC, you can control a motor with PWM down in the 60 Hz range quite easily.  A better way than a simple one timer 555 circuit is a fixed or separately varied width power pulse and a long variable off interval for the low end speeds.

Overheating is caused by putting too much power into the motor when running slow under load, and can occur at any frequency. Also using frequencies in the audio range can create audible sound in the loco and the power pack.

If you can program a PIC or AVR in assembler, you should easily get pulse width control into the few microseconds range.

I don't know the numbers, but..

I do know that a lot of DCC decoders have had to increase their motor drive frequency, to alleviate issues with noise.  I don't know if it helps them run any more smoothly or cooler, but it definitely makes a difference in the sound.  So I would speculate that too low a frequency can cause problems with noise.

I also wonder if the lower frequency (or some harmonic thereof) might induce vibration into the drive train, causing noise or possible damage?  Do higher frequencies help there as well?

DCC has nothing to do with motor drive frequency

There are DCC decoders that use low frequency pulses - under 100Hz for motor drives (e.g. original soundtrax decoders).  And there are DCC decoders that use high frequency (e.g. zimo can do 40KHz).  And everything in between.  The DCC signal on the track, which again has nothing to do with the PWM frequency for motor drive, averages out to about 9KHz.

Higher quality motors apparently work better with higher frequencies.  Coreless motors don't like low frequencies.  Some older motors may run better with very low frequencies, because the pulses sort of kick them into action.  Some DCC decoders something like NCE's "kickstart", which while it uses the high frequency PWM, interupts it at a low frequency for starting (with adjustable params, of course).  TCS's dither is, I think, similar at the root but more complicated.

The reason the decoder drive frequencies have mostly moved to> 20KHz is simply so you don't hear the whine - it's above the range of human hearing.

Good luck!

- Ken

Thanks for the comments. I

Thanks for the comments.

I understand the track signal is not the frequency of the DCC running the motor. Someone here did some tests and sent me o-scope pics. A working DCC was running the motor at about 25KHZ. I chose 25KHZ because of those pics, knowing that it was not important to the motor other than what its duty cycle was. I just did not want to find out the hard way some esoteric fact of these motors and controllers dictated PWM above audio. If that ground had been covered before I did not want to do it again. Audible noise is probably not an issue with me. How loud can a little motor be, anyway???

The Arduino will not do the 25KHZ and I really don't want to use another controller that I have to program in assembly language...there is a limit to my persistence.

The motors are not under all that much of a load as they are motors for trolleys. The motor noise might be minimal since the load is minimal.

I know how to do it, within my former capabilities, but it is just that the last time I did component or IC level design was 30 years ago. I did digital design in aerospace for 15 years before moving into management. A cursory inspection of the IC's available today shows they have not changed all that much and I could do it with a few 4-bit counters, some gates, and a couple of Flip flops. But I'm so rusty in digital design that It would take some study but I could get there at 25KHZ. But is it necessary to run at 25KHZ? Maybe no???

I suppose I need to see exactly what the Arduino will do. It will not do 18KHZ but maybe it will do 2 to 10KHZ. If nobody has yet to claim the world will end at less than 25 KHZ then I should at least see if the Arduino can do at those lower frequencies.

Again, thanks. If anyone sees a reason beyond what has been put forth so far please respond. I would hate to implement this digital throttle with the Arduino and a lower frequence only to find the reason DCC does it at 25KHZ and it is a deal breaker.

LDBennett

Have you considered using a

Have you considered using a PIC chip for the microcontroller?

Charlie

Should be OK with 2-10KHz

DCC does not do it at 25KHz.  The particular decoder you happened to put a scope on does.  Pick another brand of decoder, you'll get a different number, anything from 40Hz (no K) up to 40KHz.

Anyway, 2-10KHz should be just fine.

noise

I've probably never used the exact motor you're considering, but in general, those little motors can buzz enough to be rather annoying.  Of course, "annoying" varies, depending on your hearing and personal taste.  If it doesn't bother you, then I wouldn't worry about it.

So, the 25KHZ example of DCC

So, the 25KHZ example of DCC is not necessarily typical? And the standard for it is not 25KHZ but the frequency is the choice of the DCC manufacturer?

That is good news. I'll pursue getting the Arduino to work at any frequency. I know it will work if the frequency is low enough.

As for using the PIC, I think it requires assembly language programming and that is an uphill learning battle for me that I am not interested in undertaking. This is more of an experiment than a product I intend on marketing and such effort would take away from retirement fun time. I would rather do it with discrete counters and IC's  as that was my expertise some several decades ago. But if the frequency of the PWM is of no real consequence then I'll stick with the Arduino implementation.

At my age noise from the motor would have to be hugely loud for me to even hear it and object to it.

Thanks again, all. The responses have reduced my efforts hugely. I was not too happy about having to study up on discrete digital integrated circuit design, having been away from it for decades.

If anyone thinks lowering the frequency to below inaudible is NOT OK please speak up before I get too committed.

LDBennett

Frequency

Right, the DCC standard says nothing about drive frequency.  In fact a decoder can be 100% conforming without even using a PWM drive.

Here's the manual for an NCE decoder: http://www.ncedcc.com/pdf/n12a0.pdf

Check out the text for "Motor Drive Frequency - CV9" - By default it's 15.6KHz, but you can change it to anywhere from 7.8Khz on down to a relatively useless 3Hz.

Here's a manual for a zimo decoder: http://www.zimo.at/web2010/documents/MX-KleineDecoder_E.pdf

Page 16 has some stuff about motor drive - "The motor is controlled by pulse with modulation that can take place at either low or high frequency. Low frequency (30 – 159Hz) is only useful for very few locomotives with very old motors (i.e. AC motors with field coils instead of permanent magnets). High frequency (20 kHz by default, up to 40 kHz as per CV #112) on the other hand is quiet and easy on the motor."

That's just two examples.  Pretty much every different decoder brand will have different specifics.  One of the neat things about DCC is the wide array of tradeoffs you have as far as picking the ideal motor control for your situation.

- Ken

Final choice ????

Because of the computation overhead and limits of the Arduino, here are some test results. The bottom line (if frequency is of no matter) is the duty cycle the microcontroller will allow in my program which is pretty optimized to minimize the program time overhead. Listed are the operational frequency and the range of duty cycles the system allows:

 20 KHZ  17% to 76%

11 KHZ  10% to 86%

5.9 KHZ  6% to 93%

3.0 KHZ  2.5% to 96%

1.5 KHZ  1/4% to 98%

This is in a bare program without having to retrieve the 6 bit word from the A to D converter. In the actual program for the last two:

2.65 KHZ 3.1% to 83%

1.4 KHZ  3% to 90%

Since frequency is not a big thing (apparently), I think I'll chose the last one, 1.4 KHZ with 3% to 90% duty cycle. My little trolleys never need 90% but I may have to add a series "OFF" switch to the output in order to keep the motor from getting a constant 3% voltage when parked for long periods and as a safety off switch. Even then a 3% duty factor is probably only about 1/2 volt on the track which will not move any model train motor I have. But while parked it might heat the motor (??).

Not worrying about the frequency sure helps!

Anyone got any comments about this decision?

LDBennett

It works on the bench!

So I tied the two test Arduino's together and they work just as I predicted at the 1.4KHZ rate. Its so neat to watch the output wave form on my O-scope change its duty cycle with the twist of the pot. I have an inertia circuit, as well, done digitally that ramps the duty cycle down and then up for a startup of the trolley that works as well.

Now I have to implement the discrete parts (transistor, diode, resistor,and capacitors to be able to drive the track. I have the design that I developed. I used iCircuit to tweak the design. Now I just have to build it. More Fun!!!

I sure hope this frequency thing doesn't come back to haunt me!

Thank you all for your comments and help.

LDBennett

Confused about implementation

I am a little confused as to how you have implemented PMW with the Arduino, but I am assuming from your description that you have implemented PMW in software without using the full PMW features available in most Atmel microprocessors. I have used a single Atmega328P for several PMW projects and have had no problem running in the 15 to 20 kHz range with 0 to 100% modulation using the internal 8 MHz oscillator. In fact Atmel 8 bit processors are utilized in several of the commercial DCC decoder designs all of which offer silent (high frequency) operation. Changing frequency, modulation, or other PMW parameter only requires modifying the timer registers.

Arduino explanation

Logger01:

Thanks for commenting.

I am certainly no expert using the Arduino but I'll tell you what I know about it and PWM for my uses.

The UNO has a built in PWM feature that is severely limited in frequency. In fact it appears to be fixed at 490 HZ. So I used the delay function that is part of the C++ instruction set. The Arduino UNO has so much overhead, time wise, that I could not get to the desired frequency and the duty factor variability was very greatly impacted. When I moved the frequency down to about 1.5 KHZ the cost of that overhead was only a few percentage points so as to be insignificant for my purposes.

I am certain using  a microcontroller with attendant auxiliary circuitry I could have achieved the 25 KHZ frequency but I did not wish to make this a learning experience in assembly language. I am also certain I could have done it with a few discrete digital IC parts as well (a few counters, flipflops, and gates) as I did that for a living some 20 years ago. But after discussions here it seems that I do not have to do it at 25 KHZ and 1.5 KHZ is good enough so that is the way I went. Time will tell how well that will run my Trolleys but honestly I do not expect a problem after this discussion.

The desire to run at 25 KHZ was dictated by some tests of one DCC model but I am informed that there is no requirement to operate trains on DCC at that high of a frequency. I was merely imitating that DCC success in my PWM Throttle design. The advantage of course is any motor generated noises would be above the audible range of humans. My hearing is so bad that noises at almost any frequency will not bother me if they are even generated (??) by the 1.5 KHZ frequency of choice.

LDBennett

C++ imposes huge memory and timing penalties

C++ imposes huge memory and timing penalties on ATmega328 applications, so I avoid C++ where possible. These limitations have been my primary reasons for programming in assembler language for these small devices, but I have been programming in assembler for over fifty years.

Past life

Logger01:

I realize that the Arduino is not a real time device. It is after all running in C++. I accept that limitation but was surprised at how much the time overhead really was.

When I worked in Aerospace back in the 1960's until the late 1990's no computer was fast enough to keep up with real time data as it appeared coming out of a radar antenna. My department's job was to process those signals so that the data could be presented to a computer for display. All kinds of processing techniques were used in real time implemented with discrete LSI IC's. As time went on we were able to build custom signal processing computers out of a microprocessor that could keep up. The same algorithms we used real time went in the programming of those microprocessors. We had our own custom compiler for the programming tasks. I have been away from all of this for 16 years and I would bet that today a lot of what we did got moved into the computers that are much faster today (??).

The Arduino is a $39 microcontroller not really intended to do real time processing. It is no wonder it would not do my 25 KHZ task. My expectations were too high but I realize that with assembly language and a custom design it would be easy to do using assembly language. But if the task did not have to done at 25 KHZ then why suffer learning assembly language? We'll see if my trolley will do fine at 1.5 KHz.

Thank you for your comments.

LDBennett

Questions, Thoughts

LDBennet:

  I'm curious as to the need for two Arduinos?  You should be able to use a single AnalogIn pin to sample a potentiometer and then use two Digital outs to drive an external H-Bridge.

Coding wise, you certainly do not need C++ for such a simple application!  It's a very basic loop:

1) Read Analog pin

2) Convert analog signal to % (0-100)

3) Set DutyCycle to % of total Period

4) Loop from 0 to Period, set Digital Out to high until DutyCycle value is reached then set Digital Out to Low

5) Repeat.

You could also use a Digital In to take reading from a toggle for direction, and then use a different DigitalOut in the above loops to control the 'other' side of the H-Bridge.

At 16MHz, even if the above software PWM requires 1000 operations per loop pass, then the loop still has an effective frequency of 16KHz.  I haven't counted the actual number of operations per loop, but just 'ball parking' it has me thinking its closer 100 operations per loop... which gives you an effective loop frequency of 160KHz. (Of course this is all theory, bench tests are better!)

I moved from Arduinos to the TI Launchpads at the end of last calendar year, but the core fundamentals are the same: Setting bits in registers.  Just last night, actually, I was working on software driven PWM to slowly pulsate two LEDs.  I've accomplished this in < 50 lines of code, but it still needs refinement.  I'm at work, but I'll have a blog post up about it a day or so.  I'm shooting for a 'multipurpose' program where you can simply set Port, Pin, and the PWM params into an array at the top of the file, hit compile and it 'magically' works.  This might bloat me past 50 lines of code, but will still be relatively simple.

Last note:  C++ is a great language for development, but not for embedded systems like Arduino and TI MSP430 (IMHO).  Bite the bullet and try to program in C, I think the end result is better.

Cheers!

More details

  claymore1977:

I am a toddler in the use of the Arduino but I elected to use two Arduinos because each one could not do two things at once.

One is converting the analog potentiometer input to a digital number with a time overhead of 100 useconds according to the Arduino C++ reference manual. That is, after reading the analog input the value can not be used for 100 useconds. If you are trying to keep up with a 40 usecond period (25 KHZ) that will never do. The second Arduino is a pulse generator whose pulse width is input from the first Arduino as a 6 bit word.

There is more to my throttle than just continuous speed control. I have a point to point trolley layout. It has four stops: two end point stops and two intermediate stops. My controller for it  is still another Arduino. That controller makes random stops at the two intermediate stations for a random amounts of time (within prescribed limits). At the end stations the trolley stops for a longer random time and reverses direction. The layout can run continuously unattended. But there was a fault: Inertia. The stops and starts are sudden. I attempted a couple of fixes in the controller without total success. For a throttle I have a commercial DC PWM throttle with inertia but since the controller stops and starts the trolley with a relay the inertia of the DC PWM throttle doesn't work.

So to get inertia for the stops and starts, this new digital throttle, when the main controller tells it to stop or start the trolley, increments the pulse width up or down at a predetermined rate regardless of the throttle setting to or from the set throttle position. This requires pulse to pulse control of the pulse width. Actually the pulse width is changed every 50 or 25 milliseconds (toggle switch selectable) by a factor of 1/40 th until the PW reaches zero or the desired set throttle position. As a further explanation the potentiometer input is analog and the results is a 40 step variation in pulse width with inertia as a count down or count up in forty steps (maximum, as it depends on where it is counting from or to) in a prescribed time of 50 or 25 milliseconds.

The whole purpose of designing this digital throttle was to get inertia into the motion of the trolley. After months of thinking about how to do it I came up with this approach which I got to work on the bench with the exception of being able to sustain the pulse frequency of 25 KHZ. After the discussions here I decided that there was nothing sacred about the 25 KHZ and through testing decided that 1.5 KHZ is highest frequency least impacted by the time overhead of the Arduino and C++.

I am not about to take on learning assembly language or even another language like C just to do this project. At 71 years old I have no future need to learn still another programming language. If I can not do it with what is at hand then I'll just abandon it. The trolleys actually run nicely with a chattering stop/start relay programmed into the original controller but I just wanted it to be better and more controllable. It was kind of a test to see if I could make the throttle better and maybe I can't (???).

There is a Plan B. If the 25 KHZ turns out to be a requirement (there is no reason to believe that it will ..but...) I can always do the job of the digital throttle Arduino #2 with discrete digital LSI IC's. I know how but I require a bit of a refresher on exactly how to. I'll decide to continue on with Plan B if I have to move to it to complete the throttle. I may abandon it if I have to (???).

There is "more than one way to skin a cat". My implementation turned out to be frequency limited but if the trolley doesn't care about the frequency being switched to a lower frequency then it is a no brainer. In fact, it is done and working. I have designed an analog circuit to take the digital input from the Arduino (limited to 5 volts and 20 ma) and pump it up to a 15 volt 2 amp capacity. I am currently building that circuit and will test it on the layout before I bother to design the box it will fit in. So the digital throttle is not yet proven and may never work but I have every confidence it will, based on where I am today.

Anyway, thanks for your comments.

LDBennett

Bench test sucessful!

Sucess so far!

Well, I wired the two Arduinos together and drove my analog circuit. It delivers 12 volt into 6 ohms (resistive) at 90% duty factor no problem (full throttle for this design). The output transistor get to about 75 degress C after 15 minutes of running full throttle. The temperature drops back to about 60 degrees C at 50% duty factor. The pulses are nicely formed with reasonable rise and fall times.

The output transistor (TIP 120) is on two TO 220 heat sinks fitted back to back with heat paste and still air cooled.

I am very impressed with the iCircuit analog circuit design tool as it allowed changes to the analog design with complete visibility, allowing me to get it just right. The analog circuit took no adjustments and worked perfectly the first time. I have used both the MAC and PC versions and the MAC version is superior, in my opinion.

Next step:    See how it runs a trolley. I'll jury rig the throttle to the track and run a trolley in a loop on the layout and see how nicely it controls the trolley. This is the last hurdle. The inductance of the motor might do strange things to the throttle output (???). Or the frequency of 1.5KHZ might really be a problem (???).

LDBennett