<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>OK! So pulling together a few threads...</p>
<div class="moz-cite-prefix">Mark Herson, N2MH wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">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.
<br>
[...] 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?<br>
</blockquote>
<p>It sounds like I've volunteered to take the torch. :-)</p>
<p>Thanks Mark! Bob, feel free to remove Mark and add me in
<a class="moz-txt-link-freetext" href="http://www.aprs.org/info/echo-irlp-win.txt">http://www.aprs.org/info/echo-irlp-win.txt</a></p>
<p>Robert Bruninga wrote:
<br>
</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">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…
<br>
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.
<br>
</blockquote>
</blockquote>
<p>Agreed. It's also consistent with APRS-IS being the "backbone"
and igates being the gateways in+out.</p>
<p>"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.</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">
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.
<br>
</blockquote>
</blockquote>
<p>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 :-/</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">
Yes, I think the goal is to have proper format so that Kenwoods
and Yaesu’s TUNE and QSY buttons work correctly.
-- Bob, WB4APR
<br>
</blockquote>
</blockquote>
<p>... which I THINK needs...</p>
<pre>;IRLP-####*111111zDDMM.--NIDDDMM.--W0FFF.FFFMHz Tnnn STTS CALL
or
;IRLP-####*111111zDDMM.--NIDDDMM.--W0FFF.FFFMHz Tnnn +500 STTS CALL
</pre>
<p>... as per <a class="moz-txt-link-freetext" href="http://www.aprs.org/info/echo-irlp-win.txt">http://www.aprs.org/info/echo-irlp-win.txt</a> or
<a class="moz-txt-link-freetext" href="http://www.aprs.org/info/freqspec.txt">http://www.aprs.org/info/freqspec.txt</a> ?</p>
<p>How about the very popular (lonney9 Debian IRLP scripts with
$VERBOSE):<br>
</p>
<pre>;IRLP-####*DDHHMMzDDMM.mmNCDDDMM.mmW0FFFF.FFFMHz + offset PL tone nnn.n CONNECTED</pre>
<p>I'm guessing that DOESN'T work with TUNE/QSY buttons? Or the also
popular lonney9 non-$VERBOSE:<br>
</p>
<p></p>
<pre><span class="pl-c"><span class="pl-c"></span>;IRLP-####*DDHHMMzDDMM.mmNCDDDMM.mmW0PHGphgdFFFFFF+tttyyyyyyyyyyzzzzzzzz</span>
;IRLP-####*DDHHMMzDDMM.mmNIDDDMM.mmW0FFFFFF-tttIDLE <EOL - note spaces></pre>
<p>... which look like a noble attempt at
<a class="moz-txt-link-freetext" href="http://www.aprs.org/avrs/AVRSspec.txt">http://www.aprs.org/avrs/AVRSspec.txt</a> with/without the PHG:</p>
<pre>;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
</pre>
<p>Does this (AVRSspec.txt) work with TUNE/QSY buttons or no?</p>
<p>Symbols, can we agree that use of C0 B0 O0 I0 E0 is quite neat
for Connected, Busy, Offline, IRLP, EchoLink etc?</p>
<p>YAAC-Andrew, KA2DDO said:<br>
</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">Regarding APRS-IS, any IRLP objects
injected into the backbone won't make it to RF because of:
<br>
1. The lack of Tx I-gate stations (versus receive-only I-gates).
<br>
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.
<br>
The latter is somewhat of a problem because each Tx I-gate
operator would explicitly have to add a filter of the form
<br>
+o/IRLP* +m/50<br>
</blockquote>
</blockquote>
<p>... 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).<br>
</p>
<p>
<blockquote type="cite">
<blockquote type="cite">as we don't want spurious duplication of
other local traffic</blockquote>
</blockquote>
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?<br>
</p>
<p>
<blockquote type="cite">
<blockquote type="cite">
<div>And we still have the jurisdictional problem of having Tx
I-gates at all.</div>
</blockquote>
</blockquote>
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.</p>
<p>Does your license allow you to pass 3rd-party licensed traffic?
Does the local RF bandwidth have the capacity? Then go for it!</p>
<p>Does your license only cover messages directed to RF-local
stations? Also fine - go for it!</p>
<p>Would you like to (and are you allowed to) whitelist other
specific calls / objects? Also fine!</p>
<p>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.</p>
<p>... 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.<br>
</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">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).
<br>
</blockquote>
</blockquote>
<p>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 :-)</p>
<p>Bob said:<br>
</p>
<blockquote type="cite"
cite="mid:9777f49b-5e6b-a7f1-54c5-933affdc27e2@n2mh.net">
<blockquote type="cite">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.
<br>
</blockquote>
</blockquote>
<p>OK, I thought it might also help with uniqueness / deduplication.</p>
<p>So speaking of uniqueness... Should I use a specific FROMCALL?
TOCALL? Do I deserve a TOCALL allocation just for this "central
server"?<br>
</p>
<p>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.</p>
<p>Even if local operators wanted to generate their own,
*CONSISTENTLY*, nobody would particularly notice, know, or care.</p>
<p>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. <a class="moz-txt-link-freetext" href="http://status.irlp.net/updatenode/">http://status.irlp.net/updatenode/</a> (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:</p>
<pre> 27 A(ssisted)
38 C(losed)
252 O(pen)
1191 U(nknown)</pre>
<p>... 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".
</p>
<p>I'll run some further stats to see if / how those match up with
presence/absence of IRLP objects on APRS-IS.<br>
</p>
<p>73! Nick VA3NNW<br>
</p>
<pre class="moz-signature" cols="72">--
"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.
use Std::Disclaimer; <a class="moz-txt-link-abbreviated" href="mailto:sig@noseynick.net">sig@noseynick.net</a>
As easy as 3.141592653589793238462643383279502883197116939937510...
</pre>
</body>
</html>