| |
ZL3AI > APRDIG 23.11.06 04:52l 245 Lines 10228 Bytes #999 (0) @ WW
BID : 9116-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 29 #19, 1/3
Path: DB0FHN<DB0FOR<DB0SIF<DB0EA<DB0RES<TU5EX<7M3TJZ<CX2SA<VK2DOT<ZL2BAU
Sent: 061123/0336Z @:ZL2BAU.#79.NZL.OC #:16549 [Waimate] $:9116-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Today's Topics:
1. RE: APRS DF reporting (Robert Bruninga)
2. Re: APRS DF reporting (R. Simmons)
3. RE: APRS DF reporting (scott_at_opentrac.org)
4. RE: APRS DF reporting (Curt, WE7U)
5. Re: APRS DF reporting (Jason Winningham)
6. RE: APRS DF reporting (Robert Bruninga)
7. RE: APRS DF reporting (scott_at_opentrac.org)
8. RE: [Kenwood_TH-D7] TH-D7 Power up problem (Herb Gerhardt)
9. Re: Opinions for a small ultra compact notebook PC? (carl szentes)
10. RE: APRS DF reporting (Robert Bruninga)
11. Re: APRS DF reporting (Jason Winningham)
12. Re: APRS DF reporting (Bob Bruninga )
13. Re: APRS DF reporting (Wes Johnston, AI4PX)
14. Re: APRS DF reporting (R. Simmons)
----------------------------------------------------------------------
Message: 1
Date: Tue, 21 Nov 2006 13:01:18 -0500
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] APRS DF reporting
>... 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
------------------------------
Message: 2
Date: Tue, 21 Nov 2006 10:52:25 -0800
From: "R. Simmons" <pelican2_at_silcom.com>
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.
------------------------------
Message: 3
Date: Tue, 21 Nov 2006 11:56:21 -0800
From: <scott_at_opentrac.org>
Subject: RE: [aprssig] APRS DF reporting
>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.
You might read over my page at <http://n1vg.net/packet> for some of that.
The FCS algorithm in particular - I had a hard time myself finding the right
one. Too many bad examples out there.
If you do implement it from scratch, please do us all a favor and don't
transmit raw NMEA strings for position reports. We've got too many dumb
devices wasting bandwidth that way already.
My offer stands for the OpenTracker option - it'd cost under $10 in parts to
add it to your board if you're so inclined. And the code is open source,
under the BSD license.
>The PicoDopp DF outputs a standard Agrello message string at 4800 baud, (
>quality fixed = 7 ) with an occasional GPS message tossed in,
Ok, I found a description of the format. It's going to look something like
this, right?
%143/7
That should be easy enough to recognize automatically. I'm not sure what I
ought to report in the APRS string for number of hits or range. I suppose
range could be a user-selectable parameter based on empirical knowledge of
the system's sensitivity, but it doesn't seem to make much sense when you
don't know the transmitter power.
Accounting for the interleaved NMEA data might be harder. Hmm.. maybe I'll
just merge the Agrelo parser into the NMEA parser. Might make things
simpler. I might even be able to fit the code in the OpenTracker without
dropping other features, if I can find a few bytes of RAM to hold the
bearing.
I'd still like some real-world Agrelo data, from ANY sort of DF unit, if
anyone's got some or could capture some easily.
Scott
N1VG
------------------------------
Message: 4
Date: Tue, 21 Nov 2006 12:05:50 -0800 (PST)
From: "Curt, WE7U" <archer_at_eskimo.com>
Subject: RE: [aprssig] APRS DF reporting
On Tue, 21 Nov 2006 scott_at_opentrac.org wrote:
>I'd still like some real-world Agrelo data, from ANY sort of DF unit, if
>anyone's got some or could capture some easily.
Me too.
--
Curt, WE7U. APRS Client Comparisons: 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!"
------------------------------
Message: 5
Date: Tue, 21 Nov 2006 14:16:08 -0600
From: Jason Winningham <jdw_at_eng.uah.edu>
Subject: Re: [aprssig] APRS DF reporting
On Nov 21, 2006, at 11:27 AM, R. Simmons wrote:
>I would also have to create an IBM program to set the semi-static variables
As one of the non-wintel users, I'd rather see the config program run on
the microcontroller, which is configured via a standard RS232 terminal
application. That's a relatively minor nit to pick, though.
I've done a bit of looking at this problem myself, mostly because I'd like
to have semi-automatic APRS df reports generated. Issues for a mobile
array include resolving relative bearing reported by the DF unit with the
vehicle's true (or magnetic) bearing. I've managed this by using a GPS
with a relatively sane bearing algorithm (until you put the vehicle in
reverse), but a GPS with a compass or a straight electronic compass would
be better.
Also, There are small issues like how many objects to use - if you're one
of a team of hunters, maybe the last report only is good enough, but if
you're alone you want several reports to assist with triangulation.
I suspect custom OT firmware would be useful, but you'd probably need to
merge DF and GPS/compass rs232 streams to talk to the OT's single serial
port. The T2 might be a better choice, if a little more expensive, because
it has more code space and an extra serial port.
Come to think of it, Scott, you could write this in to accept any Agrelo
(sp?) interface DF device; use a digital input to trigger the TX of a DF
object, with other DF parameters configured as usual.
-Jason
kg4wsv
------------------------------
Read previous mail | Read next mail
| |
