teckel:
When I do the same test, I get nothing but periods. Maybe try it while disconnecting the other hardware to see if it's a possible noise issue.
I've tried it on bare-bones setups with just the Arduino and the sensor, with a protoboard between the two.
teckel:
I would still not use pin 13 for input, even on the Uno. Not that it's causing the problem, it's just probably not a good idea. If you're out of pins, it would be better to swap pins 12 and 13 and use 13 for the trigger and 12 for the echo.
I'm using pins 12 and 7 currently on an Uno, and I'm still getting false negatives.
teckel:
Also, it's possible that it's giving the zeros because the ping never initiated.
Here's what I hear: I hear clicking occurring very rapidly as the test runs. The click pattern mirrors the '0' and '.' pattern, in that it speeds up when I get '.'s and slows down when I get '0's. If I had to guess, I'd say that there is some timeout involved, but I don't know whether it's not sending pings due to a timeout, or giving up on receiving them due to a timeout.
teckel:
While the sensor specs say it only needs a 10uS high notch to trigger a pin, maybe some sensors need a little more. I haven't seen this, but I'm thinking it's very possible. Try changing the delayMicroseconds in line 46 and 48 of NewPing.cpp to 1000 each. That should give it plenty of time to initiate the ping.
That produced false positives far more often. The actual positives (in-range values while something was actually in range) became very rare.
teckel:
Are all these zeros the same thing you get when you use a different sensor library? As other libraries may not return zero for a failed ping, you'd probably need to do an additional command to make the out of range a zero and in range a period.
I'll re-test with that other implementation, but I began to code for false positives and negatives based on my experience with it, not NewPing. Still, I'll see if I can get a comparison going.
I have another Uno arriving today, which I'll test just to see if my previous Uno isn't acting strangely, although my Duemilanove results paralleled what I got with the Uno, as long as pin 13 wasn't involved.
teckel:
Even if the false negatives are going to happen for you in any case; If you only want to know the distance, why not just filter out the zeros and just deal with the successful pings? If you only want to know a distance, just ping frequently and ignore all the zeros.
The zeros are meaningful to me, too. I need to know if there's something in range or nothing in range and act accordingly. My specific application is a sensor aimed at where my head is if I'm on my treadmill desk. When I'm actually in walking position (in range, less than a specific distance), I turn a bunch of things on. When I'm not in walking position (either in range, over a specific distance, or out of range), I turn a bunch of stuff off.
teckel:
Finally, I've been thinking of some type of averaging method in NewPing. My thought was to do an odd number of pings like 3, 5 or 7, throw out the high and low value, and average the rest. Obviously, taking into consideration zero results as well. Then, it would give that average as the result. It would be a poor man's standard deviation, creating smaller and faster code but yielding basically the same result. This would also fix your false negative results. I'd rather locate the source of your problem instead, as that's a LOT of false negatives considering I get none.
That could be useful. I was thinking of doing something like that with a digital filter. I'm not sure yet which would best apply to the use case I was thinking of.
If you had an application that did something different at, say, 10cm vs 9cm, readings that oscillate between 9cm and 10cm would cause chaos. A digital filter that would return a consistent 9cm value or a consistent 10cm value would reduce this flailing. So, 9 10 9 9 10 10 10 10 might return 10, but 9 10 9 9 9 10 10 10 9 9 9 10 10 10 might not return yet, etc. Obviously it could be a concern if it's done in a blocking way, but in my case, 99% of the input to my logic is from the distance sensor. I do have pushbuttons, but given that the worst-case scenario of never returning from the filter is unlikely, I'd be fine with that. Your idea has the potential to do the same thing, but it wouldn't look for unbroken chains of consistent values. In the end, they may both do the same thing, though.