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

[Scott Miller]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170404/27272a3f/attachment.html>