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!

Wire Antenna Suspension System

Back in October, 2019 I started planning a way to get the Barker & Williamson BWD-90 folded dipole up and running. Well, now it's up and here's how I did it.

Materials

350 feet of good 3/16" cord

Three (3) stainless steel pulleys (only 2 if your tower standoff arm already has pulleys)

Three (3) weights of the same weight (I cut solid metal bars to 5 pounds each)

Tools

A good throw line with launcher

A cutter for the cord

A lighter to melt the cord ends

How To

With a throw line, pull the two pulley cords (the red lines in the drawing) up and over the two support branches. Temporarily, leave the end with the pulley within reach from the ground.

Attach a cord to each end of the dipole antenna. 

Pass the antenna cords through the pulleys, leaving a generous length of cord on each end to accommodate for it's final horizontal length and vertical height. 

Temporarily attach a weight to each of these antenna cord ends.

If you are using a center support cord, attach a cord to an insulated center part of the antenna. Take the other end and run it through the center pulley. Tie a knot so it can't fall out of the pulley.

Pull the pulley cords, lifting the pulleys to full height. Leave about 18 inches of cord between the pulley and the support branch. While lifting the pulleys, the antenna cords should be moving through the pulleys and start raising the antenna.

When the pulleys are up in final position, cut the pulley cords just above ground height. Tie a loop and attach the loop to the base of the tree with a screw eye.

Pull the center antenna cord up to bring the antenna center into final position. Just above ground level, cut the cord and attach a weight. Temporarily secure this line to the tower to maintain the center positioning.

Pull the end cords to bring the antenna ends into final position. Just above ground level, cut the cords and attach the weights. The weights must be free to move, unrestricted, up to the pulleys.

Remove the device temporarily securing the center cord and weight. All three weights should now be just above ground level and free to move up as needed.

From time to time you may need to lower the antenna, so keep a length of cord to attach on the pulley lines for lowering. 

With this system, there is no extra cord laying on the ground to get caught in the lawn mower!

Enjoy your free-floating, suspended wire antenna without worry every time a storm blows!

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 2

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

October of last year I set out to make a MMDVM repeater with my Yaesu FT-7800 and FT-7900 transceivers. At the time, the setup was in simplex mode as I researched duplexers for the two frequency, one antenna system. And there the project sat in the shack just taking up space and collecting dust. With my invested time accumulating and the research folder growing thicker, I found several characteristics about my repeater build that I decided to change.

Enclosures and Heat

In the former computer case with all the components situated side by side, the homebrew repeater occupied a large footprint in the shack. Taking a second look at this, with the transceivers being the same size and short in height, stacking them greatly reduces the required footprint.

Since my components already have protective cases on them, placing everything into yet another case is unnecessary and only inhibits heat dissipation. In the stacked configuration with the receive radio on top, mounting them on a single Yaesu SMB-201 cooling fan will allow better open-air circulation as well as direct fan cooling to the bottom of the transmitting radio's heat sink.

Power

For now, I am keeping the repeater in the shack, so a second power supply is not needed. My Yaesu FP-1030A has more than enough capacity to run the repeater while also running my FT-991A, FTM-7250, and a few other accessories. If and when the time comes to move it out, I have a 23 amp power supply with an attached RIGrunner 4004U ready to go. This will not only power the two radios, but the RPi controller as well with it's two USB 5 volt ports. Handy dandy cotton candy!
Raspberry Pi Cooling

The Raspberry Pi 3B+ and ZUM Radio GPIO hat setup I originally made was satisfactory, but a passive cooling setup would be better. To fix this, I put the RPi in an aluminum heat sink case, added a programmable Argon One Artik fan hat on an extended GPIO, and placed the ZUM Radio board on top of that. I placed the Pi setup on it's side (GPIO edge down) to allow better natural airflow up the warm faces.

My three other Raspberry Pi 4B's require cooling so each have an Argon One fan, but in this 3B+ application it really isn't necessary, though it's a nice feature to have if things do get too warm. I programmed the fan to turn on at 42 degrees C at 10% speed. With this, the fan rarely activates, and then only briefly. The higher quality fan, reduced run time, and modified speed should greatly extend the life if this setup. After watching this setup for some time, I found the Pi temperature stays around 39 C with only passive cooling.

Here, the MMDVM repeater RPi is on the left of my shack's four-Pi setup. All computers are on a LAN switch to help reduce RF exposure in the shack.

Wiring Harness

One thing I don't like is having a harness that's too long or too short for whatever the project is, especially in the shack where extra wires can turn into interference-producing antennas. For this reason, I modified the harness and made two ends using two standard RJ45 jacks. The DIN cables were shortened to 16 inches and combined into a single RJ45. The repeater board connection was also joined to a single RJ45 jack. The two components now connect together with a standard computer network cable of whatever length is needed for the components' location. Perfect!

Antennas

The biggest change of plans may forgo the use of a duplexer and single antenna setup. Instead, I may go with a less expensive collinear setup using two Diamond X50 antennas mounted on separate tower standoff arms. I've been running a similar setup at 5 watts for a short time and found it works quite well. So far, I have one LMR400-fed antenna up and working on the tower arm.

Considering my location in a tall forested lakefront area widely known as a difficult corridor for RF, and having a tower only 55 feet tall, there is no point in spending a lot of money on any setup here. Besides, this is for experimentation and just having fun with RF. That's a big part of what this is all about, right?

Nextion Screen

Having all this figured out left me with a little unused creativity, so I redesigned my Nextion screen appearance and layout. Thanks to WA6HXG for the original Nextion 3.2 HMI file, I just moved a few things around, changed the fonts and background images, and called it a day. The colors in this photo are off, but you get the idea. Still on the to-do list are: (1) purchase and install the X50 antennas, and (2) receive frequency allocation from Wisconsin Association of Repeaters.

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