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 almost immediately, before the overlay pixels are rendered. 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.

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.

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:

Switch signal, no delay and sharp edges

Switch signal, with RC delay

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.

Edit: André in Portugal has suggested another way: use a comparator to monitor the overlay video output. If it rises above black level, the comparator activates the switch. Thanks André! This would be a bit like the “blue screen” chroma keying used to show the weatherman in front of a computer-generated weather map back in the old days, except this would be luma keying. It would free up an extra bit (along with the other spare bit I’m not currently using) allowing for more colours. But it would mean sacrificing the ability to draw black in the overlay. Everything is a tradeoff…..