This is the common ideas page for Google Summer of Code 2015. AerospaceResearch.net will apply again for our own projects but also as an umbrella or for the Cosmic Dust Group at the Institute of Space Systems (IRS) at the University of Stuttgart.

As a notice: We are moving our webserver during the next days, so this ideas page is hosted in our collabrator's page. Feel free to contact us via our provided ways of contacts mentioned here! And check the AerospaceResearch.net webpage.

Constellation brings space to people by means of citizen science. We believe there is an open space for everybody…

„Space, is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the road to the chemist's, but that's just peanuts to space“ - Douglas Adams

We really enjoyed last years’ Google Summer of Code. We gain a lot and we learned a lot, so we want to share this experience again and support you! Again, we’re joining forces with the Cosmic Dust Group of the Institute of Space Systems (IRS) at the University of Stuttgart. With them, we achieved two new apps, we even supported the European Space Agency (ESA) and their Interplanetary Meteoroid Environment for Exploration (IMEX) project, we released several papers, simulated comets worth 10000 hours of computing power and discussed our findings with an Astronaut and experts. How cool is that? And we want you to be part of this again. So we are re-applying this year and give you three chances to be part of this coding family (read our news).

1. Be a GSOC Student!
2. Be a GSOC Mentor!
3. Provide a GSOC Project!

We didn't expect last years overwhelming reactions about our ideas and the great support by people also being a mentor. So we would like to expand the mentor and project scale here and please keep on applying for these important tasks. There is space for everyone!

We are almost there at our projects and ideas list. Please read this carefully, because you students are important for us and the project.

Being accepted as a Google Summer of Code 2014 student is quite competitive. Accepted students typically have thoroughly researched the technologies of their proposed project and have been in frequent contact with potential mentors. Simply copying and pasting an idea here will not work. On the other hand, creating a completely new idea without first consulting potential mentors is unlikely to work out. But we encourage you to also submit and post your own ideas. Prepared and working code works best for our well-acceptance.

As a result of our last two participations in Google and ESA summer of code campaigns, we adopted our selection process. We now have a transparent application scheme where you see for what you get points. Of course, the students with the most points will be selected. We tried to find a good compromise between the fundamental skills we want to see, and also give newcomers and space students a fair chance. And as you can see, there is also a way to surprise us with your creativity. We like to be convinced with working prototypes and good community interaction. Overall, we BELIEVE everyone can do that and we mentors will help you help yourself.

We will also release our ranking list in an anonymized way to have your see, how you ranked. This could help you improve for next year’s GSOC.

Baseline:

• 5pts Communicated with us org mentors (via their emails below)?
• 5pts Communicated with the community (via email list, here https://groups.google.com/forum/#!forum/aerospaceresearch)?
• 5pts Does your application contain a motivation letter? Tell us why you like us and our projects! And prove that you know who we are and what we do! ;) (1 page is okay)
• 5pts Do you reference projects you coded WITH links to repos or provided code?
• 5pts Do you provide all demanded ways of contact (email, skype, mobile/phone, and twitter, chat and/or tumblr if available)
• 3pts Do you add a preliminary project plan (before, during, after GSOC)?
• 3pts Do you state which project you are applying for and why you think you can do that?
• 3pts Do you have time for GSOC? This is a paid job! State that you have time in your motivation letter, and list other commitments!
• 1pts Only applied via Google Melange
• 1pts Added a link to ALL your application files in www.dropbox.com? (easy points! ;) )
• 0pts Be honest! Only universal Karma points. :)

Optional:

• 5pts Did you do push code to the existing code? Or did a bugfix?
• 10pts Do you have an aerospace background and did you reference it in your application?
• 15pts Wild space. Be creative, impress us! :)
• 5pts completed CV (1-2 pages optimal!)
• 2pts If you select on of the hardware related projects, do you have (access to) it?

Please try to follow this list to get the maximum number of points!

Okay, ready for lift-off, we are approaching our coding ideas list for GSOC. The following is our list of current tasks we offer you. Feel free to select one or more for your application. If you cannot find one you like, we have our old ideas list attached and you can always propose your own.

Those projects we have listed here are divided in two: our AerospaceResearch.net’s Distributed Ground Station Network project and we serve as an umbrella org for the Comet Trails project by the Cosmic Dust group of the University of Stuttgart. We had a great collaboration last time and want to foster this relationship.

And we have lift-off…

Tasks:

• [ComT1401] Building a Collision Model into the IMEX integrator:
• [ComT1501] Building a spacecraft flux calculation tool: [not so related to constellation]
• [ComT15XX] Propose your idea!

• [DGSN1401] Lone Pseudoranger: Expansion
• [DGSN1402] Groundstation: FPGA Programming BladeRF (Packeting IQ-streams)
• [DGSN1501] Groundstation: Remote-Access to nodes for data collection (Diverse: Network, P2P)
• [DGSN1502] LonePseudoranger: Orbit Determination with Big Data sets [statistics]
• [DGSN1503] LonePseudoranger: Real-Time analysis
• [DGSN1504] BigWhoop: Sensor Grid with Software Defined Radio Dongles
• [DGSN1505] BigWhoop: Wide Range Radio-Frequency Spectrum Analyser
• [DGSN1506] BigWhoop: Database and/or Mapping
• [DGSN1507] Signal Processing: Correlation and synchronization of two IQ-streams
• [DGSN1508] Signal Processing: Detect a Reference-Tick and GPS-NMEA data in IQ-streams
• [DGSN1509] Signal Processing: RF-Signal Demodulation [Diverse: GPS, DAB, Analog-FM]
• [DGSN1510] Signal Processing: RF-Signal Demodulation - ADS-B
• [DGSN1511] Signal Processing: RF-Signal Detection - Meteorite Scattering
• [DGSN15XX] Propose YOUR idea!

• [XXXX15XX] Propose your very own space project!

The Interplanetary Meteoroid Environment for Exploration (IMEX) is an ESA-funded project run at the IRS, which involves development of a model for predicting the spacecraft impact hazard presented by dust grains in meteoroid streams. Most Jupiter-family comets have cometary trails, caused by dust released during that most recent passage of each comet near the Sun. The risk to spacecraft is a result of potentially high fluxes combined with high impact speeds (of up to 70-80 km/s) with respect to the spacecraft.

The IMEX model uses the orbits of known short period comets to define dust trails that develop through the emission of dust during each cometary apparition. The result is a large database of recently-released cometary grains, accessed through a series of tools that determine which streams intersect a given spacecraft trajectory or planet location. This is calculated using the Constellation distributed computing system (aerospaceresearch.net/constellation). This information can be used to evaluate the risk to the spacecraft, relative to the dust populations in the interplanetary background, and also to study meteor showers at Earth or other locations. Results of the model are exemplified by a model of the CG trail given at: https://www.youtube.com/watch?v=FY0vjbBp4eg

We are now embarking on a new phase, to develop an improved model for spatial distributions and dynamical populations of interplanetary dust grains in the inner solar system (inwards of Jupiter). This model will consider particles of sizes 1μm – 1mm, and will be built by integrating the trajectories of particles from cometary and asteroidal source bodies for a duration of roughly 100 000 years, or until the particles are sufficiently dispersed under collisions, planetary perturbations, solar radiation forces, and orbital spreading. We expect the model to be a major improvement on existing meteoroid environment models. This model will also utilise the Constellation system.

Mentor(s):

• #1 Rachel Soja (IRS, Uni Stuttgart), soja@irs.uni-stuttgart.de
• Web: http://www.irs.uni-stuttgart.de/cosmicdust/
• Sources: https://github.com/aerospaceresearch/CometTrails
• Video: https://www.youtube.com/watch?v=FY0vjbBp4eg

One of the most important loss mechanisms for these particles is collisions. However, this is not yet built into the integrator.

Expected results: A computational code is required to (1) identify if a given particle has passed its statistical lifetime (which must be calculated from the number of particles in the interplanetary dust cloud that exceed that mass required to destroy the grain), (2) split particles into collisional fragments of smaller masses once they have exceeded their lifetimes, and (3) add these new particles to the integration.

Knowledge Prerequisite: This project would require developing an understanding of the dynamical problem, and then writing C code that works with the existing integrator. Test integrations can be run on Constellation. It is likely that only a simple first version of this code can be developed during a 3 month project.

Source: https://github.com/aerospaceresearch/CometTrails/

Now that we have the full dataset of comet trails computed, we need to be able to access this and compute the fluxes of cometary particles at spacecraft.

Expected results: This would require building an executable to access the datafiles, calculate parameters at the spacecraft and providing a carefully structured output describing dust streams at the spacecraft. Efficient access of large datasets and optimized calculation of the resulting parameters are the goal. The executable should allow that visualizations to demonstrate where the risk to a spacecraft is greatest can be easily produced from the output.

Knowledge Prerequisite:

• Coding level: low/medium
• Space level: medium/high
• Programming language: C/C++

This is up to you! Propose your idea what you think we need and miss. Please contact us to discuss it beforehand. Also provide your expected results. Having working code would be beneficial!

The Distributed Ground Station Network is a system for tracking and communication with small satellites and other aerial vehicles. The concept includes a global network of small and cheap ground stations that track beacon signals sent by the satellite, plane or balloon. The ground stations are located at ordinary people at home, so called citizen scientists, and are connected via the internet. A broadcasted beacon signal is received by at least 5 stations and can be used then for trilateration to obtain the position of the signal's origin. For this each ground station correlates the received signal with the precise reception time, which is globally provided and synchronized by GPS. This shall help small satellite provider and even Google's Loon (http://www.google.com/loon) project to be able to track their vehicles fast, globally and simple!

Further information can be found

• in this paper (http://www.slideshare.net/aerospaceresearch/iac-2013-dgsn4ccbyncsa)
• and in this youtube video (https://www.youtube.com/watch?v=TC4Ls3AGHf4)

Mentor(s):

• #1 Andreas Hornig (AerospaceResearch.net), hornig@aerospaceresearch.net
• #2 Marta Przyszlak (LonePseudoranger app)
• Video: https://www.youtube.com/watch?v=r4zzRkNkrGk

During GSOC 2014, the Lone Pseudoranger was developed. It locates the satellite by its beacon signal via pseudo-ranging. This is done via tri-laterating the signal’s origin. You can think of this as “GPS-reverse”. You receive the one propagated signal at 5 or more ground station and via time of arrival measurements, the position is determined.

Expected results: The LPR requires an expansion towards multi-beacon calculation, clustering-algorithm, increase of calculation speed and GUI.

Sources: https://github.com/aerospaceresearch/lonepseudoranger

Knowledge Prerequisite:

• Coding level - medium
• Space level - medium for navigation and statistics
• Language - C/C++

During GSOC 2014, the advanced ground station hardware (BladeRF) was started to be programmed. This is the next station hardware besides the low-cost baseline RTL-SDR usb-dongles. With both, the beacon signal is received. And with means of software defined radio, the received signal can be correlated to the mandatory GPS-Signal, which synchronizes each ground station to be able to do the time of arrival measurements.

Expected results: The received IQ-streams shall be correlated with the GPS 1-pulse-per-second data and also with the NMEA data (position, time, etc). The aim is to packetize both data within the BladeRF, send it to the client PC via USB and de-packetize it there for further analysis

Source: https://github.com/aerospaceresearch/DGSN_bladerf

Knowledge Prerequisite:

• Coding level - medium
• Space level - low for navigation
• Language - VHDL

Due to the fact that the satellite’s beacon signal is received at several ground stations, one of the proposed ways to transfer the data back is via remote-access. The baseline mode is to use BOINC as an infrastructure for the world-wide deployment. But for a local measurement during a field campaign, where all ground stations for this are within 1 sqkm.

Expected results: The received IQ-streams shall be correlated with the GPS 1-pulse-per-second data and also with the NMEA data (position, time, etc). The aim is to packetize both data within the BladeRF, send it to the client PC via USB and de-packetize it there for further analysis.

Knowledge Prerequisite:

• Coding level - medium
• Space level - low
• Language - to be discussed

The output of the Lone Pseudoranger is a set of position data (x,y,z) over time for each satellite. This can result in a huge volume of data of single positions. This needs to be analysed for determining the Kepler orbital elements.

Expected results: Find the orbit elements of each satellite within the position data. This will require for several filtering methods and statistical techniques to deal with the amount of data.

Knowledge Prerequisite:

• Coding level - medium
• Space level - medium for orbit mechanics and medium/high for statistics.
• Language - to be discussed, preferred Python

Together with [DGSN1501], the recorded beacon signal shall be processed in near real time to provide the position data of the satellite as fast as possible to the operator. This shall be usefull for field testing.

Expected results: Faster provision of the location data of the received signal. This will require an improvement of the existing LRP software and it shall be checked, what method could increase the efficiency of the computation. This includes multi-threading and/or GPU utilization.

Knowledge Prerequisite:

• Coding level - medium
• Space level - low
• Language - to be discussed, preferred C/C++

BigWhoop is the intended first app for the Distributed Ground Stations running the baseline RTL-SDR received dongle. It is a simple but powerful software defined radio receiver able to tune to frequencies between 50MHz and 1.9GHz. This receiver shall be used to scan the full spectrum and analyse it. The aim of this project is to already collect this data and provide it to the public as an open, citizen science project. And it also serves as the global test for the satellite reception, which will be added as an addition to those ground stations.

Expected results: Develop a working prototype app (for Windows, Linux, MacOS) that runs several RTL-SDR dongles at the same time, record the IQ-streams by it and let it interface to the analyser module for further processing. A check if and how the BadeRF and HackRF SDR-receivers can be used this way.

• Source: https://github.com/aerospaceresearch/DGSN_bigwhoop
• Video Inspiration: https://www.youtube.com/watch?v=r5BTUVPeoVY

Knowledge Prerequisite:

• Coding level - medium for software, medium/high for hardware
• Space level - low
• Language - preferred Python

The received IQ-streams by [DGSN1504] shall be analysed for the full spectrum of the receiver’s bandwidth (50MHz to 1.9GHz). This will map the area around one receiver over time and provide a map of spectrum noise level, RF-activities, activation and deactivation of services, and even environmental research (like indirect atmospheric moisture measurement).

Expected results: Several modules to analyse the samples (amplitude over time for I and Q streams). Standard analysis like FFT and STFT shall be included and the operator shall be provided with standard statistics for long term analysis.

Source: https://github.com/aerospaceresearch/DGSN_bigwhoop

Knowledge Prerequisite:

• Coding level - medium for software
• Space level - low, medium for analysis
• Language - preferred Python

The collected data of each sensor will be transferred to our central BOINC server. From there, it needs to be transferred to the DB. And from there it shall be put on our webpage as an overlayed map. This shall provide every interested person information about their region and the world. Furthermore it is intended to provide an open access to the data.

Expected results: Parse the provided data of the sensors on our server to the database. Before that, select a suitable DB for GEO Information Services. Access the data to be used on a map and for the open access export. Create a Google Maps and/or Open Street Map map for this data as a heatmap.

Knowledge Prerequisite:

• Coding level - medium for software
• Space level - low
• Language - preferred Python

The Distributed Ground Station Network uses SDR for good reason, the possibility to process signals in infinite ways and way more flexible than hardware receivers could. One of those tasks is the synchronization of two separately recorded IQ-streams f the same signal source. This could be an FM music radio or a digital DVB-T stream or satellite signals. Due to the fact that the receiver clocks cannot be synchronized via the remote distance, this tasks shall investigate the possibility to find the correlation of two signals (offset of relative start, position of certain needle segment in the full haystack, etc). This will be used for signal detection and for the time of arrival measurements of the beacon signals and any other signal.

Expected Results. Correlation of two and more signals with different sampling frequencies (+-100ppm) and different recording length. Determine the offset and the relative position of one needle signal in the other haystack signals. To experiment this, here are two recordings of the sam FM radio channel http://filebin.net/8nevid3yk3

Knowledge Prerequisite:

• Coding level - medium for signal processing
• Space level - medium for radio communication
• Language - preferred Python

The tri-lateration method uses time of arrival measurement for the determination of pseudoranging. This means the signal is found in a stream and this position is used for measuring the distance to a reference tick. This tick is provided by the 1-pulse-per-second of a GPS-receiver that was injected into the antenna and mixed into the received signal stream. So the same streams includes the sat-beacon signal we want to find and the synchronized GPS reference for the tri-lateration. So a positioning of the signal becomes possible.

Expected results: Finding the injected reference ticks in a stream under noisy signal conditions. This signal can be a dirac pulse or any other function. We already made tests for this and will provide the signal pattern. Further more the GPS-NMEA data shall also be found when injected into the signal stream. This will be done via the same method of patterns as before and in binary form the student shall propose and implement as a working prototype.

Knowledge Prerequisite:

• Coding level - low
• Space level - low, medium for radio communication
• Language - preferred Python

[DGSN1509] Signal Processing: RF-Signal Demodulation [Diverse: GPS, DAB, Analog-FM] [DGSN1510] Signal Processing: RF-Signal Demodulation - ADS-B [DGSN1511] Signal Processing: RF-Signal Detection - Meteorite Scattering These three tasks are very similar, because they will require the demodulation of the signal or pattern matching to generate the payload data or to detect a certain pattern. For this, the task is to demodulate those mentioned standards and programme a library the DGSN can use in their ground station app. This may bay used as a simple filter or for extracting the data on ground station to reduce volume before it will be sent to the server.

Expected results: Decoding of specified signal (eg. ADS-B shall provide the air plane id, position, course…). The relative position within the stream shall be determined for further time of arrival measurements. The digital data shall be stored. The task is intended to provide a module/library for our and other projects’ use

Knowledge Prerequisite:

• Coding level - high
• Space level - low, medium for radio communication
• Language - preferred Python

This is up to you! Propose your idea what you think we need and miss. Please contact us to discuss it beforehand. Also provide your expected results. Having working code would be beneficial!

• Awesome space projects
• long term involvement
• scientific papers with you as Co-Author for international conferences
• letter of recommendation

• IRC channel: irc.ham.de.euirc.net #rechenkraft
• Mailinglist: aerospaceresearch@googlegroups.com for details
• Website: http://aerospaceresearch.net