[aprssig] Proposal for APRS12 spec fix - Telemetry should allow for 000-999

[Heikki Hannikainen]

Bob,

I would go even further, and propose adopting Kenneth's proposed format, 
as described here:

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

It documents what a bunch of software have been doing for quite a while: 
sending positive *and* negative values in telemetry, and floating-point 
decimal values as well. aprs.fi also supports this when receiving 
telemetry:

http://blog.aprs.fi/2020/03/aprsfi-supports-kenneths-proposed.html

The aprsc server passes these packets to clients requesting a t/t filter 
too - it only checks whether a packet is of telemetry type and leaves 
further parsing and validation to the receiving client software.  This 
also makes it possible for the receiving software to show error messages 
if it has any problems decoding some particular telemetry packet.


On Tue, 28 Apr 2020, Robert Bruninga wrote:

> The original APRS spec said that the 5 channel
> T#sss,111,222,333,444,555,11111111 telemetry format would be limited to 5
> channels from 000 to 255.  But in fact, many people have been using values
> from 000 to 999 without affecting the fixed 3 byte format.   The only reason
> for the original limitation was simply that that was what was being
> transmitted by some early TNC's..
>
> I see no need to not allow 000-999 in those fields for the more common these
> days  10 bit A/D telemetry sensors, since it does not change the 3X fixed
> integer format.
>
> So I propose to document this note in the APRS12 update page:
> http://aprs.org/aprs12.html
>
> Bob, WB4APR
>
> -----Original Message-----
> From: Pete Loveall AE5PL <pete at ae5pl.net>
> Sent: Tuesday, April 28, 2020 2:36 PM
> To: Robert Bruninga <bruninga at usna.edu>
> Subject: RE: Telemetry should allow for 000-999
>
> Actually, Bob, it was not arbitrary.  That 3 digit value represents 1
> unsigned byte because Kantronics (and the rest of the experimenters in the
> 1990s) used 8 bit A-D converters (thus, also, the term "analog" when
> referring to those values).  Any software that supports the spec might be
> backing it with a single byte value.
>
> javAPRSSrvr is unaffected by that aspect of spec and its server operations
> (passing packets) is -not- affected by that aspect of the spec.  I wrote
> APRSFilter, however, to be specification specific and it does not consider
> non-compliant packets as being "ok".  Again, this does not affect
> javAPRSSrvr's operation as an APRS-IS server.  It only affects those who try
> to use a telemetry filter on a flow restricted port.  If it is of
> significant concern, use the callsign filter for the station of interest
> sending the telemetry and those packets will be passed along with any other
> packets -generated- by the requested station.
>
> 73,
>
> Pete Loveall AE5PL
> www.ae5pl.net
>
> This electronic message transmission contains information from Peter Loveall
> AE5PL which may be confidential or privileged.  The contents of this message
> are intended solely for the use of the recipient or recipients named above.
> If you are not the intended recipient, be aware that interception,
> disclosure, duplication, distribution or any other exploitation of this
> message is prohibited.
>
> If you have received this electronic transmission in error, please
> immediately notify me by telephone at (972) 838-4107 or by email at
> pete at ae5pl.net
>
>
>
> -----Original Message-----
> From: Robert Bruninga <bruninga at usna.edu>
> Sent: Tuesday, April 28, 2020 1:09 PM
> To: Pete Loveall AE5PL Lists <hamlists at ametx.com>
> Cc: Robert Bruninga <bruninga at usna.edu>
> Subject: Telemetry should allow for 000-999
>
> Pete,
>
>
>
> Can you change the test in APRSSrvr for the 255 limit in the telemetry to be
> 0-999 and not just 0-255.  That was an arbitrary limit since the original
> MicE from TAPR only transmitted 0-255, but there should never have neen a
> restriction on receipt of 000-999 since the goal was a fixed 3 digit integer
> field and since most A/D telemetry boxes now use 10 bit A/D converters, this
> restriction is obsolete.
>
>
>
> In fact all my satellites have used the broader field for years.
>
>
>
> If you like, I can change the spec in APRS12…
>
>
>
> Thanks
>
> Bob
>
>
>
>
>
> From: Lynn W. Deffenbaugh (Mr) <ldeffenb at homeside.to
> <mailto:ldeffenb at homeside.to> >
> Sent: Monday, April 27, 2020 10:30 AM
> To: Robert Bruninga <bruninga at usna.edu <mailto:bruninga at usna.edu> >
> Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)
>
>
>
> Actually, I "fixed" it because javAPRSSrvr is very strict when it comes the
> spec compliance.  The t/t (type of telemetry) filter does not consider
> telemetry packets with values >255 to be telemetry and it won't pass them on
> that filter.  As long as the packet matches some other filter, it will pass,
> and the packets certainly propagate through the APRS-IS network, but
> javAPRSSrvr doesn't consider them to be telemetry.
>
> Lynn (D) - KJ4ERJ
>
> On 4/27/2020 10:19 AM, Robert Bruninga wrote:
>
> 	Lynn,
> 	 I have no objection to telemetry in the 5 channel format  to be 000-999.
> I use that on all  my satellites.There was no reason to limit it to 0-255 as
> in the original spec.
>
> 	bob
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>

   - Hessu