ISC Milestone Three: Amateur Radio Integration

The intended goal of our third development milestone was to integrate amateur radio functionality into Byzantium Linux.  A persistent technical limitation of our network architecture is inherent in consumer 802.11 wireless chipsets – their transmission range is limited due to the design of their associated antennae, relatively short battery life, and limited radiated power (200mW).  In practice, this means that wireless mesh networks may become segmented if one or more nodes are farther apart than the maximum theoretical range of 802.11 wireless.  Signal attenuation results in the inability of radios to detect one another’s traffic.  This limits the effectiveness of the network and hampers the ability of nodes to route traffic and synchronize. The higher transmission power allowed under amateur radio rules, superior transceiver quality, lower frequencies available, and greater antenna flexibility would help ameliorate these problems by providing increased range for independent nodes in the mesh.  Fewer nodes would then be required to prevent mesh segmentation, and usable broadcast sites would be less scarce.  Re-purposing existing amateur hand-held transceivers (HT’s) would be especially helpful, as most amateur radio operators already have several of these.

After doing some research we discovered that amateur radio could be used for data transmission.  Licensed amateur radio operators can use linear amplifiers, specialized antennae and other techniques to boost the effective strength of broadcasts on the 2.4GHz band, persuant to Part 97 rules.  There are also transmission modes which can be used to transmit text and binary data over a number of amateur radio bands (such as 70cm and 2m).  Our stated use case of temporarily repurposing portable devices as mesh nodes implied that investigating the use of hand-held amateur radio transceivers (HT’s) might be fruitful.  We concentrated on HT’s capable of accessing parts of the amateur spectrum earmarked for data communications to see if we could send and receive mesh traffic and break the distance barrier.

Digital radio transmission is typically accomplished by connecting an audio output device (such as a computer’s sound card) to a radio’s microphone jack. The audio output device supplies tones (for example, a 1kHz signal switched on and off in morse code or a similar carrier with phase modulation).  In the case of single-sideband (SSB) radios this audio is frequency-shifted directly to radio frequency and transmitted without further modulation.  For frequency modulation (FM) radios, a carrier is modulated by the audio input, but the original data can still be recovered by another FM radio.  Thus, connecting a sound card to a radio with simple audio cables allows the computer to transmit data using arbitrary modulation schemes and protocols.

Packet radio, the transmission of packetized binary data over the airwaves, was invented in the mid-1960’s but was first attempted by amateur operators in the late 1970’s in Canada.  The techniques to accomplish this soon spread to the United States and then to other countries.  The first amateur TNC (terminal node controller – a device analogous to a dialup modem for radio) was invented in 1980 and perfected by 1985 with the commercial manufacture of a device named the TNC-2. Many different modes, or methods of encoding data as sound were developed over the years; each mode works well under certain conditions and worse under others, supports a range of speeds (measured in bits per second), and are most usable in certain bands but not in others.  Most data modulation schemes and protocols can be divided into slow, specialized protocols for sending text messages, and packet radio protocols, which existing support for networking.  Morse code, PSK31, OLIVIA MFSK, and similar belong to the former category. Their functionality is equivalent to instant messaging, Internet Relay Chat, and serial console. Some of these protocols also offer great resilience to interference.  In contrast, packet radio protocols (such as AX.25) tend to be faster and offer software with full networking support.  Our research focused on the AX.25 protocol, which seems the most ready for practical application in our network architecture.

AX.25 is a network protocol which roughly maps to the first three layers of the OSI network model (Physical, Data Link, and Network) and enables the transfer packets of information between nodes.  AX.25 is capable of operating in virtual circuit mode (supporting IPv4); in other words, it functions akin to Ethernet or 802.11.  We experimented with a software implementation of the protocol which is available as part of the Linux kernel since 1995. We tried an open source application called Soundmodem which uses the sound card of a computer to modulate and demodulate packets so that the Linux kernel can process them.  Due to the fact that Soundmodem is an emulation of a TNC certain limitations are unavoidably imposed.  First, for optimal functionality a fairly recent (newer than 2003) computer must be used due to how computationally intensive the encoding and decoding processes are.  Second, Soundmodem is highly sensitive to the volume levels of the sound card; if the volume or microphone sensitivity are too low the radio may not trigger when a packet is sent, or packets may not be detected correctly.  Conversely, if the sound levels are too high distortion and clipping may corrupt packets and interfere with operation.  Third, many audio cables are unshielded, and radio frequency interference from the internals of the computer itself may cause packet corruption.  Signal transients will definitely occur.  Fourth, noise from the computer’s power supply or hamonic noise from many of the computer’s components can make their way into the audio output before it even leaves the machine. Additionally, not all radios have voice activation circuits (VOX) which switch fast enough for more than casual use of packet radio, so Soundmodem includes a number of drivers for activating external PTT circuits.  This means that additional interface devices must be built, tested, and debugged ahead of time.  This is not unusual for the amateur radio community as a whole, but for some prospective users it poses a nontrivial problem.

We acquired several HT’s manufactured by Baofeng (UV-3r+, UV-5R) which are fairly inexpensive ($30-$50us) and readily available online.  These qualities have made them reasonably popular in both the amateur radio and hacker communities for daily use and experimentation.  These radios do not have dedicated Push-To-Talk (PTT) jacks for triggering the transmitter when packets are sent but that functionality is accessible by patching into the external audio jacks.  We also used several of our own HT’s in this effort, a Radio Shack HTX-200 and a Kenwood TH-D72 (which has a built-in TNC).  Research uncovered documentation of the pinouts of the units’ microphone and headphone jacks (http://www.miklor.com/uv5r/UV5R-Technical.html), reproduced here:

http://www.miklor.com/uv5r/images/dualplug.jpg

Haxwithaxe and several other members of HacDC worked to develop a suitable circuit which would permit a computer’s sound card to be connected to the HT’s in such a way that the transmitter would automatically trigger the PTT and broadcast outgoing traffic.  The development effort began with a search for PTT circuits which are already used and well understood, on the hypothesis that we could reimplement these known-good circuits and add support for them to Byzantium Linux.  Several possible solutions were found, constructed, and tested (reproduced here):

Kenwood HT external connector pinout.

http://web.archive.org/web/20000815205024/http://www.packetradio.org/0imgs/5026yv.jpg

2pttopto

http://www.soundcardpacket.org/1cableptt.htm#isolation

Our attempts to use these circuits were unsuccessful for a number of reasons.  First and foremost, we had to adapt the circuits to the pinouts of the Baofeng HT’s which unavoidably changed the dynamics of the circuits, possibly in a way that lead to their malfunctioning.  Secondly, the circuits were designed between ten and twenty years ago for radios which were common at the time.  Distressingly, we discovered that much of the documentation and software for packet radio are just as old and have not been updated in the same length of time.  Haxwithaxe took what we learned from our research and experimentation and designed a new series of PTT circuits for our work, culminating with this schematic:

HacDC's HT PTT schematic.

https://github.com/HacDC/AudioToResistance

Simultaneously, we engineered an additional software stack for Byzantium Linux which includes the necessary utilities and systemware for interfacing with amateur radios and configuring the resulting network interfaces.  The software packages (ax25-tools, ax25-apps, and libax25 (http://www.linux-ax25.org/wiki/Main_Page)) have existed since the early days of the Linux kernel and many distributions of Linux include the necessary device drivers as loadable modules by default.  We reconfigured several of the services running atop Byzantium Linux to avoid sending traffic over AX.25 or cellular interfaces to more efficiently use available bandwidth.  A little experimentation revealed how to properly configure and test Soundmodem and the AX.25 network interfaces.  We discovered that AX.25 interfaces are similar to Ethernet and 802.11 interfaces in most but not all respects.  Protocol analyzers like tcpdump are not capable of interacting with AX.25 network interfaces, but the ax25-apps package includes its own (called listen or axlisten, which is paired with a packet generator called call or axcall).  IPv4 works normally over AX.25, but implementations in recent Linux kernels (v3.8.7 and v3.9.4) are still not IPv6 enabled.

Additionally, we were approached early in the R&D effort by another member of the open source community who has developed a software package called Groundstation, which is designed for synchronizing datastores over high latency and unreliable network connections – perfect for amateur radio.  It also presents a responsive web front-end which permits users to read and post messages.  We are working closely with Richo, Groundstation’s chief developer, to integrate it into Byzantium Linux and develop it into an application which will fulfill several of our design goals.

We first attempted using the standard FSK (Frequency Shift Keying) mode which would have afforded us maximum bandwidth for the medium (9600 bps).  We were unsuccessful in almost all of our attempts.  We subsequently tried transmitting at successively lower speeds (4800 and 1200 bps) using FSK modes and were also unsuccessful.  We then attempted and succeeded at bench testing using the PSK31 and Olivia transmission modes for sending and receiving plain text messages.  We  were even able to acoustically decode text sent using Olivia with a third laptop’s integral microphone across the room.  When we disconnected the radios and connected two laptops together by cross-wiring their microphone and headphone jacks we had some success sending and receiving packets.

In the end, we were forced to continue without working PTT circuits and used the VOX feature of our radios instead. This imposed a significant increase in latency and reduction in throughput.  However, the technique was successful at initiating connections with other nodes and exchanging packets. During testing we were able to maintain TCP connections and transfer data in both directions, albeit slowly. There seems to be evidence that others in the amateur radio community have managed to achieve better results with similar hardware, so we believe that with additional work the techniques could be refined and tuned to improve throughput and reliability.  In a later attempt, we used the built-in TNC of the Kenwood TH-D72 as the reference implementation against which to tune Soundmodem and were able to achieve a stable 1200 bps AX.25 link. This was sufficient to allow us to profile the network performance and characteristics so that we could establish a baseline for later testing over emulated network links.  This strongly suggests that hardware TNCs seem to perform significantly better than Soundmodem, and we have ordered some common models to test with, however they have not arrived in time for use on this milestone.

The most common problem we encountered was unidirectional connections.  We were able to successfully transmit network traffic but were unable to receive it until near the end of the development effort.  An AX.25-specific protocol analyzer (listen) showed that network packets were traversing the AX.25 network interfaces.  A significant amount of ARP traffic was detected (approximately 25% of the traffic volume), as were a number of UDP broadcasts identified as originating from other applications running on our test machines (Avahi and Skype service announcements).  The contents of these UDP packets were decoded correctly.  ICMP traffic (generated by ping and traceroute) was problematic and incurred latencies measured in the tens of thousands of milliseconds.  We were unsuccessful at establishing interactive TCP connections over AX.25 during most of the development effort.  Test services were set up using NCat (in UDP server mode) and Python’s built-in HTTP server (TCP); the former was accessible only over a direct connection, the latter not at all.  We are certain that packets were being broadcast because we used a third HT as a scanner and could hear the packets on the air.

It is our recommendation that we leave amateur radio hardware support to the ham community but provide them with software and systems to enable effective support of non-licensed people in the mesh.  We know that this technology is viable because the amateur radio community has been deploying it in a much more limited fashion for several decades with spurts of activity similar to what we would expect in a disaster situation.  Some of the experiments we performed which followed in their footsteps were successful.  Project Byzantium, however, lacks the skills and experience to bring this aspect of the project to fruition in the time allotted by the grant.  To that end, we are making contacts in the amateur radio community who are working on similar projects and proposing interoperability and collaboration.  Doing so will, unfortunately, have to wait until after the grant development cycle is done.

In summary, a great deal of amateur radio-related documentation for Linux is outdated at best and nonexistent at worst.  For example, the AX.25-HOWTO was last updated in September of 2001 and has not tracked the evolution of Linux in the intervening years.  FAQs and documentation for associated software packages have suffered similar fates.  Some commonly used software packages still require early versions of Windows or even virtualized MS-DOS environments.  We may have independently rediscovered solutions to a number of problems encountered by the amateur radio community years ago without our knowledge.  We would like to thank everyone in the amateur radio community whose hard work and research we studied and tried to replicate.  Without their work this project would simply not have been possible.  We would like to take this time to express our gratitude to everybody in the amateur radio community who answered our questions, demonstrated their projects and made suggestions every step of the way.  We could not have achieved as much as we did without your assistance and patience.  We would also like to thank everybody who helped us design and troubleshoot circuits and contributed corrections and text to this document:

  • Martin Rothfield (KB3UJQ)
  • David Bern (W2LNX)
  • Philip Stewart
  • Alex Smith (K4RNT)
  • Bill Babson (WA1IVD)
  • Dan Barlow
  • Matthew Hines (AB3PI)
  • Vic Nardo (WB2U)

0 Responses to “ISC Milestone Three: Amateur Radio Integration”


Comments are currently closed.