Gertboard - Camera Remote Control - Arduino Sketch #2 - Motion Detector

Continued from last post

This final version of the camera remote control project integrates the motion detector and removes the user input. This motion detector is properly called a PIR (Passive Infrared) sensor. It detects heat given off by bodies around it. The sensor is actually split in half. Motion is detected by there being a slight difference in the heat measured by the two halves. An IC mounted on the printed circuit board processes the sensor signals and gives a digital output that we pass to the microcontroller on the Gertboard.

Here is a very informative link about these sensors My sensor is slightly different than the one in that last link. Mine looks exactly like the one you see on Adafruit's web page. It has the advantage of two potentiometers, one to set the sensitivity, the other to set a time delay between the time motion is detected, and the time the output goes to a logic high. I spent a bit of time adjusting the sensitivity. The signal from the motion detector has an LED in the path on the Gertboard (see the block diagram in the introductory post of this project). This LED gives feedback that makes it easier to set the sensitivity.

Here is the new code:

I don't think it's necessary to discuss the code further, we covered it pretty well in the last post. The changes should be pretty easy to understand.

I would like to mention that this version does not require the Gertboard, or the Raspberry PI. Once the ATmega device is programmed, it will not lose the program even if it is lifted off the Gertboard and placed on another PCB. Everything can be bundled on a small printed circuit board like Adafruit's Perma-Proto Half-sized Breadboard PCB and placed in a small box with the motion sensor and the RF transmitter. Connect 5V and away you go.

Gertboard - Camera Remote Control - Arduino Sketch #1

Continued from last post

I have covered the project scope, the hardware involved, and the digital patterns we have to reproduce. What's left is the code to make it all happen. I have two sketches, Arduino parlance for source code. The first was written without using the motion detector. Instead, the user is prompted to input an "a" or "b" at the keyboard. An "a" transmits the code to take a picture. Pressing "b" is like pushing the camera exposure button halfway down. The second sketch, presented in the next post, incorporates the motion detector and eliminates the keyboard input.

I am using the Arduino IDE (Integrated Development Environment) to write the sketch, compile the sketch, verify the C code, and upload the machine code to the microcontroller. The only IDE function we cannot use is its serial monitor which provides screen output and keyboard input. The IDE's serial monitor requires a USB connection (as would be used with an actual Arduino product). The Gertboard has no USB. If we wish to send and receive data from the microcontroller, we need an alternative.

That alternative is a terminal program called Minicom. It's like the old DOS Telex program used to talk over the modems we used in the old days. The Gertboard User Manual talks us through its installation and configuration. Minicom communicates through the UART(Universal Asynchronous Receiver/Transmitter) port. This two pin port is signified by the pins TX and RX, both on the microcontroller and the Pi/Gertboard. See the block diagram two posts ago. TX of the Pi is connected to RX of the microconroller, while RX of the Pi connects to TX of the microcontroller. The stdio program we usually use for the Raspberry Pi is LXTerminal. Even though it has "Terminal" in its name it's really a command line program. If fact, as we do with most programs, we launch Minicom from LXTerminal.

Arduino IDE and Minicom on Pi desktop

Let's take a look at the script:

Thanks to the Arduino IDE, writing the script (C code) and getting the code onto the microcontroller is simplified. The functions for serial communications, time delays, and handling digital and analog inputs and outputs to the ATmega device are available without adding libraries. There are not even any #include statements in my script. Once you write the script, you don't worry about makefiles. One click handles compiling the code and uploading the machine code to the microcontroller. All of the built-in functions as well as basic C language is included in a very useful help reference. There are other libraries included in the software, as well, that you can include in your scripts. For example, there is a library for the 16x2 LCD displays, and a 1 Wire library (see my temperature sensor posts).

My script is divided into three parts: variable assignments, functions I have written, and the main part of the program. The main part of the program is divided into two parts: a "setup:, and "loop", as required by the IDE. "setup" runs when you first apply power, or first upload the code. It establishes the UART baud rate at 9600 bps and makes the ATmega pin we connect to the RF transmitter an output. "loop" runs continuously after that.

Looking at the variable assignments, there is something I do not understand. You see the variable "one_pulse", it establishes the minimum pulse width in microseconds. This is the time for the "H" or "L" pulse (see below), the time for all other characters are multiples of the time for "H" and "L". From the Audacity display, using the camera remote control transmitter, I calculated the time for "one_pulse" to be 284 microseconds. The time in my script, after altering "one_pulse" to match the patterns, is 415 microseconds, a difference of 46%. I've done a bunch of testing, and it's a mystery to me. If anyone has an idea please let me know.

The heart of the script is the two functions, "send_bits" and "transmit". As we cycle through the pattern we send the characters to "send_bits" then "send_bits" passes the definition of each character to "transmit". "transmit" sends the pattern to the microcontroller. I've repeated the diagram from the last post here to make it clearer how the characters, "H", "L", "E", "A", "B", and "T" are defined:

For clarity: Only the Beginning of the Pattern Is Shown

An important note: The 434 MHz transmitter inverts the bit logic. If I send a low pulse from the microcontroller, to the RF transmitter, the RF transmitter sends a high pulse. That is why a low is written to outpin when the variable "is_high" is true. I think the rest of the code should be pretty straight forward.

Gertboard Project - Camera Remote Control - Introduction

I have a remote control device for my camera that consists of a receiver and a hand-held transmitter. Wouldn't be great to have a motion detector trigger the camera using this remote control receiver? I could also take exposures at timed intervals without my being near the camera. The Pi and the ATmega microcontroller on the Gertboard provided most of the hardware to do the job. I only needed to add a $10 motion detector from Adafruit, and a four dollar 433MHz RF transmitter from Sparkfun.

I have not made an enclosure so everything is just loose wires and components. When using the motion detector, once the ATmega microcontroller is programmed, the Pi can be disconnected. Just a source of 3.3V will be required. While the Pi and Gertboard combination is a good development platform, a standalone project that does not require a user interface would be much simpler. Adafruit has a couple of ATmega32U4 development boards that are tiny, cost only $20 and can be programmed over USB. Check out this one, and this one.

This is what my Pi-Gertboard combination looks like now:

Tangle of stuff to Remotely Control My Camera From a Motion Detector

I have a Canon RF remote control receiver and transmitter combination. It works with Canon's digital SLRs and their G series cameras. Luckily, the documentation that came with the remote control gave me the frequency of the RF devices. It is 433MHz, which, I believe, is more commonly used in Europe. References to the frequency of these devices seem to be reported as 433MHz or 434MHz. Most RF remote control devices manufactured in the US use 315MHz. Sparkfun also supplies receivers and transmitters for 315MHz.

The following is a block diagram of the setup showing only what I thought was necessary to show. You may wish to click on the image to see the fine details.

Block Diagram

The next post will report on how I ascertained the information the remote control transmitter sends to the remote control receiver to control the camera. Subsequent posts will present the code to control the camera using the ATmega microcontroller.