[aprssig] VARA modem replacing APRS tocall

[Pete Loveall AE5PL Lists]

I agree with Lynn.  But I will take it one step further.  It has been important that the TOCALL (AX.25 destination call) be untouched in transit because it can be Mic-E data, GPS symbols, etc. along with denoting the -source- software/hardware.  Alteration in transit, as proposed by VARA modem users, is a violation of the APRS spec.  That said, there is an alternative which is already in place and completely compliant with the APRS spec.

When I worked with Bob back in 2005-2006 to bring DSTAR in as a transport mechanism, we determined it should be considered a separate -network- from the AX.25 network and from the APRS-IS (TCPIP) network.  Using the third-party packet concept for denoting the APRS-IS network (TCPIP*) and understanding that was how it was used on the APRS-IS network (packets injected directly into APRS-IS have only TCPIP* as the path), we determined DSTAR* should be the path used when using D-STAR to transport APRS packets.  When you think about it, it is denoting that the packet was "digipeated" via DSTAR 😉.

Why not use VARA* for the path when being transported via VARA modems?  This would tell anyone on the remote end of the VARA link that the packet was transported via VARA and precludes anyone trying to dictate to a remote network how a packet is to be digipeated.  This leaves packet data (from call, to call, data) untouched yet denotes the packet traversed a non-AX.25 network, specifically the VARA network.

73,

Pete Loveall AE5PL
pete at ae5pl dot net



-----Original Message-----
From: aprssig <aprssig-bounces at lists.tapr.org> On Behalf Of Lynn W Deffenbaugh (Mr)
Sent: Thursday, February 15, 2024 5:44 PM
To: aprssig at lists.tapr.org
Subject: Re: [aprssig] VARA modem replacing APRS tocall

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