robtillaart:
@teckel
Thanks for the explanation!, good point as I did not investigate the temperature in it.yet the humidity, pressure, altitude, etc. makes no difference in the speed (only the temperature affects the speed).
Humidity does make a difference, too. Furthermore the effect of temperature and humidity depends on the frequency of the sound.
You're correct with humidity, I misspoke. I meant to say at some point that humidity makes a slight difference. You could add humidity into the calculations, but most of that could be discounted in the margin of error of the sensor itself. And, the distance the sensor can read makes humidity mostly trivial under most situations.
I guess my point was really that using close whole integers is probably good enough for most purposes. If not, use the ping function which outputs the time in microseconds and do your own calculations using a temperature sensor and optionally even a humidity sensor if your readings need to be that precise. But, if your readings really need to be that precise, you probably should use a different ranging sensor.
With all this said, I do plan on looking further into this overhead delay and possibly adding a constant in the calculations if it's found that this delay is a constant. I need to build a testing jig with distance measurements to accurately test multiple sensors in a very controlled manor. But, I'm not even going to do that until the pulseIn is rewritten as that could have an effect on these readings. I could also add a microsecond to cm and inch conversion where you could also specify the temperature from a temperature sensor. I do plan on sticking with using integers for basic conversions to save space and speed. If more precise values can be verified, I'll add those to the code as an option for those who are already using floating point calculations in their sketch or don't have a code space issue.
Tim