Lowpass for Video Output?
Christoph_H
Posts: 31
Hi everyone,
a friend of mine could use a simple test pattern generator for troubleshooting CCTV installations and I volunteered to help him. The software is based on ericball's PAL_colorbars.spin (thanks by the way, if you're reading this). I've taken a look at the video signal of the first prototype on my oscilloscope and compared it to a few other devices in reach.
Because of the way the propeller is generating the video signal, the higher harmonics of the color sub carrier are quite large compared to the background noise. Those CCTV installations also incorporate RF links where cable runs aren't feasible and I'm worrying that the high frequency components of the video signal might cause trouble in these transmitters. So I'm thinking about adding a passive lowpass filter between the DAC and video output connector.
I've simulated a 5th-order Butterworth with a corner frequency of 8MHz in pspice and the results look good to me - the 3rd harmonic is already quite a few db attenuated and the group delay up to the colorburst frequency is not so bad.
What are your thoughts on this?
a friend of mine could use a simple test pattern generator for troubleshooting CCTV installations and I volunteered to help him. The software is based on ericball's PAL_colorbars.spin (thanks by the way, if you're reading this). I've taken a look at the video signal of the first prototype on my oscilloscope and compared it to a few other devices in reach.
Because of the way the propeller is generating the video signal, the higher harmonics of the color sub carrier are quite large compared to the background noise. Those CCTV installations also incorporate RF links where cable runs aren't feasible and I'm worrying that the high frequency components of the video signal might cause trouble in these transmitters. So I'm thinking about adding a passive lowpass filter between the DAC and video output connector.
I've simulated a 5th-order Butterworth with a corner frequency of 8MHz in pspice and the results look good to me - the 3rd harmonic is already quite a few db attenuated and the group delay up to the colorburst frequency is not so bad.
What are your thoughts on this?
Comments
A simpler approach might be to output the chroma separately and filter it with a crystal lattice filter at the colorburst frequency. The crystals required for this are very easy to get. Then recombine the chroma and luma/sync signals.
So try one of these options, see if it works, and report back here with your findings. This is something a lot of folks might benefit from.
-Phil
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Leon Heller
Amateur radio callsign: G1HSM
-Phil
The signal is not that fantastic (ie "Broadcast Quality") so a simple filter should be ok. I looked around, here at work, for an analog vector 'scope to have a look at my home made Demoboard's output but I cannot find one, they are all SDI. There is a "scrap yard" over in our other unit so I will go and see if I could scrounge one.
There was a cct diagram that gave a closer approximation to 75 Ohms a while back, it used a more complicated cct in component count, and non standard values, but should present itself to a filter more kindly.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
While my current prototype DAC uses the resistor values from the demoboard schematic, I had already planned to follow phil's suggestion for a better 75Ohm match from another thread. I haven't even thought about using the Y/C mode and recombining the signals later, so that's an interesting proposal. Although, as Toby mentioned, the crystal filter would probably have a too narrow passband. The filter I have in my mind will modify the output impedance (see attachments), so an highspeed opamp buffer would certainly be the right way to do this but if it's possible I'd like to avoid the opamp.
I don't think I'll encounter any problems with the phase of the signal; as I understand it it would be nice to have linear phase at the frequencies of interest and at least up to the color frequency the deviation is quite small.
This project is indeed not in any way meant to generate a broadcast quality signal (although the clock will be at 4.43... MHz to avoid PLL jitter) and I fully understand that it's not possible to get the SMPTE color bars because of the amplitude and hue restrictions. I'm just trying to filter the output signal so it's not too revolting to any connected device. [noparse];)[/noparse]
The attachments show the 5th order butterworth, component values were computed with www-users.cs.york.ac.uk/~fisher/lcfilter/ and rounded to the nearest value I can get for a reasonable price. The series resistance of the inductors is also modeled although this will not make much of a change. The second image should show the amplitude response and the third one the phase response (with a linear scale). The last one is the impedance as seen by the 75Ohm source if the filter is also terminated with 75Ohm.
I was intrigued by you saying that you were using the 4.43MHz clock to avoid jitters. I tried that a long time back and the video wouldn't run at all, the objects say that 80MHz is a minimum and so I just stopped playing. I was trying to improve the background colour beating that I was getting from my homebrew DemoBoard, at a nominal 5MHz PLLx16. Using a 6MHz rock seemed better and so I experimented with some 4.43 and a 8.86 ones but got nowhere. I have since found that the declaration of the Freq can be tweaked a bit and yeilds better pics. mostly it was 4_999_500 to get the best ie least patterning.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
By the way - at first I had a 5M crystal connected and hadn't thought that I'd better change the PLL factor after exchanging it for the 7.3.. one. I must have been running at over 117MHz and there were no signs of malfunctions. [noparse]:)[/noparse]
I have played with the frequency declaration a bit when I was using a prop for the first time, more than a year ago, but couldn't get the TV_Text_Demo to run without diagonal stripes.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Why did I think a new, more challenging, job was a good idea ??
You're right about the crystal lattice filter having too high a Q. I hadn't thought about that. The rapid phase shifts for hue would never make it through.
I've also seen cases where adjusting _xinfreq slightly can improve video quality. This has to be done on a case-by-case basis, though, to accommodate slightly different crystal frequencies. It may also be the case that crystal aging or changes in temperature could render such fine tweaking ineffective over the long run.
-Phil
The only thing needed for various clocks, is to compute the PLLA value. (PLLA/CLKFREQ) * (2^32) gets that done.
IMHO, the Parallax graphics object should work too. The minimum for that one is 64Mhz, I believe. The only tweak potentially required would be to lower the resolution on the TV cog. Don't know whether or not the default configuration shipped with the Prop tool was tested that low, but it could be adjusted.
Another one that works pretty low is the one pin TV Eric wrote. It can clock way down --and I think he actually got it working on as little as 20Mhz, maybe 12! I don't recall exactly. At that clock, it was good for a few characters per line. Something like 40 pixels of resolution.
The newer drivers I've been working on run at lower clocks too. Potatotext at 20 or maybe, maybe 32 characters per line will operate on less than 80Mhz. All that's needed is to do the PLLA calculation and edit the value for your particular board. Running color requires more, monochrome less clock.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Propeller Wiki: Share the coolness!
8x8 color 80 Column NTSC Text Object
Wondering how to set tile colors in the graphics_demo.spin?
Safety Tip: Life is as good as YOU think it is!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Composite NTSC sprite driver: Forum
NTSC & PAL driver templates: ObEx Forum
OnePinTVText driver: ObEx Forum