Aprx as a WIDE1-1 Digipeater

[Kenneth Finnegan]

I haven't forgotten about you Evan. My router died this week, so I've been spending most of my free time rebuild it before getting to your config.

https://gist.github.com/PhirePhly/a82ac89442e9678d9030de9ef5acd668#file-aprx-conf-kd0yuj-L36-L50

One unrelated thing I do find interesting is your giant regex-filter matrix to force Aprx to be a WIDE1-1 fill-in digi. Did you come up with that trick on your own or is someone else out there advocating this?

I would be interested to hear your (and anyone else doing something like this) thoughts on what's motivating you to operate as a WIDE1-1 digipeater instead of as a directonly digipeater. Is it primarily for specification compliance with Bob's idea for how the APRS network should operate? Or is there anything about the directonly concept that is unappealing or confusing/ poorly documented?

--
Kenneth Finnegan, W6KWF
http://blog.thelifeofkenneth.com/

On Mon, Oct 31, 2016 at 5:27 PM, <kd0...@gmail.com> wrote:

As far as I can remember, there are only a couple config files, which I have attached.

I also run  "kissattach /dev/ttyS0 aprs 10.0.0.1" from the command line.

My aprx.conf file is the result of months of tweaking, and it now does exactly what I want it to do.

Many thanks to you Kenneth and Matti for your work on this project.

On Sunday, October 30, 2016 at 2:10:20 PM UTC-5, Kenneth Finnegan wrote:

So it would seem that with respect to the dropping depleted aliases patch what your showing is success.

There now seems to be the problems that axlisten is unable to correctly parse transmitted packets, and Aprx isn't logging a bunch of packets. Has anyone else noticed issues with the HDLC address extension bit or logging?

Since you're using axlisten, I assume you're using an AX25 interface? Can we see all of your config files?

Aprx supports the concept of "directonly" fill-in digipeating instead of WIDE1-1 fill-in, since it tends to be more effective for catching first hops than relying on users to write their paths correctly. I'd suggest you run it with the directonly option and see if it behaves like how you'd like.

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/

On Sun, Oct 30, 2016 at 8:25 AM, <kd0...@gmail.com> wrote:

For my setup, I downloaded the tarball for 2.9.0 and substituted the stock digipeater.c file with the one listed above.
After compiling and running for a few minutes, the results were mixed.

Example 1:
-- output from axlisten
aprs: fm KD0NBO-9 to DJBV2X via WIDE1-1 WIDE2-1 ctl UIv pid=F0(Text) len 17
`zD.l ->/`"7F}_"
aprs: fm KD0NBO-9 to DJBV2X via KD0YUJ* WIDE2-1 ctl UIv pid=F0(Text) len 17
`zD.l ->/`"7F}_"

-- from aprx-rf.log
2016-10-30 06:13:39.990 KD0YUJ    R KD0NBO-9>DJBV2X,WIDE1-1,WIDE2-1:`zD.l ->/`"7F}_"
2016-10-30 06:13:39.991 KD0YUJ    T KD0NBO-9>DJBV2X,KD0YUJ*,WIDE2-1:`zD.l ->/`"7F}_"<0x0d>

In example 1, aprx appears to behave as advertised. The output from axlisten is in agreement with the entries in the aprx-rf.log


Example 2:
-- output from axlisten
aprs: fm LSBRG to APMI01 via KD0BTX* WIDE2-1 ctl UI pid=F0(Text) len 42
@300613z3834.82NS09437.03W# ap...@K0HAM.com
aprs: fm LSBRG to APMI01 via KD0BTX* KD0YUJ* [invalid] [invalid] [invalid] ctl I12 pid=33 len 21
7.03W# ap...@K0HAM.com

-- from aprx-rf.log
2016-10-30 06:13:57.753 KD0YUJ    R LSBRG>APMI01,KD0BTX*,WIDE2-1:@300613z3834.82NS09437.03W# ap...@K0HAM.com
(no transmit packet was logged for TX)

In example 2, LSBRG was not heard direct by my station.  I would assume WIDE2-2 was the original request and the digi performed by KD0BTX.  In this example, it does not appear aprx behaved properly.


Example 3:
-- output from axlisten
aprs: fm KC0DDZ to S8UX7S via RESRCH* WIDE1* WIDE2-1 ctl UI pid=F0(Text) len 35
`z8?l W>/'"74}MT-AIO|!F&7'j|!w5Z!|3
aprs: fm KC0DDZ to S8UX7S via RESRCH* WIDE1* KD0YUJ* [invalid] [invalid] ctl I12 pid=7D len 21
MT-AIO|!F&7'j|!w5Z!|3

-- from aprx-rf.log
2016-10-30 06:14:07.861 KD0YUJ    R KC0DDZ>S8UX7S,RESRCH*,WIDE1*,WIDE2-1:`z8?l W>/'"74}MT-AIO|!F&7'j|!w5Z!|3
(no transmit packet was logged for TX)

Example 3 is not much different than example 2, except there is a used-up WIDE1 alias prior to my station answering the WIDE2-1 request.


I normally run a fill-in digipeater answering WIDE1-1 requests only.  For my configuration, it would appear the modification would work, however I would still like to see how aprx behaves when WIDE1-1 is the only requested.

--
You received this message because you are subscribed to the Google Groups "Aprx software" group.

To unsubscribe from this group and stop receiving emails from it, send an email to aprx-softwar...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Aprx software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to aprx-software+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[kd0...@gmail.com]

Kenneth:

First I probably need to explain my decision for only being a WIDE1-1 digi. The main reason is to keep the aprs transmit duty to a minimum to reduce desense to the other radios at my home station.
Aside from that, my lower elevation WIDE1 station provides a more collision-free receiver to the local area. The subsequent WIDE2's being higher elevation/higher power can take it from there.  I think this is pretty much text-book and doesn't require much explantion here.

As for the digipeater vs directonly setting, I think in the majority of cases there are no differences when operating as a WIDE1-1 only digi.
The only scenario where it might make a difference is when WIDE1-1 is NOT the first digi in the sending station's via-path.  I have logged at least one station using a via-path "WIDE2-2, WIDE1-1".  It's clearly wrong, but something you may need to deal with if it becomes a problem. In this example, the directonly option would be the better choice if you wish to deny a digi request for that packet. I would hate to be too quick to disallow it however.  In a remote area, you might want to set up a hand-held's via path to "TEMP1-1,WIDE1-1" to make use of a vehicle's TEMP1-1 digipeater.
The reason I have mine as digipeater is so that should the need arise, I can quickly transform my station to also answer WIDE2-N and WIDE3-N requests by simply commenting out the appropriate regex-filter lines from the configuration file, then restart aprx.
Although I can't say for sure, but I think the main reason for having two choices is that directonly is necessary with the viscous-delay option.

The giant regex-filter idea came from this thread:
https://groups.google.com/forum/#!searchin/aprx-software/%22regex-filter%22$20and$20via|sort:relevance/aprx-software/oF_G1avjBFQ/BJHVoHyT6dkJ

It's possible there may be a more efficient way of handling this, but my multiple regex-filter lines seem to work.  Separation of multiple entries on a single line with the vertical pipe "|" character seems missing in the documentation however.

To resolve LA9VKA's issue in that particular thread, you'll notice the regex-filter uses "destination", which is why the configuration isn't doing it's job.
Simply changing "destination" to "via" would probably resolve that issue.

Evan

[Kenneth Finnegan]

On Mon, Nov 7, 2016 at 12:34 PM, <kd0...@gmail.com> wrote:

The main reason is to keep the aprs transmit duty to a minimum to reduce desense to the other radios at my home station.

Viscous-delay usually causes a significant reduction in Tx activity, if that's what you're after. I don't think it is limited to digipeaters running in directonly mode, so you should be able to play with it regardless.

 

It's possible there may be a more efficient way of handling this, but my multiple regex-filter lines seem to work.  Separation of multiple entries on a single line with the vertical pipe "|" character seems missing in the documentation however.

I don't see ANY documentation on how to use the regex-filter expression in the manual. PR opened: https://github.com/PhirePhly/aprx/issues/34

It uses the POSIX extended regular expression syntax, so I don't think we need to add the actual syntax to the manual so much as just explicitly point people at the regex(7) man page. To answer your question without actually checking my suggestion, I think you can replace all of your regex-filter lines with the following:

regex-filter via WIDE[2-7]

regex-filter via TRACE[:digit:]

regex-filter via RELAY

Now that I think about it a little more, doesn't this reject any packets which have WIDEn (n>1) anywhere in the via list? I think you're filtering out paths like WIDE1-1,WIDE2-1 despite them asking for WIDE1-1 service. Are you seeing your digi serve any path requests except only "WIDE1-1"?

Thanks for the rest of your thoughts. It's useful to understand how people are using Aprx as I start planning more significant changes to the codebase. I go back and forth on whether to add WIDE1-1 fill-in support vs push for APRS to move past that kludge to something better. I'd love it if we could stop needing to explain "WIDE2-1 is asking for one hop, but you originally requested two, but not really".

I spent a few hours working on your original problem this weekend, and have confirmed that Aprx does seem to not be logging many digipeated transmissions, which is a BIG problem. Thanks again for bringing it up. I'll continue to put time on finding a solution to this issue as I can. https://github.com/PhirePhly/aprx/issues/33

[kd0...@gmail.com]

Viscous-delay usually causes a significant reduction in Tx activity, if that's what you're after. I don't think it is limited to digipeaters running in directonly mode, so you should be able to play with it regardless.

I tested the viscous-delay feature for several months and found it unsuitable for my location.  I don't mean to knock the option itself, because I can see certain circumstances where it would work well.  In my case however, I could decode certain packets direct, but not decode a subsequent digipeater due to the collisions from multiple WIDE1's.  My logs were indicating the subsequent WIDE2's followed by my WIDE1 digipeat followed by more WIDE2's.  It was pretty clear to me that too many copies of the packet were going out on the channel. 

 

 

It's possible there may be a more efficient way of handling this, but my multiple regex-filter lines seem to work.  Separation of multiple entries on a single line with the vertical pipe "|" character seems missing in the documentation however.

I don't see ANY documentation on how to use the regex-filter expression in the manual. PR opened: https://github.com/PhirePhly/aprx/issues/34

Actually, it's on page 45 of the aprx pdf manual for version 2.9, however it lacks an example.


 

It uses the POSIX extended regular expression syntax, so I don't think we need to add the actual syntax to the manual so much as just explicitly point people at the regex(7) man page. To answer your question without actually checking my suggestion, I think you can replace all of your regex-filter lines with the following:

regex-filter via WIDE[2-7]

regex-filter via TRACE[:digit:]

regex-filter via RELAY

The above WIDE[2-7] works the same as the multiple entries in my original config file.
Packets using TRACE are rare, so I really can't report the results of that entry.

 

Now that I think about it a little more, doesn't this reject any packets which have WIDEn (n>1) anywhere in the via list? I think you're filtering out paths like WIDE1-1,WIDE2-1 despite them asking for WIDE1-1 service. Are you seeing your digi serve any path requests except only "WIDE1-1"?

I think I am understanding this right...
"Regex-filter via" appears to only test the first unused digi in the via-path chain, and not the entire line.
Here is how my station behaves with the patch applied to 2.9.0:

2016-11-08 01:19:13.697 KD0YUJ    R KB0YME-1>SYQV7Y,WIDE1-1,WIDE2-1:`zQQl]6k/]"6`}=
2016-11-08 01:19:13.697 KD0YUJ    T KB0YME-1>SYQV7Y,KD0YUJ*,WIDE2-1:`zQQl]6k/]"6`}=<0x0d>
2016-11-08 01:19:17.370 KD0YUJ    R KB0YME-1>SYQV7Y,KD0YUJ*,KC0GP-3*,WIDE2*:`zQQl]6k/]"6`}=

 

[Tom Hayward]

On Mon, Nov 7, 2016 at 6:29 PM, <kd0...@gmail.com> wrote:
>>
>> Viscous-delay usually causes a significant reduction in Tx activity, if
>> that's what you're after. I don't think it is limited to digipeaters running
>> in directonly mode, so you should be able to play with it regardless.
>
> I tested the viscous-delay feature for several months and found it
> unsuitable for my location. I don't mean to knock the option itself,
> because I can see certain circumstances where it would work well. In my
> case however, I could decode certain packets direct, but not decode a
> subsequent digipeater due to the collisions from multiple WIDE1's. My logs
> were indicating the subsequent WIDE2's followed by my WIDE1 digipeat
> followed by more WIDE2's. It was pretty clear to me that too many copies of
> the packet were going out on the channel.

In cases like this it could be valuable to have viscous-delay watch
for a duplicate packet on all sources rather than just the source with
viscous-delay defined. That way if a packet is digipeated and received
by another igate, you have the opportunity to receive it over APRSIS
and cancel the your digipeat. Does anyone see a flaw in this logic?

Tom KD7LXL

[Bill Vodall]

> In cases like this it could be valuable to have viscous-delay watch
> for a duplicate packet on all sources rather than just the source with
> viscous-delay defined. That way if a packet is digipeated and received
> by another igate, you have the opportunity to receive it over APRSIS
> and cancel the your digipeat. Does anyone see a flaw in this logic?

That confirms that the packet made it to the aprs-is but not that it
made it to the RF neighborhood. Perhaps this could be made smarter
so folks with an yet to be created APRS-IS ONLY path would not be
repeated and stations with a request for RF coverage (WIDE2-2, etc)
would be repeated.
>

Bill

[Tom Hayward]

The context is as a dupe filter, so we would know it made it to RF
because we just received it. It would only trigger the dupe filter
when received on both APRSIS and RF.

Tom

[Bill Vodall]

>> That confirms that the packet made it to the aprs-is but not that it
>> made it to the RF neighborhood. Perhaps this could be made smarter
>> so folks with an yet to be created APRS-IS ONLY path would not be
>> repeated and stations with a request for RF coverage (WIDE2-2, etc)
>> would be repeated.
>
> The context is as a dupe filter, so we would know it made it to RF
> because we just received it. It would only trigger the dupe filter
> when received on both APRSIS and RF.

This is perhaps the flaw with Viscus digipeating... You don't know
the station on the other side of the hill received the packet because
you didn't see the digi on the hill repeat it - because it sometimes
comes only from your local digipeat. Perhaps Viscus needs a count
threshold... Resend if not heard X times.

[Kenneth Finnegan]

On Tue, Nov 8, 2016 at 8:05 AM, Tom Hayward <esa...@gmail.com> wrote:

That way if a packet is digipeated and received
by another igate, you have the opportunity to receive it over APRSIS
and cancel the your digipeat. Does anyone see a flaw in this logic?

The APRS-IS server isn't going to send you a dupe of a packet you I-gated two seconds ago.

I guess I do need to backpedal a little and point out that while it is *possible* to use viscous delay on regular wide digipeaters, it still makes the most sense while paired with directonly, since that prevents Evan's issue:

[Missed original station TX over the horizon]

[Lots of missed doubled WIDE1-1 digis]

EXAMPL>APRS,WIDE1-1*,HIGH*,WIDE2-1

At this point, we've only heard the packet once, so viscous delay would rightly digipeat it. If you don't want to be part of the high level digipeater chain, it's the fact that the packet already has two consumed hops that trips the directonly filter that's supposed to save you.

I'm still trying to wrap my head around how to support digipeating "TEMP1-1*,WIDE1-1" within Aprx. There really wasn't much consideration given to three tier networks (TEMP, Fill-in, Wide) during the APRS design process. Fill-in digis were meant to be the smallest cell on the network to shuttle low-power tracker and deep valley traffic up into the high level digipeater network. Trying to support a car digi as an even smaller cell than that takes some thought.

Bill Vodall:

Perhaps this could be made smarter
so folks with an yet to be created APRS-IS ONLY path would not be
repeated and stations with a request for RF coverage (WIDE2-2, etc)
would be repeated.

Ohhhh boy. I've lost count of the number of times this has been asked for on the SIG, and shot down because it either depends on behavior which can't be configured for a KPC3, violates the source-routing principle of APRS, or just because no digipeater is also an I-gate. For the record, I think all of those arguments hold less water in 2016 than they might have in the past.

[kd0...@gmail.com]

I'm still trying to wrap my head around how to support digipeating "TEMP1-1*,WIDE1-1" within Aprx. There really wasn't much consideration given to three tier networks (TEMP, Fill-in, Wide) during the APRS design process. Fill-in digis were meant to be the smallest cell on the network to shuttle low-power tracker and deep valley traffic up into the high level digipeater network. Trying to support a car digi as an even smaller cell than that takes some thought.

 TEMPn-N seems to be one of aprs's best kept secrets.  I've been watching my logs since April when I began using aprx, and have never logged a single TEMPn-N request.

Here's a little information about it:
http://www.aprs.org/TEMPn-N.html

I put this to the test this afternoon when I spotted a Kenwood TM-D710 equipped 18-wheeler near my station.  I sent a test "message" packet to my own callsign.

$ /usr/sbin/beacon -s -d "APRS TEMP1-1" aprs ':KD0YUJ   :Test'

aprs: fm KD0YUJ to APRS via TEMP1-1 ctl UI^ pid=F0(Text) len 15
:KD0YUJ   :Test
aprs: fm KD0YUJ to APRS via WB0HBJ-14* TEMP1* ctl UI^ pid=F0(Text) len 15
:KD0YUJ   :Test

I can see this being extremely useful in day-to-day use when a hand held can't reach a permanent digi.  The hand held user simply prepends their existing VIA path with TEMP1-1 to take advantage of the Kenwood mobile, or any other radio that supports TEMPn-N.

In order to avoid interfering with field day rules, I don't feel a fixed station with permanent infrastructure should digi TEMPn-N requests, however I might like to use it someday in a portable go-box to use at various locations.

I really didn't mean to throw a wrench into the works when I brought this up, but since you're thinking of a re-write, it's something I thought you might like to consider.

I'm also not sure what the status is on the SSn-N "statewide" alias.  Some earlier threads led me to believe that it wasn't working properly, but I can't confirm it.

Evan

[Kenneth Finnegan]

On Thu, Nov 10, 2016 at 2:36 PM, <kd0...@gmail.com> wrote:

I'm still trying to wrap my head around how to support digipeating "TEMP1-1*,WIDE1-1" within Aprx. There really wasn't much consideration given to three tier networks (TEMP, Fill-in, Wide) during the APRS design process. Fill-in digis were meant to be the smallest cell on the network to shuttle low-power tracker and deep valley traffic up into the high level digipeater network. Trying to support a car digi as an even smaller cell than that takes some thought.

 TEMPn-N seems to be one of aprs's best kept secrets.  I've been watching my logs since April when I began using aprx, and have never logged a single TEMPn-N request.

Frankly, TEMPn-N is one of Bob's dreams which doesn't seem to solve more problems than it creates. The tracker ecosystem has ended up in a situation where many trackers don't support on-the-fly changes to their path settings while in the field. If during an event you need a fill-in digi somewhere, why not set up a WIDEn-N fill-in digi there? Why do we think it's easier for every tracker user in the field to change their path settings than for individual digi operators to turn on their fill-in digis?

I'm also not sure what the status is on the SSn-N "statewide" alias.  Some earlier threads led me to believe that it wasn't working properly, but I can't confirm it.

I think the issue was that the non-trace aliases don't handle n-N --> n-(N-1) properly. I haven't been motivated to fix the handling of non-trace aliases and no one has submitted a patch for it. 

What I kind of want to do instead is drop support for un-traced digipeating all together and change the config syntax for <trace> and <wide> blocks to something like this in the interfaces:

alias list,of,prefixes [maxreq [max done]]

So an interface block for a high level digi might look like this:

<interface>

  ...

  alias WIDE,TRACE 3

  alias RELAY 3 0  <-- only serve RELAY as the first hop

  alias SS 7

</interface>

Traditionally, I think there's been the presumption that SS packets aren't traced so they don't get a *whole* 7 bytes longer on each hop, but I think the disadvantages of non-trace always out-weight the advantages. This new syntax allows a digipeater to support multiple aliases with different trap lengths on each.

I'd also like to merge the maxdone parameter for the aliases with the directonly setting for the digipeater mode. I'm leaning towards keeping the maxdone setting per alias, and drop the digi mode setting completely. "relay-type directonly" now becomes "set maxdone 0 for the alias", and I think we could get rid of relay-type all together; interface sources are hard-wired to "relay-type digipeated" and aprs-is sources are hard-wired to "3rd-party". I can't think of when you'd want it any other way.