Compiled by Mike Morris WA6ILQ
Maintained by Robert Meister WA1MIK
| Back to Home |
The Internet Radio Linking Project (IRLP) Information Page Compiled by Mike Morris WA6ILQ Maintained by Robert Meister WA1MIK |
|
|
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:
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:
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.
| Pin | Use / Description |
|---|---|
| 3 | PTT |
| 4 | Aux pin 1 (active high at parallel port) |
| 5 | Aux pin 2 (active high at parallel port) |
| 6 | Aux pin 3 (active high at parallel port) |
| 10 | DTMF 4 (value 8) |
| 11 | COS/RUS |
| 12 | DTMF 3 (value 4) |
| 13 | DTMF 2 (value 2) |
| 15 | DTMF 1 (value 1) |
| 18 | Ground on port but not used on IRLP card |
| 19 | Ground on port but not used on IRLP card |
| 20 | Ground on port but not used on IRLP card |
| 21 | Ground on port but not used on IRLP card |
| 22 | Ground on port but not used on IRLP card |
| 23 | Ground on port but not used on IRLP card |
| 24 | Ground on port but not used on IRLP card |
| 25 | Ground 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)
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. |
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 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.
