[aprssig] Correct PSAT & igating

[pfbram at comcast.net]

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...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20150611/edefe7f4/attachment.html>