[aprssig] [IRLP] APRS script for Debian 10, AVRS, etc CLARIFICATION?

[Nick VA3NNW]

OK! So pulling together a few threads...

Mark Herson, N2MH wrote:
> If I recall correctly, Bob and I had a short email conversation about
> this a number of years ago. Bob suggested, and I agreed, that he would
> place my name in the barrel for people to contact if interested. Since
> that time, I have had zero inquiries until now.
> [...] If someone wants to pick up the ball and run with it, please be
> my guest and enjoy! Nick, it kinda sounds like you are that person?

It sounds like I've volunteered to take the torch.  :-)

Thanks Mark! Bob, feel free to remove Mark and add me in
http://www.aprs.org/info/echo-irlp-win.txt

Robert Bruninga wrote:

>> I agree, that expecting every IGate operator in the world to add the
>> specific filter for IRLP, Echolink and other nodes is a high
>> expectation and will likely only be successful in a very small
>> percentage of locations.  BUT…
>> But, having central servers for each service is the best way to make
>> sure that ALL such objects (if implemented) are generated correctly
>> and consistently.

Agreed. It's also consistent with APRS-IS being the "backbone" and
igates being the gateways in+out.

"This is local, I should have heard it on the air but didn't, let's send
it to RF" as essentially a way to "extend the range" with internet hops
as well as RF hops.

If individual igate owners choose to gate to TX or not to gate to TX, so
be it, but it's there and it's useful if they want it. It's also there
for Android/iphone/tablet/laptop type devices that have internet AND RF,
for "tell me my local repeaters" even if RF isn't telling them what they
want to know. It's there, and it's in a consistent format, and it can be
gated by anyone who wants to gate it to RF, or not.

Certainly seems more workable than... Well... what, the alternative is
every IRLP node has TWO radios, one for the IRLP/repeater, one for APRS,
and needs to do its own beaconing on RF and APRS-IS or both, and keep
the beacon software up to date and properly configured in the hope that
beacons are in the correct consistent format, and hope their info on
status.irlp.net is consistent with the info in their beacons etc. I'd
say we've already tried this and it seems to put ~10% of IRLP nodes on
the map, and ONE central server could do so much better.

>> The choice is to do it this way and have interested local RF czars
>> add the filter, or for them to come up with their own method of
>> generating these objects and that would be a nightmare of
>> inconsistency and badly formatted packets.

See today... where about 3% of nodes are on the map "correctly" and a
defacto standard puts about 6% more on the map, but about 90% don't have
IRLP objects at all   :-/

>> Yes, I think the goal is to have proper format so that Kenwoods and
>> Yaesu’s TUNE and QSY buttons work correctly.  -- Bob, WB4APR

... which I THINK needs...

;IRLP-####*111111zDDMM.--NIDDDMM.--W0FFF.FFFMHz Tnnn STTS CALL
or
;IRLP-####*111111zDDMM.--NIDDDMM.--W0FFF.FFFMHz Tnnn +500 STTS CALL

... as per http://www.aprs.org/info/echo-irlp-win.txt or
http://www.aprs.org/info/freqspec.txt ?

How about the very popular (lonney9 Debian IRLP scripts with $VERBOSE):

;IRLP-####*DDHHMMzDDMM.mmNCDDDMM.mmW0FFFF.FFFMHz + offset PL tone nnn.n CONNECTED

I'm guessing that DOESN'T work with TUNE/QSY buttons? Or the also
popular lonney9 non-$VERBOSE:

;IRLP-####*DDHHMMzDDMM.mmNCDDDMM.mmW0PHGphgdFFFFFF+tttyyyyyyyyyyzzzzzzzz
;IRLP-####*DDHHMMzDDMM.mmNIDDDMM.mmW0FFFFFF-tttIDLE      <EOL - note spaces>

... which look like a noble attempt at
http://www.aprs.org/avrs/AVRSspec.txt with/without the PHG:

;IRLP-####*DDHHMMzDDMM.mmN/DDDMM.mmWLPHGphgdFFFFFF+PPPyyyyyyyyyyzzzzzzzz
;IRLP-####*DDHHMMzDDMM.mmN/DDDMM.mmWLFFFFFF+PPPyyyyyyyyyyzzzzzzzz
 Node State   YYYYYYYYYYZZZZZZZZ   Comments
 Offline:    " Off @HHMM........"  can contain some comments in Z
 On-Line:    " On  @HHMM........"  Time it returned to ON (+Z if any)
 Busy:       " Busy HHMM.3 nodes"  Time it went busy & # of nodes
 Connected:  "=NNnnnnnnn at HHMM"  Shows call/Name of connection
               "+NNnnnnnnn at HHMM"  if another one connects 

Does this (AVRSspec.txt) work with TUNE/QSY buttons or no?

Symbols, can we agree that use of C0 B0 O0 I0 E0 is quite neat for
Connected, Busy, Offline, IRLP, EchoLink etc?

YAAC-Andrew, KA2DDO said:

>> Regarding APRS-IS, any IRLP objects injected into the backbone won't
>> make it to RF because of:
>> 1. The lack of Tx I-gate stations (versus receive-only I-gates).
>> 2. The default Tx I-gate algorithm of only transmitting text messages
>> addressed to RF-local stations or position reports from stations that
>> just sent such a text message.
>> The latter is somewhat of a problem because each Tx I-gate operator
>> would explicitly have to add a filter of the form
>> +o/IRLP* +m/50

... which still FEELS more fixable (almost "just in config") than
requiring the other 90% of IRLP operators to start beaconing,
CONSISTENTLY, on a 2nd radio, or even all getting the correct consistent
config+format into APRS-IS (see "now" for example).

>> as we don't want spurious duplication of other local traffic
Right, but wouldn't the normal de-duplication algorithm handle that for
traffic it HAS seen, otherwise it's pretty much acting as a "range
extender" for traffic it HASN'T but maybe "should have seen"? Come to
think of it, why not just "+m/50" by itself? Would cover IRLP / other
repeater objects, and would cover "I didn't hear John, but he was heard
by an rx igate who got it to a tx igate who resent it" - somewhat like
WIDE-n or other digipeating, but with an internet hop?

>> And we still have the jurisdictional problem of having Tx I-gates at all.
That's surely up to each operator to understand and abide by the rules
in their own jurisdiction, same as everything else in ham radio? In some
countries the rules are even different for different CLASSES of
licenses. Seems silly to pretend WE have any right to set or enforce the
rules for ALL classes of licenses in ALL legal jurisdictions though.

Does your license allow you to pass 3rd-party licensed traffic? Does the
local RF bandwidth have the capacity? Then go for it!

Does your license only cover messages directed to RF-local stations?
Also fine - go for it!

Would you like to (and are you allowed to) whitelist other specific
calls / objects? Also fine!

I wouldn't pretend to understand the rules for all classes of licenses
in all countries, I'd give the ops the ability to configure appropriately.

... but provide a consistently generated, YaeComWood-compatible, list of
local repeaters on the APRS-IS side which igate operators can choose to
gate if they want to and are allowed to.

>> I think we need to stop worrying about limitations of UI-View, as it
>> wouldn't be able to support other things needed for this (such as the
>> above filters).

I feel as though I'd rather worry about the limitations (/capabilities)
of YaeComWood for sure. I know we're not living in an ideal world, but
software still feels SOMEWHAT fixable compared with hardware   :-)

Bob said:

>> I am open for clarification….  The 111111z could be replaced with the
>> local DDHHMMz format (to show how current it is) because the
>> IRLP-1234 number is globally unique, therefore the 111111z to prevent
>> overwriting is not required.

OK, I thought it might also help with uniqueness / deduplication.

So speaking of uniqueness... Should I use a specific FROMCALL? TOCALL?
Do I deserve a TOCALL allocation just for this "central server"?

Putting on my day-job "internet/cloud systems architect" hat: an ideal
setup might be TWO redundant well-connected identically-configured
IRLP-status-to-APRS-IS-object gateways, creating+sending "identical"
packets into APRS-IS, which will be naturally de-duped when both are
running, but will continue to work seamlessly if either one fails.

Even if local operators wanted to generate their own, *CONSISTENTLY*,
nobody would particularly notice, know, or care.

What MIGHT cause confusion would be if node owners wanted to transmit
their own in a non-standard / inconsistent format (like ~6% do now),
whilst I was also generating in an agreed standard / consistent format,
and you get 2 dots on the map in approx/exactly the same place but with
different data, and/or someone tx-igates and you get 2 inconsistent sets
of beacons on RF too. I'd certainly aim to provide a fairly easy "opt
out" if people want to run an IRLP node but DON'T want "the central
server" creating the ARPS objects for them.
http://status.irlp.net/updatenode/ (if you're browsing from/via an IRLP
node) even has a field for "AVRS Status aprs.org/avrs.html" which can be
set to "Open" "Closed" "Assisted" or "Unknown". Current values are:

     27 A(ssisted)
     38 C(losed)
    252 O(pen)
   1191 U(nknown)

... but as far as I can tell NOBODY knows/remembers exactly what it's
for or what the different values mean, but I'm fairly confident I could
get IRLP-Dave VE7LTD to tweak the help text to explain how to use it to
opt out of "the central server".

I'll run some further stats to see if / how those match up with
presence/absence of IRLP objects on APRS-IS.

73! Nick VA3NNW

-- 
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer;    sig at noseynick.net
As easy as 3.141592653589793238462643383279502883197116939937510...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200516/91ebb2b2/attachment.html>