## Simple Composite Video output

18 posts / 0 new
Author
Message

My 16x2 LCD serial backpack (a great project - thanks microcarl!) is becoming just too small for debugging with, so I've made myself a serial->TV display device. It produces a Black and White PAL composite video signal. It works nicely, but not very brightly.

I used a project at serasidis as the foundation of the circuit. Two output pins ; one sync, one pixel data. The problem is that the 'white' is very 'grey':

I now believe that this circuit shouldn't have the 75ohm resistor in it. The 75ohms is implied at the other end of the cable (inside the TV):

Question 1:
Am I right? Is the second circuit "correct"? In a fit of recklessness, I removed the 75ohm resistor from my circuit and tried it. It produces a much whiter output and the TV hasn't blown up so far. Am I safe, or do I need to check the batteries in my fire alarm?

Question 2:
Are there any simple improvements to the above circuit? It meets my target of 'simplicity', but should I be 'balancing' the signal or anything like that? Do I need a 75ohm resistor in series with the output?

Nigel Batten
www.batsocks.co.uk

Just do the math. Composite video is a nominal 1.0V pp. 0.3V sync, 0.7V video. Your device is giving 5V pp. The three resistors form a voltage divider.

You're right; the 75ohm inside the TV is implied and present. Some professional monitors have switches at the back for disabling the terminating resistor. If you don't see it assume that the 75 ohm resistor is there.

If you think education is expensive, try ignorance.

*Strictly* what you should be doing is deriving a 2.0v p-p signal and outputting that through a series 75 ohm resistor from a low-impedance source - a voltage follower or similar.

In practice I do it exactly the same way you did, and tweak the resistors till it looks right. Terminate with the TV's input resistor - but be aware that older TVs may have a live chassis!. The analysis is not as straight-forward as you might think as there are return paths to ground through the resistor which is not being driven...

If you're driving into 75 ohms, using Rsync as 1000 and Rvid as 330 ohms, when vid = 0 and sync = 5v, you're driving into 75//1000 = 61 ohms and the result is 0.28v. When both are at 5v, you're driving 75 ohms from 1000//330 = 248 ohms; result is 1.16v

This version - if I got my sums right! - should have two volts p-p at the base of the transistor, offset by the diode voltage drop to offset the Vbe drop; it *should* give a low-impedance output protected by the 75 ohm in-line resistor into 75 ohms. It assumes a 5v input voltage. Transistor type might want looking at to make sure it has the frequency range; the 2222 was conveniently to hand.

Neil

## Attachment(s):

Damn, wrong numbers... RSYNC should be 600 and RVID 240.

So the sync comes from an oc timer out, and the vid comes from the mosi spi out? Then you need to feed the spi every 8 pixel times?

Imagecraft compiler user

bobgardner wrote:
So the sync comes from an oc timer out, and the vid comes from the mosi spi out? Then you need to feed the spi every 8 pixel times?

If you use the fast SPI code example but slow it down to half speed by adding a nop after each instruction (or 2/3 speed by adding one nop after each pair of instructions) then you can replace every 16th nop (or 8th nop) by a load instruction and keep going without hiccups. :D

If you think education is expensive, try ignorance.

Blimey. I knew there was a clever timing trick in there somewhere. I was wondering how to get the next byte loaded in one pixel time.

Imagecraft compiler user

The advantage of using hardware SPI to control the Pixel output is that whilst it's shoveling bits out, you can retrieve the next byte. That gives you loads of time.

The SPI is still not ideal though.
a) It's limited(!) to 1/2 clock speed
b) you can only load the next byte after 9 bit periods.

The SPI module insists on outputting a 9th idle bit. That idle bit is high and that means an unwanted white pixel in this case. If you attempt to load the next SPI byte before the end of that 9th bit, the new byte is ignored.

The real trick is to switch the MOSI pin to 'input' for the duration of that 9th pixel, removing the ugly white pixel.

If the SPI module is ever revisited by Atmel engineers, a 'no idle' option would be nice :) - I might be able to embed teletext information into my composite video signal then!

Nigel Batten
www.batsocks.co.uk

Agreed. And the chance to load a whole bunch of bytes into it at one hit would make live absolutely peachy - i.e. a hardware buffer with, say, 64 bytes of first-in-first-out... then you could blat a whole line's worth of data at your leisure.

But if we're going to redesign the AVR range, I'd prefer first that they integrate an FT232R into a uart, so it's plug'n'play as a serial link, no messing.

I never knew the hardware SPI had so many odd quirks in it. So it is definitely not ideal for video generation.

I've seen an AVR generating (black&white) composite video with a shift register like 74HC164 or the like. The AVR loads the shift register via 8-bit bus and load signal, and there is some kind of pixel clock used as the shift clock. Not sure if the load signal was also generated from the shift clock with a divider.

I guess it was like this because the hardware SPI was used as the control interface for the AVR, receiving info what data to display.

This lets the pixels be 8 bits wide, not 9, and it is possible to generate a pixel for every pixel clock instead of every other like with hardware SPI.

Quote:

This lets the pixels be 8 bits wide, not 9, and it is possible to generate a pixel for every pixel clock instead of every other like with hardware SPI.

You mean every system clock, I think. If you slow things down, then the pixel clock gets slowed down too.

If you think education is expensive, try ignorance.

That's right. The pixel clock can be the same as system clock.

You could also run the pixels and AVR at separate frequencies, as long as the wanted value is on the bus before loaded. Might be tough to syncronize things then.

But for PAL and NTSC, a single 13.5 MHz clock is enough, as that is the common rate for both. AVRs can't run at 27MHz, which is the usual pixel clock value to get color info there too.

Well, it can be the same as system clock - but you'd be *extremely* constrained in what you can do in the time. I think it takes ten cycles minimum to get a memory byte, index a character font table, and get the byte out somewhere.

Sorry to drag up an old thread...

For further testing of my TellyMate project (which uses the 2-diode, 2-resistor circuit above), I bought an old 5" portable 12v telly from a car-boot sale this morning (Â£2 - bargain!).

It didn't work with the TellyMate.

To cut a long story short, it will only work when there's a resistor to ground (as shown in the very first diagram in the thread).

• 75ohms to ground gives a nice picture with bright whites.
• 33k to ground gives a picture with muddy grey instead of whites.
• No resistor causes sync failure, but faint grey pixels can be seen tumbling and rolling.
From these findings, I'm assuming that I've bought a TV without an internal 75ohm resistor.
Other video devices don't have problems with this TV.

Questions:
a) Does my assumption make sense (i.e. this telly has no internal resistor)?
b) How common are these TVs (are all portable TVs like this?)
c) Should I be including an optional [via jumper] 75ohm resistor in my TellyMate kits and TellyMate Shields?
d) Should I really be using a transistor circuit as kindly provided by Neil instead?

Thanks in advance for any insights!

Nigel Batten
www.batsocks.co.uk

Your 5" TVset isn't a professional monitor. It's nice that it has a composite video input though. I created one on a 12" BW TV. Used is as a terminal for my 6502 micro system. Ages ago ...

a) Unpredictable ;) You cannot be sure, there are so many variations on that theme.
b) See a)
c) Yes, I'd do that
d) That would be the best way to output video, but IMO not an absolute necessaty.

One other thing to consider:
A professional monitor will use the voltagelevel right after Vertical Sync as black level. It's called Back Porch Clamping. But I have seen many monitors that use the voltage level of Vertical Sync as reference for "blacker than black". Called SyncTipClamping. Disadvantage of that method is that black AND white levels change with setting the gain (contrast) to an different level. After contrast adjustment, brightness need to be adjusted as well. And again ....
When the proper method is used, black stays black, and gain influences the white level only.

Nard

They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/

Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips

It would be hard to analyze what goes wrong if the picture does not show up.

We'd have to see the timings and voltages of the video signal to proceed. My guess is that there may be something wrong in the odd/even field switching or serration.