The Internet Radio Linking Project (IRLP) Information Page

Click on the above image to go to the main IRLP web site – it holds the bulk of the IRLP documentation.

There is some contention as to the abbreviation “IRLP” and if it refers to the “Internet Repeater Linking Project ” or to the “Internet Radio Linking Project”. While the logo above (which I cribbed from should answer that question, you will find that most of the IRLP systems in service are attached to repeaters. Yes, there are simplex systems “out there”. Some folks feel that there are legality issues with simplex nodes. IRLP is a worldwide system and what is legal in some jurisdictions is not legal in others – but all the endpoints on the IRLP network are on amateur frequencies. I’m not going to address legalities on this page, just technical aspects. I’m also not going to touch on specific operational guidelines, as each repeater system is run a bit differently. There are, however, some overall operational guidelines that apply to all nodes.

The IRLP system is a internet-connected collection of radios and repeaters that was invented by David Cameron VE7LTD in Canada in 1997. The official information web page is at Each amateur radio repeater (or group of amateur radio repeaters) that participates in the IRLP system has a computer used as a bidirectional “bridge” between the radio and the Internet. The computers convert audio into Voice-over-IP streams and pipe them to another node computer somewhere else on the planet. With a system as large as it is there has to be a way to keep track of it, and the IRLP system status page does that job – it is at

By the way…. One of the requirements of IRLP is that the node has to be connected to a radio – either a repeater or a radio on a simplex channel. After reading all of the above, you may be asking why? Why can’t I just set up a node and plug an amplified speaker and a microphone into the sound card, and use the PTT button on the microphone as the COR?

The answer is: Technincally, you could do just that. Howevr, this is amateur radio, and both amateur radio and the IRLP is international in scope. Both amateur radio and the IRLP network is subject to international agreements which require that regulations in other countries be followed if the IRLP system is used there. In many countries the amateur radio rules require that the originating voice signal must be from another amateur. By making the hard rule that all IRLP traffic must originate from a locally received RF signal it prevents non-amateur operators from transmitting over amateur frequencies. It also promotes the use of radio in Amateur Radio, hence the IRLP motto “Keeping the Radio in Amateur Radio”.

The IRLP connection process uses authentication keys, usually called PGP keys. These are only assigned to users that support IRLP, either by purchasing IRLP hardware or by making a donation to the project. Donations need not be financial, but should benefit the network as a whole, not just a small group of users. IRLP systems authenticate using a public/private key pair. This pair of keys allows a secure method of determining the identity of a node you are calling. These keys are registered with the IRLP servers, and without the keys, there is no communication between nodes, or between nodes and reflectors. If a node is setup in a way that intentionally ignores the guidelines, or if a PGP key is determined to be obtained through fraudulent means, the PGP key will be removed, which will remove your IRLP node from the system. This prevents non-compliant systems from accessing the IRLP system.

Note that there are several situations that will trigger an automated email from one of the IRLP servers to the node owner. Each owner has a registered e-mail address (that can be updated on the STATUS page server). At least one of those situations will trigger a block on your node number. If you don’t keep your contact information there up to date, the first time you’ll notice a block is when the node announces that you can’t connect. So make it a point to use an email address that works (and you should check it occasionally), and that you check (and read!) that email account on a regular basis.

IRLP terminology:

  • Node: The collection of hardware that presents a radio system to the IRLP system via the internet. At the minimum it includes a receiver/transmitter, a computer running the IRLP software and a connection from that computer to the internet. Each node is different, and is custom-built to meet local circumstances and needs. Sometimes the “node” includes a router, maybe a node radio, maybe more. Depending on circumstances there may be a 2.4 GHz point-to-point link to bring the internet to the node computer – that would be considered as part of the node.

  • Node Computer: this term is used when you are specifically referring to just the computer at a node location and is covered in detail below.

  • Node Radio: The radio(s) used in the interfacing techniques 2 and 3 mentioned below.

  • Reflector: The telephone company offers 3-way calling in most areas, and that feature allows three parties to have a conference call. Well, an IRLP reflector allows an N-way conference of nodes, where N can be anything from 2 to well over 100. Another way of describing a reflector is to picture a internet “chat room”, but with people on radios instead of people on keyboards.
    A reflector is implemented with a computer running Linux and special IRLP reflector software. The reflector computer itself is not connected to any radio or repeater but rather runs a conference bridge program that implements 10 separate IRLP reflector channels (10 separate simultaneous conversations) at the same time. For example – reflector system 910 hosts reflectors 9100, 9101, 9102, 9103, 9104, 9105, up to 9109. Each individual reflector channel appears in the IRLP numbering system as if it were a node number, but those “nodes” are multiconnect, and are the node numbers of each individual reflector channel. Each reflector channel is as capable as any other channel – there is no advantage to being on (for example) channel 1 instead of channel 5 or channel 9. Reflector 9990-9999 is a unique, special case, see the “Echo Reflector” below.
    Reflector computers usually sit at large data centers that have big data pipes to the internet so that they can support the large number of connections (potentially several hundred connections on each of 10 channels). More info below.

  • Echo Reflector: This is like a software based repeater that records your audio and repeats it back to you 10 seconds later. You can talk to it and it will delay 10 seconds and loop it back to you. It is at address 9990 through 9999 and is used to set up node audio levels, or for node testing.

  • Script: A script, or script file, is a Linux/Unix version of a DOS batch file – a file containing a set of command lines and the system executes the script file line by line as if you were typing them in one at a time. The IRLP system software has a number of script files that collectively control the system behavior. One of the most modified script files is custom_decode – it handles DTMF decoding and determines how the individual node computer respondes to each DTMF command. Scripts are inherently open source, and are the most customiziable part of IRLP. Many nodes use the stock IRLP script files and never make any changes, other system owners spend the time to become familiar with the script language syntax (which opens the door to allowing you to make your IRLP node do exactly what you want it to). There are collections of add-on scripts for common situations, for example scheduling a net, for remote node management, using the node computer to ID your node radio, playing Newsline or ARRL news over the repeater, for disabling or enabling the node on a timed schedule, for connecting and disconnecting on a schedule, and more. There’s a script that implements a local DVR in your node so that you can let people actually HEAR just how bad that new radio actually sounds. There’s even a script that turns the node computer into a basic repeater controller, complete with a carrier delay (hang) timer, timeout timer, courtesy tones, etc. The IDer portion of the repeater script will ID the node AND optionally periodically play a wav file that has more information about the node, but only if COS has been inactive for whatever amount of time you choose to configure. Any combination of scripts can be installed and then modified to suit your specific needs. Or, since the scripts are plain text you can read through them, see what they do, learn the syntax, then modify them to there they do exactly what you want. Or you can write your own from scratch.
    Just remember rule #1 of script modifications: Never edit a script file without first making a backup of the untouched original script file…
    And in closing the topic of scripts, there are several scripts that are included in the IRLP system as tools – troubleshoot_irlpdecode and readinput are three of the major ones that are worth remembering.

  • Streaming Audio: Several repeater groups have web sites that offer a slightly delayed audio feed of their system audio on the internet so you can listen at home. This is NOT an IRLP feature – its a seperate function that can be added to most nodes if desired. One such group is the Western Intertie Network at – look in the left column, near the bottom. The Insomniac net at 23:00 Pacific Time is a hoot!

  • Codec: The term “codec” is a word that is a shortened form of the phrase “coder-decoder” which itself was derived from “encoder-decoder”. A codec is a software module that turns an analog signal into a bit stream and a different bit stream into an analog signal. The first ones were developed in 1958 (but first deployed in the field in 1961) to allow telephone systems to put multiple conversations down a single circuit (24 channels on a 1.544 MB T1 circuit). There are many codecs in use today, in telephone switches, cellphones, two way radio (IMBE and P25 are two), CD players, MP3 players, HDTV (where it does both video and audio), and more.
    Three codecs are used in IRLP, and the one used for any particular connection depends on several factors, including the node owners personal choice, or the currently available bandwidth, or the reflector involved in the connection (if a reflector is used). The three codecs are:
    1. GSM – (short for “Global System for Mobile communications“) This is the same algorithm used in the worldwide standard GSM cell phone system,
    2. ADPCM – (short for “Adaptive Differential Pulse Code Modulation“) A system of bit averaging to produce a high-quality 4-bit 8000 Hz stream, and
    3. UNCOMP – Uncompressed, true 8-bit, 8000 Hz sampling streaming audio.

  • Plus there are the terms that are familiar to any PC user, such as directory, subdirectory, etc.

There are two connection modes used on the IRLP network. You can establish a direct one-to-one link, or a one-to-many link via a reflector.

  • A direct connection is just like it sounds, where node “A” connects directly with node “B”. In this mode the two nodes (repeaters) are interconnected and no other IRLP connections involving the two nodes are possible. While “A” and “B” are linked, anyone attempting to connect with either node will be informed that “The node you are calling is currently connected to (node name / callsign)”. This message is generated within the node computer attempting the connection.

  • A one-to-many connection utilizes a reflector to connect many IRLP nodes together at one time. A reflector is required for anything but a one-to-one connection. As mentioned above, the reflector computer sits on lots of internet bandwidth and is capable of allowing many nodes to be inter-connected together by accepting the inbound audio from the currently talking node and streaming it back to all other connected nodes in real-time. This functions just like a huge telephone party line, with one difference – the reflector will not mix audio – it is a “first come, first served” type of system and the first node to talk can continue until he is finished or his node times out. So don’t even try to talk over him – it won’t work and you will not be heard.
    If you attempt a direct connection to a node that is currently connected to a reflector you will be informed that “The node you are calling is currently connected to (reflector name / channel)”. This message is generated within the node computer attempting the connection. At that point you can connect to that reflector and call him – but realize that you will be joining an in-progress “round table” conversation with an unknown number of other nodes.

The Node Computer:
The node computer is dedicated to the IRLP system and runs Linux. Linux is a free operating system that is based on Unix, which was designed from the beginning by AT&T with high reliability as one of the major considerations and remote management as a second. The Linux / IRLP system is so reliable that in many cases the computer, onece set up and running, it not touched for years. You will find many node computers at the repeater site, with no monitor, keyboard, mouse or any accessories attached. The node owner can connect to the node computer via its internet connection (or if he is on site, from a laptop), and do everything via that connection… I have seen several node computers that haven’t had any attention except to blow the dust out, to replace the CPU fan, or the hard drive (unfortunately moving mechanical parts do wear out). Some systems are configured so that the browser built into an internet-enabled cellphone can be used to control the node. Adding features like the cellphone control costs nothing but the time to install the features (but they are not supported by the IRLP support volunteers).

The hardware requirements for a node computer are not extreme, generally any 200 MHz (or better) Pentium class machine (yes, a Pentium 1 will work) with at least 128 MB of RAM, a 20 GB hard drive (or more), a supported sound system (either the on-the-motherboard chipset or a plugged-in sound card), an ethernet port (either on-board or a card) and a real parallel (printer) port (for the IRLP card to plug into) at the LPT1 address (378 and 379 hex) is enough.

On the other hand, these days, Pentium 3s and early Pentium 4s are common as mud in secondhand circles (or on eBay, or at used equipment dealers, or even the local thrift store), plus have the advantage of better supported motherboard sound chips, readily available RAM, local USB ports (for file transfer using thumb drives, etc), etc. As far as AC mains power goes, however they are hungrier than a P1 or P2.

Laptops in general have not been popular as node computers. It CAN be done, but, as I understand it, can be quite difficult. The biggest issue has been sound card compatibility, plus some have had problems with the parallel port (for the IRLP interface card), etc. Also, there aren’t as many laptops as desktops in the surplus marketplace, so the price is higher. Also, it appears that laptops aren’t as durable – as one person put it “laptops just aren’t designed for 24x7x365 operation in dusty mountaintop radio buildings”.

Desktops have a price advantage over laptops, plus some on-the-motherboard sound chipsets work fine, others sound really bad and end up being disabled and a higher grade sound card installed (which is very difficult on a laptop).

There are also “embedded” nodes that are built strictly for IRLP. They have no fans, no hard drive, boot off of a thumb drive or a flash memory card, and run strictly from RAM. Most use mini-ITX or micro-ITX motherboards that run directly from +12vDC, and normally run with no monitor, no keyboard and no mouse. These single-box-solutions are available from multiple sources – two that I know of are: The Embedded Node from David Cameron VE7LTD, the inventor of IRLP and The Micro-Node from K7IZA.

Originally the Red Hat flavor of Linux was used on the node computers, but they switched to Fedora when Red Hat was discontinued (after version 9). When Fedora’s rapid release cycle and forced upgrades were breaking nodes on a regular basis the IRLP system moved to CentOS (which is in fact a rebranded, free version of Red Hat Enterprise Linux). Each node is individually owned, and as such is subject to being heavily customized to suit the owners needs and environment. The setup of the IRLP node computer and the repeater controller needs to be well thought out as they have to play nicely and get along with each other. This means that the DTMF commands for one have to be ignored by the other. As a result any given node may use different DTMF commands from any other node.

As mentioned above, the node computer runs Linux. This scares off a large number of people as Linux is thought to be difficult to learn. But there’s no “requirement” to learn (much) Linux. In fact, the two most common Linux problems node owners have are:

  1. Installations going badly, usually because of hardware issues completely out of their control, for example the computer using an audio chipset that isn’t supported by the Linux distribution. A post on the IRLP yahoogroup frequently results in as much help as the person can use.

  2. Backups, or lack of them. No one does them. The self-inflicted lack-of-a-backup problems are totally unnecessary. It needs to be highlighted more in the docs that a nice working backup system comes already built-in,, and if you use it BEFORE you need it you can recover your own node when (not if, when) the hard drive fails or other problems occur.

One needs VERY little Linux knowledge to run a “stock” IRLP system. Used as designed, it rarely needs anyone to log in or mess with it. It comes up fully operational, and like most Linux systems just plain works.

Hardware and Interfacing:
There are several ways to interface the node computer to a repeater or a simplex radio. However it is done the connection method MUST prevent all courtesy beeps and IDs from being fed to the IRLP computer (and from there to the internet and to the far end node or reflector).
I repeat: In order for your IRLP node to work properly, you must ensure that there is nothing but the actual voice audio is sent down the IRLP connection. Why? Picture the scenario where a large number of nodes are connected together (on a reflector) for a long period of time. After every unkey the system’s controller, pauses, then goes “beep”. Every 10 minutes each repeater has to ID. If every nodes courtesy beep and ID was sent to every other node connected to the reflector the result would be that every node would be carying almost nothing but beeps and IDs from the other systems (remember – reflectors don’t mix audio). Don’t think that can happen? At the time I was creating this web page I looked at this reflector usage page. Reflector 9453 had 60 nodes connected. That would be a lot of courtesy beeps – and if each ID took 3 seconds that’s a worst-case scenario of 180 seconds (3 minutes) of every 600 seconds (10 minutes) taken up with just the IDs. And we haven’t considered the time that is wasted by the (unkey)(pause)(courtesy beep)(pause) from 60 different repeaters.

The three most common interfacing techniques are:

  1. By using a multiport controller on the repeater itself, with the repeater on one port and the IRLP node computer hard wired to another port. All it requires is a multiport controller and an internet presence at the repeater site. Multiport controllers are not rare, even the 30-year-old ACC RC-850 can do it. New ones are not expensive, look at Scom, ICS, Arcom, NHRC, and there are others.
    Some repeater sites have an internet presence right at the repeater site, some amateur groups bring the internet to the site just for the IRLP box via a 2.4 GHz or 5.8 GHz wireless point-to-point link. And long distance internet links are possible, up to 70 miles. Look at this offsite link:
    from one snowy mountaintop to another
    No matter how the internet gets there, the controller treats the on-site IRLP computer as if it was a locally installed remote base radio, complete wth PTT, COR, and audio both directions.
    Computer Automation Technology has a very good diagram of the connections in their Note #14 file. I added a few comments to the bottom of the image. The original web page is here
    The connections are similar if you are using a different controller, however you will have to adjust the pinouts and connectors.
    This directly wired connection is the preferred and most flexible arrangement, and also offers future enhancements. For example, if the repeater controller has a serial connection (ie. RS232) that supports remote programming then all it takes is a cable from a COM port on the node computer to the serial connection on the controller. Then use a SSH connection to the node computer, and a terminal session to the COM port and you are taking to the controller. The two 10K pullup resistors may not be neded at all if your controller has pull-up resistors in place to start with (many of them do).

  2. The second method is similar to the above, but with the IRLP node computer located somewhere other than the repeater site and bringing the node computer audio to the second repeater controller port via a dedicated point-to-point link radio (that carries just the bidirectional node audio).
    The point-to-point link is made up of two radios on a 222 MHz, 420-430 MHz, 900 MHz, or 1200 MHz dedicated link channel (no users on the channel, just the node computer at one end and the repeater controller on the other). Directional antennas are preferred, but not required. It could even be an E&M channel on a commercial microwave system.
    The repeater controller handles the on-site link radio as if it were one end of a leased 4-wire audio circuit (plus PTT and COR) that carries the IRLP audio between the repeater site and the IRLP computer. The point-to-point link can run in simplex, half duplex or full duplex mode, however you really want to run this link in full duplex if possible, mainly so that you can disconnect your node (if necessary) in the middle of another nodes stuck transmitter, a NewsLine playback, or someone’s monologue. With this setup the node computer can be anywhere there is an internet connection and point-to-point visibility to the repeater site.

  3. The third method is the least desirable, but probably the most common. This is where the IRLP node is located somewhere other than the repeater location and connected to a radio that talks on the repeaters regular input and output just as if it was another user (the radio in this setup is frequently referred to as a link radio, which is an incorrect usage of the term “link”). This method of connection requires modifications in the repeater itself to preclude courtesy beeps and IDs from being sent to the internet. More notes on this below.
    Overall, this is the least desirable technique since you can’t interrupt the node and shut it off – you have to wait for it to time out, or for the party at the far end to stop talking.
    DO NOT USE THIS METHOD WITHOUT THE ASSOCIATED REPEATER MODIFICATIONS to preclude the courtesy beeps and IDs being sent to the far end node (or reflector).

Note that the radio(s) used in methods 2 and 3 need to be interfaced to the repeater controller or the IRLP card. Some radios interface easier than others.

Another issue – and a big one – on radios used in IRLP link service is duty cycle. Spending some extra time selecting the radio is cheaper than repairing or replacing a radio that burned itself up. Most ham-grade radios will not survive long IRLP sessions night after night, even if you put a fan on them and are switched to low power mode. One tip: use beam antennas and low power radios with large heat sinks. Use radios that automatically throttle themselves back when they get hot (some do, some don’t). For instance, the Motorola Maxtrac radios do not have a thermal sensor on their heat sinks, the later M10-M120-M130-GM300 series do. The same M and GM series come in both 25w and 45w models. Due to the fact that the 25 watt units have the same heat sinks as the 45 watt units they handle the high duty cycle much better than the 45 watt units. Yes, the author of this article is partial to Motorola because he has a commercial two-way background in that manufacturers products, but there are other radio manufacturers that make comparable products. Just look ahead when you select the radio. Murphy will come visiting.

Whatever radio(s) you use for the #2 and #3 methods above, make sure that there is adequate cooling on the heat sinks. If you chose to add a fan you will not want it running 24×7 – use a snap-action thermal switch bolted to a fin on the hot end of the heat sink to control the fan. Think ahead and ask yourself what the most likely failure mode will be, and build the equipment to preclude it. Design the system to minimize the chances and effects of hardware failure.

Another example – a designed-for-ham-radio unit like the Yaesu 1500 mobile… it is a favorie of the APRS crowd because of the performance, the price and the ease of interfacing. It has a good reputation from that, so someone decides to try it on IRLP. But they forget the APRS is a low duty cycle application. The 1500 is a designed-as-a-mobile-ham-radio low duty cycle unit. It is easily interfaced using a cable made from the plug end of a 6 conductor PS2 keyboard extension cable plugged into the packet connector on the back. Then you select the 1200 baud mode so that the transmitter pre-emphasis and receiver de-emphasis is set up properly.

Then one day someone dials up a busy reflector (like the Western Intertie system, or a shuttle mission) to monitor it for a long net. The incoming IRLP traffic will cause the FT-1500 to transmit continuously as long as it is receiving from the opposite end of an active connection. Even if fan cooled it is not designed for an extended duty cycle. A busy reflector can keep your local radio in the transmit mode for very very long periods as you monitor. If that is your goal I would look for a radio rated for 100% (continuous) duty cycle… something like a MASTR II or MSF5000 station. They are available in anything from 12w to 100w.

There are a couple of different ways to eliminate the noise burst heard on the node radio(s) when the other end unkeys. The most common is to have the tone encoder on the radio that is talking to the IRLP node follow the repeater receiver COR. Then run the receiving link radio in full time tone squelch (i.e. CTCSS receive). Program the repeater controller to have the delay from tone encoder unkey to the start of the courtesy beep longer than it takes the link radio to squelch ( want the audio from the link radio to already be muted before the repeater courtesy beep starts).

The IRLP Hardware consists of a card that plugs into the computer parallel port. The card is 90% digital and 10% analog, and the analog part is an INPUT only. The digital side of the card has a COR input, a PTT output, and three AUXiliary outputs. The analog side is a hardware touchtone decoder. The connection information is at The IRLP board plugs into a standard drive power connector, draws no power from the 12 Volt connection, and less than 50 ma from the 5 volt connection. I repeat in different words: The IRLP board does not use 12vDC, it uses only 5vDC. I know of one board that was blown up because the system integrator assumed that everything ran on 12vDC.

The “line out” and “line in” connections on the computer sound card are treated as audio to and from the repeater, and the COR, PTT and DTMF decoder are interfaced using bits on the computer printer port. All of the “heavy lifting” is done by the IRLP interfacing card and the associated driver modules. Yes, the current IRLP system requires the system to have a real printer port (none of the USB-to-parallel-printer adapters). The most common wiring error is that people forget that the node radio audio output has to feed BOTH the node computer LINE IN jack and the DTMF decoder on the IRLP board (and at the proper levels for each one). “No DTMF decode” is one of the “top ten” errors discussed on the IRLP yahoogroup – since all DTMF decoding is done on the IRLP card (not the sound card) you need to run the receiver audio to it. And there is a script to test that: “readinput” can be run anytime to make sure the DTMF is being heard by the card.

Some motherboard sound system (and some sound card designs) only support MIC IN situations, and not a LINE IN. Others have both, or have “soft jacks” that allow one input jack to be re-assignable in the sound card driver setup. If you have a situation where the input jack is only a MIC IN, you may want to either disable the motherboard sound and install a sound card, or just use a different computer. The problem with MIC IN is that it usually includes an extra stage of gain, plus that gain is variable (google the term “automatic gain control”, or AGC), and usually the AGC is not adjustable or defeatable. The variable gain of the AGC makes your over-the-air audio sound really bad, plus making the input level adjustments (matching the input level) much more difficult.

There are two jumpers on the IRLP card. One sets whether the COS signal from the receiver is active high or active low. As you integrate your receiver and the computer it’s easy to test – just have the COS LED off with the receiver squelched, and on with it unsquelched. If it’s backwards, swap the jumper.

The IRLP software looks at the COS signal and behaves appropriately… such as muting and unmuting the receive audio, etc. The node computer does not decode DTMF, does not generate any data packets, etc. unless the COS signal is active. As an aside, this means that the audio from the radio does NOT need to be squelch muted.

The other jumper (“PTT LOCKOUT”) tells the IRLP software to look at or ignore the COS signal during transmit. Some radios produce COS during transmit, and this prevents them from causing problems in the network. If your node is hardwired to a repeater controller (common), or has a full duplex RF link (rare), switching that jumper allows the DTMF decoder to respond to commands while the node is transmitting. The node itself is still half duplex. The board ships with the jumper set (feature on), and that is always correct for a simplex node or half duplex link. Basically, if your node can hear DTMF while it is transmitting, then it is okay to turn off the PTT LOCKOUT (which would let you interrupt and disconnect from a long monologue or a playback like ARnewsline).

Think of the PTT and each AUX output as being one side of a set of relay contacts that switch to ground. These “contacts” are implemented with four IRF7313s MOSFETs. Each MOSFET can handle about 30 volts at 6 amps each, however, the traces the on circuit board CANNOT handle 6 amps nor can the DB9 connector pins. High voltage, like from a nearby lightning strike has taken out one or more of the MOSFETS.
As to if the cabling can handle it, that is dependent on the conductors in your cable. I’d recommended that if you are going to be switching a heavy load you need to use an intermediate relay. The board components are deliberately overdesigned, and to a degree the copper traces on the IRLP PC board are as well. While you can melt a trace or destroy a MOSFET if you work at it, the conductors in the cabling are probably going to be the fusible item. It’s much cheaper to replace some cable than the entire IRLP board (personally, I’d prefer to treat the board and cable as if they had a 1 amp max rating). If you do blow one, the MOSFETs can be purchased from quite a few places in small quantities, even as singles.

The IRLP board has a single male DB9 connector for the radio connection. The person building the node needs to supply the mating female DB9 (and the shell) plus the cabling to the sound card and to the radio(s). The cable from the card to the computer is a regular parallel printer cable, and uses a minimal set of the pins in the DB25 connector.

PinUse / Description
4Aux pin 1 (active high at parallel port)
5Aux pin 2 (active high at parallel port)
6Aux pin 3 (active high at parallel port)
10DTMF 4 (value 8)
12DTMF 3 (value 4)
13DTMF 2 (value 2)
15DTMF 1 (value 1)
18Ground on port but not used on IRLP card
19Ground on port but not used on IRLP card
20Ground on port but not used on IRLP card
21Ground on port but not used on IRLP card
22Ground on port but not used on IRLP card
23Ground on port but not used on IRLP card
24Ground on port but not used on IRLP card
25Ground on port and this one is used

One of the most useful tools for debugging an IRLP setup is a set of inexpensive amplified computer speakers (frequently available for free, new is about US$20) and a home-made “Y” cable that feeds one of the speakers with the sound going TO the computer and the other speaker with the sound coming FROM the computer. You will be able to listen to what is happening – not guess. And when you are not physically at the node computer you can leave them connected, just power them off.

The version 2.x boards do not have the three AUX outputs, the version 3.x and later boards do. It is very rare that a version 2.x board shows up in the second hand market as only 200 were made. The AUX outputs can be useful – some scripts are / were written to key the transmitter on and off (for example, an IDer script). Due to the IRLP system internals, these are generally written to switch one of the AUX outputs instead of the PTT, then that AUX output is wired in parallel with the PTT lead. The convention has been to use AUX1 as the first slave PTT, and AUX2 as the second (if needed). Non-slave-PTT outputs (like one used to control a transmitter cooling fan) have used AUX3 first, then AUX2.

Routers and Network Concerns:
Due to the fact that good quality audio requires about 60-90kb bandwidth it is not practical to try and operate an IRLP system over a dialup connection. Many radio sites have DSL available, but the pricing varies. Some local phone companies see a radio site as a business, some automatically give residential pricing to amateur radio groups. The determination between business and residential depends on a set of circumstances – Pacific Bell has a simple test: is there a kitchen, a bathroom and bedroom?   Does someone live there?   If all four are answered yes, that location qualifies for residential service, unless you are a ham, then this applies (and it dates back to the 1980s).

Back to IRLP:
Linux was designed from the outset to be directly on the Internet with a public IP address assigned by the Internet standard dynamic address assignment system (called DHCP). That’s right, IRLP nodes are already hardened and can live without a router or a firewall. The only reason to put a node behind one is if you are forced to share a single public IP address with other machines (most residential DSL / cable TV modem situations).

The IRLP network has the mechanisms built in to handle ISP-assigned dynamic IP addresses just fine. Your IRLP node checks it’s own public address every so often and if it changes your node “phones home” and updates the master list.

I repeat – IRLP is designed to NOT require a router between the node computer and the ISP modem, but can live quite happily with one. Since many nodes live as an additional computer at a location – perhaps at someones house, at a business, or at a radio site. As such, there are certain “rules” that have to be followed before the node will work. One is that the node computer needs to have a static IP address between itself and the router, and as such the DHCP range of the router needs to be adjusted to make a little room for locally static addresses.

One of the hats I wear says “network support” and my personal preference for setting up a local consumer-grade router at a home or small business is: (where x.y.z is 192.168.something, or some variant of 10.something.somethingelse)

  • x.y.z.1 is the router.   If for some reason it can’t be, then I use .254 or .253
    One series of AT&T DSL all-in-one modem/routers (made by “2Wire Co.”) use .254 out of the box. On those systems I leave it on .254 and .1 just isn’t used.
  • x.y.z.2-9 is reserved for local servers, if any.
  • x.y.z.10-29 is reserved for network connected printers (or print servers), if any, since they need a static address.
  • x.y.z.30-49 is reserved for non-printing static devices (this is where managed ethernet switches, the IRLP node computer and any VoIP phone adapter(s) would go).
  • x.y.z.101-254 (or 101-253, depending on where the router is) is the DHCP range (where all the other computers are).

If you need more static devices you can bump the 49 higher. If you need more DHCP devices you can bump the 101 lower.

Once the IRLP node computer is talking to the router you need to set up the ports that the router forwards to the node computer. Some people use the DMZ function of the router, others specifically forward the ports. However it is done, the following ports need to be forwarded to the static IP address that is the local IRLP node computer:

Inbound PortsTypeUsed For…
2074 through 2093UDPThese ports carry the IRLP Audio and MUST be bi-directional
15425TCPThis port handles the IRLP Control/Update function.
At one time IRLP also used ports 15426 and 15427 but these are no longer needed.
See noteTCPSSH – Defaults to port 22 BUT YOU WILL WANT TO CHANGE THIS !! This port is only required if you install the remote admin function. DO NOT RUN THE REMOTE ADMIN ON PORT 22 – it can be ANY TCP port.

The above list will setting will handle 99 percent of all installations and nothing else should have to be done for the system to work. If you can connect to 9990 and get audio back, then 9991, then 9992, then 9993, and repeat that up to 9999 and it all works then you are pretty much set to go.

One useful resource is http:/ Just select your router by manufacturer and model (skip any advertisements), select IRLP, and just follow the directions.

For those behind more stringent firewalls, the following ports are also used:

Outbound PortsTypeUsed For…
21TCPDownloading installation files (passive ftp)
53TCP and UDPDNS inquiries
80TCPFor downloading updates (http)
2074 through 2093UDPAs mentioned in the above table these ports carry the IRLP audio packets
873 or 8873TCPFor downloading updates (rsync)
8245TCPFor determining routable IP address
10000TCPIP determination. Not needed (or used) if the node computer has a static address.
12000 and 12001TCPThese ports are used only during the running of the IRLP Installation Script
15425 through 15429TCPIRLP control

All of the above port forwarding concerns can be avoided by placing the node computer on the “outside” of any firewall – and the fact that IRLP is designed for that should be stressed if you are going to be locating a node at a hosting agency (like at a local government owned Emergency Operations Center). Just point out that your node will NOT be a security concern to their IT department by specifing that you want to be on the outside of their system and outside their firewall on the raw internet. All you need is a public IP address (and while it’s preferred, it doesn’t even need to be a static address – see below for some addressing comments).

Some node operators install a e-mailer program onto the node computer so that it can send an email to selected persons if there is a problem. These systems will require the SMTP ports to be available, and some script modifications. Additions like this are not directly supported by the IRLP support volunteers, and as such require the node owner to have familiarity with both SMTP and Linux (or to have someone available who is).

The remote management feature of the IRLP package requires the installation of web hosting software on the node computer. Since the node computer operates 24×7, is connected to the internet via broadband and has web server software installed some clubs have decided to have the node computer host the amateur radio club web site. Some ISPs have a rule about having any kind of a server connected to a residential connection.
If you put the club web site on the box (which works most of the time since clubs are small and the traffic is so low) just make sure you are not leaving youself open to a future ISP terms-of-service hassle.

ISP IP addressing:
IRLP handles the common ISP dynamic IP addresses just fine with its own built-in name resolution mechanism. The node computer checks it’s own internet connection IP address every 15 minutes and updates the IRLP servers if it has changed (yes, the IRLP box “phones home” every so often). The thing to avoid is ISPs that spin the IP addresses at an insanely rapid rate (like every 10 minutes). Any standard dynamic IP connection will work perfectly fine for IRLP. You may want a static hostname for remotely logging into the node using SSH, as a backup in case the IRLP provided system ( where NNNN is your node number) falls over at the time you need to use it. In an ideal world, your connection from the internet to your location would have a static address. Some ISPs charge extra for that, some do not.

Due to the fact that the IRLP node periodically phones home and updates the central IRLP servers with its IP address you can only run one node per IP address. Most residential Internet connections are limited to a single public IP address at a time. If your ISP will deliver additional IP addresses to you then you could place an additional node on each additional IP address. A second address (if available) sharing the same bandwidth, should be pretty cheap, but some ISPs have poorly thought out policies. It all depends on you, your ISP and what you can negotiate.

Other web sites:
Besides the main IRLP web site, Gary McDuffie AGØN has an EXCELLENT web site full of good reference info for the IRLP newbie (as well as the old hand). It’s nicely organized by topic. Check out Note that there is no “www” on the front of that URL.
Every new node owner should be forced to read his web page from one end to the other BEFORE his first posting to the IRLP yahoo group. The very first page at his site “After Installation” has some good instructions that will save the newbie node operator some serious grief. See here. And that’s just the first page.
IRLP is the first exposure that many hams have to Linux. As a result there is a learning curve. Reading what Gary McDuffie has written (including the other pages linked from his main page) from one end to the other (before you start) is a good way to familiarize yourself with Linux (and how to NOT make some stupid mistakes). Over 90% of the problems that a newbie to IRLP will run into are already covered at Gary McDuffies web site. All that a newbie needs to do is to read, reread (and heeded) the pertinent page(s).

Mailing Lists:
The main IRLP Mailing list is at It is intended mainly for node owners but all who are interested are welcome. Most of the discussion on this list is technical topics involving the IRLP software and scripts, radio interface connections, router configurations, and other issues within the IRLP overall system. The inventor / developer and many of the IRLP support volunteers are regulars on this list, and therefore it is a excellent resource for solving problems. HOWEVER the list members expect some familiarity with the IRLP system, with editing scripts, with computer hardware, and how the IRLP node computer is interfaced to the repeater or node radio, etc.

I REALLY, REALLY SUGGEST that anyone use the search feature in the YahooGroups system to look for previous mentions of any new problems. I guarantee you that over 95% of the problems posted have been seen before (like a new installation can’t get any audio through). I can’t tell you how many times I’ve read of a problem that could have been prevented if the node owner had searched th eyahoogroup archives.

One of the things that comes up on a regular basis is due to the fact that the IRLP computer is so reliable that it gets forgotten until it fails. Then the node owner fixes or replaces the computer, reinstalls the IRLP software, and he gets a new node number, then he emails the support volunteers to get his old number back. This hassle (and many others) could have been prevented if the node owner had done one simple thing: after your new node is up and stable, wait a few days, or even a week (to make sure is really is stable) and then run the backup_for_reinstall script and copy the files it creates to a different system (or even to a thumb drive). Then burn a CDRW (or two) with those files and put it (along with the original IRLP install CD, or a copy of it) inside the node computer case where you know you can find it, even if it is years later.
If you modify the node to where it is non-stock (perhaps by adding an optional script, or two or three) then run the backup again, and copy the new files (and the script directory) to the different system and reburn the CDRW(s).

Other Tricks:
Since the node computer is running Linux (a dereviative of Unix) it means that you can add what are called “cron jobs”. “Cron” is short for “chronometer” and is a system function that is integral to Unix / Linux and lets you do certain jobs on a fixed date and / or time schedule. Cron jobs are easy to create and when coupled with the “send DTMF” program, or the “play a sound file” program allow you to send commands to the repeater controller from the the IRLP node on specific dates and at specific times (like August 1st at 7pm), or on a schedule (like on every Last Tuesday at 1am: “Club meeting a week from tonight”, then on the day before the club meeting chage the message to “Club meeting tomorrow night at 8pm”). then at 00:01am on the date it becomes “Club meeting tonight at 8pm”,and then at 7pm the last chron job sends the message cancel command.

Since the node computer can send DTMF you could have it send specific strings to command the repeater controller to turn off the timeout timer and change the courtesy beep, such as for a net, then put things back to normal when the net is over.

Most repeater controllers can send a DTMF strings. The node computer responds to DTMF commands and can play sound files. Put thse together and you can have announcements that use words that are not in the repeater controllers speech vocabulary… the node can play any content that fits in a WAV or MP3 file through the repeater… including local public service event announcements like “Don’t forget the Frontier Days Parade at 1pm this saturday”, or scheduled net announcements such as “Red Cross Disaster Communications net on this channel at 7pm Tuesday (and then change the message to “tonight” and then to “…in one hour”, and again to “…in ten minutes”).

If your repeater controller has a serial port (also called a RS-232 or COM port) you can cable a serial port on the node computer over to your repeater controller, and command the repeater controller silently over the RS232 cable (no DTMF involved). You can connect through the node computer to it, just as if you were sitting at a laptop and at the repeater site… this means that you can program (or reprogram) the repeater controller from anywhere that you can access the internet.

Once you have a stable IRLP node that you can remotely manage (i.e. from your home system over the Internet) then the ideas start to come… “but we can set the node up to (insert idea here)”…

The possibilities are only limited by your time, inventiveness, desires and equipment capabilities. You could even automate the download and playing of the entire ARnewsline if you wanted to… And if you get stuck, a “anybody know how to?” posting on the IRLP Yahoogroup will get you a LOT of help.

One of the first enhancements that many node owners like to do is to create new “connect and “disconnect” audio message files to replace the default “Node NNNN Link Active” and “Node NNNN Link Off”. There is one requirement that almost everyone overlooks – the audio format. The native format for many PC, Mac and Linux systesm is 44 Kbps stereo. The format that IRLP requires is a mono 8-bit file recorded at an 8 Kbps sampling rate. This results in a file that should be 8 Kbytes per second of audio. In other words, a four second announcement will be 32  KBytes. There is a free program called “Audacity” that will work just fine for the reformatting of the file, or even for the initial creation. There are versions of Audacity for all OSes. It is not particularly pretty or easy to use, but it will work for recording or editing. It can be found at Sourceforge,

Other articles:
Don L. Blanchard, WA7GTU wrote an article on connecting a Motorola GR1225 station to an IRLP repeater. It’s on the Motorola page at this web site.

QST had a generic VOIP article in the Feb 2003 issue.

QST had a one-page article oriented towards emergency communications in the May 2003 issue and it mentioned IRLP.

QST had a two-page introductory article on IRLP and mentions simplex nodes.

Worldradio, Popular Communications and a few other magazines have had a few articles, but I don’t know which issues they are/were. If anybody has scans (or PDFs), please let me know.

Wikipedia, the free encyclopedia, has an introductory writeup on IRLP.

Setting Audio Levels on an IRLP node   From an email thread…

Deja un comentario