Often, companies that sell detectors for robots, drones, and satellites will indicate either the type of measurement (imaging, acceleration) or the wavelength/data regime (light, IR, magnetic).

Here are several sample vendors’ lists:

CuteDigi:

Trossen Robotics:

Infusion Systems:

RobotShop:

One concern is that orbit has a high flux of charged particles from the Sun, which can damage electronics. Radiation-hard parts are available, but cost more than off-the-shelf. Typical picosatellite mission lifetimes are short (less than 3 months), so I’m not worried about cumulative damage. I used to do radiation damage models back in school and it turns out that modern electronics are surprisingly robust on short time scales. We will primarily have single event upsets (SEPs) that scramble a sensor or computer, but since we don’t need 100% uptime this shouldn’t be a problem.

Be aware that many off-the-shelf parts may not exactly perform as their spec sheets suggest. One CubeSat team was using an imaging sensor that simply refused to perform as specified. It wasn’t the sensor’s fault so much as the vendor; their documentation did not match the actual sensor’s interface and the interface code as provided was not robust. By that logic, you would be best served by choosing more than one sensor, then seeing which one performs best for you in your lab based on the skill sets of your team.

Given the fact that I suggest you try many sensors before settling on your final loadout, it’s only fair I document my own efforts. I enjoyed testing the first batch of sensors I bought from ICube-X (two different Magnetics and a Hot). My final flight rig includes these sensors:

The function of the light sensors will be largely binary, to catch the bright/dark cycle as the satellite itself spins to face toward or away from the Sun, as well as catching the overall day/night cycle of each orbit. If there is a slight tumble to the satellite, all the better. These light sensors will provide a basic rhythm track.

Part of the reason I settled on this one vendor is that, by the time I’d spent hours figuring out their spec sheets and parameters, I simply did not want to take the time to learn yet another company’s way of defining devices. Given that there is no one standard, just keeping up to date on the material can be difficult, unless you’re an electrical engineer. So I chose this product because it’s a good tool for the job, and I understand it, even though it may not technically be the absolute best tool available. I won’t know what the best is until I encounter it. I chose ICube-X because, once I found it and bought my first set, I didn’t need to search for something better/faster/cheaper.

Another reason for my choice was that I was able to get technical clarification on key parameters. For example, their techs suggested that their Reach detector, a capacitive charge detector, could potentially be used to detect high-energy particle events. In the end, due to time, I decided not to add it as a detector, but if my launch date gets pushed back further, I may revisit that decision and do a refit.

They also pointed out their sensors are only guaranteed to –40°C. Most electronics have trouble below –40°C, so just to support the computer and transmitter, I’m assuming my satellite will maintain a temperature above that.

That said, a metal plate in low Earth orbit will cycle from –170°C to 123°C, depending on time in sunlight. Since it’s spinning, this range is fortunately smaller (as heat has time to distribute and dissipate), and with a 90-minute orbit, we should cycle through three ranges: too cold to register, transition regions where the sensor returns valid, slowly-changing data, and possible oversaturation at the high end. But I don’t think we’ll go much above 100°C, and I believe we’ll usually be above –40°C. Obviously, thermal profiling is key.