Re: Problems compiling Direwolf 1.7 on RPi OS10
David,
It's not really a RPi problem, it's related to apt decisions.
Some reading on Stackexchange -
- shows the problem is not new and not restricted to the RPi. Taken
from the page (above), the following quote leads into a workaround -
sudo apt install --no-install-recommends git-all - but I seriously
think few end users would need anything but git, and can safely
leave git-all alone.
<quote>
git-all recommends git-daemon-run, and that depends on runit, which
conflicts with systemd, or rather systemd-sysv. This ends up causing
a conflict with GNOME, and apt chooses to remove the conflicting
packages.
To avoid this, there are two solutions:
install git-all without the recommended packages:
sudo apt install --no-install-recommends git-all
avoid installing git-all, and only install the packages you need:
sudo apt install git
</quote>
HTH
Ray vk2tv
On 20/9/21 1:01 am, David Ranch wrote:
toggle quoted message
Show quoted text
Hello Roger, Ray,
I have NO idea why the "git-all" meta package would have
dependencies on Xwindows packages but I would say that if
installing it breaks your GUI setup, that's VERY broken.? If
you're willing to do the work, please file a Raspberry Pi bug
about it:
??
Roger:? One thing:? you NO longer need to remove PulseAudio from
your Raspberry Pi system.? That is a leftover from that older
Direwolf when PulseAudio had issues on the Rpi.? I would recommend
to NOT remove it if you're using a desktop enabled Rpi.
--David
KI6ZHD
Roger, all,
I know it's not on a RPi but for my Buster desktop, selecting
git-all marks a disturbing number of packages for removal. Not
insignificant are lightdm, network manager,
network-manager-gnome, systemd-sysv, task-xfce-desktop, and
numerous desktop tools that may/may not be on YOUR required
list. Perhaps some of those don't apply for the RPi but from
memory, lightdm is used as the desktop manager and you wouldn't
want it missing in action :) I have previously compiled Direwolf
on both model B and RPi4 using just the basic git as the basis
for the process.
Given that the git package - apt install git - is all that is
required to handle git for Direwolf (and every other git based
programs I've used) I suggest you remove and purge git-all, and
install git. Naturally there are a few other dependencies? such
as cmake, et al, but cmake probably marks those for you for
installation.
Regards
Ray vk2tv
On 19/9/21 10:17 am, Roger wrote:
David:
hello, Thank you for responding.? Yes, exactly.? I burn a new
micro-SD card with Raspbian OS10, run through the set up &
reboot, no problem. Then remove pulseaudio & reboot, no
problem. Then run the command sudo apt install git-all and
reboot and the Desktop GUI disappears. Then, going through the
raspi-config set-up for boot into GUI does no good. I've done
this 6-times sequentially, with new cards and two different
RPis thinking I miss-keyed or some other goof.? A friend tried
it with different cards, different RPi, different network and
the results were the same. Desktop GUI disappears and no way
to bring it back.
I will try sudo apt install git to see if it works.
Thank you
Regards;
Roger, N1XP
On 9/18/21 1:01 PM, David Ranch wrote:
Are you saying that if you start with a stock Raspberry Pi
OS image with the desktop which works as expected, one you
install git, the desktop UI crashes and no longer works?!? I
don't see how that's possible though I would also say just
use "sudo apt install git" and not use the "git-all" meta
package that is probably bringing in a lot of other packages
you don't need.
--David
KI6ZHD
On 09/18/2021 09:52 AM, Roger wrote:
The problem isn't really with
Direwolf--?? When I install git? (sudo apt install
git-all) the RPI Desktop GUI is lost after reboot.
Re-configuring the raspi-config settings do not restart
the desktop.? Any suggestions on a different method of
compiling on RPi without loosing the desktop?
Roger, N1XP
|
Re: Problems compiling Direwolf 1.7 on RPi OS10
Hello Roger, Ray,
I have NO idea why the "git-all" meta package would have
dependencies on Xwindows packages but I would say that if installing
it breaks your GUI setup, that's VERY broken.? If you're willing to
do the work, please file a Raspberry Pi bug about it:
??
Roger:? One thing:? you NO longer need to remove PulseAudio from
your Raspberry Pi system.? That is a leftover from that older
Direwolf when PulseAudio had issues on the Rpi.? I would recommend
to NOT remove it if you're using a desktop enabled Rpi.
--David
KI6ZHD
toggle quoted message
Show quoted text
Roger, all,
I know it's not on a RPi but for my Buster desktop, selecting
git-all marks a disturbing number of packages for removal. Not
insignificant are lightdm, network manager, network-manager-gnome,
systemd-sysv, task-xfce-desktop, and numerous desktop tools that
may/may not be on YOUR required list. Perhaps some of those don't
apply for the RPi but from memory, lightdm is used as the desktop
manager and you wouldn't want it missing in action :) I have
previously compiled Direwolf on both model B and RPi4 using just
the basic git as the basis for the process.
Given that the git package - apt install git - is all that is
required to handle git for Direwolf (and every other git based
programs I've used) I suggest you remove and purge git-all, and
install git. Naturally there are a few other dependencies? such as
cmake, et al, but cmake probably marks those for you for
installation.
Regards
Ray vk2tv
On 19/9/21 10:17 am, Roger wrote:
David:
hello, Thank you for responding.? Yes, exactly.? I burn a new
micro-SD card with Raspbian OS10, run through the set up &
reboot, no problem. Then remove pulseaudio & reboot, no
problem. Then run the command sudo apt install git-all and
reboot and the Desktop GUI disappears. Then, going through the
raspi-config set-up for boot into GUI does no good. I've done
this 6-times sequentially, with new cards and two different RPis
thinking I miss-keyed or some other goof.? A friend tried it
with different cards, different RPi, different network and the
results were the same. Desktop GUI disappears and no way to
bring it back.
I will try sudo apt install git to see if it works.
Thank you
Regards;
Roger, N1XP
On 9/18/21 1:01 PM, David Ranch wrote:
Are you saying that if you start with a stock Raspberry Pi OS
image with the desktop which works as expected, one you
install git, the desktop UI crashes and no longer works?!? I
don't see how that's possible though I would also say just use
"sudo apt install git" and not use the "git-all" meta package
that is probably bringing in a lot of other packages you don't
need.
--David
KI6ZHD
On 09/18/2021 09:52 AM, Roger wrote:
The problem isn't really with
Direwolf--?? When I install git? (sudo apt install git-all)
the RPI Desktop GUI is lost after reboot. Re-configuring the
raspi-config settings do not restart the desktop.? Any
suggestions on a different method of compiling on RPi
without loosing the desktop?
Roger, N1XP
|
Re: Problems compiling Direwolf 1.7 on RPi OS10
Roger, all,
I know it's not on a RPi but for my Buster desktop, selecting git-all marks a disturbing number of packages for removal. Not insignificant are lightdm, network manager, network-manager-gnome, systemd-sysv, task-xfce-desktop, and numerous desktop tools that may/may not be on YOUR required list. Perhaps some of those don't apply for the RPi but from memory, lightdm is used as the desktop manager and you wouldn't want it missing in action :) I have previously compiled Direwolf on both model B and RPi4 using just the basic git as the basis for the process.
Given that the git package - apt install git - is all that is required to handle git for Direwolf (and every other git based programs I've used) I suggest you remove and purge git-all, and install git. Naturally there are a few other dependencies? such as cmake, et al, but cmake probably marks those for you for installation.
Regards
Ray vk2tv
toggle quoted message
Show quoted text
On 19/9/21 10:17 am, Roger wrote: David:
hello, Thank you for responding.? Yes, exactly.? I burn a new micro-SD card with Raspbian OS10, run through the set up & reboot, no problem. Then remove pulseaudio & reboot, no problem. Then run the command sudo apt install git-all and reboot and the Desktop GUI disappears. Then, going through the raspi-config set-up for boot into GUI does no good. I've done this 6-times sequentially, with new cards and two different RPis thinking I miss-keyed or some other goof.? A friend tried it with different cards, different RPi, different network and the results were the same. Desktop GUI disappears and no way to bring it back.
I will try sudo apt install git to see if it works.
Thank you
Regards;
Roger, N1XP
On 9/18/21 1:01 PM, David Ranch wrote:
Are you saying that if you start with a stock Raspberry Pi OS image with the desktop which works as expected, one you install git, the desktop UI crashes and no longer works?!? I don't see how that's possible though I would also say just use "sudo apt install git" and not use the "git-all" meta package that is probably bringing in a lot of other packages you don't need.
--David
KI6ZHD
On 09/18/2021 09:52 AM, Roger wrote:
The problem isn't really with Direwolf--?? When I install git? (sudo apt install git-all) the RPI Desktop GUI is lost after reboot. Re-configuring the raspi-config settings do not restart the desktop.? Any suggestions on a different method of compiling on RPi without loosing the desktop?
Roger, N1XP
|
Re: Problems compiling Direwolf 1.7 on RPi OS10
David:
hello, Thank you for responding.? Yes, exactly.? I burn a new
micro-SD card with Raspbian OS10, run through the set up &
reboot, no problem. Then remove pulseaudio & reboot, no problem.
Then run the command sudo apt install git-all and reboot and the
Desktop GUI disappears. Then, going through the? raspi-config set-up
for boot into GUI does no good. I've done this 6-times sequentially,
with new cards and two different RPis thinking I miss-keyed or some
other goof.? A friend tried it with different cards, different RPi,
different network and the results were the same. Desktop GUI
disappears and no way to bring it back.
I will try sudo apt install git to see if it works.
Thank you
Regards;
Roger, N1XP
On 9/18/21 1:01 PM, David Ranch wrote:
toggle quoted message
Show quoted text
Are you saying that if you start with a stock
Raspberry Pi OS image with the desktop which works as expected,
one you install git, the desktop UI crashes and no longer
works?!? I don't see how that's possible though I would also say
just use "sudo apt install git" and not use the "git-all" meta
package that is probably bringing in a lot of other packages you
don't need.
--David
KI6ZHD
On 09/18/2021 09:52 AM, Roger wrote:
The problem isn't really with Direwolf--?? When I
install git? (sudo apt install git-all) the RPI Desktop GUI is
lost after reboot. Re-configuring the raspi-config settings do
not restart the desktop.? Any suggestions on a different method
of compiling on RPi without loosing the desktop?
Roger, N1XP
|
Re: Problems compiling Direwolf 1.7 on RPi OS10
Are you saying that if you start with a stock
Raspberry Pi OS image with the desktop which works as expected,
one you install git, the desktop UI crashes and no longer works?!?
I don't see how that's possible though I would also say just use
"sudo apt install git" and not use the "git-all" meta package that
is probably bringing in a lot of other packages you don't need.
--David
KI6ZHD
On 09/18/2021 09:52 AM, Roger wrote:
toggle quoted message
Show quoted text
The problem isn't really with Direwolf--?? When I
install git? (sudo apt install git-all) the RPI Desktop GUI is
lost after reboot. Re-configuring the raspi-config settings do not
restart the desktop.? Any suggestions on a different method of
compiling on RPi without loosing the desktop?
Roger, N1XP
|
Problems compiling Direwolf 1.7 on RPi OS10
The problem isn't really with Direwolf--?? When I install git? (sudo apt install git-all) the RPI Desktop GUI is lost after reboot. Re-configuring the raspi-config settings do not restart the desktop.? Any suggestions on a different method of compiling on RPi without loosing the desktop?
Roger, N1XP
|
Re: Sound card changed from Card 2 to Card 1
iirc, this disables hdmi audio in /boot/config.txt
dtparam=audio=off
also "cat /proc/asound/cards" for the list of audio devices.
If you're headless, also put "tvservice -o" in /etc/rc.local ? to
disable hdmi video, save a few milliamps.
cool,
-craig
KM6LYW
On 9/16/21 5:21 AM, Rob Giuliano via
groups.io wrote:
toggle quoted message
Show quoted text
The below text works with
all pre Pi4 models.? For the pi 4, with 2 HDMI outputs, I
believe you put a colon between:
# Force HDMI ON for HDMI0
hdmi_force_hotplug=1:0
# Set video output to monitor and not TV
hdmi_group=2:0
# Set HDMI resolution 1920x1080
hdmi_mode=82:0
# Set HDMI sound enabled
hdmi_drive=2:0
I use this when run
monitorless.? When I connect a monitor for something
quick, there is much less hassle with settings like
resolution, etc.? I have not tried this for the audio part
though.
On Thursday, September 16, 2021, 08:00:55 AM EDT, Rob
Giuliano <kb8rco@...> wrote:
You can force Raspian to always
enable the HDMI port (even if no monitor/cable is
attached).
This may "even the score", in that
the HDMI device should always be enabled and
therefore take the lower number.
From a forum on Raspian:
Add these two lines to /boot/config.txt
and reboot:
hdmi_force_hotplug=1
hdmi_drive=2
hdmi_force_hotplug=1hdmi_drive=2 sets the Raspbmc
to normal HDMI mode (Sound will be sent if
supported and enabled). Without this line,
the Raspian
would switch to DVI (with no audio) mode
by default.
Worth a try!
On Thursday, September 16, 2021, 06:21:10 AM
EDT, Don Rolph <don.rolph@...>
wrote:
I. have also observed this
behavior: ?the sound on HDMI gets
configured as a sound device, and it seems
to take the lower number.
So, I always configure my system
level setup including network using a
local monitor and configure Direwolf
over an ssh connection.
I believe aplay -l will identify the
various sound?cards present.
Greetings,
?
After
doing an update on a Raspberry
Pi , I found Direwolf could not
find my soundcard (Fe-Pi). It
turned out that the sound card
is now Card 1 rather than Card
?2. I don’t even know what card
1 was. Thankfully, there was no
hair pulling or long searching
to find the problem and change
the direwolf.conf to reflect the
new card number. However, that
is less than ideal. Reserving a
card number for this particular
device seems practical, or,
configuring Direwolf to find my
device regardless of the card
number. The first actually seems
possible.
?
On
this system, an HDMI monitor is
connected and once it is
removed, I suspect the
card number may once again
change and since Direwolf will
look for card 1, it will not
work. I have not verified this.
?
In
my searches:
I
found a reference to editing
alsa-base.conf but that looks
depreciated permanently.
I
found a reference, from 2015, to
editing alsa.conf in
/usr/share/alsa and changing
default.ctl.card and
default.pcm.card to card 1. The
question I have is how does this
point to my specific sound card?
?
Am
I barking up the right tree? Any
pointers? Is there a better way?
?
Thank
you!
?
Best
regards,
Fred
N7FMH
?
?
pi@RPiZ-DWLiFe:~ $ aplay -l
**** List of PLAYBACK
Hardware Devices ****
card 0: b1 [bcm2835 HDMI 1],
device 0: bcm2835 HDMI 1
[bcm2835 HDMI 1]
? Subdevices: 8/8
? Subdevice #0: subdevice #0
? Subdevice #1: subdevice #1
? Subdevice #2: subdevice #2
? Subdevice #3: subdevice #3
? Subdevice #4: subdevice #4
? Subdevice #5: subdevice #5
? Subdevice #6: subdevice #6
? Subdevice #7: subdevice #7
card 1: Audio [Fe-Pi Audio],
device 0: Fe-Pi HiFi sgtl5000-0
[Fe-Pi HiFi sgtl5000-0]
? Subdevices: 0/1
? Subdevice #0: subdevice #0
pi@RPiZ-DWLiFe:~ $
?
?
|
|
This email has been checked for viruses
by Avast antivirus
software.
|
--
|
Re: Sound card changed from Card 2 to Card 1
The below text works with all pre Pi4 models.? For the pi 4, with 2 HDMI outputs, I believe you put a colon between:
# Force HDMI ON for HDMI0
hdmi_force_hotplug=1:0
# Set video output to monitor and not TV
hdmi_group=2:0
# Set HDMI resolution 1920x1080
hdmi_mode=82:0
# Set HDMI sound enabled
hdmi_drive=2:0
I use this when run monitorless.? When I connect a monitor for something quick, there is much less hassle with settings like resolution, etc.? I have not tried this for the audio part though.
On Thursday, September 16, 2021, 08:00:55 AM EDT, Rob Giuliano <kb8rco@...> wrote:
You can force Raspian to always enable the HDMI port (even if no monitor/cable is attached). This may "even the score", in that the HDMI device should always be enabled and therefore take the lower number.
From a forum on Raspian:
Add these two lines to /boot/config.txt and reboot: hdmi_force_hotplug=1
hdmi_drive=2
hdmi_force_hotplug=1hdmi_drive=2 sets the Raspbmc to normal HDMI mode (Sound
will be sent if supported and enabled). Without this line, the Raspian
would switch to DVI (with no audio) mode by default.
Worth a try!
On Thursday, September 16, 2021, 06:21:10 AM EDT, Don Rolph <don.rolph@...> wrote:
I. have also observed this behavior: ?the sound on HDMI gets configured as a sound device, and it seems to take the lower number.
So, I always configure my system level setup including network using a local monitor and configure Direwolf over an ssh connection.
I believe aplay -l will identify the various sound?cards present. Greetings, ? After doing an update on a Raspberry Pi , I found Direwolf could not find my soundcard (Fe-Pi). It turned out that the sound card is now Card 1 rather than Card ?2. I don’t even know what card 1 was. Thankfully, there was no hair pulling or long searching to find the problem and change the direwolf.conf to reflect the new card number. However, that is less than ideal. Reserving a card number for this particular device seems practical, or, configuring Direwolf to find my device regardless of the card number. The first actually seems possible. ? On this system, an HDMI monitor is connected and once it is removed, I suspect the card number may once again change and since Direwolf will look for card 1, it will not work. I have not verified this. ? In my searches: I found a reference to editing alsa-base.conf but that looks depreciated permanently. I found a reference, from 2015, to editing alsa.conf in /usr/share/alsa and changing default.ctl.card and default.pcm.card to card 1. The question I have is how does this point to my specific sound card? ? Am I barking up the right tree? Any pointers? Is there a better way? ? Thank you! ? Best regards, Fred N7FMH ? ? pi@RPiZ-DWLiFe:~ $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1] ? Subdevices: 8/8 ? Subdevice #0: subdevice #0 ? Subdevice #1: subdevice #1 ? Subdevice #2: subdevice #2 ? Subdevice #3: subdevice #3 ? Subdevice #4: subdevice #4 ? Subdevice #5: subdevice #5 ? Subdevice #6: subdevice #6 ? Subdevice #7: subdevice #7 card 1: Audio [Fe-Pi Audio], device 0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0] ? Subdevices: 0/1 ? Subdevice #0: subdevice #0 pi@RPiZ-DWLiFe:~ $ ? ?
| This email has been checked for viruses by Avast antivirus software.
|
--
|
Re: Sound card changed from Card 2 to Card 1
You can force Raspian to always enable the HDMI port (even if no monitor/cable is attached). This may "even the score", in that the HDMI device should always be enabled and therefore take the lower number.
From a forum on Raspian:
Add these two lines to /boot/config.txt and reboot: hdmi_force_hotplug=1
hdmi_drive=2
hdmi_force_hotplug=1hdmi_drive=2 sets the Raspbmc to normal HDMI mode (Sound
will be sent if supported and enabled). Without this line, the Raspian
would switch to DVI (with no audio) mode by default.
Worth a try!
On Thursday, September 16, 2021, 06:21:10 AM EDT, Don Rolph <don.rolph@...> wrote:
I. have also observed this behavior: ?the sound on HDMI gets configured as a sound device, and it seems to take the lower number.
So, I always configure my system level setup including network using a local monitor and configure Direwolf over an ssh connection.
I believe aplay -l will identify the various sound?cards present. Greetings, ? After doing an update on a Raspberry Pi , I found Direwolf could not find my soundcard (Fe-Pi). It turned out that the sound card is now Card 1 rather than Card ?2. I don’t even know what card 1 was. Thankfully, there was no hair pulling or long searching to find the problem and change the direwolf.conf to reflect the new card number. However, that is less than ideal. Reserving a card number for this particular device seems practical, or, configuring Direwolf to find my device regardless of the card number. The first actually seems possible. ? On this system, an HDMI monitor is connected and once it is removed, I suspect the card number may once again change and since Direwolf will look for card 1, it will not work. I have not verified this. ? In my searches: I found a reference to editing alsa-base.conf but that looks depreciated permanently. I found a reference, from 2015, to editing alsa.conf in /usr/share/alsa and changing default.ctl.card and default.pcm.card to card 1. The question I have is how does this point to my specific sound card? ? Am I barking up the right tree? Any pointers? Is there a better way? ? Thank you! ? Best regards, Fred N7FMH ? ? pi@RPiZ-DWLiFe:~ $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1] ? Subdevices: 8/8 ? Subdevice #0: subdevice #0 ? Subdevice #1: subdevice #1 ? Subdevice #2: subdevice #2 ? Subdevice #3: subdevice #3 ? Subdevice #4: subdevice #4 ? Subdevice #5: subdevice #5 ? Subdevice #6: subdevice #6 ? Subdevice #7: subdevice #7 card 1: Audio [Fe-Pi Audio], device 0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0] ? Subdevices: 0/1 ? Subdevice #0: subdevice #0 pi@RPiZ-DWLiFe:~ $ ? ?
| This email has been checked for viruses by Avast antivirus software.
|
--
|
Re: Sound card changed from Card 2 to Card 1
I. have also observed this behavior: ?the sound on HDMI gets configured as a sound device, and it seems to take the lower number.
So, I always configure my system level setup including network using a local monitor and configure Direwolf over an ssh connection.
I believe aplay -l will identify the various sound?cards present.
Greetings, ? After doing an update on a Raspberry Pi , I found Direwolf could not find my soundcard (Fe-Pi). It turned out that the sound card is now Card 1 rather than Card ?2. I don’t even know what card 1 was. Thankfully, there was no hair pulling or long searching to find the problem and change the direwolf.conf to reflect the new card number. However, that is less than ideal. Reserving a card number for this particular device seems practical, or, configuring Direwolf to find my device regardless of the card number. The first actually seems possible. ? On this system, an HDMI monitor is connected and once it is removed, I suspect the card number may once again change and since Direwolf will look for card 1, it will not work. I have not verified this. ? In my searches: I found a reference to editing alsa-base.conf but that looks depreciated permanently. I found a reference, from 2015, to editing alsa.conf in /usr/share/alsa and changing default.ctl.card and default.pcm.card to card 1. The question I have is how does this point to my specific sound card? ? Am I barking up the right tree? Any pointers? Is there a better way? ? Thank you! ? Best regards, Fred N7FMH ? ? pi@RPiZ-DWLiFe:~ $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1] ? Subdevices: 8/8 ? Subdevice #0: subdevice #0 ? Subdevice #1: subdevice #1 ? Subdevice #2: subdevice #2 ? Subdevice #3: subdevice #3 ? Subdevice #4: subdevice #4 ? Subdevice #5: subdevice #5 ? Subdevice #6: subdevice #6 ? Subdevice #7: subdevice #7 card 1: Audio [Fe-Pi Audio], device 0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0] ? Subdevices: 0/1 ? Subdevice #0: subdevice #0 pi@RPiZ-DWLiFe:~ $ ? ?
| This email has been checked for viruses by Avast antivirus software.
|
|
Re: Sound card changed from Card 2 to Card 1
I can confirm that connecting an HDMI device will add a sound card
to the system.? Where it will end up in the numbering scheme is
anyone's guess.? In my case it changed the USB dongle's ID, causing
Direwolf exit on startup for not having an appropriate audio device
to talk to.? This was on Raspbian Buster, with no special audio
system configuration changes.
Greg? KO6TH
David Ranch wrote:
toggle quoted message
Show quoted text
Hello Fred,
I've never seen the built-in Broadcom (bcm2835) sound device NOT
being device #0 but depending on your unique setup, maybe plugging
in HDMI later, etc, it could happen.? Anyway, the answer you seek
depends if you want to keep the onboard sound working or you want
to disable it.? This URL gives you a few options:
??
--David
KI6ZHD
On 09/15/2021 06:29 PM, Fred
Hillhouse wrote:
Greetings,
?
After
doing an update on a Raspberry Pi , I found Direwolf could
not find my soundcard (Fe-Pi). It turned out that the
sound card is now Card 1 rather than Card ?2. I don’t even
know what card 1 was. Thankfully, there was no hair
pulling or long searching to find the problem and change
the direwolf.conf to reflect the new card number. However,
that is less than ideal. Reserving a card number for this
particular device seems practical, or, configuring
Direwolf to find my device regardless of the card number.
The first actually seems possible.
?
On
this system, an HDMI monitor is connected and once it is
removed, I suspect the card number may once again
change and since Direwolf will look for card 1, it will
not work. I have not verified this.
?
In
my searches:
I
found a reference to editing alsa-base.conf but that looks
depreciated permanently.
I
found a reference, from 2015, to editing alsa.conf in
/usr/share/alsa and changing default.ctl.card and
default.pcm.card to card 1. The question I have is how
does this point to my specific sound card?
?
Am
I barking up the right tree? Any pointers? Is there a
better way?
?
Thank
you!
?
Best
regards,
Fred
N7FMH
?
?
pi@RPiZ-DWLiFe:~ $ aplay -l
**** List of PLAYBACK Hardware
Devices ****
card 0: b1 [bcm2835 HDMI 1],
device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
? Subdevices: 8/8
? Subdevice #0: subdevice #0
? Subdevice #1: subdevice #1
? Subdevice #2: subdevice #2
? Subdevice #3: subdevice #3
? Subdevice #4: subdevice #4
? Subdevice #5: subdevice #5
? Subdevice #6: subdevice #6
? Subdevice #7: subdevice #7
card 1: Audio [Fe-Pi Audio],
device 0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0]
? Subdevices: 0/1
? Subdevice #0: subdevice #0
pi@RPiZ-DWLiFe:~ $
?
?
|
|
This
email has been checked for viruses by Avast
antivirus software.
|
|
Re: Sound card changed from Card 2 to Card 1
Hello Fred,
I've never seen the built-in Broadcom (bcm2835) sound device NOT
being device #0 but depending on your unique setup, maybe plugging
in HDMI later, etc, it could happen.? Anyway, the answer you seek
depends if you want to keep the onboard sound working or you want to
disable it.? This URL gives you a few options:
??
--David
KI6ZHD
On 09/15/2021 06:29 PM, Fred Hillhouse
wrote:
toggle quoted message
Show quoted text
Greetings,
?
After
doing an update on a Raspberry Pi , I found Direwolf could
not find my soundcard (Fe-Pi). It turned out that the sound
card is now Card 1 rather than Card ?2. I don’t even know
what card 1 was. Thankfully, there was no hair pulling or
long searching to find the problem and change the
direwolf.conf to reflect the new card number. However, that
is less than ideal. Reserving a card number for this
particular device seems practical, or, configuring Direwolf
to find my device regardless of the card number. The first
actually seems possible.
?
On
this system, an HDMI monitor is connected and once it is
removed, I suspect the card number may once again
change and since Direwolf will look for card 1, it will not
work. I have not verified this.
?
In
my searches:
I
found a reference to editing alsa-base.conf but that looks
depreciated permanently.
I
found a reference, from 2015, to editing alsa.conf in
/usr/share/alsa and changing default.ctl.card and
default.pcm.card to card 1. The question I have is how does
this point to my specific sound card?
?
Am
I barking up the right tree? Any pointers? Is there a better
way?
?
Thank
you!
?
Best
regards,
Fred
N7FMH
?
?
pi@RPiZ-DWLiFe:~ $ aplay -l
**** List of PLAYBACK Hardware
Devices ****
card 0: b1 [bcm2835 HDMI 1], device
0: bcm2835 HDMI 1 [bcm2835 HDMI 1]
? Subdevices: 8/8
? Subdevice #0: subdevice #0
? Subdevice #1: subdevice #1
? Subdevice #2: subdevice #2
? Subdevice #3: subdevice #3
? Subdevice #4: subdevice #4
? Subdevice #5: subdevice #5
? Subdevice #6: subdevice #6
? Subdevice #7: subdevice #7
card 1: Audio [Fe-Pi Audio], device
0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0]
? Subdevices: 0/1
? Subdevice #0: subdevice #0
pi@RPiZ-DWLiFe:~ $
?
?
|
|
This
email has been checked for viruses by Avast
antivirus software.
|
|
Sound card changed from Card 2 to Card 1
Greetings, ? After doing an update on a Raspberry Pi , I found Direwolf could not find my soundcard (Fe-Pi). It turned out that the sound card is now Card 1 rather than Card ?2. I don’t even know what card 1 was. Thankfully, there was no hair pulling or long searching to find the problem and change the direwolf.conf to reflect the new card number. However, that is less than ideal. Reserving a card number for this particular device seems practical, or, configuring Direwolf to find my device regardless of the card number. The first actually seems possible. ? On this system, an HDMI monitor is connected and once it is removed, I suspect the card number may once again change and since Direwolf will look for card 1, it will not work. I have not verified this. ? In my searches: I found a reference to editing alsa-base.conf but that looks depreciated permanently. I found a reference, from 2015, to editing alsa.conf in /usr/share/alsa and changing default.ctl.card and default.pcm.card to card 1. The question I have is how does this point to my specific sound card? ? Am I barking up the right tree? Any pointers? Is there a better way? ? Thank you! ? Best regards, Fred N7FMH ? ? pi@RPiZ-DWLiFe:~ $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1] ? Subdevices: 8/8 ? Subdevice #0: subdevice #0 ? Subdevice #1: subdevice #1 ? Subdevice #2: subdevice #2 ? Subdevice #3: subdevice #3 ? Subdevice #4: subdevice #4 ? Subdevice #5: subdevice #5 ? Subdevice #6: subdevice #6 ? Subdevice #7: subdevice #7 card 1: Audio [Fe-Pi Audio], device 0: Fe-Pi HiFi sgtl5000-0 [Fe-Pi HiFi sgtl5000-0] ? Subdevices: 0/1 ? Subdevice #0: subdevice #0 pi@RPiZ-DWLiFe:~ $ ? ?
| This email has been checked for viruses by Avast antivirus software.
|
|
Re: Apparent problem with GPSD support in Direwolf 1.6
Hello Don,
A few other tests to try:
1. gpsd running and puck connected; In direwolf.conf GPSD
disabled but have cgps or xgps running in another window which
will enable the GPS puck and make sure it has a lock.? How are the
resulting transmitted packets sounding?
2. no transmitter:
?? - disable gpsd
?? - turn off the radio and connect the audio output from the
Direwolf soundcard to a speaker
?? - Send a beacon from Direwolf and see how it sounds through the
speaker
?? - Enable gpsd and send a beacon from
Direwolf and see how it sounds through the speaker?
--David
KI6ZHD
On 09/13/2021 03:33 PM, Don Rolph
wrote:
toggle quoted message
Show quoted text
Did a retest of one configuration.
- enable GPSD in direwolf.conf
- kill gpsd?
- unplug gps
Start direwolf:? all works.? Log messages state that there
is no gps data.
Now plug in gps puck.
- gpsd restarts
- gps data starts flowing
-? direwolf fails to produce good packets.
Since simply having gpsd running with a puck plugged in
does not cause a failure, this would seem to suggest that the
issue is the polling of gpsd by direwolf which is causing the
trouble:? when there is no gpsd to poll. everything seems to
work.
Thoughts?
-?
See below.
System works fine with gpsd running and puck
connected.? In direwolf.conf GPSD disabled.
System works fine with gpsd running and no puck
connected.?
In direwolf.conf GPSD disabled.
System works fine with gpsd not running and no puck
connected.??
In direwolf.conf GPSD disabled.
System fails with puck connected, gpsd running and
GPSD enabled in direwolf.conf.
Btw... as an experiment, try the following:
?? 1. Have your receiving radio on 144.390
check?
?? 2. disable gpsd
check?
?? 3. disconnect your GPS
check?
?? 4. open up the receive squelch and turn up the
volume so you can hear the FM static
check?
?? 5. connect the GPS.? Did you hear any difference in
the FM static?? You might not as you really need to be
listening when there is is some other active
transmitter on frequency.?
?? 6. enable gpsd.? Did you hear any difference in the
FM static?? Did you hear any difference in the FM
static?? You might not as you really need to be
listening when there is is some other active
transmitter on frequency.? Maybe try QSYing the radio
to an active analog FM repeater with an ongoing
conversation that's near 144.390.
no change in statuic?
Btw, I had a very similar "receive sensitivity" issue
on an APRS setup when using an Ambicom USB GPS:
??
I had to stop using that GPS due to the various
interference it would create on 144.390.
--David
KI6ZHD
On 09/13/2021 08:25 AM, David Ranch wrote:
Hello Don,
If GPSD is not enabled and I use
PBEACON and digipeating Direwolf is functioning,
packets are received?by a wide variety of
stations.? A capture of the sound is below as
nogpsd.m4a.
This sounds ok though I'm guessing your using a
Kenwood radio right?? Why am I hearing a beep before
the AFSK-1200bps packet and then another beep after
the packet.? That should NOT be happening.
If GPSD is enabled, and I use PBEACON?and
digipeating, Direwolf packets are in general
not?decoded by any system. ?(sometimes one
gets lucky but success is at best
intermittent).? A capture of the sound is
attached as gpsd.m4a.
To me, it sounds like you're missing the begining of
the packet here.? Have you 100% opened the squelch
on your radio?? This is how Direwolf is intended to
run.?? If this turns out to be your issue, maybe
starting up gpsd and thus powering up your GPS is
creating some interference on the VHF receiver and
it's hurting your current squelch setting.? Again..
open it up 100%.?? Also.. the Kenwood beeps are
there which should NOT be there.
- Rasperry PI 3
- Raspian?with Pulse?audio removed per
Raspberry instructions
- Direwolf 1.6
Please note that the recommendation to remove
PulseAudio is no longer required as this only
applied to older versions of Raspberry Pi OS.? There
is an open Github issue on this:
???
Your existing setup should work perfectly fine with
it removed but of you're using Xwindows on this
Raspberry Pi and want to use say system sounds via a
different soundcard, things probably won't work.
--David
KI6ZHD
--
--
|
Re: OK I seem to be homing in on the problem
I have personally witnessed a USB powered GPS module creating RFI.? I discovered that my distortion (in that instance) was eliminated when I pulled out the USB plug while the GPS was enabled.? I have since found a GPS module with a shorter cord lead that works much better (without the added RFI).
Sam - K04HBY
have used cgps to confirm that gps puck is working as expecyed.? There is a fix, and direwolf is reading the fix,
Having puck present or not does not change direwolf issues when GPSD is enabled.
Hello John,
RFI is a possiblity, though I would think the GPS
electronics are active whenever it is attached to the USB
port.?
That depends on the GPS and how gpsd is started:
man gpsd:
--
?????? -n
?????????? Don?t wait for a client to connect before polling
whatever GPS is associated with it. Some RS232 GPSes wait in a
standby mode (drawing less power) when the
?????????? host machine is not asserting DTR, and some cellphone and
handheld embedded GPSes have similar behaviors. Accordingly, waiting
for a watch request to open
?????????? the device may save battery power. (This capability is
rare in consumer-grade devices and nonexistent in USB GPSes which
lack a DTR line.)
--
I've found with at least the GlobalSat BU-353-S4 USB GPS unit on a
Raspberry Pi, it won't fully activate and start determining it's
location until a gps client (cgps, xgps, direwolf, etc.) connects to
the gpsd daemon.
--David
KI6ZHD
--
|
Re: Apparent problem with GPSD support in Direwolf 1.6
The no gpsd packet is successfully decoded by nearly all systems.
As you note the gpsd recording is stranger: the sound is typically quite distorted.
And this seems to occur as soon Direwolf has a gpsd daemon which it starts connecting to.
toggle quoted message
Show quoted text
On Sep 13, 2021, at 8:34 PM, WB2OSZ <wb2osz@...> wrote:
?This is very strange. Let's start with no nogpsd recording.?? The first thing we notice is a beep at the beginning and end. <dummyfile.0.part> The beep near the beginning has a frequency of about 782 Hz.? <dummyfile.1.part> It looks like the amplitude might be so high that it is clipping and distorting the signal. The beep near the end is very strange. <dummyfile.2.part> The fundamental frequency is about 440 Hz with very strong harmonics. The packet has amplitude fluctuating all over. <dummyfile.3.part> The with gpsd recording is even stranger but let's get the no gps case working correctly first. Where is this coming from??? Is the recording directly from the soundcard or after a transmitter and receiver?
|
Re: Apparent problem with GPSD support in Direwolf 1.6
The center portion is the only portion of the packet. ?I am recording from a microphone so I have ambient noise.
toggle quoted message
Show quoted text
On Sep 13, 2021, at 8:34 PM, WB2OSZ <wb2osz@...> wrote:
?This is very strange. Let's start with no nogpsd recording.?? The first thing we notice is a beep at the beginning and end. <dummyfile.0.part> The beep near the beginning has a frequency of about 782 Hz.? <dummyfile.1.part> It looks like the amplitude might be so high that it is clipping and distorting the signal. The beep near the end is very strange. <dummyfile.2.part> The fundamental frequency is about 440 Hz with very strong harmonics. The packet has amplitude fluctuating all over. <dummyfile.3.part> The with gpsd recording is even stranger but let's get the no gps case working correctly first. Where is this coming from??? Is the recording directly from the soundcard or after a transmitter and receiver?
|
Re: Apparent problem with GPSD support in Direwolf 1.6
This is very strange. Let's start with no nogpsd recording.?? The first thing we notice is a beep at the beginning and end.  The beep near the beginning has a frequency of about 782 Hz.?  It looks like the amplitude might be so high that it is clipping and distorting the signal. The beep near the end is very strange.  The fundamental frequency is about 440 Hz with very strong harmonics. The packet has amplitude fluctuating all over.  The with gpsd recording is even stranger but let's get the no gps case working correctly first. Where is this coming from??? Is the recording directly from the soundcard or after a transmitter and receiver?
|
Re: Apparent problem with GPSD support in Direwolf 1.6
Did a retest of one configuration.
- enable GPSD in direwolf.conf
- kill gpsd?
- unplug gps
Start direwolf:? all works.? Log messages state that there is no gps data.
Now plug in gps puck.
- gpsd restarts
- gps data starts flowing
-? direwolf fails to produce good packets.
Since simply having gpsd running with a puck plugged in does not cause a failure, this would seem to suggest that the issue is the polling of gpsd by direwolf which is causing the trouble:? when there is no gpsd to poll. everything seems to work.
Thoughts?
-?
See below.
System works fine with gpsd running and puck connected.? In direwolf.conf GPSD disabled.
System works fine with gpsd running and no puck connected.?
In direwolf.conf GPSD disabled.
System works fine with gpsd not running and no puck connected.??
In direwolf.conf GPSD disabled.
System fails with puck connected, gpsd running and GPSD enabled in direwolf.conf.
Btw... as an experiment, try the following:
?? 1. Have your receiving radio on 144.390
check?
?? 2. disable gpsd
check?
?? 3. disconnect your GPS
check?
?? 4. open up the receive squelch and turn up the volume so you can
hear the FM static
check?
?? 5. connect the GPS.? Did you hear any difference in the FM
static?? You might not as you really need to be listening when there
is is some other active transmitter on frequency.?
?? 6. enable gpsd.? Did you hear any difference in the FM static??
Did you hear any difference in the FM static?? You might not as you
really need to be listening when there is is some other active
transmitter on frequency.? Maybe try QSYing the radio to an active
analog FM repeater with an ongoing conversation that's near 144.390.
no change in statuic?
Btw, I had a very similar "receive sensitivity" issue on an APRS
setup when using an Ambicom USB GPS:
??
I had to stop using that GPS due to the various interference it
would create on 144.390.
--David
KI6ZHD
On 09/13/2021 08:25 AM, David Ranch
wrote:
Hello Don,
If GPSD is not enabled and I use PBEACON and
digipeating Direwolf is functioning, packets are received?by a
wide variety of stations.? A capture of the sound is below as
nogpsd.m4a.
This sounds ok though I'm guessing your using a Kenwood radio
right?? Why am I hearing a beep before the AFSK-1200bps packet and
then another beep after the packet.? That should NOT be happening.
If GPSD is enabled, and I use PBEACON?and digipeating,
Direwolf packets are in general not?decoded by any system.
?(sometimes one gets lucky but success is at best
intermittent).? A capture of the sound is attached as
gpsd.m4a.
To me, it sounds like you're missing the begining of the packet
here.? Have you 100% opened the squelch on your radio?? This is
how Direwolf is intended to run.?? If this turns out to be your
issue, maybe starting up gpsd and thus powering up your GPS is
creating some interference on the VHF receiver and it's hurting
your current squelch setting.? Again.. open it up 100%.?? Also..
the Kenwood beeps are there which should NOT be there.
- Rasperry PI 3
- Raspian?with Pulse?audio removed per Raspberry
instructions
- Direwolf 1.6
Please note that the recommendation to remove PulseAudio is no
longer required as this only applied to older versions of
Raspberry Pi OS.? There is an open Github issue on this:
???
Your existing setup should work perfectly fine with it removed but
of you're using Xwindows on this Raspberry Pi and want to use say
system sounds via a different soundcard, things probably won't
work.
--David
KI6ZHD
--
|
Re: OK I seem to be homing in on the problem
have used cgps to confirm that gps puck is working as expecyed.? There is a fix, and direwolf is reading the fix,
Having puck present or not does not change direwolf issues when GPSD is enabled.
Hello John,
RFI is a possiblity, though I would think the GPS
electronics are active whenever it is attached to the USB
port.?
That depends on the GPS and how gpsd is started:
man gpsd:
--
?????? -n
?????????? Don?t wait for a client to connect before polling
whatever GPS is associated with it. Some RS232 GPSes wait in a
standby mode (drawing less power) when the
?????????? host machine is not asserting DTR, and some cellphone and
handheld embedded GPSes have similar behaviors. Accordingly, waiting
for a watch request to open
?????????? the device may save battery power. (This capability is
rare in consumer-grade devices and nonexistent in USB GPSes which
lack a DTR line.)
--
I've found with at least the GlobalSat BU-353-S4 USB GPS unit on a
Raspberry Pi, it won't fully activate and start determining it's
location until a gps client (cgps, xgps, direwolf, etc.) connects to
the gpsd daemon.
--David
KI6ZHD
|
Sam - KO4HBY