Global Sources
EE Times AsiaWebsite
Stay in touch with EE Times Asia
eeBlogs-Article content Home?/?eeBlog?/?eeBlogs
Nickname:?eeLife???? Articles(62)???? Visits(90887)???? Comments(9)???? Votes(44)???? RSS
eeLife is about the engineering life, project challenges, engineering humour, community connections, career aspirations,... all that makes engineers tick.
Blog Archive
2016?-? Jan.??
2015?-? Aug.,?? Jun.,?? May.,?? Apr.,?? Mar.,?? Feb.??
2014?-? Dec.,?? Nov.,?? Sep.,?? Aug.,?? Jul.,?? Jun.,?? May.,?? Apr.,?? Mar.,?? Feb.,?? Jan.??
View All
Comment?|?Add to Favorites

Posted: 09:27:53 PM, 23/12/2013

Turn $3 SRF04 ultrasonic sensor into a $55 SRF08

? ?

As you may already know, fearless EE Times Editor Max Maxfield is building himself an Arduino-based robot.

My part in Max's master plan, as discussed below, will be to help him implement his ultrasonic distance ranging sensors. Max wrote about these in his blog, A Sensor for All Seasons. Since that time, we've been bouncing ideas back and forth with regard to connecting the sensors to his Arduino.

To refresh your memory, Max wants to load up on ultrasonic rangefinders as one technique to maintain good situational analysis. The sensors Max picked!the SRF04 type (sometimes shown without the F as SR04)!are "cheap-and cheerful" and can be obtained for only a few dollars (the price on Amazon goes up and down like a yo-yo, but you can usually obtain these sensors for less than $3 apiece).

Of course, you get what you pay for. The reason SRF04s are so cheap is that they don't have an onboard MCU; instead, they rely on the host MCU for all of their control and processing. The host MCU has to trigger an ultrasonic "ping," then time the delay between the ping and the return echo, and then use this delay to calculate the distance between the sensor and the object it's detected. The host MCU has to do this for each ultrasonic sensor, as well as managing all other aspects of the robot.

This works reasonably well for a small number of sensors, and most robots would typically only have one or two such sensors mounted on the front. The thing is that Max's three-wheeled robot platform can scoot around in any direction, which means it has no "front." This explains why he wants to have multiple sensors mounted around the periphery of his platform. The problem here is that when you start to add more and more sensors, the host MCU can very quickly use up all of its processing power servicing the sensors. When that happens, there's nothing left over for any other "robotic things." Thus, my mission was to offload the ranging burden without incurring too much cost.

For my own robot project, I've been experimenting with a related model of ultrasonic sensor, the SRF08. The '08 has an onboard PIC MCU to deal with the timing and the conversion of time into distance. It communicates over I2C in a "fire-and-forget" mode. An I2C command from the host MCU will instruct the sensor to initiate the ping, after which the host MCU can go about its business without the need to watch and wait for the echo return. Another I2C command sometime later will retrieve the distance measurement from the sensor. Here is a front view of one of my original '08 modules:


The two "cans" are the ultrasonic transmitter and receiver. The small part, between the two, near the top, is a CdS light-controlled resistor. The on-board MCU and a bunch of other bits and pieces are found on the backside of the module as illustrated below:


The downside is that the '08 is considerably more expensive than the '04. When Max and I looked recently, the best price we could find was around $55 for each '08 module. Since Max is talking about having nine ultrasonic sensors on his robot, this could quickly become a very expensive hobby.

Fortunately (certainly for Max), my own robot project will be able to help here. I plan to use an FPGA to talk to a large number of sensors simultaneously. In order to make this possible, I need each of my sensors to have a small on-board MCU and to communicate over I2C. Key to this concept is the availability of an inexpensive sensor-to-I2C board. Since I couldn't find anything commercially available that satisfied my requirements, I whipped up my own board. Conveniently, this little board will be perfect for Max to use with his '04s. In fact, the image below shows an '04 (on the left) plugged into one of my boards:


There's nothing at all complex about my board!its main feature is a small PIC12F1840 MCU and some connectors. For the purposes of these discussions, imagine my board in the above image to be rotated 90 degrees clockwise such that the 4/5 double row of holes (with the '04 plugged into the row for 4 holes) are at the top. The '04 uses a four-pin connector, while the slightly more sophisticated SRF05 uses a five-pin connector, hence the 4/5 double row of holes at the top of my board.

If we keep on visualizing my board in the image above as being rotated 90 degrees clockwise, then the six pins on the right are for programming. Meanwhile, the connector on the left can be I2C or SPI. The three-pin connector in the middle of the board (just under the 4/5 double row of holes) is designed to accept an analogue IR ranging sensor (but not at the same time as an '04 or '05, of course).
Finally, the five-pin connector at the bottom of the board is the I2C interface to the host MCU. The clever thing is that this is presented with exactly the same pin-out as an SRF08 (the LED, just right of the MCU, is connected to the trigger line). The idea is that, in its default configuration, my board!which costs only around $3 fully populated!can be used to make a $3 '04 or '05 sensor behave just like a $55 '08 module.

When I proudly presented the above image to Max, his immediate response was "That looks very nice, but where are the mounting holes?" Welcome to Revision 1.1:


First, this new version has mounting holes (never design a board for Max without mounting holes). Also, it has two more LEDs (as a general rule of thumb, you can't have too many LEDs on a board intended for Max). In addition to the trigger indicator, we now have an LED on the echo line and a power-on indicator LED on the back side of the board. (The echo LED has a jumper inline so it can be disabled when using the analogue input.)

By the time I'm finished with this and Max is happily roboting away, maybe I'll have the FPGA on my own robot ready to accept a dozen of these little boards.

Duane Benson
Marketing Manager
Screaming Circuits

Views(1725) Comments(1)
Total [8] users voted ????
[Last update: 09:27:53 PM, 23/12/2013]


Visitor 01:23:06 PM, 28/12/2013

I think you could make this even nicer if you continued the I2C offload...

It seems silly for the MCU to always have to request a sample, so it should have a mode where it just periodically samples every XX mS. ?It should then have an interrupt pin back to the MCU so that the MCU knows when a sample is available.

This makes the MCU logic very easy.

a) initialise device to sample every XXX mS as desired, and to trigger interrupt when done.

b) when interrupt occurs have the MCU retrieve the available sample and action it in some way.




Have Your Say!

Bloggers Say

Got something to say? Why not share it with other engineers?

Just introduce yourself to us, we'll contact you and set you up. Yes, it's that simple!

See what engineers like you are posting on our pages.

Interviews & Viewpoints


Learn how senior executives are seeing the industry from interviews and contributed opinions.

Back to Top