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.

Connecting my video monitor to the clamp’s output results in a distorted signal (as shown on the scope) and nothing visible on the monitor. But without the monitor, the signal waveform looks normal.

With a 0.1uF capacitor, the black level and porches look “tilted”, with the left end at a slightly lower voltage than the right.

With a 4.7uF capacitor, the tilt is no longer visible. Same with a 220uF cap. But still no steady video on the monitor.

Putting a 75 ohm terminating resistor in the circuit as I would have in a real circuit, halves the amplitude of the video signal. I’m guessing 0.1uF / 75 ohms as the input stage to a 2* op amp as I plan to use would be OK.

Seems a CVBS waveform can pass through a capacitor OK, but not with enough power to drive a monitor. It needs buffering.

With the AD724, I measured 0mV at black level, -200mV at sync tip (using a Uzebox I have lying around). With the gameloader screen active, I got -100mV at sync tip and still 0V black. Noticed some movement up and down.

With my small PAL FPV camera, I measured around 180mV at black level, 50mV at sync tip.

With my Runcam action camera, I measured 20mv at sync tip, 180mv at black level.

In conclusion, everything I have, generates CVBS with a different DC offset. TV monitors do not care. They adapt to whatever the offset is. But if I am going to mix signals, they will both need to be clamped to a common DC offset. 0V sync tip should be fine. So I will try to make a clamp circuit using just a diode and capacitor.

Made up a clamp circuit on a breadboard using a BAT48 schottky diode and a 0.1uF ceramic cap. Observed that it did bring the sync tips to the same voltage for my 2 cameras, and that unclamped each camera’s signal had a different DC offset. However the sync tips were not at exactly 0 volts as expected but appeared to be 20-40mV below zero. This must be due to the diode voltage drop.

Now I am not sure what value capacitor to use in a real system. Many video circuits just use 0.1uF. But according to what I read, at least 220uF is needed to pass the full video bandwidth.

Using my multimeter, measured 436mA drawn before the LDOs, for the OSD circuit. Does not include MCU current.

Measured 260mA drawn after the LDOs on the 3.3V supply. Measured 70mA on the 1.8V supply. (All using the Amps scale, on the 10A unfused input).

If this is accurate, then I might be able to achieve around 360mA using a switching power supply with 80% efficiency (not including MCU current draw).

Before attempting new hardware I wanted to finish 2018 with a better, more performant font system and tidy up other loose ends in the code. These changes are now complete. I am now storing fonts as 2bpp bitmaps which allows me to store the outline along with the character data, giving much better performance when rendering in outline mode.

Normally outlining in black is necessary around all character data as well and most graphics, because they tend to disappear against a white or light background. An OSD must be easy to read against any kind of background – you don’t want to have to nose down in order to read the altimeter because it is unreadable against the sky. Now almost everything has a black outline to avoid this problem.

I also implemented a variometer and experimented with yellow-white text and graphics.

I now have a font editor which I will be uploading to Github soon. It is very far from production quality code, simply the bare minimum necessary for me to be able to edit fonts instead of hand-coding them in raw binary as I was doing previously.

Now that these tasks are out of the way I will focus on the new hardware design. I will start by using a genlocked ADV725.