We (Josh, Dirk and I collectively) just killed most of an afternoon tripping over ourselves on a parallel port configuration for a node.  GRRRR!  So I’m putting a few notes here in the hopes that we won’t make these mistakes again.  Much of this was learned from this page about GPIO.

In /etc/asterisk/rpt.conf you need to define the parallel port you’ll be using.  Please do so with the following line:

iobase = 0x378

That’s the standard address for the parallel port.  If you have additional ports you’ll adjust that as required, possibly using 0x278, 0x3bc, etc.  The address for the ports may be defined in BIOS although I recall seeing some set with DIP switch or jumpers ages ago.  If you need to find where your ports are living, especially if you have multiple, there is a command for that:

cat /proc/ioports | grep parport

Next you need to define what pins are supporting which function.  This is done in /etc/asterisk/usbradio.conf  The parallel port offers you 8 lines for output and 5 lines for input.  These can be configured to do just about anything you can imagine using the event handling subsystem.  If the computer you’re using is providing multiple nodes, keep in mind that these pins on a parallel port can do things for multiple nodes.  For example, you may define pin 2 as the PTT output for node 27006 and pin 3 as the PTT for node 29915 for example.  So pay attention because to make these pin definitions in the appropriate section for the node.

Pins 18-25 on the DB-25 of the parallel port must be tied together as a ground (common).  If this is not accomplished you can expect intermittent events, odd events, unpredictable things.  Just tie them together.  Do it.  If you don’t do it now and later discover that you should have done this in the first place, I will be expecting a contribution to my PayPal account as well as a note from you acknowledging that I told you so.  Spare yourself all that and just ground the damn pins.

Pins 2-9 are the output pins.  These can be used to control a transistor switch that can do anything you like.  We often use them to control fans.  You could also drive relays.  Then you can do bigger things like turn runway lights on/off or what have you.  Of course you can use them for PTT as well.  You’ve got 8 so enjoy them and get creative.  You’ll be identifying them in /etc/asterisk/usbradio.conf as pp1 through pp8.  So pin 2 is pp1, pin 3 is pp2, pin 9 is pp8.  You’re going to label each one of them in a way that will define it’s function and initial state.  If you are using one as a PTT output you simply say so in the file as “pp2 = ptt” or “pp5 = ptt” or whatever.  By now you understand the standard format of the file and you know that I’m quoting there and you’re not actually using the quotes.

Set the polarity of PTT using invertptt=0 or invertptt=1  If the PTT works backward from what you expect (transmitting when it should receive and immediately locking into transmit) you will want to use the opposite of whatever you started with here.

Anyway, if you’re using the pin for something other than ptt you will define the initial or relaxed state of the pin.  If the pin should be in the off state by default you would use out0 and if you want it on by default you use out1.  Novel, eh?

Pins 10-15 are inputs.  They can be used for so many things, more on that in a moment.  Define these pins in a similar manner using the choices of in, cor or ctcss.  When you’ve got the processing power and have wired unfiltered discriminator audio in to the URI or fob, you get the most flexibility letting the DSP work out COR and CTCSS.  But there are various reasons why you might just let the radio provide the signals for that.  If you do then you tie those signals to parallel port pins and define them appropriately.  You will then also need to define carrierfrom=pp and, if you’re doing ctcss this way you define ctcssfrom=pp.  If you find these working backward for you then you change to carrierfrom=ppinvert or ctcssfrom=ppinvert as appropriate.

What could you do with all this?  Anything you like.  Of course you will likely need to build the appropriate interface to whatever you sense or control.  Here are a few ideas:

  • Turn a fan on/off
  • Using a thermostat (temperature controlled switch) control that fan or send an alarm.
  • Know when the door to the site has been opened or closed.
  • Know when the lights in the site have been turned on or off.
  • Send an alarm when high SWR is encountered.
  • Turn another radio on/off.
  • Turn on/off a beacon light on a tower.
  • Lock/unlock a door.
  • Change from one battery or power supply to another.