Workflow: Small Language Model for Amateur Radio Repeater Operations (Linux)

2. Regulatory and operational constraints (U.S. context)

Before integrating AI with RF, write down what the system is allowed to do. In the United States, Part 97 provides key constraints on transmissions, including prohibited transmissions and requirements for station identification.^{1, 2} The FCC also publishes operational guidance for amateur communications and operations.³

Design rules of thumb

• No “meaning-obscuring” encoding: Do not encrypt, scramble, or otherwise obscure the meaning of content carried over RF. Keep all transmitted content plainly intelligible to ordinary amateur operators.¹
• Station ID is non-negotiable: Ensure the transmitter identifies at the required cadence and circumstances. Treat ID as a core feature that the AI must never disable.²
• Human accountability remains: The SLM does not become a “control operator.” It produces recommendations and executes only those actions you explicitly permit via configuration and safeguards.
• Prefer “assistive” over “autonomous” RF: Restrict autonomous RF output to pre-approved, template-based content, reviewed by the licensee/trustee.

3. Reference architecture

The safest integration pattern is to run the repeater controller and the SLM as separate services connected by a narrow, policy-checked interface.

High-level block diagram (control plane vs RF plane)

RF Rx audio + COR/COS
        |
        v
[Repeater controller: AllStar/app_rpt or SvxLink]
        |                    \
        | audio tap (ALSA/UDP) \  control adapter (commands/events)
        v                       v
[STT service] ---> [Local log store / vector index] ---> [SLM service]
    |                         ^                             |
    |                         |                             |
    +---- alerts/metrics -----+------ policy guardrails ----+
                                  |
                                  v
                      [TX actions: allowlist only]
                      (play pre-approved audio / TTS)

Linux repeater controller options

You can run both stacks in parallel (e.g., SvxLink for local RF control and AllStar for linking) but you should only introduce that complexity if you already have strong operational reasons to do so.

4. Implementation workflow

This workflow assumes you already have a functioning repeater controller and RF chain. The SLM is added incrementally, starting with passive observation and moving toward bounded automation.

Phase 0 — Write requirements and “do not transmit” boundaries

1. Define your automation envelope: List which events may trigger automatic RF audio (e.g., ID, link status, site power state). Everything else is “recommend-only.”
2. Define your command allowlist: Enumerate permissible control actions (e.g., enable/disable a link, adjust courtesy tone profile, enable timeout timer). Assign each action to a concrete controller command (DTMF, CLI, or API call).
3. Decide on your retention policy: If you log audio/text, decide how long you keep it and who can access it. Document it for club governance and transparency.

Phase 1 — Provision and harden the Linux host

1. Choose a stable distro: Debian or Ubuntu LTS are typical for repeaters and local AI stacks.
2. Segment networks: Put controller management interfaces on an admin VLAN. If you use internet linking, keep that path separate from admin access.
3. Implement least privilege: Run each service (controller, STT, SLM, adapters) under a dedicated user, with systemd unit hardening (no new privileges, restricted filesystem access).
4. Establish observability: Journald + log rotation + simple metrics (CPU, disk, temperature). Ensure you can remote in out-of-band.

Phase 2 — Create an audio “tap” and event feed

Your SLM cannot reason about on-air activity unless you give it structured inputs. Start with (a) received audio and (b) explicit events (COR/COS changes, transmitter keyed, link state changes).

• Audio capture: Use ALSA devices or UDP audio streaming where supported. SvxLink explicitly supports audio devices specified as alsa:…, oss:…, or udp:… in configuration.⁹
• Segmentation: Use COR/COS (or squelch logic) to bound “utterances” and avoid transcribing dead air.
• Event normalization: Represent events as JSON lines (local file or message bus) so downstream services can subscribe without coupling.

Phase 3 — Add offline speech-to-text (STT)

STT provides the most value early because it is passive and supports logging, summaries, and searchable incident timelines.

Phase 4 — Stand up the SLM runtime

For small, on-prem models, prefer runtimes designed for local inference and quantized weights.

• llama.cpp: A C/C++ inference engine designed to run LLMs efficiently on a wide range of hardware with minimal setup.¹⁰
• Ollama: A local model runner with a straightforward workflow and API for integrating models into services on Linux.¹¹

Phase 5 — Add policy guardrails and “tool calling”

The SLM should not directly execute shell commands, key transmitters, or change configurations. Instead, implement a narrow adapter that exposes a small set of tools that the SLM can request, and enforce a strict allowlist.

1. Create a command schema: Define commands like link.connect(node), link.disconnect(node), status.read(), announce.play(template_id).
2. Enforce allowlists and rate limits: Reject any tool invocation not explicitly allowed. Apply “cooldowns” to prevent repeated actions.
3. Require confirmation for sensitive actions: For actions that could affect access (e.g., disabling links, changing timers), require human approval (web UI button, SMS, or SSH confirmation).
4. Log every tool invocation: Store “who/what/when/why” for later review.

Phase 6 — Add bounded transmit capability (optional)

If you choose to transmit AI-generated audio, do so conservatively. The simplest, safest path is template selection (pre-recorded voice files) instead of unconstrained generation.

• Tier 1 (recommended): Pre-recorded WAV prompts (human voice) selected by the SLM.
• Tier 2: Offline TTS with a fixed voice and fixed phrase templates, such as Piper (noting project lineage/migration).¹⁴
• Tier 3 (not recommended): Fully generative free-form speech over RF.

Regardless of tier, ensure station identification timing remains correct and cannot be suppressed by the AI.²

Phase 7 — Integrate with your controller stack

Use controller-native mechanisms first; do not “hack around” them. Examples include:

• AllStarLink: Leverage standard command conventions and DTMF-based control models as your interface contract.⁸
• SvxLink: Use module configuration and supported audio device interfaces (ALSA/UDP) to inject or route audio appropriately.^{5, 9}

Phase 8 — Operationalize: testing, monitoring, and maintenance

1. Offline test harness: Feed recorded audio into the STT pipeline; verify transcripts and SLM actions without keying the transmitter.
2. Chaos tests: Simulate network loss, high CPU load, full disk, and stuck audio device; verify the repeater controller remains stable.
3. Watchdogs: Use systemd watchdogs and health endpoints for each service.
4. Update cadence: Patch OS and dependencies; pin model versions and store hashes so you know exactly what changed between revisions.

5. Rack-mount hardware guidance

For repeaters, “suitable” hardware is defined less by peak performance and more by reliability, manageability, and environmental tolerance. Your design should assume unattended operation, power cycling, and intermittent network reachability.

Compute sizing (practical guidance)

• Baseline controller only: 2–4 modern CPU cores, 4–8 GB RAM, SSD storage.
• Controller + offline STT: 4–8 cores, 16 GB RAM, NVMe preferred.
• Controller + STT + SLM: 8+ cores, 32 GB RAM (especially if hosting multiple quantized models and an index), NVMe, strong cooling.

Rack patterns (with concrete examples)

Non-negotiable hardware features for repeater sites

• Remote management: IPMI/iKVM or vendor out-of-band management (especially if the site is hard to reach).
• Storage resilience: Mirror SSD/NVMe if feasible; at minimum, keep a known-good image for fast restore.
• Power conditioning: UPS sized for graceful shutdown and short outages; surge protection; consider DC-native power if the site is DC-backed.
• Thermal margin: Assume dust, filters, and seasonal temperature variation; avoid designs that run near thermal limits.
• Audio I/O stability: Prefer known-stable USB audio interfaces; consider redundancy (spare interface in the kit) due to field failure rates.

RF/EMI and site engineering considerations

• Physical separation: Keep the compute chassis, switching supplies, and Ethernet switching as far from receiver front-ends, preamps, and cavities as practical.
• Cable hygiene: Use shielded audio cabling where appropriate, avoid ground loops, and apply ferrites on USB/audio/Ethernet leads if you observe conducted RF issues.
• Bonding and grounding: Bond racks, chassis, and surge protectors to the site grounding system. Treat the server as a noise source until proven otherwise.
• Fans and airflow direction: Prefer front-to-back airflow consistency across the rack to avoid hot spots. Avoid consumer gear that exhausts sideways into adjacent RF equipment.

Rack layout checklist

• Top-down layout: RF cavities/filters and receivers away from switching supplies; compute and network lower in the rack when possible.
• Serviceability: Label all audio, PTT/COR, and network connections; keep a printed “as-built” diagram inside the rack door.
• Spare strategy: Stock a spare SSD/NVMe with a tested image, plus a spare USB audio interface, to reduce mean time to restore.
• Time source: Ensure stable timekeeping (NTP where available; local RTC otherwise) so logs and incident timelines remain reliable.

6. Suggested service decomposition

Keep each component small and observable. A simple split that scales from “passive logging” to “bounded automation” looks like this:

Packet / messaging add-ons (optional)

If your site includes APRS or packet workflows, Dire Wolf is a common Linux packet modem/TNC component that can be integrated into the same observability and event pipeline.¹⁵