{"id":387,"date":"2011-08-14T22:00:50","date_gmt":"2011-08-15T02:00:50","guid":{"rendered":"http:\/\/blog.alanporter.com\/?p=387"},"modified":"2011-08-14T22:00:50","modified_gmt":"2011-08-15T02:00:50","slug":"aprs-igate","status":"publish","type":"post","link":"https:\/\/alanporter.com\/blog\/2011\/08\/14\/aprs-igate\/","title":{"rendered":"APRS iGate"},"content":{"rendered":"

When I was working with the NC Nearspace group on our high-altitude balloon, we experimented with two different methods of tracking it once aloft: ham radio APRS, and a commercial system called “SPOT<\/a>“.<\/p>\n

We had some early failures with APRS.\u00a0 But over time, we have found that it’s a pretty nice technology, if you use the proper equipment.<\/p>\n

APRS, or “Automatic Packet Reporting System”, is a system that passes data packets over radios. It can be used for passing text messages, but most people use it for telemetry: tracking a vehicle’s position with a GPS, or on a weather station that broadcasts its weather readings every so often.<\/p>\n

Since we have been playing with APRS on our balloons, I wanted to learn more about it. I have been keeping my eyes open for a reasonably-priced handheld radio that can encode and decode APRS packets. Sure, some people use a special radio modem (called a “TNC”) to do the encoding\/decoding, but it’s important to me to have the modem and the radio in a single package, so I won’t have a big tangle of wires. This week, one such radio popped up on eBay, and so I bought it. While I waited for it to arrive, I did some homework on APRS and what it could do.<\/p>\n

Building an iGate at home<\/strong><\/p>\n

\"\"<\/a>

My "mobile" radio at home<\/p><\/div>\n

I already have two 2-meter radios: a small handheld “handy talkie” and a larger “mobile” radio that is designed to be installed in a car. So I tuned the mobile rig to 144.390 MHz and listened. It was a lot of static, with occasional squawks of data.<\/p>\n

Most of the time, if you wanted to decode the squawks, you would buy a packet TNC (modem) to convert the squawks to data, and you’d hook the modem to a computer to use<\/em> that data. But then I read an article about using your computer’s sound card to encode and decode the packets directly, with no modem at all. Heck, I was sitting around at home waiting for my new handheld-with-built-in-modem to arrive. Why don’t I try to do this modem-less setup?<\/p>\n

Look, Ma, no modem!<\/strong><\/p>\n

The first thing I did was hook the speaker output from the radio to my computer’s “audio in”. Optionally, I could have hooked the computer’s “audio out” to the microphone input of the radio. That second step is more complicated than you’d think, because I would also need to hook SOMETHING — maybe a parallel port pin — to the radio’s “push to talk” or “PTT” to turn the transmitter on before it’s ready send a squawk of data over the air.\u00a0 You really don’t want to just let it transmit all of the time… because other people are using that radio channel, too.<\/p>\n

\"\"<\/a>

My modest Linux server<\/p><\/div>\n

I chose the simple receive-only option, setting up my Linux-based server to “listen” to the radio. I downloaded a package called soundmodem<\/strong>, which is a APRS decoder program. It listens to the noise and the squawks, and it outputs a stream of decoded data.<\/p>\n

Soundmodem is hard to set up on a headless server, because the normal setup process involves running a graphical configuration program called “soundmodemconfig”.\u00a0 Since my server is “headless”, I don’t have a monitor or a keyboard or a mouse.\u00a0 I just connect to it over the network.\u00a0 So I could not run soundmodemconfig.\u00a0 So instead, I ran this program on my laptop and I copied the resulting configuration file back to the server. It was a pretty simple XML file that looked like this:<\/p>\n

\/etc\/ax25\/soundmodem.conf<\/p>\n

<?xml version=\"1.0\"?>\n<modem>\n  <configuration name=\"KISS\">\n    <channel name=\"Channel 0\">\n      <mod mode=\"afsk\" bps=\"1200\" f0=\"1200\" f1=\"2200\" diffenc=\"1\"\/>\n      <demod mode=\"afsk\" bps=\"1200\" f0=\"1200\" f1=\"2200\" diffdec=\"1\"\/>\n      <pkt mode=\"KISS\" ifname=\"sm0\" file=\"\/dev\/soundmodem0\" unlink=\"1\"\/>\n    <\/channel>\n    <chaccess txdelay=\"150\" slottime=\"100\" ppersist=\"40\" fulldup=\"0\" txtail=\"10\"\/>\n    <audio type=\"soundcard\" device=\"\/dev\/dsp1\" halfdup=\"1\"\/>\n    <ptt file=\"none\" gpio=\"0\" hamlib_model=\"\" hamlib_params=\"\"\/>\n  <\/configuration>\n<\/modem><\/pre>\n
The important parts are where it says it’ll read the audio<\/strong> device \/dev\/dsp1<\/code> and it’ll create a KISS<\/strong>-mode packet<\/strong> device called \/dev\/soundmodem0<\/code>.<\/p>\n
To start the APRS decoder program, I just run \/usr\/sbin\/soundmodem \/etc\/ax25\/soundmodem.conf &<\/code>. If it all works, then I can just do tail -f \/dev\/soundmodem0<\/code> and see some packets on the screen, with some header garbage and then some readable payload data with a bunch of callsigns.\u00a0 That is enough of an indication that the decoding is working correctly.<\/p>\n
The iGate software<\/strong><\/p>\n
The second piece of software I installed was a digipeater package called APRS4R<\/strong>. I had read a story about a guy who put a small TNC (radio modem) board inside of a Linksys WRT54G router and turned it into a very small portable digitpeater. He ran APRS4R on the router, and so I figured that this program must be pretty lightweight. So I should be able to run it on my modest Linux server.<\/p>\n
APRS4R is written in Ruby (that’s what the “for R” ending means), and it is configured using a single text file. Here is the configuration file that I came up with.<\/p>\n
--- !ruby\/object:APRS4R::APRS4RConfiguration\nversion: 1.0.2\ndevices:\n  device0: !ruby\/object:APRS4R::AX25SocketConfiguration\n    name: rf0\n    type: AX25Socket\n    enable: true\n    remote:\n    deprecated:\n    call: KR4JB\n    device: \/dev\/soundmodem0\n    port:\n    baudrate: 9600\n    mode: kiss\/tnc2\/northlink\n    speed:\n    duplicatePeriod: 20\n    timeout:\n    parameters: !ruby\/object:APRS4R::KISSDeviceConfiguration\n      name: kiss port\n      type: KISSDevice\n      enable: true\n      remote: false\n      deprecated: false\n      device: \/dev\/soundmodem0\n      baudrate: 9600\n      port:\n      speed: 1200\n      timeout: 300\n      txdelay:\n      persistence:\n      slottime:\n      duplex:\n  device1: !ruby\/object:APRS4R::ISSocketConfiguration\n    name: is0\n    type: ISSocket\n    enable: true\n    remote:\n    deprecated:\n    hosts: [third.aprs.net]\n    port: 14580\n    username: KR4JB\n    filter: \"# filter m\/100\"\n    duplicatePeriod: 20\n    timeout: 60\nplugins:\n  plugin1: !ruby\/object:APRS4R::BeaconPluginConfiguration\n    name: igate is beacon\n    type: BeaconPlugin\n    enable: true\n    remote:\n    deprecated:\n    device: is0\n    period: 1200\n    offset: 30\n    message: !ruby\/object:APRS4R::APRSMessage\n      source: KR4JB\n      destination: AP4R10\n      path: []\n      payload: \"!3546.30N\/07852.07W-&APRS4R CARY NC\"\n  plugin10: !ruby\/object:APRS4R::GatewayPluginConfiguration\n    name: rf02is0 Gateway\n    type: GatewayPlugin\n    enable: true\n    remote:\n    deprecated:\n    call:\n    inDevice: rf0\n    outDevice: is0\n    localOnly:\n    replacePath:\n    path:<\/pre>\n
\"\"<\/a>
My house on the map at APRS.FI<\/p><\/div>\n
It’s kind of verbose, but it basically defines two devices called “rf0” (the radio) and “is0” (the internet).<\/p>\n
Then it defines a few “plug-ins”, which are actions. I use two actions: a beacon<\/strong> that sends my call letters and position to the APRS internet site, and a gateway<\/strong> that forwards (some) packets from the radio to the internet.<\/p>\n
If I had hooked up my radio to transmit as well as receive, then I would have also transmitted a beacon on the rf0 channel, and probably forward some<\/em> of the incoming internet packets to the radio.<\/p>\n
The only tricky bits in this file were:<\/p>\n
    \n
  • For the “is0” destination, I chose a random host from a list that I saw in example files. Mine is “third.aprs.net”.<\/li>\n
  • The “destination” in the beacon is AP4R10<\/code>. That is the code for the APRS4R software package. I have no idea why I send my beacons TO some oddly-named station to signify that I am using this digipeater software package.<\/li>\n
  • The “payload” string in the beacon is \"!3546.30N\/07852.07W-APRS4R CARY NC\"<\/code>. It consists of a few parts: a bang, my latitude, slash (means “primary icon set”), my longitude, minus (means “house icon” in the primary icon set), and the rest is a comment with my software package name and my location city and state.<\/li>\n
  • I had a hard time choosing which SSID<\/strong> (dash number after my callsign) to use. I finally decided that it does not really matter, because there are several conflicting conventions. But I like using “KR4JB” with no suffix to mean “home”. I will use “-1” for my new handheld and “-2” on the (internet-only) OpenAPRS app my iPhone.\u00a0 If I buy more toys, they will get higher numbers.\u00a0 Balloons typically use “-11”.<\/li>\n<\/ul>\n
    Stuff I didn’t do – and why<\/strong><\/p>\n
    There were other APRS4R plugins that did stuff like full two-way digipeating and sending beacons on the radio. But my station is a one-way iGate, so I did not need them. My station forwards packets that it hears on the radio to the internet. It does not forward internet packets to the radio.<\/p>\n
    And my station is not a digipeater<\/strong>, it does not retransmit packets that it has heard on the air.<\/p>\n
    I run my station as a receive-only iGate for two reasons:<\/p>\n
      \n
    • Most immediately, I did not have a cable to hook into the microphone jack of my mobile radio, and rigging up the PTT looks like a hassle.<\/li>\n
    • More importantly, you need to coordinate with other digipeaters and gateways around you before you start transmitting packets over the air.<\/li>\n<\/ul>\n
      —<\/p>\n
      This has all been a lot of fun, and I have learned a lot about packet radio.\u00a0 Since I went down a few wrong paths, I learned a lot of stuff that was not immediately applicable.\u00a0 But in this article, I have summarized the parts that got my receive-only iGate working in a single afternoon.<\/p>\n
      Now I am waiting for my new APRS-capable radio to show up!<\/p>\n","protected":false},"excerpt":{"rendered":"
      When I was working with the NC Nearspace group on our high-altitude balloon, we experimented with two different methods of tracking it once aloft: ham radio APRS, and a commercial system called “SPOT“. We had some early failures with APRS.\u00a0 But over time, we have found that it’s a pretty nice technology, if you use […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-387","post","type-post","status-publish","format-standard","hentry","category-geek","count-0","even alt","author-alan","last"],"_links":{"self":[{"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/posts\/387","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/comments?post=387"}],"version-history":[{"count":0,"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/posts\/387\/revisions"}],"wp:attachment":[{"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/media?parent=387"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/categories?post=387"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/alanporter.com\/blog\/wp-json\/wp\/v2\/tags?post=387"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}