<html><head></head><body><div style="font-family:courier new, courier, monaco, monospace, sans-serif;font-size:medium;"><div><div>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".</div><div><br></div><div>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.</div><div><br></div><div>Our value comes from "outside of the yellow tape".</div><div><br></div><div>Enter: APRS as the IoT/M2M of the Emcomm world<br></div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><div>It is time to reinvent.  How do we build inexpensive, callibrated, deployable sensors and regain our worth to the Emcomm community?<br></div><div><br></div><div>Ev, W2EV</div><div><br></div><div><br></div><div><br></div></div><div>Inspired by the post below...<br></div><div><br></div><div id="yahoo_quoted_2246697666" class="yahoo_quoted"><div>On Monday, April 3, 2017, 8:04:38 PM EDT, Scott Miller <scott@opentrac.org> wrote:</div><div><div id="yiv4469555378"><div>
    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.<br clear="none">
    <br clear="none">
    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.<br clear="none">
    <br clear="none">
    Scott<br clear="none">
    N1VG</div></div><br></div></div></div></body></html>