Hi,
Just finished building Cadet Sync generator and RGB encoder and it looks like something went wrong.
I’m looking for some suggestions/hints on how to start debugging the modules.
The behavior is that the output is noisy and B&W.
Tried different things:
-
No input, Encoder connected to Sync generator → B&W screen, noise (dotted lines) on the left side with Encoder set to PAL, no noise with Encoder set to NTSC (strange because the monitor is PAL)
-
Cadet Processor as input, Encoder connected to Sync generator, Encoder = PAL → B&W screen, noise (diagonal saw-like lines)
-
Cadet Processor as input, Encoder connected to Sync generator, Encoder = NTSC → B&W screen, noise (diagonal more straightened lines)
-
Camera as input (via Cadet III), Encoder connected to Sync generator, Encoder = PAL → B&W screen, camera output is visible and more-or-less in sync, noise (diagonal saw-like lines)
-
Camera as input (via Cadet III), Encoder connected to Sync generator, Encoder = NTSC → B&W screen, camera output is visible and more-or-less in sync, noise (diagonal more straighten lines)
Pics of the PCB also attached:
Any suggestions on where to start fixing it?
Many thanks in advance!
I had similar issues when I built my Cadet system, it was three years ago so I don’t remember too much detail but I reflowed some joints and believe I sorted the issue. I also had a faulty LM6172 in on my encoder which I replaced but I don’t think it gave me this issue, just a dropped colour channel.
Worth going through and doing the normal debugging checks, component values, polarities etc. Also worth checking your sync connection too. For video input III make sure you’re looping your video through the sync generator otherwise it won’t be in sync.
2 Likes
Seems like the color subcarrier is out of spec. I see you have C17 populated, does it change if you remove it? It is listed as DNP in the BOM, so it should work without it. I had a similar issue on VU007B, mostly on the production/SMD version, some units would display black and white with similar noise as you have, the solution was adding a small capacitor (2.2pF) in parallel with the crystals (same spot as C17 on Cadet II). There might be some variation between AD724s and also the layout seems pretty critical, as a few pF can deviate the color subcarrier frequency enough that it cannot be picked up by the receiving device.
From AD724 datasheet:
A parallel resonant crystal, is the type required for the AD724 oscillator, will work at its operating frequency when it has a specified capacitance in parallel with its terminals.
For the AD724 evaluation board, it was found that approximately 10pF was required across either the PAL or NTSC crystal for proper tuning.
The parallel capacitance specified for these crystals is 17pF for the NTSC crystal and 20pF for the PAL crystal. The parasitic capacitance of the PC board, packaging and the internal circuitry of the AD724 appear to be contributing 7pF–10 pF in shunt with the crystal.
A direct measurement of this was not made, but the value is inferred from the measured results.
With the crystal selection circuit described above, the unselected crystal and diode provide additional shunt capacitance across the selected crystal. The evaluation board tested actually required no additional capacitance in order to run at the proper frequency for each video standard. However, depending on the layout, some circuits might require a small capacitor from FIN (Pin 3) to ground to operate with the chrominance at the proper frequency.
https://www.analog.com/media/en/technical-documentation/data-sheets/AD724.pdf
5 Likes
ohhh, thanks for the hints!
good question how I missed this C17…
I will try to remove it and see if it solves the problem
Bastien, you’re a genius!
That was the problem! Now everything works fine!
7 Likes
Good to hear you got colors now! The captures you sent looked oddly familiar with what I had experienced, the noise is actually the subcarrier being interpreted as luma since it’s outside of the tolerated frequency range of the AD724.
Out of curiosity, what was the value of the capacitor placed in C17?
When debugging VU007B units, I did try 10pF initially and it was too much, 4.7pF did work on a few units but not all, so in the end 2.2pF was the right value in my case, it’s crazy that a tiny change in capacity has such a drastic effect. Cadet II anticipated this with C17 and also a trimmer capacitor, C28, so it could be tuned precisely if there was too much frequency deviation, but looks like the layout was made right so both capacitors ended up in DNP (do not place).
Anyway, I could go on but I guess you got some intense video patching planned 
not even close to pico… it was a standard 0.1 uF (104) capacitor (don’t ask me how did I find this for C17 
…maybe I just worked in an autopilot mode … and of course missed the most important rule of builders - “don’t solder after midnight” 
)
…and yes, a long awaited patching has been started (the other 20+ modules /some of yours as well!/ just waited this moment to get and finish these brain modules…)
1 Like
I usually place 100nF after placing all other capacitor values, since 100nF is used all over the place for power decoupling, and I just place them in all remaining empty capacitors footprints, so I could have done the same mistake really easily
2 Likes
