What hardware and program are you using? It's very unlikely that the PING sensor is the problem. The microcontroller can't control how far it can sense. The microcontroller just initiates the ultrasonic pulse and the PING waits for the echo to be received. The PING puts out a pulse that starts shortly after the sound pulse is produced and the pulse stops when the echo is received (or after about 18ms). Your program may be measuring the pulse incorrectly.
Front or rear different inputs it will not read above 5 inches. it will go down though.
Standard ping code. Works for the 3 other pings.
This code just turns leds from green to red base on distance sensed.
#include <FastLED.h>
const int pingPin = 7; // ping in
#define NUM_LEDS 6 // How many leds in your strip?
#define DATA_PIN 2 // What pin is the NeoPixel's data line connected to?
CRGB leds[NUM_LEDS]; // Define the array of leds
void loop()
{
// establish variables for duration of the ping,
// and the distance result in inches and centimeters:
long duration, inches, cm;
// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
pinMode(pingPin, OUTPUT);
digitalWrite(pingPin, LOW);
delayMicroseconds(2);
digitalWrite(pingPin, HIGH);
delayMicroseconds(5);
digitalWrite(pingPin, LOW);
// The same pin is used to read the signal from the PING))): a HIGH
// pulse whose duration is the time (in microseconds) from the sending
// of the ping to the reception of its echo off of an object.
pinMode(pingPin, INPUT);
duration = pulseIn(pingPin, HIGH);
// convert the time into a distance
inches = microsecondsToInches(duration);
cm = microsecondsToCentimeters(duration);
What happens if you only try to read the front or the rear alone? Looking at the code I'm wondering if your Pings are picking up the sound of another Ping.
Remove the Ping for a bench test. I just had an interference issue on a bot from wire routing. A pwm wire bundled right next to a servo control wire made the servo spaz out. Had to reroute wiring. Shielding was another option.
The main wildcard is the set of LEDs. Those can pull a lot of current, so if you're running them off the 5V regulator on the Arduino, there may not be enough juice to fire the Ping at full volume. For testing unhook the LEDs and try again.
Do all of the Pings, including the good ones, tick?
I would also route one of the working Pings to the pin used in your example code that demonstrates the problem. That will help rule out if you've got some bad pins or ports on your Uno. On the Uno they group pins by ports; any port goes out, it can take all the pins on that port with it.
As noted in comments above, you can only reliably fire off one Ping at a time. Otherwise you may get false echos. Even with that, I'd put your Ping code in a user function, with local variables to the function, so you can isolate the return values.
I took the sensor off and will bench test it. today.
It's also important to test a known good Ping on the same pin as the unit that's been giving you trouble. There are several potential failure points: the Ping itself, as well as the Arduino pin, are among the top ones to consider.
Comments
If a different sensor is used in the same location with the same software does it do the same thing?
Are you using 3.3V level translators, by any chance?
What microcontroller are you using?
Also what are you trying to detect?
Some objects don't reflect well such as soft and small objects.
Front or rear different inputs it will not read above 5 inches. it will go down though.
Standard ping code. Works for the 3 other pings.
This code just turns leds from green to red base on distance sensed.
#include <FastLED.h>
const int pingPin = 7; // ping in
#define NUM_LEDS 6 // How many leds in your strip?
#define DATA_PIN 2 // What pin is the NeoPixel's data line connected to?
CRGB leds[NUM_LEDS]; // Define the array of leds
void setup() {
// initialize serial communication:
Serial.begin(9600);
FastLED.addLeds<NEOPIXEL, DATA_PIN>(leds, NUM_LEDS);
}
void loop()
{
// establish variables for duration of the ping,
// and the distance result in inches and centimeters:
long duration, inches, cm;
// The PING))) is triggered by a HIGH pulse of 2 or more microseconds.
// Give a short LOW pulse beforehand to ensure a clean HIGH pulse:
pinMode(pingPin, OUTPUT);
digitalWrite(pingPin, LOW);
delayMicroseconds(2);
digitalWrite(pingPin, HIGH);
delayMicroseconds(5);
digitalWrite(pingPin, LOW);
// The same pin is used to read the signal from the PING))): a HIGH
// pulse whose duration is the time (in microseconds) from the sending
// of the ping to the reception of its echo off of an object.
pinMode(pingPin, INPUT);
duration = pulseIn(pingPin, HIGH);
// convert the time into a distance
inches = microsecondsToInches(duration);
cm = microsecondsToCentimeters(duration);
Serial.print(inches);
Serial.print("in, ");
Serial.print(cm);
Serial.print("cm");
Serial.println();
if (inches <= 20) {fill_solid( &(leds[0]), NUM_LEDS /*number of leds*/, CRGB::Red); //{whitestrobe(30);
FastLED.show();
}
else if (inches >= 21) {fill_solid( &(leds[0]), NUM_LEDS /*number of leds*/, CRGB::Green);
FastLED.show();
}
delay(100);
}
long microsecondsToInches(long microseconds)
{
return microseconds / 74 / 2;
}
long microsecondsToCentimeters(long microseconds)
{
return microseconds / 29 / 2;
}
CAUTION TURN YOU SPEAKER VOLUME DOWN
And the clicking is the ultrasonic pinging I think?? Video from iPhone 5
Do all of the Pings, including the good ones, tick?
I would also route one of the working Pings to the pin used in your example code that demonstrates the problem. That will help rule out if you've got some bad pins or ports on your Uno. On the Uno they group pins by ports; any port goes out, it can take all the pins on that port with it.
As noted in comments above, you can only reliably fire off one Ping at a time. Otherwise you may get false echos. Even with that, I'd put your Ping code in a user function, with local variables to the function, so you can isolate the return values.
I took the sensor off and will bench test it. today.
It's also important to test a known good Ping on the same pin as the unit that's been giving you trouble. There are several potential failure points: the Ping itself, as well as the Arduino pin, are among the top ones to consider.