Skip to content

Satellite Missions Catalogue


Last updated:Dec 30, 2016



Space environment


Gravity and Magnetic Fields


Operational (nominal)


Quick facts


Mission typeEO
Mission statusOperational (nominal)
Launch date12 Aug 2012
Measurement domainGravity and Magnetic Fields
Instrument typeSpace environment, Data collection
CEOS EO HandbookSee Prometheus summary

Prometheus CubeSat Missions

Overview   Launch    Mission Status    Payloads   References

Prometheus is the name of the CubeSat constellation developed and operated by LANL (Los Alamos National Laboratory),Los Alamos, New Mexico, for USSOCOM (U.S. Special Operations Command). The Prometheus CubeSats are part of a technology development and demonstration effort to explore the viability of using a CubeSat constellation to meet existing special operations mission requirements.

The LANL ASP (Agile Space Program) has developed a paradigm intended to enable new, low cost, rapidly deployed space systems. Aspects of this paradigm in the areas of requirements definition, tailoring of risk, and controlling the costs of reproduction and operations are discussed. 1)

History of the LANL Agile Space Program

The LANL Agile Space team has launched 12 CubeSats and is expecting to launch at least 10 more in 2016. These have been part of the completed Perseus project and the currently active Prometheus project. Here, a brief history and goals of these programs is provided before a focus on the technical details of Prometheus.

In 2008, LANL began its first CubeSat project, called Perseus. Perseus was designed as a system including ground assets and satellites (Figure 1). The development took about 6 months. Satellite reproduction costs after NRE (Non-Recurring Engineering) was estimated at $25 k. The goals of the Perseus system were to:

1) Demonstrate the ability to build and launch a useful satellite quickly and at very low cost.

2) Demonstrate a satellite system simple enough to be operated and maintained by non-space experts with little training.

3) Demonstrate a tactically relevant communications capability to a CubeSat with an extremely modest ground station footprint.

4) Validate the Agile Space management and development methodology.

Figure 1: Perseus Satellite and Ground Station Components (image credit: LANL)
Figure 1: Perseus Satellite and Ground Station Components (image credit: LANL)



On December 8, 2010, four Perseus CubeSats were released into a roughly circular 300 km orbit at a 34.5° inclination. The lift vehicle was a SpaceX Falcon-9. All four satellites and ground stations performed flawlessly throughout their three-week lifetime. The system met all of its goals.


Following the success of Perseus, in 2012 the LANL Agile Space Team began work on the next phase, called Prometheus (Figure 2). Prometheus has the goals of:

1) Demonstrate the ability to build and launch a useful satellite quickly and at very low cost. Focus on maintaining low reproduction costs.

2) Demonstrate a satellite system simple enough to be operated and maintained by non-space experts with little training. Focus on highly automated operations to control costs.

3) Demonstrate a tactically relevant communications capability to a CubeSat with an extremely modest ground footprint. Increased data rates over Perseus.

4) Provide sufficient operational time on orbit to assess:

- Potential concepts of operations for a tactically controlled space system

- Costs of the system

- The operational utility of a CubeSat system.

5) Validate the Agile Space management and development methodology.

Figure 2: Prometheus Block 1 satellites just prior to stowing and integrating into the dispensers (image credit: LANL)
Figure 2: Prometheus Block 1 satellites just prior to stowing and integrating into the dispensers (image credit: LANL)


On November 20, 2013 eight Prometheus Block 1 satellites (1.5U CubeSats) were dispensed to a circular 500 km altitude, 40.5° inclination orbit from the upper stage of a Minotaur 1 rocket launched by the Department of Defense's Office of Operationally Responsive Space (ORS). The primary payload on this mission was ORS-3/STPSat-3. The launch site was MARS (Mid-Atlantic Regional Spaceport) on Wallops Island, VA. 2)


Near-circular orbit, altitude = 500 km, inclination = 40.5º.

The Prometheus Block 1 demonstrated successes included:

1) Both configured and scripted tasking demonstrated on the satellite.

2) Doppler correction of ephemeris.

3) Regular secure communications achieved with all eight of the Block 1 satellites and maintained for many months.

4) Regular, fully automated, easily configured "lights out," operations at multiple ground stations.

5) Remote, networked control of ground stations.

6) Autonomous system anomaly resolution.

7) Regular automated and easy to use code upload and reprogramming of all microprocessors and SDR (Software Defined Radio) FPGAs.

8) Automated file transfer from ground station to satellite and satellite to ground station (see automatically downlinked picture in Figure 3).

9) Developing software capability after delivery and launch. Testing that software on orbit.

10) Attitude control for both Sun pointing and ground point tracking.

11) Manually variable data rates.

12) Fully encrypted communications.

Figure 3: Photo of heavy cloud coverage taken by Block 1 via a script of a selected location (image credit: LANL)
Figure 3: Photo of heavy cloud coverage taken by Block 1 via a script of a selected location (image credit: LANL)

Although successful, Prometheus Block 1 was not perfect. On orbit testing of Block 1 has provided many lessons for Block 2. This is in line with the rapid, risk tolerant development approach being employed. The goal is to continually fix issues and improve the capability while holding to a relatively constant reproduction cost. This type of incremental, heritage building development is commonplace in traditional space programs but is sometimes lacking amongst CubeSats. Prometheus Block 2 is underway and will benefit from these lessons learned.


Mission Status

• On December 13, 2015, the Prometheus Block 1-4 nanosatellite reentered Earth's atmosphere after two years on orbit. 3)

• On December 11, 2015, the Prometheus Block 1-1 nanosatellite reentered Earth's atmosphere after two years on orbit. 4)

• On December 10, 2015, the Prometheus Block 1-2 nanosatellite reentered Earth's atmosphere after two years on orbit. 5)

• On December 9, 2015, the Prometheus Block 1-6 nanosatellite reentered Earth's atmosphere after two years on orbit. 6)

• On December 8, 2015, the Prometheus Block 1-3 nanosatellite reentered Earth's atmosphere after two years on orbit. 7)

• On December 5, 2015, the Prometheus Block 1-7 nanosatellite reentered Earth's atmosphere after two years on orbit. 8)



Prometheus Block 1 Satellite Architecture

Prometheus Block 1 is actively being tested and improved on orbit. Prometheus Block 2 is in development for a planned launch date in 2016. The following sections are intended to give a status and overview of the Prometheus satellite and ground station technologies.

Structure: The Prometheus structure (Figure 4) has been developed with emphasis on accessibility and modularity. The system breaks into three major pieces. The ‘top' is the housing for the analog processing and antennas. The ‘middle' is the card cage housing the software defined radios (SDRs), command and data handling (C&DH), and attitude determination and control system (ADCS) subsystems. The ‘bottom' is the power system. All subsystems in all three pieces are connected to each other by a single backplane. It is intended that each subsystem be as independently testable as possible.

Figure 4: Prometheus Block 1 internal structure showing modularity (image credit: LANL)
Figure 4: Prometheus Block 1 internal structure showing modularity (image credit: LANL)

Figure 4 shows the layout of the individual subsystems within the satellite. There are two SDRs (Software Defined Radios) with corresponding antenna and analog processing chains, an ADCS (Attitude Determination and Control Subsystem ), and a C&DH (Command and Data Handler) subsystem.

EPS (Electrical Power Subsystem)

The EPS includes solar panels that are bonded and welded using techniques developed at LANL for its small satellite efforts. It houses the converters for all the major voltage rails within the satellite. The batteries are charged from the solar panels when illuminated. The charging has maximum power point tracking built in for maximum efficiency. Prometheus is designed to not require active attitude control to be functional. In failsafe mode, in which there is no attitude control, the satellite draws a low amount of power and, given that there are solar cells on both sides of the panels, there is sufficient power for failsafe operations and charge recovery under most orientations. Block 2 will have twice the solar panel area (compare Figure 5 to Figure 4). This will provide for the capability additions from Block 1 to Block 2 in the areas of ADCS and SDR improvements, as well as provide power for a possible hosted payload.

Software: The automation, ease of integration, and low cost requirements for Prometheus gave the LANL team a unique opportunity to design the application software and shared libraries for Prometheus from scratch. A standard microprocessor (a 32-bit ~200 MHz ARM) was selected for use within all subsystems. Therefore, a great deal of code could be shared amongst all the subsystems. We initially assigned individual hardware boards (e.g., C&DH, ADCS, SDR) to software developers for board bring-up and design validation. We quickly realized that there were many common functions needed on all boards, so we transitioned to creating a common code base shared across several board-specific applications. Networking, file I/O operations, low-level hardware configuration, and many basic commands are applicable to all subsystems and the code for these is shared. This provided a large reduction in overall system development cost.

For Block 1, a software bank structure was developed in which every subsystem has a failsafe software storage area (that can never be overwritten) and two banks for uploading new application code. The hardware has been designed with multiple levels of watchdog to ensure that any issues with new code upload reliably causes a predictable return to the failsafe code. This permits on-orbit development of capability with little or no danger of damaging or losing a satellite should imperfect code be uploaded. For Block 1, all subsystems in many of the satellites were updated many times. At the time of this writing, the team has absolute confidence that they can test a new capability on orbit and, if a mistake is made, the satellite will return to failsafe with no negative consequences.

Prometheus utilizes a single networking layer, developed at LANL for small satellites, to interconnect the various microprocessors within the system. This network code is part of the common code base shared across all subsystems. LANL assumed that the application software will have a significantly longer life than any specific system or piece of hardware. Therefore, an early goal was to abstract interconnecting the system away from a particular satellite or ground station implementation. The networking model was designed to be independent of the hardware so that new links can be added and operated over different and possibly not yet defined hardware standards in a seamless way that is invisible to the application software engineer. This network extends from the ground station to each subsystem in the satellite.

The networking layer is a static ‘circuit' protocol derived from ATM (Asynchronous Transfer Messaging). It is called SATM (Satellite ATM) because of design changes, such as its reduced header overhead, relative to standard ATM. SATM permits the creation of virtual circuits between any nodes within the system. Variable length messages are easily interleaved and moved between network nodes without forcing a complex application level decode and header parse burden on any node. This is particularly beneficial to the software radio. For example, a circuit can be established to provide apparently seamless communications between a computer in the ground station and a microprocessor in one of the subsystems within the satellite. As will be discussed in the payload hosting section, this can be extended to connecting payload developers at the ground station directly to their payload. The intervening network, number of hops, and hardware implementation is unimportant. We have routed SATM traffic over SPI, UART, and RF links.

All software for Prometheus was developed at LANL. The goal, partially realized in Block 1, and expected for Block 2, is to have a satellite and a ground station on the desk of every developer. The team stores code in a common repository and frequent merging and system level testing by all developers is performed as part of their development process. This leads to more thorough and more frequent testing as well as vastly increased confidence at the time of final satellite integration and functional testing.

C&DH (Command and Data Handler) subsystem

The C&DH is the central hub within the satellite. From a network point of view this is transparent, but at the hardware level the C&DH controls the power to the individual subsystems, monitors the health of the batteries, controls initial solar panel deployment, receives commands from the ground, and stores the system logs.

In Block 2, one of the principal functions of the C&DH is to manage targeted activities (for example, taking a picture or establishing a link with a ground asset). The Prometheus system is fundamentally configured and not scripted. The target manager is configured with a simple list of latitude and longitudes of interest along with rules governing different modes of operations. It continually propagates the orbit of the satellite and the position of the ground assets, and when line-of-site access is possible, it begins the target activity. When hosting a payload in Block 2, the C&DH additionally schedules payload actions (e.g., power-on, power-off, extract data, etc.).

Testing of Block 1 revealed that an independent source of SV (Satellite Vehicle) ephemeris is important. Prometheus Block 1 relies on ground-based tracking to determine the ephemeris and uses TLE (Two Line Element) sets provided by JSpOC (Joint Space Operations Center). Immediately, after launch and deployment, all 8 Block 1 SVs (Space Vehicles) were close enough to use a common TLE. As time progressed, the SVs spread out, the TLEs were not sorted out between Prometheus and the 20 other CubeSats dispensed from that launch, and communications began to fail due to Doppler correction errors. LANL, owning the entire system, was able to respond in a few weeks by updating its radio firmware at the ground station to make additional frequency measurements and developing a toolset to update TLEs based on these measurements. Also, the operation of the satellite relies on on-board propagation of the orbit and since the predictive quality of a TLE for a low altitude satellite decays with age (over several days), the target manager (scheduler) requires that the TLE be refreshed regularly on orbit.

Block 2 Prometheus will include a GPS receiver module. This will enable improved instantaneous orbit knowledge and independent calculation of our orbit ephemeris. On-orbit orbit determination of our ephemeris, using the GPS data, avoids issues with age of externally-provided TLEs. In Block 2, we expect to establish initial communications based on launch provided state vectors. Once the GPS operation has been confirmed, the ground station will receive ephemeris from the satellite during each pass.

RF Communication Subsystem

Ground to space and space to ground communications for Prometheus are facilitated by an encrypted half-duplex radio subsystem developed entirely at LANL for small satellites and CubeSats. The concept was to develop a radio that can communicate with itself. This permits nearly exactly the same hardware, firmware, and software to be used in both the satellite and the ground station. There is actually a second set of satellite flight boards within the Prometheus ground station. This provides a tremendous reduction in development cost and testing. The networking layer runs over the communications subsystem. - The radio can be separated into two logical parts; analog processing and digital SDR (Software Defined Radio).

Analog Processing: The analog processing includes a portion of the transmit and receive paths between the digital data converters and the antenna. It resides on its own printed circuit board so that it can be independently modified for different missions.

The carrier frequency on both transmit and receive can be independently set, allowing a channeling scheme for multiple satellites or frequency agility should interference limit the quality of communications. One of the design decisions in Block 1 and retained in Block 2 is that the SDR operates with a common IF (Intermediate Frequency). Therefore, should a need arise to operate at different carrier frequencies, this can be accomplished by modifying just the analog processing. Small changes are accomplished by software controlled configuration, large changes by limited redesign. A future goal of the system is automatic frequency adapting to avoid interference.

The ADCs (Analog Digital Converters) and DACs (Digital Analog Converters) operate at baseband. For the transmit path, the DAC output is up-converted to the desired carrier frequency. The receiver is a super-heterodyne optimized for minimal noise figure and high sensitivity. This facilitates an important system goal of a very small ground station footprint.

SDR (Software Defined Radio)

The digital portion of the radio is made up of a microprocessor—the same model is used system wide—that configures and controls a high performance SRAM-based FPGA. Potential upset of the SRAM interconnect fabric in the FPGA is mitigated through multiple means. As with all subsystems within the Prometheus satellite, the SDR is fully reprogrammable on-orbit. Safe reprogramming of the microprocessor and FPGA has been demonstrated on Block 1.

The Prometheus radio is designed for weak signals or long distances. Thus the SDR is optimized for low SNR (Signal to Noise Ratio). The FPGA performs the required DSP (Digital Signal Processing). The current algorithms programmed into the FPGA operate at the in-phase and quadrature (IQ) baseband. The algorithms include programmable IQ-to-IF up-conversion, programmable IF-to-IQ down-conversion, low SNR packet acquisition, carrier and time synchronization, modulation and demodulation, FEC (Forward Error Correction) channel coding, and some of the cryptographic pieces. The computational requirements are quite demanding, but the use of a modern high performance low power FPGA makes this possible even within the limited resources of a CubeSat.

A LEO satellite's communication system will see large Doppler shifts due to the high range-rate-of-change. Operating at minimum SNR demands a coherent demodulator. However, acquisition and tracking of the carrier in the presence of high Doppler shift is challenging. Both the satellite and the ground station are capable of pre-correcting Doppler. On the satellite, both the satellite and ground station positions are continually recalculated by the target manager, providing real time frequency updates to the radio on board the satellite. Or, at the ground station, the positions can be calculated by the GUI, providing the same updates.

There is a default data rate the satellite expects for initial communications. However, to maximize transferred data volume, a critical capability of the radio subsystem is varying data rate based on the channel capacity. Manually changing the data rate with a ground station command was demonstrated on-orbit with Block 1. For Block 2, the application software will automatically adapt the data rate based on signal strength metrics produced for each reception. In the future, it is planned that adapting the waveform will permit even better channel capacity utilization.

Prometheus Block 1 was a narrow bandwidth communications system. For Block 2, the communications will be direct sequence spread spectrum to reduce the power flux density per bandwidth on the ground in order to conform to spectrum regulations.

A prime goal of Prometheus is a modest footprint for ground assets. This has led to a radio designed for communication over highly disadvantaged links. Low SNR, low error rate communications is paramount, while bit rate is secondary. However, the Prometheus SDR is very flexible due to the on-orbit reprogrammable FPGA and microprocessor, and due to high speed and high dynamic range ADC and DAC. If the hardware and physics permit, support for new missions with different radio requirements can simply be uploaded. For instance, using the same Prometheus SDR hardware, it is possible to support bandwidth-limited high data rate applications using completely different modulations, DSP algorithms, and FEC channel codes. This would be possible with larger ground station antennas. Such an upgrade could be made after launch.

Satellite Antennas: Custom novel deployable antennas were developed for Block 1 and are being updated and refined for Block 2. There are two SDRs each with their own independent antenna. One SDR has a higher gain antenna at a higher carrier frequency and is intended for higher data rate or more disadvantaged ground assets. This antenna requires the ADCS and pointing. The high gain antenna for Block 1 and Block 2 is a helical that is compressed to about 5% of its deployed volume when stored in the dispenser (Figure 5). The low gain antenna, at a lower carrier frequency, is a more isotropic crossed dipole.

Figure 5: Prometheus Block 2 showing the deployed helical antenna and crossed dipole antennas (image credit: LANL)
Figure 5: Prometheus Block 2 showing the deployed helical antenna and crossed dipole antennas (image credit: LANL)

ADCS (Attitude Determination and Control Subsystem)

The Prometheus ADCS was developed entirely at LANL specifically for the Prometheus project and future Agile Space small satellite programs. The software libraries were developed from scratch to facilitate a configured-not-scripted system. There are four basic modes of operation supported by the Prometheus Block 2 ADCS:

1) To support high data rate communications, the high gain antenna must point to and track a ground station throughout a pass.

2) To maximize available solar input, when the Sun is in view and communications are not occurring, the solar panels are oriented normal to the Sun.

3) When neither the ground station nor the Sun is in view, the ADCS can be set to reduce its power draw.

4) For future hosted payloads, a nadir pointing mode is being added to Block 2.

Transitions between these modes are controlled by the target manager software on-board the satellite. The actions of the target manager are controlled by configuration data periodically uploaded by a ground station. This configuration data includes: locations of the ground assets, radio communications parameters, and some additional configuration values. The location of the satellite, the location and access to the ground assets, and access to the Sun are continually calculated on board. The target manager uses this information to choose between target-pointing, sun-pointing, nadir-pointing, and free-floating operations of the ADCS. The target manager operates at 1 Hz; in each iteration, it propagates the location of the satellite and the location of the ground sites in Earth-centered inertial JD2000 coordinates. From this, access to ground sites as well as access to the Sun is calculated. The target manager software will, in real time, compute the desired attitude (the command quaternion) of the SV.

One of the major accomplishments of Block 1 was developing the ability to efficiently perform on-orbit testing and characterization of the ADCS. The ADCS software on multiple Block 1 satellites was updated many times as improvements were implemented and new features were added. An ADCS test is defined by a fairly simple, human readable, configuration file. The Prometheus team developed the capability to fully automate the process of up-linking configuration files, executing an on-orbit test, and downlinking the resulting data. To start a test, the ground station is configured to uplink a SV configuration file and downlink the corresponding logs created during the test. On the next pass, the ground station automatically uplinks the configuration file and commands the ADCS to run it. Over subsequent passes, the ground station automatically downlinks the log files.

On-orbit tests of the ADCS from Block 1 were successful. Sun and ground tracking modes were demonstrated and much was learned in the process. Our experience indicated that increased actuator control authority as well as the addition of another sensor, not dependent on the Sun, are required to support all desired maneuvers reliably at all times. These additions are in the Block 2 design.

Figure 6: Left: Sun vector sensor; Right: Block 1 ADCS module (image credit: LANL)
Figure 6: Left: Sun vector sensor; Right: Block 1 ADCS module (image credit: LANL)

Navigation Library and Control: A library of functions was written to support the ADCS and target management systems for Prometheus. The library includes basic vector, matrix, and quaternion operations, models of the Earth's magnetic field, Sun location, orbit propagation, coordinate system transformation, time transformations, Earth surface point propagation, attitude determination and control, etc. For Block 2, basic image processing, star catalogs, and pattern search operations will be added to support the addition of a SFS (Star Field Sensor).

The ADCS is configured with a file containing the SV TLE, a list of ground locations (latitude and longitude) at which to point the antenna, and parameter matrices for control loop gain, SV moments, and sensor/actuator rotation. The ADCS computer runs its control loop at 1 Hz.

Attitude Determination and Sensors

For each iteration of the control loop, the current orientation of the satellite (determined attitude quaternion) is updated. Models of the Earth's magnetic field vector and Sun ephemeris are run on-board in real time to produce reference vectors. Measurements of the Earth's magnetic field vector; the Sun vector, if available; and an integration of the on-board gyro are used in correlation with the reference vectors to determine the attitude.

In Block 1, the attitude sensors include three independent, orthogonal, SVS (Sun Vector Sensors); a vector magneto-resistive magnetometer; and a 3-axis MEMS gyro. The SVS was designed at LANL for the Prometheus project (Figure 6 left panel) because, at design time, a suitably small SVS with sufficient field of view and resolution was not commercially available. The magnetometer and gyro are commercial components.

On-orbit testing of Block 1 successfully demonstrated attitude determination. However, for reliable attitude determination when not in view of the Sun, LANL decided that Block 2 should include an additional sensor not dependent on the satellite's location in its orbit. Block 2 will, therefore, include the same sensor suite as Block 1 with the addition of a self-contained SFS, (Figure 6 left panel). This compact SFS will provide a periodic, 3-axis attitude fix. To keep the sensor simple, a simple, LANL-developed, "lost-in-space" pattern match algorithm will be performed with an on-board star catalog. The SFS will provide reliable attitude determination at any point in orbit. The SFS will also facilitate significantly improved precision in our attitude determination for improved performance of the Prometheus communications mission as well as for future missions requiring more stringent pointing requirements.

Attitude Control and Torque Actuators

 Given the command quaternion (from the target manager) and the determined attitude quaternion, the ‘error quaternion' between the command and determined attitude is calculated during each iteration of the control loop. This error is used, in conjunction with configurable loop gain matrices, to determine the torque required to correct the error in the attitude via an optimal motion.

Block 1 includes two types of torque actuators. The primary control actuator is a set of four kinematically redundant reaction wheels arranged in a pyramid formation. The second actuator is a single torque coil intended only to dump small amounts of angular momentum and not for active control. The torque coil on Block 1 has not been tested to date as vehicle angular momentum after dispensing was sufficiently small.

For Block 2, the torque coil has been replaced by three orthogonal torque rods. The principle purpose of the torque rods will be to dump all vehicle angular momentum at the beginning of the mission and, thereafter, as needed. Also, to improve the reliability of the pointing, the range of maneuvers possible, and to support a 3U CubeSat with a hosted payload, the angular momentum storage of the wheels will be significantly increased for Block 2 (compare Figure 7 right panel to Figure 6 right panel).

Figure 7: Left: illustration of SFS (Star Field Sensor); Right: Block 2 ADCS module (image credit: LANL)
Figure 7: Left: illustration of SFS (Star Field Sensor); Right: Block 2 ADCS module (image credit: LANL)

Satellite Testing

Radiation Testing of COTS Parts

An enabler for controlling costs is the use of COTS (Commercial Off-The-Shelf) parts. Modern COTS parts are reliable, inexpensive, and available on a short timeframe. One of the problems with COTS is, however, the possibility of susceptibility to the space environment. LANL has extensive expertise in house in radiation testing of microelectronics and the Prometheus team takes this very seriously. If selected components do not have previous radiation test or flight heritage, then that are tested prior to flight use. The goal of radiation testing was to give a high confidence while keeping testing costs low. For example, random samples were tested and the traditional practice of lot testing components was not performed assuming lot-to-lot variation is generally small for high volume commercial components.

Figure 8 shows setups at three different facilities as components are tested for Prometheus Block 1. Similar testing is being performed on new components as they are added to the Block 2 design. Most modern CMOS electronics are relatively hard against TID (Total Ionizing Dose) in that charge trapping oxide volumes are small. Also, for LEO satellites, the TID levels are low (only a few krad for missions of a few years in duration). For Prometheus, only a few components were tested for TID. Many components (>20) were tested for single event effects.

Figure 8: Left: Radiation testing: Gamma TID at LANL, Middle: Neutron SEE LANL, Right: Heavy Ion SEE at LANL (image credit: LANL)
Figure 8: Left: Radiation testing: Gamma TID at LANL, Middle: Neutron SEE LANL, Right: Heavy Ion SEE at LANL (image credit: LANL)

Parts were not necessarily ruled out if they did not pass a traditional radiation test. The important results of these tests were the failure symptoms the parts would exhibit. Many of the components were protected by additional analog circuitry and via supervisory functions on rad tolerant FPGAs.

Functional and Environmental Testing

Although controlling costs is the key enabler, one must always remember that it is still a satellite. The LANL team believes strongly that testing the fully integrated satellite in a relevant environment is critical to success. The testing plan for each flight satellite includes an initial baseline functional test. This is followed by a battery of environmental tests including vibration and thermal vacuum. Finally, functional testing is repeated once again to verify full flight readiness.

Verifying full mission capability under all possible scenarios a highly automated, configured-not-scripted, satellite system might encounter would require an extremely costly test campaign for each satellite. Also, it would be very difficult to get software coverage and coverage of the hardware ranges if operating in a mission configuration. Functional testing is therefore focused on hardware and critical failsafe software functionality. A single, multi-tab, LabVIEW program was developed to permit basic in-family functional testing and logging of all hardware subsystems within the satellite (Figure 9). This testing capability was developed in parallel with the subsystem development and used to test and debug the subsystems as they were developed. All subsystems provide a common interface to this capability. This is another re-use advantage the LANL team reaped by developing the whole system. In Block 1, the connections were made via external debugging connectors available for each subsystem. The flight code operating on board the satellite supported the LabVIEW interface. The critical flight software includes wakeup, secure connection, code file upload, and new code loading. It is also critical that the satellites will automatically fall back to the failsafe software should there be issues with new code loads. This is capability is tested on each satellite as part of the formal satellite functional test plan.

Figure 9: Left: Hardware testing: Reaction wheel test tab, Right: Sun Vector Sensor test tab (image credit: LANL)
Figure 9: Left: Hardware testing: Reaction wheel test tab, Right: Sun Vector Sensor test tab (image credit: LANL)

LANL has a full satellite environmental testing capability available in house. Prometheus is fully qualified to the GEVS (General Environmental Verification Specification) based on a relatively harsh launch and on-orbit environment. The approach utilized an EQM (Engineering Qualification Model) satellite put through qualification testing. After this unit passed, all flight units were subjected to acceptance level testing. All units were put through 3-axis random vibration and lengthy thermal vacuum cycling (Figure 10).

In parallel with the satellite testing and available after launch is an "EDU Lab" which includes a satellite and a ground station. The mission capable code is tested for functionality in this environment prior to upload to the on-orbit satellites.

Figure 10: Left: Block 1 random vibration testing, Right: Thermal vacuum testing (image credit: LANL)
Figure 10: Left: Block 1 random vibration testing, Right: Thermal vacuum testing (image credit: LANL)



Hosting Payloads

There are many examples of CubeSat payloads that, due to a bus failure, never got an opportunity to be tested properly on orbit. Satellites require significant effort, experience, and facilities to realize an acceptable probability of meeting the fundamental requirements of turning on, surviving the environment, and communicating commands and data with the ground.

After the launch and initial success of Block 1, the team was approached by developers, internal and external to LANL, interested in hosting payloads on Prometheus. Since Prometheus is a mission driven development, payload capabilities were not included in Block 1. However, the team came up with a novel approach that, with little modification to the satellite hardware, can provide a hosting capability. All Block 2 satellites will include this capability.

Hosting on Prometheus will enable payload developers to focus their efforts on the payload, permitting them to leverage the existing investment and the continually evolving technology of Prometheus. More consistently successful CubeSat missions will help the entire small satellite community.

Prometheus Hosting Concept: Prometheus is a 1.5U satellite permitting two satellites to fit within a standard 3U dispenser. Keeping Prometheus at 1.5U has been a continuous engineering challenge but is an important part of controlling launch costs for future constellations. When hosting a payload, a 1.5U payload volume will extend the satellite to 3U (Figure 11).

Block 1 has demonstrated reliable communications of commands and data files to and from the satellites via inexpensive, easy to use, and highly automated ground stations. Prometheus has attitude control, a power system (with significant margin in Block 2), and an autonomous software target manager that will be extended to control data collection or other actions required by a payload. All of this capability will be provided to payloads.

The hardware changes for hosting are simply the addition of a bolt-hole pattern and two ruggedized connectors. These are located at the end of the satellite away from the antennas (Figure 11). A 51-pin connector provides general purpose digital logic lines to each of the satellite's subsystems as well as access to the internal power rails. A second connector provides access to the battery and charging circuitry. An interposer board (Figure 12), will provide the interface between these connectors and the payload.

Two paths for payload hosting are under development. These are described in the following two sections. Both are focused on ensuring the bus will have the highest probability of successfully turning on and communicating with the ground. This will provide the highest probability of success for the payload. The payloads will be isolated (switches on interposer) during initial on-orbit turn-on and the failsafe software will not include payload support. This will permit consistency of testing the bus, and all missions will inherit from previous analysis and testing of the Prometheus satellite running its failsafe software.

There is an additional advantage enabled by this approach to hosting payloads. The connectors provide comprehensive access to the satellite subsystems for easy, non-invasive testing. For Block 2, a "docking station" (Figure 15) is under development. This is a significant step towards future plans for automated testing during higher volume manufacturing.

Figure 11: Left: Hosted payload volume in orange, Right: Volume retracted to show interfaces (image credit: LANL)
Figure 11: Left: Hosted payload volume in orange, Right: Volume retracted to show interfaces (image credit: LANL)


Hosting Option 1: Standard Interface

Some payload developers may be interested in a simple documented interface they can design to. This option will employ a standard interposer board that will provide power (one or two rails) and communications to and from the payload (one or two basic standards like UART). Additional functionality would be added to the application software on the C&DH within Prometheus to facilitate the payload. Cost savings would be realized in that no additional development on the host side would be required.

This option will be the lowest cost, but would be somewhat limited in capability. It is expected to be of particular interest to payloads that are early in development and can be modified or baselined to interface with Prometheus.

LANL is currently in discussion with several potential payload providers. Attempting to meet the desires of all of these with a single interface would require large software and firmware efforts, a complex interposer, a very complex and lengthy ICD (Interface Control Document), and would be unlikely to fully satisfy anyone. This is where in the option described in the next section comes in.

Figure 12: Hosted payload interposer PCB (image credit: LANL)
Figure 12: Hosted payload interposer PCB (image credit: LANL)


Hosting Option 2: Flexible Interface

Many providers are, for the most part, looking for satellites to host an existing or nearly complete payload. Therefore, they have already chosen their payload-specific hardware and data formats, have different power requirements, and generally desire to have very different interaction with the satellite. Some payloads, may also have very complex support requirements.

As was discussed in the previously, most of the Prometheus subsystems (radios, C&DH, ADCS) utilize a common digital template including the microprocessor and supervisor FPGA. The 51-pin hosted payload connector provides lines to the FPGAs on each of the subsystems. Therefore, given a custom interposer board and additional software within the subsystem, data could be communicated directly to and from any of these subsystems using virtually any standard or custom format. Also, since access to the batteries is available, a custom power rail, additional batteries for high short term power requirements, etc. are all options.

This option would require software and FPGA firmware work as well as hardware design of a custom interposer board. However, there would be no required hardware changes to the Prometheus satellite. For most payloads, it is believed that the required development will still be relatively small.

As our experience hosting various payloads grows, we envision the need to include the payload as part of the SV network. This requires including one of the Prometheus microprocessors on the interposer to participate on the network. This processor could "relay" commands and data to a specific payload or be used to perform processing on behalf of the payload.

Given this, the payload could be provided independent virtual circuits to/from the ground to facilitate direct communications between the payload developers and their payload. This allows payload functionality to be modified and improved without requiring modification and requalification of the base Prometheus flight code. This will also provide many of the capabilities inherent in the system library software, probably the most attractive of which will be reliable software upload and reprogramming on orbit.

Figure 13: Prometheus Block 2 atop the Test Docking Station (image credit: LANL)
Figure 13: Prometheus Block 2 atop the Test Docking Station (image credit: LANL)



Prometheus Block 2 CubeSats (Prometheus 2-1 and 2-2)

The Prometheus Block 2 satellites are developed and operated by LANL (Los Alamos National Laboratory) and follow up on a successful series of missions of eight Block 1 satellites and the Perseus program. Their primary purpose is the demonstration of low-cost satellites in a feasibility study of CubeSat applications in communications between remote field sites and ground station terminals in a store-and-forward environment.

Each of the 1.5U CubeSats is manufactured for less than $100,000 and features four deployable solar panels, an active attitude control system with stellar sensors, and a SDR (Software Defined Radio) with a footprint sufficiently small for tactical operations.

The use of a 1.5U bus provides the option of using it as platform to be outfitted with a 1.5U payload, allowing for low-cost integration of a variety of small-sized space experiments. Payloads can be integrated in a plug-and-play fashion – the bus comes with a generic 51-pin connector and power interfaces to be able to virtually host any payload.

Figure 14: Artist's rendition of the Prometheus Block 2 nanosatellite (image credit: LANL)
Figure 14: Artist's rendition of the Prometheus Block 2 nanosatellite (image credit: LANL)



The two Prometheus Block 2 nanosatellites were launched as secondary payloads on November 11, 2016 on an Atlas-V 401 vehicle of ULA (United Launch Alliance) from VAFB, CA, SLC-3E. The primary payload on this flight was the WorldView-4 spacecraft of DigitalGlobe. 9) 10) 11)

Orbit of WorldView-4: Sun-synchronous near-circular orbit, altitude of 617 km, inclination = 98º, period = 97 minutes, LTDN (Local equatorial crossing Time on Descending Node) at 10:30 hours, effective revisit time capability ≤ 3 days.


Secondary Payloads 12)

DigitalGlobe has included a CubeSat rideshare program. The CubeSats will be launched by use of ULA's Centaur Aft Bulkhead Carrier that has flown successfully on four previous Atlas V missions. All of the CubeSats manifested for the WorldView-4 mission are sponsored by the U.S. NRO (National Reconnaissance Office) and are unclassified technology demonstration programs. DigitalGlobe is also partnering with California Polytechnic State University, Tyvak Nanosatellite Systems Inc., Lockheed Martin and United Launch Alliance to bring this rideshare program to fruition.

• CELTEE-1 (CubeSat Enhanced Locator Transponder Evaluation Experiment-1), a 1U CubeSat built by M42 Technologies (Seattle,WA) for AFRL (Air Force Research Laboratory).

• Prometheus-2 x 2, two 1.5U technology demonstration CubeSats (Block 2) of LANL (Los Alamos National Laboratory).

• AeroCube-8C and -8D, two 1.5U technology demonstration CubeSats of the Aerospace Corporation (El Segundo, CA) to test electric propulsion, CNT (Carbon Nanotubes) and solar cell technology.

• U2U (Untitled 2U), a 2U CubeSat of AFRL to demonstrate the EGM (Electron and Globalstar Mapping) experiment.

• RAVAN (Radiometer Assessment using Vertically Aligned Nanotubes), a 3U CubeSat mission funded by the NASA and developed and operated by JHU/APL.

The CubeSats will be deployed after WorldView-4 separation as part of the NRO-sponsored ENTERPRISE mission.



1) Nicholas A. Dallmann, Jerry G. Delapp, Donald C. Enemark, Thomas D. Fairbanks, Clifford M. Fortgang, David C. Guenther, Stephen L. Judd, Gayle M. Kestell, James E. Lake, John P. Martinez, Kevin P. McCabe, John M. Michel, Joseph M. Palmer, Mitchell W. Powell, Dean A. Prichard, Michael C. Proicou, Heather M. Quinn, Robert S. Reid, Edward B. Schaller, Daniel N. Seitz, Paul S. Stein, Steven A. Storms, Erica A. Sullivan, Justin L. Tripp, Adam Warniment, Robert M. Wheat, "An Agile Space Paradigm and the Prometheus CubeSat System," Proceedings of the 29th Annual AIAA/USU Conference on Small Satellites, Logan, Utah, USA, August 8-13, 2015, SSC15-V-4, URL of paper:,
URLof presentati on:

2) Eleanor Hutterer, "Thinking inside the box — Global data-relay demands are changing and Loa Alamos's fleet of tiny CubeSats is rising to the occasion," LANL, October 2015, URL:

3) "Re-Entry: Prometheus 1-4," Spaceflight 101, Dec. 14, 2015, URL:

4) "Re-Entry: Prometheus 1-1," Spaceflight 101, Dec. 12. 2015, URL:

5) "Re-Entry: Prometheus 1-2," Spaceflight 101, Dec. 10, 2015, URL:

6) "Re-Entry: Prometheus 1-6," Spaceflight 101, Dec. 10, 2015, URL:

7) "Re-Entry Prometheus 1-3," Spaceflight 101, Dec. 8, 2015, URL:

8) "Re-Entry: Prometheus 1-7," Spaceflight 101, Dec. 6, 2015, URL:

9) "Lockheed Martin Successfully Launches WorldView-4 Satellite for DigitalGlobe," Lockheed Martin, Nov. 11, 2016, URL:

10) "ULA launches latest DigitalGlobe commercial earth observation satellite WorldView-4," Space Daily, Nov. 14, 2016, URL:

11) "Atlas V to Launch WorldView-4," ULA, Nov. 2, 2016, URL:

12) "WorldView-4's Atlas V launch vehicle to carry seven CubeSat missions for NRO," DigitalGlobe, July 25, 2016, URL:

The information compiled and edited in this article was provided by Herbert J. Kramer from his documentation of: "Observation of the Earth and Its Environment: Survey of Missions and Sensors" (Springer Verlag) as well as many other sources after the publication of the 4th edition in 2002. - Comments and corrections to this article are always welcome for further updates (

Overview   Launch    Mission Status    Payloads   References    Back to top