wb2osz
PTT dead air for 2-5 seconds before packet is transmitted
I believe this issue was fixed in a later Raspberry Pi OS release.
Please reopen this if the issue is observed again.
Originally posted by @wb2osz in #194
Dead air for 2-5 seconds before packet audio
Random, difficult to reproduce.
PRETTY_NAME="Raspbian GNU/Linux 13 (trixie)" Linux digipi 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux Pi5 Icom 705 Dire Wolf version 1.8 (Oct 4 2025) KM6LYW-1
EDIT:
Something needs to read/drain ttyACM0 before PTT is engaged. If you spin the vfo for a few seconds before a PTT, queuing up data behind ttyACM0, you get the dead air until that data is read (at a slow baud rate), causing the dead air before the packet.
Issue 194 was specifically for USB audio. Now 6 years later same symptom but with I2S audio device.
The test case https://github.com/wb2osz/rpi-usb-audio-bug did not detect a problem an RPi 5 running trixie and USB audio adapter. My recollection was that there was a timing issue in the USB audio driver.
You said this is very rare. I suppose my next step is to modify the test case to run for a couple days to catch glitches. I don't have an I2S audio device so it might not be relevant. Could you try the same thing?
To David: direwolf uses threads all over the place. Each audio input stream has its own thread. Reading from each network connection has a thread and uses a blocking read. There are threads that wake up when a queue becomes non-empty. Beaconing has its own thread which sleeps until the next beacon time. etc.
To Craig: /* Ugly hack for RPi. */ Don't remember off the top of my head. Need to study.
This is also USB audio (ic705 listed in OP). I can certainly try on other nonUSB audio devices too.
$ cat /proc/asound/cards
0 [CODEC ]: USB-Audio - USB Audio CODEC
Burr-Brown from TI USB Audio CODEC at usb-xhci-hcd.0-1.4, full speed
Ok, the scenario here is still USB-based audio. If Craig can report back the results of https://github.com/wb2osz/rpi-usb-audio-bug , that would be helpful. I'm also starting to remember this original TX-Delay scenario more and I had written this up at https://www.trinityos.com/HAM/CentosDigitalModes/RPi/rpi-setup.html#24c.direwolf-deadtx with work arounds for different Rpi hardware models. Craig, you are using an Rpi5 but you're also tailoring your system to work on Zero / Rpi3. Please confirm you ARE or ARE NOT enabling DWC mode on your Rpi5 (I'm not even sure if that mode is supported on the Rpi5).
Confirmed - DWC2 usb compatibility driver is only in use for 3B+/3A+/Zero2W, NOT Pi5/Pi4.
I backed out the 4x tx buffer change I made, which might have been because of the delay years ago. haven't replicated it yet, so I'm hopeful.
Reverted my Tx buffer hack, so direwolf is stock 1.8beta in this regard, Three in thirty packets has a 1.5 second dead-air preamble, though, not as long as before.
10% is pretty bad so this needs to be researched and possibly fixed. Per https://groups.io/g/direwolf/message/11041 , you said these delayed packets are coming via a KISS client. Are you seeing this for any beacon packets from within Direwolf itself? Please tell us what this other KISS client program is and if possible, share it's configuration so maybe this issue can be reproduced.
Also, since you're using an Icom IC-705 radio via USB for both audio and PTT, I assume you're using hamlib. If correct, what version are you using?
Completely stock checkout of dev, seeing this maybe 1/40 packets,
Raspberry Pi 5 Model B Rev 1.0 ICOM705 Raspberry Pi OS Trixie, Linux digipi 6.12.47+rpt-rpi-v8
Dire Wolf version 1.8 (Oct 17 2025) BETA TEST 1
Includes optional support for: gpsd hamlib cm108-ptt libgpiod-2.2.1 dns-sd
Reading config file /run/direwolf.tnc.conf
Audio device for both receive and transmit: default (channel 0)
Channel 0: 1200 baud, AFSK 1200 & 2200 Hz, A+, 44100 sample rate / 3, Tx AX.25.
Initializing GPIO common structure
Opening GPIO line 16 on chip /dev/gpiochip0
DCD 0 = 0
Hamlib determined CAT control serial port rate of 19200.
Ready to accept AGW client application 0 on port 8000 ...
Ready to accept KISS TCP client application 0 on port 8001 ...
DNS-SD: Avahi: Announcing KISS TCP on port 8001 as 'Dire Wolf on digipi'
Virtual KISS TNC is available on /dev/pts/0
Created symlink /tmp/kisstnc -> /dev/pts/0
DNS-SD: Avahi: Service 'Dire Wolf on digipi' successfully registered.
Now connected to IGate server noam.aprs2.net (205.209.228.99)
Check server status here http://205.209.228.99:14501
Attached to KISS TCP client application 0 on port 8001 ...
Ready to accept KISS TCP client application 1 on port 8001 ...
DCD 0 = 1
Digipeater HOPEMT audio level = 85(22/12) ___||||__
[0.4] PLKPIN>APOT30,HOPEMT*,WIDE2-1:!3845.70N/12034.70W# 13.4V N6YBH Pollock Pines DIGI
DCD 0 = 0
DCD 0 = 1
DCD 0 = 0
# digipi TNC direwolf configuration file
# this file is used as a template by direwolf.tnc.sh
MYCALL KM6LYW-2
# disable internet if crosstalk is an issue
# this is an issue with ISS/satellite stuff, we don't get credit for repeat
IGSERVER noam.aprs2.net
IGLOGIN KM6LYW-2 00000
# put us on aprs.fi map via internet
# change sendto=IG to sendto=RF to send beacons over RF
PBEACON sendto=IG compress=1 delay=00:15 every=30:00 symbol="igate" overlay=R lat=38.9119 long=-120.9356 comment=" DigiPi http://digipi.org/"
# APRS Tracker
# Comment out above PBEACON line, uncomment both lines below
# You might need to edit /etc/default/gpsd to assign gps device file
#GPSD localhost
#TBEACON delay=00:15 every=10:00 symbol="igate" overlay=R via=WIDE1-1 power=5 height=5 gain=3 comment="DigiPi igate/tracker http://digipi.org/"
# data carrier detect, and push-to-talk pins
DCD GPIOD /dev/gpiochip0 16
# direwolf.tnc.sh will modify and uncomment one of these and copy to /run/direwolf*conf.
# Add PTT line BELOW these to override. DO NOT edit the following PTT lines, or uncomment
# them.
#PTT GPIOD /dev/gpiochip0 12
PTT RIG 3085 /dev/ttyACM0
#PTT /dev/DEVICEFILE RTS
#PTT /dev/DEVICEFILE DTR
#PTT CM108 DEVICEFILE
DWAIT 0
TXDELAY 30
TXTAIL 10
AGWPORT 8000
KISSPORT 8001
Few ideas: Please enable Direwolf external file logging with timestamps to see timing detail. Please also enable Hamlib and PTT logging as well when starting direwolf. Please try disabling the DCD GPIO pin feature for now as that's all new code. Is the IC-705 really presenting itself to the Raspberry Pi as /dev/ttyACM0 and not as say /dev/ttyUSB0 ? Please mention what TCP-KISS application is sending these occasionally delayed packets.
TBEACON
[0L] KM6LYW-2>APDW18,WIDE1-1:!3854.70NT12056.09W&220/002DigiPi igate/tracker http://digipi.org/
If you spin the VFO, the next packet will have the dead-air preamble, every time. Hamlib flush?
If you spin the vfo for three or four seconds back and forth, presumably filling up the hamlib socket/buffer, you can increase the dead air. The dead air length seems directly proportional to the amount of data hamlib just sent with VFO events,
Direwolf is hung in ptt.c during the dead air at this function,
int retcode = rig_set_ptt(rig[chan][ot], RIG_VFO_CURR, ptt ? RIG_PTT_ON : RIG_PTT_OFF);
ptt.c
if (rig[chan][ot] != NULL) {
dw_printf ("craiger: start rig_set_ptt\n");
int retcode = rig_set_ptt(rig[chan][ot], RIG_VFO_CURR, ptt ? RIG_PTT_ON : RIG_PTT_OFF);
dw_printf ("craiger: exit rig_set_ptt\n");
if (retcode != RIG_OK) {
text_color_set(DW_COLOR_ERROR);
dw_printf ("Hamlib Error: rig_set_ptt command for channel %d %s\n", chan, otnames[ot]);
dw_printf ("%s\n", rigerror(retcode));
}
}
Spin VFO for a few seconds, then send packet via kiss,
PTT 0 = 1 craiger: start rig_set_ptt five second pause here craiger: exit rig_set_ptt [0L] KM6LYW>APZ100,WIDE1-1,WIDE2-1:@171720z3854.71N/12056.14WlAPRSD WebChat Beacon PTT 0 = 0 craiger: start rig_set_ptt craiger: exit rig_set_ptt
Which tells us this is a hamlib issue and not a Direwolf issue, no? Have you asked the hamlib folks about it?
Which tells us this is a hamlib issue and not a Direwolf issue, no? Have you asked the hamlib folks about it?
https://github.com/Hamlib/Hamlib/issues/1936
When Direwolf is starting up, it says "Hamlib determined CAT control serial port rate of 19200". As an experiment to see if serialization delays are very bad, various web searches say the IC-705 CAT control can be sped up to 115200. Press the [MENU] button on the IC-705 --> Navigate to [SET] --> Choose [Connectors] --> Select [USB Serial Port] --> Tap [CI-V USB Baud Rate] --> Change to 115200. Now you might actually have to run rigctld to be able to specify the /dev/ttyACM0 port speed if Direwolf doesn't auto detect it so see the thread here for more details (which you're already in btw): https://groups.io/g/digipi/topic/digipi_and_icom_ic_705/84985687 . Beyond that this CAT control speed up (which is always a good idea IMHO), this new delay might be coming from HamLib directly. There is also another option where instead of using CAT control, you can assert PTT via the "DTR" signal on one of the IC-705's /dev/ACM ports. Give this a read as well: https://www.florian-wolters.de/posts/ic705-serial-device-symlinks/
ttyACM0 is more of a character device than a serial port, so the baud rate doesn't even make sense (vs ttyUSB0).
The IC705 doesn't have [USB Serial Port] under [Connectors]
This is one workaround, demonstrating that rig_set_ptt() wont immediately return unless something first drains data waiting from /dev/ttyACM0.
wiggle VFO cat /dev/ttyACM0 (ctrl-C) transmit packet no dead air!