SatNOGS is a modular and scalable stack for Satellite Ground Station implementation. Fully based on open source technologies and open standards, it provides interoperability with existing or future subsystems.
A Global Management Network is the key part of our stack, connecting multiple observers with multiple ground stations enabling tracking and monitoring of satellites from multiple locations around the world. The data gathered will be publicly accessible through the network website.

SatNOGS project is implementing the above general stack design using 4 different sub-projects.
SatNOGS Network - Our observations, scheduling and discovery server
SatNOGS DB - Our crowd-sourced suggestions transponder info website
SatNOGS Client - An embedded system that receives the scheduled operation from Network, records an observation and sends it back
SatNOGS Ground Station - The actual ground station instrumentation with tracker, antennas, LNAs and connected to Client.

You can choose the configuration you want, re-using existing hardware:

The following System Design visualization depicts all subsystems of a reference implementation of a SatNOGS Ground Station.

A rendering of the finalized ground station (with front cover open) can be seen here:



Pierros Papadeas


























ehughes
danalvarez
The idea of using 100s of SatNOGS together for tracking "whatever" has been buzzing in my mind, after the recent "astroexormisi" event in Mt. Elikonas, Greece, of last week!
There are a zillion of approaches to take about how to run such a setup and I'm growingly convinced that the best way may be to allow a bouquet of technologies to co-exist together.
I started looking at SPIKE and found out it's already 25 years old technology and many more things have sprung up in the meantime, see [1] [2] [3]. Windows of Opportunity (WoP) are an objective to highlight and calculating celestial and orbital mechanics may be the holy grail of this business. Subgroups of SatNOGs may be homogeneous or heterogenous, which affects scheduling dearly [4]. Finally, efforts to integrate observations with data reductions and network transfers should be overlooked and may become relevant [5].
Let me explain:
* This is by far and large a Multi-Objective-Optimization problem
* There are multiple scheduling platforms (SPIKE, ASPEN, Raptor/TALON)
* There are plenty of planning languages that could be of interest (ANML, PDDL, NDDL, AML)
* It is not clear if a push or pull scheduling (ref. "Condor") mechanism is optimal in efficiency
So, neither would ever any single approach be optimal for everybody at the same time!
In short, let's keep the current open API (congrats for that) and, build upon it multiple implementations, perhaps even allowing different coordinated groups to tackle this!
Thanks for reading the long email, F.
Ref.
[1] http://scholar.google.gr/scholar?q=SPIKE+Intelligent+Scheduling
[2] The Deep Space Network Scheduling Problem
http://www.aaai.org/Papers/AAAI/2005/IAAI05-009.pdf
[3] http://aspen.jpl.nasa.gov/
[4] http://scholar.google.gr/scholar?q=htn+telescope+scheduling
[5] https://www.google.gr/search?q=System+aspects+of+the+EUDOXOS+observatories+network