[aprssig] "station which heard ... directly on the radio"

[Pete Loveall AE5PL Lists]

See below...

> -----Original Message-----
> From: Georg Lukas
> Sent: Tuesday, May 21, 2013 9:06 AM
> 
> * Pete Loveall AE5PL Lists <hamlists at ametx.com> [2013-05-21 15:40]:
> > Both the TNC2 and AEA formats do not permit -0 as a SSID [...]
> 
> It was really hard to find anything resembling a specification for TNC-2/AEA.
> The closest thing I got into my hands is APRS101.pdf, where it is stated on
> PDF page 94 (chapter 17):
> 
>     "In both formats, the SSID may be omitted if it is –0."
> 
> I read it as a permission to use both "DO1GL-0" and "DO1GL", even though
> most APRS-IS software breaks on the former one, so I would always
> implement the latter form.

While your interpretation of APRS101.pdf may be correct, in point of fact TNCs (both AEA and those that implement TNC2) have never shown the -0 SSID in their monitor mode nor accepted it in converse mode.  Yes, your assumption to always implement with the -0 is compatible with all software.

> > While showing all callsign-SSIDs with an asterisk that have the
> > digipeated bit set won't generally break anything, it is also not
> > compliant with the TNC2 and AEA formats.
> 
> This is true, according to APRS101.pdf. However, providing compliant
> behavior when converting AX.25 to APRS-IS requires a two-pass solution to
> look for the last digi element with the H-bit set and destroys information on
> the way (which of the previos digi H-bits were actually set?), so a lossless
> conversion back to AX.25 is not possible any more.

It never is "lossless" if you are converting to TNC2 converse mode format.  Therefore, you must either convert for APRS (command byte, PID, etc. are dropped) or you leave in AX.25 format for digipeating.  APRS-IS is not an AX.25 transport, it is an APRS transport and should not be assumed to present more information than originally defined.

> A 1:1 mapping is easier to implement and seems to be accepted by the
> relevant applications (like, aprs.fi). Therefore I would actually propose
> changing the default behavior to map H-bit of digis 1:1 to the "*" field. Of
> course, this shall not affect source or dstcall.

May be "easier to implement" and "accepted by the relevant" applications (-your- determination that a single Internet application is all "relevant" applications) but is not necessarily accepted by many other applications and may not be accepted by many TNCs (how the spec started).  I can state as fact that should you inject a packet into APRS-IS with asterisks throughout the path, they will be stripped out by most servers.  APRS "packets" in TNC2/AEA converse mode format are -not- 1:1 mapped to AX.25, never have been, and never can be with TNC2/AEA converse mode representation.

Both TNC2 and AEA converse mode representations predate APRS (hence their use in the spec).  Random changes such as these to suit some developer's concept of "easy" is still changing the spec even if it is "only" changing a de facto implementation assumed to be generally accepted by the spec writers.

73,

Pete Loveall AE5PL
pete at ae5pl dot net