HC-SR04E Ultrasonic Range Finder

I've got this idea of using ultrasound triangulation to help guide a model helicopter during take-off and landing. You would have launch pads with three separated ultrasound transmitters, and the copter would have an ultrasound receiver, connected by some bus to its flight controller. It wouldn't have a particularly great range, but away from the ground other sensors (GPS, compass, gryo, accelerometer) are good enough for flight control.

A few weeks ago, I ordered four ultrasonic rangefinders from 12geeks, an online shop run by some very nice chaps in Singapore. I didn't know much about the sensors I'd ordered, apart from that they were cheap and widely used, didn't do exactly what I needed, but were sufficiently close to be interesting.

The particular rangefinder I'd ordered was named the HC-SR04, and had been originally designed by Devantech Ltd, a small Norfolk-based electronics firm specialising in robot sensors. The HC-SR04 works by sonar: issuing a burst of 40kHz sound from one ultrasound transceiver and measuring the time taken for the echo to reach a second transceiver. This time is then sent to the sensor's output pin as a pulse, with a duration proportional to the echo time.

On Devantech's site, there is a detail-packed page explaining the design of the sensor, including a circuit diagram, showing the connections between the microcontroller and transmitter/receiver.

You can see that the microcontroller is an eight-pin PIC12C508, which isn't reprogrammable. It was clear that if I was going to adapt the sensor to a different application, I would need to replace the microcontroller, so I ordered a bunch of eight-pin Atmel AVR chips (ATtiny85). I planned to remove the PIC chip, add some tiny pin headers, and use a daughter board for prototyping the AVR replacement.

Then the sensors arrived from 12geeks, and I realised the sensor had undergone various design changes. Gone was the eight-pin PIC, to be replaced with a 14-pin Taiwanese EM78P153S, with more connections to the send-receive circuits than could be handled by the eight-pin ATtiny. Bugger. Here's what it looks like, after the microcontroller has been removed:

Luckily, I found that someone else had been working on the same problem, and he had done almost all of the documentation necessary for me to work with the current design. Even better, he had redesigned the circuit board to take advantage of all the existing components, apart from replacing the microcontroller with a 14-pin AVR (ATtiny24a) and crystal oscillator. Building the board should be a simple matter of removing components from one board and soldering them into the same position on the new board (which has been tentatively named as the HC-SR04E). I ordered the boards from a prototyping PCB printer, and am waiting for them to arrive. When they do, I will probably have to invest in a hot-air soldering gun if I'm not going to fry the components.

While I'm waiting for the boards to arrive, and plucking up the courage to tell my wife I need a hot-air gun, I've ordered some 16-pin PCB headers and sockets, together with a SOP14 to DIP14 adapter, which I can use to build a daughter board.

I've also been thinking about software. Most sensors used in flight control use I2C as a communication bus, so my first task has been working on getting an interrupt-driven implementation running on the ATtiny24. I'm used to working with the ATmega328P, so thought this would be a simple matter. It is not. The ATtiny24 doesn't have a hardware implementation of TWI (Atmel's version of I2C); instead it has something known as USI (universal serial interface).

After communication is done, I'll start looking at how the sensor's clock can be synchronised to a more accurate source, which will be necessary if the HC-SR04E is ever put into mass production, with uncertain precision of crystals being used.

Anyway, there's very little on GitHub yet, but should be some progress soon: HC-SR04E source code.

Please get in touch if you'd like to get involved with the project, especially if you're in Singapore, in which case I'll be able to share some of my hardware.