Go Down

Topic: Ultrasonic distance sensor HC-SR04 lack of timeout problem (Read 57705 times) previous topic - next topic

arielnh56

I ran into this today while putting together a blog video for how to daisy-chain my little octosonar board to drive 12 of these little buggers with my sonari2c library (apologies for the plug).

I prototyped all this using SR04s I bought last year from somewhere in China (not banggood - it's not in my purchase history there) and it all works just dandy. Those units don't look like either of the ones pictured above.

The new ones I *did* get from Bangood recently and look like the "bad" ones above (same circuit, narrow silk screen) and my tests/demos were locking up occasionall (I was blaming it on wiring). I finally got to the bottom of this today (reproduce 100% by putting thumb over sensor) and google found this thread.

The most obvious difference between my "good" ones and the "bad" ones is the "bad' ones have 10K pullup resistors on Trig and Echo. My "good" ones do not - very high resistance between Trig, Echo and Vcc,Gnd.

The "good" and "bad" ones above both seem to have the pullups (R1/R2) so they are clones. Sometimes clones have different component values due to the cloners not being as good as the dudes on Kamino.

I tried tying the Echo to ground - seemed to clear it, but I can't do that through my board, nor can I flap the power.

While debugging I connected echo to the LED on my protoshield so I'd have a visual indicator. Bingo. Problem cleared right up. The protoshield has an inline resistor with the LED, but I figured these pulses are short, so how about just connecting a LED directly across Trig and GND. Seems to work....

Can someone else try this and verify?

Also can the guy with the good and bad clones check the resistance on r1/r2 on the "good" ones? I suspect they may be more than 10k i.e. weaker.

Update: I tried a variety of LEDs direct connect and they did not all work. The little red ones with 1.6V forward voltage did not lock up my board, but did not give a signal back from the rogue sensor either - probably pulling the voltage too low for the logic gate.

The rest seem to be 2V forward voltage and work direct without a resistor. All the LEDs fix the issues with a 220 ohm series resistor.

I was thinking of putting blinky activity LEDs on the next version of my board anyway, I think this clinches it.

Why does this work? No idea.

arielnh56

I take it back about the clone thing and cheaper components. A closer squint at the picture DaveEvans posted on Oct 10 tells me these are a clone with fewer components. The overall circuit layout looks almost identical, but there are a lot less capacitors.


jlmyra

Is that an LED and resistor on each sensor?
Thanks.

arielnh56

yes, attached between the sensor echo and ground. I just tried a 1k resistor (no LED) and that worked too.


arielnh56

It occurs to me that those 10K pullups may be supposed to be 10k pull-downs. I got some protoshields last month that had one of the tracks mis-designed and connected Vcc direct to Groun, so dumbassity like this definitely happens in the knock-off world.

If someone could check that on the "good" ones it might explain a lot.

vasimv

How to solder diode to prevent locking problem. Almost any diode will go (no need such big one, i just didn't have other in my inventory).

kanwarkumar

How can I Stop the measurement of ultrasonic sensor.... during program ruining.....please help me

arielnh56

#82
Mar 23, 2018, 04:50 am Last Edit: Mar 23, 2018, 04:58 am by arielnh56 Reason: adding picture of sensors I use, as they differ from the ones previously shown
I was updating my tindie text for these sensors and came back here and realized I had never come back and listed the solution found to this issue.

My sincere apologies. Open source is give and take, not just take.

many thanks to @jlmyra above for figuring out the actual cause - and persuading me by this action to buy an oscilloscope. http://www.bitscope.com/product/BS05/

The bad sensors raise the echo pin when they don't get a response. They never time out. Period. In brief: avoid.

They do reset the echo when a new cycle is started, so they are not a completely lost cause, once their behavior is understood.

The data sheets say that the timeout from no response is 37ms. While this may have been true for the original HC-SR04, the observed value for the not-bad clones is between 150ms and 200ms. So even with the "good" sensors my original octosonar board was getting interference between adjacent sensors when there was no echo as that sensor would still be hanging up the pin when the next one came active after the 50ms rotation period. This was patched in software to force a wait until the pin dropped.

The revised version of my "OctoSonar" board uses tri-state buffers to isolate the echoes from each other entirely and enforces a sensible 50ms (software changeable) time window to each sensor, eliminating the lockups and delays above, regardless of whether the sensor is one of the "good" or "bad" ones.

The "good" sensors I use have a different board layout from either of the ones shown in port #70. They are distinguished by having the passive components arrranged in two vertical rows.


jaknil

(New poster.)
I got my super cheap HC-SR04 sensors working with a software only solution after they all experienced the same error of getting stuck waiting for lost echos.

I have modifed the arduino Examples -> Sensors -> Ping code for the Ping Ultrasonic Range Finder and explained all steps in comments.

I hope this will be of help for others that come looking for a software only solution.  (Based on docdoc's solution in reply #16)

Code: [Select]

/*
 Ultrasonic distance sensor

 This sketch reads a ultrasonic rangefinder and returns the distance
 to the closest object in range. To initiate a reading it sends out a
 sound pulse and then listens for the echo of the pulse to return.
 The time it takes before the echo is registered is proportional to
 the distance of the object from the sensor.

 The circuit:
- +V connection of the Sensor attached to +5V
- GND connection of the Sensor attached to ground
- SIG connection of the Sensor  attached to digital pin 7 (TRIG and ECHO can be combined)


 created 3 Nov 2008
 by David A. Mellis
 modified 30 Aug 2011
 by Tom Igoe
 modified 1 Sept 2018
 by Jakob Nilsson
 
 This example code is in the public domain.

 http://www.arduino.cc/en/Tutorial/Ping
*/

// This constant won't change. It's the arduino pin that communicates with the sensor:
const int pingPin = 7;

// We need to add a timeout for the longes range that the Sensor can sense, so that
// it does not get stuck waiting for an echo that never comes.
// long timeout = 157 / 74 / 2;//Timeout in microseconds for a max range of 157 inches
const long timeout = 400 * 29 * 2; //Timeout in microseconds for a max range of 400 cm

void setup() {
 // initialize serial communication:
 Serial.begin(9600);
}

void loop() {
 // establish variables for duration of the ping, and the distance result
 // in inches and centimeters:
 long duration, inches, cm, mm;

 // The sensor is triggered by a HIGH signal for 10 microseconds.
 // Give a short LOW pulse beforehand to ensure a clean HIGH pulse and
 // to reset the sensor if it didn't register an echo from the last ping:
 pinMode(pingPin, OUTPUT);
 digitalWrite(pingPin, LOW);
 delayMicroseconds(10); //This delay lets the capacitors empty and resets the sensor
 digitalWrite(pingPin, HIGH);
 delayMicroseconds(10);
 digitalWrite(pingPin, LOW);

 // The same pin is used to read the signal from the Sensor: 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,timeout);

 // convert the time into a distance
 inches = microsecondsToInches(duration);
 cm = microsecondsToCentimeters(duration);
 mm = microsecondsToMillimeters(duration);

 Serial.print(inches);
 Serial.print(" in, ");
 Serial.print(cm);
 Serial.print(" cm, ");
 Serial.print(mm);
 Serial.print(" mm");
 Serial.println();
 
 delay(100); //Recommended minimum cycle time is 50ms so that the echo has time to fade
}

long microsecondsToInches(long microseconds) {
 // According to Parallax's datasheet for the PING))), there are 73.746
 // microseconds per inch (i.e. sound travels at 1130 feet per second).
 // This gives the distance travelled by the ping, outbound and return,
 // so we divide by 2 to get the distance of the obstacle.
 // See: http://www.parallax.com/dl/docs/prod/acc/28015-PING-v1.3.pdf
 return microseconds / 74 / 2;
}

long microsecondsToCentimeters(long microseconds) {
 // The speed of sound is 343 m/s or 29 microseconds per centimeter.
 // The ping travels out and back, so to find the distance of the object we
 // take half of the distance travelled.
 return microseconds / 29 / 2;
}

long microsecondsToMillimeters(long microseconds) {
 // The speed of sound is 343 m/s or 2.9215 microseconds per millimeter.
 // The ping travels out and back, so to find the distance of the object we
 // take half of the distance travelled.
 return microseconds * 10000 /29215 / 2;
}


Hope it helps!

nielyay

Hello,
Quote
detect an echo.
This sometimes results in the echo line staying high forever
have you check the connector for the echoPin?

and what is the code that you input to the HC-004.

Go Up