[aprssig] case sensitivity of NSWE in posit reports

[Robert Bruninga]

Wow!
Thanks for checking.  But this goes way way back.  Does anyone
then remember which client or app (that can never be changed) is
the one that was preventing use of these two flags?    I just
checked the D700 and it is OK with lower case, and other than
Uiview and the Kenwoods, I don't know of any other legacy
systems that cannot be changed.

Maybe the person that originally tested it and reported it as
not possible simply screwed up the test?

So what we are talking about here is WHICH clients (if any)
cannot correctly decode this posit:

!1234.56n/01234.56w-

Where the correct spec TX requirement has been:

!1234.56N/01234.56W-

Thanks
Bob, WB4APR


> -----Original Message-----
> From: aprssig-bounces at tapr.org 
> [mailto:aprssig-bounces at tapr.org] On Behalf Of Keith VE7GDH
> Sent: Wednesday, December 29, 2010 3:52 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] case sensitivity of NSWE in posit
reports
> 
> Bob WB4APR wrote...
> 
> > 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 UI-View...
> 
> That is strange. I just generated an object using lower case 
> n and w in
> the lat / long. UI-View didn't have any trouble displaying the
object.
> Just to give it a bit more of a workout, I changed the script
so that
> it generated a regular position report instead of an object.
Again,
> UI-View displayed it OK.
> 
> If anyone wants to look at the object and position report that
I used,
> the name of the object was 123456789. I originally used the
same
> name for the "callsign" for the position report. Just to cover
all the
> bases, I changed it to VE7GDH-13 and did it again. Ignore the
few
> syntax errors while I was fiddling with it. It still displayed
OK in
> UI-View with lower case n & w used in the lat / long. Another
myth
> bytes the dust. I don't know who started the rumour, but it
doesn't
> appear to be true.
> 
> > so until UI-View is replaced completely, we cannot use those
bits.
> 
> With all due respect to authors who are designing APRS 
> clients, this may
> be a long time in coming. I can't see all UI-View users just 
> giving the
> program the heave ho en masse... at least not unless something
in the
> APRS spec is changed to make it incompatible. All other APRS
clients
> would have to be updated too, but at least if the authors of 
> those clients
> were still actively developing the program, that shouldn't be 
> a problem.
> A lot of hardware might have to be updated too, but many of
them would
> just require a firmware update. I know there may eventually 
> be a compelling
> reason to stop using UI-View, but it  would likely take a 
> conscious effort
> to change the spec in such a way to make this a requirement,
and APRS
> would likely be in pretty in chaos during the transition.
> 
> On the other hand, if we are going to have chaos, we could 
> all just move
> to OpenTRAC. It would give us everything that APRS does now,
but with
> almost unlimited expansion for additional symbols and new 
> ideas. It would
> be a major change, but sometimes major changes are needed.
Either we
> stick with what we have now, which includes UI-View, or we
move
> forward. It's amazing what has been done within the 
> constraints of using
> 20+ year old hardware, and some newer equipment that has
mostly had
> to live within the same constraints of that 20+ year old
equipment.
> 
> 73 es cul - Keith VE7GDH
> --
> "I may be lost, but I know exactly where I am!"
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>