开云体育

  1. Direwolf
  2. Messages
Expanded Topics Messages Polls
Date
Re: 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


# Home call
MYCALL KQ6DI-4


MODEM 1200
#TXDELAY 25
#TXTAIL 2
PTT GPIO 27
DCD GPIO -17


AGWPORT 0
KISSPORT 0


FIX_BITS 1


# Beacon for Pi Zero
# home location & symbol
PBEACON delay=0:10 every=59:59 symbol="igate" overlay=R lat=38^21.77N long=121^24.76W


# Send Telemetry
#CBEACON delay=14:35 every=30:02 InfoCmd="sudo python makemytelem.py"


#This should only digipeat WIDE1-1
DIGIPEAT 0 0 ^WIDE[3-7]-[1-7]$ ^WIDE[1]-[1]$ TRACE


#Digipeat parameters & filter to desired stations
FILTER 0 0 ( b/KQ6DI/KQ6DI-*/WA6ODP-*/WB6ETY/WB6ETY-*/W6TCP/W6TCP-*/W6ERE-*/KG6AZZ* ) & ( ! b/WA6ODP-3)?


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

?


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
Re: Raspberry Pi Zero VERY long transmit delay

 

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

?


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
Re: Raspberry Pi Zero VERY long transmit delay

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
Re: Raspberry Pi Zero VERY long transmit delay - more

 

So I put the micro USB hub #2992 back in Without the WiFi USB thing, and my problem went away. ?However that USB Hub does have an ethernet port, although nothing is attached... ?Just the Sound USB thing.
The Sound device is Syba. ?I know it's not recommended to run on a hub, but that's the only way this works???

I don't think I have any more micro-USB hubs or anything else, so I've run out of things to try. ?At least I'm narrowing it down.

Arnold
KQ6DI

From: "kq6di@... [direwolf_packet]"
To: "direwolf packet"
Sent: Saturday, March 11, 2017 10:52:57 AM
Subject: [direwolf_packet] 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
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
Bluetooth SPP w/ APRSDroid

 

I've been researching and trying to see if it's at all possible to run Dire Wolf with a virtual TNC over Bluetooth SPP for use with APRSDroid. I can easily do it over TCP/IP, but Bluetooth is more convenient and suits my project a bit better. Any have any ideas?
Re: Direwolf APRS I-Gate over Cellular

 

Check out freedompop on sprint, aka cdma. Free 500 megs each month and easy to root and hotspot most devices.?
Re: dw 1.3: "gps must be configured to use tbeacon"

 

David, thanks. My bad; I had not in fact read the 1.3 docs as you can guess. :) Figures that I am looking at the guts of source code instead of the obvious. All better now, though. -Mike K0FSJ
Re: dw 1.3: "gps must be configured to use tbeacon"

David Ranch
 

开云体育


Hello Shimniok (no call given),


?
Config file, line 58: GPS must be configured to use TBEACON

I assume you've configured a Tracker beacon (tbeacon) in your direwolf.conf and also configured the use of your GPS using either the GPSNEMA or GPSD keywords.


But on direwolf-1.2 -- using the very same config file -- no such error and, in fact, the older version happily beacons the gps-provided position as instructed by the TBEACON statement.


Looking at the older Direwolf 1.2 Raspberry-Pi-APRS-Tracker.pdf documentation, this GPS support is via gpsd method ONLY.? Unfortunately, it seems the TBEACON there assumes that things just work vs. modern version of Direwolf requires that you specify which GPS method you want to use (GPSNEMA - aka direct serial support or GPSD via the daemon) in the direwolf.conf file.? This is obviously a change in behavior from a configuration point of view but I don' think this is a big deal.


Any ideas what might be amiss? Possibly a bug? Thanks!


Please update your direwolf.conf to reflect how you want to use your GPS and let us know how it goes.

--David
KI6ZHD
dw 1.3: "gps must be configured to use tbeacon"

 

I'm running into a TBEACON error on RPi / direwolf 1.3.?I searched github issues, googled, and searched yahoo groups -- to no avail. I figured I'd ask if anyone's seen this...


On RPi 2, newly dist-upgraded Debian Jessie, using a USB GPS and gpsd set up as instructed,?direwolf 1.3 (rebuilt for gpsd as instructed)?issues this error upon startup:


Config file, line 58: GPS must be configured to use TBEACON


But on direwolf-1.2 -- using the very same config file -- no such error and, in fact, the older version happily beacons the gps-provided position as instructed by the TBEACON statement.


Q: Is anyone else running direwolf 1.3 on a Raspberry Pi? Are you seeing the same error or not?


I haven't dug into the source code to any great extent yet, but the code generating this error message doesn't exist in 1.2. I've eliminated gpsd as the problem -- direwolf 1.2 works fine along with?cgps -s?and gpsmon commands.


Any ideas what might be amiss? Possibly a bug? Thanks!
Re: Audio input device 0 error: Input/output error

David Ranch
 

开云体育


Hello John,

If things are working for an hour or so and then things start to break down, I would begin to suspect:


?? - RFI from your radio getting back into the soundcard and/or Rpi and confusing/corrupting it
????? - Try disconnecting the PTT line from the radio and make it a purely RX setup.? See if that makes your Direwolf setup run longer.? Say all day, etc.
????? - If this helps, make sure you have the audio lines using decoupling caps, the polarity of the lines are correct, wrap ferrite chokes on both sides of all audio cables.? More turns per side, the better (within reason)

?? - Do you have any other software running that is trying to use the soundcard:? mixers, pavucontrol, etc?

?? - You might have a poor/weak power supply for the Rpi.? You should ideally be running a 5.1volt (not 5.0 but 5.1V) 2A or better supply.?
????

?? - You might have a marginal hardware be it the sound device or Rpi.? Could be say heat could be building up and making it fault (do you see other OS errors in /var/log/syslog?)? What kind of airflow does the Rpi have through it's case?


Ps.? I see that you're using Audio device 0 here meaning that you disabled or swapped the built-in sound device to be "audio device 1".? I generally leave the built-in soundcard in place and set as the default audio device.? I then let the USB sound device for packet to be device 1.? This seems to avoid misconfiguration issues, etc.

--David
KI6ZHD


On 03/08/2017 07:37 AM, John Spoonhower jpspoonhower@... [direwolf_packet] wrote:

?
David,
sorry for the delay. Just to be sure I checked the patch level of Jessie:
?apt-get update
??? apt-get upgrade
??? apt-get dist-upgrade
??? rpi-update
??? reboot.

?still see the same error after an hour or so of clean operation.

The sound devices are directly connected ...no USB hub.

73, NX2I, John

"Insanity: Doing the same thing over and over again and expecting different results"
- Albert Einstein

On Fri, Mar 3, 2017 at 1:05 AM, David Ranch dranch@... [direwolf_packet] <direwolf_packet@yahoogroups.com> wrote:
?


Hello John,


?

?? - What Linux distro and version of distro are you running??

Raspbian Jessie

Ok.. and it's fully patched:

??? apt-get update
??? apt-get upgrade
??? apt-get dist-upgrade
??? rpi-update
??? reboot


?? - Are you running in command line only mode or running Xwindows?

Command line

 Ok.. and how is your Syba sound device connected to your Raspberry Pi?? Directly connected (recommended) or via an attached USB hub (not recommended)

--David
KI6ZHD
Re: Audio input device 0 error: Input/output error

 

David,
sorry for the delay. Just to be sure I checked the patch level of Jessie:
?apt-get update
??? apt-get upgrade
??? apt-get dist-upgrade
??? rpi-update
??? reboot.

?still see the same error after an hour or so of clean operation.

The sound devices are directly connected ...no USB hub.

73, NX2I, John

"Insanity: Doing the same thing over and over again and expecting different results"
- Albert Einstein

On Fri, Mar 3, 2017 at 1:05 AM, David Ranch dranch@... [direwolf_packet] <direwolf_packet@yahoogroups.com> wrote:

?


Hello John,


?

?? - What Linux distro and version of distro are you running??

Raspbian Jessie

Ok.. and it's fully patched:

??? apt-get update
??? apt-get upgrade
??? apt-get dist-upgrade
??? rpi-update
??? reboot


?? - Are you running in command line only mode or running Xwindows?

Command line

 Ok.. and how is your Syba sound device connected to your Raspberry Pi?? Directly connected (recommended) or via an attached USB hub (not recommended)

--David
KI6ZHD
Re: Serial PTT not functioning after exit

 

开云体育


On 05/03/2017 19:48, wb2osz@... [direwolf_packet] wrote:
?


Nick B. wrote:

> ? Despite being able to write to GPIO as my normal user,
> ? Direwolf always wants a sudo password.

Commit?58c2707f7d65b5b074b5e67e00c06a50fb968349, on the 'dev' branch, should fix this.

Raspbian Jessie has a new 'gpio' group which was not in Wheezy.
The logic for getting access to the GPIO pins has been rewritten to take advantage of that.


Just pulled and rebuilt from dev branch. That works for me (user is a gpio group member). Thanks!
Re: Digipeater hearing & repeating itself

 

This has been fixed.
67b11d4922ce538e55ab7853c1a449ad4de6ec83 in the 'dev' branch.
Don't digipeat packets when the source is my call.
Re: Serial PTT not functioning after exit

 


Nick B. wrote:

> ? Despite being able to write to GPIO as my normal user,
> ? Direwolf always wants a sudo password.

Commit?58c2707f7d65b5b074b5e67e00c06a50fb968349, on the 'dev' branch, should fix this.

Raspbian Jessie has a new 'gpio' group which was not in Wheezy.
The logic for getting access to the GPIO pins has been rewritten to take advantage of that.



?
Re: Audio input device 0 error: Input/output error

David Ranch
 

开云体育


Hello John,


?

?? - What Linux distro and version of distro are you running??

Raspbian Jessie

Ok.. and it's fully patched:

??? apt-get update
??? apt-get upgrade
??? apt-get dist-upgrade
??? rpi-update
??? reboot


?? - Are you running in command line only mode or running Xwindows?

Command line

Ok.. and how is your Syba sound device connected to your Raspberry Pi?? Directly connected (recommended) or via an attached USB hub (not recommended)

--David
KI6ZHD
Re: Audio input device 0 error: Input/output error

 

Dave,
Please see responses below.?
73, John, NX2I


On Mar 1, 2017 7:10 PM, "David Ranch dranch@... [direwolf_packet]" <direwolf_packet@...> wrote:
?


Hello John,

I've been running Direwolf v1.4 on both a Raspberry Pi v2 and v3 with Syba USB devices with good luck for months.? A few questions if I may:

?? - Are you running on a Rpi v1, v2, or v3??


V3

?? - What Linux distro and version of distro are you running??

Raspbian Jessie

?? - What else is your Rpi running along side Direwolf?

Basically nothing.

?? - Are you running in command line only mode or running Xwindows?

Command line


--David
KI6ZHD


On 03/01/2017 01:26 PM, John Spoonhower jpspoonhower@... [direwolf_packet] wrote:
?
Thanks Tim.
I have been testing this solution for the last couple days. Bottom line.....
I still see the same error.
Thanks and 73,
John NX2I
Re: Audio input device 0 error: Input/output error

David Ranch
 

开云体育


Hello John,

I've been running Direwolf v1.4 on both a Raspberry Pi v2 and v3 with Syba USB devices with good luck for months.? A few questions if I may:

?? - Are you running on a Rpi v1, v2, or v3???
?? - What Linux distro and version of distro are you running?
?? - What else is your Rpi running along side Direwolf?
?? - Are you running in command line only mode or running Xwindows?

--David
KI6ZHD


On 03/01/2017 01:26 PM, John Spoonhower jpspoonhower@... [direwolf_packet] wrote:

?
Thanks Tim.
I have been testing this solution for the last couple days. Bottom line.....
I still see the same error.
Thanks and 73,
John NX2I
Re: Audio input device 0 error: Input/output error

 

Thanks Tim.
I have been testing this solution for the last couple days. Bottom line.....
I still see the same error.
Thanks and 73,
John NX2I

On Feb 27, 2017 9:08 AM, "overrocking@... [direwolf_packet]" <direwolf_packet@...> wrote:
?

John,?


I have run into a similar error.?
What I found was that the Raspberry Pi processor couldn't keep up with the audio demands at the higher USB speeds. This resulted in dropped USB packets that caused the Rpi to lock up.?

The solution was to force the Rpi to the lower USB speed by adding a parameter to the cmdline.txt?

sudo nano /boot/cmdline.txt

and adding dwc_otg.speed=1 to the end of the text.


?However, this solution is not without its side effects. Some keyboards and mice refuse to operate at this speed. This is not an issue if you are connecting to the Pi via ssh or VNC.

If there is a better solution, I am all ears.?

Tim (KD9DBG)


?
Re: Audio input device 0 error: Input/output error

 

开云体育

Hi,

It may also be worth reducing checking the CPU load by running top or htop in another terminal. Then reduce the sampling rate by running with e.g. "direwolf -r 11025" . This made a difference for me on slower single-core processors (A10, Pi Zero). It could also be an issue with the soundcard itself.

I would agree that dwg_otg=1 can break usb keyboards and mice in my experience. It did, however solve some issues I was having with SD card readers when backing moving file systems from SD -> microSD...

Nick.

On 27/02/2017 14:08, overrocking@... [direwolf_packet] wrote:

?

John,?


I have run into a similar error.?
What I found was that the Raspberry Pi processor couldn't keep up with the audio demands at the higher USB speeds. This resulted in dropped USB packets that caused the Rpi to lock up.?

The solution was to force the Rpi to the lower USB speed by adding a parameter to the cmdline.txt?

sudo nano /boot/cmdline.txt

and adding dwc_otg.speed=1 to the end of the text.


?However, this solution is not without its side effects. Some keyboards and mice refuse to operate at this speed. This is not an issue if you are connecting to the Pi via ssh or VNC.

If there is a better solution, I am all ears.?

Tim (KD9DBG)


?
8681 - 8700 of 10532