I’ve got a project where I’m going to be using a large number of ultrasonic rangefinders, so I bought a few HC-SR04s to test them out since they are very low-cost. In general they work well. I’m testing them with the NewPing Arduino library and when an object is in range, they’re accurate enough for my application.
The modules have 4 pins: VCC, Trig, Echo, and GND. You’re supposed to give the Trig pin a 10uS pulse, and the Echo pin is supposed to go high and remain high until the ultrasonic burst comes back, then it goes low. The length of time the Echo pin is high corresponds to the distance.
The problem occurs when the ultrasonic burst never comes back (you aim it into space, a block of foam, etc.). When this happens, the Echo pin stays high forever and there doesn’t appear to be a timeout. Even if you pulse the Trig pin again it still keeps Echo high, waiting for the response. You can trick it into thinking it got a response by tapping the receiving transducer can with a screwdriver or something, but other than that it seems like power cycling the module is the only thing that works.
What confuses me is that these sensors are sold everywhere and people don’t seem to have issues (except for a few posts I found that didn’t offer a fix). I’ve bought some from a few different places now, and they all have this problem.
Can anyone who has one of these confirm this behavoir? Is there something special you’re doing to get them to timeout properly?
It sounds like some Chinese cloners didn’t get the firmware copied correctly. Apparently the “real” SR04’s from a couple of companies do time out in the event of a non-detection. I saw a post where the guy ran the 5v power line from a DIO pin and did a power cycle every time this occurred.
And then this guy had a different problem, false alarms.
So he set out to make a smarter one, replacing it’s “brains” w/an ATtiny.
But he did post a schematic for the original clone and it makes me wonder if there isn’t a way to couple, perhaps via a cap, the trigger signal to the “detection” signal trace and so allow you to do a semi-reset w/o a power cycle ?
Huh. After looking through the posts on that page it looks like you’re right, a huge number of these HC-SR04 clones were built using OTP microcontrollers with poorly written firmware. So there’s pretty much nothing I can do in software unless I control VCC using an IO as you suggested. But further testing has shown me that this only works for some of them. Half of the sensors (bought from a certain popular chinese supplier) randomly enter the “waiting” state at power-up, and you have to tap the transducer to even get it started. I consider these a loss. Maybe I can use the other ones for something.
It’s so weird though. I simply couldn’t imagine writing/contracting firmware this poor, burning it into >100,000 OTP MCUs, and then populating the same number of modules with them. And it’s particularly strange that it mostly works, but they just stopped caring at some point and went for it.
Anyway, they were about $0.95 each so it’s no great loss. Lesson learned!
Devantech, who I think was the original designer, still sells them. Beyond that you might peruse the forums at Society of Robots, and see who gets thumbs up vs down.
FWIW I’ve been looking into the electrical designs posted on the WWW (there are a few differing ones) and I’m surprised because not one of them seems entirely right to me … let alone optimized. The clone that was analyzed in the link I posted above was “wrong” in that it’s BPF wasn’t even near the 40 kHz ultrasonic frequency used … if I believe the schematic posted by the author (who corrected it in his revision). Other schematics use different parts and even a different BPF design (still off-centered). And I’m still not sure about the end “detector” design, apparently wrong in all but the original design, though I may post that question separately. I don’t think even the original designer was familiar with classical radar detection techniques, which might yield a more sensitive design for the cost of another op-amp.
Mee_n_Mac:
…And I’m still not sure about the end “detector” design, apparently wrong in all but the original design, though I may post that question separately. I don’t think even the original designer was familiar with classical radar detection techniques, which might yield a more sensitive design for the cost of another op-amp.
A potential workaround to this issue is in your “master” processor if the echo remains high after a certain period of time, assume loss of echo. Trigger the unit again after that and continue on. When an object comes into range the echo output will go low and you know that you have a return echo.
dschlic1:
A potential workaround to this issue is in your “master” processor if the echo remains high after a certain period of time, assume loss of echo. Trigger the unit again after that and continue on. When an object comes into range the echo output will go low and you know that you have a return echo.
That assumes a new ultrasound wavefront is emitted when the device is re-triggered. I understood from “…Even if you pulse the Trig pin again it still keeps Echo high,…” that it is basically in a hang-mode until the receiving transducer is mechanically excited. Which won’t happen is a new echo is never received.
