[Xastir] strange stuff on stdout

[Jason Winningham]

On Sep 1, 2006, at 10:01 AM, Curt, WE7U wrote:

> Any idea what we might want?

I've got some ideas.

First, the RDF report as a separate type of DF report is a new idea for 
me.  I like it, and think xastir would do well to parse and display it. 
  It would probably be fairly simple to add an Agrelo DDF unit to an old 
TNC in much the same way one can add a GPS to an old TNC to get a raw 
NMEA position report.  One would still need to allow for the relative 
vs. true bearing difference.

For an actual RDF device type in xastir, one would want some history 
(last X reports) for triangulation purposes.  You want history either 
for a trend, in the case of tracking a moving object, or for 
triangulation, in case you're tracking alone.

I would think you would also want the capability of having Y reports as 
objects being transmitted (using the standard  decay algorithm, 
naturally) for some "on the air" history.  I certainly envision this 
number being less than the total number of "history" reports.

Both these values X and Y would need to be configured as part of the 
device settings.

For some objects that stream DF reports continuously, we need to be 
able to push a button and say "use that one".  This could be done with 
an external pushbutton switch, either incorporated into the DF unit or 
as simple as a momentary-on in the serial TX line (think I read that 
one on Bob's web site).

Another issue is bearing, including relative vs. true vs. magnetic 
bearing.  Xastir would need support in the existing GPS code to extract 
the bearing from the NMEA data.  I've done a small amount of testing 
and my Garmin MAP60 does a very good job of keeping a true bearing 
under conditions of slow/no movement, even though it does not have a 
magnetic compass.  Of course, this would vary from model to model - my 
old Trimble SV6 always drops back to a heading of 0 when it stops.  For 
the more stupid units, the xastir "compass" code may need to implement 
a sane algorithm of keeping the bearing based on bearing at last speed 
above some value.  Some GPS units also have a magnetic compass.  I have 
no idea if those units with a magnetic compass do a declination 
adjustment. (they could, since they know where you are, right?)

Xastir _may_ also need to provide support for an electronic compass 
device.  I know there are some high end units out there, and used to be 
some more basic units (the PicoDopp guy used to sell one).  There are 
also components available for one to construct one.  (Hey Scott, if 
you're reading, how 'bout a magnetic compass with a serial interface 
when you need a break from OT/T2 work? :)

I have dealt with this issue for testing purposes by using gpsd to 
share the GPS between xastir and my perl DF glue.

I would also suggest (in fact, been meaning to add it to the feature 
request list) an option so that DF objects can be rendered on the 
display with a single line indicating the bearing of the report.  It's 
nice to have the accuracy of the beam width indicated, but if you have 
a bunch of reports it gets pretty messy and hard to read.

It would be _very_ nice to have a way to enter a DF object more easily. 
One big help would be a button that says "use my current position" 
(e.g., right above the "calc" button on the existing object screen) so 
I don't have to figure out where I am and then enter those numbers.  
Ideally, my antenna type (omni vs. beam), beam width and desire to use 
the current GPS position could be stored as a default so I don't have 
to type them in every time.  Actually, this is an improvement to 
existing object handling, and not specific to DF device interfacing.

For some pie-in-the-sky type features, maybe some way to automatically 
account for declination for those who use magnetic compasses?  I never 
understood the big deal about magnetic declination - around here it 
typically runs 0.5 to 1.5 degrees, which is less that the error in my 
measurements.  Then I made a backpacking trip to NM, where it was 12 
degrees - the importance became quite clear at that point. (:

Another "it sure would be nice" feature is a DF indicator on the map, 
that updates frequently (1Hz) to take the place of an external DF 
display.  We'd need a software "plop an object here" button, in this 
case.

Of course, another great feature would be code to calculate an 
estimated position based on existing reports, both my own and any 
received externally.  I think a previous discussion on xastir and 
direction finding had a fair amount to say on this subject.

I could probably think of more, but it's lunch time and I skipped 
breakfast this morning.

-Jason
kg4wsv