Greg Cook, G4CUI, Tony Whitaker, G3RKL, Dave Cameron VE7LTD

1. Introduction

Since the beginning of the hobby, amateur radio has always been about communication between like-minded enthusiasts, be they in the next street or on the other side of the World. Over the decades, advances in both RF and computer technology have allowed additional techniques to voice and CW communication to be developed, such as RTTY, AmTOR, PacTOR, PSK31 and packet, increasing both the diversity and range of contacts. Long distance QSO's have traditionally been made on HF, though always subject to the uncertainties of propagation. The OSCAR satellites introduced the possibility of some such contacts 'on demand', independent of propagation, but only under certain restricted conditions. Logically, the next step is to ask if there is any way that long distant contacts could be made with simple equipment at any time, especially for those whose licence does not give them access to HF. The answer is now yes, facilitated by the internet.

As of summer 2001, connection of amateur radio equipment to the internet has been authorised in the UK by the Radiocommunications Agency (RA) for about 18 months. This has been implemented by issuing an NoV (Notice of Variation) to individual amateurs, allowing attended operation on a few specific frequencies in the 2m and 70cm bands, and, with the keeper's permission, through named repeaters. For the greater part of this period, the software package used on the computer has been VocalTec's Internet Phone (IPhone) [1], with the station (gateway) operator selecting the remote internet connection. Initially, linking was point to point between single gateways, but as experience was gained it became possible to include more stations at a time with multiple gateways in 'conference rooms' [2]. Here everybody can hear and talk to everyone else, whether coming in directly on the internet or via a radio path. However, one of the drawbacks of the IPhone System for someone operating a radio rather than a computer is that he or she is entirely dependent on the gateway operator's choice of which station(s) are connected to the link radio. What would be desirable is a system which allows the radio operator to have a direct choice of where to link, without the need to involve the gateway operator, and the IRLP system does just this. A previous article [3] described how GB3US was linked to the internet via the IPhone system, and here we present a superior system for internet linking using IRLP, offering better audio quality and more control of the link by the radio operator.

2. What is IRLP?

IRLP stands for Internet Radio Linking Project, and was devised by Dave Cameron, VE7LTD. A much fuller description can be obtained from the IRLP web site [4], but essentially it is a system which connects one IRLP node to one or more other nodes via the internet. It differs from the IPhone system in several ways, a major one being that the node owner (equivalent to the IPhone gateway operator) is not usually involved in selecting connections between nodes, control being in the hands of the radio operator. Another important difference, and this also applies to the ILink system being developed by M0CSH [5], is that it is not possible to connect directly from the internet, only via an amateur radio link, thus excluding potential unlicensed operation. Each node, which can be anywhere in the World, is allocated a three digit identification code. For example, the original IRLP repeater, VE7RHS, in Vancouver is 100, and GB3US in Sheffield is 515. To make a connection between two nodes, all that is necessary is for the radio operator to first establish radio communication with a node, then key in the desired ID followed by a zero, using DTMF tones to turn the link ON, and the ID followed by a one to turn the link OFF. So, keying in 1000 would connect to VE7RHS and keying in 1001 would disconnect the link.

Although IRLP mainly caters for node to node links, there are some 'reflectors' to which several nodes can connect concurrently. Input from one node is then broadcast to all others, in a similar way to IPhone conference rooms. These reflectors can be dialled up just like any other node, but there is much more control with IRLP since the radio operator can also disconnect the node from a reflector, which contrasts with the IPhone system where traffic is continuously relayed until the gateway operator switches it off.

3. The IRLP Node

3.1 General Aspects

As mentioned,, the IRLP system is a collection of nodes, any two of which can be connected together. A node comprises a link radio and a computer with an appropriate internet connection, running RedHat Linux v5.2 or 6.2 [6] as the operating system. The Linux platform allows relatively slow PC's (e.g. 100MHz 486 Pentium) to run the proprietary software with good efficiency and reliability. There is also a small interface board, which contains the DTMF decoder and simple logic to control the radio PTT line and to detect the squelch state on the COS (Carrier Operated Squelch) line, that connects to the parallel port. Receive audio from the radio connects to this board, and also is input to the PC sound card, whilst the sound card output goes directly to the radio's mic input. It should be noted that the system is designed to have hard control of the radio, rather than the dual VOX method used by IPhone. All the essential control software is loaded and maintained remotely by VE7LTD through FTP and Telnet, which not only means that all the nodes are running the same up-to-date programmes, but also lessens considerably the burden on the node owner, who is probably not a Linux guru.

3.2 More Technical Aspects

The IRLP system was originally designed for fast internet connections (>100kbps), and many overseas nodes are installed in the 'works QTH' of node owners (as is GB3US node), where high speed internet access is provided by office intranet systems. Under these conditions, ADPCM protocol is used for the voice IP, potentially providing high quality audio. However, IRLP will work very satisfactorily with a dial-up connection using a standard BT line and modem, although a GSM software codec is then used. Although generally not a problem with a dial-up type ISP, firewalls may cause problems with installations at commercial or business locations, since in-bound IP packets must be allowed as well as out-bound. The required ports for IRLP in-bound data are detailed in Table 1. Normally out-bound packets should not be blocked, but for information purposes the ports 80 (http), 873 or 8873 (rsync) and 10000 (IP determination) must additionally allow out-bound data.

The RedHat v6.2 Linux platform is the preferred version to use with IRLP, and indeed the software will only run under RedHat versions 5 and 6 at present. There are considerable security patches built into the system, and the node operator has a degree of flexibility in designing the node functionality through the use of script files. These are similar to the old DOS .bat files, and can be executed from the command prompt. In MS-DOS is the command interpreter, whereas IRLP under RedHat Linux use the Bash shell. The purpose of such a shell is to display a prompt and execute the command you type in at the keyboard, as well as executing shell scripts, which are text files containing one or more commands. A special custom_decode script file allows script files and binaries to be run when specific DTMF sequences are received by the radio on the up-link. This very useful feature allows node owners to customise their stations by playing specific audio .wav files over the down-link in response to an up-link DTMF sequence. For instance, when 12345 is received by the GB3US node, a short .wav file describing IRLP is transmitted. Similarly the G4CUI dial-up node initiates a connection to the ISP when 12002 is received on the up-link. The free off-peak internet call deal offered by BT/ Freeserve used by G4CUI only permits two hours internet access at a time, after which the call is terminated. Hence the facility to allow remote users to re-dial the internet connection using their radios and thus re-establish the IRLP link is most useful. Interested readers with some past programming experience should soon master the script file syntax, using a combination of existing files that come with the IRLP software and a good Linux manual [6]. However, a brief idea of the syntax is given in Table 2 with reference to the directory tree in Fig.1. The actual files are displayed in bold, and are of three basic types; custom_decode and info are script files, cosstate, key, unkey and play are binary files, and info.wav is the audio file. The binaries all come as part of the IRLP software package, leaving the node owner to customise the script and audio files.

The Linux operating system can either be installed on a virgin hard drive, or on a drive with a native partition of at least 500Mb. The latter option allows the useful feature of being able to import files directly across from a Windows partition. The IRLP 'package' obtainable from VE7LTD [4] comprises a suitable version of Linux on CD ROM and the interface board plus leads with basic instructions. Subsequent to Linux installation and connection to the link radio, a session is then arranged with VE7LTD who FTP's the IRLP software over.

4. Using an IRLP Node over the Air

When a valid four digit sequence is detected requesting a link, the node interrogates the system to see if the connection can be made, and the appropriate status message played. If all is well, this will be in the form of a welcome message from the target node, ending with "LINK ON". If the requested node is busy, then the message will state that it is either "in use locally" or already "connected to node callsign". Once connected, calls and QSO's can be made in the usual way, since one of the features of IRLP is the excellent audio quality, and many comments have been made to the effect that remote stations sound just like locals. With high speed internet access, the turn-round time is very short, but a delay of a few seconds can occur with slower modems. When the link is no longer required, the four digit disconnect sequence can be sent from either end and a farewell message will be sent ending with "LINK OFF". As a safety feature, if no traffic is detected in one direction for a certain time period, then the link is automatically closed, which has already caught out a few people in 'waffle mode'. The node owner can also add his own features to customise the node, using Linux script files as mentioned previously. A list of node ID's and current status can be found on the web [7].

5. GB3US, the First Permanently Linked IRLP Node Repeater in the UK

The majority of IRLP nodes are located in Canada and the USA, and a large number of these are connected to existing VHF/UHF repeaters, although some work on simplex frequencies. The first node in the UK was set up at the home location of G4CUI, with the first UK IRLP linked QSO between G4CUI (working his own node with a hand held) and VE7MAN via remote node VE7URG occurring at 20:45GMT on March 12th 2001. Realistically, this node can only be activated intermittently for a few hours on some days, as the NoV specifies continuous attendance and dial-up time costs money! Nevertheless, it demonstrated the power and popularity of the system, especially when linked to the wide coverage of GB3HH at Buxton during the normally quiet couple of hours either side of midnight. Interestingly VE7LTD had never set up a node with such a low baud internet connection before (56k Hayes dial-up modem with standard BT connection), and was surprised at how well the GSM compression worked. The only constraint with a standard dial-up connection however is that reflectors cannot be accessed. The second UK node was established a few weeks later by G4NJI in Rotherham, who with G3ZHI had pioneered IPhone linking to GB3US from the start [3]. Even though he was able to activate his node for longer periods on an almost daily basis, both through GB3US and simplex on 2m, local opinion favoured it being available at any time and on a fixed frequency. Since the current linking NoV's require attended operation, this really excludes an individual running a 24/7 (24 hours a day, 7 days a week) node on practical grounds, unless an actual repeater licence is applied for. However, GB3US was already licensed for such continuous, unattended type operation, so, through the Repeater Management Committee (RMC), in early July 2001 the RA gave permission to connect GB3US as a 24/7 IRLP node, a week or so after GB3CL (Clacton) became a 24/7 IPhone gateway. Node 515 is connected to the internet via the University of Sheffield's high speed intranet system, and runs on a 120MHz Pentium I. Firewall problems had to be overcome by obtaining special permission to have the ports detailed in Table 1 opened for in-bound data. In fact port 23 could not be opened under any circumstances, and port 22 was only opened on the condition that the latest version of SSH was run.

At the time of writing, a few weeks after switch-on, activity has been high as people experiment with connections to different nodes. Fig 2 shows the marked increase in usage compared to the rest of the year and Fig 3 shows one of the busiest days, with a fair amount of night-owl activity. As mentioned before, most nodes are in North America, but there are a few in Dominica, Hawaii and Australia, the latter proving particularly popular from both sides. It has also been possible to compare IRLP linking to IPhone linking, and, although IPhone certainly has its place, IRLP seems to have the better quality and reliability. Its main advantage though is that link selection is in the hands of the radio operator rather than the gateway operator or the unknown occupants of a conference room.

6. The Future

Inevitably, there are some who view any type of linking as 'not amateur radio'. In one respect, they are correct, since a majority of the path is not via amateur radio, although, paradoxically, the majority may still be by radio, through a satellite link. However, they are missing the point, since the hobby is concerned with communication between amateurs using one, or a combination of, the various techniques available, linking being just the latest addition to the arsenal. The ability to be able to select a part of the World and then chat to a mobile station in Vancouver say on his way to work, whilst you are on your way home, with the same quality as a local QSO is a significant addition to amateur radio operating. Mobile HF operation does not provide anywhere near the quality and reliability, especially in urban environments. It is also nothing like a 'telephone call' since at both ends of the link the conversation is being broadcast to many other hams who often join in. There are already well over 100 active IRLP nodes and this number will continue to grow, giving an ever increasing choice around the World. Simplex linking via IPhone and ILink is fine for gateway operator supervised contacts. However with IRLP connected permanently, just sitting in the background, a repeater can be used locally, or with a few DTMF keystrokes people from much further afield can be included. It is therefore not nearly as intrusive as a permanent IPhone connection. The days of selecting, then talking to a fellow amateur on the other side of the World using a small, VHF/UHF hand-held have finally arrived, and are long overdue.




[3] Internet Linking via the GB3US Repeater, A.J.T. Whitaker, G3RKL RadCom, April 2001, pp39-40.



[6] RedHat Linux Secrets, Naba Barkakati, IDG Books Worldwide Inc.(2nd Ed) ISBN: 0-7645-3175-1







22 or 23

TCP (SSH/Telnet) for remote admin


UDP for IRLP audio (bi-directional)


TCP for control and update (bi-directional)

Table 1. Ports required to allow incoming packets









if [ "$1" = "12345" ] ; then

/home/irlp/scripts/info #runs info

exit 1



/home/irlp/bin/cosstate #checks if squelch open

if [ "$?" = "1" ] ; then #..if so, exits

exit 1


/home/irlp/bin/key #keys ptt line

/home/irlp/bin/play /home/irlp/audio/info.wav #plays wav

/home/irlp/bin/unkey #releases ptt

exit 0

Table 2. Syntax to tx audio file on down-link in response to DTMF 12345 rx on up-link