Slow vertical roll in overlay that changes based on video in brightness

[holtt]

I just built a board from scratch following the schematic and using an Arduino protoshield.

Much to my amazement, it actually works! I’ve got it hooked up to a little CCD camera for a FPV multicopter for input, and an old Hitachi B&W monitor for video output. I’m running the OverlayDemo, and it runs as one would expect. Almost

I get a slow (2 second) vertical roll in the overlay. But if I put my fingers in front of the camera and darken the input some, the roll stops. It seems to be related to the brightness of the video input signal.

Pointing the camera at a very bright light doesn’t speed up the overlay roll by the way. But darkening it does make it stop. It doesn’t have to be totally dark even. I’ve also tried both PAL and NTSC (with appropriate code updates), and that makes no difference in behavior. Plus I have played around with both potentiometers, and neither seems to have any noticeable affect at all.

I’ve uploaded a video of this, which you can view at https://flic.kr/p/FJqBNP

Any ideas?

[Michael]

I’ve never seen that problem before. It seems related to the vertical sync. This vsync pin on the LM1881 must be connected to D2.

[holtt]

The camera by the way is an EACHINE 1000TVL, which can put out either NTSC or PAL. I’ve hooked it up directly to my monitor, as well as to the video board, and there are no issues with the video from it that I can see.

I was reading the LM1881 datasheet and section 7.3.1 talks about the Composite Sync Output, which I am guessing the Arduino needs in order to time generating the overlay. The second paragraph of that section states…

Normally the signal source for the LM1881 is assumed to be clean and relatively noise-free, but some sources may have excessive video peaking, causing high-frequency video and chroma components to extend below the black level reference. Some video discs keep the chroma burst pulse present throughout the vertical blanking period so that the burst actually appears on the sync tips for three line periods instead of at black level. A clean composite sync signal can be generated from these sources by filtering the input signal. When the source impedance is low, typically 75 Ω , a 620- Ω resistor in series with the source and a 510-pF capacitor to ground will form a lowpass filter with a corner frequency of 500 kHz. This bandwidth is more than sufficient to pass the sync pulse portion of the waveform; however, any subcarrier content in the signal will be attenuated by almost 18 dB, effectively taking it below the comparator threshold. Filtering will also help if the source is contaminated with thermal noise. The output waveforms will become delayed from between 40 ns to as much as 200 ns due to this filter.

Reading this makes me wonder if the brightness causes “excessive video peaking” and leads to timing issues. I’m going to give the suggested modification of adding a resistor and capacitor and see if that doesn’t fix it. If you look on the datasheet at 7.2, it shows how this is done.

I’ll post tonight after I give this a try.

[Author]

Posts