Keyboard Shortcuts
Likes
Search
Raspberry Pi Zero VERY long transmit delay
I asked this question before and didn't get any answer, so now I've done more testing and have a major clue. I have a Raspberry Pi Zero running DireWolf that has a very long transmit delay. ?First, I do have all of the Pi OS updated to the latest and greatest. ?It has done this with BOTH DireWolf versions 1.3 AND 1.4. What I see (and hear on the radio) is the transmitter is turned on with total silence transmitted for up to 8 seconds or so, then the packet burst and the transmitter gets turned off. ?Sometimes there is no delay, and quite often it is 5 seconds or more. I had no problems when my sound USB device AND a wireless Ethernet were plugged into a USB Hub w/ Ethernet Hub. When I removed that hub and all internet access, my problems begin again. ?I now have the sound device plugged into the Pi Zero through a 4" micro USB to USB adapter cable. ?Then the problem begins. I have tried other USB sound devices with the same results. I'm going to try putting the USB hub back in without the wireless USB device and see what happens, but it has a wired Ethernet port on it (but nothing plugged into that port). Any hints on why the Pi Zero seems to need the USB hub w/ internet to function properly with DireWolf? Since the Pi Zero in stand-alone digipeater configuration only requires 80 mA from my 12V supply (Yes, regulated down), this is perfect for the battery & solar portable digipeater... ?if it worked. Thanks, Arnold KQ6DI-4 |
David Ranch
开云体育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 |
David, Correct, I am not using any Linux AX.25 Stack. ?I am also not including any HamLib support in the DireWolf build. The Hub I am using (that works) could have an external supply, but it wasn't included and wasn't specified, so I don't have one there. I don't have any?PERSISTANCE or TXDELAY parameters set, I'm just using the default. The odd part here is the transmitter keys up with no audio, so the channel is or should be clear. ?Even if it was hearing itself, no audio out of the sound card doesn't have much modulation for Persistance to wait for. If you provide more details on what you would like for Telemetry, I'd be glad to try. ?I'm just not sure what I should set, and how... ?Other telemetry is not an issue for me, just don't know what goes here. I did find another USB hub (not powered) and a micro to mini USB adapter that should permit it to work in the Zero. ?Since the long delay isn't always present, I like to run one test long enough that I have a positive result (yes or no) for each configuration. At least I have a configuration that works now, even if it isn't ideal. ?So we'll figure it out. Arnold KQ6D From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Saturday, March 11, 2017 3:44:27 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
|
David, I should have provided you with the DireWolf configuration. ?The following is the configuration I have for this Zero. ?Anything not included is commented out. ?These are the only active parameters. Arnold KQ6DI
MODEM 1200
# Beacon for Pi Zero # Send Telemetry #This should only digipeat WIDE1-1 #Digipeat parameters & filter to desired stations From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Saturday, March 11, 2017 3:44:27 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
|
Usually you would have something like "ADEVICE?plughw:1,0" when running on the Raspberry Pi. ?I don't see ADEVICE in there which would result in using the "default" device. Did you make sure that PulseAudio was removed? ?In my experience PulseAudio never worked right on the RPi and my recommendation is to remove it. ? (Note: ?It is fine on larger x86 based systems.) ?? ?Currently section 1.3. The other thing I would try is running the "top" command in another window? ?What is using a significant amount of CPU time? ?How much idle time is left over? |
Somehow I missed putting this in the email. ?It IS in the DireWolf configuration. ADEVICE plughw:1,0
I DO have PulseAudio removed. ?I don't think it is included in the latest Raspberry Pi Jessie OS, but I went through the steps anyway. 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. ?However, there are other changes going on, so I haven't convinced myself about this. ?I just thought I'd toss that wild thought out. Running the "Top Command" in another window is an issue in itself. ?I'm trying to run this without any external connection to anything. ?If I do have this connected, then only about 20% of the processor time is used, but I have no idea when I start having issues. Arnold KQ6DI From: "wb2osz@... [direwolf_packet]" <direwolf_packet@...> To: "direwolf packet" Sent: Sunday, March 12, 2017 3:33:36 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay Usually you would have something like "ADEVICE?plughw:1,0" when running on the Raspberry Pi. ?I don't see ADEVICE in there which would result in using the "default" device. Did you make sure that PulseAudio was removed? ?In my experience PulseAudio never worked right on the RPi and my recommendation is to remove it. ? (Note: ?It is fine on larger x86 based systems.) ?? ?Currently section 1.3. The other thing I would try is running the "top" command in another window? ?What is using a significant amount of CPU time? ?How much idle time is left over? |
David Ranch
开云体育Hey Arnold,
When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running?? --David |
David, "When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running? ?" How would I know??? ?I suppose I could connect to the serial port for a terminal. ?Would that give you the answer? Arnold From: "David Ranch dranch@... [direwolf_packet]" To: "direwolf packet" Sent: Sunday, March 12, 2017 8:32:20 PM Subject: Re: [direwolf_packet] Raspberry Pi Zero VERY long transmit delay
When your Rpi isn't connected to the network, what is in the /etc/resolv.conf file?? Anything?? Is DNSMasq running?? --David |
David Ranch
开云体育Hello Arnold, ? Yes, or connect up the HDMI display with a USB keyboard. --David KI6ZHD |
Hello all,
I had this problem to using Direwolf 1.6 development build. I performed this action to reinstall the libsound2 libraries and the problem went away. I forcefully removed the libasound2 library and re-installed them.??? ? ?
Note that since I do not actually understand the root cause of this problem, I cannot guarantee this solution. However it did work for me. My problem is gone, and all packets transmit in around 1 second or less. I'm running on Raspberry PI Zero, OS = "Raspbian GNU/Linux 10 (buster)", again running a development version of Direwolf 1.6 -- Rich KC3ARY
|
开云体育Hello Rich,This is a rather old email thread (2017) but it has been discussed many times in other threads.? There is a known issue around the Raspberry Pi and it's legacy USB stack with DIrewolf.? You're removal and re-install of the ALSA libraries fixing your issue is just coincidental and I'm pretty sure your issue remains though you don't realize it.? Below is what I wrote about this topic in my Raspberry Pi documentation --David KI6ZHD -- ?e. Direwolf Dead TX issue : OSS Support: ???? If you're using a USB based sound device (not an I2S-based sound device) on older Raspberry Pi ???? model (RPi 3B+, 3, 2, Zero-W, Zero, 1, but NOT the RPi4), there is a known issue of Direwolf ???? transmitting random amounts of "dead airtime" before actual modem sounds play.? You can read ???? more about this Raspberry Pi DWC bug at: ??????? ?????????? and ??????? ??????? ??????? ???? It was previously recommended that older Rpi HW owners try a work around using the OSS sound system ???? but this OSS support was accidentally removed from the Rpi kernel (recently re-added in). ???? Per , there are several options to address this ???? issue: ??????? Option #1: DWC2 USB stack - BETA RECOMMENDED ?????????????????? Rpi 0, 1, 2, 3, 3+ users can try using the alternative "DWC2" USB stack which the ?????????????????? Rpi 4 hardware already uses.? To try this, add the line "dtoverlay=dwc2" to the ?????????????????? /boot/config.txt file and rebooting.? Please make a backup of your SD card before ?????????????????? you try this ??????? Option #2: Use a cutting edge kernel version ?????????????????? Users running Raspberry Pi OS Buster, Stretch, and Jessie can switch to using the ?????????????????? bleeding edge kernels using the "rpi-update" tool to get both the DWC_OTG fixes ?????????????????? finally solve ALSA sound issues as well as bring the return of the OSS sound system.? ?????????????????? Once the 5.4.70 kernel for the Buster OS comes to a mainline release (~Jan 2021), ?????????????????? Raspberry Pi Buster users will no longer need the bleeding edge kernels.? The Stretch ?????????????????? and Jessie distros will NEVER get these fixes in a mainline kernel update so you'll ?????????????????? need to stick with the bleeding edge kernels.? Please make a backup of your SD card ?????????????????? before you try this. ??????? Option #3: Use the Legacy OSS sound stack ?????????????????? It seems that the original Linux sound system (OSS) is not affected by this DWC ?????????????????? USB issue and thus, fixes the issue.? The problem here is that in modern Raspberry Pi ?????????????????? OS versions, this option was accidentally disabled in the mainline kernel.? If users want ?????????????????? to go this route, you will either need to use a bleeding edge built kernel mentioned in ?????????????????? Option #2 above or compile your own kernel.? Building a new kernel isn't too hard ?????????????????? and there are many guides out there on the Internet how to do it but it does take time. ?????????????????? If you've never built a kernel, I recommend this as you'll learn a lot. ???? BETA RECOMMENDED Dead Airtime fix:? ?????????????????? For simplicity sake, I recommend users to try the DWC2 USB stack as it's very easy to ?????????????????? deploy but it doesn't have a huge amount of testing yet.? It's worth noting that this ?????????????????? is the same USB stack that's now used on all Raspberry Pi 4 and newer SBCs but it's just ?????????????????? not the default for them.?? To use this newer stack, it's highly recommended you FIRST ?????????????????? make a backup of your SD card if something goes badly.? See the later sections in this ?????????????????? guide how to do that easily. ?????????????????? With a SD backup done, simply edit the /boot/config.txt file and add the following line ?????????????????? to the bottom of the file: ????????????????????? dtoverlay=dwc2 ? ?????????????????? Once done, reboot your Raspberry Pi and make sure everything is working fine.? That's it! -- On 10/29/2020 07:34 AM,
rvnash@... wrote:
Hello all, |
After reviewing the best information I could on this topic, I took this recommendation and started using DWC2 in my digipeater setup.
toggle quoted message
Show quoted text
On Thu, Oct 29, 2020 at 01:31 PM, David Ranch wrote: ??????? Option #1: DWC2 USB stack - BETA RECOMMENDEDIt had been running without issue or long transmit delays for over a week. However?direwolf (1.6) exited?last?night. I captured the logs. Here is the direwolf log output: ?
?
The OS kept running, however in /var/syslog there is this single line around the same time.
?
Any insight into this?
Note I'm running this on a Raspberry PI Zero, running Buster 5.4.72. The sound card is a USB device I picked up on Amazon based on the?C-Media HS-100B chipset, Called a TROND AC2-P USB Audio Adapter. Thanks for any assistance. - Rich KC3ARY |
开云体育Hello Rich, It had been running without issue or long transmit delays for over a week. However?direwolf (1.6) exited?last?night. I captured the logs. Here is the direwolf log output: Since things were working well for you... and I was to guess, I'm thinking your USB stack went south due to RFI issues.? How close is your tranmitting antenna to the Raspberry Pi and it's USB based sound card?
If you look in your various /var/log/messages, /var/log/syslog, and "journalctl" output, I bet you'll see the USB sound card went "away".? That's a tell-tale sign of RFI issues. ?
The Direwolf documentation is pretty clear that it's observed "iffy" issues on various soundcards but good luck was found with the Syba units.? I personally think this was really revolving around the USB software stack but it's still early to tell.? A safe test would be to try "upgrading" to a Syba device and see if that helps but moving the TX antenna as far away from the Rpi and adding a bunch of ferrites to all wires going in/out of the Raspberry Pi (audio, power, etc) would be a safe bet too. --David KI6ZHD |
Hi David,
Thanks for the response, allow me to answer your question and offer some discussion. How close is your transmitting antenna to the Raspberry Pi and it's USB based sound card?The Pi Zero is 25 feet directly below the Arrow J Pole antenna. This should be a null spot in the radiation pattern of the antenna. However, the Pi Zero and associated wiring is literally directly on top of the transceiver, a Kenwood TM-281A. In looking at the logs of the timing of the situation, the audio problem occurred exactly in the same second of a transmit event (my digipeater doesn't transmit very often). This would strongly support the RFI theory. I'll take your suggestions to try to protect the system from RFI, and grab a Syba device as they are cheap. I'll report back if it happens again. Thanks again for your insights, -- Rich KC3ARY |