Raspberry Pi Cooler

Ever since the Raspberry Pi 4 came out, there has been concern of the CPU and board overheating, and rightly so. After trying many cooling configurations, I finally landed on a cool answer to this hot problem, with great success.

The pictured heat sink armor case is the fan-less version by Geekworm. I believe it may be sold under several other names as well. There is a dual-fan version of this case, but based on personal experience, I would not recommend using it because the fans are junk and the fan wiring prohibits the use of hats on the GPIO pins.

This Argon Artik fan is a very quiet, programmable fan hat set on an extended GPIO so it clears the case nicely. In this configuration, the RPi 4 CPU temps have never gone above 43 degrees Celsius, and the fan speed has not yet run higher than 10%, or at least the 25% LED indicator. I haven't timed the fan cycle, but it's off far more than it's on, which should lead to a nice long fan life. Custom programming provides a scaled response to CPU temperature rise. I programmed this to:

• 43 C, fan on 10%
• 45 C, fan on 25%
• 50 C, fan on 50%
• 55 C, fan on 75%
• 60 C, fan on 100%

As you can see from the photo, a second hat can be mounted nicely on top of the fan using a male/male pin set. Here, a ZUM Radio repeater controller is mounted on top, and the fan works flawlessly cooling the Pi as well as the repeater controller. An RTC or other less-than-full-size hat may be a little awkward, but for the big boards, it's a go.

Raspberry Pi 3 model B+ with the same setup works fan-tastic

How much do I like this setup? I have the same thing on all of my RPi's, and I must say, this makes for one cool Raspberry Pi!

GOTA

updated: 10/05/2020

APRS SDR iGate Update

The distance from stations heard in Michigan seems to indicate some assisting propagation over Lake Michigan.

After four days of almost continuous operation, the APRS SDR receive-only iGate seems to be working well. I did two reboots to test the auto-connect between Direwolf and APRS-IS and it worked perfectly. The Xastir software was restarted manually and the configuration settings loaded and returned to my settings as expected. 

Seeing that the data was feeding as it should, I closed the terminal window displaying the Direwolf journal, so now I'm just viewing the Xastir map. I have the map intensity is set to 70% so station activity stands out better. I may play around with this a bit, and I may look for a different map.

On the iGate Data page, I have some performance statistics listed, but a picture is still worth a thousand words, and maybe three bar graphs. Here is a station heard radius provided by APRS Direct. The radius they are showing is about 18 miles. I agree with their assessment, as this is the area from which a majority of stations are heard by my station.

 

Here's a few stations that fall outside of the majority curve. The KD9JSX-14 mobile station was heard from a distance of 32 miles. The AB9HH-10 station in Milwaukee, at a distance of 42.7 miles, accounts for over 65% of all packets received. The KB9OIV-1 station comes in from 46.7 miles, and three Michigan stations are heard from 89.4 miles over Lake Michigan.

Raspberry Pi APRS with SDR

For complete information on this project, see the APRS page.

While experimenting with the Raspberry Pi 3B+ APRS receiver, the Pi is temporarily running Gqrx SDR software with an AFSK1200 decoder. 

How does the RPi 3B+ handle the demand of processing with the SDR? The CPU is averaging a pretty busy 55% load. The Argon programmable fan is doing a good job keeping everything cool as it cycles on at 42C with 10% fan speed, and off at 38C. The fan cycle time is about 1:3 minutes on/off in a 69F degree environment. 

In comparison, monitoring the CPU load on the K9KMS MMDVM repeater while it's in use (not idle), I found it to be less than a 2% load. This MMDVM repeater runs on a Raspberry Pi 4B, so it's not exactly an apples-to-apples comparison, but running the Gqrx software to get the APRS data is obviously much more demanding. This will likely result in a shorter life expectancy for the RPi using this approach, so scratch Gqrx off the list and find something to process data, not radio frequency.

On Sep 21, 2020 at 17:39 UTC, the decoder ran until 00:30 (6+ hours) and logged 1,029 hits, an average of 171.5 hits per hour. Not too bad considering the surrounding forest and lowland lakefront area.

Read about this project's exciting continuation on the APRS page!

FT-7900R ZUM Repeater Build - Part 3

Repeater Build Part 1 - Repeater Build Part 2 - Repeater Build Part 3

Over the last two weeks, I have been experimenting with various settings on the FT-7900R ZUM Radio Pi-Star repeater. After going through frequency calibrations, TX delay and TX/RX offset settings, I'm still having an issue with one particular thing.

The Problem

I have been unable to mitigate what seems to be a delay in the digital processing. This occurs after releasing the PTT of a transmitting radio. A short <1 second clip of the last transmission is heard coming back over the transmitting radio from the repeater. If you have ever heard a short-path long-path echo, you know what I'm trying to describe. It's more annoying than anything else, but something I'd rather not have happening, if at all possible.

Having gone through everything I could think of with the Pi-Star software settings (a short list for me), I began looking at hardware. Everything appeared to be working as it should, but then I had a light-bulb moment: "Maybe it really is a signal processing-induced delay."

Modification

The repeater is built around a Raspberry Pi 3 B+ that I once used as a desktop computer, even though it was pretty slow. When the Raspberry Pi 4 came out, I made the 3B to 4B change, and Wow! What a difference in performance! So if it made such a huge difference in a desktop environment, I wonder what it will do in a repeater controller environment. There's one way to find out.

A few minutes later, I had the Rpi 3 B+ disconnected from the ZUM Radio controller and replaced with a Raspberry Pi 4 B 2GB fitted with a full heat sink case and Argon programmable fan. I swapped out the Raspberry Pi OS card with a back-up copy of the Pi-Star repeater image and in under five minutes, the repeater was up and running.

Result

Almost any reasonable thing is worth trying when you are experimenting. For this repeater project, it has been a little of this. a little of that, old parts, spare parts, and a lot of fun. As for the Raspberry Pi 3 B+ to 4 B computer swap, I hear no perceptible difference with the original delay echo problem.

Hey, if nothing else, it looks like the blinking LED on the USB/Serial converter for the Nextion display is blinking a little faster, but that could just be me. So for now, I'll leave it with the Rpi 4 B and monitor the CPU temperature and Argon fan activation cycle frequency for a while.

New Hypothesis

Maybe the delay echo is caused by the collinear antenna setup feeding back, even running at very low power. I guess I'll find out when I get my frequency allocations from the Wisconsin Association of Repeaters and get a duplexer ordered, tuned, and installed.

Repeater Build Part 1 - Repeater Build Part 2 - Repeater Build Part 3

FT-7900R ZUM Repeater Build - Part 1

Repeater Build Part 1 - Repeater Build Part 2 - Repeater Build Part 3

 

Here is a project involving a ZUM Radio duplex MMDVM and a Raspberry Pi 3 B+ combined with my trusty old Yaesu FT-7900 and FT-7800 radios, and a couple of mini-DIN cables. Together, a trial version of small digital all-mode repeater capable of full duplex D*Star, DMR, NXDN, P25, POCSAG, and Yaesu System Fusion should be the result. If this works out as expected, I will likely be seeking out an old GE Master II, or any other robust analog repeater, to handle whatever mode is selected.

Pins and Colors

So it's been a little while, and I finally figured it all out. Part of the problem I found was the Yaesu CT-39A mini-DIN wire color was incorrect for the pin location. So lets forget about colors and talk straight up pin number to pin number. Conduct a simple ohms test on your mini-DIN cable pins to determine what color goes to what pin (my Electronics-101 oversight...)

As stated on page 10 of the Yaesu FT-7900R user manual, the pins are identified by both number and function. Using this, combined with the pin information from the ZUM Radio, I found the following connections to work properly using one FT-7900R as a simplex digital mode repeater.

Note: Two wires on the CT-39A mini-DIN are not used: Yellow (RX1200), and second Black (shield ground).

The pins - looking at the back of the FT-7900R - are identified in the following locations. The locator tab will be at the bottom center.

 

Pin 1: top left - PKD (DATA IN)
Pin 2: top right - GND
Pin 3: middle left - PTT
Pin 4: middle right - RX9600
Pin 5: bottom left - RX1200
Pin 6: bottom right - PKS (SQL)


Keep in mind, this will transmit when anyone keys up on the WIRES-X, YSF, or FSC rooms you are connected to. Be sure to keep the power as low as possible for your needs, and share the air.

Now to get a repeater frequency allocation from the Wisconsin Association of Repeaters and get this working as a duplex repeater!

Pi Cooler

The Raspberry Pi ZUM repeater board gets a new case and a custom fan install to keep things nice and cool. This is a HiFiBerry box, which is tall enough to have a GPIO hat and a fan inside. I cut a 1.125" in the top and mounted a Pi fan inside, blowing directly down on the ZUM Radio hat and Raspberry Pi. Temps stay under 40 degrees C.

Repeater Case

There it was, down in the basement. A lonely old Windows computer that has seen it's better days. Perfect! I gutted all the hardware out, saved everything that was still good, and prepared the case to be converted into my new ZUM repeater box.

I was able to rewire the existing power supply to reduce the number of wires clumped together for the previous occupant of this case. Now I have 17 amps of 12 volts, 18 amps of 5 volts, and 11 amps of 3.3 volts available, all regulated and fan-cooled. This works out perfect for all my needs.

Getting everything positioned in the case is pretty easy, so long as the fans have coordinated air movement over the radios and through the case.

I'll need to fabricate a new front face plate to incorporate the two radio faces, a Nextion touch screen, the voltage and temp monitor, and the power switches. The Raspberry can be controlled via SSH, but a re-program of the Nextion screen can provide the shutdown capabilities I am looking for. It should work well and look pretty nice when it's all done.

Propagation Estimation

I found a tool online to help estimate propagation from the repeater's site at Radio Mobile Online. The parameters I used for the estimate are a 6 db vertical antenna at 55 feet on 146 MHz. This, of course, only gives a general idea of coverage. The actual specs will be used as soon as I get the frequency allocation from the Wisconsin Association of Repeaters.

This map is at 5 watts output. Since the goal is to serve the surrounding communities, I would like to keep the repeater at 5 watts to prolong the life of the FT-7900R driving the repeater, but a real-world test today around the area had the 5 watts barely making 5 miles; at 6 miles there was almost no squelch break on the Yaesu FTM-400XDR in the car. I was always told to expect one mile per watt on the ground, so I'm not really surprised. My Diamond X300 antenna, at 55 feet, is basically on the ground, here in the woods.



For comparison, I can hit the WE9COM repeater in Plymouth from my QTH using my FT-70D and FT-2D on 5 watts. The RFinder app lists this repeater as 14.1 miles from my QTH. This is 2.82 miles per watt. Here is an example of antenna height making all the difference.

Below is a map I made with a 5 mile, 10 mile, and 15 mile radius. If one watt per mile on the ground holds true, this map should be better aligned with real-world expectations and performance.

Repeater Build Part 1 - Repeater Build Part 2 - Repeater Build Part 3