[Xastir-dev] xastir as pvd

[Curt Mills]

On Wed, 14 Apr 2004, Owen DeLong wrote:

> Ah... I misunderstood your desire.  I thought you were trying to use XASTIR
> as a MFD within the flight simulator.  Give what you have now described...
>
> A couple of questions come to mind... This sounds like a perfect
> fit with the internet APRS formats, except for your insistance on UDP.
> Is there a reason you can't do TCP?
>
> If you can do TCP, then, you could spit out APRS format messages (basically
> NMEA with an AX25 wrapper), and you'd have callsign, altitude, course,
> speed,
> and just about any data you wanted.
>
> I think you can do it with minimal additional code in XASTIR.
>
> I think if you can do TCP and pretend to be an internet APRS feed, you
> then only need to add functionality we already want in XASTIR, but haven't
> had time to implement:
>
> 	Symbol Rotation
> 	Alternate Symbol Library
> 	Over-the-air Symbol definition
>
> I think if you were to add those features to the mainline XASTIR code, and,
> code up your end to spit out TCP APRS Daemon format stuff, you'd be done
> and we'd all be happy.
>
> Someone tell me what I'm missing here.

I'm sure a lot of stuff, but I can't think of any!

That's how I see it as well.  Perhaps if the remote end only does
UDP then you could create a shim program that provides a TCP
listening socket for Xastir to connect to.  That way no changes to
Xastir's main processing loops or interfaces would be required.

You said the format wasn't all that critical, so perhaps the type of
connection isn't either?  If the remote end could just provide just
a listening socket, you'd be in business already.  Send APRS format
packets across, then implement two or three of the items mentioned
above and you'd be all set.

Do you need high accuracy, or is DD MM.MM format enough?  If you
need more, you can go to APRS compressed posits, but stay away from
NMEA posits unless you plan on sending additional packets (of a
different format) just to identify the symbols and additional items.

The symbol rotation should be able to be tweaked internally without
messing with different packets.  We usually have the direction
within one or two degrees, depending on the transmitted packet.
That one will benefit everybody, so it's not an issue to implement
it, except perhaps for extra CPU to do the rotations?

The alternate symbol library is the biggie.  This would benefit
everybody if we did it correctly.  If it's done quickly, without
much thought, it might not benefit anybody.

Do you absolutely need additional symbols at this point, or are the
small/large aircraft and the helo symbols that we currently have
adequate, if they can be rotated in finer increments?

-- 
Curt, WE7U.				archer at eskimo dot com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"