[aprssig] APRS = the IoT of Amateur Radio [was: APRS to the planet rescue?

Ev Tupis w2ev at yahoo.com
Tue Apr 4 11:25:11 EDT 2017

So here is where I chime in (again).  Several years ago (at the "Emcomm East" convention), I presented on the topic "Growing APRS' Value to the First Responder Community".
The points that I made there hold true even more today: Emcomm is not what it was in the 1980's.  EFR's don't need us to pass traffic.
Our value comes from "outside of the yellow tape".
Enter: APRS as the IoT/M2M of the Emcomm world

We need to provide situational awareness that is not available in any other way.  We need sensors that are both housed at our homes *and* reporting via APRS *and* batter backed up ... and we need sensors that we can deploy around the perimeter of an event to report conditions via APRS ... and we need an APRS infrastructure with a gateway to the EFR's "dot on a map" system.
If you still think otherwise, then please tell me specifically...when was the last time you were activated and did anything OTHER than open an HF net and take check-ins?  A rhetorical question as someone in some special case may come up with one or two instances...but let's be honest...that is all that happens a VAST majority of the time.

I have asked the ARRL each time they touted an ARES activation, "This looks like a news story about the disaster, but what did we actually do?"  Answer: setup an HF net and took checkins.  (yawn).
I asked here, "When were you deployed and used APRS?".  The answers I received were not Emcomm related...they were public service related.  It is only a matter of time until even public service organizations can do it themselves, too.

It is time to reinvent.  How do we build inexpensive, callibrated, deployable sensors and regain our worth to the Emcomm community?

Ev, W2EV

Inspired by the post below...

On Monday, April 3, 2017, 8:04:38 PM EDT, Scott Miller <scott at opentrac.org> wrote: Throwing a bunch of uncalibrated sensors out there with no standards for their placement is not going to get you much useful data.  It might be fun to look at your own track and see where you get hot spots but it's not going to do serious researchers much good.
 And didn't we discuss a standardized type-length-value extension scheme a while back?  Aside from OpenTRAC, that is.  At the very least I think any more extensions to the format need a formal definition, maybe a BNF grammar, to guarantee that everything is unambiguous and parseable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170404/e915c180/attachment.html>

More information about the aprssig mailing list