Featured

What is Weka OSD?

Update: new Github repository cvbs3, a testbed project.

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.

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.

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 a working proof of concept which is capable of overlaying simple colour graphics and text. I will be releasing the schematics and source code soon.

Update: Schematics available now at Github.

Advertisements

The Switch is Early

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 immediately. 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.

SwitchOverlay_NoRC
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.

SwitchOverlay_47pF4KR
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:

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:

  1. Use a hex Schmitt trigger with up to 6 small RC networks, in series. One can be tunable with a variable cap.
  2. Simply use a clock delay IC such as the DS1110.
  3. Use one or more flip flops, clocked from the MC44144.

To which I added an idea of my own:

  1. 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.

 

Overlay, Take 2

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.

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.

Overlay

Well, sort of.

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?

Genlocked

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.

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.

Video on loss of sync

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.

New Boards Complete

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!

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.

 

New Board Designs

New design is a timing board, which extracts all the signals needed for genlock but does not generate any video. There will also be a fast video switch on a separate board using a MAX4313 which is both a buffer and a switch. Switching time is around 40ns, much slower than the TI switch I was planning to use. But this may still be OK and does not require a negative supply. I will still make the negative supply board though and if the MAX4313 is not suitable I can make another board with the TI switch.

This is a modular approach. I intend to try generating the CVBS from the uC, but if this does not work out I can make another board with an AD724 as originally planned.

Circuit schematics are complete, currently working on the routing.

Assuming 52uS of analog video, 320*240 resolution means each pixel lasts 162.5nS. This means the MAX4313 which takes 40nS to switch, will take around 1/4 of a pixel when switching.

Video timing board design is uploaded to Github:

https://github.com/Batperson/video_timing_board