USB causing ground loop noise

eagletalontim

This has been an issue I have been battling for awhile now and I need to see what I can do to completely resolve my issue. I am using the FTDI FT232R IC on my board and it is powered by the on board power supply. For some reason, I believe, the Data LED's are causing noise on my ground plane. This is interfering with my RPM signal and my ADC. The RPM signal is currently a 5V signal that is passed through a 150K resistor and a 300K resistor (to ground) which drops the current and voltage to the prop pin. The ADC has a 0.1uf decoupling cap and is connected to the prop directly except for the data pin which is separated from the prop with a 10K resistor (Just for safety. I know it could be a 4.7K).

The FT232R is wired EXACTLY like the schematic on page 24 on the data sheet located here : http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf The LED's are connected to the FT232R just like the Prop Plug's schematic located here : http://www.parallax.com/sites/default/files/downloads/32201-Prop-Plug-Documentation-v1.3.pdf

Maybe I have the capacitors too far away from the FT232R? I have tried adding another 0.1uf cap to the 232's incoming power since I must have left it out on the first board design. This did not help at all. The "shield" of the USB plug is not grounded either. There are no filter caps on it either. Should I have some sort of filter cap on the USB jack's body to ground?

eagletalontim

Ok, I have disconnected the LED's from the loop and the noise actually seemed to get worse I was hoping to disable output from the "C" pins on the FT232, but there does not seem to be an option to do that. Am I supposed to put some sort of filter on the RX and TX lines in from the USB port?

shimniok

Any chance you could post the board layout?

eagletalontim

Ok, here it is. Please don't laugh.... This is only my second ever board I have designed. Some things on this layout are incorrect and I have not made the changed to the design yet.

Things that are changed :
Added 0.1uf cap next to C4 and C5 (Top close to FT232 IC)
Reversed all pins on the USB jack (Top Left).
Removed Mosfets that were installed backwards....

I have attached the component sheet as well. If you want to view it in Excel, change the extension to .cvs

If you need to see the bottom of the board, please let me know as well. There are no components on the bottom and all ground plane areas connect.

eagletalontim

I just tried to connect the 5V PWM signal to the Prop pin using a 10K current limiter and it seemed to have stop all "glitches". The "RPM" signal is currently going through a 150K resistor and I did have a resistor going straight to ground to make a voltage divider, but I removed it for testing purposes. By bypassing the 150K resistor and using a 10K resistor instead, the "glitch" did not appear through the output of my VB program. While the board is powered up, the VB program constantly retrieves data and outputs it to the screen. While watching my "RPM" signal, it would randomly go from 3999 to some random number like 1234189123 for 1 "reading" and then go right back to 3999 where it should be.

tonyp12

You are not using a Ground plane?, but daisy chained traces for ground?
If you are going to use traces when all traces should meet at one spot (like a trees branches meeting at the trunk)

Analog parts need a quiet area on the board, so put that on a corner/side
then on the ground copperpour use keepout (or signal traces if they are nearby) to isolate this part of ground from noisy main ground
and make it so it only meets up close to the main ground connection.

Don't use car chassis as ground but run a thin wire all the way back to the battery.

Power connections should also have the tree branch pattern.
Think of electricity as water.
One device is using a lot of water, but all the sudden stops doing it and if the pipe is daisy-chained to the next smaller device
then the water (electrons) wants to keep going in that direction and will force a spike on this smaller device.
And when the bigger device start using a lot of water again, the smaller device down the line may see a brownout.

eagletalontim

There is a ground plane, I just don't have it "filled" so you can see the bottom traces. Some of the ground connections are visible because I tried that "Auto router" feature in Diptrace and that was a mistake. Just did not go back through and clean them all up. There is a top and bottom ground plane. I tried to keep the 12V to one side, the 5V to one area, and the 3.3V to another area.

shimniok

Wow, my 2nd board had like 4 components on it That's really ambitious.

The 'glitch' ... a code bug? Can you look at signals with an oscilloscope? That'd help, no doubt. Was the 'glitch' actually the maximum value for the ADC? Or was it a truly random number? Or any pattern at all? Can you graph the readings and show that graph? That might help.

What's generating the RPM signal? How much current can/does it drive? By hooking it up direct to a prop pin Thru 10K, the impedance the rpm generator sees is going to be quite high, I would think. Versus what it'd see with a voltage divider. I'm not exactly sure how that'd result in these strange random glitches in the readings.

it might be worth going with more of a star pattern on the power side, with bigger traces, like 0.016 (Adafruit Playground app can help you calculate what's actually needed).

Erik Friesen

Maybe someone mentioned it already, but I don't see any bypass caps by the propeller. Shoe horn them somewhere. one .1uf by each power pin pair.

Mark_T

300k is too high an impedance for a logic signal, it will pick up nearby signals - change your voltage divider to something in the 10k range
to harden it against noise perhaps?

For good ADC performance you need some proper decoupling at audio frequencies, 100uF on Vcc and AVcc perhaps. Keeping analog
circuitry away from digital and separating AVcc from Vcc with an RFC or at least 20 ohms or so can make a difference if those electrolytics
are there.

USB power will be very noisy compared to a battery supply BTW, since computers use switching supplies.

eagletalontim

I only have 1ea 0.1uF filter cap on the Prop since that was all the protoboard had and my circuit was working from the protoboard and about 4 different breadboards / radioshack PCB's. Apparently when you add USB and squeeze it in a small space, noise starts to become an issue. I may add 3 more to the next set of boards if I can squeeze them in.

The glitch is for sure not a code glitch as I have been able to solve it with changing hardware. On the protoboard, I was using a 100K / 100K voltage divider on the RPM signal and it seemed to work perfectly, I was just hoping to allow for a 12V RPM signal as well instead of just a 5V signal. Since the Prop can sink a maximum of 500uA, I need to stay under that and need to calculate for a maximum of 16V or 18V pulse. So, a range from 4.5V (Minimum voltage) to 18V is pretty large and I would like to do it with just resistors and 1 prop pin.

The ADC is accurate enough for what I am doing with it and if I pull the input down to ground with a 1M resistor, it is actually really steady. I don't have this set up on my current board though, but I am keeping a list of what all needs to change. The ADC is actually very close to the header ground pin.

As for watching the ground loop on an O-Scope, I have done this and there is a 26mV ripple that happens when data is either sent from the FT232 or when it is received. When data has stopped being transferred, the ground plane is quiet as can be.

tonyp12

So it's only happens when you use USB, it could it be that what you are plugging in does not have same level for ground.
Is even pin4 on the usb connected to the boards ground?, don't connect shield to the board that is the host sides job.

Ground the car ground to earth and plug in the laptop with a A/C cord, does that help?

Best option, isolate the ftdi chip.
Let it get its power/gnd from usb host only.
Run RX/TX through a:
http://www.mouser.com/Semiconductors/Interface-ICs/Isolator-Interface-IC/_/N-62fhbZscv7?P=1z0z7ptZ1z0x0qu&Keyword=1%2f1&Ns=Pricing%7c0

For reset use a 1nf cap in series to Prop-reset and invert in RST inside the ftdi.

shimniok

26mV ripple... So 5V down to 4.74V ?! Wow. To me that says that there are some major switching current spikes from the FTDI that drop the supply voltage (locally or otherwise) due to too much resistance on the + or - side. I think bigger power traces distributed from a central point will help. Given that it works on the protoboard.

Having 0.1uF and maybe 1uF even 10uF cap for the FTDI chip also with big traces (16 - 24 mil) surely will help.

Also, what happens if you get rid of all 90 degree bends in your traces?

Finally, how about using a unity gain op amp circuit to buffer your analog signal? That ensures high input impedance seen by the analog source and low output impedance seen by the ADC.

Are you using a ratiometric ADC? Or what's the analog reference voltage generated by? If you're using a ratiometric ADC, the bits generated will depend on the supply. So if the supply sags while the analog signal doesn't, it causes glitches. If you instead use an ADC that references an absolute voltage, then use a reference IC, I would expect the results to be more stable, certainly much less dependent on supply (I've never done this but ...)

JLocke

shimniok wrote: »

26mV ripple... So 5V down to 4.74V ?!

Think you lost a decimal place there... 5.000 - 0.026 = 4.974 (however, 5.00 - 0.26 = 4.74).

shimniok

JLocke wrote: »

Think you lost a decimal place there... 5.000 - 0.026 = 4.974 (however, 5.00 - 0.26 = 4.74).

Heh, yeah. See how I am? I can build complex robots but carelessly goof up the decimal places if I'm not watching myself. Sheesh.

So anyway, 26mV will wreak havoc on a ratiometric ADC if the noise only affects the local supply and not the source of the analog signal. And it is kind of a lot of noise, really... you should see the kind of noise you get on the supply rail of a Sharp IR sensor. Try doing analog to digital conversion on that... I have. It's ugly. I found a nicer result using by oversampling and simple filtering in software.