Audio TRRS PTT Schematic Bug


I’ve come across a bug in the schematic that has affected others and not been resolved with board rev 1.9. This is related to the hardware PTT switching functionality

What I’m referring to is the “stuck PTT” complaints unrelated to RF or anything else. It’s easy to reproduce. If you break squelch manually with no RF when the digirig is unpowered (not supplying the NPN forward bias) there is a latchup in the switching circuit. You can simulate it by supplying +3-4v on the tip of the TRRS jack. I can’t imagine that’s good for the CM108 either.

This is a real problem using this method of PTT. :grimacing:

Do I understand it correctly that you apply DC voltage to the audio input and that triggers the PTT?

Here’s the schematic of the relevant circuitry. You can see that the line is DC-decoupled with C21 before it reaches the codec. It’s not clear how that would end up running current through the base of Q2.

All I can tell you without soldering on a bunch of bodge wires for test points is that either R1 or R2 is being pulled low when T is high and there is no other source of power to the board. There is +3vdc from R1 and R2 when in the OFF state and drops to ~+1.2vdc when pulled low (ON), T is -0.5vdc low (OFF) and +3vdc (ON) when high. (VX-6R)

Cutting the trace enabling the attenuator confirmed my suspicion. This prevents the incoming DC from triggering a latchup but now the board latches when the PTT is pressed on the radio and there is no power to the digirig. The DC is not being effectively decoupled. At least this error state can be more easily avoided but it is not a real fix. I’ll see if I can get a scope on it later.

I remember, now. I did this on our FM repeater right before a digital net when I was getting set up. The usb end of the digirig was dangling. I power cycled my radio to try to stop it.

73 Constrainted

I did some experimentation. Here’s what I think is going on:

With everything shut down, the audio from the radio gets past the decoupling cap C21 into the codec and rectified through the internal input protection circuitry to the 5V rail which then opens the Q2 PTT switch through R18 pullup.

Here’s how typical clamp protection circuit looks like:

I’ve added R19 assuming the issue stems from loose RF interference messing with Q2, but apparently things are quite bit more involved. Swapping R19 from 100K to 12K takes care of the issue in my tests even with headphones level audio at max volume. I’ll apply this mod to the next batch.

Thank you for bringing it up. Luckily this is exotic enough scenario that very few operators came across it. The irony is that this accidental case is 1:1 equivalent of the deliberate PTT implementation in the cellphones cable I’ll be releasing later this year.



Here is a post perhaps describing this issue:

73 Constrainted