yes. i do think you missed something.
if i run the new ping sampe code i get a minimum error of 1cm or 2cm even in an absolutely stable setup, if i change the calculation to float the error is a little bit smaller but still in the range of 1cm. and both will give no stable values. the results fluctuate with ever line on the console.
if i use my 'slow' method to measure i get an error that is in the range of 1mm and absolutely stable values. no fluctuation. repeated measurements give the same distance again and again.
this is a huge difference for my application. and now it makes sense to appy the temperature correction.
if you say that this is not your intendet usage scenario that is fine with me. but to say the sensors are inherently so bad that nothing can be done ist just plain wrong.
Maybe you need to turn on rounding in the header file? #define ROUNDING_ENABLED true
I get stable values with no fluctuations with my library without any modifications with all the sensors I have.
The math doesn't change from sensor reading to sensor reading. So, if the sensor is outputting the exact same ping time, the exact same distance calculation will occur. With this said, it does depend on how it's rounded. By default, NewPing truncates the distance calculation. So if the distance is say 50.95cm it could flip between 50 and 51cm. This has to do with the margin of error of the sensor, which is around 0.33cm. With the rounding enabled, the same situation as shown above would yield a stable 51cm.
I think you've confused the accuracy of the sensors and the method of time to distance calculation. But, in all cases, you can simply just use the ping() method which just gives you the ping time. Then, you can do whatever logic you wish to convert this to a distance. The ping_cm() and ping_in() methods are meant to be a down and dirty, fast, and tight way of getting accurate results. This works for 99.9% of people best. But, if you're in the 0.01% that must use a different formula and use a thermometer to get more accurate results, NewPing is already set to work for you, just use the ping() method.
Basically, what I'm saying is that you should use the ping() method and use your own math. NewPing is not the place to debate the speed of sound (which is yet another debate that 0.01% of people want to get into). I'm not getting into this and won't be changing NewPing making it bigger and more complex for 0.01% of people. One of the primary goals of NewPing is to be smaller and faster than other ping libraries. While adding rounding and temperature calculations could make it ever so slightly more accurate, it's simply not within the scope of the project, and what the ping() method is exactly designed for. So please, use ping() and this can be the last I hear of time to distance calculations, it's an old, dead, and boring topic that I don't wish to debate further.