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!

DMR Round 2

 I listened all day to TAC310 and all I heard were mic clicks and almost no talking. Two new-to-DMR hams started talking, but their radios were so over-driven and had so much packet loss, they were hardly intelligible. Lower the mic gain, fellas. The couple of others I heard were "Testing 1, 2, 3...". I really am trying to give DMR a fair shake, but I need some air-time experience before I can develop any sort of opinion about the mode itself, not just the programming. That's just not happening. 

"Stop listening and start talking!", you say? Yeah, no DMR repeaters near here, so it's all by hotspot. I tried talking the other day, but HughesNet satellite internet has so much latency (seconds, not milliseconds) and speed fluctuation (from 3Mb/s to 4,000 bits/s - really, no joke), that I can't do anything requiring a live, continuous connection, like a VPN or, say... radio transmissions on WIRES-X or hotspots. I'm serious! The other day it took 55 minutes to download a 73 MB file, and that's not uncommon! What's up with that? Sure makes me very thankful for real RF! Star Link! Where are you?!

Round 2.5: This evening, Lon and Tom, both 2-land stations, were on TAC310 just t-t-t-t-t-t-talking away! Boy, it was g-g-g-grea-t-t-t-t-t-t-t to hear hams on DMR like I hear on America-a-a-aLink. Finally, there is hope. Maybe I can see some li-i-i-i-i-i-i-ght in this dark tunnel...   ...rescued me from the thought of b-b-b-b-b-b-eing single-mode'd-d-d-d-d-d-d. Diversity, I say. Div-v-v-v-v-versity of digital modes l-l-l-l-l-leads to new front-t-t-t-tiers in the world of amateur radio. And that, m-m-m-m-m-my friends is....

...just havin' fun!

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