[aprssig] Why do stations send telemetry parameter messages to themselves?

Wed Nov 20 14:51:03 EST 2024

On 11/19/24 8:38 PM, Lynn W Deffenbaugh (Mr) wrote:
> On 11/19/2024 7:08 PM, John Gorkos wrote:
>> inline comments
> ditto
>>
>>
>> On 11/17/24 8:23 PM, Lynn W Deffenbaugh (Mr) wrote:
>>> Read chapter 13 of aprs101.pdf.  It describes the "On-Air Definition 
>>> of Telemetry Parameters" which are specially formatted messages 
>>> (PARM, UNIT, EQNS, BITS) sent via APRS message format packets from a 
>>> station to itself.   The T datatype only carries values, not the 
>>> definitions of how to interpret those values.
>>
>> Ok.  So we have 4 specifically spec'ed, formatted messages that use 
>> no DTI, and cause parsers to specifically have to look beyond char[0] 
>> of an on-air message to see what they really contain and if they need 
>> special handling.  That's probably not the worst thing in the spec, 
>> but it's in the running...
>
> What null are you trying to parse beyond?   There isn't a null in the 
> telemetry definition messages.   At least, there's not supposed to 
> be.   What is a "DTI"?   I'm not familiar with that TLA (Three Letter 
> Acronym).
>
DTI:  Data type Identifier (Chap 5, page 17 aprs101).  In my parser, the 
APRS "Information Field" starts with character 0 as shown in the packet 
diagram  show on that same page, the "Data Type ID".    It corresponds 
to the beginning of the "INFORMATION FIELD" in the "AX.25 Frame" diagram 
on page 12.  I wasn't trying to imply it was a null.  One of the 
cornerstones of my parser is that I can look at that Data Type 
Identifier, reference against the "APRS Data Type Identifiers" table on 
p17, and accurately begin to parse the frame. Information fields that 
start with A-S, U-Z, or a-z are tagged as "do not use", so my logic 
interprets anything that start with those characters as "Other Packets" 
as defined in "Ch 19, p89" as "All Other Packets"   I guess, 
technically, these Telemetry definition packets should start with '{' as 
user defined, or ',' as "test data", or we could assign one of the 6 
unused DTIs from the table to Telemetry Definition packets.  It's 
possible that's been done in one of the addendums, which I'm horrible at 
referring to.
>>
>>
>>>
>>> As for RXTLM-1, technically that would be an Alternate Net 
>>> identifier of RXTLM since it doesn't start with AP.   You can read 
>>> about these on Page 15 of chapter 4 in aprs101.pdf.
>>>
>>> The -1 would be a Generic APRS Digipeater Path also discussed on 
>>> page 15 in chapter 4 of aprs101.pdf.   The -1 would technically be 
>>> the same as a WIDE1-1 path.
>>>
>>> However, that said, I suspect that the RXTLM-1 is actually not 
>>> meaning that but is being mis-used by some software somewhere.
>>>
>>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>>
>>>
>> And I still don't see the purpose of wrapping the telemetry specs in 
>> a message and sending it to yourself.  that triggers all kinds of 
>> third-party message handing in the network that doesn't need to be 
>> woke up.
> If we had been around when aprs101.pdf was being authored, I'm sure 
> we'd have learned the reasoning behind it.   But coming on the scene 
> later than that, we pretty much have to live with it.
>
> My first check in message packet handling: If the source callsign-SSID 
> is the same as the addressed callsign-SSID, process it as a telemetry 
> definition or ignore it entirely as needed. These should NEVER be 
> gated to RF from the APRS-IS, IMHO, if for no other reason that if the 
> addressed callsign-SSID was recently heard on RF, then the source 
> callsign-SSID must also be on RF (it is the same, after all) and so it 
> won't need these messages gated to it.
That logic follows.  I think I'll adopt that.
>
>>
>> I'm torn between being a spec-Nazi and just throwing my hands up and 
>> saying I can't fight 40 years of momentum.
>
> Like all specifications, implementers have the choice to be compliant 
> or non-compliant.   But if you expect to handle telemetry and present 
> it to the user in readable (read: converted) format, then you'll need 
> to process the definitions.
>
> And if you're doing IGating, then you need to consider these 
> definition and see how a message sourced by and addressed to the same 
> callsign-SSID would be handled in your logic.

My whole goal is accurate and complete parsing.  I then hand the parsed 
packet back to whatever code asked me to parse it, and it gets to decide 
what to DO with it.  That code could write it to a DB, formulate and 
answer and send it back to the originator, digipeat it, or put it in a 
bowl and smoke it.  Not My Problem at that point. :)

>
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
>
>>
>>>
>>> On 11/14/2024 4:15 PM, John Gorkos wrote:
>>>> I'm back into the deep, ugly guts of parsing the full APRS-IS 
>>>> stream, and I keep seeing messages like this:
>>>>
>>>>
>>>> EL-OK1BY>RXTLM-1,TCPIP,qAR,OK1BY::EL-OK1BY:UNIT.RX Erlang,TX 
>>>> Erlang,RXcount/10m,TXcount/10m,none1,STxxxxxx,logic
>>>> ER-F5ZVB>RXTLM-1,TCPIP,qAR,F5ZVB::ER-F5ZVB :UNIT.RX Erlang,TX 
>>>> Erlang,RXcount/10m,TXcount/10m,none1,STxxxxxx,logic
>>>> KI0AU-1>APMI06,TCPIP*,qAC,T2BC::KI0AU-1 
>>>> :UNIT.C,Pkt,Pkt,Volts,Volts,N1,N2,N3,N4,N1,N2,N3,N4
>>>> GM7AFE>APMI01,TCPIP*,qAS,MB7UZL::GM7AFE 
>>>> :UNIT.Pkt,Pkt,Pcnt,Volts,Volts,Off,On,On,On,Hi,Hi,Hi,Hi
>>>>
>>>> Why are stations wrapping telemetry parameter messages in APRS 
>>>> Messages and then sending them to themselves?  At least they're not 
>>>> asking for acknowledgements.  Can anyone explain this behavior and 
>>>> what it's intended to do, versus just using a :T telemetry message, 
>>>> per spec?
>>>>
>>>> While we're at it, what does the RXTLM-1 tocall tell me? Clearly 
>>>> something to do with Receive Telemetry (i.e. erlang values, etc).
>>>>
>>>>
>>>> Thanks de AB0OO
>>>> John Gorkos
>>>>
>>>>
>>>> _______________________________________________
>>>> aprssig mailing list
>>>> aprssig at lists.tapr.org
>>>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>>
>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at lists.tapr.org
>>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA4025CE04AE176ED_and_old_rev.asc
Type: application/pgp-keys
Size: 2346 bytes
Desc: OpenPGP public key
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20241120/6eb665e2/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20241120/6eb665e2/attachment-0001.asc>