Linking Ping Sensor to Coridium ARMite controller.

SSCT

Hello, hopefully somebody can point to what is going wrong here.· I am a member of a robot team at a technical school.· We are attempting to link a Ping ultrasonic sensor to a Coridium ARMite controller.·We are able to send the pulse and ping the sensor, but we are getting a very inconsistent return.· From the code below we are printing the time of the return pulse in microseconds.· The·return is almost always 5 or 6 us.··Occasionally we get a much higher return, but·it is not related to the distance we are pointing at.· We have moved the ping sensor around attempting to eliminate problems and we feel·we have eliminated any bad echoes or feedback.· It seems the problem is in the code.· Thank you for looking at this and providing whatever help you can.·

#include<pulse.bas>

'' Conversion constants for room temperature measurements.
CmConstant = 2260
InConstant = 890
cmDistance = 0
inDistance = 0
time = 0
DO
PULSOUT(0,5)
time = PULSIN(0,1)
cmDistance = cmConstant * time
inDistance = inConstant * time
' print cmDistance; " cm"
' print inDistance; " in"
print time; " us"
' wait(100)
LOOP

Post Edited (SSCT) : 3/31/2009 5:08:06 PM GMT

Mike Green

You probably need a short delay between the PULSOUT and the PULSIN. You may be sensing noise or reflections on the data line with the PULSIN. The "Echo Hold-off" time from the end of the trigger pulse to the start of the echo pulse is at least 750us according to the documentation. You probably need to wait at least 500-600us.

SSCT

The minimum time delay on the "wait" function is 1 millisecond. I think, but cannot remember, that we did try to put a pause in between the pulsout and pulsin. The only other function that could possibly work is to put a timer in as the timer is set in micro-seconds. In your opinion would that be a valid operator, to just tell the pulsin to turn on after so many microseconds?

Mike Green

You could also do a FOR loop and calibrate it by writing a short program with a nested loop, perhaps 32767 times through the inner loop that does nothing, then trying different outer loop counts to see how many loops to delay a second, then adjust the count for what you want for a delay between the PULSOUT and PULSIN.

You could also use a built-in timer.

SSCT

We used the timer that is built in to the controller and tried a variety of delays, none of which seem to have worked.·

code was

timer = 0
while timer < 650· 'we went from 40us to 2000us with no change in results
loop

After the loop ended, the pulsin was activated.

We still had the same output from the sensor in a 5-7 us range

Mike Green

The PING does work as documented. I've used it with a Stamp and with a Propeller which are very different microcontrollers.

A 5us or so return pulse doesn't make sense. Read the PING documentation. The minimum width of the echo pulse is 115us.
There's something else going on and it either has to do with the hardware setup or the programming system you're using and
there's no way for me to guess further with the amount of information you've provided.

I did find the ARMlite on SparkFun's website. It's not a 5V logic device. The spec says that the I/O pins are 5V tolerant and that
output voltages are approximately 2.9V. Now the Propeller is also a 3.3V device and it does work with the PING. I've had no
problems with the Propeller and the PING. On the other hand, it is "out of spec" and, if the ARMlite's voltage regulator is a little
low or if there's more voltage drop in the ARMlite's output circuitry than the Propeller's, you're in trouble. You may need some
buffering between the ARMlite and the PING. Philips (NXP) has some application notes on simple bidirectional buffering for use
with I2C busses running at different voltages. There's a Propeller thread on this and related subjects:
http://forums.parallax.com/showthread.php?p=585920.

Post Edited (Mike Green) : 4/3/2009 6:45:01 PM GMT

SSCT

We have a separate board wired with a battery and a voltage regulator that is providing 4.9 volts. We have the input/output pin going to the controller and the power pins on this second board. We have checked this a number of times as we are also running a line tracker that requires 5 volts. The Armite uses its own version of Basic, with add-ons like a timer and some other things. This morning we used the timer function with the results as shown. The green LED that shows activity was flashing more frequently then when we had no delay built in. The LED was very infrequent before we used the delay.

We have talked to Parallax tech support on the phone. They have said that our program should cause the sensor to function normally and there should not be any problems. The Coridium people have been absolutely no help. Parallax also says their sensors rarely go bad and they don't think we have a problem on that end. To be on the safe side, we ordered a new one just to be sure (we are currently using two that were left from last year's robot).

If you can think of any other information you need from our end, we would be happy to provide whatever we can. Thank you.




http://www.coridiumcorp.com/Products.php

We are using the board all the way on the left, maybe those specs will tell you what you need to know.

Mike Green

I agree with Parallax tech support and I really don't have anything else to add. You're sort of stuck. If I were you, I'd switch to either a Parallax Stamp or a Propeller depending on what else you're trying to do. The primary reason is that there's sample code that works and you have only one place to have to go for support. You always run the risk of problems when you have to deal with two completely different manufacturers even if the products individually are fine.

I've made several suggestions and observations along the way. You really need to work with them. If you have an oscilloscope or logic analyzer, you need to use them to find out what's going on.

SSCT

Well Mike, thank you very much for the help.· We finally got the sensor to work as designed, turns out we had a ground wire disconnected on the secondary breadboard that was confusing the sensor.· We are now getting the results that we were initially expecting, with the input reading 7500us about 6 inches and ranging out.· Thank you for the help.