Sorry, another TL;DR...but hey its Friday night, what else have I got to do.....The one sentence version of the below is 'it would be cool if the SatNOGS network could record raw IQ, and then that could all be brought together at a central processing location to do some really cool stuff.'.....here comes the longer version........
I'm also generally 'pro-SatNOGS' (they started right about when I published my Master's thesis about GS networks! I wish they had been there sooner or I had known about them earlier....would have been a great addition to the work). I was furiously writing to finish my thesis while they were out winning the Hack-a-day prize. I'll admit I was jealous at first......but I quickly got over my "hate 'em cause I ain't 'em" problem because what they are up to is just too cool (and every time I talk with someone from their team face to face, they have all been super nice enthusiastic folks!). I'll freely admit I haven't had time to participate in the network myself or with VTGS systems, though that is mainly due to us not being 'ready' in terms of things like system automation (just not enough hours in a given day....this whole sleep thing is a real downer). That said, the VT Amateur Radio club, K4KDJ, a separate entity from our ground station (though with overlapping people, I used to be an officer in K4KDJ when I was a student) is considering setting a node up.
Here's one thought (laid out in a list) for the SatNOGS folks (This is a total 'feature request' of which I'm sure they get a lot......this is not a poke against them, more 'hey here's a fun idea' type thing. If I had more time I'd actually try to get more involved on this front). What follows is a total 'thinking out loud', not fully thought through, brain dump of some ideas I've been kicking around for a couple years now (I guess since at least 2013/2014.....but the existence of the SatNOGS network makes it seem more feasible now), so feel free to skip. I know others have had similar thoughts, so I also no way claim this as solely my own idea.....(AMSAT in general and Douglas, KA2UPW and Joe, KM1P specifically were in the acknowledgments section of the thesis specifically because of some conversations in this arena and for their super positive encouragement to a newby, Bob McGwier, N4HY was my committee chair....). I'm sure there are others I've talked about this with (maybe also Chris Thompson), these ideas have been 'marinating' over the last few years and I can't remember every conversation I've had........
1. One thing I think would be REALLY fun to explore is raw IQ captures shared over their network. The recorded audio is great, and I'm 100% behind what Douglas mentioned. However, if the recording point could be moved 'upstream' a bit to the raw IQ samples, some really interesting applications could be explored. Cross correlating the IQ streams to determine things like time difference of arrival and frequency difference of arrival can lead to things like orbit determination...something that might be of interest for folks burning Ion thrusters (or solar sails) and don't want to wait for TLE updates.....I'm thinking for future HEO efforts on this front, but the general theory/application could be applied across the various orbital regimes from LEO out to GEO and beyond. The familiar 'Fox Tail' on the Fox bird might make for a good 'target' for this type of thing.
2. One requirement for this to work properly is good timing references at the ground stations though (RTL SDR and FCDPP oscillators are prob not good enough), GPSDOs and other oscillators would be desirable (and are not hard to come by these days...QEX has some great articles, ebay has surplus, etc.). If reference signals can be sent over a transponder (PN sequences to make the correlations that much simpler to identify is what I'm thinking here) with a known group delay, with precise freq/time control, then there is potential to explore applications and resolving timing ambiguities between station pairs, even if they don't have 'great' oscillators (room to experiment!). Even with good timing references, you then have to make sure that's properly integrated with the SDR software actually executing the recordings (see #5 below for potential solution to part of that problem). I'm sure Tom Clark, K3IO with his long history of VLBI work might have some advice on this front (along with others). For those involved with ADSB collection over the Flightaware network (similar to SatNOGS....but different and for collecting transmissions from general and commercial aviation aircraft), they do something similar as part of their multilateration processing (using the 'known location' message bursts to resolve timing residuals between station pairs, and then using the residuals to correct the timing offsets when geolocating the messages/emitters that don't have position info in them....they call it 'MLAT'). Big difference is they don't send IQ, just 'precise' timestamps of the received messages......but I bring it up because all their Python code is open source and on github for the multilateration process....and might be a useful starting point.
3. Raw IQ recordings come with an obvious tough requirement....storage capacity and network bandwidth. IQ sample captures will be MUCH larger than the audio recording of the same pass. Perhaps some type of prototype system could be set up though to 'get started' that doesn't break the bank where certain systems (maybe volunteer stations that have the oscillator/timing features mentioned) are tasked for specific experiments on this front (not normal ops that might generate way too much data).
4. Then there is the central storage/computing resources needed to run the correlations. With modern compute resources (including cloud services), the cost of that effort doesn't necessarily have to break the bank (especially if a willing university....with big honkin GPUs in server stacks that are currently underutilized, with a research faculty member interested in GS networks and novel applications, who is also a ham, and a lifetime member of AMSAT......... are willing to free up some system time ;-) hi hi, at least maybe for some prototyping on this front).
5. then there is the appropriate tagging of metadata necessary to take full advantage of the timing information. For this I would recommend the Signal Metadata Format (aka SigMF) (https://github.com/gnuradio/SigMF). While it grew out of GNU Radio (and there are OOTMs for GNU Radio support) it is not specifically tied to the GNU Radio project and can be used for anything (literally any time series of data, even for stuff that is 'not radio' if desired). I use it extensively for signal collection work and keeping track of the myriad bits of info that needs to be tracked along with the raw IQ (the metadata is in JSON format, super easy to use). Their 'extensions' framework is ingenious, and allows folks to 'extend' the specification for custom metadata formats not already covered in the spec.
6. Finally, if all of the above can be accomplished, then there is another application that could be explored beyond the satellite tracking, signal combining. Imagine if there were packets transmitted that no single ground station could decode due to lack of sufficient SNR.....but then all the IQ streams are brought together, the correlations are performed and the streams are time aligned, and summed (perhaps with weighting)........the random nature of the noise drives its average lower, while the not so random nature of the signal drives its average higher (massive oversimplification of the idea).....leading to higher SNR....leading to potentially high enough SNR to demodulate the otherwise 'lost' packets. There are lots of techniques out there for this sort of thing in the DSP world, right now I'm thinking 'maximal ratio signal combining' that applies weights to the summing process based on the measured SNR at each station.
7. Finally, Finally. Imagine the ground stations involved were using omni antennas. Also imagine multiple birds were overhead and in the recording bandwidth. Theres nothing stopping you from going back in time, doing a bit of preprocessing (maybe coarse tuning for the target bird using TLEs, filtering for the specific signal of interest, etc.) and then re-executing the above process.
All of the above is pretty complicated to do, and I didn't cover every little technical detail or 'gotcha' type problem......but I think it could be a lot of fun to explore as a team.....if there is enough interest, perhaps some collaboration on this front and ideas for proposals could be put together to explore more.....I'm also betting the 'super-Elmers' out there (like the Bobs, Toms, and Phils) could figure out the math for this sort of thing in their sleep.
If you're reading this line....then THANKS! For sticking with the thinking out loud brain dump on this topic......as always, feedback is welcome (on or off list).
-Zach, KJ4QLP