[aprssig] Multi control station situational awareness - How's this supposed to work?

wa7skg wa7skg at wa7skg.com
Mon Dec 2 20:59:09 EST 2019


A couple thoughts.

First, what is the geographical area? Are these people close enough for 
2.4GHz communications? Perhaps something like a mesh network would work. 
That will give you a fairly high speed data link in a local network. The 
problem with mesh, is the individual stations are relatively short 
range. Yes, I know people who have communicated dozens of miles, but 
that is the exception rather than the rule.

Lacking that, if VHF communication is possible, if I understand your 
desire, I would consider old style packet radio, pre-APRS. I don't 
really think the APRS protocols might be best for what you are asking. 
However, back in the old days pre-Internet, we had BBS stations and 
simple digipeaters. A couple BBS stations would periodically "compare 
notes" as it were and match their data across the network. Users would 
access the BBS, get a list of files, download them to their local 
computer and carry on. The files were primarily text files. In your 
case, I would envision the NCS would run his net, prepare a report of 
the gathered information, and upload it to the BBS. The other NCS 
stations would download those reports, run their nets, update the file, 
and upload the new information to the BBS. With several BBS stations for 
redundancy, the information would be reliably available to all the NCS 
as well as interested other users. The old-style packet system could 
(and did) utilize simple digipeaters which could be rapidly deployed for 
a particular situation. I know we did some public service events in 
remote areas passing data via packet. We literally had digipeaters in 
ammo cans with sufficient battery for about a week of operation and hung 
them in trees on hilltops for fill-in coverage. We used discrete 
frequencies to avoid normal traffic (everybody was on 145.01 in those days).

It may not have the finesse of today's APRS or WinLink networks, but it 
was extremely simple and reliable. It had redundancy and was rapidly 
deployable. It was strictly keyboard to keyboard text files.

Like anything else, you have to plan, prepare, train, and practice. But 
a system like that can be easily put together with used low-cost parts, 
packed away between uses, and implemented in a short time. You want 
something basic and not reliant on any existing infrastructure, yet 
using tried and proven technology available to almost everyone, easy to 
deploy and use by the average ham with out needing a high level 
technology degree to understand it.

Like I said, just some thoughts.

73,
Michael WA7SKG

Greg D wrote on 12/2/19 3:22 PM:
> Hi Bob,
> 
> The recent planned power outages here in California have several members
> of our club wondering what the right solution is for coordinating
> information from multiple Net Control stations.  I expect APRS is the
> right foundational tool for the job, but am unsure how to apply it.  Can
> you give us some guidance?  Especially, how should we handle information
> that is not tied to a location (map), and how do we search for answers
> to requests?
> 
> Usually, Net Control is a centralized role.  Single operator at a single
> location, or if multiple operators working in shifts, there's still a
> single log or database for information.  Higher-end solutions exist with
> commercial software support, but that's overkill for our needs and
> situation.
> 
> The challenge is that we have had several wide-spread power outages in
> the area.  Folks are without power for a day upwards to nearly a week,
> with some having no access to city utilities.  Many (now) have
> generators, but those need fuel.  Some run short of other essentials.
> My own power was restored after the first outage just as the ice I had
> set aside in the fridge was about done.  Others were not so lucky.
> Critically, Internet access was either totally out, or spotty at best.
> Cable-based Internet went out totally, cellular was spotty.  Evidence at
> my house was that the cell system only lasted about 2 hours before
> failing.  I did have a land-line analog phone that worked, but have no
> idea what I'd do with it other than make phone calls.  The modem and
> dial-up account are long gone.
> 
> Our ham club decided to run an informal information-sharing net, taking
> check-ins reporting on where the outages were, what stores were open,
> shortages found, requests for supplies, and offers to provide the same.
> During the first outage, that was handled mostly by one person, using
> pencil and paper for record keeping.  I added my support during the
> second outage, and while the needs were fewer (folks were better
> prepared after the first one), it became clear that having a split data
> record between the various net control stations could be problematic.
> So, we're looking for a solution which will be effective across multiple
> Net Control stations, and ideally without the need for Internet access,
> even at the periphery.  Fortunately, there's no serious emergency, and
> no "served agencies" to include in the plan.
> 
> If we could count on the Internet, a simple Google Sheets file would be
> perfect.  Multiple authors, real-time updates, shared access,
> persistence.  It provides the model of what we're trying to achieve with
> the radio links.  The "situational awareness" aspect of APRS suggests
> that it would make for a good foundation for a shared-view of the
> "situation".  Stores open and closed, locations of fuel available and
> unavailable, etc. in theory can be handled with Objects.  But three
> problems.  Some locations (especially stores) have multiple reports.  Do
> we create multiple objects at the same location?  That could get messy.
> Some reports are location-vague, for example, a report of power out for
> an entire part of town; do we "pin" it to the location of the person
> reporting and explain it in the object text?.  The "all clear" call, for
> example, was for the entire county.  Where to put them?  And finally,
> how to find the most recent information, given that there is no time
> context for the map view.  One would be forced to scan the map, clicking
> on objects looking for the information requested, and likely becoming
> frustrating and ineffective over time.  It's also a bit tedious to
> create and manage an object.
> 
> During the last outage, I experimented a bit with the use of a Bulletin
> packet.  Some simple formatting could be used to indicate the category
> of information included, or one could use the bulletin number as a
> category indicator.  It was nice that the bulletin was received by a
> member's HT without any preparation, but the broadcast nature of
> bulletins would perhaps be a bit annoying for those who don't
> particularly care about this topic.
> 
> One of the thoughts was that an APRS application that focused more on
> category-oriented text instead of map-based pins would be effective, but
> we are not aware of any that provide this sort of view.  Given the lack
> of Internet access, the app would need to be running 24x7 in order to
> provide data persistence, unless the text information is repeated
> periodically as it is with traditional objects.  For something like this
> to work, would any of the existing packet formats be appropriate, or
> would we need to create something new?
> 
> What is the right solution for this sort of situation?
> 
> Thanks,
> 
> Greg  KO6TH
> 



More information about the aprssig mailing list