I am working on a project where I need a DC motor to run forwards and backwards. After some research I thought that this H-Bridge would do the trick. So I hooked it up via an Arduino (AVR chip) to provide logic control and a wall-wart (3A) 12VDC supply to provide power for the motor. The motor runs and stops as instructed by the AVR, but no matter what it always runs in the same direction even though the AVR chip should be telling it to run in two directions. Can any electronics experts here tell me why this @#$@# motor would only run in one direction connected to this H-Bridge?

The schematic is attached for those so inclined. I'm attaching the motor to the H Bridge by hooking up output 1 of the bridge to one motor pole and output 2 to the other motor pole (is this right??).

Have you tested the motor by connecting the power supply you've got directly up to the motor both ways to see if it can run in the other direction?

I have a similar project underway here right this minute!.
This L293D driver chip is what I'm using, wired in a circuit like this simple kit uses (page 10).

Your wiring looks correct, but the datasheet shows an unusual truth table on pages 4 and 5.

It looks like your two GPIO pins need to be 00 for one direction, and 01 for the other direction. Use 10 for "brake" mode, and 11 for "coast".

Cheers

Yes the motor will run both directions on it's own.

Thanks- I will double check my coding on the AVR. If I still can't get it to work then I guess I will order some L293s. I'm not happy the L293 only outputs 600ma though. My motor will probably draw more than that.

You should be able to get it working with the chip you have -- probably just logic issues, which you can verify with a volt meter on the GPIO outputs.

But if not, then each L293D (you definitely want the D version, with built-in diodes, not the one without the D) has *two* complete H-bridges, which can be ganged up for 1.2Amp peak drive capability (as done in the sample board circuit I'm using here).

Cheers

AVR...shudders...

Ok it ended up being some sort of logic error as suspected. The digital pin I was plugging in to must have had 2V logic because that was what was reading on the multimeter. I changed it to a different digital pin and it works fine now. Never knew the AVR had so many different logic levels...

Have you configured port D or any of the pins in there differently? It should do 5V.

Hi,

I noticed that your circuit only had high frequency decoupling (the 100nF), which is good, but there should be bulk low frequency decoupling as well. Maybe you already have it and it's not shown.

You will notice that in the LTE-5202 datasheet, they have a large decoupling capacitor (100uF to 4700uF) on the power pin.

MOSFETs are very good at instantaneously sucking energy from the supply to drive the load. The instantaneous power delivered to the chip is limited by the power supply source impedance and the inductance of the power interconnect to the Motor Driver Chip.

The bulk low frequency capacitor acts as a "local battery", much like a large capacitor (1 Farad or more), is located near a car power amplifier to reduce the "local" source impedance that the amplifier sees. It improves the local storage for the amplifier to improve low bass performance. The midbass and high frequency energy source impedance is supplied by the decoupling within the power amplifier.

The load in your case is composed of FET RDS(on) in series with the motor DC resistance. The time frame is governed by the FET edge rate, motor inductance, and interconnect.

The capacitor will also improve the initial torque of the motor as the voltage on the FETs remains closer to the applied voltage during the transient. The FET Bridge voltage droops when the motor is started or moved from a position where it draws higher peak currents. The capacitor keeps that voltage closer (more available current) to the rail voltage over the transient time. If capacitor is not there, the FETs will be starved for energy during that timeframe.

The capacitor could improve stability & reliability too.

Ross

Regarding motor control circuits..

I've been having my own, different, issues here. I'm using a FT232RL USB breakout board to interface to the H-bridge circuits, all controlled from my MythTV box (for Frankenswitch V2).

The problem I see, is that when the motor is under high load (aka. "stalled"), sometimes the FT232R disconnects/reconnects on the USB side, and consequently gets reset by the host. The host is using Linux (of course), and I looked into the low level code there. It's simply the UHCI hardware reporting a "connection change" event, meaning a disconnect/reconnect.

So I figured maybe a voltage brownout on the USB cable was the cause, and then went through a progressive series of increasing the circuit isolation.

Now the FT232R breakout board is still bus-powered, but simply connects to some opto-isolators, using internal (5V) drivers through 10K resistors to the O-I to ground.

The motor controller side of the house is now triggered from the far side of the O-I, and runs on a totally independent PSU, all the way to the 120VAC wall outlet. Not even a ground wire is shared.

The USB now behaves much better, but I can still cause it to disconnect/reconnect with repeated stressing of the motor.

Why?

The obvious guess here, for me anyway, is EMI from the motor, since I'm doing these tests with 6" or less physical distance between the motor and the FT232R.

I suppose a nice grounded metal/foil shield, or simply more distance, should cure this. Or is there something better (yet easy) to also try?

EDIT: Information on the FT232R Breakout Board is here. I have tied pin VccIO to Vcc.

Cheers

Hi,

EMI or EMC work like this is usually performed in an RF tight Chamber or certified open-field test sites, with calibrated antennas, and receivers or spectrum analyzers.

You are in the mode of identifying what the emission source(s) are first. It is either coming from the controller electronics, edge rate of the MOSFETs in the motor driver or from the motor.

The antenna for the emissions is the cable between the motor and the controller board including the traces on the controller board if they are surface routes. The USB cable could also be an antenna if it is not grounded well on both sides. Both sides need to grounded if the frequency exceeds 1 MHz or edge rates are faster than 1 us.

1.0 Servo Noise sources
-----------------------
You need to see if the noise is related to the controller electronics, Motor Driver, or the Motor.

1.1 Controller Noise Sources.
.............................
The controller will have a crystal controlled clock source on it near the processor chip. It divides this clock down and uses it for logic timing for the controller. The clock is used to create synchronous and asynchronous strobes, USB interface timing, and time databuss transaction. The noise will be heard as a whine for steady state clocks, clicks and chirps for strobes and buss transactions.

Note the oscillator frequency that is marked on it (like 4 MHz, 16 MHz, etc, it may be 3.579, 4.000 or 4000k). Multiply that frequency by 2, 3, 4, 5, 6, 7, 8, 9, and write the numbers down. Then divide the clock by 2 and multiply that number by 3, 4, 5, 6, 7, 8, 9, and write those down too. They will be suspect frequencies to look for as controller noise sources.

1.2 Motor Driver Noise Sources.
...............................
The Motor Driver usually makes noise based on the modulation frequency (5 khz to 20 kHz) or the edge rate of the MOSFETs (MHz). The modulation frequency will often be heard as a whine or gated buzz. The MOSFETs will generally be heard on the FM Radio and are usually pulsating white noise.

1.3 Common Motor Noise Sources.
...............................
Generally, the commutation of a common DC motor will generate predominantly broadband low frequency noise (hence, the AM radio for the receiver system) and also recessive high frequency noise from the commutation arcing.

1.4 Brushless DC Motor Noise Sources
.....................................
If it is a Brushless DC Motor, BLDC motors have noise in the higher frequency bands as the motor package re-radiate the conducted noise from the edge rates and modulation frequency of the Motor controller. On a spectrum analyzer it looks like 20 kHz (or the modulation frequency) narrowbands (spikes) spaced at the modulation frequency intervals on a carrier frequency based on the MOSFET Edge Rate. There can be groups of these throughout the spectrum. The edge rate of the MOSFETs determine how high in frequency the narrowbands clusters will go (how many 100s of MHz).


2.0 Sniffing to find the emission source
----------------------------------------
One inexpensive and easy way to see if you are experiencing EMI conducted or radiated emissions is to find an small AM/FM transistor radio (for portability) - digital dial may help too, and move it to locate the source and frequency of the offender. You can tune it from 530 kHz to 1600 kHz and listen for the noise. It is very likely that you will hear a buzzing or whining sound when it is idle or during operation of the motor. If not, check FM band and tune across the band from 88 MHz to 108 MHz.

2.1 Without The Motor Running
.............................
You might want to disconnect the motor for this test if it will not harm the Motor Driver chip or any feedback electronics (like position sense, tachometer, or Hall Effect sensors for BLDC commutation, etc).

2.1.1 Move the radio tuned to the AM band (tuned to 530 MHz) closer to the motor, then to the cable, then to the controller, and see which one is louder. Repeat at mid frequency band and 1600kHz. You might want to scan other frequencies too. If that doesn't show much, do the same thing with the FM band at 88 MHz, midband and 108 MHz. See if any of the frequencies match (are close to) the ones you wrote down.

Any frequencies shown here will likely be controller electronics generated noise.

2.2 With The Motor Running
..........................
You need to see if the noise is related to edge rate of the MOSFETs in the motor driver or from the commutation noise of the motor. These will be heard as a buzz or whine for the 20kHz (or whatever modulation frequency) of the controller, or a frequency buzz for motor noise.

Use a similar method to sniff as above in 2.1.1.


3.0 Source Suppression Fixes
----------------------------
If the noise is a constant whine in the FM band without the motor running, it is noise from a clock, strobe, or bus transaction. This usually has to be solved via shielding or source suppression at the circuit level, with proper signal line termination, local shielding of the controller or offending section. You need to see if it is radiated from the board or conducted through cabling.

3.1 Controller EMI Containment & Source Suppression
...................................................
The first easy thing to do is insulate the board and wrap it completely in aluminum foil, you may have to ground the foil to the connectors. This is called EMI containment. Radiated emissions can cover a large area. If the noise goes away or is drastically reduced, good. If not, do the same thing with the cable that goes to the motor and ground it on the motor and the foil wrapped around the controller board. If this solves the problem, you have a some options.

1) Keep it shielded (wrapped) with small 1/4 inch holes (paper punch) offset spaced 1/2 inch apart will allow cooling and containment.

2) If the noise is coming from the output cable, a ferrite core on the cable of Fair-Rite Corp #43 or Steward Corp. #28 will help. Both motor wires are twisted at 4 twists per inch and the wtisted pair is looped through the core 2 to 4 turns.

3) You may have to create a common mode choke (another email).

4) If the noise is on the cable, it may also help to twist the wires and wrap a shield (copper with tin lead braid - you need the ferrous characteristics of the braid for low frequencies). ground the cable on both sides. Shield termination of 360 degrees is preferred to a wire or pigtail termination.


3.2 Motor EMI Source Suppression
................................
If you do have buzzing noise in the AM band as the motor runs and it is quiet when the motor is running, solutions can be as easy as paralleling a 0.01uF to 0.1 uF ceramic disk across the motor pins (at the motor). This has to be approached with some caution as MOSFETs can dump a lot of current into the capacitor and may increase dissipation in the motor driver chip (there is a finite amount of Power Capacitance MOSFET Drivers can handle).

If it is higher frequency noise you may have to install small ferrite bead-on-lead components on the Motor and/or Motor Driver leads. Same materials and manufactures as above. The worst you may have to do is add "Y capacitors" from each output to ground. This would be another email. The Y Capacitors provide a preferred return path local to the Motor Driver instead of allowing the noise to travel across the cabling (read as - hey, I found an antenna to re-radiate the conducted noise on me) to the motor and return back to the Motor driver.

Sorry again for the long response, but, if you really think it might be EMI, I thought you would like to understand what it, how it is generated, how to find the source, and ideas on how to fix it. This only scratches the surface and there is more that can be done to fix it if it doesn't work. At least this can eliminate EMI as a potential problem and you can focus on code which I try to stay away from <grin>.

I know, I've heard it before - GEEEEK,

Ross

Another vote here for EMI.

I've seen something similar on a project that I worked on recently - but this caused the processor to go off into space. The fix was easy, but it took a while to figure out what was going on.

<off topic>
Was usb designed by sadists? I'd find its poor design & implementation almost funny if I didn't have to deal with i!
</off topic>

Hi,

sn00p Quote:
The fix was easy, but it took a while to figure out what was going on.

Response:
That's why I gave the detail that I did, to help others. There's nothin' worse than EMI Pain...

I also noticed that the schematic he referred to has very little decoupling too. It would benefit from a 10uF capacitor on the USB power side of the inductor. A lot of designers don't consider the Power Distribution System (PDS) and where currents are sourced or returned. Istvan Novak (Sun Microsystems) has a good understanding of it and his website is a good reference for PDS design.


sn00p Quote:
Was usb designed by sadists?

Response:
Yes <sad grin>


Ross

The system I'm having difficulty with, already has a (10nF) cap on the USB power side of the inductor.

The clock crystal/circuit is built into the FT232R chip, and again, this entire USB chip/board is optically isolated from all of the motor electronics. There is no shared ground or signal or voltage lines with the motor driving stuff (also just a single chip).

The motor driver has no clock or frequency to speak of. It's either on, or off, and there's no clock or switching of any kind within that .. just some darlingtons wired as H-bridge, with diodes -- all inside the single chip.

The USB tends to fail when the motor is stalled (not turning, and therefore not generating pulses). Or perhaps the USB fails just before (?) the motor is about to stall, when there may be a rather largish EMI field being output (motor draws about 450mA at 4.8V when stalled, and maybe only 1/10 that when free running).

So the mystery for me really is, how does a stalled motor, on independent circuitry and independent PSU, somehow affect my USB gadget? Yes, it's gotta be EMI, I suppose. Big magnetic field there from the motor at that point.

The FT232R board does *not* have the usb cable shield connected to anything other than the terminating USB socket itself. The cable *is* grounded on the host end, though. It has a 10nF cap from USB power to ground, and some other similar bits aimed at transient suppression or something.

I did once try connecting the cable shield ground to USB logic ground on the FT232R board, and was surprised when doing so made things *much* worse. But that was before I decoupled the motor driver from it with the optical isolators.

Here's the stock FT232 board schematic -- very simple, and probably in dire need of some mechanical shielding.

I take the CBUS0/CBUS1 lines off to a pair of optical isolators, and from there back through 10K to GND. Those pins are powered from the VCCIO line, which I have jumpered to VCC.

End of circuit. The rest is on the other side of the isolators, with it's own 5V PSU, a single H-bridge chip, two LEDs, and a motor.

No I didn't configure anything differently-- I wonder if the Arduino bootloader does this automatically perhaps? The pin I was using (13) is used in all the Arduino tutorials to turn LEDs on and off. 5V would normally kill a small LED correct? Maybe's thats why this particular pin is only outputting 2V or so.

Thanks for the explanation of why those caps are necessary. I did end up putting in a 100uf capacitor in, I will follow it with a 100nf cap as well per your suggestion.

Ah. Pin 13 is special. "We have added a 1K resistor to pin 13, w...in and ground. "

+1

A small DC motor was causing noise on my 1-wire communication network. The PIC was reseting once in a while without reason. It stopped when I placed a ferrite bead on the cable going from my control box to the motor. Took a while to find out what was going on too. That kind of non-replicable bug can be a pain.

Well, adding a largish (1000uF) capacitor to the 3.3V pin seems to have helped a lot.

Not perfect, mind you -- I can still trigger a reset of the USB chip with repeated stressing of the motor, but this is much harder to achieve than before.

I'll add a 0.01uF ceramic alongside the larger one when I transfer the design from the plug board to a soldered product.

Cheers

How close are the bypass caps to the actual chip? The inductance and resistance of PCB traces will affect how effective they are. The 0.1uF should be as close as possible across the pins to ground. If they aren't try a 0.1uF or even a 10nF straight across the pins.

The brute force approach of 1000uF on 3.3V shows you're probably on the right track. I'd try some smaller ceramics instead since the electrolytic (I'm assuming you've used) will have a high ESR. Some 1uF or 10uF decent ceramic caps are likely to help more IMO than your big electro.

A good high speed CRO might catch something on the supply lines but I'm guessing you won't have that. Stick with the filtering.

Got any ferrites? Try running a few turns of the of the CBUS lines. Might stop the ugliness getting in. One thing I've found with EMI/EMC is that often once the noise/interference gets in, it can be hard to get it out, so try and stop it at the "border".

The FT232R breakout board is tiny. It has just the surface mount FT232RL chip itself, and the caps/filters are all within millimeters of it. L1, C1, and C3 are right at the USB connector at the top edge of the chip, but C2 and C5 are a longish way from there.

All of those parts are exactly what FTDI (the chip maker) recommends in their datasheets, but perhaps not quite right for this particular application.

I'll try and work out a metal can or shield for the breakout board, as well as digging out some ceramic discs.

Cheers

Okay, I added some ceramics on the power pins (of the FT232RL board, not the chip itself), and put a bead onto the VCCIO line, and looped the motor wires a few times around another bead.

It merely fails more often with that setup.

Oh well. I suspect the breadboard configuration I'm using may be part of the current problem, it exposes a lot of signals over longer "wires" than necessary.

I'll just have to wait and see what happens when the current design is transfered back to a PCB, with much shorter leads on everything.

Cheers

Isn't the point of breadboarding to work out the bugs *before* you go to PCB?

Oh well. Still worth trying. Some series resistance in te CBUS lines might help. The issue is that you're still not 100% certain "where" it's getting in exactly.

Is that with the 1000uF still in place?


To some extent yes, but when you're having EMI/EMC issues, using breadboard/veroboard you can't always fix things. It does let you "play" with solutions much easier though.

Things like radiated/conducted emissions can be greatly affected merely by PCB layout. Short (and long) tracks can make massive differences. And immunity is often closely related to emissions.

Another idea: /RESET doesn't have any external circuitry. I haven't looked up the data sheet but I'm guessing some kind internal pullup is inside the FT232R. Unless it has a proper reset circuit in there.

Perhaps it's sensing a reset? A small external cap (0.1uF for a start) and maybe a pullup resistor might help filter the reset line better. 10k and 0.1uF has a time constant of just 1mS so I doubt it will affect the start up when you plug in the USB. It probably wouldn't matter if it was held in reset for a bit initially anyway.

Yeah, I really need a storage scope here, to find out what's actually happening.

But for now, I've just reworked the breadboard to shorten wires and the like, and it seems much improved. More later.

Ok! So break out the Altoids tin already.

You know You want too.

Mmmm... so long as I use a totally independent power supply for the motor side of the house, it works flawlessly now. Well, except for once in a very blue moon, when I force the motor in reverse while the current tries to drive it the other way, but even then it takes a few dozen attempts to glitch it.

That's on our MythTV box, which has an undervoltage PSU (4.8V on the "5.0V" line). On my notebook (which has 5.1V on the 5.0V line) I cannot glitch it in that way.

It's good enough now, but I really don't want another wall wart in that room. Powering the motor side directly from the 5V line of the ATX PSU in the box can still glitch it. So I may try a 12V line instead, and use a 7805 to step that down to 5V on the motor board.

The saga continues..