SoftRepeater v1.0

SoftRepeater v1.0
Written by Mark Smith, mark@halibut.com

The current version of this software can always be found at:
   http://www.halibut.com/~mark/softrepeater/

What is SoftRepeater?
~~~~~~~~~~~~~~~~~~~~
SoftRepeater is a software package that runs in Linux, and controls
a radio, or a set of radios, and performs all the functions of a hardware
repeater controller, only in software.

If you want to get going and skip over all this boring stuff, do a
search for "Getting Started" and start reading there.

Advantages to SoftRepeater over Conventional Repeater Controllers:
- SoftRepeater is free, like Beer.  You don't have to pay for it.
- SoftRepeater is free, like speach.  If you want the repeater to do 
  something it doesn't currently support, no problem!  Add it yourself!
- PC Hardware capable of running SoftRepeater is cheap, sometimes free.
  Getting an old Pentium PC and installing Linux and SoftRepeater can
  often be done for between free and $100, _MUCH_ less than those 
  full-featured repeater controllers out there, and comparable to the
  small, MicroController based controllers.
- There isn't anything you can't do with SoftRepeater.  See the To-Do
  section to get an idea of what features I'm looking to add.  (Remember,
  this is a v1.0 release; it works, so I'm releasing it.  There's LOTs
  more to do.)

Disadvantages to SoftRepeater:
- The hardware is usually larger than a conventional repeater controller.
- PC hardware typically has moving parts.  This can be fixed (Compact
  Flash and CF <-> IDE adaptors are getting cheaper and cheaper as the
  days go on), but it adds to the cost.
- Support is on a "when I get a chance" basis.  If you give someone else
  money for their controller, you're more likely to get ahold of them
  in a timely mannor if something goes wrong.  Don't get me wrong, I'll
  do what I can to help, but no guarantees.
- Right now, the features just aren't there.  This is a v1.0 release.
  It will get better, I promiss.
- There really is something to be said for "You get what you pay for..."
  If there's something you don't like, please offer constructive critisim
  to mark@halibut.com.  I'm open to ideas and suggestions (and, even better,
  patches.  :)  Flames will get directed to /dev/null.


What can be found in this package:
- README
  You're reading it.
- Makefile, bunch of .h files and a bunch of .cc files
  All the source code that I've written
- parapin-0.95.tar.gz
  The current (as of Sep2002) version of parapin (used by SoftRepeater)
  This version will work with SoftRepeater, although it may not be the
  most current.  You may want to go to: 
  http://www.circlemud.org/~jelson/software/parapin/ for the most current
  version if you're going to do anything else with it.
- ptt.c and pttcycle.c
  Two programs I wrote to help debug the parallel I/O interfacing to
  your radio.

What you _WON'T_ find in this package:
- Hardware
  Specifically, you'll want a radio capable of full-duplex operation.
  Many old Motorola and GE radios can pretty easily be modified for
  full-duplex, in-band operation.  Of course, if you're doing in-band
  stuff, you'll also want Duplexors (also not included in this tarball. ;)
  You'll also need the other obvious stuff, like antennas, power supplies,
- Interface hardware
  This software uses an OSS compatable sound card, and a parallel port
  as its I/O to talk to a radio.  You're responsible for figuring out
  how to connect your radio's PTT to Pin 2 of your parallel port.  You're
  also responsible for connecting audio in and out from the radio to
  the sound card.  I personally went the cheap route and just connected
  them straight, no matching, no nothing.  It doesn't sound real good, 
  but it works for development.  When I go live, I'm going to both to
  impedance and level match everything.
  In future releases of SoftRepeater, I'll include some schematics for
  my test hardware.
- Computer
  You'll also need a computer.  SoftRepeater doesn't require a dedicated
  computer, but whatever computer you do use will need to be running
  for your repeater to work.  (Duh!)
  It will also need a Parallel port (like a printer port) and a Sound
  Card that'll work in Linux.  (I use the ES1371, but just about anything
  will do.)
- Operating System.
  I'm developing on RedHat 7.3, but there's nothing really all that OS
  dependant to what I'm doing.  As long as it supports the OSS sound
  interface and you can get Parapin to compile, you should be set.

Current Feature List:
- It, uhh, repeats.  It even keys up the radio and everything!
- Courtisy Tone
- PL tone (with a cheap reverse burst feature)
- Automatic morse IDer

To-Do Feature List (Oy.  This'll be long...):
- Support Multiple input/output channels
- Support two channels on a single sound card (left and right)
- Voice (.wav) ID, QST, Court. Tone, etc.
- Clean up the code, make more OO (eg: parapin)
- Add a better UI (make a UI at all!)
  - CLI
  - Web GUI
- Put what are currently constants into a config file (eg: court. tone delay,
  frequency and volume)
- Document, document, document.
- Draw up some diagrams for interface hardware.
- Investigate using IRLP hardware (maybe?  That would be cool.)
- Auto-patch support (using a modem with "voice-mail" support)
- Incomming PL Detect
- DTMF detect and control
- VoIP linking (IRLP?)
- Trunking
- Trunking/IRLP/One-to-one.  You select a callsign, it finds the person
  over the net, and opens a trunk to them, possibly linking to another
  repeater if necessary.
- Figure out why sound "clicks" a little bit.
- Activity logging
- Intelegent IDing (only ID if activity with-in the last 10 minutes)
- Give up root privs after setting up Parapin
- Parallel port COR input instead of Threshold/PL detection
- MIC-E decoding and forwarding to APRS networks (both Inet and RF)
- AX.25 digipeater (receive and send w/o PL to not disturb voice operation.)
- Layer2 AX.25 switch, receive frames on one channel, send on another.
- Software RF De-mod (requires sampling IF)
- ... I'm sure there's more.  Feel free to add to this list...

Getting Started:
1: Untar the SoftRepeater package somewhere (presumably, you've already
   done that; you're reading this, aren't you?)

2: Compile and install parapin.  Follow the directions there.

3: Copy libparapin.a from the parapin directory into the main SoftRepeater
   directory.

4: Edit repeater.cc and change the #define constants to values you want.
   Yeah, I know, I know..  That's ugly.  Not only are they not run-time,
   but they're #defines in a .cc, not in a .h.  Deal with it.  This is a
   v1.0.

   What they mean:
   - AUDIO_DEVICE is the device filename for your sound card.  Probably
     "/dev/dsp"
   - SAMPLE_RATE is the rate at which sound is sampled.  This should 
     probably be kept at 8000
   - BUFFER_RATE is the number of buffers per second that will be read.
     Increasing this number will increase the load on your system, but
     will improve full-duplex latency.  Decreasing this number will lighten
     the load on the system, but will create more delay between incoming
     and outgoing audio.  It should probably be kept about 8.
   - BUF_SIZE   Don't touch this.
   - THRESHOLD is the minimum average (RMS, sorta) value of incoming audio
     needed to trigger the repeater.  This will need to be set, depending
     on the noise and audio level of your radio.  I found that 100 works
     pretty well.  Increasing this number makes the repeater more impervious
     to extranious noise, but means that softer signals will be lost.  
     Decreasing this number will make the repeater more sensitive to softer
     audio, but also more likely to trigger on unwanted noise.
   - TAIL_LENGTH is the number of buffers in a row that do not trigger
     the threshold detection stuff needed to give a courtisy tone.  This
     is in the unit of Buffers.  If your BUFFER_RATE is set to 8, and 
     TAIL_LENGTH is set to 16, then 2 seconds after the last audio comes
     in, the courtisy tone will sound and the radio will un-key.
   - LP_BASE is the IO port for your parallel port.  'dmesg | grep lp'
     should show you which parallel port IO address is in use.  See
     the parapin documentation for more information here.
   - PTT is a redefine of a constant from the parapin library, saying which
     physical pin on the parallel port is to be used to key the radio.
     For my hardware, it's Pin 2, so I define PTT as LP_PIN02
   - PL_TONE is the PL tone generated by this repeater.  Its in 1/10Hz.
     For example, a PL of 127.3Hz would be:  #define PL_TONE (1273)
   - ID_EVERY is the number of buffers between identifications by the
     repeater.  For example, if BUFFER_RATE is 8, then a value of
     (8*60*10) or (4800) will ID every 10 minutes.
   - ID is a text string that will be converted to Morse code for IDing.
     I recomend putting a space at the begining and the end just for some
     added buffering, but its not normally necessary.
   - There are probably some more constants in the code.  Like I said,
     this is a v1.0 release; its going to suck.

5: Type 'make repeater'  This should work without any problems.  If you
   have problems, try to figure out what went wrong and send me an email
   so I can fix it in the distribution.  mark@halibut.com
   This will build the repeater binary.  

6: Build and connect your interface hardware and radio.  You can also
   test with a standard mic and headphones.  (That's how I've done most
   of my development.)

7: Run the repeater binary as root.  (Yeah, I know.  It's on my To-Do list
   to give up root privs as soon as we're done with them, but we need them
   to get at the parallel port.)

8: Key up your HT and see whether it gets repeated!




softrepeater-1.0.tar.gz 02-Sep-2002 21:49 127k [MISSING]


Main / \ / \ List List | | Thread Thread | | +--------Input <------ Mixer & | | / Controler InputDevice List List | | / Output----+ v / | Waiting OutputDevice As you can see from the above diagram (will be replace with a graphical image when I can.), the main program consists of two lists of threads. The first list of threads are reading data from the different input methods. They stuff the audio data into the internal format (not shown above) and trigger all mixers waiting for this input. Waiting is an object with a semaphore (pretty simple, 'eh?) When a Mixer registers as "listening" to a particular input, it adds a Waiting to that Input's list. Then, when an input has a block of audio ready, it triggers that Waiting. The Mixer wakes up and starts processing. When the Mixer and Output are done, they wait on the Waiting again.


SoftRepeater News Updates 2004May17 - mts So, I was right that I wouldn't be updating this file very often, but at least I have an excuse: I haven't done much work on the repeater since the last update! (That's not helping, is it?) Yesterday, however, I did get this done: And, that's about where I left it for the night. Up next, I'm going to rig up a quick and dirty audio interface using an existing sound card, and the parallel port for PTT (and possibly COR). I've gotten my main unix server (www.halibut.com) already setup with the sound card and parallel port to be used for testing, so once I get the interfacing hardware setup, I should be good to go! -mts 2004Jan31 - mts This is my first update. I'm not real confident that I'll keep up with this news column, but I'll give it a try. I do this in my spare time, so sometimes it'll take me awhile to do anything. So, this is what I've been up to since I release SoftRepeater v1.0 last year. The software was written using a mic and headphones; no radio was ever connected to the system. This doesn't make a very good repeater, now does it? I've got a UHF Motorola Mitrex that I've modified for use in the Ham Bands, I've coordinated 442.600+ for use in Arroyo Grande, CA (where I live), I've got a set of crystals, and I've gotten my duplexers tuned up. The radio is, in theory, all ready to be used in the ham bands. I have not, as of yet, modified the radio for full duplex, although the two pages I've found for this make it look pretty simple. I also don't have any level matching circuit to connect the radio to the computer, yet. That's been what I've been spending the bulk of my time on in recent days. In a perfect world, I would have a device which would have a standard interface to the computer, supported by linux, and would be able to connect to at least one (possibly more) radios, supporting full duplex audio, a PTT, a COR, and maybe a few other IO pins for other uses. The audio interface on this device would have a low impedance output with lots of power (which could be turned down if not needed), and a high impedance input with lots of gain (which could be turned down if not needed.) The idea would be to have as generic an interface as humanly possible, so it could be connected to just about any radio at any point in the audio path. All interfaces to the radio would be totally isolated from the computer, using transformers on the audio, releys on digital outputs, and optoisolators on digital inputs. Oh yeah, it should be cheap and easy to build too. :-) I found a chip that will meet most, if not all, of these requirements. The C-Media CM108 is a USB <-> Sound Interface chip, ment for use in a USB headset, or something similar. It has a standard USB 2.0 interface to the computer, speaker level audio out, and mic level audio in. (It has Stereo output, but only Mono input, so its only good for a single radio channel.) The Speaker output can drive anything from a 32 ohm headphone speaker, to a 1000 ohm line-level. (I'm sure it'll do just fine with a higher impedance load; worse case, throw a load resistor across the output to lower the effective impedance.) The Mic input is (I suspect) high impedance, and has a switchable 20db boost built-in, if needed. The best part about this chip is the 4 General Purpose I/O pins it also comes with. These can be easily controlled using hiddev in Linux v2.4, or libHID in Linux v2.6, and make great PTT/COR controls. All of this in a single chip, less than .5" square. So, I'm working building an interface board based on this chip. I have a schematic that I'm working on right now for this board. Some of the component choices are pulled from my nether-regions, so don't worry when you look at the thing and say "Holy Cow! You're going to burn up that transister!" I'll run the actual numbers before I order any components; they're just there as place holders so the net-list will compile and so I can get to work on the board layout... ...which I have just started. I'm using Express PCB for the schematic and board layout, and will be using them to fab the boards. I've used them in the past for some other projects and they did a smashing job, and the boards are cheap. My eventual goal is to get this radio, this USB interface thingie, and a MiniITX computer, mount it all to a rackmount shelf, run it all off 12vDC, and throw it in a rack at a friend's house with a PS and some batteries and a net connection, and continue development of the software. I've got a lot of features I want to add. Well, if you've made it this far, I'm damned impressed. Check back here periodically if you're currious how this project is going. Of course, if you're interested in helping, feel free to email me: mark-sr@halibut.com and we'll see what we can work out. -mts