Hello Arnold,

There have been random reports about these delays and I've seen it too.? I didn't correlate it to being related to having a USB hub in front of the sound device but that's weird.? In the Direwolf docs, it's actually recommended to directly attach the USB sound card to avoid USB hub arbitration issues but Raspbian has changed a *LOT* in the last two years.

With your testing, does your USB hub support external power supplies?? I've found this is almost always required when you either have a Wifi dongle or multiple devices connected to it.?

I highly highly doubt that these delays are coming from the Rpi hardware, the USB sound hardware, or even the OS.? They have to be coming from Direwolf itself.? I believe you're doing all your packet work within Direwolf itself and not using the Linux AX.25 stack right?? Looking into this a little (guessing really), I wonder if this comes from say the PERSISTANCE or TXDELAY parameters:


--
6. Persistence

The P and SlotTime parameters are used to implement true p-persistent CSMA. This works as follows:

Whenever the host queues data for transmission, the TNC begins monitoring the carrier detect signal from the modem. It waits indefinitely for this signal to go inactive. When the channel clears, the TNC generates a random number between 0 and 1. [2] If this number is less than or equal to the parameter p, the TNC keys the transmitter, waits .01 * TXDELAY seconds, and transmits all queued frames. The TNC then unkeys the transmitter and goes back to the idle state. If the random number is greater than p, the TNC delays .01 * SlotTime seconds and repeats the procedure beginning with the sampling of the carrier detect signal. (If the carrier detect signal has gone active in the meantime, the TNC again waits for it to clear before continuing). Note that p = 1 means "transmit as soon as the channel clears"; in this case the p-persistence algorithm degenerates into the 1-persistent CSMA generally used by conventional AX.25 TNCs.
--

The real next step would be to add telemetry to your logs with detailed timestamps to see when the radio is getting keyed up vs. when audio is started, etc.? Looking at the direwolf code:

?? - in the audio.c file, there is the audio_flush routine which has various commented out debug lines that could be enabled (remove the # characters)
?? - in the ptt.c file, there is the much nicer "ptt_debug_level" variable and if you set this to 1 or 2 and recompile, you'll get more details

You might try fiddling around with some of these items, recompile Direwolf, and see what you get in the logs.?? Let us know what you find!

--David
KI6ZHD

Hello Arnold,

There have been random reports about these delays and I've seen it too.? I didn't correlate it to being related to having a USB hub in front of the sound device but that's weird.? In the Direwolf docs, it's actually recommended to directly attach the USB sound card to avoid USB hub arbitration issues but Raspbian has changed a *LOT* in the last two years.

With your testing, does your USB hub support external power supplies?? I've found this is almost always required when you either have a Wifi dongle or multiple devices connected to it.?

I highly highly doubt that these delays are coming from the Rpi hardware, the USB sound hardware, or even the OS.? They have to be coming from Direwolf itself.? I believe you're doing all your packet work within Direwolf itself and not using the Linux AX.25 stack right?? Looking into this a little (guessing really), I wonder if this comes from say the PERSISTANCE or TXDELAY parameters:


--
6. Persistence

The P and SlotTime parameters are used to implement true p-persistent CSMA. This works as follows:

Whenever the host queues data for transmission, the TNC begins monitoring the carrier detect signal from the modem. It waits indefinitely for this signal to go inactive. When the channel clears, the TNC generates a random number between 0 and 1. [2] If this number is less than or equal to the parameter p, the TNC keys the transmitter, waits .01 * TXDELAY seconds, and transmits all queued frames. The TNC then unkeys the transmitter and goes back to the idle state. If the random number is greater than p, the TNC delays .01 * SlotTime seconds and repeats the procedure beginning with the sampling of the carrier detect signal. (If the carrier detect signal has gone active in the meantime, the TNC again waits for it to clear before continuing). Note that p = 1 means "transmit as soon as the channel clears"; in this case the p-persistence algorithm degenerates into the 1-persistent CSMA generally used by conventional AX.25 TNCs.
--

The real next step would be to add telemetry to your logs with detailed timestamps to see when the radio is getting keyed up vs. when audio is started, etc.? Looking at the direwolf code:

?? - in the audio.c file, there is the audio_flush routine which has various commented out debug lines that could be enabled (remove the # characters)
?? - in the ptt.c file, there is the much nicer "ptt_debug_level" variable and if you set this to 1 or 2 and recompile, you'll get more details

You might try fiddling around with some of these items, recompile Direwolf, and see what you get in the logs.?? Let us know what you find!

--David
KI6ZHD

Hey Arnold,

Off the wall thought, it is possible that without any Ethernet device in the Pi Zero that something is looking for it, and kills things? ?That seems to be a common thread in my troubleshooting. ?If I have some sort of Ethernet or WiFi connected or not, nothing fails. ?When I don't have something, then I get this failure.