In practice, this means rigging up a magnet to replicate ionospheric magnetic fields, putting a strobe for mimicking the Sun as seen by a rapidly spinning satellite, then seeing what sort of data my detectors spit out.
All instrument design requires you predict what range and variability your data has, then ensure the sensors you fly can cover that range. Sonification-- converting that to music-- has the added step of ensuring that the data provides some form and structure that is pleasing.
Even something as simple as "let's go out and look at the night sky" requires instrument design. If you grab binoculars, you can see bright stuff only, but it's easy to find it. Setting up a telescope, you need to choose an eyepiece to maximize the amount of light and detail seen, while also making sure the field of view is wide enough to a) let you find the object and b) see the entire object. And if you're tracking something that changes, such as a variable star, you'll have to come out many nights in a row to see any variability.
So for a simple, known problem-- look up at the night sky-- there are still design issues at stake. When you start with an open slate-- we can fly anything on our TubeSat-- the design problem becomes a fundamental issue that must be tackled.
 | The aurora borealis seen high in the Earth’s ionosphere (credit: NASA), linked from SunEarthPlan.net |
Basic instrument design has to deal with detection, saturation, and variability, while also tracking the bandwidth involved.
Detection: You don't want to miss on data because your detector just can't see that low. This is your eyes on a very dark night-- you can only barely see things. This is why night vision goggles were invented for people-- to raise the signal to a level your eye can get useful information out of.
Saturation: You don't want to saturate (overload) your detector by having it experience signals too large for it to measure. Think of how your eyes respond to a spotlight-- poorly. Too much light means you can't see anything.
Variability. Signals can change over time, and you want to make sure your detectors capture that. In our eye example, imagine you have a flashlight you can turn on only once a minute. That gives you insufficient information to navigate a nighttime terrain at any speed. And, you'll miss any passing wildlife. If you increase your light source's 'blink rate' so you can see once every second, you get a stroboscopic effect where you can see everything clearly. If your light flickers at 24 times a second, it's essentially the same as fully lit, and anything faster doesn't gain you much advantage. So you want to make sure what you're doing is fast enough to capture the action, btu not oversampling things so that you have extra data with no real change observed.
Finally, bandwidth is the amount of data being transmitted, and is usually a limited quantity. You can only download-- and sort through-- a given amount of data. For example, movies tend to run at 24 frames per second (fps). You can make a movie at 1,000 fps, but at that point you're just wasting film (or digital storage space) with overkill. On the other hand, if you are severely limited in bandwidth-- say, you have to watch the movie over a slow modem connection-- you have to somehow limit your data. Perhaps you take fewer frames per second, or you take smaller frames, or you compress the data and risk artifacts and jaggies, but your bandwidth needs will constrain how you capture the data.
So the next few weeks will see me prototyping detectors, with the help of the ICube-X people and my musician friends. We don't want to saturate the detectors, nor miss data, so we need to tune them to the range expected in space. We want to capture all the data and changes we can, within our bandwidth limits. And we want it to work as music, not just as random signals.
Alex, the daytime astronomer
Track The Satellite Diaries via RSS feed and Twitter @skyday (or go slumming in my main column, the Daytime Astronomer)
Comments