<html><head></head><body><div style="font-family:courier new, courier, monaco, monospace, sans-serif;font-size:medium;"><div><div>Very interesting, Scott. This seems like a fairly complex device with lots of capability. I'll be watching from afar to see how it progresses.</div><div><br></div><div>Interestingly, the local ARES group has a text-message system that just sent out the following for my area...</div><div><br></div><div>"The Storm Trackers Team continues the Potential Alert for General Flooding for all of our area from thru Sat. midday. Periods of rain continues into Friday night. Snow mixes in Friday. Rainfall of 1 to 2.5 inches is likely which can cause flooding. If you live in a flood prone area, remain alert!"</div><div><br></div><div>Here is where the IoT of amateur radio (if it existed) could offer huge value...if we only had sensors to deploy *and* a robust APRS network to deliver the data.</div><div><br></div><div>I imagine a variation of a common "floor wet monitor" that you find in a hardware store that...</div><div><br></div><div>* can be deployed to a "flood prone" area, attached to a stake in the ground</div><div>* would send a "flood stage" beacon once water was detected "at that level"</div><div>* could be deployed during these events and removed afterward</div><div>* run on a 9V battery (or maybe two)</div><div>* with an algorithm to minimize battery consumption while still providing useful data</div><div>* (maybe) could be cheap enough to be "throw aways" in case they are "swept away" (or stolen?)</div><div><br></div><div>I'm thinking small, inexpensive, deployable ... and a "bridge" to send that data to a municipality's "command center".</div><div><br></div><div>I'm also thinking about what it would take for the ARRL to ask their Emcomm person to pursue DHS or NOAA grants to fund development if needed.</div><div><br></div><div>THIS would be a big step in making amateur radio relevant again, in the eyes of the sworn-officer and professional EFR community.<br></div><div><br></div><div>Ev, W2EV</div><div><br></div><div><br></div><div><br></div></div><div><br></div><div id="yahoo_quoted_2060958414" class="yahoo_quoted"><div>On Tuesday, April 4, 2017, 9:36:46 AM EDT, Scott Miller <scott@opentrac.org> wrote:</div><div><div id="yiv0638953111"><div>
I'm definitely headed down the IoT/M2M path with the stuff I'm
working on now. This is what's on my desk now:<br clear="none">
<br clear="none">
<a rel="nofollow" shape="rect" class="yiv0638953111moz-txt-link-freetext" target="_blank" href="http://imgur.com/2M8Xs9K">http://imgur.com/2M8Xs9K</a><br clear="none">
<br clear="none">
This is the successor to both the Tracker3 line and the ADS-SR1
repeater. It has two radio ports (and will add at least a third
RX-only port to meet repeater control requirements), WiFi (not in
the small version), including the ability to function as an access
point, USB (virtual COM port and mass storage at this point),
RS-232, and RS-485.<br clear="none">
<br clear="none">
It'll do a bunch of conventional TNC and repeater controller things,
including operating as a dual-port simplex repeater, cross-band
repeater, duplex repeater, and some weird hybrid modes. It'll
operate as a TNC, digipeater, and standalone IGate.<br clear="none">
<br clear="none">
The RS-485 port is set up for Modbus RTU and will interface with all
sorts of off the shelf sensors, relays, I/O modules, motor
controllers, actuators, and whatnot. The small board connected to
it here is an interface for our wind and rain sensor assembly. I've
been testing it with everything from $8 quad relay boards to $400
Acromag industrial I/O modules.<br clear="none">
<br clear="none">
It has a BASIC interpreter with high-level commands for handling
voice, APRS, and Modbus. It's particularly useful for data
transformation tasks - one demo pulls raw Modbus temperature and
humidity readings and converts them to floating point values in the
required units, and you can build APRS packets with the string
handling functions.<br clear="none">
<br clear="none">
You could have a BASIC script watch a Modbus temperature sensor and
door switch and when something of interest happens send an APRS
message over one radio port, play a series of WAV files on another
radio port, and use HTTPS to send JSON data to a service like Twilio
to send a text message to your phone.<br clear="none">
<br clear="none">
I'm looking into the feasibility of making it Echolink-compatible,
but usable technical information on Echolink is scarce. If anyone
knows of any protocol specification, please let me know. It looks
like it's using the GSM full-rate codec over RTP, but I don't know
anything about the signalling protocol.<br clear="none">
<br clear="none">
All of this is stuff you could do with a Raspberry Pi and a pile of
adapters and some shell scripts, but I'm trying to make it one
ready-to-use box with a scripting system geared toward
non-programmers.<br clear="none">
<br clear="none">
It's got months of work to go still, but a few units are out there
for beta testing as repeaters already. I'm hoping to have something
ready to release to the APRS community this summer.<br clear="none">
<br clear="none">
Scott<br clear="none">
N1VG<br clear="none">
<br clear="none">
<div class="yiv0638953111yqt8751880203" id="yiv0638953111yqt99962"><div class="yiv0638953111moz-cite-prefix">On 4/4/2017 8:25 AM, Ev Tupis wrote:<br clear="none">
</div>
<blockquote type="cite">
<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 clear="none">
</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 clear="none">
</div>
<div>Our value comes from "outside of the yellow tape".</div>
<div><br clear="none">
</div>
<div>Enter: APRS as the IoT/M2M of the Emcomm world<br clear="none">
</div>
<div><br clear="none">
</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 clear="none">
</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 clear="none">
</div>
<div><br clear="none">
</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 clear="none">
</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 clear="none">
</div>
<div><br clear="none">
</div>
<div>It is time to reinvent. How do we build inexpensive,
callibrated, deployable sensors and regain our worth to the
Emcomm community?<br clear="none">
</div>
<div><br clear="none">
</div>
<div>Ev, W2EV</div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
<div><br clear="none">
</div>
</div>
<div>Inspired by the post below...<br clear="none">
</div>
<div><br clear="none">
</div>
<div class="yiv0638953111yahoo_quoted" id="yiv0638953111yahoo_quoted_2246697666">
<div>On Monday, April 3, 2017, 8:04:38 PM EDT, Scott Miller
<a rel="nofollow" shape="rect" class="yiv0638953111moz-txt-link-rfc2396E" ymailto="mailto:scott@opentrac.org" target="_blank" href="mailto:scott@opentrac.org"><scott@opentrac.org></a> wrote:</div>
<div>
<div id="yiv0638953111">
<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 clear="none">
</div>
</div>
</div>
</blockquote></div>
<br clear="none">
</div></div></div></div></div></body></html>