The only reason I can think of for wanting an iffy intensity signal is to determine distance to the target.

This is more reliably done by triangulation, either using two sensors, at least one of which can be turned relative to the other, or one taking two readings of the same thing at different points along a baseline. (Aren't Physics fun ? this is about How the 'Eye' "Sees = locates" an Object (in space).)

Once you have two different signals, you can look up in a table, or grind out a computation in PBASIC (using the numeric co-processor on board the Stamp :yikes: for greater accuracy.)

To do triangulation, aren't you going to need trigonometry? I suppose you could do it with lots of IFs that simulated a sin or cosine function, but I thought that PBASIC lacked trig support. Please correct me if I'm wrong.

Trig Support
 

Yes, there is trig support

ABS - Absolute Value
COS - Cosine
SIN - Sine
DCD - set bit

weee here we go
The Basic Stamp SIN operator breaks the circle down into 0 to 255 units instead of 0 to 359 degrees. Some textbooks call this unit a binary radian or brad. Each brad is equivalent to 1.406 degrees. And instead of a unit circle, which results in fractional sine values between 0 and 1. BASIC Stamp SIN is based on a 127-unit circle. Results are given in two's complement form in order to accommodate negative values. So, at the origin, SIN is 0. At 45 degrees (32 brads), sine is 90. At 90 degrees (64 brads), sine is 127. At 180 degrees (128 brads), sine is 0. At 270 degrees (192 brads), sine is -127.

To convert brads to degrees, multiply by 180 then divide by 128. To convert degrees to brads, multiply by 128, then divide by 180.


I hope this explains it, any questions?

Re: Errr
 

Actually, it is possible if you hook up a position encoded motor shaft to that little sensitivity adjustment doo-hicky on the back and using a successive approximation feedback loop to resolve each of the bits :).

The algorithm would work like this: First you would set the doo-hicky to the 50% point using the motor. Then you would read the binary output of the sensor. This output, a one or a zero, is the most significant bit. If the bit is a one, you know that the value is between 50% and 100%, otherwise it's between 0% and 50%. For the sake of this explanation, assume the bit was a one. Now we know we can exclude the lower 50% of the possible values. So we now set the doo-hicky to 75% and read the sensor to see if the level is between 50% and 75% (a zero) or 75% and 100% (a one). This bit is the second to MSB. Now assume we got a zero which means the value is between 50% and 75%. So now we set the doo-hickey to 62.5%... Each time through the loop you get one more bits-worth of resolution.

At the heart of most analog to digital converters is a voltage comparator that's making a binary decision just like the optical sensor does. This is how successive approximation analog to digital converters work.

-Kevin

Ever heard of Rube Goldberg?
 

Rather than using three separate sensors looking at the same thing with varying gains, you could definately put a little TOO much effort into this thought.
Take a small motor. Very small. Mount a flat-head screw diver bit to it. Program it to constantly, or in some sort of pattern, adjust the gain on a single sensor, preferably with the robot stationary. That should theoretically give you the strength of the reflection, wouldn't it? Would be a LOT of fun to engineer and program, don't you think? Although, the sort of pattern used by the screw driver bit might be useful for a whole robot that lost its way. Just a late evening thought.

Ol' Rube came to mind many time while I wrote that missive :D. No, I don't expect anyone to implement the above, my point was that it wasn't impossible to do. I also wanted to tie it in with the mechanism by which some analog to digital converters do their thing.

Actually, the binary search that I described is faster (in general) than the algorithm that you've described. It only needs one time through the loop to resolve each bit. The other method requires, assuming an equal distribution of data, an average (2^n)/2 or 2^(n-1) times through the loop where n is the number of bits to resolve.

-Kevin

even easier. why not just use a photoresistor hooked to one of the analog inputs?

Yeah, this is what the sane person would do. Which approach is more fun though? :)