Surveillance camera ensures your valuables aren't part of the vanishing act
A safe home is a happy one, but many off-the-shelf surveillance cameras are too expensive or simply impractical for home use. That's why designer Alberto Ricci Bitti created an automated and inexpensive surveillance camera that uses a flash card as recording media.
All the required functionalities fit inside a small 8-bit microcontroller and the design harnesses the potential of the ATmega32: almost every hardware component of the AVR is put to good use, resulting in a leaner, more cost-effective parts list. The camera only needs to be set up once and an IR remote and easy-to-use voice-prompt menu means this award-winning design will be the star of the show.
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.
Despite their huge commercial success, video surveillance recorders have had little impact on residential markets. No doubt they would be useful at home as well as they are at work: according to the Police, most home thieves go unpunished, so in a sense homeowners must help for themselves.
I have always wanted a video recording system protecting my house, but commercially available systems didn't persuade me. Let's see why.
Standard systems won't do.
Commercially available systems are not designed for home use, and unfortunately don't adapt well to the new role. Problems start with the time-lapse recorder, which is a special recorder capable of recording several days of slow-frame-rate video on an ordinary VHS tape or a big hard disk. Most units are solidly built and usually they worth their money, nonetheless my concept of reliability for home use is "install and forget", which doesn't match hard disks or tape heads spinning forever.
If the price tag and periodic functionality inspections are OK for you, there is always the problem of placement. You need a out-of-sight place, spacious enough to accommodate the recorder and the video display, because images can only be inspected using the original recorder.
Another issue differentiating between commercial and residential systems is the way you run the wires from the camera to the recorder. For shops and offices you can easily pass the cable under the floor or over the ceiling, but if you live in a old brick house like me, you simply can't do it without cutting the walls. You can try RF-linked cameras, if you don't care wiping out all WiFi networks in your neighbourhood (and you are not concerned about exposing your privacy). Alternatively, you can use good WiFi cameras that by definition preserve the network, with only drawback of consuming most of the bandwidth for themselves...
My tailored solution.
The Witness Camera is a combination of a VGA CMOS camera, a passive-infrared movement sensor, a 1 GB SD-card (or bigger), and an AVR Mega32 microcontroller implementing a solid-state time-lapse recorder. It is a compact, complete, self-contained surveillance system designed with home users in mind. It can be installed in minutes wherever there is a mains plug, and it is affordable because of it is built using an handful of inexpensive parts.
For most typical domestic environments, it can store more than one month of images at a maximum rate of a colour picture every 2 seconds (320x200 pixels, comparable to VHS-CCTV recorders), or 3 seconds (VGA, 640x480 pixels). Recording starts automatically upon detecting a movement. Alternatively you can set a timer, or supply an external trigger, and even do continuous recording.
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.
In the (unfortunate) case you need to investigate the images, just take off the card from the camera and put it on any PC or laptop with an SD-card slot. Specialized software is not required: the Witnesscam records its files using a standard file system (FAT16 or FAT32) and image compression format (JPEG). Retrieval is immediate as the camera sorts the pictures in folders according by date and time.
How it works.
The Witness Camera operation is conceptually simple, but involves many ingredients. Some are physical components, the others are software blocks. To make things clear, I will introduce them gradually, according to the operating mode.
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.
Having a file system in place opens up many possibilities to the world 8-bit microcontrollers. Once you try it, it's hard to go back. The capability of accessing huge data files is exploited also in the other operating mode of the Witnesscam, the setup mode.
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.
Samples compression is unnecessary. Years ago, devoting more than one megabyte of flash for this purpose would have been regarded as extravagant opulence, but today this figure represents about 0.1% of flash disk capacity! So this technique is cheaper than an LCD display, and ways more effective, because it's expected that the camera is concealed or placed out-of-the-way.
The complete picture.
The complete block diagram is the sum of the two previous diagrams plus some extra details. The software modules are drawn inside the AVR Mega32 body. For ease of reference, the relevant source file names are given in italics.
The complete block diagram isn't trivial. It includes both hardware parts and software-only objects and libraries (file names in italics). The Mega32 is a perfect fit for this design, as almost all of its features are used.
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.
There is a new file manager layer (file archive.bas) mediating between the recorder and the AVR-DOS file system. Its purpose is to provide helper functions like determining the oldest files in the archive, deleting unused stuff to make room for new images, and creating an orderly set of directories and files to archive the pictures according to the time stamp.
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.
BASIC instinct.
The most peculiar aspect of this design is that the firmware is written in BASIC. I'm a strong advocate of using C for embedded systems, and I use routinely the excellent GCC compiler for AVR development on PC and Linux platforms. But at the time I was waiting for the samples of the camera to arrive, I was asked to select a BASIC compiler and IDE for an educational board my company was developing.
BASCOM-AVR from MCS electronics is a stable, popular product with a rock-solid user base, and a syntax similar to Visual Basic. The IDE installs with lots of examples, and you don't need anything else to make your applications. Actually, the IDE integrates all sorts of accessories including a simulator, a chip programmer and (nice touch) a serial terminal.
While browsing the online help, my attention was caught by the AVR-DOS library supplied with the package. The help includes a schematic for wiring an SD or MMC card to the SPI, and a 3-line-long code snippet for writing a text file:
open "README.TXT" for output as #1
print #1, "HALLO FILE!"
close #1
I couldn't resist trying it. I grabbed an SD-card from the nearest photo camera, the Atmel's STK300 evaluation board and a soldering iron. A few minutes later, Windows Notepad running on a 32-bit, 3 GHz machine was opening a file written by an 8-bit, 8 MHz AVR microcontroller. I was hooked.
print #1, "HALLO FILE!"
close #1
I couldn't resist trying it. I grabbed an SD-card from the nearest photo camera, the Atmel's STK300 evaluation board and a soldering iron. A few minutes later, Windows Notepad running on a 32-bit, 3 GHz machine was opening a file written by an 8-bit, 8 MHz AVR microcontroller. I was hooked.
BASCOM does a good work at simplifying hardware access. For small applications, it's a time saver. Do you need a real time clock? Just tell the compiler, and he will do the hard work of making timer interrupt code specific to the AVR flavour you selected. Do you need buffered serial I/O? Just select the buffer size and baud rate. The list of supported features is long - RC5 infrared remote control, ADC readout, timers and PWM setup, to name a few that were useful for the Witnesscam project. But also graphic and text LCD, 1-wire devices, SPI and I2C busses, PS2 mice, AT keyboards, and even a TCP/IP stack.
On the other extreme, as the complexity of your application increases, you will miss C type checking, aggregate types and support for modularity. Also, BASCOM error massages are obscure when not misleading, and lacking of automatic type conversions and true expression handling is an unnecessary pain. My advice is to stay on C if you expect to develop more than 64 kB of code; for smaller designs, like this one, it makes sense to opt for BASIC if you are exploiting most of the built-in features it offers. BASCOM supports structured programming, and with a bit of discipline you can write code as organized as you can do in C. See the sources for my best attempt at doing it!
Filled to capacity
Keeping the disc filled to capacity, but not overfull, was a challenging problem.
In theory you can get disk occupation calling diskFree(), find the oldest file in the disk and delete it. In practice it turns out that both operations are time-consuming, so you must avoid them as much as possible. To complicate matters, file size isn't constant. It depends on the scene and how it gets compressed by the JPEG algorithm. It depends also on the time of acquisition, because storing a picture file may require creating new directories (hence more disk space) each time the year, month, day, or hour change. And users are free to select a different resolution or recording mode at any time, changing the space required to accommodate new files.
I developed an heuristics based on common-sense rules:
When the disk is only partially full, it is sufficient to check disk occupation only every now and then, and all files can be conserved without problems.
As disk occupation increases, the amount of space left need to be checked more frequently, and it's wise to start deleting some files. As deleting files burns precious machine cycles, it's preferable to do it when the camera is idle, i.e. recording isn't triggered.
Should disk occupation reach its limits, disk occupation checks must be performed frequently. Deletion of oldest files must be performed anyway, even if the processor needs resources for recording, because of the risk of getting out of disk space.
Careful section of the value for deleteWhenIdle and cleanupInterval improves recorder's performance in all but continuous recording modes, because all erasing is performed when there is nothing else to do. If you feel 1000 pictures is a large number, consider it represent a negligible percentage of full disk capacity. It takes time to get accustomed to the Gigabyte Age!
The flow chart in Figure 4 should shed some light on how the heuristics works. Experimentation in my house as PIR-triggered recorder resulted in all file erases performed during idle, calling diskFree()at most every 30 minutes.
Speech preparation.
The Witnesscam speech synthesizer plays a set of speech files to build its messages. You can record the files with your own voice if you want, but I was reluctant doing this, so I used computer-generated speech instead.
I would like to tank the people at AT&T Research Laboratories for giving me the permission of using samples from their Natural Voices system for this contest. Those unfamiliar with this technology can test their fantastic software online (http://www.research.att.com/~ttsweb/tts/), typing-in any text and listening for a warm, natural voice reading it.
I used the AT&T online demo tool to download a set of .WAV files with the words of interest. I selected a male voice (Mike) in order to reduce the content of high frequencies as possible. The Witnesscam dynamic range is 8 bit, and sample rate is 11,250 Hz, so I used a sound editing program (Cool Edit Pro) for down-sampling. I compressed the voice waveforms using the dynamic compressor tool in order to compensate for the reduced bit resolution (AT&T audio files are 16-bit). Then, I normalized the amplitudes, and saved each speech segment in a separate file as 8-bit "unsigned" samples - that is, raw numbers where silence corresponds to a value of 128.
At run time, the Witnesscam uses the file name to select the files to play. It expects to find them under a common folder named "speech". Sound playback technique is brutally tricky. The samples are banged straight to the PWM without buffering, the only timing coming from a busy-wait loop. Ironically, the unpredictable delays due to disk access add a pleasant chorus-like effect, making the voice warmer and fuller.
The circuit amplifying the PWM signal is even more brutal, using just one transistor and trusting the speaker elastic properties for filtering higher frequencies and moving the cone back to the positive direction. These shortcuts limit the kind of speaker to use: if it's too small, the Nyquist products will be audible, if it's too large, it won't jump back in time for the next audio peak. I have experimented with various sizes from my junk box, and found that a 75mm/3" speaker works well - surprisingly well. A clear sign that speech is like no other sound, because the brain is capable to reconstruct the voice from very little information.
Circuit implementation.
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. Don't replace it with the more common 8MHz as the camera module is picky about baud rates. 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.
I've been less parsimonious with the power supply: it's easy to overlook power supply issues. The camera and the flash disk have an impulsive behavior, consuming almost nothing when not in use and drawing intense bursts when writing or compressing an image. Thus I provided both a 100 µF electrolytic and a 0.1 µF ceramic capacitor for most parts. These caps are outlined in a separate section of the schematic diagram, take care to place the capacitors near to their respective owners.
DC power comes from a wall-wart adaptor and a battery pack. The batteries keep clock running (see the 32.768 kHz crystal), while ensuring completion of disk operations during power outages. A 15V varistor cuts power spikes, and diodes D1 and D2 mix the power sources prior to power regulators. The 1N5822 are Shottcky diodes in order to optimize the voltage drop. The 3.3V regulator is a LM1117-3.3 (National Semiconductor) low-dropout regulator.
The circuit monitors its own power to safeguard disk integrity. Two identical divider networks for battery power (R3-R4-C5), and mixed power (R7-R8-C8), reduce voltages to safe levels suitable for ADC pins. Don't omit the capacitors that smooth the measurements and provide a charge tank for sampling.
Almost all of the parts (with the notable exception of the camera, see the FAQ for details) can be obtained from RS Components: here are the part numbers:
CIRCUIT
Posts
