DEL CITY RADIO CLUB – W5DEL

W5DEL Linking System: Technical Overview

The Del City Radio Club (W5DEL) uses a central Linux communications server to connect local RF repeaters, VoIP services, digital radio networks, and public audio streams in one integrated linking system.

Scope and Technical Basis

This overview describes the W5DEL topology recorded in this document and explains how its RF, AllStarLink, telephony, DMR, and streaming paths fit together. Node assignments, frequencies, hardware names, extension numbers, and feed identifiers are retained from the existing overview. General protocol explanations are supported by the technical references at the end.

The installed software versions, configuration files, radio wiring, network addresses, and bridge software have not been supplied. Explanations of normal operation are therefore distinguished from implementation details that must be verified on the live system. The existing images accompany their respective sections as Figures 1–4; their captions identify the section context rather than certify individual image labels.

Core Server Architecture

A dedicated Debian Linux server hosts six active AllStarLink (ASL) nodes:

• Public ASL nodes: 468100 and 468101
• Private ASL nodes: 1996, 1997, 1998, and 1999

Server and Node Responsibilities

AllStarLink is based on the Asterisk communications platform and its app_rpt application. Asterisk provides communications channels, while app_rpt supplies repeater-control and node-linking functions. A node is a logical communications endpoint, not necessarily a separate computer or radio. This distinction explains how one Debian server can host the public radio endpoints and the private routing portals.

Public node 468100 is assigned to the VHF repeater path, and public node 468101 to the UHF path. Private nodes 1996–1999 separate external bridge and telephony connections into individually identifiable routing points. “Private” describes their role in this topology; it does not, by itself, establish encryption, access restrictions, or a separate security boundary.

The server brings the paths together, but the overview does not specify a permanent connection between public nodes 468100 and 468101. VHF-to-UHF cross-linking must not be assumed merely because both nodes run on the same host. Audio distribution depends on the connections and routing actually enabled.

In a typical ASL installation, node behavior, linking functions, identifiers, and timers are configured in rpt.conf. The W5DEL configuration must be checked before documenting exact commands, timeout values, or reconnection policies.

RF Links to the Repeaters

Two dedicated bidirectional duplex link radios connect the server to the repeater site, 1.4 miles away:

Frequency / Band	Operating Mode	Repeater	Link Radio	Radio Interface	ASL Node
146.700 MHz (2m)	Duplex	VHF Repeater	TYT TH-9000D	TOADS Digital Interface (DI)	468100
443.300 MHz (70cm)	Duplex	UHF Repeater	TYT TH-9000D	TOADS DI-6 Interface	468101

RF-to-Server Audio and Control

The RF links span the 1.4-mile separation between the server and repeater site. The table identifies the repeater frequencies and associates each TYT TH-9000D link radio and TOADS interface with its public ASL node. It does not specify the link radio’s complete receive/transmit frequency pair, repeater input offset, access tone, antenna arrangement, or power setting.

Functionally, the receive path carries audio from the repeater through the link radio and interface into the associated node. The transmit path carries audio from an enabled network connection through that node and interface to the link radio, which accesses the repeater. Audio alone is not sufficient: the node also needs a reliable indication of received activity and a way to key the transmitter.

A typical radio interface handles receive audio, transmit audio, push-to-talk (PTT), and a carrier-operated relay or squelch indication (COR/COS). PTT requests transmission; COR/COS indicates that the receiver has detected activity. The exact TOADS pin assignments, signal polarity, audio coupling, and ASL channel driver used at W5DEL require verification. The word “Digital” in the interface name should not be treated as evidence that either RF repeater operates in a digital voice mode.

The existing overview describes the links as duplex. Bidirectional audio routing and simultaneous RF transmit/receive capability are not interchangeable terms. The supplied equipment list does not establish the simultaneous transmit/receive capability of the complete link arrangement or its ASL duplex setting. Confirm the radio arrangement and configuration before assigning a specific full-duplex operating mode.

Figure 1 accompanies the RF-link description. Use the table and the verified wiring documentation together when tracing the VHF and UHF paths; the image alone is not a commissioning record.

Figure 1. RF repeater links — illustration accompanying the VHF and UHF link architecture.

Network Trunks and Extensions

Inter-Asterisk eXchange version 2 (IAX2) trunks connect the system to amateur VoIP telephony networks:

• Node 468100 (VHF) has active IAX2 trunks to:
  • Hams Over IP (HoIP): extension 15062
  • AmateurWire: extension 90031
• Node 468101 (UHF) has an active IAX2 trunk to:
  • AmateurWire: extension 90032

What the IAX2 Trunks Carry

IAX2 connects compatible communications systems using IP transport. It carries call signaling and voice media through a single UDP port, normally 4569. This is a protocol default, not a verified W5DEL firewall or listening-port setting. Each peer still requires a compatible configuration, permitted network access, and the appropriate authentication and routing rules.

An extension identifies a destination within HoIP or AmateurWire; an ASL node number identifies an endpoint in the linking topology. These are separate addressing systems. For example, AmateurWire extension 90031 is associated with the VHF path, but it is not an alternative ASL node number for 468100.

The public-node list above summarizes which repeater each network service reaches. The private-node assignments below identify the portals that manage those service connections: 1997 for AmateurWire 90031, 1998 for AmateurWire 90032, and 1999 for HoIP 15062. The overview does not provide the dialplan or peer definitions needed to establish exactly where each IAX2 session terminates.

Both ends must support a common audio codec. Network delay variation can be compensated by a jitter buffer, although buffering adds delay to the conversational path. The codecs, buffer settings, authentication methods, and registration requirements used here are not documented. They should be recorded per peer rather than assumed to be identical across all trunks.

Figure 2 accompanies the network-trunk section. Read its extension references alongside the portal assignments to distinguish a service destination from the internal node that manages it.

Figure 2. Network trunks and extensions — illustration accompanying the HoIP and AmateurWire connections.

Private Bridges and Control Portals

Four private nodes provide routing portals and digital network bridges. Each stays connected to its assigned public node and provides an administrative isolation layer to protect system integrity when network moderation is needed:

• Node 1996 — TGIF DMR bridge: links TGIF DMR talkgroup 51405 directly to public node 468100.
• Node 1997 — AmateurWire portal: manages the link to AmateurWire extension 90031 through public node 468100.
• Node 1998 — AmateurWire portal: manages the link to AmateurWire extension 90032 through public node 468101.
• Node 1999 — Hams Over IP portal: manages the link to HoIP extension 15062 through public node 468100.

Routing and Administrative Isolation

The private portals provide separate attachment points for the external services while remaining connected to their assigned public nodes. This makes the affected service easier to identify during moderation or troubleshooting. The intended isolation is operational: a control operator can target a specific external path rather than treating all connected services as one undifferentiated link.

For example, a problem on the AmateurWire VHF path should be investigated at portal 1997 and its associated extension 90031. A problem on the HoIP path belongs to portal 1999 and extension 15062. Whether either service can actually be disconnected without affecting other traffic depends on the deployed routing and control configuration; the portal design is not a guarantee of hardware or process isolation.

TGIF DMR Bridge

Node 1996 connects TGIF DMR talkgroup 51405 to public node 468100. A talkgroup is a logical DMR destination, whereas node 1996 is the ASL-side bridge endpoint. At a functional level, the bridge must adapt audio and transmission state between the DMR network and the ASL path so that traffic can reach the VHF repeater and return through the enabled bridge.

The overview does not identify the bridge software, vocoder implementation, DMR identity, TGIF endpoint, timeslot requirements, or talkgroup-selection policy. Those details are necessary for a reproducible installation description. Do not infer that the UHF repeater has TGIF access: the documented DMR bridge is assigned only to node 468100.

Figure 3 accompanies these private-node assignments. The key distinction is between the public RF endpoint and the private portal through which an external service is managed.

Figure 3. Private bridges and control portals — illustration accompanying nodes 1996–1999 and their public-node assignments.

Public Live Audio Streams

Both repeater systems stream live audio continuously to Broadcastify through ezstream:

• VHF — 146.700 MHz: Listen on Broadcastify (Feed 47665)
• UHF — 443.300 MHz: Listen on Broadcastify (Feed 47664)

Streaming Is a Separate Listening Path

The documented feeds publish the VHF and UHF audio separately. Broadcastify Feed 47665 corresponds to 146.700 MHz; Feed 47664 corresponds to 443.300 MHz. These public listening destinations are distinct from the ASL and telephony endpoints used for interactive communications.

Ezstream is a streaming source client, not a repeater controller or a public listening server. It accepts media from files or standard input and can use external encoding tools before sending the stream to a compatible server. In this deployment it supplies the Broadcastify upload path, but the document does not identify how the node audio is captured, which encoder is used, or the actual stream format and bitrate.

The functional chain is repeater/node audio, audio capture and encoding as required, ezstream upload, Broadcastify distribution, and listener playback. This path is listen-only in the documented architecture; a listener’s playback session does not provide a return PTT or RF-transmit path. “Live” means a continuing feed, not zero delay: encoding, transport, distribution, and player buffering can separate playback from the original transmission.

A feed can appear connected yet carry silence or the wrong source. Verification should therefore include listening to known activity on each repeater and confirming that it appears on the correct feed. Figure 4 accompanies the public streaming section and should be read with the feed mapping above.

Figure 4. Public audio streaming — illustration accompanying the separate VHF and UHF Broadcastify feeds.

End-to-End Signal Paths

The following paths summarize the documented assignments, not a substitute for the live dialplan. Each path depends on its links being enabled and its endpoints being available.

• VHF to AmateurWire: VHF repeater audio reaches the TH-9000D/TOADS link and public node 468100; portal 1997 manages the connection associated with AmateurWire extension 90031. Return traffic uses the enabled route back to the VHF RF path.
• VHF to HoIP: the VHF endpoint is public node 468100, with portal 1999 managing the HoIP extension 15062 connection.
• VHF to TGIF DMR: public node 468100 connects through bridge node 1996 to TGIF talkgroup 51405. The bridge supplies the adaptation between the two communications domains.
• UHF to AmateurWire: UHF repeater audio reaches the TH-9000D/TOADS DI-6 link and public node 468101; portal 1998 manages the connection associated with AmateurWire extension 90032.
• Public listening: the selected VHF or UHF audio source is uploaded through ezstream to its corresponding Broadcastify feed, without a listener return-transmit path.

Multiple services associated with one public node may share audio when their connections are active. The actual fan-out, source arbitration, and telemetry distribution must be checked in configuration. Avoid adding an alternate return route between already connected endpoints without reviewing loop prevention; unintended recirculation can cause repeated audio or persistent keying.

Operation, Monitoring, and Fault Isolation

The following checks are recommended practices, not claims that monitoring or automatic recovery is already implemented at W5DEL.

Commissioning Checks

• Confirm the inventory: record the Debian, ASL, Asterisk, bridge, and ezstream versions and map each physical interface to its logical node.
• Test each RF direction independently: verify received audio and activity detection, then transmit audio and PTT. Check for clipping, low audio, false keying, stuck transmission, and RF feedback using authorized test transmissions.
• Test portals individually: confirm each extension or talkgroup reaches only its intended public node. Exercise controlled disconnect and restore operations to establish the actual scope of isolation.
• Test both feeds: compare known VHF and UHF activity with the corresponding Broadcastify playback and verify that the sources are not swapped.
• Test recovery: verify what happens after a lost peer connection, an Internet interruption, and a server restart. Record which links return automatically and which require operator action.

Locating a Fault

Start with the smallest affected path. If all server-connected services fail, investigate host power, processes, and network connectivity. If only one repeater path fails, check that node’s radio, interface, activity detection, and audio settings. If RF works but a single external service fails, investigate the assigned private portal, peer reachability, authentication, and routing.

If interactive audio works but Broadcastify fails, check the capture source, encoder if present, ezstream connection, and remote feed status. A common server failure can affect both public nodes, all four private nodes, and stream generation; separate logical nodes do not eliminate that shared dependency. Conversely, loss of an external network does not by itself establish that local repeater operation has failed, because the independent repeater-site controls are not described here.

Control and Configuration Protection

Recommended controls include restricting administrative access, keeping credentials out of public copies, backing up configuration before changes, and retaining a tested restoration procedure. Private node numbers should not be relied on as passwords. Record the available moderation commands and their permissions from the live configuration rather than publishing unverified command sequences.

Configuration Details Needed for a Reproducible Build

The topology is documented, but an installation-ready specification also needs the following verified information. Keep secrets in protected administrative records rather than in this overview.

• Host and software: hardware resources, installed versions, service names, startup dependencies, configuration locations, and backup/restore process.
• RF and interfaces: repeater input/output frequencies, access tones, transmit power, antennas, interface wiring, audio levels, PTT/COR polarity, channel drivers, and the complete duplex arrangement.
• ASL control: node configuration, link mode, automatic reconnection, timeout and identifier settings, command permissions, and any intended VHF/UHF cross-link policy.
• IAX2 peers: remote endpoints, ports, registration requirements, permitted codecs, jitter-buffer settings, extension routing, and firewall/NAT requirements.
• DMR bridge: bridge software, DMR identity, codec/vocoder path, TGIF connection settings, talkgroup policy, and transmission-state handling.
• Streaming: per-feed capture source, encoder, format, bitrate, destination configuration, service supervision, and recovery behavior.

Technical References

These references support the general software and protocol explanations; they do not verify the W5DEL deployment. Accessed October 30, 2026.

• AllStarLink — platform architecture and app_rpt overview.
• AllStarLink app_rpt — radio interfaces, repeater control, and linking functions.
• AllStarLink Manual: rpt.conf — node configuration and linking controls.
• Sangoma IAX Settings User Guide — signaling/media transport, codec selection, and jitter buffering.
• Icecast: Ezstream — source-client operation and external encoding support.

DTMF Control Quick Reference

AllStarLink Direct Commands

• Connect (Two-Way Transceive): *3 + [Node ID]Example: Dial *3468100 to link in normal two-way mode.
• Monitor Only (Listen): *2 + [Node ID]Example: Dial *2468100 to monitor without transmitting RF audio to the remote node.
• Disconnect: *1 + [Node ID]Example: Dial *1468100 to disconnect.

EchoLink Commands

EchoLink Node Formatting: All EchoLink IDs must be converted to 6 digits by adding leading zeros after the 3 network flag.

• Connect (Two-Way Transceive): *33 + [6-Digit Padded ID]Example (Node 1234): Dial *33001234
• Monitor Only (Listen): *23 + [6-Digit Padded ID]Example (Node 1234): Dial *23001234
• Disconnect: *13 + [6-Digit Padded ID]Example (Node 1234): Dial *13001234

Command Summary