[aprssig] case sensitivity of NSWE in posit reports

[Robert Bruninga]

Yes, those two bits NSEW or "nsew" are the only two bits we have
that are available for carrying additional info in an APRS
packet that are backwards compatible with most existing systems.
But they are NOT with Uiview, so until Uiview is replaced
completely, we cannot use those bits.

But ALL developers should RECEIVE either case, but only TRANSMIT
uppercase IAW the spec.   This also applies to the "MHz" in the
frequency spec.  Accept MHZ but only transmit MHz.  This allows
for acceptance of manuallyl entered frequencies where the human
is not so careful with case.

Bob, WB4APR


> -----Original Message-----
> From: aprssig-bounces at tapr.org 
> [mailto:aprssig-bounces at tapr.org] On Behalf Of Lynn W. 
> Deffenbaugh (Mr)
> Sent: Wednesday, December 29, 2010 7:42 AM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] case sensitivity of NSWE in posit
reports
> 
> VK6 UFO wrote:
> > Couple of questions of the nit-picking variety.
> 
> As a software developer, one of my mantras is "all nits need 
> to be picked!".
> 
> > Is it fair to say that an APRS uncompressed position report 
> should (or
> > must?) use N,S,W and E (capitals) to comply with APRS 
> specs, but APRS
> > applications should be prepared to expect n,s,w and e from
APRS
> > stations anyway? Is it possible that future revisions of the
APRS
> > specification will use the case for some purpose in the 
> same way as it
> > was originally proposed for the 'operator present' bit?
> 
> See http://www.aprs.org/aprs12/operator-bit.txt  Apparently
lower case
> has been proposed for some things, but UI-View breaks.  I can 
> only speak
> authoritatively for my own APRSISCE/32 and it explicitly
upcases the
> NSWE before checking it for validity.  I call that defensive
coding
> until some spec comes out that puts meaning onto the case of
those 2
> characters (NS or EW).
> 
> > Is it valid for a station reporting weather to use a symbol
that is
> > not normally recognised as a weather station (eg is it OK to
use a
> > digipeater symbol with a wx report?) Will some APRS 
> applications break
> > if this happens? Should the wx be decoded and used anyway 
> or should it
> > slip through as a comment?
> 
> Give the vast amount of variability in user-specified
comments, my own
> client only parses weather data if it is explicitly weather 
> by data-type
> (#, *, ., and _)  or uses a weather station symbol (_).  I 've
been
> looser in my comment string interpretation in other areas
(like the
> /A=), but ended up tightening up my parser as it had strange
results
> when parsing through the world feed of packet variability.
> 
> So, since the spec says "weather must use a weather symbol", 
> that's the
> only place I try to interpret weather from.
> 
> As always, YMMV, and I'm only relating my implementation
choices and
> reasoning, not attempting to establish a standard here.
> 
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and
Win32
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>