MMS from an analogue camera

READ THIS TO FIND OUT ABOUT: The steps involved in designing a module that can be added to an existing analogue camera system to send digital MMS.

The potential benefits of being able to receive a CCTV or surveillance camera image directly to a mobile phone are obvious but expensive in practise. Paolo Trere, Future Electronics, explains.

There are several home alarm and video-surveillance systems on the market, but only a few of them are able to send out a picture via the Multimedia Messaging Service (MMS), and these systems are very expensive and based on modern components and cameras. Most surveillance equipment, however, is based on old technology and analogue infrared cameras. To add the MMS functionality to these systems there are two options: re-build with newer technology digital cameras and new central processing units; or simply add a module to an existing system. This article explains a method of implementation for a module that could solve the problem, considering carefully the required specification to lower system complexity and cost.

 

 

Simplify the system

The limitations of the existing system should be considered in order to define the required performance of the new module to be added to it.

In a cell phone, for example, the resolution which is most appropriate for the small display could typically be very low at just 176 by 144 pixels. Also, analogue infrared cameras only supply black and white images, meaning that colour information would not be needed for the MMS.

Finally, once the image has been acquired from the system, a GSM module is required to send it. The details of this have been omitted from the article, because implementation can be achieved with a GSM module.

 

Module requirements

Three main actions are required to implement the module:

1. Acquire and convert the analogue video signal to digital.
2. Collect bit-map information and compress all in a JPEG file.
3. Send picture via MMS using a GSM module.

 

 

Component choice

For the first of these requirements a frame grabber (video decoder) is essential, possibly one that is able to scale the image to the correct resolution. The right component could be the SAA7114 from NXP. It is a highly-integrated circuit based on the principle of line-locked clock decoding and is able to decode the colour of PAL, SECAM and NTSC signals (see Table. 1) into ITU 601 compatible colour-component values.

PAL, SECAM and NTSC are the most common analogue outputs from cameras, while ITU 601 is the most suitable format in which those signals can be encoded to a digital format. ITU 601 includes methods of encoding 525-line, 60Hz and 625- line, 50Hz signals, both with 720 luminance samples and 360 chrominance samples per line. This means that it is able to cover all three analogue standards. The colourencoding system is known as YUV 4:2:2, that being the ratio of luminance data to blue chroma data and red chroma data samples, also referred to as Y:Cb:Cr. For a pair of pixels, the data are stored in the order Y1:Y2:Cb:Cr, with the chrominance samples co-sited with the first luminance sample.

Through an I²C port it is possible to configure the SAA7114 with all the required parameters, such as the type of input analogue standard, the encoding format output, contrast, brightness and saturation control. Extracting data from the SAA7114 is achieved through the Image Port. This is an 8-bit port synchronised with a clock and other control signals. The clock speed is a standard 27MHz for ITU 601, and every data stream is accompanied by horizontal and vertical Reference and Data-Valid flags.

Some microcontrollers have a dedicated port that is specifically built to be directly connected to those pins for video-stream acquisition, but in general they are highperformance microcontrollers for video-orientated applications, making them more expensive.

 

Collect and compress

For the JPEG compression stage a microcontroller is required that is general purpose and low cost, but also able to fulfil a number of requirements. It should be able to interface directly to the Image Port, possibly avoiding the use of complex logic (CPLD or FPGA). For example, GPIOs with an external DMA Request pin that are able to accept input at 7MHz could achieve this functionality.

The microcontroller should have an enough powerful DMA to transfer data at a high rate. This means a DMA able to be requested at a speed of almost 7MHz. This is not an impossible requirement for low-cost 32-bit CPUs (i.e. ARM7, MIPS), but it has to be checked carefully.

The microcontroller should also be able to run the JPEG library to perform image compression in an acceptable amount of time. It is not a question of Mega Instructions Per Second (MIPS) since in general a 60MHz CPU with 32-bit words could do the job. Instead, the internal architecture of the core, the low-end instructions and the way in which bits can be manipulated inside the data word make a bigger difference. An acceptable time for the compression depends on the specifications of the application. In general, to have a detailed sequence of pictures rather than a movie, it will be necessary to take pictures every 2 or 3 seconds, therefore compression would need to be performed in at least 2 or 3 seconds.

If possible the microcontroller should also have a GCC compiler for quick and straight-forward porting of the JPEG library directly from JPEG.org.

 

 

Coldfire from Freescale could be a suitable choice for all of these requirements, in particular the MCF5207 has enough calculation power and DMA speed (see Figure 2).

In general there is no fixed rule for calculating the amount of time a CPU can take to perform this compression. JPEG adapts the algorithm depending on the image, so the best way to predict performance is to try different images and measure a average value.

An alternative is to choose a multimedia processor explicitly dedicated to video acquisition such as NXP Semiconductors’ PNX1300. With this component it is possible to realise a video compressor for high-end qualities up to 25 or 30 frame/s in MPEG 1/2 format. This choice will be a compromise between cost and performance.

 

System connections for low-end solutions

One of the most critical design considerations is the connection between the video decoder and the microcontroller. If the Image Port Data (IPD[7:0]) signals can be connected to the microcontroller bus, as a normal peripheral device with its Chip Select, a DMA Request signal only needs to be attached to the DREQ0 pin using simple glue logic. This pin can not be connected to the output clock of the Image Port, because this would cause a 27MHz interruption of bus activity and not all of the data from the port is required.

Only luminance data is required for a black and white picture, and could be set to use the SAA7114’s 16-bit data output, but it is possible to ignore the HPD[7:0] port and connect only IPD[7:0] to the bus. The output image is then scaled to a resolution of 352 by 144 to acquire only half of the total amount of data. In this way the DMA request would be at an acceptable speed, and only necessary data is acquired.

 

 

To show this in detail, consider the output on the Image Port with the video decoder output set to 16 bit (see Figure 3). The advantage of this configuration is that 4 bytes are obtained for every IDQ high value (data valid) period signal, and only one of those 4 is needed.

Apart from the 4 data blocks marked with SAV (synchronisation byte) this can be considered to be the start of a video stream with the 4 bytes inside an IDQ high period carrying 2 luminance values, referring to two adjacent pixels and 2 chrominance values. If horizontal resolution is set to 2 times the the required value, it is only necessary to sample one Y value for every data-valid period. Therefore, a logic combination of IDQ and ICLK has to be used for the sampling signal to be connected to DREQ0 (see Figure 4).

 

 

Software for low-end solutions

Once the uncompressed bit-map has been acquired, this data needs to be converted into a JPEG file format before sending via MMS or other medium. To perform JPEG compression, the JPEG standard library provided by the Independent JPEG Group can be obtained from www.ijg.org. Various parameters allow the choice of specific architectures including m68k and ColdFire® and compilers such as GCC and Codewarrior. Trying to use a CPU not listed in the GCC specific type, would involve having to configure the library manually, which could be very hard work.

Once a generic GCC compiler has been obtained, the library can be included, allowing compression in application code using the following these steps:

• Allocate and initialise a JPEG compression object
• Specify the destination for the compressed data (e.g. a file)
• Set parameters for compression, including image size and colourspace
• jpeg_start_compress(...);
• while (scan lines remain to be written)
• jpeg_write_scanlines(...);
• jpeg_finish_compress(...);
• Release the JPEG compression object

Depending on the software architecture used, it may be possible to have an OS running on the processor or a File System (FS). The most important consideration is where and in which format to store the results of the compression. One suggestion is to reserve a buffer in RAM, independent of any FS, and store or send data afterwards. For example, a typical LCD of a mobile phone might show images of 176 by 144 resolution. In black and white (i.e. typical video surveillance in darkness with infrared illumination) that would result in a bit-map of around 200kBytes. Because of the line-by-line way in which the JPEG library implements compression, it is not necessary to reserve the entire 200kbytes, instead a few lines should be sufficient, roughly 5kbytes. Furthermore the total size of the compressed picture should not be more than 8kbytes. So, it is only necessary to reserve 20kbytes of RAM as buffered data for compression. Using a MCF5207 or a microcontroller that needs external memory, this amount does not present a problem.

For all configurations and applications, it is worth consulting libjpeg.doc, contained in the JPEG library package from www.ijg.org. This describes how to act on the data destination module. This is the part of the library that manages all outgoing data, defining buffer sizes and addresses for compressed data. That is the only part of the library that might need to be modified to meet the needs of a specific configuration.

 

 

High-end solution

If small movie MPEG files are required, for example to record the scene following an alarm, higher-budget applications can attach the SAA7114 directly to a PNX1300 video input port. The PNX1300 processor is the smallest of the Nexperia family from NXP and is ideal for multimedia applications that deal with high-quality video and audio. It has a powerful DMA-driven coprocessor that can easily implement popular multimedia standards such as MPEG-1 and MPEG-2 (see Figure 5).

 

GSM modules

No particular GSM module is suggested, because it is a very standard product, with a UART port to be connected to the microprocessor.

 

Conclusion

These guidelines and suggestions show that to achieve MMS functionality from camera systems, there is an alternative to designing new powerful video-surveillance equipment. A module can be inserted into legacy analogue camera systems, and by taking careful consideration of system requirements, this can be done with minimal component cost.