How To - Build a Cross-Band Full-Duplex AllStar Node Using a Mobile Radio
by David Gleason, NR9V

Introduction

AllStarLink Nodes can be built in many ways with various tradeoffs between cost, features, ease of construction, portability, audio quality and RF performance. Most nodes now available are small, simple nodes that support only half-duplex operation and often have low audio quality. Or another common design is to use old Motorola or similar radios, but these require special programming software and do not support cross-band full-duplex thus 2 radios and a duplexer would be required.

This guide shows how to build a node with a dual-band mobile radio that supports Cross-Band Full-Duplex operation while also being a full-featured radio that supports QSOs on analog FM repeaters, VFO and memory scanning, and simple front panel configuration. My other How-To Guide covers how to do this using 2 low-cost HTs, which is generally a more cost-effective way to go, but mobile radios can be a better option for base station use with an outdoor antenna or where maximum range is required.

AllScan ANF200 (w/Dell Wyse 3040, R1-ASL URI, and Kenwood TM-V71A)


Mobile Radios vs. HTs for use in a Full-Duplex AllStar Node

An ANF101 node with HTs can be built for well under $200, whereas an ANF200 mobile-radio node will typically be closer to $500, with the radio itself being $250+, an antenna and coax adding another ~$50+, and the MiniPC and USB Radio Interface (URI) adding another ~$100-150. A mobile-radio node with good outdoor antenna can have a range of ~50 miles depending on terrain and antenna height. HT-based nodes can also be used with an outdoor antenna by adding a ~$50 duplexer, in which case an HT-based node is still about half the price of a mobile-radio node but can give ~10-20 miles range. Thus mobile-radio nodes are more suited to applications that need 25+ Watts of output power, that can operate from an RV or parked vehicle, or where a modular, easy-to-build design is preferred.

Mobile-radio nodes are very easy to build if using a high-quality dual-band mobile such as a Kenwood TM-V71A or Yaesu FT-8800R. No mods are needed to the radio and no enclosure or other mounting hardware is needed. The mounting bracket that comes with most mobiles works great for attaching the MiniPC and URI, and the entire node can be assembled and wired in 1-2 hours. In contrast it can take 4-8 hours to make a full-duplex HT-based node that's properly optimized for RFI and noise. Mobile radios have less chance of RFI issues due to using an outdoor antenna that is typically at least 10-20 feet away from the node electronics. A higher-end mobile radio should also have better overall circuit design and power supply and I/O filtering than inexpensive HTs.

Mobile-radio nodes are typically used as Base-Station nodes at a home QTH, in an RV, or at a field day site for example, rather than actually "mobile". This is an important point to consider before going with a mobile, which are significantly more expensive and less power-efficient than HTs. Thus I only recommend going with a mobile-radio for a node radio if you need a lot of range (>~10 miles), already have a good outdoor antenna and 12V 15+Amp power supply/batteries, and if you would not generally take the node mobile or portable.

Table of Contents

Introduction
Overview
  Background
  History
  Node Components
Parts List and Component Options
  Main Components
  Mobile Radio
  USB Radio Interface
Setup Steps
  Dell Wyse 3040 Micro PC
  Recommended App-Rpt Settings
  Updating to the Latest ASL Code
  Wiring Notes
  Radio Interface Wiring
Setup Steps (continued)
  Radio Settings
  Ferrite Filters
  Signal-To-Noise Ratio (SNR) Optimization
  Node Management / Dashboard Apps
  WiFi Support, Portability
Full-Duplex Communication Benefits
FAQs
Node Notes / Instructions
Troubleshooting
Conclusion
Contact

Overview

Demo Video and Slideshow of an ANF200 using an Alinco DR-735T


Quick Demo Video of an ANF200 using a Yaesu FT-8800R


ANF200-8800R Back View showing Cables and Ferrite Filters


This uses a 5-16VDC Dell 3040 powered from the radio power cord with added PowerPole connectors. Top View showing all Cabling

Background

My other How-To Guide on building a full-duplex node using 2 low-cost HTs covers my background in engineering, ham radio, and AllStar, and many other details on the history and features of AllStar. I recommend reviewing that document for a broader context on the use and design of various types of nodes.

History

AllStarLink (ASL) has been used for controlling repeater systems for 15+ years, supporting a high-precision multiplexing receiver system that precisely time-aligns audio feeds from any number of receivers and ensures perfect synchronization, even with unpredictable delays that occur over various IP and wireless links. It's based on Asterisk, a powerful open-source PBX system that supports numerous features including full-duplex communications, conference calling, autopatch, integration with VOIP systems and equipment, voicemail, voice detection, Interactive Voice Response menus, support for a wide range of voice codecs, and extensive control and monitoring capabilities via web interfaces, DTMF commands, scripting and macros.

When you put an ASL image on a microSD card or flash drive, you're loading GigaBytes of software containing the result of millions of lines of code that make up Linux, Asterisk, ASL, Apache, PHP, SQLite, and the 1,000's of other utilities and programs that come with Linux. The power and flexibility of all this is far higher than what you see in typical commercial products such as a modern digital HT. Linux, Asterisk and ASL are 100% open-source and free, meaning that not only is it free but that anyone can look at the source code, see how it works, edit it, add to it or improve it.

Node Components

There are several main pieces to an ASL node:

  1. A computing device. This can be a Raspberry Pi, any Intel/AMD PC or Mini/Micro/Thin-Client PC, or a "cloud" Linux server such as a linode.com VM. In the case of a cloud server an RTCM interface can be used which connects to a router and then to your radio (but which cost almost $300). RPis, the Dell Wyse 3040 and some other Micro PCs use only about 5 Watts of power.
  2. A radio interface. This usually consists of a small PC Board with a C-Media CM108 or CM119 IC that interfaces to a USB port and provides an audio input, audio output(s), and GPIO lines for PTT, COS, and status LED(s). This is referred to as a URI (USB Radio Interface), RIM (Radio Interface Module), or could be called an audio interface or sound card, but due to the presence of hardware IO lines for connecting PTT and COS lines the term URI is more accurate.
  3. A node radio*. This is often built-in to Off-the-Shelf nodes in the form of a small simplex radio module. However these modules may not have very good audio quality or RF specs. Real radios are definitely preferable.
  4. Last, some other radio is needed to then talk to the node with. It could be an HT, mobile rig or base rig. With cross-band full-duplex the node radio could for example Tx on ~431 MHz and Rx on ~147 MHz, and your other radio would Rx on ~431 and Tx on ~147.

*There are also radio-less nodes, which use just a speaker and mic, but don't give you the flexibility of being able to walk around your yard or neighborhood with an HT. A VOIP phone can also be used as a radio-less node by setting it up with a standalone MiniPC or cloud VM running ASL (to key up dial *99 and then # to unkey), or smartphone apps such as DVSwitch Mobile, DroidStar, RepeaterPhone or Transceive can connect to an ASL cloud server over IAX.

Smartphone/PC IAX apps such as DVSwitch Mobile (DVSM), iaxRpt and DroidStar can easily connect to a node. The DVSM 2.x Android app supports IAX client, Web-Transceiver, and Node modes, is highly recommended, and is free in a limited demo mode or $2 to buy. DVSM in Node Mode is a true AllStar node with its own ASL node number but with some limitations. VOIP phones (such as any model supported by Hamshack Hotline) can be convenient and usually have a speakerphone feature, and SIP phone apps such as Linphone or GS Wave can also be used. Thus there are multiple ways to talk on an ASL node, through RF, IAX apps, VOIP (SIP) phones and apps, or in the case of radio-less nodes by plugging in a speaker and microphone. See this excellent article on how to set up VOIP phones/apps on AllStar nodes. This also covers using ASL's autopatch feature, enabling calls to VOIP phones to be made from a radio. This does require port 5060 to be open in the node's iptables (firewall) configuration and forwarded to the node in your router settings.

There are many cross-band full-duplex HTs and mobiles that are easy to find used for ~$150 or so.

Parts List and Component Options

Mobile-radio nodes are easy to build – only a MiniPC/RPi, URI, Radio, and a couple cables are needed. Recommended main components:

I have bought many 3040's from various sellers for as little as $25. Some 3040's also come with a built-in wifi card and dual antennas, which work very well. Most 3040's run on 5V 3A, but some will also run on 5-16V. I've also seen new 3040's on ebay for a little bit more (~$60) which is a small price difference for new vs. used. But even a used 3-5+ year old 3040 should run great for many years. The design is well thought-out with excellent thermal management and no fan to pull dust inside. If getting one that's more than a few years old I recommend checking the small backup battery and replacing it if below 3V. CR2032 batteries are available with solder tabs for as little as $1 ea. The case pops open with no tools needed and you can then also confirm if it has built-in wifi. Many 3040's have the internal wifi card and antennas even though many ebay sellers don't mention it. I usually have numerous 3040's with and without wifi in stock that I can provide with new backup battery and ASL preinstalled at a reasonable price. I also provide fully assembled and tested nodes.

Since the radio runs on 12V, ideally the newer 3040 version that supports 12V input should be used. That way the 3040 can be powered from the radio's power cable and no AC Adapter or DC-DC converter is needed. The 3040 bottom label will say either 5V or 12V. The "12V" versions actually support 5-16VDC input. Many 3040's also have built-in WiFi.

For base-station or fixed location use ideally wired internet will be available and the 3040 will not need to support WiFi. Use of wired ethernet results in simpler configuration and higher reliability. WiFi may be needed in some cases though in which case the Dell OEM internal WiFi module works very well, or a USB WiFi adapter can be added which are anywhere from $5~$25 depending on range and performance.

Mobile Radio

Kenwood TM-V71A or Yaesu FT-8800R mobile radios are probably the best options for overall price, performance, and features. These are often available on ebay, QRZ.com, eham.net, etc. for as little as $250 used to $400-450 new or near new. The hand mic supplied with the 8800R is not very good so for that reason I prefer the V71A, but that's a minor difference, and during normal node operation the mic is not needed.

Any other radio can be used if it supports Cross-Band Full-Duplex (CBFD) and has a "data" jack that provides unfiltered discriminator audio output. Some radios do not support cross-band operation on the data jack, in which case the Mic jack can be used for Tx audio and PTT on one band with Rx audio obtained from the data jack. This does limit the use of the mic ie. to switch between node operation and normal radio operation a mic switch would be needed. This could be added easily with an extra RJ-45 mic jack and plug and a DPDT switch on the mic audio & mic ground lines, but ideally a radio that properly supports both bands on the data jack can be used.

The Alinco DR-735T is the only current-production radio I know of that supports cross-band full-duplex, has a MiniDIN6 jack, has ≥ 4 stars average reviews on eham.net, is easy to use and program via the front panel with no programming software needed, and has excellent audio quality. These make great base-station nodes that can give 25+ miles range with a good outdoor antenna. Due to limitations of the 735T use of the mic jack is required as its MiniDIN6 only supports the B band in the radio thus for cross-band full-duplex the mic input is used for A band node Tx on 2m, while the MiniDIN6 provides unfiltered "9600" Rx audio on 70cm. The 735T does not support CTCSS decode when in TNC mode thus it is necessary to use the ASL usbradio driver DSP mode, which works flawlessly, using only about ~10% CPU on a Dell 3040, while totally eliminating squelch tails on the Rx audio which is a great feature that very few radios are capable of.

Radios such as the Kenwood TM-V71A and Yaesu FT-8800R are easier to set up as their MiniDIN6 jacks fully support cross-band full-duplex, making for a simple setup with no custom cabling needed, just a straight MiniDIN6 cable and you have a finished node, but these radios can be harder to find in excellent condition for a good price. Thus the DR-735T is the most cost-effective way to build a full-duplex node with a new current-production highly-rated mobile radio. The 735T also has a quieter fan than those in the V71A and 8800R, and has a nice LCD with configurable color coded backlighting that makes it easy to see the Rx/Tx/Idle status of each band.

The fans on the 8800R and V71A run every time you key up (regardless of power level or transmit duration) and can be annoying in a quiet environment. The fans can be switched to a quieter model or have their supply voltage reduced fairly easily if needed, though you'd want to be sure to then only use lower power settings or closely monitor the heatsink temperature. If using the 735T on low power in a cool environment the lowest fan setting can be used (where the fan typically stays totally off if transmitting Low power), but the heatsink temperature should be monitored closely. A radio could be mounted inside a small case or Go Box with acoustic foam to reduce the fan noise and make the node more portable (with some openings at the front and back to allow sufficient airflow). Running radios on a lower voltage can also greatly reduce heat dissipation. Many HTs will run very hot if powered from 9-12V but barely even get warm on 6-7V. Thus running a mobile closer to its minimum specified supply voltage eg. 11V will likely result in cooler operating temperatures than at 13.8V.

The DR-735T, TM-V71A and FT-8800R all support "9600" unfiltered audio out which then enables the use of ASL's usbradio driver DSP mode. This is easy to set up and provides very high quality CTCSS/squelch detection and no squelch tails. Therefore I recommend using only the 9600 output. This also makes the cabling a little simpler because no COS line is needed.

The DR-735T MiniDIN6 audio input does not support unfiltered wideband audio however, thus the 735T has to do CTCSS encode rather than usbradio. This works fine but means that usbradio's notone setting cannot be used, which drops CTCSS prior to unkeying thereby preventing squelch tails on node transmits. Because of these limitations a TM-V71A or FT-8800R is definitely preferable, but the 735T's are easier to find and can be less expensive.

While there are many Chinese mobile radios available, as far as I know none of them provide a data jack with unfiltered audio or properly support cross-band full-duplex. (Some support cross-band repeat, but that's not the same thing.)

Cheap single-band radios such as old Motorola radios could be used but this doesn't really save much money, takes up more space, requires a duplexer or separate antennas, is more difficult to set up and configure, and does not provide nearly as many features as a good cross-band full-duplex mobile radio.

A Yaesu FT-8900R would probably also work fine, however these have lower review ratings than the 8800R, apparently due to some diodes often failing. They might be fine if used on lower power settings, but I would avoid any radio with average ratings of less than 4 stars in eham.net reviews. There are various other mobile radio models that would work well also such as a Kenwood TM-D710A or even a TS-2000, but these are more expensive and probably overkill for an AllStar node. And there are many vintage/older radios that would probably also work well, but you'd want to carefully review the manual and specs to confirm how well they support cross-band full-duplex operation.

USB Radio Interface

A number of URIs are available that use high-quality C-Media USB Audio I/O Controller ICs:


Modified BH7NOR R1-2023

Modified CM108AH on Left, RIM-Lite V2 on Right

The CM1xx-series ~45dB mixer gain range supports most radios perfectly with no trim pots or resistors needed. The ASL channel drivers set these gain settings in the IC based on the rxmixerset, txmixaset and txmixbset config settings. This provides a wide adjustment range while retaining the full dynamic range of the 16-bit converters.

Option 1: BH7NOR, Repeater-Builder, or Kits 4 Hams Interfaces

The BH7NOR R1 are compact, inexpensive, have a MiniDIN6 connector, include an attractive blue extruded aluminum enclosure, and have very thorough RFI filtering. The Repeater-Builder RIM-Lite V2 are compact and have all needed lines on a DB9 connector but do not include a case. The Kits 4 Hams PAUL look like a great option though I have not yet had a chance to test their performance.

For highest performance while also being inexpensive I therefore recommend an R1-ASL/2023, which will easily deliver 55-60dB end-to-end audio SNR. The R1-202x needs 2 simple modifications, whereas the R1-ASL already includes these:

  1. Remove R22 and Q8 for proper support of Full-Duplex
  2. Carefully lift CM1xx IC pin 38 (MSEL) and connect to pin 37 (3.3V) for proper support of ASL's txmix level settings

For use with a MiniDIN6 10KΩ audio output the following additional mods are also needed:

  1. The R1 has a low ~100Ω load impedance on the Rx Audio line, which is not a good match to the typical ~10KΩ output impedance of the Rx audio lines on the MiniDIN6 jack of most radios. This can result in the Rx audio being too quiet and noise then resulting due to the high gain required to bring the signal back up. This can be fixed by using the Speaker jack output instead but that can limit other functionality and is not ideal. The better thing to do is: Remove the Rx audio isolation transformer, connect the Rx audio line to the transformer output pad, connect the Rx audio input Gnd to the transformer output Gnd pad, remove R1 and R7, replace R2 with 0Ω, and add a 1nF cap and 10KΩ resistor between C15 and the CM108AH Ground. The R1 still has plenty of other RFI filtering and isolation, so bypassing this for the Rx audio is not likely to result in increased RFI or noise
  2. To use the unfiltered 9600 audio line on the MiniDIN6 jack the audio should be taken from pin 4 instead of pin 5. And in this case no COS line is needed thus the R1-202x COS circuitry can be disconnected and the blue Rx LED used to instead show the CM108 "Status" by connecting the LED to pin 12 with a 10KΩ resistor

I can provide R1s with any needed mods and ship usually within 1 day. See my Products page for details.

Alternatively a RIM-Lite V2 and a shielded enclosure can be used, which are also easy to connect and can also deliver 55-60dB SNR. Or a Masters Comms DRA-36 could be used with no case and would work fine if your antenna(s) are far enough away from the node, but a shielded enclosure definitely improves RFI-resistance and looks more professional.

Option 2: Modified CM108 Interface

CM108 USB interfaces can work well but require extensive modifications to provide proper RFI filtering and thereby achieve high-quality audio with no noticeable noise. Even then I have only been able to get a SNR of 50-55dB. That seemingly small ~5dB SNR difference from URIs mentioned above is definitely noticeable if using a good quality radio in a quiet environment. The fobs require a lot of optimization to add filter caps and ferrites on various I/Os, keep all wiring and grounds as short as possible, separate the analog and digital grounds on the board, etc. to get acceptable noise levels. Otherwise the nearby RF from the Tx antenna and from your other radio(s) can cause 60Hz and 1KHz harmonics to be induced on the Tx audio and to a lesser extent on the Rx audio. This approach can save maybe $30 vs. going with an R1, but could require hours of additional time to do the mods, testing, and RFI optimization. See the CM108 Sound Fob Modification page for further details, but note that if you are already spending ~$300+ on a mobile radio it makes more sense to buy a high quality URI rather than try to cut corners with a ~$5 sound fob.

RFI/Noise Optimization

Fobs or URIs that do not come with a metal case should be put inside a small 1" x ~2" x 3-4" aluminum enclosure (eg. link) to improve RFI resistance, protect the PCB from possible damage, and simplify the node appearance. A mobile radio transmitting as much as 50 Watts from a nearby antenna, or an HT used to talk to the node transmitting 1+ Watts from 5 or 10 feet away, can make for a challenging RFI situation – particularly with full-duplex nodes. A small opening should be provided so the status LED(s) are visible, or mount a standard 5mm LED on the enclosure (eg. with a panel mount LED clip) and wire it to the LED output lines on the URI.

All cables should be as short as possible, and the URI case should be grounded, which can be done by attaching a small (eg. #4 or M3) nut, bolt, washer, and star washer to the case and the radio's metal mounting bracket.

Setup Steps

Dell Wyse 3040 Micro PC

Installing ASL on a Dell 3040, other Mini/Micro PC, or Netbook is not hard if you're experienced in building/maintaining PCs. The 3040's have a UEFI-only BIOS that needs a boot file in a specific place. Making a UEFI USB drive is simple: Download the most recent ASL install image, then format the USB drive as FAT32 and unzip the image files onto it (7-Zip is a good program for unzipping ISOs). The USB drive has to have the ASL image files on it with no modifications. Do not try to make it "bootable" using some other program as that will result in a "legacy" boot format, which will not work.

There have been rare cases reported where people were not able to properly copy ISO files to a USB drive but were finally able to get it working using "Rufus", a free program that can create UEFI USBs. It's probably not going to do anything that 7-Zip wouldn't but it's possible that if you are unfortunate enough to be running an OS like Windows 11 that it may be limiting your ability to do basic things and thus a "special" program may be needed. (However in such a case the first thing I would recommend is to install Linux on your PC instead, as it's a far better OS that is completely free, more secure, and easy to install.)

To initially set up a 3040 requires a USB keyboard and a monitor/TV with a DisplayPort cable. Plug in the keyboard and DisplayPort cable. Power up the 3040 and when you see the Dell logo hit F2 to enter BIOS setup, and review the various settings. Some 3040's may have a BIOS password which defaults to "Fireport". This can be cleared in the Security section or if some other password was set can be cleared with a button on the PCB. Recommended BIOS settings: 

System Configuration
→ UEFI Network Stack: Disabled
→ Integrated NIC: Enabled (NOT w/PXE)
→ USB Configuration: Enable all checkboxes
Secure Boot: Disabled
Power Management
→ AC Recovery: Last Power State
→ USB Wake Support: Disabled
→ Wake on LAN: Disabled
POST Behavior
→ Keyboard Errors: Disabled
→ Fastboot: Auto
Virtualization Support: Disabled

Nothing should need to be changed on the boot order page or most other pages. Once you have confirmed the BIOS settings, save and exit, and then when you see the Dell logo hit F12 for the boot menu, then select the USB drive. The 3040 will then boot from the USB drive and will guide you through the ASL installation.

The Intel/AMD ASL image is an installer image intended to boot on a removable device and install Debian and ASL on an internal storage device (or on a separate removable USB/SDCard). This differs from the RPi image which goes on an SD Card, into the RPi, and the install is done. The Debian installer is pretty simple and takes about 10 minutes to complete. The default options should all be fine. Make sure to install to the MicroPC's internal eMMC drive, overwriting ALL existing partitions.

The Intel/AMD ASL install image is based on the Debian Linux installer which has a boot file where the 3040 expects it. However, once the install finishes to the 3040 internal flash, the boot file there needs to be renamed for the 3040, thus an extra step is required: Hit Ctrl + Alt + F2 after the Debian installer has completed to access the console and then run the following commands: 

sudo mkdir /boot/efi/EFI/BOOT
sudo cp /boot/efi/EFI/debian/shimx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

(Alternatively these commands can be run by booting a UEFI clonezilla USB drive, selecting the "Local operating system (if available)" boot option, and then the Debian OS option. Clonezilla is also useful for backing up nodes and PCs and for upgrading PC hard drives.)

Then remove the USB drive and power cycle the PC. The rest of the AllStar setup process is then the same as on an RPi. Refer to the AllStarLink.org Install Guide to complete the node configuration and properly provision it on the AllStarLink Web Portal.

When I build nodes I use Clonezilla to restore an image with the latest compiled-from-source ASL 2.0, AllScan, Supermon and various other utilities already set up. I then update everything and make a backup copy of the node eMMC before shipping. For instructions on how to backup and restore a node using Clonezilla see this post on the AllScan Facebook Group.

Installing on other Thin Client models or on a Netbook or Laptop should be even easier as those shouldn't need the boot file to be renamed. Note however that Chromebooks should be avoided. Only use a Netbook if it already has a properly working Linux OS, not ChromeOS which is a closed and encumbered platform.

Alternatively, Debian 10 can be installed from a Debian install USB, and then ASL installed as described in the "Updating to the Latest ASL Code" section below. This gives more options in how Debian is set up. Debian 11 or 12 can be used also but ASL does not yet officially support those and a lot of extra steps are needed to make the compile work (see the ASL Forum for details).

A Desktop GUI can be a nice addition if you have a monitor, TV, or remote desktop app that can be connected to the 3040. The Xfce Desktop is easy to set up, looks great, simplifies wifi and wired network management, and only needs about 2GB of eMMC space. The whole install with Desktop can fit on an 8GB 3040 but is a tight fit requiring some adjustments to partitions or removing unneeded packages thus the 16GB 3040 version is preferable. The 3040 is then a full-featured Linux PC with 1,000's of free programs. Only a single command needs to be run to install Xfce, see this article for details.

Recommended App-Rpt Settings

This node design can use hardware COS or usbradio's carrierfrom=dsp mode. I highly recommend DSP mode to ensure the highest audio quality and eliminate squelch tails. While a short burst of loud white noise at the end of every transmission can give an "old-school" analog FM sound, squelch tails are in fact unnecessary noise that thereby decreases average signal-to-noise ratio. Any technique that reduces noise improves clarity and interactivity. There may be a tradeoff of a small delay (rxsquelchdelay in usbradio.conf which defaults to 30mS) in eliminating squelch tails but with this set to 10mS I still get no squelch tails and 10mS is a very short delay that should not result in perceptible outgoing IAX audio latency.

While most other node designs support only half-duplex operation often with a noisy RF module, no easy front panel programmability, closed-source software, overpriced RPi hardware, and/or limited features and configurability, AllScan node designs leverage the full capabilities of AllStar including advanced Digital Signal Processing, and of the best available amateur radio transceivers to deliver professional-level audio quality and a full feature set.

Mobile radios that provide COS eg. on a MiniDIN6 connector should have a cfg setting allowing the line to properly follow Tone Squelch rather than just Rx Busy, and most such radios should provide unfiltered discriminator audio out that supports Rx Carrier Detect and CTCSS decode in ASL. Be sure to only use a radio that supports at least one of these features, otherwise the node could get keyed up by QRM/QRN.

Tests I ran on a 3040 (which has 4 CPU cores) doing a full-duplex parrot test showed that the simpleusb driver and usbradio driver in various carrierfrom modes all use about 25% CPU (6% total CPU of all 4 cores) or slightly higher but well under 10% total CPU. Tests with the Linux 'htop' command confirmed that asterisk does appear to use all 4 CPU cores thus there should be plenty of headroom on the 3040. Thus usbradio's DSP mode should not have any significant impact on CPU use.

rpt.conf Recommended Settings

rxchannel = Radio/usb_[node#] ; Comment out all other rxchannel lines
duplex = 3 ; Full-duplex, do not repeat Rx audio to Tx audio
hangtime = 100
althangtime = 100
;linkunkeyct = ct8 ; Comment out to prevent courtesy tones when connected
holdofftelem = 1
telemdefault = 0   ; Prevent "node X connected to node Y" messages
parrotmode = 1     ; 1 = Parrot On Command
;Uncomment following lines:
921 = cop,21 ; Enable Parrot Mode
922 = cop,22 ; Disable Parrot Mode

usbradio.conf Recommended Settings

rxboost = 0
;Enter your desired Rx & Tx CTCSS Tone frequencies below
txctcssdefault = 127.3
rxctcssfreqs = 127.3
txctcssfreqs = 127.3
rxctcssoverride = 0
carrierfrom = dsp
ctcssfrom = dsp                 ; no,usb,usbinvert,dsp
rxdemod = flat                  ; input type from radio: no,speaker,flat
rxsquelchdelay = 10             ; delayline in ms carrier squelch tail eliminator
txboost = 0
txprelim = yes                  ; Audio processing on left output channel: no,yes
txlimonly = no                  ; Audio limiting with no pre-emphasis on output channel: no,yes
txtoctype = notone              ; Transmit tone control type: no,phase,notone
txmixa = composite              ; Left channel output: no,voice,tone,composite,auxvoice
txmixb = no
rxlpf = 2
rxhpf = 1
txlpf = 1
txhpf = 1
duplex = 1

NOTE: For radios such as the Alinco DR-735T that do not have a direct modulator (9600) audio input, use the following settings: 

txprelim = no                   ; Audio processing on left output channel: no,yes
txmixa = voice                  ; Left channel output: no,voice,tone,composite,auxvoice

Once you have set up your node and made the above settings you will want to run sudo /usr/sbin/radio-tune-menu and run these steps in the following order:

Some fine-tuning of these settings may be needed over time if you run into any issues where the node does not always reliably detect when you are keyed up. Refer to the allstarlink.org wiki or forums for more details on these settings.

simpleusb.conf Recommended Settings

Simpleusb is not recommended, but if you prefer a slightly "simpler" configuration or have issues with usbradio, and have the COS line from the radio connected, the simpleusb driver can be used with the following settings: 

rxboost = 0
carrierfrom = usbinvert
ctcssfrom = no
deemphasis = yes                ; yes if using "9600" discriminator output, no otherwise
plfilter = yes                  ; yes if using "9600" discriminator output, no otherwise
txmixa = voice
txmixb = no
preemphasis = 1                 ; 1 if using "9600" modulator input, 0 otherwise
duplex = 1

Audio Levels

Consistent audio levels are important on any communication network, otherwise users have to make frequent volume adjustments to properly hear everyone. This is an issue on AllStar and I recommend that any time you hear someone who is significantly quieter or louder than average – let them know. Audio levels are easy to adjust on AllStar and there is no good reason anyone should have improper levels that require everyone else to frequently adjust their volume controls or put up with distorted, clipped, crackly audio.

Updating to the Latest ASL Code

The ASL install image is rarely updated thus to get the latest features and bug fixes requires downloading and compiling the latest code and updating the OS and packages. This takes about 10-15 minutes to do, as follows:

  1. Log into the node by SSH as root (run "sudo su" if not already root user).
  2. Run the command listed on the ASL GitHub Prerequisites - "Install apt dependencies" section. Note: The "Repo" steps should not be necessary and are not recommended.
  3. Run the 5 commands listed on the ASL GitHub Compiling - "Manually" section.

Your node should now have the very latest ASL code, fixes and features. If you see any error messages, go to the ASL Forum App_rpt-users Category, do a search there to see if the error message was already reported and a solution provided, or if not open a new Topic there and describe the error(s). You should then likely get a response within a few hours or so. Because ASL is currently in the process of Beta testing the 2.0 release there can occasionally be compile errors but they are usually easy to resolve thanks to the many excellent devs and contributors.

After setting up any node I recommend checking the system logfile /var/log/syslog periodically to make sure there are no error messages shown during system boot and normal operation. I have seen errors with some ASL versions where an invalid command in /etc/network/if-up.d/firewall causes the networking service to exit and thus the node will lose its DHCP IP address after half a day or so (bug report). This is easy to fix by commenting out the 1st line in /etc/network/if-up.d/firewall. I have also seen an issue where the cron entry set up for AllMon is not valid preventing Allmon's astdb file from getting updated. If you don't use Allmon it's not an issue but is easy to fix by adding a cron command similar to the one set up by Supermon (eg. run "sudo crontab -e" and add a "0 9,21 * * * (/usr/sbin/astdb.php cron)" line at the bottom). There are other known issues in older ASL code that have already been fixed in the latest code, and these couple other fixes will probably be merged soon.

Wiring Notes

If powered from AC you'll need a 12V 15+Amp DC power supply for the radio. As mentioned previously ideally a 12V Dell 3040 version should be used. A power cord going to the Dell's 4.0x1.7mm power jack can then be spliced onto the radio's power cord, ideally with a pair of PowerPole connectors such that the 3040 power cord can be detached from the radio power cord if need be.

Power cords should be as short as possible and no more than one fuse should be used. Mobile radios often have power cables with 2-3 separate fuses, then another fuse inside the radio, and yet more fuses in the PowerPole distribution box/outlet. This results in as many as 5 fuses and 10+ feet of power wire, which over time often causes unreliable power connectivity and large voltage drops. Therefore I try to keep radio power cords no more than 6 feet in length, with no more than one fuse in the cable (in addition to fuses I have in my power distribution box).

I recommend PowerPole connections for everything as these are easy to use and reliable. If you don't already have one I suggest investing in a PowerPole connector kit which includes the crimp tool, insertion/removal tool, and various sets of connectors for different wire sizes. Note that in addition to crimping, terminals should be soldered to each wire, otherwise wires can easily slip out of the terminals, which is not something you want to happen when on a road trip or at a field day site.

The above details will result in a nicely-integrated compact node with a single power cord.

If you happen to have only a 5V 3040, an LM2596 DC-DC converter module can be used to reduce the 12V supply to 5V. This may need a few 1,000μF of added filter capacitance and possibly an RC filter to reduce switching-noise RFI, but should usually be fine with no added filtering.

Radio Interface Wiring

Kenwood TM-V71A, Yaesu FT-8800R, and Similar Models

High-quality radios such as the V71A or 8800R plug directly into an R1 URI with a standard MiniDIN6 (aka PS/2) cable. No custom cable is needed. The R1 however should be wired to use the 9600 audio input, with 10KΩ input impedance.

Alinco DR-735T and Similar Models

The 735T and probably many older radios do not support cross-band full-duplex operation on the MiniDIN6 jack and thus the Mic jack has to be used for the Tx audio and PTT on 2m while the MiniDIN6 supplies the 70cm Rx audio.

Wiring - R1-ASL/202x to Alinco DR-735T 
MiniDIN6 Pin 4 ---- MiniDIN6 pin 4 (9600 Rx Audio)
MiniDIN6 Pin 2 ---- Mic Jack pin 7 (Ground)
MiniDIN6 Pin 3 ---- Mic Jack pin 4 (PTT)
MiniDIN6 Pin 1 ---- Mic Jack pin 6 (Tx Audio)
Tx Audio Ground* --- Ferrite Bead --- Mic Jack pin 5 (Mic Ground)

*Tx Audio Ground should be taken from inside the R1 from the Tx audio isolation transformer output ground pin, to a ferrite bead. Using any other ground, not using a ferrite bead, or connecting the Mic jack Gnd and Mic Gnd lines directly together can result in noise on the Tx audio.

Other Radios/URIs

There are many other older radios that could work well but which can have a variety of different connectors and config settings. With the possible number of combinations of radios and URIs I can't cover them all here but it's easy to figure out from the radio manual and URI documentation.

Radio-Less Node Notes

See my other How-To Guide for details on building a high-quality full-duplex Radio-less node, which can be built with just a Dell 3040, CM108 interface and a half-dozen small parts.

With mobile-radio nodes that connect to the URI through a MiniDIN6 type of jack the radio's speaker and mic are still usable for normal radio use. The mic audio will only go out on the Tx RF (not into ASL), and only RF Rx audio will be output on the speaker (not audio from ASL). Thus the radio can be used as a normal radio any time (be sure you are not connected to any nodes if doing this, or turn off the 3040), but the mic and built-in speaker are not able to be used with AllStar. It would not be hard however to add a switch box that would switch the mic and internal speaker between normal operation and radio-less node operation, where the mic and speaker would connect to the URI instead of the radio. This could be complicated to set up depending on the specific radio, but could work well on Alinco radios since Alinco mics output regular DTMF rather than serial data. (I can do custom nodes with this and many other custom features, email me for details.) In the case of the 735T which requires the Mic jack to be used due to the data jack not supporting dual-band operation, a switch box could allow the mic and speaker to be switched between normal radio mode, node mode, and radio-less node mode. One ~6P3T rotary switch could be used to route all necessary lines.

Radio Settings

Be sure to set up the node with CTCSS Tone Squelch enabled, to prevent possible QRM/QRN from keying the node. And enabling Tone Squelch on your other radios will then shorten/eliminate squelch tails. Also check your local 2m and 70cm band plans (eg. in Southern California TASMA.org and SCRRBA.org) to find simplex frequencies specifically intended for analog FM hotspots so you won't possibly interfere with repeaters or calling frequencies.

Comments re. Frequency Coordination from Jim NO1PC: "...Hotspots are a 'new niche' not fully encompassed amid the more well-known realms of ATV, SSB, EME, repeaters, simplex, etc. Some regions have specifically addressed this, some not yet. "The ARRL Band Plan" is wholly inadequate in addressing this, but then they vacated much of the issue a decade or so ago. ... There are 53 repeater coordinating/spectrum management organizations in the United States. Links to them are provided by at least the following two web sites: https://w2xq.com/bm-repeaters.html, https://repeaters.us/"

When picking your node frequencies be sure to consult the above sources, and verify the frequencies are not being used by other nearby users or systems.

Alinco DR-735T Settings

Recommended settings for use with the 9600 audio output and usbradio DSP mode

Kenwood TM-V71A Settings

Recommended settings for use with the 9600 audio I/Os and usbradio DSP mode

Yaesu FT-8800R Settings

Recommended settings for use with the 9600 audio I/Os and usbradio DSP mode

You should of course thoroughly read the radio manual and be familiar with all other menu settings and how to configure, store and recall memory channels.

Important Note: Nodes can run at a 100% Tx duty cycle during nets or long QSOs. Many radios are not designed for long-term 100% duty-cycle operation at Medium to High power and this could damage the radio. I suggest using Low power settings generally and only use Medium or High power if the radio has plenty of airflow and is in a cool environment. After first setting up any node the heatsink temperature should be monitored closely to establish what temperatures it reaches under various conditions ie. duty-cycle, Tx power setting, ambient air temperature, supply voltage, etc. If it gets hot to the touch an additional cooling fan and/or lower power setting is advised.

Ferrite Filters, RF Notes

Clip-on ferrite cores or ferrite beads are inexpensive and should be used on the audio cable(s), USB and ethernet cables. Laird 28A2029-0A2 work well and have enough room to allow cables to be wrapped 2 or 3 times. They are less than $1.50 ea. in Qty's of 10, and often come in handy for other things around the shack. One may be helpful on the power cable also depending on your specific setup and RF environment. Or you may be fine with no ferrites if your antennas are far enough away from the node. Ferrite kits can be found on amazon eg. with 50 pieces of various sizes 3.5–13mm for about $20. These are great for any ham shack and accommodate all common cable sizes.

Ferrite filters should generally be used with any DC power supply, with the cord wrapped around the ferrite a few times at the side of the cord closest to the power supply. Without that there can be significant buzz that comes through onto the node audio. This is a common issue caused by RF induced on the power cord causing 60Hz harmonics when the diodes in the power supply are near their zero-crossing points where they can be modulated by induced RF. This results in a broadbanded buzz on 60Hz and its harmonics that gets louder and quieter as you move antennas or cables around or move around with your HT that you're talking to the node with. This is not likely to be an issue on a high-quality mobile radio and power supply, but if it ever is, ferrite filters can reduce this by 99+%.

A ferrite filter is most likely needed on any ethernet cable going to the node, placed as close to the node as possible. A ferrite filter was needed with my RPi node on the USB cable, but on my Dell 3040 nodes no ferrite is usually needed there. This is good news as it confirms that the FCC-certified Dell puts out much less EMI/RFI than an RPi4. This is another advantage of the Dell 3040 (which has about 15 different certification logos on the bottom) over RPi's. But I often put a ferrite on the USB cable anyway just to reduce any possible chance of noise.

Everyone's RFI/EMI environment can be different. As with with any product or project, you may run into issues and need to do some debugging. You might need to add some extra ferrites on certain cables, or move some things around on your desk or in your shack. Any time a receiver is amplifying signals in the < 1μV range it's easy for interference to occur if you have a noisy power supply nearby, or you're too close to a cell tower, wifi devices, power lines, or other possible EMI sources. Keeping the node antenna as far as possible from other electronic devices is also generally a good idea.

Be sure to use a proper mobile or base antenna with large solid ground-plane and at least 25 feet of coax. HT-type antennas should never be used with a mobile-radio. They can cause RFI issues, have a high SWR, poor performance, and can overheat.

The antenna is the most important part of any ham radio system. If not properly installed and tested it could have a high SWR which over time could damage the radio or cause RFI and noise. Nano VNA analyzers are a great tool for checking antenna SWR plots and are easy to find for <$50 – which is quite a deal because 10 or 20 years ago the same thing would have cost easily 10 times as much. Or SWR meters can be found for as little as ~$25. Some nicer VHF/UHF radios even have a SWR meter function built-in. SWR should be periodically rechecked, especially with outdoor antennas that often corrode over time with exposure to the elements. And be sure to disconnect any outdoor antennas prior to possible lightning storms.

An important test to do after setting up any node is a sensitivity test where you transmit to it with low power from about a mile away, and using parrot mode confirm that your audio is clearly received. Also make sure your 70cm frequency is not a multiple of your 2m frequency. ie. if the node transmits on 145 MHz and receives on 435 MHz, it's not going to work. The 70cm frequency should be at least a couple MHz away from the 3rd harmonic of the 2m frequency.

Signal-To-Noise Ratio (SNR) Optimization

When building or optimizing a node it's important to measure the Signal-to-Noise Ratio of both the receive and transmit audio paths. This can be done by connecting the speaker output of any radio or receiver to a PC audio interface / sound card, recording the node's output audio, then normalizing the file to 0dB and looking at the noise level in the quiet parts. Note that SDRs are not recommended for this as they often have inconsistent results due to the numerous settings options they have with gain, bandwidth, and filter parameters, and they may have higher noise due to being USB-connected devices. A good quality analog radio is better for test purposes, and ideally should be run on battery power with no connections to any equipment other than the audio recording interface.

When you first assemble a node it might have perfect audio quality and no noise on both transmit and receive, in which case you don't need to test anything, but things are not always that simple. Consistently getting 55+dB SNR through the whole Rx + Tx signal chain on a node is not easy – especially on a full-duplex node. But once proper testing and optimization have been done the result can be indistinguishable from even the best Analog FM repeater systems. Mobile-radio nodes tend to have less noise/RFI than HT-based nodes since mobile radios typically use an outdoor antenna, and a $300+ mobile radio will probably have a better overall RF design than a $25 HT. Though HT nodes can sound just as good once properly optimized.

In having done extensive audio quality testing and seeing SNR's of anywhere from 40–60dB in various scenarios it was necessary to fully investigate all possible noise sources and optimize the design to ensure consistent results as close to 60dB SNR as practical in all cases. After weeks of testing, including building audio interfaces using various combinations of CM108B and CM108AH USB fobs, Repeater-Builder RIM-Lite V2's, audio isolation transformers, termination resistors, optocouplers, etc. I have things now pretty well optimized and consistently delivering 60dB transmit SNR (node transmit only) and 54dB round-trip full-duplex SNR (node and other radio simultaneously transmitting).

Full-duplex nodes are more of a challenge to minimize noise on because 5+ Watts are being transmitted (on 2m) while receiving on the same antenna (on 70cm), all while you're also transmitting into the node on another radio on 70cm. The following graphic illustrates SNR measurement results on a variety of nodes, radios and radio interfaces, along with S-Unit equivalents, and comparisons to typical audio equipment quality levels. Note that SNR is not the only important measurement of noise performance, as the type of noise and spectral distribution and randomness are also important, but SNR is one of the first things that should be tested in order to quantify overall clarity.

Measured Signal-To-Noise Ratios of various Nodes and Radios

60dB SNR on a node is a clean, clear, and professional-sounding result, easily on par with typical end-to-end Analog FM SNR's on even the best repeater systems. 60dB in real terms means that the noise is literally 1 million times lower in acoustic power than the signal, which equates to essentially zero discernible noise in typical listening conditions. (I will soon update the above table with SNR measurements on various mobile radios.)

For these measurements I record the node's transmit audio from the audio output of a high quality VHF/UHF base radio into a 24-bit audio interface, normalize the levels such that open squelch gives 0dB (max) signal level and no clipping on the interface, and then look at the signal and noise levels and noise spectral analysis in a wave editor (see Screenshot showing 60dB SNR during transmit hangtime after RXCD drop from an ANF101). In that case the ANF101 RT85's are capable of 60dB SNR thus we know that if the resultant SNR through the node is any less than that there is room for improvement.

Once the SNR is consistently above 50-55dB with the node operating Full-Duplex it will sound very clear, with no background noise audible unless you are in a quiet room and turn the volume up fairly loud. At that point there can in some cases still be some faint digital noise, usually comprised of harmonics of 60Hz and 1KHz from power supply and USB connections. Even at a low level this can be somewhat distracting/annoying, even more so than quiet broadband white-noise that might be 10+dB louder. Thus whenever building a node I ensure all such noise is properly fixed, which can require a lot of testing and optimization but becomes easier once the SNRs, gains, and source and load impedances of the node components have been properly measured and characterized. If you usually use a node in a mobile or loud environment you would probably be just fine with a 30-40dB SNR, but for quieter home/office environments closer to 60dB is definitely preferable.

Node Management / Dashboard Apps

Installing AllMon and then Supermon is highly recommended. Supermon provides many system info and configuration functions and only takes about 5-10 minutes to install and configure. AllScan can then be installed in even less time and provides a Favorites Dashboard with integrated ASL Stats scanning. This makes it easy to add favorite nodes and see their Tx & Rx activity and Connected Link Count stats in real-time (typically 1-minute resolution). These apps can be used in any web browser.

AllScan Favorites Management & Dashboard Web App on a Netbook

Wi-Fi Support, Portability

Wired-internet is more reliable and easier to set up but for a portable node wireless connectivity is essential. USB WiFi adapters are inexpensive and fairly easy to set up if you have basic familiarity with Linux.

Many 3040's come with an internal WiFi card and antennas that work well. Otherwise a cheap USB WiFi adapter should work for short-range communication but I would recommend a reputable brand that's known to work well on Debian Linux and that has a proper antenna. With WiFi frequencies starting at 2.4GHz, a 1/4λ vertical antenna should be 3cm in length or for some gain you'd want 1/2λ or 5/8λ ie. 6-7cm antenna length. Any adapter that's smaller than that is probably not going to have good performance. The TP-Link "Archer T2U Plus AC600" look good and are < $20. I would suggest testing a few different models and seeing how their signal strength, jitter, packet loss, etc. are at different distances from your WiFi router.

If you use WiFi on a node you should have basic familiarity with Linux and configuring the various settings. Eventually some setting or driver may need to be updated or debugged. Like anything with computers this is not hard to do, just do a web search for what you want or what issue you're seeing and dozens of web pages with plenty of answers will usually come up.

Wi-Fi Setup for nodes with no Desktop GUI (Command-line Only)

This Article has detailed instructions on how to set up wifi on Debian. This process does require knowing the node's IP address (which can usually be found on your router management page) and initially connecting to the node through ethernet with an SSH app. This may not be easy to do on networks that you do not manage but there are ways to make that easier, for example you can set up a command in ASL to say the node's IP address in response to a DTMF command. On all nodes I ship I have DTMF commands *690 and *691 set up to say the node's LAN and WAN IP addresses. See the AllScan FaceBook Group for details on how to set up these commands, plus many other tips and updates.

Before configuring WiFi as described in the above article you may need to run the following steps: "sudo su", "apt install wireless-tools wpasupplicant", then run "iwconfig" and confirm a wireless interface is listed. On a Dell 3040 with internal wifi module this shows a wireless interface named "mlan0". You may then need to run "ifconfig mlan0 up" to start the interface. "iw mlan0 scan" should then list the available networks, or run "iw mlan0 scan | grep SSID" to see just the names.

After first setting up wifi on a 3040 I was seeing a lot of jitter and audio dropouts but after disconnecting the ethernet cable, restarting my wifi router and restarting the node, everything worked perfectly.

Another way to set up wifi on Debian is with iwd, which may be slightly simpler vs. the article above. See this Article for details.

Wi-Fi Setup for nodes with a Desktop GUI

To simplify wifi network management a desktop environment can be set up on the node such as Xfce or MATE along with a small ~11-15" LCD monitor and USB keyboard/trackpad – or use an inexpensive Netbook or small Laptop instead of a MiniPC. Connecting is then as simple as clicking on the network icon and selecting the wifi network.

If you often travel and connect to various wifi networks, using a small laptop or netbook for the node computer rather than a 3040 can make things much easier to manage. These are available for around the same price as 3040's which is a quite a deal considering they include an LCD, keyboard, trackpad and battery. I have used a small Asus netbook that came with Linux Mint preinstalled (was only $50 on ebay) that I set up with Debian 11 and ASL and it works perfectly. This makes for an innovative node product that in addition to being an AllStar node works as a regular laptop and runs 1,000's of free programs available on Linux supporting web browsing, office apps, graphics, audio, music, ham radio apps, etc. Small laptops are slightly more expensive but still < $100, and have a nicer keyboard, more I/Os, and better performance.

For my ANR100-LT nodes I use Dell E7440 laptops, which are easy to find for < $100, with 256GB SSD, charger and Win 10 Pro. They are really nice compact laptops with backlit keyboard, full HD LCD, and many hours of battery life. I then shrink the C drive by 65,535 MB and then run the ASL install USB, which installs Debian and ASL on the blank 64GB partition and automatically sets it up to dual-boot either OS, with Debian 10 and ASL as the default. ANR100-LT Demo Video

Full-Duplex Communication Benefits

In The Beginning...

In the beginning...there was CW. Most HF/CW/All-mode transceivers support full or semi break-in keying, meaning that the receiver is on between symbols/letters/words sent. Thus if someone is transmitting on a decent radio and making a reasonable attempt to monitor the frequency between characters or words, anyone can easily break in. Thus CW supports interactive, fluid conversation, and allows others to join a QSO or reply to a CQ at any time. CW can be considered semi-duplex because each dit and dash is only a couple 100mS and good radios can switch between Tx and Rx very quickly. Thus the receiver is never off for a significant time and it's easy to hear responses and other activity on the frequency.

And then there was AM, and soon after SSB which is much more energy-efficient and more widely used. Because SSB has no carrier there is no energy transmitted (or very little) during quiet parts ie. between words or during pauses. Experienced hams take advantage of this by briefly unkeying here and there, during pauses or maybe every other sentence, for enhanced awareness of the channel. This is a subtle technique that many aren't aware of. Some operators will just key up and talk for minutes straight, whereas more experienced OMs tend to keep things shorter and more interactive – just like in-person conversations. When you talk to someone in person you don't just talk for 3+ minutes straight at a time without ever pausing to allow someone to comment, acknowledge, reply, etc. And there's usually no good reason to do this on the ham bands, with some exceptions such as on nets. Thus while SSB is not generally full-duplex, experienced hams use it in an interactive way where they pay attention to what's happening on the frequency (as well as plus or minus a few KHz where there might be QRM or QRN that needs to be worked around), and as a result QSOs tend to be more dynamic and interesting.

And Then There Was FM

Next there was FM. FM sounds better than AM because of its better noise resistance, but it is less energy efficient than SSB due to having a constant power regardless of modulation level. And unlike SSB where you can unkey briefly with no audible effect, if you unkey on FM it results in squelch drops for listeners (unless their radio has unusually good squelch like an IC-9700 or they have tone squelch properly set up), thus there is a slight disincentive on FM to pay attention to the channel while you're transmitting.

Due to the FM capture effect, multiple people can't transmit at the same time or the signals interfere destructively or one covers up the other. With SSB that's not an issue and multiple signals combine linearly. One might be louder than the other or you might not be able to follow what either is saying very well but at least you'll be able to tell that there are 2 people talking, vs. FM doubling which can sound like a train wreck. Thus when FM first started being used on repeaters 60+ years ago it sounded great but also had some limitations that earlier modes did not.

As a side note, repeaters don't need to only use FM (or PSK digital equivalents). They could also support SSB without a huge amount of effort. Squelch would be a little more complicated because you don't have a constant carrier to reference, but DSP, signal analysis, noise reduction and AGC techniques have come a long way since the days of the first FM repeaters. It would not be hard to set up a repeater with separate FM and SSB inputs and repeat the audio on separate FM and SSB outputs. This would for the first time (that I know of) enable the advantages of SSB to be achieved on a repeater, namely SSB's inherent resistance to destructive interference and thus the ability to support multiple signals on a single frequency, and SSB's greater power efficiency that would reduce battery use for portable users or give more range with the same average power.

Before the Above There Was The Telephone

Originally repeaters and radios only supported half-duplex (from the user perspective). If you receive at the same time you're transmitting, from a repeater that has only one FM receiver, you're generally just going to hear yourself, or maybe a bunch of noise if someone doubles with you. Technically a repeater is full-duplex because it can transmit at the same time it's receiving, but that doesn't do you a lot of good (beyond the basic advantages that repeaters provide) if no more than 1 repeater user can transmit at the same time. Prior to ASL, only rarely did repeaters actually support true multi-user full-duplex communications. This is in contrast to phones which are multi-user full-duplex and always have been, which is much more natural and intuitive. Even the very oldest telephones from the 1800's were full-duplex. Apparently Thomas Edison and whoever else contributed to the early development of telephones figured out that it would be easier to just let people talk whenever they want with no limitations on how many people can talk at a time. This is easier to do on a pair of wires than over RF, but can be easily done on RF by using multiple bands/frequencies.

Multi-User Full-Duplex Repeaters

Most repeaters have only one FM receiver, which due to the FM capture effect can only properly receive one signal at a time, thus there was really no such thing as a repeater where any number of people could talk at any time while also hearing everyone else. To support that without ASL currently requires a repeater to have multiple receivers. Such systems do exist and work well for trivia nets or other scenarios with quick-witted hams jumping in with quick comments. San Diego's W6ZN repeater does this and there are numerous interlinked repeater systems with multiple inputs such as the SoCal DARN or PAPA systems where you can listen to one repeater on one mountain and transmit into a linked repeater on another mountain. ASL now makes it much easier for repeaters to support true multi-user full-duplex, as connected (radio-based) user nodes in fact extend the repeater with additional receivers and user-specific link monitoring transmitters (ie. that do not repeat local Rx audio).

And Then There Was The Internet

The Internet is essentially an extension of public telephone systems that had existed for a century before, with the major difference being packet-switching vs. circuit-switching. They both work for getting audio from one place to another regardless of if it's half-duplex or multi-user full-duplex. The internet does this in a general way with no limitations on the application layer which is a big improvement over the closed and proprietary phone system networks that have now become mostly obsolete.

And Finally There Was Asterisk and Then AllStarLink

Because ASL is based on Asterisk – a phone system, it supports full-duplex perfectly and makes it very simple. Even repeaters that have only one RF input, that would not ordinarily support multi-user full-duplex, if ASL-linked now support this capability by default for all AllStar users. I have tested this on many repeaters and it works just like a full-duplex phone call on a speakerphone. You talk just like you would on a simplex node but if someone else keys up you hear them and if someone doubles you hear it right away. Because you always hear the remote system, and if someone starts to double or there's echoes, timeouts, interference, etc. you can simply unkey until the repeater (or node / hub / bridge / etc.) is clear. This is a powerful feature that greatly improves the interactivity, efficiency and flexibility of amateur radio repeater communications. And it's an essential feature in emergency comms scenarios.

For those who have not used a full-duplex radio or node, or who do not intuitively understand how much of a difference it makes, a simple analogy is to consider what it would be like if the phone system was only half-duplex. Imagine that when calling a friend, relative, or business if only one person could talk at a time, no one could speak until the other person or people on the call unkeyed, and if when you then did key up to speak you couldn't be sure someone else hadn't keyed up at the same time. This would result in awkward and inefficient conversation because it would no longer be like real in-person communication. In contrast, full-duplex enables natural, smooth, effortless communication just like when you're standing right next to someone.

True Multi-User Full-Duplex

Although most people may not know it (even repeater owners), ASL-linked repeaters by default do support true Multi-User Full-Duplex. This is a subtle detail that can be hard to fully appreciate until you've tried it yourself. The repeater itself on analog will not support more than one analog RF input at a time if the repeater has only one RF receiver, but generally will support any number of simultaneous ASL full-duplex users and at least one analog RF input. There are a small number of improperly set up repeaters that don't support multi-user full-duplex but I only know of a few.

By default when a repeater links to ASL it will be with a node whose audio output gets mixed with the RF receiver audio input(s). Some repeaters may prioritize one over the other and only allow one audio channel at a time, or ASL may be linked through some intermediary interface, but even then multiple connected AllStar users can still be full-duplex and talk and hear each other fine, as that's a core feature of Asterisk's architecture. Audio streams from each connected node are always routed to all other connected nodes, no different than a VOIP conference call.

Some repeater system admins may opt to give RF Rx audio priority over AllStar Rx audio but there is no advantage to this and it only causes issues. For example if an RF user and an AllStar user key up at the same time the RF users on the repeater will hear only the RF user while AllStar users hear only the AllStar user, thus resulting in 2 separate conversations, which makes for quite a dysfunctional system. Such a phenomenon could be called "halfing" rather than "doubling", as it results in the communications topology being split into separate halves while both users are keyed up. Fortunately only a small number of repeaters seem to have this issue. If you should encounter such a system I suggest letting the admins know there is a better approach, ie. combine (mix) the Rx audio inputs rather than prioritize one over another.

Amateur vs. Professional

Go on any repeater net that has more than a half dozen or so users and you'll frequently hear doubles, echoing, etc. This wastes minutes of everyone's time and sounds "amateurish". Full-duplex solves these issues and gives you full situational awareness. This goes back to the definitions of "amateur" vs. "professional". "Amateur" just means we're not in it for money – not that we can't communicate well. Full-duplex gives you full real-time situational awareness – just like in the real world if you were right next to everyone in the QSO, and AllStar makes this so easy to do that there's no reason not to.

Situational Awareness

Another nice detail about full-duplex is that once you start transmitting from your cross-band full-duplex HT it's nice to see your node transmitting back to you right away. I can be over a mile away on an HT and start transmitting, its red Tx LED lights up, and then ~25mS later you see the green Rx LED light up which confirms that you're in range, the node is receiving you and transmitting back to you, no one is doubling with you, and you hear if there is any path noise. This is another example of how Full-Duplex improves overall situational awareness.

Radio Compatibility

Cross-band full-duplex nodes are fully compatible with half-duplex radios if they are dual-band dual-receive. For example a Kenwood TH-D74 I used to have won't do full-duplex but I had the node's 70cm Rx frequency on one memory channel and the 2m Tx frequency on the next memory channel, with dual-watch on and when I transmit the D74 will not receive at the same time but once you unkey you hear the node transmitter just fine. Thus any dual-band dual-receive radio can be used, which pretty much all modern HTs are.

Full-duplex nodes provide powerful benefits even if your other radios are only half-duplex. You can key up any time without having to wait for the node to unkey first, and if during a transmit you quickly unkey on a half-duplex radio you'll immediately hear what's on the remote system and can confirm that the channel is clear and no one is doubling with you then key up again. This is essentially the same technique mentioned above used by savvier hams on CW and SSB since the dawn of those modes, and makes checking into larger nets more efficient and enables large QSOs and nets to run more smoothly and interactively.

Full-Duplex Nodes vs. Repeaters

A Cross-Band Full-Duplex personal node (ie. that has duplex=3 in rpt.conf) does not repeat receive audio into the transmit audio. This is an important distinction and I do not recommend that this node design be used as a repeater or in a commercial application. A common misconception is that a full-duplex node is a repeater. This is not a valid assumption, and building a repeater is not the subject of this guide.

A full-duplex personal node can be used as a repeater (by setting duplex to 2 or 4 in rpt.conf), but that defeats one of the main benefits of a full-duplex personal AllStar node – the ability to hear audio from other connected nodes at all times without your own outgoing audio being repeated back, and thus no need to use a headset or headphones. This gives much better situational awareness and flexibility than a simplex node because if someone else keys up while you're talking you hear it right away and can then unkey thereby preventing a double, or you can both continue talking. In that case the conversation can work just like a good quality speakerphone. ASL is based on Asterisk – an enterprise-grade phone switch system that supports full-duplex by default for all users, thus anyone can key up with a quick comment or break any time. There are applications where a small low-cost portable repeater is useful though, such as if travelling with other hams to a remote area or field day site. For occasional repeater use this node design works well and provides all of ASL's features at a very reasonable cost. You can even add additional receivers (eg. $25 HTs) along with a simple audio mixer circuit to provide true multi-user full-duplex functionality.

Because the Tx audio is not repeated a personal node is generally limited to one RF user, in contrast to a repeater which can be shared by numerous users, but a personal node can be used by multiple RF users if they are all within simplex range of each other and thus can all hear each other's transmit audio. Cross-Band Full-Duplex (CBFD) radios also support dual-receive, thus when receiving you can monitor the node input and output frequencies at the same time. Thus if you have 10 ham friends within a few miles who all have CBFD radios, you can all use one CBFD personal node and hear all local RF users on the node input frequency and all ASL users on the node output frequency. This will not prevent doubles if 2 RF users key up at the same time, but that shouldn't be an issue if you use the node at different times or have only a few people using it at the same time who are careful to avoid doubles.

(Ideally a radio supporting CBFD could be set up with echo-cancellation DSP functionality, in which case any number of users could share a CBFD repeater node and each radio could subtract its transmit audio from the receive audio. Echo-cancellation is used in telephone and VOIP systems to help prevent echoing/feedback. No such radios currently exist, but it wouldn't be hard to build one. Maybe someday an open-source Linux-based HT product will be created that supports CDFD and runs GNU Radio or other SDR programs enabling DSP capabilities. This could be a very popular product as it could then also support other analog and digital modes and anyone could create their own software, DSP algorithms, codecs, etc. or even whole new analog, digital or hybrid modes.)

Repeaters are therefore full-duplex in a different way than full-duplex personal nodes – a Full-Duplex personal node supports one or a small number of nearby users, whereas a Repeater supports multiple users over a much larger area who usually have only half-duplex radios. A full-duplex radio (or 2 half-duplex radios) are commonly used with repeaters, particularly by net controllers, however in that case because the Tx audio is echoed back a headset or headphones usually need to be used to prevent feedback/echoing, and there also can be a delay in the repeated audio on some linked repeater systems which makes the full-duplex aspect from a user perspective not as user friendly as full-duplex on a speakerphone or full-duplex personal node.

Building a half-duplex node is slightly simpler and less expensive, but even if you do not yet fully understand or appreciate the advantages of full-duplex there is no disadvantage to supporting full-duplex and you will then have a higher-quality node that will be a better long-term investment.

Summary

There are no disadvantages to full-duplex other than slightly increased cost, which is a small price for all the above advantages. This node could be used half-duplex if desired though, just select the B band as the Main band on the radio and change the duplex settings in rpt.conf and usbradio.conf.

Kenwood TS-2000's are excellent All-Band All-Mode radios supporting Cross-Band Full-Duplex


Demo Video & Shootout with 7 Different Cross-Band Full-Duplex Radios


FAQs

Q: I like the idea of Full-Duplex but I have to wonder wouldn't I get a lot of feedback? When I use Full Duplex on satellites I need earbuds.

A: The great thing about Full-duplex on AllStar (with duplex=3 in rpt.conf, not 2 or 4 which is a repeater), is that it does NOT repeat your Tx audio into the Rx audio that goes back to you. Thus it's no different than talking on a speakerphone – you hear the other people on the call but it doesn't feed back your own audio. Because of this, Full-Duplex is actually much easier to use on AllStar than it is on satellites or non-ASL-linked repeaters.

Node Notes / Instructions

I provide the following notes with nodes I build and have included them here as they are useful notes regarding the general operation of any AllStar node.

  1. When you first plug in the node and connect an ethernet cable, it should be assigned a DHCP address by your router. If you look on the router's web admin page it should show a list of connected devices and the IP Address assigned to the node. You should then 'reserve' that address for the node there so the IP Address does not change later. The *690 DTMF command can also be used to have the node say its LAN IP address, or *691 for the WAN address.
  2. You'll also need to then forward port 4569 UDP&TCP in the router to the node. If this is not done you may get jittery audio or dropouts. (This assumes you do not already have another node on port 4569. Otherwise subsequent port#s should be used ie. 4570, 71...)
  3. If you will want to use AllMon/Supermon/AllScan from external networks you'll also need to forward port 80 TCP in the router to the node, or for portable nodes use a Dynamic DNS service.
  4. To access the node by SSH enter the node's IP Address in your SSH client, username=______ and password=______. This password should be changed. To do this, log into the node by SSH and type "passwd" and you will be prompted for a new password. Make sure not to lose that as there is no easy way to recover or reset it.
  5. AllMon, Supermon and AllScan are all installed and have the same login: username=______ password=______, and can be accessed by entering the node's IP or DDNS Address in your browser. This will open the AllMon index page which then has links to Supermon and AllScan. To update the AllMon password see this link. To update the Supermon password see this link. To update the AllScan password go to the Users page link.
  6. If the Dell 3040 has not been connected to power for awhile sometimes the power button has to be held in for 5-10 seconds and it may take a minute to then start up. Usually though a single click is all that's needed to turn it on or off.
  7. AllStar nodes can take several minutes after first being turned on to register with the ASL Network and for connections to remote nodes to then be accepted.
  8. The radio is set up to RX on 431.18 MHz and TX on 147.48 MHz, with a 127 Hz PL. This can be easily changed on the radio. Be sure to confirm that the frequencies are not being used by any repeaters or other reserved frequencies in your area.
  9. The mobile radio can be left off if using IAX/SIP apps instead of a radio.
  10. Because 5+ Watts of RF is a significant amount of RF power that can easily induce EMI/RFI on nearby electronics, it is highly recommended to use only a high-quality outdoor antenna that is at least 25 feet above ground, and at least 25 feet away from the node, from any other electronic devices, and from people and pets. This will also greatly increase range.
  11. RX and TX level adjustments can be made in the asl radio tune settings, by logging in by SSH and running "sudo /usr/sbin/simpleusb-tune-menu" if using simpleusb driver or "sudo /usr/sbin/radio-tune-menu" if using usbradio driver, then follow the prompts to adjust the level settings.
  12. You can check your audio using Parrot mode: Enter DTMF command *921 to enable, *922 to disable. (Be sure you're not connected to any other nodes when doing any testing.) N2DYI's Parrot Test Node 55553 can also be used.
  13. The audio levels on the node have been adjusted to good general levels, however your voice and your radio(s) you use may be louder or quieter than average and you may need to adjust the Rx gain accordingly. You can also adjust the Tx gain to your personal preference or to better match its audio levels with local FM repeaters.
  14. An extra ferrite filter is included in case you get noise/RFI on the node or in any other devices. This should not be needed but if you do get any noise try putting it on different cables to filter out noise and help locate the source(s).
  15. For nodes with wifi, it is generally recommended to use wired ethernet when available for best performance. In this case the wifi module should be turned off with the SSH command "ifconfig mlan0 down" or DTMF command *692, and can later be turned back on with the command "ifconfig mlan0 up" or DTMF command *693. The wifi will default to on when the node is next powered on or rebooted, unless this is changed in the networking settings.
  16. If you have questions on the node or settings be sure to review this guide, which is frequently updated.

Troubleshooting

If there is any noise on the node's transmit or receive audio these are some simple solutions:

  1. Check the power supply ripple, try different power supplies, and added ferrite filters. A snap-on ferrite core filter with 3-4 turns of the DC power cable around it is often helpful – as close to the power supply as possible.
  2. To prevent any possible ground loops, keep all wiring as short as possible and always run power and audio wires/cables in straight lines and next to each other rather than spread apart or in any shape resembling a loop. Also be sure to use only a star-ground configuration such that there is no more than one ground path between any 2 node components.

If you get distorted audio or stuttering/dropouts, or inbound connection attempts to your node do not work, make sure all your port settings match on the ASL site for both the server and the node, and that those match the port settings in iax.conf (bindport), rpt.conf ([node#] = radio@ip:port), in the node's firewall (iptables) configuration, and in the router/cable modem. This is 6 different places the port has to be set. If it's your first node then you probably have the default of 4569 and didn't need to change anything, but if it's not your first node then a different port number is required (eg. 4570, 4571, ...), and all 6 of those places need to have the same setting. The node can still appear to be working fine if those settings don't match but the audio will be more likely to have stuttering/dropouts.

Conclusion

My goal has been to find the simplest and most cost-effective ways to build a full-duplex node using only high-quality off-the-shelf components. I also build and sell fully assembled, configured and tested nodes. For more info send me an email. I usually have several nodes in stock or can custom build a node to your specifications usually within a few days.

Note for ebay users: Be sure to contact me (or any other ham radio equipment builder) directly before purchasing a node through ebay. Ebay fees are quite high and you can save 10-20% by ordering direct from a reputable seller and using no-fee payment services such as venmo or zelle.

Contact

For any questions, feedback or other enquiries email david at allscan.info. 73, David NR9V

−−··· ···−−

GitHub | Facebook Group | YouTube | AllStarLink.org | ASL Forum | eHam.net