Basil,

Updated your scripts. Thank you.

Slipped my mind to include the alsa-show.sh output:
PCM L:[-11.00dB] R:[-11.00dB]
ADC Level L:[-2.00dB] R:[-2.00dB]
LO Driver Gain L:[-2.00dB] R:[-2.00dB]
IN1 L:[10 kOhm] R:[Off]
IN2 L:[Off] R:[Off]

These were determined for the lowest TX drive level that also showed
minimal noise with PTM-P1 set L channel. Quick and dirty lunchtime

I also did not tell you specifically that I did adjust the LO Drive up
all the way through its range 1st just to see what was going on.

1. With PCM set at -21.0dB (where I had it for PTM-P3), there was a
lot of the background noise through most of the entire range LO Drive

2. With the PCM increased to 0dB it was "cleaner looking" but maxing
out ALC through the entire LO Drive range - couldn't get a drop in ALC

3. Arbitrarily I picked -11.0dB as the halfway point. It got me where
you see above. Moving the LO Drive above 0dB increased the ALC, below
-2.0dB it stopped dropping the ALC, but the noise showed up. I left it

When I go back - I want to again start with:
Right channel levels "more completely turned off" (that might
eliminate a source of the noise from crossover?) Methodically step
through a range of LO Drive settings for each specific PCM setting
near the "sweet spot" for the IC-7000 Record what I am seeing in some
video clips if you think it would be helpful

Thanks for the info on the FT-817 - I will take a look now but
probably test them when you release Beta7.

KD4IZ
Jack Spitznagel
FM19oo





-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 14:42
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Jack,

Thank you for all the data, it is very much appreciated. I have a
request for when you give us one of the ALSA control settings that you
run alsa-show.sh instead so we get a better understanding of how other
controls are set as well.

To get the latest version of that script:
cd
cd n7nix
git pull
cd n7nix/bin
./alsa-show.sh

Also the LO Driver Gain (analog) control should be adjusted before the
PCM
(digital) control.

Since you mention the Yaesu FT-817 note that we have successfully
setup that radio with FLdigi & DRAWS. Reference these files:

bin/setalsa-ft817.sh
docs/RADIO_APP_NOTES.md

Thanks.

Jack Spitznagel <kd4iz@frawg.org> writes:

Hi Basil, Annaliese, and John,



@ Basil and Annaliese: Thanks for the PTM information. It made for an
interesting lunch break today. Here are a series of quick
observations using fldigi which I want to confirm. I will send you my
more complete observations when I can.



Exec Summary: Switching from PTM-P3 to PTM-P1 did not reduce the TX
audio level sufficiently to allow for clean audio tone and a
reduction of ALC reading on the IC-7000. It did do something
unexpected; the floor for appearance of the low level circuitry noise

Apparently there is "other stuff" getting into the TX audio output
circuit that comes along with setting the TX tone(s) to low output
levels. It appears that "noise" is keeping the ALC reading from going
much below "redline" and is also causing the ALC reading to pulse.
The noise appears/sounds to be random popping/sizzling along with a
higher amplitude ticking pulse.



I am going to refer to this as "circuit background noise" for lack of
the proper technical description. Please tell me what to call it if
that is incorrect. I plan to repeat this using a little more careful
method of transmitting tones generated by DRAWS. I will plan to send
a link to a short video clip of Spectrum Lab tracings with receiver
sound to show differences between the PTM-P1, P2, and P3 settings but
probably won't get to it until tomorrow.



My quick comparison of PTM alsamixer settings used:

fldigi/flrig as the DRAWS tone generation app into the IC-7000, USB
at 21.070MHz with LO Drive set at -0.0dB.

IC-7100 to receive with the attenuator on and the RF gain reduced to
50% to avoid overdriving the receiver front end. Output of the
IC-7100 sound device observed with Spectrum Lab 2.

Adjusting PCM (only) while observing rig ALC level along with
spectrum, waterfall, and amplitude on Spectrum Lab.



PTM-P3 (default) - shows lowest "circuit background noise" floor at
about -25.00dB or so, but when set at levels (-21.5dB or higher)
where the "background noise" disappears (per Spectrum Lab) - the
IC-7000 (and FT-817) input is overdriven when the tone is at cleanest

(So the S/N ratio is the highest?)



PTM-P2 reduces the audio level some but also appears to increase the
level where the "circuit background noise" appears (to around
-21.0Db)
- the
IC-7000 input is still overdriven when the tone is at cleanest
appearing setting.



PTM-P1 definitely reduces the TX audio level BUT changes the level at
which the background noise appears (about -18.0dB) - the IC-7000
input is still overdriven when the tone is at cleanest appearing

(but the S/N is
lowest?)



For all 3 of the settings, that means the ALC reading on the IC-7000
remains at about mid scale and the appearance of the "circuit
background

noise"

prevents me from reducing it any more. Obviously, the "circuit
background noise" is being transmitted... not optimal.



As a result, it appears it is not possible to get a clean signal AND
reduce the drive level using the controls to a point where the
IC-7000 is not using ALC to limit the input. The rig and DRAWS will
likely need an attenuator placed somewhere in the TX audio circuit

Current app testing status has not changed.

1. DRAWS can be used to receive very well in all apps I have tested.

2. Can transmit from:

A. direwolf maybe over dev a little, but basically Xastir and YAAC
are solid into local digipeaters and gateways. I will need to redo
the DEV adjustment (when Beta 7 arrives).

B. fldigi is "working", I can QSO, but app is overdriving the rig
when TX tone is cleanest noted by test and by other ops.

C. wsjt-x only at very low levels, no QSO yet in FT8, but decoded
here on the bench by another radio/computer. I can't raise TX audio
levels with alsamixer high enough to get a significant power out
reading on the rig during FT8 transmission.



More to come. would appreciate knowing if I am on track with the
measuring methods and if this is useful data for you.



KD4IZ

Jack Spitznagel

FM19oo







-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Do I surmise correctly that the PTM control is not exposed in the
BETA 6

mixer driver?



The new ALSA controls will be in the BETA7 image which will be out in
the next day or 2. Or do the following:



Check the old version with

dpkg -l "udrc*"



apt-get update

apt-get upgrade



Check the new version:

dpkg -l "udrc*"



It should be 1.0.5



/Basil

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ

Jack Spitznagel

FM19oo

Basil,

Updated your scripts. Thank you.

Slipped my mind to include the alsa-show.sh output:
PCM L:[-11.00dB] R:[-11.00dB]
ADC Level L:[-2.00dB] R:[-2.00dB]
LO Driver Gain L:[-2.00dB] R:[-2.00dB]
IN1 L:[10 kOhm] R:[Off]
IN2 L:[Off] R:[Off]

These were determined for the lowest TX drive level that also showed
minimal noise with PTM-P1 set L channel. Quick and dirty lunchtime

I also did not tell you specifically that I did adjust the LO Drive up
all the way through its range 1st just to see what was going on.

1. With PCM set at -21.0dB (where I had it for PTM-P3), there was a
lot of the background noise through most of the entire range LO Drive

2. With the PCM increased to 0dB it was "cleaner looking" but maxing
out ALC through the entire LO Drive range - couldn't get a drop in ALC at

3. Arbitrarily I picked -11.0dB as the halfway point. It got me where
you see above. Moving the LO Drive above 0dB increased the ALC, below
-2.0dB it stopped dropping the ALC, but the noise showed up. I left it on

When I go back - I want to again start with:
Right channel levels "more completely turned off" (that might
eliminate a source of the noise from crossover?) Methodically step
through a range of LO Drive settings for each specific PCM setting
near the "sweet spot" for the IC-7000 Record what I am seeing in some
video clips if you think it would be helpful

Thanks for the info on the FT-817 - I will take a look now but
probably test them when you release Beta7.

KD4IZ
Jack Spitznagel
FM19oo





-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 14:42
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Jack,

Thank you for all the data, it is very much appreciated. I have a
request for when you give us one of the ALSA control settings that you
run alsa-show.sh instead so we get a better understanding of how other
controls are set as well.

To get the latest version of that script:
cd
cd n7nix
git pull
cd n7nix/bin
./alsa-show.sh

Also the LO Driver Gain (analog) control should be adjusted before the
PCM
(digital) control.

Since you mention the Yaesu FT-817 note that we have successfully
setup that radio with FLdigi & DRAWS. Reference these files:

bin/setalsa-ft817.sh
docs/RADIO_APP_NOTES.md

Thanks.

Jack Spitznagel <kd4iz@frawg.org> writes:

Hi Basil, Annaliese, and John,



@ Basil and Annaliese: Thanks for the PTM information. It made for an
interesting lunch break today. Here are a series of quick
observations using fldigi which I want to confirm. I will send you my
more complete observations when I can.



Exec Summary: Switching from PTM-P3 to PTM-P1 did not reduce the TX
audio level sufficiently to allow for clean audio tone and a
reduction of ALC reading on the IC-7000. It did do something
unexpected; the floor for appearance of the low level circuitry noise

Apparently there is "other stuff" getting into the TX audio output
circuit that comes along with setting the TX tone(s) to low output
levels. It appears that "noise" is keeping the ALC reading from going
much below "redline" and is also causing the ALC reading to pulse.
The noise appears/sounds to be random popping/sizzling along with a
higher amplitude ticking pulse.



I am going to refer to this as "circuit background noise" for lack of
the proper technical description. Please tell me what to call it if
that is incorrect. I plan to repeat this using a little more careful
method of transmitting tones generated by DRAWS. I will plan to send
a link to a short video clip of Spectrum Lab tracings with receiver
sound to show differences between the PTM-P1, P2, and P3 settings but
probably won't get to it until tomorrow.



My quick comparison of PTM alsamixer settings used:

fldigi/flrig as the DRAWS tone generation app into the IC-7000, USB
at 21.070MHz with LO Drive set at -0.0dB.

IC-7100 to receive with the attenuator on and the RF gain reduced to
50% to avoid overdriving the receiver front end. Output of the
IC-7100 sound device observed with Spectrum Lab 2.

Adjusting PCM (only) while observing rig ALC level along with
spectrum, waterfall, and amplitude on Spectrum Lab.



PTM-P3 (default) - shows lowest "circuit background noise" floor at
about -25.00dB or so, but when set at levels (-21.5dB or higher)
where the "background noise" disappears (per Spectrum Lab) - the
IC-7000 (and FT-817) input is overdriven when the tone is at cleanest

(So the S/N ratio is the highest?)



PTM-P2 reduces the audio level some but also appears to increase the
level where the "circuit background noise" appears (to around
-21.0Db)
- the
IC-7000 input is still overdriven when the tone is at cleanest
appearing setting.



PTM-P1 definitely reduces the TX audio level BUT changes the level at
which the background noise appears (about -18.0dB) - the IC-7000
input is still overdriven when the tone is at cleanest appearing setting.
(but the S/N is
lowest?)



For all 3 of the settings, that means the ALC reading on the IC-7000
remains at about mid scale and the appearance of the "circuit
background

noise"

prevents me from reducing it any more. Obviously, the "circuit
background noise" is being transmitted... not optimal.



As a result, it appears it is not possible to get a clean signal AND
reduce the drive level using the controls to a point where the
IC-7000 is not using ALC to limit the input. The rig and DRAWS will
likely need an attenuator placed somewhere in the TX audio circuit

Current app testing status has not changed.

1. DRAWS can be used to receive very well in all apps I have tested.

2. Can transmit from:

A. direwolf maybe over dev a little, but basically Xastir and YAAC
are solid into local digipeaters and gateways. I will need to redo
the DEV adjustment (when Beta 7 arrives).

B. fldigi is "working", I can QSO, but app is overdriving the rig
when TX tone is cleanest noted by test and by other ops.

C. wsjt-x only at very low levels, no QSO yet in FT8, but decoded
here on the bench by another radio/computer. I can't raise TX audio
levels with alsamixer high enough to get a significant power out
reading on the rig during FT8 transmission.



More to come. would appreciate knowing if I am on track with the
measuring methods and if this is useful data for you.



KD4IZ

Jack Spitznagel

FM19oo







-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Do I surmise correctly that the PTM control is not exposed in the
BETA 6

mixer driver?



The new ALSA controls will be in the BETA7 image which will be out in
the next day or 2. Or do the following:



Check the old version with

dpkg -l "udrc*"



apt-get update

apt-get upgrade



Check the new version:

dpkg -l "udrc*"



It should be 1.0.5



/Basil

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ

Jack Spitznagel

FM19oo

Hi Annaliese,

I checked /etc/default/gpsd and the GPSD_OPTIONS was set as GPSD_OPTIONS=”-n”

In my investigation of this issue I checked the www.catb.org/gpsd/ site and under troubleshooting I found:

Ubuntu/Debian
The .deb package supplied for the Debian and Ubuntu Linux distributions launch at boot either using systemd with gpsd.socket and gpsd.service, or on older releases from the system V-like script /etc/init.d/gpsd. However, both are governed by a control file, /etc/default/gpsd. If necessary, edit the control file as root.
Please note that systemd will only start gpsd on request by clients connecting to the unix or tcp socket. In case you need gpsd to run always, you'll need to configure systemd to start it. One way would be to create /etc/systemd/system/gpsd.service with the following content:
[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service

[Service]
EnvironmentFile=-/etc/default/gpsd
EnvironmentFile=-/etc/sysconfig/gpsd
ExecStart=/usr/sbin/gpsd -N $GPSD_OPTIONS $DEVICES

[Install]
WantedBy=multi-user.target
Also=gpsd.socket

Then make sure you ask systemd to reload its config run:

sudo systemctl daemon-reload; systemctl reenable gpsd.service

I have implemented this as suggested and it resolves the problem that I run into.

I suspect that this would not be an issue for anyone who is automatically starting applications that access gpsd on bootup but that is not my case. My main use of gpsd is for chrony to act as a time server for my local network.

Cheers,
Daniel VE3NI


-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Annaliese McDermond
Sent: Tuesday, January 01, 2019 7:32 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2

On Jan 1, 2019, at 2:01 PM, Daniel VE3NI <dgoodier@gmail.com <mailto:dgoodier@gmail.com> > wrote:

This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

I believe that this is still under investigation.

If you haven’t already checked, make sure that as part of the GPSD_OPTIONS variable in /etc/default/gpsd, it includes the “-n” flag. It should read something like:

GPSD_OPTIONS="-n -G”

This line will cause gpsd to start as a daemon and to answer queries from outside of the Pi (if, for example, you wanted to use it as a GPS source for Xastir or YACC).

Hi Annaliese,

I checked /etc/default/gpsd and the GPSD_OPTIONS was set as GPSD_OPTIONS=”-n”

In my investigation of this issue I checked the www.catb.org/gpsd/ site and under troubleshooting I found:

Ubuntu/Debian
The .deb package supplied for the Debian and Ubuntu Linux distributions launch at boot either using systemd with gpsd.socket and gpsd.service, or on older releases from the system V-like script /etc/init.d/gpsd. However, both are governed by a control file, /etc/default/gpsd. If necessary, edit the control file as root.
Please note that systemd will only start gpsd on request by clients connecting to the unix or tcp socket. In case you need gpsd to run always, you'll need to configure systemd to start it. One way would be to create /etc/systemd/system/gpsd.service with the following content:
[Unit]
Description=GPS (Global Positioning System) Daemon
Requires=gpsd.socket
# Needed with chrony SOCK refclock
After=chronyd.service

[Service]
EnvironmentFile=-/etc/default/gpsd
EnvironmentFile=-/etc/sysconfig/gpsd
ExecStart=/usr/sbin/gpsd -N $GPSD_OPTIONS $DEVICES

[Install]
WantedBy=multi-user.target
Also=gpsd.socket

Then make sure you ask systemd to reload its config run:

sudo systemctl daemon-reload; systemctl reenable gpsd.service

I have implemented this as suggested and it resolves the problem that I run into.

I suspect that this would not be an issue for anyone who is automatically starting applications that access gpsd on bootup but that is not my case. My main use of gpsd is for chrony to act as a time server for my local network.

Cheers,
Daniel VE3NI


-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Annaliese McDermond
Sent: Tuesday, January 01, 2019 7:32 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2

On Jan 1, 2019, at 2:01 PM, Daniel VE3NI <dgoodier@gmail.com <mailto:dgoodier@gmail.com> > wrote:

This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

I believe that this is still under investigation.

If you haven’t already checked, make sure that as part of the GPSD_OPTIONS variable in /etc/default/gpsd, it includes the “-n” flag. It should read something like:

GPSD_OPTIONS="-n -G”

This line will cause gpsd to start as a daemon and to answer queries from outside of the Pi (if, for example, you wanted to use it as a GPS source for Xastir or YACC).

Basil,

Updated your scripts. Thank you.

Slipped my mind to include the alsa-show.sh output:
PCM L:[-11.00dB] R:[-11.00dB]
ADC Level L:[-2.00dB] R:[-2.00dB]
LO Driver Gain L:[-2.00dB] R:[-2.00dB]
IN1 L:[10 kOhm] R:[Off]
IN2 L:[Off] R:[Off]

These were determined for the lowest TX drive level that also showed minimal
noise with PTM-P1 set L channel. Quick and dirty lunchtime observations.

I also did not tell you specifically that I did adjust the LO Drive up all
the way through its range 1st just to see what was going on.

1. With PCM set at -21.0dB (where I had it for PTM-P3), there was a lot of
the background noise through most of the entire range LO Drive range.
2. With the PCM increased to 0dB it was "cleaner looking" but maxing out
ALC through the entire LO Drive range - couldn't get a drop in ALC at all.
3. Arbitrarily I picked -11.0dB as the halfway point. It got me where you
see above. Moving the LO Drive above 0dB increased the ALC, below -2.0dB it
stopped dropping the ALC, but the noise showed up. I left it on -2.0dB.

When I go back - I want to again start with:
Right channel levels "more completely turned off" (that might eliminate a
source of the noise from crossover?)
Methodically step through a range of LO Drive settings for each specific PCM
setting near the "sweet spot" for the IC-7000
Record what I am seeing in some video clips if you think it would be helpful

Thanks for the info on the FT-817 - I will take a look now but probably test
them when you release Beta7.

KD4IZ
Jack Spitznagel
FM19oo





-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 14:42
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Jack,

Thank you for all the data, it is very much appreciated. I have a request
for when you give us one of the ALSA control settings that you run
alsa-show.sh instead so we get a better understanding of how other controls
are set as well.

To get the latest version of that script:
cd
cd n7nix
git pull
cd n7nix/bin
./alsa-show.sh

Also the LO Driver Gain (analog) control should be adjusted before the PCM
(digital) control.

Since you mention the Yaesu FT-817 note that we have successfully setup that
radio with FLdigi & DRAWS. Reference these files:

bin/setalsa-ft817.sh
docs/RADIO_APP_NOTES.md

Thanks.

Jack Spitznagel <kd4iz@frawg.org> writes:

Hi Basil, Annaliese, and John,



@ Basil and Annaliese: Thanks for the PTM information. It made for an
interesting lunch break today. Here are a series of quick observations
using fldigi which I want to confirm. I will send you my more complete
observations when I can.



Exec Summary: Switching from PTM-P3 to PTM-P1 did not reduce the TX
audio level sufficiently to allow for clean audio tone and a reduction
of ALC reading on the IC-7000. It did do something unexpected; the
floor for appearance of the low level circuitry noise actually went up!



Apparently there is "other stuff" getting into the TX audio output
circuit that comes along with setting the TX tone(s) to low output
levels. It appears that "noise" is keeping the ALC reading from going
much below "redline" and is also causing the ALC reading to pulse. The
noise appears/sounds to be random popping/sizzling along with a higher
amplitude ticking pulse.



I am going to refer to this as "circuit background noise" for lack of
the proper technical description. Please tell me what to call it if
that is incorrect. I plan to repeat this using a little more careful
method of transmitting tones generated by DRAWS. I will plan to send a
link to a short video clip of Spectrum Lab tracings with receiver
sound to show differences between the PTM-P1, P2, and P3 settings but
probably won't get to it until tomorrow.



My quick comparison of PTM alsamixer settings used:

fldigi/flrig as the DRAWS tone generation app into the IC-7000, USB at
21.070MHz with LO Drive set at -0.0dB.

IC-7100 to receive with the attenuator on and the RF gain reduced to
50% to avoid overdriving the receiver front end. Output of the IC-7100
sound device observed with Spectrum Lab 2.

Adjusting PCM (only) while observing rig ALC level along with
spectrum, waterfall, and amplitude on Spectrum Lab.



PTM-P3 (default) - shows lowest "circuit background noise" floor at
about -25.00dB or so, but when set at levels (-21.5dB or higher) where
the "background noise" disappears (per Spectrum Lab) - the IC-7000
(and FT-817) input is overdriven when the tone is at cleanest setting.
(So the S/N ratio is the highest?)



PTM-P2 reduces the audio level some but also appears to increase the
level where the "circuit background noise" appears (to around -21.0Db)
- the
IC-7000 input is still overdriven when the tone is at cleanest
appearing setting.



PTM-P1 definitely reduces the TX audio level BUT changes the level at
which the background noise appears (about -18.0dB) - the IC-7000 input
is still overdriven when the tone is at cleanest appearing setting.
(but the S/N is
lowest?)



For all 3 of the settings, that means the ALC reading on the IC-7000
remains at about mid scale and the appearance of the "circuit background

noise"

prevents me from reducing it any more. Obviously, the "circuit
background noise" is being transmitted... not optimal.



As a result, it appears it is not possible to get a clean signal AND
reduce the drive level using the controls to a point where the IC-7000
is not using ALC to limit the input. The rig and DRAWS will likely
need an attenuator placed somewhere in the TX audio circuit (AFIN).



Current app testing status has not changed.

1. DRAWS can be used to receive very well in all apps I have tested.

2. Can transmit from:

A. direwolf maybe over dev a little, but basically Xastir and YAAC are
solid into local digipeaters and gateways. I will need to redo the DEV
adjustment (when Beta 7 arrives).

B. fldigi is "working", I can QSO, but app is overdriving the rig when
TX tone is cleanest noted by test and by other ops.

C. wsjt-x only at very low levels, no QSO yet in FT8, but decoded here
on the bench by another radio/computer. I can't raise TX audio levels
with alsamixer high enough to get a significant power out reading on
the rig during FT8 transmission.



More to come. would appreciate knowing if I am on track with the
measuring methods and if this is useful data for you.



KD4IZ

Jack Spitznagel

FM19oo







-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Do I surmise correctly that the PTM control is not exposed in the
BETA 6

mixer driver?



The new ALSA controls will be in the BETA7 image which will be out in
the next day or 2. Or do the following:



Check the old version with

dpkg -l "udrc*"



apt-get update

apt-get upgrade



Check the new version:

dpkg -l "udrc*"



It should be 1.0.5



/Basil

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ

Jack Spitznagel

FM19oo

Hi Basil, Annaliese, and John,



@ Basil and Annaliese: Thanks for the PTM information. It made for an
interesting lunch break today. Here are a series of quick observations
using fldigi which I want to confirm. I will send you my more complete
observations when I can.



Exec Summary: Switching from PTM-P3 to PTM-P1 did not reduce the TX
audio level sufficiently to allow for clean audio tone and a reduction
of ALC reading on the IC-7000. It did do something unexpected; the
floor for appearance of the low level circuitry noise actually went up!



Apparently there is "other stuff" getting into the TX audio output
circuit that comes along with setting the TX tone(s) to low output
levels. It appears that "noise" is keeping the ALC reading from going
much below "redline" and is also causing the ALC reading to pulse. The
noise appears/sounds to be random popping/sizzling along with a higher
amplitude ticking pulse.



I am going to refer to this as "circuit background noise" for lack of
the proper technical description. Please tell me what to call it if
that is incorrect. I plan to repeat this using a little more careful
method of transmitting tones generated by DRAWS. I will plan to send a
link to a short video clip of Spectrum Lab tracings with receiver
sound to show differences between the PTM-P1, P2, and P3 settings but
probably won't get to it until tomorrow.



My quick comparison of PTM alsamixer settings used:

fldigi/flrig as the DRAWS tone generation app into the IC-7000, USB at
21.070MHz with LO Drive set at -0.0dB.

IC-7100 to receive with the attenuator on and the RF gain reduced to
50% to avoid overdriving the receiver front end. Output of the IC-7100
sound device observed with Spectrum Lab 2.

Adjusting PCM (only) while observing rig ALC level along with
spectrum, waterfall, and amplitude on Spectrum Lab.



PTM-P3 (default) - shows lowest "circuit background noise" floor at
about -25.00dB or so, but when set at levels (-21.5dB or higher) where
the "background noise" disappears (per Spectrum Lab) - the IC-7000
(and FT-817) input is overdriven when the tone is at cleanest setting.
(So the S/N ratio is the highest?)



PTM-P2 reduces the audio level some but also appears to increase the
level where the "circuit background noise" appears (to around -21.0Db)
- the
IC-7000 input is still overdriven when the tone is at cleanest
appearing setting.



PTM-P1 definitely reduces the TX audio level BUT changes the level at
which the background noise appears (about -18.0dB) - the IC-7000 input
is still overdriven when the tone is at cleanest appearing setting.
(but the S/N is
lowest?)



For all 3 of the settings, that means the ALC reading on the IC-7000
remains at about mid scale and the appearance of the "circuit background

prevents me from reducing it any more. Obviously, the "circuit
background noise" is being transmitted... not optimal.



As a result, it appears it is not possible to get a clean signal AND
reduce the drive level using the controls to a point where the IC-7000
is not using ALC to limit the input. The rig and DRAWS will likely
need an attenuator placed somewhere in the TX audio circuit (AFIN).



Current app testing status has not changed.

1. DRAWS can be used to receive very well in all apps I have tested.

2. Can transmit from:

A. direwolf maybe over dev a little, but basically Xastir and YAAC are
solid into local digipeaters and gateways. I will need to redo the DEV
adjustment (when Beta 7 arrives).

B. fldigi is "working", I can QSO, but app is overdriving the rig when
TX tone is cleanest noted by test and by other ops.

C. wsjt-x only at very low levels, no QSO yet in FT8, but decoded here
on the bench by another radio/computer. I can't raise TX audio levels
with alsamixer high enough to get a significant power out reading on
the rig during FT8 transmission.



More to come. would appreciate knowing if I am on track with the
measuring methods and if this is useful data for you.



KD4IZ

Jack Spitznagel

FM19oo







-----Original Message-----
From: udrc@nw-digital-radio.groups.io
<udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Do I surmise correctly that the PTM control is not exposed in the
BETA 6

mixer driver?



The new ALSA controls will be in the BETA7 image which will be out in
the next day or 2. Or do the following:



Check the old version with

dpkg -l "udrc*"



apt-get update

apt-get upgrade



Check the new version:

dpkg -l "udrc*"



It should be 1.0.5



/Basil

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ

Jack Spitznagel

FM19oo

Hi Basil, Annaliese, and John,



@ Basil and Annaliese: Thanks for the PTM information. It made for an
interesting lunch break today. Here are a series of quick observations using
fldigi which I want to confirm. I will send you my more complete
observations when I can.



Exec Summary: Switching from PTM-P3 to PTM-P1 did not reduce the TX audio
level sufficiently to allow for clean audio tone and a reduction of ALC
reading on the IC-7000. It did do something unexpected; the floor for
appearance of the low level circuitry noise actually went up!



Apparently there is "other stuff" getting into the TX audio output circuit
that comes along with setting the TX tone(s) to low output levels. It
appears that "noise" is keeping the ALC reading from going much below
"redline" and is also causing the ALC reading to pulse. The noise
appears/sounds to be random popping/sizzling along with a higher amplitude
ticking pulse.



I am going to refer to this as "circuit background noise" for lack of the
proper technical description. Please tell me what to call it if that is
incorrect. I plan to repeat this using a little more careful method of
transmitting tones generated by DRAWS. I will plan to send a link to a short
video clip of Spectrum Lab tracings with receiver sound to show differences
between the PTM-P1, P2, and P3 settings but probably won't get to it until
tomorrow.



My quick comparison of PTM alsamixer settings used:

fldigi/flrig as the DRAWS tone generation app into the IC-7000, USB at
21.070MHz with LO Drive set at -0.0dB.

IC-7100 to receive with the attenuator on and the RF gain reduced to 50% to
avoid overdriving the receiver front end. Output of the IC-7100 sound device
observed with Spectrum Lab 2.

Adjusting PCM (only) while observing rig ALC level along with spectrum,
waterfall, and amplitude on Spectrum Lab.



PTM-P3 (default) - shows lowest "circuit background noise" floor at about
-25.00dB or so, but when set at levels (-21.5dB or higher) where the
"background noise" disappears (per Spectrum Lab) - the IC-7000 (and FT-817)
input is overdriven when the tone is at cleanest setting. (So the S/N ratio
is the highest?)



PTM-P2 reduces the audio level some but also appears to increase the level
where the "circuit background noise" appears (to around -21.0Db) - the
IC-7000 input is still overdriven when the tone is at cleanest appearing
setting.



PTM-P1 definitely reduces the TX audio level BUT changes the level at which
the background noise appears (about -18.0dB) - the IC-7000 input is still
overdriven when the tone is at cleanest appearing setting. (but the S/N is
lowest?)



For all 3 of the settings, that means the ALC reading on the IC-7000 remains
at about mid scale and the appearance of the "circuit background noise"
prevents me from reducing it any more. Obviously, the "circuit background
noise" is being transmitted... not optimal.



As a result, it appears it is not possible to get a clean signal AND reduce
the drive level using the controls to a point where the IC-7000 is not using
ALC to limit the input. The rig and DRAWS will likely need an attenuator
placed somewhere in the TX audio circuit (AFIN).



Current app testing status has not changed.

1. DRAWS can be used to receive very well in all apps I have tested.

2. Can transmit from:

A. direwolf maybe over dev a little, but basically Xastir and YAAC are solid
into local digipeaters and gateways. I will need to redo the DEV adjustment
(when Beta 7 arrives).

B. fldigi is "working", I can QSO, but app is overdriving the rig when TX
tone is cleanest noted by test and by other ops.

C. wsjt-x only at very low levels, no QSO yet in FT8, but decoded here on
the bench by another radio/computer. I can't raise TX audio levels with
alsamixer high enough to get a significant power out reading on the rig
during FT8 transmission.



More to come. would appreciate knowing if I am on track with the measuring
methods and if this is useful data for you.



KD4IZ

Jack Spitznagel

FM19oo







-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

Do I surmise correctly that the PTM control is not exposed in the BETA 6

mixer driver?



The new ALSA controls will be in the BETA7 image which will be out in the
next day or 2. Or do the following:



Check the old version with

dpkg -l "udrc*"



apt-get update

apt-get upgrade



Check the new version:

dpkg -l "udrc*"



It should be 1.0.5



/Basil

If it is, where/how would I find it and under what subdevice name?

HNY and 73,

KD4IZ

Jack Spitznagel

FM19oo

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 2, 2019 01:00
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6

> Do I surmise correctly that the PTM control is not exposed in the BETA 6 mixer driver?

The new ALSA controls will be in the BETA7 image which will be out in the next day or 2. Or do the following:

Check the old version with

dpkg -l "udrc*"

apt-get update

apt-get upgrade

Check the new version:

dpkg -l "udrc*"

It should be 1.0.5

/Basil

> If it is, where/how would I find it and under what subdevice name?

> 

> HNY and 73,

> 

> KD4IZ

> Jack Spitznagel

> FM19oo

> On Jan 1, 2019, at 2:01 PM, Daniel VE3NI <dgoodier@...> wrote:

> 

> This however has not resolved the fact that gpsd service does not start automatically on startup until I either issue a systemctl start gpsd.service or run gpsmon.

> 

> I believe that this is still under investigation.

If you haven’t already checked, make sure that as part of the GPSD_OPTIONS variable in /etc/default/gpsd, it includes the “-n” flag.  It should read something like:

GPSD_OPTIONS="-n -G”

This line will cause gpsd to start as a daemon and to answer queries from outside of the Pi (if, for example, you wanted to use it as a GPS source for Xastir or YACC).

--

Annaliese McDermond (NH6Z)

nh6z@...

> Cheers,

> Daniel  VE3NI / NI2D

It appears to me that you have incorrect settings in your config.txt file.  I will make this very explicit because I’m not sure I’ve made myself clear before:

*ORDER MATTERS IN LINES IN config.txt*

If you do not get the directives in the correct order, the OS kernel will not load the correct drivers for you.

If you intend to use the onboard audio on the Pi, the line

dtparam=audio=on

*MUST* come after the lines

dtoverlay=
dtoverlay=draws

Otherwise the device tree will not be loaded correctly and you won’t get a proper driver set.

--
Annaliese McDermond (NH6Z)
nh6z@...

On Jan 1, 2019, at 3:56 PM, Joseph Vilardo <jvilardo@...> wrote:

Basil

I ran your suggested procedures and I am still where I was when I started.  When I run FLDIGI, after doing all the prerequisites for shutting down  DIREWOLF and and running ./ax25-stop , I still cannot select a sound card from the fldigi audio setup menu.  To select the the codec from the fldigi audio set up I must have #dtparam=audio=on commented out in the config.txt file. With dtparam=audio=on commented out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: - (hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is what you said enumerates with dtparm=audio=on commented out, only hw 0,0 will enumerate. 

When following the new draw "getting started doc "DRAWS Raspberry PI image"  from the wiki and run "aplay-l I" do not get the same results shown in the example of the doc. 

This what I see:


**** List of PLAYBACK Hardware Devices ****

card 
0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]

  
Subdevices: 7/7

  
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

card 
0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]

  
Subdevices: 1/1

  
Subdevice 
#0: subdevice #0

Your example shows the following which I do not get:


 card 1: udrc [udrc], device 0: Universal Digital Radio Controller tlv320aic32x4-hifi-0 []

  
Subdevices: 0/1

  
Subdevice #0: subdevice #0

I have tried re formatting the micro sd card, changing sd cards,  re burning the image, changing the RPi 3 B+ to a different RPi B+, powering the RPi/DRAWS board from 12 volt supply. I am out of ideas and because of the anomaly in the results from aplay -l I think the problem it is a hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Best regards and happy New Year,

Joe K3JV





On 12/30/2018 1:08 AM, Basil Gunn wrote:

Joe,
Thanks for all the information.

I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.

Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav

Here is the question. When I complete the verify core test and
shutdown --ax25

You need to run a script in your local bin called. ax25-stop

and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.

Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi

In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.

I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.

IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi

There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.

I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe

On Dec 31, 2018, at 1:34 PM, Jack Spitznagel <kd4iz@frawg.org> wrote:

Hi Basil,

Again Thanks!!!
I understand these differences. Not confusing. I have been leaving the base config alone for now, but with the info from Annaliese yesterday and yours below, is speculative experimentation fair game now 😊?

Her notes on the implementation of the TI CODEC chip brought up these questions:
1. Should we disable the port not in use if only using 1 of them?? Annaliese suggests this would eliminate possibility of crosstalk. Is there a description of how you do this in the DRAWS wiki or your github pages? I missed it.

2. The info she sent about the PTM-P1/2/3 (DAC Left|Right Playback Powertune) settings for selecting the max output level suggests that the PTM-P1 setting should be default for the sensitive radios like the 7000. I look forward to seeing that available in Beta7. Where is it defaulting to now?

3. Her description of the three resistances associated with configuring input routing appear to be for the input only, I assume input from the rig?

Do they also impact the output to the rig? What you say below implies that... I am a little confused on this now.

For the record, I am doing everything at 1200 for the initial testing here thus focusing on IN2. IN1 - 9600/GMSK will come later once I know things work the way I want.

Assume you mean the 7000 below, not the 7100? They appear similar as far as the data port specs are concerned, I just have not played with the 7100 all that much other than using its internal sound device for HRD/DM780 ops and as a modem for Spectrum Lab.

In the DRAWS implementation here, the IC-7000 and the FT-817 will get used (max portability), both of which I have used with audio/data and GMSK/data in the past. The IC-7100 here is happy as is, mostly acts as #2 in an SO2R set up, providing 144/440 coverage and HF D-STAR. The primary HF radio can't do that.

If you have something specific you would like me to look at, or a possible solution you want to test for one of these radios (assuming not all are available to you), please ask. I have or can scrounge pretty much any needed test equipment. I also have a PDF copy of the service manual for the IC-7000 which may provide more clarity for that radio if you think it might help.

KD4IZ
Jack Spitznagel
FM19oo

so I found out about this problem quite by accident... if you run
xastir that was installed by apt from the repository and you want to
build from the source (for version 2.1.1 or later) you have to
rename/modify/delete xastir.cnf in ~/.xastir/config to point to
/usr/local/share/xastir instead of /usr/share/xastir.

Also, as of this writing the beta images come with the binary version
of xastir (version 2.0.8)

I ran your suggested procedures and I am still where I was when I
started. When I run FLDIGI, after doing all the prerequisites for
shutting down DIREWOLF and and running ./ax25-stop , I still cannot
select a sound card from the fldigi audio setup menu. To select the the
codec from the fldigi audio set up I must have #dtparam=audio=on
commented out in the config.txt file. With dtparam=audio=on commented
out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: -
(hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is
what you said enumerates with dtparm=audio=on commented out, only hw 0,0
will enumerate.

When following the new draw "getting started doc "DRAWS Raspberry PI
image" from the wiki and run "aplay-l I" do not get the same results
shown in the example of the doc.

This what I see:

|****ListofPLAYBACK HardwareDevices****card 0:ALSA [bcm2835 ALSA],device
0:bcm2835 ALSA [bcm2835 ALSA]Subdevices:7/7Subdevice#0: subdevice
#0Subdevice#1: subdevice #1Subdevice#2: subdevice #2Subdevice#3:
subdevice #3Subdevice#4: subdevice #4Subdevice#5: subdevice
#5Subdevice#6: subdevice #6card 0:ALSA [bcm2835 ALSA],device 1:bcm2835
ALSA [bcm2835 IEC958/HDMI]Subdevices:1/1Subdevice#0: subdevice #0 Your
example shows the following which I do not get: |

**

*|card 1:udrc [udrc],device
0:UniversalDigitalRadioControllertlv320aic32x4-hifi-0[]Subdevices:0/1Subdevice#0:
subdevice #0|*

**

I have tried re formatting the micro sd card, changing sd cards, re
burning the image, changing the RPi 3 B+ to a different RPi B+, powering
the RPi/DRAWS board from 12 volt supply. I am out of ideas and because
of the anomaly in the results from aplay -l I think the problem it is a
hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

On Jan 1, 2019, at 3:56 PM, Joseph Vilardo <jvilardo@verizon.net> wrote:

Basil

I ran your suggested procedures and I am still where I was when I started. When I run FLDIGI, after doing all the prerequisites for shutting down DIREWOLF and and running ./ax25-stop , I still cannot select a sound card from the fldigi audio setup menu. To select the the codec from the fldigi audio set up I must have #dtparam=audio=on commented out in the config.txt file. With dtparam=audio=on commented out with the # symbol I can then select urdc: - (hw:0,0) , not urdc: - (hw:0,1) for capture and urdc:-(hw:0,0) for playback. This result is what you said enumerates with dtparm=audio=on commented out, only hw 0,0 will enumerate.

When following the new draw "getting started doc "DRAWS Raspberry PI image" from the wiki and run "aplay-l I" do not get the same results shown in the example of the doc.

This what I see:


**** List of PLAYBACK Hardware Devices ****

card
0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA]


Subdevices: 7/7


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

card
0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI]


Subdevices: 1/1


Subdevice
#0: subdevice #0

Your example shows the following which I do not get:


card 1: udrc [udrc], device 0: Universal Digital Radio Controller tlv320aic32x4-hifi-0 []


Subdevices: 0/1


Subdevice #0: subdevice #0

I have tried re formatting the micro sd card, changing sd cards, re burning the image, changing the RPi 3 B+ to a different RPi B+, powering the RPi/DRAWS board from 12 volt supply. I am out of ideas and because of the anomaly in the results from aplay -l I think the problem it is a hardware failure of the DRAWS Board.

If you have any suggestions I am ready to try them.

Best regards and happy New Year,

Joe K3JV





On 12/30/2018 1:08 AM, Basil Gunn wrote:

Joe,
Thanks for all the information.

I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.

Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav

Here is the question. When I complete the verify core test and
shutdown --ax25

You need to run a script in your local bin called. ax25-stop

and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.

Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi

In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.

I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.

IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi

There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.

I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe

Joe,
Thanks for all the information.

I have been successful in verifying the core operation of Beta 6 and
have Direwolf/YAAC running without issue on port 0. I also have FLDIGI
running on port 0 (left hand port on the draws board) without a
problem but had to deviate from the information in
DRAWS_CONFIG.md. The directions in the verify document tell us to
remove the # from dtparm=audio=on to "Test analog audio" . I do that
by removing the # in the config.txt file for the Rpi and the test runs
and I get the results indicated. The same is true for "TEST OF HDMI
AUDIO" . By the way there is a minor error in the information the beta
6 release doesn't have a file named "silence.wav" in $
/usr/share/xastir/sounds.

Yes I see that. I'll fix it.
For now just copy it from n7nix/xastir/silence.wav to the
/usr/share/xastir/silence.wav

Here is the question. When I complete the verify core test and
shutdown --ax25

You need to run a script in your local bin called. ax25-stop

and then start FLDIGi and try to configure the sound
card FLDIGI fails and shuts down.

Try this.
You should see the process id of direwolf the first time you run pidof
and not the second time.

cd
cd bin
sudo su
pidof direwolf
./ax25-stop
pidof direwolf

Now run fldigi

In fldigi under the choices in the
audio selection menu there is no udrc audio choice available.

I just tried it & Fldigi enumerates:
udrc: -(hw:1,0)

without the enabled RPi sound device the udrc will enumerate like this:
udrc: -(hw:0,0)

I have a feeling you are not shutting down direwolf.
The next image will have direwolf unloaded by default.

IF I go
back to CONFIG.TXT and comment out, put the # in, for the line
dtparam=audio=on, reboot, start FLDIGI I can then select the udrc 0
port and complete the configuration of fldigi without issue and fldigi
runs just fine. Am I overlooking something in your instructions?
Or are we to comment out the dtparam=audio=on in the config.txt of the
RPi

There should be no problem enabling the BCM2835 RPi sound device.
I use it with Xastir for the sound alerts.

I am making some progress with WSTX I can receive and decode but not
transmit yet. I need to recheck the cable I made that goes from the
6pin mini din of the draws board to the 13 pin Din of my TS 590.

Thanks,
K3JV Joe