Date   

Re: DRAWS viability

 

As for changes to the DRAWS PCB:

  1. 5V Monitoring was added
  2. The GPS Receiver was moved to provide slightly better reception
  3. The power connector was changed to a barrel type, so you can use a OTS PowerePole Cable
73,
Bryan K7UDR


Re: DRAWS for KX3 IQ capture

Annaliese McDermond
 

Be careful about this.

Yes, there is a 196ksps sample rate in the tlv320aic3204.  I made sure the driver supported that when I wrote the code to expand the sample rates.  If you notice in the application guide, though, the antialiasing filter for the 196ksps sample rate cuts off at 20kHz.  So, if you are expecting to see pandadapters that are 192kHz wide on your display, you won't get them.  There'll be rolloff at 20kHz.  See the description of filter C on page 30 of the aforementioned application note.  If you want to see wide pans, go with 96kHz which should work okay from the filter descriptions there.

--
Annaliese McDermond, NH6Z


Re: NWDR20.2 & NWDR21 image release announcement

ke7kus@...
 

On Sun, Jan 23, 2022 at 10:04 AM, Basil Gunn wrote:
The 2 error messages seen in the upper right hand corner of a bullseye
display are not related to UDRC or DRAWS and have been fixed in the
current raspbian kernel. (nwdr21.2.img does not have this problem)
Thanks for the help, Basil.  I modified /boot/config.txt as you indicated and rebooted into RasPi OS running the 5.10.92-v7l+ kernel and had the same issue as described above.

Initial /boot/config.txt:
dtoverlay=udrc
force_turbo=1

I still received the two error messages at the top right of the main display, the top of which is still the "Failure to load HAT overlay".  I checked the /boot/overlays directory for the presence of udrc.dtbo and it was present.  The OS did not register the UDRC, as it did not appear in the "aplay -l" listing.

I went back and added "dtoverlay=" to the first line of the /boot/config.txt file and all worked OK after that with no errors on boot:

Final /boot/config.txt:
dtoverlay=
dtoverlay=udrc
force_turbo=1

Very much appreciate the help.
73,
Kurt
KE7KUS


Re: DRAWS viability

 

Or just use an USB attached drive. 


On Sun, Jan 23, 2022, 09:39 N5TXZ via groups.io <markwaldron1=verizon.net@groups.io> wrote:
Am also interested in a robust, fail-safe EMCOMM solution.

I do have an early adopter DRAWS hat, but am curious as to any disadvantages it may have over the newest (or newer) iterations.

One solution required for EMCOMM, in my opinion, is redundancy and fail-safe design.

For those uneasy about uSD card reliability, you might consider the dual uSD card switches that are available.

One example is here: https://thepihut.com/collections/raspberry-pi-sd-cards-and-adapters/products/2-in-1-sd-card-dual-system-switcher-for-raspberry-pi


Re: NWDR20.2 & NWDR21 image release announcement

Basil Gunn
 

"Failed to load HAT overlay."
The 2 error messages seen in the upper right hand corner of a bullseye
display are not related to UDRC or DRAWS and have been fixed in the
current raspbian kernel. (nwdr21.2.img does not have this problem)

Prior to implementing the fix, RasPiOS wouldn't recognize the UDRC-II
at boot
The /boot/config.txt entry for the proper UDRC overlay is:

dtoverlay=udrc

The DRAWS overlay (/boot/overlays/draws.dtbo) is different than the UDRC
overlay (/boot/overlays/udrc.dtbo)

Rich,

I just upgraded a RasPi4 to the latest Raspberry Pi OS bullseye image
(2021-10-30-raspios-bullseye-armhf) and also got a "Failed to load HAT
overlay" error at boot. My sub-error was slightly different than
yours, but I think I've come up with the simple fix (for now):

In /boot/config.txt I added the line "force_eeprom_read=0" just above
my "dtoverlay=draws:alsaname=udrc" line. The final version of
/boot/config.txt pertaining to my UDRC-II config looks like this:

force_eeprom_read=0
dtoverlay=draws:alsaname=udrc
force_turbo=1

Prior to implementing the fix, RasPiOS wouldn't recognize the UDRC-II
at boot. After the above fix and a reboot, the OS recognized the
UDRC, I was able to configure the UDRC levels with Basil's
"setalsa-udrc-din6.sh" script, and tested using JS8Call with no
issues. Hardware was a RasPi4 (4GB) with a UDRC-II.

Source document which led to the fix:
https://forums.raspberrypi.com/viewtopic.php?t=323705

Hope this helps.
73,
Kurt
KE7KUS


Re: DRAWS viability

Don Rolph
 

You can also mount the filesystem read only if this is an ongoing issue.


On Mon, Jan 10, 2022 at 2:45 PM Zonker <consoleteam@...> wrote:
It may be time to offer this;

  One suggestion for preventing the corruption of your SD card is to perform a shutdown of the Pi before pulling the power.  But, sometimes power hiccups happen. Sometimes we forget to issue the command on the keyboard. Things happen...

  There are a few options (depending on your Pi model) for a UPS Hat, and most come with a pushbutton to invoke the shutdown with a simple press. If you are building your Pi into a grab-and-go box, you can connect a second, remote pushbutton in parallel, where you can get to the second button without unpacking your Pi. (Just make an effort to protect it from unintended presses, and put it somewhere  where you see it before you pack up your kit.)

  The shutdown button will help protect your SD cards, and the battery is another bit of protection.

              Best regards,

               de N6UOW



--

73,
AB1PH
Don Rolph


Re: DRAWS viability

N5TXZ
 

Am also interested in a robust, fail-safe EMCOMM solution.

I do have an early adopter DRAWS hat, but am curious as to any disadvantages it may have over the newest (or newer) iterations.

One solution required for EMCOMM, in my opinion, is redundancy and fail-safe design.

For those uneasy about uSD card reliability, you might consider the dual uSD card switches that are available.

One example is here: https://thepihut.com/collections/raspberry-pi-sd-cards-and-adapters/products/2-in-1-sd-card-dual-system-switcher-for-raspberry-pi


Re: NWDR20.2 & NWDR21 image release announcement

ke7kus@...
 

On Tue, Dec 14, 2021 at 07:44 AM, Rich KR4PI wrote:
"Failed to load HAT overlay."
Rich,

I just upgraded a RasPi4 to the latest Raspberry Pi OS bullseye image (2021-10-30-raspios-bullseye-armhf) and also got a "Failed to load HAT overlay" error at boot.  My sub-error was slightly different than yours, but I think I've come up with the simple fix (for now):

In /boot/config.txt I added the line "force_eeprom_read=0" just above my "dtoverlay=draws:alsaname=udrc" line.  The final version of /boot/config.txt pertaining to my UDRC-II config looks like this:

force_eeprom_read=0
dtoverlay=draws:alsaname=udrc
force_turbo=1

Prior to implementing the fix, RasPiOS wouldn't recognize the UDRC-II at boot.  After the above fix and a reboot, the OS recognized the UDRC, I was able to configure the UDRC levels with Basil's "setalsa-udrc-din6.sh" script, and tested using JS8Call with no issues.  Hardware was a RasPi4 (4GB) with a UDRC-II.

Source document which led to the fix:  https://forums.raspberrypi.com/viewtopic.php?t=323705 

Hope this helps.
73,
Kurt
KE7KUS


DRAWS for sale

Chris Edwards
 
Edited

I have an early adopter complete DRAWS for sale, with gps antenna, dv, metal case, and raspberry pi 3.

make offer.


Re: DRAWS viability

 

OKay, so when I made my comments about the sd card. I think i did state I have also only corrupted 1. With that in mind, I have to think about and address this issue. ESPECIALLY as I could be putting life and safety assets on the line in an actual disaster. Because I encountered a bad card once, it has remained with me. Yes a backup is a must, and should be with any OS.

True some cards are just crappy and not up to the task. In my couple of decades of this, I too have only corrupted or otherwise destroyed a card, twice. The first time was exactly because of a sub par card in use. the second, i didnt spnd much time on, I just tossed in the trash and moved on with the backup. It was NOT a subpar card however.

As for the use of external drives, i am not seeing a need for such, and instead argue against thm for my intentions. If I build an emcomm box for a team, i need guys that can be a bit abusive and not have to worry to much about some things. When I work on disasters throughout the country, I often fnd guys bashing around a pelican case full of sensitive equipment. I dont want to add external drives to that mix, not to mention its not realy needed for DRAWS apps.

I do see the power issue that some could experience depending upon their power scheme. I am not concerned with that environment, as it is most likely that we will operate off of mobile or other portable power. 12Vdc is adequate!


Sincerely,
 Mr. Chris A. Robinson 
 KF6NFW / WQOQ661



On Mon, Jan 10, 2022 at 1:14 PM Basil Gunn <basil@...> wrote:

You do NOT need to eject the flash media before shutting down.
You SHOULD use the shutdown command before removing power.

Also you should do a 'sync' after writing a couple of gigs of data to a
device before yanking it out.  It would be a good idea to unmount the
file system as well.

This is good practice on ANY OS.

As I mentioned before if you are seeing corrupted micro SD cards it is
most likely because you purchased crappy SD cards or you are using
Windows to write to a Linux file system.

My experience is with several hundred mini SD cards accumulated over the
last decade (yes, before Raspberry Pis) and only 5 of them are corrupted
and unrecoverable. I collect data from sensors and write to the micro SD
card once a second and those cards have been running for years without a
problem. Micro SD cards are NOT as prone to corruption as some people
would have you believe.

Note the DRAWS image will fit on a 16GB flash device but 32GB is
better because it allows the wear leveling algorithm to work better.

Sorry if this sounds like a rant.

Gwen Patton <ardrhi@...> writes:

> At one time, I had a Western Digital PiDrive hooked up to my RasPi. A
> spinny disk is less likely to corrupt by shutting down without ejecting the
> media, because who actually DOES that with a hard drive? The trouble with
> the PiDrive was that it used way more power than I liked, and setting it up
> was finicky as hell. But power drops didn't usually corrupt it.
>
> The whole "eject the media before shutting down" thing just smacks of lazy
> systems architecture, though. I get around it on my main computer by never
> shutting it down unless I must. But still, why is there something sitting
> in cache that hasn't been written even after the machine has been sitting
> for the computer equivalent of a week? (About 3 seconds of meatspace time.)
> Just write the damn info out and clear the cache! You HAVE the time! I
> never understood that.
>
> -=-=-=-=-=-=-=-=-
> 73,
> Gwen, NG3P
>
>
> On Mon, Jan 10, 2022 at 2:45 PM Zonker <consoleteam@...> wrote:
>
>> It may be time to offer this;
>>
>>   One suggestion for preventing the corruption of your SD card is to
>> perform a shutdown of the Pi before pulling the power.  But, sometimes
>> power hiccups happen. Sometimes we forget to issue the command on the
>> keyboard. Things happen...
>>
>>   There are a few options (depending on your Pi model) for a UPS Hat, and
>> most come with a pushbutton to invoke the shutdown with a simple press. If
>> you are building your Pi into a grab-and-go box, you can connect a second,
>> remote pushbutton in parallel, where you can get to the second button
>> without unpacking your Pi. (Just make an effort to protect it from
>> unintended presses, and put it somewhere  where you see it before you pack
>> up your kit.)
>>
>>   The shutdown button will help protect your SD cards, and the battery is
>> another bit of protection.
>>
>>               Best regards,
>>
>>                de N6UOW
>>
>>
>>
>>
>
>
>






Re: DRAWS viability

Basil Gunn
 

You do NOT need to eject the flash media before shutting down.
You SHOULD use the shutdown command before removing power.

Also you should do a 'sync' after writing a couple of gigs of data to a
device before yanking it out. It would be a good idea to unmount the
file system as well.

This is good practice on ANY OS.

As I mentioned before if you are seeing corrupted micro SD cards it is
most likely because you purchased crappy SD cards or you are using
Windows to write to a Linux file system.

My experience is with several hundred mini SD cards accumulated over the
last decade (yes, before Raspberry Pis) and only 5 of them are corrupted
and unrecoverable. I collect data from sensors and write to the micro SD
card once a second and those cards have been running for years without a
problem. Micro SD cards are NOT as prone to corruption as some people
would have you believe.

Note the DRAWS image will fit on a 16GB flash device but 32GB is
better because it allows the wear leveling algorithm to work better.

Sorry if this sounds like a rant.

Gwen Patton <ardrhi@gmail.com> writes:

At one time, I had a Western Digital PiDrive hooked up to my RasPi. A
spinny disk is less likely to corrupt by shutting down without ejecting the
media, because who actually DOES that with a hard drive? The trouble with
the PiDrive was that it used way more power than I liked, and setting it up
was finicky as hell. But power drops didn't usually corrupt it.

The whole "eject the media before shutting down" thing just smacks of lazy
systems architecture, though. I get around it on my main computer by never
shutting it down unless I must. But still, why is there something sitting
in cache that hasn't been written even after the machine has been sitting
for the computer equivalent of a week? (About 3 seconds of meatspace time.)
Just write the damn info out and clear the cache! You HAVE the time! I
never understood that.

-=-=-=-=-=-=-=-=-
73,
Gwen, NG3P


On Mon, Jan 10, 2022 at 2:45 PM Zonker <consoleteam@gmail.com> wrote:

It may be time to offer this;

One suggestion for preventing the corruption of your SD card is to
perform a shutdown of the Pi before pulling the power. But, sometimes
power hiccups happen. Sometimes we forget to issue the command on the
keyboard. Things happen...

There are a few options (depending on your Pi model) for a UPS Hat, and
most come with a pushbutton to invoke the shutdown with a simple press. If
you are building your Pi into a grab-and-go box, you can connect a second,
remote pushbutton in parallel, where you can get to the second button
without unpacking your Pi. (Just make an effort to protect it from
unintended presses, and put it somewhere where you see it before you pack
up your kit.)

The shutdown button will help protect your SD cards, and the battery is
another bit of protection.

Best regards,

de N6UOW





Re: Pi es Hat temperature

Basil Gunn
 

Hi Larry,

heat dissipation might be a problem
1. Running pi_throt.sh will tell you if your Pi has ever been throttled
due to heat. ~/n7nix/debug/pitemp.sh will describe what the bits mean
for vcgencmd get_throttled

2. Installing rpi-temp-graph will give you definitive data if heat
dissipation is a problem. It plots CPU load, CPU temp and ambient temp.

https://github.com/n7nix/rpi-temp-graph#screen-shot-of-temperature--cpu-activity-plots

Note: running init_cfg.sh twice will install the graph setup.
You will need to install a DHT-11 or DHT-22 sensor
to measure ambient temp. Check on Amazon.
Notes on that here:
https://github.com/n7nix/rpi-temp-graph

Will the Geekworm armor heat sink interfere with the Aluminum DRAWS
case that NW Digital offers with the DRAWS Hat?
I'm guessing it will. You assume I have an Aluminum DRAWS case. I do
not. I use a 1U rack mount for 2 of them, some VESA mounts for the back
of monitors and a couple of variations of the Geekworm armor heat
sink. I use Artic Silver thermal paste. I don't use any fans. None of my
RPi 4's have heat problems as verified by pi_throt.sh and my temperature
graphs.

I am currently actively running 11 RPi's including the ones in my garage
& pump house. Four of them are RPi 4 or 400. Seven have DRAWS hats
installed.


Larry Nelson <lcnelson48@hotmail.com> writes:

Hi Basil

I will install the DRAWS hat on my Raspberry Pi 4 and will be doing
digital modes like FT8 and JS8 heat dissipation might be a
problem. Will the Geekworm armor heat sink interfere with the Aluminum
DRAWS case that NW Digital offers with the DRAWS Hat? If so I'll use a
fan. https://nwdigitalradio.com/products/draws™-case


Re: DRAWS viability

Gwen Patton
 

At one time, I had a Western Digital PiDrive hooked up to my RasPi. A spinny disk is less likely to corrupt by shutting down without ejecting the media, because who actually DOES that with a hard drive? The trouble with the PiDrive was that it used way more power than I liked, and setting it up was finicky as hell. But power drops didn't usually corrupt it.

The whole "eject the media before shutting down" thing just smacks of lazy systems architecture, though. I get around it on my main computer by never shutting it down unless I must. But still, why is there something sitting in cache that hasn't been written even after the machine has been sitting for the computer equivalent of a week? (About 3 seconds of meatspace time.) Just write the damn info out and clear the cache! You HAVE the time! I never understood that.

-=-=-=-=-=-=-=-=-
73,
Gwen, NG3P


On Mon, Jan 10, 2022 at 2:45 PM Zonker <consoleteam@...> wrote:
It may be time to offer this;

  One suggestion for preventing the corruption of your SD card is to perform a shutdown of the Pi before pulling the power.  But, sometimes power hiccups happen. Sometimes we forget to issue the command on the keyboard. Things happen...

  There are a few options (depending on your Pi model) for a UPS Hat, and most come with a pushbutton to invoke the shutdown with a simple press. If you are building your Pi into a grab-and-go box, you can connect a second, remote pushbutton in parallel, where you can get to the second button without unpacking your Pi. (Just make an effort to protect it from unintended presses, and put it somewhere  where you see it before you pack up your kit.)

  The shutdown button will help protect your SD cards, and the battery is another bit of protection.

              Best regards,

               de N6UOW


Re: Pi es Hat temperature

Larry Nelson
 

Hi Basil
I will install the DRAWS hat on my Raspberry Pi 4 and will be doing digital modes like FT8 and JS8 heat dissipation might be a problem. Will the Geekworm armor heat sink interfere with the Aluminum DRAWS case that NW Digital offers with the DRAWS Hat? If so I'll use a fan.
https://nwdigitalradio.com/products/draws™-case


Re: DRAWS viability

Zonker
 

It may be time to offer this;

  One suggestion for preventing the corruption of your SD card is to perform a shutdown of the Pi before pulling the power.  But, sometimes power hiccups happen. Sometimes we forget to issue the command on the keyboard. Things happen...

  There are a few options (depending on your Pi model) for a UPS Hat, and most come with a pushbutton to invoke the shutdown with a simple press. If you are building your Pi into a grab-and-go box, you can connect a second, remote pushbutton in parallel, where you can get to the second button without unpacking your Pi. (Just make an effort to protect it from unintended presses, and put it somewhere  where you see it before you pack up your kit.)

  The shutdown button will help protect your SD cards, and the battery is another bit of protection.

              Best regards,

               de N6UOW


Re: Panhead Screw Size for Case Bottom

Ed Bloom, KD9FRQ
 

Thank you.

Shopping list has been updated accordingly.

I am mounting the Pi onto a 1U short shelf (6in depth) in my nearly complete
Gator 4U Go Box.  The shelf will also hold the West Mountain Radio Power
Pole distribution panel.

The shelf will be covered by a 1U blank that will have a the GPS antenna bulk
head pass through and the Powerwerx PolePole connector.

The radios are mounted to Novexcomm plate that was modified to use their
wing brackets (no shelf needed cutting down the weight). A 1U drawer is being
modified to hold the 12v DC HDMI monitor.


-----Original Message-----
From: Bryan Hoyer <bhhoyer@...>
To: udrc@nw-digital-radio.groups.io
Sent: Wed, Jan 5, 2022 10:01 am
Subject: Re: [draws and udrc] Panhead Screw Size for Case Bottom

IIRC It's a #8

On Tue, Jan 4, 2022 at 4:36 PM Ed Bloom, KD9FRQ via groups.io <ewbloom=verizon.net@groups.io> wrote:
What size panhead screw fits into the bottom slot of the metal DRAWS case?

Looking to use them to mount the Pi / DRAWS.

73, Ed, KD9FRQ







Re: Pi es Hat temperature

Erwin OE1EKG
 

Hi,

does anyone have experiences with cooling the RaspiP4 with the DRAWS on it. It wasn't able to remove the 4 distance pieces? A couldn't find another cooling plate that fits in the container. So I want wo try to remove the original distancers and fix the cooling plate with own screws.
Second little problem is, that cause to be secure there should be a space between the cooler and the DRAWS hat so the connectors are a little apart.

73 de Erwin, OE1EKG


Re: Panhead Screw Size for Case Bottom

 

IIRC It's a #8


On Tue, Jan 4, 2022 at 4:36 PM Ed Bloom, KD9FRQ via groups.io <ewbloom=verizon.net@groups.io> wrote:
What size panhead screw fits into the bottom slot of the metal DRAWS case?

Looking to use them to mount the Pi / DRAWS.

73, Ed, KD9FRQ







Re: DRAWS viability

K3VIN
 

On Tue, Jan 4, 2022 at 08:14 PM, Chris Robinson KF6NFW DMR ID 3153250 wrote:
what size SSD are you using? any config issues or troubles? 
I had a 128 sd card with my image all setup and working. so I just matched that size SSD and wrote the sd card image backup to the SSD and it went flawlessly. I still maintain the sd card as a backup.

Kevin, K3VIN


Re: DRAWS viability

Jim VA7SHG/VE7TGZ
 

I have setup at my QTH a Raspberry Pi 4 with the DRAWS Hat.  I use a USB3.0 External SSD that I’ve setup for DRAWS and run it 24/7 as a LinBPQ Node with Winlink and a BBS on one side of the DRAWS, and a Message-only APRS igate on the other side.  It is rock solid.  Current uptime is 257 days. 

I believe the SSD is a Sandisk 1TB Extreme Portable SSD.  I have a video here (https://youtu.be/xkz7l23hyE8) in which I migrate a Build-A-Pi from a SD card to an SSD in an ARGON One case.  I took the same steps when I moved my DRAWS to the Sandisk.  Hope that helps.

------
73,
Jim
VA7SHG - Phone
VE7TGZ/VA7TGZ - Other

On Jan 4, 2022, at 17:14, Chris Robinson KF6NFW DMR ID 3153250 <kf6nfw@...> wrote:

what size SSD are you using? any config issues or troubles? 

 
 

1 - 20 of 6031