Sync-ope : sync restoring circuit - next revision ideas

[geepot]

Testing the board I just assembled based on the latest design on GitHub with NTSC. For some reason the chroma is getting significantly amplified to the point that my LCDs and V-8 can’t lock onto it, even with the mix potentiometer all the way to the left. I’m able to tame the signal with a TBC and get color back, but I was hoping to not have to use one with this circuit. This may also be related to the color shift.

Do you have any guidance as to any modifications I can make to counteract this?

Also, the trimpots don’t have enough range to properly calibrate the blanking with NTSC. I don’t think this causes the above issues because you can get it more or less close enough, but it’s noticeable on an oscilloscope. I’ll look at swapping the trimpots out for different values and see if I can get enough range to properly adjust it and share my findings.

[cyberboy666]

thanks for your feedback @geepot - appreciate it and the time uv put into this project already

@geepot

the trimpots don’t have enough range to properly calibrate the blanking with NTSC

this is something i discovered recently also - the problem is that there is quite a bit of variation in the actual value of C22 ( 1uF ) which depends on whether the ntsc range will work (which is why didnt pick up on it initially - since the few ones i tested were fine)

i tried it with about ~40 different 1uF caps of different types, and concluded that the following changes should be made for next revision:

• rv5 : 10k_trim → 20k_trim
• r22 : 22k → 12k

with the circuit i tested this gives enough range for all the cap types on ntsc and on pal

---

expect to see this subtle change to the BOM added to the git repo as v1_0_1 v shortly

[cyberboy666]

@geepot

For some reason the chroma is getting significantly amplified

just tested this on my version of the board and can confirm that the chroma does look to be over amplified on the output:

this could explain also the colour shift mentioned by @scragz also?

(where BLUE is the input signal and YELLOW is the output signal)

dont really know why the colour burst is looing so much higher than the rest of signal (any ideas @BastienL ?)

i suspect it could be due to some of the resistors setting the amplification here:

let me play around a little bit w simulation / on the circuit to see if we can improve this !

[geepot]

Also, just a heads up. The AD8072 has gone end-of-life on Mouser so it may be a good idea to look at replacing it with an easier to source part for the next revision.

Also, this TI whitepaper looks like it may have some good info on high speed opamps in video circuits and it might provide some insight as to what’s going on. https://www.ti.com/lit/an/sloa057a/sloa057a.pdf

I plan on reading through it tonight or this weekend.

[geepot]

@cyberboy666 I made the modifications to the board you suggested. I ended up putting another 22k resistor in parallel with R22 as I didn’t have a 12k resistor. Figured 11k is close enough with a trimpot. It’s better (actually may be too much adjustment range now, but haven’t tested PAL), however I am still not able to adjust RV3 enough to get it in-line with the rising edge of the vertical sync pulse. This is with Channel 1 (yellow) on Pin 3 of U7 and Channel 2 on Pin 10 of U6, 1ms timebase.

I also can’t get the horizontal sync to be as tight as shown on the GitHub, however, I actually get some effect coverage missing on the edges as I adjust the video faders if I make it too tight so this might not be a big deal. What you see here is about as tight as I was able to make it before things get weird. Channel 1 on Pin 1 of U7, Channel 2 on Pin 10 of U5, 10µs timebase.

EDIT: That horizontal blanking window looks suspiciously close to the front+back porch window in the final signal and I think that’s why I am seeing what I am. I go into this at the bottom.

What’s interesting to note is that the colorburst is actually higher on the input (yellow) than it is on the output (blue) for me. I was mistaken previously that the chroma was getting amplified as that seems to not be the case now that I’ve taken some more time to test and have the full picture. This actually makes sense with what I’m seeing because the colorburst is used to compensate for amplitude variations and it should match the chroma portion of the signal in amplitude. Since it’s lower in amplitude than the rest of the chroma signal, everything should be more saturated (higher signal strength in reference to the colorburst) which checks out. That would also be why the V-8 and the LCD is having difficulty locking onto it because the colorburst amplitude is too low.

I slept on this a bit and I am thinking it may have to do with that horizontal pulse adjustment. Since I can’t bring that rising edge close enough it might be intruding into the colorburst and suppressing it. I’ll see if I can change out the resistors and bring it any closer and if that results in the the output signal looking more similar to yours. In your case it should be desaturating the image as your colorburst is amplified. I need to check with the markers on my scope and see if it’s the same time window as how I have that adjusted to.

[BastienL]

@cyberboy666

dont really know why the colour burst is looing so much higher than the rest of signal (any ideas @BastienL ?)

Not sure what can be causing this, as the sync pulse seems to be amplified a bit, but not as much as the burst, so there might be some filtering going on, though I’ve simulated the send subcircuit and everything looks fine.

When it comes to the color shift, it is probably because of the filtering/delay induced by the components in the path of the video return. A full hue cycle in NTSC is a 360° phase shift of the color subcarrier, so that’s about 280ns of delay, then to go from Red to Magenta, it asks for a 60° phase shift, which is about 46ns. Usually, a hue compensation circuit is used to adjust the phase of the color burst so it matches the processed video, as unless the processing part ends up with exactly 360° phase shift, there will always be a little bit of delay. It would be even more useful to have a hue adjustment on circuits such as Sync-ope, because there can be anything in the send-return loop, and each device in the chain will have a different delay.

That’s something I’m looking to implement on my stabilization module, there is some simple transistor based phase shifters, like in this Vidicraft Proc Amp (which is NTSC):

http://soundexcellence.com/old_products/ProcAmp_5-Schematic.pdf (the Chroma Phase Preset and Chroma Phase on the right part of the schematic)

And seems like the circuit inspired people from Progetto Elektor for a PAL version, though there is no Chroma Phase Preset trimmer:

https://github.com/Syntonie/videomagazines/blob/main/Progetto%20Elektor%20(Italy)/ProgettoElektor_1987_07-08%20Color%20Processor.pdf (Tint potentiometer at the right of the schematic)

[cyberboy666]

@scragz

hooking the send to the return, is this amount of color shift expected?

decided to take another look into this hue-shift thing @scragz observed when patching VIDEO_SEND to VIDEO_RETURN on a sync_ope:

on my sync_ope i set the blanking so could see side by side the difference (inside square is returned video - edges is from original signal):

you can kinda make out there is a hue shift in this image, also appears to be a brightness shift on return signal

the hue shift is more obvious when the image is red:

fix 1 alone

i found out that to fix the hue shift you only need to replace r7 - 75ohm with a LINK ( 0ohm )

now when sending VIDEO_SEND to VIDEO_RETURN:

can see that there is still a brightness shift between original and return signal, but the hue shift appears to be gone

heres how it looks with red effect on:

fix 2 alone

i found out that to fix the level shift you only need to remove d4 - BAT46 (ie replace d4 with a DNP )

now when sending VIDEO_SEND to VIDEO_RETURN:

can see that there is still a hue shift between original and return signal, but the level shift appears to be gone.

how it looks with red effect on:

fix 1 & fix 2 combined

now with both r7 → LINK and d4 → DNP:

and with red effect on:

basically seamless between orginal and return…

explanations

unfortunately i dont have full context on what these parts were doing / why they caused this effect.

my understanding is that putting a 75ohm resistor in series on composite_video output (and a 75ohm to GND on composite video_input) is for impedance matching of the cables used… (not sure if this is even doing anything since the VIDEO_RETURN doesnt have the 75ohm to GND in this circuit?)

and that the d4 - bat46 to GND was part of protecting the VIDEO_RETURN from out of spec signals on return… since if signal is negative the diode will conduct and clamp the signal at GND…

so it is possible that these changes could have other effects however from my tests today the circuit works as expected after performing both these mods on a number of devices…

if anyone in this thread who knows more has any thoughts around this would love to hear it! (@BastienL maybe?) i will do some more tests, and consider making a revision to pcb to include these changes…

[BastienL]

Great to hear you found a fix for those issues!

@cyberboy666

my understanding is that putting a 75ohm resistor in series on composite_video output (and a 75ohm to GND on composite video_input) is for impedance matching of the cables used… (not sure if this is even doing anything since the VIDEO_RETURN doesnt have the 75ohm to GND in this circuit?)

About the 75ohm matched impedance in video standards, it is mostly here to avoid reflections caused by long cables, so a typical output stage will have an op-amp with x2 gain, with a 75ohm resistor in series with the output, and the input stage of the next device will have a 75ohm resistor to ground to match the impedance of the previous stage, and bring back the signal to it’s nominal level (as it will divide the signal by 2).

Here since the op-amp on the output stage has unity gain, the 75 ohm resistors are not needed, as it would halve the amplitude of the signal that comes back in the video return.
Else you could try adding a 1.5k resistor from (-) input of the op-amp to ground to make it 2x gain, then add the 75 ohm in series back, and add another 75R to ground. This should work better if you have a typical video device following the 75ohm standard in-between the send and return, cause the device will output a signal twice the nominal amplitude, that would need to be brought back to nominal level once it is connected to the video return input. Though it may causes more issues like the one you had.

What would be a bit better is probably to do what I just mentioned, and add an op-amp buffer between the video return input and the 100nF capacitor, as it would help with keeping the input impedance high, and the output impedance low. To go further, using an active clipping circuit would help with keeping the signal strictly between 0V/700mV (like the one in LZX Cadet RGB Encoder), though that’s two additional video rate op-amps (plus the one for the input buffer).

@cyberboy666

if anyone in this thread who knows more has any thoughts around this would love to hear it! (@BastienL maybe?) i will do some more tests, and consider making a revision to pcb to include these changes…

It’s hard to tell exactly, but impedance issues can cause filtering, filtering which also induces phase shift, so it could explain the hue shift you experienced. Any coaxial cable can be seen as a capacitor to ground, so along with the 75ohm series resistor, and without the 75 ohm to ground on the receiving end, it acts as a low pass filter, and without a buffer after the input stage, the capacitor + diodes adds up to the equation.

[proxy]

I know absolutely nothing about circuitry and my sync_ope can’t display a video signal without infinitely scrolling to the right. That is only with the glitch signal though and I know it isn’t my glitch setup because my crt doesn’t show that same scrolling image. Any fixes or anyone with the same issue?

[jmsiener]

I haven’t built my syncope yet but are you positive your calibration is good? How does it handle a not glitched out signal? Just thinking of some troubleshooting ideas.

[cyberboy666]

did you get your sync_ope through underscores.shop or build your self ?

a scrolling image sounds like the blanking calibration needs to be adjusted - have you tried doing this as it is described in the manual ?

[proxy]

I originally got one from the shop but it got broken and I had to send it back for a fix. The screen size is good I set it from pal to ntsc with a screwdriver if that’s what you meant, or is there anything else I can do?

[PAUL_TEMPLE]

hi hi, nice sleuthing. These mods are recommended then, for a general improvement of existing boards? thanks

[cyberboy666]

that is what i meant - even if the screen size looks good adjusting these pots a bit can help to stop scrolling since every display is slighty different in terms of blanking needed…

another option to try if you have it is to run the output from sync_ope through a tbc before sending to your display to see if that helps (also could try sending it to a crt since these are usually the most forgiving)

and finally if the glitched signal is too distorted to display you can always set the blend pot on sync_ope somewhere between wet/dry to find a spot where it is stable

[cyberboy666]

i did some more testing with this mod including sending out of spec signals on the return and couldnt find any reason not to perform these mods.

i dont think it matters too much comparing the signal sent directly from effect_send to effect_return since its not really intended to be used like this, but i will revise the pcb and have all future versions of sync_ope with this mod. so ya feel free to make these minor changes to your sync_ope also if you want to (and write to me if you want some help with it)

[PAUL_TEMPLE]

Thanks very much I will mod mine, it seems a good idea and straightforward enough. The only thing I found difficult was the location of R7 : )

I looked on the github but I could not find a layout/silkscreen of the component side.

D4 was easy to find. I expect they are close together though : )

[cyberboy666]

take a look here - you can search “r7” in the ref lookup

[PAUL_TEMPLE]

thanks : ) I still find github hard to navigate after years of browsing I enjoyed using that device when I soldered the kits too

[PAUL_TEMPLE]

modded : )

[fairplay]

…yeah - but: successfully?!..