Time the distance calculation is based on
Benedikt13 opened this issue · 2 comments
Why is the time of the answer on the echo-Pin used for distance calculations?? The resulting values are fluctuating strongly.
They are also far worse than calculations based on the runtime of the plus?
This design decision seems to be a "wrong" choice. I noticed this while using the library and couldn't isolate the fluctuating measurements I got while using the sensor because it came from this library with over 1500 uses on Platform IO.
I am somewhat puzzled that the way the time is measured can at all be used for distance calculations!!
Hi @Benedikt13!
Well, you're not the first to have some kind of difficulty with the library when used by PlatformIO.
About the calculation: Originally it was done using pulseIn(). However, we see some incompatibilities with non-Arduino platforms. Anyway, the strategy is similar. In the timing() method the pulse duration is calculated, which in this case basically means the time of the wave going back and forth.
We used the speed of an ultrasound wave, the relationship between distance, speed and time as the basis for the calculation and, for the conversion of values to centimeters, the following table:
| Distance (CM) | Divisor |
|---|---|
| 15.875 | 29.9029 |
| >>46.355<< | >>27.6233<< |
| 92.075 | 28.1949 |
| 137.795 | 28.4717 |
| 183.515 | 28.5584 |
| 229.235 | 28.5936 |
| 274.955 | 28.7194 |
To make sure everything was working, we ran tests with the library and compared it with others. In general, the accuracy is ± 1cm. Of course, due to the nature of the sensor, this accuracy can change depending on the angle of the obstacle and the material it is made from.
About PlatformIO, I often get reports of issues related to documentation or parts of the library that appear to be in older versions. Unfortunately I have no control over this. In this case, I recommend adopting the latest version available here on GitHub.
If you have any questions or problems with the library, I'll be happy to help.
[]s
Hello ErikSimoes,
I am sorry for the partially insulting comment.
My comment was written in anger over it being so widely fluctuating and ill fit for a codesharing platform.
The library was used with an Elegoo Mega 2560 and Elegoo HC SR 04 in my school project,
I wrote the issue and forgot about it. Later I realised that the problem wasn't the way you measure it, which was indeed correct, but something else. Switching to pulseIn() complete eradicated the problem.
With averaging over 20- 30 measurements ( I don't know the exact number anymore) the offset got within max 0.5 cm and consistently stayed within 0.05 cm.
In the school project group, we investigated this phenomenon and after comparing the code for pulseIn() and digitalRead() we concluded that pulseIn() works with a few clock cycles level of accuracy, while digitalRead() is a lot longer, due to it being oriented towards user-friendliness.
Using it in a while loop with a longer boolean expression sure doesn't help.
I can only talk about my exact configuration and maybe this approach has major incompatibility issues as you said. So the conclusion is that this library worked poorly in my configuration and pulseIn() worked great.
Thank you for your professional answer.
Have a nice day.