[aprssig] VARA modem replacing APRS tocall

Thu Feb 15 18:43:36 EST 2024

On 2/15/2024 4:15 PM, Jose Alberto Nieto Ros wrote:
> I understand your concern but I don't share your opinion at all.  If 
> VARA is the source then i can use APVARA, but if the source is 
> PinPoint connected to VARA, then i have to use APPIN20. OK, then, must 
> i to build an APRS client embedded in VARA Modem (Like JS8CALL)  to 
> send a Position Report as "APVARA"  having specific applications (like 
> Pinpoint) for it ? Has no sense

The applicant for APVARA indicated that the VARA HF modem is dropping 
the client's ToCall when transmitting packets over RF and then 
substituting APVARA at the receiving end.   The connected client at the 
receiving end then gates this incorrectly substituted packet to the 
APRS-IS resulting in the issue.

The destination callsign, aka ToCall, is designed to represent the 
SOURCE of the packet, not the MODEM over which a packet may have been 
transmitted.   If you actually implement a full APRS client, then yes, 
by all means you can use APVARA as the ToCall. But if VARA HF is 
actually just a modem, and not the originator of a packet, then the 
entire packet, including an unmodified destination callsign/ToCall is 
expected to be transmitted and received intact by all receiving stations.

>
> / If the destination callsign is considered "unnecessary", then who is 
> to say that comment strings, altitudes, speed/direction, or other 
> various APRS packet components won't be dropped in the future to "save 
> RF time" by some particular protocol./
>
> Do you really consider destination callsign to be equally important as 
> comment strings, altitudes, speed/direction.... ?

Yes, I consider all specified portions of an APRS packet to be equally 
important.  None of them should be modified according to the 
specifications, beyond the provision that an IGate is supposed to insert 
a q-Construct at the end of the path.  If a packet is formatted at the 
source, then that same unmodified packet should be received at the 
destination.   The over-the-air format is up to the modem and the RF 
protocol, but the APRS packet format should not be modified from end to 
the other.

>
> and do you consider someone are going to drop in his protocol comment 
> strings, altitudes, speed/direction, or other various APRS packet 
> components, when is the user who decides what he want to include or 
> not in their frames?
>
> We are mixing pears with apples

Nope, all components of the APRS packet are equal.   You are correct 
that the user decides what to include in the frame.   And the user of 
specific APRS client software, by that choice of software, is choosing 
what ToCall the packets should contain.   It is not up to other software 
to replace any component of that APRS packet, or that other software is 
not "APRS" any longer.

Lynn (D) - KJ4ERJ - APRS Foundation - Ensuring the Future of APRS

>
> sincerely
> Jose
> EA5HVK
>
>
> ------------------------------------------------------------------------
> *De:* Lynn W. Deffenbaugh (Mr) <KJ4ERJ at homeside.to>
> *Enviado:* jueves, 15 de febrero de 2024 20:40
> *Para:* aprssig at lists.tapr.org <aprssig at lists.tapr.org>
> *Cc:* mike.ph4 at gmail.com <mike.ph4 at gmail.com>; nietoros at hotmail.com 
> <nietoros at hotmail.com>
> *Asunto:* Re: [aprssig] VARA modem replacing APRS tocall
> First, I hope both Michael Phelps NA7Q (the person raising the issue) 
> and Jose Alberto Nieto Ros EA5HVK (apparently the VARA HF author) are 
> members here on the aprssig.  This is the definitive venue to discuss 
> APRS and APRS-IS implementation issues and questions.
>
> I concur that this is very bad practice and 100% non-APRS-IS-spec 
> compliant.   To quote the specification from 
> https://aprs-is.net/IGating.aspx <https://aprs-is.net/IGating.aspx>
>
>> *No modification of the TNC2 format line should be made* except to 
>> add ,qAR,IGATECALL to the end of the path (and the third-party 
>> exception noted above). IGATECALL is the callsign-SSID of the IGate 
>> and denotes the point of entry for the packet.
> Specifications exist to ensure compatibility across independent 
> implementations. The so-called "ToCall" (actually the AX.25 
> destination address) is defined in the APRS101.pdf specification to 
> contain (page 13) one of the following:
>
> The AX.25 Destination Address field can contain 6 different types of 
> APRS information:
> • A generic APRS address.
> • A generic APRS address with a symbol.
> • An APRS software version number.
> • Mic-E encoded data.
> • A Maidenhead Grid Locator (obsolete).
> • An Alternate Net (ALTNET) address.
>
> Each of these is further detailed in the following sections of chapter 
> 4. While it may not be explicitly stated, the ToCall is assigned by 
> the originator of the packet. So, if VARA HF is SOURCING the packets, 
> then using >APVARA would fit within the specifications.  However, in 
> this case the VARA HF modem is choosing to not transmit the ToCall to 
> save a few bytes over RF.  However, this constitutes a loss important 
> data from the original packet and a non-compliant modification of the 
> original client APRS packet.
>
> There are many tools that use the packet destination address (ToCall) 
> to identify the type of station that originated the packet.  This is 
> used to identify client station capabilities (messaging-capable, for 
> instance) as well as to identify client hard/firm/software that may be 
> generating non-compliant packets.  This is the reason behind the IGate 
> specifications. IGates are responsible for relaying the actual 
> received packets, without modifications, to the APRS-IS. To do 
> otherwise is to invite chaos into the system.
>
> IMHO, the loss of the originating client identity (or worse, a 
> conflicting indication of the client identity if the original packet 
> is delivered to the APRS-IS outside of VARA HF) is not worth the 
> savings of a short bit of RF time. If the destination callsign is 
> considered "unnecessary", then who is to say that comment strings, 
> altitudes, speed/direction, or other various APRS packet components 
> won't be dropped in the future to "save RF time" by some particular 
> protocol.
>
> Lynn (D) - APRS Foundation - Ensuring the Future of APRS
>
> PS.   Most of the above text was originally posted by me in the quoted 
> github issue, but is copied here to keep a single discussion thread here.
>
> On 2/15/2024 2:50 PM, Heikki Hannikainen wrote:
>>
>> Hi,
>>
>> I've just learned that the VARA HF modem is replacing the APRS 
>> destination callsign with "APVARA".
>>
>> For example, if you use APRSIS32 with a VARA HF modem, APRSIS32 sets 
>> a tocall of APWW11 and sends the packet to VARA modem software, which 
>> replaces APWW11 with APVARA. This is apparently done to save a few 
>> bytes on the slow HF link.
>>
>> If APRSIS32 is configured to also send the packet to the APRS-IS, 
>> there will be two different copies of the packet, both will be 
>> received by other APRS stations, and the original APRS software model 
>> cannot be detected any more.
>>
>> https://github.com/aprsorg/aprs-deviceid/issues/123 
>> <https://github.com/aprsorg/aprs-deviceid/issues/123>
>>
>> Just thought this should be brought up for other APRS software 
>> developers to discuss, and for awareness of the side effects. I'm not 
>> particularly delighted by this implementation choice. Don't shoot the 
>> messenger.
>>
>>   - Hessu
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at lists.tapr.org <mailto:aprssig at lists.tapr.org>
>> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org 
>> <http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20240215/3bf2c353/attachment.html>