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!
I clocked an SN74HC174 hex flip flop with the 4FSC clock signal, connected the flip flops in series with each other, and connected the pixel switch to the first input. Using the 5th flip flop output gives a delayed switch signal which is neither early nor late. So there is no more black band before or after the overlay.
Switch timing now coincides with the pixel output.
Although some haloing left and right of the white bands is still present, I don’t think this is caused by the switch. The image is quite noisy, you can see a noise artefact in the magenta band. Some of the connections on the breadboard are a bit loose and the circuit is quite finnicky. I have to fiddle with it for several minutes to produce an output.
I now have a working OSD prototype, which works for NTSC only. I still haven’t come up with a method that supports both NTSC and PAL. Also, the circuit is quite complex: 7 ICs and supporting passive components.
The current draw is 143mA at 5V, which includes the STM32 discovery board with its on-board debugger, a much more economical usage of power than my previous attempt which drew 550mA.
I noticed a few things. Although the last 2 white bands are 2 pixels and 1 pixel wide, the 2-pixel band looks about 3 times as wide as the 1-pixel band. Also, colours don’t really show up in less than 2 pixels. I tried rendering the white bands in various colours, and the 1-pixel band was still mostly white. This seems to be a limitation of the AD724, as previously when using digital video ASICs I was still able to render single pixels in colour.
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…..
Over the weekend, I tracked down the problem with poor saturation. This was due to an incorrect connection to ground in my clamp circuit. After doing this I had the opposite problem: the strong overlay signal was causing the monitor’s AGC to dim the rest of the picture. I compensated for this by increasing the series resistance after the AD724 from 75 ohms to 150 ohms. This didn’t alter the brightness of the overlay but the source video is now less dim.
I also used an RC circuit to shift the phase of the subcarrier clock, in an attempt to correct the colours. I experimented with different capacitor values and discovered that 1nF and above caused the clock to disappear completely. 20pF caused a barely perceptible shift in colour, but a 10K resistor with a 470pF capacitor gave correct red, green and blue colour bars. Subjectively they appear exactly as they should, however I will experiment further to see if there is any more scope for improvement. The colours now appear solid where before there was banding, I’m not sure why this has disappeared unless it was clock jitter that the RC network somehow mitigated.
Here is the result.
RGB overlay – no fake, and full sats
Overlay trace. Note the switching artefact.
I have to say it’s looking a lot better than last week. The only issue still remaining is a switch artefact. Notice that there is a black vertical line before the red bar appears. This shows on the scope as a small bright spot just above sync level. Since there is no artefact when switching from overlay back to source video, I suspect it is the switch responding more quickly than the AD724, switching in a blank image before the colour signal has been generated. If so, I should be able to mitigate it by introducing a delay to the switch.
In fact the real image looks worse. The colours look more saturated in the photo than they do in real life.
Sync tip, colour burst, active video, overlay. The horizontal trace looks thick due to noise.
My test setup.
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?
After resolving some DMA issues I now have a working testbed running on the STM32F413 mcu. It is using the signals from the timing board to drive an AD724. It is generating a good test pattern but connections are very finicky, since I have the AD724 on a breadboard. Noise is visible and jiggling the wires is sometimes necessary to get it to work. But it will do for the time being.
Rainbow test pattern, genlocked to incoming video
Scope trace. Horizontal sync is the short low pulse and the colourburst is the short sinewave following that.
In theory the output from this should be in phase with the video from my Runcam. To see if that is the case or not I need to have a working pixel switch. When I attempted to use the MAX4313 I didn’t see a picture, and when i checked the output with the scope I saw that the sync tips are being clipped off. It is attenuating the waveform when it drops below 0 volts. I will try clamping the sync tips to 1 volt to see whether it will pass the entire waveform through.
Made a design for an OSD board using a genlocked AD724. When I attempted this previously, one issue seemed to be mismatched DC levels for the input video and the OSD video. To get them matched, both signals will need to be clamped. Normally video signals that are AC coupled are clamped to 0V for black level, which means sync tips are -0.3V. So I need a circuit to do that.
Design Note DN327 from Linear Technology has a clamp circuit using a diode and a capacitor-resistor network. Not sure what DC level it actually clamps to, it is probably optimized for the amplifier in the circuit which would have sync tips at >= 0V.
Wondering if this actually matters? Assuming the next stage down from the OSD (the monitor, or the vtx) is going to be AC-coupled, the DC level is going to be stripped out anyway. As long as the black level of both signals is equal it is probably OK.
If I do clamp to a DC offset with no negative excursion, maybe I won’t need a negative supply for the amplifier and pixel switch either.
My plan for the time being is to experiment with clamp circuits before continuing with the OSD board design.
Now looking at making a new board, using the AD724 clocked in sync with the incoming video signal’s colourburst. This is looking like quite a challenge. The basic principle has been shown to work, but it requires a lot of ICs. Am considering using the AD8001 as the pixel switch as it has “excellent video characteristics” according to the datasheet, which also gives a reference circuit for exactly that. However it requires a dual +-5V supply and I am not sure what is the best way to provide this. More research needed. Could it be as simple as 2 +5V LDOs, with the positive rail of one and the negative rail of the other, becoming GND?
Am also wondering how much of the 550mA used by my existing design, is due to losses by the inefficient linear voltage regulators? If I changed them to switch-mode regulators, could I bring the power down to 300mA? And could I do this while keeping noise within acceptable limits? I will try to measure the actual current drawn by the video chips from the LDO regulators. To date I have only measured total current drawn from the 5V USB power supply which includes losses from the LDOs.
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.
Update: new approach by André using DDS, see below.
This will be a record of my attempts to develop a colour graphical OSD for radio-controlled aircraft. An OSD system is a device which overlays flight information onto the video feed used by the pilot of an RC aircraft, so that they are able to see their altitude, airspeed, GPS co-ordinates, remaining battery power or fuel, or direction back home.
There are a number of OSD systems available. Many of these are based on the Minim OSD board. This was originally designed by 3D Robotics but released as an open hardware project so there are many variations available and it is inexpensive. However it is entirely text based. The MAX7456 chip at the heart of it was intended to display black and white text over security camera feeds.
Minim OSD board
MinimOSD output using custom firmware (MWOSD)
There have been projects to create true graphical OSD systems, such as AlceOSD. It is relatively straightforward to superimpose a black and white or greyscale image over a video feed using a modern microprocessor, doing the same with a colour image is much more challenging. The only widely available OSD capable of doing this is the EagleTree Vector. It is a closed-source commercial product. Edit: MyFlyDream Crosshair autopilot, another closed-source product, also features a colour OSD.
AlceOSD – grayscale graphics
PlayUAV – black and white, with graphics. Camera feed is not shown here.
Eagletree Vector OSD – full colour, true graphics
MyFlyDream Crosshair – full colour, true graphics
I am aiming to create something of comparable performance, for the FPV community, which will be fully open that anybody can build on or customize. At present I have two working solutions, one using the ADV7184 and ADV7341 digital encoder and decoder connected back to back, and one using the AD724 locked to an external subcarrier (Yes, Analog Devices are the last best maker of the buggy whip that is analog video technology). Neither solution is entirely satisfactory to me; the first uses too much current and the second too many components. So the search goes on. Please keep reading below to follow my progress, and if you have any ideas feel free to share them!
Artificial horizon, airspeed and altitude indicators
Weka OSD 