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