Resurrecting a Forgotten HSR-USB as an AllStar Node

🔊 Listen to this Read Time: 8 minute(s)

That forgotten HSR-USB board in the back of the drawer had no documentation and I had no memory of what frequency it was programmed on. My first exploratory attempt was to drive it from Windows using Ampersand-Win and I got surprisingly far before hitting a wall. The real breakthrough came from flipping the USB-C cable over to access the SA818 and interrogating the chip directly from PowerShell. Once I knew the frequency and CTCSS tones, a spare Pi Zero 2W running ASL3 took it the rest of the way. Node 578498 is now live on the AllStarLink network — rescued from the drawer and back in service.

There it was, lurking in the back of the drawer — a small acrylic-covered board with HSR engraved on the cover, a stubby antenna, and a single USB-C port. I had no memory of what frequency it was programmed on, no documentation, and no clear recollection of why I’d shelved it in the first place.

I was about to find out.

---

What Is This Thing?

The HSR-USB is a product of HotSpotRadios.com, a small operation that makes AllStarLink node hardware. The USB variant — the one I had — is a self-contained UHF radio interface built around two chips: a NiceRF SA818S embedded radio module and a CMedia CM119B USB audio IC. No Raspberry Pi inside. No microSD card. Just a board, a radio module, an antenna connector, and one USB-C port for audio/power and programming.

The case was made by C4Labs. The HSR board carries the part number MCO/MCE-2023-HSRUSB-V1.2U. After applying power, my HSR-USB was sitting inert, blue power LED on, green ACT LED glowing steadily — alive, but uncommunicative.

My first instinct: can I drive this thing from Windows using Ampersand-Win?

---

The Windows Detour

Ampersand-Win (by Bruce MacKinnon KC1FSZ) is a Windows-native AllStarLink node application — no Linux, no Asterisk, just an exe and a browser-based configuration UI. I’ve been trying various implementations of Ampersand-ASL and noted it supports CM-type USB radio interfaces. The HSR-USB has a CM119B. Seemed like a reasonable match.

I plugged the HSR into my Surface Laptop 7 via USB-C. Windows chimed. Device Manager showed USB Audio Device under Sound, video and game controllers. Encouraging. I set it as the Windows default audio device for both input and output, then launched Ampersand-Win with Setup Mode set to C-Media CM1xx URI/UCI, Carrier From: USB, PTT To: USB.

The Ampersand console started cleanly. Node 578498 came up on my custom IAX port 4564. The config JSON confirmed it had picked up my settings. Progress.

Except the Audio Device dropdown in the Ampersand UI was empty and greyed out. The mixer dropdowns — also greyed out. And the SA818 Settings section, which looked promising with fields for Command Port, frequency, and tones — also greyed out.

Ampersand-Win’s SHARI mode exists for exactly this kind of hardware combination, but the UI wasn’t wiring it together. The Command Port dropdown stayed disabled regardless of what I tried. Ampersand-Win is experimental software, still evolving, and this particular hardware combination — a bare HSR-USB board without a host Pi — appears to be outside what it currently supports in a fully functional way.

So this was a dead end on Windows. Time to dig deeper.

---

Finding the Frequency

Before abandoning the Windows approach entirely, I wanted to answer the question that started all of this: what frequencies does this thing use?

Flipping the USB-C cable over, I noticed the other side was labeled PROGRAM. You use the same cable for programming and for operating, turning it over to gain access to the SA818’s serial programming interface, exposed via a CH340 USB-to-serial chip. I flipped the cable, plugged it into the Surface, and watched Device Manager.

USB-SERIAL CH340 (COM7) appeared under Ports (COM & LPT).

Now to talk to it. The obvious first attempt — Windows’ mode command — returned “Device COM7 is not currently available.” Frustrating, but not fatal. The .NET SerialPort class is more direct:

powershell

[System.IO.Ports.SerialPort]::getportnames()

COM7 appeared in the list. The port existed. Windows just didn’t want to configure it through mode. I opened it directly:

powershell

$port = New-Object System.IO.Ports.SerialPort "COM7",9600,([System.IO.Ports.Parity]::None),8,([System.IO.Ports.StopBits]::One)
$port.Open()
$port.WriteLine("AT+DMOREADGROUP")
Start-Sleep -Seconds 2
$port.ReadExisting()
$port.Close()

The SA818 responded: +DMOERROR

Not ideal, but significant — the chip was alive and answering. The error meant the command format was wrong, not that comms had failed. The SA818 AT+DMOREADGROUP command requires a group number parameter. Correcting the syntax:

powershell

$port = New-Object System.IO.Ports.SerialPort "COM7",9600,([System.IO.Ports.Parity]::None),8,([System.IO.Ports.StopBits]::One)
$port.Open()
$port.Write("AT+DMOREADGROUP=0`r`n")
Start-Sleep -Seconds 2
$port.ReadExisting()
$port.Close()

This time:

+DMOREADGROUP:1,439.0000,439.0000,0001,4,0001

There it was. Decoded:

Field	Value	Meaning
Bandwidth	1	25 kHz (wide)
TX Frequency	439.0000	439.000 MHz
RX Frequency	439.0000	439.000 MHz (simplex)
TX CTCSS	0001	67.0 Hz
Squelch	4	Level 4
RX CTCSS	0001	67.0 Hz

Mystery solved. The HSR was programmed for 439.000 MHz simplex with 67.0 Hz CTCSS on both transmit and receive. I programmed my TIDRADIO H3 Plus to match using the ODMaster app over Bluetooth — which is its own kind of remarkable compared to how we used to program radios — and confirmed the HSR was receiving: I could see the LED light up red when I hit the PTT button.

Now I knew what I had. Time to make it actually useful.

---

The Right Platform: Pi Zero 2W and ASL3

The HSR-USB was designed to be driven by a Linux host. A Raspberry Pi Zero 2W is the natural companion — small, inexpensive, and explicitly supported by AllStarLink 3. I had a spare Pi Zero 2W in the same parts drawer, so I installed the ASL3 Appliance package with Raspberry Pi Imager.

I booted the Pi, got it on my network, and SSH’d in. Then:

sudo asl-menu

Here’s where ASL3 impressed me. The configuration menu includes a Device Configurations section with a dedicated entry: *HotSpotRadio* HSR-USB. No manual configuration. No hunting through documentation. The template knows what the board is and sets up the correct duplex, URI settings, and SA818 interface automatically.

I selected it, worked through the node number and credentials for node 578498, and rebooted with the HSR plugged into the Pi’s USB-C port via an adapter.

Guess what? It worked on the first try.

---

Tuning the Audio

“Worked” is a relative term. The node was up, the ACT LED was blinking green, and my H3 Plus could key into it — but the audio needed attention.

A few adjustments in /etc/asterisk/simpleusb.conf:

Transmit level — I adjusted txmixaset and txmixbset from the default 500 up to 650. The ASL parrot on node 2002 confirmed the level was good.

CTCSS squelch — without this, the node opens on any carrier, including noise. Adding rxctcssfreq=67.0 to the [578498] stanza in simpleusb.conf tells ASL3 to only pass audio when the 67.0 Hz tone is present. This cleaned up the noise floor considerably.

After changes, reload without a full restart:

sudo asterisk -rx "module reload app_rpt.so"

Let me be clear: the SA818 is not a high-fidelity audio device — it’s a budget embedded radio module and sounds like one. Audio from it is readable, making this a functional node, but don’t expect it to sound like a URI board. That’s my honest assessment.

---

Adding AllScan

With the node working, I wanted a proper web interface for connecting and disconnecting nodes — something better than memorizing DTMF codes or navigating Allmon3. AllScan, by David (NR9V), is the answer.

One important note for anyone who’s installed AllScan before: it no longer depends on Allmon3. The two are now independent. You can install AllScan fresh on a new ASL3 node without touching Allmon3 first. This was a long-standing friction point and it’s resolved.

Follow David’s current installation instructions at github.com/davidgsd/AllScan — the README is authoritative and kept current. Dependencies matter and they evolve, so don’t rely on cached memory of a previous install.

After installation, AllScan is available at http://[your-node-ip]/allscan/.

Node 578498 came up immediately. I imported my favorites.ini file (I keep a copy on my laptop) and was ready to connect.

---

What You Need

If you have an HSR-USB in a drawer and want to do this yourself:

• HSR-USB board with antenna
• Raspberry Pi Zero 2W with ASL3 Appliance image
• USB-C to USB-C cable (or USB-C with OTG adapter for the Pi’s micro-USB port)
• ASL3 node number and credentials from allstarlink.org
• A radio programmed to 439.000 MHz simplex, 67.0 Hz CTCSS (or whatever your HSR is programmed to — use the PowerShell method above to find out)

---

The Takeaway

The PowerShell SA818 interrogation sequence is the part of this project I hadn’t seen documented anywhere else. If you have any SA818-based device — HSR-USB, SHARI, or anything else using that module — and you’ve lost track of its programming, this works:

powershell

$port = New-Object System.IO.Ports.SerialPort "COM7",9600,([System.IO.Ports.Parity]::None),8,([System.IO.Ports.StopBits]::One)
$port.Open()
$port.Write("AT+DMOREADGROUP=0`r`n")
Start-Sleep -Seconds 2
$port.ReadExisting()
$port.Close()

Substitute your actual COM port number. The response tells you everything: frequency, CTCSS tones, bandwidth, squelch level.

The rest of this project — the ASL3 setup, AllScan install, audio tuning — is well-trodden ground. But that one PowerShell block is the key that unlocked a device I’d written off as unrecoverable.

It’s now node 578498 on the AllStarLink network.