As in the first book in this series, DIY Satellite Platforms (O’Reilly/MAKE) and satellite design in general, you will be constrained in your budgets for size, weight, mass, and money. Within those limits, you need to design a sensor loadout.

As an open-ended design qualification question, we offer these design criteria:

The best way to understand space is to figure out how to explore it, the best way to learn engineering is to design a mission, and the best way to emphasize mathematical rigor is to apply math to solve interesting problems. The current rapid advances in picosatellite access are shifting satellite technology from the old model of “can it be built” to a newer model of whether you can come up with a concept that is worth flying.

At the brainstorming stage, pie-in-the-sky ideas are great. Picosatellites are born for trying new ideas. Your payload concept can be about an instrument or measurement, or a technology test or tech demo, or a science/hybrid mission such as sonifying the ionosphere or creating art in space. When coming up with what to fly, deliberately keep it very open to encourage imaginative as well as critical thinking.

Picosatellite payload brainstorming requires both intuitive and mathematical development of two key scientific and engineering concepts. Scientifically, you must define a useful set of items to measure in orbit. As an engineering challenge, you must balance trade-offs of power, mass, and size of your satellite versus the goals you wish to achieve. These loosely break into the categories of design and implementation.

The use and choice of measurement is what differentiates science from opinion. Fundamentally, a measurement consists of a number value, the units of measure, and the error range in the measurement. Designing a picosatellite instrument package engages the same path of analytical thinking, moving from base dictionary properties such as space has no air or the Earth is blue to scientific thinking on concepts such as orbital drag or atmospheric opacity.

Your scientific goals will provide the parameters that your detector engineering will achieve. One key component of scientific measurement is being able to distinguish between two similar objects or events. For example, Figure 1-3 shows the aurora on Earth, due to solar activity charging up our ionosphere. Figure 1-4 shows a similar aurora on Jupiter: same solar cause, different planet. While engineering can build a detector to measure a property such as magnetic field, science informs the engineering so that measurements of the two aurora allow you to compare and contrast their properties.

Figure 1-3. Earth aurora viewed from the ISS, image courtesy NASA

Figure 1-4. An aurora on Jupiter, viewed by the HST, image courtesy NASA. Is this similar to Earth, or different?

The core engineering concept is the use of key trades and resource budgets. A key trade is the balance of connected opposing quantities. Everyone faces this in using common consumer items or in managing their time. Reducing electronics weight raises the cost. Using more power-hungry devices decreases your battery lifetime. Spending time watching TV means you get less sleep. In engineering thinking, these trade-offs are quantifiable: you can put a number to the relationship and use your data to decide.

For picosatellites, we emphasize the cardinal spacecraft limiting budgets of: Mass, Size, and Power. Add too many instruments, and one or more budget is exceeded and the mission is not viable. Fail to make good use of your budgets, and your mission may be underutilizing its capacities.

A TubeSat picosatellite lifts 200 grams of payload. That’s about 7 ounces. Viewed one way, that’s less than half a can of soda. But it’s enough to lift an entire Nintendo DS game handheld into orbit. Two hundred grams can mean a lot of electronics.

When I committed to this project, I didn’t yet have the specific electronics in mind. I’ve built mini guitar amps and guitar sound processors that come in well under 7 ounces. I assumed I could kit-bash stuff and create my own schematics for the final assembly. What I didn’t expect was that there would be companies that already build everything I need.

You likely already know about MAKE’s Arduino books, such as Getting Started with Arduino. Robot Electronics is a shop that also has some good tutorials. I-CubeX is a Canadian company that creates sensors for performance art, concept pieces, human-computer interaction, and just general sensor fun. Any of these has much of my payload in easy-to-assemble Lego-like fashion.

As a case study (since it was my payload), I-CubeX sensors returned MIDI. What’s MIDI? MIDI is an electronic musical instrument data format. It lets you separate the instrument from the actual sound generation. The instrument—a MIDI keyboard, MIDI drum, MIDI saxophone, MIDI satellite—generates event messages that you can feed into a sound card or synthesizer. It’s kind of like transmitting a player piano roll: it has no sound itself, but it lets other devices create sound.

My concept was to sonify the ionosphere, to fly a satellite with MIDI-based sensors that returned their data as instrument riffs rather than raw numbers. True, the data is still just raw numbers, but the interpretive aspect is easier for non-scientists.

As a first step in my path of instrument design, I ordered a batch of sensors just to start playing around. This is an important part of sensor design—start early, try lots of things, and don’t commit to your final loadout until you’ve played around a bit.

For starters, I had a single magnetic sensor and a sensor-to-MIDI converter. The converter can take up to 8 channels, so if I have weight to spare, I can add more sensors. Optical, definitely. Temperature, likely. Vibration, maybe.

As a weight test, I weighed out my first batch of parts. I added in an FM transmitter (representing a to-be-designed add-on) and, of course, a box to hold them. I’m under 3 grams—well under half my weight budget.

During the brainstorm stage, feel free to fail. I tried a heliophone kit from a UK company to see about adding on-board signal processing akin to a theremin. Eventually I discarded this idea, but the toying around helped me later define how I wanted to process my signals.

My next analysis was on my power budget. The more sensors and sound processing I stick in, the more power it sucks up. We have a fixed amount of juice from the battery/solar cell setup. Limiting yourself to 3.5V and 500mA is a strong limit, but well within the capability of today’s easily available robot and drone sensor parts.

The result of my brainstorming and prototyping defined the mission. My satellite would not take images, but would sample the magnetic field, the temperature, and the ambient brightness levels experienced by a satellite that travels through the ionosphere at a rate of one orbit every 90 minutes.

My satellite sensors return data formatted into MIDI. You (on Earth) take the MIDI data and you can make it sound like anything. Piano, trumpet, footsteps…just dial in a different sound and run the MIDI data and it’ll play in that voice. The MIDI events give you pitch and intensity; the rest is up to the remixer.

Like techno? Assign magnetic and temperature to two harmony drones, opticals on different sample triggers, and add a drum track. Like ambient? Try magnetic on organ, temperature as a phase modulator, optical on chimes. Punk? Put everything on guitar and speed it up. Want space whales like Star Trek IV? Map everything to whale song samples. I’m doing music from space, using a 200-gram instrument in a half-kilogram case launched 312 kilometers up.

What 200 grams would you put into orbit?