[aprssig] Why do stations send telemetry parameter messages to themselves?
Lynn W Deffenbaugh (Mr)
KJ4ERJ at arrl.net
Wed Nov 20 15:29:17 EST 2024
On 11/20/2024 2:51 PM, John Gorkos wrote:
>
> 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.
Ah, right, the raw AX.25 frame (likely via KISS), not the humanly
readable TNC-2 formatted APRS packet. My approach with that is to
first convert the AX.25 to TNC-2 format which makes them all the same.
Some TNCs in some modes actually hand you the TNC-2 format to start
with. My parser then, only needs to handle the TNC-2 format and can
ignore whatever the transport-formatted packet (like AX.25) looked
like. The aprs101.pdf spec is written based on the TNC-2 APRS packets,
NOT the raw AX.25 format.
Once you're in TNC-2 format, the type indicator byte immediately follows
the first colon and will be another colon (":") because the telemetry
definitions are actually APRS messages and 100% comply with that format
for parsing. So you parse it as a message, set the source and
addressee station IDs and let the caller figure out that they match and
what to do with the actual definitions.
AFAIK, no addendums have done anything to the telemetry definition
specifications, so you didn't miss anything there.
As for the "All Other Packets", just because your parser recognizes the
Data Type Identifier doesn't mean that the packet is actually one of
those. It is not uncommon to receive a packet that starts with T (like
"This is a comment") but it's not really a Telemetry packet. You'll
note that the "All Other Packets" section defines them as "Packets that
do not meet any of the formats described..." which means if a T packet
is received, but fails the more detailed parse of the Telemetry
specification, then it is, by specification, an "Other Packet" as well
even with the recognized DTI.
>>>
>>> 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. :)
That actually sounds like the structure of my APRS programs. One section
gets the packets from the channel and converts it to TNC-2 format. That
packet is then passed to the parser which implements the aprs101.pdf
specification and returns a structure with a set of "valid" bits and
sub-structures that contain the parsed information from the packet. In
my case, the parser (since it is part of the specification) recognizes a
Message packet that is actually a Telemetry Definition, parses it
according to that part of the spec, and populates the appropriate
section of my parsed packet structure with the appropriate "valid" bit
set. Once the parser returns, the rest of the code decides what needs to
be done with the packet, gate the original TNC-2 format to the APRS-IS
port, or gate it to a local RF port (which handles any TNC-2 to AX.25
conversion if necessary), process it internally (like handling query
messages or internal auto-responders), or map the packet to an object on
a locally connected display.
But in any/all cases, I only attempt to parse TNC-2 formats because
that's what the spec describes, not the RF-side's quirks (like
bit-shifted callsigns, reversed source/destination structures, bits,
protocol identifiers, character escaping, or prefix/suffix packet
wrapping. I let the port logic handle that because, like I stated
earlier, some ports may be KISS/AX.25 and others deal directly in TNC-2
formatted packets (like APRS-IS-server compatible ports and some TNCs).
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
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
More information about the aprssig
mailing list