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.
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.
360 * 288 frame buffer, instruments in white. Notice how much better the text looks.
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.
I have decided to stop developing against the STM32F407 and switch to the STM32F413, the main reason being that this part has much more on-chip SRAM- 320KB to be exact. This will be enough for a 360 * 288 double frame buffer, which will give the same resolution as the MAX7456 chip used in the MinimOSD board.
Although this is only half the resolution of an analog TV picture, it is adequate for graphics and text overlays.
I have purchased a Nucleo-F413zh board and ported the code over to it, it is working but I have not taken advantage of the extra ram to create a larger frame buffer yet. That will be the next objective.
Weka OSD 