FPGA NTSC signal with 2 resistors and PWM

Hi

I am evaluating the possibility to use 2 resitor video output from FPGA similar to:

formatting link

to generate color NTSC output, so far my results show less quality then the test picture in the link above I use 300/600 ohm with Xilinx Spartan3A starterkit

I am not yet sure if the difference in visible output is from the different receiver USB video grabber vs TV receiver, but the video as grabbed with cheap 25EUR grabber is very noisy, almost like the 80MHz would be pass the input filtering so that the 16 shaders are almost not recognizeable, also there is too much noisy flickering at the top the screen. I will be testing with real TV set later, so I can compare better.

so just asking if anyone has any compare results or suggestions for ultra low cost and simple direct video output with FPGA, there is one design with 9 resistors and 2 bipolar transistors, or then R-2R type networking, both are too complex, if a PWM based solution could work with some little neat tricks

Antti

Reply to
Antti
Loading thread data ...

A television will have a low-pass filter on the video and may look better. If you didn't add at least a capacitor (1 pole LPF) after your PWM, the digital grabber will no doubt show the effects of sampling the 80 MHz PWM signal.

Noise at the top of the screen may indicate some problem with sync levels. My guess is that a proper LPF might fix this, too.

Good luck, Gabor

Reply to
Gabor

ha, eh the PWM is clocked with 80MHz and for 16 grey levels the PWM frew is 5 MHz :( yes i already tried some cap for filter, it makes it a very little better only

for color signal i guess at least the R-2R thing is needed I will try without by using 500MHz clocked delta sigma, that should be much better then 80mhz clocked PWM but not sure if even that is useable for color.

Antti

Reply to
Antti

At better than 100:1, I'd expect the 500 MHz delta to give good results. The filtering will be less of an issue for the delta scheme.

Until or unless you have the nice modulator configured, would you consider using some TV analog filter chips to clean up the video? Your low-cost end solution might not use a part like the US$0.59 MAX9512 from maxim-ic.com, but it could make the initial development a little easier.

- John_H

Reply to
John_H

Hi John,

wau thanks for this link - I was considering that

formatting link

but I think feeding the maxim thing from FPGA would give better results

the 0.59 may still be in the budget, well the total self cost are below 12USD (hopefully havent got FPGA pricing yet) so it is more than just peanuts, but not so bad

Antti

Reply to
Antti

That's interesting. I think several of the Xilinx evaluation boards have VGA outputs with R-2R networks so you get a very limited set of colors. I'm not sure why you wouldn't just use a video DAC, though. Are they too expensive? They can be very small and low-resolution versions don't use too many inputs.

-Kevin

Reply to
Kevin Neilson

VGA is much simpler then color NTSC/PAL ;)

R-2R is an option of course, but i would rather use 2 resistors then the R-2R network

Antti

Reply to
Antti

Here is what my experiments with four resistors looked like (the camera wasn't a good one - the image was nicer live):

formatting link

-- Jecel

Reply to
Jecel

Hi

hm, i browsed your website and found interesting things :) and hints for more interesting thing without download links :(

hm by 4 resistor you mean 4 bit 2N DA stage or something else

on the test PCB I included 5 bit R-2R network, that could be little better then 4 resistors, but if delta sigma with high clock gives nice results I would go with it, or then 4 R version ;)

Antti ah, the results of the 2 resistor PWM greyscale also look better on TV set then on usb capture device. the 16 grey bars are all visible nicely.

Reply to
Antti

I have some random stuff at

formatting link
but unfortunately that doesn't include any HDL code yet. I will try to find the NTSC test next week (in VHDL) and make it available.

I considered the output to be a 75 ohm resistor to ground, so just had

4 resistors (N, 2*N, 4*N and 8*N) between the FPGA pins and the RCA connector. Video quality was not a requirement for this project (the video output was only used by me during development and not by the end customers) so I didn't bother adding capacitors to filter things a bit. The DA was calculated to go from 0 to 1.5V in 0.1V steps with the FPGA i/o programmed for 3.3V TTL levels. For black and white going to 1V would be enough, but for color you have to add a sine and need to go higher.

You would get twice the brightness levels and twice the sine amplitudes (saturations) for a total of four times as many colors. You would also reduce the noise level, which would improve the image considerably.

It is interesting to see what the delta sigma DAC can do, but it might introduce too much jitter for the color circuits to work properly. On the other hand, real TV circuits have limited bandwidth and might just ignore all the extra noise.

That is what normally happens. A digital video capture circuit is probably more picky about the signals it accepts.

One cute trick I came up with (but did not implement in the test circuit I mentioned) was using Xilinx 16 bit shift register slices to generate phase modulated sines for the chroma circuit. For each bit you cascade two of them, where the first is always 16 bits long and feeds back to itself (at reset it gets the correct pattern to repeat) and the second one varies from 1 to 16 bits of delay. You can do a four bit generator with only 8 slices.

-- Jecel

Reply to
Jecel

Cool! For color, you would want your main clock to be some multiple of the color subcarrier frequency. In the US (NTSC) that is 3.57954525 MHz, so a good frequency might be 128 times that, or 458.1819 MHz. You have to generate the color subcarrier, whose amplitude is proportional to color saturation, and whose phase (relative to the reference burst at the beginning of each line) gives the angle around the hue wheel. This is mixed with the luminance signal. A portion of the luminance bandwidth is chopped out and sent to the color decoder.

Jon

Reply to
Jon Elson

Found it and it is now at

formatting link

Most of the 218 lines are there to implement a test of the bar code reader shown as a scrolling display in the middle of the video output. You don't need any of that and just eliminating the lines where this is output (in the "dac

Reply to
Jecel

Thanks for the example.

-- Mike Treseler

__________________________ Note: abarras

Reply to
Mike Treseler

That is indeed wrong! I wonder if this used to be a warning back in

2003 (probably WebPack 3 or so) and I just ignored it.

Anyway, this is part of the stuff that is unrelated to the video test itself. I just had a 512 bit FIFO that was shifted 16 times per frame each frame (960 samples per second) so I could use part of the screen as a cheap osciloscope showing what the bar code reader (just a LED and photo diode) was seeing so I could debug that part of the circuit. It might come in handy if you connect a relatively slow signal to "leitor", like a RS232 input or something.

But it would be better to just clean this up and replace the sine ("seno" in Portuguese) part with shift16 circuits as I mentioned previously. The result would be really tiny. Missing lots and lots of stuff, like filters, that are needed for a high quality video, of course. But one of my computers is an Apple II, so you know I can live with sloppy NTSC ;-)

-- Jecel

Reply to
Jecel

(snip)

In the olden days (Apple II, IBM CGA) it was done with on/off switching at four times the subcarrier frequency. That gives you 16 combinations of phase and amplitude to choose from, which was good enough in those days.

If you allow for 128 times the subcarrier and allow for all on/off combinations (that is, allow 128 bits per subcarrier cycle) you should get a good number of hue/saturation/intensity combinations.

-- glen

Reply to
glen herrmannsfeldt

Antti, you'll only be able to generate a black and white signal with this technique.

For colour you need to generate a reference colour burst at the start of each frame, then output a sinusoid whose relative frequency to this reference burst indicated the colour.

This is superimposed on the luminance signal to provide a composite output.

With just the resistors all you'll get is levels of grey.

Nial.

Reply to
Nial Stewart

Nial dont be so sure ;)

you can get NTSC color with 4 resistors for sure, and if you use very high clocked (500MHz) delta-sigma DAC you may get color NTSC with one resistor too I think. not very high quality but more than 8 colors should be possible.

Antti

Reply to
Antti

Indeed, Woz's low-rez circuits were simply amazing. It wasn't obvious to me at first how he got different intensity levels. You have to notice that 1100 and 1000 have different DC levels...

It would be essentially a specialized delta-sigma DAC, but should be very interesting. You would have 128 hues, 64 saturations and 32 intensities (supposing 1 generates 1.5V and 0 is 0.5V, with the other resistor used to bring it to 0V for sync). You get less than 262,144 colors, however, since with 0 saturation the hue doesn't matter and with 0 intensity neither the hue nor the saturation matter.

Here is a page I recommend to anyone interested in this kind of thing, by the way:

formatting link

-- Jecel

Reply to
Jecel

Nial Stewart wrote: (snip)

You do need the burst, but you don't need sinusoids. Square waves (they will be filtered soon enough) work pretty close, too. If you clock is a multiple of the color subcarrier frequency those gray dots have components (consider an FFT) at the appropriate frequency and phase.

-- glen

Reply to
glen herrmannsfeldt

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.