[aprssig] The best resolution of ---

[Scott Miller]

> Honestly - APRS is fun, BUT I think we MAY need to develop a NEW spec
> - let's call it NAPRS, that does NOT worry about
> backwards compatibility with APRS - the "digital, HDTV" version of
> APRS that incorporates all the "lessons learned" in developing and
> using APRS over the years - maybe it would include such things as
> uncertainty circles, geoid type (NAD83, WGS84, UTM, etc - let the
> client do the translating = or not - some folks won't care about the
> small difference between say, wgs84 and nad83)

That's exactly what OpenTRAC is trying to do.  See http://www.opentrac.org/.
Granted, work has been slow on the spec lately.  I've been busy with
hardware projects, and I want to have more capable hardware on the air to
test some aspects of the protocol before I go too much further with it.

> Now, I'm NOT saying "lets obsolete APRS" - far from it - in fact, I
> would say that the BEST place to stick this is on UHF or HIGHER - 1.2
> gig anyone? and run intelligent gateways between then current APRS

>From a protocol perspective that part doesn't really matter.  I'm trying to
stay away from layer 1 issues at the moment.  I *would* like to see
something better than Bell 202 for VHF - maybe MSK with robust FEC to help
counter mobile flutter problems.  That's not really my strong point, though.

> Let's see a NEW spec, based on the processing power of say a $300 year
> 2006 system - say, 2 GHz, 256 meg, 40 Gig HD etc - not that 
> we necessarily have to
> go that far - and if it can be done in less, fine

I'm hoping to do a lot of that with a low-power ARM system.  But for now, a
$300 small form factor PC will run all sorts of stuff.  I'd love to see a
radio interface that fits in either a PCI slot or 3.5" drive bay to turn
these PCs into slick, single-box network controllers.

> Let's not worry about 1 FOOT precision - lets figure Galileo goes
> live, the second "C2" signal goes live, we have someone who plays with
> stuff - lets figure even survey grade - sub CM

The OpenTRAC spec calls for a 32-bit integer lat/lon format, which works out
to a couple of centimeters, worst case.  A full fix at that resolution takes
8 bytes.

> Think about it - what could we do WITH A CLEAN SLATE?  Maybe things
> like partial position packets (a friend did that with a commercial
> APRS like device - cell phone data packets are small)  Store and

OpenTRAC's supposed to be modular, composed of a bunch of data elements so
that you can pick and choose which parts go out with each transmission.

> forward routing (learn what we can from the old days of email and even
> modern IP packet - some messages unicast, some multicast, some
> broadcast - as needed - clients acting as intelligent routers - maybe
> even ad-hoc, built on the fly routing tables)

That's one of the main goals that drove me to start the spec, actually.
Mostly for SAR use - team goes out of contact with the CP, another team
crosses a ridge and stores all of their position/track data since last
contact with the CP, and relays it back to the CP when they cross over the
ridge again.  Not real-time, but better than not having any data.  Plus ad
hoc routing for when a path IS available.  That's why I need more capable
hardware - all that takes RAM.

> Maybe the ability to say "I want WA2GUG-2, KG2V-15, and 
> KC2MMI-15 to get
>  my position packets, I want my weather to get routed to the internet
> and then to the NWS and that's it" - other folks can listen - but the

If you want to take a crack at designing a consistent destination scheme
that handles named stations, areas, and groups, go for it!  That's been
lacking from the spec and it's still bugging me.  It needs to be UNIFORM -
you use the same format to address a station-to-station message, to set an
area bulletin, etc.  We want to avoid at all costs the ad-hockery of APRS.
I lost count of how many ways there are to encode a position in APRS, and
how many things you've got to parse to figure out where the position portion
IS.  In OpenTRAC, you get a data element that defines position, and use that
format for everything that needs a position.  It's identified by a tag, and
includes an element length.  Any element you don't understand, you can still
skip because you know where the next one starts.

> Just ideas - good, bad, or indifferent

Good ideas, but daunting to take on.  What exists of OpenTRAC so far isn't
perfect by any means, but it's a start.  I'm open to suggestions, and it
hasn't been so widely deployed that it's not possible to change core
features still.

Scott
N1VG