Refining the DDS approach

This is another guest post by André, after revising and improving his (to my knowledge) completely new and untried DDS technique, he is achieving splendid results.

Hi Batperson and fellow DIY’ers.

I have focused on two major areas in my efforts to improve the colour osd prototype.

Fixing the chroma inconsistency

The first task was to deal with the perceived chroma inconsistency, which manifests as colour variations rolling vertically up or down. After much back and forth with some ideas and coding, I found that a partial answer was lying just in front of me. However the issue still needs to be tackled on more than one front to be fully resolved. I realized that there were two major contributors:

  • MCU comparator timing variations
  • DDS square wave output.

The trigger point of the comparator varies due to factors such as power supply noise or video signal voltage variations, and this inconsistency of the comparator is responsible for some colour variation. However the DSPIC on the prototype has a comparator filter, which when enabled gives a more consistent trigger point at the expense of a reduced sampling rate. After much fiddling with parameters I settled on a 1:5 prescaler, as the comparator is sampled at 400Mhz, the filter samples at 80Mhz, and it takes 3 consecutive positive samples to produce a change in the comparator output. So in reality the filter has a sampling output of 26.666Mhz (curiously, or not, this frequency is suspiciously close to the 27Mhz sampling rate of modern video decoders). Even after many sessions adjusting the filter sampling rate the issue never disappeared and I only obtained small improvements. However, that lead me to another solution, this time more accidental.

The first time I tried to connect the DDS output to the voltage created by the mcu pin, the DDS was outputting its frequency signal as a sine wave. Unfortunately it didn’t have any effect, and I was convinced that the DDS DAC output was too weak to make any change to the voltage already set by the port pin 330Ω resistor to the 75Ω input load voltage divider as seen in my previous post.

The DDS DAC only outputs a maximum of around 0.680V for sine or triangular waves, depending on frequency. Because of that I changed to square wave output which is a 0V – 3.3V signal and in my excitement at finally getting a colour overlay I never looked back at this fact.

As I could not fix the Chroma inconsistency issue, I reflected on the causes of the abrupt variations of color, and I thought for a while that the quadrature decoder inside the video receiver (monitor or video digitizer) would not like to receive square waves, but that idea was not convicing me, as I tried to improve the chroma detection and the DDS resetting routine.

One day out of tiredness and hopelessness, I reverted the DDS to triangle wave output, and the improvement was better than I imagined.

Improved colour bars
Super smooth colours!

Keep in mind two things: the video digitizer I used has a resolution of only 640×480 but the overall resolution looks even lower, and the DDS output is too weak to make a true 1V p-p sinewave so the digitizer’s automatic gain control boosts the signal making the image appear brighter. I will amplify the signal to proper levels later on.

This solution also made me modify the connection between the DDS output and the resistor divider output:

New DDS connection
New DDS connection

The 100pf capacitor is a simple AC coupling capacitor, nothing fancy.

Also there are signs of impedance mismatch as the overlay is switched on and off from the video signal, visible at the start of the overlay as a brightness change, and also at the end of the overlay as well if you look closely. As an interim solution I added a 75Ω  resistor connected via a diode to the pixel signal pin, so that when the overlay is switched  off the port pin that controls the switch is terminating the signal, when it is on the diode prevents the pin’s 3.3V from entering the video signal path and making all the overlay white, and potentially damaging the receiver input stage or camera output stage.

After I acquired a better video digitizer and changing the DDS to sine wave output the image became even better, IMHO.

Further improved colour bars

As previously mentioned, brightness and color saturation were increased in the PC software due to the weak DDS DAC output. I intend to address this later.

The artifacts at the numbers are caused by the way the digitizer deals with interlacing, these numbers vary at double the frame rate of NTSC (I just now realized this so I will correct it ASAP). Curiously the old digitizer dealt better with interlaced signals, maybe the crappy resolution masked this.

The vertical color rolling effect is barely perceptible now, and the quality o the overlay is vastly improved.

So I conclude that if you are trying to make a color OSD, you want to generate your overlay using sine or triangle wave signals, as the abrupt transitions of a square wave lead to colour inconsistencies. This happens because square waves are composed of various odd frequencies besides the fundamental frequency and this will certainly end up confusing the receiver converter.

Improving the firmware

The second area I wished to improve was the synchronization with the incoming video as I needed a stable overlay to continue the improvement of the OSD code without constant overlay dropouts.

This took up the vast majority of the coding efforts of the past weeks, and even if it is not fully fixed it has improved by leaps and bounds.

The problem would manifest itself as a complete disappearance of the overlay in case of sharp brightness variations from one scanline to another. One of the reasons of this issue is the attempt by me to let go of the “more silicon syndrome” by avoiding the use of popular sync stripper chips such as the famous LM1881. However replacing a venerable chip like the LM1881 proved to be a gargantuan task, as it is an old but still effective chip, with lots of modern descendants.

The prototype uses an internal MCU comparator to achieve many of the tasks of a sync stripper, adjusting an internal DAC connected to the comparator. From the comparator signal a routine was created to firstly increase the DAC voltage until the sync signals are detected, and then to adjust the DAC signal until it is just slightly below sync level (the voltage just below Black level)  and then hold this voltage.

The structure of interrupts of the code were as as seen in the next figure.

Old interrupt sequence
Old interrupt sequence

One disavantage of the “Comparator does all” approach, is that the composite video signal is a complex signal, having slow wave forms like the sync tip, and fast modulated signals, like the chroma and luma, and also variations of the image brightness will introduce variations on the sync level voltage, even with a clamping circuit. These variations are called APL, average picture level. This factor led me to introduce a “dynamic DAC voltage detection”. Simply put the MCU would use an ADC to read the sync tip voltage at interrupt 1.

The current DSPIC used in this prototype has a very useful ADC peripheral that besides being a 3.5Msps ADC, also has an oversampling or averaging filter.

Oversampling is not useful as the  ADC resolution is a generous 12 bits, and it coincides with the 12 bits of the comparator DAC. Instead the ADC filter was used at 8X averaging. In this mode, the ADC when requested will automatically take 8 measurements and average them before presenting the value in a register. Using that value, the program extrapolates the sync level voltage, and ideally keeps it from going over the sync level threshold.

The solution proved to be insufficient. If the next line had a big brightness change like the sun appearing at full brightness, especially at the right edge of the image, right before the next sync tip, the APL would change up and interrupt 2 would be lost, and because it missed the 4 chroma burst raising edges, the interrupt would never fire. Consequently the overlay would disappear because this interrupt decides whether the line is a scanline or vertical sync line.

An interrupt rearrangement needed to be devised to give sufficient time, meaning more cycles, to implement the DAC dynamic adjustment before the chroma burst, as seen in the next image.

New interrupt sequence
New interrupt sequence

For this, interrupt 1 was modified to wait for the ADC filter result, decide if the sync tip was a new Scanline or a Vertical sync line and raise the DAC voltage for the chroma detection. And interrupt 2 was changed from CCP reading 4 raising edges (it has to be under 8 ideally), to a DMA interrupt that takes 6 or 7 (still deciding on this) chroma rising edges from the same CCP, giving more time between these two interrupts. It then resets the DDS, and lowers the DAC voltage to the previous sync detection level to avoid any scanline glitches causing an interrupt to fire in error.

Even at 8X averaging the ADC voltage readings would oscillate plus or minus 2 lsb’s, so to improve that, and also deal with extraneous noise induced by the MCU or video signal, a median filter was applied afterwards in the line rendering interrupt (call it phase 3) to filter out noise outliers and implemented before the next sync detection.

A median filter has the advantage of filtering out large measuring spikes by sorting a list of past values and then taking the value at the middle of the list. The list size is currently 23 values.

The interrupt structure change decouples line detection from the chroma burst detection, meaning that in case the chroma burst is missing, such as with a black and white composite video image, the overlay will still be rendered, although with unsynchronized colours.

The results can be seen at these videos. The brightness of the video changes dramatically, but the MCU remains locked to the incoming video sync.

Note: these videos were made with different cameras, which shows another benefit of the dynamic DAC ajustment: better camera compatibility.

Next up will be a general code cleanup, increasing the amplitude of the DDS-generated chroma, implementing a luma DAC using resistors, and finally a long-promised full schematic. There are still issues with the overlay ocasionally disappearing, but this only occurs now under extreme conditions.

Thanks to my wife, family and friends, including the nice host of this blog, Batperson, for letting me publish my efforts and ramblings.

Milstan (André)

Updated Timing Board

Currently I’m waiting on parts, so there is not much for me to do project-wise at the moment. In the meantime I’ve fixed the errors on the video timing board. The MC44144 and LM1881 are separately AC-coupled to the CVBS input, and I’ve removed the clamp circuit. I also replaced the too-small 1.27mm pinheaders with normal-sized 0.254mm DuPont headers.



Well, sort of.

It’s a colour test pattern overlay, but there are a bunch of issues:

  • The colours are wrong. I had to change the order of the red, green and blue inputs to get even this result, because the phase delay from the MC44144 is 60 degrees. The colours are also poorly saturated, and look worse in real life than in the picture.
  • The image flickers, due to noise. This is most likely due to the use of a breadboard.
  • The source video appears washed out. I believe this may be partly the result of clamping which seems to compress the waveform by 200mV.

On the positive side, I did solve some problems:

  • I’m using an SN74LVC2G53 analog switch. This one is unbuffered. Since both the AD724 and the camera are both outputting at full-drive 2V p/p, there should be no need for buffering. The switch is very fast (<10ns) and seems to be performing as advertised.
  • Originally the 2 video signals were mismatched by around 200mV. This was enough to cause an unstable picture, as the overlay signal dropped below sync level. Worse, it even appeared to contaminate the source video in the LM1881, causing it to lose sync.

In order to continue with this approach, I will need to solve the subcarrier phase problem, and also find out why the colours look so terrible.

Another problem that has been bugging me is that the MC44144 often starts up without generating a subcarrier. It seems worse when using the USB power supply which is very noisy, although the filter on the board reduces it to < 5mV p/p. Both the chip and the crystal came from AliExpress, could it be a quality issue?

New Board Designs

New design is a timing board, which extracts all the signals needed for genlock but does not generate any video. There will also be a fast video switch on a separate board using a MAX4313 which is both a buffer and a switch. Switching time is around 40ns, much slower than the TI switch I was planning to use. But this may still be OK and does not require a negative supply. I will still make the negative supply board though and if the MAX4313 is not suitable I can make another board with the TI switch.

This is a modular approach. I intend to try generating the CVBS from the uC, but if this does not work out I can make another board with an AD724 as originally planned.

Circuit schematics are complete, currently working on the routing.

Assuming 52uS of analog video, 320*240 resolution means each pixel lasts 162.5nS. This means the MAX4313 which takes 40nS to switch, will take around 1/4 of a pixel when switching.

Video timing board design is uploaded to Github: