Thanks to Terry King and YourDuino I did a round of range testing with 6 ultrasonic/ping sensors and the results were not as I expected. I tested with 3 different models, (4) SF04, (1) SRF05, (1) SRF06. The testing environment was in an air conditioned room at 75 degrees. I tested at distances of 5cm, 10cm, 25cm, 50cm, and 100cm. Longer distances were not tested in this round. I believe the accuracy within 100cm or important as that's within the primary measurement distance. Beyond 100cm it's not as much of an issue in most situations. Once the pulseIn echo code is reworked, I'll do round 2 of testing out to a further distance.
The good news is that the sensors were all very consistent. With all the SF04 and SRF05 generating nearly identical results (makes sense as the PCBs are nearly identical). The SRF06 uses different components and yields slightly different measurements as a result. It does appear to be a slightly better sensor (makes less clicking noise, hardly no lag, and results closer to actual speed of sound). The maximum distance of the SRF06 seemed to be slightly lower, but that will be answered in round 2 of testing.
The results don't fit at all with the speed of sound calculations previously being used. For the SF04 and SRF05 sensors, the calculation from microseconds to cm is:
cm = (microseconds + 37) / 48
For the SRF06 sensor, the calculation is:
cm = (microseconds + 5) / 51
Using these calculations, I could accurately measure any distance in the 5cm to 100cm range with all 6 sensors. Albeit, not even close to speed of sound at this temperature, which should be right around cm = microseconds / 58. If it was simply a long sensor lag, the additional microseconds added in the equation would be much higher, which they're not.
I have two theories as to why this is happening:
- The pulseIn function is simply way off. It's not even measuring time, but counting processor cycles, so there's a good possibility the time conversion is wrong.
- Because I'm using port registers the code is faster. And, since the formulas used to compute pulseIn are not based on port register manipulation but using the known slow higher-level digitalWrite command that's where the error is. This doesn't seem likely as while digitalWrite is slow, it's not THAT slow.
At this point, I think diving into the pulseIn code and replacing it is a wise choice. Then at least I'll have some other information to figure out the source of the time discrepancy.
Tim