1. The road that carried everything
Neal Stephenson’s Snow Crash has the Metaverse, a shared virtual space, but it also has the real world’s infrastructure: roads, franchises, delivery systems. The road is the boring but essential layer that lets everything else function. The desktop’s power and data buses are the same: not glamorous, but the spacecraft stops without them.
Entry 270 opened the integration arc. This entry draws the electrical backbone: how power and data move between attachments.
2. Power bus architecture
The desktop’s power system has several voltage levels:
- Battery bus: the raw voltage from the battery, typically 14–29 V depending on state of charge and chemistry.
- 28 V regulated bus: a stable voltage for most subsystems.
- 12 V / 5 V / 3.3 V regulated buses: lower voltages for digital electronics.
The battery bus is the trunk. From it, DC-DC converters produce the regulated buses. Each regulated bus has its own protection and monitoring.
A practical architecture:
- Solar arrays charge the battery through the power conditioning unit.
- The battery bus feeds the main power distribution unit.
- The distribution unit provides fused or electronically protected feeds to each attachment.
- Each attachment has its own local DC-DC converters if it needs voltages other than the bus voltage.
This architecture keeps the main harness simple while allowing each attachment to manage its own internal power needs.
3. Power protection
Every attachment feed should be protected against overcurrent. Options:
- Fuses: simple, reliable, but not resettable. A blown fuse ends the mission for that attachment unless there is redundancy.
- Electronic circuit breakers: can be reset by command, allowing recovery from temporary faults.
- Current limiting: prevents a failing attachment from dragging down the whole bus.
For the desktop, electronic circuit breakers are preferable because they allow ground operators to recover from a tripped load. They also provide telemetry on current consumption.
4. Power sequencing
Attachments must be powered on in a sensible order. A typical sequence:
- Compute and core electronics first, so the spacecraft can monitor itself.
- Communications radio, so the ground can be contacted.
- ADCS sensors and actuators, so attitude can be determined and controlled.
- Thermal control, so temperatures stay within limits.
- Payload and high-power loads last, once the spacecraft is stable.
Power-off sequencing is the reverse. The flight software manages this automatically, but the ground can override if needed.
5. Data bus architecture
The desktop’s data traffic has two classes:
- Housekeeping and control: low to moderate data rate, high reliability, many endpoints.
- Payload data: high data rate, burst traffic, usually point-to-point or to storage.
For housekeeping and control, CAN bus is a good choice. It is robust, widely used in space, and supports many nodes. A typical CAN bus runs at 250 kbps to 1 Mbps. For a spacecraft with a few dozen messages per second, this is adequate.
For payload data, Ethernet or SpaceWire is more appropriate. Ethernet is familiar and flexible. SpaceWire is designed for space and supports deterministic timing. For the desktop, Ethernet is likely the baseline because it is simpler and the compute and storage attachments already speak it.
6. Bus topology
A hybrid topology for the desktop:
- Primary CAN bus: connects compute, power, thermal, ADCS, propulsion, and radio for commands and telemetry.
- Secondary CAN bus: a redundant loop for critical commands if the primary bus fails.
- Ethernet switch: connects compute, storage, imager, and radio for payload data and file transfers.
- UART/SPI/I2C: point-to-point links for bootloaders, low-level sensors, and debugging.
This topology separates slow control traffic from fast data traffic. It also keeps the critical control path simple and redundant.
7. Command and telemetry routing
Commands from the ground arrive at the radio and are passed to the compute attachment. The compute attachment routes commands over the CAN bus or Ethernet to the target subsystem. Telemetry flows back the same way: subsystem → CAN bus → compute → radio → ground.
Payload data is different. An image from the imager may go directly to storage over Ethernet, bypassing the compute attachment until the compute requests a thumbnail or metadata. This offloads the compute and uses the higher-bandwidth network.
8. Connector and harness
The physical harness must be designed for the environment:
- Cables: use stranded wire with radiation-tolerant insulation.
- Connectors: use flight-proven connectors with positive retention.
- Shielding: shield high-speed data cables and separate power and signal harnesses where possible.
- Routing: keep harnesses away from hot surfaces, moving parts, and thruster plumes.
- Service loops: provide enough slack for robotic replacement of attachments.
The desktop’s modular grid helps because attachments can have standard connector locations and harness lengths.
9. A rough bus budget
| Bus | Data rate | Nodes | Use |
|---|---|---|---|
| Primary CAN | 500 kbps | 8–12 | Commands and telemetry for most subsystems. |
| Secondary CAN | 500 kbps | 4–6 | Redundant critical commands. |
| Ethernet | 100 Mbps or 1 Gbps | 4–6 | Payload data, file transfer, software updates. |
| UART/SPI/I2C | 0.1–10 Mbps | 4–8 | Bootloaders, debug, low-level sensors. |
This budget is modest. It assumes the desktop does not carry a high-resolution video payload or a massive sensor array.
What this changes
- The desktop uses a battery bus plus regulated 28 V, 12 V, 5 V, and 3.3 V buses.
- Electronic circuit breakers protect each attachment and allow remote recovery.
- Power sequencing is managed by flight software, with ground override.
- CAN bus handles housekeeping and control; Ethernet handles payload data.
- A secondary CAN bus provides redundancy for critical commands.
- The harness is designed for launch loads, thermal radiation, and robotic serviceability.
- The next entry will define the mechanical integration and attachment grid details.