void loop() { digitalWrite(vcc, HIGH); // 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(trig, OUTPUT); digitalWrite(trig, LOW); delayMicroseconds(2); digitalWrite(trig, HIGH); delayMicroseconds(5); digitalWrite(trig, 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(echo,INPUT); duration = pulseIn(echo, HIGH);

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

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-PI... return microseconds / 74 / 2; }

long microsecondsToCentimeters(long microseconds) { // The speed of sound is 340 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; }

Step 1: 3-pin Code

Code /* Ping))) Sensor

This sketch reads a PING))) ultrasonic rangefinder and returns the distance to the closest object in range. To do this, it sends a pulse to the sensor to initiate a reading, then listens for a pulse to return. The length of the returning pulse is proportional to the distance of the object from the sensor.

The circuit: * +V connection of the PING))) attached to +5V * GND connection of the PING))) attached to ground * SIG connection of the PING))) attached to digital pin 7

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);

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 340 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; }

Step 2: Trouble With the Sensor/troubleshooting

So there have been many questions about failing sensors and no output. Here are some solutions.

1) Dubble check the connection.

2) check your power source: Sometimes usb connections or 9v batteries do not deliver enough power for sensors and motors/servos. So check the output with only the sensor before you upload your final code. A bigger battery might come in handy too.

3) Use other ports: First of try using a different usb port on your computer and restart the program. Second of try using other pins to attach the sensor to the arduino

Searching for other example projects i found that this one is the only that doesn't require a breadboard, so i wonder, why bothering using a breadboard when you can simply connect it like this example? Is there something wrong with connecting the senspr directly to the arduino?

Most of the time a breadboard is used to make assembly easier (there is more room on a breadboard and it uses power rails) and to get more current than the I/O ports can deliver (for example when using a servo or multiple sensors).

Also some say connecting the sensor directly to the I/O will damage the sensor (see MitchellB30's comment), but I doubt this and I haven't had any issues with this.

the four-pin is just plain wrong. You can't power sensors over digital I/O of arduino boards. Digital I/O pins aren't rated for enough current to power most sensors, you run the risk of damaging one or both devices. Use the 5V and GND pins, they're there for a reason.

After reviewing the specs for the ultrasonic sensor, the sensor only draws 15 of the 20mA max for arduino digital I/O pins. That said, its a dumb idea to power sensors off of Digital I/O and hope you down blow up your microcontroller. ploease, don't do this.

Thanks for the warning, but according to the arduino website the output current is only 20mA. This might be a problem for long term use, but certainly won't damage the sensor in the sort term. Furthermore, I have never had any issue with this.

Also isn't the output current equal to the current "requested" by the sensor?

// set the data rate for the SoftwareSerial port emicSerial.begin(9600);

/* When the Emic 2 powers on, it takes about 3 seconds for it to successfully intialize. It then sends a ":" character to indicate it's ready to accept commands. If the Emic 2 is already initialized, a CR will also cause it to send a ":" */ emicSerial.print('\n'); // Send a CR in case the system is already up while (emicSerial.read() != ':'); // When the Emic 2 has initialized and is ready, it will send a single ':' character, so wait here until we receive it delay(10); // Short delay emicSerial.flush(); // Flush the receive buffer }

Sorry no. The so called echo is not an echo of the transmitted pulse. Also the transmitted pulse is fixed at 8 cycles at 40kHz. The echo line goes high when the pulse is sent and stays high until the first echo is received. So distance is measured from the duration of the echo pulse. The arduino devices are however a cheap source of ultrasonic Tx/Rx. Also the LM324 quad amp that is used to detect the return might be used to monitor the received signal without too many mods. There is a very good analysis of the HC-SR04 at:

hello, please i have a problem. My arduino keeps tripping off any time i connect the GND of the HCSR04 with the GND of my microcontroller. the ardunio uno micro controller keeps tripping off and i have tried this on two different micro-controller. the micro controller is powered by my laptop usb port. any idea how i can fix this problem?/

I am using a HC-SR04 hooked up to a Arduino Nano. I have it mounted on my quad-copter (drone) to control the retractable landing gear. I have it set to 3 feet and it works reliably when closer than 3 feet to the ground. My problem is when it is flying, the sensor is "seeing" my rotor wash from the props and generating false triggers. When my quad is up high flying, the landing gear goes up and down at random.

I think I need to look at the distance, wait a second and look again. If the two answers match, then perform an action. My problem is I'm not a programmer. Can anyone give me a clue or just do it for me?

Here is my code that I stole so far. Any help will be greatly appreciated and I promise I won't spy on you with my drone. :) Thanks in advance

I have a confusion with HC-SR04. I tried your code and it works very well. I got the output on the Serial Monitor just fine. The problem is, when I take out the trig pin (detach) from pin 3. I still got the reading just fine? I thought that the TRIG is for sending pulse and the ECHO is for receiving pulse. Somebody please explain what is the case here?

However, I have a question about the use of the pulseIn function here. Aduino Documentauin tells me that this function starts timing when the pin gets a high signal, and then stops timing when the pin gets a low signal. So in our context it will record the ‘duration’ as the time between when it started hearing the reflected sound, and when it stopped hearing the reflected sound. But I don't think that is what we want. That duration will always be 10 microsecond, since that was the length of our pulse (assuming that any obstacle is further than 5 sound-microseconds). Don't we want something that starts timing whn the signal is first sent, and then stops timing when the signal is first received? I may be wrong. The code works perfectly, but it doesn't make theoretical sense to me.

Thanks for this! :)I found that I was getting 0 inch and 0CM but going through a breadboard and hooking Ground to Ground (instead of pin 5) and VCC to 5V (instead of pin 2) I started to get readings! Might help other people trying this?!Not sure my readings are all that accurate at the moment but im already late for work. ;) Ill take a look at the code/calculations and the actual sensor etc and see if there is a reason for it and maybe fudge the calculation to match my sensor.