Here is the schematic for the colour overlay prototype I have been breadboarding. The next logical step would be to design a proper circuit board. However I’m not happy with it for a number of reasons:
Too many ICs, too complex
Not able to support both video standards at the same time (need to select either a PAL or NTSC crystal)
Doesn’t work reliably with PAL, in any case because the PAL colourburst changes phase on each line and it is a 50/50 chance that the AD724 will change phase in the opposite direction to the incoming signal
The MC44144 is an obsolete part
I want to explore other alternatives. I have a few ideas. However for the time being I’m taking a break from analog video. My son needs an alarm clock so I’m going to build him one!
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.
There is a delay of several hundred nanoseconds (I estimate 250-300, it is probably a multiple of the 4FSC period) between the RGB inputs and the output of the AD724. But the pixel switch activates almost immediately, before the overlay pixels are rendered. This is visible as a black bar to the left of the patterns below. The left pattern should be white-black stripes, and the right pattern should be white stripes only.
Notice the black bar to the left of the white bar. This is because the pixel switch is faster than the pixels.
I tried to eliminate this by putting an RC delay in front of the pixel switch. It does delay the switch, but the result is disappointing.
Delaying the switch with an RC network of 47pF and 4K. The delay is gone but there is a blue “halo” in its place, and the switch cannot toggle faster than the delay.
The worst problem is that the switch can’t toggle faster than the delay, which means overlays 1 or 2 pixels wide don’t even appear. I’m not sure what is causing the blue halo, it could be because the envelope for the switch signal is no longer a sharp square edge. Compare these 2 scope traces:
Switch signal, no delay and sharp edges
Switch signal, with RC delay
Note the sloping attack and decay. The last 2 peaks didn’t reach the threshold to activate the switch.
I need to find a way to delay the rise and fall of the switch signal equally, while preserving the sharp edges, even when the switch toggle time for 1 pixel (162ns) is less than the delay (250+ns).
The good folk at Stack Overflow have made some suggestions:
Use a hex Schmitt trigger with up to 6 small RC networks, in series. One can be tunable with a variable cap.
Use one or more flip flops, clocked from the MC44144.
To which I added an idea of my own:
Delay the signal in the microcontroller. This could be done by setting up a second DMA transfer to a different GPIO port. Of that, only enable 1 pin which will be the switch. Drive the DMA from a timer with the same period as the pixel clock, but started an arbitrary number of ticks later.
Of these, I like 2 and 3 for simplicity. 3 has the advantage that the switching will be in the same clock domain as the pixels. This may turn out to be important, otherwise the switching may still be in and out of sync with the overlay image.
My own idea would be a great one (if I do say so myself), if not for the fact that I will now have 2 DMA transfers contending with the CPU for the bus. From my reading, there are is an issue with the DMA2 controller on the STM32F4 series when concurrently accessing peripherals. So adding an extra stream willy nilly is something to be avoided. The finished product will need at least 1 other DMA transfer (to receive data from a UART), or most likely more if I end up integrating it with a flight controller.
I think I will try the flip-flop approach, and it will be an added incentive to clock the microcontroller from the pixel clock, if this is possible on a Discovery board. I will also experiment with 2 DMA transfers.
Edit: André in Portugal has suggested another way: use a comparator to monitor the overlay video output. If it rises above black level, the comparator activates the switch. Thanks André! This would be a bit like the “blue screen” chroma keying used to show the weatherman in front of a computer-generated weather map back in the old days, except this would be luma keying. It would free up an extra bit (along with the other spare bit I’m not currently using) allowing for more colours. But it would mean sacrificing the ability to draw black in the overlay. Everything is a tradeoff…..
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.
With altitude, airspeed and heading indicators as well as an RTH arrow and a better attitude indicator, it is starting to look like a proper HUD. I have made the indicators white-green to reduce the effects of limited chroma bandwidth, and the Armed warning is now black on yellow for the same reason.
Pitch ladders, heading, RTH arrow, it’s starting to look good. Pity the Armed warning is covered up, but that will be soon fixed. It’s time to get rid of the rainbow test pattern.
The attitude indicator needs a boresight, and text rendering needs some tidying up – you can see the imperfections if you look closely. Next item to implement will be a battery meter. It will use colour to show battery status, progressing from green to yellow, orange and red as the voltage drops. I will also try to implement a generic “indicator” which can be used to display any kind of parameter. It will have a text label and an optional colour swatch or icon, which can change in response to the parameter. It can be used to show things such as GPS satellite count, temperature, current and so on.
Some time in the future I would also like to have analog gauges as an alternative to HUD-style tapes. You will be able to have the traditional “6-pack” instruments if you want to.
After some discussion with airbanana at RC Groups I am going to make another attempt to generate the overlay by genlocking and pixel switching, instead of using digital decoder and encoder ASICs. If this works it should use less current (at the moment my dev board and MCU draw about 0.5A). There 2 are ways I could do this. One is the method I tried earlier, using an AD724 clocked in sync with the colour subcarrier. Another possibility is the approach used here. Rossum is generating the entire composite signal including the colourburst using the SPI port. To do that he needed to overclock the MCU to a multiple of the colourburst frequency. But the SPI port can be driven by an external clock. I can obtain a clock signal in sync with the colourburst using an MC44144 and a comparator as I did previously, and try using that to drive the SPI. It will be some time before I can try either approach as I will need to fabricate a new board. In the meantime I will continue working on the graphics.
Weka OSD 