Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Welcome to the CU Sounding Rocket Lab Docs

Welcome to the CU SRL Avionics Documentation!

If you are not yet a member of the CU SRL, please visit our site, at https://cusrl.com/, for more information on getting involved. You can also check out any pages on this site called "Getting Involved" under each of the sub-teams.

Editing the docs

Our documentation system is hosted on GitHub Pages, and uses Markdown files to show content.

To edit the documentations, you may either:

  1. Clone the git repository these documents are hosted on, and edit using an editor of your choice.
  2. Edit the docs directly on GitHub, and commit your changes there.

If you're going to be doing a lot of editing, we recommend the first option. Otherwise, click the "Edit" button on the top right of a page to edit it directly on GitHub. You may also add new pages on GitHub itself.

Cloning the repository

First, you must be added to the Github SRL organization. Get in touch with a team leader to do this.

Next, clone the repository.

For first-time Git users, we recommend you use GitHub Desktop, with an editor of your choice (such as Visual Studio Code).

For command line users, or those who want to familiarize themselves with git, use the following command in a folder of your choice:

git clone git@github.com:CU-SRL/docs.git

then open the documentation in an editor.

Uploading changes

Using GitHub Desktop, simply add a change summary, commit, then push to the main branch.

Using command-line git, navigate to the repository folder, then

git add .
git commit -m "<change description>"
git push origin main

Working with the documentation

The documentation root looks like this.

book/           The theme and styling of the website itself.
src/            The folder containing site content.
book.toml       Backend parameters for the site generator.

Most of the work you'll be doing will be inside the src/ folder.

Working with Markdown

GitHub has good documentation on working with Markdown, available here.

There is also a guide specific for this book available on the mdBook documentation, with some unique features like strikethrough text and table syntax.

Structure

The documentation inside the src/ folder is structured as shown below.

SUMMARY.md
avionics/
- currentprojects/
    - currentprojects.md
    - testboard.md
- overview/
    - images/
    - overview.md
    - ...
- gettinginvolved.md

All pages are Markdown (.md) files.

Section headings are folders. Inside each folder, you might find some subheadings. If you want a subheading to be clickable, create that subheading inside its folder (such as overview/overview.md).

We recommend you explore a bit and get familiarized.

Adding a page

First, create the .md file for the page you want to create.

Then, create a link to that Markdown file inside the SUMMARY.md file. Look inside SUMMARY.md for examples.

Removing or moving a page.

Modify the relevant page, and make sure to update SUMMARY.md accordingly to redo the link to that page.

Working with images

To add an image to a page, create an images/ folder if it does not already exist, in the same directory as the page you want to add an image to. Copy the image to that images folder.

Then, inside the .md file, use Markdown image syntax to link to it. Links are relative, so use images/your-image.png for the link.

If you want to resize your image, use the following syntax instead:

<img src="images/your-image.png" width="150" height="280">

Mission Statement

The mission of SRL Avionics is to create a reliable avionics system capable of verifying that a rocket has reached space while building a supportive community which develops us as engineers. We welcome members of all skill levels and are dedicated to using rocketry avionics as a way to deepen our technical ability.

Meeting Time

Join us every Wednesday at 6:30PM in ECEE 220!

Join the SRL Slack and Notion!

Leads

Reach out to leads for any questions you may have!

Alex Reich alre8317@colorado.edu - Avionics Lead

Pranith Bhat pranith.bhat@colorado.edu - Avionics Controls Lead

Owen White owen.white@colorado.edu - Avionics Embedded Software Lead

Fedor Bezzubtsev fedor.bezzubtsev@colorado.edu - Avionics Hardware Lead

Landon Holligan landon.holligan@colorado.edu - Avionics Structures Lead

Getting Involved!

Ready to get involved? Follow these steps!

  1. Do everything on the new member checklist. Joining the slack is especially important, as all meeting announcements and general discussions happen there!

On the slack, join the following channels:

  • #avionics
  • #avionics-hardware
  • #avionics-software
  • #avionics-bay

  1. Browse through the avionics resources, and see what looks interesting to you.

    • Take a look at our common practices page to get more familiar with our typical architecture. Although we try to be as beginner-friendly as possible, we do use some jargon so reading through this page will help you get a leg up!

  2. Reach out on Slack to the current avionics team lead (Alex Reich) or the sub-team lead with the topic you're most interested in (embedded software, web development, controls/state estimation, structures, RF, or PCB design) to see where you can get started.

The leads will have a list of things you need to do to get set up with the team, ask about this! Also let them know how much experience you are coming in with so they can cater the onboarding process to you individually.

Jot down the time and date of the next avionics meeting in your planner! (Also should be on the central page)

This is a page for avionics members to list out resume and career tips!

First off, feel free to reach out to your avionics lead if you want to meet 1-on-1 for resume advice or a mock interview or even simply resume advice. Your sub-team leads and team lead will always be willing to help you out, and you can gain a lot of meaning from getting feedback from peers on your resume. This will be a page that gets updated as time moves forward, and hopefully it can be a great additional resource for your professional development!

Things to consider:

  1. What is the culture of the company you are applying for and what skills are valuable for the role?
    • Your resume should be tailored to the company you are applying to and the specific job posting.
      • Companies like SpaceX and Blue Origin want to see ownership on your resume. What were YOU 100% responsible for? You should be able to talk about the parts of the project you owned in extreme depth, and be able to answer any question possible about them.
      • If you are applying to a SWE role, your resume should not stay the same as if you are applying to an EE role. Use detailed terms in your bulletpoints (i.e. "STM32", "designed in Altium", etc.) to get past the ATS checkers for the specific role that you are looking for. For example, a software role probably doesn't care if you know how to use OpenRocket.
  2. General Stuff
    • You should not have more than 4-5 bulletpoints for each experience
    • Class projects generally do not make you stand out, since everyone else in your class probably did a similar project. Unless your project was far above the level of everyone else's, a club project or research experience is always more impressive.
    • Your employer unfortunately does not care what your hobbies are. If they are curious they will ask during the interview, but on a one page resume every line should be used to convey technical ability.
    • Your resume should be one page only. In college you do not have enough experience to warrant anything more, and recruiters do not have the time to read through two pages of fluff.
    • Do not make up statistics just because you think you're supposed to. In a technical round you will be asked about how you "increased efficiency by 25%", and if you didn't really do that they will see it from a mile away. It is better to represent yourself accurately and honestly, and trust that the right job will come your way.
    • Represent your technical achievements at a high level. In other words, do not specifically say "Wrote a function that wrote 8 bit values to a configuration register over SPI for the TMC429". Instead, think more along the lines "Wrote custom driver to control the TMC429 motor driver over SPI in C". They will ask you about the details in the interview-- use the space to include more high level ownership.
    • Keep your bulletpoints short. Each one should not take up more than 2 lines.
    • Start bullet points with action verbs. "Owned", "Led", "Executed", etc.

Resources

SRL Avionics Common Practices

SRL Avionics tends to use similar components and frameworks across lots of different projects. This helps build expertise and decrease development/debug time, allowing us to build our skills and projects faster.

Microcontrollers:

SRL Avionics loves the STM32 line of microcontrollers. With a large selection of different specifications, there is typically an STM that is applicable for any project. It also has great documentation and wide support across software frameworks, as well as a useful HAL (Hardware Abstraction Layer) that can be used in Zephyr in addition to higher level APIs.

Typically, for "smarter" applications requiring complex matrix operations, we use an MCU in the STM32H7 line. These can have up to 208 pins and are used on the Liquids Data Acquisition System (DAQ). For "dumber" applications that simply control a peripheral we use an MCU from the STM32F4 line. These can have as low as 32 pins and are used on applications such as a stepper controller or a radio board.

Embedded Frameworks

We typically use the Zephyr RTOS for almost every project. Its API is extremely well documented, and it has prewritten drivers for a wide variety of communication protocols, sensors, and various other peripherals. This makes it much more beginner friendly, and speeds up the pace of development significantly. It can be a bit finicky when it comes to hardware abstraction in the devicetree, but documentation can usually straighten things out. In addition, our resources document common issues we've faced in the past, so we can move past many problems quickly. All of our software-based leads have at least a year of experience with Zephyr, and can help you debug as well!

Programming Languages

Avionics almost always uses C or C++ for embedded applications. It is well documented and is very beginner friendly, allowing new members to jump in quickly. Python is also occasionally used for higher-level programming on a Raspberry Pi or computer, and MATLAB is typically only used for post-flight data processing.

PCB Design Software

Electrical engineers in SRL avionics use Altium, and do version control using GitHub repositories inside the CU SRL organization. Altium is widely used in industry and is a very valuable skill to have on your resume. In addition, it is well documented with lots of informative tutorials on YouTube. CU Boulder provides a free student license, and we believe that everyone interested in PCB design should take advantage of this to build skills before entering industry.

Computer-Aided Design (CAD)

Across all subteams (not just avionics), SRL uses a shared Fusion360 drive. Any CAD relating to a core project (Spaceshot, Liquids Engines/Vehicles, etc.) must eventually end up in the shared F360 drive to be saved for posterity. DM the current team captain to be added.

Communication Protocol

To communicate between nodes in a distributed embedded system such as SRL's ground station or avionics bay, we typically use RS422 with RJ45 (Ethernet) connectors. It is easy to buy shielded harnesses with these connectors which is useful when routing near high-power RF systems. See more details on RS422 on the (communication protocols)[../embedded/comm_protocols.md] page.

Git Version Control Basics

Topics:

SRL Avionics Software Development Workflow with GitHub

Resources for Embedded Systems

Topics:

  • What is an embedded system?
  • Application architecture
  • Communication protocols
  • Polling, Interrupts, and DMA
  • Distributed embedded systems

What is an Embedded System?

Everyone interacts with embedded systems countless times every single day. Anything from your refrigerator to your car can be an embedded system. The line between what is and isn't an embedded system is blurry, but generally the idea is that an embedded system has constrained resources, low(ish) size, weight, and power (SWaP), and is designed for a set of defined applications. Think garage door opener or microwave as opposed to a laptop.

Most of what avionics does is build and test various forms of embedded systems. Our flight computer, gimbal controller, and all of our radios qualify.

Typical Architecture

A typical embedded system consists of a central MCU (Microcontroller Unit), which communicates with peripherals (electronic devices like sensors, level shifters, drivers, or other embedded systems). Below is an image with some example peripherals.

Resources for software development with ZephyrRTOS

Topics:

Installing ZephyrRTOS

Windows

Mac

Linux

Interfacing with peripherals in ZephyrRTOS

Topics:

  1. GPIO Interface

GPIOs

STEP 1: Setting up the devicetree:

In Zephyr RTOS, the easiest way to configure hardware interface with the gpio is to add the following to your app.overlay file

/ {
    ...other configs here...

    zephyr,user {
        your-gpios = <gpioa 1>;
    };
}

&gpioa {
    status = "okay";
}

This example would define GPIO A1. Setting status = "okay" tells Zephyr to enable GPIO bank A, and the zephyr,user code defines the specific GPIO that you want to access (bank A, pin 1). When you do this for your own code, talk to whoever designed the PCB to see what GPIO bank and pin you should use.

STEP 2: Access the device in your C/C++ code:

Then, in your code, you can access that node in the following way:

#include <zephyr/drivers/gpio.h>
#include <zephyr/logging/log.h>

LOG_MODULE_REGISTER(gpio_sample, LOG_LEVEL_INF);

// define the gpio device in your C/C++ file
#define USER_NODE DT_PATH(zephyr-user)
static const struct gpio_dt_spec your_gpio = GPIO_DT_SPEC_GET(USER_NODE, your-gpios);

int your_function() {
    //check if the gpio device is ready
    if (!gpio_is_ready_dt(&your_gpio)) {
        LOG_ERR("GPIO not ready");
    }

    //configure the gpio pin (in this case, it is output and active high)
    int ret = gpio_pin_configure_dt(&your_gpio, (GPIO_ACTIVE_HIGH | GPIO_OUTPUT));
    if (ret < 0) {
        // failed
        LOG_ERR("Failed to configure gpio: %d", ret);
    }

    // now that the gpio is initialized and configured, you can toggle it or set it arbitrarily!

    // toggle gpio:
    gpio_pin_toggle_dt(&your_gpio);

    // set gpio high:
    gpio_pin_set_dt(&your_gpio, 1);

    // set gpio low
    gpio_pin_set_dt(&your_gpio, 0);

    return 0;
}

Sensor API

I2C Devices

ADCs

SPI Devices

UART (Interrupt Based)

UART (DMA Based)

Spawning and Using Threads in ZephyrRTOS

PCB Resources

Topics:

Heritage designs for future use

Power Circuitry

Buck Converters

LDOs

Sensors

MCUs

Common PCB Standards for SRL Electronics

Debug Capability

Power Systems

Silkscreen

How to bring up a PCB

So you've designed, laid out, ordered, and assembled your PCB. How do you bring life to it?

Steps

Structures Resources

Topics:

  • Creating Drawings
  • Tolerancing Guidelines
  • Design for Manufacturing Guidelines (DFM)

Drawings

Before going to manufacturing,

  • Every flight part shall have an associated drawing signed off by a lead
  • This drawing shall be stored in the OneDrive for future reference
  • Proper tolerancing guidelines shall be observed

Resources for RF engineering

Topics

  • Basics of RF (Fourier Transforms, Gain, Link Budgets, Bandwidth/Bitrate relationship)
  • Basics of Antennas (Gain Pattern, Polarity, Smith Charts, Antenna Tuning)
  • RF Front End (RFFE) High Level Design (Filters, Amplifiers, Mixers, PLLs, ADCs, DACs)
  • RF Layout (Impedance profiles, Hybrid couplers, Rat-race couplers, Stripline/Patch antennas)
  • RF Component Choice (Amplifier characteristics, filter characteristics)
  • Phased Arrays (Array factor, Beam Steering, Angle of Arrival)
  • ANSYS EDT HFSS Resources

Current Projects

Avionics is currently working on a number of projects in parallel.

  1. Phoenix Flight Computer
    • This is the custom flight computer flown on Mamba III and currently being upgraded for Spaceshot. Currently looking for new members with experience in
      • State estimation/Kalman Filter (Simulink, C++)
      • Embedded software (C, C++)
  2. Spaceshot Avionics Bay
    • We will be developing the entire avionics bay structure for Spaceshot. Currently looking for new members with experience in
      • Structures
      • Harnessing
      • Manufacturing (Lathe, Mill)
  3. Ground Station
    • We are currently developing an entire ground station and mission control suite. Looking for new members with experience in
      • Structures
      • Linux software development
      • Full stack web development
      • Embedded software
  4. WALRUS Video Streaming
    • Project in progress to create a system to live stream video from the rocket. Looking for new members with experience in
      • Linux software development
      • Shaders/video compression
  5. Lighthouse Cooperative Radar
    • Project to create a radar system to accurately track the rocket through flight using radio waves. Looking for new members with experience in
      • Verilog
      • Embedded software

Phoenix Flight Computer

The Phoenix flight computer is designed with one goal in mind-- to be the main flight computer for SRL's rockets. It must

  • Record data from onboard sensors
  • Downlink telemetry in flight to aid in recovery
  • Estimate apogee altitude using an Extended Kalman Filter
  • Deploy parachutes at apogee
  • Trigger cameras and various peripherals based on command from mission control

Software Details

Phoenix Software Details

WALRUS Video Streaming

Wireless Array for Long Range Uninterrupted Streaming

Lighthouse Cooperative Radar

In order to get an accurate altitude/position reading on the rocket, we are developing a cooperative radar system. We will uplink a signal from the ground, re-amplify and retransmit it using a repeater onboard the rocket. We will then use ranging and angle-of-arrival algorithms on the ground to determine the position of the rocket.

The signal will be a Pseudo-Random Noise (PRN) sequence. It will be generated by an FPGA, and modulated using Binary Phase Shift Keying (BPSK). The uplink signal will be on the 2.4 GHz HAM band, and the downlink signal will be on the 3.3GHz HAM band.

Ranging

The ranging algorithm will compute the 2-way time-of-flight (TOF) for the signal. It will estimate the TOF by correlating the recieved, demodulated stream with the PRN being transmitted. By timing the difference between correlation peaks, we can calculate the time of flight and get the distance the signal traveled using $ d = c*\frac{t}{2} $ where $c$ is the speed of light and $t$ is the 2 way TOF. The correlation algorithm will be written in Verilog for the Spartan 7 FPGA.

The bitrate of the PRN determines the ranging accuracy. Since we are using BPSK modulation, the bitrate is directly proportional to the signal bandwidth. At the HAM bands we have chosen, the largest bandwidth we can get is 20MHz, which means that we can get a 20 Mbps chip rate. This corresponds to an accuracy of 15 meters radially, which is good enough considering that the rocket will be more than 100km in the sky.

Angle of Arrival

Angle of arrival will consist of three phases.

  1. Initial Pointing

The repeater on the rocket will send out a pure tone beacon at 3.3GHz (only modulated using On-Off Keying (OOK) to comply with HAM laws). The groundstation horn antenna array will use either amplitude angle of arrival or phase interferometry (not sure yet). The gimbal control law will work to point the array towards the beacon source.

  1. Acquisition

Once the gimbal is pointing close enough to the rocket for it to recieve the uplinked PRN, the beacon tone will turn off and the repeater will automatically start retransmitting the PRN. The groundstation will continue to use the coarse angle of arrival algorithm.

  1. Tracking

Since the baseline of the antenna array is 1 meter in the azimuth and elevation axes, the $2\pi$ ambiguity angle will be ~2.5°. Once the coarse tracking gets within this threshold, it will switch to fine tracking, which will use phase interferometry with the 1m baseline to track with a higher accuracy. More details on the fine accuracy can be found in the PDR slideshow.

Antenna Design

Details can be found on the antenna design page.

Antenna Design

Ground side

RX Horn Antennas

TX Helix Antenna

Flight Repeater

COTS Monopoles

We have chosen to use commercial monopole antennas on the flight repeater. The omnidirectional gain pattern is best for a rocket with uncontrolled attitude, and since the ground antennas are circularly polarized we won't get polarization mismatch as the rocket tumbles. Using COTS parts will also reduce development cost and risk.

Spaceshot Avionics Bay

Preliminary wiring diagram

Ground Station Distributed System

The objective of this project is to improve the operational capacity of SRL during launches. The system is designed with the following architecture.

[block diagram here]

This project consists of the following subparts:

Raspberry Pi Central Controller

The Raspberry Pi CM5 with a custom carrier board will be the central node in the system. It will interface with the peripherals (stepper controller PCB, radios) and recieve commands/forward downlinked data to and from the mission control application.

Gimbal

Our avionics structures team has designed, manufactured, and constructed a 2-axis actuated gimbal. We will mount our antennas on it, using the Lighthouse angle of arrival functionality to automatically track the rocket. By tracking the rocket, we can use antennas with higher directionality and improve the link budget.

The gimbal stepper motors are controlled by the stepper controller PCB.