[aprssig] APRS DF reporting

[R. Simmons]

To all... ( reply )

 Thanks for the responses. Yes, the intention is to generate tones and PTT
so it could interface with a conventional radio, and send APRS compatible
messages. I believe the PicoDopp in its present state can drive an external
TNC to do APRS DF reporting, but ( again ) I'm not involved in this culture.
Some folks have done it, I am told. Adding a switch to manually enable
reporting would be easy, and would require no changes in present design.

 I have been looking at the public TNC code by Bob Ball ( et. al. ) in an
article published in QEX a couple of years ago, to get familiar with the
requirements. I have trimmed it down significantly and originally I intended
to adapt it to this task, but I now think it might be simpler for me to just
write my own code. Also looked at the APRS spec and the AX.25 spec. Aside
from the CRC calculation routine ( which I suppose I can "rob" from Bob
Ball's ( et. al. ) code, worst case ) I think I understand how to do it all.

 I agree, operator control of DF reporting is worthwhile. Conversely, a lot
of interference comes from "kerchunkers" who are not around long enough to
formulate an opinion about validity of DF data, so I'll leave automatic
reporting as a user-selectable option.  Thinking also of having selectable
"quiet time" intervals ( = search for clear channel ) so multiple units can
operate without crashing packets. ( that would require some co-ordination
among users, though )

 The PicoDopp DF outputs a standard Agrello message string at 4800 baud, (
quality fixed = 7 ) with an occasional GPS message tossed in, if a GPS is
connected. The two messages are merged into a single output RS232 data
stream, so no switching or dual-port arrangement is required. The PicoDopp
repeats GPRMC messages if found. If not found in 8 seconds, it will also
repeat GPGGA ( if found ) and GPVTG. ( if found ) Other GPS messages are not
repeated. If GPRMC later becomes available, it will switch back to that. (
GPRMC = preferred message to relay )

 Every 3rd GPS message is repeated, to allow more RS232 time for DF
messages. GPS messages are not checked at all... if detected,  they are
relayed "verbatim", and not used at all by the DF. ( relative bearings are
reported by the DF )

 No DF messages are reported unless the DF detects sufficient Doppler "tone"
in the DF reciever audio to indicate a signal is present on the channel. GPS
messages ( if available ) are relayed at all times. ( every 3rd message )

 For those who might want to dialogue "off-forum", my e-mail is
pelican2 at silcom.com

 The PicoDopp is here :

http://www.silcom.com/~pelican2/PicoDopp/PICODOPP.htm

 Several folks have "networked" the PicoDopp by various means, ( LANs,
internet etc. ) but they have not been forthcoming with descriptions of how
they did that. ( as I had hoped they would )

 Thanks to all for the response, will await further comments.

regards / Bob S.


----- Original Message -----
From: "R. Simmons" <pelican2 at silcom.com>
To: <aprssig at lists.tapr.org>
Sent: Tuesday, November 21, 2006 9:27 AM
Subject: [aprssig] APRS DF reporting


> To all... I'm a new member and have no prior experience with APRS or any
> packet modes, but I am considering something that might interest folks
here.
> I'm Bob Simmons, ( WB6EYV ) and I make the PicoDopp DF, which is a DSP
> Doppler DF with RS232 output and a GPS input.
>
>  I recently had cause to investigate packet and APRS technology for a
> potential customer, and I now think I could add automatic APRS DF
reporting
> to the PicoDopp, without too much trouble. ( or offer it as a separate
> optional board ) It would have a PTT output, an audio input to check for
> channel = busy, and a tone output. I would also have to create an IBM
> program to set the semi-static variables ( like the user's call sign,
> destination address, etc. ) which would be stored in EE memory of the PIC
> chip, and which would not change during normal operation. It wouldn't be
> terribly easy to do all this, but I think also not terribly hard.
>
>  I want to solicit opinions and comments on this, and suggestions for
> features. I don't want to turn this into a major engineering effort, but
if
> there is an interest out there for such a beast, I probably will pursue
it.
> Offers to critique and test the design ( if I proceed ) would also be
> appreciated.
>
>  TNX DE WB6EYV
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>