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
|
Re: Apparent problem with GPSD support in Direwolf 1.6
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: RFI issues with RPi3B+
Have the hats coming now, which I’m sure will wire fine. I’ll probably use the one that is similar to the Fe-Pi and around with the Audio injector for something else.
Also, found this USB audio adapter in one of my junk drawers that I totally forgot about. If picture can’t be posted here, it’s one of those USB audio adapters that has about a 4” USB cable, then has a volume dial on the adapter itself, plus buttons turn on/off the speaker or microphon independent. It’s working and is kind of cool because it’s another point to adjust volume (found it works well to use dongle knob to make fine adjustments), plus the button switches are pretty cool if you, say, want to turn off the digipeter but still have iGate running (or vice-versa). Found my RFI issue really wasn’t much of an issue anyway now that I’m connected to an outdoor antenna (Diamond V2000A). Very cool. I’d say with the dongles, it’s seems about 99% solidrbut expect with a hat it to be 100^. :-)
Sent from my iPhone 11 Max Pro
|
Re: OK I seem to be homing in on the problem
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
Btw... as an experiment, try the following:
?? 1. Have your receiving radio on 144.390
?? 2. disable gpsd
?? 3. disconnect your GPS
?? 4. open up the receive squelch and turn up the volume so you can
hear the FM static
?? 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.
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:
toggle quoted message
Show quoted text
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
If I was to guess, once you enable gpsd and it powers up the GPS and
then your radio starts transmitting, you're getting RFI coming back
into the system that's impacting your sound card's output.? This
isn't an uncommon issue.? How close are all the wires and cables to
the transmitting antenna?? Can you move the transmitting antenna and
ideally transmitting radio as FAR AWAY from the rest of the
Raspberry Pi, GPS, and all cabling as possible?? Can you add
ferrites to both sides of all your power, audio, etc cables?
--David
KI6ZHD
RFI is a possiblity, though I would think the GPS electronics are active whenever it is attached to the USB port.? We have not seen issues with GPS (other than the version of GPSD) as a tracker with Direwolf.? I tend to use the DRAWS? HAT and active antenna. -- John D. Hays
Kingston, WA K7VE / WRJT-215
|
Re: Apparent problem with GPSD support in Direwolf 1.6
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 posted some examples of the sounds in a second post.
I understand that PBEACON?is not controlled by GPSD support but PBEACON and more importantly for my testing digipeating are functional if GPSD is enabled.
The behavior is as follows:
- GPSD disable: ?Direwolf functions normally and packets are decoded by nearly all stations which receive the packets
- I enable GPSD and nothing else?and the PBEACON?packets and digipeated packets sound "rough" and the packet ?are not decoded
- I enable GPSD and enable TBEACON and digipeating and the packets sound rough?and are not decoded
When GPSD is enabled it measurably degrades?the sound when listened to and the packets can not be decoded.
It is not a function?of sound level: ?adjusting levels changes volume but not behavior.
It is not a function of the sound card: ?this problem is evidenced with a DINAH usb sound?card and a Signalink usb sound card.
At this point it would?appear that there is a problem with the GPSD capabilities in Direwolf.
Direwolf works fine for a static digipeater but is not working as a tracker with location provided by gpsd daemon.
Hello Don,
My direwolf system performs perfectly with GPSD
disabled in the direwolf.conf.
I have PBEACON?on and have set up a system to listen to the
sound.
The PBEACON function is for static locations only and doesn't have
any interaction with GPSD.? It's on the TBEACON (Tracker BEACON)
that uses your GPS.
I hear the usual rough but steady sound.
I don't know quite what you mean by "rough" but your 1200bps AFSK
packet sounds should sound similar to these examples with a clear,
not distorted sound:
??
I now enable the GPSD option.
PBEACON?is still on.
Again, these should be 100% unrelated.
I listen to the sound, it is extremely rough and erratic
and my systems are unable to decode the packet.
You're listening to what you're system is transmitting or what it's
receiving?? Can you provide a mp3/wav file example of this?
It appears that enabling GPSD seriously?degrades the
quality?of the modulating sound produced?by direwolf making
the sound unreadable most of the time.
I have increased and decreased the volume of the sound and
it has no impact, so. it appears to be an issue in the
generation of the tones themselves not in the levels.
If I was to guess, once you enable gpsd and it powers up the GPS and
then your radio starts transmitting, you're getting RFI coming back
into the system that's impacting your sound card's output.? This
isn't an uncommon issue.? How close are all the wires and cables to
the transmitting antenna?? Can you move the transmitting antenna and
ideally transmitting radio as FAR AWAY from the rest of the
Raspberry Pi, GPS, and all cabling as possible?? Can you add
ferrites to both sides of all your power, audio, etc cables?
--David
KI6ZHD
|
Re: OK I seem to be homing in on the problem
Hello Don,
My direwolf system performs perfectly with GPSD
disabled in the direwolf.conf.
I have PBEACON?on and have set up a system to listen to the
sound.
The PBEACON function is for static locations only and doesn't have
any interaction with GPSD.? It's on the TBEACON (Tracker BEACON)
that uses your GPS.
I hear the usual rough but steady sound.
I don't know quite what you mean by "rough" but your 1200bps AFSK
packet sounds should sound similar to these examples with a clear,
not distorted sound:
??
I now enable the GPSD option.
PBEACON?is still on.
Again, these should be 100% unrelated.
I listen to the sound, it is extremely rough and erratic
and my systems are unable to decode the packet.
You're listening to what you're system is transmitting or what it's
receiving?? Can you provide a mp3/wav file example of this?
It appears that enabling GPSD seriously?degrades the
quality?of the modulating sound produced?by direwolf making
the sound unreadable most of the time.
I have increased and decreased the volume of the sound and
it has no impact, so. it appears to be an issue in the
generation of the tones themselves not in the levels.
If I was to guess, once you enable gpsd and it powers up the GPS and
then your radio starts transmitting, you're getting RFI coming back
into the system that's impacting your sound card's output.? This
isn't an uncommon issue.? How close are all the wires and cables to
the transmitting antenna?? Can you move the transmitting antenna and
ideally transmitting radio as FAR AWAY from the rest of the
Raspberry Pi, GPS, and all cabling as possible?? Can you add
ferrites to both sides of all your power, audio, etc cables?
--David
KI6ZHD
|
Sam - KO4HBY
John Hays - K7VE / WRJT-215