Space Domain Awareness (SDA) has moved past single research telescopes. Commercial operators and government programs now run networks of ground-based sensors spread across continents, tracking satellites and debris around the clock. Picking a camera for one telescope is one problem. Picking one that will run in a dozen domes, on different optics, with minimal staff, is another. This post covers what changes when you plan at fleet scale.
A single-site system can be tuned by hand. A network can't. Every difference between sites (a different camera model, a different driver version, a different cooling setup) multiplies your calibration, software and support work. The goal of fleet planning is to keep the number of configurations small while each site still meets its mission: wide-area survey, custody of known objects, or follow-up of new detections.
The easiest way to keep a network manageable is to standardize on one camera family with a few sensor options. Our Kepler CMOS cameras were built for this kind of work and have been adopted around the world for Space Domain Awareness. The family shares a common design approach and software, so a site that needs more sensitivity or a wider field can change models without changing its control stack.
Within the family, the large-format models cover most network roles:
Every model above shares the same family software and accessories, so a mixed network still runs one control stack. Our sales team can help you match each site's aperture and field to the right sensor.
For survey sites, the sky area covered per exposure largely decides how many objects you can catch per night. A large sensor diagonal on fast optics gives a wide field without stitching. That's why the 86.9 mm KL6060 sensor appeals for wide-area search, while sites doing custody or follow-up on longer focal lengths can trade field for pixel scale. Plan each site's role first, then match sensor and optics to it, not the other way round.
High frame rates let you sample fast-moving LEO objects and reject bad frames, but every frame has to go somewhere. At fleet scale, plan for:
Network sites are often remote and run unattended for weeks. Kepler cameras are designed for continuous 24-hour use, so a sensor can support daytime and twilight observations as well as night-time work. FLI cameras operate in observatories from the high arctic to the Antarctic.
When you evaluate a camera for unattended use, ask how it handles cooling in high ambient temperatures, how it prevents condensation on the window, and what happens to the camera after a power interruption. Kepler cameras are air cooled as standard and plumbed for liquid circulation, and liquid cooling adapters and anti-dew technology are listed as options on Kepler model pages.
In a ten-site network, something always needs attention. Design your spares strategy around the camera:
Network operators automate everything. Look for an SDK that runs on the operating systems you deploy (Windows and Linux are the usual pair) and drivers that fit your scheduler and pipeline. The Kepler SDK runs on Windows and Linux, and ASCOM, LabVIEW and MATLAB downloads for Kepler are on our support page, along with manuals and the FLI Pilot setup software for Windows.
Before you lock the bill of materials for a network, confirm each of these for every site:
Teams that settle these early spend their operating budget on observing, not troubleshooting.
Many SDA programs want to add new wavelength bands to their networks. We hear this from our customers too, and we're working on it. Watch this space.
If you're designing a new SDA network or growing an existing one, our sales team can help match Kepler models to each site's role and optics. Request a quote or email sales@flicamera.com. For an overview of FLI cameras in SDA, see the SDA section of our applications page.
