Sharp GP2-D120 infrared distance sensors

I'm using a Tech Arts Micro Core system and am interfacing three CDS cells and three GP2-D120s. The 68HC11 has two banks of four A/D channels
and all testing on my wiring indicates that there are no shorts or open circuits. My software can read analog voltages from both sets of ports.
Here's what's happening: If I have one of the GP2-D120 units plugged in to any of the three ports, it works fine on any port. I also checked each unit and each works fine.
If I have more than one GP2-D120 plugged in, the 68HC11 board starts resetting itself constantly. I had the inputs floating and tied high with the same results. (except that the no-sensor values was different)
I entertained the idea that maybe they were drawing too much current, but they are listed as a continuous draw of about 33 ma. I have the electronics buss powered with a 1800 ma NiH battery pack. I'm feeding off of the Micro Core regulator. But I doubt that's doing anything because I also have serial LCD that draws well over 100ma when the LED backlight is on. I have it shut off now, so, the total should be less than 160ma for everything on that regulator.
Is there some special magic to get these units to work together?
Thanks in advance, Joe Nastasi
--
Joe Nastasi
Pyramid Design
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joe Nastasi wrote:

Plenty of capacitors. These units are EXTREMELY noisy. while the average current draw is only about 33ma, each unit actually flashes its LED at around 1khz, with a 10% duty cycle (going by memory here). When the LED is on, it is actually drawing about 330ma.
I use 8 in one of my robots. I think I used 1uf across each the power pins of each unit, and then a larger (maybe 20uf?) cap elsewhere on the power supply upstream. This doesn't eliminate the noise, but greatly reduces it. You need to tamp it down considerably; even if you get it quiet enough so that the rest of your H/W functions correctlty, you'll get erroneous readings from the GP2's if things are still too noisy.
The easiest way to see what's happening is to put a scope on your power supply and experiment.
Hope that helps -- tAfkaks
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Amen, brother!
One of the builders in our San Diego club routinely gives each of these sensors their own reguated power supply. Sounds like overkill, except that regulators and associated caps are pretty cheap and he claims to not have any glitches or brown-out setting problems typical of robots that use multiple Sharp sensors. The OP is using an 1800 mA battery pack, so a brown-out condition isn't likely in this case, but I know this can be a problem when people try to power these things with the 9 volt battery on their controller board.
-- Gordon Author: Robot Builder's Bonanza Budget Robotics: http://www.budgetrobotics.com
The Artist Formerly Known as Kap'n Salty wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Gordon McComb wrote:

I *like* it!
I'm about to try to use some of these with the Phidget Interface Kit (http://www.phidgets.com /) and will be using a large cap between the power and ground, but I'll consider using this solution with my next project... -- D. Jay Newman http://enerd.ws/robots /
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
The fellow's name who uses this technique is Alex Brown. He has a Web page here:
http://abrobotics.com /
and he provides a fairly involved discussion of the arrangement of the sensors on one of the robots be built for Trinity. He mentions the separate regulators on the page.
He hasn't updated his page with his latest robot, which uses image recognition usintg a Logitech camera, but maybe he will soon.
-- Gordon Author: Robot Builder's Bonanza Budget Robotics: http://www.budgetrobotics.com
D. Jay Newman wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Thanks to all who replied.
As it turns out a big honking cap on my I/O board cleaned it up nicely. I do get some jitter on the values, but nothing a little averaging won't clean up. What's a good plan for that? Running average?
The next robot I design will have separate regulators, which must certainly be better. Didn't have enough room on this board.
Cheers, Joe
--
Joe Nastasi
Pyramid Design
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Joe Nastasi wrote:

Hey, Joe -- a running average will work fine. You can also try an "exponential decaying average" -- I'm not sure why this is termed "exponential" -- by adding the ne value to current value, multiplying each by a coefficient so that the sum of both is less than 1. For example:
cur = 0.75*cur + 0.25*new
Cheers -- tAfkaks
--
(Replies: cleanse my address of the Mark of the Beast!)

Teleoperate a roving mobile robot from the web:
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
wrote:

That looks interesting. I'll give that a whack. Thanks!
--
Joe Nastasi
Pyramid Design
  Click to see the full signature.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
I find an easy way (also easily tunable) to do this calculation is as follows:
cur = (cur * per + new) / (per + 1).
where "per" is the "period" of the exponential average.
This way, everything works with integer numbers, and if you use nice values such as 3, 7, or 15 for the period, the division can just be taken care of by a right shift instead of an expensive divide. Just make sure that the (cur * per + new) value doesn't overflow the integer range. (Can you tell I spent a lot of time with itty-bitty processors?)
The big downside of an exponential decaying average, compared to a true moving average, is that a single large perturbation (such as power-on, for example) will continue to have an effect for a very long time, possibly (likely) overriding the values of more recent measurements. A moving average, OTOH, will regain accuracy within a deterministic length of time.
-- Mark Moulding "I prefer heaven for climate, and hell for companionship."

example:
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.