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 would like WekaOSD have the capability to continue generating video if the signal from the camera is lost or a camera is not connected. For this, I will need to detect when
loss of sync occurs and have the MCU generate sync signals.
I have worked out a way I can do this. The sync input on the AD724 is driven by the CSYNC output of the LM1881. At the same time, CSYNC is connected to a pin on the MCU. During normal operation the MCU pin is configured as an input so the MCU can derive horizontal timing. If LOS occurs or there is no camera, the pin can be configured as an output. Since the LM1881 sync output appears to be open-drain, either the LM1881 or the MCU can pull the line low to generate a sync pulse. This means the MCU can easily generate its own sync signals with no risk of 2 pins driving the line at the same time.
I can detect LOS by monitoring the Burst Gate output from the LM1881 using a second MCU pin. When there is incoming video there will be a short pulse every 64 uS. If those pulses stop then there is no video, and the MCU can switch to generating sync pulses.
If I make the pixel switch pin open-drain with a pullup resistor, then when loss of sync occurs I can put the pin into input mode. This will have the effect of turning the pixel switch signal continuously on, regardless of the value for the current pixel.
It took a long time to get these boards made up and populated, and I ran into issues along the way due to some errors in the design. The first mistake was to use 1.27mm pinheader footprints instead of 2.54mm. This might have been great from a miniaturisation point of view but not for convenience of prototyping as I needed to make custom jumpers to connect the boards, and special adapters to work with the DuPont connectors that are normal for prototyping. More troublesome was the use of a single AC coupling capacitor on the video input. Each IC which receives the video signal needs its own AC coupling capacitor as they apply their own bias to the incoming signal and will interfere with each other. I had to perform surgery by scraping off the soldermask, cutting traces and soldering in extra caps before the LM1881 sync separator would extract meaningful sync signals.
Once I get some free time I will correct the design files, but for now please don’t anybody use them! They are fixed now.
Video Timing Board connected to my Runcam 2, running from a 5V switching power supply.
3.58MHz clock locked to colour subcarrier
NTSC sync signals
I have a PAL and NTSC version of the timing board. I intend to start with the NTSC version and use it to drive an AD724 video generator in sync with the colour subcarrier. I will then use another board (not shown) with a video switch controlled by the MCU to switch pixels.
Another possibility is to ditch the AD724 and generate composite video with discrete components, by applying a delay to the colour subcarrier. This is how the early home computers did it back in the 1980s. If time permits I will explore both options, but for now the aim is to get a proof of concept working. The next task on the agenda is to revisit the WekaOSD code and adapt it for the new hardware.