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:
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.
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.
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.
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).
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.
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
Type
Pointing?
Wavelength regime (energy range)
FOV
Resolutions
Description
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:
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 |
|