Setting Up a Home APRS Digipeater and Igate

Somewhere between plugging a handheld into a laptop and building a mountaintop site, there’s a decision a lot of hams make casually and should make carefully: putting an APRS digipeater and igate on the air at their house.

The appeal is obvious. You already have the radio, the antenna, a Raspberry Pi, and an internet connection. The software is free. It takes an afternoon, and afterward your callsign shows up on the map with a digipeater symbol next to it, which feels like contributing to the network.

Sometimes it is contributing. Often it isn’t. APRS is one shared 1200 baud channel, and everything your station transmits is airtime that every other station in earshot pays for. A home station is the hardest place to get this right, because a home station has all of the ability to add traffic to the channel and very little of the coverage that would justify it.

This deep dive is about the home case: a normal station, a normal antenna, one radio, running all the time. It is not about mountaintop wide-area digipeaters, which are a different job with different answers. I’ll cover how to decide whether your location needs a digipeater at all, and then how to configure the digipeater, the beacon, and both directions of the igate so your station earns its airtime.

The principles here work with any software. I run Graywolf and recommend it, so after each set of principles I give the specific Graywolf settings that implement them. If you run something else, the principles still apply and you should be able to find the equivalent knobs.

Everything below assumes 144.390 MHz in North America and the New N Paradigm path conventions. Other regions use different frequencies and sometimes different regional aliases, but the shape of the advice doesn’t change.

What these two things actually do

They get lumped together because one box usually does both, but they are separate functions with very different risk profiles.

A digipeater listens for packets, looks at the digipeater path in the packet, and if it sees something addressed to it, rewrites the path and retransmits the packet on the same frequency. There are two kinds:

• A wide-area digipeater lives on a high site, responds to WIDEn-N and usually a regional SSn-N alias, and forms the backbone of APRS coverage in an area. Its value comes from its height.
• A fill-in digipeater lives at a normal elevation and responds only to WIDE1-1. Its only job is to catch packets from stations that can’t reach the wide-area digipeater and hand them up into the network.

The New N Paradigm is why that split works. Mobiles and trackers are supposed to use the path WIDE1-1,WIDE2-1: the first hop is deliberately reserved for a fill-in digipeater, and the second hop for a wide-area digipeater. If a mobile is already inside the wide-area digipeater’s footprint, that first hop is wasted. If it isn’t, a fill-in is the difference between being on the map and being invisible.

An igate is a gateway between RF and the APRS-IS internet network. It runs in two directions, and they are not remotely equivalent:

That table is the whole argument of this article. The receive side of an igate is free and helpful. Everything below it costs airtime, and the further down you go, the more careful you have to be.

Start with the half that can’t hurt

A receive-only igate never transmits. No PTT, no channel time, no chance of making anything worse. What it does do is put every packet you can hear onto APRS-IS, which is how those packets get to aprs.fi, to the phone app somebody’s spouse is using to watch them drive home, and to every other consumer of the network. In an area with thin igate coverage, this is a genuine contribution and it costs you nothing but electricity.

It’s also how you gather the data to answer every other question in this article. A month of receive-only logs tells you who you hear, how well you hear them, and whether anybody in your neighborhood is having trouble getting into the network. That’s a much better foundation than a guess.

A receive-only igate should still identify itself, but on APRS-IS only. Beacon your position and a comment saying what you are through the internet side, with no RF beacon at all. If you’re not transmitting, don’t advertise a symbol that implies you are.

Does your area need another digipeater?

This is the question people skip, and it’s the one that matters most. Before you enable digipeating, listen for a week and answer this: are the local mobiles using WIDE1-1,WIDE2-1 already getting into the wide-area digipeater directly?

If your WIDE1-1 hop is just duplicating packets the mountaintop digipeater already heard, you’re not adding coverage. You’re adding collisions. Every packet you repeat is a packet that can step on somebody else’s.

Here’s how to answer it with data instead of vibes:

1. From your receive-only igate logs, list the stations you hear directly, meaning zero used hops in the path. Those are the only stations your digipeater could ever help.
2. For each of those stations, look at its raw packets on aprs.fi and check whether a wide-area digipeater also hears it directly. The raw packet view shows the full path of every packet, so you can see exactly which digipeater moved what.
3. Anything you hear directly that the wide-area digipeater never hears directly is your case for a fill-in. If that list is empty, you don’t need a digipeater. You need an igate, which you already have.

A fill-in earns its keep where there’s a real hole: an urban canyon, a valley, a neighborhood where handhelds and low-power trackers can’t make it out. That work is done by terrain and height, not by software. If your antenna is at 20 feet in the same open valley as a digipeater at 8,000 feet, you aren’t filling anything in.

While you’re at it, ask the people who run the wide-area digipeaters in your area. They know where their coverage holes are, they’ve usually thought about this a lot, and they will tell you honestly whether another fill-in helps. Local APRS coordination is not as formalized as repeater coordination, but the courtesy is the same.

Picking the software

Any of the common packages can do everything in this article. The ones you’ll run into:

• Dire Wolf has been around a long time, is very well documented, and is what most tutorials assume.
• aprx is the classic minimal digipeater and igate daemon. It’s the only one of these three that implements viscous digipeating, which I’ll come back to.
• Graywolf is newer. It’s configured through a web UI instead of a config file, has presets for common digipeater roles, shows a live map of what you’re receiving, and exports Prometheus metrics so you can graph your own station.

I use Graywolf, both for the portable APRS command center and at home, and it’s what I’d recommend to somebody setting up a home station today. The web UI matters more than it sounds like it should: the settings in this article are ones you’ll want to revisit after you’ve watched the results for a week, and a config page you can pull up on your phone gets revisited more often than a YAML file you have to SSH in to edit.

Configuring the digipeater

Here’s the whole rule for a home fill-in: respond to exactly two things, WIDE1-1 and your own callsign. Nothing else.

A fill-in forwards only the fresh first hop from WIDE1-1 stations. It replaces the used-up WIDE1-1 with its own callsign, forwards any remaining path so the packet can continue up to a wide-area digipeater, and ignores everything else so it isn’t forwarding stale QRM.

Substitute your callsign, don’t just decrement

When you digipeat a WIDE1-1, replace the alias with your own callsign and set the has-been-digipeated bit, so the path reads K0TFU* rather than WIDE1* or WIDE1-0. This is called callsign substitution, and it’s what makes the path traceable: anybody looking at that packet later can see exactly which station moved it. It’s also what keeps you from looking like a dumb digipeater in somebody’s path analysis. Every modern package can do this, usually as a single checkbox.

Duplicate suppression: 30 seconds

Digipeaters have to remember what they’ve recently repeated, or two of them in earshot of each other will bounce the same packet back and forth. Thirty seconds is the conventional window.

The important detail is what you match on: source callsign, destination, and the information field, not the whole frame. The path changes as a packet moves through the network, so a frame that reaches you by a different route is still the same packet and still a duplicate. Matching the whole frame means you repeat it again.

UI frames only

Digipeat unconnected (UI) frames. Don’t digipeat connected-mode traffic. APRS is a UI-frame protocol, and connected-mode sessions have their own retry logic that a digipeater will only interfere with.

Viscous digipeating, if you can get it

This is the single biggest courtesy improvement available to a fill-in, and most people have never heard of it. Instead of repeating a packet immediately, hold it for about five seconds. If you hear a wide-area digipeater repeat it during the hold, throw yours away. Nobody needed you.

In overlapping coverage, this cuts your transmissions dramatically while losing nothing at all. You transmit only when no one else did the job, which is exactly the definition of filling in. aprx implements it as viscous-delay paired with directonly. Dire Wolf doesn’t have it, and Graywolf doesn’t expose it as of this writing. If you’re going to run a fill-in inside a wide-area digipeater’s footprint and your software supports it, turn it on.

In Graywolf

The Fill-in preset plus a preemptive rule for your own callsign gets you there:

Set the dedupe window to 30 seconds. A max hops of 1 means packets requesting more than one hop are ignored, which is exactly the fill-in behavior described above. Substitute your own callsign for K0TFU, obviously.

Configuring your beacon

Your digipeater needs to tell the world it exists, and the settings people get wrong here are the path and the symbol.

Path: none. Direct only. A fill-in digipeater’s beacon should have no digipeater path at all. This limits your visibility to your actual coverage area and keeps your beacons off the surrounding systems. If a fill-in isn’t heard directly by any igate, WIDE2-1 is sometimes justified, but you are the igate, so you have no excuse. No path.

Rate: every 10 to 30 minutes. Bruninga’s guidance for digipeaters specifically is 10 minutes, on the reasoning that digipeaters are the network’s lifelines and users need to know which one serves them. Direct-only beacons are cheap, so 10 minutes is affordable. On a busy channel, 20 or 30 is fine.

Symbol: # with a 1 overlay. The 1# overlay is the documented marker for a WIDE1-1 fill-in. It tells a mobile passing through, at a glance, that WIDE1-1,WIDE2-1 is the right path here. For reference, I# marks a digipeater with an igate attached, and S# marks a wide-area SSn-N digipeater. Don’t use S. You are not one.

You only get one overlay character, so a station that’s both a fill-in and an igate has to choose. I’d use 1, because the path hint is the more useful thing to broadcast to a passing mobile, and put “igate” in the comment text instead. If you’re running an igate that doesn’t digipeat at all, use the gateway symbol (&) with an appropriate overlay rather than a digipeater symbol.

Comment text: PHG plus a terse capability string. Something like PHG5230/W1 fill-in+igate. PHG is a compact encoding of your station’s Power, Height, Gain, and Directivity, and PHG5230 decodes as 25 watts, an antenna 40 feet above average terrain, 3 dB of gain, and omnidirectional. Users and network analysts both use it to understand what your station can do, and digipeaters in particular should publish it along with the path settings they want people to use.

Beacon to RF and to APRS-IS from the same beacon configuration. Don’t run a separate internet-only beacon with a path in it. One station, one identity, and the position you report to the internet should match the one you report on the air.

Gating RF to the internet

This direction is nearly always “gate everything,” and the exceptions are narrow:

• Don’t gate anything with TCPIP, TCPXX, NOGATE, or RFONLY in the path. Those are explicit instructions not to.
• Third-party frames (the ones starting with }) need a little care. Don’t gate ones that already carry TCPIP in the third-party header, because that packet came from the internet in the first place and sending it back creates a loop. For ones that don’t, strip the RF header and the third-party data type indicator before gating.
• Don’t modify the packet in any other way. Your software appends the q construct and your igate callsign, for example ,qAR,K0TFU-10, and that’s the only change that should happen.

Do not deduplicate before sending to APRS-IS. This is the counterintuitive one. Your instinct is that sending the same packet twice is wasteful, but the APRS-IS servers do content-aware deduplication themselves, and the duplicates you send are exactly what makes path analysis possible: they’re how tools can tell that a packet arrived by two different routes. Filtering them at your end throws that information away. This is documented in aprsc’s IGATE-HINTS, and Graywolf gets it right by default.

One other convention: the -10 SSID is traditionally used for internet gateways. If your station is one box doing both jobs, run it as a single station with a single identity rather than inventing separate callsigns for the digipeater and the igate.

Gating the internet to RF

This is where home igates do damage, and it’s worth being blunt about why. There is vastly more traffic on APRS-IS than a 1200 baud channel can carry. Any rule you write that gates traffic based on geography rather than on need will eventually gate more than your channel can hold.

Gate the minimum. The set of things a transmitting igate is supposed to send is small and specific:

1. Messages addressed to a station you’ve heard directly on RF, meaning zero used hops, within the last 30 minutes.
2. The acks and rejects for those messages.
3. The position of the sender of such a message, as a courtesy so the local station knows who’s calling them.

That’s the list. Transmitting to stations you haven’t heard floods the channel for no benefit, because a station you can’t hear can’t be helped by anything you transmit.

Do not gate bulletins, NWS broadcasts, telemetry, or “everything within N km.” That last one is the classic way a well-meaning home igate ruins a frequency. Everything on the internet is already on the internet. The only stations that need you to put it on the air are the ones without internet access, and those stations are the ones talking to you directly.

Transmit path for gated frames: none. Empty path, third-party wrapped. General igate guidance is to keep the path local, usually one hop at most, but since your gating criterion is “heard directly,” a path buys you literally nothing. The station you’re transmitting to can hear you.

“Directly” is worth repeating, because it’s easy to get wrong: zero used hops in the path. Not “heard through a digipeater.” Not “inside my filter radius.” Heard directly, within the last 30 minutes.

Two layers of filtering

Keep the APRS-IS server-side filter as narrow as it can be while still delivering messages, then let your local rules be the final gate.

For message service you generally need t/m at the server, because a message can originate anywhere in the world and you can’t range-limit the sender. That’s fine, because the local direct-heard test is what actually decides whether anything gets transmitted. What you should resist is adding an r/ range filter so you can watch what’s around you. On a transmitting igate, everything the server sends you is a candidate for transmission, and a filter you added for curiosity becomes a filter that generates airtime.

In Graywolf

Graywolf’s policy gate handles the heard-directly-in-30-minutes test, but a packet still needs a matching allow rule, and bare * Message Dest patterns are rejected. To express “any local station I heard directly,” you need a small set of Message Dest allow rules covering the callsign prefixes in your area. In the US that’s K*, N*, W*, and A*.

That’s only safe because the policy gate has already narrowed the candidates to directly heard addressees. The prefix rules are the second layer, not the first. Verify it in simulation mode before you key up, and if the rule layer turns out to widen things, you’ll see it in the log before it reaches the air.

Sharing one radio

You now have four things competing for one PTT: beacons, digipeated frames, messages gated in from APRS-IS, and whatever you transmit yourself. A few things to watch:

Loop prevention, in both directions. A frame you just gated in from APRS-IS must never be picked up and digipeated by your own digipeater, and your own callsign appearing in an inbound path should suppress retransmission. Most software handles both correctly, but verify it, because the failure mode is a self-sustaining loop that’s obvious to everybody on the channel and invisible from inside your own shack.

Watch your total transmit time. A fill-in plus a message igate on a healthy channel should account for a low single-digit percentage of airtime. If you’re above that, something is misconfigured, and the fix is almost always in the digipeater rules or the igate filter rather than in the beacon rate.

Graph it by source. If your software exports metrics (Graywolf publishes Prometheus counters), put transmissions on a dashboard broken out by source: beacon, digipeater, igate. The pattern to watch for is your digipeater count climbing while the number of stations you hear directly stays flat. That’s the signature of digipeating traffic that didn’t need you.

Remember it transmits when you’re not home. An automatically controlled station is still your station. Make sure you can shut it down from wherever you are, and make sure you’d notice if it started misbehaving.

Verify it, then keep watching

Give it a week, then pull your station up on aprs.fi and look at the raw packets, both yours and those of the mobiles near you.

• You want to see your callsign with an asterisk appearing as the first hop for nearby mobiles that then reached a wide-area digipeater. That’s a fill-in doing exactly its job.
• If you’re mostly showing up as a redundant second copy of packets the wide-area digipeater already carried, tighten up. Add viscous digipeating if you can, or turn the digipeater off and go back to being an igate. There’s no shame in that. It’s the more useful half anyway.
• Check that your own beacons show up with no path.
• Test messaging end to end. Have somebody with a handheld nearby send you a message from a phone app through APRS-IS, and watch it come down the internet-to-RF path and get acked.

Then keep watching. Dashboards, alerts, and a way to turn it off remotely are what separate a piece of local infrastructure from a thing that transmits in your garage.

The short version

If you remember one thing from all of this: gate more and digipeat less. The receive side of an igate is a gift to the network that costs the channel nothing, and a digipeater is a promise that you’re solving a problem somebody actually has.