Assuming that pin 13 really is the reason why the Duemilanove wasn't working with NewPing, I wanted to work on a contribution to the project. Everyone's experiences with the HC-SR* family of sensors is that they're mostly reliable, but they occasionally throw out a false positive or false negative. I've put digital filters in my code so that I don't trust readings until they remain consistent for a window of time or number of pings. It occurs to me that this would be of general utility, as an optional way of using NewPing objects.
Some ideas of how I'd do this:
-
- Sliding scale between responsive and trustworthy: Max responsiveness would provide no filter. Max trustworthiness would only trust a reading if there are no incompatible readings over a period of time, depending on whether we're trying to eliminate false positives or false negatives.
-
- "Best result in N ms": Similar to the above, except it only examines as many pings as it can in an N ms window. Should ensure that a filtered ping comes through in N ms, +/- some inherent latency
-
- Parameter-level tweaking: Open up all the configuration options to advanced users. They could specify a time-based filter or a filter that waits for N compatible pings in a row before believing the results.
I think I'd start with #1 and see how it's received.
Would you like me to have a go at coding this up? Would you prefer that I subclass NewPing or extend NewPing with additional methods that enable/configure the digital filter option? My intent is to not change the existing API so as not to break any legacy code, and I think either approach could facilitate that.