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

Tue Apr 28 16:29:22 EDT 2020

Just as an observation, I coded receipt of telemetry messages in YAAC to accept floating point for the 5 analog fields, because I had so many errors reported from people sending telemetry messages like that. That code was like that from the first time I added support for telemetry messages in 2013, so floating point telemetry packets have been around since before then.So, IMHO, it's long past time to accept we're no longer limited to the capabilities of 40-year-old 8-bit microprocessors. And any 40-year-old 8-bit microprocessor APRS stations aren't going to be analyzing the contents of received telemetry packets anyway.Andrew Pavlin, KA2DDOauthor of YAAC

-------- Original message --------
From: Heikki Hannikainen <hessu at hes.iki.fi> 
Date: 4/28/20  16:07  (GMT-05:00) 
To: aprssig at lists.tapr.org 
Subject: Re: [aprssig] Proposal for APRS12 spec fix - Telemetry should allow for 000-999 

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.mdIt 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.htmlThe 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_______________________________________________aprssig mailing listaprssig at lists.tapr.orghttp://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20200428/7cf87f7f/attachment.html>