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

wa7skg wa7skg at wa7skg.com
Tue Dec 3 12:09:02 EST 2019

While Kenwood radios are nice, I would never design a system operating 
around and focusing on them. All of your system features need to be 
generic and equipment agnostic. You will want something you can set up 
and leave for extended periods of time while doing other radio things. 
Most of us do not have the budget to dedicate a $500 radio for this. A 
used 2m mobile radio for <$100, inexpensive antenna, Raspberry Pi 
computer, $15 Goodwill monitor and you can have a complete system to 
leave up 24/7 for well under $200 (even under $100 if you have  good 
junk box). Let the computer software do everything and you will have a 
much more versatile system for a lot less money.

I borrowed one of those Kenwood radios for a few days to play with its 
APRS features and it was a complete exercise in futility and 
frustration. The complexity was unbelievable. And I consider myself to 
be pretty good at figuring out fancy radios.

Remember, a system like this, to be effective, needs to be able to setup 
with commonly available items, likely to be stored away with only 
occasional use, usable by pretty much anybody who walks up to it with 
minimal instruction, accessible to all users regardless of equipment 
brand. The KISS principle reigns supreme if endeavors like this are to 

Michael WA7SKG

Robert Bruninga wrote on 12/3/19 6:41 AM:
> Perfedt.
> APRS has these text capabilities:
> Messages (call to call)
> Bulletins
> Announcements
> Status text
> Kenwood radios can store up  to 100 incoming messages in order received.
> Bulletins were SUPPOSED to be editable.  That is, if you sent a 4 line
> bulletin and needed to update the second line, you could just start
> resending the edited 2nd line.  And it will replace the 2nd line in
> everyone's copy... I don’t think most clients implemented that.
> Best to cram all info in a single object at a single location rather than
> stacking.
> I think figuring out how to use these meger capabilities that EXIST in every
> APRS radio and client is better than an Ap.  An AP is great and fun, but is
> ususally never finished and only available to a few...
> Getting the info to the radios is what counts.
> Also, map data ages out.  Or should.
> Also there aer AREA OBJECTS that can apply to a large square, rectangle or
> triangle of any size.  But I think you need an APRS client to draw it on the
> map.  And then also radios them selves with no maps cannot display it
> anyway.
> Most people will only have radios.  What you can PUSH to the front panel of
> a Kenwood Radio is your system goal.
> Also BULLETINS can have bulletin groups to separate areas.
> Same witth Messages can have group names that people subscribe to in thir
> radio.
> Bob
> -----Original Message-----
> From: Greg D <ko6th.greg at gmail.com>
> Sent: Monday, December 2, 2019 6:23 PM
> To: Bob Bruninga <bruninga at usna.edu>
> Cc: TAPR APRS Mailing List <aprssig at lists.tapr.org>
> Subject: Multi control station situational awareness - How's this supposed
> to work?
> 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
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org

More information about the aprssig mailing list