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

Wed Apr 12 06:42:16 EDT 2017

Hi Scott,I agree that a simple float switch would do.  Simple is the key.
I am frankly growing tired of going to ARES meetings and hearing about "passing voice traffic" and counting words to assure proper delivery and then going to Emergency First Responder meetings (in my professional capacity...where nobody knows I'm a ham) and hearing the snickers about ham radio when it is brought up casually.  We are frankly a burden as we appear at this time.
My position is different than Bobs on this.  The need is less "I want" than it is "we would be more valued if".
My approach is one of practical usefulness and "start by pursuing the low hanging fruit that people already want to eat.  I see flood gauges as being lower hanging fruit than methane detectors (I see more news stories about floods than methane leaks).  I see wind speed/direction gauges that can be deployed into and around fires (and left to burn if the perimeter is consumable...like a prairie or forest) as saving lives in real time.
Too many modules, too early is also bad.  Focusing on a flood detector and making it low-power (battery life), quickly deployable, disposable (if lost/stolen), re-usable (if not lost/stolen) and trainable will uncover other low-hanging fruit.
It will also motivate the re-generation of the needed APRS infrastructure to support delivery.  That infrastructure needs rethinking, too...but it will be driven by the learnings from a few deployed sensors.
Assuming that others are interested in this fresh approach to APRS and are still reading this post, I have a question... "What is the lowest-hanging-fruit for data sensors in YOUR area?"
Ev, W2EV

On Tuesday, April 11, 2017, 8:07:16 PM EDT, Scott Miller <scott at opentrac.org> wrote: 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.

 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.

 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.

 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.

 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.

 Scott
 N1VG

 On 4/6/2017 7:24 AM, Ev Tupis wrote:

   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. 
  Interestingly, the local ARES group has a text-message system that just sent out the following for my area... 
  "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!" 
  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. 
  I imagine a variation of a common "floor wet monitor" that you find in a hardware store that... 
  * can be deployed to a "flood prone" area, attached to a stake in the ground * would send a "flood stage" beacon once water was detected "at that level" * could be deployed during these events and removed afterward * run on a 9V battery (or maybe two) * with an algorithm to minimize battery consumption while still providing useful data * (maybe) could be cheap enough to be "throw aways" in case they are "swept away" (or stolen?) 
  I'm thinking small, inexpensive, deployable ... and a "bridge" to send that data to a municipality's "command center". 
  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. 
  THIS would be a big step in making amateur radio relevant again, in the eyes of the sworn-officer and professional EFR community.

  Ev, W2EV 

   On Tuesday, April 4, 2017, 9:36:46 AM EDT, Scott Miller <scott at opentrac.org> wrote:    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:

 http://imgur.com/2M8Xs9K

 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.

 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.

 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.

 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.

 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.

 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.

 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.

 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.

 Scott
 N1VG

  On 4/4/2017 8:25 AM, Ev Tupis wrote:

   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.

 Scott
 N1VG  

 _______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig

 _______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170412/c13495b3/attachment.html>