Adding HF, 6 Meters and Other Band Capability to Your IRLP Node
INTRODUCTION
My UHF repeater system is part of the Internet Repeater Linking Project (IRLP), which has greatly enhanced its functionalilty for users. The repeater is physically located on a local mountain (along with a 2 meter FM only synthesized remote base) and full-duplex UHF links. For more info on the system, click here.
The computer that runs my IRLP node is located at my home and the computer also serves a router for my home network, my mail server and my web server (if you're reading this, you're using it now). As such, this computer is on 24 hours a day, 7 days a week.
One very nice thing about having full-duplex links to the repeater is that you can add all sorts of functionality to the repeater without ever having to take a trip to the mountain! Also, you tend to want to use those links for all sorts of things. This project is an outcome of that thought process.
CONCEPT
When you set up an IRLP node, you install a hardware card into the computer, which includes a DTMF decoder and buffering to/from the computer's parallel port. This hardware card normally provides all the hardware interfacing between your IRLP "node" and the radio (or repeater) its connected to.
I've always thought that adding more than just 2 meter FM capability to my repeater system would be a nice feature (I even designed a stand-alone controller to allow the remote control of an HF rig via a radio link). But it struck me - why should I tie up all that hardware in order to do something that my Linux computer could easily handle and it already had most of the hardware needed (DTMF decoder and so on).
This project is born out of those thoughts.
THE SOLUTION
I wrote the software for the Kenwood protocol, as my main rig is a Kenwood TS-2000 (other manufacturers will be supported in time as well - more on this later). By allowing both my repeater users and those coming in from the IRLP network access to the TS-2000, the radio will give them coverage from all bands I have antennas for (80 through 440). As I am not complete convinced of the legalities of an IRLP user from Australia using a HF remote base located in the US, I also included provisions for allowing the disabling of the remote base from the IRLP side.
As serial ports (used to communicate with the HF radio) on Linux computers are generally inaccessable by anyone other than the superuser (root), I wrote a serial port driver in the C language to allow access by everyone. The rest of the software is actually shell scripts, used to convert the TouchTone digits from the IRLP DTMF decoder board into a format understood by the Kenwood, as well as utilize the existing COS and PTT signals (also from the IRLP hardware) to manage the link radio (which in my case, links back to the repeater). Command codes for controlling everything is fully configurable by the IRLP node owner as well.
Via DTMF codes, the user can change modes (USB,LSB,AM, FM) and frequency of the TS-2000. Limited scanning is also provided. The software also provides voice readback of commands and frequencies entered.
OTHER RIGS
Icom and Yaesu radios use a different protocol than the Kenwood series of radios and I am currently working on providing the proper drivers for controlling these radios as well. These will be made available when avaiable.
CIRCUIT DESCRIPTION
One area that we can't escape the need for additional hardware is in audio switching and routing. Normally, an IRLP node uses a standard soundcard to provide audio in and out of the computer. These audio lines connect to a link radio (as in my case) or directly to a repeater controller (as in the case of a node where the computer is physically located with the repeater). In the latter case, no additional hardware would be needed, since you could simply connect the HF rig's audio in and out lines to an open audio port on the repeater controller and be done with it. Since I have links from my IRLP node to the repeater, I could either uses another link radio for the HF rig (with another antenna and all that), or "share" the one I use for IRLP. I chose to share.
The audio routing board allows you to mix all the audio sources you need, adjust their levels, route them to the appropriate receiver, transmitter or soundcard. All audio sources are mixed to all audio outputs so, for example, you have complete control of the IRLP DTMF decoder from IRLP itself.
All audio inputs are buffered by LM358 dual op amps. A single voltage source is used in this design, which works quite well in this application and provides more than enough gain and output. R9 and R10 comprise a simple voltage divider which is used to bias the non-inverting inputs to 1/2 VDD (needed for single supply operation). The feedback resistors chosen should provide more than enough gain for the type input they're meant to deal with. Should your particular source be too low to provide adequate output from the input buffers, you can increase the values of R11 and R4 as needed. For most uses however, this shouldn't be necessary.
Op amp circuit U1A is a special case as it is meant to connect to your link radio. The stage provides for a standard 3 db per octive de-emphasis, which you will need if you tap audio before this processing is handled within your link radio. Do not change the value of R2 if you need more gain as this will upset the de-emphasis characteristics of the stage. If you need more gain, you can try reducing the value of R1. If you don't need de-emphasis, simply omit C1 when building the board (if the audio coming from the link receiver is "tinny" sounding, you need de-emphasis). If you don't use C1, you can adjust the value of R2 if needed, although there should be more than enough gain in this stage as is.
Both the link receiver and HF receiver audio are routed through some more CD4066 analog switches, allowing us to control this audio path as needed. If your link receive audio isn't gated within the radio, you can use the enable line (pin 10) to control it. A logic high (1) enables it. If you don't need this audio input switched, be sure to provide anywhere from 5 to 15 volts to pin 10 or you'll wonder where your link receive audio went.
The HF receive and transmit audio is controlled by a grounding pin 12, which is normally done in the software, driven by one of the IRLP Aux1 output.
The audio driver op amps (U2B, U3BA and U3B) provide buffering to your transmitters and soundcard. You will notice that the input levels to these stages are not adjustable. They don't need to be as any audio delivered to them is adjusted by the input op amps. Output level is adjusted by controlling the gain of these op amps by making the feedback resistor adjustable. The exception is U3A, which is the driver for your soundcard. The gain here is fixed to provide a high level audio signal to your soundcard line in connection, which should help to mimimize noise.
Not being a fan of relays, which are noisy, unreliable and power hogs, I used CMOS analog switches which consume very little power, have no moving parts and are therefore completely silent in operation.
CMOS switches are also used to control the routing of all the HF COS and PTT signals.
HF SQUELCH CIRCUIT
In order to accomodate non full-duplex nodes, this project uses a voice-syllabic squelch that ignores noise and heterodynes and responds only to actual human speech. Details can be found here.
The squelch board is configured as a separate assembly since not everyone will want/need it. All connections from the IRLP HF board are made via a 4 pin connector.
THE FILES
With the exception of the serial port drivers, all control is accomplished by the use of shell scripts. They are as follows:
hf_control - acts on the actual command codes decoded by your custom_decode script.
freq_decode - formats and sends the selected VFO frequency to the serial port driver. Also formats the command for voice readback.
speakfreq - converts the entered frequency to the appropriate wav file and plays that wav.
serial - A small binary program written in C to allow serial port access by non-root users. It also accepts an argument passed to it by the various shell scripts and sends them to the serial port.
EXISTING IRLP SCRIPT MODIFICATIONS
Aside from the command added to the IRLP custom_decode script, two other changes are needed:
environment - Add a new exported environment variable to point to the new /hf directory.
custom_decode - Add a line to "touch" (a Unix command to create an empty file) a pointer file called dtmf_present upon receipt of a valid DTMF digit, which is used by the hf_ptt_control file.
For details on these changes, see the README document in the tarball (download) or click here.
CONSTRUCTION NOTES
I designed a circuit board for this project which you can duplicate. If there is enough interest, I will probably make PCB's available at reasonable cost.