logo1.bmp (61374 byte)

how to build 
 a witness camera


This the full description. Looking for a short abstract?

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. This is an expensive piece of equipment: prices start at $300 for a tape recorder, but if you look for a reliable brand-name device be prepared to pay more than $1000, and $1500 for a hard disk system. 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 ($150), 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 - another $2000 to the bill. 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, which is outlined in Figure 2.

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 of Figure 3 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.

Figure 3. 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.

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:

Based on the assumptions above, I wrote an algorithm that computes the value of two variables, deleteOnWrite and deleteWhenIdle, storing the number of files to delete according to the recorder’s state. (see diskCleanup(), file “archive.bas”). The algorithm computes also the interval between checks, cleanupInterval, using the rules outlined above and the following table:

Mega Bytes left

# of files to delete each time a new file is recorded

# of files to delete when idle

time before next disk occupation check

> 60



1 hour

> 30


Up to 1000

½ hour

> 20


Up to 1000

½ hour

> 15


Up to 1000

¼ hour

> 10


Up to 1000

¼  hour

> 5


Up to 1000

5 minutes

> 2


Up to 1000

5 minutes

Less than 2


Up to 1000

1 minute

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.

Figure 4 – Flow chart of the heuristics that keeps the disc filled to capacity.

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.Figure 5 - Using CoolEditPro, a sound editing program, I compressed the voice signals to make the voice more intelligible after a dynamic range reduction from 16 to 8 bits.

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.

witness camera schematic diagramThe 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 the worldwide RS-components network: here are the part numbers:

RS part code
D1,D2 Shottky diode
TPH alternative: 1N5822
D4,D5 Diode (LL4148 or 1N4001)
TPH alternative: 1N4001
C1,C2,C3,C4,CB1,CB2,CB3,CB4,C5,C6,C7,C8 100 nF ceramic capacitor (1206 case)
C9,C12, C13,CB5,CB6,CB7,CB8 100uF/25V electrolytic capacitor (TPH)
TPH part
C10,C11 15…22pF ceramic capcitor (1206 size)
VARISTOR1 15Vdc transient suppressor
Optional part
SW1-DETECTOR microswitch, lever actuated
XTAL2 32.768kHz CFPX-56 watch crystal
TPH part
XTAL1 7.3728 MHz crystal
TPH part
CARD1 Yamaichi FPS009-3001-BL SD/MMC card connector
IC3 Ultra low dropout voltage regulator, TO92 case
TPH part
IC2 LM1117T-3.3 fixed voltage regulator
SMT part mounted on heatsinkon TPH side
SW1 Two pole toggle switch
R5,R6 1000 ohm, 0.25W, 5% resistor (size 1206)
R2, R11 100 ohm, 0.25W, 5% resistor (size 1206)
R3, R7 10 kiloohm, 0.25W, 5% resistor (size 1206)
R1 100 kiloohm, 0.25W, 5% resistor (size 1206)
R4, R8 2.2 kiloohm, 0.25W, 5% resistor (size 1206)
R16 50 ohm, 0.25W, 5% resistor (size 1206)
R12,R13,R14,R15 330, 0.25W, 5% resistor (size 1206)
Q1,Q2 BC817 transistor (SOT123 case)
LD2 Red LED, 3 mm
TPH part
LD1, LD3, LD4 Greem LED, 3 mm
TPH part
RELAY1 Subminiature relay, 10V coil
TPH part
ISP CONNECTOR 10-way box connector for programming
TPH part
IC4 Atmel AtMega32 AVR processor
LS1 8 ohm, 3 inch diameter loudspeaker


From concept to prototype.

I started the development with the card and the camera connected to and Atmel STK300 board and a Mega128 chip. Developing on a larger chip facilitates development, as you have extra pins, flash and RAM to use for debug. Once I gained confidence in the design, I started building a prototype.

With most parts being SMT devices, I decided it was time to learn etching PCBs at home. As a debutant, I knew in advance the board would have been a single-sided one. Thus I adopted a couple of tricks worth mentioning.

First, I designed the board as if it were double sided, except I placed as few and streamlined copper-side tracks as possible. I ended up with just a dozen of them. Later, I etched only the component-side tracks and replaced the copper-side tracks with short lengths of thin insulated wire (the black jumpers you can see on Photo 3).

Second, I placed all through-hole parts on the (now trackless) copper-side, so they can be soldered to the pads lying on the same side as the SMT parts. I opted for through-hole version of all cumbersome components (like electrolytic capacitors and power regulators), in order to get a flat SMT side facilitating SD-card access.

I didn’t use special tools for etching: I printed a mirrored layout image on plain paper, and used it to expose pre-coated PCB material manufactured by Bungard, a German company. The light came from three standard-white, energy-saving lamps from IKEA. Exposure time was very long to balance for the use of non-transparent paper and the low amount of UV light produced by the lamps.

Despite this rude setup, the board turned out well.  After soldering and double checking every component, I was ready for applying power and programming the AVR.

BASCOM makes the porting from Mega128 code (used for the STK300) to the Mega32 (prototype) a trivial process. I merely selected the new target processor from IDE and changed the single line of code that used the second hardware UART of the ‘128, instructing the compiler to use a bit-bang implementation instead. Everything else is handled automatically by the compiler.

The PCB doesn’t hold all the parts. The camera and PIR sensor, among others, are placed on the enclosure box. I used breakable pin-strip headers for removable connections to the parts secured to the box. Use of coloured self-shrinking tubing, together with colour-encoded labels, helps preventing connection mistakes and gives the unit a tidy aspect.

The enclosure needs special care. The SD-card must be extracted without removing the PCB screws, so the PCB must protrude on top of the box walls. Also, the lid-switch must be placed in a way that it gets engaged when the box closes.

I have modified a sturdy plastic box originally intended for holding electric switches (SCAME). I removed the DIN-Norm rail that was provided for switch holding on its bottom. I placed the loudspeaker in its place, drilling the holes for sound diffusion. Then I have positioned the lid-switch, and the supports for the PCB (cut from soft aluminium sheets), fixing them with extra-strong double-adhesive tape.

The front panel consists of a cut-out of black plastic holding the camera, PIR sensor, remote control sensor and LEDs. It is secured to the front of the box with the same adhesive tape.

The finished  prototype is aesthetically pleasant. Place it on your living room, the remote control next to it,  to have a real piece of conversation for your next party.


How to use it.

Designers should never dare to say this, but yes, the Witnesscam is easy to use.

System setup requires you to copy the entire SPEECH folder to a blank SD-card. Then put the card in the camera, close the box, select an appropriate camera location and run the power cord from the wall-wart to the Witness camera. You are almost finished.

Once the camera is powered-up, it will greet you: “This is the Witness Camera recording system!” and give a readout of current settings (BRIEF key on the remote control replays it at any time).

The camera is immediately operating and taking pictures. The PIR LED fires each time a movement is detected. The RECORD LED fires when images are being recorded on the SD-card.

The first time, you need to set the clock.

The default setting is movement-triggered recording, taking 5 extra frames after the movement ends. If you want to change it:

Picture inspection.

You can check the pictures at any time without powering off the camera. As soon it detects that the case is being opened, the Witness camera stops recording. Likely, any pending disk operation is completed  by the time you finish removing the lid. Anyway, have a look at the disk semaphore (green and red LEDs next to the card connector), and always wait for the green light before removing the SD-card.

Now the efforts for using standard media, file system and graphic formats start paying back. Gently insert the SD-card in your PC’s or laptop card reader. The icon of a removable SD-disk will be added to the system disk resources. You don’t need any additional software because  Windows XP supports browsing JPG images folders by default. Click on the SD-disk and browse to the folder you want to analyze. My advice is to set Windows Explorer’s view mode to “Sequence”, and enable the folder pane.  The screen will look like this:

The Witnesscam sorts the files hierarchically, grouping the folders by year, month, day and so on. They appear orderly on the left pane. Click on any folder to view its contents in the main pane. The main pane shows the current picture in full size. Clicking the buttons below it, you can zoom in, rotate, or skip to the next or previous frame.

The thumbnails of all of the frames in the folder are aligned at the bottom of the screen, like a film roll. The horizontal scrollbar shifts the thumbnails left or right, thus you can identify the image of interest at a glimpse. Clicking on a thumbnail you make it the current picture: Double-clicking it you can view the image full-screen by means of Windows Image Viewer, which allows you to print the image and make a slide-show of the images in the current folder. These functionalities embrace the needs of most users.

Alternative applications

I designed the Witness Camera for home use, but its low-cost and flexibility make it a great starting point for many alternative applications.

Wherever a switch closure can be associated to an event, there is an opportunity for practical use: just route the switch to the external trigger input and you are done.

It would be easy to incorporate the camera into automatic doors. Doors are ideal to take a picture of people entering a building, as one always enters face-front. Normal doors can be used as well, provided you add a reed switch for the trigger signal.

Another interesting product could be an automated barrier capable to register number plate and driver of each car entering a parking lot. Or maybe you just like to have a look at what people is ringing your bell when you’re not at home.

Perhaps the most natural alternative use of the Witnesscam is as in-vehicle camera (this photo with the lorry was taken on a test drive). The trigger facility can start recording automatically as the engine ignites - or a tilt switch detects an excessive bump. The SD-card can collect precious evidence and survive an accident – something you may want to tell to your insurance in order to get a rebate. Young drivers may hate it, but an electronic eye can help making them drive more responsibly.

Managers must prevent fraudulent use of corporate cars, and need a means to verify that a vehicle – and consequently employees – was where they were intended to be. Delivery trucks, patrol squads, and even taxi can profitably adopt a cheap recording system.

Other times a vehicle or a machinery can cause injury or damage a property. It is the case of bulldozers, cranes, road rollers, mining and engineering vehicles, excavators… After an accident, Witnesscam evidence helps discovering how and why an accident occurred, pinpointing responsibilities, and making clear how to prevent it from happening again.

A machine doesn’t need wheels or caterpillars to be (potentially) dangerous. Presses, benders, punchers, cutters, all have safety devices in place to ensure hands are in a safe place during operation. Workers sometimes irresponsibly remove the safety to operate faster or more easily.  Production managers should welcome machinery capable of recording the position of hands and safeties, right on the time blades are about to strike.

But let’s think positive. What about automating your Quality Assurance records? A machine can easily take a picture of every piece it produces for later reference.

In the same way, you can think of an intelligent packaging table, capable of documenting  the contents of every box about to ship from a company.

The Witness camera is also capable of time-lapse photography. This  introduces a totally different class of applications. I can’t forgive digital camera manufacturers for keeping this feature only for the most expensive cameras.

Learning applications range from elementary schools (building movies of  bean sprouts growing, sunflowers turning, or ice blocks melting) up to higher levels of education and research. 0.3 Mega Pixels may not seem much, but low-cost mean researchers can place as many cameras as needed. For example, agricultural research requires to compare growth of hundreds of plants over a period of several weeks.

Time for results.

Photo 6 shows the ceiling view of my living-room captured by the Witness Camera. Your mileage can vary, but you should be able to get about 50,000 frames at 320x200 (like the one below), or 25,000 at 640x480, using a 1 GB card (I haven’t tried bigger cards). This corresponds to more than 40 hours of overall recording.

Actual time span is much more than that. Likely, the best location for the camera is in the foyer, where people stand just a few minutes per day. In my case; just 20 minutes on average, giving an impressive 120 days of storage capacity.

The Witnesscam fulfils all my needs, but I know from experience that it would be presumptuous to consider it a finished product. Extensive testing, like verification against the most commonly available cards and PC readers, would be a huge task. Nonetheless, its potential should be easy to appreciate, even in this homemade incarnation.

The design is unquestionably useful. I hope you like also the design philosophy. The Witnesscam merges two mainstream technologies – flash memory and image sensors – to create something new and practical. The result is a very flexible concept: after you play some time with the prototype, it is really easy to find applications you haven’t thought before.

This design is definitely inexpensive. It takes advantage from mass-produced components to generate an extremely cost-effective solution. The price of the most expensive part, the SD-card, is dropping every day, thanks to the booming markets of music players and digital cameras. The same applies to the camera module, which comes from the mobile telephony market.

Compared to standard video surveillance equipment, the savings are striking, and more than balancing for the reduced frame rate or resolution.

I hope you enjoyed this entry as I enjoyed developing it. Admittedly, I have introduced some unorthodox circuits (like the audio driver or the straight-to-PC serial port), more for the fun of experimenting than for saving the cost of an extra transistor. Anyway, they worked well.

Other optimizations are more serious. Replacing the LCD with a voice interface is both cost-effective and optimal from a ease-of-use perspective. The choice of the Mega32 processor is a perfect fit. It handles easily its workload, and almost all its hardware features are used. Also the  sizes of FLASH and RAM are just right for the application.

While I’m writing these lines, I’m about to leave for summer vacation. It’s nice to know the Witnesscam will be watching my house. I’ve spent many sleepless nights designing and building my prototype: but now, I can sleep like a baby!






designs f.a.q.


crc guide who am I ? awards
home | nutchips | designs | f.a.q. | provokations | crc guide | who am I ? | awards