| |
ZL3AI > APRDIG 06.05.07 05:03l 147 Lines 5619 Bytes #999 (0) @ WW
BID : 10116-ZL3AI
Read: GUEST
Subj: [APRSSIG] Vol 34 #26, 4/4
Path: DB0FHN<DB0NOE<DB0GAP<DB0FSG<I4UKI<IR0UCI<I0TVL<DK0WUE<7M3TJZ<ZL2BAU
Sent: 070506/0249Z @:ZL2BAU.#79.NZL.OC #:46483 [Waimate] $:10116-ZL3AI
From: ZL3AI@ZL2BAU.#79.NZL.OC
To : APRDIG@WW
Message: 31
Date: Thu, 26 Apr 2007 12:30:37 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Signal Locator WEB page
>I'm not sure I see what the web has to do with it.
>Every time I've been DFing I was mobile, not sitting
>in front of the computer surfing the web.
Problem is, that's where most folks are, and it is like picking hen's teeth
to get anyone to go DF when needed. And then you only get a few dedicated
individuals, maybe 1% of ham radio participating. I'd rather accumulate a
little bit of info out of a whole lot of data points, than to always be
dependent on the 3 people out of 300 that may or may not be available when
the need arises.
>Why not use an APRS client that's smart enough to create and
>understand DF objects?
Because the common denominator in APRS has defaulted to Uiview which is all
many people ever see of APRS, and to do Dfing or even to see the simplest
of APRS information and that is Antenn-Height-Gain ranges, you have to
locate and run add-ons. This put's us back to square-one, in that only 3
out of 300 can see the signal contours and omni-DF abilities of APRS.
The signal-strength technique works wonders with lots of little inputs from
people with nothing but a radio and omni antenna. This way, everyone can
participate, and with a browser based system, everyone cal also see the
accumulated result.
Of course, the challenge is getting some hams to understand their
subjective Height-above-average-terrain...
WB4APR, Bob
------------------------------
Message: 32
Date: Thu, 26 Apr 2007 11:31:19 -0500
From: Ron Tonneson <ron.tonneson_at_gmail.com>
Subject: Re: [aprssig] RE: "Local Info" confusion...
Are the object examples at
Thanks,
Ron - K0QVF
Robert Bruninga wrote:
>Keith, Its not a UIDIGI ROM issue. Its Uiview that interprets
>any source of a 3rd party packet as being an Igate. And since
>we initially suggested using 3rd party packets for these
>objects, this began to cover the map in Uiview with digipeaters
>that then were marked as Igates.
>
>So that is why we are abandoning 3rd party format and now
>receommending the original APRS object format instead. Hope
>that helps. Bob
>
>>-----Original Message-----
>>>UI-View will display the digipeater on the map with a
>>>star and an S... As soon as UI-View receives a [3rd
>>>party voice-reepeater-object packet from that digi, then
>>>Uiview] highlighs [the digi] with the square box
>>>around it... [indicating an Igate]
------------------------------
Message: 33
Date: Thu, 26 Apr 2007 12:47:51 -0400
From: "Robert Bruninga" <bruninga_at_usna.edu>
Subject: RE: [aprssig] Signal Locator WEB page
>>Please see the OMNI-Dfin technique in APRS:
>>http://www.ew.usna.edu/~bruninga/dfing.html
>
>One could do this with an Xastir instance hooked to
>an internet feed, set up to do snapshots every XX
>minutes. Feed that snapshot to an Apache web server
>and you've got it.
That would do it nicely. But the final system would need to be able to let
the browser viewer to zoom anywhere in the world to select which particular
signal-search is in progress.
Actually, I think this would be a great feature on FINDU. All this CGI
needs to do is:
1) Normal APRS maping/placment of stns/objs (like FINDU)
2) Browser access to translate and zoom (like FINDU)
2) The ability to Display PHG circles around selected stations
3) On any OMNI-DF object or station, draw the DFS circle and color it
according to the reported subjective signal strength. It would be ideal if
this coloring could be transparent.
I couldn't use transparency in APRSdos, but I have a routine that sorts all
DFS circles and then draws the darker weaker signal-circles first and then
drawing the smaller and brighter circles last. This way, the overlaps are
easy to see and clearly indicate the highest probability of the signal
source.
Steve says he cannot draw circles on Google maps, and that is OK. In fact,
one only needs the crudest maps for these plots, because it is not the
real-earth/map domain that we are plotting, but just areas of probability.
Once one can visually interpret these overlaps, then one could
click-and-zoom to google maps (without the circles, but toggling back and
forth).
Again, this technique is only trying to locate the signal source to a few
miles quickly, the final DF can be done with Hihger Tech equipment, or good
operators that know how to DF with simply their HTs and a paperclip.
>>Browser based stations could also enter their
>>report on the same web page and add to the display
>>of contours.
>
>Xastir Can't do that though. One would need a web page
>form that then generated APRS packets which would then
>get injected into the local Xastir server port.
Yes.
Also, a callsign would be required, because garbage-in-equates-to a garbage
plot. I think all DFS circles should be marked with the call of the
ENTRANT. There is nothing so bad to this system as someone with no clue
about HAAT or who doesn't understand the POWER of a not-heard report!
A guy that turns on his HT for 1 minute, and reports NOT-HEARD on a signal
that only beacons once every 10 minutes, or who is on the wrong frequency,
or doenst understand the difference between the input and output frequency
of a repeater, or who's rig is deaf as a post, but "it works for him" since
he can work the repeater 3 miles away.. Etc...
Bob, WB4APR
------------------------------
aprssig mailing list
aprssig_at_lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
End of aprssig Digest, Vol 34, Issue 26
Read previous mail | Read next mail
| |
