How To - Build a High-Quality Full-Duplex AllStar Node for Under $150
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, support only half-duplex operation, and often have low audio quality. Or another common approach is to use old Motorola or similar mobile radios, which have good audio and RF performance but take up a lot of space and make inefficient use of power, putting out 5+ Watts of power when only a few 100mW is usually needed.

In some applications a small portable node such as a SHARI or HotSpotRadio node might work fine, if you already have a Raspberry Pi or can find one at a reasonable price. These are compact, portable, and can have good audio quality if properly designed, assembled and tested. For those who are new to AllStar this can be a good way to get familiar with AllStar and with the performance and limitations of a "starter" node. For mobile use portability is often the main priority, but even then there is no good reason to settle for limitations or any less than excellent performance.

After months of research and testing in late 2022 I developed the ANF101 design which is the most cost-effective, highest-performance full-duplex radio-based node available, using readily available FCC-certified components, that can be built by anyone with basic electronics skills. I have seen no previous mentions online of this having been done with excellent audio quality and RF performance, full-featured MiniPC, radio interface, node radios, power supplies and integrated enclosure for under $150 in materials costs.

AllScan ANF101 (w/Dell Wyse 3040, AllScan URI100 and 2 Retevis RT85 HTs)


Table of Contents

Introduction
Overview
  Background, History
  Using HTs for Node Radios
  Node Components
Parts List and Component Options
  Main Components
  USB Radio Interface
  Additional Required Components
  Recommended / Optional Components
  Enclosure Options
Setup Steps
  Debian & ASL Installation
  ASL Configuration
  Power Supply
  Wiring Notes
Setup Steps (continued)
  Radio Settings
  Ferrite Filters, Filter Capacitors
  Signal-To-Noise Ratio (SNR) Optimization
  Node Management
Design Overview
  FCC Compliance, RF Performance
  Audio Quality Notes
  WiFi Support, Portability
Full-Duplex Communication Benefits
FAQs / Notes / Instructions
Troubleshooting
Conclusion, Contact

Overview

Quick Demo Video


Top View of an ANF101 with a BH7NOR R1-ASL USB Radio Interface


The ANF101 has a total footprint of only 10"W x 3"D

ANF101 (older version) with Classic Cross-Band Full-Duplex HTs


From left to right Yaesu FT-530, Icom IC-W32A, Kenwood TH-D72A & Yaesu FT-51R

ANH100 Half-Duplex Node with TIDRADIO TD-H3 HT


This How-To Guide focuses on Full-Duplex Nodes and the numerous advantages full-duplex provides,
but for those who want to keep cost and size as small as possible it's very easy to build a
half-duplex node, which can be easily expanded to support full-duplex at any time.

The ANF101 can be built with different enclosure sizes, colors and materials. The AllScan URI200 USB Radio Interface has outstanding RFI-filtering and a shielded aluminum enclosure, and an ABS box can be used to enclose the power supplies and wiring. Or a metal box can be used which may further improve RFI resistance, but with proper placement of ferrites, proper wiring keeping all wire lengths as short as possible and a shielded URI enclosure the audio and RF performance should be excellent.

Background

I've been a ham since 1986, an Electrical Engineer since 1993, and a Software Engineer since 1997, but did not start using AllStar until mid-2022. I also have extensive experience in Audio Engineering, Recording and Pro-Audio. I discovered EchoLink in early 2022, and then soon heard that AllStar was a step up with higher audio quality, lower latency, and more features and flexibility. After a little research I found that the nodes on the market – both commercial nodes and DiY designs – were not well documented and lacked basic specifications such as Signal-to-Noise Ratio (SNR).

I bought a ClearNode in May '22 as it was a popular node with a useful phone app, and spent many hours on ASL-linked repeaters over the next few months. The Tx audio from the ClearNode had a noticeable digital whine noise but I didn't pay much attention to it. However, I kept hearing reports that there was a buzz on the outgoing audio. Finally a few months later I did some tests and found that its RF receive audio (which goes out to other nodes) was significantly noisier than its RF transmit audio (which only you hear), leading you to believe it sounds reasonably OK when in reality the outgoing audio had a very noticeable buzz and well under 30dB SNR. A high-quality node can deliver a SNR of 50–60dB, which is over 100 times higher than the ClearNode (10dB=10x higher, 20dB=100x, …). I emailed Node-Ventures in Sept. '22 and Gerry suggested a ferrite filter on the power supply cable, and moving the node around to different rooms, but nothing made any significant difference.

I then heard from another node maker who uses the SA818 RF Module that the ClearNode PCB design is known for being noisy and was not properly optimized with RF shielding and filtering. (Maybe Node-Ventures has fixed that now but I continue to hear the same buzz/whine on the signals of many ClearNode users.) I've heard that other nodes using the SA818 have done a better job, but by then I was much more familiar with AllStar & ASL and it was time to build my own node. I also wanted to try Full-Duplex on AllStar as I knew it would be a game-changing feature, and as I have always been an advocate of open-source software I did not want to continue to support any node makers who use closed-source software.

This How-To Guide thoroughly covers many design aspects and subtle details. Some of this can be found in bits and pieces on various websites, wikis, blogs, etc. going back 10+ years, but I've also made some significant optimizations that enable a full-featured node to be built that has no compromises in quality or functionality yet costs less than any other node on the market.

It's easy to skim through a lengthy document such as this and miss some of the subtleties or jump to conclusions, since "people weren't doing it that way before" or "ASL couldn't actually work that well". But any such conclusions would be unfounded. With my 30-year background in engineering, I would not propose a design to the ham community without first being sure it fully met my own (very high) standards. I encourage questions, am responsive to emails, and am active on a number of forums. I'm also fortunate to be able to spend a lot of time on ham radio projects. I created the AllScan Web App, contribute to the AllStarLink App-Rpt code, and have built and sold dozens of very nice 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, 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, support for a wide range of codecs, and extensive control and monitoring capabilities via web and IP interfaces, DTMF commands, scripting and macros.

An AllStar node is part of a comprehensive system of GigaBytes of software and millions of lines of code that make up Linux, Asterisk, ASL, Apache, PHP, SQLite, and 1,000's of other utilities and programs that come with Linux. 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, modify it or improve it.

Using HTs for Node Radios

ASL usually uses a Carrier Operated Squelch (COS) line or USBRadio driver DSP mode to determine when audio is being received. Most nicer mobile radios have a Mini-DIN-6 jack that provides COS and unfiltered discriminator audio outputs along with PTT and Tx audio inputs. For example if you take a Kenwood TM-V71A or Yaesu FT-8800R mobile radio, connect a standard USB Radio Interface (URI), and install Debian and ASL3 on an RPi or MiniPC, in less than an hour of work you'd have a very nice node supporting cross-band full-duplex with 5+W power output, which with a good outdoor antenna could have a range of 25+ miles. See my other How-To Guide for details on how to do this with a mobile radio.

ASL's USBRadio driver has a VOX mode that can detect the presence of Rx Audio automatically but this is far from perfect. If you have a quiet voice, the radio(s) you use to talk into the node have low mic gain, or if you would often use the node in a quiet environment and frequently pause when speaking, the "carrierfrom=vox" mode is not ideal. It is much better to use a TIDRADIO H3 which provide a hardware COS+CTCSS output. Or various other HTs such as an RT85 or UV-K5/K6 can be modified to add a hardware COS line. With as inexpensive and nice as the H3's are though there should be no reason to need to make hardware mods to anything. If modding some other HT, be sure to connect to the audio amp IC enable line rather than the Rx LED, to ensure the COS output reflects CTCSS validity. AllStar nodes should always use CTCSS or DCS tone squelch to ensure QRM/QRN will not key up the node.

Using HT(s) for the node also makes it very portable. With a small battery pack and wifi hotspot the node could be used anywhere. HTs don't need a separate antenna, duplexer or coax cables, and have lower power options than mobile radios. An HT transmitting Low power is usually plenty of power to cover within 1-2 miles, or 10+ miles on high power with a better antenna.

It's simple, practical, and cost-effective to use HTs for node radios. All HT models listed above use the same speaker/mic pinouts (K1) as Kenwood HTs and are easy to connect, with no resistors or other components needed. It's very cost-effective and practical to use a couple of cheap simple HTs for the node radios, and then use a nice FT-470, FT-530, FT-51R, TH-D72A, IC-W32A, DJ-G5, DJ-G7, etc. full-duplex HT to talk to the node. (See this Demo Video & Shootout with an ANF101 and 7 Cross-Band Full-Duplex Radios)

Node Components

There are several main pieces to an AllStar node:

  1. A computing device (ASL "server"). This can be a Raspberry Pi, any Intel/AMD PC or Mini/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). RPi's and many Mini PCs use only a few Watts of power.
  2. A radio/audio/GPIO 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 usually referred to as a URI (USB Radio Interface), or in the case of a radio-less node a UCI (USB Communications Interface).
  3. A node radio*. This is often built-in to Off-the-Shelf nodes as a small simplex radio module. However these modules may not have very good audio quality or RF specs. Real radios are definitely preferable, and are easier to configure and monitor through their front panel display, keyboard and LEDs.
  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 ~147 MHz and Rx on ~431 MHz, and your other radio would Rx on ~147 and Tx on ~431.

*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.

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. DVSM in Node Mode is a true AllStar node with its own ASL node number but with some major 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 can also be used. Because VOIP phones don't have a PTT button however it is necessary to dial *99 to key up and then # to unkey, which is not nearly as convenient as a real radio or PTT mic. 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. The node radio does not need to support full-duplex because separate HTs can easily be used eg. one for Rx on 70cm and one for Tx on 2m, but for other radios cross-band full-duplex is a very nice feature.

Parts List and Component Options

Main Components

There are a number of options for the Main Node components:

The Dell Wyse 3040 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 can also provide fully assembled and tested nodes.

For base-station or fixed location use ideally wired internet will be available. Use of wired ethernet results in simpler configuration and higher reliability.

USB Radio Interface

A number of URIs are available that use high-quality C-Media USB Audio I/O Controller ICs. However, most of them are not suitable for use in full-duplex HT-based nodes. Most are simple designs that do not implement proper digital and analog power supply and ground separation and that have very little I/O RFI/EMI filtering and isolation. These usually work fine in simplex nodes but can have significant noise, hums, whines, buzzes, clicks, feedback, etc. on the audio when used in a full-duplex node where the node TX HT is transmitting 1+ Watt less than 1' away from the URI.

RF field strength near ground level is generally proportional to transmit power divided by the square of distance from the antenna, thus an HT transmitting 1 Watt less than a foot away from a URI can result in much higher field strength than a 100+ Watt repeater with an antenna 50 feet from the URI. Now add an additional HT (used to talk into the node) into the equation and you have 2 strong nearby signals combining in complex ways in every nearby wire, cable, and conductive surface.

Full-duplex nodes using HTs have higher RFI & EMI than just about any other type of node. Intuitively it might seem that a mobile radio or repeater would present a more difficult RFI environment due to their higher power output, but in reality mobile radios are usually used with an antenna that is 25+' away and repeaters usually have an antenna that is 50+' away on a tower and that tends to have a narrow and well controlled radiation pattern to the horizon. Thus 1 Watt from an HT 1' away from the URI can result in significantly higher RF field strength at the URI than is the case with mobile or base radios or repeaters.

Before reading further it's important to understand why Full-Duplex nodes are better than simplex nodes and why a little extra time and effort to support Full-Duplex is a good investment. This is discussed in detail in the Full-Duplex Communication Benefits section below. Despite these clear advantages, most hams don't really "get" what a full-duplex node is, and even AllStar "experts" often have no familiarity with the concept or jump to the conclusion that you're talking about a repeater, but to be clear, a full-duplex personal node is not a repeater and does not repeat Rx audio into Tx audio. The purpose of full-duplex in a personal node is to enable you to hear what's happening on other nodes you're connected to at all times – not to echo your own audio back to you. ie. you can can always hear everyone else, and your node can always hear you.

CM108 USB Sound "Fobs" are less than $10 but require extensive modifications to provide proper RFI filtering, and even then will not work nearly as well as a URI that has been properly designed to support operation in a full-duplex HT-based node. There are a number of URIs made by Repeater-Builder, Kits 4 Hams, Masters Comms and Digirig that all have a similar basic design and do not work well in this type of very-high RFI/EMI environment. I have used and extensively tested many of these and some of them can work well with careful optimization of ferrites, cables/wiring, grounding, shielding, etc. but they are not a simple plug-and-play solution for this application. BH7NOR R1 URIs have good RFI filtering and I/O isolation and are only about $50 but do require some modifications and do not have the same level of flexibility or the same level of immunity to RFI-induced USB & power supply noise as the AllScan URI100 or URI150.


AllScan URI100

AllScan URI150

The CM1xx-series ~45dB mixer gain range supports HTs 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.

BH7NOR R1 URIs are compact, inexpensive, include an extruded aluminum enclosure, and have fairly thorough RFI filtering & isolation. 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 CM108AH IC pin 38 (MSEL) and leave unconnected for proper support of ASL's txmix level settings

AllScan URIs incorporate very thorough RFI/EMI filtering, I/O isolation and analog & digital power supply and ground separation. The URI150 and URI200 additionally provide audio isolation transformers and extensive configuration options supporting just about any possible grounding configuration and a wide range of audio I/O levels and impedances. As a result AllScan URIs are without exaggeration far superior to every other URI in existence, both in price and performance. Since first building a full-duplex node in 2022 I have invested many 100's of hours into R&D with the goal of creating a URI that supports full-duplex nodes with a simple, reliable, true plug & play solution that delivers uncompromising audio quality with 55+dB SNR, with zero added noise, buzzes, etc. AllScan URIs have now finally solved those issues once and for all. Despite their small size (~2"x2"), the URI100 and URI110 are professional-grade products that can handle 99% of AllStar applications better than anything else available.

The URI150 is specifically customized for use with full-duplex HT nodes and provides a built-in high-efficiency step-down regulator to power the HTs. This enables the ANF101 to be powered from a single 9-15VDC supply that then powers the Mini PC and HTs.

 

RFI/Noise Optimization

URIs that do not come with a metal case should be put inside a small aluminum enclosure to improve RFI resistance, protect the PCB from possible damage, and simplify the node appearance.

All cables should be as short as possible, and ferrite beads (such as Fair-Rite 2743002112's, or ~22x14x13mm ferrite rings (link)) should be added to the USB cable and the cables going to the HTs. The URI enclosure should be grounded, which can be done with a short ground wire from the aluminum mounting plate and HT power supply ground to a nut, bolt and star washer on the enclosure or to a ground pad on the URI PCB.

I do not recommend the use of Raspberry Pi's for AllStar nodes, and especially not for full-duplex nodes in high-RFI environments, as they do not have the same level of RFI/EMC performance as properly integrated and certified MiniPCs, and lack basic features such as a power button and built-in eMMC. RPi's were a good option 5 or 10 years ago but are now far inferior to Mini PCs in terms of cost, performance, features and reliability.

The URI and its enclosure should be directly connected to Ground, whereas the MiniPC and its power supply should not be connected to Ground or should have ferrites on the power and USB cables with at least 3 turns of each cable around each ferrite.

Additional Required Components

2.5mm & 3.5mm cables are included with AllScan URI's or can be easily found online. Right-angle cables save space and reduce the likelihood of damage due to the node being bumped or dropped. A 2.5mm cable is not usually needed for the Tx HT as a Ground connection is already provided by its power supply ground wire.

Some basic wiring (such as 24 ga. Hookup wire) is then needed to connect the above together. If you plan to leave the node in one place such as on a shelf or in a closet then you might not need an enclosure, but I recommend mounting the MiniPC, URI and HTs on a ~10"W x 4.5"H aluminum mounting plate.

I've built many full-duplex radio-based nodes, some with metal enclosures and some with plastic enclosures and after various (sometimes major) optimizations have got them all working well, however the ones in metal enclosures have usually had fewer noise issues needing to be debugged and optimized. Having ferrite filters on all cables is the most important thing. The ferrites should be placed as close to the node end of the cable as possible. Each cable should have 2-4 turns around a ferrite core. With the Tx HT putting out 1+ Watts of RF energy just inches away, any wire or cable longer than a couple inches that does not have a ferrite filter or is not fully enclosed in a shielded enclosure will act like an antenna and conduct RF into the node electronics, which can cause noisy audio and other issues.

Recommended / Optional Components

If using a Beelink T5 Mini PC and AllScan URI150, everything will run from a single 12V power supply, the URI150 provides a power switch for the radios and no additional enclosure is needed. In older designs I used a ~6"x4"x2" enclosure to hold the MiniPC and HT power supplies along with an AC power inlet and switch. And if using a TIDRADIO H3 w/nicFw those have a very wide output power adjustment range and no attenuator is needed. Thus with this setup none of the below items are needed other than a mounting plate. There are many different ways to build nodes so you may not need any of the below or may have other various items that will work.

For best performance a 6.3" x 4.1" x 2.1" aluminum enclosure (link) can be used for the power supplies instead of the above ABS enclosure but this adds about $20 to the cost and is more difficult to fabricate.

Alternatively a larger enclosure with no mounting plate could be used with the HTs mounted on the sides, or a longer box could be used with the HTs on the front, ideally 10" x 4.5" x 1.75", but this is not a common size. Off-the-shelf boxes/enclosures in longer lengths tend to also have larger widths/depths.

Amazon and ebay have pretty much everything needed at good prices. Traditional electronics suppliers like Mouser and DigiKey are really only needed for more specialized components or where quality is important.

Enclosure Options

Die-cast or extruded aluminum enclosures are essentially indestructible and have a nice "industrial" look. ABS, polycarbonate, or other plastic enclosures are also very durable, cost less and are a little easier to cut and drill. RFI can be more likely to occur with non-metallic enclosures thus I would generally recommend going with aluminum, particularly for the URI. Steel can work also but is harder to cut and drill. Black enclosures match the RT85s and give a more professional look. Aluminum boxes are available anodized, painted or powder-coated for a small additional cost.

Optimizing/fixing RFI/noise issues can vary significantly from node-to-node, sometimes requiring significant debugging. I do recommend using a metal mounting plate as this provides a nice solid ground plane that will help shield nearby cables and components. With a 10"x4.5" metal mounting plate, which has a nut, bolt, star washer and ground lug near the IEC inlet, the power cord ground wire and metal plate provide a ground plane that can help minimize RFI. The HT power supply ground and URI ground should also go to the ground lug.

At VHF and lower frequencies where wavelengths are relatively long, RFI 99% of the time comes in on cables/wires rather than being directly induced on PC Boards or components. A metal enclosure won't help if there are long cables that don't have appropriate grounding and ferrite filters. RFI in VHF/UHF nodes is more likely to be solved by keeping all cables as short as possible, using ferrite cores where needed, and avoiding ground loops by using a star ground configuration.

My local Industrial Metal Supply cut 10 mounting plates from 0.040" black painted aluminum for about $6 ea, though they are black on one side only and thus look a little nicer if spray painted black on the back. I plan to get some custom fabricated enclosures at some point that will be nicely finished with all needed mounting holes pre-drilled and cut. These should look great and save easily 1-2 hours of time per node in cutting, drilling, rounding corners, filing edges and painting.

For optimal portability and durability the node components should be mounted in/on an enclosure such as a project box, mounting plate, rack shelf, or a clear plastic carry case. Optionally all components can be mounted inside (as opposed to on) an enclosure or case. By setting up the MiniPC BIOS to turn On by default after power is applied, and because the RT85's have a regular analog volume knob with on/off switch, no access is needed to the PC or radios once they have been configured. It's preferable to have these easily accessible and clearly visible, but if the node will often be taken portable in harsh environments it's probably better for the PC and HTs to be inside an enclosure. With this approach however a cooling fan and some ventilation slots would likely be needed to prevent heat buildup.

Clear visibility of the PC, HTs, and radio interface is important. Sometimes things happen on AllStar such as disconnects or timeouts and it's nice to be able to look at the node and be able to see the HT LCDs & LEDs and the URI LEDs.

Using right-angle 2.5mm & 3.5mm plugs to go into the HTs greatly reduces the amount of space they take up. Everything then fits nicely on a 10" x 4.5" mounting plate. With everything on a mounting plate the MiniPC can be turned on and off with its power switch, a separate power switch for the HTs can be used, and the node is then easier to use and more portable, with total dimensions as small as 10" x 3" x 5".

Aluminum or powder-coated steel for the mounting plate and/or enclosure ensures maximum durability and reduced chance of RFI while also not being flammable like most plastic materials.

For portable applications a small battery and charger could be included in the enclosure allowing the node to work anywhere that WiFi is available.

Ideally the MiniPC used will run on the same voltage as the HTs, in which case one 7.5V 3A power supply can power everything. This can save significant space and allow the node to be powered from a single AC wall adapter or from a 12VDC input with step-down regulator(s).

The URI150 and URI200 are a big step in the direction of creating a true plug & play solution that works as it should without the issues that commonly occur with other URIs in high-RFI environments. The URI150 further simplifies builds by providing power for the HTs and MiniPC from a 12VDC power input. I hope to also soon make available a prefabricated mounting plate that the HTs, MiniPC, and URI150 can quickly attach to, but until then it can take a little thought and experimentation to arrange the various pieces in the most space-efficient way.

Setup Steps

Dell Wyse 3040 MiniPC

Installing ASL3 on a Dell 3040, other Mini PC, or Laptop/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 amd64 ISO from debian.org/CD/netinst/, then format the USB drive as FAT32 and unzip the ISO into the root folder (7-Zip is a good program for unzipping ISOs). Do not try to make the USB drive "legacy bootable".

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 maybe it has fewer options and thus is more resistant to user error.

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, and plug in the Debian 12 USB drive. Power up the 3040 and when you see the Dell logo hit F2 to enter BIOS setup. 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: Thorough
Virtualization Support: Disabled

Nothing should need to be changed on the boot order page or any 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 Debian installer menu will then appear.

The Debian net install image is intended to boot on a removable device and install Debian on an internal storage device (or on a separate removable USB drive / SD Card). This differs from the RPi "appliance" image which goes on an SD Card, into the RPi, and the install is done. The Debian install takes about 20 minutes to complete. The default options should be fine but if there is anything you are not sure about, do a web search from another computer and try to clarify any questions you have.

The ASL2 image did not have the boot file where 3040's need it to be (/boot/efi/...), requiring an extra step to copy the boot file, but fortunately the Debian 12 installer provides this option.

I recommend the "high-contrast", "advanced" install option as it seems to better explain each step and not skip any potentially important details.

Installing on other Thin Client models or on a Netbook or Laptop should be even easier. (Note however that Chromebooks should be avoided, as ChromeOS is a closed and encumbered platform.)

A Desktop Environment such as MATE is a nice addition if you have a monitor, TV, or remote desktop app. This will greatly simplify wifi and wired network management but does require a 16GB 3040 version to fit everything.

Beelink T5 or GMKtek NucBox5 MiniPCs

Installing Debian on a Beelink T5, GMKtek NucBox, or other similar recent Mini PC model is simple. First, make a UEFI USB drive by downloading the amd64 ISO from debian.org/CD/netinst/, then format the USB drive as FAT32 and unzip the ISO into the root folder (7-Zip is a good program for unzipping ISOs). Do not try to make the USB drive "legacy bootable".

Plug in a USB keyboard and a monitor/TV with HDMI cable into the MiniPC. Many Mini PCs include Windows 11. If you want to keep Windows you will want to let it boot and update itself (which can take over an hour) and then use the Windows Disk Management tool to shrink the C drive by 50%, ie. for a Mini PC with 128GB eMMC/SSD, shrink it by 65,535KB, thereby leaving 64GB of unallocated space, or for a mini PC with 64GB eMMC shrink the C drive by 32,767KB. When setting up Win11 I recommend during the setup specifying that the PC will be used for "work". There is no need to create a Microsoft account. In reality it is unlikely you'd ever have any need for Windows on a node MiniPC, and with the 1+ hours of time it takes a new Win 11 install to update itself, keeping Windows is probably not worth the time and hassle.

I recommend disabling all unnecessary options in the MiniPC BIOS, including Secure Boot, TPM module, Wake on LAN, Virtualization, Network/PXE boot, and legacy device support. Then power off the MiniPC, plug in the Debian 12 USB drive, press the power button and you will see the Debian installer menu. The Debian install takes about 10 minutes to complete. The default options should be fine but if there is anything you are not sure about do a web search from another computer to clarify any questions. I recommend the "high-contrast", "advanced" install option.

ASL3 Install

When the Debian install completes you will be prompted to remove the USB drive and power cycle the PC. Make sure it boots OK into Debian. The "hostname --all-ip-addresses" command can then be used to get the node's LAN IP address. You can then SSH into the node, proceed with the ASL3 install as described in the ASL3 Manual, and provision it on the allstarlink.org Web Portal.

ASL Configuration

ASL3 was released in July 2024 and is a major release that brings Debian and Asterisk up to the latest versions and makes other significant improvements. Asl-menu can be used to make some of the initial node configuration settings but the .conf files still need to be manually reviewed and edited as described below.

This node design can be used with either hardware COS or with USBRadio's carrierfrom=vox mode. Each has its advantages. Adding a COS line to the RX RT85 has an advantage of ensuring reliable RX Carrier Detection even if a node is used in a quiet environment while you talk quietly or with frequent long pauses. And with a hardware COS line the SimpleUSB driver can be used, which is a little simpler to set up. Hardware COS can also have issues though. On all HTs I have seen Tone Squelch will prevent audio from being heard if the transmitter does not have the correct PL Tone but it will not prevent the radio's RX LED from lighting up, thus any mod to obtain COS from an RX LED will result in a COS line that will be triggered by any received signal even if there's no PL tone. This could be an issue in areas with a lot of RF activity or if using a higher gain outdoor antenna.

The USBRadio carrierfrom=vox mode is thus a better solution for the case of ensuring the node cannot be unintentionally keyed by received noise or other signals not having the correct PL tone. Some mobile radios that provide COS eg. on a Mini-DIN-6 connector do have a cfg setting allowing COS to properly follow Tone Squelch rather than just Rx Busy. And some have an unfiltered discriminator audio out that supports CTCSS decode in ASL.

Thus for an HT-based node there is a tradeoff between hardware COS not being able to prevent signals with no PL tone from keying the node, vs. USBRadio's vox mode carrier detect not being perfect in situations where input audio levels are very quiet. If you like to talk quietly with a lot of long pauses, hardware COS is probably better, but to be sure the node won't be keyed up by signals not having a PL tone, USBRadio carrierfrom=vox mode may be better. For 100% reliable COS and Tone Squelch a mobile radio could be used for UHF receive that has a data connector providing "flat" unfiltered discriminator audio. Used for receive only this would have low current draw, and some smaller mobiles are very compact. However mobile radios that have a discriminator output can be significantly more expensive or may require special programming software.

Tests I ran on a 3040 doing a full-duplex parrot test showed that the SimpleUSB driver and USBRadio driver in various carrierfrom modes all use about 10% total CPU, thus there should be plenty of headroom on a 3040 and no significant difference in CPU use between SimpleUSB and USBRadio.

Note that Usbradio in most carrierfrom modes hard-limits outgoing IAX audio which results in a significant reduction in overall dynamic range and loudness. I confirmed this using the iaxRpt PC app recording directly (software loopback) into Audacity. Thus I recommend using the SimpleUSB driver if possible as this transmits the Rx audio over IAX exactly as it came in from the ADC. Usbradio's limiting could be useful if it was more flexible but there seems to be no option for makeup gain thus all audio is limited to <~-10dBFS, thereby resulting in up to 5 or 10 dB of lost dynamic range.

rpt.conf Recommended Settings

rxchannel = Radio/[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

NOTE: The ASL3 asl-menu utility has an issue where it does not provide a clear option for setting duplex to 3. Be sure to manually edit rpt.conf, find all lines that start with "duplex=" and make sure they set duplex=3.

*In ASL3 there may be 2 rxchannel lines, one with dahdi/pseudo and the 2nd with Radio/[node#]. Those lines should not need to be manually edited. The ASL Menu Utility (run "sudo asl-menu" on the command line) should be used for initial node setup to set your node#, node password, IAX port number, AMI password, and channel driver.

simpleusb.conf Recommended Settings

If you have a hardware COS line from the RX HT then use the SimpleUSB driver and make sure to update the rxchannel setting in rpt.conf accordingly and load the SimpleUSB driver instead of the USBRadio driver in modules.conf. 

rxboost = 0
carrierfrom = usbinvert
ctcssfrom = no
plfilter = no
txmixa = voice
txmixb = no
duplex = 1                ; ASL2/HV only, not needed in ASL3
clipledgpio = 1           ; Supports ADC Clip LED
legacyaudioscaling = no

USBRadio.conf Recommended Settings

USBRadio Driver is not recommended for HT nodes, unless you have no way to access a COS+CTCSS line and need VOX functionality, or if you have an HT that can provide flat (preemphasized) audio in which case USBRadio DSP mode can be used. VOX mode settings are shown below: 
rxboost = 0
rxctcssoverride = 1
carrierfrom = vox
voxhangtime = 500
ctcssfrom = no
rxdemod = speaker
txprelim = no
txlimonly = no
txtoctype = no
txmixa = voice
txmixb = no
rxlpf = 2
rxhpf = 1
txlpf = 1
txhpf = 1
duplex = 1
clipledgpio = 1           ; Supports ADC Clip LED
legacyaudioscaling = no

Updating ASL

Be sure to review the ASL3 Manual and follow the recommended steps to periodically update Debian and ASL. After setting up any node I recommend checking the system logfile (in Debian 12 use "sudo journalctl", otherwise use "sudo tail -n 500 /var/log/syslog") periodically to make sure there are no error messages shown during system boot and normal operation. If you see an error (for which a web search of the message does not reveal a simple fix) check the ASL Forum to see if it has been reported, and if not I suggest making a new post.

Backups

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

Power Supply

Most HTs need a well-filtered DC power supply, as they're designed to run primarily on battery power and probably don't have much if any filtering or regulation. HTs will run much cooler on 7-8V and should not be run any higher than that for high duty cycle node TX. It's easy to find inexpensive DC power supplies (~$10) or step-down regulators (~$5) on ebay that have a variable voltage regulator IC, filter capacitors, and terminal block connections. A larger filter cap eg. 2200+uF can further reduce any power supply ripple/switching noise. HTs can be run on their included batteries but for a node that will be transmitting a lot it's better to not constantly charge and discharge them or have the battery die during a longer QSO or net. If you already have a 12V battery system, that could provide plenty of clean power, but HTs can overheat if run at high duty cycle on 12+V (even if on the low power setting) thus a step-down regulator / DC-DC converter should then be used.

Power to the radios is best provided by a small switch-mode power supply. AC adapters have come a long way, they used to have only a transformer, rectifier and small filter cap providing unregulated output with a lot of ripple which can easily cause 60Hz hum if used to directly power an HT, but now have good regulation and go through EMC certification processes. Some switching supplies can cause RFI (birdies) in the HF bands on harmonics of the switching frequency (typically 100KHz or as high as 1MHz) but if you confirm that's not an issue for a specific adapter you'll then have a clean, inexpensive, compact and energy-efficient power source. Adding a ferrite filter and filter capacitor will ensure even lower noise.

My measurements of the RT85's show that at 7.5V they have the following Current Draw & Power Output: 

Off: 3mA
Standby: 100mA
Low Power: 475mA ~1.5W
Mid Power: 906mA ~2.8W
Hi Power: 1020mA ~3.7W

A 7.5V DC 2A power supply thus easily accommodates 1 HT in receive and 1 HT transmitting low power, with plenty of margin. Note that a node Tx radio should only be used on Low transmit power because of the high Tx duty cycle. The RT85's Low power setting is already significantly higher than most HTs (1500mW vs. more like 500mW on most other HTs or as little as 100mW on HTs with an Extremely Low power setting). These power supplies are widely available on ebay/amazon for as little as $6. I've tested several models and they have all worked well, but ideally a 2200+uF capacitor should be added which will reduce any remaining ripple to < 1mV. Because switching-supplies switch at a high frequency there should be little or no 60Hz harmonics on the output and large filter capacitors should not be needed but some additional small capacitance is good to eliminate any remaining switching noise. Switching supplies are used with many devices such as internet routers and other electronics and they do not seem to cause any RFI issues at my QTH. But be sure to test any power supply for RFI issues as every situation can be different and just one poorly designed power supply in your house or even in a nearby neighbor's house could affect your HF and VHF noise levels.

The power adapters can be placed on the back of the node thereby keeping them out of the way and organized. And a metal or heavy-duty plastic enclosure for the power wiring and components provides a support base to anchor things to and enables the node to stand solidly upright.

Note for hams in areas with 100V/220V/240V mains voltage: Most of the AC-DC adapters I use are autoranging adapters that will work on 100-240VAC automatically with no adjustments necessary. The nodes I build have the adapters in an enclosure with IEC C13 power inlet, thus you'd need to provide only a standard power cord going from an IEC C14 plug to the type of wall plug you use. There are a variety of adapters that can come with the 3040's, so you'd want to confirm with me before ordering but I should usually have at least one in stock that supports 100-240V, and the HT power adapters I use all support 100-240V.

Wiring Notes

For the power wires I solder 2 24 ga. wires onto the battery contacts on the back of the radios. Just pre-tin the wires and the contacts and the wires can then be tacked on in less than a second, and can be easily removed later if need be.

The node ideally should have either one AC power cord or one 12VDC power cord that connects to the power supplies for the PC and HTs. The node can easily run on 100–240VAC or 9–16VDC. To run it on 12V use DC-DC converters instead of AC-DC adapters, which are widely available for < $2 ea., and a 5.5x2.1mm DC Power Jack instead of an IEC inlet. Dell Wyse 3040's are often available on ebay without AC adapters at a significant discount.

The above details will result in a nicely-integrated node, with a single power cord and separate power switch for the HTs, that's easy to access, power on/off, change radio settings, etc., with the mini-PC and HTs fully visible and well ventilated. (Many past designs have opted to hide things in a box, which results in overheating and thus reduced component lifetimes, while making it harder to see what the node is doing or requiring additional wiring and components to bring additional LEDs or connectors to the exterior of the box.)

Radio Interface Cable Wiring

Wiring - AllScan URI150/URI200 to Kenwood, Retevis, TYT, QRZ, etc. HTs

AllScan URIs have K1 2.5mm and 3.5mm jacks enabling standard TRS cables to be used with no need to splice or solder anything. I have a variety of these cables in stock in short lengths and with right-angle plugs or these can be easily found on amazon, ebay or aliexpress. Lengths of 12-18" are usually good and provide plenty of length to wrap 2-3 times around a ferrite core. Coiled cables are also nice and the coil inductance can help reduce RFI.

For other URIs making cables to go to the HT 2.5mm and 3.5mm plugs can take a little effort for professional-looking results, but with a decent soldering iron (such as this) and a stereo microscope it's easy to do.

Wiring - R1-ASL/202x to Kenwood, Retevis, TYT, QRZ, etc. HTs

Mini-DIN-6 Pin 1 --- TX HT 3.5mm Ring (Tx Audio)
Mini-DIN-6 Pin 2 --- RX HT 2.5mm Sleeve (Ground), Node Ground
Mini-DIN-6 Pin 3 --- TX HT 3.5mm Sleeve (PTT)
Mini-DIN-6 Pin 5 --- RX HT 2.5mm Tip (Rx Audio)
Mini-DIN-6 Pin 6 --- RX HT 2.5mm Ring (COS) (optional)

Radio Settings

Be sure to set up the node radios with CTCSS Tone Squelch enabled, to prevent possible QRM from causing the node to transmit. 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.

A general note on tone squelch settings, Yaesu HTs (FT-530, FT5D) have very good squelch that drops quickly (maybe ~20mS max) and quietly, and Icom 9700s are even faster with basically no squelch tail at all, but the Kenwood TH-D72A is not so quick and has a much more noticeable squelch tail, more like 50-100+mS and fairly loud. Therefore I enable Tone Encode on the node TX HT and Tone Squelch on my other radios to minimize squelch tails after the node unkeys. The D72 then drops squelch immediately ie. no squelch tail at all. The FT-530 doesn't drop squelch any faster with Tone Squelch on but that's fine as the tail was already short and quiet. DCS can be used instead of CTCSS and seems better for Squelch Tail Elimination (STE) however as there are very few recent HT models that support Cross-Band Full-Duplex I am not aware of any HTs that properly support DCS and full-duplex. The Alinco DJ-G7 may be the only one that does but it has a limitation that it can do DCS on only one band at a time. The Yaesu FT-51R and Icom IC-W32A are currently my favorite HTs for use with full-duplex nodes. I do not recommend the TH-D72 as it's pretty noisy in duplex mode.

Important Note: Nodes can run at a 100% Tx duty cycle during nets or long QSOs, HTs don't have fans built in, and even at the lowest power setting HTs can get very hot if run at a higher voltage such as 12V, but will stay MUCH cooler at a lower voltage. One node I built used a Yaesu FT-530 for the node radio which will run on anything from 6 to 16 Volts but to minimize voltage across the final I run it on 6-7V, and it barely even gets warm at 100% Tx duty cycle. Transmitters typically have an RF final output transistor operating linearly between Vcc and Ground and thus even at the lowest power setting the transistor is dissipating the majority of the voltage across it. Therefore reducing Vcc to the minimum necessary will greatly reduce the heat dissipation and energy use of the radio. RT85's should not be run on 12V, but when run on 7.5V can transmit 1.5 Watts for hours without getting significantly above ambient air temperature. There is a common misconception that HTs cannot be run at a high Tx duty cycle but that is not at all true on any HT I have ever tested when an appropriate voltage is used.

Ferrite Filters, Filter Capacitors

Ferrite cores are needed on at least some of the 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 of these is recommended on the cable from the HT power supply, and may be needed on other cables depending on your specific setup and RF environment. 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 rectifier 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 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. Ferrite filters placed appropriately can reduce this by 99+%.

As a general recommendation for any node, the output ripple of any power supply, converter or regulator should be < 1mV AC, and at least 2200uF of low-impedance capacitance should be added to the power supply output to achieve that, and a few turns of the DC power cable should be wrapped around a ferrite core as close to the power supply case as possible.

Ferrite filters are also often needed on the AC power and ethernet cables going to the node, placed as close to the node as possible. Otherwise these long cables (which are 2+m in length) will act like antennas that strongly pick up the 2m Tx RF resulting in very high RFI levels into the power supplies and Mini PC.

A ferrite filter was definitely needed with my RPi node on the USB cable going to the audio interface, 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. Thus 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.

A ferrite core will likely be needed on the RX and TX audio cables, but sometimes neither is needed depending on the cable lengths, routing, shielding, etc. In general the more ferrites the better. A ferrite on the Tx audio cable is usually needed. Particularly if you're listening to a node on an SDR with full audio bandwidth and no deemphasis, which will reveal much more detail than a normal radio that filters to ~ 300Hz - 3KHz. An SDR can thus help to even further reduce quiet noise that wouldn't be audible on a normal radio. In total 4 or 5 ferrite cores will probably be needed. The Dell 3040's supply probably won't need one but the HT power supply most likely will. The same would probably apply to a node that runs off 12V using switching DC-DC converters.

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, additional filtering/regulation on your DC power supplies, 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 antennas as far as possible from other electronic devices is also generally a good idea.

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 usually not that simple. Achieving a more general design approach that is highly resistant to noise or any other issues in the widest range of conditions is an ongoing R&D process. Consistently getting 55+dB SNR through the whole Rx + Tx signal chain on a node is not easy – especially on a full-duplex node. Noise can be induced in the RX HT, TX HT, URI, or on any cabling in-between. But once proper testing and optimization have been done the result can be indistinguishable from even the best Analog FM repeater systems.

This document started as a quick How-To Guide but has become quite lengthy, providing a lot of info on building a node but also illustrating that it is in fact not easy to build a truly high-quality full-duplex node that's also compact and inexpensive. I'd generally not recommend this type of project for those who are not skilled in electronics, but if you have the time and patience, the best way to learn about AllStar, RF, computers and electronics is to build things and debug and optimize them until they work very well with no compromises.

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 and URIs, 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).

I then in 2024 developed the AllScan URI100 and URI200, incorporating the above along with 30+ years of my previous electrical engineering and pro audio experience, and the latest and most cost-effective manufacturing processes, resulting in the highest performing, most cost-effective and compact URIs available anywhere.

Full-duplex nodes are more of a challenge to minimize noise on because one RT85 is transmitting 1.5W in Low power (on 2m) while the Rx RT85 is less than a foot away (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

It was a nice surprise to find that the RT85s have 60dB of Tx SNR. This is ~10dB higher than 5 other radios I tested. (This test requires the mic gain to be set to 0 or input shorted since we are looking for the Tx audio noise floor). This is very impressive for a $20 HT. 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.

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 with Repeater-Builder RIM-LiteV2 interface). Because the RT85's are capable of 60dB SNR 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 you have properly measured and characterized the SNRs, gains, and source and load impedances of all the node components. 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

Installing AllMon and then AllScan is highly recommended. AllScan 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

Design Overview

Asterisk along with Linux provide a powerful and flexible platform. While many technologies tend to become obsolete over time, ASL has the ability to evolve and support new features, and this only increases over time as more open-source developers make contributions and the platform becomes more widely adopted. To summarize some of the key points underlying this node design,

These points together enable a node to be built that has more features and better quality at a lower cost than any previous node design.

FCC Compliance, RF Performance

All components used have FCC certifications indicating that at least some level of certification was done. As an example a 2020 December QST review and bench test of the Radioddity GA-510 (a similar HT) found that it was fully compliant with FCC specs. I have not verified the RF specs on the RT85 with precision test equipment but have had no issues such as intermod or degraded receive sensitivity. With this node one RT85 transmits on ~147 MHz and the other receives on ~431MHz and because it's Full-Duplex, it is always transmitting whenever it's receiving, thus if the TX spurious emissions were bad or the receive performance not good the RX HT would likely be overloaded and de-sensed. The RT85 will receive a 500mW signal very well from a mile away on 70cm when the other RT85 is transmitting 1.5 Watts on 2m from less than a foot away - which says a lot about the RF performance.

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. For the best possible receive sensitivity the Tx and Rx antennas should be as far apart as possible, but in my case I don't need to use my nodes from more than 1-2 miles away and they work very well with the antennas only 8-10" apart.

Because no modifications have been done to the radios or PC they are indeed FCC Part 15 compliant. If they were integrated into an enclosure with a different antenna setup then the system might technically not be considered FCC-certified but with this node design there's no need for any such changes.

Re. generalizations of Chinese radios, after seeing reputable companies adopting them I did some research and found that Chinese radios have come a long way in the recent past. If it's good enough for Yaesu, Gigaparts and QRZ then it's worth some investigation, which has paid off because we now have some great node radio options that cost next to nothing. I can do full-duplex on various vintage cross-band full-duplex HTs from miles away and the audio quality is excellent, indistinguishable from local analog FM repeaters.

This node design is intended for personal use, not as a repeater or for commercial use. There are big differences between cross-band full-duplex, full-duplex (on a single band), and a repeater. Cross-band full-duplex is easy to do with HTs going as far back as the Yaesu FT-727, which I believe was the first ham HT that supported cross-band full-duplex (I bought one new in 1987). Any claim that Chinese HTs should be not used in a cross-band full-duplex application would be a baseless overgeneralization. I don't doubt that $500+ commercial radios would probably give even better RF performance, and if anyone wants to spend $500-1,000+ on a node instead of $150 I would not discourage them from doing so, but in achieving excellent, reliable performance at a very low cost, the RT85's deliver.

It also appears that nearly all the Chinese HTs are now FCC-certified. A web search for the model number and "FCC ID" will turn up lots of info, test reports, etc. These radios are not as nice as a top-of-the-line Icom or Kenwood, but that is to be expected because it wouldn't make sense to spend $100's on a node radio that will be used on one frequency and only provide the most basic functionality. Pretty much any of the newer Chinese HTs should therefore work well as basic node radios. The Baofeng UV-82 look very similar to the RT85s and are available for as little as $20, and have been used in other node designs.

As of 2024 there are now several other newer HTs with very interesting capabilities such as the Quansheng UV-K5 which is capable of CAT control, SSB, HF operation, etc. SDR transceivers such as a HackRF could also potentially be used which could support major innovations such as high bit-rate digital communications that provide even better quality than analog and far higher quality than low bit-rate modes such as DMR, YSF, D-STAR, etc. As these technologies continue to come down in price and expand in flexibility over time some great innovations could occur within AllStar.

Audio Quality Notes

In the context of ASL where audio streams are typically filtered to a ~ 250Hz – 3.5KHz bandwidth, audio I/O through speaker/mic connections is not going to be any different generally than it would be on a higher-end radio after the signal has been bandpass filtered and encoded for ASL. The codecs will generally be the limiting factor.

Many analog FM repeaters are professional-grade systems, built and maintained by Electrical Engineers with decades of experience in Audio and RF systems. An AllStar node should not detract from the audio performance of the overall system relative to any other node, and its audio should be indistinguishable from analog RF users. This node design if properly built and optimized indeed has as good or better audio quality than any other node I've heard. However, you can't just plug in a $5 CM108 fob and expect good audio quality. Some combination of ferrite beads/filters, filter capacitors, metal enclosure(s), proper grounding and wiring is also needed, and no node build should be considered complete and acceptable for use until you have confirmed the audio going out on AllStar sounds very good, not too quiet or too loud, with at least 50-60dB SNR.

ASL uses an 8KHz sample rate, which sounds very good for voice. Because the bandwidth of FM increases in proportion to the maximum modulation frequency, FM transmitters have sharp lowpass audio filters at around 3KHz. For this reason, in good RF conditions AM and SSB can actually deliver higher-fidelity audio within the same bandwidth. AM and SSB are often used with audio bandwidths as high as 6KHz.

The App-Rpt USB audio drivers use a fixed 8KHz sample rate (decimating the USB stream 1:6 from 48KHz) at 16-bits ie. a bitrate of 128Kbps. Once compressed by the codec this is reduced to around 64Kbps to as low as < 10Kbps (depending on the codec) sent over IP. (Which is generally far better than what's used by AMBE/IMBE codecs ie. DMR, D-STAR, C4FM, P25, etc., thus why AllStar sounds far better than all the digital radio modes.) A number of codecs can be enabled in modules.conf, by default u/A-law, ADPCM, G.726, and GSM. If you hear a repeater or hub node that does not have excellent audio quality it may be that u/A-law or other high quality codecs have been excluded in its modules.conf. If a node needs to limit codecs to minimize network bandwidth, testing should be done to ensure appropriate lower-bitrate but high-quality codecs are fully supported.

Re. the SA818 RF module, some nodes have properly integrated this with proper filtering, etc. thus providing good audio quality. But even then it does not support Full-Duplex, does not have the flexibility or RF performance of a real radio, and is known to have other issues, for example using CTCSS tones below ~127 Hz results in loud harmonics that can intrude into the audio passband, and according to its datasheet it provides a Tx SNR of only ~40dB.

Use of HT Speaker/Mic Jacks

ASL fully supports a variety of audio sources, from unfiltered pre-emphasized FM discriminator audio, to filtered deemphasized ("speaker") audio, covering a wide range of use cases. Both the ASL SimpleUSB and USBRadio drivers have a configuration setting to specify if the Rx Audio line is speaker audio vs. unfiltered discriminator audio. For this node the RX HT does the CTCSS decode and tone squelch, and SimpleUSB/USBRadio does not need to do any CTCSS encode/decode or DSP squelch detection. The channel drivers do bandpass filtering of the Rx and Tx audio, and Usbradio can do Rx Carrier Detection.

The audio level from the speaker jack is controlled by the HT's volume control, which once set at an optimum point remains perfectly calibrated with the audio interface trim and USBRadio gain settings. Thus it's easy to set the level at an optimum point, and there are many simple ways to ensure the volume knob stays where it should. For example, put the node where people won't bump into it and turn knobs, such as a high shelf or in a closet, or put a piece of tape on the knob once it has been set, or a dab of hot glue or silicone.

With any type of node it's good to periodically check your Tx signal, which can be easily done with Parrot mode. DTMF commands should be enabled for parrot mode in rpt.conf (*921/922). Double-check that you are not connected to any other nodes before doing any audio tests.

Audio Levels

Consistent audio levels and dynamics 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 ride their volume controls or put up with distorted, clipped, crackly audio.

Asterisk provides an AGC function that can be enabled in extensions.conf and this could be helpful if you find that nodes, repeaters, or nets you listen to have a lot of volume variation between different users.

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. The option to use a 9-16VDC 5.5x2.1mm input rather than 100-240VAC makes the design slightly more cost-effective and energy-efficient, and perfect for portable ops.

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.

AllStar and other VOIP / communication applications require low-latency, reliable IP connectivity, and extra care is required to ensure any WiFi devices and networks used are properly set up. If you ever experience audio issues, dropouts, jitter, etc., it is much more likely to be an issue with your network configuration than with ASL or the node itself.

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 net-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 (DE) can be set up on the node such as KDE or MATE along with a small 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. The DE should then be configured for auto-login so that WiFi will auto-connect after bootup without needing to turn on a monitor and manually log in with a keyboard. The KDE desktop is recommended for newer MiniPCs with ≥4GB RAM and >16GB eMMC.

Some DE's are able to automatically enable/disable WiFi based on ethernet connected status, but it seems MATE does not have that option. This Post shows how to set up a Network Manager script that automatically turns Wifi off or on when ethernet is or is not available, which should help ensure WiFi is not left on when not needed.

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) 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. 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 nice compact laptops with backlit keyboard, full HD LCD, and decent battery life. I shrink the C drive by 65,535 MB and install Debian 12 on the blank partition which then sets it up to dual-boot either OS with Debian and ASL3 as the default. ANR100-LT Demo Video

Full-Duplex Communication Benefits

All AllScan nodes and products support full-duplex communication, which provides powerful advantages over half-duplex nodes. This requires setting the "duplex" parameter to 3 in rpt.conf and to 1 in simpleusb.conf/usbradio.conf. If you do not do this you will not hear Rx audio when keyed up and will be much more likely to experience doubling and other issues.

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 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, quick-keying, and other issues, which can waste minutes of everyone's time, result in inefficient communication, and could even be described as "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 it's not for-profit – not that we can't communicate well. Full-duplex enables communicating as if you were standing 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.

Some Chinese HTs may also support cross-band full-duplex, most likely with the limitation that they can only Tx on 70cm and Rx on 2m, so their 70cm Rx doesn't get de-sensed/overloaded by the nearby 3rd harmonic of their 2m Tx, but I have not been able to find any currently available models that do this and work well. For example the TYT 8000 supports cross-band repeat but it does not support cross-band full-duplex. Fortunately there are plenty of older Japanese radios that fully support CBFD, and maybe some new Chinese radios will support it at some point. For the purposes of a node radio however, as a pair of RT85's is only $50 it is unlikely that any old or new CBFD radio will be available at a lower price. As for mobile radios the Alinco DR-735T does CBFD and has a MiniDIN6 jack thus there is now at least one current production mobile that can work well, though there do not appear to be any Chinese mobile radios that provide these features and have good reviews.

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. ASL was used more for repeaters than personal nodes in the beginning because things like RPi's and MiniPC's did not yet exist or were not powerful enough to run Linux and Asterisk, and FCC-certified ~$20 HTs did not yet exist. But things have changed and there are now many ways to build a node, which if properly done can deliver professional-grade audio quality and long-term reliability.

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 traveling with other hams to a remote area or field day site. For occasional repeater use this node design works well and provides the majority of ASL's features at a very low 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.

(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 that it increases the cost of the node by ~$20 for a 2nd HT, which is a small price for all the above advantages. This node could be made half-duplex if desired though, just use 1 HT instead of 2, plug the RX HT 2.5mm plug into the TX HT, and change the duplex settings in rpt.conf and simpleusb.conf/usbradio.conf.

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


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.

Q: Are the RT85 HTs robust enough for use transmitting hours per day eg. connected to nodes that have multiple nets per day?

A: The RT85's have been around for years now, used by 1,000's of hams, and have many reviews, the vast majority of which are very positive. I haven't seen a single bad review relating to reliability. A few people have had minor complaints such as the menus being a little confusing, but that's to be expected from a $20 radio. I've used dozens of them in various nodes and never had the slightest issue.

Considering the specific operating conditions, 1,000's of people use these HTs on the High power setting with no issues, while in this node design the HTs are only used on Low power and even after transmitting for hours get no more than 10-20°F above ambient air temperature. The HTs run on a well-regulated power supply putting out the optimal voltage and there's no potential for issues associated with batteries, 12V power supplies or cigarette lighter outlets. Thus the HTs are being operated conservatively and have quite a lot of operating margin. And with them being part of a node that will generally be used in a home QTH they will not get the same type of abuse as daily-carry HTs.

The above cannot be said for a lot of other nodes on the market. Raspberry Pi's for example are known to run hot, and it's only a matter of time until a node such as an RPi 3 or 4 and Pi-Hat running at 150+°F will fail. Heat is the #1 cause of failure in computers and RF electronics. In this node all components stay cool. Dell 3040s rarely go above 120°F, and RT85's can transmit 1.5 Watts for hours without getting even close to hot. Longevity and reliability are top priorities in this design and this is reflected in the components I've used, in how cool they run and in their overall energy efficiency.

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. AllScan and AllMon are installed and have the same login: username=______ password=______, and can be accessed by entering the node's IP or DDNS Address in your browser. To update the AllScan password go to the Users page link. To update an AllMon3 password see this link. To update an AllMon2 password see this link. To update a Supermon password see this 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 volume control on the RX radio is marked where it should be with an arrow. Make sure to keep the level around there, or adjust slightly up or down if more or less gain is needed depending on how loud your other radio(s) are. (The volume control on the TX HT does not affect the node.) The HTs should be powered on/off with the rocker switch on the node rather than use their volume control switches.
  9. The node radios are 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 radios. Be sure to confirm that the frequencies are not being used by any repeaters or other reserved frequencies in your area.
  10. The rocker switch on the node controls power to the radios only, not the PC. (Sometimes the radios don't need to be on, eg. if using IAX/SIP apps instead of a radio.)
  11. Using an outdoor antenna is highly recommended and will greatly increase range and reduce possible RFI. An outdoor antenna can be connected to the 2 HTs using a VHF/UHF Duplexer such as a Diamond MX72, Comet CF-416, or MFJ 916, and SMA to PL-259 cables/adapters.
  12. A 6dB or 10dB attenuator for the TX HT is recommended if you will not be using the node from more than ~1/2 mile away. RT85s put out 1.5W in the Low power setting which has a range of 2+ miles. With a 6dB attenuator the TX power will be ~375mW.
  13. Because 1+ Watts of RF is a significant amount of RF power that can easily induce EMI/RFI on nearby electronics, including components in the node itself, it is highly recommended to keep the node at least 6-10 feet away from any large metal surfaces such as LCD TVs, computers, file cabinets, appliances, exterior walls with aluminum siding or stucco, electrical panels, solar panels, cars, RVs with metal siding, etc. If you experience any noise or other issues be sure the node has at least 10 feet of clear space in all directions, or if this is not possible, use an outdoor antenna or put a 6-10dB attenuator on the Tx HT. It's also generally a good idea to keep transmit antennas at least 10 feet away from people and pets if the transmitter will be keyed for long periods of time eg. 1+ hours per day.
  14. 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.
  15. 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. When setting levels keep in mind that it's better to be a little on the low side than to have too much gain and possible clipping and distortion.
  16. 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.
  17. 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).
  18. 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.
  19. 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. Put some attenuation in-line with the Tx antenna. The RT85's put out 1.5 Watts on Low power which is far more than needed within half a mile or a mile. 6dB of attenuation reduces that to ~375mW which is much more reasonable, and will greatly reduce the chance of RFI in the node and with any other nearby devices.
  2. Add a small ferrite clip-on filter on the power supply wires to the Rx HT. On one node I already had a ferrite filter inside the power supply box but it was for the power to both HTs. Apparently some RF could still get coupled into the power line to the Rx HT however so there should either be one ferrite right next to the power supply and one on the line to the Rx HT, or separate small ferrite filters on each line going to each HT.
  3. Use some other antenna for the Tx HT, such as a small magmount antenna 10 feet or so away on a steel cabinet or an outdoor antenna or attic antenna. The 1+Watt of RF will then no longer be right next to the node components.
  4. Check the power supply ripple, try different power supplies, ferrite filters and filter capacitors. I recommend a snap-on ferrite core filter with at least 3-4 turns of the DC power cable around it – as close to the power supply as possible, and then also add a min. 2200uF filter capacitor – as close to the radios as possible.
  5. 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 kind of 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 most cost-effective way to build a fully self-contained, compact and portable full-duplex node using only high-quality off-the-shelf components. I also build and sell fully assembled, configured and tested nodes, to accommodate hams who would rather pay a little more for a plug & play node than build one from scratch. For more info see the Products page.

Because all the software is open-source and the node uses only commonly available off-the-shelf parts, anyone can make a node with the same main components and sell them on ebay/qrz/eham/etc., while adding other features, options, or optimizations. I encourage anyone to do so and hope this article will be useful.

Contact

For questions, feedback or other inquiries email david at allscan.info.

−−··· ···−−

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