Communication Between Two Ping Sensors

stone

Hello All,

I'm new to the forum, here with a question about the Ping ultrasonic sensors. I'm attempting to make a prototype for an ultrasonic pager of sorts. The device will broadcast a simple ultrasonic signal after a button press. When not broadcasting, it will listen for incoming signals and produce light and vibration when a signal is received.

As a cheap proof-of-concept model, I've been attempting to coerce two ultrasonic rangefinder modules to talk to each other. In planning it seems to be a relatively simple operation, as the units are both transmitters and receivers and I expected those separate functions to be individually accessible. I began with HC-SR04 modules and couldn't elicit the behavior I anticipated, so I also acquired some Ping sensors and attempted the same procedure.

My tests with both sensor models began with simply taking the rangefinder code and disabling the transmission element of the loop. I uploaded this to one unit (Unit 1 for nomenclature's sake). I then utilized a second sensor (Unit 2) running the full rangefinder code and pointed it directly at Unit 1. I anticipated that I would see some sort of distances being calculated on the receiving unit, but I consistently get a "0in, 0cm" reading from the standard code. Since this correlates to a duration using pulsein and subsequently a high on the control pin (pin 7 in this case), I simplified the code to manually poll the pin status with digitalRead and still found no response from Unit 1. It seems that no matter how I try to find observable transmission, I see no pin high on the control pin of Unit 1.

I'm learning as I go along here, so at first I investigated the potential of frequency mismatch due to tolerances within the transducers, but I ruled that out as literature seems to allude to acceptably wide bands of frequency response for this sort of transducer.

Another potential pitfall I considered is the timing of the signal and echo pulses, but according to the Ping datasheet the signal pulse is 200us and the minimum echo pulse is 115us, which should work out.

The biggest question I have is how the Ping's onboard timing circuit functions, as I don't know much about how a circuit like that would work. The datasheet spec's a 750us echo delay time, which maybe alludes to my problem, but I believe that in theory if Unit 1 is constantly polling the control pin it should read a high regardless of delay timing. Could it be the case that the Ping sensor isn't prepared to read an echo without first transmitting a signal? That would seem to be a potential cause, one that may be solved by circumventing the use of the pre-made ping sensor and going straight to a custom circuit controlling transducers.

Does anyone have any thoughts on the question in bold above or any way to make Ping sensors communicate with one another? I'm preparing to move on to a more specifically designed solution but it would be nice to have this proof-of-concept model function just for demonstrations sake. I can provide code if necessary but it is for the most part so simple I figured I would omit it for now.

Just as a note, I've done a great deal of searching online for similar projects but found little that actually outlined functional solutions. I've also search forums, including this one, and didn't come up with much, but if anyone has prior art in mind I'd be very happy to give it a read.

Many thanks in advance for any advice! I also apologize for any blatant ignorance, I'm coming from the world of mechanical engineering and I still have ample learning to do in this discipline.

Franklin

If you have not modified the code the ping sends a pulse and then waits for a response. If it does not get one in a specified time it times out. You need to modify the code so it will wait for the ping indefinately.

stone

Thanks for the reply Franklin.

As far as I can tell, there is nothing in the code that acts as a time out. This is the code I'm using as a foundation:

/* 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
 
 http://www.arduino.cc/en/Tutorial/Ping
 
 created 3 Nov 2008
 by David A. Mellis
 modified 30 Aug 2011
 by Tom Igoe
 
 This example code is in the public domain.
 
 */


// this constant won't change.  It's the pin number
// of the sensor's output:
const int pingPin = 7;


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;


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


  delay(100);
}


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

I've disabled the section of code that triggers the Ping module, so the loop is just looking for pin 7 to get pulled high and then counting the duration. I've also polled the pin directly and constantly looking for a high and found none, so there should be no issue with timing out in the code. This seems to allude to the fact that the ping module itself is not returning a high value when it receives a signal from other unit, and goes back to my suspicion that it only listens once it has emitted a signal.

I think I may have just confirmed this by covering the transmitting transducer on one Ping module while pointing it directly at another module with rangefinder code operating on both. I can get both modules to read a similar distance with that transducer covered up, so it seems that the Ping will receive the signal of its counterpart only after sending its own signal (which is now conveniently blocked by my finger).

I'm picking up transducers to build my own control circuit that I can operate via arduino. I'll update as I go along if anyone is interested.

Chris Savage

stone wrote: »

Could it be the case that the Ping sensor isn't prepared to read an echo without first transmitting a signal?

This is exactly the case. The PING))) doesn't become ready to receive until it has been triggered and sent its own pulse out. I believe I did read a post here some time ago from someone who hacked two PING))) sensors to remove the transmit tranducer from one and the receive transducer from the other in order to do something similar, but remember the PING))) also times out without a window corresponding to the maximum echo time it can receive.

stone

Chris, thanks for confirming my hunch. Working on more specific solutions. If anyone has resources regarding the control of transducers using diodes and microcontrollers, I'd be grateful to be pointed in their directed! Thanks again for the replies.

macrobeak

Stone, I do not know if this is of interest to you, but I have successfully made a network of one-transmit, several receive PING devices as follows;
a) Make blanking caps to cover one of the PING ultrasonic sensors. I used a 19mm irrigation end cap filled with cotton wool.
b) For the transmit PING cover the left-hand (looking at the sensors) transmitter sensor.
c) For the receiving PINGs cover the right hand (looking at the sensor) receiver sensor.
c) Pulse all the PINGs. Only the transmit PING will send out a signal - the receive PINGs are blanked. However, the receive PINGs will start their receive cycle.
d) Read all the receive PINGs and you will have the distance for each receive PING from the transmit PING.
e) In this way you can triangulate the position of the transmit PING if you know the co-ordinates of the receive PINGs.

Publison

macrobeak wrote: »

Stone, I do not know if this is of interest to you, but I have successfully made a network of one-transmit, several receive PING devices as follows;
a) Make blanking caps to cover one of the PING ultrasonic sensors. I used a 19mm irrigation end cap filled with cotton wool.
b) For the transmit PING cover the left-hand (looking at the sensors) transmitter sensor.
c) For the receiving PINGs cover the right hand (looking at the sensor) receiver sensor.
c) Pulse all the PINGs. Only the transmit PING will send out a signal - the receive PINGs are blanked. However, the receive PINGs will start their receive cycle.
d) Read all the receive PINGs and you will have the distance for each receive PING from the transmit PING.
e) In this way you can triangulate the position of the transmit PING if you know the co-ordinates of the receive PINGs.

Phil did a good write up on this technique a couple of years ago.:

http://forums.parallax.com/showthread.php/134899-Triangulation-with-a-Ping)))-Array?highlight=Ping

prof_braino

The SR04 is the part that looks like the Ping))), but has 4 leads instead of the Ping)))'s 3. SR04 are cheap and sometimes questionable quality, but if you get 20 there are only a couple duds. The range tends to be more like 2 meters instead of 4.

The SR04 has a separate send and receive lines.

There is a driver for the SR04 in the propforth download
http://propforth.googlecode.com/files/PropForth-V5.5-20130317.zip

in the extesnsions subdirectory at
Propforth/V5.5/CurrentRelease/Extensions / SR04.f

that looks like one could simply comment out the send section, and it would listen. You might have to set the reviece line high (instead of sending and setting it high).
I haven't tried this yet, but I do have a Ping and many SR04; it might be time to give this a shot.

This is in FORTH, but it should be straight forward enough to glean what’s going on.