RF Message Paths
- I'm working on a couple of IGates running APRSIS32 and am having a little trouble with messaging.
If I understand the current thinking correctly, fixed stations should now be using either WIDE2-1 or WIDE2-2 (or no path at all) so they don't awaken fill-in digipeaters. Fill-in digipeaters should only digipeat WIDE1-1. And mobile and portable stations typically use WIDE1-1,WIDE2-1 to allow them to use the fill-ins. I have followed these guidelines and they work well except for messaging. Here is the scenario:
My HT, with low power and poor antenna, is unable to reach a "real" digipeater or IGate without using a fill-in (WIDE1-1) digipeater. With the help of a fill-in, it can easily reach both. The IGate hears it, and igates its beacons and messages to APRS-IS. The problem is with the message return path. The IGate transmits messages via RF to the HT, and, if the IGate is configured with a WIDE2-1 beacon path, the real digipeaters also repeat them. But since they aren't transmitted with a WIDE1-1 path, the fill-in near the HT, the only station capable of delivering the message, does not repeat the message, and the HT doesn't receive it. It seems to me that ideally the IGate needs to transmit the message using the path on which it heard the HT, but I don't see any way to configure this behavior. And I don't see any workaround that doesn't have negative effects on the local RF environment (such as changing the IGate beacon path to WIDE1-1).
So my question is this: Do I have it right? And if so, what are the chances that a "feature request" for "smart message return paths" might be considered? I really like APRSIS32 and appreciate all the work that has gone into getting it where it is today.
- On 7/8/2011 5:52 PM, Chuck Hatcher N4XS wrote:
> So my question is this: Do I have it right? And if so, what are the chances that a "feature request" for "smart message return paths" might be considered? I really like APRSIS32 and appreciate all the work that has gone into getting it where it is today.So-called "smart" return paths is actually not possible given the
configuration of too many digipeaters. Until every digipeater can be
relied upon to actually INSERT rather than REPLACE path components, any
given packet cannot be traced back to the source. Also, even though we
like to think of WIDE1 and WIDE2 (indeed, WIDEn) as "magic", they
actually look just like another digipeater station to software. And
please don't tell me to code in "knowledge" of WIDEn, because there's
also the state-based initiative that is completely (to my last search)
undocumented. Can you tell me what SSn alias is in your area?
I've considered it, reviewed packets from all over the place (see
http://tinyurl.com/Act24) and concluded that there isn't a "magic
bullet" for this one.
The general idea for WIDE1 fill-ins, is that local stations can still
hear the WIDE2's transmissions. At least, that's been my
understanding. Low powered stations need the WIDE1 boost to get out,
but the WIDE2 can still be heard within the WIDE1's "local" coverage
I'll keep thinking on it, but "reversing" an arbitrary "heard" path
isn't high on my priority list at the moment. Allowing a separately
configured -IS to RF IGate path for messages may actually make it in
though. But please don't even THINK about making the path anything
crazy like WIDE2-1,WIDE1-1 to "reach down into the holes". There's a
station in Miami (180 miles south of me) that runs WIDE2-2,WIDE1-1 and
he keeps lighting up my fill-in digi when his packets hop through this
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> The general idea for WIDE1 fill-ins, is that local stations can stillThanks for the quick reply, Lynn. I understand now that what I was asking
> hear the WIDE2's transmissions. At least, that's been my
> understanding. Low powered stations need the WIDE1 boost to get out,
> but the WIDE2 can still be heard within the WIDE1's "local" coverage
for is not as straightforward as it first seemed. I think what I will do is
to try adding WIDE2-1 to the fill-in digipeater. Of course this will only
address the fill-in I have control over, but the fact that my HT can't hear
the other digipeaters means that digipeater coverage in this hole is poor,
and it will fill a need until better coverage exists. Of course a better
solution would be to add APRS-IS connectivity to the fill-in so it could
transmit the RF message to the HT with no path, but that is not currently an