The Hard Truth about Hardware TNCs in Packet Radio

I know this will not come as an easy pill to swallow for most people who come across this blog post. I implore you to read with an open mind. Hear me out and then build your argument in the comment section. This post is an effort to help guide those who may be looking into packet radio, to help steer them into the direction of the future. Hardware TNCs are an aspect of packet radio that people can’t just let go. While they can certainty be used, there is almost no reason to get one today with the software options that are available. There are a few exceptions we’ll get into. Let’s start off by talking about the reason for their existence.

Why were Hardware TNCs made in the First Place?

Thanks to Steve Stroh from Zero Retries for some corrections. Be sure to check out his newsletter here. Hardware TNC(Terminal Node Controller)s for packet were mostly made and used in the 80’s and 90’s, although their development started in 1978. The name TNC was used to differentiate it from the NNC(Network Node Controller), which didn’t quite happen. Originally, they were the primary input/output for digital systems. The 1980s, 1990s were the height of connected packet radio popularity. Computers at this time were mostly single application systems. (Mostly during the 80’s). Meaning, for a BBS node to function, it usually need dedicated computing hardware. We didn’t have CPUs with several cores, gigabytes of ram to spare, and small form factor low, power computers we have today. It was logical that a separate device would be made that could serve packet node services 24/7 besides that of the family Desktop.

Now, we have small form factor computers that are smaller than most hardware TNCs, with enough processing power and ram to run 10 of these hardware TNCs at once, that use a fifth of the electricity than traditional hardware TNCs from the 80s/90s at a fraction of the cost. They can have embeded screens, and GPIO pins can easily be used to create TX and RX indicators.

What does a Software TNC offer over Hardware TNC?

Dire Wolf will be used as an example, as a popular well-known software TNC.

• Ability to decode and transmit several speeds and modulations at once.
  Several instances of direwolf can be started to listen for different speeds of packet on the same radio. 1200, 9600, 2400, 300 can all take place at one time, on one radio, with one sound card interface. By sharing a virtual PTT/Serial port, the software TNC can also transmit back on all of these speeds, matching the sender. Hardware TNCs are basically all limited to a single mode and speed at a time per radio.
• Wider Range of Supported Modulation and Speeds
  Due to the nature of software, it is much easier to upgrade often. A user only needs to download the latest version to get new features. This benefit is obvious given many software TNC’s (like Dire Wolf) will support AX25, IL2P, FX25, along with different speeds of each, as well as different versions. Dire Wolf for example supports version 2.2 of the AX25 protocol, increasing throughput of data, where most hardware TNC’s will forever be stuck on the pre-1998 version 2.0.
• Multi Modem Support
  Given the fact that Software TNCs only need an audio device, and PTT port, those resources can be shared with other modems on the system like VARA. My own packet node uses software that can “share” the serial/PTT ports of my radio in order to share the same radio between DireWolf, VARA, and FLDigi for remote management. This is something that I could never remotely consider with a Hardware TNC as the interface for my radio.
• Easy Backups and Replaceability
  If the hardware(computer) being used to run my software TNC were to fail, I can use a backup of the config to rebuild the same functionality on virtually any x64bit or ARM based computing device within an hour. If a hardware TNC were to fail, all data and configuration on it will be lost unless a backup was manually copied and pasted from a terminal, and the same model was ordered to replace it. This could take weeks to arrive in the mail, and that’s if it is still being sold. If not, you are also looking at porting your configuration to a different system, and creating a new cable for a different TNC. Not very repaceable nor redundant.
• Built in ways to troubleshoot all things.
  The computer where a software TNC is plugged in can be used to troubleshoot audio signal issues easily to and from the radio. Listening to the audio from the radio is as easy as setting “Listen to this Device” as enabled in Windows or Linux. You can then hear exactly what audio is being fed in and out, while watching raw packet data come across the screen. For a Hardware TNC, this is typically where one would break out some oscilloscope to try to visually inspect the audio signals from the radio. Test tone and PTT commands can be generated from software to diagnose PTT issues as well. The NinoTNC takes care of a few of these things, but you won’t see it on other TNCs.
• Open-Source Code and Low-Cost Solutions
  While most of the Hardware TNCs are closed source products, software TNCs like direwolf are open to the world to learn from and improve on. This is also what makes them free. Hardware TNCs are typically very expensive, with a few exceptions like the NinoTNC. To be fair, a Soundcard/PTT interface should be included in the price of the software TNC, but we use the same interface for all digital modes right? That brings me to the next point.
• You can use your Existing Digital Interface Hardware
  Software TNCs like Direwolf and QtSoundModem can use the exact same digital interfaces you already have for other modes like FT8 and VARA. You don’t need to make/craft special cables that you will only every use for that specific purpose (packet). A hardware TNC requires a special cable to be made for every different model of TNC. They often use old connectors that can’t be found in stores, and must be ordered online(Like DIN Connectors). In 2025, there’s not must of an excuse for not opting for a USB standard like USB-C. These hardware TNC cables typically can’t be used with the industry standard interfaces for digital at the time of writing.
• All in One package to do all things.
  A software TNC like direwolf also bundles features like digipeating, i-gating, and is also reachable over the network. Apart from this, more software stacks can be run on the same hardware to provide an almost infinite number of features. My packet radio node consists of a single computer to a radio that provides a BPQ BBS(mailbox) node, Winlink, Chat, APRS Digipeater/IGate. and Internet Packet Routing all in one device. A Hardware BBS will typically serve a mailbox, and that’s about the extent of things.
• Software modems decode more packets.
  A study was done, which found that software modems (like DireWolf) were able to successfully decode more packets when presented compared to that of hardware TNCs at the same signal input level. This isn’t really surprising given the processing power a computer has compared to a traditional hardware TNC, and the fact the Direwolf can decode several slices of the spectrum at once. This eliminates any argument that the hardware TNC is there to spare the computer resources. The computer obviously doesn’t need it.

What does a Hardware TNC offer over a Software TNC?

It wouldn’t be fair if I didn’t at least put effort into talking about why someone may want to use a hardware TNC instead. I could see why the following two points could be handy for a user who may change their volume settings often without a permanent packet station. But being a SysOp, I set up my node and leave it until something breaks. I don’t need lights and knobs, so others may have more use case.

• A DCD(Data Carrier Detect)/PTT light can show you when a packet arrives or transmits when not using a screen.
  Although Software TNCs can show you raw packets as they arrive when using a monitor, or remoting into a system, they don’t have hardware LEDs for indicators. A hardware TNC often features a DCD light that can show when a packet arrives, but they often just light up for any strong signal.
  I see this argument come up when someone is talking about it as a feature to troubleshoot a node. I can’t say I have had to do that given I use Dire Wolf and a Digirig, so things “Just Work”. But If I had to troubleshoot something like this, I would rather see the raw packet data and listen to the radio as I can do with the software TNC. After things work, I don’t have much use in a DCD light at all. My node runs, works, and I don’t stare at the TNC waiting for signals. If you do want something like this for a software TNC, you can use something like direwatch to achieve the same result with a software TNC.
• Some Hardware TNCs feature knobs to adjust Input/Output Signal Levels
  Some hardware TNCs have adjustment knobs on the front that allow you to change the drive level of the radio, and the input into the TNC.
  Again, the digirig and software TNC manages all of this for me by doing a pretty good job at balancing those audio levels. If I need to make adjustments, I would have to log into the computer the radio is connected to and adjust the sound card levels within the OS where I get a nice visual picture of what the levels look like to the TNC, as well as Dire Wolf telling me something is too quiet or loud if needed.

Common Arguments

“A hardware packet node is simpler, and doesn’t require a computer therefore it’s better or more robust”

A TNC is a computer. It is doing some of the things a Windows/Linux/Mac computer can do, and comes with just as many points of failure. It features memory, a CPU, power supply, ports, and other things commonly found on a computer. The argument is misguided in the fact that it assumes because it does less, it must be more robust. Assuming you don’t actually have the hardware TNC connected to a computer anyways, and you are in fact running one standalone with only a built in mailbox, you are prone to failure with the same odds as if you were running a standalone computer with a software TNC on it. The difference at the end of the day is, the TNC will be much harder to replace with another compared to a raspberry pi or other computer failure, and only running with the built in software leaves a lot to be desired.

“Software TNCs are difficult to Setup and contain known bugs”

This quote is basically ripped from the Santa Clara ARES packet radio page. Making content over packet the past year, I get A LOT of questions over email. I also read a lot of questions posted on packet groups. The majority of issues people have, is when using hardware TNCs. There are a few reasons for this. One being, there are so many different standards for the plugs, and expected behavior in capability with other modes (even versions of AX25). Another big issue people have, is the hardware TNCs turn the audio signal from the radio into a black box, where you can’t really listen to what’s fed to the TNC without using special equipment. If you buy a digirig interface for your radio, and plug it into the USB port of a computer running dire wolf, you will have a plug and play software TNC. The software TNC configuration file needed for dire wolf is about 10-15 lines long. I promise, it will take you less time to make that configuration file than it will take to get a hardware TNC running from scratch. On top of this, it’s much harder for others to help you troubleshoot hardware over the internet, rather than software modems everyone has access to. When I first started making videos about packet, I got so many comments about users having issues with XYZ TNC, I eventually just told them to replace them with Dire Wolf.

As for the talk about bugs, I can only assume it’s just confusion on the operator’s part. Software TNCs are often open source, so if a bug is discovered, anyone can fix them, or submit a request for a fix. The update can be downloaded within days, and all is well. You won’t see that with hardware TNCs which will keep having issues for years (or forever if discontinued). If you do notice an actual bug (like in Direwolf for Example), go raise an issue over on the github page detailing what you’ve found. I’m not aware of any bugs that occur in connected packet that come for software TNCs. There are some misconfigurations people can make if they don’t read the user guide, however.

Hardware TNCs are more compatible all around because they only require a serial connection.

Although Direwolf runs on about anything, it also has the ability to bind a virtual serial KISS port to a hardware USB connection on the host computer. This means something like a raspberry pi zero (at $10-$15) can be made to function as a hardware TNC, by allowing a client to plug into it’s serial/kiss dedicated USB port and use it as a serial TNC. This is still much cheaper than a hardware TNC, offers all of the benefits of a software TNC, and can even be powered over the USB connection when combined with a USB hub, and something like a raspberry pi.

What about as a standalone/remote APRS digipeater?

Just because the “sound modem” or “software TNC” can serve so many features, doesn’t mean they have to. When we think of the word standalone, we must remind ourselves that the hardware TNCs are computing devices. When up against a small form factor PC, or raspberry pi, they take up just as much space and resources (in the pis case more) to do the exact same job(with less features and compatibility). Just because it is a software modem does not mean it needs a monitor, keyboard or mouse. In fact, a Pi can be setup completely headless after the image is on the sd card. When talking about a well trusted hardware TNC such as the Kantronics KPC-3+ against a Software TNC, lets see what a remote APRS digipeater looks like (excluding other functions):

Kantronics KPC-3:

• Cost: $249 (Shipping, adapter , and Radio interface Cable not included)
• APRS Digipeater
• GPS position transmitting and tracking (requires external GPS receiver with NMEA-0183 data output)
• 1200bps AX25 packet speed.
• AX25 V1 and V2 Support
• Requires a computer to change settings or program.
• 12v, which makes it more compatible with off grid systems.

Raspberry Pi Based Software TNC with digirig:

• Cost: $90 (Raspberry Pi Zero with Wifi/Bluetooth, $60 Digirig Package)
• APRS Digipeater with several different beacons, times, and paths configurable.
• GPS Position transmitting and tracking (with any GPSD supported receiver, or NMEA/GNSS receiver)
• Too many supported AX25 Speeds to count. At least 300n, 1200b, and 9600b (which can be done at the same time).
• AX25 V1, V2, and V2.2 Support.
• Settings can be changed over wifi if needed, and any arm/linux supported remote management protocol.
• 5v, which can be powered over any modern phone charger, but not 12v systems directly.

Even after the features gained with the software TNC, the price jump alone is enough to make the software TNC my go to, even when used as a simple remote APRS digipeater. I myself wouldn’t use a PI, I would opt for a $100 refurbished HP elite-desk mini. But I’m still getting much more bang for my buck over the KPC-3 in a remote APRS digipeater configuration, with the exception of a voltage step up/step down that I might need for a Pi/Small form factor PC.

A dedicated piece of hardware on a mountain top beats software any time.

Both a Kantronics or any other hardware TNC, and a Raspberry Pi are all dedicated pieces of hardware running software. There is no difference.

“What’s the boot time on a Raspberry Pi/PC vs a Hardware TNC?”

The raspberry PI takes about 21 seconds to boot. TNCs like the Kantronics take about 5-10 seconds. If using the system as a dedicated TNC to provide a service such as digipeating/APRS, it should not be rebooting more than 1 time a year. If those 10 seconds every reboot matter to you more than the massive list of benefits above, I have a feeling you are probably aren’t here to have your mind changed about anything.

“What about flakey power conditions, how well does a PC or Pi like being turned on and off 20 times in a minute?”

Take the several hundred dollars you saved form the Kantronics, and get yourself an UPS (Uninterruptible Power Supply) for $50-$100 dollars for a PI or PC. If you are setting up a remote station that is meant to be robust, you should probably start with a decent foundation in your power before worrying about TNCs. You can use the same UPS for other electronics on the system to provide clean, reliable power when conditions aren’t great. If the argument assumes you don’t intend on providing reliable power, the PI PC is probably fine in this case anyweays, as not much writing to the drive is being done those first 15 seconds of boot. OF course, if you do have a disk failure, swap it out with a backup disk/sd card that you hopefully made, or even use a USB/another drive device as a secondary boot device with a copy of the OS if the first one fails.

What about malware? Aren’t PC/Pis more vulnerable than a Hardware TNC.

Yes, in fact. PCs and PIs are more easily infected with malware than that of a Kantrnoics other other hardware based TNC. Lets talk about what that really takes. If the devices don’t have internet the risk and attack surface is the same. But if you decide to plug the PI/PC into a network, AND you decide to expose vulnerable services to the internet AND you open the ports AND an attacker decides to target your device, AND they have a remote code execution exploit without any user interaction, than the PI can be infected. Or if you let random people into the site location, AND they bring a monitor, keyboard and mouse, AND they have your PC password, they can put malware onto a PI/PC. Both scenarios are things that are easily prevented by not actively exposing vulnerable services and ports to the internet, setting a password and using a lock. All basics.

Some Exceptions

There are a few exceptions where several benefits may outweigh all of the drawback’s hardware TNCs have. Two particular TNCs come time mind. The Mobilinkd and the NinoTNC.

The TNC4 by mobilinkd is the same as any other hardware TNC, except that it is battery powered, and offers a KISS interface over Bluetooth. This means you can connect to your radios TNC wirelessly. This feature seems kind of niche, but some people have a use for such a thing.

The NinoTNC has the advantage of having the full support of the IL2P modes, which is a major improvement over AX25. Other than that, it also has the DCD/Transmit lights and hardware level adjustment mentioned above. The NinoTNC itself still features a USB-B interface, and a DE9 connector for the radio making it very future facing in terms of the protocol used, but held up in the past by leaning on these connectors and dedicated hardware for this mode. Had a software modem shipped with all of the modes and protocols supported on this device, I believe IL2P would be a lot more popular. The Dire Wolf project has made an effort, but doesn’t have the full support for IL2P that the NinoTNC does. It reminds me of buying a modern Nintendo console to play some exclusive, knowing the game would have been more popular if it had shipped for a computer. Even swapping out the USB-B for USB-C and replacing the DE9 connectors with a TRRS jack with the same pinput as the Digirig would have made a world of difference. At least then, a new cable wouldn’t need to be made specifically for this one device, or if someone didn’t want to make their own, they could just buy one for their radio from the digirig store.

Conclusion

Call it a rant if you wish, but this is a hill I will die on. In 2025, our computers can make sound. We have a plethora of efficient, premade audio interfaces for all of our radios. A lot of the hobby already focuses on digital modes, so we have the interfaces for our radios on hand, and if not, you can buy them made for you online. There is little to no use in adding additional hardware to modulate and demodulate audio signals into data.

Until a Hardware TNC comes onto the market that is updated every several months, supports many modes and speeds, can run all of the packet applications available to us at once, with high processing power to decode many slices of audio at the same time, that also doesn’t tie the radio to it alone, I will stick with my software modem/tnc. When the point above happens, I guess we’ve come full circle, as you now have a computer running a software TNC my friends.

Please leave this field empty

Consider Subscribing!

Signup for our once a month newsletter!

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.