Where is all this noise coming from?

Community General Discussions
,
1

Hey folks,

I am finally getting around to Walter's autonomous drive mode and have run into a noise issue. It seems that my motor driver (this one) is affecting my sharp IR sensors. I am still running the motor driver off of a 14.4V DeWalt drill battery as I can't afford proper batteries yet (I don't know if that makes a difference). The Picaxe 40x1 is powered by 5 AA's with a 7805 regulator (included with the regulator is a 220uf+ cap, a 10uf+ cap and a 100nf ceramic cap in a regular configuration). Of course, the regulator and motor driver share a ground. It seems, with the motor battery disconected, my sharps are a-ok spitting out a value of about 10 or so with nothing in front. However, when the motor battery is plugged in, they jump up to about 50 or 60 (on average) while fluxuating as high as 80 and as low as 1 in short bursts. Even more odd, when the motor driver battery starts going dead, the problem seems to be resolved. Is there a way to isolate the motor driver or can I get rid of this noise another way? Big caps somewhere, maybe?

2

Issues with Sharps can

Issues with Sharps can sometimes be resloved at the sensor. Here’s a related solution for a different problem, that still might work in cleaning up the Sharps.

Also, a note from another source :

Note: it is very important to put a good capacitor (something like 22uF) between GND and Vcc, directly on the sensor itself, in order to reduce the noise on the 5V power supply due to the current required by the emitting LED. In the other hand, avoid the use of a capacitor between the signal output and GND or Vcc: it may dramatically reduce the sensor dynamics (low pass filter).

I know these aren’t the same as what Walter is doing, but I think they might help isolate power issues anyway. Another possiblity is to place a good inductor on the ground connection between the motor controller and the rest of the grounds.

3

Elaborate…
Could you give me a run-down on this inductor you speak of?

4

Here’s a possible, 22uH
Here’s a possible, 22uH inductor at Digikey. Looks sorta like a blue resistor. Devices like this are often use to smooth out the reference supply voltage to get accurate measurements on ADC devices. The 22 micro Henry is a sorta WAG based on 19 kHz noise. Note that inductors are also called chokes by strange shirtless people on other hemispheres. The ferrite that Oddbot also mentioned is also a good possible addition as well, again on the tie between the ground between the 2 sides.

5

Noise Noise and more noise
Hello CTC,<o:p></o:p>I thought of a couple of points to add.<o:p></o:p>Electric Motors produce a lot of noise; one of the major issues is the spikes caused by the field current collapse, either during the trailing edge of the PWM Pulse or the brush moving to the next commutator<o:p></o:p>These spikes can be very high voltage; normal practice is to place diodes to shunt any over voltage. Other than the noise reason; these are used is this voltage can easily cook the electronics driving them, the same thing happens when the current is removed from a relay. The reason I brought this up is that it does not look like your driver board does no have flyback diodes on the relays. Now this is not the source of your noise, you would get a glitch when changing the motor direction.<o:p></o:p>Now the advice you have received from Robologist is spot on but there is perhaps another source of noise which needs to be considered.<o:p></o:p>When your Microcontroller starts to out put the PWM stream the current demand of the Microcontroller will put a noise signature back on the supply rail. This may be propagated to the sensor and shows up in the signal. This can be corrected by a small decoupling capacity mounted across the rails as close the Microcontroller as possible, I normally do this with most chips especially TTL.<o:p></o:p>A quick check might be to remove the motor board put say a 0.5KΩ resistor across the PWM and relay control ports (on your microcontroller board) and see if the problem goes away, if it does it is noise from the motor control, if is stays put a few decoupling caps (0.1-µF ceramic). Oh and I would put the Flyback diodes across the relay coils (get them around the right way :wink: ).<o:p></o:p>All the best<o:p></o:p>

 

6

CtC is using BOAs Brilliant
CtC is using BOAs Brilliant Hybrid H-Bridge Robologist Mod on Walter, that has the flybacks on. I had not thought about the relay coils themselves though, possible noise. But the noise is seen when the motor battery voltage is up, which seems to point all to a possible ground loop between the 2 sources. The test you prescribe sounds like a great trial to run. Good idea on the bypass caps too, good to have a collection of 0.1 uF just to drop in near every chip, though I think the PICAxe board might have them already.

7

I think it may be the relays

Now that you mention relays, I noticed that the problem seemed to be self-increasing. As the sharps were affected (and the code recognized an obsticle) a relay would click (per code) to turn the bot away. When this happended it seemed as if the relay click/ sharp affected/ more relay clicks pattern grew worse and worse.

Questions (or a little more clarity):

In terms of adding flyback diodes, I am to assume I can use the same units and configuration as the ones on the main motor connections, correct?

In general, I really can’t go wrong with 0.1uf ceramic caps on all power in and out of the picaxe. Thats a cap bridging + and GND.

Could I get a little clarity on the test with the 0.5k resistor on the PWM and rev. contacts? Just a little step-by-step on where-to-where the conections should be made.

One more: I looked at 4 channel optoisolators… Would this solve my problem entirely? Pros/ cons? And if this is a good direction to go, could you suggest a part number? All the ones I looked at did not support a 5V input and had a high in/low out set up which would require some transistors to switch it back.

 

Thanks in advance, guys – I really appreciate your guidance and knowledge.

8

For flybacks on the relay

For flybacks on the relay coils, you’d only need something common, like a 1N914, or 1N4148, as the relay coils do not carry a lot of current.

THe 500 ohm resistors are used in place of your connections to the h-bridge. Wire each PICAxe pin to ground through the resistors, run your code, and see if the noise shows up on the Sharps. If noise on the Sharps with just resistors on outputs, then the PICAxe needs some caps etc. If no noise, then the relay h-bridge needs noise suppresion.

The PS-2501 opto used in a similar h-bridge Brooksware did could work decently, probably need an added transisotr on the output to drive the driver and relays sufficiently.

 

9

I think it may be the relays

Hi CTC,

 

Robologist has provided answers for most of your questions so I will just add a comment or two.<o:p></o:p> First, do you own or have access to an Oscilloscope? If you do or can a photograph of the signal out of the Sharp IR distance sensors will tell us what is going on, flyback noise and switching noise have distinct traces compared to ground loop type noise.<o:p></o:p>There is a lot of software around to properly analysis this sort of problem but many older engineers just resort to one decoupling cap per TTL Chip. I ran in to a similar problem with the Sonar I am building, the transmitter put switching spikes on the power rails, two caps later and it was gone.<o:p></o:p>Optocouplers may resolve the noise but I doubt it, I think the noise is not coming back via the signal path (PWM/Relay control) but is being superimposed on the power or ground rails, if you use optocouplers you could completely separate the power supplies and ground rails.<o:p></o:p>Check your code and make sure you are not sending PWM to the relay control, if so you have just created a spark ignition system with no diodes (flyback voltages).<o:p></o:p>We will get there in the end.<o:p></o:p>

 

10

One more thought

Hi

Is it more noisier with the motors running in one direction or the other, ie relay in or out.

11

One way or another,… it gunner get ya

Hi Chris,

That is a little weird, what type of motors are you using? Motors for RC cars often have the brush timing altered

to increase the performance in one direction (forward), I have never looked at this but I guess there might be a

difference in the noise produced.

Do the motors run at the same speed in both directions?

On thing which I would suggest you check is the flyback diodes are soldered ok and are working

(use a multimeter with the power and motors disconnected). Another test is to run the motors for awhile and feel

the diodes if you have a hot one it is probably backwards but I would expect if this was the case the motors would

run noticably slower in one direction.

all the best

Cliff

 

12

How often?

I would really hope the relays aren’t flicking so often as to cause any appreciable noise. I know I didn’t publish any code, but I have a deadband in the DPDT changeover so it doesn’t vibrate when close to "stop."

My money is on the motors themselves causing the noise.

13

Ooooooh!

This is defo the case with the wiper motors for which the original controller was designed. The speed difference between forward and reverse is phenomenal. It’s about 15%. Which was really irritating because to get big chaser to go in a straight line, one of the motors needs to go backwards.

Actually, now I think about it, with my algorithm, one of the motors is always PWMing. That might be the key. Chris, are you using a fixed PWM frequency? I use a technique called “bit twisting” where the PWM frequency changes depending on the mark to space ratio. I would gess that if the PWM frequency is constantly changing, it acts as a filter, disallowing any “reverberation” from being set up which might amplify any interference.

Any of you electronics geniuses ever seen this before?

14

Exactly what I have.

I have the exact same issue… and about 15% as well. Now to be honest, some of what you guys are suggesting/bringing up is a bit over my head. I do not have an osiloscope (or access to one) and really, I am an artsie not a techie. To give you a little background: First I am a builder but in my past I was a model airplane guy and more importantly, I was a huge car-stereo guy. In terms of electronics, I picked up most there (ohm’s law and the like). For the most part, when you guys suggest something, I can test it (with clear instructions) and I figure out the lesson only after I have done it in a physical sense (any on-paper theory doesn’t do much for me).

Now, riddle me this Batman… In terms of “brush timing” and running slower --also BOA mentioned his motors were themselves “PWMing”. The only thing I can equate this to in my brain is harmonics in an engine. Without a harmonic balancer, the harmonics keep increasing on themselves untill failure. Is this even close to an analogy for the “reverberation” BOA speaks of?

In terms of my sent PWM, I am sending this:

pwmout 1,63,0
pwmout 2,63,0

main:

pwmduty 1,b5

pwmduty 2,b6

 

The b5 and b6 are controlled by either the auto-drive code or from the RC unit. To “straight-line” the unit, I am simply slowing the fast wheel with a b6=b6 max (X). For frequency, I used the picaxe wizard to figure out what frequency would lead to b5 and b6 going from 0 to 255. At different times I have changed this to go from 75 to 225 for obvious reasons.

 

As I sit now:

I have found that the pic and motor driver are happy (with no caps anywhere) when simply using RC drive code. I have done this with a pulsin (coming from the servo out on my RF RC unit) and also from another picaxe (with a joystick) spitting numbers out serial to serial. The noise issue, and this thread, started when I started to code Walters auto-drive and that’s when I noticed the issue with the sharps spitting out crap numbers. --I also noticed my SRF05 doing the same. I have taken the capacitor adviceand simply added one to each sharp across + and gnd. This seems to have solved all problems with the sharps (obviously going into ADC channels). I have yet to play with my sonar, but my assumption is I will find the same. I have not yet added diodes to my relays, although I will probably do so as more protection couldn’t hurt, and I have double checked that the flyback diodes on the motor-outs are a-ok and going the right direction per BOA schematic.

I think that is it for now, my main problem of bad ADC data has been solved, and if I find a similar issue elsewhere my standard opperating procedure will be to add a .1uf cap. If this “noise” wants to rear it’s ugly head again elsewhere, I will be sure to ask again. I am glad I am able to bring some fodder for geek brains out there to work on! Thanks for your help, folks.

15

Dude, please make more

Dude, please make more breaks in your text, like this:

Have you any unused analouge in’s on your Pic? If so, I’d recomend shorting those, as I have experimented that not doing so causes strange readings in situations just like the one you describe.

From start here-robot:

how_20to_20start_20a_20robot_html_2805b34a.jpg
how_20to_20start_20a_20robot_html_2805b34a.jpg436×500 31.1 KB

(read more on the page, you know where to find it :)

16

Good point
I’m not sure what hardware is on your picaxe board, but I’m pretty sure ai read in teh PIC manual that it’s good practice to pull unused inputs to ground. For heaven’s sake make sure you don’t pull OUTPUTS to ground!

17

Shorting Unused Pins

Hello ChrisTC,

Arties are cool, I think we all want to help were we can, the beauty of such forums is that it is the basis of a Collective Intelligence.<o:p></o:p>Being a techie, I thought I would throw a few more points:<o:p></o:p>Shorting unused pins, this is common practice on unused pins of various chips; the reason is if left unconnected, they can generate quite a lot, imagine say the input of an OR gate being allowed to float, the electrical noise would cause the out put to flap between 1 and 0, not good.<o:p></o:p>Now the caution, in many microcontrollers the ports can be configured as Input, Output or ADC, now shorting to ground or power should be ok for Input or ADC should be fine but if you accidentally configure the pin as an Output and you output a 1 (or the default value) with the port tied to ground (or vice a versa), the Microcontroller will probably burn the port out (over current); so the safest way of tying the ports is to use 1k resistor. If the chip in question does not support the pin as an output it does not matter.<o:p></o:p>Now PWMing, if your Pulse Width Modulation frequency is too low you get a buzz in the motors, the efficiency is not very good, as you increase the PWM Freq this buzz will go away however if you go too high the motor controller starts to burn power, I run at 10Khz with no problems. One approach to optimising the controller/motor is to measure the drive current (thru controller and motor) hold the motor speed constant (pwm width) and adjust the PWM Freq for the lowest current. Note very low PWM Freq and the motors will run erratically.<o:p></o:p>

all the best

18

PWM frequencies
The object of PWM frequencies is first to get above the mechanical time constant of the motor, then to also get above the electrical time constant. The mechanical is pretty easy, something in the 100s of hz can do so for most motors, inertial reaction time being somewhat easy to overcome. The next, electrical, can vary quite a lot with different motors, based on the inductive nature of the devices. While 10 kHz may be adequate for some cases, in a couple decent quality Pittmans I have it will cause the motors to "scream". This is not an efficient operating frequency for those motors. For high quality coreless motors, PWM frequencies can be 60 or even 100 kHz. Industry standard to operate most (except coreless) motors is to go for 20 kHz, getting beyond human hearing range. The best way to ensure the drive controller is not burning power, is to use/design a high quality driver that can operate well at the frequency required.