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

Tue Apr 28 16:39:55 EDT 2020

How does the Kenneth's proposal on APRS.FI (below) compare to the APRS.FI
proposal that has been posted before on aprs12.html -
http://he.fi/doc/aprs-base91-comment-telemetry.txt

I'm open to clarifying this as needed?
Bob
-----Original Message-----
From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Heikki
Hannikainen
Sent: Tuesday, April 28, 2020 4:07 PM
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.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