GP2Y0A2YK0F Sharp Distance Sensor

[Commanderbob]

Glad this helped someone  . I have not tried it with my microcontroller yet. I have also messed with some other values for the capacitor and any less and you get some noise and any more it does not really help with noise but makes the rising/falling edges longer. The resistor value is not so crucial some where around 500 ohms works good. That allows the capacitor to discharge faster. A smaller value may be a bit better, I have not tested it.

Admin you said your scope could not find a pattern in the spikes. When I set mine to peak detect it found that the spikes happen at around 1KHz. Each spike has the same shape a little spike flowed by a -320mv drop, then the larger spike that has a tail that lasts for about 1.5us. The whole glitch has a length of 1.75us.

You can sample the sensor faster then 40ms. You will get the same voltage, it won't cause any errors.

OK, I took some pictures with my camera, they will have to do until I get a USB drive for my scope.

Here is a closeup of one of the spikes.

This is what the signal looks like with peak detect setting.

And here is the signal with the capacitor/resistor attached.


Justin

[bens]

Just out of curiosity (and I apologize if you have already answered this earlier in the thread), do you have a bypass capacitor of 10uF or more between Vcc and ground somewhere near your sensor?

It seems to me like the easiest way to deal with noise from the sharp sensors would be to simply average readings over perhaps a 10 ms period.  Given that the refresh rate is greater than this, you're not losing any response time by doing this, and you're pretty much negating the impact of the glitches and other noise that might be overlaying the signal.

- Ben

[Commanderbob]

Actually I did not put a cap on the power line. I powered it with +5V from USB on my computer. I think I posted this somewhere else but the Sharp IR sensors seem to take large bursts of power that causes the microcontroller to reset.

I just checked to see if that helped and it did absolutely nothing on the read out.

You could do as Admin said earlier and take multiple readings then use an algorithm to cancel the noise. That works OK but it has a two major problems.
1) Processing time, your microcontroller has to take multiple readings and then figure out which readings to average.
2) Sensor changes, if you take readings while the sensor is changing its output then you will get the wrong data.

Here is a picture of what I mean. This is the output as I move my hand up and down over the sensor. You can see each step is about 40ms.

[bens]

Actually I did not put a cap on the power line. I powered it with +5V from USB on my computer. I think I posted this somewhere else but the Sharp IR sensors seem to take large bursts of power that causes the microcontroller to reset.

The datasheet recommends you use such a capacitor to protect your power line from these bursts.  I was wondering if it could also help smooth out the output just by smoothing out the supply.

I just checked to see if that helped and it did absolutely nothing on the read out.

1) Processing time, your microcontroller has to take multiple readings and then figure out which readings to average.

In general you should always be taking multiple analog readings to protect yourself from noise.  Since the ADC runs in hardware, you can have it set up to be constantly measuring and averageing in the background, which will take up almost none of your CPU's processing time.  I don't think it would be necessary to devote any resources to figuring out which readings to average: just average all the ones you get in some block of time of predetermined length, such as 5 or 10ms).

2) Sensor changes, if you take readings while the sensor is changing its output then you will get the wrong data.

Basically you'll get the same kind of result as with a capacitor during the time period that spans a step: you'll see a weighted average voltage somewhere between the high portion of the step and the low portion of the step.  If you're averaging results over a period of time that's several times smaller than the sharp sensor's refresh rate, your average values will usually be as correct as they can be given the sensor's refresh rate, or they will at least be smoothly inbetween steps.  Given that your algorithm already has to deal with the notion that your sharp sensor output might be 40ms behind reality, I don't think this step-averaging effect will be too significant.


- Ben

[Webbot]

Request to Admin

There seems to be an endless number of threads covering Sharp IR detectors, noise etc. Some give potential solutions in hardware (with caps and resistors) and others give noise filtering solutions in software. It would be good to try and consolidate all this into "best practice" in the tutorials to try and consolidate all these threads and "head off" new ones with some kinda generic approach.

Appreciate your busy - but a holistic solution, that can be referenced in posts, will help us all trying to keep disparate threads up to date and cross referenced. As I understand it - this problem is common to all Sharp I/R devices - so it's not like we need different info for each device.

[Commanderbob]

Webbot I think the best solution is to use a combination of both. Ben is right ADC should be sampled more then once, but you should also have the cap/resistor combo to prevent the spikes as they will throw your average off. The larger spikes got up to 2V more then the correct reading.

Thanks,
Justin

[Webbot]

Commanderbob :- I'm not suggesting what the best answer may or may not be - I'm just suggesting that a 'unified' answer to the zillions of posts in the forum, in this thread and MANY others, is linked to the Sharp IR Tutorial. Otherwise newbies, let alone anyone else, will search the forum and be reading for days on end.

Its hard to see the wood for the trees.

[bens]

Webbot I think the best solution is to use a combination of both. Ben is right ADC should be sampled more then once, but you should also have the cap/resistor combo to prevent the spikes as they will throw your average off. The larger spikes got up to 2V more then the correct reading.

But the duration of the spikes is miniscule compared to the noise-free portion of the signal, so their effect on the average will pretty much be negligible (assuming your ADC sample rate is around 10 kHz, so you get plenty of samples in your average).  Averaging in software is for the most part functionally identical to using an RC filter to average/integrate in hardware.  Just as the voltage spikes will raise the software average slightly, so will they raise the average sensor output voltage if a capacitor is used to filter the noise.  My personal opinion is that it's sufficient for one to just use either the hardware filtering (capacitor) or software filtering (averaging).  Which one works best for you will depend on whether you'd rather sacrifice a few CPU cycles or modify your hardware/sacrifice prototyping space.

- Ben

[Admin]

Admin you said your scope could not find a pattern in the spikes. When I set mine to peak detect it found that the spikes happen at around 1KHz. Each spike has the same shape a little spike flowed by a -320mv drop, then the larger spike that has a tail that lasts for about 1.5us. The whole glitch has a length of 1.75us.

The little spikes had a pattern, but the larger ones were completely random (see my earlier pic).

It seems to me like the easiest way to deal with noise from the sharp sensors would be to simply average readings over perhaps a 10 ms period.

taking an average still isn't perfect:
http://www.societyofrobots.com/robotforum/index.php?topic=2712.msg19663#msg19663
I'd rather do it in hardware with the cap + resistor, anyway.

Request to Admin

There seems to be an endless number of threads covering Sharp IR detectors, noise etc. Some give potential solutions in hardware (with caps and resistors) and others give noise filtering solutions in software. It would be good to try and consolidate all this into "best practice" in the tutorials to try and consolidate all these threads and "head off" new ones with some kinda generic approach.

Appreciate your busy - but a holistic solution, that can be referenced in posts, will help us all trying to keep disparate threads up to date and cross referenced. As I understand it - this problem is common to all Sharp I/R devices - so it's not like we need different info for each device.

Entirely noted. As soon as I get time I'll do this.

But the duration of the spikes is miniscule compared to the noise-free portion of the signal, so their effect on the average will pretty much be negligible (assuming your ADC sample rate is around 10 kHz, so you get plenty of samples in your average).

Too processor intensive . . . and if you have a low sample rate, and a large spike gets into your average, it will throw it off.

Which one works best for you will depend on whether you'd rather sacrifice a few CPU cycles or modify your hardware/sacrifice prototyping space.

My plan was to solder the resistor + cap directly onto the back of the sensor. Probably 10 min of work tops

[bens]

Too processor intensive . . . and if you have a low sample rate, and a large spike gets into your average, it will throw it off.

It's not processor intensive at all given that the ADC functions in hardware.  If you clock the ADC at the I/O clock / 128 and note that the ADC takes 13 clock cycles to perform a conversion, you get 1664 instruction cycles (so maybe 1000 instructions) for every ADC sample you receive, and adding that sample to a running sum and starting the new conversion is what, maybe 20 instructions at most?  The burden this adds to the processor is maybe 2%.  Running the ADC constantly is one of the least processor-intensive things you can do on an AVR (assuming you aren't deliberately delaying the processor while the conversion is taking place).

As far as a large spike throwing the average off, as I said in an earlier post, the degree by which it throws the average off will basically be the same as the degree by which the voltage is thrown off by the presence of a capacitor.  The capacitor is doing in hardware the exact same thing as a software average (assuming you have enough data points in your average to approximate the continuity of an integral).  The only time a software average will perform worse than a capacitor is if you do something like in the thread you linked, which is to take only five readings and get unlucky enough to have a spike in the middle.  In the case of the sharp IR sensor, where the update rate is limited to maybe 25 Hz by the sensor itself, there's no reason not to take on the order of 100 samples per average, which would pretty much mitigate the presence of any large noise spikes to the same degree as a capacitor.

- Ben

[Commanderbob]

The capacitor is doing in hardware the exact same thing as a software average (assuming you have enough data points in your average to approximate the continuity of an integral). 

That is not true at all. It would only be true if you did not have the resistor in parallel with the capacitor. When there is a spike the capacitor absorbs it and there is only a little increase in voltage. Then the capacitor is allowed to discharge the spike though the resistor effectively reducing noise and keeping the original signal.

My plan was to solder the resistor + cap directly onto the back of the sensor. Probably 10 min of work tops Grin

That was my plan too.
Bens would that be so hard? You could get a surface mount capacitor and resistor that would fit right between the pins.
Justin

[bens]

That is not true at all. It would only be true if you did not have the resistor in parallel with the capacitor. When there is a spike the capacitor absorbs it and there is only a little increase in voltage. Then the capacitor is allowed to discharge the spike though the resistor effectively reducing noise and keeping the original signal.

Your statement is incorrect.  An RC filter in this case acts as an integrator of the noise.  The output is identical to a software integration of the signal, which can be approximated via an average.  Every noise spike bumps the voltage slightly (this is because the RC filter smooths it out greatly, but the down side is that the voltage stays slightly above the real signal for significantly longer).  If the frequency of the noise spikes is high enough, your voltage output will always be slightly higher than the actual signal.  This is exactly the same result as you get when you add up all of the values over time and divide (i.e. the noise spike is smoothly distributed over a much longer time scale, leading to a voltage reading that is slightly higher than the signal).

Don't think that an RC filter gives you free and perfect noise suppression, because it doesn't.  It is doing in hardware what can easily be duplicated in software in this particular case.

Bens would that be so hard?  You could get a surface mount capacitor and resistor that would fit right between the pins.

It wouldn't be hard, but neither would the 10 lines of code it would take to accomplish this on on an AVR.  In my mind, the two solutions are functionally equivalent and it's just a matter of personal preference deciding on which one to use (for example, maybe you don't have surface mount caps and resistors in the right value range on hand).


- Ben

[Admin]

Yea but software has a limited sample rate, and takes at least "2%" of processing

Anyway there is another point missed: that noise is going to interfere with other nearby sensors

[bens]

Yea but software has a limited sample rate, and takes at least "2%" of processing

I sense a note of mockery in this.  Are you not as fond of theoretical software calculations as you are of theoretical mechanical calculations?    As far as the limited sample rate, on an AVR it's still more than sufficient for getting accurate readings from the Sharp sensors.

Anyway there is another point missed: that noise is going to interfere with other nearby sensors

I could be wrong, but I don't think it will interfere with nearby sensors in any significant way (any more than high-speed serial communication interferes with nearby sensors).  I think the much bigger source of interference would come from not having a capacitor across the sensor's power and ground somewhere near the sensor as the sensor's large power-drain spikes will create system-wide power disturbances.

- Ben

[Commanderbob]

I got some unexpected data for you guys. Before I show it I want to say that the measurements were taken with the IR sensor in a box, dark and the same distance away from the sensor. The vertical divide and the horizontal divide was left the same for all 3 shots.
Here it is...
Standard spike signal measured at 1.40V

Sensor with a capacitor on the output, signal still 1.40V, the spike is a different shape.

Sensor with RC filter, signal drops to 1.29V

I had to move this one up a bit so it was still on the screen.

Also note that this was with a 0.1 uf cap. (I could not find the small one I recommended) I will update this once I get one.

Justin

[bens]

What value resistor did you use and can you explain how you connected everything?  Putting a resistor on the sensor output is going to raise your output impedance and, depending on the magnitude of the input impedance of your measuring device, will throw off your readings somewhat.  When measuring voltages, you want to have as small an output impedance and as high an input impedance as possible, so you might want to use a larger capacitor and a smaller resistor.  Or maybe something else strange is going on.

- Ben

[Commanderbob]

The resistor and the capacitor are both connected to ground and the signal line. The sensor can put out quite a bit of power, it can light a LED.

I found the capacitor I recommended before and a 450 ohm resistor. Here is the output. The first row is zoomed to see each spike and the second row is zoomed out to see many spikes. The first column is just the sensor, second is just capacitor, and third is capacitor and resistor.



The mean is the average so that is what you would get with the microcontroller if you manage to get 1GS/s. (thats what the scope is )

Justin

[bens]

If your resistor and capacitor are both connected to ground and the signal line, then you aren't using an RC filter.  In an RC filter the resistor and capacitor are in series, which lets the resistor limit the flow of current through the capacitor.  What you are describing is a resistor and capacitor in parallel, and the effect is that you are putting a very strong pull-down resistor on the signal output, and then filtering that with a capacitor.  This would explain why your third column is 20% lower than what it should be.  You definitely don't want a pull-down resistor on an analog voltage signal.

The mean is the average so that is what you would get with the microcontroller if you manage to get 1GS/s. (thats what the scope is )

Given that signal, I'd put money on being within 1% of that mean measuring at 10 kHz.

- Ben

[Commanderbob]

You definitely don't want a pull-down resistor on an analog voltage signal.

I know that it is dropping the signal but it makes the fall time a lot shorter. See my earlier post. I will try adding some other stuff and see what I can get. Any suggestions for removing noise?

Justin

[bens]

I know that it is dropping the signal but it makes the fall time a lot shorter.

Losing 20% of your signal to get a shorter fall time might not be worth it, though.  Is the pull-down effect a constant or is it dependent on the output voltage (in which case it would interfere with the ability to linearize the sensor output)?  I'd be interested to see what an RC filter does to the signal (i.e. sensor output -> resistor -> x -> capacitor -> ground, where X is your filtered signal)


- Ben

[Commanderbob]

Ask and you shall receive. 
Sensor->450 ohm->test point->10nf->ground
First picture is the control second is with the filter.


EDIT: I forgot to say that I think the reason that it is lower is there are some low spikes that will pull it down.
Justin

[Murmandamus]

Hi people,

Sorry for bumping this old topic. I'm new to this site (and loving it by the way!) and just found this topic via this article about Sharp IR range sensors. The article talks about these sensors being noisy and links to one of the posts in this thread as being the best known solution to date.

I haven't read the entire topic (nor any other topics on this forum yet) but I just decided to register and drop a quick reply here, because I didn't see the following mentioned. I've played around with a couple of Sharp GP2D02's (one of the digital range sensor variants) a couple of years ago, and I remember reading somewhere that it actually helps reduce noise (a lot) if you ground the sensor casing. Yes, that black plastic box that houses the sensor, electrically connect it to ground. I remember doing that and noticing dramatic improvement. I imagine the same might be true for the particular analog variant mentioned in this thread.

I thought this was common knowledge, but again, I didn't see it mentioned here. If everybody already knows about this, or if I'm wrong afterall, then my apologies... If not, try it!

Cheers

[Commanderbob]

Is the black case even conductive? I though it was some sort of plastic. How would you go about grounding it?

Thanks for the suggestion!

[Murmandamus]

Is the black case even conductive? I though it was some sort of plastic. How would you go about grounding it?

Thanks for the suggestion!

Yes, that's the surprise, apparently it is conductive. At least to some extent that makes a difference. The way I grounded it at the time was by sticking a wire into the mounting hole and securing that with the screw (plus a ring) used for mounting the sensor. The other end of the wire, of course, goes to ground (i.e. negative pole of whatever powers your project). That was just a test setup, don't know how well it would hold on a mobile platform. Haven't done a lot of playing with this stuff since then, unfortunately. But anything that connects the casing to ground should do.

I've been scratching my head where the heck I found this particular tip, and finally dug up the following link: http://www.barello.net/Papers/GP2D02/ - I have no idea how I came to that site at the time. Just scroll almost halfway down and look for a paragraph under the header "Physical mounting issues". I have a couple more links about the GP2D02 but none of them mention the grounding thing. By the way this is an older variant of the Sharp IR sensors, I don't think it's even available anymore. And I don't know if the current variants still have the same issues. But it's worth a try.

Hope it helps!

[Commanderbob]

Wow, I would of never guessed. My multi-meter just showed that from each hole (2Y0A02) it has a resistance of about 3K ohms and sometimes as low as 500 ohms, depending on how I hold the probes. Once I get some time I will try grounding it and see how that affects the output.

[Commanderbob]

Alright I did some tests. For my tests I simply took my Sharp 2Y0A02 sensor and put it in a paper cup. Then I gave it power, took a sample of its original signal spikes, grounded the case and took another sample. here are the two images.

Control


Grounded Case


As you can see grounding the case (I just used an alligator clip) significantly reduces the spikes intensity. If I grounded it better (maybe in multiple places?) the spikes would go down even more.

Great tip, I'll be grounding the cases from now on.

[Murmandamus]

Great to know it helps, thanks for the update!