|
Hi Basil, I appreciate your precisions concerning DRAWS use with nwdr14 distro. However there is a complete discrepancy between what you suggest and what is explained in the "Getting Started Guide" https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS%3A-Getting-StartedIn the above guide is written to execute script _appconfig.sh core in Initial Configuration. On the contrary you wrote https://github.com/nwdigitalradio/n7nix/blob/master/docs/IMAGE_README.md)
come pre-installed on the nwdr14.img. Running the install scripts on
this image is not necessary and most likely will break things.
You can see a log of what is already installed here:
cat /var/log/udr_install.log However, direwolf is not installed in nwdr14 image. Currently you can switch between vhf/uhf packet & HF programs by
starting & stopping ax25 which also starts & stops direwolf and a number
of other daemons used by packet. ie mheardd
cd ~/bin
# Become root
sudo su
./ax25-start
# or
./ax25-stop Immediately after first initial distro configuration ax25-status shows that AX.25 pplications are not RUNNING and NOT ENABLED. Executing ./ax25-start fails with error code due to direwolf port not found. There are a few reasons for this. First /etc/direwolf.conf is not configured for DRAWS device is commented together with PTT GPIO is not set to 12 (default left DRAWS plug). #ADEVICE plughw:1,0 #MYCALL N0NONE #PTT GPIO 25 If /etc/direwolf.conf is configured for DRAWS before running ./ax25-start things go much better. In order to check if AX.25 is now correctly set up I started YAAC application and listening to APRS frequency. No stations could be decoded. I had to execute setalsa-udrc-din6.sh script. At this step, to be able to get a functioning APRS application I found it is abolutely necessary to switch Raspberry Pi power OFF and ON to reboot. Otherwise, direwolf is not getting DRAWS audio. After these mandatory successive procedures, measure-deviate script was found to be working correctly and beacon application could also be activated. I will continue further in order to find the correct order of scripts execution steps toward ax0 and ax1 configurations for other AX.25 applications. 73 de Bernard, f6bvp
|
|
|
Re: [New post] DRAWS™Case Update
Dave Phelps <dave.phelps@...>
Can you clarify if this is about the aluminum case? I tried to inquire about my order with the support form on the website but I received no response.
Still on track? Or?
|
|
|
Re: UDRC 2 and motorola GM300 connection
Basil,
Sorry. I was referring specifically to MMDVMHost for UDRC/DRAWS.
On Tue, Dec 10, 2019 at 2:42 PM Basil Gunn < basil@...> wrote:
> It seems that this project is dead.
There was a few things mentioned in this thread. Specifically which
project are you talking about?
I confirmed last January that Motorola radios with either a 16 pin or 20
pin accessory connector should work with the UDRC II using the Argent
Data GM300 Mini-Din Adapter
(https://www.argentdata.com/catalog/product_info.php?products_id=169)
I confirmed with Motorola Radios that I have (PM 400, CDM 750, CDM
1550-LS, Radio M1225-LS)
> Anyone know if any future development is planned?
>
> Alternatively, are there any other packages configurable for a multi-mode repeater/simplex node using the UDRC or DRAWS?
I know that in 2015 John K7VE demonstrated a Yaesu DR-1X in Tri-mode (Fusion Digital,
D-Star, Analog FM) using a UDRC.
https://nw-digital-radio.groups.io/g/udrc/wiki/UDRC%E2%84%A2-Setup-for-the-Yaesu-DR-1X-Repeater
/Basil n7nix
-- ***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
|
|
|
Re: UDRC 2 and motorola GM300 connection
Basil Gunn
It seems that this project is dead. There was a few things mentioned in this thread. Specifically which project are you talking about? I confirmed last January that Motorola radios with either a 16 pin or 20 pin accessory connector should work with the UDRC II using the Argent Data GM300 Mini-Din Adapter ( https://www.argentdata.com/catalog/product_info.php?products_id=169) I confirmed with Motorola Radios that I have (PM 400, CDM 750, CDM 1550-LS, Radio M1225-LS) Anyone know if any future development is planned?
Alternatively, are there any other packages configurable for a multi-mode repeater/simplex node using the UDRC or DRAWS? I know that in 2015 John K7VE demonstrated a Yaesu DR-1X in Tri-mode (Fusion Digital, D-Star, Analog FM) using a UDRC. https://nw-digital-radio.groups.io/g/udrc/wiki/UDRC%E2%84%A2-Setup-for-the-Yaesu-DR-1X-Repeater/Basil n7nix
|
|
|
Re: UDRC 2 and motorola GM300 connection
It seems that this project is dead.
Anyone know if any future development is planned?
Alternatively, are there any other packages configurable for a multi-mode repeater/simplex node using the UDRC or DRAWS?
|
|
|
Basil Gunn
Having installed recently last available NorthWest digital radio image
nw14dr.img I got an excellent Linux system on a RaspBerry Pi 4. Great to hear Bernard. Just after booting fresh new system I checked different applications
and found they where working although I did not go further into
complete configurations. Fldigi, Xastir, Yaac could start correctly.
I entered n7nix directory and updated n7nix scripts using 'git pull'
command. Yes, that's a good thing to do. Then I decided to install Direwolf using n7nix script ~config/core-install.sh
After all was done without any error, I found that fldigi could not
start anymore. direwolf and many other programs (see list here: https://github.com/nwdigitalradio/n7nix/blob/master/docs/IMAGE_README.md) come pre-installed on the nwdr14.img. Running the install scripts on this image is not necessary and most likely will break things. You can see a log of what is already installed here: cat /var/log/udr_install.log Currently you can switch between vhf/uhf packet & HF programs by starting & stopping ax25 which also starts & stops direwolf and a number of other daemons used by packet. ie mheardd cd ~/bin # Become root sudo su ./ax25-start # or ./ax25-stop See the "Getting Started Guide" https://nw-digital-radio.groups.io/g/udrc/wiki/DRAWS%3A-Getting-StartedThere is a message about libjpeg.so.9 file missing and Linux system
says that this library is not used anymore. libjpeg.so.9 is used by one of the hf programs probably fldigi. It gets installed with the .n7nix/hfprogs/hf_install.sh script and lives in this directory: /usr/lib/arm-linux-gnueabihf/ /usr/lib/arm-linux-gnueabihf/libjpeg.so.9 If you see a message that libjpeg.so.9 is missing then: sudo apt-get install libjpeg9-dev So I am asking the question about direwolf and fldigi compatibility ? I am currently using both direwolf & fldigi at the same time and it works well using the split-channels instructions. I have a script that installs split-channels but it needs some work. You should understand that direwolf & the HF programs like to "own" the sound card device and usually can only be run separately from one anther. The split-channels instructions ( https://github.com/nwdigitalradio/split-channels) creates a virtual sound card device using pulse audio for each of these different modem programs to bind to. /Basil n7nix
|
|
|
Hi,
Having installed recently last available NorthWest digital radio image nw14dr.img I got an excellent Linux system on a RaspBerry Pi 4.
Just after booting fresh new system I checked different applications and found they where working although I did not go further into complete configurations.
Fldigi, Xastir, Yaac could start correctly.
I entered n7nix directory and updated n7nix scripts using 'git pull' command.
Then I decided to install Direwolf using n7nix script ~config/core-install.sh
After all was done without any error, I found that fldigi could not start anymore.
There is a message about libjpeg.so.9 file missing and Linux system says that this library is not used anymore.
So I am asking the question about direwolf and fldigi compatibility ?
Bernard, f6bvp
|
|
|
Basil Gunn
toggle quoted messageShow quoted text
Your suggested experiment was exactly my intention. I will give it a shot
this weekend.
And thank you for the reference as well.
|
|
|
Your suggested experiment was exactly my intention. I will give it a shot this weekend.
And thank you for the reference as well.
On Thu, Dec 5, 2019 at 5:28 PM Paul Noa < pauljnoa@...> wrote: Ryan, Your question peeked my interest so I looked around to see what I could find about GPS reception. not alot on the RX side but some references in 6.1.
I would expect you could use gpsmon to monitor the signal level and then reposition it and record the difference.
Perhaps empirical data will be your best answer.
Paul
After seeing some pictures in another forum, a question came to mind.
Aside from the difference between active and passive gps antennae, is there any advantage/disadvantage to orienting them vertically/horizontally?
-- ***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
|
|
|
Ryan, Your question peeked my interest so I looked around to see what I could find about GPS reception. not alot on the RX side but some references in 6.1.
I would expect you could use gpsmon to monitor the signal level and then reposition it and record the difference.
Perhaps empirical data will be your best answer.
Paul
After seeing some pictures in another forum, a question came to mind.
Aside from the difference between active and passive gps antennae, is there any advantage/disadvantage to orienting them vertically/horizontally?
|
|
|
After seeing some pictures in another forum, a question came to mind.
Aside from the difference between active and passive gps antennae, is there any advantage/disadvantage to orienting them vertically/horizontally?
|
|
|
Basil Gunn
Can you explain why I would need the `dtoverlay=` line? The original UDRC & some of the UDRC II HATs have their DT (Device Tree) overlay files in EEPROM on the HAT. The DT overlay in the HAT EEPROM is automatically loaded by the boot firmware. The DT overlay file for the UDRC II & DRAWS HATs grew too large for the EEPROM so are now only loaded dynamically from the /boot/overlays directory. Using dtoverlay= ends the current overlay scope so that the UDRC or DRAWS overlay in the /boot/overlays directory can be loaded by a subsequent dtoverlay=udrc or dtoverlay=draws command. dtoverlay= effectively suppresses the loading of the HAT overlay in EEPROM. Any dtparam or dtoverlay directives must come after the dtoverlay= line. /Basil n7nix
|
|
|
William McKeehan (KI4HDU)
Thanks for the explanation! On Wed, Dec 4, 2019 at 11:24 AM Ryan Matthew Headley <headley.ryan@...> wrote:
The purpose of 'dtoverlay=' is to clear any previous like settings in the file so that 'dtoverlay=draws' will be accepted.
On Wed, Dec 4, 2019 at 11:17 AM William McKeehan <@KI4HDU> wrote:
That alone did not resolve the issue, but adding `dtoverlay=` directly
above the `dtoverlay=draws,alsaname=udrc` line, then moving the entire
DRAWS block to be above `dtparam=audio=on` seems to have things
working.
Can you explain why I would need the `dtoverlay=` line?
Thanks for the help!
On Wed, Dec 4, 2019 at 10:44 AM Ryan Matthew Headley
<headley.ryan@...> wrote:
Place
dtoverlay=
directly above
dtoverlay=draws,alsaname=udrc
in /boot/config.txt
On Wed, Dec 4, 2019 at 9:13 AM William McKeehan <@KI4HDU> wrote:
Is there a guide for setting up the DRAWS hat with Buster?
I started with a clean image, and tried to enable the DRAWS by adding `dtoverlay=draws` to the /boot/config.txt file, but when the pi starts, `aplay -l` does not list the draws audio device and the GPS devices (ttySC0 and pps0) are also not available.
The hat appears to be installed:
/proc/device-tree/hat/name: hat
/proc/device-tree/hat/product: Digital Radio Amateur Work Station
/proc/device-tree/hat/product_id: 0x0004
/proc/device-tree/hat/product_ver: 0x0204
/proc/device-tree/hat/uuid: 7b87530a-0975-43cc-bbc0-203350f4c6e9
/proc/device-tree/hat/vendor: NW Digital Radio
I added the dtoverlay to the end of the /boot/config.txt file:
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtoverlay=vc4-fkms-v3d
# DRAWS related:
# this adds the udrc driver to the device tree
dtoverlay=draws,alsaname=udrc
# https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
force_turbo=1
but don't see the audio device:
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
If someone could point me to some debugging steps, I'd appreciate it.
Thanks!
William
KI4HDU
--
***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
--
William
KI4HDU
--
***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
-- William KI4HDU
|
|
|
Great news Basil! Thanks for your efforts in this entire thing!
------ 73,
Jim
VA7SHG - Phone
VE7TGZ/VA7TGZ - Other
On Dec 3, 2019, at 21:21, Basil Gunn < basil@...> wrote:
Jim,Yes that's exactly the problem! The chk_conflict.sh script was left overfrom when the DRAWS drivers were installed with DKMS (Dynamic KernelModule Support). At that time the AutoSense-Pi drivers were over writingthe DRAWS drivers. That was all fixed with the acceptance of Anna'smatches for the tlv320aic codec which supported the DRAWS hat back inearly summer.The chk_conflict.sh script has been removed and there is no reference toit in prog_refresh.sh. I've updated the n7nix repo with the requiredchanges.Thanks for figuring this out! Nice work!/BasilJim Erickson <jim@...> writes:I think I have a repeatable set of steps that I can perform to make the DRAWS disappear. I’ve done it three times with the same results. Here they are. Please comment on changes to steps or outputs that you’d like to see at particular steps.
Burn and install nwdr14.img that I downloaded back on October 3, 2019.
Boot my RPi4 headless, plugged into ethernet on my local network.
SSH in, and verify that udrc is listed with aplay -l. It is, though it’s listed as card 1, otherwise, everything is the same as the directions.
• card 1: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 []
• Subdevices: 1/1
• Subdevice #0: subdevice #0
At this point, I run sudo raspi-config. I go into Interfacing Options and enable VNC as well as Advanced Options and configure my screen resolution. Finish and then reboot.
Now I’m able to VNC in to my Pi4, so I do, and go through the steps from the piwiz, including changing password. I skip joining my wifi network, and I also skip performing an update. I now reboot.
I’ve done two things on this step. One way was to run n7nix/config/app_config.sh core as root. The other was to do a git pull in n7nix first and then do the app_config.sh core as root. Both ways work with out error. I can send you the console output of that script which appears to work with out error. Reboot.
Verify now that udrc is still showing, which it is. Now I run ./n7nix/bin/prog_refresh.sh which updates JS8Call to 2.0.0 (over 1.1) and WSJT-X to 2.1.2 (over 2.1.0) Both of those installs appear to work with out issue.
Here’s the bit that looks relevant to me in the prog_refresh.sh script output
pi@ve7tgz-rpi4:~ $ ./n7nix/bin/prog_refresh.sh
Update scripts in n7nix directory
Already up to date.
Check udrc driver conflict for Kernel release: 4.19.66-v7l+
=== chk1: snd-soc-tlv320aic32x4-i2c.ko exists, removing
=== chk2: snd-soc-tlv320aic32x4.ko exists, removing
=== Loaded module check
snd_soc_tlv320aic32x4_i2c 16384 9
snd_soc_tlv320aic32x4 40960 1 snd_soc_tlv320aic32x4_i2c
snd_soc_core 192512 5 vc4,snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_soc_simple_card
snd_pcm 102400 6 vc4,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core
snd 73728 12 snd_compress,snd_timer,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core,snd_pcm
=== Sound card check
OK
After a reboot now, when I look for urdc, it’s not listed and I only have card 0, the on board sound.
pi@ve7tgz-rpi4:~ $ aplay -l
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Hope this helps, and let men know if I can provide any other information.
------
73,
Jim
VA7SHG - Phone
VE7TGZ/VA7TGZ - Other
On Dec 3, 2019, at 15:20, Basil Gunn <basil@...> wrote:
Ryan Matthew Headley <headley.ryan@...> writes:
I will get all of that together tomorrow.
Thanks. With a little patience we will figure this out.
I'm focusing on the drivers loading and enumerating the hardware
sometimes and not others. Just booting your system without running any
config scripts and looking at the output of 'aplay -l' should help us
understand what is going on.
There is no point in even running the configuration scripts if the
drivers haven't loaded. I'll put that in the getting started guide.
/Basil n7nix
I did check that the udrc was appearing is alsa. I will send you
everything tomorrow.
On Tue, 3 Dec 2019, 17:33 Basil Gunn, <basil@...> wrote:
Something is going wrong from the very beginning.
|
|
|
The purpose of 'dtoverlay=' is to clear any previous like settings in the file so that 'dtoverlay=draws' will be accepted.
On Wed, Dec 4, 2019 at 11:17 AM William McKeehan < ki4hdu@...> wrote: That alone did not resolve the issue, but adding `dtoverlay=` directly
above the `dtoverlay=draws,alsaname=udrc` line, then moving the entire
DRAWS block to be above `dtparam=audio=on` seems to have things
working.
Can you explain why I would need the `dtoverlay=` line?
Thanks for the help!
On Wed, Dec 4, 2019 at 10:44 AM Ryan Matthew Headley
<headley.ryan@...> wrote:
>
> Place
>
> dtoverlay=
>
> directly above
>
> dtoverlay=draws,alsaname=udrc
>
> in /boot/config.txt
>
>
> On Wed, Dec 4, 2019 at 9:13 AM William McKeehan <ki4hdu@...> wrote:
>>
>> Is there a guide for setting up the DRAWS hat with Buster?
>>
>> I started with a clean image, and tried to enable the DRAWS by adding `dtoverlay=draws` to the /boot/config.txt file, but when the pi starts, `aplay -l` does not list the draws audio device and the GPS devices (ttySC0 and pps0) are also not available.
>>
>> The hat appears to be installed:
>> /proc/device-tree/hat/name: hat
>> /proc/device-tree/hat/product: Digital Radio Amateur Work Station
>> /proc/device-tree/hat/product_id: 0x0004
>> /proc/device-tree/hat/product_ver: 0x0204
>> /proc/device-tree/hat/uuid: 7b87530a-0975-43cc-bbc0-203350f4c6e9
>> /proc/device-tree/hat/vendor: NW Digital Radio
>>
>> I added the dtoverlay to the end of the /boot/config.txt file:
>>
>> # Additional overlays and parameters are documented /boot/overlays/README
>>
>> # Enable audio (loads snd_bcm2835)
>> dtparam=audio=on
>>
>> [pi4]
>> # Enable DRM VC4 V3D driver on top of the dispmanx display stack
>> dtoverlay=vc4-fkms-v3d
>> max_framebuffers=2
>>
>> [all]
>> dtoverlay=vc4-fkms-v3d
>>
>> # DRAWS related:
>> # this adds the udrc driver to the device tree
>> dtoverlay=draws,alsaname=udrc
>> # https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
>> force_turbo=1
>>
>> but don't see the audio device:
>> **** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
>> Subdevices: 1/1
>> Subdevice #0: subdevice #0
>> card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
>> Subdevices: 1/1
>> Subdevice #0: subdevice #0
>>
>> If someone could point me to some debugging steps, I'd appreciate it.
>>
>> Thanks!
>> William
>> KI4HDU
>>
>
>
> --
> ***************************
> Ryan Matthew Headley
> 1705 Granby Road
> Cayce, SC 29033 USA
>
> mobile - +1803-386-1799
>
--
William
KI4HDU
-- ***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
|
|
|
William McKeehan (KI4HDU)
That alone did not resolve the issue, but adding `dtoverlay=` directly above the `dtoverlay=draws,alsaname=udrc` line, then moving the entire DRAWS block to be above `dtparam=audio=on` seems to have things working. Can you explain why I would need the `dtoverlay=` line? Thanks for the help! On Wed, Dec 4, 2019 at 10:44 AM Ryan Matthew Headley <headley.ryan@...> wrote:
Place
dtoverlay=
directly above
dtoverlay=draws,alsaname=udrc
in /boot/config.txt
On Wed, Dec 4, 2019 at 9:13 AM William McKeehan <@KI4HDU> wrote:
Is there a guide for setting up the DRAWS hat with Buster?
I started with a clean image, and tried to enable the DRAWS by adding `dtoverlay=draws` to the /boot/config.txt file, but when the pi starts, `aplay -l` does not list the draws audio device and the GPS devices (ttySC0 and pps0) are also not available.
The hat appears to be installed:
/proc/device-tree/hat/name: hat
/proc/device-tree/hat/product: Digital Radio Amateur Work Station
/proc/device-tree/hat/product_id: 0x0004
/proc/device-tree/hat/product_ver: 0x0204
/proc/device-tree/hat/uuid: 7b87530a-0975-43cc-bbc0-203350f4c6e9
/proc/device-tree/hat/vendor: NW Digital Radio
I added the dtoverlay to the end of the /boot/config.txt file:
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtoverlay=vc4-fkms-v3d
# DRAWS related:
# this adds the udrc driver to the device tree
dtoverlay=draws,alsaname=udrc
# https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
force_turbo=1
but don't see the audio device:
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
If someone could point me to some debugging steps, I'd appreciate it.
Thanks!
William
KI4HDU
--
***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
-- William KI4HDU
|
|
|
Place
dtoverlay=
directly above
dtoverlay=draws,alsaname=udrc
in /boot/config.txt
On Wed, Dec 4, 2019 at 9:13 AM William McKeehan < ki4hdu@...> wrote: Is there a guide for setting up the DRAWS hat with Buster?
I started with a clean image, and tried to enable the DRAWS by adding `dtoverlay=draws` to the /boot/config.txt file, but when the pi starts, `aplay -l` does not list the draws audio device and the GPS devices (ttySC0 and pps0) are also not available.
The hat appears to be installed:
/proc/device-tree/hat/name: hat
/proc/device-tree/hat/product: Digital Radio Amateur Work Station
/proc/device-tree/hat/product_id: 0x0004
/proc/device-tree/hat/product_ver: 0x0204
/proc/device-tree/hat/uuid: 7b87530a-0975-43cc-bbc0-203350f4c6e9
/proc/device-tree/hat/vendor: NW Digital Radio
I added the dtoverlay to the end of the /boot/config.txt file:
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtoverlay=vc4-fkms-v3d
# DRAWS related:
# this adds the udrc driver to the device tree
dtoverlay=draws,alsaname=udrc
force_turbo=1
but don't see the audio device:
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
If someone could point me to some debugging steps, I'd appreciate it.
Thanks!
William
KI4HDU
-- ***************************
Ryan Matthew Headley
1705 Granby Road
Cayce, SC 29033 USA
mobile - +1803-386-1799
|
|
|
William McKeehan (KI4HDU)
Is there a guide for setting up the DRAWS hat with Buster? I started with a clean image, and tried to enable the DRAWS by adding `dtoverlay=draws` to the /boot/config.txt file, but when the pi starts, `aplay -l` does not list the draws audio device and the GPS devices (ttySC0 and pps0) are also not available. The hat appears to be installed:
/proc/device-tree/hat/name: hat
/proc/device-tree/hat/product: Digital Radio Amateur Work Station
/proc/device-tree/hat/product_id: 0x0004
/proc/device-tree/hat/product_ver: 0x0204
/proc/device-tree/hat/uuid: 7b87530a-0975-43cc-bbc0-203350f4c6e9
/proc/device-tree/hat/vendor: NW Digital Radio
I added the dtoverlay to the end of the /boot/config.txt file:
# Additional overlays and parameters are documented /boot/overlays/README
# Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
dtoverlay=vc4-fkms-v3d
# DRAWS related:
# this adds the udrc driver to the device tree
dtoverlay=draws,alsaname=udrc
# https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md
force_turbo=1
but don't see the audio device:
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
If someone could point me to some debugging steps, I'd appreciate it.
Thanks!
William
KI4HDU
|
|
|
Basil,
You asked that I email you directly, but I do not have your email address. Everything I can find in forum only shows 'basil@...'
|
|
|
Basil Gunn
Jim,
Yes that's exactly the problem! The chk_conflict.sh script was left over
from when the DRAWS drivers were installed with DKMS (Dynamic Kernel
Module Support). At that time the AutoSense-Pi drivers were over writing
the DRAWS drivers. That was all fixed with the acceptance of Anna's
matches for the tlv320aic codec which supported the DRAWS hat back in
early summer.
The chk_conflict.sh script has been removed and there is no reference to
it in prog_refresh.sh. I've updated the n7nix repo with the required
changes.
Thanks for figuring this out! Nice work!
/Basil
Jim Erickson <jim@...> writes:
toggle quoted messageShow quoted text
I think I have a repeatable set of steps that I can perform to make the DRAWS disappear. I’ve done it three times with the same results. Here they are. Please comment on changes to steps or outputs that you’d like to see at particular steps.
Burn and install nwdr14.img that I downloaded back on October 3, 2019.
Boot my RPi4 headless, plugged into ethernet on my local network.
SSH in, and verify that udrc is listed with aplay -l. It is, though it’s listed as card 1, otherwise, everything is the same as the directions.
• card 1: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 []
• Subdevices: 1/1
• Subdevice #0: subdevice #0
At this point, I run sudo raspi-config. I go into Interfacing Options and enable VNC as well as Advanced Options and configure my screen resolution. Finish and then reboot.
Now I’m able to VNC in to my Pi4, so I do, and go through the steps from the piwiz, including changing password. I skip joining my wifi network, and I also skip performing an update. I now reboot.
I’ve done two things on this step. One way was to run n7nix/config/app_config.sh core as root. The other was to do a git pull in n7nix first and then do the app_config.sh core as root. Both ways work with out error. I can send you the console output of that script which appears to work with out error. Reboot.
Verify now that udrc is still showing, which it is. Now I run ./n7nix/bin/prog_refresh.sh which updates JS8Call to 2.0.0 (over 1.1) and WSJT-X to 2.1.2 (over 2.1.0) Both of those installs appear to work with out issue.
Here’s the bit that looks relevant to me in the prog_refresh.sh script output
pi@ve7tgz-rpi4:~ $ ./n7nix/bin/prog_refresh.sh
Update scripts in n7nix directory
Already up to date.
Check udrc driver conflict for Kernel release: 4.19.66-v7l+
=== chk1: snd-soc-tlv320aic32x4-i2c.ko exists, removing
=== chk2: snd-soc-tlv320aic32x4.ko exists, removing
=== Loaded module check
snd_soc_tlv320aic32x4_i2c 16384 9
snd_soc_tlv320aic32x4 40960 1 snd_soc_tlv320aic32x4_i2c
snd_soc_core 192512 5 vc4,snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_soc_simple_card
snd_pcm 102400 6 vc4,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core
snd 73728 12 snd_compress,snd_timer,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core,snd_pcm
=== Sound card check
OK
After a reboot now, when I look for urdc, it’s not listed and I only have card 0, the on board sound.
pi@ve7tgz-rpi4:~ $ aplay -l
**** 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 IEC958/HDMI [bcm2835 IEC958/HDMI]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 0: ALSA [bcm2835 ALSA], device 2: bcm2835 IEC958/HDMI1 [bcm2835 IEC958/HDMI1]
Subdevices: 1/1
Subdevice #0: subdevice #0
Hope this helps, and let men know if I can provide any other information.
------
73,
Jim
VA7SHG - Phone
VE7TGZ/VA7TGZ - Other
On Dec 3, 2019, at 15:20, Basil Gunn <@basil860> wrote:
Ryan Matthew Headley <headley.ryan@...> writes:
I will get all of that together tomorrow. Thanks. With a little patience we will figure this out.
I'm focusing on the drivers loading and enumerating the hardware
sometimes and not others. Just booting your system without running any
config scripts and looking at the output of 'aplay -l' should help us
understand what is going on.
There is no point in even running the configuration scripts if the
drivers haven't loaded. I'll put that in the getting started guide.
/Basil n7nix
I did check that the udrc was appearing is alsa. I will send you
everything tomorrow.
On Tue, 3 Dec 2019, 17:33 Basil Gunn, <@basil860> wrote:
Something is going wrong from the very beginning.
|
|
|
