[aprssig] Vicinity plotting
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Nov 22 13:27:50 CST 2011
APRSISCE/32 doesn't do vicinity plotting at all currently. There is
never, IMHO, a clearly located first digi. I don't care if you see a
packet that says "src>to,DIGI1,WIDE1*" that doesn't mean that DIGI1 was
the first to see the packet. There are devices out there (albeit few)
that are beaconing a WIDE1-2 for their first path component and
digipeaters that do callsign substitution instead of insertion. Pair
the two up, and you still have no idea where the station is nor what it
might be close to.
And how do you handle a packet that you see that simply says
"src>to,WIDE1*"? It was obviously (possibly) digipeated by something,
but what and where?
And then you have the packet "src>to,DIGI1,WIDE2*" which may or may not
have been heard first by DIGI1, may have been a WIDE2-1 originally, or
maybe a WIDE2-2, and where do you draw src if you haven't heard where
DIGI1 even is?
Nope, after looking at how many chances there were to get it wrong, I
decided to simply not place stations by inference.
And yes, I learned the hard way also that monitoring the local RF was
wonderfully CLEAN as compared to what you see via APRS-IS. And then I
realized that everything that I saw via APRS-IS was actually local RF to
someone that might be running my client, so I concluded that my client
had to do reliable, reproducible, and explainable (above all) things
regardless of what it was fed, so I opted for the 0,0 solution. And it
had to survive 24x7 operation against an APRS-IS full feed or I needed
to fix it until it could survive the onslaught of concatenated,
corrupted, delayed, and generally ugly packets.
Just wait until you get someone insisting that your new-kid-on-the-block
APRS client "isn't showing my station in the right place" when in fact,
they mean that his station appears in a different place on your client
than on aprs.fi or jfindu.com or OpenAPRS and when you dig even deeper
you find out that they've configured their Kenwood radio to beacon with
10nm (yes, 10 MILE) ambiguity. So, they're not transmitting their
actual location and then they complain that different viewers put them
in different places, all within 10 miles of where they actually are.
Yep, it's a thankless job, but I'm glad we've got brave souls out there
to give hours and hours of work to let the rest of us complain about
what's wrong with the results.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 11/22/2011 2:05 PM, Andrew P. wrote:
> Hmmm..... So, does APRS-IS/CE not do vicinity plotting at all, or only do it when there is a clearly located first digi? I'm currently implementing the second choice, and trying to decide what to do about the spurious error messages from the non-located digis. I do suspect part of my problem is the APRS-IS feed is bringing me relayed stations where the digis don't have WIDEn aliases in their position beacons, but the stations they relay do use WIDEn aliases. I don't have this issue nearly as much with an RF-only feed from a TNC and radio.
> Good thing there isn't a land mass at (0,0); they'd be swamped with traffic. ;-)
> Andrew Pavlin KA2DDO
> ------Original Message------
> From: Lynn W. Deffenbaugh (Mr)
> To: aprssig at tapr.org
> Sent: Nov 22, 2011 12:15 PM
> Subject: Re: [aprssig] Vicinity plotting
> Having struggled with the same thing myself, I finally decided that any
> station from which I have not received a position report will be located
> at 0,0 until I get a position report. I examined many many paths before
> coming to the conclusion that there is NO good solution that will
> RELIABLY tell you where you should RANDOMLY position said station. And
> cluttering the map with ambiguity circles or any other indication that
> the station really is NOT where you're drawing it was worse than just
> keeping the station off the map until a position was received.
> I would also recommend against any sort of automatic query of a station
> from which you think you need additional information. Think of the
> traffic that would be generated when you successfully replace UI-View
> and 10,000 instances of your client (yes, it works via APRS-IS too, I
> assume) "decide" they need to know exactly where that event tracker
> actually IS and fire out the requests. Not a pretty picture in my
> mind's eye.
> If you haven't heard where a station is, then my opinion is that the
> station might as well be invisible, but at least I draw them at 0,0 off
> the coast of Africa.
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
> PS. All that said, I am considering some better approaches having
> watched the real-time plots of packet paths in APRSISCE/32. I may (or
> may not) implement some sort of user-option for "guessing" a position
> for a non-beaconing station...
> On 11/22/2011 11:30 AM, Andrew P. wrote:
>> Greetings, all.
>> I've been trying to implement vicinity plotting of stations that don't send position reports, and I'm having a tough time of it. Many of them were originated over TCPIP, so they never had an initial digipeater to use for vicinity plotting. Others digipeated over a path without tracing, so their path only reports the WIDEn aliases. Yet others had an initial digipeater, but I never got a position report from the digi itself to use for vicinity plotting.
>> So how should I handle these? Right now, they are being plotted off the coast of Africa at lat/lon 0,0. Should I be querying the invisible digis as to their position? That would at least help with some, but that would cause more spurious radio traffic.
>> Thanks in advance.
>> Andrew Pavlin KA2DDO
>> Sent from my Verizon Wireless BlackBerry
>> aprssig mailing list
>> aprssig at tapr.org
> aprssig mailing list
> aprssig at tapr.org
> Sent from my Verizon Wireless BlackBerry
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig