Simple Composite Video output

18 posts / 0 new
Last post
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

*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): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Pages