The Problem

Minutes matters. There are situations where people get in danger through no fault of one's own like hiking a mountanious trail and getting surprised by changing weather conditions and requiring help. Then is when search and rescue operation teams come at play and one of the first things they try to do is locating you. Normally SAR teams can find you via your cellphone you are calling them. But there are remot places with limited coverage making it harder to locate you and finding you will take more time.

The problem indirectly arose from a similar problem the KSat-Stuttgart e.V. team had. They said:
"We need to find our rover in case it will be falling of from the REXUS sounding rocket. Our ROACH experiment will be flying on an suborbital ballistic trajectory in northern Sweden and landing in the snowy Swedish tundra. This is a remote region and even with the pretty good Swedish cellphone coverage, we cannot risk loosing our rover due to a failed location over SMS transmission"
So this object recovery problem made us aware, that when this is already time crititcal and if there are still regions and situations with lacking SAR infrastructure, we want to combine both tasks and do something against it!

How it works

Our approach is pretty simple: Have a beacon signal that can reach several ground stations. At those ground stations, the time of arrival will be determined and with this a classical trilateration will be done to position the signal's origin. The mathematics behind it all of us do in highschool. The challenging part is how to realize it with hardware that can be used at remote places because all those stations need to be connected.

Setting up shall be as easy as setting up a roadside pickinc, just several, and afterward you really collect all your trash:

• select 5+ locations for covering the area
• go there and place the station
• put power on
• they either mesh themselves, or you just collect the data at the end of the experiment
• let the station record the beacon signals and triangulat the position
• get the data and get help in case people need it

So for that reason this project has the "Experiments" attached to it because we will need to test it under real conditions. This is why we need you helping us with good ideas how to test and where to test. We already have 3 phases of tests and please send us more. You can add them on our Google Map. For now, we have the following...

Basic Principles:
While design the system we always kept in mind to have the following flexbility...

• mobility: place a ground station somewhere and have it running autarkicly on battery (and solar power if region allows it)
• independence: you want it working without it being connected to the internet ("go there and grab this hdd by hand"). It is an Internet-of-Things systems, but with very high latencies in mind! (time to collect each ground stations data and get it back for analysis)
• comfort: if there is internet coverage, use it but don't rely on it, stay independent!
• quick response: a fast imprecise result leading you to a living person is better than a slow precise result leading to more sufferring.
• the more you know: the beacon can transmit more data (health conditions, environment, last known GPS location)
• expect the worst: that is why we want to test the system as hard and as much as possible, on ground and even in very high altitude.

Setting up a ground station grid shall be as flexible as possible and sometimes you need it as soon as possible for a very specific task. So you need to be able to neglect one part of the configuration and still be able to locate the signal. As usual, minutes matter because people matter.

Test it like you fly

"Test it like you fly" is one of the many mantras you will hear in aerospace engineering. MoSAReX in its essence are great testbed for our Distributed Ground Station Network (on hackaday) that is meant for tracking cubesat. But while building it, we uncover further applications beyond space....