Back to Home   The Internet Radio Linking Project (IRLP) Information Page
Compiled by Mike Morris WA6ILQ
Maintained by Robert Meister WA1MIK
  Print this Page


This page was first made public in early December 2008 and as such is a work in progress.
Comments, critiques, contributions, etc. are encouraged.
If you think of something that belongs here, let the page maintainer know.


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 www.irlp.net) 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 http://www.irlp.net. 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 http://status.irlp.net.

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:

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.

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. Single-box-solutions are available from The Embedded Node from David Cameron VE7LTD, the inventor of IRLP.

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.

  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.
    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 24x7 - 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 (i.e.you 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 http://www.irlp.net/new-install/Ver3_Wiring.pdf. 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). 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 DE-9 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 DE-9 connector for the radio connection. The person building the node needs to supply the mating female DE-9 (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 DB-25 connector.
PinUse / Description
3PTT
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)
11COS/RUS
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)

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 Ports Type Used For...
2074 through 2093 UDP These ports carry the IRLP Audio and MUST be bi-directional
15425 TCP This port handles the IRLP Control/Update function.
At one time IRLP also used ports 15426 and 15427 but these are no longer needed.
See note TCP SSH - 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 https://portforward.com/. 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 Ports Type Used For...
21 TCP Downloading installation files (passive ftp)
53 TCP and UDP DNS inquiries
80 TCP For downloading updates (http)
2074 through 2093 UDP As mentioned in the above table these ports carry the IRLP audio packets
873 or 8873 TCP For downloading updates (rsync)
8245 TCP For determining routable IP address
10000 TCP IP determination. Not needed (or used) if the node computer has a static address.
12000 and 12001 TCP These ports are used only during the running of the IRLP Installation Script
15425 through 15429 TCP IRLP 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 24x7, 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 (stnNNNN.ip.irlp.net 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 http://garymcduffie.com/irlp. 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).

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

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, sourceforge.net/projects/audacity/.

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


Back to the top of the page
Back to Home



Thanks to Dave Cameron VE7LTD, Tony Langdon VK3JED, Gary McDuffie AGØN, Randy Hammock KC6HUR, Nate Duehr WYØX, and several others for their contributions and helpful comments on this page.

This page originally created and posted on 18-Aug-2008


Article text, artistic layout and hand-coded HTML are © Copyright 2006 and date of last update by Mike Morris WA6ILQ
All Rights Reserved, including that of paper and web publication elsewhere.

 

The Repeater Builder's site does not evaluate the accuracy of materials created by persons beyond its control or supervision.   Therefore, although this site links to many additional web sites, The Repeater Builder's site is not responsible for the availability of or the accuracy of any materials contained within those web sites.