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

[Heikki Hannikainen]

Bob,

Yes, a lot of devices send values like that. But that example is 
disallowed by the specification and may be rejected by some receivers, 
since 845 and 345 are both outside the APRS101.PDF specified range of 
0-255:

"There are five 8-bit unsigned analog data values (expressed as 3-digit 
decimal numbers in the range 000–255)"

It'd make sense to relax this limit and adopt Kenneth's Proposed Telemetry 
Format. Old transmitters will still meet the spec so it's backwards 
compatible for those.
https://github.com/PhirePhly/aprs_notes/blob/master/telemetry_format.md


On Wed, 20 Nov 2019, Robert Bruninga wrote:

> 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
>

   - Hessu