[aprssig] Correct PSAT & igating
pfbram at comcast.net
pfbram at comcast.net
Thu Jun 11 10:52:32 CDT 2015
One more tidbit, with fldigi, wsjt-x, etc. the ability to automatically upload to a spotting site is opt-in only. I suppose this addresses privacy, potential outbound firewall issues, non-internet scenarios, decentralized aspects of the modes, etc.
On this topic, for some reason, I keep recalling coursework on graph theory. In a sense, a non-depuped data set is as close to a fully connected graph as you might achieve for a given packet, given the distribution of currently operating igates. Whereas a deduped view is always a subset path of that graph ( http://mathworld.wolfram.com/topics/GraphTheory.html ). Knowing both would help in thinking about redundancy in paths. If one of the vertices he relies on goes down, he knows what alternatives are in range capable of RX'ing the packet and igating it or digipeating it along (analytics knowledge possible with a de-duped view).
73, KD0KZE / Paul
----- Original Message -----
From: "Paul Bramscher via aprssig" <aprssig at tapr.org>
To: aprssig at tapr.org
Sent: Thursday, June 11, 2015 9:38:10 AM
Subject: Re: [aprssig] Correct PSAT & igating
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig