New version of Autopatch how-to
Table of Contents
28Sept2022
updated: 20Feb2024
Building an AutoPatch. It's still useful!
1. A quick intro
I live on the rural northern California coast. As technology has marched on, and AT&T has been allowed to let all the copper communications lines fall into disrepair and failure, we find ourselves dependent on a very fragile infrastructure. In our case, hundreds of miles of coast are connected inland by a single fiber run. All land lines, cell phones, and network connections from various providers tie into this single point. And it's failed, taken out by a truck hitting a single pole on a secondary road, causing all communications to fail. No 911, no internet. And we've had smaller outages since, when construction folks dug into local communications lines, isolating smaller numbers of people.
Thankfully, some other advances have arrived, one being Starlink. A fast bi-directional satellite connection to the internet. Not dependent on local infrastructure, except what we control ourselves. With that key piece, some local Hams thought it might be a good idea to see if we could build a simple and inexpensive autopatch, so we'd have some ability to communicate to non-hams, via our radios, when the network again goes down.
One such Ham, Jonathan, KK6RPX, had gone as far as to grab a AVRTX RI-2020 radio interface, and was hoping to get AllStarLink working with it. But, projects kept stacking up, so he asked me if I could take a crack at it, being the old software guy I am. As always, I'm indebted to the many people who've worked on parts of this technology, and shared their learnings. Here's my how-to on getting this working…
2. Prerequisites
- A computer that can run the AllStarLink software (PC or Raspberry Pi, or other Debian boxes). I used the 2.0 Beta software.
- A soundcard to radio adapter (I used an avrtx RI-2020, but I don't know if you can buy those anymore, I'll update this as we try other devices)
- A voip provider (I used voip.ms)
I won't get into the politics, since frankly I don't understand them, but there's some kind of disagreement surrounding the AllStarLink software. It seems to have killed all new development. But, what's available seems to work, and for the single use case of a voip AutoPatch, it works fine.
First, follow the Beginners Guide to get the Beta 2.0 image installed and configured. You technically don't need the server and node just to be a standalone AutoPatch, but the current software wants to phone home, and needs to be able to connect with a node number.
If you use a different distribution of AllStarLink, this guide may, or may not help you. Also, not entirely sure how this will work with other voip providers.
3. Configuring Asterisk
Once you've run through all the AllStarLink setup, and have a node up and online, it's time to customize. If you're not using voip.ms, you might want to change the tag 'voipms' to something else in all the config files it is mentioned in. We'll be modifying the following config files (located in /etc/asterisk)…
- modules.conf - what modules are loaded at startup
- rpt.conf - repeater configuration info
- sip.conf - configuring your voip provider info
- extensions.conf - setting up how numbers are dialed
- simpleusb.conf - fix for DTMF decoding on some radios
3.1. modules.conf
The easiest of the batch. Simply change the single line:
noload => chan_sip.so ;
to
load => chan_sip.so ;
This tells the software to load the code supporting SIP (Session Initiation Protocol, if you're curious)
3.2. rpt.conf
change:
callerid = "Repeater" <0000000000> ; callerid for phone calls
(Note, I believe the software puts the machine name here, which is Repeater by default)
to whatever text and phone number you want your callerID to show, when the voip provider makes the call. Note, I'm using voip.ms which does not honor this request. You have to have an incoming number, and then you can set the callerID with voip.ms, but that comes with a monthly fee. Don't know if other voip providers honor the sent callerID, but I'm guessing with so much phone number spoofing happening, this won't be available.
NOTE: You must set the number to a valid 10 digit phone number. If you leave it all zeros for testing (like I did), then when voip.ms tries to make a call, nothing will happen because the callerID is invalid. Again, YMMV with a different voip provider.
I was getting a tone from the software whenever I unkeyed. Since the plan is to have this link with a repeater, that's not very friendly, don't want the autopatch to do anything unless asked directly.
I found that changing the duplex to '0' fixed it. To do this, simply change the default
duplex = 1
to
duplex = 0
Add the line:
context = voipms ; Autopatch addon ;
I added this right after the callerid line.
Change the line:
61 = autopatchup,noct = 1,farenddisconnect = 1,dialtime = 20000 ; Autopatch up
to:
61 = autopatchup,context = voipms,noct = 1,farenddisconnect = 1,dialtime = 20000,quiet = 1 ; Autopatch up
All I did is add the options context = voipms and quiet = 1. The options can be in any order. context links to the entries we'll make in sip.conf, and if quiet is set to 0, it just didn't work with voip.ms for me.
What this means is when you send *61<number> from your radio, it will
send <number> to the sip provider specified in sip.conf. When you send
*62, it will hang up. Obviously, customize these to numbers you want
to use, if you don't like the defaults.
I noticed a bunch of other DTMF commands in the file, which worked as described. One section I was particularly interested in was the Control Operator (cop) items. I wanted to be able to enable/disable things via DTMF, and these do exactly that. I uncommented (and changed the numbers for) items like:
902 = cop,2 ; system enable 903 = cop,3 ; system disable
That'll let you enable/disable the entire system, plus do any other functions listed there. When testing I was getting Tx held high (see NOTE below). I couldn't use any DTMF codes, since the radio was transmitting. I did find that the following command in the ASL Asterisk CLI lets you use these directly:
rpt fun <node #> *<code>
So, if your node number is 12345, typing "rpt fun 12345 *903" will disable the system. And "rpt fun 12345 *62" will hang up the call in progress. Pretty handy to know when testing everything.
NOTE: I changed the duplex from 1 to 2, since the comments in the file said it was preferred when interfacing with a repeater (which this will eventually). Unfortunately, when not talking to a repeater, this just held Tx on until things timed out. Changing it back to 1 fixed that.
3.3. sip.conf
Comment out (or remove) the line:
bindaddr = 127.0.0.1 ; IP address to bind to (0.0.0.0 binds to all)
to:
;bindaddr = 127.0.0.1 ; IP address to bind to (0.0.0.0 binds to all)
This cost me a few hours. I was getting what seemed like a totally unrelated, and very vague, error message on startup when I had the sip module loading. Eventually, I commented out this entire file, and found this was the offending line. I don't know why it didn't work, or why commenting it out fixed it.
One nice thing about the rest of this config file, voip.ms has a page with the required settings! Once you're logged into their main site, you can follow this link to find them. I'll place mine here too, just for reference…
register => <userid>:<password>@sanjose1.voip.ms:5060 [voipms] canreinvite=no context=voipms host=sanjose1.voip.ms secret=<password> type=peer username=<userid> disallow=all allow=ulaw fromuser=<userid> trustrpid=yes sendrpid=yes insecure=invite nat=yes
3.4. extensions.conf
In the [pstn-out] section, comment out:
exten = _NXXNXXXXXX,1,playback(ss-noservice) exten = _NXXNXXXXXX,2,Congestion
So they look like:
;exten = _NXXNXXXXXX,1,playback(ss-noservice) ;exten = _NXXNXXXXXX,2,Congestion
Again, if you're using voip.ms, they have the next section listed out, which I added right after the [pstn-out] sections, but I added one more thing…
[voipms]
;include => voipms-inbound
include => voipms-outbound
;[voipms-inbound]
;exten => _X.,1,Ringing
;exten => _X.,n,Answer()
;exten => _X.,n,Rpt(41899|Rrpt/node:NODE:rpt/in-call:digits/0:PARKED|120) 75
;exten => _X.,n,Hangup
; THIS IS FOR OUTGOING AUTOPATCH CALLS
[voipms-outbound]
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@voipms)
exten => _1NXXNXXXXXX,n,Hangup()
exten => _NXXNXXXXXX,1,Dial(SIP/1${EXTEN}@voipms)
exten => _NXXNXXXXXX,n,Hangup()
exten => _NXXX,1,Dial(SIP/${EXTEN}@voipms) ; <-- added this line
exten => _NXXX,n,Hangup() ; <-- added this line
exten => _011.,1,Dial(SIP/${EXTEN}@voipms)
exten => _011.,n,Hangup()
exten => _00.,1,Dial(SIP/${EXTEN}@voipms)
exten => _00.,n,Hangup()
This enables only outbound calling. I added the two lines:
exten => _NXXX,1,Dial(SIP/${EXTEN}@voipms)
exten => _NXXX,n,Hangup()
Without these patterns, you can't use the 4 digit codes from voip.ms for testing.
Also, I figured out that you can insert actions to happen after the call is dialed, and before the hangup. I added the following line in between the Dial and Hangup lines to send a Pushover notification to my phone whenever an autopatch call is made. This fires when the call completes.
exten => h,1,System(curl -k -X POST "https://api.pushover.net/1/messages.json?token=<token>&user=<user>&message=autopatch+has+made+a+call")
And another addition, an absolute call timer that terminates a call, so someone doesn't spend 30 minutes chatting on the phone, tying up the repeater. Adding the "L(x:y:z)" function to the Dial command terminates after "x" number of milliseconds, starts warning when "y" seconds remain, and repeats the warning every "z" seconds. Replacing the Dial lines with lines that look like this:
exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@voipms,15,L(300000:60000:20000))
This terminates the call after 5 minutes, starts warning when 1 minute remains, repeating the countdown every 20 seconds until it hangs up. Or, and the 15 is how many seconds the system lets a call ring.
ONE FINAL NOTE
Everything seemed to work fine, except the '3' DTMF, when sent from a Baofeng, didn't register. Also, nearly all the "lower" digits didn't register if sent from a Kenwood V71. Found a comment in a thread (here) that suggested changing "deemphasis" in the simpleusb.conf file. Made the change from "no" to "yes", everything now seems to work just fine…
3.5. simpleusb.conf
deemphasis = yes ; enable de-emphasis (input from descriminator)
And that's it! With those changes, I was able to make calls from my HT, talking to the AllStarLink, which in turn talked to voip.ms and connected the calls. The quality varies, as you might expect, but it's definitely usable.
3.6. Next steps…
Right now, this has all the functionality I need. I'm experimenting with removing courtesy and other tones to keep things quieter when we put it on the repeater frequency. I'm also going create multiple clones to geographically distribute amongst local Hams, using cheaper, reliable Motorola commercial radios. I'll be adding some watchdogs that notify me if things aren't responding as expected. I'll document those when I have them running smoothly.
I've also gotten things working with hamvoip, and will be deploying a version of that as well. Then try to get all the config files unified.
3.7. Raspberry Pi Audio adjustments…
When trying to get everything working with a Motorola 1250, we ran into very low audio issues. Sunk a lot of hours into trying to get usable audio. Finally got it working, although still would like more audio. Here's what I did…
Using the ASL config menu, set the Rx and Tx audio from 500 to 900 for all levels. That didn't have much of an effect.
Then, because this was running on a Raspberry Pi, I moved on to working on the audio there. Made the following changes…
Ran aplay -l to get the sound device card indexes, here was the output for me:
card 0: b1 [bcm2835 HDMI 1], device 0: bcm2835 HDMI 1 [bcm2835 HDMI 1] Subdevices: 4/4 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 card 1: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones] Subdevices: 4/4 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 card 2: Device [USB PnP Sound Device], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0
We want the USB PnP Sound Device, this is card 2 BUT since the HDMI port is also a sound card, if I unplugged the monitor cable, the card numbers changed, and the USB would become card 1. As you'll see, that'll break things we are about to do. So, first, to prevent the card number from changing, I did the following:
$ cat /proc/asound/modules
Mine looked like this:
0 snd_bcm2835 1 snd_bcm2835 2 snd_usb_audio
OK, stay with me here, since we have two cards with the same name, we have to find their ID's before we can configure things. To do that, look at the output from aplay -l earlier. The ID is the text following the card #:. So, the ID's are b1, Headphones, and Device.
Now, we will create the file /etc/modprobe.d/alsa-base.conf, with the following text:
options snd_bcm2835 index=0,id=b1 options snd_bcm2835 index=1,id=Headphones options snd_usb_audio index=2
I believe the id is optional for unique device names, so I left that off for the usb audio. With this in place the usb audio device will always be device 2, whether the HDMI is inserted or not. Now we can continue our audio configuration.
In the file
/usr/share/alsa/alsa.conf
Change the lines:
defaults.ctl.card 0 defaults.pcm.card 0
to:
defaults.ctl.card 2 defaults.pcm.card 2
Reboot, just to make sure all the right things get restarted.
Now use the alsamixer command to adjust the audio.
I set the output level from the initial setting of 18 to 84. This gave me usable, if still a bit quiet, audio. When I set it higher, I heard some distortion, but as always, Your Mileage May Vary…
Created: 2024-02-27 Tue 13:46
Comments
Post a Comment