I’ve used the MisMatcher which has a similar circuit. It isn’t the same thing as a TBC but it has the same practical effect in terms of stabilizing a glitched signal for capture devices, projectors, etc.
2 Likes
Mismatcher is actually what I’ve been having trouble with… hmm, maybe there is something wrong with my build.
I’ve been glitching high definition component video using rotary potentiometers and am wondering if anyone has or will build something like this that restores sync for high definition video. I use a scaler that does an ok job of keeping my monitors from cutting out to a blue screen, but something like this for HD seems like what I might need. Is it possible to affordably build sync-ope for HD with YPbPr or Rgbhv inputs?
I’m working on a blanking/clipping circuit kind of similar to Sync-ope, using a digital sync/blanking generator, in order to choose SD/HD framerate, resolution and scan type with switches (might even implement a format auto-detection feature but still have to write and simulate the code).
Then Sync-ope can definitely be set for HD formats since the horizontal and vertical blanking timings are set using two monostables (74HC4538) and the timings are defined using trimmers/resistors/capacitors, following the formula T = 0.7RC. The values shown in the Sync-ope schematics covers NTSC/PAL, then since vertical sync is the same for SD and HD (50Hz/60Hz), the vertical blanking timings doesn’t need to be changed/can be achieved using the existing RC values. Then not sure for the horizontal blanking interval, may ask to lower the capacitor value to achieve a better precision when setting the timings with the trimmers, though might not be even needed. I’ll give it a go with my sync-ope and report.
4 Likes
Great to hear you’re working on that. What inputs will it have because sync-ope appears to just have composite and idk how to change that
It will only have a single RCA 75R input which can work with Composite/Component/RGB (and why not S-video with the right adapter). Cause Component and RGB only contains sync in Y and G signals respectively, so only this signal needs to be stabilized, Pb/Pr and R/B can be glitched without stabilizing them as long as the Y or G is in-spec. That was why I was saying that Sync-ope can be used for HD too, as you only need to stabilize the signal that contains sync.
Ok thank you so much for explaining that!
1 Like
i guess that in this use case the knob that mixes between clean and glitched signal on the sync_ope would only work for the channel that contains sync…
although a passive mix between the other channels should work fine since they are already in sync
2 Likes
Thanks and thanks for all your work!
1 Like
i just tested this same image on my sync_ope - and yupp its the same. i knew there was some shifting but didnt realise it was quite so dramatic
not 100% sure why thats happening… can take a deeper look into it at some stage // if anyone has suggestions happy to test em :))
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.
1 Like
thanks for your feedback @geepot - appreciate it and the time uv put into this project already 
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
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 !
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.
1 Like
@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.
1 Like
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)
1 Like
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…
4 Likes
Great to hear you found a fix for those issues!
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).
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.
4 Likes
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?