[aprssig] APRS: IoT via Ham Radio (-> telemetry format)

[Robert Bruninga]

We always choose an R1/R2 volytage divider in the sending device so that
the"count" in the telemetry packet makes human sense even without equations
generally.   IE, T#000,845,345,123,xxx,xxx,01000001
Would mean 8.45 volts on channel 1, 345 mA on channel 2, and 1.23 volts on
the 3rd channel and so on.

This works well on linear sensors.
bob

-----Original Message-----
From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Heikki
Hannikainen
Sent: Wednesday, November 20, 2019 2:21 PM
To: TAPR APRS Mailing List <aprssig at lists.tapr.org>
Subject: Re: [aprssig] APRS: IoT via Ham Radio (-> telemetry format)

On Wed, 20 Nov 2019, Jason KG4WSV wrote:

> APRS could simply act as a transport for MQTT messages as wb2osz points
> out at the beginning of this thread.
>
> If the APRS telemetry source makes full use of the PARM/UNIT/EQNS/BITS
> features it would be relatively simple to put together an APRS to MQTT
> gateway that translates APRS telemetry packets to fully functional MQTT
> messages.  Likewise some MQTT messages could translate to APRS telemetry.

At this point I'd like to briefly highlight this fine proposal from Kenneth,
under the title "Proposed Telemetry format":

https://github.com/PhirePhly/aprs_notes/blob/master/telemetry_format.md

It basically would relax the archaic APRS telemetry format of 8-bit integer
values, to allow floating-point values and negative values too, without
weird exercises with EQNS.

I think this would ease up the work of APRS implementations a lot,
especially on the transmitting side. The network has an awful lot of
trackers which send the 8-bit intneger values but the EQNS have never been
sent, or they've been sent a few times 4 years ago.

Changes on receiving side would be trivial (just parse the floating-point
values, and apply EQNS if they are available).

   - Hessu