Is it possible to receive PAL video data from ADC of STM32 for example ?

I made a program which convert analog data to digital data (tested with analog accelerometer).

It is the same for PAL video data ? Or should I follow specific protocol ?

  • \$\begingroup\$ PAL has a bandwidth of 8MHz. Can the STM32 sample at 16 million samples per second? \$\endgroup\$ – JRE May 10 '16 at 8:56
  • \$\begingroup\$ 5.5MHz (System I Pal) rather than 8 MHz (which was the channel spacing) so you need to sample above 11 MHz. Still rather a lot for the internal ADC in a MCU... \$\endgroup\$ – Brian Drummond May 10 '16 at 9:06
  • \$\begingroup\$ Ok, I have to make a snapshot when I press a button, I just want to capture a picture each minute and send it to UART. \$\endgroup\$ – EEElectronic May 10 '16 at 9:11
  • \$\begingroup\$ According to STM32F4 datasheet, I can obtain 2,4 Msamp/sec. I saw some projects where it is possible to receive PAL signal using STM32F4 ADC \$\endgroup\$ – EEElectronic May 10 '16 at 9:18
  • 1
    \$\begingroup\$ My recommendation would be to consider using a camera module that gives you direct access to the RGB data from the camera rather than encoding into PAL/NTSC and then turning around and having to decode it again from the analogue domain. Stuff was put into the analogue domain for sending over a cable with minimal wires or for modulating an RF signal for over the air transmission. In today's world why do that? \$\endgroup\$ – Michael Karas May 10 '16 at 9:52

It is not practical to resolve an NTSC or PAL type analogue video data into a digital format using a typical microcontroller A/D converter. The equivalent pixel density of the analogue signal is 13.5 MHz and if you want to retain any type of ability to realize the color of the pixels you would be having to oversample the analogue signal at something on the order of 54 MHz.

What you need to look for is a type of chip called a video decoder. These contain all the processing circuitry to convert an analogue video signal into a stream of of digital data. A typical part will convert to a data stream of digital video that is represented by values 8 or 10 bits wide decoded in the digital realm in a format known as YCbCr component video. The data will come out of such chip at a rate of 13.5 MHz in parallel 8 or 10 bit values.

To make use of the digital data you would have to capture the real time data into a memory buffer and then send it on your communications link. A typical UART connection is not going to be particularly feasible unless you are satisfied with one frame of video being transferred over a long period of time relative to the actual video frame rate.

Note that there are encoder chips that can also produce RGB outputs but that may result in more data per pixel unless a low resolution 5 bits per pixel is used per color.

  • \$\begingroup\$ Thanks you very much for your answer First, I wanted to do this projet by 2 ways, the first with analog converter, and the 2nd with video decoder YcRcB 4:2:2 which gives me 8 bits data, For this projet, I think the camera gives information in back & white, so I don't really care about color, To answer your question why I do that today, because I have a project where I need to realize a screen capture from an analog camera (the same camera as video monitor in supermarket, or airport...) \$\endgroup\$ – EEElectronic May 10 '16 at 12:31
  • \$\begingroup\$ For UART connexion, it's not a problem because I'll configure DCMI interface to compress data to JPEG format (STM32 is equipped of JPEG compression function). So, I have to use DCMI interface & DMA interface ? But for the DMA, I don't want to send data to LCD, but to UART.. Is it a problem ? \$\endgroup\$ – EEElectronic May 10 '16 at 12:43
  • \$\begingroup\$ The compression function is probably not fast enough to operate on streaming video data (and needs a 2d input anyway), so you would have to have enough memory to buffer the input at your desired resolution including the oversampling, which will be a squeeze for monochrome on the largest F4. Really, you are choosing the wrong source or the wrong processor, unless you want to capture relatively low resolution (probably monochrome) stills and transmit them infrequently. \$\endgroup\$ – Chris Stratton May 10 '16 at 13:02
  • \$\begingroup\$ I don't really need to have the best resolution. I saw some project with DCMI interface between camera & LCD. In my case, I just want to make a Snapshot (not continuous mode), compress data with JPEG function in DCMI drivers (STM32F4xx dcmi.c). After that, I send data by UART or other bus that I didn't yet defined. I don't need to be fast, because Snapshot will be made every minute or every 5/10 sec. \$\endgroup\$ – EEElectronic May 10 '16 at 20:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.