Long delay (1sec) when switching from TX to RX

[radiokitten]

Hi All,

I’m having trouble connecting to my local ARES BBS through my uv-5r, Digirig & Direwolf. After trying various Direwolf settings on both MacOS and a Raspberry Pi 3, I think the problem is that the Digirig has a too long delay between the radio TX ending and the input audio coming back on.

When Direwolf transmits I can hear the outgoing packets in a separate HT that I use for monitoring. Then right afterwards I hear the response from the BBS but Direwolf does not pick it up and decode it. Subsequent messages from the BBS are being decoded just fine (when Direwolf wasn’t transmitting right before) but since it misses the initial UA response, the connection does not get established. Direwolf only fails to decode right after transmitting.

To understand what’s going on I listened to the mic input of the Digirig USB soundcard through my headphones and noticed that there’s a long silence after each transmission of approximately 1 second before the input audio comes back. Towards the end of the silence I can hear the tail of the BBS response. This would explain why Direwolf can’t decode it: it only hears the tail end of the message. I also confirmed that this 1 second of input silence exists when I hit the PTT button on the radio myself, which suggests that this is not a Direwolf or serial PTT problem. Additionally I tried this with low TX power, with various antennas connected (the rubber duck, a J-Pole under the roof), and without an antenna to rule out RF interference between the transmitting radio and the digirig but the delay is still there. I’m using the official Baofeng cable from the digirig store.

To rule out issues with the radio itself, I connected it to the laptop with a “dumb” APRS cable [0] and when hitting PTT, the audio comes back after ~100ms or so, much quicker than when connected to the digirig. I also tried this with two different uv-5rs but the behavior is the same.

I also went through the radio settings to make sure that things like squelch tail elimination are off. In the past I had been able to use these radios with an easydigi and a serial cable (but I don’t have access to that setup anymore).

Now my question is: is this a known issue? Is there anything I can do to prevent this long silence after the radio transmits?

Thanks for any help with this!

---

This is my direwolf config:

ADEVICE  plughw:1,0
CHANNEL 0
MYCALL <MY CALL SIGN>
MODEM 1200
PTT /dev/ttyUSB0 RTS
AGWPORT 8000
KISSPORT 8001
TXDELAY 30
TXTAIL 10
SLOTTIME 10
PERSIST 63

Not sure if it’s relevant at all but the BBS runs JNOS-2.0k.2.xsc.4-B1FHIM$.

---

[0] The cable is called BTECH APRS-K1

[K0TX]

Normally Digirig’s input is receiving audio continuously, regardless if the radio transmits or receives or turned off. It’s just a mic audio input into the computer and it has no concept of or electrical connections to PTT. With that in mind, there should be no silence as long as the sending side (radio) has the audio output.

Now one thing comes to mind: do you have AGC unchecked in the recording device settings? If enabled, the AGC can hear the loud click from PTT switch and send the gain way low killing the audio until it readjusts.

[radiokitten]

Thanks for your comment.

I remember turning AGC off on the Raspberry Pi and I just double checked and repeated my experiments just to be sure it was turned off.

I also search around but MacOS doesn’t seem to have a setting for it in the system at all so I assume it’s disabled there, too.

I created recordings from the Mac that show the issue, one with Digirig and one with the APRS cable for comparison. You can find both files here: Dropbox - Digirig - Simplify your life

Please let me now if there’s anything you can think of or that I can try.

[K0TX]

I would try on the PC where there is an explicit setting for AGC which is enabled by default.

[radiokitten]

Sadly I don’t have a PC here that I can try this with, only a Macbook and the Raspberry Pi.

In the meantime I noticed that sometimes the input audio would have a weird bouncing to it and I’d have to unplug and replug the Digirig to get rid of it. I made a recording of it here: Dropbox - Bouncing after PTT.m4a - Simplify your life

Does that point towards any known issue?

I’ll keep looking for AGC settings in the meantime. Thanks again for your help!

[K0TX]

That can also potential point to AGC dialing in the sensitivity.

[radiokitten]

Here’s the waveform of the Digirig PTT response (no antenna attached):

I’m not sure what that is telling me though. It does look like something is messing with the gain. I can’t find any notion of it in the system settings and for recording this clip to get the waveform I made sure that “Automatic Level Control” is off in the recording software.

Edit: This is the waveform for the APRS cable, same settings in the recording software.

[K0TX]

You can probably have some effect on it by trying different radio volume settings and mic sensitivity, but ultimately the sound card should have the AGC turned off for predictable results.

[radiokitten]

I also went ahead and created recordings on the Raspberry Pi which has an explicit AGC setting. I recorded a manual PTT push with AGC on and off. It didn’t make a difference, other than the overall levels being higher.

Here’s with AGC off: Dropbox - AGC-off.wav - Simplify your life
And here’s with AGC on: Dropbox - AGC-on.wav - Simplify your life

Is there any way in which the internal circuit of the Digirig could get overloaded or restarted that would explain this strange phenomenon? Could any of its components get shorted out or discharged by the PTT or some faulty wiring and show such a behavior as a result?

Apologies for all the questions. I’m out of ideas what else to try.

[K0TX]

If this was a systematic issue I’d get other reports by now. We can swap your Digirig out for a different unit to settle the faulty hardware issue. Please PM me for RMA if you want to go this route.

[radiokitten]

Today I spent some more time trying to figure things out and I discovered that the long delay after PTT release only happens when the input volume is very low. Higher volumes seem to make it through the Digirig much quicker.

If I set the radio to about 10% of it’s volume, then the behavior is as I described before. If I set it to about 25% of its volume, the silence after the PTT becomes shorter:

Setting the radio volume to about 55%, the silence seems to be gone:

However, at that volume level, the signal is too overdriven for Direwolf to work (around 185, Direwolf claims it should be around 50, I’ve seen something like 90 work in the past). As such I also haven’t had much success in connecting to the local BBS.

As before I tried this with both MacOS and the Raspberry Pi and made sure that the input volume / mic gain sliders were as low as possible.

Does a low audio input volume explain what I’m seeing or does this indicate an issue with my particular unit? Are there any impedances on the audio input side that would explain the asymptotic curves in the signals?

I also thought of enabling the hardware attenuator on the Digirig but I’m not sure whether that would cause the same issues just at a higher volume setting?

Thanks again for your help!

[K0TX]

This can also explain the AGC theory. If you keep the radio’s volume low, the input sensitivity has to adjust to high. Then in the PTT switch the loud click desensitizes the input and you get no audio for some time until AGC adjusts the sensitivity back up. If the volume is high and the sensitivity is low to begin with then the click blends in and there is less adjustment for AGC to make. The attenuator may help with the situation, it may be worth trying.

[Constrainted]

With the Baofeng HT and the 5/20/50W mobile, using Soundmodem/Win 11, my TX delays for packet are 100 - 300 ms, and I even have set them higher. I sent some 2m packet earlier today.

[radiokitten]

Thanks for your message. I checked multiple times to confirm that AGC is off on both operating systems where I observed the behavior. I’ll reach out in a PM for RMA.