VARA Modem

[na7q]

tocall: APVARA vendor: Jose, EA5HVK model: VARA HF Modem

VARA HF Modem for APRS usage.

We are experimenting with a version of VARA HF that replaces the tocall of all clients with APVARA. Doing so allows the slowest speed possible in VARA (SL1), while limiting the packet size to keep the RF time at a minimum. While this is does not align with the APRS standards, it has been agreed upon by active APRS users as an acceptable sacrifice. Adaptation is key to ham radio!

[hessu]

Hi,

So do I understand this right: an igate which receives VARA packets would change the tocall to APVARA?

Or is it the transmitting station which uses APVARA as destination callsign instead of something else?

[wb2osz]

Could you elaborate on the rationale for the TNC to replace the destination ("tocall") field with the modem type? Would this apply to the MIC-E format as well? This field has a well established meaning that all implementations are expected to follow. I find it troubling that it would be hijacked for a different purpose.

73, John WB2OSZ

[ldeffenb]

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, the originally posted request specifies:

VARA HF that replaces the tocall of all clients with APVARA

This violates the APRS-IS specifications of what is allowable for IGates, specifically:

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.

Or if you consider the destination address to be part of the path (it isn't really) https://aprs-is.net/IGateDetails.aspx

Gates must not modify paths of packets gated to APRS-IS except to append ,qAR,IGATECALL (IGATECALL = the callsign-SSID of the IGate).

There are many tools that use the packet destination address 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.

[ldeffenb]

Adaptation is key to ham radio!

This may be true, but backward compatibility with published specifications is equally, if not more, important. Imagine the outcry if someone decides to implement a new over-the-air protocol that sounds like, but is incompatible with, VARA HF, but wants to call it "VARA" because it delivers nearly similar functionality?

Or the case that already happened with JS8CALL, which originated as an incompatible extension of FT8. IIRC, it was originally called FT8CALL until the public outcry forced a name change.

If it is called "APRS" over VARA HF, then it must be compliant with all of the definitions of "APRS" (and APRS-IS).

There have been other suggestions of extensions to the APRS-IS (which, in fact, is what this request is about). It may be time to establish a group to work on a completely new APRS packet Internet-based distribution network to support these "forward looking", but incompatible adaptations.

[hessu]

The comments from @ldeffenb and @wb2osz contain some of the worries I had, additionally I'm worried about duplicate packet suppression failing on the APRS-IS if an APRS-IS client sends a packet to VARAHF and which replaces the tocall, and the packet also goes via another path (older VARAHF igate version, or directly to APRS-IS from the APRS application).

But @na7q please elaborate, what are the actual intentions. This is again probably not the best place to discuss APRS protocol and compatibility issues, maybe the APRS groups.io group, or the APRSSIG would be better, if you'd like to take the discussion there, that'd be great.

[hessu]

Here is a related ticket: https://github.com/hessu/aprsc/issues/84 - maybe @ldeffenb and @wb2osz could chime in for additional expertise on the matter as mine seems to not be convincing enough.

It seems like VARA is indeed replacing the tocall of packets originated by (for example) APRSIS32. Mic-E packets will be broken as it encodes data in the tocall, APRSIS32 software can no longer be detected, and if APRSIS32 sends the same packet to the APRS-IS, there will be two slightly modified copies of the same packet. This is quite unfortunate.

As for this ticket, I don't mind allocating APVARA for the VARA software if it is indeed generating packets of its own. If it's replacing the tocall of packets generated by other software, it is a problem of its own (and off-topic for the allocation discussion).

[na7q]

Hi,

So do I understand this right: an igate which receives VARA packets would change the tocall to APVARA?

Or is it the transmitting station which uses APVARA as destination callsign instead of something else?

No. The Modem, that being VARA HF, replaces it from the client. It's quite simple. The reason for it is simply to reduce the packet size.

[na7q]

Could you elaborate on the rationale for the TNC to replace the destination ("tocall") field with the modem type? Would this apply to the MIC-E format as well? This field has a well established meaning that all implementations are expected to follow. I find it troubling that it would be hijacked for a different purpose.

73, John WB2OSZ

Simple. It reduces the packet size as the modem won't include it on transmission, allowing for truly robust packet. It does not replace anything for compressed packets. Nothing troubling about it.

[na7q]

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, the originally posted request specifies:

VARA HF that replaces the tocall of all clients with APVARA

This violates the APRS-IS specifications of what is allowable for IGates, specifically:

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.

Or if you consider the destination address to be part of the path (it isn't really) https://aprs-is.net/IGateDetails.aspx

Gates must not modify paths of packets gated to APRS-IS except to append ,qAR,IGATECALL (IGATECALL = the callsign-SSID of the IGate).

There are many tools that use the packet destination address 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.

Adapt or die. I get that like FT8, all the old guys are complaining, "THIS ISN'T REAL HAM RADIO". This situation within APRS is no different. The igate is not what changes it, it's the modem. All for great reasons.

[na7q]

Adaptation is key to ham radio!

This may be true, but backward compatibility with published specifications is equally, if not more, important. Imagine the outcry if someone decides to implement a new over-the-air protocol that sounds like, but is incompatible with, VARA HF, but wants to call it "VARA" because it delivers nearly similar functionality?

Or the case that already happened with JS8CALL, which originated as an incompatible extension of FT8. IIRC, it was originally called FT8CALL until the public outcry forced a name change.

If it is called "APRS" over VARA HF, then it must be compliant with all of the definitions of "APRS" (and APRS-IS).

There have been other suggestions of extensions to the APRS-IS (which, in fact, is what this request is about). It may be time to establish a group to work on a completely new APRS packet Internet-based distribution network to support these "forward looking", but incompatible adaptations.

100% disagree. Modes change, you either stay behind or you move forward. We all know the old guys will fight and bicker the whole way.

[ldeffenb]

It does not replace anything for compressed packets. Nothing troubling about it.

Compressed packets send the entire coordinate in the payload, so you are correct in your statement.

But the real issue is with Mic-E-encoded packets where a portion of the coordinates is formatted into the Destination Address field that VARA HF, in this mode, is summarily replacing with "APVARA".

See Chapter 10 of aprs101.pdf, specifically the "Mic-E Destination Address Field" definition. Then try interpreting "APVARA" into that specification and see what you get for the latitude.

[na7q]

It does not replace anything for compressed packets. Nothing troubling about it.

Compressed packets send the entire coordinate in the payload, so you are correct in your statement.

But the real issue is with Mic-E-encoded packets where a portion of the coordinates is formatted into the Destination Address field that VARA HF, in this mode, is summarily replacing with "APVARA".

See Chapter 10 of aprs101.pdf, specifically the "Mic-E Destination Address Field" definition. Then try interpreting "APVARA" into that specification and see what you get for the latitude.

Neither types were modified.

This issue is now resolved in the next release of VARA. Case closed.

I intend to release something else under the APVARA tocall.