> For the complete documentation index, see [llms.txt](https://avionics.rocketcommand.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://avionics.rocketcommand.org/projects/kingfisher.md).

# Kingfisher

<mark style="color:$info;">This is the project specification for the next generation of the Apogee Targeting System (ATS), supporting the NASA USLI mission.</mark>

<a href="https://discord.com/channels/1156334327223816224/1531742867389677770" class="button secondary" data-icon="discord">Project Thread</a><a href="https://github.com/carnegie-mellon-rocket-command/avionics-hw27-kingfisher" class="button secondary" data-icon="github">Hardware Repository</a><a href="https://github.com/carnegie-mellon-rocket-command/avionics-sw27-kingfisher" class="button secondary" data-icon="github">Software Repository</a>

<table><thead><tr><th width="161.80078125">Domain</th><th>DRI</th><th>Additional Contributors</th></tr></thead><tbody><tr><td>Top-Level</td><td>Rahim Malik</td><td></td></tr><tr><td>Hardware</td><td>Adie Guo</td><td></td></tr><tr><td>Software</td><td>Katherine Liu</td><td></td></tr></tbody></table>

### Concept

#### Overview

One of the NASA USLI challenges involves getting the rocket's apogee as close as possible to a predeclared altitude. CMRC uses a real-time airbrake system to accomplish this. That system needs to be able to continuously stream altitude and accelerometer data into a processor, run a sophisticated control algorithm on said processor, and use its results to drive open flaps connected via gears to a servo. Avionics owns the electronics, firmware, and algorithm for the ATS.

#### Previous Designs

ATS hardware, and thus software, has kept roughly the same architecture throughout its entire lifetime: a Teensy 4.1 MCU, Adafruit prepackaged sensors, and built-in power regulation. In 2025, ATS went through it's biggest redesign in terms of layout, shrinking by more than half. In 2026, a speaker and dedicated switch port were added. However, significant user experience concerns around programming flexibility, footprint, storage reliability, power readiness, and time-to-data-analysis exist.

#### Tentpoles

These govern the direction features should be aligned to, and are derived from team-wide goals and past user experience bottlenecks.

1. Develop a new hardware/software architecture as the backbone for future control boards, especially for rockets in the Spaceshot lineage, which require live telemetry.
2. Provide a development environment and stack more similar to the industry for members to market in their professional skills.
3. Mitigate past concerns around footprint, storage reliability, and power readiness.

#### Feature List

<details open>

<summary>STM32 MCU</summary>

Switching to STM32 will allow for true C embedded programming, providing members with an industry-accurate learning experience. It will also allow us to push our footprint further, cutting down on functionality the Teensy 4.1 provided at no benefit.

</details>

<details open>

<summary>Soldered-on Storage</summary>

Instead of using an MCU like the Teensy 4.1 with an included SD card slot and interface, we will integrate our own storage and interface over SDMCC via SDIO, similar to Pelican. This will mean dropping support for hotswapping storage devices, but cut down on moving parts that have gotten lost or damaged in previous flights. This will also push footprint.

</details>

<details open>

<summary>USB-C and LiPo Charging</summary>

Like Pelican, we will integrate a USB-C connector meant to read from memory and charge any connected LiPo. Reusing the power regulation scheme from Pelican is ideal. Using the USB interface to program the STM32 instead of JTAG is TBD but a desirable feature for bringup and testing.

</details>

<details open>

<summary>RF Telemetry</summary>

To enable future integration with a ground station, we will support an RF transceiver, likely LoRa, directly on the board. If this eats too much into the footprint, this can be an optional feature omitted from subscale.

</details>

<details open>

<summary>Sensor Packages</summary>

To push footprint, we will no longer used prepackaged Adafruit sensors with peripheral circuitry. Instead, we will integrate the plain sensor package and just the required circuitry directly on the PCB. Using multiple sensor types for redundancy is TBD.

</details>

<details open>

<summary>Micro Molex LiPo Connector</summary>

Like Pelican, to improve LiPo security, we will switch from JST to Micro Molex connectors.

</details>

<details open>

<summary>Status LEDs</summary>

Like Pelican, we will integrate status LEDs for: battery voltage, MCU aliveness, storage mounting, and one spare.

</details>

<details>

<summary>Switch Port</summary>

We will support the same dedicated screw terminal switch port as ATS v3.

</details>

<details>

<summary>Speaker</summary>

We will support the same single-tone active piezoelectrice speaker as ATS v3.

</details>

<details>

<summary>Servo Interface</summary>

We will support the same 3-pin header servo interface as previous designs.

</details>

<details open>

<summary>Software Architecture</summary>

To leverage the STM32, integrated storage, telemetry, and possible redundant sensors, a new software architecture will be developed to properly balance core function with application workloads like the ATS algorithm.

</details>

### Timeline

{% hint style="info" icon="route" %}
See [Roadmap](/roadmap.md) for a birds-eye-view of all the R\&D project milestones.
{% endhint %}

### Hardware

### Software