Low cost RF camera trigger

I just wanted to make some night shots, but commercially available triggers are too expensive, so I decided to make my own RF-enabled device

Description

I bought a super-zoom HS-35EXR camera and wanted to take some night shots with a tripod: the best reasonable choice you may think of would be a remote trigger, in order to avoid pushing the trigger button and move the camera while taking those long-exposure (up to 30") photos. Commercially available triggers were kind of expensive and if I bought one on eBay, I'd take up to 2 months to be delivered to my house (dude, I live in Guatemala), so it wasn't a feasible solution.

As a low-power obsessed guy, I chose MSP430 microcontrollers to make the dirty job. First prototype was done with the ones included on MSP430 Value-Line Launchpads (MSP430G2553). But, what if I used that new Energia Arduino-like IDE? After all, I wanted it to be done ASAP. I tryed to port VirtualWire library to Energia, but every try I did was unsucessful. So, I thought it would be a good exercise to develop a library to drive those extremelly cheap 433MHz ASK/OOK radios. That's how everything was born.

Details

RF Library

RF 433MHz Library's development was based on the knowledge form this paper:

http://www.rfm.com/products/apnotes/tr_swg05.pdf

Also, this library was written to be compatible with any microcontroller available in Energia. This is a cool advantage, because you may cycle among (theoretically) every microcontroller supported by Energia. Of course, as it's done via bit-banging, max speed is not as good as a hardware-based solution. But, well, the latter is and advantage too, because the lower the data bandwidth, the higher the SNR is!

Data codification was done via 4B6B in order to keep DC balance, and simultaneously reduce BER.

Also, as you may use different addresses on each device, you may talk to many nodes with no interference within the same RF range. And what about range? Well, I've done some tests, and was able to transmit data successfully up to a distance of almost 1000 ft. Of course, everything was done with a pair of "AA" batteries (both Tx and Rx).

What about the trigger?

The HS-35EXR has a mini-USB female connector, but the "reserved" pin is used to "sense" some basic instructions. As I realized while experimenting with the camera, that pin seems to have an internal 34k pull-up resistor. It looks like if it had a 2-bit ADC, detecting different levels between 0 and 5 volts. If voltage goes below 1.2 V, the camera takes a shot, but if the voltage on that pin remains between 1.2V and 2.4V, an "autofocus" instruction is executed.

How is it possible to achieve those analog voltages with a microcontroller? Well, as there is a default 34k pull-up internal resistor in the camera, I just tied a 82k and a 18k resistor to a 2N7000 (each) in an open-drain configuration, so they would perform the required actions when activated from the microcontroller.

Notice that the shutter/autofocus functions may also be triggered via those two large push-buttons shown in the picture, just in case your batteries go out of power.

Future work

I''d like to add a user interface on the Tx side in order to go further and convert the remote trigger into a remote intervalometer, so I'd be able to take some nice long-exposure timelapses.

Also, if you carefully check the receiver's picture, you may notice there is an ASK IR TV receiver: this is how I plan to implement the intervalometer, using a cheap IR remote control (those ones you may easily find on eBay).

As this was the very first prototype, it was done with most of the components I had at home. Next revision is planned to be done with SMD parts. Well, and an ergonomic 3D-printed case for the transmitter wouldn't be a bad idea, though.

Discussions

Gabriel wrote 07/23/2014 at 19:28

Your post motivated me to read more on the modulation/encoding to get the most out of the cheap RF modules. I learned something today, thanks!

I get you are transmitting your data with a nice DC Balance, but how do you manage the receiver side? Those modules spit out tons of noise, how do you ignore the noise until your clean signal comes in? From what i understood you are using software to receive, which can only mean polling. how do you keep your code from trying to read a byte off of every spike the receiver throws?

SO MANY QUESTIONS!!!!!!!!!

Are you sure? yes | no

imoralesGT wrote 07/28/2014 at 16:54

Hi [Gabriel]. Great to know it was useful :P

As it states on the paper cited at the beginning (and as you said), at the receiver side you may listen to random noise all the time. However, if you send a "known" pattern from the transmitter side and it is near enough, the receiver may listen to that sequence: in this case, you must set a target address both at the Tx and the Rx side. The Tx will send a packet starting with the ADDR and that's what the Rx is waiting for. And until the Rx detects the valid address, it will start fetching data, and then checking parity. Note that this wouldn't be possible to implement without the right coding scheme. As this is a simple implementation, the packet contains only 3 bytes: ADDRESS, DATA, PARITY_CHECK.

Oh, I almost forget it: while polling at the receiver, the sampling frequency is 8 times the data rate. Each sampled bit is passed through a software integrator, and only after that, you may decide whether you detected a "0" or "1".

Are you sure? yes | no

Gabriel wrote 07/28/2014 at 17:45

Its that integrator that does the trick and the explanation i was looking for.
So, you sample 8 times after each transition, and based on a (I'm assuming) simple average of 8 samples you determine a high or a low. I'm assuming you then have a lower and upper limit of what is the minimum average that passes as a 1 or 0

I like it!

Are you sure? yes | no

imoralesGT wrote 07/28/2014 at 17:46

You're right. The faster you sample, the higher Signal/Noise ratio you get. Of course, there is a limit while sampling rate tends to infinity, but this is not the case.

Are you sure? yes | no

imoralesGT wrote 07/28/2014 at 17:51

If you look at the code, there is a boolean method (readAndIntegrateBit). Check line #131, there is where the limit between '0' and '1' is set.

Are you sure? yes | no

Low cost RF camera trigger

Description

Details

Discussions

Similar Projects

SNAP: Augmented Echolocation

Laptop Webcam Reuse Made Simple

VR Tracker

Less than $100, high FOV, mobile AR glasses

Low cost RF camera trigger

Become a Hackaday.io member

Just one more thing

Description

Details

Enjoy this project?

Discussions

Become a Hackaday.io Member

Similar Projects

SNAP: Augmented Echolocation

Laptop Webcam Reuse Made Simple

VR Tracker

Less than $100, high FOV, mobile AR glasses

Does this project spark your interest?

Report project as inappropriate

Send message

Remove Member