DIYRE G Bus 202c VCA Weird Noise. Please Help.

[Clbraddock]

Grounding R92 helps but does not fully cure things. I guess I tried that earlier and shouldn’t have expected that different of a result.

What do ic1.3 and ic1.4 (and surrounding components) do in the circuit? Looking at Gssl and at original ssl schematics, on both the signal goes directly from what would be R90 on the g bus to what would be R35 on the g bus with no ICs in between.

http://www.gyraf.dk/gy_pd/ssl/ssl_sch.gif
https://www.gyraf.dk/gy_pd/ssl/ssl_82e27.gif
On the Gssl there is 202 vca emulation circuit (not used when using an actual 202 vca) that has a ne5534 going into the 2181 vca. Is Ic1.3 and ic1.4 doing the same role as that ne5534? From reading Gssl threads my understanding is that the 202 emulation circuit is supposed to be omitted when using an actual 202 vca. Wonder if that is contributing to the issues?

I could cut a trace match the ssl/Gssl but am pretty reluctant to do that.

I’ll try reverting it back to stock and see if it works correctly that way before doing anything drastic like cutting traces though. Edit: Actually, I think I could take R14/R15 out of the pcb and use a jumper from there to the respective R35s to bypass ic1.3 and ic1.4 without cutting anything.

 

[Meathands]

What do ic1.3 and ic1.4 (and surrounding components) do in the circuit? Looking at Gssl and at original ssl schematics, on both the signal goes directly from what would be R90 on the g bus to what would be R35 on the g bus with no ICs in between.

On the Gssl there is 202 vca emulation circuit (not used when using an actual 202 vca) that has a ne5534 going into the 2181 vca. Is Ic1.3 and ic1.4 doing the same role as that ne5534? From reading Gssl threads my understanding is that the 202 emulation circuit is supposed to be omitted when using an actual 202 vca. Wonder if that is contributing to the issues?

I could cut a trace match the ssl/Gssl but am pretty reluctant to do that.

I’ll try reverting it back to stock and see if it works correctly that way before doing anything drastic like cutting traces though. Edit: Actually, I think I could take R14/R15 out of the pcb and use a jumper from there to the respective R35s to bypass ic1.3 and ic1.4 without cutting anything.

IC1.3 and 1.4 are buffers to keep the source impedance to the audio VCA's control ports as low as possible. Via the 2181 datasheet, "The 2181 Series VCAs are designed to be operated with zero source impedance at pins 2 and 3, and a high (≥50 kΩ) source impedance at pin 4. To realize all the performance designed into a 2181, keep the source impedance of the control voltage driver well under 50 Ω." The resistor/capacitor pairs after IC1.3 and IC1.4 is a stability measure recommended by THAT, "Excessive inductance in the control port source impedance can cause the VCA to oscillate internally. In such cases, a 100 Ω resistor in series with a 1.5 nF capacitor from the control port to ground will usually suffice to prevent the instability."

Yes, the NE5532 feeding pin 3 of the 2181 in the GSSL is fulfilling the same role as IC1.3, IC1.4. However, even though IC1.3 and IC1.4 are still in the circuit after the vintage 202 resistor mods (G Bus vintage VCAs - DIYRE Support Center), the emulator circuit is essentially bypassed. Changing R16/R17 disables the attenuation of the control signal, and the control port of the 202 is fed through R35, 1k. The only difference is that the signal is buffered between R90 and R35.

You're right to note these differences, but nothing jumps out to me here as a potential source of distortion. I think returning it to stock to check the behavior is the next best step still.

 

[Voyager10]

Right - the mods change quite a lot in the areas of interest, so makes it hard to compare against a stock unit reliably.

As an aside: I've just noticed R89 - a 470K resistor in IC1.1's feedback path. Also present in the Gyraf schematic, but with a 10p cap in parallel. Seems to me this leaves the -ve input driven from a high impedance, and open to picking up noise.

Returning to stock configuration definitely the best next step IMO.

 

[Clbraddock]

Ok, swapped everything back to stock. Going to finish cleaning the board again tonight and then let it dry 100% overnight. Will reassemble the rest of the way tomorrow and should be able to test tomorrow night.

 

[Clbraddock]

After converting to stock, no difference. Harmonic distortion behavior remains more or less identical.

 

[Meathands]

Ok great! Thank you for reverting the mod so we can confirm that. Could you please run this test in REW so I can try to recreate your issue exactly?

1. Send a 1Khz, +4dBu sine wave to the L input.
2. Set THRESHOLD completely CCW, ATT/REL CCW as well, RATIO 10:1, all mods out, FILTER off. COMPRESSION out.
3. Monitor the L output in the RTA window, with "Show Distortion" on so that it shows the THD %.

Please send a screen capture of the RTA window that shows the graph as well as the THD percentages. I am out of the office Mon-Wed but will try to recreate on Thursday.

 

[Dreams]

So the sidechain "leaks" into the audio. As soon as the rectifier in the sidechain starts working, artifacts make it through to the audio CV and generate distortions. I think the main problem is how the bypass was implemented. Looks like it was taken from the GSSL, none of the other SSL style bus comps I've looked at so far used that particular scheme. SSL originally used a fet muting on the input to the sidechain, and no voltage made it to the rectifier. You can test this by measuring voltage at the SC test point. As soon as you get a voltage there, harmonics start to show up on the output. You can disable the sidechain as SSL does and they'll go away. Ground the node at C30, R47, and R49, or the inverting input on IC 5.1. Not sure which one is better, or how best to implement that bug fix, but that's what i got so far

 

[Script]

Thanks for investigation and follow-up report.

I'd think the best way to fix or rather 'circumvent' the problem is to drop the soft bypass altogether (go hardwired for IN) and add a hard bypass to the unit.

 

[Clbraddock]

Well, at least that means I can stop pulling my hair out trying to figure out what I did wrong lol I think I double checked the placement of every component a half dozen times.

Really appreciate your work figuring it out Dreams (and appreciate everyone else helping in this thread too).

Does the leakage you identified affect the signal with compression IN also, or is it exclusively a problem with compression OUT?

Now, the question is what to do for the fix. I am definitely not smart enough to figure that out, so I will let the smarter people figure out what the best option is and go with that. I'm not opposed to a hard bypass if thats the best option, but Im not sure the best way to implement it with all the relays.

 

[Voyager10]

The million-dollar question is whether your unit and @Meathands' stock unit behave (obviously) differently under the same conditions. If so, there's a good chance that (collectively) we can track down something which needs "fixing", and that's really the best option.

If it's looking like a common issue, it's up to you how much you're bothered about it and what level of hacking you'd be prepared to undertake to fix it. (Somehow disabling the sidechain signal at an earlier point in the chain would be the basic idea).

 

[Clbraddock]

The million-dollar question is whether your unit and @Meathands' stock unit behave (obviously) differently under the same conditions. If so, there's a good chance that (collectively) we can track down something which needs "fixing", and that's really the best option.

If it's looking like a common issue, it's up to you how much you're bothered about it and what level of hacking you'd be prepared to undertake to fix it. (Somehow disabling the sidechain signal at an earlier point in the chain would be the basic idea).

Makes sense. Im still going to do the REW test Meathands requested. Just havent had a chance yet, and it sounds like he wouldn't be able to look at it until Thursday. I will get it uploaded though.

 

[Script]

Does the leakage you identified affect the signal with compression IN also, or is it exclusively a problem with compression OUT?

Good question. Also would like to know. If so, might need fixing -- or being called a 'feature'.

 

[Voyager10]

So the main symptom of the leakage is high THD at the output, made clear with a spectrum analyser. The original post suggested this wasn't a problem with the compressor IN.

The sidechain itself will behave differently with the compressor IN or OUT, because the control signal is fed back to VCA2 in the sidechain when it's IN, reducing its gain. So I'd expect to see the 'SC' test point having a much higher signal level when OUT than when it's IN. In other words, the leakage may still be happening, but to a lesser degree.

Given that "grounding R92 helps but does not fully cure things." it's always possible there are two leakage paths, one via R92 and the relay contacts, and another yet to be determined.

 

[Script]

100n also on THR wiper to ground... maybe. All the above somehow reminds me of a problem that more recent DBX units have.

 

[Clbraddock]

Ok great! Thank you for reverting the mod so we can confirm that. Could you please run this test in REW so I can try to recreate your issue exactly?

1. Send a 1Khz, +4dBu sine wave to the L input.
2. Set THRESHOLD completely CCW, ATT/REL CCW as well, RATIO 10:1, all mods out, FILTER off. COMPRESSION out.
3. Monitor the L output in the RTA window, with "Show Distortion" on so that it shows the THD %.

Please send a screen capture of the RTA window that shows the graph as well as the THD percentages. I am out of the office Mon-Wed but will try to recreate on Thursday.

 

[Meathands]

Thanks. Here's mine, which is a bit lower than yours but still confirms that there is harmonic distortion from the SC being induced into the audio path when COMPRESSOR is out. (When COMPRESSOR is out and THRESHOLD is fully CW THD is 0.006%.)



So, first off thank you for your patience and tenacity in helping identify this bug! We'll revise the way we do bypass with the next run of PCBs.

In the meantime, I can think of a few options for how to proceed. It all depends on what you want to do.

1. Leave it as-is. I forget if you measured the THD increase with the 202 VCAs, or found it to be audible. But even if it is, what we are testing here is the most extreme compression setting possible, which I imagine you won't be using that often. If I reduce the THRESHOLD or RATIO in this state (COMPRESSOR out), THD quickly drops back near the baseline of 0.006%.

2. Perform the true bypass mod (G Bus true bypass - DIYRE Support Center) where you turn the XFMR switch into a true bypass switch. This comes with the tradeoff that you lose access to one of the output styles, either IC or XFMR. But you would then have true bypass accessible via the front panel.

3. Implement the new bypass scheme that we figure out. We'll have this worked out pretty soon, at which point I can drop instructions here for how to do it to the v1.0 PCB that you have. It will almost certainly involve cutting some traces and running wires.

So, up to you which way you want to go! Personally, I would go with option 1 and just make sure that THRESHOLD and RATIO are not at maximum if I am tracking through the G Bus in bypass. But, I don't know your workflow, so I can't make that determination for you.

Thanks again for your help with this @Clbraddock! I will post the new bypass scheme details soon.

 

[Clbraddock]

Thanks. Here's mine, which is a bit lower than yours but still confirms that there is harmonic distortion from the SC being induced into the audio path when COMPRESSOR is out. (When COMPRESSOR is out and THRESHOLD is fully CW THD is 0.006%.)

View attachment 114783

So, first off thank you for your patience and tenacity in helping identify this bug! We'll revise the way we do bypass with the next run of PCBs.

In the meantime, I can think of a few options for how to proceed. It all depends on what you want to do.

1. Leave it as-is. I forget if you measured the THD increase with the 202 VCAs, or found it to be audible. But even if it is, what we are testing here is the most extreme compression setting possible, which I imagine you won't be using that often. If I reduce the THRESHOLD or RATIO in this state (COMPRESSOR out), THD quickly drops back near the baseline of 0.006%.

2. Perform the true bypass mod (G Bus true bypass - DIYRE Support Center) where you turn the XFMR switch into a true bypass switch. This comes with the tradeoff that you lose access to one of the output styles, either IC or XFMR. But you would then have true bypass accessible via the front panel.

3. Implement the new bypass scheme that we figure out. We'll have this worked out pretty soon, at which point I can drop instructions here for how to do it to the v1.0 PCB that you have. It will almost certainly involve cutting some traces and running wires.

So, up to you which way you want to go! Personally, I would go with option 1 and just make sure that THRESHOLD and RATIO are not at maximum if I am tracking through the G Bus in bypass. But, I don't know your workflow, so I can't make that determination for you.

Thanks again for your help with this @Clbraddock! I will post the new bypass scheme details soon.

No prob. Glad we got it figured out, and I definitely appreciate all of your insight and input figuring it out!

Im also happy I can put my 202c goldcans back in! I realize that they probably dont make any real difference, but I think they are "cool" and that makes me happy lol

If you think the revision will be figured out within the next few weeks, I might just wait and see what it involves before deciding what to do. Its not a pressing need to have the compressor hooked up, and it is a major pain in the butt to get it in and out of the rack in my desk.

Thanks!

Edit: Just wanted to add that I love this forum. So many super smart electronic wizards willing to help out people just learning like me. Such a great place!

 

[Voyager10]

Final comments from me:

- switching the filter to EXT SC when you switched it OUT seemed to cure the leakage, so that might be a tolerable workaround.
- I still can't figure out why R89 is useful either. If it were me I'd short it out (so IC1.1 is a standard voltage follower like IC1.3, IC1.4 etc.). It may not help but shouldn't hurt.

Thanks for playing, everyone, it's been fun.

 

[Clbraddock]

- switching the filter to EXT SC when you switched it OUT seemed to cure the leakage, so that might be a tolerable workaround.

Thats a great idea. Thanks!

 

[Clbraddock]

Any progress on the new bypass scheme? Thanks!