[aprssig] Multi control station situational awareness - Using standard APRS

[Robert Bruninga]

POSITS:  Keeping track of Checkins (who is on the air) is trivial.  They
simply send their standard POSIT packet but with the local net keyword.
Maybe "PWRnet" as a key word.  AND if they activate Frequency QSY, then
their periodic position status not only shows they are in the NET but also
shows what voice frequency they are monitoring.  This shows every APRS radio
and client who is on the air, where, and on what frequency.  The posit rate
for fixes stations should be set to 10 minutes and use only the LOCAL DIGI
as a path so these do not flood into other areas.  The ten minute refresh of
everyone participating is common ham radio practice on most nets anyway.

OBJECTS can convey:
* The object name, the Symbol, and a Symbol overlay character (giving one of
36 flexibility)
* Then there is a full line of text (status) for each one.
Although everyone with a radio and HT can see all the information on an
object instantly, they are best originated at an APRS client ap where the
operator can type in the status info quickly.

Each time the info for that object changes, then the operator can edit it
and restart the sending.  Very good way to get out location dependent info.
AND this new object data REPLACES the old data on every radio so there is no
accumulation of old objects and the info at that location is always current.

BULLETINS can do the rest.

Bob



-----Original Message-----
From: Greg D <ko6th.greg at gmail.com>
Sent: Tuesday, December 3, 2019 10:26 PM
To: spam8mybrain <spam8mybrain at yahoo.com>; Robert Bruninga
<bruninga at usna.edu>; aprssig at lists.tapr.org
Subject: Re: [aprssig] Multi control station situational awareness - For
mobiles? or homes without power?

Hi all,

Wow, excellent discussion.  And, thanks Andrew for your insight into the
problem, if not your actual code.  Would this be a view of the data from
within YAAC, or a separate application?

To summarize some of the thoughts....  First, a bit of clarification on what
I'm envisioning are parameters that the solution should include.
The scale, for starters.  Right now we're looking at check-ins
(contributions) from the field of view of our club's repeater, which covers
the outage area our members reside in pretty well.  That area is some 40
miles in diameter, or 120-ish square miles.  The terrain is the Sierra
Nevada foothills, so lots of valleys.  Our repeater has battery backup
power, good for several weeks, which worked perfectly.  At the north end,
about 25 miles from the club repeater is a high level Digi, which appears to
also have backup power (it was operating continually as far as I could
tell).  Its coverage is even larger, and can usually be counted on to hit an
iGate somewhere, though not all iGates in the area are bi-directional.  But
because of the terrain, not everyone can hit that Digi with any reliability,
and the few fill-in digis are usually not outfitted with backup power (mine
isn't).  I believe both net control stations can hit it, and there's enough
coverage that we could use APRS as a viable transport.

We discussed the use of mesh netwoks, such as the mentioned TARPN, and AREDN
which is similar.  These networks don't currently exist in this area, and
again with the physical area and terrain, would take some time and money to
create.  Doubtful that such an undertaking would be supported for the need
we have identified.

Hosting a dial-up node is not going to be good, as I was pretty much alone
in having a working land-line phone, and that it was working was a huge
surprise to me, as it's gone down (no dial tone) for every unplanned outage
over the past about 3 years.  Creative idea, however.

Packet BBS was not an option we had though of.  There are (or, were?) a few
packet BBS systems in the state, and I think one within earshot of me is
still operating.  Haven't used it for a while.  That certainly could be a
way to pass a file around from one control operator to another.  But being
an informal net, we didn't set up a specific operator schedule.  Instead we
just let each other know when we came and went; often both were available at
the same time.  So, the idea of passing a file around would take some
coordination, but could be possible.  We had thought to use Winlink for
this.  If nothing else, my TNC is an MFJ-1278T with a huge mail storage card
installed.  It's mostly wasted technology, as I run the TNC in KISS mode...
This is a worthwhile thing to investigate, if we can figure out the RF
paths.
Thanks for the idea!

Overall size of the data collected is important to consider.  My
hand-written notes from the 3 events totaled about 4 pages, single sided.
So, this is way more than will fit in an HT, good size for text files, and
trivially small for an enterprise-class application (SARtrack).

The two (current) net control operators included one ham who is about 10
crow-flies miles from the other (me), but not on a line-of-sight basis.
He has radios and backup power (battery + generator), and was on them for
all 3 of the major outages.  No internet during the outages.  I was the
other operator, and my situation is less dire, as I was only out during the
first of the three outages.  For the other two, I had both power and
Internet, and could view the PG&E website for their updates.
For the first outage, I was totally offline until power came back.  No
generator here (nor a desire to have one); I have battery backup power, and
can hit the repeater with just my Kenwood D-74 and the main beam antenna.
Computers here were not used during the outage, but I have a variety of
platforms from the proverbial Raspberry Pi to laptops that are within
capacity of the batteries.  And in a pinch I could tap into the battery in
my EV.

A question about Objects...  How much information can one object contain?  I
was thinking 1 packet-worth, but apparently that's not true?  I think that
it would be good for folks to be able to see the objects as they are
generated, but as Stephen says, creating one on an HT-sans-PC is not going
to happen.  Data input from the population at large is expected to be
primarily voice through the repeater.

So, next steps.  On the guess that I'd survive the last planned outage, we
set up a Google Docs file to use as a test bed to see what sorts of
information should be captured and now the baton passing could work between
stations.  The outage ended up being canceled for our area, so we didn't
have a chance to test it in action.  We did a little pre-outage postings
with it, and it seemed like it would work well.  So, that's action along the
file-transfer leg of the discussion.

For the live RF-based path, I'm very interested in Andrew's work.  I use
YAAC on a Raspberry Pi in my car, and could certainly take the new code out
for a test drive (pun intended and not).  Let me know what I can do to help.

Thanks to all for the excellent discussion, and the great ideas to try!

Greg  KO6TH


spam8mybrain via aprssig wrote:
> Bob,
>
> I could have something available for option#2 in a week or so, freely
> available. I've been working on this sort of usecase for some time
> now, but I haven't been in charge enough to deploy it.
>
> And I'm still working on adding supplemental information to the
> reports from one-way trackers, like how many injured/exhausted
> bicyclists riding in a SAG vehicle.
>
> Andrew, KA2DDO
> author of YAAC
>
>
> -------- Original message --------
> From: Robert Bruninga <bruninga at usna.edu>
> Date: 12/3/19 19:08 (GMT-05:00)
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] Multi control station situational awareness -
> For mobiles? or homes without power?
>
> There sounds like two paths emerging.
>
> - Come-as-you are with APRS radios in the mobile as the end terminal unit
>    Everybody has one
>
> - Invent something new with PC's, clients, Pi's, displays, for use at
> home (or front seat mobile?
>   Nobody has one
>
>
> -----Original Message-----
> From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Shawn
> Stoddard
> Sent: Tuesday, December 3, 2019 7:01 PM
> To: aprssig at lists.tapr.org
> Subject: Re: [aprssig] Multi control station situational awareness -
> How's this supposed to work?
>
>
> Great sanity check. You’re thinking the same path I am.
>
> On Tue, Dec 3, 2019, at 15:40, Greg Troxel wrote:
> > I would urge you to step back and consider your requirements, think
> > about the protocol that will be used at a high level, and then
> > figure out how to use specific techniques to implement that protocol.
> >
> > If what you want to do is publish infomration about status of
> > particular places, then APRS probably is the best fit.
> >
> > If you are trying to synchronize the list of checked-in stations
> > among N NCS stations, then I think you want some sort of database
> > sync protocol which is going to send messages among the
> > participants, and you may or may not want to carry that over APRS.
> >
> > I think you implied this, but from the "train like you'll fight" I
> > would suggest using the over-the-air sync all the time, and not use any
> > direct-to-APRS-IS internet-based injection.   Gatewaying to APRS-IS is
> > great for others to probably be able to see what's up, but I think
> > you should plan on no internet, and thus operate that way routinely,
> > because otherwise you are likely to be depending on it more then you
> > think.
> >
> > ALl of this is going to push you to protocols that are very terse
> > and push just the data, with all formatting and UI local.  This
> > means writing a local implementation of the UI for the protocol.
> >
> > 73 de n1dam
> >
> >