Date   
Re: DRAWS and Buster distro

Frank Ivan
 

Hi Guys,

I spent quite a bit of time on this because I, like Jonathan, have first run Draws hats which also require the dtoverlay= line.
I found the best place to put the new lines are the first non-commented lines in the /boot/Config.txt file.
If you want to make your own SD card, down load the latest Buster and then update it with sudo apt update sudo apt disc-upgrade.  Do not use rpi-update - that brings in a 64 bit experimental kernel that does not yet have the drivers you need.
After you get the system up to date, add the lines to the /boot/Config.txt - just make them the first non-comment lines and after a reboot (assuming the Draws card is installed), the aplay -l command should show the sound card.

Then you can download the n7nix file and run the config/image_install.sh.

If you want to skip all of that, you can download https://www.dropbox.com/s/i21qtsn7c9pwx19/Buster-Draws-2019-09-03.gz?dl=0 which links to a copy of Buster ready to go.  Just be sure to expand the disk when you first boot the Pi - sudo rasps-config or install gparted and use that.

73 - Frank - K0FEI

Download Issues

drjenks70@...
 

Hello, 
    Just received my board and when trying to download the image from:Index of /downloads/  current_image.zip  
     I see minimal download speed and varying between 17 hours to 2 days left. I tried both Chrome and Edge and see basically same results.  I tested to my provider and see 90 Mbps download speeds  After 45 minutes  I have received 39,493 KB of data,  Is there an issue with you access or Server causing this delay.. 2.2g should take about 3 minutes to download.  thanks Daryl 

Raspberry pi 3b+ crash after update/upgrade #draws #a25

Justin Clark (KJ7JC)
 

I haven't used my draws in about 5 months. I started it up and did an update and then upgrade. Rebooted, now it won't reboot. I etched a new image and still get the same problem. I'm no expert on this, any help would be grea . Thanks. 

Re: Raspberry pi 3b+ crash after update/upgrade #draws #a25

 

Did you get your new image from http://nwdig.net/downloads

On Mon, Sep 30, 2019 at 3:48 PM Justin Clark (KJ7JC) <jstnsclark@...> wrote:
I haven't used my draws in about 5 months. I started it up and did an update and then upgrade. Rebooted, now it won't reboot. I etched a new image and still get the same problem. I'm no expert on this, any help would be grea . Thanks. 



--
John D. Hays
Kingston, WA
K7VE

 

Re: Raspberry pi 3b+ crash after update/upgrade #draws #a25

Justin Clark (KJ7JC)
 

Thanks for the fast reply John!!

No, i had got the image on the 27th. I will etch this one here and see how it works. Thank you

Re: Download Issues

Mitch Winkle
 

I saw something similar when downloading it yesterday.  On Win10 it was abysmally slow.  With the same connection on Linux it was it's normally speedy self.  The reader is left to his own conclusions.

On 9/30/19 6:13 PM, drjenks70@... wrote:
Hello, 
    Just received my board and when trying to download the image from:Index of /downloads/  current_image.zip  
     I see minimal download speed and varying between 17 hours to 2 days left. I tried both Chrome and Edge and see basically same results.  I tested to my provider and see 90 Mbps download speeds  After 45 minutes  I have received 39,493 KB of data,  Is there an issue with you access or Server causing this delay.. 2.2g should take about 3 minutes to download.  thanks Daryl 
_._,_.

Re: Download Issues

drjenks70@...
 

Thanks for responding.  the download finally finished after 17.5 hours.   I guess I will have to make a Pi Download machine for any future updates I need.    

[New post] DRAWS™Case Update

 



k7udr posted: "Working thru delays in moving product in/out of China. Should have final prototypes this month. Hopefully production in November. Thanks for your patience, Bryan K7UDR"

New post on NW Digital Radio

DRAWSCase Update

by k7udr

Working thru delays in moving product in/out of China. Should have final prototypes this month. Hopefully production in November.

Thanks for your patience,
Bryan K7UDR

k7udr | October 1, 2019 at 8:00 am | Categories: DRAWS | URL: https://wp.me/p2mAAP-1NS


Trouble clicking? Copy and paste this URL into your browser:
http://nwdigitalradio.com/drawscase-update/




--


John D. Hays
Director

  

Re: Download Issues

Basil Gunn
 

I concur with Mitch. I just downloaded the zipped image and it took
10min 18s at 4.73MB/s
I used my Linux workstation. It does depend on how many other
connections are in progress.

time wget http://nwdig.net/downloads/current_image.zip
--2019-10-01 11:11:19-- http://nwdig.net/downloads/current_image.zip
Resolving nwdig.net (nwdig.net)... 173.203.212.50
Connecting to nwdig.net (nwdig.net)|173.203.212.50|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2406078182 (2.2G) [application/zip]
Saving to: ‘current_image.zip’

current_image.zip 100%[==============================================================================>] 2.24G 4.73MB/s in 10m 18s

2019-10-01 11:21:37 (3.71 MB/s) - ‘current_image.zip’ saved
[2406078182/2406078182]

I'll announce the image possibly tomorrow as I am still testing some things
out.
/Basil


Mitch Winkle <ab4mw@...> writes:

I saw something similar when downloading it yesterday. On Win10 it was
abysmally slow. With the same connection on Linux it was it's normally
speedy self. The reader is left to his own conclusions.

On 9/30/19 6:13 PM, drjenks70@... wrote:
Hello,
Just received my board and when trying to download the image
from:Index of /downloads/ current_image.zip
<http://nwdig.net/downloads/current_image.zip>
I see minimal download speed and varying between 17 hours to 2
days left. I tried both Chrome and Edge and see basically same
results. I tested to my provider and see 90 Mbps download speeds
After 45 minutes I have received 39,493 KB of data, Is there an
issue with you access or Server causing this delay.. 2.2g should take
about 3 minutes to download. thanks Daryl

Re: Eureka!!!! She works perfectly!!

Roderick Wayne Hart Sr.
 

I have been hunting audio out here with a FT-847. The receive works fine. Should I remove pin 6? Can someone explain why. I am using cables that were supplied with the Draws.

Re: Eureka!!!! She works perfectly!!

okiejim
 

I have the same trouble, I have the same radio. I have not tried for several months now. It did work on vhf and aprs with the supplied cables. I live in a trailer and just dont want to take a chance of shorting out the board during transports. I will give it another chance when I receive my case I ordered. Good luck and please advise this thread if you get it going or get an answer.

On Wed, Oct 2, 2019 at 3:58 PM Roderick Wayne Hart Sr. via Groups.Io <rod.hart=verizon.net@groups.io> wrote:
I have been hunting audio out here with a FT-847. The receive works fine. Should I remove pin 6? Can someone explain why. I am using cables that were supplied with the Draws.

Re: Eureka!!!! She works perfectly!!

Matt N7ROO
 

I removed pin 6 from both ends of the cable and it didn't seem to help in my case in my ft-891. In fact it was rather a step backwards as I no longer was receiving signals. 


On Wed, Oct 2, 2019, 16:46 okiejim <kd6vpe@...> wrote:
I have the same trouble, I have the same radio. I have not tried for several months now. It did work on vhf and aprs with the supplied cables. I live in a trailer and just dont want to take a chance of shorting out the board during transports. I will give it another chance when I receive my case I ordered. Good luck and please advise this thread if you get it going or get an answer.

On Wed, Oct 2, 2019 at 3:58 PM Roderick Wayne Hart Sr. via Groups.Io <rod.hart=verizon.net@groups.io> wrote:
I have been hunting audio out here with a FT-847. The receive works fine. Should I remove pin 6? Can someone explain why. I am using cables that were supplied with the Draws.

image update failure

John Spoonhower
 

I am attempting to update my aprs system to the current buster-based image nwdr14.img. the old image was beta 10 I believe. The system uses a UDRC-II HAT. I am looking for a very plain end point; an APRS Igate with some custom software that automatically broadcasts NWS warning packets when an official weather warming is issued. I have had the custom software running on the old beta image.
I have followed the online guidance for installing and verifying  the image file. All seems to proceed normally. The only exception is that showudrc.sh alerts that the gpsd has failed. 
(There is no gps on my UDRC HAT). 
The problem is that although all seems normal otherwise, there are no packets received as evidenced by either "listen -at" or "tail -f /var/log/direwolf/direwolf.log".
It is very clear that the attached radio is receiving aprs packets.
There is likely something obvious I am missing ...?
73,
John, NX2i

Re: image update failure

Basil Gunn
 

I am attempting to update my aprs system to the current buster-based image
nwdr14.img. the old image was beta 10 I believe.
New image is not released yet, so not supported yet.

The system uses a UDRC-II
HAT. I am looking for a very plain end point; an APRS Igate with some
custom software that automatically broadcasts NWS warning packets when an
official weather warming is issued. I have had the custom software running
on the old beta image.
Sounds cool.

I have followed the online guidance for installing and verifying the image
file. All seems to proceed normally. The only exception is that showudrc.sh
alerts that the gpsd has failed.
(There is no gps on my UDRC HAT).
I can't comment on that unless I see the actual showudrc.sh console
output. But please wait until I announce the release. Should be in the
next day or 2. Life keeps getting in the way.

The problem is that although all seems normal otherwise, there are no
packets received as evidenced by either "listen -at" or "tail -f
/var/log/direwolf/direwolf.log".
Did you set your alsa settings the same as what you had on your working
BETA10 image?

It is very clear that the attached radio is receiving aprs packets.
There is likely something obvious I am missing ...?

Re: image update failure

John Spoonhower
 

Hi Basil,
thanks for the information. I have some additional responses below.
73, NX2I
John

On Thu, Oct 3, 2019 at 5:52 PM Basil Gunn <basil@...> wrote:

> I am attempting to update my aprs system to the current buster-based image
> nwdr14.img. the old image was beta 10 I believe.

New image is not released yet, so not supported yet.

I am not sure what "released " means; nwdr14.imgf is what I get when I click on "current image" on the NWD download site.

> The system uses a UDRC-II
> HAT. I am looking for a very plain end point; an APRS Igate with some
> custom software that automatically broadcasts NWS warning packets when an
> official weather warming is issued. I have had the custom software running
> on the old beta image.

Sounds cool.

The credit belongs with K2DLS. If I can implement this, anyone can. Just search for noaacap.py or K2DLS.

> I have followed the online guidance for installing and verifying  the image
> file. All seems to proceed normally. The only exception is that showudrc.sh
> alerts that the gpsd has failed.
> (There is no gps on my UDRC HAT).

I can't comment on that unless I see the actual showudrc.sh console
output. But please wait until I announce the release. Should be in the
next day or 2. Life keeps getting in the way.

The gpsd problem has been fixed by simply pointing to the correct device file in /etc/defaults/gpsd. I can send the showudrc.sh when you wish,

> The problem is that although all seems normal otherwise, there are no
> packets received as evidenced by either "listen -at" or "tail -f
> /var/log/direwolf/direwolf.log".

Did you set your alsa settings the same as what you had on your working
BETA10 image?

yes.
> It is very clear that the attached radio is receiving aprs packets.
> There is likely something obvious I am missing ...?



Draws Hat with Cooling #case

Frank Ivan
 

Hello Everyone,

I have updated my case and it is Thing 3897403 https://www.thingiverse.com/thing:3897403.  It uses a Raspberry Pi Poe Hat between the Raspberry Pi and the Draws Hat.  This brings a temperature controlled fan blowing on the Pi's CPU and also is sealed so that hot air can't recirculate back through the fan but must exit through the cooling slots.  Again - can be printed for Pi3 or Pi4.

Case for Raspberry Pi 3b or Raspberry Pi 4b + NWDR DRAWS hat with GPS port on side.

Added PoE Hat as temperature controlled fan - keep Pi cool no matter load

SCAD file provided so you can help tune the design

STL files for both Raspberry Pi 3b or Raspberry Pi 4b print your choice

Has a powerpole power port

Nice fit for DRAWS card

Rounded corners

Machine screws into card spacers hold case together

 

Hardware

4 M2.5 x 8mm hex socket head machine screws (8mm does not include head)

4 M2.5 x 15mm female to female spacers

4 M2.5 x 8mm male to female spacers

4 M2.5 x 25mm hex socket head machine screws

1 Adafruit ADA2223 - 8.5mm header 40 pin stacking header - also available on Amazon

1 4 Pin Extra Tall Header - https://thepihut.com/products/4-pin-extra-tall-header-push-fit-version-poe-hat

 

1 Official Raspberry Pi Power over Ethernet card - must be official Raspberry Pi PoE hat

Available on Amazon - but PiHut is cheaper and you may want to get 4 pin header from PiHut

 

Assembly

Clean out screw holes - 7/64 or 3mm bit does it nicely

Clean out ports

Install Powerpole connector - maybe use a bit of thin double stick tape to hold in place

Install DRAWS card in lid. It's a close fit but should not be difficult

Push M2.5 x 25mm screws into holes

Slide baffles into slots - keep fan power notch on right as you look from back to front of lid

Install 8mm spaces on screws coming though Draws card

Install 40 pin spacer header into PoE Hat with header pushing into header on PoE Hat

Install PoE Hat onto Draws card - you may need to work the hat past the baffles

Install 15mm spaces onto screws coming through PoE Hat

Plug Pi into Poe Hat - make sure it is aligned with the pins go into correct holes

Install base

Secure with the 4 M2.5 x 8mm screws

Tighten every thing up with allen wrench

 

The PoE Hat will keep a Ri4 down to under 60C under extended load.  It easily passes the heating test from the Explaingcomputers YouTube videos testing Raspberry Pi4 B cooling.

While the PoE Hat is primarily used as a cooling fat, but a nice side effect is you can power the system from the ethernet port.

Note: If you need RFI shielding line the inside of the case with copper foil tape. 

Enjoy and 73
Frank - K0FEI

 

Re: image update failure

Basil Gunn
 

The problem is that although all seems normal otherwise, there are no
packets received as evidenced by either "listen -at" or "tail -f
/var/log/direwolf/direwolf.log".
Did you set your alsa settings the same as what you had on your working
BETA10 image?

yes.
It is very clear that the attached radio is receiving aprs packets.
There is likely something obvious I am missing ...?
I think that your ALSA audio routing is incorrect.
If you route through ALSA IN1 then you are using DISCOUT or
discriminator audio. If you route through ALSA IN2 then you are using AFOUT or
compensated audio (preemphasis/deemphasis). Verify how your radio is
configured. On my Kenwood if I select DATSPD 9600 I am selecting
DISCOUT. This works well for both 1200 & 9600 baud packet.

Could you please return the console output of:

# Verify driver loaded properly
aplay -l

# Verify configured for udrc & not draws
tail /boot/config.txt

# Verify how ALSA is routing audio in
alsa-show.sh

Thanks,
/Basil n7nix

Re: image update failure

John Spoonhower
 

Basil,
responses below.
73, John

On Fri, Oct 4, 2019 at 7:42 PM Basil Gunn <basil@...> wrote:
>> > The problem is that although all seems normal otherwise, there are no
>> > packets received as evidenced by either "listen -at" or "tail -f
>> > /var/log/direwolf/direwolf.log".
>>
>> Did you set your alsa settings the same as what you had on your working
>> BETA10 image?
>>
>> yes.
>
>> > It is very clear that the attached radio is receiving aprs packets.
>> > There is likely something obvious I am missing ...?

I think that your ALSA audio routing is incorrect.
If you route through ALSA IN1 then you are using DISCOUT or
discriminator audio. If you route through ALSA IN2 then you are using AFOUT or
compensated audio (preemphasis/deemphasis). Verify how your radio is
configured. On my Kenwood if I select DATSPD 9600 I am selecting
DISCOUT. This works well for both 1200 & 9600 baud packet.
 
This is not clear to me. I have tested the RPI3/UDRC-II controller to 2 different Yaesu radios both of which work fine with the beta 10 version.


Could you please return the console output of:

# Verify driver loaded properly
aplay -l

 aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0 []
  Subdevices: 0/1
  Subdevice #0: subdevice #0

# Verify configured for udrc & not draws
tail /boot/config.txt
tail /boot/config.txt
[all]
#dtoverlay=vc4-fkms-v3d

# Flush all overlays, ie. deprecated overlays loaded from eeprom
dtoverlay=
# enable udrc/draws if no eeprom
dtoverlay=udrc

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on
 

# Verify how ALSA is routing audio in
alsa-show.sh

 
 alsa-show.sh
 ===== ALSA Controls for Radio Transmit =====
LO Driver Gain  L:[-6.00dB] R:[-6.00dB]
PCM        L:[-16.50dB] R:[-16.50dB]
DAC Playback PT L:[P3] R:[P3]
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]

Thanks,
/Basil n7nix



Re: image update failure

Basil Gunn
 

I used a new image (nwdr14) with a UDRC II and it worked fine. I will
release that image today. The only thing I changed from the scripts was
to select discriminator out using the alsa commands. You can do it from
the alsamixer gui as well.

sset 'IN1_L to Left Mixer Positive Resistor' '10 kOhm'
sset 'IN1_R to Right Mixer Positive Resistor' '10 kOhm'

Since you have a working configuration why not save it to a file &
compare it with the configuration you are using with the new image.
ie. save /boot/config.txt, alsa-show, ax25-status -d

You could try a transmit test to see what that gives you
cd
cd n7nix/debug
./btest.sh -P udr1 -p

Remember that on a UDRC II the mDin6 connector is port 1 not port 0.

I notice that you have manually edited /boot/config.txt. I did not
manually edit any files for my UDRC II test.

/Basil


John Spoonhower <jpspoonhower@...> writes:

Basil,
responses below.
73, John

On Fri, Oct 4, 2019 at 7:42 PM Basil Gunn <@basil860> wrote:

The problem is that although all seems normal otherwise, there are no
packets received as evidenced by either "listen -at" or "tail -f
/var/log/direwolf/direwolf.log".
Did you set your alsa settings the same as what you had on your working
BETA10 image?

yes.
It is very clear that the attached radio is receiving aprs packets.
There is likely something obvious I am missing ...?
I think that your ALSA audio routing is incorrect.
If you route through ALSA IN1 then you are using DISCOUT or
discriminator audio. If you route through ALSA IN2 then you are using
AFOUT or
compensated audio (preemphasis/deemphasis). Verify how your radio is
configured. On my Kenwood if I select DATSPD 9600 I am selecting
DISCOUT. This works well for both 1200 & 9600 baud packet.
This is not clear to me. I have tested the RPI3/UDRC-II controller to 2
different Yaesu radios both of which work fine with the beta 10 version.


Could you please return the console output of:

# Verify driver loaded properly
aplay -l
aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi
tlv320aic32x4-hifi-0 []
Subdevices: 0/1
Subdevice #0: subdevice #0


# Verify configured for udrc & not draws
tail /boot/config.txt
tail /boot/config.txt
[all]
#dtoverlay=vc4-fkms-v3d

# Flush all overlays, ie. deprecated overlays loaded from eeprom
dtoverlay=
# enable udrc/draws if no eeprom
dtoverlay=udrc

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on



# Verify how ALSA is routing audio in
alsa-show.sh


alsa-show.sh
===== ALSA Controls for Radio Transmit =====
LO Driver Gain L:[-6.00dB] R:[-6.00dB]
PCM L:[-16.50dB] R:[-16.50dB]
DAC Playback PT L:[P3] R:[P3]
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]

Thanks,
/Basil n7nix



Re: image update failure

John Spoonhower
 

Thanks. I will give this a try.
On a somewhat different topic...I notice in beacmin.sh that in the comments aprs symbols are listed. I do not see sending a symbol implemented in this script. Is this fairly straightforward to add ?


On Sun, Oct 6, 2019 at 11:17 AM Basil Gunn <basil@...> wrote:

I used a new image (nwdr14) with a UDRC II and it worked fine. I will
release that image today. The only thing I changed from the scripts was
to select discriminator out using the alsa commands. You can do it from
the alsamixer gui as well.

sset 'IN1_L to Left Mixer Positive Resistor' '10 kOhm'
sset 'IN1_R to Right Mixer Positive Resistor' '10 kOhm'

Since you have a working configuration why not save it to a file &
compare it with the configuration you are using with the new image.
ie. save /boot/config.txt, alsa-show, ax25-status -d

You could try a transmit test to see what that gives you
cd
cd n7nix/debug
./btest.sh -P udr1 -p

Remember that on a UDRC II the mDin6 connector is port 1 not port 0.

I notice that you have manually edited /boot/config.txt. I did not
manually edit any files for my UDRC II test.

/Basil


John Spoonhower <jpspoonhower@...> writes:

> Basil,
> responses below.
> 73, John
>
> On Fri, Oct 4, 2019 at 7:42 PM Basil Gunn <basil@...> wrote:
>
>> >> > The problem is that although all seems normal otherwise, there are no
>> >> > packets received as evidenced by either "listen -at" or "tail -f
>> >> > /var/log/direwolf/direwolf.log".
>> >>
>> >> Did you set your alsa settings the same as what you had on your working
>> >> BETA10 image?
>> >>
>> >> yes.
>> >
>> >> > It is very clear that the attached radio is receiving aprs packets.
>> >> > There is likely something obvious I am missing ...?
>>
>> I think that your ALSA audio routing is incorrect.
>> If you route through ALSA IN1 then you are using DISCOUT or
>> discriminator audio. If you route through ALSA IN2 then you are using
>> AFOUT or
>> compensated audio (preemphasis/deemphasis). Verify how your radio is
>> configured. On my Kenwood if I select DATSPD 9600 I am selecting
>> DISCOUT. This works well for both 1200 & 9600 baud packet.
>>
>
> This is not clear to me. I have tested the RPI3/UDRC-II controller to 2
> different Yaesu radios both of which work fine with the beta 10 version.
>
>
>> Could you please return the console output of:
>>
>> # Verify driver loaded properly
>> aplay -l
>>
>
>  aplay -l
> **** List of PLAYBACK Hardware Devices ****
> card 0: udrc [udrc], device 0: bcm2835-i2s-tlv320aic32x4-hifi
> tlv320aic32x4-hifi-0 []
>   Subdevices: 0/1
>   Subdevice #0: subdevice #0
>
>>
>> # Verify configured for udrc & not draws
>> tail /boot/config.txt
>>
> tail /boot/config.txt
> [all]
> #dtoverlay=vc4-fkms-v3d
>
> # Flush all overlays, ie. deprecated overlays loaded from eeprom
> dtoverlay=
> # enable udrc/draws if no eeprom
> dtoverlay=udrc
>
> # Enable audio (loads snd_bcm2835)
> #dtparam=audio=on
>
>
>>
>> # Verify how ALSA is routing audio in
>> alsa-show.sh
>>
>
>
>
>>  alsa-show.sh
>>  ===== ALSA Controls for Radio Transmit =====
>> LO Driver Gain  L:[-6.00dB] R:[-6.00dB]
>> PCM        L:[-16.50dB] R:[-16.50dB]
>> DAC Playback PT L:[P3] R:[P3]
>> 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]
>>
>> Thanks,
>> /Basil n7nix
>>
>>
>>
>>
>
>