NewPing Library: HC-SR04, SRF05, SRF06, DYP-ME007, Parallax PING))) - v1.7

I'm building a little robot with an HC-SR04 for obstacle avoidance, and I'm finding NewPing to be very nice. Thanks for your hard work, Tim.

I'm using NewPing in timer-mode, but I don't really need to do anything inside my echoCheck() function... I just want a distance value to be available to other parts of the code.

Here's where I run into a problem... I'm not seeing a good way to directly determine the difference between "timed out without an echo" and "still waiting for an echo" conditions. check_ping() returns false in both cases, and x.ping_result is only updated on receiving an echo. So x.ping_result always indicates the distance of the last successful ping, but it will always be a positive value even when pings are timing out without an echo.

So inside my echoCheck(), I have to assign the value of ping_result to a global variable, and then when I read the global variable elsewhere in the code, I have to remember to set it to zero. This is effectively doing the same job as ping_result, except it's happening in my code instead of inside NewPing.

Would it make sense for the timeout reset portion of check_ping() to set ping_result back to 0? ping_result isn't used anywhere else in NewPing, so it wouldn't affect internal behavior. I don't know how it might affect behavior of existing programs, but I suppose it could.

With this minor change, I could eliminate my global variable and just look at ping_result any time I want to know the status of the last ping.

On one level, I'd like the option for the timer-driven model to be even less involved. I'd like to start the "ping engine" in setup() and have it ping every 50 usec "forever" without calling ping_timer() again, and be able to just check ping_result any time I like. I can't call ping_timer(echoCheck) from within echoCheck(), because again, check_timer()'s return value doesn't differentiate between "timed out" and "still waiting". (And despite being a career developer / system architect, I'll admit that I may be missing something here and that the problem is easily solved.)

If check_timer() returned an int... -1 for "still waiting", 0 for "timed out" and a positive value (distance) for an "echo received", it would be a lot more flexible. And it would break existing code, since its' an API change.

I suppose I could peek at the timer value itself to see if it's still enabled, but having the library help with that would be ideal. Maybe a function or variable I could call/look at to find out why check_timer() returned false? Of course, an alternative function to ping_timer(), say, ping_forever(), that didn't (or optionally) require a echoCheck() and handled running the ping over and over on its own might be ideal. (And I'll admit, this is what I expected when I first dug into the timer-driven mode.)

I may make some tweaks to the library and see which ideas pan out.