[aprssig] Voice Repeater Frequency Objects

Robert Bruninga bruninga at usna.edu
Wed Sep 17 18:47:48 CDT 2008

>> The APRS spec was printed in 2000.  Yet 
>> the APRS1.1 addendum in 2004 revolutionized 
>> the APRS network with the New-N Paradigm
> The New-N paradigm is a layer 2 convention for 
> source routing of AX.25 traffic; it is an issue 
> completely unrelated to the format of an APRS
> packet in an AX.25 payload.

For proper APRS operation and consistent network performance,
certain standards need to be used by all participants.  Adding
the New-N Paradigm as a standard in APRS1.1 for consistent
operation of APRS on a nationwide or worldwide basis was very
important and very successful.

>> After much discussion on the APRSSSIG over many 
>> months, the format of the [new] frequency [standard]
>> was hammered out and documented in the
>> www.aprs.org/APRS12.html addendum.
> Bob, this is your personal web site, and the 
> contents have not been formally adopted by the 
> community, or even seriously vetted for
> technical inconsistencies and backwards 
> compatibility issues such as the one we are 
> discussing.

We do the best we can.  We post any proposed new capabilities
here on the APRSSIG for discussion and critique.  We take test
results, feedback, suggestions, comments and roll them back in
to modify the proposals until the best working solution can be
found.  Then we post it back on the APRSSIG and the APRS12 web
page above.

>> It is good that we have discovered this 
>> minor quirk of XASTIR and possibly other devices
> Sorry, the only quirk I see is with a new 
> piece of Kenwood hardware.

THen it does not appear that you understand the issue as I have
detailed it in my previous posting.  The problem is the *forced*
insertion by XASTIR of /Axxxxxx at the beginning of the comment
field while *forcing* a right-shift of the previously formatted
user comment, that clearly violates the flexibiilty designed
into the /A=XXXX format that allows it to be anywhere so that
the user can use that location for higher priority information.

> How much trouble would it be to apply 
> the same terminology to Tnnn (i.e. "anywhere 
> in the comment") so that it does not break the
> original formally adopted spec as well as the
> vast majority of stations using altitude in a 
> way that meets that spec? 

What is breaking the "spec" is XASTIR placing an arbitrary
limitation on the use of the comment field by forcing the
/A=xxxxx in only the beginning of the string and then corrupting
the original intent and placement of the users comment string
without his control.

> The D710 has field upgradable firmware so a 
> change could be pushed out to this device that 
> represents a tiny handful of devices on the APRS 
> network, instead of declaring a large number of 
> stations on the network broken because the 
> D710 can't handle it.

Its not a problem in the D710.  It is a problem in XASTIR which
is software and can easily be fixed.  The problem in XASTIR is
the violation of the flexibility given to the placement of the
/A=XXXXXX in the spec. It is XASTIR that has placed an added
limitation on the designed/intended flexibility of the /A=xxxxx
by forcing it in a location that then corrupts the following

> Maybe the reason we don't see more APRS radios 
> is because the vendors don't want to deal with 
> trying to meet such ill defined and amorphous
> "standards"?

Which is why I invest hours evey day trying to keep the spec
current and to find and document these minor issues and get them
fixed so that people can find consistent results when
implementing the spec.

The /A=xxxxx format was *specifically* and *intentionally*
defined in the spec to be able to be placed anywhere in the
packet, just to *avoid* this very problem of conflicts with the
first field of the comment string which can have other meanings.
So in this case, it is XASTIR that has placed the additional
(non spec) limitation on the location of the /A=xxxxx string by
forcing it at the beginning and not giving the user the option
of having it at the end to de-conflict with other data that
may/should/might go at the beginning.


More information about the aprssig mailing list