Date   

Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

Basil,

I do not have the IC-7000 9600 mode turned on now, 1200 or less only.
I hope to do so in the future for high speed packet, after the HF fldigi and
wsjt-x transmit issues are solved.
Eventually I will want to be able to configure it as a D-Star DV HotSpot and
to use on HF with Free DV/D-Star. I have a NW Digital AMBE3000 dongle
waiting for that use.

So at present, the apps I want to be able to run are 1200 packet and HF
digital (obviously not at the same time) - this will be a field portable
unit, so needs to be a bit of a swiss army knife when I have it working the
way I would like. I think Julian is shooting for a similar goal. I am not a
set it and forget it operator...

To your question regarding the receive input - I was not intentionally using
the discriminator input. As I commented before, *both packet and fldigi
receive are working, so you have me a bit puzzled*...

For the functions of IN1 vs IN2, I misunderstood them to be the opposite. I
was obviously confused about which was for what because I was not aware
of/had not seen either Annaliese's description of the CODEC or the
"App-Notes-for Radios" document when I modified the ALSA settings for the
7000. Those documents had not been uploaded to the Wiki yet and I did not
catch the fact that the assignment was reversed until you and Annaliese
pointed it out. I forgot I configured it the way I did (glad I had some
notes).

The script I started with (originally called soundset.sh or something like
it) was in an email from before the holidays. It fed the amixer command with
a string of subcommands as shown:
------------------------
amixer -c udrc -s << EOF
# Set input and output levels to 0dB
sset 'ADC Level' -2.0dB
sset 'LO Driver Gain' 0dB
sset 'PCM' 0.0dB

# Turn on AFOUT
sset 'CM_L to Left Mixer Negative Resistor' '10 kOhm'
sset 'IN1_L to Left Mixer Positive Resistor' '10 kOhm'

# Turn on DISCOUT
sset 'CM_R to Right Mixer Negative Resistor' '10 kOhm'
sset 'IN1_R to Right Mixer Positive Resistor' '10 kOhm'

# Turn off unnecessary pins
sset 'IN1_L to Right Mixer Negative Resistor' 'Off'
sset 'IN1_R to Left Mixer Positive Resistor' 'Off'
sset 'IN2_L to Left Mixer Positive Resistor' 'Off'
sset 'IN2_L to Right Mixer Positive Resistor' 'Off'
sset 'IN2_R to Left Mixer Negative Resistor' 'Off'
sset 'IN2_R to Right Mixer Positive Resistor' 'Off'
sset 'IN3_L to Left Mixer Positive Resistor' 'Off'
sset 'IN3_L to Right Mixer Negative Resistor' 'Off'
sset 'IN3_R to Left Mixer Negative Resistor' 'Off'
sset 'IN3_R to Right Mixer Positive Resistor' 'Off'
------------------------
... and so on... at that point I had no idea what any of the settings were
for except PCM, LO Driver Gain, and ADC Level. Annaliese's document about
the CODEC was the first comprehensive description I have seen and I am still
trying to digest that.

I had things set the way you see below because I started with the script
above and commented out the two lines following the comment "# Turn on
DISCOUT" thinking that would disable DISCOUT- so maybe some of that stuff
from emails and earlier "how to's" should be retracted and "official" list
of authoritative documents made - I am sure the early stuff had errors in
it. This stuff has moved quickly and I have not focused on every thread on
the list so I likely have missed important pointers and announcements of
documentation along the way. Docs have moved from GIT Hub and email comments
like "you can use the UDRC documents in the Wiki" to a growing family of
documents in the Wiki. I still have to unlearn what defaults left port or
right port because of confusion regarding the UDRC2 from that period.

I will run the FT-817 script since it will get me pretty close to what I
think the 7000 will like... and solve the IN2 config issue. See what
happens, but that doesn't address the TX level adjustment issue.

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 17:03
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6


I am interested to know why you are using the discriminator connection for
receive (IN1). For HF modes (AFSK) you should be using the AFOUT
connection(IN2) unless I am missing something regarding the IC-7000.
Are you running a vhf/uhf packet app or some HF app?
Could you tell me which data speed the IC-7000 is configured for? ie. is
9600 Mode turned on?

Check the App Notes for Radios wiki:
https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS%3A-App-Notes-for-Radios

ALSA settings:
Use IN1_L IN1_R for 9600 baud (DISCOUT)
Use IN2_L IN2_R for 1200 baud or less (AFOUT)

Also you will be using the latest version of alsa-show.sh if your output
looks something like this:

===== ALSA Controls for Radio Tansmit =====
LO Driver Gain L:[-2.00dB] R:[-2.00dB]
LO Playback CM [Full Chip CM]
PCM L:[-11.00dB] R:[-11.00dB]
DAC Playback PT L:[PTM_P3] R:[PTM_P3]

===== ALSA Controls for Radio Receive =====
ADC Level L:[-2.00dB] R:[-2.00dB]
IN1 L:[10 kOhm] R:[Off]
IN2 L:[Off] R:[Off]

/Basil

Jack Spitznagel <@flyingfrawg> writes:

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 <@flyingfrawg> 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













--
J Spitznagel
Science River LLC
KD4IZ


Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Daniel VE3NI
 

Basil,

Made the changes as you suggested and it now works as expected. Not sure which missing line you added so I added both of them, hi hi.

Looking forward to the next beta image release.

I have installed linBPQ and now to work my way through making it work with Direwolf. My goal is to replace my existing rPi Packet BBS/KPC 9612+ TNC with the rPi DRAWS hat.

Thanks,
Daniel

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Basil Gunn
Sent: Wednesday, January 02, 2019 6:50 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2


Daniel,

You may have added a second gpsd.service file.
Package-provided service files are usually located in /lib/systemd/system, check there for a gpsd.service file.
That's where the current version of compass/raspbian puts that file.

The gpsd.service file in /lib/systemd/system was not that different then the one from the catb.org site. I added one line and enabled it and gpsd now is enabled from boot.

This change will be in the Beta7 image.

/Basil


Daniel VE3NI <dgoodier@...> writes:

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@... <mailto: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).


Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Basil Gunn
 

Daniel,

You may have added a second gpsd.service file.
Package-provided service files are usually located in
/lib/systemd/system, check there for a gpsd.service file.
That's where the current version of compass/raspbian puts that file.

The gpsd.service file in /lib/systemd/system was not that different then the one from
the catb.org site. I added one line and enabled it and gpsd now is
enabled from boot.

This change will be in the Beta7 image.

/Basil


Daniel VE3NI <dgoodier@...> writes:

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@... <mailto: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).


Re: Draws and IC-7000 #draws #ic7000 #minidin6

Basil Gunn
 

I am interested to know why you are using the discriminator connection
for receive (IN1). For HF modes (AFSK) you should be using the AFOUT
connection(IN2) unless I am missing something regarding the IC-7000.
Are you running a vhf/uhf packet app or some HF app?
Could you tell me which data speed the IC-7000 is configured for? ie. is
9600 Mode turned on?

Check the App Notes for Radios wiki:
https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS%3A-App-Notes-for-Radios

ALSA settings:
Use IN1_L IN1_R for 9600 baud (DISCOUT)
Use IN2_L IN2_R for 1200 baud or less (AFOUT)

Also you will be using the latest version of alsa-show.sh if your output
looks something like this:

===== ALSA Controls for Radio Tansmit =====
LO Driver Gain L:[-2.00dB] R:[-2.00dB]
LO Playback CM [Full Chip CM]
PCM L:[-11.00dB] R:[-11.00dB]
DAC Playback PT L:[PTM_P3] R:[PTM_P3]

===== ALSA Controls for Radio Receive =====
ADC Level L:[-2.00dB] R:[-2.00dB]
IN1 L:[10 kOhm] R:[Off]
IN2 L:[Off] R:[Off]

/Basil

Jack Spitznagel <@flyingfrawg> writes:

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 <@flyingfrawg> 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








Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

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 <@flyingfrawg> 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












--
J Spitznagel
Science River LLC
KD4IZ


Re: Draws and IC-7000 #draws #ic7000 #minidin6

Basil Gunn
 

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 <@flyingfrawg> 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








Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

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

 

 


--
J Spitznagel
Science River LLC
KD4IZ


Re: possible DRAWS hardware failure.

Basil Gunn
 

Thanks, you nailed it. /dtparm=audio=on/ was before /dtovelay=/ and
/dtoverlay=draws. /Made the change and it fixed the problem. Someone
needs to make this change in the image. I didn't change the contents or
order of the commands in config.txt, just added # to comment out the
line and got FLDIGI to work on urdc (0,0).
When you enable the RPi bcm2835 audio device it enumerates first &
becomes hw:0,0 and the udrc becomes hw:1,0

Also on the image I use it does not matter where I put dtparm=audio=on
in the /boot/config.txt file.

I can't explain why aplay -l did not find the udrc device when you
enabled the bcm2835 audio device. The udrc not showing up with aplay -l is
certainly a symptom that the draws dtoverlay did not load.

Which Image are you using?

/Basil

I have been fighting with
the problem for about a week and convinced it was a hardware failure,
which was wrong, but not smart enough to know what it was or how to fix
it.

I am sure there are dozens of subtle problems in getting a product and
software launched. All of the players at NW digital providing support
have been great. Early adopting can be frustrating at times.

Thanks,

Joe

On 1/1/2019 7:40 PM, Annaliese McDermond wrote:
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 <@k3jv> 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




Re: Draws and IC-7000 #draws #ic7000 #minidin6

Basil Gunn
 

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


Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Daniel VE3NI
 

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@...> 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


Re: possible DRAWS hardware failure.

Joseph Vilardo
 

Annaliese

Thanks, you nailed it. dtparm=audio=on was before dtovelay= and dtoverlay=draws. Made the change and it fixed the problem. Someone needs to make this change in the image. I didn't change the contents or order of the commands in config.txt,  just added # to comment out the line and got FLDIGI to work on urdc (0,0).   I have been fighting with the problem for about a week and convinced it was a hardware failure, which was wrong,  but not smart enough to know what it was or how to fix it.

I am sure there are dozens of subtle problems in getting a product and software launched. All of the players at NW digital providing support have been great. Early adopting can be frustrating at times.

Thanks,

Joe

On 1/1/2019 7:40 PM, Annaliese McDermond wrote:
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





      





Re: Draws and IC-7000 #draws #ic7000 #minidin6

Jack Spitznagel
 

Thank you Annaliese,

Your answers below were a big help as they always are!

Had a few minutes to play today so I went through the current settings in alsamixer by browsing through the outputs of "amixer", "amixer scontents", and "amixer controls" (essentially the same list +/- the setting values). Did not see the "DAC Right|Left Playback Powertune" control listed.

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

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 Annaliese McDermond
Sent: Monday, December 31, 2018 18:44
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] Draws and IC-7000 #draws #ic7000 #miniDIN6



On Dec 31, 2018, at 1:34 PM, Jack Spitznagel <@flyingfrawg> 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.
Just change the pin you would like to disable to “Off.” For example, to turn off the discriminator input to the left DIN-6, you would set “IN1_L to Left Mixer Positive Resistor” to “Off” Likewise to change the 1200 baud/audio input off to the left DIN-6, you would set “IN2_L to Left Mixer Positive Resistor” to “Off"


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?
Default is PTM-P3

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?
Yes, this is audio/discriminator from the rig. Input from the DRAWS’s point of view.

Do they also impact the output to the rig? What you say below implies that... I am a little confused on this now.
No, it does not impact the output channels in any way. If you look at the analog routing diagram on the Wiki page, the resistor in question is represented by the switches between the various pins and the respective Mic PGA. They aren’t straight switches, they are either off, or they switch in a resistor of one of the three values.

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





--
J Spitznagel
Science River LLC
KD4IZ


Re: note about xastir and building from source #draws #xastir #aprs

Ken Koster
 

On Tuesday, January 1, 2019 4:25:51 PM PST Art - KC7SDA wrote:

> 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.

 

You could also remove the old xastir and it's config files with:

apt-get purge xastir

That will remove the config files, then build and install xastir.

 

Or if you want to keep the config files build xastir with:

../configure --prefix=/usr

 

That will place the new xastir in the same location as the repository package does.

 

> Also, as of this writing the beta images come with the binary version of

> xastir (version 2.0.8)

>

>

 

 

--

Ken - N7IPB

Email: n7ipb@...

JID: n7ipb@...

SvxLink Repeaters: http://pnw220.wetnet.net

PGP Sig: F42B EF90 3CD3 31C7 3056 122E 993A 7B2E 5138 C42A

“Contrariwise,' continued Tweedledee, 'if it was so, it might be;

and if it were so, it would be; but as it isn't, it ain't. That's logic.”


Re: note about xastir and building from source #draws #xastir #aprs

Basil Gunn
 

Debian File System Hierarchy Standard
https://wiki.debian.org/FilesystemHierarchyStandard

It's a debian convention that locally built binaries use:
/usr/local/var
/usr/local/etc
/usr/local/share
/usr/local/bin

programs installed with apt use:
/var
/etc
/usr/share
/bin

The install method for Xastir on the DRAWS image can be seen in the
n7nix/xastir/install.sh script.

- xastir is installed using apt-get
- a desktop icon is used that actually works
- xastir-sounds are installed to /usr/share/xastir-sounds

/Basil

Art - KC7SDA <@nouse4anick> writes:

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)


Re: possible DRAWS hardware failure.

Basil Gunn
 

From your description your system is either not loading the draws driver
or you have a hardware error.

Please send the output of showudrc.sh to my personal email address.

/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:

|****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.


Re: possible DRAWS hardware failure.

Annaliese McDermond
 

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 <@k3jv> 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



Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Annaliese McDermond
 

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


note about xastir and building from source #draws #xastir #aprs

Art - KC7SDA
 

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)


Re: possible DRAWS hardware failure.

Joseph Vilardo
 

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




Re: State of GPSD on boot and PPS2 #pps #gpsd #chrony

Daniel VE3NI
 

Hi Art,

 

Thanks for having a look at this.

 

John had pointed out to be that the ‘require’ at the end of the gps line was not required in my case and that the PPS2 was caused by the fact that when I ENABLED the line ‘refclock PPS  . . . . ’  I need to comment out the ‘refclock SHM 2 . . . ’  line in the chrony.conf file.

 

Since I did this I have not had any issue with ‘multiple’ PPSx showing up in sources.

 

pi@draws:~ $ chronyc sources -v

210 Number of sources = 6

 

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.

/ .- Source state '*' = current synced, '+' = combined , '-' = not combined,

| /   '?' = unreachable, 'x' = time may be in error, '~' = time too variable.

||                                                 .- xxxx [ yyyy ] +/- zzzz

||      Reachability register (octal) -.           |  xxxx = adjusted offset,

||      Log2(Polling interval) --.      |          |  yyyy = measured offset,

||                                \     |          |  zzzz = estimated error.

||                                 |    |           \

MS Name/IP address         Stratum Poll Reach LastRx Last sample              

===============================================================================

#x GPS                           0   3   377    13   -152ms[ -152ms] +/-  102ms

#* PPS1                          0   4   377    16   +249ns[ +389ns] +/-  251ns

^- zero.gotroot.ca               2   8   377    41  -1336us[-1336us] +/-   43ms

^- 2607:5300:60:975a::           2  10   377   303   -142us[ -142us] +/-   10ms

^- comet.spiderspace.co.uk       2   9   377   439  +1482us[+1483us] +/-   11ms

^- 2620:10a:800f::12             1  10   377    53   +283us[ +283us] +/-  504ms

pi@draws:~ $

 

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.

 

Cheers,

Daniel  VE3NI / NI2D

 

From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Art - KC7SDA
Sent: Tuesday, January 01, 2019 1:33 PM
To: udrc@nw-digital-radio.groups.io
Subject: Re: [udrc] State of GPSD on boot and PPS2

 

I was messing around last night and I think that if you don't remove 'require' at the end of the gps line it won't update based on the ntp server time chrony just hangs.

testing:
- shutdown pi
- remove gps antenna
- wait 10+ minutes
- boot pi
- use chronyc sources to verify

if you add the -v flag you get this output:


one of the time servers should be selected (either * or +).