Chapter 2. Introduction to Instruments
There is no ultimate detector, no detector that has an infinite field of view with perfect spatial resolution taking rapid frames covering the entire spectral wavelength (plus particle events) with zero noise. We’ll cover what sensors and detectors do, and how to balance the key tradeoffs required to make the best sensor for your task.
Let’s get some definitions out of the way:
- A sensor is a device for measuring a quantity. Sensor and detector are fairly synonymous.
- An instrument is one or more sensors.
- A telescope is one or more instruments coaligned, often with a focusing device.
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. In 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 picosatellite”—the design problem becomes a fundamental issue that must be tackled.
Basic instrument design has to deal with detection, saturation, and variability, while also tracking the bandwidth involved.
- Detection
- You don’t want to miss out on data because your detector just can’t see that low. This is like your eyes on a very dark night—you can 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. You’ll also miss any passing wildlife. If you increase your light source’s blink rate so you can see once every second, you’ll 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 being 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, but not oversampling things so that you have extra data with no real change observed. See Figure 2-1 for an illustration of timing issues.
- Bandwidth
- 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.
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 so the data has utility. Time to go into a little sensor formalism. The five primary components we will explain are our spatial or Imaging resolution, our choice of color or Spectral resolution, our ability to discern brightnesses or Photometric resolution, and being able to capture events or Timing resolution.
Parameterizing a Mission
Not every picosatellite is a sensor mission. The quite capable list of past CubeSat missions at Wikipedia, for example, lists several technology demos and operational tryouts, as well as several radio relay satellites. This book assumes you want to capture data, not just operate a satellite.
Mission Domains
One easy way to define a mission is to assess what science branch it falls into. This schema is particularly nice, as it maps to the NASA science domains and thus matches much of both the published technical literature and the grant and proposal world as well (Figure 2-2).
- Earth-observing
- Solar
- Astrophysics
- Planetary
Licensing
Does your satellite need a license? Space is highly regulated. Some of the regulation can be handled by your launch provider, but there are three areas you need to look into yourself. The first is communications: in the USA, either the FCC or the IARU must approve your mission’s communications profile.
Second is for detectors—in the USA, NOAA (see below) approves remote sensing, which may or may not included non-image work as well.
If you are from the US, observing the Earth with visual (camera-like) detectors, you need to get a special waiver from the National Oceanic and Atmospheric Administration (NOAA, license info at http://1.usa.gov/10GOLf1). In other countries, you likely have a government agency that provides licensing. This is to prevent just anyone from being able to launch a spy satellite.
Formalities are important. NOAA states “It is unlawful for any person who is subject to the jurisdiction or control of the United States, directly or through any subsidiary or affiliate to operate a private remote sensing space system without possession of a valid license issued under the Act and the regulations.”
Most picosatellites are going to have very poor spatial resolution, and therefore are not likely to be considered a threat. Therefore, getting this waiver is a question of paperwork, rather than being something to worry about during your design.
Finally, there are requirements for insurance (if your satellite damages another) and deorbiting (avoiding leaving debris) that need to be investigated. These are areas in which launch providers and existing CubeSat consortiums can assist. Alas, I am not a space lawyer, and thus will refrain from giving advice.
Look at Past Missions
Before you begin choosing your detectors, you must study what has already flown. While there is no single defined mission specification, I suggest the following bulleted list to help you quickly parameterize the instrument engineering and science designs of past missions. A good way to begin is by choosing one or more parameters from the first category (mission domain), one or more from the second category (type), etc.
Mission domain
- EO
- Solar
- Astro
- Planetary
Type
- Imaging
- Spectrometric
- Photometric
- Timing
Pointing?
- Pointing
- In situ
- Survey
- Active/passive
Wavelength regime (energy range)
- nm
- mm
- m
- eV
- keV
FOV
- Extra-wide
- Wide
- Medium
- Narrow
Resolutions
- Spatial: L/M/H
- Spectral: L/M/H
- Photometric: L/M/H
- Timing: L/M/H
Description
- Example: A camera using a 4x4 array of CCDs
Start with the broad science goal of the mission—is it Earth-observing, astronomical (pointing outward), Orbital sensing (looking at other items in orbit), or in situ (measuring the environment around the satellite itself)? Did it serve a technical function such as acting as a radio relay or testing a solar sail, or was the primary goal to acquire data via sensors?
Given its mission type, what is its specific target or class of targets that it wishes to observe?
Next, look at the wavelength regime the mission is using. Do the sensors detect visible light, radio or submillimeter light, X-rays, gamma rays, particles, or materials?
Who was involved, and how big of an effort was it? This information is useful for comparing missions. A NASA Great Observatory is very different from a single-detector SMEX satellite, and the latter might be more informative when scoping out picosatellite concepts because of its reduced goal set.
What orbit was involved? Low Earth Orbit (LEO) is what we assume is typical for prospective picosatellites, but there are many orbits possible, including high Earth and geosynchronous orbits, solar orbits, even lunar and planetary orbits. Your choice is limited to what altitude your rocket can put you into, and so the orbit itself will be a clue as to the payload and sensor choices.
Given a Low Earth Orbit, you are going to loop around the Earth every 90 minutes (give or take 20 minutes, depending on the specific orbit assigned to you). Half of that might be in darkness, with the other half in sunlight. Your orbit is rigid and fixed (relatively) but the Earth is turning below you, so you will have a different part of the Earth underneath you over the course of a 24-hour cycle. If you are looking down at Earth, the region below might have different lighting each time you cover it, or (if a Sun-synchronous orbit), it might always have the same lighting. If you are pointing at an astrophysical target, the Earth may or may not block (or occult) your target for part of each orbit, and whether there is occultation depends both on the astronomical target’s location and the date you are observing from orbit.
Now you can look at each detector on the missions you are analyzing. Break them into their categories (imaging/spectrometric/photometric/timing). Look at the specific hardware, be it CCD, Lidar, etc.—there are hundreds of pieces of potential detector hardware.
For each detector, get the resolution numbers. Indicate, for each detector, its range for spatial, spectral, timing and, if possible, minimum and maximum brightness.
Finally, look at the operations mode required. How many contact passes to downlink data to the ground did they have? How many will you have? Use past missions to understand how to better design your mission.
As a report, a mission analysis includes all five of these topics. We’ll also expand on this format and use it later to parameterize your own mission design:
- Summary of mission: type (EO, Astro, etc.), wavelength regime (radio, optical, X-ray, etc.), science goal (observe stars, track water, etc.), participants (NASA, JAXA, etc.), orbit (LEO, L5, etc.), and dates operational.
- Summary of detectors involved, including the detector category (imaging, spectrometer, etc.), the specific detector type (CCD, Lidar, etc.), and how they work.
- Detector Data resolution limits. Indicate, for each detector, its range for spatial, spectral, timing and, if possible, minimum and maximum brightness (e.g., a 128×128 imaging detector covering 1.5 degrees of wide-field sky view over a 15-250 keV wavelength range taking 16 second-long exposures, each with 4-second time resolutions, able to resolve faint objects but must avoid the Crab Nebula, Sun, and other bright objects).
- Operational details, such as the number of contact passes and comm support required (e.g., LEO, TDRSS passes 5 times daily), the approximate daily data rate (e.g., 1TB/day), and any other interesting details (such as cryogen/consumables).
- Why flown or summary of impact. Historically, how well did this do, how advanced was it, and what was its impact in its category (e.g., was first testbed for CCDs, first to discover black holes, predecessor to HST)?
This sort of historical analysis will let you use past missions as a template for designing your future mission. Further, this is very handy if you want to advance the state-of-the-art of picosatellites, and not just duplicate past efforts. Here is a blank table to get you started:
| Mission domain |
|
| Type |
|
| Pointing? |
|
| Wavelength regime (energy range) |
|
| FOV |
|
| Resolutions |
|
| Description |
|