Introduction To IRLP
The Internet Radio Linking Project
|
To Engage Multimedia Mode Press Play |
This portion of our website was prepared with the help of David Cameron, VE7LTD, IRLP Designer.
What Is IRLP?
The Internet Radio Linking Project was started back in November of 1997 as an attempt to use the internet to link radio systems across Canada. The first full time link that was established ran from Vancouver, BC to Saint John, NB. The link had many problems and was shut down in March of 1998 due to the numerous computer crashes and repeater lockups it was causing, and the lack of user control over the system.
I set out to design a better way to use the same technology to perform the same task, while improving usability, user control, and sound quality. My first breakthrough was to replace the existing operating system, Windows, with a more stable and versatile language. I chose Linux, an open source form of the operating system UNIX designed by Linus Torvalds, because of its superior networking characteristics, its reliability, and its ease of programming.
I designed my own interface board to interface the radio to the computer. This allowed a large amount of delay to be removed from the system because two VOX circuits were no longer being used . I also wrote my own custom control software, and modified an existing voice-over-IP software package to accommodate the project.
The final product was a combination of hardware and software that created a nearly seamless radio link between two remote sites on the internet. The product works so well that many people can not believe that they are talking through a link at all!
How It All Started
Back in December of 1996, I was flipping through the many magazines at the UBC club. I came across the December 1996 issue of the QST Amateur Radio magazine that had the words "Link your repeater to the Internet" written on it. I had a quick read through the issue and found a well written article by James Millner, WB2REM entitled 'A New "Band" for Your Radio'. At first glance, I was hooked. What more could I ask for? It was a combination of the two hobbies that I love the most.
My first connection used VocalTec's Iphone. The original article by WB2REM used Iphone to send the voice over the internet. I did have some problems with the software, mainly in the fact that Iphone is not very stable nor is it controllable. After running Iphone for close to 6 months on active connections to Vernon BC and St. John NB, I decided that the stability and control were key. That is when I started getting into using LINUX as an operating system and Speak Freely as a client/server.
Speak Freely is a voice over IP client/server package that transmits live audio (i.e. speech) over the internet with surprising clarity and quality. This program basically allows any two parties anywhere on the internet to have a voice conversation with each other in real time. My objective, and the objective was to use this program to link to radio equipment so that voice connections can be made without the operator being tied to a computer. This will allow hams from all around the world to talk to one another without relying on radio conditions.
Many amateurs have raised a very important question regarding this kind of system; What if non-ham users start connecting to ham repeaters? With all the experienced "hackers" out there, I can not say that this system is totally bullet-proof. I have designed safeguards into my software to reject calls from "non-hams".
The main hurdle I had to overcome was the interface between the computer and the radio. From my experience with VOX circuits under Iphone, I decided that I HAD to find an alternate way to start sending audio and to key the radio when audio came in (from the internet side). Since the source code for Iphone was not available, I had to look for an alternative. I was told about Speak Freely by a friend of mine, and I decided to give it a try.
I played around with modifying the source code for several weeks and finally came up with some code that works. The software starts the link radio transmitting once packets have been received over the internet and unkeys once they stop coming in. The software starts sending audio once a signal is received and continues to send it until the signal is removed. This logic control is performed using the parallel port of the computer and all the computer chips are on a separate interface controller board. I have designed this board, and I am building them and selling them at cost to promote the project.
The whole system is DTMF controllable. The control codes lie imbedded in a separate program that reads the DTMF tones from the decoder chip (located on the interface controller board) and activates various parts of the software. DTMF codes are used to enable/disable linking, open/close links and set identifiers. Every site will have the ability to connect direct to any other site(s), either using direct connections or reflector sites.
So in a period of 8 months, I switched from a piece of software and hardware that someone else built, to my own creation which solved all the previous problems I was experiencing! Ever since the IRLP started, I have never again looked to Iphone or Windows for an option in the system.
How Does IRLP Work?
The IRLP uses a Voice-Over-IP (VoIP) streaming software called Speak Freely. Speak Freely is very similar to other VoIP software packages (such as Microsoft NetMeeting and VocalTec Iphone) with one difference... It runs under Linux.
Linux is the operating system of choice for the IRLP system as it allows the best in reliability, programmability, efficiency, and functionality. Most IRLP nodes use Linux RedHat 7.3 or RedHat 9 as they are very stable releases and run very smooth on any P1 or better computer. Effective December 2004 IRLP started shipping the open sourced Fedora Project Core3 version of Linux. This release provides greatly improved operation with more support for audio cards.
The concept of IRLP's use of VoIP is as follows:
1. Sample the audio using an analog to digital (A/D) converter. The A/D converter used by IRLP is the input source of a standard PC sound card. This creates a continuous mono 16-bit digital stream of raw audio at 8000Hz (120000 bps).
2. Compress the audio by downsampling the stream and using an 4-bit ADPCM algorithm to reduce the size of the stream by a factor of four (32000 bps)
3. Split the sample into small chucks (or packets).
4. Transmit the packets to the remote host using a User Datagram Protocol (UDP) stream. UDP does NOT confirm the reception of packets, so it uses a "fire and forget" method.
5. Receive the packets on the remote host.
6. Join the split packets back into a 4-bit ADPCM stream.
7. Uncompress the ADPCM stream back into an 16-bit raw stream of audio.
8. Play the raw audio stream through a digital to analog (D/A) converter (the output device of your sound card).
The control software controls the stream using carrier operated squelch (COS) or continuous tone coded subaudible squelch signals (CTCSS) to start and stop the stream. When COS is present, the computer detects it through the IRLP interface board.
The PTT is controlled by the buffer which joins the split packets back into the audio stream. The IRLP interface board receives a "transmit" signal from the computer while there are packets in the buffer, and a "unkey" command when the buffer is empty.
The user interfaces to the IRLP computer using DTMF signals sent over the radio. DTMF sequences are owner programmable, and can accomplish almost any function imaginable. The DTMF signals are detected on the IRLP interface board and sent directly to the computer in binary, where they are converted into numbers. A DTMF software program which I wrote then runs commands on the computer depending on the code entered.
These commands are what start and stop Speak Freely, basically establishing and breaking the link.
And that is, in a nutshell, how IRLP works.
Typical Node using a repeater configuration
Typical Node in a SIMPLEX configuration
Hardware Requirements
Computer
Operating System
IRLP now ships with Fedora Core 3, the open source project of Redhat EL. The custom version we provide is very small, only 175 megabyte on the CD which installs to about 400 megs. (Help with CD and over-the-net installs can be provided.)
RF Hardware
Link radio or repeater (the radio must have a COS {carrier operated squelch} signal)
If the link radio is to be connected directly to the input/output frequencies of a repeater, the repeater MUST not have any hang time or courtesy tone. This can easily be accomplished using CTCSS on the repeater transmitter that follows the COS of the receiver.
Other Hardware
IRLP Operating Guidelines
As with any new technology, it does take some time to adopt to operating procedures that differ from conventional FM repeater use. This work in progress can serve as a guideline for those wishing to use their local IRLP enabled repeater node.
Common Modes
There are two connection modes for an IRLP connection. Direct one-to-one or, one-to-many via a Reflector.
Direct connect is just like it sounds where repeater (node) "A" connects direct with node "B". With this type of link the two nodes are interconnected and no other IRLP connections are possible. While repeaters "A" and "B" are connected, anyone attempting to connect with either node will be told by a recording that - "The node you are calling is currently connected to callsign" however all local traffic on each repeater will be heard on the other repeater as well.
While Direct Connect is preferred for a city to city chat, the most common type of connection in use today is via the Indianapolis Reflector (Ref 9200). A reflector is a Linux computer that is not connected to any radio but rather sits on lots of internet bandwidth capable of allowing many repeaters to be inter-connected together by streaming the received audio back to all other connected stations. Each reflector has 9 sub channels allowing up to 10 separate virtual reflectors to operate. These are identified by the last digit. For example - 9200 is the main channel with 9201, 9202 9203 etc being virtual reflectors with identical capability as the main channel.
You can always check which stations are connected to the reflectors main and sub-channels by visiting http://status.irlp.net and looking for nodes connected to individual nodes or reflectors.
Reflector Use
With reflector use the first thing we must all remember is to leave a gap between transmissions. Having said that this is a good time to list the three main rules when connected to a reflector:
Pause
Pause
Pause
Due to the slight increase in delays created by multiple Tone Squelch radios in the links between the repeater and IRLP link radio, a slight change in our normal operating procedures is required with IRLP.
By leaving a pause between transmissions it .....
allows users on other nodes a chance to check in.
allows other nodes time to send touch-tone commands to drop their node.
The most important guideline to remember is leaving a pause after pressing the PTT button as well as between transmissions.
Reflector 9200 Guidelines Courtesy
by Dave K9DC reflector 9200 owner
Avoid Local Traffic While Connected To The Reflector
By its nature, the reflector has a large footprint and a wide audience, therefore if local users would like to have a discussion, they should disconnect from the reflector. If we hear a local conversation (all participants coming from the same node) that continues, I, or one of the other reflector control ops will likely ask them to disconnect. If attempts to break into the conversation are unsuccessful, the node may be blocked from the reflector (more on blocking later).
Along the same line, if two stations become engaged in an extended dialog involving only themselves, then I would recommend they both move off the reflector and make a direct node to node connection, freeing up the reflector for others. If more than two nodes are involved, then moving to one of the lesser used reflectors might be an alternative, especially if one of the stations can check the web site for an available reflector. In the future, moving to one of the available sub-channels will become an option.
Calling CQ DX
It IS acceptable to call CQ, in fact, if you really want to make a contact, it is preferable to say "This is K9DC calling CQ, is anyone available for a contact?" as opposed to "K9DC Listening" ...silence for 2 minutes, followed by a disconnect. However 3 x 3 x 47 CQs are unnecessary and should be left for CW/SSB frequencies where tuning around is the observed practice. Odds are we heard it the first time.
It IS acceptable to talk about the weather, or anything else that is geographically significant. But like anything else, within reason. A station in Indiana that says to a Colorado op, "Hey I heard that you have a mountain out there" will probably cause eyes to roll worldwide.
In general though, long winded, channel consuming conversations should be avoided. Remember there are usually a dozen or two connected systems, with perhaps hundreds of users that might like a chance to use the system.
A Few Other Reflector Operational Guidelines
Listen first. When connecting to the main channel on a Reflector, odds are that you are dropping into an existing conversation. Wait for at least 15 seconds to make sure you are not interrupting an existing QSO before calling.
Pause between transmissions. Many nodes are connected using simplex links, therefore the only time it is possible for them to disconnect is between transmissions. Be sure to pause AT LEAST 5 seconds between transmissions.
Key your transmitter and wait before speaking. There are propagation delays across the Internet, as well as delays caused by sub audible tone decoders and other devices that cause a delay before the audio path is cut through. If you speak immediately upon PTT, the beginning of your transmission will not be heard.
Being Blocked From Reflectors
IRLP reflectors have a management function allowing reflector control operators to block specific nodes from accessing the reflector. When a node is blocked, the reflector ALWAYS automatically generates an e-mail message to the e-mail address of the Node owner as submitted to database
irlp.net. The e-mail should contain the specific reason for the block. This blocking is NEVER personal. It does NOT mean that we don't like you, but is only done to ensure continued operation of the reflector. Even my own node has been blocked.
Nodes are usually blocked for a technical malfunction, such as a locked COS, open squelch noise, extended hang time, or your repeater ID (with no user traffic) or courtesy beeps audible to IRLP, or any other problem that that impairs operation of the Reflector. Your node may also be blocked for rapid fire local traffic making it impossible for nodes to break in between transmissions.
Cross-linking other VoIP networks on IRLP reflectors is not allowed as very few non IRLP VoIP systems mute Station IDs, hang timers and courtesy tones. IRLP does not permit retransmission of any source that is not part of a users PTT transmission. With 20 or more repeaters connected together, sheer chaos would result if this hard rule was not enforced.
The reflector control ops may try to contact a local control op on the air to advise the problem, however this may not always be possible. It is important that the node owner respond to the e-mail message advising the problem has been corrected.
If you have any other specific questions I can address, please send them along.
Making A Direct Connection
First of all listen on your local machine for at least 15 -30 seconds before transmitting and then ask if the repeater is currently in use. Assuming all is clear, identify your self and give the node name or number you wish to call . Example: "VE3xyz for the Sydney node" - - then enter the ON code for the node and release your PTT. Your local repeater should come up with a carrier as it waits for the connection to be authenticated. This can take a few seconds of dead-air so don't be concerned. When the connection is confirmed, the voice ID of the destination node will be transmitted back to you as well as your nodes voice ID to the other repeater.
NOTE: If your node is already connected to another node or reflector, a greeting will play saying; - "your node is currently connected to...ID of the connection") In this case confirm if anyone desires the connection to remain up before dropping by using the OFF code..
Once connected and after hearing the confirming voice ID, wait at least 15 seconds before transmitting as.......
The repeater may be in use, and your entry may have occurred between transmissions.
The voice ID of your node is longer than the voice ID of their node, and the connection is not made until the ID is fully played.
Their computer may be slower, and hence take longer to process the connection than yours.
Press and hold the microphone PTT for a second and then announce your presence and your intention such as you are calling someone specifically or just looking for a QSO with another ham in that city.
If no response is heard, announce your call and your intent to drop the link and then touch- tone in the OFF code. Not a good idea to transmit touch-tone commands without first giving your call-sign. Not only is this courteous it is a regulatory issue in some countries who may be connected to the reflector.
Some nodes are configured so you cannot connect to them if that repeater is active. In this case you will receive the message "The node you are calling is being used locally" If you receive this message wait 5 or 10 minutes and then try again.
If you stay connected to a node and there is no activity on your repeater for 4 minutes, the connection will time out and automatically disconnect with a voice ID disconnect message on both nodes.
What Are The Node Codes?
This is a very common question to which there is no single answer. Some node operators choose to add a prefix to their node. Also some nodes require membership so the easiest way to get current codes is to contact the node operator or custodian. To email a node owner go to http://status.irlp.net, find the node you wish to contact and click on the node number. At the bottom of the node info is a link to create an email message.
Connecting To The Reflector
As above, listen to your local machine for local use and then announce your intention for the Reflector before keying the ON command. When you hear the confirmation ID always WAIT at least 15 seconds before transmitting as you are most likely now connected with many repeaters and a QSO could be in progress. If after 15 seconds you hear nothing, identify yourself and indicate you are listening to the Reflector from "City and, Prov./State, Country". With the world wide IRLP activity your local repeater now has world wide coverage thus the suggestion to better detail your QTH.
Don't be in a hurry to hear someone come back to you. You may have to do a bid of pleading from time-to-time to dislodge someone from whatever they are currently involved with.
By default, connections to the reflectors now time out with no activity however many node owners set this period for a long period so it is not unusual for repeaters with minimal traffic to stay connected to the Reflector for extended periods of time. When or if the node times out from a Reflector connection a standard time-out greeting will precede the timeout saying, "Activity time out ... Reflector xxxx, link off"
If you are new to IRLP you should always consult with your local node sponsor to confirm the local guidelines on reflector connections in your area.
If you hear or wish to engage in a prolonged rag-chew on your local repeater (long discussion of a local nature) out of courtesy to other node listeners drop the reflector.
Error Messages
From time-to-time you may receive error messages when attempting to connect with a node or reflector. The most common ones are:
"The node you are calling is not responding, please try again later"
This is caused by a loss of internet connectivity to one end of the call attempt.
"BEEP Error- The call attempt has timed out, the connection has been lost"
This error occurs when a node is OFF-LINE. Some nodes such as in the UK use dial-up connections and then, only for short periods. Also there may be temporary net or node problems.
"The Connection Has Been Lost"
If the internet connection drops, this error message will be heard. I found this out when I accidentally kicked out my network cable while working around the node computer.
Do's And Don'ts
In summary then a few Do's and Don'ts:
DO pause between transmissions to let other in or others to enter DTMF command.
DO identify before sending DTMF command tones.
DO hold your microphone PTT for about 1 second before talking to allow all systems time to rise.
DO NOT rag-chew on your local repeater while connected to the reflector.
DO pause for 10 seconds or when entering the reflector before talking.
DO NOT start or plan a Net without pre-authorization from the reflector owner
IRLP QSLing
Many users of IRLP express desires to exchange QSL cards. With many IRLP users not being on HF they may have never considered having QSL cards printed. Now here is a new Internet technology for you to easily exchange QSL cards.
eQSL is a new electronic QSL service that allows you to custom design your own card which is then formatted with your contact info and automatically sent to your contact. You are able to create your custom card from many graphical templates provided or upload your own graphic to the eQSL web site. This graphic is then used to automatically generate all of your outgoing cards with the contact info.
The eQSL web site is http://www.eQSL.cc
The eQSL service is free supported by some advertising and private donations.
Of course there is nothing like getting a real QSL card via the bureau or direct. If sending cards direct your remember that your local postage is not valid outside of your country so include a US dollar bill or an IRC to cover return postage.
For more information visit http://www.irlp.net
"Ham-Shack.com", Copyright 1997-2009 Jonathan and Sara Imberi All rights reserved.