[aprssig] Correct PSAT & igating
pfbram at comcast.net
Thu Jun 11 09:38:10 CDT 2015
I was thinking mainly of two scenarios in which a comprehensive
(non-deduped) view of igated packets would be useful. (I do this as an
unpaid hobby, novelty and personal challenge are common to most any
hobby, otherwise it's like a mundane dayjob -- but without the pay.)
1. Terrestrial + non-digipeated. Like pskreporter.info, wsprnet.org,
etc. for band conditions. I know APRS-IS wasn't designed for this, but
other digital modes/software increasingly allow for automatic spot
reporting. Maybe we simply need a "aprsreporter.info" equivalent. A
central bucket that igates could dump a secondary copy of all RX'd
packets into, hooked up to an openstreetmap.org or google map interface
with a simple XML/REST type API. Good ones sort of exist (aprs.fi), but
with the deduped aspect.
While band conditions are of more interest to HF, and probably
researchers/engineers/etc., looking at who can receive your local 2m
packets has more selfish (and therefore more personally useful)
purposes: you can verify that your equipment is setup optimally, you
have good antenna placement, you can see how little power you can get
away with, how local geography/topography affects your reach, and
possible emcomm uses -- to verify that you can hit a certain APRS
ipgate, in a certain location, with a certain antenna and power level.
2. Primarily non-terrestrial + digipeated. Unless we're working EME,
meteor scatter, etc. working over a satellite or high altitude balloon
offers the greatest line-of-sight 2m FM work and challenge for most of
us. Bob mentioned doing a multi-hop satellite-to-satellite path here
(http://www.aprs.org/pcsat.html). And if the number of APRS-equipped
cubesats and/or Google's Loon ever take off (literally speaking), there
would be all sorts of interesting APRS work possible -- and it would be
useful to see how many ground stations simultaneously RX the same
packets. Both as a test of the satellite, as well as personal/selfish
reasons: I'd expect ARRL + AMSAT to expand the awards available for
satellite work as more opportunities open up.
I know alot of people have time/effort invested into the current
arrangement, and that (I work IT professionally myself) some kinds of
architectural changes are too fundamental if approached head-on. It
needn't inject anything into the current system, and offer no IS->RF
capability. So I was mainly thinking of an add-on service (i.e. like an
aprs spotting site).
Or perhaps even an aprs-is 2.0. Ideally, a topology that would
accommodate the kinds of suggestions I've seen in the aprsisce group
also -- for example, a real-time lightning map.
73, KD0KZE / Paul
On 6/8/2015 11:50 AM, Nagi Punyamurthula via aprssig wrote:
> 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
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig