How To - Build a High-Quality Full-Duplex AllStar Node for Under $150
by David Gleason, NR9V
Last Updated: Mar. 27, 2023

Introduction

AllStarLink Nodes have been built in many interesting ways over the past 15 years, with various tradeoffs between cost, features, ease of construction, portability, audio quality and RF performance. Most nodes now available for sale are small, simple nodes that support only half-duplex operation and often have marginal audio quality. Or another common design is to use old Motorola or other mobile radios, which have good audio and RF performance but take up a lot of space and make inefficient use of power, requiring 5+ Amps of supply current and putting out 5+ Watts of power when only a few 100mW is usually needed.

In many 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 for a reasonable price. These are compact, portable, and can have good audio quality if properly 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 with the goal of achieving the highest possible quality at the lowest possible cost, I've built a number of Full-Duplex nodes using readily available FCC-certified components, that can be built by anyone with basic computer and 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 supply, and integrated enclosure for under $150 in materials costs. Some previous designs with Raspberry Pi's used to be around the same price point, but for the past year RPi's have been $100+, making them a far inferior choice for use in a node, and for more reasons than just cost. If at some point RPis come down to more like $50 then such an RPi could be used with this design but until then there are a wide range of mini/microPCs that have more features and the same level of processor power and energy efficiency at a much lower cost.

Table of Contents

Introduction
Overview
  Block Diagram
  Completed Node Pictures
  Background
  History
  Using HTs for Node Radios
  Node Components
Parts List and Component Options
  Main Components
  Radio Interface
  Additional Required Components
  Recommended / Optional Components
  Enclosure Options
Setup Steps
  Dell Wyse 3040 Micro PC
  Recommended App-Rpt Settings
  Updating to the Latest ASL Code
  Power Supply
  Wiring Notes
  Radio Interface Cable Wiring
Setup Steps (continued)
  Ferrite Filters, Filter Capacitors
  Signal-To-Noise Ratio (SNR) Optimization
  CM108 Sound Fob Modification (Optional)
  Enclosure Notes
  Radio Settings
  COS Line Installation (Optional)
  Node Management / Dashboard Apps
Design Overview
  FCC Compliance, RF Performance
  Audio Quality Notes
  WiFi Support, Portability
Full-Duplex Communication Benefits
FAQs
Node Notes / Instructions
Troubleshooting
Conclusion
Contact

Overview

Short 1-minute demo video

Block Diagram

Completed Node Pictures

AllScan ANF101 - Front View


Top Front View with Classic Full-Duplex HTs Yaesu FT-530, FT-51R, Kenwood TH-D72A & Icom IC-W32A


AllScan ANF101 - Back View


AllScan ANF101 Next to a Vintage Yaesu FT-530 Cross-Band Full-Duplex HT


The above gives a good perspective of the compact size of the ANF101, which has a total footprint of only 10"W x 3"D. In contrast a Yaesu FT-530 measures 7.5"L x 2.5"W (with larger 12V battery, excluding antenna).

AllScan ANF100

For this node an ~8" x 5" x 3" Black ABS project box was used, in contrast to a ~6" x 4" x 1.75" enclosure for the ANF101, which is less than half the volume. the ANF100 side-mounted HT layout can be used with enclosures as small as 6" x 4.5" x 2.5", giving a minimum footprint of about 8"x3.5" vs. a 10"x3" but generally more practical and efficient layout for the ANF101.


Front View - Older Version with Dura-Board


This was my first fully-integrated node. It works great but I later optimized the design to be more space-efficient, reducing the mounting board size from 16"x7" to 10"x4.5".

Top Back View - Older Version with Dura-Board


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 seemed like 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 its outgoing audio. Finally in September 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+dB, which is about 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. Also I have always been an advocate of open-source software so did not want to continue to support any node makers who use closed-source software, which seems to be all the commercial node makers (for unnecessary reasons that will be further discussed below). And last but not least I wanted to try Full-Duplex on AllStar, as I knew it would be a game-changing feature.

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 several significant optimizations that no one has documented before, 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 (which is now over 20,000 words) 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, and have essentially been a full-time AllStar developer since October '22. I created AllScan, have contributed to the AllStarLink App-Rpt code, and have built and sold some very nice nodes.

History

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

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

Using HTs for Node Radios

ASL usually uses a Carrier Operated Squelch (COS) line to determine if you are transmitting audio into the node. Most nicer mobile radios have a MiniDIN6 or DB9 jack that provides a COS output along with the PTT input and Rx & Tx audio lines. If you pick up for example a Kenwood TM-V71A or a Yaesu FT-8800R mobile radio, you can plug it right into a standard USB interface such as a Masters Communications DRA-36. Then put the ASL image onto a MicroSD card, put it in a RPi, hookup a keyboard, monitor and mouse, turn it on and run the install script. The standard cfg settings should all work fine and your node should be up and running within 15 minutes. This would be a fine node, supporting cross-band full-duplex (set duplex=3 in rpt.conf), with 5+W power output, which with a good outdoor antenna would have a range of 5-10+ miles.

ASL doesn't actually need a COS input. It comes with a "usbradio" driver that will detect the presence of Rx Audio automatically, and it does so very reliably. This is simple to enable, just uncomment out the "usbradio" line in rpt.conf and comment out the "simpleusb" line, and then in usbradio.conf set carrierfrom to "vox" and voxhangtime to "500" (mS). Then adjust your audio levels reasonably close to where they should be, and you should be all set.

I had initially thought the usbradio "carrierfrom=vox" mode might work more like a typical VOX circuit, which have a somewhat high activation threshold and may look for voice vs. noise spectral signatures, but fortunately that is not the case and ASL's usbradio does exactly what it should - reliably detects the presence of any signal on the Rx audio line, even if you're not talking but are keyed up and there's just ~1mV of background room noise. This is good news for anyone who was thinking of putting together a node using an HT as the node radio but who thought the lack of the COS line might be an issue or wasn't sure how to do it.

Software-based COS detection is not perfect for all use cases – if you have a quiet voice, the radio(s) you use to talk into the node have low mic gain, and if you would often use the node in a quiet environment and frequently pause when speaking, then "carrierfrom=vox" mode would not be ideal, and I would for this case recommend modifying an RT85 to add a hardware COS line. Detailed instructions are provided below on how to do this, though it does require some skill in working with surface-mount electronics.

The first node I built uses a Yaesu FT-530 for the node radio which work perfectly as full-duplex radios. (Unfortunately the radio manufacturers later gave up full-duplex support, only to replace it with low-bitrate digital modes.) But the old radios continue to work fine and are cheap and easy to find.

Using HT(s) for the node also makes it very portable. With a small battery pack and cell 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.

In summary, it's simple, practical, and cost-effective to use HTs for node radios. Retevis and TYT radios use the same pinouts as Kenwood HTs are are easy to connect, with no resistors or other components needed. This is a nice option if you already have some old HTs sitting around. This article focuses on the Retevis RT85 HTs because they are only $50 for a pair new, look nice, are compact, and work well, but any other HTs could be easily substituted. An advantage of using a Full-Duplex HT such as an FT-530 is the node only needs one HT instead of 2, but unless you have multiple full-duplex HTs it makes more sense to use a couple of cheap simple HTs for the node radios and then use your nice FT-530, FT-51R, TH-D72, etc. as the radio you use to talk to the node.

Node Components

There are several main pieces to an ASL node:

  1. A computing device. This can be a Raspberry Pi, any Intel/AMD PC or Mini/Micro/Thin-Client PC, or a "cloud" Linux server such as a linode.com VM. In the case of a cloud server an RTCM interface can be used which connects to a router and then to your radio (but which cost almost $300). RPis are a bit more standard and slightly easier to set up but due to supply chain issues they can be harder to get or more expensive. RPis, the Dell Wyse 3040 and some other Micro PCs use only 10-15 Watts, but others may use significantly more and even 10 Watts of extra usage if left on 24 hours/day could cost 0.01 KW * ~25¢/KWh * 24 * 365 = $22/year in electricity costs.
  2. A radio interface. This usually consists of a small PC Board with a C-Media CM108 or CM119 IC, that interfaces to a USB port and provides an audio input, audio outputs, and GPIO lines for PTT, COS, and status LED(s). This may also be referred to as an audio interface or sound card, but the term radio interface indicates the presence of hardware IO lines for connecting to PTT and COS lines.
  3. A node radio*. This is often built-in to Off-the-Shelf nodes in the form of a small simplex radio module. However these modules may not have very good audio quality or RF specs. Some node manufacturers take audio quality more seriously than others and unfortunately none of them provide detailed specifications on things such as audio signal-to-noise ratios, frequency response, distortion, etc. The only time I would get a node with a built-in radio module is if the node needs to be as compact and portable as possible. But if you'll mainly be using the node at your QTH then real radios are definitely preferable. Note that node radios should always have Tone Squelch enabled to prevent possible interference from keying the node.
  4. Last, some other radio is needed to then talk to the node with. It could be an HT, mobile rig, or base rig. With cross-band full-duplex the node radio could for example Tx on ~431 MHz and Rx on ~147 MHz, and your other radio would Rx on ~431 and Tx on ~147.

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

I also often use nodes with a VOIP desk phone. That way when I'm at my desk I don't need to turn on any radios and can use the node on a speakerphone (such as any model supported by Hamshack Hotline). I also have DroidStar on my shack PC and Android phone and can easily connect to the node through the IAX protocol. Or "Linphone" or "GS Wave" are free SIP VOIP phone apps that are excellent for monitoring. Thus with any ASL node there are multiple ways to talk on it, through RF, IAX apps, VOIP (SIP) phones and apps, or in the case of radio-less nodes by plugging in a speaker-mic. Using HTs is nice though because there is then no dependence on IP devices/apps or wifi/cellular networks. See this excellent article on how to set up VOIP phones/apps on your node. This also covers using ASL's autopatch feature, enabling calls to VOIP phones to be made from a radio. Note that port 5060 will need to be open in the node's iptables (firewall) configuration and forwarded to the node in your router settings.

There are many HTs and mobiles that do cross-band full-duplex 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 great feature.

Parts List and Component Options

Main Components

The Main Node components I recommend are as follows, with purchase links and last-known prices:

Total: $101 (plus any sales tax that may need to be paid to amazon/ebay)

The above items are available from many sources and can be purchased from the links above or from any other reputable source. (If any links on this page are no longer working or you find a better source for any parts let me know.)

I have bought a number of 3040's from various sellers at anywhere from $36 - $47 with free shipping. I bought several from one seller who had the 16GB version and has sold over 1,000 of them. They apparently sell like hotcakes as ebay showed that over 130 were sold just in a 24 hour period. Some 3040's also come with a built-in wifi adapter, which I have not yet tried. Most 3040's run on 5V 3A, but some run on 12V 1.5 or 2 Amps. More recently I've been seeing some new 3040's on ebay going for a little bit more (~$60 with shipping) which is a small price difference for new vs. used. But even a used 3-5+ year old 3040 should run very well for many years. The design is well thought-out with excellent thermal management, no fan to pull dust inside, and they are very popular with many large institutional Thin-Client PC users.

Radio Interface

Several audio/radio interface USB devices are available that use high-quality C-Media USB Audio I/O Controller ICs. Generic CM108 USB audio interfaces (Sound "Fobs") are less than $10 but require some modifications, whereas interfaces such as the Digirig Mobile, Repeater-Builder RIM-Lite-V2 or the Masters Communications DRA-30 are designed specifically for use with radios and are easier to set up. The Digirig Mobile's are < $60 with shipping, include a nice metal case, bring all needed lines to a 3.5mm TRRS jack, and also provide a serial port. The RIM-Lite-V2's are $60 + $5 for shipping, and include a shielded DB9 connector and USB cable, whereas the DRA-30's fully assembled with no case are $65 + $10.50 for shipping. I have used RIM-Lite-V2's, a DRA-100, a DRA-30, and CM108 fobs in nodes and they all work very well.

Option 1: Digirig, Repeater-Builder, or Masters Communications Interfaces

The Digirig Mobile is an open-source design that seems to be popular and well made, usually used for digital modes on portable radios. These have the audio, PTT, and ground lines on a 3.5mm TRRS connector, which is easy to make a cable for. The Repeater-Builder RIM-Lite-V2 are very compact and have all needed lines on a DB9 connector. (If you don't want to solder anything you can get a DB9-Male to terminal block adapter, or cut a TRRS or DB9 serial cable in half and splice the wires onto the 2.5mm TS and 3.5mm TRS audio cables to the HTs. Or various phone plug to RCA breakout cables could be used.) Any of these interfaces are good options but at $60+ they would be the most expensive part of the node.

Option 2: Modified CM108 Interface

CM108 USB interfaces work very well but require some modifications, including soldering a resistor onto a ~0.01" (0.25mm) wide IC pin. If you have a microscope and experience with soldering surface-mount parts this is easy to do but otherwise can be challenging. In my tests the CM108 boards have well over 60dB SNR which is well above the typical end-to-end SNR of any FM repeater. The C-Media CM108AH, CM108B and the CM119A used in the RIM-Lite have essentially identical specs. At some point I'd like to produce custom manufactured AllScan CM108/119 boards with everything needed for this type of node, but in the meantime I can provide hand-modified fobs for $35 shipped. Otherwise you'll want to obtain the below parts and do a bit of soldering.

Total: $7

I had initially avoided CM108 fobs because of significant mods/hacks potentially being required, but in Feb. '23 did some further investigation. Testing revealed that the stereo line out audio is excellent (Hi-Fi/CD quality) but the (unmodified) mic input had some significant digital noise in the intended use with an electret mic. I then removed the bias resistor R6, tested on a PC again from an HT speaker jack output and found that the audio input then sounds great with over 60dB SNR. It turns out that most of the mods that people have been doing to these fobs are unnecessary. Various pages online say to remove the 3.5mm jacks and cut various traces but there's no need to do that. Doing so provides some extra small solder pads but the metal pads on the tops of the jacks already provide large solid areas to solder to. In about 15 minutes I can remove R6, add a 2N3904 transistor and 4.7KΩ resistor to CM108 pin 13 to provide an open-collector PTT output, and solder on the radio cables.

The CM1xx-series wide gain range supports HTs perfectly with no trim pots or resistors needed. I have the Tx gains on my node set at the default (500) in the usbradio_tune settings and the audio level into the Tx HT is right where it should be. I did reduce the Rx gain somewhat (to 250) which gives an optimal input level with the RX HT volume control set at about 20%. The CM1xx also have a mic boost circuit, which should be left off (see usbradio.conf settings below).

The CM108 datasheet shows that the ADC and DACs have programmable gain ranges of ~45dB, and I confirmed in asterisk/channels/chan_usbradio.c that ASL does set these gain settings in the IC based on the rxmixerset, txmixaset and txmixbset config settings. This should provide a wide adjustment range while retaining the full dynamic range of the 16-bit converters. This also confirms that the 0-1000 ranges of the ASL configs correspond to a dB range of ~0-45dB.

Note that some C-Media ICs including the CM108B and CM119B can run with or without an external quartz crystal. The fobs I'm using have a crystal. Fobs that do not have a quartz crystal should be avoided, as the sample timing may not be as precise. The B versions also have a pop filter for the mic input, which rolls off low-frequency response and could be an issue in apps doing CTCSS decode, but since the RX HT does that in this node the pop filter is probably a good feature to have. Also note that only the fob shown in the above image should be used. Other fobs are not as well made, don't have a crystal, or have the IC encapsulated in a resin material preventing access to the pins. The above fobs appear to have been made by C-Media themselves as evaluation boards, thus why they have a high build quality but no case or USB connector housing.

Some C-Media fobs are now using the AH version of the IC, with no other changes to the PCB or other components. An interface I built with a CM108AH fob has significantly more Tx audio gain than the B version and I had to set the txmixb to the minimum (50). Note: In my tests so far the CM108AH fobs appear to have much better noise performance than the CM108B's. I will post more detailed measurements of both soon but for now I strongly advise against using anything with a CM1xxB IC.

There is a similar fob made by Syba that uses a CM119A IC. These go for $10, which is still very cheap. The Syba fob has a small plastic case and a USB connector metal housing which is nice, however the 3040's top USB ports are so close to the Ethernet jack that the Syba fob won't fit unless a USB extension cable is used. Thus the Syba is a good alternative, but there's no real reason to use one over the CM108AH fob in this application.

HT speaker outputs can drive loads as low as 8Ω and for minimum chance of induced noise on the Rx Audio line the fob should present a load resistance somewhere in the range of 100Ω to a few KΩ. The existing 1.2KΩ resistor R7 on the fob helps with this somewhat as it goes to a small filter capacitor to ground, though for the lowest possible noise a ~100Ω termination resistor could be added on the fob. I have so far had no noise issues though so there seems to be no need for such a resistor. By keeping all audio cables as short as possible (< 1 foot), noise/RFI is not likely to be an issue.

To simplify the node appearance the fob could be moved inside the enclosure using a 6" USB extension cable. The board's blinking red status LED (indicating the USB port is running) is helpful, thus if put in an enclosure a small opening should be provided so the LED is visible.

See the CM108 Sound Fob Modification section below for further details.

Additional Required Components

The following additional parts are needed. If you've been doing ham radio and electronics for awhile you may already have some of the various wiring, audio plugs/cables, ferrite filters, etc. around the shack. Kenwood K1 connectors can be found on $2 headset speaker/mics, just cut off the cable and toss the rest. For the 2.5mm cable going to the RX HT just cut a 3' cable in half or use a 2nd K1 connector. The K1 connector cables have fine enameled wire which is more delicate but they work fine and are not hard to solder. Fine enameled wire does break easily however so it's important to then strongly secure the cable with silicone, a small zip tie, or with clear heat shrink tubing around the connections.

A 3.5mm TRS plug and 2.5mm TS or TRS plug can be used instead of the K1 connector. 2.5mm right-angle cables can sometimes be harder to find or more expensive but even then they are usually worth the extra ~$2 to then have regular insulated wire vs. the fine enameled wire used in cheap K1 connector cables. Currently I use 1 K1 connector for the Tx HT and a 2.5mm right-angle TS cable for the Rx HT, as the K1's do look very nice despite them being a bit more hassle to work with.

A 2.5mm cable is not really needed for the Tx HT as it's only used for the Ground connection, and since we already connect to Ground on the back of the radio with the power supply wires, that Ground could be used instead of the 2.5mm jack. However, since the 3040 is not connected to Ground, this would require that an additional ground wire be run from the radio interface to the HT power supply ground. Thus it's a little simpler to just use a K1 connector.

Total: $12

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 no enclosure is needed, or mount the PC and HTs on a ~10"W x 4.5"H aluminum or plexiglass mounting board with the power supplies, power switch and wiring in a small box on the back.

Recommended / Optional Components

These are what I have used but there are many different ways to build a node so you may not need any of the below or may already have various items that will do what's needed.

Total: $28

To simplify the enclosure and reduce costs a larger enclosure with no mounting plate can be used. With a 7.5" x 4.4" x 2.4" ABS enclosure ($9) the HTs will fit on the sides nicely. Or a longer box could be used with the HTs mounted on the front, ideally 10" x 4.5" x 1.75", but this is not a common size and I was not able to find anything reasonably priced. Off-the-shelf boxes/enclosures in longer lengths tend to also have larger widths/depths. For example 10 x 5 x 3 are easier to find, but take up almost twice the volume. Or you could make your own enclosure out of plexiglass, copper, brass, wood, or a surplus equipment case.

The above can be purchased directly from numerous sources but as they are small low-cost items I am able to provide any of the above parts in a Kit that can ship together. Prices shown are my total price for each item and Qty and I would add a flat rate shipping and handling charge. If you just need a few things it may be more cost-effective to get them directly from Amazon/Ebay/Mouser/DigiKey/etc., but if you need a number of the above items it may be more cost-effective for me to send you a kit. Contact me with any questions on that. Parts availability does often change so you may need to look around a bit or improvise. I tend to get a lot of good deals on various parts and keep a lot of things in stock. With amazon prime I get free & fast shipping and while reordering various things will often see sales and order more when the price is right. Amazon and ebay have pretty much everything you need at very good prices and traditional electronics suppliers like Mouser and DigiKey are really only needed for more specialized components or where quality is very important. For example I get filter capacitors and semiconductors from Mouser or similar US distributors to be sure I'm getting genuine high-quality parts meeting all stated specs.

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 but cost ~$10 less and are a little easier to cut and drill. Black ABS matches the RT85s and 3040 very well, giving a clean, professional look. Aluminum or steel boxes are also available anodized or painted for a few $ more.

After doing a lot of testing it appears that ABS often works as well as aluminum as far as noise/RFI. My earlier nodes used die-cast aluminum boxes but then as a cost-reduction experiment I tried an ABS case and after some testing and optimization found that the noise performance of the new node was just as good. Optimizing this can vary from node-to-node, but so far I have not needed a metal box to solve a noise issue. However I do recommend that a metal mounting plate be used as this provides a nice solid ground plane that will help shield any nearby cables and components from induced RFI. I have seen a couple instances in various node builds and refactoring where ferrites were no longer needed on certain cables after adding a metal plate.

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 nice ground plane that minimizes RFI while also providing better antenna loading and better RF performance. The HT power connection ground wires and HT power supply ground also go to the ground lug. Note that the MiniPC power supply does not connect to ground however, to prevent any switching noise on that supply from affecting the HTs.

A conductive box is only likely to block RF at wavelengths that are approximately the same or shorter than the dimensions of the box itself. Small circuit boards/components will not have a direct RFI issue from a 2m node transmitter as the PCB traces are much smaller than the 2-meter wavelength, thus there will not be significant coupling. 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 running around that do not have appropriate grounding and ferrite filters. Any RFI in VHF/UHF nodes is much more likely to be solved by keeping all cables as short as possible, using ferrite filters when needed, and avoiding ground loops by using a star ground configuration.

Update: I ordered 2 anodized aluminum mounting plates from onlinemetals.com and they arrived 2 days later. They look good but are only anodized on one side and need to have the corners rounded and edges filed a bit. Thus it's probably easier and cheaper to get plain aluminum and spray paint it with a heavy-duty glossy enamel after cleaning up the edges and drilling the various mounting holes. I then called the local Industrial Metal Supply who cut 10 mounting plates for me from 0.040" black painted aluminum, at a cost of less than $6 ea. I'm also getting some quotes on custom fabricated black powder-coated 20 ga. steel enclosures, and black anodized/power-coated extruded aluminum enclosures that will be nicely finished with all needed mounting holes pre-drilled & cut. Once I can get the cost down to < $30 ea. this should look great and would save considerable time (easily an hour per node) in laying out, cutting and drilling the mounting holes, rounding and filing the edges, and painting.

Setup Steps

Dell Wyse 3040 Micro PC

Installing ASL on a Dell 3040, other Mini/Micro PC, or Netbook is not hard if you're experienced in building/maintaining PCs. The 3040's have a UEFI-only BIOS that needs the boot file in a specific place. Making a UEFI USB drive is simple: Download the ASL install image, then format the USB drive as FAT32 and unzip the image files onto it. Then boot the 3040 from the USB and it will guide you through the installation. Conveniently the Intel/AMD ASL install image is based on Debian Linux which happens to have the boot file where the 3040 expects it.

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

Once the install finishes to the 3040 internal flash, it won't boot, but you can then boot from a UEFI clonezilla USB, select the "Local operating system (if available)" boot option and then the Debian OS option, and then do the following: 

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

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

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

Recommended App-Rpt Settings

usbradio.conf Recommended Settings

Your node number (should have been set in asl-menu/initial setup)
rxboost = 0
rxctcssoverride = 1
carrierfrom = vox
voxhangtime = 500
ctcssfrom = no
rxdemod = speaker
txprelim = no
txlimonly = yes
txtoctype = no
txmixa = no
txmixb = voice
rxlpf = 2
rxhpf = 1
txlpf = 1
txhpf = 1
duplex = 1

rpt.conf Recommended Settings

Your node number (should have been set in asl-menu/initial setup)
rxchannel = Radio/usb_[node#] ; Comment out all other rxhannel lines
duplex = 3
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

Updating to the Latest ASL Code

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

  1. Log into the node by SSH as root (run "sudo su" if not already root user).
  2. Run all commands listed on the ASL GitHub Prerequisites section.
  3. Run the commands listed on the ASL GitHub Compiling "Manually" section.

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

Voxhangtime Adjustment and Timing

When using ASL's usbradio driver in carrierfrom=vox mode there is by default a hardcoded 2000mS VOX Hangtime added that results in 2 seconds of silence being added after transmissions to the node. This is not an extremely long time considering that repeaters already have a hang time and courtesy tone delay of anywhere from 1 to several seconds, but it is a noticeable delay and I found that it works more optimally when reduced to more like 500mS. I submitted a Pull Request to the ASL codebase in November to make this hangtime configurable by adding a voxhangtime parameter to usbradio.conf, and this was merged into the ASL code in Feb. 2023.

With the latest ASL code now on the node (after running commands in the "Updating" section above), edit the /etc/asterisk/rpt.conf file and make sure voxhangtime is set to around 500 (mS). Then restart the node and test some transmissions using parrot mode (*921 to enable, *922 to disable). If all is set up correctly transmissions into the node from your radio will be reliably detected with no dropouts (even if you're not talking or are quiet for a short time) and once you unkey the node will show that COS dropped within approximately 1 Second.

Timing measurements

When in full-duplex (duplex=3 in rpt.conf (not 2 or 4)) the hang time on the local RF TX is longer, but the node is not actually transmitting audio to the network during that extra time (beyond when RX CD dropped). It probably stays keyed a bit longer to prevent more squelch tails and because it is full-duplex and thus you can key up any time without having to wait for the node to unkey first. Thus it appears App-rpt took that into consideration and is making it work a little more like a repeater in this case, giving a little extra hang time after each TX is complete so if you or a remote node key up there's no unnecessary carrier drop and extra squelch tail.

To better characterize the timing I set up a script to get the rpt keyed vars from asterisk every 50mS, then keyed up for a fraction of second, enough to trip CD. Results: 

time 1671868925.527  [cos_keyed] => 1  [tx_keyed] => 1
time 1671868926.803  [cos_keyed] => 0  [tx_keyed] => 1 => diff: 1200 mS
time 1671868929.321  [cos_keyed] => 0  [tx_keyed] => 0 => diff: 2500 mS

This timing works great for me. The extra 1.2 seconds of space is not noticeable or annoying during a normal QSO on a repeater, where there's already several seconds of hang time and a courtesy tone. When voxhangtime was 2000mS (vs. 500mS now) it was much more noticeable and the time to drop COS was closer to 3 seconds.

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. To get power to the RT85's I solder 24 ga. power wires onto the battery contacts on the back of the radio. 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 in recent decades, 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 many certifications. 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 the QTH. Be sure to test any power supply for RFI issues though as every situation can be different and just one poorly designed power supply in your house or even a nearby neighbor's house could impact 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 have used 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.

ANF101 Interior View showing AC Adapters, Ferrite Filter, Capacitor and Wiring

After several node builds I have settled on a 6.8" x 4.5" x 1.8" ABS enclosure for the power supplies, which is compact but has some extra room to accommodate extra parts or wiring if needed. The enclosure shown above is 5.6 x 4.3 x 1.8.

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. These should then go to a small terminal block or small wire nuts.

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 120VAC 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 easy to find on ebay without AC adapters at a significant discount, and with the difference in cost between an AC adapter and DC-DC Converter for the HT power supply there could be a ~$20 cost savings to go with a 12V powered node instead of 120V.

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

For some good info on DC-DC converters see G6OJB's site AllStarSetup.com. This also has info on building a node with an RPi and modified Baofeng in a plastic case, but I definitely recommend using fully-intact RT85s and a Dell 3040 mounted such that they are fully accessible and visible.

Radio Interface Cable Wiring

Making cables to go to 2x 2.5mm plugs and 1x 3.5mm plug 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 - Modified CM108 Sound Fob to Kenwood, Retevis, TYT, QRZ, etc. HTs

Line Out Jack Ring ----- TX HT 3.5mm Ring (Tx Audio)
Transistor Collector --- TX HT 3.5mm Sleeve (PTT)
Line Out Jack Sleeve --- TX HT 2.5mm Sleeve (Ground)
Mic In Jack Ring ------- RX HT 2.5mm Tip (Rx Audio)
Min In Jack Sleeve ----- RX HT 2.5mm Sleeve (Ground)

Wiring - Digirig Mobile Interface to Kenwood, Retevis, TYT, QRZ, etc. HTs

Audio Jack Tip ------ RX HT 2.5mm Tip (Rx Audio)
Audio Jack R1 ------- TX HT 3.5mm Ring (Tx Audio)
Audio Jack R2 ------- TX HT 3.5mm Sleeve (PTT)
Audio Jack Sleeve --- RX & TX HTs 2.5mm Sleeve (Ground)

Wiring - RIM-Lite V2 to Kenwood, Retevis, TYT, QRZ, etc. HTs

DB9 Pin 1 --- TX HT 3.5mm Ring (Tx Audio)
DB9 Pin 5 --- TX HT 3.5mm Sleeve (PTT)
DB9 Pin 6 --- RX HT 2.5mm Tip (Rx Audio)
DB9 Pin 8 --- TX HT 2.5mm Sleeve (Ground)
DB9 Pin 9 --- RX HT 2.5mm Sleeve (Ground)

Wiring - DRA-30 to Kenwood, Retevis, TYT, QRZ, etc. HTs

DB9 Pin 1 --- TX HT 3.5mm Ring (Tx Audio)
DB9 Pin 3 --- TX HT 3.5mm Sleeve (PTT)
DB9 Pin 5 --- RX HT 2.5mm Tip (Rx Audio)
DB9 Pin 6 --- TX HT 2.5mm Sleeve (Ground)
DB9 Pin 9 --- RX HT 2.5mm Sleeve (Ground)

Ferrite Filters, Filter Capacitors

Clip-on ferrite cores are needed on at least some of the cables. The 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 filters should generally be used with any switching power supply, with the cord wrapped around the ferrite a few times. Without that there can be significant buzz that comes through. This is a known issue with nodes in general, relating to Tx RF being picked up by the power cord and then causing 60Hz harmonics when the diodes in the power supply are near their zero-crossing points where they can be modulated by induced RF. This results in a broadbanded buzz on 60Hz 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 cores placed appropriately can reduce this by 99+%.

Ferrites should not be needed with linear power supplies because linear regulators do not produce high-frequency switching noise. Linear power supplies put out more low frequency ripple however, thus it can be even more important to add a good quality filter capacitor. 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 for switching supplies a few turns of the DC power cable should be wrapped around a ferrite core as close to the power supply case as possible.

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 needed there. This is good news as it confirms that the FCC-certified Dell does in fact put out much less EMI/RFI than my RPi4 (which is in a high quality Vilros metal case). Thus this is another advantage of the Dell 3040 (which has about 15 different certification logos on the bottom) over RPi's.

A ferrite core will likely be needed on the RX and TX audio cables, but sometimes nether is needed depending on the cable lengths, routing, shielding, etc. In general the more ferrites the better, they won't hurt anything. Adding a ferrite on the Tx audio cable may also help in some cases. Particularly if you're listening to a node on an SDR (I use an SDRplay RSPdx) with full audio bandwidth and no deemphasis, which will reveal much more detail than a normal radio that bandpasses everything 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 3 or 4 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.

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 RF output signal, 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 you might get lucky and 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. If you have talked to other node builders or built nodes yourself you probably know that consistently getting 50+dB SNR through the whole Rx + Tx signal chain on a node is not easy – especially on a full-duplex node. Noise can be introduced in the RX HT, interface ADC and/or DAC, in the TX HT, or on any cabling in-between.

It'd be great if you could just hook these things up and have everything work perfectly, but the 1+Watt of RF energy being transmitted right there on the node makes this easier said than done. I have had excellent results with the nodes I've built and continue to refine the design. With proper testing and optimization the result can definitely be indistinguishable from Analog FM.

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 even in that case, 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.

Signal-To-Noise Ratio (SNR) Optimization

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

Full-duplex nodes are more of a challenge to minimize noise on because 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 $25 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.

Another interesting note is that the C-Media fobs now are available with a CM108AH rather than CM108B IC, and so far I notice the audio levels are quite a bit higher, and the overall noise is lower. I'm still doing further testing and optimizations on the radio interface to keep the cost as low as possible while being easy to assemble but delivering very clean audio with essentially zero discernible noise in typical listening conditions.

For these measurements I record the node's transmit audio from the audio output of my IC-9700 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).

Once the SNR is consistently above 50dB 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 somewhat loud. At that point there can in some cases still be some faint digital noise, usually comprised of harmonics of 60Hz and 1KHz, which arrive on 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 well under control, 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 throughout all the node components.

If you usually use a node in a mobile or loud environment you would probably be just fine with a 30dB SNR, but for quieter home/office environments 50 - 60 dB is definitely preferable.

CM108 Sound Fob Modification

Modifying a generic ~$5 CM108 Sound Fob will result in a major cost savings vs. expensive radio interface modules, and is easy to do if you have experience working with surface-mount electronics. The following is all there is to it:

  1. Remove resistor R6
  2. Attach a 2N3904 or other general purpose NPN transistor Emitter to Ground
  3. Attach a 4.7KΩ resistor between the transistor Base and Pin 13 on the CM108
  4. (Optional for Hardware-COS) Attach a general purpose NPN transistor Emitter to Ground, attach a 4.7KΩ resistor between the transistor Base and the COS line from the RX RT85, and connect the transistor Collector to Pin 48 on the CM108.
  5. Connect the radio cables as described in the Radio Interface Cables section above
  6. Secure the cables to the fob using small zip ties or silicone, or enclose the fob in clear heat-shrink tubing

Closeup of a CM108B Fob with Added PTT Output

Note at the top middle there are 3 light brown capacitors in a row. The top 2 are on the Tx audio lines and the lower connects to ground. Thus the right side of the top one is a great place to connect the Tx Audio wire, and the right side of the bottom one is a great place to connect to Ground. Notes on the above image:

Closeup of the Added Transistor, Resistor and K1 Connector Cable

Modified CM108 Interface with 2.5mm and K1 Connectors Before Enclosing in Heat-Shrink Tubing

Completed Fob with Clear Heat-Shrink Tubing

With a nice piece of heat-shrink tubing properly applied the fob feels very solid and durable and the cables stay tightly in place. Care is required in arranging the parts and wiring so that when compressed down by the heat-shrink no bare wires touch anything they shouldn't.

Another advantage to this approach is that the 3.5mm jacks on the fob are still fully intact and usable. This is very useful for test/debug purposes, and the node can also be used with a speaker-mic or headset with the radios off. However the speaker-mic/headset would probably need different audio level settings which would require some adjustments to the usbradio gain settings, and most have electret mic elements that require DC power to be provided on the mic audio line. It would be easy to make a small interface board though that did the necessary level conversions, which would enable the node to support radios or speaker-mics/headsets.

Radio-Less Node Notes

A radio-less node can be built with just a Dell 3040, CM108 interface and a half-dozen extra parts. No PTT line is needed if there's no radio. COS might also not be needed (which in this case is PTT from a mic) if usbradio's vox mode was used, but this would require the PTT button in the mic to be wired so that when it's off the mic element is disconnected or shorted to Ground. This may not be practical as it would require a SPDT PTT switch or other added circuitry. Thus it would probably be better to wire the mic's PTT line to pin 48 on the CM1xx. PTT on most mics is active-low (switches to Ground) thus no extra resistors or transistors are needed.

It does not appear that speaker-mics are available that have a DTMF keypad, and because DTMF control would be an essential feature to support in a radio-less node, this would imply a DTMF mic and separate speaker need to be used. A small speaker could be built into the node enclosure, and/or a 3.5mm jack provided for an external speaker or headphones.

This would make for a simple radio-less node, barely larger than the 4"x4"x1" 3040 and its AC Adapter. I plan to build one of these soon just to be able to offer a TurnKey super-low-cost node that works with commonly available DTMF mics while being full-duplex and having great audio quality.

If a speaker-mic was going to be used (as opposed to a DTMF mic), these almost all have an electret mic element requiring a few Volts on the mic audio line. An unmodified CM108 fob provides this but from a noisy USB source that requires additional filtering. C-Media's website states "Because USB Power has a 1KHz noise, it needs an RC Filter (10Ω and 10μF) on DVdd (pin 35) and AVdd (pins 29 & 34) to reduce this effect. DGND and AGND are separated". I checked both the C-Media CM108 and Syba CM119A fobs and they both have pins 34 and 35 connected together. To install an RC filter would appear to require cutting the trace between those 2 pins and replacing with a 10Ω resistor, then adding at least a 10μF capacitor from pin 34 to Ground. Resistor R6 then provides bias voltage to the mic audio line. Alternatively a speaker-mic with an internal or external preamp could be used, though as some power source would be needed for that it's probably easier to just add the 2 small components to the fob to fix the noise issue. It remains to be seen how effective this fix would be though - additional filtering might still be needed.

With a DTMF mic however, these should need only a 5V input, which can be taken off the CM108 fob's 5V line. This line may still need additional filtering as described above however, depending on how good the filtering is in the DTMF mic used.

The CM108B datasheet indicates it will only put out 442mVrms into 32Ω which is only 6mW of power, which may be enough for an earphone but not for a speaker. Thus an audio amp circuit would be needed, such as an LM386 with a 1KΩ audio-taper volume control potentiometer. (Complete audio amp modules can be obtained on ebay/amazon for as little as $2.) This may not put out much power but should run fine on the 5V supply from the USB fob. An LM386 should be able to put out ~4.5Vpp = 1.6Vrms which would drive 320mW into 8Ω, which is about the same output as many HTs, though would probably be too quiet for use in a vehicle.

This would be a great add-on option for regular nodes also so a speaker and mic could be used when desired with no need to turn on any radios. In that case an extra potentiometer would be needed to match the speaker-mic and RX HT output levels.

I will be posting a How-To Guide for building a radio-less node in the next few weeks. Until then, see my preliminary design and picture of the needed parts.

Enclosure Notes

For a home node a case is not necessary – just set everything on a shelf, and you can control the node from any web browser using AllScan, AllMon and/or Supermon. But for better portability and durability the node components should be mounted in/on an enclosure such as a project box, mounting board, or a clear plastic carry case. Everything will then be better integrated and self-contained, and the cables and wiring can then be kept short and direct which can greatly reduce the chances of RFI/noise.

Optionally all components can be mounted inside (as opposed to on) an enclosure or case. By setting up the MicroPC 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 are 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 and Tx & Rx LEDs and the LED(s) on the radio interface.

Using right-angle 2.5mm/3.5mm phone plugs to go into the HTs greatly reduces the amount of space taken up by the plugs, and the small CM108 USB interfaces save additional space. With those optimizations everything fits nicely on a 10" x 4.5" mounting plate, and an enclosure as small as 6" x 4" x 1.75" can be used for the power supplies.

With everything on a mounting plate the MicroPC 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 easy to move around, set on a shelf or hang on a wall. Though not as small as a Pi-Hat type node it's very portable with total dimensions as small as 10" x 3" x 5". An ABS, polycarbonate, aluminum or steel box on the back can nicely enclose the power supplies and wiring, preventing the all-too-common Spaghetti-wiring found in many shacks. Or instead of a separate mounting plate and enclosure a single larger enclosure can be used, but keeping the enclosure size to a minimum makes the node more portable and provides nice recessed areas on the sides for the power and ethernet cords.

Acrylic (Plexiglass) is available in custom sizes on ebay or from various websites professionally cut with polished edges, and plain/painted/anodized aluminum is also easy to order in custom sizes. Aluminum or powder-coated steel for the mounting board and/or enclosure ensures maximum durability and reduced chance of any RFI issues while also not being flammable.

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

Top Front view of an AllScan ANF101 with 5.6 x 4.3 x 1.8 ABS Project Box

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 my Icom-9700 is even faster with basically no squelch tail at all, but the Kenwood TH-D72 and D74 are not so quick and have a much more noticeable squelch tail, more like 50-100+mS and fairly loud. Therefore I enabled Tone Encode on the node TX HT and Tone Squelch on my other radios to minimize squelch tails after the node unkeys. Both Kenwoods now drop 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 short and quiet to begin with.

Important Note: Nodes (even if simplex only) 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. My first homebrew node uses a Yaesu FT-530 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. Power dissipation = V×I, so by running an HT off of 6V rather than 12V and transmitting low power the power consumption and dissipation of the RF output section should be ~half as much. I confirmed this on the FT-530, which gets very hot during continuous Tx on 12V but barely even gets warm when run on 6-7V. As for the RT85's I have never tried running them on 12V and would not recommend that but when run on 7.5V they barely get warm even when transmitting 1.5 Watts for hours.

Installation of a COS Line in an RT85 (Optional)

See this page for details on how a COS line can be installed in an RT85 if desired. This is not necessary if using the usbradio driver carrierfrom=vox mode, but having a hardware COS line can provide a more reliable COS signal ie. in cases where you're transmitting 1+ Watt from or adjacent to the node and do not have ferrite filters everywhere they should be or if you use the node in quiet environments and tend to talk quietly with frequent long pauses.

By adding a resistor and transistor in the RT85 and connecting the resulting open-collector active-low COS output to the 2.5mm jack Ring, no wires need to be brought outside the HT case, and the 2.5mm TRS cable used for RX Audio and Ground will also have COS – which connects directly to Pin 3 of the RIM-LiteV2 DB9 or to Pin 48 on a CM1xx IC.

Size comparison of a Kenwood TH-D72A and a Retevis RT85

Node Management / Dashboard Apps

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

AllScan ANF100 flanked by Yaesu FT-530 and Icom IC-W32A HTs, with AllScan running in the background

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 now enable a node to be built that has more features and better quality at a lower cost than any previous node design.

One of my first nodes using a Dell 3040, DRA-30, and Yaesu FT-530

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, up until recently I was under the impression that Chinese radios are all junk, but 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 an FT-530 or TH-D72 from miles away and the audio quality is excellent, indistinguishable from local analog FM repeaters.

The node I have detailed here 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 baseless and a vast 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 then by all means go for it, but in achieving excellent, reliable performance at the possible lowest 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 $24 ea., and have been used in other node designs in the past.

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 if not most Analog FM Repeaters are professional-grade systems, built and maintained by professional EE's with decades of experience in Audio and RF systems. The key distinction in this context is does a node uphold that level of quality throughout the entire signal chain? If a node does not detract from the audio performance of the overall system relative to any other node, it upholds the performance of that professional-grade system. This node design indeed has as good or better audio quality than any other node I've heard. Not to say it's perfect, but I don't hear any significant hums, buzzes, clunks, hiss, distortion, etc.

It would be nice to precisely measure the specs of various radio options and fully characterize their frequency response, phase response, SNR, input sensitivity, dynamic range, etc., however there's been no need to do that so far because the audio quality and performance of the nodes I've built are meeting all expectations. ASL and repeaters in general only have a bandwidth of ~250Hz to 4-5KHz at the most thus we're not aiming for same level of performance as Pro-Audio or Studio Recording equipment. ASL uses an 8KHz sample rate, which sounds very good for voice. If a repeater were set up with an unusually wide audio bandwidth and analog FM radios used with the widest possible audio bandwidths it could theoretically have HD audio quality, and thus better audio quality than most VOIP codecs, but I've never seen a radio that has much if any options for this on VHF/UHF FM or heard of any repeaters set up for extended audio bandwidth. FM transceivers typically have sharp filters on the Rx and Tx audio and few if any configuration options to adjust those.

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 it's probably more like 32 or 64 Kbps sent over IP. (Which is about 10-20x more bandwidth 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 ADPCM, A/u-law, G.726, and GSM. It would be interesting to do some testing and confirm if ASL nodes are going with the best-sounding codecs by default, or how much improvement could be made and what the differences would be in internet bandwidth. The 8KHz sample rate is probably the limiting factor as that limits the frequency response to ~3.5KHz, and the ASL-defaults are probably already pretty optimal. ASL does support many codecs and could potentially do HD audio if both nodes enabled the appropriate codecs, but ASL's (or at least the channel driver's) 8KHz sample-rate does not look like it could be changed without days of work involved.

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, may only be supported under HamVOIP, 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.

Use of HT Speaker/Mic Jacks

ASL fully supports a variety of audio sources, from unfiltered pre-emphasized FM discriminator audio, to filtered 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. The HT does the CTCSS decode and tone squelch, and simpleusb/usbradio does not need to do any CTCSS encode/decode or DSP squelch detection. Usbradio does bandpass filtering of both the Rx and Tx audio, and does Rx carrier detection.

There are some settings in usbradio.conf and in rpt.conf that are important as described earlier. Usbradio's Rx and Tx filters may not be necessary since HTs should already do bandpass filtering on the speaker and mic audio but it shouldn't have any significant impact on audio quality to do additional filtering in usbradio with the wider frequency range options (250–3.5K Rx, 250–3.3K Tx). This additional filtering ensures that no residual PL tones or high frequencies will get through that could potentially result in codec aliasing. (It does not appear there is a way to disable usbradio's bandpass filters but if there was it would be interesting to see if that made any noticeable difference in audio quality. The frequency and phase response might be a little more linear with them off.)

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:

Audio Levels

If you hear anyone on AllStar who is significantly too loud or too quiet – let them know. They will probably be happy to fix it, and the system then works better for everyone. Audio levels are pretty easy to adjust on AllStar (definitely much easier than with the low-bitrate AMBE/IMBE digital radio modes where people are using random apps and devices with a huge range of volumes, glitches, artifacts, etc.)

It would also be relatively easy to add a configurable Auto-Gain Control (AGC) function to App-Rpt, providing a smooth, transparent auto-leveling feature to help normalize overly quiet and loud input signals. This was recently discussed on the ASL forum and may be added at some point if there is sufficient interest.

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 makes the design slightly more cost-effective and energy-efficient than the 120V version, and perfect for portable ops.

Any cheap USB WiFi adapter should work for basic short-range communication, but I would recommend a reputable brand that's known to work well on Debian Linux, and a model that's FCC-certified and has a real antenna (rather than only a 1cm square piece of plastic). 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 is only 1cm wide/long is just not going to have good RF performance. I only use my nodes at home thus haven't needed WiFi, but I have received inquiries on building a node with WiFi included and preconfigured. The TP-Link "Archer T2U Plus AC600" look good and are < $20. I have not yet tested any WiFi adapters but would suggest testing a few different models and seeing how their signal strength, jitter, packet loss, etc. are at different distances from your WiFi router.

If you use WiFi on a node you will need to have basic familiarity with Linux and configuring the various settings. Eventually some setting or driver will need to be updated or debugged. Thus I prefer to not provide pre-configured WiFi as an option in my node builds, because although it would probably work great for awhile I'd rather not have to support potential WiFi issues remotely, thus ideally any builder or purchaser of a node should have a solid familiarity with setting up and debugging any possible WiFi issues. 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.

Full-Duplex Communication Benefits

In The Beginning...

In the beginning...there was CW. Most radios support full or semi break-in keying, meaning that they can receive between symbols/letters/words sent, depending on the radio and its settings. Thus if someone is transmitting on a decent radio and making a reasonable attempt to monitor the frequency between words or sentences, anyone can easily break in. CW is not full-duplex but it supports interactive, fluid conversation, and allows others to join a QSO or reply to a CQ quickly and easily.

And then there was AM...and then 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 frequency. 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 at all times (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's less energy efficient than SSB due to having a constant power regardless of modulation level. And unlike SSB where you can unkey briefly with no audible effect, if you unkey on FM it results in squelch drops for listeners (unless their radio has unusually good squelch like an IC-9700 or they have tone squelch properly set up), thus there is a slight disincentive on FM to pay attention to the channel while you're transmitting.

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

As a side note, repeaters don't actually need to only use FM (or PSK digital equivalents). They could also support SSB without a tremendous 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 an FM 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. This could be an interesting experiment.

But Even 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 infamous W6ZN repeater does exactly this, and there are numerous interlinked repeater systems with multiple inputs such as the SoCal DARN system where (if you're using a radio that supports cross-band full-duplex or 2 different radios) you can listen to one repeater on one mountain and transmit into a linked repeater on another mountain. These repeaters have limits though because they only have so many receivers, and full-duplex users need to know what frequencies those receivers are on and coordinate amongst themselves to prevent doubles. In summary, prior to ASL, repeaters almost never supported true multi-user full-duplex in the way that phone systems always have.

And Then There Was The Internet

The Internet is essentially an extension of the telephone system that had existed for 50+ years 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 – an enterprise-grade PBX system, it supports full-duplex perfectly and makes it very simple. Asterisk started as a phone system, where full-duplex is just how things are done. 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 looping, 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.

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 for 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 is only one repeater I've used so far that doesn't support full-duplex. I initially had doubts about how many would fully support it and was pleasantly surprised.

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.

Amateur vs. Professional

Go on any repeater net that has more than a half dozen or so users and you'll frequently hear doubles, echoing, etc. This wastes minutes of everyone's time and sounds "amateurish". Full-duplex solves these issues and gives you full situational awareness. This goes back to the definitions of "amateur" vs. "professional". "Amateur" just means we're not in it for money – not that we don't communicate well. Or at least that's how I see it. Full-duplex gives you the ability to easily monitor your communications in real time, and with AllStar now making it so simple to do there's no longer any good 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 TH-D74 I recently sold 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 smoothly and more interactively.

Some Chinese HTs also support cross-band full-duplex, with the limitation that they can only Tx on 70cm and Rx on 2m – so that their 70cm Rx doesn't get de-sensed/overloaded by the nearby 3rd harmonic of their 2m Tx. Several models such as the TYT 8000 support this and could work well for use with this node, and the 8000's are available new for as little as $65. Haven't tried one as I already have some good Japanese radios that fully support FDX, but it is nice to see the Chinese supporting it in new radios to at least some extent since there are few if any current production Japanese models that do. These would not be ideal for node radios though since a pair of RT85's is only $50 and have no limitations in transmitting on 2m while receiving on 70cm.

Full-Duplex Nodes vs. Repeaters

A Cross-Band Full-Duplex node (ie. that has duplex=3 in rpt.conf) does not repeat the received audio into the transmitted audio. This is an important distinction and I do not recommend that this node be used as a repeater or in a commercial application. A common misconception about how full-duplex works on ASL 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. As a result of this misconception I occasionally hear objections that you can't use Chinese HTs, or HTs at all, or carrierfrom=vox mode. Hopefully any such doubters or naysayers will read this document and its significant discussion of these details, and try it themselves. ASL was used more for repeaters than personal nodes in the beginning because things like RPi's and MicroPC's did not yet exist or were not powerful enough to run Linux and Asterisk, and FCC-certified $25 HTs did not yet exist. But things have changed and there are now many ways to build a node.

Any full-duplex ASL node can be used as a small simple repeater by setting duplex=2 or 4 in rpt.conf, which I do not generally recommend because it would defeat one of the main benefits of a full-duplex personal AllStar node, since the received audio is then routed to the transmit audio, making it work more like a typical repeater than a full-featured radio-linked VOIP node. But there are applications where a small low-cost portable repeater would be useful, such as if travelling with other hams to a remote area or field day site. For that type of application I would generally recommend a higher-end mobile radio and radio interface with a MiniDIN6 connector, but for occasional use this node design would work well and provide all of ASL's features at a very low cost. You could even add additional receive HTs at only $25 each along with a simple audio mixer circuit and thereby provide true multi-user full-duplex functionality.

Usbradio Driver Additional Notes

A related note and clarification about usbradio's carrierfrom=vox mode is that one reason it works so well in a full-duplex node is that full-duplex radios have a little bit higher background noise level during quiet parts or pauses in speech, since the radio you talk into the node with will be receiving at the same time it's transmitting. Thus the small amount of path noise / white noise you typically hear on FM comes through the radio speaker and gets coupled into the mic, thereby ensuring that the signal received by the node is always going be at least 1mV, which is then sufficient for usbradio's "vox" mode to sense a carrier and keep RX CD set. (This small amount of noise is very smooth and of a broadbanded random nature that is not distracting or noticeable.) If half-duplex radios are used with this node the incoming signal during quiet parts might not be loud enough at all times and you might get some occasional RX CD drops. However if there is any other background noise such as a breeze blowing, road noise, or general noise around the house, or you don't pause too long when talking it's unlikely to be an issue, and you can always set the voxhangtime parameter higher. Its default is 2000mS, while 500mS seems to work quite well with full-duplex radios. Also some full-duplex radios have more noise and speaker→mic coupling than others. The FT-530 has the lowest noise floor and clearest audio of any full-duplex HT I've tested, whereas the TH-D72, IC-W32A, and TH-79A are a little noisier and would probably never have an issue with false CD drops.

Summary

There are no disadvantages to full-duplex other than that it increases the cost of the node by $25 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 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 analog-only repeaters.

Q: Wouldn't the usbradio carrierfrom=vox mode cause delays in detecting audio or other issues?

A:There are a lot of misconceptions about the ASL usbradio driver carrierfrom=vox mode. This Guide discusses this in detail. To sum it up, this DSP function in ASL is in reality a sensitive and precise Rx Carrier Detect function. I didn't think it would work so well either when I first tried it but then found that it works exactly like it should, with absolutely no delays in detecting audio, and no false carrier drops. It's sensitive enough to detect even ~1mV of room background noise.

The RX HT is either going to output 0 Volts (or well under 1mV) when squelched, or some signal > ~1mV when a signal is present. Carrierfrom=vox mode just differentiates between these 2 states. Thus it's a simpler scenario than what most VOX circuits were designed for, and the designers of ASL set up the code perfectly to do exactly what's needed. The term VOX (Voice-Operated Transmit) is somewhat misleading here in fact, because this particular usbradio DSP function is processing Receive audio to determine RXCD.

Q: Isn't carrierfrom=dsp mode even better and more powerful than vox mode?

A: The RX HT has both squelch and Tone squelch enabled, thus there is only audio on the RX audio line when a signal is present with sufficient level and valid CTCSS tone. Usbradio's carrierfrom=vox mode then sees the signal and immediately sets RXCD. This is a simple and reliable process, and there would be no significant benefit to using the dsp mode instead. Usbradio's carrierfrom=dsp mode is typically used with repeaters and raw (unfiltered, preemphasized) discriminator audio which gives ASL full control over squelch and CTCSS detection, but this node is not repeating audio to an RF transmitter, the Rx audio goes only to a VOIP codec at an 8KHz sample-rate where it is then filtered to the same ~250 Hz – 3.5KHz bandwidth typical of a speaker output, and the squelch functions of the HTs work very well. Things might be different for a repeater but that's not the subject of this guide.

You could tap into the raw discriminator audio in an HT and use carrierfrom=dsp mode, which might result in slightly higher audio quality and/or shorter squelch tails, but as the audio quality of the node is already indistinguishable from users going into repeaters directly on Analog FM, and the squelch tails on the RT85s are not unusually loud or long, it's unlikely that such a modification would be worth the hassle. Also, newer HTs are unlikely to have a discriminator audio line available as they tend to use a single IC that does all conversions and DSP between RF and filtered audio. I have not seen a schematic for the RT85 but according to the Baofeng UV-82 schematic (an almost identical HT) it uses an RDA1846 single-chip transceiver, which does not appear to have any option for unfiltered discriminator audio output.

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 $25 radio. I've used about a dozen of them as of Feb. '23 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 barely get warm. 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. The Dell 3040 rarely goes above 120°F, and RT85's can transmit 1.5 Watts for hours and barely get warm. Longevity and reliability are definitely 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.
  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. (This assumes you do not already have another node on port 4569. Otherwise subsequent port#s should be used ie. 4570, 71...)
  3. If you will want to use AllMon/Supermon/AllScan from external networks you'll also need to forward port 80 TCP in the router to the node, or for portable nodes use a Dynamic DNS service.
  4. To access the node by SSH enter the node's IP Address in your SSH client, username=______ and password=______. This password should be changed. To do this, log into the node by SSH and type "passwd" and you will be prompted for a new password. Make sure not to lose that as there is no easy way to recover or reset it.
  5. AllMon, Supermon and AllScan are all installed and have the same login: username=______ password=______, and can be accessed by entering the node's IP or DDNS Address in your browser. This will open the AllMon index page which then has links to Supermon and AllScan. To update the AllMon password see this link. To update the Supermon password see this link. To update the AllScan password go to the Users page link.
  6. If the Dell 3040 has not been connected to power for awhile sometimes the power button has to be held in for 5-10 seconds and it may take a minute to then start up. Usually though a single click is all that's needed to turn it on or off.
  7. AllStar nodes can take several minutes after first being turned on to register with the ASL Network and for connections to remote nodes to then be accepted.
  8. The switch on the top of the node controls power to the radios only, not to the PC. (Sometimes the radios don't need to be on, eg. if using IAX/SIP apps instead of a radio.)
  9. 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 anything.) The HTs should be powered on and off with the rocker switch on top of the node rather than use their volume control switches.
  10. RX and TX level adjustments can also be made in the asl radio tune settings, by logging in by SSH and running "sudo /usr/sbin/radio-tune-menu", then follow the prompts to adjust the usbradio settings.
  11. 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.)
  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, or with 10dB of attenuation will be 150mW which is enough to cover several hundred feet.
  13. Because the node can transmit a significant amount of power it's a good idea to keep it at least 10 feet away from other electronic devices, people, pets, etc., if you often leave it connected to busy nodes and it's transmitting hours per day.
  14. An extra ferrite filter is included in case you get noise/RFI on the node or in any other devices. This should not be needed but if you do get any noise try putting it on different cables to filter out noise and help locate the source(s).
  15. 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 right on the radios. Be sure to confirm that the frequencies are not being used by any repeaters or other reserved frequencies in your area. If you have questions on the node or radio settings be sure to review this article, 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 need 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, 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 least-expensive possible way to build a full-duplex node using only high-quality off-the-shelf components. In addition I wanted it to be fully self-contained such that it's portable and compact.

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 send me an email. I usually have several nodes in stock or can custom build a node to your specifications within a week.

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 their own unique touches, other features, options, or optimizations. I encourage anyone to do so and hope this article will be useful.

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

Contact

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

−−··· ···−−

AllScan.info | AllStarLink.org | AllStarLink Forum | QRZ ASL Forum | eHam.net