Video surveillance systems have rapidly grown from being a specialized equipment for high-risk areas (like banks and airports), to the point of being standard facilities of most places open to the public. Nowadays, no shopping centre, office, industry can afford lacking one. In conjunction with a time-lapse video recorder, these little cameras play an active role discouraging theft and collecting evidences and precious information about the offenders.
Standard systems won’t do.
My tailored solution.
You only need to setup the camera once. An infrared remote control and voice-prompt menus allow easy operation, even when the camera is concealed or installed in places like ceiling corners.
When the card is full, new images replace automatically older ones, so you get always the most recent snapshots. You won’t even notice the system is working; there are no moving parts, no fans, no electrical power wasted.
How it works.
The most important hardware component is the ITC328 camera module. It consists of a VGA (640x480) CMOS colour sensor and a JPEG-compression chip. The compression engine includes a serial interface at 3.3V levels that can be connected directly to a microcontroller’s UART. Issuing the appropriate commands you can take snapshots as JPEG-compressed byte streams. The camera comes in a handy module with everything including the lens, and a 4-pole connector for power and data.
The most important software component is the AVR-DOS file system. It is a library for driving mass storage devices, like SD and MMC cards, CompactFlash, and even hard disks connected to the AVR microcontroller. It provides an high-level programming interface for accessing disks formatted according to FAT16 or FAT32 specifications, which means its files are directly compatible with PCs. By linking AVR-DOS to your program you can create and open files, write and read data, create and change directories with simple commands, like you would do on a PC. Restricting read/write access to one file at a time, the FLASH and RAM footprints are minimal (8kB and 1.3kB), making it possible to use a small 8-bit AVR device like the Mega32 for tasks usually accomplished by 16- or even 32-bit processors.
These two blocks are the foundation and starting point of the Witness Camera design. With the aid of the simplified block diagram of Figure 1, let’s see how these block interoperate during normal operation as a time-lapse recorder.
This diagram introduces a second hardware block, the PIR (Passive Infra-Red) movement sensor model ITM256. This module can sense people up to 5 meters/16 feet away, by measuring changes in the infrared radiation caused by human body temperature. It is a cheap mass-production part from the burglar alarm market, including a Nicera RE200B thermopile and a KC778B companion chip in dice form, under the familiar epoxy blob. A Fresnel lens with an angle of 60º snaps in the PCB, which connects to the outside world by means of a short 3-pole cable (power, ground and signal).
The PIR triggers a software block, the recorder, which is in charge of deciding if and how many pictures to take according to its trigger inputs and operating mode. The recorder controls the camera driver (another software module) in order to get the JPEG byte stream. The real-time clock is an hardware feature of the AVR controller, and the recorder uses it both for time-stamping the JPEG files with current date and time, and as an interval timer if time-lapse photography mode is selected. After time-stamping, the recorder hands over picture data to the file system, which stores it permanently on the SD-card.
During setup the user interacts by means of an infrared remote control (I have used an off-the-shelf universal remote), and the Witnesscam responds with voice prompts. The prompts guide the user through the editing of all the operating parameters (date, time, recording mode, picture resolution, number of frames to take each time the sensor triggers…).
The voice menu block is the software module running the user interface. It takes the pulse train from the infrared receiver as input, and after decoding it uses it to edit the settings from AVR’s non volatile memory. During this process, it invokes the speech synthesizer module, which provides the primitives needed to compose and play the messages.
The speech synthesizer takes advantage from the existing mass storage capabilities, using the file system in read mode. The flash disk must be prepared in advance with a special set of files with audio samples for each word or status messages to be pronounced, e.g. the file “15.PCM” stores the waveform samples for the word “fifteen”. Reconstructing the audio signal is then a matter of opening the file and sending the samples to the AVR PWM feature.
The complete picture.
This chart shows the file system exploded into its constituents: the AVR-DOS library, the underlying SD-MMC software driver which takes care of low-level access to the physical media, and the SD-card itself. The card talks to the AVR via the hardware SPI interface, which is notably fast in Mega devices.
Another added functionality, introduced in order to preserve disk integrity, is power monitoring. The system must cease any disk write in case of problems. It measures both main and battery voltages using the 10-bit AD converter of the AVR.
The remaining functions are not essential for the Witnesscam to work, but make development and use much easier. With the PC debug port you can log system operations messages (disk size and free space, JPG file size, read and write file access details, remote control codes received) for diagnostic purposes – or just for the pleasure of watching the internal clockwork in action.. I created the port bit-banging an I/O pin, a technique that works perfectly for low baud rates (9600) and allows setting of signal polarity. That is, you can connect the AVR pin straight to the RX pin on PC serial port, without any interface logic (a priceless trick for debug).
The AVR can drive LEDs from all of its general purpose I/O pins. I have provided two status indicators on the front panel. They are useful to verify the PIR sensor range and to check if disk is actually recording.
Notably, I have introduced two extra LEDs inside the box, next to the SD-card slot. I call this the “disk semaphore”: when the green light is on, it’s safe to extract or insert the SD-card from its slot. A red light signals that a disk operation is in progress, and you must wait before touching the SD-card. A simple algorithm inside the main recording loop determines what light to put on based on the status of the recorder, the card detect switch from the SD-card receptacle, and the lid detector switch that notifies the system when the camera case is opened.
The final circuit of the Witness camera works out the details of interfacing the modules introduced by the block diagram, and supplying power as appropriate. The circuit develops around the AT Mega 32, and most interfacing resolves to straight connections, as all AVR I/O pins provide programmable pull-ups and respectable output current. One notable exception is the PIR movement sensor (Intertec’s ITM256), which is a 5V part (opposed to the rest of the circuit that works at 3.3V), and needs an independent power regulator (IC3, an LM2936-Z5 low-dropout, low quiescent current regulator from National). A separate regulator is beneficial in this case, as it provides extra power decoupling for some very sensitive analog amplification contained on the PIR module. A series resistor on the PIR output is an inexpensive way to adapt its 5V output to the 3.3V input level of the AVR.
The camera module (Intertec ITCM328) connects to the UART RX and TX pins. Communication runs at 115200 baud, thus I selected a 7.3728 MHz crystal for exact bit timing. The SD-CARD connects directly to the SPI port pins. The card connector is a Yamaichi FPS009-3202. I like its space-saving outline, with most of its pin placed inside its body instead of sticking out.
The connector features also extra signals indicating card insertion status and the position of the write-protect tab of the card. I routed them to two spare I/O pins (internal pull-ups enabled). A different kind of switch, the micro switch detecting when the lid is opened, and the external trigger switch connect in the same way to the AVR.
However, I selected one of the three AVR interrupt pins for the external trigger, in order to capture and flag automatically any transition. The same applies to the PIR input (think of it as an “internal” trigger) and the remote control input.
The latter pin comes from a Vishay TSOP34836 infrared receiver IC. This inexpensive part is mass produced for the consumer market (TV, VCRs, DVDs…) and is tuned for 36kHz infrared bursts (like the RC5 encoding required by the Witnesscam). You can replace it with similar parts from other manufactures; I selected it for its immunity to false triggers, which improves Witnesscam’s overall performance.
As regards the outputs, four LEDs showing device status take half of the port A. A spare bit on port C drives the relay output by means of the typical transistor & diode network. I used a BC847 and 1N4001.
As previously detailed while describing the audio subsystem, the same conventional circuit drives the output speaker in an unorthodox way. I tried it for fun, and it worked so good that I didn’t change it.
Another unorthodox section is the serial port built around port C, bit 5 of the AVR. Being a software implementation, its polarity is reversed compared to an hardware UART, so the usual additional polarity inversion circuitry is not required. You can connect it to a PC running a serial terminal program for debug or troubleshooting: connections to the PC DB9 pin are PC-TX to DB9-PIN3, PC-GND to DB9-PIN5.
Admittedly, this circuit doesn’t meet RS232 specifications (no negative voltages, just 3.3V swing, imperfect timing during interrupts limiting speed to 9600 baud), nonetheless it’s a zero-cost solution that does its job.
The following part will be devoted the microcontroller software where mainframes of algorithm, their features will be considered.