This project is submitted for

Description

SatNOGS project is a complete platform of an Open Source Networked Ground Station. The scope of the project is to create a full stack of open technologies based on open standards , and the construction of a full ground station as a showcase of the stack.
SatNOGS provides the basis for:

Bulk manufacturing and deployment of affordable Satellite Ground Stations
Modular design for integration with existing and future technologies
A platform for a variety of instrumentation around Satellite Ground Station operations
A firm platform for a Ground Station collaborative network (one to one, one to many, many to many)
A community based approach on Ground Station development
A solution for massive automation of operator-less Ground Stations based on open standards

Check out our documentation on the website for detailed info.

Details

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:

Project Logs

SatNOGS community has been busy over the last couple of months, with many exciting updates on projects to share with you!

Rotator v3.1

First and foremost, the 3.1 version of the SatNOGS rotator
is soon to be finalized. If you are already working with a v3 keep in
mind that upgrading to 3.1 is pretty straightforward, on the meantime
feel free to share your build progress or finished ground stations
with our community We got have some stickers to send to SatNOGS ground
station operators. We really hope that lot’s of people get to install
their own v3.1 rotator and hook up to the SatNOGS network, and we are working on a way to get the v3.1 rotator design to as many people as possible.

Updates on SatNOGS DB

Our crowd-sourced satellite database, SatNOGS DB, is expanding and will soon be powering Csete’s gpredict through it’s API. In the meantime we deployed new functionality that allows SatNOGS DB to visualize telemetry data captured using the SatNOGS Network of ground stations.

Events

We really appreciate people participating in the SatNOGS project, either in our community website, our IRC/Matrix
chatroom, the SatNOGS Wiki, populating the SatNOGS database and our
source code repositories but we also enjoy meeting people interested in
SatNOGS in person.

Since
most of the core SatNOGS team lives in Europe most of us will attend
FOSDEM in Brussels,Belgium this February. There Manolis Surligas is
giving a talk “SDR for Space the Open Way” focusing on the Software Defined Radio RF frontend and the GNU Radio module operating it and will be introduced in the coming versions of the SatNOGS client.

Stay tuned for more detailed updates, and as always … keep hunting satellites!

Early on, while developing SatNOGS, the SatNOGS team encountered
the lack of a central and editable database for active satellite
transmitters. Such information would be vital not only for SatNOGS
operations but also for amateur radio operators interested in satellite
telecommunications.

Over the past many years, lots of radio amateurs undertook the
challenge by creating personal pages that would keep track of
transmitter data, and although there are really fine examples of such
efforts (props to PE0SAT, JE9PEL, OZ9AEC,
AMSAT-UK and others) those are unfortunately not scalable approaches,
that could easily become deprecated and are not easily exported for
further usage.

Our solution was to create SatNOGS DB
an open satellite transmitter database, that allows everyone to suggest
transmitter information of active satellites and collaborate in keeping
the database up-to date. SatNOGS DB information is freely and openly
(CC-BY-SA) accessible via an API and a web application, to facilitate the needs of satellite radio operators across the globe.

Technically our current implementation is based on the Django Python framework. The code can be found here
and we are looking for code contributors as always! Do you have any
suggestions on how we can make SatNOGS DB better? File away issues here, so we can make DB better for everyone.

If you are a satellite operator, or an amateur radio enthusiast and
would like to make suggestions on populating SatNOGS DB don’t hesitate
to check out our FAQ on how to do so.

The more transmitter information we have, the easier it is to
communicate with many more satellites. So get those contributions
started, and together let’s create the holistic, open and crowd-sourced
satellite transmitter database once and for all!

Emilio Martínez is a Spanish Telecommunication Engineering (MSc) student at University of Granada. He defines himself as an enthusiast of space-related technology and he would like to focus his professional career on the space industry when he finishes his studies.

He is enrolled in an aerospace developing group at University of Granada called GranaSAT. This group isformed by students and professors with the goal of designing and developing a Cubesat mission. Currently, Emilio is developing his master's thesis about the Communications System of the Granasat Cubesat and the satellite-earth link: designing the Cubesat communication hardware, defining the link budget and improving their ground station capabilities in order to reach a reliable communication.

The SatNOGS team is looking forward for the expertise and know-how Emilio brings to our project.

We welcome all contributors that would like to be involved in the SatNOGS project and we would like to encourage all parties interested in satellite communications to join our community of developers.

Since the conception of the SatNOGS one of our design mantras was modularity, not only we believe that the SatNOGS stack should be able use a wide variety of components but also that components should be able to used in a wide variety of applications.

This Sunday May 1oth 2015 the SatNOGS team had the chance to test how versatile our SatNOGS rotator and control software was by tracking the Aeolus-2way High Attitude Balloon.

Tracking was made possible by receiving APRS data from the Aeolus-2way High Attitude Balloon and converting them using a specialized script as azimuth and elevation coordinates.

The balloon launched from the center of the Peloponisos peninsula of Greece in the city of Megalopolis at Plaka airstrip at around 11:10.

Aeolus-2 way launch

The SatNOGS team was positioned 35 km (~21.7 miles) West – NorthWest of the launch site on the Antenna park near the Ano Dolianna village of Mt Parnon. An inverter was used to power two laptops sever ham radio transceivers and our SatNOGS rotator and provide sufficient power for the team's needs

ESA's Summer Of Code In Space (also known as SOCIS) is an open source development program specifically for students run by the European Space Agency Under this program. ESA funds students to write space-related code for open source projects during the northern hemisphere's summer.

Having access to an awesome 3D printer is certainly crucial for the SatNOGS project but the SatNOGS hardware is much more than 3D printed parts. To push the development of the ground station forward the core development team decided to acquire an oscilloscope, a programmable power supply and a Vector Network Analyzer

Following our ideal of sharing resources with the community, sharing it with the local hackerspace, we decided to install our instruments to it's lab and share them with anyone interested.

In the future we plan to include to our instruments among other things a frequency generator and a signal analyzer.

We consider having access to a complete electromechanical lab/workspace is crucial not only for SatNOGS but for any community driven open hardware initiative.

10 days ago we deployed a SatNOGS v2 on top of hackerspace.gr in Athens, Greece. This is the first SatNOGS deployed on the field and we couldn't help but thinking that this is a huge milestone and brings great pride to the team!

(obviously the front cap is closed at the finished deployment)

The deployment was pretty straightforward, with one UHF helical antenna (our VHF is still up for matching) and no SatNOGS client controlling it (still under development for connection to Network). We simply controlled it with gPredict and Gqrx. POE for powering it up and minimal weather shielding (just some silicone on and around the bolts of the box)

After a nice code push, scheduling observation functionality is now complete in SatNOGS Network website. The website is now able to dynamically calculate and schedule observation windows given a satellite for all available Ground Stations. The functionality works like this:

The observer enters the New Observation page. After selecting a Satellite and associated Transponder desired, the observer selects the timeframe for the observation. The timeframe selection is constrained in the future with maximum width being 8 hours (this could change as we scale the Network). After hitting 'Calculate Observation' the system returns a proposed Timeline of the observation, that includes the Ground Stations to be used and their individual observational windows. For this calculation we use PyEphem library and input the Ground Station locations, Satellite TLE, and timeframe desired.

Once the proposed timeline is reviewed and/or modified the observer can schedule the observation by hitting 'Schedule Observation'. This creates the Observation in our database as planned, together with its associated individual observations for the Stations.

The Stations, through the Client, query the Network API frequently for scheduled individual observations.They then execute them on time, and push back the recorded data to Network, for further analysis by the Observers (making them also publicly available!)

Optimization of the Scheduling functionality will be further pursued. Ideas like deduplication of overlapping (more than 50%) individual observations, and accounting for horizon constrains are already in the works, and will be evaluated (in terms of their efficiency) as the Network scales up.

We've been thinking for some time that there is no need to install two separate RTL-SDR dongles to cover both VHF and UHF. It increases power consumption on WR703N without actually having any benefit, as using two dongles simultaneously is limited by the CPU power and network bandwidth.

A diplexer would allow the connection of a single dongle on both antennas. After studying the theory behind filters, we decided to implement a pair of Chebyshev filters. This type of filter has very steep roll-off and the maximum ripple can be a design parameter.

The two filters, a high-pass to attenuate the VHF band and a low-pass to attenuate the UHF band, should be crossing at exactly 288MHz@-3dB. Attenuation on each band should be at least 50dB. We calculated that a 9-pole Chabyshev filter would match these requirements and started designing a prototype on Qucs. Qucs is an open source circuit simulator which helped us verify that our calculations are correct.

LPF

The LPF has a maximum insertion loss of 0.4dB in VHF. The attenuation in UHF is more that 60dB. Some ripple can be observed on the chart, but it should not affect reception of narrow band signals.

HPF

The HPF has a maximum insertion loss of 0.2 dB in UHF. The attenuation in VHF is more that 80dB.

Special care has been taken to ensure minimal cross-talk between the two filters. The bottom layer of the PCB is a complete ground plane and two copper shieldings have been solder on top of each filter.

Please note, that this diplexer can be used only for receiving. For transmission, a higher grade of components (high voltage caps, high current inductors) should be used.

Very nice antenna system,,am a HAM and have worked all the Russian Ham Sats when they were up,,2 meter up 10 meter down,,had a bay of 4 x 10 element 2 meter antennas trying to get in moments before and after the foot print was gone,,lots of work tracking,,LOL

I would like to point out, that if we are to implement a many-to-many configuration, this requires scheduling on at least two levels: A) global (=task submission) B) local (=execution site).

This is for example how the LCG (LHC Computing Grid) system has been implemented, crunching tons of data coming out of CERN, for some years already. Iff a FIFO queue at local (B) level is considered sufficient, then this has already been described how it's done in paper [1]; it is relatively trivial implementation for people experienced with the gLite middleware stack. Truth be told, that solution does not take into account celestial and orbital mechanics natively, at least not in a way that would yield near-optimal scheduling. Optimality here is a far more complex problem, which should rather be solved by the groups of users and resource owners. To do that, the concept of Virtual Organizations that grid systems provide, would become handy.

In short, there can be *some* initial solution, but for optimal utilization let's all honestly expect that this is a problem that will take some man-years of effort and tuning! If you are not sure why this would take time, try to play NetworKing [2] and you will understand ;-)

Hello Pierros & SatNOGS team, I hope you received your Astronaut or Not t-shirts!

Just looking at your project and wanted to remind you that by August 20th you must have the following documentation on Hackaday Projects to be considered for the next round:
- A video less than 2 minutes long describing your project.
- At least 4 Project Logs (you need at least 3 more)
- A system design document (give us a visual overview of how it all works. Highlight the design doc in the details section)
- Links to code repositories, and remember to mention any licenses or permissions needed for your project. For example, if you are using software libraries you need to document that information.

You should also try to highlight how your project is 'Connected' and 'Open' in the details and video.

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!