Feature Request: Compensate for temperature on Speed of Sound

[Former user]

The speed of sound is variable and dependent on the temperature. It would be nice if the ping_in, ping_cm, convert_in, and convert_cm methods allowed for optionally passing in the temperature.

Without that option, projects operating outside of room temperature have to handle the conversion themselves, like this: http://www.geekstips.com/arduino-snow-depth-remote-sensing-with-ultrasonic-sensor/

You could try to also compensate for other factors, but temperature has the biggest effect and would be the most useful.

You can find more information than you ever wanted to know about the speed of sound here: https://en.wikipedia.org/wiki/Speed_of_sound#Practical_application_to_air

Thanks for creating and maintaining such an incredibly useful library!

[Tim Eckel]

I could give you 3 different resources that would give 3 different calculations on the speed of sound. Anyway... One of NewPing's design goals is to be VERY fast and VERY small. Doing any type of floating point math totally destroys both of those goals. For that reason, I've developed NewPing's measurements to be fairly accurate at about 70 degrees (normal interior temp). Also, because ultrasonic sensors are not overly accurate, temp differences rarely make a squat difference unless you're using them outside exposed to the elements in Antarctica or in Texas, which I highly doubt.

In any case, NewPing is also designed to do whatever math you'd like with the results if you believe you can make them more accurate. Simply use the standard ping() method which returns the ping time. Then, do whatever math you'd like. And seriously, if I developed an accurate floating point method that takes temperature, altitude, humidity, etc. into the equation, I'd get emails all the time that my math was wrong. The reason, somehow, the speed of sound is still up for debate. Google gives (for example) the WRONG value.

Anyway, the ping_cm() method is much more accurate, fast, and produces smaller code than if you tried to make a low accuracy sensor more accurate by throwing in more calculations.

Thanks for the suggestion, but it's 100% out of scope until the world can agree on the speed of sound and floating point math doesn't take such a big hit on the ATmega microcontrollers.