<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body>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.<div><br></div><div>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.</div><div><br></div><div>Andrew Pavlin, KA2DDO</div><div>author of YAAC</div><br><br>-------- Original message --------<br>From: Heikki Hannikainen <hessu@hes.iki.fi> <br>Date: 4/28/20 16:07 (GMT-05:00) <br>To: aprssig@lists.tapr.org <br>Subject: Re: [aprssig] Proposal for APRS12 spec fix - Telemetry should allow for 000-999 <br><br><br>Bob,<br><br>I would go even further, and propose adopting Kenneth's proposed format, <br>as described here:<br><br>https://github.com/PhirePhly/aprs_notes/blob/master/telemetry_format.md<br><br>It documents what a bunch of software have been doing for quite a while: <br>sending positive *and* negative values in telemetry, and floating-point <br>decimal values as well. aprs.fi also supports this when receiving <br>telemetry:<br><br>http://blog.aprs.fi/2020/03/aprsfi-supports-kenneths-proposed.html<br><br>The aprsc server passes these packets to clients requesting a t/t filter <br>too - it only checks whether a packet is of telemetry type and leaves <br>further parsing and validation to the receiving client software. This <br>also makes it possible for the receiving software to show error messages <br>if it has any problems decoding some particular telemetry packet.<br><br><br>On Tue, 28 Apr 2020, Robert Bruninga wrote:<br><br>> The original APRS spec said that the 5 channel<br>> T#sss,111,222,333,444,555,11111111 telemetry format would be limited to 5<br>> channels from 000 to 255. But in fact, many people have been using values<br>> from 000 to 999 without affecting the fixed 3 byte format. The only reason<br>> for the original limitation was simply that that was what was being<br>> transmitted by some early TNC's..<br>><br>> I see no need to not allow 000-999 in those fields for the more common these<br>> days 10 bit A/D telemetry sensors, since it does not change the 3X fixed<br>> integer format.<br>><br>> So I propose to document this note in the APRS12 update page:<br>> http://aprs.org/aprs12.html<br>><br>> Bob, WB4APR<br>><br>> -----Original Message-----<br>> From: Pete Loveall AE5PL <pete@ae5pl.net><br>> Sent: Tuesday, April 28, 2020 2:36 PM<br>> To: Robert Bruninga <bruninga@usna.edu><br>> Subject: RE: Telemetry should allow for 000-999<br>><br>> Actually, Bob, it was not arbitrary. That 3 digit value represents 1<br>> unsigned byte because Kantronics (and the rest of the experimenters in the<br>> 1990s) used 8 bit A-D converters (thus, also, the term "analog" when<br>> referring to those values). Any software that supports the spec might be<br>> backing it with a single byte value.<br>><br>> javAPRSSrvr is unaffected by that aspect of spec and its server operations<br>> (passing packets) is -not- affected by that aspect of the spec. I wrote<br>> APRSFilter, however, to be specification specific and it does not consider<br>> non-compliant packets as being "ok". Again, this does not affect<br>> javAPRSSrvr's operation as an APRS-IS server. It only affects those who try<br>> to use a telemetry filter on a flow restricted port. If it is of<br>> significant concern, use the callsign filter for the station of interest<br>> sending the telemetry and those packets will be passed along with any other<br>> packets -generated- by the requested station.<br>><br>> 73,<br>><br>> Pete Loveall AE5PL<br>> www.ae5pl.net<br>><br>> This electronic message transmission contains information from Peter Loveall<br>> AE5PL which may be confidential or privileged. The contents of this message<br>> are intended solely for the use of the recipient or recipients named above.<br>> If you are not the intended recipient, be aware that interception,<br>> disclosure, duplication, distribution or any other exploitation of this<br>> message is prohibited.<br>><br>> If you have received this electronic transmission in error, please<br>> immediately notify me by telephone at (972) 838-4107 or by email at<br>> pete@ae5pl.net<br>><br>><br>><br>> -----Original Message-----<br>> From: Robert Bruninga <bruninga@usna.edu><br>> Sent: Tuesday, April 28, 2020 1:09 PM<br>> To: Pete Loveall AE5PL Lists <hamlists@ametx.com><br>> Cc: Robert Bruninga <bruninga@usna.edu><br>> Subject: Telemetry should allow for 000-999<br>><br>> Pete,<br>><br>><br>><br>> Can you change the test in APRSSrvr for the 255 limit in the telemetry to be<br>> 0-999 and not just 0-255. That was an arbitrary limit since the original<br>> MicE from TAPR only transmitted 0-255, but there should never have neen a<br>> restriction on receipt of 000-999 since the goal was a fixed 3 digit integer<br>> field and since most A/D telemetry boxes now use 10 bit A/D converters, this<br>> restriction is obsolete.<br>><br>><br>><br>> In fact all my satellites have used the broader field for years.<br>><br>><br>><br>> If you like, I can change the spec in APRS12…<br>><br>><br>><br>> Thanks<br>><br>> Bob<br>><br>><br>><br>><br>><br>> From: Lynn W. Deffenbaugh (Mr) <ldeffenb@homeside.to<br>> <mailto:ldeffenb@homeside.to> ><br>> Sent: Monday, April 27, 2020 10:30 AM<br>> To: Robert Bruninga <bruninga@usna.edu <mailto:bruninga@usna.edu> ><br>> Subject: Re: [APRSISCE] JS8CAll/FT8 Log Scrapers (Dev 2020/04/26 22:23)<br>><br>><br>><br>> Actually, I "fixed" it because javAPRSSrvr is very strict when it comes the<br>> spec compliance. The t/t (type of telemetry) filter does not consider<br>> telemetry packets with values >255 to be telemetry and it won't pass them on<br>> that filter. As long as the packet matches some other filter, it will pass,<br>> and the packets certainly propagate through the APRS-IS network, but<br>> javAPRSSrvr doesn't consider them to be telemetry.<br>><br>> Lynn (D) - KJ4ERJ<br>><br>> On 4/27/2020 10:19 AM, Robert Bruninga wrote:<br>><br>> Lynn,<br>> I have no objection to telemetry in the 5 channel format to be 000-999.<br>> I use that on all my satellites.There was no reason to limit it to 0-255 as<br>> in the original spec.<br>><br>> bob<br>><br>> _______________________________________________<br>> aprssig mailing list<br>> aprssig@lists.tapr.org<br>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br>><br><br> - Hessu<br><br>_______________________________________________<br>aprssig mailing list<br>aprssig@lists.tapr.org<br>http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org<br></body></html>