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

Jim Alles kb3tbx at gmail.com
Thu Apr 13 13:43:23 EDT 2017

Scott, my brain might be mush, but it mashed up your message with
​ a recent article about​
'modular phones'.


Amateur Radio building blocks? SDR could be a part of the equation, I don't
phone bloks (youtube) <https://www.youtube.com/watch?v=oDAw7vW7H0c>


Jim A.​

---------- Forwarded message ----------
From: Scott Miller <scott at opentrac.org>
Date: Tue, Apr 11, 2017 at 8:06 PM
Subject: Re: [aprssig] APRS = the IoT of Amateur Radio [was: APRS to the
planet rescue?
To: aprssig at tapr.org

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.


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.


aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20170413/8993225b/attachment.html>

More information about the aprssig mailing list