[aprssig] PSAT & igating

[Steve Dimse]

On Jun 7, 2015, at 9:36 AM, Paul Bramscher via aprssig <aprssig at tapr.org> wrote:

> I could have sworn I didn't see anything there yesterday, and nothing
> for N5ZNL on http://www.findu.com/cgi-bin/pcsat.cgi.  Is it possible
> that the servers are occasionally lagged?  Otherwise I'll have to chalk
> it up as an early-onset senior moment.

The latency in findU is roughly 200 milliseconds total, it is something I watch carefully.

However it probably isn't a senior moment either. The issue here is the one discussed a few days ago. Bob used ARISS as an alias for a reason I still don't understand, other than "I did it for my other satellites". Those other satellites had no problem because their TNCs converted ARISS to the specific name of the satellite, so the downlink looked correct. This one instead inserts the PSAT but leaves the ARISS in as the active (*ed) digi. The trouble is the ARISS alias belongs on ISS, and so packets digied through it do not appear on the PSAT page. I took ARISS off the findU ISS page because it isn't being used by ISS on the downlink at this time and with Bob using it the confusion is too great. The answer for now is simply use a different alias to work PSAT.

A couple days ago in private email Bob promised me a complete list of unique strings to identify the current mode of PCSAT, the possible modes of PSAT and the future satellite he is currently trying to deliver. Last minute problems with the new sat delayed him producing that list and I'm still waiting. It may be possible to separate these into the correct bins depending on the list, but since each packet on the APRS-IS (dozens a second) needs to be compared against the full list of alias paths it is also possible that the overhead will be too great. I need to see the list to decide.

> It would seem logical that the only way a packet can be de-duped is if
> it is gated to a server and a check is made.  If it's already been
> submitted, then it's ignored.  But rather than simply dumping it then,
> it would be arguably useful to keep it around a short time (e.g. an hour
> or so?) in a data bucket with a simple API, like XML/REST.  Interested
> hams could query their own callsigns and at least verify their operating
> setups, propagation, etc.
> 
> For historical reasons, was this not part of the APRS igating design
> because 2m (terrestrial) doesn't offer terribly much interesting in the
> way of propagation compared to HF, 2m satellite operations or balloons,
> etc.  Or would the data set be too large, even for a short caching period?
> 
You need to understand that the APRS-IS is not that centralized. Dup checking is done at every stage of the system, so that every IGate, every javAPRSSrvr, every aprsd, and every APRSC needs to have this database, and somehow you would need to link all these together.

As I said yesterday, the best answer would be a special IGate mode that appends something innocuous to the end of each packet. By adding even one character to the end of each IGated packet (say rotating A-Z,a-z, and 0-9) each IGated packet from an individual station would have a different payload and no dup filtering would be done. By eliminating the self-sacrifice currently involved with running a satellite gateway it would encourage more IGates.

Steve K4HG