Hi Basil,

Just when I thought everything was pretty stable, I started to get protests
from xastir that my GPS wasn't behaving. Dropped out of xastir and ran
gpsmon only receive a blank stare... Unfortunately did not check to see that
the alsa config was recognized... but for some 23:59EDT reason put a new SSD
with image 15 in and did a core config. (I do have the old microSD card
saved).

Well - things seemed to be OK as I followed the setup steps until I ran
alsa-show.sh and it gave a matrix of nothing entries, then gpsmon gave me a
blank stare.

I then ran showudrc.sh and got the following which seems to indicate that I
hosed the configuration somehow or the DRAWS card is behaving abnormally:
-----------------------------------------------------------------------
pi@kd4izdraws1:~/n7nix/config $ showudrc.sh
==== Sound Card ====
udrc card number line: card 1: udrc [udrc], device 0:
bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0
[bcm2835-i2s-tlv320aic32x4-hifi tlv320aic32x4-hifi-0]
udrc is sound card #1
==== ALSA Controls for Radio Tansmit ====
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
LO Driver Gain L: R:
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
PCM L: R:
amixer: Mixer hw:1 load error: Remote I/O error
==== ALSA Controls for Radio Receive ====
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
ADC Level L: R:
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
amixer: Mixer hw:1 load error: Remote I/O error
IN1 L:[] R:[]
IN2 L:[] R:[]
==== Pi Ver ====
Pi 3 Model B+, Rev 1.3, Mfg by Sony UK
Has WiFi
==== udrc Ver ====
Found a DRAWS

HAT ID EEPROM
Name: hat
Product: Digital Radio Amateur Work Station
Product ID: 0x0004
Product ver: 0x0405
UUID: 6170bac5-b90e-462b-8dec-8f564d9cbbe5
Vendor: NW Digital Radio

==== sys Ver ====
----- image version
2020 01 23 09:25:01 PST: SD image version: nwdr15
----- /proc/version
Linux version 4.19.97-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG
crosstool-ng-1.22.0-88-g8460611)) #1294 SMP Thu Jan 30 13:15:58 GMT 2020

----- /etc/*version: 10.3

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

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

---- systemd
Static hostname: kd4izdraws1
Icon name: computer
Machine ID: 27ac1f0c20904cb7a960920e966db545
Boot ID: 5c158adeda3043cda9402f8dc718f6d3
Operating System: Raspbian GNU/Linux 10 (buster)
Kernel: Linux 4.19.97-v7+
Architecture: arm

---- modules
snd_soc_tlv320aic32x4_i2c 16384 48
snd_soc_tlv320aic32x4 40960 1 snd_soc_tlv320aic32x4_i2c
snd_soc_core 192512 4
snd_soc_simple_card_utils,snd_soc_bcm2835_i2s,snd_soc_tlv320aic32x4,snd_soc_
simple_card
snd_pcm 102400 5
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_pc
m

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

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

---- syslog

---- dmesg


----- Dire Wolf DEVELOPMENT version 1.6 D (Jan 6 2020)

==== Filesystem ====
/dev/root 29G 5.3G 22G 20% /

==== boot config ====
[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

# Flush all overlays, ie. deprecated overlays loaded from eeprom
dtoverlay=
# enable udrc/draws if no eeprom
dtoverlay=draws,alsaname=udrc
force_turbo=1
# Enable audio (loads snd_bcm2835)
dtparam=audio=on

---- gpsd
/usr/local/sbin/gpsd
gpsd: 3.20 (revision 3.20)
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; enabled; vendor preset:
enabled)
Active: active (running) since Tue 2020-03-31 16:36:26 EDT; 4min 41s ago
Process: 509 ExecStart=/usr/local/sbin/gpsd $GPSD_OPTIONS $OPTIONS
$DEVICES (code=exited, status=0/SUCCESS)
Main PID: 511 (gpsd)
Tasks: 1 (limit: 2200)
Memory: 1.1M
CGroup: /system.slice/gpsd.service
└─511 /usr/local/sbin/gpsd -n /dev/ttySC0 /dev/pps0

Mar 31 16:36:26 kd4izdraws1 systemd[1]: Starting GPS (Global Positioning Sy
…n...
Mar 31 16:36:26 kd4izdraws1 systemd[1]: Started GPS (Global Positioning Sys
…mon.
Hint: Some lines were ellipsized, use -l to show in full.

---- chrony
crw------- 1 root root 241, 0 Mar 31 16:36 /dev/pps0
crw-rw---- 1 root dialout 239, 0 Mar 31 16:36 /dev/ttySC0
crw-rw---- 1 root dialout 239, 1 Mar 31 16:36 /dev/ttySC1
-- chrony sources
210 Number of sources = 6
MS Name/IP address Stratum Poll Reach LastRx Last sample

============================================================================
===
#? GPS 0 3 0 - +0ns[ +0ns] +/-
0ns
#? PPS 0 3 0 - +0ns[ +0ns] +/-
0ns
^- darwin.kenyonralph.com 2 6 77 107 -2007us[-3418us] +/-
79ms
^- atl1.ntp7.mattnordhoff.n> 2 6 177 43 -1306us[-1697us] +/-
54ms
^* ellone.fdisk.io 2 6 177 41 -249us[ -641us] +/-
14ms
^- fin.mattnordhoff.net 2 6 177 42 +270us[ -122us] +/-
50ms
-- chrony tracking
Reference ID : 30FED930 (ellone.fdisk.io)
Stratum : 3
Ref time (UTC) : Tue Mar 31 20:40:26 2020
System time : 0.000266782 seconds slow of NTP time
Last offset : -0.000392392 seconds
RMS offset : 0.001072069 seconds
Frequency : 2.079 ppm fast
Residual freq : -2.085 ppm
Skew : 17.376 ppm
Root delay : 0.027547063 seconds
Root dispersion : 0.001782908 seconds
Update interval : 64.9 seconds
Leap status : Normal
-- chrony sourcestats
210 Number of sources = 6
Name/IP Address NP NR Span Frequency Freq Skew Offset Std
Dev
============================================================================
==
GPS 0 0 0 +0.000 2000.000 +0ns
4000ms
PPS 0 0 0 +0.000 2000.000 +0ns
4000ms
darwin.kenyonralph.com 6 4 136 +3.546 18.414 -1660us
337us
atl1.ntp7.mattnordhoff.n> 7 3 200 +0.169 7.690 -1323us
211us
ellone.fdisk.io 7 5 201 -2.085 21.671 -87us
586us
fin.mattnordhoff.net 7 4 201 -0.646 19.456 +210us
437us

---- sensors
-rw-r--r-- 1 root root 171 Sep 19 2019 /etc/sensors.d/draws
rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A ALARM (LCRIT)

ads1015-i2c-1-48
Adapter: bcm2835 I2C adapter
+12V: +0.00 V
in5: +0.53 V
User ADC 1: +0.01 V
User ADC 2: +0.00 V


---- throttle
temp=69.3'C
throttled=0xd0005

---- locale
Locale country codes consistent among WiFi cfg file, iw reg & X11: US
core_config.sh has been run 1 time(s)
pi@kd4izdraws1:~/n7nix/config $
-----------------------------------------------------------------------

I've tried my best to follow the output above to troubleshoot, but have a
bit of difficulty with what I see other than the obvious.

SO:
Should I wait for image 16, try another install then?
Do you see something that got flipped the wrong way by me when running
./app_config.sh core?

Hi Jack,
If I could give out prizes for most interesting symptoms you would
definitely get a prize.

First Pass at your console output.
Drivers are loading fine, no software faults, hardware is definitely
stressed, gps not working, codec not working

Second Pass at your console output.
Your RPI is running at over 150F and will soon catch fire if you don't
DISCONNECT THE POWER. From vcgencmd throttled=0xd0005

- Temperature limit has occurred
- Throttling has occurred
- Under voltage has occurred
The RPi is currently running throttled & under-voltage

Just recently I have seen someone else's RPi start running really hot.
Also check your 5V RPi wall wart. Is it warm/hot?

/Basil n7nix

See embedded below.

Jack Spitznagel <@flyingfrawg> writes:

Hi Basil,

Just when I thought everything was pretty stable, I started to get protests
from xastir that my GPS wasn't behaving.
... snip...
---- sensors
-rw-r--r-- 1 root root 171 Sep 19 2019 /etc/sensors.d/draws
rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A ALARM (LCRIT)

ads1015-i2c-1-48
Adapter: bcm2835 I2C adapter
+12V: +0.00 V
in5: +0.53 V
User ADC 1: +0.01 V
User ADC 2: +0.00 V


---- throttle
temp=69.3'C
throttled=0xd0005

SO:
Should I wait for image 16, try another install then?

Nope.

Do you see something that got flipped the wrong way by me when running
./app_config.sh core?

Software config looks OK.

Ok.... now, I did not notice that set of TEMP lines in the output because I
was so focused on the sound device/ALSA and GPS lines. I have heatsinks on
the Pi. I have not heard that lack of ventilation of the Pi on a Sunfounder
display is an issue even with hats in place... I do not use a wallwart.

The Pi has seemed to run happily off the aux 5V USB power out from the
Sunfounder 10' display. The display is fed from a 25A 13.9V power supply via
3A fused line from a multi-powerpole type distro panel. No problems in over
a year 'til now. I did notice the undervoltage lightning bolt on the X
display however. A crappy old DVM says the voltage is 13.77 at the plug to
the display with all other devices on the buss operating. I don't have a USB
voltage monitor around, so I don't know what the display USB line is putting
out but obviously the Pi thinks it is low.

The Pi did not seem to be acting sick by itself. Could it be the power
source or should I not trust the PI at all?

If you think I can trust the Pi, I could always take a different power
supply tactic and use the buck supply line in the DRAWs card for the Pi and
feed the display from a separate line.

Thanks for playing Doc!

Jack - KD4IZ

Ya that was a little too dramatic. While your RPi is running much hotter
than any of mine on the bench @ 69C it won't catch fire. It looks like
the "official" operating limit is around 85C and will start to thermally
throttle at around 82C which your RPi has already hit.

So yes your RPi is running suspiciously hot and no it probably won't
catch fire.
/Basil

Basil Gunn <@basil860> writes:

Hmmm... and Pi was feeding the DRAWS card, not visa-versa... but that should
not be causing the CPU to overheat!
-Jack

So things to do to help triage the problem:

* Keep a continuous eye on the temperature
In a console window
cd
cd n7nix/debug
watch ./pitemp.sh

* Using pitemp.sh note the temperature at boot & after 1/2 hour
* Remove the DRAWS hat, boot, note the temperature & after a 1/2 hour

* When you re-install DRAWS hat check for being off by one on the
40pin connector.
* Power down RPi with DRAWS hat, let RPi cool down
At cool power up is the DRAWS hat working?
* just run alsa-show.sh and look for something reasonable.
* Do a close visual inspection of the DRAWS hat & RPi.
* Anything look charred?

* Feel the USB cable powering your RPi does it feel warm?

More things to try as you suggested.

The Pi did not seem to be acting sick by itself.
Could it be the power source or should I not trust the PI at all?

It is suspicious to me that the RPi gives the low voltage symptom
(lightning bolt). Is it the power supply or is the DRAWS card loading
the RPi voltage source?

The following is not a bad idea but I would confirm that there is not
something seriously fried on the DRAWS hat first.

If you think I can trust the Pi, I could always take a different power
supply tactic and use the buck supply line in the DRAWs card for the Pi and
feed the display from a separate line.

/Basil

Jack Spitznagel <@flyingfrawg> writes:

Hmmm... and Pi was feeding the DRAWS card, not visa-versa... but that should
not be causing the CPU to overheat!
-Jack

-----Original Message-----
From: udrc@nw-digital-radio.groups.io <udrc@nw-digital-radio.groups.io> On
Behalf Of Basil Gunn
Sent: Tuesday, March 31, 2020 18:49
To: udrc@nw-digital-radio.groups.io
Subject: Re: [draws and udrc] #DRAWS oddity, GPS and ALSA headaches


Ya that was a little too dramatic. While your RPi is running much hotter
than any of mine on the bench @ 69C it won't catch fire. It looks like the
"official" operating limit is around 85C and will start to thermally
throttle at around 82C which your RPi has already hit.

So yes your RPi is running suspiciously hot and no it probably won't catch
fire.
/Basil

Basil Gunn <@basil860> writes:

Hi Jack,
If I could give out prizes for most interesting symptoms you would
definitely get a prize.

First Pass at your console output.
Drivers are loading fine, no software faults, hardware is definitely
stressed, gps not working, codec not working

Second Pass at your console output.
Your RPI is running at over 150F and will soon catch fire if you don't
DISCONNECT THE POWER. From vcgencmd throttled=0xd0005

- Temperature limit has occurred
- Throttling has occurred
- Under voltage has occurred
The RPi is currently running throttled & under-voltage

Just recently I have seen someone else's RPi start running really hot.
Also check your 5V RPi wall wart. Is it warm/hot?

/Basil n7nix

See embedded below.

Jack Spitznagel <@flyingfrawg> writes:

Hi Basil,

Just when I thought everything was pretty stable, I started to get
protests from xastir that my GPS wasn't behaving.
... snip...
---- sensors
-rw-r--r-- 1 root root 171 Sep 19 2019 /etc/sensors.d/draws
rpi_volt-isa-0000
Adapter: ISA adapter
in0: N/A ALARM (LCRIT)

ads1015-i2c-1-48
Adapter: bcm2835 I2C adapter
+12V: +0.00 V
in5: +0.53 V
User ADC 1: +0.01 V
User ADC 2: +0.00 V


---- throttle
temp=69.3'C
throttled=0xd0005

SO:
Should I wait for image 16, try another install then?

Nope.

Do you see something that got flipped the wrong way by me when
running ./app_config.sh core?

Software config looks OK.

Hi Basil,

Good news/bad news story:
DRAWS hat appears to be OK, the Pi3B+ is a sick puppy. Silver lining:
discovered just how fast everything DRAWS seems to respond with a Pi4. That
may be the replacement board I pick. The 1GB versions have gotten fairly
cheap.

See inline after your suggestions below:

* Keep a continuous eye on the temperature In a console window cd cd
n7nix/debug watch ./pitemp.sh

// never bothered with pitemp.sh - just used vcgencmd measure_temp to start

with & GPU temp

// kept rising, so removed the DRAWS board, let the Pi cool, booted vanilla

Rasbian Buster

// and the GPU temp headed toward 65C very quickly. Both GPU and CPU sinks

were very hot to touch so

// shut it down so not to waste time to create pitemp.sh on the sick Pi in

vanilla buster.

// AT this point I decided the Pi3B+ board was ailing and did not push it.

* Using pitemp.sh note the temperature at boot & after 1/2 hour

// Skipped this as noted above

* Removed the DRAWS hat, boot, note the temperature & after a 1/2 hour

// Skipped, see above

* When you re-install DRAWS hat check for being off by one on the 40pin
connector.

// it is on all 40 pins correctly - that is one of my personal QC checks -

burnt up my first pi making that error

* Power down RPi with DRAWS hat, let RPi cool down At cool power up is the
DRAWS hat working?
* just run alsa-show.sh and look for something reasonable.

// I did this and the symptoms were the same, nothing in alsa-show.sh

output and nothing

// from gpsmon other than it "could not find the device at localhost port

2XXX" whatever.

* Do a close visual inspection of the DRAWS hat & RPi.
* Anything look charred?

// Nope! Just two very hot to touch processors - both have heat sinks on

them too! That may have

// been what prevented a total meltdown.

* Feel the USB cable powering your RPi does it feel warm?

// Neither power cable configuration got warm

More things to try as you suggested.

The Pi did not seem to be acting sick by itself.
Could it be the power source or should I not trust the PI at all?
// wired the buck regulator feed to the display power line and saw the same

symptoms with the Pi3B+

// THEN I subbed in a Pi4 (4GB) that I have been playing with and it fired

right up. DRAWS came up and

// behaved normally for alsa-show and gpsmon including no lightning bolt

while running off the buck

// regulator on the DRAWS board.

QUESTION:

// Is it OK to run a Pi4 off the DRAWS buck regulator? - I vaguely remember

discussion concluding it was.

It is suspicious to me that the RPi gives the low voltage symptom (lightning
bolt). Is it the power supply or is the DRAWS card loading the RPi voltage
source?

The following is not a bad idea but I would confirm that there is not
something seriously fried on the DRAWS hat first.

If you think I can trust the Pi, I could always take a different power
supply tactic and use the buck supply line in the DRAWs card for the
Pi and feed the display from a separate line.

SO: The Pi4 is good with the DRAWS but the Pi3 is the second I have
consigned to the junk bin. Something probably munged up the GPIO lines
needed by the sound and GPS subsystems - have no idea what and @ <$30 for a
replacement, it ain't worth fretting about. Solution found.

Hi Jack,
Taking your responses out of order.

it ain't worth fretting about. Solution found.

Yep, totally agree. Get another RPi and continue having some fun. A
friend of mine had exactly the same symptom on a Pi 3B. I have 6 RPi's
on my bench running 24/7 and haven't seen the problem with any yet. At
least two of the RPi's are RMS Gateways that have been running for a
couple of years.

I am going to add a cron job to all my RPis that check's being throttle
& over temperature as in the case you had where vcgencmd get_throttled
returned 0xd0005.

vcgencmd get_throttled
https://www.raspberrypi.org/documentation/raspbian/applications/vcgencmd.md

// Is it OK to run a Pi4 off the DRAWS buck regulator? - I vaguely remember
discussion concluding it was.

Yep. I have 2 RPi 4's (2GB, 4GB) running powered by the DRAWS 12 V buck
regulator with no problem. Actually all my RPi's run from 12 V. I never
have problems with under voltage & it is a lot easier to manage a bunch
of power pole connectors than a bunch of wall warts plugged into a power
strip.

// it is on all 40 pins correctly - that is one of my personal QC checks -
burnt up my first pi making that error

You are not an RPi expert unless you burn at least one up.
I killed two due to mDin6 control cable laying on antenna coax. Didn't
learn my lesson the first time.

Glad to hear you are back up & running.
/Basil n7nix

Jack Spitznagel <@flyingfrawg> writes:

Hi Basil,

Good news/bad news story:
DRAWS hat appears to be OK, the Pi3B+ is a sick puppy. Silver lining:
discovered just how fast everything DRAWS seems to respond with a Pi4. That
may be the replacement board I pick. The 1GB versions have gotten fairly
cheap.

See inline after your suggestions below:

* Keep a continuous eye on the temperature In a console window cd cd
n7nix/debug watch ./pitemp.sh

// never bothered with pitemp.sh - just used vcgencmd measure_temp to start

with & GPU temp

// kept rising, so removed the DRAWS board, let the Pi cool, booted vanilla

Rasbian Buster

// and the GPU temp headed toward 65C very quickly. Both GPU and CPU sinks

were very hot to touch so

// shut it down so not to waste time to create pitemp.sh on the sick Pi in

vanilla buster.

// AT this point I decided the Pi3B+ board was ailing and did not push it.

* Using pitemp.sh note the temperature at boot & after 1/2 hour

// Skipped this as noted above

* Removed the DRAWS hat, boot, note the temperature & after a 1/2 hour

// Skipped, see above

* When you re-install DRAWS hat check for being off by one on the 40pin
connector.

// it is on all 40 pins correctly - that is one of my personal QC checks -

burnt up my first pi making that error

* Power down RPi with DRAWS hat, let RPi cool down At cool power up is the
DRAWS hat working?
* just run alsa-show.sh and look for something reasonable.

// I did this and the symptoms were the same, nothing in alsa-show.sh

output and nothing

// from gpsmon other than it "could not find the device at localhost port

2XXX" whatever.

* Do a close visual inspection of the DRAWS hat & RPi.
* Anything look charred?

// Nope! Just two very hot to touch processors - both have heat sinks on

them too! That may have

// been what prevented a total meltdown.

* Feel the USB cable powering your RPi does it feel warm?

// Neither power cable configuration got warm

More things to try as you suggested.

The Pi did not seem to be acting sick by itself.
Could it be the power source or should I not trust the PI at all?
// wired the buck regulator feed to the display power line and saw the same

symptoms with the Pi3B+

// THEN I subbed in a Pi4 (4GB) that I have been playing with and it fired

right up. DRAWS came up and

// behaved normally for alsa-show and gpsmon including no lightning bolt

while running off the buck

// regulator on the DRAWS board.

QUESTION:

// Is it OK to run a Pi4 off the DRAWS buck regulator? - I vaguely remember

discussion concluding it was.

It is suspicious to me that the RPi gives the low voltage symptom (lightning
bolt). Is it the power supply or is the DRAWS card loading the RPi voltage
source?

The following is not a bad idea but I would confirm that there is not
something seriously fried on the DRAWS hat first.

If you think I can trust the Pi, I could always take a different power
supply tactic and use the buck supply line in the DRAWs card for the
Pi and feed the display from a separate line.

SO: The Pi4 is good with the DRAWS but the Pi3 is the second I have
consigned to the junk bin. Something probably munged up the GPIO lines
needed by the sound and GPS subsystems - have no idea what and @ <$30 for a
replacement, it ain't worth fretting about. Solution found.

Basil,

The saga continues.

It also turns out that the original GPS/LNA antenna had gone bad along with
the Pi3B+. It was working before the RPi started into the overheating
problem. So what ever started the heating problem took out the ability to
connect to the DRAWS hat and apparently the GPS antenna...

I tried the GPS antenna from the other DRAWS unit I have in my GO box and it
came right up. Just ordered another from you.

Note: The Pi4 B+ really needs a fan... runs 55 to 60C without, 35-37C with.
Had a 12V microfan sitting in the junk box, wired it in, and the Pi stays
cool now.

I have a case on back order. Does it have a place for a fan mount?

Jack - kd4iz

Hi Jack,

It also turns out that the original GPS/LNA antenna had gone bad along with
the Pi3B+. It was working before the RPi started into the overheating
problem. So what ever started the heating problem took out the ability to
connect to the DRAWS hat and apparently the GPS antenna...

I tried the GPS antenna from the other DRAWS unit I have in my GO box and it
came right up. Just ordered another from you.

I found these also work:
https://www.amazon.com/gp/product/B00LXRQY9A/ref=ppx_yo_dt_b_search_asin_title

Note: The Pi4 B+ really needs a fan... runs 55 to 60C without, 35-37C with.
Had a 12V microfan sitting in the junk box, wired it in, and the Pi stays
cool now.

Yes I agree. Pi4's run cool enough when laying naked on my bench but as
soon as you put them into any kind of enclosure they heat up.

I have a case on back order. Does it have a place for a fan mount?

Don't know. Bryan or John need to answer that.

Jack - kd4iz

I am using this Adafruit antenna...because it has a 5M long cable...

https://www.amazon.com/gp/product/B013EUOCZ6/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Hi Basil,

Well, I finally got a chance to do a "multiswap" to see what hardware is
working and what is not with this DRAWS system.

Previously determined that the GPS antenna we have discussed was bad by
swapping on to a good DRAWS/Pi unit that was working fine with another
antenna. Ordered a replacement which arrived last week.

Finally got some time to reconfigure so... before putting the new GPS
antenna on the DRAWS unit that had the antenna failure, I tested both DRAWS
boards with a good Pi3B+ and the remaining good GPS antenna that I have. I
was worried because there had been some heating that took place when the GPS
antenna failed.

The DRAWS board that had the antenna go bad apparently also has a bad GPS
chip:

-When I was testing it a week ago or so with the good antenna from my GO
kit, it "seemed OK", but was very sluggish getting a fix and there seemed to
be a lot of position jitter when it did acquire some satellites. ALSA
indicated the UDRC BCM chip was working. The GPS chip seemed to get a bit
warm, but not alarmingly.

-Today's testing, the DRAWS board in question did not get a fix and no
matter how long after starting the units, no satellites were acquired. ALSA
did appear to work. GPSMON show 4 satellites in the list, but consistently
only shows 00.0000 for coordinates no matter how long I left it.

With the same antenna and same Pi3B+ with the other DRAWS board mounted, the
full GPSMON display comes up immediately and all systems check out. Xastir
runs flawlessly.

I guess this moves to a Brian question... Is the DRAWS board repairable or
swappable for a fee? I most likely am past any reasonable warranty time and
I need this unit for my go kit.

73 and Thanks!

KD4IZ
Jack Spitznagel
FM19oo