sbright33:
Let me simplify and round to make it easier to discuss. We will use your method of only 1 unit. First send out a single ping and wait up to 100ms. Each 1ms is about 1ft, 2ms round trip. Measure the integer number of msecs rounding down. Let's assume the result is near the middle between 20-21 about 20.5. We don't need to be more exact than that. Now send out 100 pings exactly 1ms apart. Measure the return values mod 1000us. This gives us the part to the right of the decimal. We already know 20ms. Average them. We might get 522us. So the answer is 20.52ms. The last 2 is not significant. Convert to feet.You can see we don't need to identify which ping is which. It doesn't matter since they're all sent at x.000 secs. This could be relative to nothing, or GPS time. But we could figure it out since we know the object is about 20.x ms away. When a ping comes 20.51ms later we know it was sent 20+us ago, not 19 or 21.
This would not work if the object were exactly 20.01ms away, because we would hear the ping being sent each 1ms. It would be much louder and block us from hearing the echo. But it would work with 2 devices using an accurate clock! Or you could just change the interval to 1.12ms instead of 1.0ms if your echo was being blocked. More complicated math.
The advantage of my idea is that you get 100's of pings per second to average, even if the target is far away. This will let you calculate an accurate distance much quicker than waiting 100ms between sending, if you want an answer in 0.3 secs.
If you like my idea you an have it!
Sending pings out every 1ms would be too quick as it could take up to 29ms for that ping to arrive. A ping every 1ms would only work if you were measuring distances of less than around 34cm. Anything further than that would require a longer time between pings. I was assuming you were wanting to measure up to 10m (the max sensor distance). If so, you couldn't ping faster than once every 29ms. If you only were going to measure within 34cm, then you could send a ping out every 1ms.
And that's just the start of the problem. Conventional ping sensors would still have a problem for three reasons. First, when you tell a ping sensor to send out a ping, it takes it's good old time doing it. I haven't found one that takes less than 440 microseconds (7cm worth) of waiting around before it starts. Some can take over 88ms! Secondly, some sensors go inactive for a while after a ping is received, or even longer if a ping is not received (like 32ms!) Finally, existing sensors don't listen for an echo till that same sensor sends out a ping first. In other words, the receiving sensor isn't even listening when the sending sensor is sending out pings.
Maybe I don't understand what you're trying to accomplish. Do you want to ping 100 times a second? You can almost do that already with the NewPing library if your sensor allows it. Or, are you trying to make an ultrasonic sensor work for further than 5m? And if so there are sensors that work up to 50 feet away already. But, the technique you're speaking of would not allow you to send 100 pings per second and measure the distance from 10m away. Pinging every 29ms for 10m or pings every 1ms for distances within 34cm would be possible. But only with custom designed ping sensors and receivers and accurately synced devices.
I guess I just don't see what you're trying to do, as you can already ping at very high speeds with the NewPing library with sensors that support it (not quite 1ms, but every 3ms works for distances of about 50cm). It's also a bit of an issue outside the scope of the NewPing library as you would need custom hardware and special hardware to sync the two systems. More of a specialty thing rather than a public library.
Tim