[aprssig] Correct PSAT & igating

[Nagi Punyamurthula]

Hmm, the term "hacking" is used liberally here.  When in fact, what we're proposing is an accommodation to a certain "use-case persona". I would think of this as an "evolution of software" to solve new chanllenges. Software needs/meets changes, and change is constant. So, let's ponder this a bit before we force a lid on this idea.

Please indulge me, kindly review the attached quick+dirty workflow
(as you read this below summary, please visualize a paper-workflow in a typical office environment where a request moves from point A to Z through nodes of feedback/approval workflow. Think of a capital-expenditure electronic request going thru an approval workflow)

By enabling the terrestrial ISS igates to behave intelligently ("contingent digipeating/igating"), we have an opportunity to extend the APRS capabilities beyond the terrestrial operations by supporting insight and telemetry reporting.

My 2c w.




-----Original Message-----
From: aprssig [mailto:aprssig-bounces at tapr.org] On Behalf Of Lynn W. Deffenbaugh (Mr) via aprssig
Sent: Monday, June 08, 2015 10:30 AM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] Correct PSAT & igating

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

_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aprx workflow.pdf
Type: application/pdf
Size: 706817 bytes
Desc: aprx workflow.pdf
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20150608/1f0f39f5/attachment.pdf>