Both of these sensors indicate in their datasheets they should timeout if no object is detected after 38 ms, but they both behave very similar if no object is detected, and that’s that they take over 200ms to timeout. This means when there is no object, they can only scan at a rate of about 4-5 hz (they vary slightly each but are around 200ms average.) This is quite a big problem because for the other 160ish ms the sensor isn’t doing anything, it won’t re-ping, and the sound that can return at the maximum distance the transducer is able to receive has traveled too far after 38ms, so they simply sit there waiting for a timeout. You can’t re-trigger them without either letting them finish their timeout or powercycling them (which takes over 100ms before they become ready to use again.)
I bought 4 of each, and have been researching this problem to find a reliable 4 pin sensor that actually times out according to spec and so far haven’t been able to locate one. I tested over 30 hc-sr04s from Amazon from more than 5 vendors, and now 8 total from here as well. Do you know why they behave so differently than the datasheet specifies? It’s quite a large problem… if you had one of these scanning on a bot going even 3.4 mph it would travel like 4.5 feet between readings… that could kinda hurt
These are:
RBE-lte-54 (HC-SR04)
RB-Prr-10
I’ve attached a scope reading showing the timeout behavior. The measurements are listed at the bottom and the “width” is the timeout value. Trigger and Echo are on CH3 and CH4
We have tested both RB-Prr-10 and RB-Ite-54 and found a similar issues with the delay when no object is found. It was in the range of 150-200 ms instead of the 38 ms that is expected from the manufacturers’ datasheets.
We will be contacting the manufacturer to determine what might be causing this type of delay with the sensor.
If anyone wishes to test their sensor, they can use the example code and library attached to this post.
According to the supplier of the RB-Ite-54 the timeout delay of 38 ms specified in the datasheet is actually wrong (our tests revealed it was more around 191-193 ms). We should be obtaining a newer datasheet shortly at which point we will update the one on our website.
Here is a response from the supplier for the RB-Prr-10:
Therefore, both of the sensors had wrong information from the manufacturer. We will be correcting the information on our side and update the product pages again once we receive new datasheets.
Thank you for pointing out these problems with the sensors.
