[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 mailing list