[aprssig] APRS DF reporting

[Robert Bruninga]

>... and I now think I could add automatic APRS DF...ing
>
> ...it would have a PTT output, an audio input to 
> check for channel = busy, and a tone output. 

I assume the "tone ouptut" is an AX.25 packet in APRS DF format?

If so, then that would be fantastic.  Please read the original
APRS DF text file, since DF was one of the fundamental aspects
of APRS from the beginning (although some programs never
implemented that part of the protocol)..  See the APRS DF page:
http://www.ew.usna.edu/~bruninga/dfing.html

The concept of automatic DF reporting on APRS worked very well
with one very important lesson learned.  And that was that the
human had to be in the loop.  Ths is simply because there is no
Doppler DF algorithm that is perfect, there will always be
reflections, and erroneous data at times.  And the worst thing
on APRS is -BAD-DATA-..  BAD-DATA is much-much worse than no
data.

So we found that with the automatic Doppler DF interfaces, that
the only way to have any value to the data that was transmitted
to the APRS system was to put a PUSH-TO-SEND momentary button
for the operator.  Only the gray-matter of the operator has the
full experience and knowledge, and situational awareness to know
when his Doppler DF was giving him a good vector in the actual
direction of the signal, or when it was looking at a reflection.

Again, just one bad data heading can wipe out the value the good
ones because the other 99 APRS users only see the "data" they
have no clue about all the nuances that the DF driver is aware
of...  So as long as your system has a button on it that says
"send", then I think it will be great.  I know this takes a lot
of the steam out of the thrill of "automating" everything with a
PIC, but the cost of BAD-DATA is just too high on an APRS
network, to allow unfettered data to pour onto it.

Anyway, that is how it looks from this end...
Bob
WB4APR