<div dir="ltr"><div>Way to go Scott!</div><div><br></div><div>Yes, I'm ready to roll on the AoT, (APRS of things)!  As our government and its followers turns towards greed and self interest and profit over science and knowledge and the protection of our environment, we are just going to have to do what we can ourselves.</div><div><br></div><div>We'll probably have to carve out a different frequency to protect our throughput on 144,39, but that will come when needed.  </div><div><br></div><div>I sure wish there were cheap modules on 6m!  The path loss for Omni to Omni is 8 dB better than 2m and 16 dB better than UHF (though the higher noise floor eats up most of that.</div><div><br></div><div>I want theses things:</div><div>* water gauge, (flood gauge)</div><div>* Methane detector</div><div>* Radiation detector</div><div>* Radon Detetctor</div><div>* Carbon monoxide</div><div>* Smoke</div><div>* others?</div><div><br></div><div>And I want a TX only unit and a 2-way unit for building the mesh DIGI network.</div><div><br></div><div>Bob, WB4APR<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 11, 2017 at 8:06 PM, Scott Miller <span dir="ltr"><<a href="mailto:scott@opentrac.org" target="_blank">scott@opentrac.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    I remember seeing an APRS flood monitor at Dayton a few years ago. 
    They weren't particularly cheap devices, but I think they used
    ultrasonic gauges.  A simple float switch would do it.<br>
    <br>
    The DRA818V (and probably others) transceiver modules have finally
    started to make a lot of these applications cheap and practical on 2
    meters without resorting to scavenged HTs.  They're under $15 and
    good for at least half a watt of TX power, or a full watt if you
    believe the data sheet.<br>
    <br>
    My current project isn't focusing on low power consumption right
    now, but without any effort at power saving it's still not too bad -
    I just tested it at about 80 mA @ 5 volts with WiFi connected and
    idle.<br>
    <br>
    I'll definitely work on getting something out there to cover the low
    power sensor mesh stuff.  Having a high-level scripting language
    geared specifically for APRS and radio applications should make it a
    lot easier to tackle some of these projects than starting from
    scratch with an Arduino, with a lot less power consumption than a
    single-board computer like a Raspberry Pi.<br>
    <br>
    Some of this I'm going to do for myself, market viability be damned,
    because I've got too many little sensor and remote monitoring and
    control projects of my own that don't rate custom hardware and
    firmware.  Even if no one else ever buys any, I'm going to have a
    shelf full of complete APRS gadgets that I can use to throw together
    just about anything without having to compile any code.<br>
    <br>
    Scott<br>
    N1VG<br>
    <br>
    <div class="m_4142914530507397364moz-cite-prefix">On 4/6/2017 7:24 AM, Ev Tupis wrote:<br>
    </div>
    <blockquote type="cite">
      <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 class="m_4142914530507397364yahoo_quoted" id="m_4142914530507397364yahoo_quoted_2060958414">
          <div>On Tuesday, April 4, 2017, 9:36:46 AM EDT, Scott Miller
            <a class="m_4142914530507397364moz-txt-link-rfc2396E" href="mailto:scott@opentrac.org" target="_blank"><scott@opentrac.org></a> wrote:</div>
          <div>
            <div id="m_4142914530507397364yiv0638953111">
              <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 class="m_4142914530507397364yiv0638953111moz-txt-link-freetext" href="http://imgur.com/2M8Xs9K" target="_blank" rel="nofollow" shape="rect">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="m_4142914530507397364yiv0638953111yqt8751880203" id="m_4142914530507397364yiv0638953111yqt99962">
                  <div class="m_4142914530507397364yiv0638953111moz-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="m_4142914530507397364yiv0638953111yahoo_quoted" id="m_4142914530507397364yiv0638953111yahoo_quoted_2246697666">
                        <div>On Monday, April 3, 2017, 8:04:38 PM EDT,
                          Scott Miller <a class="m_4142914530507397364yiv0638953111moz-txt-link-rfc2396E" href="mailto:scott@opentrac.org" target="_blank" rel="nofollow" shape="rect"><scott@opentrac.org></a>
                          wrote:</div>
                        <div>
                          <div id="m_4142914530507397364yiv0638953111">
                            <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>
      <br>
      <fieldset class="m_4142914530507397364mimeAttachmentHeader"></fieldset>
      <br>
      <pre>______________________________<wbr>_________________
aprssig mailing list
<a class="m_4142914530507397364moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org" target="_blank">aprssig@tapr.org</a>
<a class="m_4142914530507397364moz-txt-link-freetext" href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>______________________________<wbr>_________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a href="http://www.tapr.org/mailman/listinfo/aprssig" target="_blank" rel="noreferrer">http://www.tapr.org/mailman/<wbr>listinfo/aprssig</a><br>
<br></blockquote></div><br></div></div>