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"
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
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:
toggle quoted message
Show quoted text
?
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
|
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
?
Hello John,
?
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
Hello John,
?
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
V3
Raspbian Jessie Basically nothing.
Command line
|
Re: Audio input device 0 error: Input/output error
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:
toggle quoted message
Show quoted text
?
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.?
?
|
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.
toggle quoted message
Show quoted text
?
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.?
?
|
I'm seeing an odd problem, but it might be difficult to describe. I have a Raspberry Pi Zero running the latest software and DireWolf 1.4.E. ?But it has also done this with version 1.3. I am running this as a digipeater only without any internet.
When the transmitter is turned on (PTT from GPIO Pin) normally the audio/data is sent almost instantly.
Sometimes there is a long delay between PTT and sending any audio. ?This long delay is sometimes 5 seconds, and I've even heard close to 10 seconds of carrier only, no audio, then the data burst. You might think that it is waiting for the frequency to be clear, but it has already turned on the PTT and is transmitting, just no audio or data yet.
I'm sure this isn't enough information yet to figure this out, so where do I start looking?
Thanks, Arnold KQ6DI
|
Re: Serial PTT not functioning after exit
As far as it concerns permissions, everything seems to be fine. Something else is grabbing your serial port as soon as direwolf exits. After stopping direwolf, try: $ lsof | grep PTT and $ lsof | grep ttyUSB0 On ¦¤¦Å¦Ô, 2017-02-27 at 22:54 +0000, overrocking@... [direwolf_packet] wrote:
Thanks for the reply,
here is the results:
kd9dcs@bluetracker:/dev $ ls -al /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 0 Feb 27 15:26 /dev/ttyUSB0
as an added bonus here is the udev rule I wrote to create the link:
ATTRS{product}=="CP2104 USB to UART Bridge Controller", SYMLINK
+="PTT", GROUP="dialout", MODE="0660"
Tim ...
|
Re: Serial PTT not functioning after exit
Hi David, thanks for your reply.
I've been exploring the sudo issue for a few days now and here's
what I've found.
- Works perfectly on the default pi user on Rpi. This is because
pi is set up for sudo access without password. Can be verified by
examining the sudoers file with visudo.
- Direwolf calls chmod go+rw on the gpio direction and value
irrespective of whether the permissions are set correctly. Can be
verified by examining the system logs -? # journalctl | grep gpio.
All my user permissions are set up for gpio as you recommended
below. I can create gpio devices, change direction and write to
value as a normal user with gpio group membership.
gpio devices are created by udev rules with root:gpio 0770
permissions. This is set in /etc/udev/rules.d/99-com.rules. Also
worth noting that when a gpio device is created under
/sys/class/gpio it's actually a symlink to
/sys/device/platform/soc//3f200000.gpio/gpio.
So Direwolf appears to do some checks for permissions in ptt.c. I've
not quite figured that part out yet but for whatever reason it still
decides it needs elevated permissions to change the gpio direction
and value even if it is correct. I've sent a bug report/query to
John regarding this.
That aside, the decoding performance on HF is fantastic! I've had a
Windows build running with 5@30 300 modems and it's decoding stuff I
can barely hear on 10.1476MHz.
73
Nick G4IRX
On 28/02/2017 05:05, David Ranch
dranch@... [direwolf_packet] wrote:
toggle quoted message
Show quoted text
?
As for GPIO access, the running user needs
to be apart of the "gpio" group.? Quick example is:
--
??????? b. Add this new user into the following
unix groups:
????????????? - "audio" (allow users to access
the soundcard)
????????????? - "dialout" (allow serial port
access - if needed)
????????????? - "gpio" (allow access to the
GPIO pins)
????????????? - "sudo" (allow root access)
????????????? - "video" group (allow diagnostic
permissions to the GPU)
???????????????? sudo usermod -G
audio,dialout,gpio,sudo,video
--
As far as killing direwolf, control-c should be fine as
well as using "kill" but don't use the -HUP signal.?
When you kill Direwolf and the serial port is no longer
available, try running "ps aux | grep modem" and tell us
if NetworkManager's "modem-manager" is running.
--David
KI6ZHD
On 02/27/2017 09:37 AM, 'Nick
B.' nick@...
[direwolf_packet] wrote:
?
Hope you don't mind if I join in with this Tim as I'm
watching this with interest. I have similar problems
trying to get GPIO PTT and DCD working with the
correct permissions. Despite being able to write to
GPIO as my normal user, Direwolf always wants a sudo
password.
I haven't tried USB serial PTT yet but I may well do
and see if I get a similar result to you.
Nick.
?
I'm always game for learning more, thanks for
diving in with some help.?
Here are the results of the commands:
kd9dcs@bluetracker:~
$ who
kd9dcs ? :0 ? ? ? ?
? 2017-02-26 17:51 (:0)
kd9dcs ? pts/0 ? ? ?
?2017-02-27 05:34 (192.168.2.10)
kd9dcs@bluetracker:~ $ groups
pi adm dialout cdrom sudo audio video
plugdev games users input netdev gpio i2c
spi
kd9dcs@bluetracker:~ $ ls -al /dev/PTT
lrwxrwxrwx 1 root root 7 Feb 26 17:51
/dev/PTT -> ttyUSB0
Thanks again for looking at this
Tim ...
|
Nick G4IRX