Need Advice on PWM and other stuff

Hi Folks,

Well, school's out for the summer, and I am ready to build my new bot. If you recall, last winter break, I built "bang-bang", so named by the people on this group because of my use of dpdt toggles connected to RC servos to bang him off and on. Well, bang bang's motors died after about 3 weeks of use.

Since then, I have read Gordon's book, along with a few others, finished my course in electronics, and built a SONAR range finder device for my final project, along with some optical gadgets for my LASER course.

I have a circuit for PWM using a 555 and a potentiometer to vary the duty cycle. Now, at first I thought of driving the potentiometer with a small telescope motor, but then I started thinking about how to let the micro know (I am using Atmel AVRs) when the pot was against the stops so it wouldn't keep trying to turn the motor in that direction.

Just some background I am building my own H-Bridges, using power mosfets, and my PWM circuit (actually Horowitz and Hill's circuit). Also, I am using 2 windshield wiper motors that use 12V at 2.5 Amperes at 60 RPM (unloaded), With a load, I have found the stall current to be 4.5 amperes and the stall torque is 13.5 Newton-meter each. This is to be a 2 front wheel drive (differential system) vehicle using a sprocket and chain system to transfer the power from the motors to the wheels. Oh, this is an outdoor bot.

My question is, what frequency PWM?. All the above tests were conducted with the motor connected directly to the battery. I have heard that anywhere from 60 Hz to 100Khz is acceptable, but I tried first (on the bench, ie no load) 1Khz and the power mosfet was dissipating too much heat (like finger burning heat). At 10Khz it is much better (ie, much less heat dissipation). I have also tried using power darlingtons (TIP102's) and they reach 100C within about 5 seconds of power on. These tests are being conducted without heat sinks as I was able to rig up a temperature alarm to sound when the metal portion of the mosfet reaches 100 degrees C. Of course, I know I will be using heat sinks in the real deal. And probably active cooling (ie a fan).

I get absolutely no rotation until my duty cycle reaches about 60%. That did not change from 1Khz to 10 Khz.

I am using separate power supplies for motors and electronics with just the grounds commoned.

I decided that using the motor driven potentiometer was folly, and I will probably use mosfet switches to change the resistor values (and, hence, the duty cycle) in my PWM control module. Unless folks have a better idea.

I guess I wanted to bounce my ideas and design thinking off the group, as I know some of you have been building bots for years.

If anyone has ideas on any of what I have mentioned above, your comments are welcomed. As this is only the second bot I have built, I need all the help I can get. It will be radio controlled at first, as I have been able to decode the pulses from my futaba using the AVR. Ultimately, I hope to make it at least semi autonomous. I have many, many sensor ideas for it that I would like to experiment with.

TIA, Joe

Reply to
Joe
Loading thread data ...

The frequency isn't the problem, if increasing the frequency reduces heat dissipation. It's the waveform. You're probably driving the MOSFETS with a waveform that has too long a rise time. If you're getting overheating like that, you're spending too much time in the linear range of the device. Put a scope on the inputs and measure the risetime of the MOSFET's control signal. It should be well below 1us. Commercial MOSFET gate drivers have rise times like 35ns. See

formatting link
for some commercial drivers.

A 555 ought to have an output rise time of about 125ns, so you should be seeing rise times like that at the MOSFET gate.

Also note that the output of a 555 is not rail to rail. Are you getting enough voltage swing at the MOSFET gate?

There are also issues with driving an inductive load like a motor, but that's less likely to be the problem here. That's a problem which becomes worse as the switching frequency increases.

The real issues with switching frequency is that if it's too low, the motor vibrates, and if it's too high, the motor's inductance limits current into the motor.

John Nagle

Reply to
John Nagle

Hello John,

Thank you for the response. I should have specified, I am using the ts555cn, which according to STMicro has a rise time of 25 ns. Yesterday, I did just what you suggested and measured an actual rise time of 40 ns. I didn't think too much of the discrepancy at the time. Is this significant? Although, now that I read the data sheet again, it says 'trigger propagation delay is 100 ns" Is this what you meant? It (the ts555) is connected to the 12V power supply the whole time.

Now you gave me an idea, my power mosfet (the IRF 520) has a rise time of 23ns at 50V, but the number I quoted you above for the ts555 is into a 30pf load, where the input capacitance of the mosfet is 330 pf.

BTW, the microchip link you gave me above just timed out. I did not receive the pdf yet. Is there a part number you were referring me to? I will try the link again, but just in case, if you do not mind, perhaps I would have better results looking for the part number.

Oh, I am whacking the gate of the mosfet with 12 V from the ts555cn. I noticed that using 5V resulted in unacceptable heating as well. Experimenting showed that any voltage above about 7V resulted in significant less heating of the mosfet. I only wanted to have 2 voltage sources for my electronics, 12 V for the eventual SONAR, and

5V for the micro and other electronics. But that is still flexible.

I'm still stuck on this but I will try the link you gave me once I log off this forum to see what that's all about. Oh, and while I am at it, since I did not specify enough info in my first post. I am using the

20L15T Schottky diode b tween the drain and source of the mosfet. Do I really need something that hefty? They are expensive, but I didn't want to take any chance on blowing mosfets due to the inductive kickback.

Thank you again for the info,

Joe

Reply to
Joe

Since you have an AVR, you might want to replace the 555 with a pin(2) from the AVR. Depending on which AVR you have you may already have a couple of PWM counters on board. Even if you don't have the PWM counters you can build one easily enough with a timer interrupt.

Using an AVR for the PWM output gives you a little more flexibility in how to set the motor speed.

I'm about to do the same thing (AVR/PWM) for my bot so let me know if you want more specific help.

Bob

Reply to
Bob Smith

Hello Bob,

Yes, a very kind offer. Just one pin? I would love to use the avr, but I don't know how, even after reading the dox. I am going to have one micro whose sole function will be to control the motors and steering (and, at first, will have to decode the signals from my RC and timeout when it stops receiving the once every 18ms pulse that the transmitter generates when it is on, just a safety precaution in case the thing's running full tilt and my RC transmitter batteries go dead, or it goes out of range). I will add micros later for sensors, navigation, etc. as needed.

I have in my possession the following:

ATTiny 2313 (I know that has 4 PWMs aboard), but limited memory ATMega 8515, my favorite ATMega8535, because of the A/D's. I haven't used this one yet.

Bascom full version programming language. 1.1.83 STK 500 programmer.

I cannot seem to wrap my head around how to use the timers for PWM and get a timeout if needed also. Being more inclined to hardware, I thought I would use a separate PWM (which probably sounds insane).

Anyway, suggestions on which micro would be the best to use, and, If possible, I would like to control each motor with its own PWM so I can slow down instead of stopping one of them to make a turn.

Now, if it so happens that you don't use Bascom, then a flow chart (antiquated term, I know), or description of which pins I have to use, details, details, and I can probly figure out how to code it myself in Bascom.

Thank you for the reply, I look forward to this to enhance my understanding of all the functions these avrs can perform.

Joe

Reply to
Joe

Sorry, the "(2)" was *supposed* to be "(s)" indicating more than one pin. You'll probably want, per motor, one pin for the PWM output and one pin for the direction.

I sit at a Linux desktop and really like the AVR since you can program it using gcc. The site that got me going on this was:

formatting link
Some AVR books to consider are: John Morton's "AVR, An Introductory Course", and Dhananjav Gadre's "Programming and Customizing the AVR Microcontroller".

All of the above are good and have enough PWM channels that you don't need to use a timer interrupt. I use the ATMega8 in the

28 pin DIP. It is easy work with since I wire-wrap most of my projects. (See my hobby web site at:
formatting link

The basic idea is the same for both a hardware and a software implementation. You have a free running counter with the number of bits of your desired resolution. For 8 bit resolution you need an 8 bit counter. Set up a timer interrupt and increment the counter on each interrupt. If the new count is zero, set the PWM output high. The terminal count is the PWM width times the resolution. So if you wanted a one-quarter width PWM output, the terminal count would be 64. If the new count is equal the terminal count, set the PWM output pin low. There are other considerations but this is the basic idea.

hope this helps Bob

Reply to
Bob Smith

was:

formatting link

Hello Bob,

I did some more reading in both the bascom user manual and the atmel documentation for the 8515. They don't talk about rise times, which is crucial for using power mosfets.

The bascom user manual has a sample program to output 2 PWM signals (according to the 8515 dox, "phase and frequency correct outputs are the preferred modes for electric motors), using timer 1, the 16 bit timer. It divides it into 2 8 bit pwm signals. I don't know if they are "phase and frequency correct", nor do I even know what that means, but I am going to give it a go today.

You said above: So if you wanted a one-quarter width PWM output,

I don't know what you mean by terminal count. Do you mean clock scaling?.

I guess I will begin at the beginning. Program the chip using the sample program in the user manual, and measure the OC1A and OC1B pins and see what I get on the scope. Then, I will try and vary the width of the pulses after I make sure the rise time is on the order of about 35-40 nanoseconds (or less), although I doubt it. If not, maybe there is some logic (LS series maybe ? that can take a slow rising edge and make it fast.) Is there a such thing as a Schottky comparator with the rise times I have mentioned?

Anyway, I am off to the races now, so to speak. I will repost here if I have any questions, and I will check out your web site first. Maybe I will get some ideas from there.

Thank you again,

Joe

Reply to
Joe

Hmmm, I'm surprised. I thought I recalled seeing these diagrams for the AVR. The Bascom manual is chip-agnostic, so it wouldn't have anything specific about any of the chips.

The 8515 is a rather old (and now obsolete chip) and maybe they didn't use to document this. Or, you have the "summary" or errata documentation, and not the full documentation. On most of their chips, the full docs are >100 pages.

-- Gordon

Reply to
Gordon McComb

Hey Gordon,

Good to hear from you again. I've been indisposed for the past few months with studies and finals and all.

Sheeutt, the bascom manual is 750 pages long ! And, the ATMega8515 "data sheet" (ahem) is 250 pages long. Lots of stuff to wade thru there. I have to laugh when it says "data sheet". A data sheet is maybe what 20 pages at most? This thing is like a book.

What do you mean the 8515 is obsolete? maybe the AT90S8515 is what you are referring to. I am the one who got a mega8515 that said it was the AT90S8515 and it drove me batshit for 2 days till someone on the mcs forum asked me to send them the chip ID, and then she told me that it was the ID for the ATMega 8515. Everyone said it was a one in a million shot. The Atmel app engineer said he'd heard of it, but that it was extremely rare. Maybe I should have played the lottery that night !

And, yes, you are right, no mention of rise times. Maybe they don't even know, but now I do.

I did some experiments today. Bob, You Rock !

I just entered the sample program from the bascavr user manual, but using the pins from the (ahem) 8515 data sheet and looked at the waveforms on the scope.

I'll be dipped in shit, it works! Just by changing the pwm1a= and pwm1b= values, you actually get what looks like a linear relationship between those numbers and duty cycle. (I haven't plotted them yet,but it is predictable and repeatable).

Also, when you configure timer1=pwm,pwm=8 compareApwm=clear up, compareBpwm=cleardown results in a pi shift in phase between the 2 signals, but if both compares are up or down, ie, equal, then both wave forms are in phase.

So, I have duty cycle and phase control. The signal is clean, and I didn't see any glitches.

Now for the best part. I measured the rise time of the pulses at 50 nanoseconds. Not quite what I wanted, but I was very pleasantly surprised.

OK, so now I need to speed up the rise time. I have to run these nice neat clean waveforms thru something that will give them a gain of, say, 3, and will speed up the rise time. I have to whack the gate of these mosfets with at least 7 volts, 14V is their limit before the fireworks, but 5 volts will just cause a meltdown, so I am thinking 12 volts, since that is my electronics power source (not the same 12V the motors will be using). All the so called high speed comparators out there have rise times on the order of 100 ns.

Any ideas?

Joe

Reply to
Joe

One of the few times I am answering my own post. I think I have solved the above problem I outlined in the last paragraph above. At least on paper anyway. I'm going to try my solution out today.

Well, thank you gentlemen, for all your advice and information.

I will be visiting the group more often now that I have a little more time.

Joe

Reply to
Joe

PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.