Using the DRAWS hat with a Raspberry Pi 4 #draws #yaac #install #js8call #replacecompass
Stretch is the best path for Pi 3 and Pi 2. If you have a Pi 4, you will need to use Buster and the edit that Basil lists. Now that the DRAWS™ support is directly in the Buster kernel, it is configuration to activate it. We may put out some images specific to some application groupings on top of Buster with DRAWS™, but they will start on top of Buster. Pi 4 is still leading edge at this point.
On Thu, Aug 29, 2019 at 7:36 AM Basil Gunn <basil@...> wrote:
--
John D. Hays Kingston, WA K7VE
|
|
Jonathan Visser
Frank,
toggle quoted messageShow quoted text
I am using the card with the GPS antenna on what I would consider the back. The GPS antenna antenna is on the same side as the power. Thanks, Jonathan
|
|
Frank Ivan
Hi Jonathan,
Could you look at a couple of things and tell me what you are seeing. 1. Could you enter sudo lsmod. That should display a list of kernel modules loaded. 2. Could you cat /boot/config.txt to type out the config.txt file. 3. Could you enter the nx7nix/bin/showudrc.sh. Its a lot of stuff but it tells pretty much the story. 4. Finally could you cat /etc/modules and get a list of kernel modules that are being loaded. Thanks Frank - K0FEI
|
|
Frank Ivan
Hi Basil,
Just adding the lines to /boot/config.txt didn't get the tlv modules to load and I could not see the sound card. If I put those lines before the drtparam=audio=-on then aplay -l said there is no sound card found. In the Stretch version there is a module udrc loaded. What does that do and do we still need it? I am presenting my 3d printed case for the draws hat on a Pi4 at the Tech Connect 285 club the first Saturday in September and would like to tell everyone how great the product is. We have a lot of SOTA folks (Colorado is SOTA heaven) and the draws hat is one of the smallest interfaces available. The following Saturday we will be having our annual picnic on a SOTA peak and showing off equipment. The long and short of it is you have a show stopping problem and it would appear you can not duplicate it. I am not the only one who is having the problem. I know what I would do if it were my product. It would not be to blow it off until after some hamfest more than a month down the way. Frank - K0FEI
|
|
Frank Ivan
I'm sorry Jonathan,
You did show the showudrc and it shows some of the modules, and the /boot/config.txt. If could show all the modules the sudo lsmod and the /etc/modules file that would be interesting. Thanks - Frank - K0FEI
|
|
Just adding the lines to /boot/config.txt didn't get the tlv modulesProvide the output of showudrc.sh describing what you did doesn't work for me. lsmod | grep -i tlv320* snd_soc_tlv320aic32x4_i2c 16384 27 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 8 vc4,snd_pcm_dmaengine,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core snd 73728 14 snd_compress,snd_timer,snd_soc_tlv320aic32x4,snd_bcm2835,snd_soc_core,snd_pcm This works with the latest version of Raspbian which uses this Linux kernel uname -r 4.19.57-v7l+ If you do not see the udrc driver enumerated: aplay -l | grep udrc card 1: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 [] then you are not using the latest Raspbian image it's that simple. Also Beta image 13 works as long as you do NOT do an upgrade. It would not be to blow it off until after some hamfest more than aIt's 2 weeks a way, thanks for your concern. /Basil
|
|
Frank Ivan
Hi Basil,
Sorry to have wasted your time. 73 - Frank - K0FEI
|
|
And make sure the lines are added at the end of /boot/config.txt in that order. dtoverlay=draws,alsaname=udrc force_turbo=1
On Thu, Aug 29, 2019 at 7:36 AM Basil Gunn <basil@...> wrote:
--
John D. Hays Kingston, WA K7VE
|
|
Jonathan Magee
Hi I just wanted to let the group know that I have made good progress. I started from scratch with a clean buster image and using my Pi3B (to rule out any issues specific to my PI4). With just the out of the box image I added in the lines dtoverlay=draws,alsaname=udrc force_turbo=1 to config.txt and rebooted. With just those lines the the DRAWS sound card was not detected. I then added in the line dtdebug=1 at the start of config.txt, rebooted and looked at the debug output. I saw that it was trying to load the device tree for HAT but it failed with the error dterror: can't find symbol 'cprman' and then it unloaded HAT I then added in the line dtoverlay= to the start of my config.txt and rebooted. This time the sound card was detected. I then tried the sd card in my Pi4 and the DRAWS sound card was detected ok. I still have to set up the rest of the software but I am now heading in the right direction. It looks like the automatic loading of the drive tree based on the data in the DRAWS eeprom was failing and that had a knock on effect that stopped the line dtovwerlay=draws,alsaname=udrc from working. I also had a look at the config.txt on the image I am actively using with DRAWS for wsjtx and I notice that it also has the line dtoverlay= in it. 73 de Jonathan GI7KMC
On Fri, 30 Aug 2019 at 04:47, John D Hays - K7VE <john@...> wrote:
|
|
Mike Watkins <mike.watkins@...>
Hi Jonathan, all. I'm puzzled by your "dtoverlay=" observation as that certainly was not required on either my Pi3 or Pi4 running the same Buster image. I wonder if some of the confusion has to do with specifics of the OS you have; what updates it has received. When I first downloaded Buster it was before the DRAWS/udrc device tree files had hit; I had to perform an update before it would work. As of today (sometime in the last month actually), that's not an issue if one downloads a Buster image from the official source: https://www.raspberrypi.org/downloads/raspbian/ In short, to get DRAWS/udrc recognized, all I did was: 1. Download and burn a new image - I've used both Raspbian Buster "Lite" as well as the full desktop image - same results. 2. While doing the initial setup of the Pi to create an empty ssh file in "boot", I also add to config.txt the famous: # 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 and, to save having to change ALSA devices when running alsamixer: # Enable audio (loads snd_bcm2835) # DRAWS: May as well disable if you don't need this # dtparam=audio=on And boot. We're done. aplay -l **** List of PLAYBACK Hardware Devices **** card 0: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 [] Subdevices: 1 / 1 Subdevice #0: subdevice #0 The "July 10" label on Lite on the download page might not be accurate: uname -a But it indeed is working on a Pi 3 and Pi 4. I'd recommend doing a system update in any case. sudo apt-get update && sudo apt-get -y dist-upgrade After reboot, on the Pi 4: uname -a Move the same SD card to the Pi 3: pi@raspberrypi:~ $ aplay -l This is what we should expect. For hams new to all this I wrote up a short guide that only goes as far as the above; configuring applications without the support of the myriad of scripts will be daunting for some. I intend to write some follow up guides for the apps I'm using (mostly packet related at this point). Cheers all Mike
On Thu, Aug 29, 2019 at 11:58 PM Jonathan Magee <jmagee@...> wrote:
|
|
K4KDR
Great write-up, Mike! Thanks so much for putting that all together in one summary. FYI, I am still using the "draws_beta13.zip" image from http://nwdig.net/downloads/ on a Pi 3 B+ connected to an FT-857d and everything (audio in/out, CAT rig control, & PTT) works extremely well. However, your information is great and I will keep it in my notes for whenever I might try the Buster O/S. -Scott, K4KDR =======================
On Fri, Aug 30, 2019 at 12:49 PM Mike Watkins via Groups.Io <mike.watkins=vectorradio.ca@groups.io> wrote:
|
|
Frank Ivan
Hi Jonathan,
You are the MAN! You managed to reproduce the problem that NW Digital denies exits and have a work around! All the people that say you do not need the dtoverlay= line in config.txt probably have new cards with the correct EEPROM. I have one of the first cards and removing the dtoverlay= line breaks the soundcard. Putting it back fixes it. Maybe one of the folks at NW Digital can put in the dtdebug=1 line then boot and see what comes back in sudo vcdbg log msg command. Maybe after the Pacific Northwest Summer Gathering there might be either a fix to the driver module or they might send out a way to update the EEPROM on the card. One other note - the DRAWS lines need to be inserted in the config.txt before the [pi4] and [all] stuff in the config file. This has been tested on new images for Buster for both Pi3 and Pi4 after doing the sudo apt update and sudo apt upgrade. I do like the suggestion to comment out the dtparam=audio=on from Mike. 73 and thanks Frank - K0FEI
|
|
Mike Watkins <mike.watkins@...>
Hi Frank,
Is there a version number we should be looking for where the problem exists (or ceases to exist)? Will be very helpful when supporting others. See below, there may be some specific "parameter" conflict, or who knows even a bug in parameter processing, that could have been causing that. All software has bugs. One other note - the DRAWS lines need to be inserted in the config.txt before the [pi4] and [all] stuff in the config file. Not quite - as long as the relevant configuration information is after [all] it will be read, regardless of the Pi model number. But sure, if you included it before the config.txt file format Pi model tag, you can be sure it'll be read. No harm. Out of curiosity and in an attempt to see what's folklore or not, I've dug into the config.txt documentation out of interest; rather wish I didn't - there's time I won't get back LOL - and discovered a couple things that may not be important but had me curious. Forgive me if I'm covering ground others have already. Regarding dt_overlay=, from the documentation (https://www.raspberrypi.org/documentation/configuration/device-tree.md) it would appear that dt_overlay= is used to reset "parameters" from conflicting with another overlay that happens to use the same parameter names. Since there's only one parameter - alsaname - maybe there's a conflict there but doesn't seem likely... but who knows. Commenting out the on board audio interface removes the other alsa device, and that could be why it's helpful for some cases. I used to think Raspberry Pi's were quite identical until I discovered one of my RPi 3's no longer saw its Wireless adapter despite being configured identically to every other one. Regarding dt_overlay parameter convention: Maybe I'm missing something but the line: dtoverlay=draws,alsaname=urdc Seems to be mis-formatted, unless commas are happily being interpreted per the documentation (below). A colon between the driver and first parameter appears to be the documented format. Does it matter? Maybe. Not in my case though, both work. Still, it's probably best that the documented approach be used in case that happy accident, if that's what it is, ends one day. dtoverlay=draws:alsaname=happytimeurdc $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: happytimeurdc [happytimeurdc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 For the curious, see following. 73 Mike VE7WV If you have an overlay that defines some parameters, they can be specified either on subsequent lines like this:
or appended to the overlay line like this:
Note here the use of a colon ( Overlay parameters are only in scope until the next overlay is loaded. In the event of a parameter with the same name being exported by both the overlay and the base, the parameter in the overlay takes precedence; for clarity, it's recommended that you avoid doing this. To expose the parameter exported by the base DTB instead, end the current overlay scope using:
|
|
Edouard Lafargue
One thing I have noticed about those discussions whether udrc/draws works or not on various Pis: the necessary codecs for the DRAWS/UDRC seem to be hit or miss in the latest kernel module distributions on Raspbian:
root@raspberrypi:/lib/modules# find . -name "*tlv*"
./4.19.66+/kernel/sound/soc/ ./4.19.66+/kernel/sound/soc/ ./4.19.66-v7+/kernel/sound/ ./4.19.66-v7+/kernel/sound/ ./4.19.69+/kernel/sound/soc/ ./4.19.69+/kernel/sound/soc/ ./4.19.66-v7l+/kernel/sound/ ./4.19.66-v7l+/kernel/sound/ root@raspberrypi:/lib/modules# For instance, the modules are missing from 4.19.69-v8+ which is the current latest RPi kernel as of Sept 4th.
|
|
Frank Ivan
Hi Edouard,
Where did you get kernel 4.19.69-v8+? The best I can do this morning - Sept 5 is 4.19.66-v71+ with sudo apt upgrade and 4.19.69-v71+ with sudo rpi-update on a Pi4. Both of them have the tlv modules. In other words - what should I not do that might break things? Thanks 73 Frank K0FEI
|
|
Edouard Lafargue
The one big 'no-no' in this case, is to run 'raspi-update', which will move you to a bleeding edge testing kernel that really breaks a lot of drivers - it is not even an armhf kernel anymore, but aarch64 which is quite exciting by itself - . It's difficult to go back afterwards. I discovered this early on when installing Buster and trying raspi-update, and reverting to the standard kernel lead to various errors. As a conclusion: do not 'raspi-update' :) Ed
On Thu, Sep 5, 2019 at 7:54 AM Frank Ivan via Groups.Io <k0fei=me.com@groups.io> wrote: Hi Edouard,
|
|
Frank Ivan
Thanks Ed,
I can't wait for an aarch64 system. I think it will really allow the Pi4 to show what its made of - especially with 2 or 4 gig. 73 - Frank - K0FEI
|
|