Back to Home   The Internet Radio Linking Project (IRLP) Information Page
Compiled by Mike Morris WA6ILQ from a variety of sources 		  Print this Page


Note that the contents of this page, like most here at www.repeater-builder.com, are totally dependent on donations of information.
In other words, the repeater-builder web site and this IRLP web page is what the contibutors make it.
If you have a hint, or a useful trick, please consider writing it up and sending it in.

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 me know.
(contact info is at the bottom of the 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 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 200MHZ (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 on-board chipset or a 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 & 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 like PC Liquidator), plus have the advantage of better supported motherboard sound chips, readily available RAM, local USB ports (for file transfer using thumb drives, etc), etc.

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 the hard drive failure 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 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 wasted time used by the (unkey)(pause)(courtesy beep) 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, look at these off-site links:
    A ComputerWorld magazine article describing a 70 mile link over water, a second one from one snowy mountaintop to another, a third one that's a 21-mile shot.
    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.
    This is the preferred and most flexible connection arrangement, and also offers future enhancements. For example, if the repeater controller has a serial connection (ie. RS232) that supports remote programming a cable can be added from a COM port on the node computer to the serial connection on the controller and the controller can be managed via an SSH connection to the node computer.

  2. 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, jusr the node computer at one end and the repeater controller on the other). Directional antennas are not required, but are, in fact, preferred.
    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, 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 a point-to-point visibility to the repeater site and an internet connection.

  3. Locating the IRLP node at somewhere other than the repeater location, connected to a radio that talks on the repeater input and output just as if it was a regular user (which 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 (the most common technique is to install a CTCSS encoder on the repeater transmitter and control it with the repeater receiver COR, then run the node radio receiver in CTCSS mode). 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).
There are a couple of different ways to eliminate the noise burst heard on the node radio(s) when the other end unkeys.

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. It plugs into a standard drive connector, draws no power from the 12V connection, and less than 50ma from the 5v connection. Basically 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).

The IRLP card does not output any voltage(s) at any time. The PTT and AUX outputs act like a set of relay contacts with one side on the connector pin, the other side is ground. These "contacts" are implemented with high current MOSFETs with one side on the connector pin and the other side to ground. The MOSFETS 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. As to if the cabling can handle it, that is dependent on the conductors in your cable. It is recommended that if you are going to be switching a heavy load you need to use an intermediate relay. The board components are deliberately over-designed, and to a degree the copper traces on the 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 teh board and cable as if they had a 1 amp max rating). High voltage, like from a nearby lightning strike has taken out one or more of the MOSFETS. The PTT and three AUX outputs are driven by four IRF7313s MOSFETS. You can buy them in small quantities, even as singles in quite a few places.

The board has a 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 only pins 3,4,5,6,10,11,12,13,15 and 25 in the DB25 connector.

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.

Some scripts are 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 difference 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 http:/www.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.

Some node operators install a 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 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 phones home and notifies the central servers of 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. 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 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 is a good way to familiarize yourself with Linux (and how to NOT make stupid mistakes).

Randy Hammock KC6HUR is the author of many add-on script files. After he found this web page he wrote:

> I would like to offer my web site as an additional resource: <http://irlp.kc6hur.net>
>
> While it starts out somewhat geared towards my own nodes, it contains  
> plenty of info about the inner working of IRLP and has lots of free 
> downloadable scripts. It is becoming a bit dated because of work  
> commitments and I've been devoting much time working to integrate 
> IRLP with Asterisk operation. 
> I have recently converted my IRLP node into an embedded IRLP/Asterisk 
> node that does not require a soundcard or IRLP board.  The radio 
> interface is via $6 modified USB soundcard which actually talks to the 
> receive and transmit radios with Asterisk acting as the controller. The 
> radios are the only analog interface in the whole mess. The system even 
> has full duplex autopatch via a VoIP telephone provider.
>
> My total cost has been about $500 including rack, radios, computer, 
> duplexer and antenna. There is a photo here.
>
> The computer boots from a CF card then runs from RAM disk after  
> unmounting the CF card. The computer was the most expensive part $285  
> fully assembled, test and shipped, and the antenna was the next most  
> expensive item $148 after taxes. I paid $2.50 for the duplexer. $15  
> for the rack (30 years ago) and I traded for the radios. I'm using the  
> flat audio interfaces of the radios. The app_rpt chan_usbradio drivers  
> do all Pre-/De-emphasis, CTCSS encode/decode and Squelch in DSP.

Mailing Lists:
The main IRLP Mailing list is at http://groups.yahoo.com/group/irlp. 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 90% 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 read (and heeded) the pertinent page(s) at Gary McDuffies web site.

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 (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 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 a system function that is integral to Unix/Linux and lets you do certain jobs on a 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 1am on the date it becomes "Club meeting tonight at 8pm".

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 repeater can play any content that fits in a WAV or MP3 file... 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 "amybody know how to?" posting on the IRLP Yahoogroup will get you a LOT of help.

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.

Paul Cassel VE3SY has done am overview article on IRLP
a nice writeup comparing IRLP to the other internet linked radio systems, and
the introductory page to IRLP at eHam.

Robert Pectol KK7AV has a nice writeup on IRLP here.

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


Back to the top of the page
Back to Home



If you think of something that belongs on this page, let me know.
Mike WA6ILQ       (callsign) //at// repeater-builder //dot// com.
Yes the address is disguised a little since there are too many email address sinffer systems out there and I get enough spam as it is.

Thanks to Dave Cameron VE7LTD, Tony Langdon VK3JED, Gary McDuffie AGØN, Randy Hammock KC6HUR, Nate Duehr WYØX, and several others for their contributrions 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.