[aprssig] Correct PSAT & igating
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Mon Jun 8 11:29:44 EDT 2015
On 6/8/2015 11:04 AM, Kai Gunter Brandt - LA3QMA via aprssig wrote:
> Using APRX as an IGATE is now posting "false positions" for a user as
> it insert them even if it was not digipeated by ISS.
> This is misleading as users then seems to have been using a satellite
> but the real story is that the local igate just inserted it.
> So for regular terrestrial APRS use i agree that this is not something
> APRX should do differently. But for satellites it's a bit different as
> "direct" positions are a false position and has gone directly to an
> IGATE and not via "space".
The raw packet shows plainly that it was gated directly and not via the
satellite, so it's not a "false position" nor is it "misleading" to
those that understand paths and used path components.
However, the biggest issue with locally gating packets attempting to
bounce through one of the APRS satellites is that the APRS-IS
(correctly) dupe-suppresses any reception of the digipeated packet
because the original packet was directly gated.
Hacking the APRS-IS server software to solve this "problem" I don't
believe is a good long-term solution. Hacking the received packets to
make them unique is also a disaster waiting to happen.
What I think we need is for someone to put up a firenet-type APRS-IS
server to which SatGates can connect that logs ALL received packets and
does not do any dupe suppression. The packets can be fed into the
normal APRS-IS for global visibility (and dupe-suppressed), but those
that want to see their raw packets would have a place to look.
It would require SatGate operators to change their APRS-IS server, but
there's few enough of those (currently) that it shouldn't be very difficult.
Just my $0.02 for whatever it's worth these days.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
More information about the aprssig