<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>Interesting idea.
<div><br></div><div>Regarding APRS-IS, any IRLP objects injected into the backbone won't make it to RF because of:</div><div><br></div><div>1. The lack of Tx I-gate stations (versus receive-only I-gates).</div><div><br></div><div>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.</div><div><br></div><div>The latter is somewhat of a problem because each Tx I-gate operator would explicitly have to add a filter of the form </div><div><br></div><div>+o/IRLP* +m/50</div><div><br></div><div>(where the 50 is adjustable based on the coverage area of the I-gate) for both their link to the backbone and to their supplemental transmit forcing filter. And that's assuming all I-gates support the ANDing operator to require both conditions to be simultaneously met to forward the packet (as we don't want spurious duplication of other local traffic nor every single IRLP gateway in the world sent to the local RF channel). YAAC can do it, but YAAC is not the best choice for an I-gate, performance-wise.</div><div><br></div><div>And we still have the jurisdictional problem of having Tx I-gates at all.</div><div><br></div><div>I think we need to get Kenneth Finnegan on this thread, as his aprx seems to be the most popular I-gate, along with Pete Loveall for his javAPRSsrvr.</div><div><br></div><div>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).</div><div><br></div><div>Another question is: are those IRLP Object packets strictly compatible with the Kenwood and Yaesu TUNE button capability? Since those are the mobile and portable stations most likely to be able to take advantage of IRLP Objects.</div><div><br></div><div>Just my $.02.</div><div><br></div><div>Andrew, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: Robert Bruninga <bruninga@usna.edu> <br>Date: 5/15/20 12:25 (GMT-05:00) <br>To: Nick VA3NNW <irlp@noseynick.com>, lonney.harper@icloud.com, Mark Herson <n2mh@n2mh.net> <br>Cc: spam8mybrain via aprssig <aprssig@lists.tapr.org> <br>Subject: Re: [aprssig] [IRLP] APRS script for Debian 10, AVRS, etc CLARIFICATION? <br><br><div class="WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I added Lynn and Andrew for the IGate question…</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">In reading that APRS1.2 text, there was a note about 3<sup>rd</sup> party packets not being able to be used because of limitations in UIview. Its been so long, can someone clarify that the problem of all 3<sup>rd</sup>-party formatted packets being “assumed” to be igates is no longer a problem?</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Bob, WB4APR</span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span></p><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Nick VA3NNW <<a href="mailto:irlp@noseynick.com">irlp@noseynick.com</a>> <br><b>Sent:</b> Thursday, May 14, 2020 11:29 PM<br><b>To:</b> <a href="mailto:lonney.harper@icloud.com">lonney.harper@icloud.com</a>; <a href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>; Mark Herson <<a href="mailto:n2mh@n2mh.net">n2mh@n2mh.net</a>><br><b>Subject:</b> Re: [IRLP] APRS script for Debian 10, AVRS, etc</span></p></div></div><p class="MsoNormal"> </p><p class="MsoNormal">Lonney [KL3NO] via <a href="http://groups.io">groups.io</a> wrote:<br><br></p><blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"><p class="MsoNormal">Yes, I tweaked the original some years ago to work with Debian:<br><a href="https://github.com/lonney9/IRLPScripts" target="_blank">https://github.com/lonney9/IRLPScripts</a></p></blockquote><p>I recognise this! ... or at least, I recognise the OUTPUT of this, in fact it looks like I recognise TWO outputs of this depending on the setting of $VERBOSE :-D</p><p>I was recently reading <a href="http://www.aprs.org/info/echo-irlp-win.txt">http://www.aprs.org/info/echo-irlp-win.txt</a> and a bunch of related specs, EG <a href="http://www.aprs.org/localinfo.html">http://www.aprs.org/localinfo.html</a> and <a href="http://www.aprs.org/info/freqspec.txt">http://www.aprs.org/info/freqspec.txt</a> - In particular, "It is hoped that a central server will be written for these objects as well so that they can be consistently generated into the APRS-IS and then only gated back to RF locally"</p><p>I was considering WRITING that "central server" as it doesn't; seem to exist. I've been unable to get hold of Mark Herson <a href="mailto:n2mh@n2mh.net">n2mh@n2mh.net</a> who appeared to be responsible for a previous version of this "central server", but I did get IRLP-Dave to grant permission to carefully poll <a href="http://status.irlp.net">status.irlp.net</a> every few mins, in order to put *ALL* IRLP nodes on the map periodically. I'd probably follow the spec, which specifies:</p><p> ;IRLP-1234*111111zDDMM.--NIDDDMM.--W0FFF.FFFMHz Tnnn +500 STTS CALL</p><p>111111z is pseudo default null Date-Time for PERSISTENT OBJECTs - yeah I know, it's crap, because any object COULD be sent at 11:11 on the 11th of the month, but it's the standard, NOT DDHHMMz for persistent objects - see APRS 1.2 spec or <a href="http://www.aprs.org/info/object-perm.txt">http://www.aprs.org/info/object-perm.txt</a></p><p> "--" are spaces, for ~1mi position ambiguity. It's not clear whether these were EXPECTED for IRLP nodes, or "a good idea", or "totally optional", but most IRLP nodes in the database seem to have 6 decimal places of Lat/Lon anyway, so it's not clear if we should be DELIBERATELY ambiguous or "only if asked".<br> I0 = "IRLP" symbol<br> Tnnn can be Cnnn for CTCSS tone, Dnnn for DCS code, Toff for no tone<br> Tnnn can also be tnnn or cnnn (lower case) for narrowband, 1750 for tone, l750 (lc L) for narrow<br> +500 offset (or other, in 10s of kHz) can be -000 (not +000?) to force simplex, absent for "radio's default"</p><p>... however before writing this "central server" I obviously wanted to do some stats on what's already out there. <10% of IRLP nodes seem to be on APRS, though a few are beaconing position objects not ";IRLP-nnnn*" objects, and there are at least a dozen non-standard defacto standards, in fact for the month of April...</p><p>APVR30 is definitely the most popular TOCALL for these IRLP objects :-) It's not clear if this is a real standard, a defacto standard, a TOCALL reserved for this script specifically, or just totally hijacked. The most official TOCALLS lists I could find said "<span class="pl-s">APVR??" is "for IRLP", "unknown vendor".</span></p><p><span class="pl-s">27389 APUN10 is also fairly popular. Completely unknown, unless it's a UIview but they're theoretically APU1xx, APU2xx or APU3xx. Perhaps [AP]rs [UN]known version [1].[0] even? :-)</span></p><p> 45446 use 111111z timestamp, as per spec<br> 5181 use 000000z (0th day of month, 00:00? Nice idea for persistent objects BUT not spec)<br> 314079 use something resembling a real time (not checked for accuracy), so it may arguably be wrong, but it;s currently far more popular :-/</p><p>ONE IRLP node uses compressed LatLon format, presumably its own one-off script.</p><p>Some use an over-long Lat like 01234.56N (should be 1234.56N?)</p><p>361190 dddd.ddN = valid Lat (N=[NS])<br> 2707 __ = use position ambiguity for decimal mins<br> 347443 nnnn.nnN = northern hemisphere (notable bias)<br> 13746 nnnn.nnS = southern hemisphere.</p><p> 1 is >80 degrees away from the equator :-D</p><p> 842 use -10204.79W - Not only wrong length but Negative West Longitude?!? That's ";IRLP-nnnn*nnnnnnznnnn.nnNI-nnnnn.nnW0nnn.nnnMHz - offset PL tone nnn.n IDLE" in full, which looks a lot like someone misconfigured Lonney's script. :-(</p><p>A few nodes MOVE - seems unlikely but not completely impossible for IRLP? Wonder what they use for their mobile uplink?</p><p>For symbols...</p><p> 224475 I0 = IRLP repeater (I in grey circle)<br> 100916 C0 = C in grey circle? (often used as "Connected")<br> 11796 IW = I in green circle<br> 6756 O0 = O in grey circle? O balloon? (often used as "offline")<br> 4333 S0 = Staging Area (S in grey circle)<br> 4259 S1 = possibly invalid?<br> 2747 /r = Repeater tower<br> 2582 /k = Truck</p><p>Generally MOST repeaters are doing the correct FFF.FFFMHz, but quite a lot are doing "FFFFFF+tttC (EXP|REF|)nnnn". Also really popular is "nnn.nnnMHz - offset PL tone nnn.n IDLE"</p><p> 53157 MHz Tnnn +500 RXXm [std]<br>115776 MHz( [-+] offset)?( PL tone nnn.n)?( Prefix 0)?STTS<br> STTS=<spaces?>(IDLE|CONNECTED| OFFLINE)<spaces></p><p>My understanding is the most technically correct format would be:</p><p class="MsoNormal">CALL>TOCALL:;IRLP-2410*111111z4324.38NI08031.30W0444.875MHz T131 idle VE3RBM<br>CALL>TOCALL:;IRLP-2440*111111z4226.23NI08206.38W0444.325MHz T250 +500 busy VE3COZ<br>CALL>TOCALL:;IRLP-2450*111111z4400.69NI07931.08W0444.700MHz T103 +500 idle VE3RAK<br>CALL>TOCALL:;IRLP-2460*111111z4519.73NI07857.93W0146.775MHz T156 -060 idle VE3MUS<br>CALL>TOCALL:;IRLP-2461*111111z4401.47NI07920.97W0147.330MHz T103 +060 idle VA3BAL<br>CALL>TOCALL:;IRLP-2480*111111z4523.49NI08002.37W0145.490MHz T156 -060 idle VE3RPL<br>CALL>TOCALL:;IRLP-2490*111111z4519.72NI07858.00W0146.820MHz T156 -060 idle VE3KR<br>CALL>TOCALL:;IRLP-2507*111111z4537.10NI06158.42W0146.550MHz T141 down VE1JCS</p><p>... but given that "defacto standard lonney9/IRLPScripts" seem to currently outnumber "actual Bob standard" APRS IRLP objects at least 2:1, but COMBINED are still approx 10% of active IRLP nodes I COULD put on the map from my near-complete "central server [...] so that they can be consistently generated into the APRS-IS", We should chat :-D</p><p>... and probably get input from APRS-Bob as well.</p><p>... and give Mark N2MH one more try too.</p><p>If I was to periodically gate ALL IRLP nodes into APRS, should I mimic lonney9/IRLPScripts defacto standard specs ($VERBOSE version or non-$VERBOSE), try to follow Bob's official specs (and have I understood those right in the examples above?), or something else? If we came up with standard FROMCALL and TOCALL, could we hope to deduplicate if there were multiple sources of the same info, or is it pointless to expect that?</p><p>I was intending to try to rotate through the entire list every 30 mins, giving priority to nodes that have recently changed status. Various of Bob's specs seem to suggest every 10 mins, but it was looking like I'd already add about 1% to the total APRS traffic even at 30min intervals. I'd probably initially experiment with a subset of the nodes, EG (selfishly) all VE3 / VA3 ones, and "test the water" a bit before going "all in".</p><p>... and maybe try to add Echolink -R nodes if we wanna REALLY add to the bandwidth, maybe revive an AVRS server too eventually.</p><p>73 -- Nick VA3NNW</p><pre>-- </pre><pre>"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.</pre><pre>use Std::Disclaimer; <a href="mailto:sig@noseynick.net">sig@noseynick.net</a></pre><pre>Think honk if you're a telepath.</pre></div></body></html>