piclist 2000\12\16\102428a >
Thread: Overlaying video
www.piclist.com/techref/ubicom/lib/io/index.htm?key=video
flavicon
face BY : Nikolai Golovchenko email (remove spam text)

part 1 4562 bytes content-type:text/plain; charset=us-ascii (decoded 7bit)

Okay, synchronizing to horizontal pulses video in software
works now. The trickiest part was to lock to sync pulses with
the free running internal oscillator. Even the smallest
errors (under 0.01 us per line) build up very quickly and
synchronization fails...

The program implements only horizontal sync locking, but
vertical sync pulses detection should be a bit easier since
they coincide with horizontal ones. Here is the details:

I used the built-in comparator and a DC level shifter to
separate sync pulses. Here is the circuit in ascii 'art'.

                    -------*----------> +5V
                    |      |  R2
                    |      |  4k
              VT1   |      --/\/\/--
              n-p-n C\|            |       _
                     B|----*-/\/\/-*   RB1| \
    R1       C2     E/|    |  R3   -------|- \   RB0
    1k       0.22u  |      |  30       RB2|   >----o
o--/\/\/--*--||-----*------|--------------|+ /  Composite
Video     |         |      |              |_/   sync out
In       --- C1     \ R5   --|>|---|
         --- 330p   / 2.2M   VD1   |     Comparator
          |         \              |
         === GND   ===            === GND

The resistors R2,R3 and diode VD1 set about a 60 mV
threshold above the sync pulses lower level (sync pulses are
negative going). Surprisingly, the comparator negative input
reference should have been taken *above* the transistor base
(as it is in the circuit). One would assume that BE voltage
drop is about 0.6V and the negative input of comparator is
already 0.6V above the sync 'floor'. But it is not so. The
capacitor C2 has almost no way to discharge and consequently
it is charged with very low current and the BE drop is about
0 V. Therefore, the sync floor potential is equal to the
voltage set by divider at the transistor base. When the
charging current rises, which happens when a new sync pulse
arrives, so does the difference between comparator inputs,
so the pulse at this moment is not missed.

The circuit takes 3 pins: 2 comparator inputs and 1
output. Comparator output could be checked by polling its
configuration register, but it takes 3 instructions to check
it this way:

waitHigh mov !RB, w     ;exchange comparator conwfiguration
                       ;with w (mode = $08)
       mov temp, w
       sb temp.0
        jmp waitHigh   ;6 cycles in loop

while it takes just 1 instruction to check the port pin

waitHigh sb RB.0
        jmp waitHigh   ;4 cycles in loop

So I chose to sacrifice the pin as it is better to sample
the comparator output a little faster (and smaller code size
too).

Locking to the HSync frequency is the most difficult part
here. As Simon Nield suggested I use two PLL modes:

    1) Crash PLL. It is used after chip reset and when too
    many sync pulses are missed. On each external pulse
    (longer than 2 us) SX resets RTCC and calculates error
    on the next pulse. Errors are summed up for 256 samples
    and the timer load value is corrected with the average
    error value. The timer load value is 16 bit, higher byte
    adds directly to RTCC and lower one to phase
    accumulator.

    This mode works until average error goes low enough.
    After that the SX enters the fine PLL mode.

    2) Fine PLL. This is the hardest part. In this mode,
    the RTCC load value is not corrected (that is the line
    is assumed to have a fixed length), only RTCC is
    corrected. The correction value is produced by a low
    pass filter, which averages the errors. This works like
    an integral term in a PI regulator. I found out that
    proportional term (subtracting current error from RTCC)
    doesn't help really, because the error signal is so noisy
    that subtracting it from RTCC results in passing the
    noise further.

It works pretty well for a wide range of video sources,
maybe just a bit worse than the TV circuit. Another possible
issue may be that a line can have slightly different length
for a different video source. That may result in a different
position of overlaid image on the screen, because the clock
is not adjusted, only its period is adjusted by PLL.

By the way, this was tested on SECAM, but I think NTSC and
PAL are very close to SECAM in the horizontal sync
parameters. In SECAM horisontal period is 64 us, sync pulse
is 4.7 us, and equalizing pulses are 2.35 us.

Next step is vertical sync...

Anyone knows of a cheap way to mix video with a signal from
SX?

Attached: hsync_pll.asm

Nikolai

part 2 8711 bytes content-type:application/octet-stream; name="hsync_pll.asm" (decode)

part 3 136 bytes
--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspam_OUTspamKILLspammitvma.mit.edu with SET PICList DIGEST in the body


<233890728.20001216142514@yahoo.com>

See also: www.piclist.com/techref/ubicom/lib/io/index.htm?key=video
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Overlaying video

month overview.

new search...