Date   

Re: Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Russ Harper
 

Hi, Corky.  I ran the setalsa-ic7000.sh script again after reading your post and tried again unsuccessfully.  Here is the alsa-show.sh script output:

pi@raspberrypi:~/n7nix $ alsa-show.sh
 ==== List All sound card device names (3)
card 0: b1 [bcm2835 HDMI 1]
card 1: Headphones [bcm2835 Headphones]
card 2: udrc [udrc]

 ======= DRAWS
 ===== ALSA Controls for Radio Transmit =====
LO Driver Gain  L:[-6.00dB]    R:[-6.00dB]
PCM            L:[-26.50dB]    R:[-26.50dB]
DAC Playback PT    L:[P1]        R:[P1]
LO Playback CM    [Full Chip]

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

Here is a screenshot of fldigi controlling the radio:


I'm using SSB filter 2, passband of 2.7k and shift frequency of -25, sharp shape.  I'm not sure what you mean by gain; I don't see a gain setting or control in the manual.

Thanks
73
Russ
KF5WBI


Re: Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Corky
 

Sorry, that you are having trouble. The values in the script represent the latest values for the IC-7000. Note that there are actually 3 gain adjustments on DRAWS and the script modifies all three.

I am currently not able to get to either my radio or the attached DRAWS control card, so I will not be able to fully test what you are seeing until this Saturday. In the mean time can you please provide the output from the alsa-show.sh script so I can see what settings you are using. Also, what are the gain and filter settings on the IC-7000?

Thanks and 73,
-Corky, AF4PM


On Tue, Mar 30, 2021, at 7:23 AM, Russ Harper via groups.io wrote:
Hi, Corky.

Thanks for the quick reply.  I did run core setup and setalsa_ic7000.sh.  I noticed that the gain values produced by the script differed from those shown in n7nix/docs/RADIO_APP_NOTES.md.  So I to determine the proper gain values via the process described in Brian's video and your post, varied the digital gain values and saw no change in rig ALC on TX from fldigi. I don't believe there is a problem with the 7000.

I do have access to some more sophisticated measurement capability via a Diligent Analog Discovery 2 (Oscilloscope and others) so can perhaps do some more investigation with a bit of direction.

Thanks
73
Russ
KF5WBI


Re: Direwolf CPU utilization = 100% #direwolf

Basil Gunn
 

I have to run out & do some other stuff for the rest of the day but this
is what I think.

You have a pulseaudio/direwolf configuration problem. Pulseaudio
recently switched their systemd service files from "system" to "user" and
that I believe is the problem.

Also when you switch to one channel direwolf (split channel) config you must
use the pulseaudio virtual device names ie.

Change:
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
to
ADEVICE draws-capture-left draws-playback-left

Go to directory n7nix/splitchan and run the following script. I have
some pretty thin notes there (sorry).

./split_ctrl.sh status

Also try this experiment: With your one interface direwolf config switch
off all pulseaudio system files then run 'cpu_util.sh' to get a utilization
number.

To switch off all pulseaudio system files
sudo su
systemctl --system stop pulseaudio
systemctl --user stop pulseaudio

This only stops pulseaudio until the next reboot.
To stop pulse audio between reboots you must also disable them.

systemctl --system disable pulseaudio
systemctl --user disable pulseaudio

I couldn't get direwolf to recognize pulseaudio interface names when using
'user' service files. My scripts only set up 'system' service files.

Will respond later on today.

Dan Keizer <ve4drk@gmail.com> writes:

Hey Basil - thanks for that info.

The local 2m 145.01 frequency is being used as a test to another RMS
gateway. It's extremely quiet. Currently two stations that only use it for
RMS gateway message testing.
I did add the second channel back into this config.
Attaching the output of the new script where the second channel is attached
with direwolf: (pretty much stock config). (below that is the one channel
config)

pi@draws:~ $ cpu_util.sh
== pi version
Pi 3 Model B, Rev 1.2, Mfg by Embest with WiFi

== direwolf version
Found direwolf version: 1.6 : Dire Wolf version 1.6

== pulseaudio version
pulseaudio 12.2

== pulseaudio status
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled;
vendor preset: enabled)
Active: active (running) since Tue 2021-03-30 07:29:12 CDT; 4h 15min ago
Main PID: 1267 (pulseaudio)
CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service
└─1267 /usr/bin/pulseaudio --daemonize=no

Mar 30 07:29:11 draws.ve4drk systemd[1031]: Starting Sound Service...
Mar 30 07:29:12 draws.ve4drk systemd[1031]: Started Sound Service.

== cpu utilization (ps)
root 1623 27.1 0.9 140368 9104 ? Ssl 07:53 62:37
/usr/bin/direwolf -t 0 -c /etc/direwolf.conf -p
root 316 0.6 0.0 0 0 ? S 07:29 1:34 [sc16is7xx]
gpsd 609 0.4 0.3 22636 3176 ? S<sl 07:29 1:08
/usr/sbin/gpsd -n /dev/ttySC0 /dev/pps0
root 2179 0.1 0.0 0 0 ? I 11:44 0:00
[kworker/0:1-events]
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

Installing sysstat package
Preconfiguring packages ...
Selecting previously unselected package sysstat.
(Reading database ... 123981 files and directories currently installed.)
Preparing to unpack .../sysstat_12.0.3-2_armhf.deb ...
Unpacking sysstat (12.0.3-2) ...
Setting up sysstat (12.0.3-2) ...

Creating config file /etc/default/sysstat with new version
update-alternatives: using /usr/bin/sar.sysstat to provide /usr/bin/sar
(sar) in auto mode
Created symlink /etc/systemd/system/multi-user.target.wants/sysstat.service
→ /lib/systemd/system/sysstat.service.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u6+rpi1) ...

== ALL cpu utilizations (mpstat)
Linux 5.4.79-v7+ (draws.ve4drk) 2021-03-30 _armv7l_ (4
CPU)

11:44:55 AM CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %gnice %idle
11:44:55 AM all 6.33 0.00 3.02 0.09 0.00 0.03 0.00
0.00 0.00 90.53
11:44:55 AM 0 3.62 0.00 1.05 0.15 0.00 0.10 0.00
0.00 0.00 95.09
11:44:55 AM 1 3.26 0.00 2.37 0.10 0.00 0.00 0.00
0.00 0.00 94.27
11:44:55 AM 2 2.86 0.00 6.87 0.07 0.00 0.00 0.00
0.00 0.00 90.20
11:44:55 AM 3 15.59 0.00 1.78 0.06 0.00 0.01 0.00
0.00 0.00 82.56

== Direwolf config
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 2
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
CHANNEL 1
PTT GPIO 23
MODEM 300 1600:1800 7@30 /4
MYCALL VE4DRK-2
AGWPORT 8000
KISSPORT 8001

IGSERVER 50.65.148.226

IGLOGIN VE4DRK 17320
FILTER IG 0 t/m
IGTXLIMIT 6 30
TTPOINT B01 37^55.37N 81^7.86W
TTPOINT B7495088 42.605237 -71.34456
TTPOINT B934 42.605237 -71.34456
TTPOINT B901 42.661279 -71.364452
TTPOINT B902 42.660411 -71.364419
TTPOINT B903 42.659046 -71.364452
TTPOINT B904 42.657578 -71.364602
TTVECTOR B5bbbddd 37^55.37N 81^7.86W 0.01 mi
TTGRID Byyyxxx 37^50.00N 81^00.00W 37^59.99N 81^09.99W
TTUTM B6xxxyyy 19T 10 300000 4720000
TTCORRAL 37^55.50N 81^7.00W 0^0.02N
TTMACRO xx1yy B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO xx2yy B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO xxyyy B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO z Cz

---------------------------------------------------------------------------------------------------------------------------------

Changed the config to be one port for direwolf and rebooted.
Here's the output of the script with only ONE port defined for direwolf:

pi@draws:~ $ cpu_util.sh
== pi version
Pi 3 Model B, Rev 1.2, Mfg by Embest with WiFi

== direwolf version
Found direwolf version: 1.6 : Dire Wolf version 1.6

== pulseaudio version
pulseaudio 12.2

== pulseaudio status
● pulseaudio.service - Sound Service
Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled;
vendor preset: enabled)
Active: active (running) since Tue 2021-03-30 11:50:23 CDT; 3min 3s ago
Main PID: 1287 (pulseaudio)
CGroup: /user.slice/user-1000.slice/user@1000.service/pulseaudio.service
└─1287 /usr/bin/pulseaudio --daemonize=no

Mar 30 11:50:21 draws.ve4drk systemd[1078]: Starting Sound Service...
Mar 30 11:50:23 draws.ve4drk systemd[1078]: Started Sound Service.

== cpu utilization (ps)
root 542 98.6 0.8 128864 8040 ? Ssl 11:50 3:09
/usr/bin/direwolf -t 0 -c /etc/direwolf.conf -p
root 1 1.7 0.8 33776 8160 ? Ss 11:50 0:03 /sbin/init
splash
pi 1365 1.6 0.3 8488 3632 pts/3 Ss 11:53 0:00 -bash
pi 1212 0.9 2.9 46324 27916 ? S 11:50 0:01
/usr/bin/python3 /usr/share/system-config-printer/applet.py
pi 1183 0.9 2.1 72756 20796 ? Sl 11:50 0:01 pcmanfm
--desktop --profile LXDE-pi

== ALL cpu utilizations (mpstat)
Linux 5.4.79-v7+ (draws.ve4drk) 2021-03-30 _armv7l_ (4
CPU)

11:53:26 AM CPU %usr %nice %sys %iowait %irq %soft %steal
%guest %gnice %idle
11:53:26 AM all 5.45 0.00 23.63 5.05 0.00 0.22 0.00
0.00 0.00 65.65
11:53:26 AM 0 6.77 0.00 33.12 4.91 0.00 0.75 0.00
0.00 0.00 54.44
11:53:26 AM 1 6.07 0.00 23.70 5.57 0.00 0.07 0.00
0.00 0.00 64.60
11:53:26 AM 2 5.27 0.00 31.91 3.84 0.00 0.02 0.00
0.00 0.00 58.95
11:53:26 AM 3 3.69 0.00 5.88 5.88 0.00 0.03 0.00
0.00 0.00 84.53

== Direwolf config
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 1
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
AGWPORT 8000
KISSPORT 8001

IGSERVER 50.65.148.226

IGLOGIN VE4DRK 17320
FILTER IG 0 t/m
IGTXLIMIT 6 30
TTPOINT B01 37^55.37N 81^7.86W
TTPOINT B7495088 42.605237 -71.34456
TTPOINT B934 42.605237 -71.34456
TTPOINT B901 42.661279 -71.364452
TTPOINT B902 42.660411 -71.364419
TTPOINT B903 42.659046 -71.364452
TTPOINT B904 42.657578 -71.364602
TTVECTOR B5bbbddd 37^55.37N 81^7.86W 0.01 mi
TTGRID Byyyxxx 37^50.00N 81^00.00W 37^59.99N 81^09.99W
TTUTM B6xxxyyy 19T 10 300000 4720000
TTCORRAL 37^55.50N 81^7.00W 0^0.02N
TTMACRO xx1yy B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO xx2yy B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO xxyyy B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO z Cz

this config with one port for direwolf has sustained 100% one core usage.

Dan.


On Tue, Mar 30, 2021 at 11:28 AM Basil Gunn <basil@pacabunga.com> wrote:


Dan,

You may have a pulseaudio config problem?
What frequency is your VHF radio set to?
APRS 2M frequency? How busy is it?

Please post the output of script cpu_util.sh

cpu_util.sh is a new script to try and solve your problem so refresh
your local n7nix repository:

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

cpu_util.sh



Dan Keizer <ve4drk@gmail.com> writes:

I've updated my image to hold back the bad kernel and i've ensure my
apps are up to date.
I noticed that since then, the direwolf process is consuming an entire
core 100%.
It never used to do that and I've not seen that with other non-udrc uses
with direwolf on my other Pi's.
Curious if anyone has noticed this before or if there is a known
issue/config I haven't found yet.
I checked my direwolf configuration and nothing out of the ordinary. one
channel currently on ax25 vhf. (basic config here):
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 1
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
AGWPORT 8000
KISSPORT 8001

(hoping to go to split channel if i can figure out this cpu issue).
I noticed a rather old posting by WB02SZ:

Dire Wolf uses many threads for the various concurrent activities. Each
audio input device has its own thread which reads data as quickly as the
source can provide it. In this case, the null device provides zero bytes
at an unlimited rate and one CPU core is completely consumed
SO, to check this theory, I added back channel 2 into my direwolf config
and stopped/restarted direwolf -- sure enough, the high cpu load went away
and it's back down to approx 20% to 30% or so on one core -- which is
normal.

So, with me trying to take direwolf out of using both channels and
allocate one to HF with pulseaudio ... is this expected behaviour from
direwolf? and are others seeing similar results? or am i missing some other
configuration to get direwolf to stop trying to read null streams and
becoming cpu bound.

73, Dan ve4drk








Re: Direwolf CPU utilization = 100% #direwolf

Dan Keizer
 

Hey Basil - thanks for that info.

The local 2m 145.01 frequency is being used as a test to another RMS gateway. It's extremely quiet. Currently two stations that only use it for RMS gateway message testing.
I did add the second channel back into this config.
Attaching the output of the new script where the second channel is attached with direwolf: (pretty much stock config). (below that is the one channel config)

pi@draws:~ $ cpu_util.sh
== pi version
 Pi 3 Model B, Rev 1.2, Mfg by Embest with WiFi

== direwolf version
Found direwolf version: 1.6 : Dire Wolf version 1.6

== pulseaudio version
pulseaudio 12.2

== pulseaudio status
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-03-30 07:29:12 CDT; 4h 15min ago
 Main PID: 1267 (pulseaudio)
   CGroup: /user.slice/user-1000.slice/user@.../pulseaudio.service
           └─1267 /usr/bin/pulseaudio --daemonize=no

Mar 30 07:29:11 draws.ve4drk systemd[1031]: Starting Sound Service...
Mar 30 07:29:12 draws.ve4drk systemd[1031]: Started Sound Service.

== cpu utilization (ps)
root      1623 27.1  0.9 140368  9104 ?        Ssl  07:53  62:37 /usr/bin/direwolf -t 0 -c /etc/direwolf.conf -p
root       316  0.6  0.0      0     0 ?        S    07:29   1:34 [sc16is7xx]
gpsd       609  0.4  0.3  22636  3176 ?        S<sl 07:29   1:08 /usr/sbin/gpsd -n /dev/ttySC0 /dev/pps0
root      2179  0.1  0.0      0     0 ?        I    11:44   0:00 [kworker/0:1-events]
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

Installing sysstat package
Preconfiguring packages ...
Selecting previously unselected package sysstat.
(Reading database ... 123981 files and directories currently installed.)
Preparing to unpack .../sysstat_12.0.3-2_armhf.deb ...
Unpacking sysstat (12.0.3-2) ...
Setting up sysstat (12.0.3-2) ...

Creating config file /etc/default/sysstat with new version
update-alternatives: using /usr/bin/sar.sysstat to provide /usr/bin/sar (sar) in auto mode
Created symlink /etc/systemd/system/multi-user.target.wants/sysstat.service → /lib/systemd/system/sysstat.service.
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u6+rpi1) ...

== ALL cpu utilizations (mpstat)
Linux 5.4.79-v7+ (draws.ve4drk)         2021-03-30      _armv7l_        (4 CPU)

11:44:55 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
11:44:55 AM  all    6.33    0.00    3.02    0.09    0.00    0.03    0.00    0.00    0.00   90.53
11:44:55 AM    0    3.62    0.00    1.05    0.15    0.00    0.10    0.00    0.00    0.00   95.09
11:44:55 AM    1    3.26    0.00    2.37    0.10    0.00    0.00    0.00    0.00    0.00   94.27
11:44:55 AM    2    2.86    0.00    6.87    0.07    0.00    0.00    0.00    0.00    0.00   90.20
11:44:55 AM    3   15.59    0.00    1.78    0.06    0.00    0.01    0.00    0.00    0.00   82.56

== Direwolf config
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 2
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
CHANNEL 1
PTT GPIO 23
MODEM 300 1600:1800 7@30 /4
MYCALL VE4DRK-2
AGWPORT 8000
KISSPORT 8001

IGSERVER 50.65.148.226

IGLOGIN VE4DRK 17320
FILTER IG 0 t/m
IGTXLIMIT 6 30
TTPOINT  B01  37^55.37N  81^7.86W
TTPOINT  B7495088  42.605237  -71.34456
TTPOINT  B934  42.605237  -71.34456
TTPOINT B901  42.661279  -71.364452
TTPOINT B902  42.660411  -71.364419
TTPOINT B903  42.659046  -71.364452
TTPOINT B904  42.657578  -71.364602
TTVECTOR  B5bbbddd  37^55.37N  81^7.86W  0.01  mi
TTGRID   Byyyxxx    37^50.00N  81^00.00W  37^59.99N  81^09.99W
TTUTM  B6xxxyyy  19T  10  300000  4720000
TTCORRAL   37^55.50N  81^7.00W  0^0.02N
TTMACRO  xx1yy  B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO  xx2yy  B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO  xxyyy  B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO  z  Cz

---------------------------------------------------------------------------------------------------------------------------------

Changed the config to be one port for direwolf and rebooted.
Here's the output of the script with only ONE port defined for direwolf:

pi@draws:~ $ cpu_util.sh
== pi version
 Pi 3 Model B, Rev 1.2, Mfg by Embest with WiFi

== direwolf version
Found direwolf version: 1.6 : Dire Wolf version 1.6

== pulseaudio version
pulseaudio 12.2

== pulseaudio status
● pulseaudio.service - Sound Service
   Loaded: loaded (/usr/lib/systemd/user/pulseaudio.service; disabled; vendor preset: enabled)
   Active: active (running) since Tue 2021-03-30 11:50:23 CDT; 3min 3s ago
 Main PID: 1287 (pulseaudio)
   CGroup: /user.slice/user-1000.slice/user@.../pulseaudio.service
           └─1287 /usr/bin/pulseaudio --daemonize=no

Mar 30 11:50:21 draws.ve4drk systemd[1078]: Starting Sound Service...
Mar 30 11:50:23 draws.ve4drk systemd[1078]: Started Sound Service.

== cpu utilization (ps)
root       542 98.6  0.8 128864  8040 ?        Ssl  11:50   3:09 /usr/bin/direwolf -t 0 -c /etc/direwolf.conf -p
root         1  1.7  0.8  33776  8160 ?        Ss   11:50   0:03 /sbin/init splash
pi        1365  1.6  0.3   8488  3632 pts/3    Ss   11:53   0:00 -bash
pi        1212  0.9  2.9  46324 27916 ?        S    11:50   0:01 /usr/bin/python3 /usr/share/system-config-printer/applet.py
pi        1183  0.9  2.1  72756 20796 ?        Sl   11:50   0:01 pcmanfm --desktop --profile LXDE-pi

== ALL cpu utilizations (mpstat)
Linux 5.4.79-v7+ (draws.ve4drk)         2021-03-30      _armv7l_        (4 CPU)

11:53:26 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
11:53:26 AM  all    5.45    0.00   23.63    5.05    0.00    0.22    0.00    0.00    0.00   65.65
11:53:26 AM    0    6.77    0.00   33.12    4.91    0.00    0.75    0.00    0.00    0.00   54.44
11:53:26 AM    1    6.07    0.00   23.70    5.57    0.00    0.07    0.00    0.00    0.00   64.60
11:53:26 AM    2    5.27    0.00   31.91    3.84    0.00    0.02    0.00    0.00    0.00   58.95
11:53:26 AM    3    3.69    0.00    5.88    5.88    0.00    0.03    0.00    0.00    0.00   84.53

== Direwolf config
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 1
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
AGWPORT 8000
KISSPORT 8001

IGSERVER 50.65.148.226

IGLOGIN VE4DRK 17320
FILTER IG 0 t/m
IGTXLIMIT 6 30
TTPOINT  B01  37^55.37N  81^7.86W
TTPOINT  B7495088  42.605237  -71.34456
TTPOINT  B934  42.605237  -71.34456
TTPOINT B901  42.661279  -71.364452
TTPOINT B902  42.660411  -71.364419
TTPOINT B903  42.659046  -71.364452
TTPOINT B904  42.657578  -71.364602
TTVECTOR  B5bbbddd  37^55.37N  81^7.86W  0.01  mi
TTGRID   Byyyxxx    37^50.00N  81^00.00W  37^59.99N  81^09.99W
TTUTM  B6xxxyyy  19T  10  300000  4720000
TTCORRAL   37^55.50N  81^7.00W  0^0.02N
TTMACRO  xx1yy  B9xx*AB166*AA2B4C5B3B0A1yy
TTMACRO  xx2yy  B9xx*AB170*AA3C4C7C3B0A2yy
TTMACRO  xxyyy  B9xx*AB180*AA3A6C4A0Ayyy
TTMACRO  z  Cz

this config with one port for direwolf has sustained 100% one core usage.

Dan.


On Tue, Mar 30, 2021 at 11:28 AM Basil Gunn <basil@...> wrote:

Dan,

You may have a pulseaudio config problem?
What frequency is your VHF radio set to?
APRS 2M frequency? How busy is it?

Please post the output of script cpu_util.sh

cpu_util.sh is a new script to try and solve your problem so refresh
your local n7nix repository:

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

cpu_util.sh



Dan Keizer <ve4drk@...> writes:

> I've updated my image to hold back the bad kernel and i've ensure my apps are up to date.
> I noticed that since then, the direwolf process is consuming an entire core 100%.
> It never used to do that and I've not seen that with other non-udrc uses with direwolf on my other Pi's.
> Curious if anyone has noticed this before or if there is a known issue/config I haven't found yet.
> I checked my direwolf configuration and nothing out of the ordinary. one channel currently on ax25 vhf. (basic config here):
> ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
> ACHANNELS 1
> CHANNEL 0
> MYCALL VE4DRK-10
> MODEM 1200
> PTT GPIO 12
> AGWPORT 8000
> KISSPORT 8001
>
> (hoping to go to split channel if i can figure out this cpu issue).
> I noticed a rather old posting by WB02SZ:
>>
>> Dire Wolf uses many threads for the various concurrent activities. Each
>> audio input device has its own thread which reads data as quickly as the
>> source can provide it. In this case, the null device provides zero bytes
>> at an unlimited rate and one CPU core is completely consumed
>
> SO, to check this theory, I added back channel 2 into my direwolf config and stopped/restarted direwolf -- sure enough, the high cpu load went away and it's back down to approx 20% to 30% or so on one core -- which is normal.
>
> So, with me trying to take direwolf out of using both channels and allocate one to HF with pulseaudio ... is this expected behaviour from direwolf? and are others seeing similar results? or am i missing some other configuration to get direwolf to stop trying to read null streams and becoming cpu bound.
>
> 73, Dan ve4drk
>
>
>






Re: Direwolf CPU utilization = 100% #direwolf

Basil Gunn
 

Dan,

You may have a pulseaudio config problem?
What frequency is your VHF radio set to?
APRS 2M frequency? How busy is it?

Please post the output of script cpu_util.sh

cpu_util.sh is a new script to try and solve your problem so refresh
your local n7nix repository:

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

cpu_util.sh



Dan Keizer <ve4drk@gmail.com> writes:

I've updated my image to hold back the bad kernel and i've ensure my apps are up to date.
I noticed that since then, the direwolf process is consuming an entire core 100%.
It never used to do that and I've not seen that with other non-udrc uses with direwolf on my other Pi's.
Curious if anyone has noticed this before or if there is a known issue/config I haven't found yet.
I checked my direwolf configuration and nothing out of the ordinary. one channel currently on ax25 vhf. (basic config here):
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 1
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
AGWPORT 8000
KISSPORT 8001

(hoping to go to split channel if i can figure out this cpu issue).
I noticed a rather old posting by WB02SZ:

Dire Wolf uses many threads for the various concurrent activities. Each
audio input device has its own thread which reads data as quickly as the
source can provide it. In this case, the null device provides zero bytes
at an unlimited rate and one CPU core is completely consumed
SO, to check this theory, I added back channel 2 into my direwolf config and stopped/restarted direwolf -- sure enough, the high cpu load went away and it's back down to approx 20% to 30% or so on one core -- which is normal.

So, with me trying to take direwolf out of using both channels and allocate one to HF with pulseaudio ... is this expected behaviour from direwolf? and are others seeing similar results? or am i missing some other configuration to get direwolf to stop trying to read null streams and becoming cpu bound.

73, Dan ve4drk



Re: Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Jack Spitznagel
 

Corky,

 

The exchanges between you and Russ have inspired me to try to configure my DRAWS and IC-7000 to work with fldigi again. I will try to hunt down your earlier messages about this.

 

I played with it extensively not too long after the DRAWS early experience boards were released. At the time, I was able to use Basil’s IC-7000 setalsa bash script to get XASTIR (default core script install/Direwolf) to work well.  

 

Here is where things went south: So, fldigi did not work when the AX.25 setup was turned off, the rig switched to USB on an HF band, and when the setalsa-ic7000.sh settings are left alone. An attempt to use fldigi to transmit a basic RTTY diddle produces no sound except a background clicking and pulsing noise.

 

In order to hear any digital mode sound at all from the DRAWS, I have to max out the digital and analog gain using Manager and reduce the transmit attenuation in fldigi to 0.0. I can hear transmitted tones clearly but the rig shows no power and little indication of ALC. I can decode the fldigi generated RTTY on a in IC-705 once I can hear the tone, but I have no idea whether enough power is being produced to be useful, it certainly does not register on the meter.

 

I am now wondering if there are some rig settings that are wrong. Did you have to do anything rig specific to get HF output of the IC-7000 to be what it should?

 

I could post as clear a summary as I can with a couple of audio samples, if it would help.

 

KD4IZ

Jack Spitznagel

FM19oo

 

From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On Behalf Of Corky Searls
Sent: Monday, March 29, 2021 21:57
To: udrc@nw-digital-radio.groups.io
Subject: Re: [draws and udrc] Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

 

There is a setalsa_ic7000.sh script in the n7nix/bin directory (it should also be in pi p/bin if you ran the core setup). This should set all the necessary parameters for using the IC-7000 and properly set the levels for use with fldigi. Unless you ran the core setup, there are a number of other DRAWS parameters that need to be set to properly configure DRAWS.

 

The easiest answer is to run the core setup (This should only be run once, so if you have already done this there is no need to repeat) and then use the setting script for the audio levels.

 

If you still have difficulty come back here as I have an IC-7000 that I have been using for HF digital for several years and it works great.

 

Thanks and 73,

-Corky, AF4PM

 

 

On Mon, Mar 29, 2021, at 4:41 PM, Russ Harper via groups.io wrote:

Hello to the group.

 

I purchased a DRAWS Hat last year and tried to get it working with my IC-7000 to run Pat Winlink on the RPI3+.  I knew virtually nothing about digital modes, so wasn't successful - reception was good, but no station received my transmissions.  I figured out that I needed to set levels, but was over my head at the time.

Fast forward to this year.  I purchased a new IC-7300 and got it working with Pat WInlink on the RPI4 using the internal -7300 internal sound card.  Through that process I learned a lot more about digital.

 

Now I'm revisiting the -7000, and have tried to set levels after watching the "Setting the TX Level on the NW DIgital Radio DRAWS Hat" video.  I also saw post # 5611 by Corky detailing some specific steps due to potential conflicts between fldigi and alsamixer.

 

I followed the specific steps, using draws-manager and alsamixer in tandem.  I used alsamixer to reduce pcm to zero, saw the value of -47.5 dB, and used draws-manager to set that value.  I started flrig, then fldigi.  The result was 4 bars ALC on the rig when commanded by the TX button in fldigi.  That seemed strange, so I shut down flrig & fldigi and repeated the process with a value of -25 dB, and got the same result.  Finally, I used a value of -10 dB and got the same result.

 

Prior to starting, I did a git pull for both the distribution and draws-manager, so both should be current.

 

The rig operates well on SSB.

 

Any recommendations or insights would be welcome; I see I'm not the only one working this issue.  Also please advise what information / details are needed for further insight.  The rig is set up with no preamp, no notch filter no noise reduction, no noise blanking, passband filter 2, fast AGC.

 

Thanks for developing and selling this great piece of kit.  This will be fantastic for portable ops with my old tech rig when it's sorted out.

 

73

Russ

KF5WBI

 


Re: Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Russ Harper
 

Hi, Corky.

Thanks for the quick reply.  I did run core setup and setalsa_ic7000.sh.  I noticed that the gain values produced by the script differed from those shown in n7nix/docs/RADIO_APP_NOTES.md.  So I to determine the proper gain values via the process described in Brian's video and your post, varied the digital gain values and saw no change in rig ALC on TX from fldigi. I don't believe there is a problem with the 7000.

I do have access to some more sophisticated measurement capability via a Diligent Analog Discovery 2 (Oscilloscope and others) so can perhaps do some more investigation with a bit of direction.

Thanks
73
Russ
KF5WBI


Direwolf CPU utilization = 100% #direwolf

Dan Keizer
 

I've updated my image to hold back the bad kernel and i've ensure my apps are up to date.
I noticed that since then, the direwolf process is consuming an entire core 100%.
It never used to do that and I've not seen that with other non-udrc uses with direwolf on my other Pi's.
Curious if anyone has noticed this before or if there is a known issue/config I haven't found yet.
I checked my direwolf configuration and nothing out of the ordinary.  one channel currently on ax25 vhf. (basic config here):
ADEVICE plughw:CARD=udrc,DEV=0 plughw:CARD=udrc,DEV=0
ACHANNELS 1
CHANNEL 0
MYCALL VE4DRK-10
MODEM 1200
PTT GPIO 12
AGWPORT 8000
KISSPORT 8001

(hoping to go to split channel if i can figure out this cpu issue).
I noticed a rather old posting by WB02SZ:
Dire Wolf uses many threads for the various concurrent activities. Each audio input device has its own thread which reads data as quickly as the source can provide it. In this case, the null device provides zero bytes at an unlimited rate and one CPU core is completely consumed
SO, to check this theory, I added back channel 2 into my direwolf config and stopped/restarted direwolf -- sure enough, the high cpu load went away and it's back down to approx 20% to 30% or so on one core  -- which is normal.

So, with me trying to take direwolf out of using both channels and allocate one to HF with pulseaudio ... is this expected behaviour from direwolf? and are others seeing similar results? or am i missing some other configuration to get direwolf to stop trying to read null streams and becoming cpu bound.

73, Dan ve4drk


Re: Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Corky
 

There is a setalsa_ic7000.sh script in the n7nix/bin directory (it should also be in pi p/bin if you ran the core setup). This should set all the necessary parameters for using the IC-7000 and properly set the levels for use with fldigi. Unless you ran the core setup, there are a number of other DRAWS parameters that need to be set to properly configure DRAWS.

The easiest answer is to run the core setup (This should only be run once, so if you have already done this there is no need to repeat) and then use the setting script for the audio levels.

If you still have difficulty come back here as I have an IC-7000 that I have been using for HF digital for several years and it works great.

Thanks and 73,
-Corky, AF4PM


On Mon, Mar 29, 2021, at 4:41 PM, Russ Harper via groups.io wrote:

Hello to the group.

I purchased a DRAWS Hat last year and tried to get it working with my IC-7000 to run Pat Winlink on the RPI3+.  I knew virtually nothing about digital modes, so wasn't successful - reception was good, but no station received my transmissions.  I figured out that I needed to set levels, but was over my head at the time.

Fast forward to this year.  I purchased a new IC-7300 and got it working with Pat WInlink on the RPI4 using the internal -7300 internal sound card.  Through that process I learned a lot more about digital.

Now I'm revisiting the -7000, and have tried to set levels after watching the "Setting the TX Level on the NW DIgital Radio DRAWS Hat" video.  I also saw post # 5611 by Corky detailing some specific steps due to potential conflicts between fldigi and alsamixer.

I followed the specific steps, using draws-manager and alsamixer in tandem.  I used alsamixer to reduce pcm to zero, saw the value of -47.5 dB, and used draws-manager to set that value.  I started flrig, then fldigi.  The result was 4 bars ALC on the rig when commanded by the TX button in fldigi.  That seemed strange, so I shut down flrig & fldigi and repeated the process with a value of -25 dB, and got the same result.  Finally, I used a value of -10 dB and got the same result.

Prior to starting, I did a git pull for both the distribution and draws-manager, so both should be current.

The rig operates well on SSB.

Any recommendations or insights would be welcome; I see I'm not the only one working this issue.  Also please advise what information / details are needed for further insight.  The rig is set up with no preamp, no notch filter no noise reduction, no noise blanking, passband filter 2, fast AGC.

Thanks for developing and selling this great piece of kit.  This will be fantastic for portable ops with my old tech rig when it's sorted out.

73
Russ
KF5WBI



Another guy trying to set DRAWS Hat levels for an IC-7000 #ic-7000 #draws

Russ Harper
 

Hello to the group.

I purchased a DRAWS Hat last year and tried to get it working with my IC-7000 to run Pat Winlink on the RPI3+.  I knew virtually nothing about digital modes, so wasn't successful - reception was good, but no station received my transmissions.  I figured out that I needed to set levels, but was over my head at the time.

Fast forward to this year.  I purchased a new IC-7300 and got it working with Pat WInlink on the RPI4 using the internal -7300 internal sound card.  Through that process I learned a lot more about digital.

Now I'm revisiting the -7000, and have tried to set levels after watching the "Setting the TX Level on the NW DIgital Radio DRAWS Hat" video.  I also saw post # 5611 by Corky detailing some specific steps due to potential conflicts between fldigi and alsamixer.

I followed the specific steps, using draws-manager and alsamixer in tandem.  I used alsamixer to reduce pcm to zero, saw the value of -47.5 dB, and used draws-manager to set that value.  I started flrig, then fldigi.  The result was 4 bars ALC on the rig when commanded by the TX button in fldigi.  That seemed strange, so I shut down flrig & fldigi and repeated the process with a value of -25 dB, and got the same result.  Finally, I used a value of -10 dB and got the same result.

Prior to starting, I did a git pull for both the distribution and draws-manager, so both should be current.

The rig operates well on SSB.

Any recommendations or insights would be welcome; I see I'm not the only one working this issue.  Also please advise what information / details are needed for further insight.  The rig is set up with no preamp, no notch filter no noise reduction, no noise blanking, passband filter 2, fast AGC.

Thanks for developing and selling this great piece of kit.  This will be fantastic for portable ops with my old tech rig when it's sorted out.

73
Russ
KF5WBI


Re: GPS not recognized

William McKeehan (KI4HDU)
 

yes, that error is what I was referring to....looks like things are
working for me again.

Thanks for the support!

On Mon, Mar 29, 2021 at 4:10 PM Basil Gunn <basil@pacabunga.com> wrote:


After following the directions in that post, I still have an
issue....output of buginfo.sh below.
If by issue you are referring to:

" brcmfmac mmc1:0001:1:
Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2"

-2 means file not found. I see this error a lot for instance on my RPi 4
I get this.

"Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2"

It appears that file is missing or more likely wrong path or file name
anyway it seems benign.

From your buginfo.sh output I get:

Codec driver tlv320aic32x4-hifi loaded OK
DRAWS was enumerated
i2c serial devices are OK
gpsd is OK

and that's as good as it gets.


$ ./buginfo.sh
== Kernel version:
Linux ki4hdu-home 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020
armv7l GNU/Linux

== Firmware version:
Nov 18 2020 19:59:22
Copyright (c) 2012 Broadcom
version 8e01026adc5a87d80f8748fc6a4fecb9012393cc (clean) (release) (start)

== Codec driver check:
[ 9.649099] asoc-simple-card soc:sound: tlv320aic32x4-hifi <->
3f203000.i2s mapping ok

== DRAWS driver check:
udrc card number line: card 3: udrc [udrc], device 0:
bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0
[bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0]
udrc is sound card #3

== Boot 'fail' check:
[ 8.161416] brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2

== GPS check:
Serial devices OK
gpsd OK

== Pi Version
Pi 3 Model B, Rev 1.2, Mfg by Sony UK with WiFi



--
William
KI4HDU


Re: GPS not recognized

Basil Gunn
 

After following the directions in that post, I still have an
issue....output of buginfo.sh below.
If by issue you are referring to:

" brcmfmac mmc1:0001:1:
Direct firmware load for brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2"

-2 means file not found. I see this error a lot for instance on my RPi 4
I get this.

"Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.txt failed with error -2"

It appears that file is missing or more likely wrong path or file name
anyway it seems benign.

From your buginfo.sh output I get:

Codec driver tlv320aic32x4-hifi loaded OK
DRAWS was enumerated
i2c serial devices are OK
gpsd is OK

and that's as good as it gets.


$ ./buginfo.sh
== Kernel version:
Linux ki4hdu-home 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020
armv7l GNU/Linux

== Firmware version:
Nov 18 2020 19:59:22
Copyright (c) 2012 Broadcom
version 8e01026adc5a87d80f8748fc6a4fecb9012393cc (clean) (release) (start)

== Codec driver check:
[ 9.649099] asoc-simple-card soc:sound: tlv320aic32x4-hifi <->
3f203000.i2s mapping ok

== DRAWS driver check:
udrc card number line: card 3: udrc [udrc], device 0:
bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0
[bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0]
udrc is sound card #3

== Boot 'fail' check:
[ 8.161416] brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2

== GPS check:
Serial devices OK
gpsd OK

== Pi Version
Pi 3 Model B, Rev 1.2, Mfg by Sony UK with WiFi


Re: GPS not recognized

Dan Keizer
 

thanks for this info Basil - i also had missed this earlier and was trying to figure out what i was doing wrong.
Now, i'll work on trying to get my split vhf/hf operations running :-) i did log your prior emails on that subject to refer to.

73, Dan ve4drk


On Mon, Mar 29, 2021 at 12:20 PM Basil Gunn <basil@...> wrote:

> Is there an easy fix for this?

RPi kernel upgrade problem
https://nw-digital-radio.groups.io/g/udrc/message/5475

Even though your TI tlv320aic32x4 codec was enumerated, the serial ports
on the i2c buss for the gps script failed.
Both the codec & i2c buss problems are intermittent, that is, on any
given boot the devices may not properly work.

The above link to my Feb groups.io post tells you every thing you need
to know in order to revert your kernel version and put a hold on it to
get things working again.

Using script buginfo.sh is a quicker way to get relevant information on
these 2 kernel problems.

To get the latest buginfo.sh script

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

There are 3 patches recently submitted to fix these problem:

[PATCH 1/2] ASoC: tlv320aic32x4: Increase maximum register in regmap
[PATCH 2/2] ASoC: tlv320aic32x4: Register clocks before registering component
[PATCH] sc16is7xx: Defer probe if device read fails


William McKeehan (KI4HDU) <ki4hdu@...> writes:

> I recently did a `apt upgrade` to my pi that has my draws hat on
> it...since then, the GPS no longer "works" (i.e., the devices are not
> present in `/dev`).
>
> Is there an easy fix for this?






Re: GPS not recognized

William McKeehan (KI4HDU)
 

I figured it was something like that, but my googling of the problem
did not lead me to that post, so thanks for the link.

After following the directions in that post, I still have an
issue....output of buginfo.sh below.

$ ./buginfo.sh
== Kernel version:
Linux ki4hdu-home 5.4.79-v7+ #1373 SMP Mon Nov 23 13:22:33 GMT 2020
armv7l GNU/Linux

== Firmware version:
Nov 18 2020 19:59:22
Copyright (c) 2012 Broadcom
version 8e01026adc5a87d80f8748fc6a4fecb9012393cc (clean) (release) (start)

== Codec driver check:
[ 9.649099] asoc-simple-card soc:sound: tlv320aic32x4-hifi <->
3f203000.i2s mapping ok

== DRAWS driver check:
udrc card number line: card 3: udrc [udrc], device 0:
bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0
[bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0]
udrc is sound card #3

== Boot 'fail' check:
[ 8.161416] brcmfmac mmc1:0001:1: Direct firmware load for
brcm/brcmfmac43430-sdio.raspberrypi,3-model-b.txt failed with error -2

== GPS check:
Serial devices OK
gpsd OK

== Pi Version
Pi 3 Model B, Rev 1.2, Mfg by Sony UK with WiFi

== /boot/config
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=51
dtoverlay=
dtoverlay=draws,alsaname=udrc
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtparam=audio=on

On Mon, Mar 29, 2021 at 1:20 PM Basil Gunn <basil@pacabunga.com> wrote:


Is there an easy fix for this?
RPi kernel upgrade problem
https://nw-digital-radio.groups.io/g/udrc/message/5475

Even though your TI tlv320aic32x4 codec was enumerated, the serial ports
on the i2c buss for the gps script failed.
Both the codec & i2c buss problems are intermittent, that is, on any
given boot the devices may not properly work.

The above link to my Feb groups.io post tells you every thing you need
to know in order to revert your kernel version and put a hold on it to
get things working again.

Using script buginfo.sh is a quicker way to get relevant information on
these 2 kernel problems.

To get the latest buginfo.sh script

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

There are 3 patches recently submitted to fix these problem:

[PATCH 1/2] ASoC: tlv320aic32x4: Increase maximum register in regmap
[PATCH 2/2] ASoC: tlv320aic32x4: Register clocks before registering component
[PATCH] sc16is7xx: Defer probe if device read fails


William McKeehan (KI4HDU) <ki4hdu@gmail.com> writes:

I recently did a `apt upgrade` to my pi that has my draws hat on
it...since then, the GPS no longer "works" (i.e., the devices are not
present in `/dev`).

Is there an easy fix for this?



--
William
KI4HDU


Re: GPS very slow to pick up sats #gps

Basil Gunn
 

I completed brand new setup and all "getting started guide"
steps. Left it overnight and still no fix.
I think your problem is the GPS antenna:
- is the SMA connector fully screwed on
- location of the antenna


Re: GPS not recognized

Basil Gunn
 

Is there an easy fix for this?
RPi kernel upgrade problem
https://nw-digital-radio.groups.io/g/udrc/message/5475

Even though your TI tlv320aic32x4 codec was enumerated, the serial ports
on the i2c buss for the gps script failed.
Both the codec & i2c buss problems are intermittent, that is, on any
given boot the devices may not properly work.

The above link to my Feb groups.io post tells you every thing you need
to know in order to revert your kernel version and put a hold on it to
get things working again.

Using script buginfo.sh is a quicker way to get relevant information on
these 2 kernel problems.

To get the latest buginfo.sh script

cd
cd n7nix
git pull
cd config
./bin_refresh.sh

There are 3 patches recently submitted to fix these problem:

[PATCH 1/2] ASoC: tlv320aic32x4: Increase maximum register in regmap
[PATCH 2/2] ASoC: tlv320aic32x4: Register clocks before registering component
[PATCH] sc16is7xx: Defer probe if device read fails


William McKeehan (KI4HDU) <ki4hdu@gmail.com> writes:

I recently did a `apt upgrade` to my pi that has my draws hat on
it...since then, the GPS no longer "works" (i.e., the devices are not
present in `/dev`).

Is there an easy fix for this?


GPS not recognized

William McKeehan (KI4HDU)
 

I recently did a `apt upgrade` to my pi that has my draws hat on
it...since then, the GPS no longer "works" (i.e., the devices are not
present in `/dev`).

Is there an easy fix for this?

Output from showudrc.sh below (because that always seems to help with
troubleshooting).

Thanks!
William

==== Sound Card ====
udrc card number line: card 3: udrc [udrc], device 0:
bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0
[bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0]
udrc is sound card #3
==== ALSA Controls for Radio Transmit ====
LO Driver Gain L:[0.00dB] R:[0.00dB]
PCM L:[-2.00dB] R:[-2.00dB]
DAC Playback PT L:[P3] R:[P3]
LO Playback CM [Full Chip]
==== ALSA Controls for Radio Receive ====
ADC Level L:[-7.00dB] R:[-7.00dB]
IN1 L:[Off] R:[Off]
IN2 L:[10 kOhm] R:[10 kOhm]

==== Pi Ver ====
Pi 3 Model B, Rev 1.2, Mfg by Sony UK with WiFi
Hardware : BCM2835
Revision : a02082
Serial : 000000003d167355
Model : Raspberry Pi 3 Model B Rev 1.2

==== Pi Firmware VideoCore Ver ====
Feb 25 2021 12:12:09
Copyright (c) 2012 Broadcom
version 564e5f9b852b23a330b1764bcf0b2d022a20afd0 (clean) (release) (start)

==== Pi Firmware EEPROM Ver ====
unknown

==== Pi Firmware EEPROM Config ====


==== udrc Ver ====
Found a DRAWS

HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0204
UUID: 7b87530a-0975-43cc-bbc0-203350f4c6e9
Vendor: NW Digital Radio

==== sys Ver ====
----- image version
2020 08 05 09:41:31 EDT: config.sh: direwolf config script FINISHED
----- /proc/version
Linux version 5.10.17-v7+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8
(Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu)
2.34) #1403 SMP Mon Feb 22 11:29:51 GMT 2021

----- /etc/*version: 10.8

----- /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

----- lsb_release
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Release: 10
Codename: buster

---- systemd
Static hostname: ki4hdu-home
Icon name: computer
Machine ID: 4e0d71c3f1cc44fba354b56f96875c49
Boot ID: 3fba07d861aa4a1e9f1701fbfa25a40a
Operating System: Raspbian GNU/Linux 10 (buster)
Kernel: Linux 5.10.17-v7+
Architecture: arm
sd card id: 035344534c313647803b50245101098f

---- sound modules
snd_soc_tlv320aic32x4_i2c 16384 117
snd_soc_tlv320aic32x4 40960 1 snd_soc_tlv320aic32x4_i2c
regmap_i2c 16384 3 ti_ads1015,sc16is7xx,snd_soc_tlv320aic32x4_i2c
snd_soc_core 225280 4
snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_soc_simple_card
snd_pcm 106496 7
snd_compress,snd_usb_audio,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core
snd 77824 33
snd_compress,snd_hwdep,snd_usb_audio,snd_timer,snd_rawmidi,snd_usbmidi_lib,snd_seq_device,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core,snd_pcm

---- kernel
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==================-============-============-=================================
ii raspberrypi-kernel 1.20210303-1 armhf Raspberry Pi bootloader

---- Codec drivers
Found: snd-soc-tlv320aic32x4-i2c.ko, OK
Found: snd-soc-tlv320aic32x4.ko, OK
Directory: /proc/device-tree/soc/i2c@7e804000/tlv320aic32x4@18 exists
and status is okay

---- syslog

---- dmesg


----- Dire Wolf version 1.6

==== Filesystem ====
/dev/root 15G 13G 1.1G 93% /

==== boot config ====
hdmi_force_hotplug=1
hdmi_group=2
hdmi_mode=51
dtoverlay=
dtoverlay=draws,alsaname=udrc
[pi4]
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtparam=audio=on

---- gpsd
/usr/sbin/gpsd
gpsd: 3.17 (revision 3.17)
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; disabled; vendor
preset: enabled)
Active: active (running) since Mon 2021-03-29 12:37:47 EDT; 8min ago
Process: 1166 ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $DEVICES
(code=exited, status=0/SUCCESS)
Main PID: 1167 (gpsd)
Tasks: 2 (limit: 2062)
CGroup: /system.slice/gpsd.service
└─1167 /usr/sbin/gpsd -n /dev/ttySC0 /dev/pps0

Mar 29 12:37:47 ki4hdu-home systemd[1]: Starting GPS (Global
Positioning System) Daemon...
Mar 29 12:37:47 ki4hdu-home systemd[1]: Started GPS (Global
Positioning System) Daemon.
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: SER: device open
of /dev/ttySC0 failed: No such file or directory - retrying read-only
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: SER: read-only
device open of /dev/ttySC0 failed: No such file or directory
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: initial GPS device
/dev/ttySC0 open failed
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: SER: device open
of /dev/ttySC0 failed: No such file or directory - retrying read-only
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: SER: read-only
device open of /dev/ttySC0 failed: No such file or directory
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: /dev/ttySC0:
device activation failed.
Mar 29 12:37:47 ki4hdu-home gpsd[1167]: gpsd:ERROR: /dev/ttySC0:
activation failed, freeing device

---- chrony
ls: cannot access '/dev/ttySC*': No such file or directory
crw-rw---- 1 root root 240, 0 Mar 29 12:37 /dev/pps0
----- No chronyc program found in path

---- sensors
-rw-r--r-- 1 root root 330 Jul 17 2020 /etc/sensors.d/draws
iio_hwmon-isa-0000
Adapter: ISA adapter
in1: +2.37 V
in2: +0.58 V
in3: +0.00 V
in4: +0.00 V

cpu_thermal-virtual-0
Adapter: Virtual device
temp1: +47.8°C

rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A


---- throttle
temp=48.3'C
throttled=0x0

---- locale
Locale country codes do not match: WiFi: , iw: US, X11: US.
core_config.sh has been run 0 time(s)


Re: GPS very slow to pick up sats #gps

Kk6qms
 

I completed brand new setup and all "getting started guide" steps. Left it overnight and still no fix. I set up SSH and port forwarding if any gurus would be willing to take a look. Contact me privately for info.
Thank you
Clifford- KK6QMS


Re: GPS very slow to pick up sats #gps

Basil Gunn
 

1. Good.
2. gpsd is active & running, so also good
3. You are running as root, why?
The PATH for root is different then the PATH for user pi.

# As user pi

q$ echo $PATH
/home/pi/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/game
$ which udrcver.sh
/home/pi/bin/udrcver.sh

# As user root

$ sudo su
# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Generally speaking most of the time You should be running as user pi.

4. nwdr19.img.xz & current_image.xz ARE the same file.

I think your problem is the GPS antenna:
- is the SMA connector fully screwed on
- location of the antenna


Kk6qms <kk6qms@arrl.net> writes:

On Sun, Mar 28, 2021 at 09:59 PM, Basil Gunn wrote:


systemctl status gpsd
1- I am using the aluminum DRAWS early adopter case. No issue there.

2- gpsd is good- almost 4hrs- no fix (I stopped/restarted it in the idea I was closing/reopening to troubleshoot not from any inherent wisdom haha):
"root@DRAWSpi:/home/pi# systemctl status gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; enabled; vendor preset: ena
Active: active (running) since Sun 2021-03-28 18:20:40 PDT; 3h 41min ago
Process: 603 ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $DEVICES (code=exited, sta
Main PID: 608 (gpsd)
Tasks: 3 (limit: 3738)
CGroup: /system.slice/gpsd.service
└─608 /usr/sbin/gpsd -n /dev/ttySC0 /dev/pps0

Mar 28 18:20:40 DRAWSpi systemd[1]: Starting GPS (Global Positioning System) Dae
Mar 28 18:20:40 DRAWSpi systemd[1]: Started GPS (Global Positioning System) Daem
lines 1-11/11 (END)"

3- I am using a fresh NWDR image- I verified udrcver.sh is in the dir but I get no output:
"root@DRAWSpi:/home/pi/bin# which udrcver.sh
root@DRAWSpi:/home/pi/bin# "

4- I think I used the "nwdr19.img.xz" not the "current_image.xz" I am downloading the former and will start from scratch.

Thank you both for the help and appreciate the extra info on ./ info and links. I am always learning more about Linux.

Clifford



Re: GPS very slow to pick up sats #gps

Kk6qms
 

I figured it out by using VNC - appears there is a difference when operating as user vs su- will see how it goes.

281 - 300 of 5888