Skip to content

Hardware Anatomy & Specifications

r0r0x edited this page Jul 4, 2026 · 4 revisions

02. Hardware Anatomy & Specifications

This section covers the physical hardware infrastructure, components, and exposed interfaces of the FlatSat testing platform based on the original system architecture.


Hardware Infrastructure Overview

The infrastructure is designed for FlatSat testing, where hardware components are laid out for accessibility and auditing. FlatSat is a hardware-based platform designed for aerospace cybersecurity research, learning cybersecurity concepts, and prototyping payloads.

The platform uses onboard components to develop and test payload logic, radio communication, or telemetry systems.


Component Specification Table

The following table details the hardware components, their descriptions, and the specific interfaces or pins used by the firmware:

Component Description Interface
MCU Raspberry Pi RP2040 Dual Core ARM Cortex-M0+ Main Controller
Radio 0 SX1262 LoRa (Uplink) SPI0 / NSS Pin 17
Radio 1 SX1262 LoRa (Downlink) SPI0 / NSS Pin 5
IMU LIS2DH12 Accelerometer I2C (SDA 20, SCL 21)
ENV BME280 Environment Sensor I2C (SDA 20, SCL 21)
Status WS2812B NeoPixel GPIO 15

Detailed Subsystem Breakdown

1. Processing Core (On-Board Computer)

The processing infrastructure utilizes the Raspberry Pi RP2040 microcontroller. It operates using an Asymmetric Multiprocessing (AMP) approach where tasks are split across two cores:

  • Core 0: Manages the physical radio interfaces (Uplink/Downlink), sensor data acquisition, and the primary telemetry state machine.
  • Core 1: Dedicated to the TinyUSB stack, handling the usbCDC interface to provide a high-speed command-and-control link for the On-Board Computer (OBC) or ground station simulation.

Note: The OBC Data Link on Core 1 is used in case you don't have access to a Software Defined Radio (SDR) device to collect and send packets.

2. Radio Frequency (RF) Communication Hardware

FlatSat relies on two independent SX1262 LoRa modules connected via the SPI0 bus.

  • Radio 0 (Uplink): Assigned to NSS Pin 17. It processes incoming over-the-air packets.
  • Radio 1 (Downlink): Assigned to NSS Pin 5. It handles outgoing over-the-air packet transmission.

Frequency Allocation and Restrictions

FlatSat uses ISM (Industrial, Scientific, and Medical) band frequencies for all RF communication—typically 433 MHz or 915 MHz, depending on your region. These frequencies are internationally reserved for unlicensed, experimental, and educational use.

To ensure that FlatSat does not interfere with any production space systems, licensed satellites, or critical ground infrastructure, the hardware does not use sensitive or restricted space communication bands such as:

  • ❌ X-band
  • ❌ Ka-band
  • ❌ S-band

3. Onboard Sensors

The platform integrates physical sensors on a shared I2C bus using pins SDA 20 and SCL 21:

  • LIS2DH12 Accelerometer: Used for tracking position metrics.
  • BME280 Environment Sensor: Used for collecting telemetry data (temperature, barometric pressure, and relative humidity parameters).

Exposed Interfaces for Auditing

For hardware hacking foundations and educational auditing, the board layout leaves critical communication lines exposed. The following interfaces are directly accessible on the board:

  • I2C: Connects the RP2040 to the LIS2DH12 and BME280 sensors (SDA 20, SCL 21).
  • UART: Exposed serial interface for system data and logs.
  • SWD: Serial Wire Debug interface connected directly to the RP2040 for hardware-level access.

Status Indicators (NeoPixel Feedback)

The hardware includes a WS2812B NeoPixel LED mapped to GPIO 15. It provides real-time feedback for field operations without requiring a serial monitor. The physical patterns and meanings are:

  • White (Single Blink): Successful Downlink Transmission.
  • Blue (Single Blink): Successful Uplink Reception.
  • Yellow (8 Blinks): SPP Unpacking/Parsing Error.
  • Red (8 Blinks): Hardware Interface / Radio Failure.
  • Red/Yellow (Alternating): System Reboot Initiated (triggered by a software watchdog reboot via the reset telecommand or safety loops).