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

Tue Apr 28 16:46:05 EDT 2020

Hi,

The base91 telemetry is a different, parallel track. It was implemented to 
allow transmitting telemetry together with position packets, as some 
trackers want to transmit a few voltage parameters or such and it's nice 
to be able to send them together with the position in a highly compressed 
format. Mic-E telemetry got superseded/conflicted by Mic-E type codes so 
it did not work any more. Base91 telemetry has been implemented in quite a 
few places now, and as a side effect it also provides a sequence number 
for the position packet which is otherwise missing in all the position 
formats.

Kenneth's proposal just relaxes the "regular" telemetry packet format 
further, to allow large values (outside 0-255 or 0-999), negative values, 
and decimal values (-0.005 or whatever). And to allow a variable length 
format.

On Tue, 28 Apr 2020, Robert Bruninga wrote:

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

   - Hessu