I have finished porting the code over to the new STM32F413 Nucleo board and now have a frame buffer big enough to cover the whole screen. You can see the output here.
Word from Analog Devices regarding the chroma transient issue I mentioned earlier, is that this is a result of conversion to a YCrCb 4:2:2 digital format by the decoder. This format compresses the video data significantly, but at the expense of chroma information. Chroma is sacrificed because the human eye is much more sensitive to luma detail than chroma, so the loss is barely noticeable with a scene from ordinary television. However with coloured text and graphics it does become noticeable. From what I have observed, the effect is most noticeable with primary colours (pure red, blue or green). White or black pixels are the least affected and intermediate colours (yellow, magenta), while still affected, look better than primary colours. This makes sense when you consider that white pixels are almost entirely luma in the data stream, while primary colours contain the greatest proportion of chroma information.
For the time being I will have to live with this limitation. I will try to mitigate it by outlining text with black pixels (as most OSDs already do) and making coloured output at least 4 pixels wide (which will be 2 pixels in my half-resolution overlay).
It would make sense to render the altimeter, airspeed and AHI in white, and reserve colour for warning messages and status icons so that is what I am doing now. Ultimately this will be the sort of thing users can set according to their own preferences.
The way to avoid the chroma issue altogether would be to stream data as an RGB 4:4:4 stream which has no compression, or YCrCb 4:4:4. The ADV7341 encoder I am using understands RGB 4:4:4 but the ADV7184 cannot generate it and does not have a wide enough pixel bus.
Colour looks great when there are 4 or more horizontally-adjacent pixels. But when there is an isolated single overlay pixel in a scanline (e.g. as part of a vertical line or the upright stems of text characters) then the colour is faint, as you can see in this image below.
Notice how much darker the vertical and diagonal lines are compared to the solid green horizontal lines. Also, although it’s not visible here, the green appears to “bleed” into the adjacent left and right pixels from the video feed.
This may be the result of signal processing in either the decoder, encoder, or my video monitor. Or it could be the result of the analog video encoding, which attempts to squeeze 3 signals (1 luminance and 2 chrominance) down one wire, with limited bandwidth. The ADV7184 datasheet states:
Due to the higher bandwidth, the signal transition of the luma component is usually much sharper than that of the chroma component. The color edge is not sharp and can be blurred, in the worst case, over several pixels.
The decoder has a Chroma Transient Improvement block, and the encoder has various Digital Noise Reduction filters. I will need to experiment with all of them. Next step will be to add a pushbutton handler which will progressively enable and disable the CTI and DNR settings so I can observe what difference if any they make.
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