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

Fri May 15 12:25:30 EDT 2020

I added Lynn and Andrew for the IGate question…

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.

In reading that APRS1.2 text, there was a note about 3rd 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 3rd-party formatted packets
being “assumed” to be igates is no longer a problem?

Bob, WB4APR

*From:* Nick VA3NNW <irlp at noseynick.com>
*Sent:* Thursday, May 14, 2020 11:29 PM
*To:* lonney.harper at icloud.com; bruninga at usna.edu; Mark Herson <
n2mh at n2mh.net>
*Subject:* Re: [IRLP] APRS script for Debian 10, AVRS, etc

Lonney [KL3NO] via groups.io wrote:

Yes, I tweaked the original some years ago to work with Debian:
https://github.com/lonney9/IRLPScripts

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

I was recently reading http://www.aprs.org/info/echo-irlp-win.txt and a
bunch of related specs, EG http://www.aprs.org/localinfo.html and
http://www.aprs.org/info/freqspec.txt - 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"

I was considering WRITING that "central server" as it doesn't; seem to
exist. I've been unable to get hold of Mark Herson n2mh at n2mh.net 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
status.irlp.net every few mins, in order to put *ALL* IRLP nodes on the map
periodically. I'd probably follow the spec, which specifies:

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

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 http://www.aprs.org/info/object-perm.txt

  "--" 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".
  I0 = "IRLP" symbol
  Tnnn can be Cnnn for CTCSS tone, Dnnn for DCS code, Toff for no tone
  Tnnn can also be tnnn or cnnn (lower case) for narrowband, 1750 for tone,
l750 (lc L) for narrow
  +500 offset (or other, in 10s of kHz) can be -000 (not +000?) to force
simplex, absent for "radio's default"

... 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...

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 "APVR??" is "for IRLP", "unknown
vendor".

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?   :-)

  45446 use 111111z timestamp, as per spec
   5181 use 000000z (0th day of month, 00:00? Nice idea for persistent
objects BUT not spec)
 314079 use something resembling a real time (not checked for accuracy), so
it may arguably be wrong, but it;s currently far more popular  :-/

ONE IRLP node uses compressed LatLon format, presumably its own one-off
script.

Some use an over-long Lat like 01234.56N (should be 1234.56N?)

361190 dddd.ddN = valid Lat (N=[NS])
   2707      __  = use position ambiguity for decimal mins
 347443 nnnn.nnN = northern hemisphere (notable bias)
  13746 nnnn.nnS = southern hemisphere.

      1 is >80 degrees away from the equator   :-D

    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.   :-(

A few nodes MOVE - seems unlikely but not completely impossible for IRLP?
Wonder what they use for their mobile uplink?

For symbols...

 224475 I0 = IRLP repeater (I in grey circle)
 100916 C0 = C in grey circle? (often used as "Connected")
  11796 IW = I in green circle
   6756 O0 = O in grey circle? O balloon? (often used as "offline")
   4333 S0 = Staging Area (S in grey circle)
   4259 S1 = possibly invalid?
   2747 /r = Repeater tower
   2582 /k = Truck

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"

  53157 MHz Tnnn +500 RXXm   [std]
115776 MHz( [-+] offset)?( PL tone nnn.n)?( Prefix 0)?STTS
        STTS=<spaces?>(IDLE|CONNECTED| OFFLINE)<spaces>

My understanding is the most technically correct format would be:

CALL>TOCALL:;IRLP-2410*111111z4324.38NI08031.30W0444.875MHz T131 idle VE3RBM
CALL>TOCALL:;IRLP-2440*111111z4226.23NI08206.38W0444.325MHz T250 +500 busy
VE3COZ
CALL>TOCALL:;IRLP-2450*111111z4400.69NI07931.08W0444.700MHz T103 +500 idle
VE3RAK
CALL>TOCALL:;IRLP-2460*111111z4519.73NI07857.93W0146.775MHz T156 -060 idle
VE3MUS
CALL>TOCALL:;IRLP-2461*111111z4401.47NI07920.97W0147.330MHz T103 +060 idle
VA3BAL
CALL>TOCALL:;IRLP-2480*111111z4523.49NI08002.37W0145.490MHz T156 -060 idle
VE3RPL
CALL>TOCALL:;IRLP-2490*111111z4519.72NI07858.00W0146.820MHz T156 -060 idle
VE3KR
CALL>TOCALL:;IRLP-2507*111111z4537.10NI06158.42W0146.550MHz T141 down VE1JCS

... 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

... and probably get input from APRS-Bob as well.

... and give Mark N2MH one more try too.

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?

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".

... and maybe try to add Echolink -R nodes if we wanna REALLY add to the
bandwidth, maybe revive an AVRS server too eventually.

73 -- Nick VA3NNW

-- 

"Nosey" Nick Waterman, VA3NNW/G7RZQ, K2 #5209.

use Std::Disclaimer;    sig at noseynick.net

Think honk if you're a telepath.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200515/fb830428/attachment.html>