Order Tray | Contact Us | Home | SIG Lists

[aprssig] APRS DF reporting

Robert Bruninga bruninga at usna.edu
Tue Nov 21 20:42:44 UTC 2006


The Agrelo format mentioned below is a standard interface for
APRS,
But it is never transmitted on the air.  It is the interface
between the Doppler DF unit and the PC that is running APRS
(with DF code in it).  The APRS software then parses out the DF
info and the interleaved GPS info and then when appropriate,
sends the combined single packet containing the DF unit's:
LAT/LONG/CSE and SPEED
DF bearing 
Signal quality 
Range of the bearing line 

All of these are "smartened-up" by the APRS software so that it
is not just regurgitating raw data, but is applying some kind of
smarts (even a human
"send now" button) that decides if the DF report seems valid and
worth putting out on the air.  This should be very easy to do in
the PIC especially if you use the "send-now" button.

For automatic unattended fixed sites, then some kind of
weighting function should be applied to make sure the report
seems reasonable compared to pervious values... Etc.   Bob,
WB4APR

> -----Original Message-----
> From: aprssig-bounces at lists.tapr.org 
> [mailto:aprssig-bounces at lists.tapr.org] On Behalf Of R.
Simmons
> Sent: Tuesday, November 21, 2006 1:52 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] APRS DF reporting
> 
> 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
> >
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
> 





More information about the aprssig mailing list