Designing for Testability: How AstroForge is Building DeepSpace‑2 to Succeed

After our Odin mission, we rethought not just how we test spacecraft—but how we design them to be testable. DeepSpace‑2 embodies this that shift, featuring cleaner integration, earlier verification, and operational flexibility built in from day one. Designing spacecraft is hard. Testing them to ensure they function in the vacuum, extreme temperature swings, and radiation of deep space is even harder. The evolution from Odin to DeepSpace‑2 represents a major mindset change at AstroForge: from “testing as a final phase” to “testability as a design requirement.” This post shares our upgrades and how they contribute to a smoother early mission and more confident operations.

What We Changed After Odin

We learned a ton from Odin, not only what we did right and definitely should do again, but also what we did wrong and should never repeat.

The Design

The design phase of a mission is where the biggest gains for integration and testing can be made. The best parts are simply the ones that don’t exist. Containing complexity is key to ensuring that a spacecraft is built in a way that’s both buildable and testable.

On Odin, we prioritized acquiring parts over designing for integration because we were rushing to build and assemble the spacecraft. This approach led us to place each system in a discrete box, resulting in unnecessary harnessing. Testing components often required specific hardware configurations that weren't always available. Consequently, we frequently delayed tests until hardware was sufficiently integrated. When we discovered issues, we had already invested significant time building the system and had to disassemble it for troubleshooting. This process cost us enormous amounts of time, though we were aware of the problem throughout. Recognizing this issue, we made several upfront design choices for DeepSpace-2 to improve the situation.

We established two simple constraints. First, all avionics must be housed in a single, stand-alone box. This approach enables us to conduct all electrical testing outside the spacecraft, in isolation. Additionally, it means that all harnessing connecting our avionics boards remains internal to one product, rather than being integrated throughout the spacecraft.

This led us to implement a backplane avionics design - a simple construction of six cards that plug into a backplane. This design allows all interconnects between cards to be printed rather than hand-made. This single change will eliminate over 40% of the issues we encountered with Odin.

The design also enables earlier testing of flight parts. With everything on stand-alone cards, we clearly understand the inputs and outputs of each system. This clarity allows us to begin Thermal Vacuum and vibration testing much earlier than we did with Odin. When building spacecraft, the key strategy is to start testing as early as possible - the sooner you discover an issue, the more options you have to solve it.

Second, we intentionally left the front panel off. If you look at any pictures of DeepSpace-2, you'll notice this detail. The open front allows us to disconnect and remove any component without disassembling the entire structure.

With Odin, we designed the spacecraft so we could open the box without disconnecting any electronics. While this helped in several situations, it created a significant drawback - each time we disassembled the box, we had to redo vibration testing. This forced us into a difficult decision whenever we needed to check something: either invest the time and money to retest everything or proceed without verification.

Another fundamental change we made relates to spacecraft communication. For DeepSpace-2, we've reduced our data transmission rate to 100bps, compared to Odin's minimum of 1600bps. This intentional reduction maximizes our signal-to-noise ratio. We've also designed a compact spacecraft state-of-health packet that contains all telemetry in a single frame. These deliberate decisions help establish stable communications throughout all mission phases while providing a consistent framework for spacecraft behavioral testing.

Infrastructure

While we can design our way to fewer parts and verify components outside the vehicle, integrated system testing remains essential. SpaceX requires standard tests like vibration and thermal testing, but what about other critical tests they don't mandate?

Our approach to testing solar panels on Odin was problematic. To demonstrate battery charging using sunlight, we simply placed the spacecraft outside in the sun.

This led to over two weeks of taking the spacecraft outdoors around noon, hoping for clear skies and proper sun alignment. At best, we achieved only 5 continuous minutes of power generation before clouds appeared or the sun shifted. Each interruption required us to break our configuration and reposition the spacecraft - a time-consuming process since the arrays needed to be stowed and re-deployed each time.

Though we eventually completed a verified test where the panels received enough sunlight to start the spacecraft, the process was difficult to reproduce. For a system as critical as spacecraft power, we needed a more reliable way to conduct multiple tests and ensure everything worked properly.

For DeepSpace-2, we have invested in four heavy-duty full-spectrum solar illumination simulators - essentially sophisticated lights that match the sun's power output in Earth orbit at 1,300 watts per square meter from a 1-meter distance. We've developed a test fixture that provides constant illumination to our solar arrays at full solar power density, freeing our power generation testing from weather conditions and time of day constraints.

From our cleanroom, we can now demonstrate complete battery charging and vehicle operation using solar power. This setup also allows us to simulate varying distances from the sun and other parameters we need to account for. With these lamps, we can generate approximately 200W from our solar arrays in the lab—a figure limited only because our arrays are too large to fit entirely under a single lamp. That's precisely why we purchased four lamps.

How We Test—Layer by Layer

Spacecraft testing requires a methodical approach, examining every component from individual circuit boards to the fully assembled vehicle. Before integrating any component into a larger assembly, we must verify it's free of flaws, defects, and early failure risks.

With Odin, we faced challenges because each test was isolated. Testing the flight computer required different hardware and fixtures than testing the power board. With so many separate boxes, automating tests wasn't feasible within our timeline.

For DeepSpace-2, we've implemented a clear testing hierarchy. Starting with the spacecraft at the top level, we work down through boxes, circuit assemblies, and individual circuits. Each level has specific functional and performance requirements that must be met before moving to the next integration stage. These tests confirm that each component (the "Device Under Test") performs correctly within its design parameters.

Another DeepSpace-2 advantage is our volume approach. Since we're producing a single box design - with two identical units serving as primary and backup systems - we can apply mass production principles. This allows for better test fixtures, increased automation, and faster verification procedures.

For flight computer circuit assemblies, we maintain a comprehensive list of interface requirements and processor performance specifications. We've built dedicated test stations that quickly verify all functional and performance requirements at the board level. We also subject individual boards to temperature cycling to catch any manufacturing defects. During these tests, we verify performance across the entire operating range, testing at both minimum (22V) and maximum (33.6V) battery voltages using automated test scripts. Once a board passes both bench testing and thermal chamber verification, it's cleared for installation in an avionics box.

Avionics box testing follows a similar principle but encompasses multiple interconnected boards. Before box-level testing begins, every circuit inside must have passed its individual component test. This ensures that each element meets requirements in isolation. Box-level checkout can then be efficiently automated, as workmanship and sub-component functionality have already been verified. This testing is highly automated and exercises all box interfaces at maximum power and data rates. Finally, we subject the complete box to qualification and acceptance thermal vacuum tests.

The qualification test runs on non-flight hardware and pushes components to their absolute limits. The acceptance thermal vacuum test provides final verification of the box's construction and workmanship, giving the green light for spacecraft integration. We've cleverly designed the box so that if a single board fails, we can replace it without disassembling the entire unit.

By the time we integrate the spacecraft, every box and subsystem has been verified to meet its interface, functionality, and performance requirements. The harnesses connecting our components have also undergone exhaustive testing. At this stage, everything in the spacecraft has been tested and validated to function normally, which should make assembly straightforward. However, to mitigate potential issues, we first build the spacecraft in a flat configuration (known as a FlatSat). In this setup, all spacecraft panels are laid out side by side on a table, resembling an unfolded box. We've carefully designed the harnesses to work in both this configuration and when the box is fully assembled.

After testing all components in the FlatSat configuration, we move to final assembly. By this point, every component and interface has been tested at multiple levels, eliminating surprise problems. This final assembly represents the most important step, as it creates the actual launch configuration of the vehicle. We then subject the assembled spacecraft to environmental testing—we "shake and bake" it. We use a vibration table to simulate the launch environment and place it in a thermal vacuum chamber to ensure all components function properly in space vacuum. This self-compatibility test answers a critical question: "Will the spacecraft overheat during normal operations?" During this testing phase, we run the spacecraft through various on-orbit procedures.

Despite our comprehensive testing regimen, one component remains impossible to fully test in-house: the thruster. While we can verify everything up to ignition—including charging, startup sequences, and even flowing nitrogen through the valves—we cannot actually fire the Hall Effect thruster. This is because it requires both a vacuum environment and Xenon fuel to operate.

To address this critical verification gap, we conduct one of our most significant system tests: firing the thruster in a specialized vacuum chamber. For this test, we transport the spacecraft to an offsite facility with a massive vacuum chamber specifically designed to withstand high-energy particles traveling at extreme velocities without damaging either the chamber or the spacecraft.

From Issues to Improvements

AstroForge is not NASA, and we don't aspire to be. While NASA has an impressive track record of deep space achievements, they're known for lengthy timelines and budget overruns. As a commercial venture, we must remain nimble and agile. We incorporate NASA's valuable lessons while avoiding bureaucratic delays. This doesn't mean we operate without structure - we've developed our own streamlined process that adapts NASA's best practices while maintaining our schedule and cost constraints.

All of our work on integration and testing centers around reviewed and released procedures. This ranges from design reviews of our circuit cards to the hot fire testing of our Hall Effect thruster in a vacuum chamber. Every operation on the vehicle is meticulously planned. We invest extra time planning tests upfront to save time later by being prepared. However, no plan survives first contact, and issues inevitably arise.

When we encounter issues during integration and testing (known in the industry as Non-Conformances), we stop work, document the problem, and identify both a root cause and path forward. Sometimes the cause is simple—a skipped procedural step or an oversized fastener. For these issues, we document the problem and solution, occasionally updating our process to prevent recurrence.

We've developed standard operating procedures for design reviews, harness assembly, integration, and more. These were created with one intent: build our spacecraft faster, better, right. While following these procedures, some things inevitably go wrong. When this happens, we track issues through an Issue Database, recording interim dispositions, root causes, and future mitigations. This lets us maintain momentum on critical operations without losing track of details that could cause problems later.

Over time, these mitigations are incorporated into our standard operating procedures, preventing us from making the same mistake twice. But rather than simply adding to our procedures, we often ask: "How can this problem be avoided altogether?" The answer frequently involves removing parts or steps from our design and process. If a component isn't present, it can't break. If a step isn't in a procedure, an operator can't perform it incorrectly.

Conclusion

The bottom line is that space is hard, and deep space is harder. AstroForge is pushing the boundaries of small satellite deep space exploration on an unprecedented timeline and budget. This achievement builds on decades of groundwork laid by NASA and other agencies who pioneered this domain. As we establish new standards for deep space exploration, we must continuously reassess our approach and remain agile when facing new challenges.

While we can't perfectly recreate deep space conditions on Earth, we can narrow the gap by designing spacecraft that are easy to understand, verify, and operate. DeepSpace-2 embodies this philosophy in both hardware and software. As we integrate components onto the vehicle, we're prepared to swap out any component at a moment's notice with minimal testing downtime.