Thursday, January 3, 2013

KC0ALC-1 Digipeater

KC0ALC-103 HSMM-MESH router

The current iteration of my digipeater is a WRT54GSv1 router, running APRS4R which is written in Ruby.  The Ruby packages for OpenWRT takes up more than the available memory space on other routers (G and GL versions) so I'm using a GSv1 that has more flash and memory to handle both APRS4R and HSMM-MESH™ firmware.   Previously, I had been using a WRT54Gv2 router with the USB modification and had the OS running on a flash drive, later on an external 2.5" hard drive.  The USB sticks would die after a month or two of usage and the hard drive required a USB hub to provide enough power so I decided to upgrade it to a GSv1.

The TNC is a TNC-X v1, KISS only TNC that I bought at a swapmeet for $5 and the radio is a FM-2030, a 70s vintage mobile radio that I had no other use for.

The TNC is connected to the router via one of the built-in serial ports on the WRT router.  I found a TTL-RS232 converter chip laying around that works on a 3.3V Vcc voltage (ICL3232) so I wouldn't have to add any other voltage regulators. I made up a simple interface-board, dead-bug style, for the converter and used a couple of DB9 cables to provide external

Other additions to the router include a heat sink on the main processor and a fan inside the case to circulate air.  The fan is a 12V fan I found in a junk box with a current limiting resistor to slow it down.  Since this router will be running 24/7 I wanted to minimize the thermal stress on the components.



APRS4R is running as a fill-in digipeater (only responds to WIDE1-1 packets) and also a transmit I-Gate, limited only to the polygon weather alerts coming through the APRS-IS servers.  I further limit the packets to my county and surrounding counties via the APRS-IS filtering I have set up.  I'm using APRS4R right now mostly for the ability to share the APRS data and have other computers connect to the digipeater and use it as a TNC interface.  I have the port forwarded through my home router so I can access my TNC wherever I have an Internet connection and also available to any HSMM-MESH™ routers that are connected to the router.

APRS4R also needs regular restarts to behave correctly (due to a memory leak issue, I believe) so I have a cron job reboot the router at specified intervals.

Here is an overall system diagram:


Some pertinent links:

Monday, November 12, 2012

7911G behind NAT

I can happily report that I have been able to run VoIP phones across a HSMM-MESH link.  I was surprised at how easy it was, once I was able to reproduce the results.


First off, I set the VoIP phones to static IP addresses.  I chose 172.27.0.51 since it was outside the range of  the router's DHCP (and I have been using the 172.27.0.5x space as VoIP experiments anyway).  

On the router that has the server on it, I forwarded UDP ports 5060 and 10000-20000 to the server by adding a line to the /etc/config/firewall file on the router.  This line will looks like:
forward:wifi:dport=5060,10000-20000 proto=udp dest=routerWiFiaddress:serverIPaddress
Replace the bolded fields with the appropriate IP addresses for your equipment; note there is a colon between the two IP addresses.



The router with just the phone attached, do the same thing but instead of the server IP address, put in the IP address of the phone:
forward:wifi:dport=5060,10000-20000 proto=udp dest=routerWiFiaddress:phoneIPaddress
For me, this was all that was needed.  The phones started working as if they were connected to the same LAN.



Here is a photo of a demonstration I set up at the November 2012 CVARC club meeting:

The Trixbox server running on the laptop and one phone connected to the left router (hiding behind the phone) and the other phone connected to the router on the right.

Helpful links:
http://fonality.com/trixbox/forums/trixbox-forums/trixbox-endpoints/need-help-remote-sip-extension-using-cisco-7940-60

Future work:
Move the Asterisk server to a small nettop, Rasberry Pi, Beagleboard, etc.

Tuesday, October 9, 2012

Cisco 7911G Hardware Info


Here is some hardware information on the Cisco 7911G VoIP phones that might be useful to someone down the line thinking of integrating the phones into a HSMM-MESHÔ system.
  • The power connector not same as the WRT54 series routers.  The DC power jack is a 5.5mm OD/2.5mm ID jack rather than the 5.5/2mm of the WRT routers.
  • It also runs off of the POE, which is 48V rather than 12V like some polycom phones.
  • The PoE chip is a TPS2375/2377 which according to the datasheet states it needs at least 30V to start power.  In experiments, I found that the phone won't turn on until at least 34V is presented to the DC power jack.  Using PoE over the Ethernet cable, it requires at least 36V to turn on.
  • PoE does not appear to care what DC polarity is on pins 3/4 and 7/8, either configuration worked for me

Cisco 7911G, SIP and Trixbox

I have seen a few people experiment with VoIP phones running over a HSMM-MESHÔ link and thought this could be an interesting experiment.  I have been thinking of experimenting with VoIP for a couple of years but never found a good reason to as I use my cellphone for just about everything.  I figured I would

One day searching through eBay a couple of weeks ago, I found an auction from a local electronics warehouse that was selling 16 Cisco 7911G phones for a price I couldn't pass up.  Cursory look on-line seemed that the configuration files were adequately documented so I started off on my journey.

I was looking for a entry-level Asterisk server program that I could load on an old laptop for testing.  Searching through the Internet, I found Trixbox - which is a self-contained Linux distro with Asterisk and FreePBX already installed.  Configuration is done through a web page interface - perfect for a Linux Padawan like myself.

Setting Trixbox to talk to my Polycom IP501 phone was extremely easy: went through the extension and phone setup pages and had everything configured in less than an hour thanks to YouTube videos and online tutorials.  Same thing with a softphone application on my Ubuntu desktop - Twinkle.  The Cisco phones, however, were not as easy....



Upgrading the phones to SIP firmware

Cisco has two different firmwares that you can load into the phone which will change it's behavior: SIP (Session  Initiated Protocol) and SCCP (Skinny Call Control Protocol).  SCCP is a proprietary protocol created and defined by Cisco, where SIP is a more open protocol and generally universal from what I've seen.  Since I don't know where this project will go in the long term, I'd rather not limit myself to one brand of phone or equipment so I decided to go with SIP.  Unfortunately the phones I bought were pulled from a business environment so it had SCCP firmware installed and needed to be changed.

Changing the firmware is a relatively easy task.  It involves having a tftp server on the network that serves the firmware files to the phone upon bootup.  After registering for a free account on the Cisco website, I was able to download the SIP9-3-1-1S firmware files and followed the instructions at this link to upgrade 7911 phones to SIP firmware:
http://lodge.glasgownet.com/tech/upgrade-a-cisco-7911-to-sip-firmware/




The configuration file

The Cisco 7911G phones use a XML file that gets loaded during bootup for all of it's settings and configuration.  This file sets things like the time and date format, the IP address of the VoIP server, the username and password for debugging and registration, etc.  This is where it started to get hairy.


My hope was that with Trixbox, I would just go through the same motions that I did with the Polycom phone and it would be a simple matter to get it working.  Boy, was I wrong.  Trixbox apparently has limited support for Cisco phones and does not have a default configuration for the 7911G phones.  Off to the Internet I went, hoping I could find a valid configuration file that someone had posted but came up empty handed.  I found a lot of forum posts that were similar to my situation but none of the configuration files worked.

After a week of trying different configuration files, settings, searching online and just as I was about to write the phones off and re-sell them on eBay, I finally found a configuration file that worked!



<device>
   <deviceProtocol>SIP</deviceProtocol>
   <sshUserId>user</sshUserId>
   <sshPassword>pass</sshPassword>
   <devicePool>
      <dateTimeSetting>
         <dateTemplate>D-M-YA</dateTemplate>
         <timeZone>New Zealand Standard/Daylight Time</timeZone>
         <ntps>
              <ntp>
                  <name>xx.xx.xx.xx</name>
                  <ntpMode>Unicast</ntpMode>
              </ntp>
         </ntps>
      </dateTimeSetting>
      <callManagerGroup>
         <members>
            <member priority="0">
               <callManager>
                  <ports>
                     <ethernetPhonePort>2000</ethernetPhonePort>
                     <sipPort>5060</sipPort>
                     <securedSipPort>5061</securedSipPort>
                  </ports>
                  <processNodeName>xx.xx.xx.xx</processNodeName>
               </callManager>
            </member>
         </members>
      </callManagerGroup>
   </devicePool>
   <sipProfile>
      <sipProxies>
         <backupProxy></backupProxy>
         <backupProxyPort></backupProxyPort>
         <emergencyProxy></emergencyProxy>
         <emergencyProxyPort></emergencyProxyPort>
         <outboundProxy></outboundProxy>
         <outboundProxyPort></outboundProxyPort>
         <registerWithProxy>true</registerWithProxy>
      </sipProxies>
      <sipCallFeatures>
         <cnfJoinEnabled>true</cnfJoinEnabled>
         <callForwardURI>x--serviceuri-cfwdall</callForwardURI>
         <callPickupURI>x-cisco-serviceuri-pickup</callPickupURI>
         <callPickupListURI>x-cisco-serviceuri-opickup</callPickupListURI>
         <callPickupGroupURI>x-cisco-serviceuri-gpickup</callPickupGroupURI>
         <meetMeServiceURI>x-cisco-serviceuri-meetme</meetMeServiceURI>
         <abbreviatedDialURI>x-cisco-serviceuri-abbrdial</abbreviatedDialURI>
         <rfc2543Hold>false</rfc2543Hold>
         <callHoldRingback>2</callHoldRingback>
         <localCfwdEnable>true</localCfwdEnable>
         <semiAttendedTransfer>true</semiAttendedTransfer>
         <anonymousCallBlock>2</anonymousCallBlock>
         <callerIdBlocking>2</callerIdBlocking>
         <dndControl>0</dndControl>
         <remoteCcEnable>true</remoteCcEnable>
      </sipCallFeatures>
      <sipStack>
         <sipInviteRetx>6</sipInviteRetx>
         <sipRetx>10</sipRetx>
         <timerInviteExpires>180</timerInviteExpires>
         <timerRegisterExpires>3600</timerRegisterExpires>
         <timerRegisterDelta>5</timerRegisterDelta>
         <timerKeepAliveExpires>120</timerKeepAliveExpires>
         <timerSubscribeExpires>120</timerSubscribeExpires>
         <timerSubscribeDelta>5</timerSubscribeDelta>
         <timerT1>500</timerT1>
         <timerT2>4000</timerT2>
         <maxRedirects>70</maxRedirects>
         <remotePartyID>false</remotePartyID>
         <userInfo>None</userInfo>
      </sipStack>
      <autoAnswerTimer>1</autoAnswerTimer>
      <autoAnswerAltBehavior>false</autoAnswerAltBehavior>
      <autoAnswerOverride>true</autoAnswerOverride>
      <transferOnhookEnabled>false</transferOnhookEnabled>
      <enableVad>true</enableVad>
      <preferredCodec>g729a</preferredCodec>
      <dtmfAvtPayload>101</dtmfAvtPayload>
      <dtmfDbLevel>3</dtmfDbLevel>
      <dtmfOutofBand>avt</dtmfOutofBand>
      <alwaysUsePrimeLine>false</alwaysUsePrimeLine>
      <alwaysUsePrimeLineVoiceMail>false</alwaysUsePrimeLineVoiceMail>
      <kpml>3</kpml>
      <natEnabled>false</natEnabled>
      <natAddress></natAddress>
      <phoneLabel>Version 3</phoneLabel>
      <stutterMsgWaiting>2</stutterMsgWaiting>
      <callStats>false</callStats>
      <silentPeriodBetweenCallWaitingBursts>10</silentPeriodBetweenCallWaitingBursts>
      <disableLocalSpeedDialConfig>false</disableLocalSpeedDialConfig>
      <startMediaPort>16384</startMediaPort>
      <stopMediaPort>32766</stopMediaPort>
      <sipLines>
         <line button="1">
            <featureID>9</featureID>
            <featureLabel>6003</featureLabel>
            <proxy>USECALLMANAGER</proxy>
            <port>5060</port>
            <name>cisco1</name>
            <displayName>Cisco Phone 1</displayName>
            <autoAnswer>
               <autoAnswerEnabled>2</autoAnswerEnabled>
            </autoAnswer>
            <callWaiting>3</callWaiting>
            <authName>user</authName>
            <authPassword>pass</authPassword>
            <sharedLine>false</sharedLine>
            <messageWaitingLampPolicy>3</messageWaitingLampPolicy>
            <messagesNumber>1111</messagesNumber>
            <ringSettingIdle>4</ringSettingIdle>
            <ringSettingActive>5</ringSettingActive>
            <contact>cisco1</contact>
            <forwardCallInfoDisplay>
               <callerName>true</callerName>
               <callerNumber>false</callerNumber>
               <redirectedNumber>false</redirectedNumber>
               <dialedNumber>true</dialedNumber>
            </forwardCallInfoDisplay>
         </line>
         <line button="2">
            <featureID>21</featureID>
            <featureLabel>Dial 6004</featureLabel>
            <speedDialNumber>6004</speedDialNumber>
         </line>
      </sipLines>
      <voipControlPort>5060</voipControlPort>
      <dscpForAudio>184</dscpForAudio>
      <ringSettingBusyStationPolicy>0</ringSettingBusyStationPolicy>
      <dialTemplate>DRdialplan.xml</dialTemplate>
   </sipProfile>
   <commonProfile>
      <phonePassword></phonePassword>
      <backgroundImageAccess>true</backgroundImageAccess>
      <callLogBlfEnabled>2</callLogBlfEnabled>
   </commonProfile>
   <loadInformation>SIP11.9-2-1S</loadInformation>
   <vendorConfig>
      <disableSpeaker>false</disableSpeaker>
      <disableSpeakerAndHeadset>false</disableSpeakerAndHeadset>
      <pcPort>0</pcPort>
      <settingsAccess>1</settingsAccess>
      <garp>0</garp>
      <voiceVlanAccess>0</voiceVlanAccess>
      <videoCapability>0</videoCapability>
      <autoSelectLineEnable>0</autoSelectLineEnable>
      <webAccess>0</webAccess>
      <spanToPCPort>1</spanToPCPort>
      <loggingDisplay>1</loggingDisplay>
      <loadServer></loadServer>
   </vendorConfig>
   <versionStamp>1143565489-a3cbf294-7526-4c29-8791-c4fce4ce4c37</versionStamp>
   <networkLocale>New_Zealand</networkLocale>
   <networkLocaleInfo>
      <name>New_Zealand</name>
      <version>5.0(2)</version>
   </networkLocaleInfo>
   <deviceSecurityMode>1</deviceSecurityMode>
   <authenticationURL>http://mako/authenticate.php</authenticationURL>
   <directoryURL>http://mako/directory.xml</directoryURL>
   <idleURL></idleURL>
   <informationURL>http://mako/GetTelecasterHelpText.jsp</informationURL>
   <messagesURL></messagesURL>
   <proxyServerURL></proxyServerURL>
   <servicesURL>http://mako/services.xml</servicesURL>
   <dscpForSCCPPhoneConfig>96</dscpForSCCPPhoneConfig>
   <dscpForSCCPPhoneServices>0</dscpForSCCPPhoneServices>
   <dscpForCm2Dvce>96</dscpForCm2Dvce>
   <transportLayerProtocol>2</transportLayerProtocol>
   <capfAuthMode>0</capfAuthMode>
   <capfList>
      <capf>
         <phonePort>3804</phonePort>
      </capf>
   </capfList>
   <certHash></certHash>
   <encrConfig>false</encrConfig>
</device>


From this base, make sure you change the appropriate values for your setup:
  • Change the timezone information to whatever you prefer
  • Change the <name> tag in the <sipLines> block.  It needs to be the same as the username
  • Change xx.xx.xx.xx to the IP address of the Trixbox server
  • Check all the URLs to make sure they align with the files hosted on the server
    • make a authentication script for the <authenticationURL> field
  • Change the <loadInformation> tag to match the firmware you have loaded in the phone
Go through the Cisco Phone setup, make an extension as usual and a 7940 phone.  Then go in and replace the XML file with this one.

Make sure on the Trixbox extensions to change nat=no and qualify=never -- somehow this was restricting the registration process and not allowing it to complete.



Ongoing work: 
  • Working on the NAT firewall and forwarding so that phones behind a HSMM-MESH nodes will be able to talk to the Trixbox server
  • Coming up with a directory scheme for users
  • connecting multiple Asterisk servers together for redundancy/load sharing?
  • What is the difference between Trixbox SEP.cnf file and one that works?


I hope this helps someone down the line.

Friday, September 7, 2012

WRT54 Router Information Links

I've been doing more research into the WRT54 router hardware and thought I would share some links that I have found:


WikiDevi: Database of thousands of wireless adapters, embedded systems, images, information, etc.
http://wikidevi.com/wiki/Main_Page


Copy of the IEEE specification 802.11-2007
http://www.ahltek.com/WhitePaperspdf/802.11-20%20specs/802.11-2007.pdf
Yes, I know it's outdated but for research on things like frequency stability, it does me just fine.



Making 802.11G Transmitter Measurements, whitepaper by Agilent
http://cp.literature.agilent.com/litweb/pdf/5988-7813EN.pdf


Search the FCCID database for any pertinant test data (use the FCCID found on the bottom of the routers):
https://apps.fcc.gov/oetcf/eas/reports/GenericSearch.cfm 

HSMM-MESH at the Pigman Triathlon 2012

The Pigman Triathlon long course is a half Ironman race, consisting of participants completing a 1.2 mile swim, 56 mile bike ride and a 13 mile run.  For many years, they have asked the Cedar Valley Amateur Radio Club to provide communications between the race officials, water stops, Sheriff departments and keep an overall watchful eye out for participants that need medical attention.

We traditionally run two net control locations, one dedicated to in-park portions and the running course and one about 3/4 mile away handling the bicycle portion of the race.  During the race this year, we decided to try a couple of new things, adding a HSMM-MESHÔ link between the two net control stations to use an IRC text chat and share APRSÔ data between the two spots.

On a scouting trip prior to the event, we found there was not line of site between the two shelter locations so we decided to set a node in the Gazebo's parking lot, which did have line-of-site to the North Shelter location.
Google Earth view of locations
When I got all the equipment set up the morning of the race, I was surprised on the robustness of the link.  100% link quality to both the gazebo parking lot and to the gazebo router (going through a few trees).  As soon as the router that had the IRC Chat server installed (at the North Shelter) was powered up, both computers connected to the server and never dropped out throughout the entire 8 hours.  We used the IRC server to share participant numbers for leads, sags, etc.  Simultaneously, we used an APRSÔ client, APRSIS32, with cached maps to track our chase vehicle following the last bike rider throughout the course.

Unfortunately as one of the NCS stations, I did not have enough time to test everything I would have liked (playing with output powers, recording data, antenna positioning) but as a first deployment of HSMM-MESHÔ, I would call it a success.

Antenna at North Shelter
Lessons learned:

  • Antenna height can make or break your link.  During the prior testing, the panel antenna at the North Shelter was not high enough, causing a bad link.  Elevating it the day of the race solved all those issues.
  • Having a deployment kit with everything needed makes setup a breeze (I came away with several ideas from this event, look for a couple of "go-kits" detailed here soon.
  • Don't rely on computers having the necessary software loaded.  Always bring a flash drive with the software you'll be using, just in case you are not using your own computer.
  • You really need to dedicate an operator to oversee 'special' tasks during a deployment (APRSÔ, HSMM-MESHÔ, etc) which leaves the other operators to focus on their jobs.
Equipment used:
  • Gazebo at entrance to park
    • WRT54GS router, modified for Part97 operation
    • One 5.2dBi omni-directional antenna (Cushcraft S2403B) bungee corded to gazebo
    • 3dBi antenna on other port
    • 19dBm output
  • Gazebo parking lot (had line of sight to north shelter)
    • WRT54GS router, modified for Part97 operation mounted on tripod
    • 12dBi omnidirectional antenna on tripod (~5' elevation to base of antenna)
    • 3dBi antenna on other second port
    • Belkin residential Gateway power supply
    • 19dBm output
  • North Shelter (0.75 miles distance from Gazebo)
    • WRT54GS router, modified for Part97 operation
    • 19dBi patch antenna (Tranzeo TR-CPQ-19), router mounted inside antenna enclosure
    • 9ft tripod stand (American DJ LTS-6)
    • 19dBm output
Future Ideas:
  • We've already talked about using a couple of cameras set up along a particularly crowded portion of the course inside the park, monitoring them on a computer screen
  • Now that we have proven it will work, possibly set up an APRSÔ display tracking first/last participants at the race official's table

Friday, August 10, 2012

First long-distance HSMM-MESH link

Last week I was able to find some free time to attempt my first "long distance" MESH link.  The link was from my house to the hill next to Nielson Hall at Kirkwood Community College.  I finished modifying two routers to be Part 97 devices by changing out the reference crystal and mounted them in a couple of surplus Transeo TR-CPQ-19 CPE antenna enclosures.

For the link setup, I placed one of the Transeo enclosures on my front porch, bungeed to keep it stationary as I didn't have a second tripod available for this test. For the location at Nielson Hill, as I nicknamed it, I had a tripod with the other Transeo enclosure attached and did my best to aim the patch in the direction of my house:



To get the best chance of a link, I left both the routers set to +19dBm initial output power (which translates to 6.275W EIRP on both ends).  I haven't come up with a good method of aiming the flat patch antennas yet, so I took my best guess.

Lo and behold, it connected right away, average of 12dB SNR margin, not bad for the first attempt:


I then began to decrease the power level on my end of the link to see how far I down I could go and still maintain the link.  Decreasing in 3dB steps (cutting the power in the power each time).  Here is a screenshot at the 13dBm output level.
Then something unexpected happened, the link completely died.  With no-one watching the other end of the link I'm suspecting that the antenna shifted such that the pattern was no longer lined up with the hill.





This test was mainly to test the distance link before heading out to the Pigman Triathlon race, where we're planning on using this equipment to create a link that will be about 0.75 miles in distance.  I am now comfortable saying as long as we have line of sight the link should work just fine.