Propeller Backpack video circut question

legoman132

Hello everyone,

I'm working on a video overlay circuit for an ROV controller I'm building. I saw that the propeller backpack can be used for video overlay, so I put the circuit onto my Protoboard. I built the video generator first so I could make it generate video, which I believe is a step in the right direction. However, on both my little NTSC lcd here and my parents big tv, the text from the demo (I think it was the one that said how the program or characters could fit into so much space of memory and than listed a bunch of characters, but i cant find it) was very fuzzy and drifted to the right and came back around. I have attached the circuit as built.

Thanks in advance

Post Edited (legoman132) : 8/4/2010 10:40:21 PM GMT

legoman132

Update: I found that the demo I had tried was the TV_text demo in the demo section of the propeller library The text drifts right to left and is completely unrecognizable.

Phil Pilgrim (PhiPi)

Your character display is driifting and smearing because it's not synchronized to the incoming video. Part of the Propeller Backpack's onboard circuitry is used to detect and lock on to the sync pulses from the incoming video. But TV_text is not equipped to handle an external sync; you have to use a display program (like the one provided on the Backpack product page) written for that purpose. If you're using your own circuitry, you may find it easier to incorporate an LM1881 to do your sync detection for you, rather than trying to duplicate the method used by the Backpack.

-Phil

legoman132

right now I'm not trying to overlay text yet, I'm just trying to generate video. When I get plain video generation working, I'll finish the Sync extraction and input switching circuitry and use the overlay object on the Backpack's web page

Phil Pilgrim (PhiPi)

I see. In that case, is your text actually drifting, or is it just smeared across the screen? In either case, you may have inadvertently put a low pass filter in your video stream. Do you have a scope you can use to look at your signal? How about posting a schematic of your actual setup?

-Phil

legoman132

Here's the scope readout at 20 mV/DIV and 10 uS/DIV and the current video generation schematic as built
The text is blurred AND drifting

wjsteele

I've not used that backpack yet, but your schematic doesn't look right for video generation to me. If I were using 3 pins, I'd have a 1.1k, a 560u and a 270u resistor on my 3bit DAC (which you approximate with your 430's arrangement.) The Cap and other two resistors are not necessary just to generate video, as far as I can tell. In fact, they actually might be the cause of it not working correctly.

Bill

legoman132

I'll try that when I get a chance, but I don't get why the circuit from the backpack wouldn't work (see attachment). How tolerant are the video generators of different resistor values?

Phil Pilgrim (PhiPi)

The Backpack circuit is correct. In fact, it's better than the usual video output circuit, since it presents a 75 ohm output impedance, rather than the customary 150 ohms. Judging from your scope trace, however, I would have to say that you did not use the component values in the schematic. Either the cap or the resistor values are too large -- I suspect the cap. It should read "331" on the package.

-Phil

wjsteele

Phil Pilgrim (PhiPi) wrote: »

The Backpack circuit is correct.

When I look at the backpack circuit and his circuit, there is a difference. He's not using the two additional pins that the backpack is using.

Are they doing anything special?

Bill

Phil Pilgrim (PhiPi)

In the Backpack circuit, A11 is just used for the overlay function, A15 for FM audio, A16 for audio input, and the cap connections (A17, A18) for switching lowpass filtering in and out. The 300pF cap isn't really necessary unless one is outputting DUTY-mode gray-level video. It's used to smooth the transitions, but it's not so large that it will mess up the chroma part of the signal.

-Phil

legoman132

@wjsteele:
Which two pins are you talking about?
@Phil Pilgrim:
The scope trace has a time scale WAY smaller than what would show the best info (2ms is more helpful).


Update: I took the cap out and it works perfectly:). I just want white text, nothing else, so I wont need gray-level filtering (for now...). Now I have to order the right mosfet from mouser and work on the sync extraction portion.

Thanks to all persons involved (including my dad)