FRom the Flightaware Console you can see the planes . However I also run Virtual Radar with is much better software. This is windows software that can connect to your pi however I installed using mondo on the PI itsself. This is somewhat harder to do bit works great because it connects to a database and logs everything. The plans will get looged the number of times seen and you can make notes look up the owners and correct the ones marked private.

You can also receive and track military aircraft including the ones that dont transmit GPS signals. If you use flightaware 1090 your signal will triangulate with other users and triangulate the aircraft. called MLAT

Feeder Type: PiAware (Debian Package Add-on) 10.0.1
Feeder Mode: Mode-S (1090 MHz)
Multilateration (MLAT): Supported / Enabled (synchronized with 37 nearby receivers)

You can either download a pi image or build your own. I preferer to build my on system because it runs more than absd it also tells the time and temp through a pa system.

If you have a debin installed on a pi you just install dump1090 here https://github.com/flightaware/dump1090 Remember there is a older version online you want this new version with MLAT.


complete instructions on using a prebuilt image are here.
https://www.flightaware.com/adsb/piaware/build

Virtual radar is located here
https://www.virtualradarserver.co.uk/
You might want to install the windows version first to Understand how it works Then install the mondo version. One of the reasons i use my own system and not the image is because i install the desktop and webmin for remote operation and i use teh remote desktop to fix any problems with virtual radar by opening it in the console there is a small bug that will corrupt the database on load you will get a option to repair. But the command line that boots up has no console and doesnt offer the repair option and just refuses to work. SO once every 6 months or so if it stops working i have to load it from the desktop and see if it says repair database. The databases it uses contain all the flight logos and aircraft your going to have to download these.

These files come from the old base station program http://woodair.net/SBS/Utilities/Kinetic_Utilities4_Bitmaps.htm

The post SDR for ADS-B aircraft decoding. first appeared on Louisiana GMRS/HAM news.

EchoLink is now LIVE on the Main Hub!

You can now join the system from anywhere using EchoLink. Just connect to:

KJ5MZL‑L

This links you straight into the Main AllStar Hub, the DVSwitch server, and TGIF DMR Talkgroup 28100 — all fully bridged together.

Perfect for mobile, HT, travel, or quick check‑ins. Jump in and say hello.

The post Echolink server is now online for Louisiana Nationwide first appeared on Louisiana GMRS/HAM news.

Take apart the radio. Remove the knobs remove the screws on the back.
Under the battery is a connector is a connector we will remove later. This will allow wires to enter the radio without removing the LED as you see in the old mod.

Remove the 2 belt clip screws and the plastic under them you will use these 2 screw holes to mount the radio to your case so it stays upright and stable.

We will not use the battery you cant use the charger and battery so what we do is use a regulator set for 3.7 volts this runs the radio just fine. Remember these batteries could explode if overcharged so don’t use it.

Once taken apart you can un sorder the speaker so you can remove the front.

Unsorder the connector for the battery so we can run in power round and cos. You may wish to use shielded wire for cos connection as noise may be on the wire.

There are several different versions of the BF888 so the COS point can be in several different locations. But its on pin 1 of the chip on the back side of the board. Take care in running the wire from behind around to the top because we want to reinstall the back which is the sheild and we don’t this wire to get pinched.

All audio in and out and PTT is handled by the mic cable so nothing else to modify. Get a mic cable off amazon i have been looking for uncoiled but cant find that the coined one will need some space to fold it around.

More photos later check back..

You need a voltage regulator likely a LM2596 However some packages may create noise. So you might try more than one version one of my LM2596 caused a buzz when I shared power with the pi. Position is very important place the pi a foot away from the radio in like a amno box. Some people lower the power in the radio but if thats what your gona do then just use a usb radio and dont use the bf888. we need max power in our moble so we can go inside wallmart and still get a signal.

Orginaly i built these with 5v in. But some cars will have low voltage so im now using 12v in and a 12v to 5vusb regulator this allows a 12v fan as on this old one it has a 5v pi fan. Fans are needed in cars it gets very hot when you not in the car. And i suggest the script to report hi temp back to you on the link..

The high temp alarm is built into my node manage but im going to release it as a stand alone script in a few weeks.

There is a new cable that works on VOX and has a built in sound card for those that dont want to modify at all.

https://www.amazon.com/dp/B0DF8GSB4C?th=1

The post Modifying Bf888 for Allstar better mods first appeared on Louisiana GMRS/HAM news.

Here’s what’s actually happening, why it’s happening, and what it means for your nodes, hotspots, and packet setups.

What Linux Is Really Removing

The Linux kernel team is removing a handful of very old, unmaintained drivers that haven’t been updated in 10–20 years. These include:

• Obsolete AX.25 kernel drivers
• Old Baycom‑style serial modem drivers
• Legacy packet radio TNC interfaces
• Experimental soundmodem drivers nobody maintains

These drivers were written for hardware from the 1980s and 1990s — ISA cards, parallel‑port TNCs, and early packet radio devices that almost no one uses today.

They were removed because:

• They no longer compile cleanly
• They have no active maintainer
• They contain outdated or insecure code
• They clutter the kernel with dead modules

This is normal housekeeping, not an attack on amateur radio.

What Linux Is Not Removing

This is the part that gets lost in the panic.

Linux is not removing:

• AX.25 networking support
• KISS TNC support
• Direwolf compatibility
• USB sound cards
• USB serial CAT control
• Hamlib
• AllStar / Asterisk
• Pi‑Star hotspot support
• DMR / D‑Star / YSF digital modes
• APRS tools
• Winlink tools
• Anything used by modern ham radio systems

If your setup is newer than 2005, you are completely unaffected.

Will My Nodes Still Work?

Yes — 100% yes.

Your:

• AllStar node
• Pi‑Star hotspot
• Direwolf packet node
• APRS iGate
• Winlink RMS
• M17 reflector
• JS8Call / FT8 / WSJT‑X station

…all rely on user‑space software, standard USB/serial drivers, and ALSA sound.
None of that is being removed.

The removed drivers were for hardware that predates the Raspberry Pi by two decades.

Why People Think “Ham Radio Is Being Erased”

A few posts online took a kernel patch note like:

“Remove unmaintained AX.25 legacy drivers.”

…and turned it into:

“Linux is removing ham radio support!”

That’s not what’s happening.

The kernel team is removing dead code, not removing amateur radio from Linux.

Modern Ham Radio on Linux Is Alive and Well

In fact, Linux is still the strongest platform for:

• Digital modes
• Packet radio
• Hotspots
• SDR
• Remote rig control
• APRS
• Winlink
• AllStar
• M17

And the most important ham radio tools — Direwolf, WSJT‑X, fldigi, Hamlib, and Asterisk — are actively maintained and widely used.

Linux remains the backbone of ham radio infrastructure.

Bottom Line

Linux is not dropping ham radio support.
Linux is not erasing amateur radio.
Linux is not breaking your nodes.

What’s being removed are ancient, unmaintained drivers for hardware that almost no one uses anymore.

Your modern ham radio software and hardware will continue to work exactly as they always have.

The post Is Linux Really “Removing Ham Radio Support”? Here’s What’s Actually Going On first appeared on Louisiana GMRS/HAM news.

Join operators from across the region for a relaxed, friendly weekly net on BM TG 31225. Whether you’re local to Louisiana or checking in from across the country, everyone is invited to participate.

Bring your questions, your updates, or just stop by to say hello. We look forward to hearing you on the air!

The post Southeast Louisiana Net Thursdays – 8:00 PM CST BrandMeister DMR Talkgroup 31225 Open to Everyone – All Check‑Ins Welcome first appeared on Louisiana GMRS/HAM news.

If you’ve ever installed AllStarLink 3.x on a Raspberry Pi or x86 system and noticed your node randomly dropping off Wi‑Fi, switching between access points, or getting stuck in a strange “dormant” state, you’re not alone. I recently ran into this exact issue on two different nodes, and the root cause turned out to be something most users never think to check.

The good news: the fix is simple once you know what’s going on.

This post walks through the symptoms, the diagnosis, and the exact steps to fix the problem permanently.

The Symptoms

On both of my ASL3 nodes, I was seeing:

• Random Wi‑Fi disconnects
• The Pi jumping between 2.4 GHz and 5 GHz access points
• “DORMANT” mode showing up in iw dev
• Slow or failed reconnects
• Occasional audio dropouts on the AllStar node
• Unstable links even with strong signal

At first, I assumed it was a weak signal or interference. I even disabled the 2.4 GHz SSID on a nearby access point to force the Pi onto 5 GHz. That helped a little, but the dropouts continued.

Something deeper was going on.

The Real Cause: Two Wi‑Fi Managers Fighting Each Other

ASL3 is based on Debian 12, and depending on how the image was built, it may include:

• NetworkManager
• wpa_supplicant

Both of these services can manage Wi‑Fi connections. And on my nodes, both were active at the same time.

You can check this with:

Code

systemctl is-active NetworkManager
systemctl is-active wpa_supplicant

If both return active, you’ve found the culprit.

When two Wi‑Fi managers try to control the same interface, you get:

• roaming between APs
• DHCP conflicts
• interface resets
• “dormant” mode
• dropped packets
• unstable 5 GHz connections

This is exactly what I was seeing.

The Fix: Disable wpa_supplicant and Let NetworkManager Handle Wi‑Fi

NetworkManager is the more modern and stable option on ASL3, especially since it supports the nmtui Wi‑Fi setup menu.

Here’s the fix:

1. Disable wpa_supplicant

Code

sudo systemctl stop wpa_supplicant
sudo systemctl disable wpa_supplicant

2. Restart NetworkManager

Code

sudo systemctl restart NetworkManager

3. Verify Wi‑Fi is still connected

Code

iw wlan0 link

You should see your SSID and channel listed normally.

Once I did this on both nodes, the random dropouts stopped immediately.

Bonus Fix: Disable Wi‑Fi Power Saving

Raspberry Pi Wi‑Fi defaults to power‑saving mode, which is great for laptops but terrible for AllStar nodes. It causes latency spikes, missed packets, and sometimes disconnects.

Turn it off:

Code

sudo iw dev wlan0 set power_save off

Make it permanent:

Code

sudo mkdir -p /etc/NetworkManager/conf.d
sudo nano /etc/NetworkManager/conf.d/wifi-powersave.conf

Add:

Code

[connection]
wifi.powersave = 2

Restart:

Code

sudo systemctl restart NetworkManager

This alone can dramatically improve stability.

Automating the Fix for Future Installs

To make life easier, I created a script that:

• disables wpa_supplicant
• enables NetworkManager
• disables Wi‑Fi power saving
• launches the Wi‑Fi setup menu

Here’s the script:

#!/bin/bash

echo "=== ASL3 Wi-Fi Fix Script ==="

# 1. Stop and disable wpa_supplicant
echo "[1/4] Disabling wpa_supplicant..."
sudo systemctl stop wpa_supplicant 2>/dev/null
sudo systemctl disable wpa_supplicant 2>/dev/null

# 2. Ensure NetworkManager is enabled and running
echo "[2/4] Enabling NetworkManager..."
sudo systemctl enable NetworkManager
sudo systemctl restart NetworkManager

# 3. Disable Wi-Fi power saving (runtime)
echo "[3/4] Disabling Wi-Fi power saving..."
sudo iw dev wlan0 set power_save off 2>/dev/null

# 4. Make power saving OFF permanent
echo "[4/4] Making power saving permanently disabled..."
sudo mkdir -p /etc/NetworkManager/conf.d
sudo bash -c 'cat > /etc/NetworkManager/conf.d/wifi-powersave.conf <<EOF
[connection]
wifi.powersave = 2
EOF'

sudo systemctl restart NetworkManager

echo ""
echo "=== Wi-Fi services configured ==="
echo "Launching Wi-Fi setup menu (nmtui)..."
echo ""

sleep 1
sudo nmtui

Run it once after installing ASL3, and your Wi‑Fi will be rock‑solid.

Conclusion

If your ASL3 node is experiencing Wi‑Fi instability, the problem may not be your access point, your signal strength, or even your hardware. In many cases, the real issue is that NetworkManager and wpa_supplicant are both trying to manage Wi‑Fi at the same time.

Disabling wpa_supplicant and letting NetworkManager take over — combined with turning off Wi‑Fi power saving — results in a dramatically more stable connection.

After applying this fix, both of my nodes have been running flawlessly on 5 GHz with zero dropouts.

If you’re building or maintaining AllStar nodes, this is a must‑do step.

The post Wifi setup on ASL3 allstar wifi problems first appeared on Louisiana GMRS/HAM news.

Many HAMS & GMRS users believe they need to buy a static IP address from their ISP to run a home node, hotspot, or DVSwitch server. Good news: you don’t. In almost every case, a simple and free tool called Dynamic DNS (DDNS) solves the problem completely.

Below is a clear explanation you can share with anyone setting up a home node, AllStar, DVSwitch, or any remote‑access ham radio system.

So someone told you you had to have a static IP to use DVSWITCH or remote connect to your node.
This is incorrect. This problem was solved way back in the 90s. Everyone should know this.

Why People Think They Need a Static IP

Most home internet connections use a dynamic IP address. This means:

• Your IP stays the same for long periods
• It can change after a modem reboot or power outage
• It is not guaranteed to stay the same forever

If you try to connect to your home node using the raw IP address, and it changes, your connection breaks. This leads people to think they need a static IP.

But they don’t.

Dynamic DNS (DDNS) Fixes the Problem

Dynamic DNS gives your home network a permanent hostname, such as:

myshack.ddns.net mycallsign.duckdns.org mynode.no-ip.org

This hostname never changes, even if your home IP does.

Your router or Raspberry Pi automatically updates the DDNS service whenever your IP changes. So instead of connecting to: 11.11.11.18
You connect to: myshack.ddns.net
And it always points to the correct IP.

DDNS Works Perfectly With DVSwitch and Home Nodes

DVSwitch, Analog_Bridge, AllStar, Pi‑Star, and other ham radio tools don’t care whether you use:

• A static IP
• A dynamic IP
• A DDNS hostname

They only care that the hostname resolves.

Port Forwarding Still Works the Same

DDNS does not replace port forwarding — it only replaces the IP address you connect to.

If your node needs ports like:

• 30001 UDP
• 30002 UDP
• 4569 UDP (AllStar)
• 62030 TCP

…you still forward those ports in your router.

But instead of connecting to your changing IP, you connect to your DDNS hostname.

DDNS Is Free, Fast, and Reliable

Popular free DDNS providers include:

• DuckDNS.org (simple, free forever)
• No-IP Free (works well, requires periodic confirmation)
• Dynu (free tier available)

Most routers support DDNS natively. If not, a Raspberry Pi can update it automatically.

When Do You Actually Need a Static IP?

Only in rare cases:

• You’re hosting a large public reflector
• You need reverse DNS (PTR records)
• Your ISP blocks DDNS updates
• You’re running a commercial service

For 99% of ham radio home setups, DDNS is the correct solution.

Summary

• You do not need a static IP
• DDNS gives you a permanent hostname
• DVSwitch and home nodes work perfectly with DDNS
• Port forwarding still works normally
• DDNS is free and takes only a few minutes to set up

Static IPs are expensive and unnecessary for almost every ham radio use case. DDNS is the modern, simple, and reliable solution.

Absolutely — here’s a clear, practical explanation you can drop straight into your WordPress article. It explains how a DDNS client works, why it solves the “I need a static IP” myth, and exactly how to use DuckDNS on a Raspberry Pi to keep a home node or DVSwitch server reachable.

I’ll keep it clean, readable, and formatted for WordPress.

How a DDNS Client Works (and Why You Don’t Need a Static IP)

Dynamic DNS (DDNS) is the secret weapon that makes home nodes, DVSwitch servers, and remote‑access systems work without needing a static IP address. The idea is simple: instead of connecting to your home’s changing IP address, you connect to a permanent hostname that always points to your current IP.

A DDNS client is the small program that keeps that hostname updated.

What the DDNS Client Actually Does

A DDNS client (like the one from DuckDNS) runs on your Raspberry Pi or router and performs three simple jobs:

1. Detect your current public IP

Your Pi asks an external service:

• “What is my public IP right now?”

This is usually done by checking:

https://api.ipify.org

or DuckDNS’s own IP check.

2. Compare it to the last known IP

If the IP hasn’t changed, nothing happens.

If it has changed (after a reboot, power outage, ISP refresh, etc.), then:

3. Update your DDNS hostname

The client sends a secure update request to DuckDNS:

https://www.duckdns.org/update?domains=YOURDOMAIN&token=YOURTOKEN&ip=YOURIP

DuckDNS instantly updates your hostname, so:

myshack.duckdns.org

always points to your current home IP — even if it changes.

This is why you don’t need a static IP.
Your hostname stays the same, and the DDNS client keeps it pointed at the right place.

Using DuckDNS on a Raspberry Pi (Simple Setup)

DuckDNS is one of the easiest DDNS services to use, and it’s completely free.
Here’s how to set it up on your Pi.

1. Create your DuckDNS domain

Go to:

Sign in with:

• Google
• GitHub
• Twitter
• Reddit

Choose a domain name, for example:

myshack

Your hostname becomes:

myshack.duckdns.org

Copy your token — you’ll need it.

2. Create the DuckDNS update script on your Pi

On your Pi:

mkdir -p ~/duckdns
cd ~/duckdns
nano duck.sh

Paste this inside:

echo url="https://www.duckdns.org/update?domains=YOURDOMAIN&token=YOURTOKEN&ip=" | curl -k -o ~/duckdns/duck.log -K -

Replace:

• YOURDOMAIN with your DuckDNS name
• YOURTOKEN with your DuckDNS token

Save and exit.

3. Make the script executable

chmod 700 duck.sh

4. Add a cron job to update every 5 minutes

crontab -e

Add this line:

*/5 * * * * ~/duckdns/duck.sh >/dev/null 2>&1

This keeps your hostname updated automatically.

How This Helps DVSwitch, AllStar, and Home Nodes

Once DuckDNS is running, you no longer connect to your home IP.
You connect to your hostname:

myshack.duckdns.org

This works for:

• DVSwitch Mobile
• Analog_Bridge
• AllStarLink
• Pi‑Star
• Private dashboards
• Remote control apps
• Custom reflectors

Your Pi stays reachable even if your ISP changes your IP.

Why This Eliminates the Need for a Static IP

A static IP is only needed if:

• You’re hosting a large public reflector
• You need reverse DNS
• You’re running a commercial service

For home ham radio use:

• DDNS is free
• DDNS is automatic
• DDNS works with every node and hotspot
• DDNS solves the “changing IP” problem completely

This is why you do NOT need a static IP to run DVSwitch or a home node.

The post How to use dvswitch without a static IP address first appeared on Louisiana GMRS/HAM news.

The post APRS on DMR first appeared on Louisiana GMRS/HAM news.

The post Online ham test first appeared on Louisiana GMRS/HAM news.

Published: November 16, 2025

If you’ve upgraded to ASL3 (AllStarLink on Asterisk 20+), you may have run into this frustrating issue:

“User talks too long → timeout → transmission drops → node won’t come back, even when they unkey. I have to key up locally to reset it!”

Good news: This isn’t a bug — it’s a safety feature in ASL3 to prevent stuck carriers from RF loops or bad USB devices. But for hub operators, it feels like a step backward from ASL2’s smooth recovery.

The Problem (Default ASL3 Behavior)

totime = 180000        ; 3 minutes

• User talks > 3 min → timeout
• TX drops → PTT locks
• Remote unkeys → node stays silent
• Only local key-up resets the channel

The Fix: Just 3 Lines in rpt.conf

totime = 360000        ; 6 minutes (adjust as needed)
timeoutmacro = *1      ; Auto-reset on timeout
lnkactenable = 0       ; Disable link activity timer

And add this macro at the top of your rpt.conf:

[macros]
*1 = cmd,/usr/bin/rpt reset

Why This Works

Apply Without Restart

sudo asterisk -rx "module reload app_rpt.so"

No downtime. No reboot.

Result

Exactly like ASL2 — but with ASL3’s stability.

Pro Tip: Add a 30-Second Warning Beep

Want users to know timeout is coming?

timeoutmacro = *81 30

[macros]
*81 = p,/var/lib/asterisk/sounds/rpt/timeout-warning

Bottom Line

ASL3 isn’t broken — it’s just more cautious. With one macro and two settings, you get:

• Rock-solid timeouts
• Smooth, automatic recovery
• Happy users

Your hub stays live. Your net stays smooth.

Tested on ASL3 v3.0.0, Debian 12, DVSwitch hubs. Always test during a quiet net first.

Got a stuck node? Drop these lines in rpt.conf and reload. Problem solved.

Dows this fix it let me know. If you find a better option please comment.

KJ5MZL/WRXB288

The post AllStarLink ASL3 Timeout Fix first appeared on Louisiana GMRS/HAM news.