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.

Join us for the full team new member meeting on 9/2!

Join the SRL Slack and Notion!

Members

Reach out to leads for any questions you may have! (Also if you don't see your name up here, let the avionics team lead know and they will add you! It's an important part of avionics to take pride in and show off what you've done, the experience you've gained, and what you've learned!)

Alex Reich alre8317@colorado.edu - Avionics Team Lead

Allison Byrnes allison.byrnes@colorado.edu - Avionics Hardware Lead

Winnie Regan wire5926@colorado.edu

Kofi Asare koas3551@colorado.edu

To be updated in the fall!

Getting Involved!

Ready to get involved? Follow these steps!

Do everything on the new member checklist.

You can find an updated list of all the current members on the central page. Reach out to the current avionics team lead or the sub-team lead with the topic you're most interested in (electronics hardware, software, RF-specific engineering).

On the slack, join the #avionics channel, #avionics-hardware, and #avionics-software channels.

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 simply send them/him/her your current resume. Whatever your comfortable with! 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!

Documentation on Avionics Testing Rocket

We will document our design process from an avionics perspective on these pages!

Our intention is to fly an L1 or L2 cert rocket with our current board in conjunction with the planned L1 launches for the club. This will allow us to have an early, lower-stakes test flight than on Mamba III.

More to come soon.

This is a page to document how we made decisions on the avionics test rocket

[NOT CURRENTLY UP TO DATE]

Reasoning Behind Not Using Smaller Rocket

It's cheaper to use a smaller rocket, but here is our engineering justification behind not going with that. The main goal of these flights is to test our avionics system to see if it will achieve proper performance on space shot. As far as basic functionality, we will do that on the ground, read data sheets carefully, and be thorough with documentation of our system. For survivability and reliability, this is where we need to test on a real rocket. The goal is to get our system to break. Our system is cheap enough to where we don’t have to care about testing slowly and upwards. We already know we have hardware that, if properly soldered together, can survive an obsidian level flight as well (our previous big rocket flight). Thus, we still believe the cheapest and most time efficient way to have accurate testing is to get our system to break as fast as possible and fix problems from there.

List of considerations:

  • Size
  • Speed
  • Parachute Mechanism?
  • Heat
  • Pressure Range
  • g-loading
  • ESD Requirements
  • Timeline

Current Considerations

The general plan is that we will coordinate with the L1 launch team and use one of their launches, in order to save money for the club. They have generously offered to help us with this, but first we need to provide them with our expected parameters like size, apogee, acceleration etc. to give them an idea of what we need.

SIZE:

As previous years suggested, the diameter should be at least 3 inches, but ideally 4 or 5 so that the components can rest comfortably. This is something that we will have to design once we have all of our components laid out.

MORE TO BE DOCUMENTED LATER

Previous Years' Discussion

Considerations...

SIZE -

For the size, we must be able to fit our entire avionics system, a back-up avionics system (the one that will deploy parachutes and stuff for the first few flights while we are testing basic functionality), and have space to route any thermistors, connectors, battteries, etc.

The Beagle Bone Black (hereby referred to as BBB in this document) has dimensions of 3.4 inches x 2.15 inches x ~ 1 inch. We wanted a 5-inch diameter rocket at first, but soon realized that this would be extremely expensive in terms of the quality of the fuel, amount of fuel, and cost of rocket kit in order to make and launch this rocket (look to the next section about speed for more details on this). Thus, we are going to use a 4-inch diameter rocket which will be able to fit the BBB and BBB cape board (custom electronics attatched onto the BBB) extremely easily when they are positioned vertically. This should offer enough space for even testing more boards at once as well.

SPEED -

For the speed, we want to reach the COCOM limit of the GPS module we are using (which is 1000 knots, or 514m/s, or 1150mph) in order to be able to see how the GPS will turn off, and then also see if it will turn back on again by the time we reach apogee. We originally wanted to see this rocket go above that speed for over 10 seconds. This is because typical GPS modules have a refresh rate of 1 second. We will have to look deeper into the datasheet of the GPS we currently have, determine if we need one with a higher refresh rate or not. The simulations of the 4-inch diameter rocket we are likely to choose results in a speed above 514m/s for only about 1.5 seconds.

PARACHUTE MECHANISM -

For the parachute, we won't be able to deploy them on our early on. For first few flights we want to record when we WOULD deploy our drogue and see how accurate we are with the actual deployment of the COTS solution. The avionics test rocket will have COTS avionics system as the main avionics system until we deem ourselves capable of doing it in-house.

HEAT -

We want to be able to survive the ambient heat. Not much to consider here for now, the avionics bay of our rocket likely won't get that hot. We will have temperature sensors to measure exactly how hot things are getting.

PRESSURE RANGE -

We want to test what our pressure readings are at each height, while we are moving at the speed we are. This will offer very valuable information on how we can use pressure data readings in the future, and how accurate of a model they may provide of our trajectory if we don't adjust them for the speed we move at, or if we do, or if we need to make additional considerations when we reach speeds higher than mach 1.

G-LOADING -

The g-loading requirement is still up for debate. Current rockets we are looking at will have a max-g of around 22g. Currently, we should figure out how we can coat the board, make sure thermals won't go crazy if we do that, and then also test another board inside the rocket that doesn't have coating and see how each performs (do parts fly off during flight).

ESD REQUIREMENTS -

Previous flights have taught us that ESD protection is important for our system (duh, my bad for not implementing something like that on the last board - Andrew Lee), but because this is the first time we are designing something like this, we don't have a perfectly informed idea of the current counter-measures are going to work, and perfectly protect our electronics. Thus, we will first do testing on the ground of the effects of ESD on our system, and then we will decide whether we need some sort of grounding to the rocket frame or something like that.

TIMELINE -

The intention of this rocket is to be able to fly and test custom avionics. It offers some type of real-situation testing without costing the club an arm and leg, and allows us to test more frequently, as opposed to waiting for the yearly big rocket launch. Currently, the team allocates around 1500 dollars a year for our avionics test rocket launches. Each reload of the motor costs around 400 dollars. The first rocket launch will ideally occur at the beginning of the spring semester of 2022. This will be for the absolute minimum viable product, with the core requirement that we are able to take and log data. Afterwards, we will do a lot of testing on the avionics electronics and software (plan in our testing process documentation), and then hopefully launch again with an avionics system we are confident of operating correctly by the end of the semester.

Testing Documentation

NOTE, THIS PAGE IS STILL UNDER HEAVY DISCUSSION AND UPDATES WILL BE COMING SOON, WE WANT TO BE VERY DETAILED ABOUT THIS

This page is to develop a test plan so that we make the most out of each launch. SRL is not rich and we should do our due diligence to make sure we don't waste each opportunity we get to launch!

List of Tests To Perform For

  • RF Signal Integrity
  • Accelerometer Drift (as we integrate to get our position)
  • GPS functionality
  • Pressure readings
  • Data logging capabilities
  • Chute deployment tests
  • Physical shock/vibration
  • ESD Tests (want to start off by shocking a board that only has 1 cheap component soldered onto it (hopefully the most sensitive device to voltage), no need to shock a fully populated board)

Here is the main page for the RF (Radio Frequency) subteam on avionics. The RF team is mainly responsible for enabling wireless communications between our avionics systems.

What is RF?

Do you remember learning about Ohm's Law in your electronics classes? V=IR? Guess what––your professors lied to you! (sort of). In the RF world of high frequency signals, suddenly voltage is now also a function of position. If you could instantenously measure the voltage of a 2.4 GHz Wi-Fi signal at one point to be some positive voltage, a few centimeters away, you would measure 0 volts, and another few centimeters away, the voltage might be negative! All at the same point in time! With DC or low frequency AC signals (e.g. your 60 Hz 120 Vrms wall power), this isn't an issue, because the wavelength of light at 60Hz is almost 5000 km, or slightly over the distance from New York City to Los Angeles. So your instantenous voltage drop at different points in space is in the nanovolt range for practical circuits. In fact, the miniscule non-zero resistance of copper wire is far more significant than low frequency RF effects.

Nontheless, in general, you're in RF land once your longest wire/trace length is an appreciable fraction of the signal wavelength (roughly 10%). For reference, an 8 kHz audio signal has a wavelength of about 37 km, a 1700 kHz AM radio signal has a wavelength of about 175 m, a 99.9 MHz FM radio signal has a wavelength of about 3 m, and a 1575.42 MHz GPS signal has a wavelength of about 2 mm. Keep in mind, the wavelength of light is longest in a vacuum and decreases slightly through a medium such as copper or air.

xkcd1457

Our project

The end goal of this system is to have it fly on Spaceshot. Since the Karman Line is 100km from the surface, that is our required range. We want to stay in the ISM (Industrial, Scientific, and Medical) frequency range (902-928 MHz). We also can assume that we will have "line-of-sight", since the rocket will be in the air. The legal limit for ISM broadcasting is 1 Watt supplied to the antenna, and a maximum power transmitted from the antenna is 4W. Assuming a 30 dBm broadcasting intensity, and free space path loss over 100km to be ~ -130 dBm, we know the reciever has to be sensitive down to -100dBm, at least.

Therefore, we are considering this transciever module. More details to come soon.

Antenna design considerations to come soon.

Video downlink has been postponed to be a very long term goal, considering how expensive and complex a dev campaign for that would be.

Resources

Here are a list of resources that may be useful if you want to learn more about RF.

Very much a work in progress...

Hardware Team

The avionics hardware sub-team develops custom printed circuit boards (PCBs) which gives the software a platform from which they may run on small form-factor hardware, collect and store important data, and eventually implement controls.

New Member Set-Up Guide

This is a page dedicated to making it easier for hardware new members to get set-up and ready to develop hardware.

Here is a list of software that we use regularly:

  • Altium Designer - Circuit & PCB design
  • LTSpice - IC circuit simulator
  • Saleae Logic 2 - Circuit debugging and logic analysis

Note: Altium and Saleae Logic both require a Windows OS.

The majority of this guide will be dedicated to getting set up with our Altium workspace.

Getting set up with Altium

First, visit Altium's Link For Student License. This will allow you to get up and running with Altium - the student license allows you to install the software for free.

You will need to verify your email to receive your student license. Once you've received the verification email and clicked the link to verify your email, Altium will send you another email, this time containing your licensing information. You will need to activate your AltiumLive account and sign in to be able to download and use the installers. Once you have downloaded the executable, follow the installation instructions to fully install Altium.

After Altium is installed, send your email to the hardware team lead. They'll add you to the Altium workspace we're using for Avionics. In the meantime, you can follow some Altium tutorials to get familiar with the software, and the PCB design process in general! Here is a very good intro to PCB design that I highly suggest: Altium Tutorial. It explains what PCB design is, why we use it, all of the terminology used, and walks through making a simple project to get used to Altium.

Now back to getting setup, once you are added to our Altium workspace, in the top-right corner of your window you should see the workspaces button (it might read "Not Connected"). Click this, and look for "CU SRL Yonix".

If you don't see it, restart Altium. If you still don't see it, contact the avionics hardware lead.

After clicking on CU SRL Yonix, you should see a little blue cloud with CU SRL Yonix right next to it in the projects tab. Right click this and click "Open Project".

Select the project you'd like to open, and click the "Open" button.

Download new changes

Whenever Altium first starts up, please right-click the project name and, under History & Version Control, click "Update Whole Project". This ensures you have any changes other members have uploaded.

Adding changes

If you've added work to the Altium document, you'll notice the little green checkmarks next to each file can change to orange or red marks. This indicates there's a pending change to be uploaded.

To upload your changes to the cloud, right-click the project name and, under version control, click "Commit".

If any errors come up, please get in touch with hardware lead - Altium's implementation of Git can be hard to work with sometimes.

Getting LTSpice

Follow the link to go to LTSpice Download Link. This is a useful circuit simulation software. No one in industry will almost ever touch a differential equation because there are so many circuit simulation software things out there. This one is a really good basic circuit simulation software.

Getting Saleae Logic 2

So an old avionics member named Brendan happened to have like 10 of these cheap knock-off logic analyzers. He donated them all to the avionics team, and we will begin handing these out to people as soon as they are needed when we actually start testing. They work with Saleae Logic 2 software, which is nice beacuse the software will automatically talk interpret the one's and zero's on a signal line as long as it's not a proprietary communication method. This is really useful to debugging circuits, testing software, and bringing up our boards.

Some cool resources and guides:

These are all resources that past hardware leads have used to learn more about the tools in this page. They are all confirmed to be really really interesting. All of the tools we use have excellent documentation and finding more resources or guides on them is really easy (just search it up on google). Feel free to ask questions in the avionics hardware channel for any confusion on these topics, we are all here to help!

Altium Licensing

If your license has expired, or you are looking to get a new license, follow this guide. The steps for both refreshing a license and acquiring a new one are the same.

  1. Navigate to this page on Altium Student Licensing.
  2. Fill out the form, being sure to use the account you signed up for Altium with.
  3. Look for an email from Altium. For both renewal and new licenses, the email will look the same - it will ask you to verify your account first, then, once your account is verified (even if it already has been), there will be another email within a few minutes with a subject along the lines of "Student License Information".

Once you get the email for student license information, go to the account symbol in the top right of Altium, and click "Licenses", as shown below.

Licenses button visualization

There should be a new license visible, with an expiration date sometime in the future. Click it and click the "Use" button below.

Development Resources

Here is a list of useful resources that the EE team has used in the past to aid in their development. They are organized by topic.

Altium Designer Guides

This guide is the one that Andrew Lee vouches for. This is how he began his journey learning about electronics design. Eric Bogatin is a professor at CU who is incredibly knowledgeable and famous for his publishings on signal integrity and high speed digital design among many other topics. Altium Designer has had him as a keynote speaker at several of their AltiumLive events. With diligent work, this course will probably take around 2 weeks to complete (or beat Andrew and do it faster, I bet you won't).

Altium Education Student License

Altium is a VERY expensive software for companies to use. Luckily, we get to use this industry standard ECAD tool as students for free.

Understanding the I2C Bus

Picking a GPS...

Documentation of how we are picking our GPS... so this link shows some basic information on GPS. Main take-aways are that u-blox MAX gps's do implement stuff as AND logic (when you exceed 1000 knots (1150mph or 514m/s) AND 18km (altitude) then your GPS shuts down). Note that for a lot of GPS modules that are sold out there, it is implemented as OR logic (which won't work because then we won't be able to get GPS data any point above 18km and therefore we can't confirm if we made it to space or not). Another important thing to consider is that it seems that basically the industry standard is to limit GPS tracking to 50km altitude, not because of COCOM limits but just because companies feel like it lmao (which once again doesn't work for us, we need something that can record up to at the very least 110km or something). Therefore we probably need to come up with a seperate solution. Right now Parker Lamb is working on a GNSS-SDR receiver which would get around both of those limitations. NOTE - This is ITAR restricted, no non-US-citizen may help him.

One other point of confusion is the specifics of COCOM limits... Andrew Lee will look at the official document (hopefully soon) and see if he can figure out what exactly are the limitations. He will add that to the documentation soon. Maybe we could ask a big company super-duper-nicely and promise to advertise their company without our club and as a student org to get them to adjust one of their gps modules so that it's no longer limited to 50km. Or we can ask them if they can offer any sort of mentorship on finding any other types of solutions that we can try to implement that allow us to bypass this all.

On the possibility that the GNSS-SDR is later determined to not be an actual solution, maybe we look into using a GPS module like the one in this link and forget about this for a while. This is still cheaper than the Kate (COTS solution we are currently going to rely on for SpaceShot and Mamba) and therefore still leaves a ton of room for us to create a custom avionics unit that does everything else besides collecting GPS data.

The last option that we currently can think of is getting as many data points before our GPS shuts off and relying completely on accelerometer data for our position after that, and then getting a position fix as we are coming down again and comparing both of those models.

Picking a TVS Diode

The reason why you would use a TVS diode is to protect from ESD discharge. This is an important thing to protect from as it has destroyed some of our past custom designed boards. The basics of ESD can be read in this ESD Basics

A TVS Diode basically a zener diode with a slightly adjusted slope that is specially made to protect electronics systems.

The most important parameter of a TVS diode (transient voltage suppressor diode) is the clamping voltage AKA V_(clamp). This is the parameter which MUST be beneath the tolerable voltage of the system. This is the voltage that the TVS Diode will regulate to when exposed to a transient current waveform that is detailed by the datasheet usually.

V_(rwm) is the same thing as V_(reverse standoff), which is the same as the reverse working maximum voltage. This describes the voltage that you can sit at and you would only have a tiny amount of leakage current (on the order of singular nano-amps which is something that no one cares about). This is generally where you want the nominal voltage of your system to sit at.

V_(breakdown) or V_(br) is the voltage at which you get 1mA (at DC) of current through the diode, and it beings to shunt current through it (provide an almost zero resistance path for current to flow through it). Usually this ends up being way higher than what your system can tolerate.

Note, be careful of the polarity of TVS diodes. Sometimes they work both directions, sometimes they don't.

Here's an application note from Texas Instruments which describe the most important things to consider when choosing a TVS diode. TI AppNote TVS Diodes

Logic Analyzer Guide

These resources came from Lyon, the avionics lead of 2019, he gives the thumbs up of approval that these are good introductory ways to familiarize yourself with the basics of navigation.

NASA Handbook on Sounding Rockets

Zoe Roy found this amazing resource for NASA's takes on how sounding rockets should be made.

Design Process

This is the page which explains how avionics will organize its hardware projects. The objective of documenting this general process is to give students an idea of how electronics product development is often carried out by industry. Learning and becoming familiar with the design process is just as important as learning how to use Altium Designer to design a PCB.

Currently this is still considered a draft. Avionics members are encouraged to critically think about the existing design process and constantly consider ways to improve the effectiveness and robustness (if that's a word) of it. Reach out to a team lead if you think something may be improved and they will let you know if you should add it to the documentation.

Phase 1: Requirements Breakdown

This beginning phase is to make sure everyone is on the same page of what the board should look like and do. This is an important step for any kind of project, even if you are not working on a team because you will come to realize that there is a TON of gray space. It's important to define the scope of the project before it begins.

This phase begins the new project design process. Everything from this phase should be able to be accomplished in one kick-off meeting with everyone involved with the project (team lead and any other oversight included).

In the meeting, the following should be decided/discussed and/or documented:

  • What requirements of the avionics system will this board address? OR How does this board bring us closer to developing the final avionics system?
  • What are the requirements of this board? Start with functional requirements and then break it down. Some things that might be easy to miss include where human interfaces shall be, what connector interfaces shall exist, what sensors should be on the board, where is power sourced from, how much power should the board produce, cost, how many to produce, etc. (NOTE: This is not at all an all-inclusive list, think as far as your imagination will allow of things you might be asking yourself later in the design process, this does get a lot easier with experience, and no student is perfect at this by any means)

Phase 2: Preliminary Design Work

Here is the phase where you need to do the analysis that informs your design. Every single thing done in this step should be documented for later reference. Any MATLAB scripts or simulation files need to be stored. As of writing this, the google drive will the expiring soon, so we need to figure out a better way to do that... ask Andrew to update this once he figures that out (which should be soon).

Here is a list of things that might be a part of this step (currently all I can think of off of the top of my head, potentially a lot that can be added here):

  • Napkin drawings of the board and block diagrams
  • Power budget
  • Link budget (this is RF territory, just throwing it out there)
  • Circuit simulation (LT Spice)
  • Interface control document
  • Efficiency calculations (maybe best done as a MATLAB script)

Phase 3: The Fun Part! Design Time!

Here is where you actually begin designing. Hopefully the prior steps have prepared you enough to tackle this comfortably... My one piece of advice is if it's your first time reading a datasheet or designing something then pick a big semiconductor manufacturer and read one of their datasheets back-to-back. It's really annoying, but just trust that I wish I had told myself that long ago. The small text and notes under tables are SO useful and can really be make-or-break in some cases.

Because of the chip shortage, one more tip during this step is to start with all of the major ICs but don't even place them on schematics. Just pick them all out, make sure that all of the specs match (i.e. if you need all of your ICs on this board to be powered from 3.3V, then make sure that is true for all of the ICs you choose), that we can actually solder the package, that the part is going to work. Place all of the parts on a purchase order document and buy them. Often, you will be in the middle of a design and lose supply of a part, and then become stuck in a hell-loop of remaking all of your schematic symbols and footprints over and over again. It is honestly not worth stressing over 5 dollars of shipping. Make sure you update inventory as soon as you recieve the parts!

To add on a little more, the low priority parts (resistors, diodes, capacitors, etc.) should be chosen with a very common standard footprint and have huge in-stock amounts (hundreds of thousands preferred). This means that these parts will be unlikely to go out of stock, and if they do when it comes time to order them, you can just replace them with another part with the same exact footprint without having to change your design (make sure you update the BOM to match the new design item ID you are using though).

In broad strokes - and if may be worth breaking this process down further into seperate documents - the following should be done:

  • As mentioned above, choose all major ICs and order them (do your due diligence, do not waste SRL money, you should write out justification for each part)
  • Start making all schematic symbols and footprints. See if you can re-use footprints (or maybe even entire parts) from previous projects
  • Create the structure of the PCB project, how will you organize your schematic sheets to make readability as easy as possible?
  • Start and finish your schematic. Request review from the hardware team-lead and avionics lead
  • Shape your PCB to the correct shape. Determine your layer stack-up. Place all components in such a way to minimize cross-talk, improve ease of routing, efficiently use space, make sure everything fits, isolate analog signals from digital signals, etc. Request review from hardware team-lead and avionics lead
  • Route your PCB. Start with high-priority traces (i.e. high-speed signals). Request review from hardware team-lead and avionics lead
  • Overall design review. Make sure the current design will address the requirements laid out in Phase 1.
  • Bill of materials creation (BOM), and order the rest of the parts, and update inventory

Phase 4: The Bitter-Sweet Part! Board Bring-Up!

Good work getting to this phase. This is where you solder everything together and get it to actually work. The soldering part is pretty sweet. It's a lot of fun to see the project you've been working on come to life. The bitter part is when you have to debug the board if there are any issues... if any issues do arise, it may potentially takes hours upon hours to figure out where the issue really lies.

In another set of broad strokes...

  • Make sure inventory is fully updated
  • Find a time when the school lab is open and at least one other person on this project is available to help board assembly. If it's your first time, then ask the hardware team-lead to also help mentor.
  • First solder on the surface mount parts using the reflow oven then hand-solder everything else. Update inventory as you go along soldering components on. This is why you want two people. One will solder and place components, the other will be on the computer telling the first person the design item ID and reference designator to place the part on and also updating inventory. It is encouraged that you switch-off to make sure that everyone gets the full experience. It's not extremely often that we are given the opportunity to actually get hands-on experience when it takes so long to develop our boards.
  • Check solder joints using a microscope
  • Check continuity on all power rails. Also check to make sure there are no shorts from a power rail to ground (that will ruin the board and potentially all the components as well if not caught at this stage)
  • Probably at a later date, upload software and do a functional test. At this point, you should re-visit the requirements and validate that your entire project has met all the requirements listed. You're in big trouble if some of the requirements haven't (a costly mistake, but we will forgive you)

List of Companies that Often Hand Out Free Samples

Credit to Brendan Haines for coming up with this list! This is a list of companies who are usually willing to give out free stuff as samples!

Connectors (sample anything)

Connectors (limited selection)

Connectors (limited selection?, limited quantity, sometimes very long lead times without notification, I think I've had sample orders disappear silently)

Power and RF ICs (limited selection, limited quantity)

ICs (I'm not clear on their sample policy but lately have had good success lately)

RF filters and ICs (limited selection, limited quantity)

List of Past Projects

Adaptor Board

The purpose of this project was to develop and test a sensor system on the Obsidian rocket flight. The adaptor board was meant to be one that connected the main microcontroller (Beaglebone Black) to the rest of the stack, but was re-purposed when the team decided to push to launch Obsidian.

We did not start good documentation practices back in the day, so the only thing we have from this is past purchase orders, and a zipped file with our Altium Designer project.

Project Personnel

Project Lead: Andrew Lee and Ben Pera

Project Reviewers: Jason Popich and Zoe Roy

Software Team

The avionics software sub-team develops custom software to run on a beaglebone black and additional hardware, with the goals of telemetry collection and storage, drogue and parachute deployment, and telemetry downlink software.

New Member Guide

Table of contents

  1. Background
  2. Pre-Install Prep
  3. Installing FPrime
  4. Learning FPrime

Background Information

For software development we are using the FPrime framework (sometimes written as F') for C++ developed by JPL. In order to develop software you must first understand the basics of C++ as the more advaced concepts can be learened as you work through the tutorial. If you have completed CSCI1300(or equivalent) and CSCI2270(or activly taking 2270) than you will learn all the basics you need in class. If you have not completed 2270 this video is recommended for learning all of the basics.

A Linux operating system or image is required for self installation. Because many of our new members will be using windows, we are working on hosting a server which will run linux and solve all the issues that come with VMs and things. Updates to come.

If you want to install FPrime on your own computer, use the following instructions. This guide will use macOS as an example, but the commands in linux will be the same unless otherwise specified. Windows users should install WSL to follow these commands.

Pre-Install Setup

Software Requirements

  1. Unix based OS (macOS or Linux)

    • Windows can use wsl with a debian based image, or a virtual machine
    • See Avionics lead or Software lead for a copy of the vm image

  2. git

    • Here is a good tutorial for git

  3. CMake 3.16 or higher

  4. GCC or Clang

  5. Python 3.7+ with pip

  6. Vim

    • In depth knowledge is not really need, just understand how to edit a few lines and save
    • Here is a good vim tutorial

  7. VSCode

    • While another editor could be used, most developers use VSCode and a list of recomended plugins will be provided

Software install

Needed software

Ensure all software listed above is installed with your package manager of choice. On macOS brew is recomended.

brew install CMake gcc git python@3.10 vim

Python venv

If using a debian based image it is possible not all needed python packages are installed, fix this by installing them with

sudo apt install git cmake default-jre python3 python3-pip python3-venv

We can now begin the virtual enviroment creation

A virtual enviroment (venv) allows for different packages to be installed at different versions within python and mitigate version conflict errors

Pick a location to install the virtual enviroment. For the purposes of this guide we will use the $HOME directory as our root. If you would rather use another location feel free.

python3 -m venv $HOME/fprime-venv
. $HOME/fprime-venv/bin/activate
pip install -U setuptools setuptools_scm wheel pip

The first command creates the venv, the second command activates the venv, and the third command installs some needed packages.

To exit the virtual enviroment simply enter deactivate while the venv is active.

Adding an alias to your shell profile can be useful to quickly activate the venv from any directory Using macOS and zsh as an example we can execute the following commands to add it as an alias

cd $HOME
vim .zshrc

linux users will need to modifly the file ~/.bashrc Add the following line at the end of the file and save

alias fpvenv=". $HOME/fprime-venv/bin/activate"

Ensure to update your terminal with . ~/.zshrc Now typing fpvenv will activate your virtual enviroment

Github Setup

We recomend linking your student email to Github for the student pro benefits Found Here.

If you already have a working git and github with 2FA setup skip to FPrime Install

Generating SSH keys

We first generate a ssh key with the line below

ssh-keygen -t ed25519 -C "your_email@example.com"

When you're prompted to "Enter a file in which to save the key", you can press Enter to accept the default file location. When prompted for a passphrase you can press Enter to skip.

Ensure the ssh agent is running

eval "$(ssh-agent -s)"

For macOS verify the ~/.ssh/config file exists

open ~/.ssh/config

and add this information the the config file.

Host *.github.com
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_ed25519
  IgnoreUnknown UseKeychain

If the file does not exist create it with and then add the information

touch ~/.ssh/config

For both macOS and Linux

ssh-add ~/.ssh/id_ed25519
Adding the SSH key to Github

copy the ssh key public information to your clipboard

pbcopy < ~/.ssh/id_ed25519.pub

In Github go to settings > Access> SSH and GPG Keys and select new SSH key. Give it a meaningful title, ensure it is an authentication key, and paste your clipboard into the key box. Then press the Add Key button.

To verify that it has worked run and type yes when prompted

ssh -T git@github.com

You should see

> Hi USERNAME! You've successfully authenticated, but GitHub does not
> provide shell access.

if this does not display check here

VSCode Setup

I recomend installing the following plugins to your VSCode, along with connecting your github to VSCode for sync between devices.

For using VSCode in conjunction with F', the recomended way is opening the srlFp directory in VSCode, and cd your shell into the srlFp/Ref directory.

FPrime Install

Note that all commands should be executed within the virtual enviroment created above

Clone the repo

In your prefered directory($HOME or Desktop is recomended) clone the srl FPrime repo

git clone git@github.com:CU-SRL/srlFp.git
cd srlFp
pip install -r requirements.txt

Verify install

On the tutorials branch verify that the Ref deployment builds

cd Ref
fprime-util generate
fprime-util build
fprime-gds -g html

use git checkout <branch> to switch branches

Learning FPrime

Before begining the tutorials checkout a branch for your work from tutorials. There is no need to push this branch, this will just be for your personal use.

git fetch -a
git switch tutorials
git checkout -b <BRANCH NAME HERE>

You are able to now start on the Getting Started Tutorial found here.

There are a few extra terms that are common that should be highlighted:

  • Drv: short for driver, contains a variety of different drivers including uart, i2c, and spi drivers for linux
  • Fw: short for framework, provides a large number of useful data types and routines
  • Fpp: short for FPrimePrime, a modeling language to make F' development quicker and easier than before
  • Svc: short for Service, provides useful runtime tools for fprime deployments
  • Os: short for Operating System, provides the Operating System Abstraction Layer(OSAL) for fprime

For working on the Math Component Tutorial found Here I recomend focusing on following the steps given in in sections 1-4, then reading the goals in section 5 and attempting to implement them without copying from the tutorial until needed.

Developing Fprime

[TO BE UPDATED]

This page will act as a top-down walkthrough of what the deployment development process looks like. New deployments can be created for any intended purpose, however for the time-being we make our changes in Ref for simplicity, as much of the setup is already done. Within the deployment, there are a variety of components, connected with a topology. When adding a new component (say, for a sensor), we need to create a directory within the deployment:

Adding a new sensor

The process for adding a new sensor can be broken down as follows

  1. Create sensor dir with fpp, CMake, cpp, and hpp files
  2. Add it to the deployment CMake file, and fill out component CMake file
  3. Run touch <componentname>ComponentImpl.cpp and touch <componentname>ComponentImpl.hpp. This creates "invisible" versions of the file, so that they exist. Trying to implement without these files touched could cause issues.
  4. After fully filling out the fpp, fprime-util impl the component (it should build without error at this point)
    • The Tlm is recomended to run with on change link
  5. This should have produced cpp and hpp file templates. Just rename these to the ComponentImpl.cpp and hpp files you had previously created.
  6. Include the component in Top/Components.hpp along with the extern reference
  7. Include the compeonet in Top/RefTopologyAc.hpp
  8. Add the instance to Top/instances.fpp
  9. Add the instance and connections to Top/topology.fpp
  10. Fill out and complete the cpp and hpp files
  11. Comment the functionality, then make sure it builds
  12. Ensure the pins are configured correctly with config-pin

Configuring Drivers

When implementing drivers, be sure to do the following:

  1. Look into the both the driver function handlers, as well as the driver ports
  2. In the component fpp file, include the corresponding driver ports, and add any relevant events if desired
  3. In topology.fpp, include the instance of the driver, as well as add the connections for whichever devices are using it
  4. In instances.fpp, again create the instance of the driver, but also add any and all specifications for initialization such as base id, type, and location (remember to leave room for offset for ids)

    • In this file we also chose to make our open calls for said driver,using the following syntax to insert cpp code into our fpp file:

      phase Fpp.ToCpp.Phases.configComponents """ {insert code here} """

    • Look here for more information on every phase, and their intended uses

  5. In Component.hpp, include componentimpl header file for the driver and add the driver extern
  6. In Topology.cpp, add the component impl, initialize the component, and do any necessary checks for the previously metioned open call

BBB Notes

The bashrc used:

alias route="sudo route add default g2 192.168.7.1"
alias runDep"chmod 777 ~/Ref; ./Ref -1 192.168.7.1 -p 50000"

make sure pins are configured properly with config-pin <pin number> <pin mode>

check i2c device connections with

i2c-detect -y -r <bus-number>

Cross-Compilation

The BeagleBone uses an arm-32 architecture. As such, the cross compilation steps from this tutorial.

FURTHER NOTES:

The bbb toolchain is now missing from the dev branches, if you are using the Deb 10 VM provided by avionics add the following to srlFp/cmake/toolchain/bbb.cmake

set(CMAKE_SYSTEM_NAME           Linux)
SET(CMAKE_SYSTEM_VERSION        1)
SET(CMAKE_SYSTEM_PROCESSOR      arm)

set(CMAKE_C_COMPILER "/opt/gcc-arm-linux/bin/arm-linux-gnueabihf-gcc")
set(CMAKE_CXX_COMPILER "/opt/gcc-arm-linux/bin/arm-linux-gnueabihf-g++")

set(CMAKE_FIND_ROOT_PATH  "/opt/gcc-arm-linux/arm-linux-gnueabihf")

set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

assumes the installed binutils are found in /opt but can be installed anywhere as long as the path is adjusted

If you are interested in using Clang, look at this. Currently we use gcc and the arm binutils to cross-compile but are interested in eventually switichng to clang for both performance and convenience.

Documentation

We have a history of poor documentation in SRL, and as developers in general. We are solving that with 2 exersices: 1. Suggesting that people comment their code using the doxygen style, using plugins and 2. Realizing that FPrime is complex enough that trying to remember why you did something is hard.

Our standard style for funciton comments uses the JAVADOC/C-STYLE as shown here with a simple addition function:

/**
* \brief (Short description here)
* (Longer in depth description here)
* 
* \param x (what is this input)
* \param y (what is this input)
* \return (what is the return)
*/ 
int function(int x, int y){
        int temp; /*  What does this member var do   */
        tmp = x+y
        return tmp;
}

It is also important to use annotations in the fpp code in order for the autocoder to create comments for you, see here for more information.

When merged into main, doxygen automatically runs and executes on the documentation branch.

Buffers

An important aspect to note about the linux communication drivers provided by Fprime is that they take Fprime Buffers as inputs, as opposed to standard buffers made in C. Using Fprime Buffers is a three step process: allocating out the required space, serializing it with the relevant data, then deallocating said memory. A more in depth explanation on this process can be found here.

Toplogies

Depending on how old the documentation you are looking at, a topology may be using direct graph specifiers. For most connections however (in the topology.fpp), you can use pattern graph specifiers. This will make your life a whole lot easier.

Running the Groundstation on Windows

If you are trying to connect to the beaglebone and run the groundstation on your local machine, and then collect data, you will need to do a couple of things. Go to Windows Defender Firewall, then advanced settings, adn from there Inbound Rules. Select the four rules that contain

Nice aliases to have

There are certain aliases that are nice to have that make quality life a lot better in terms of running the avionics:

For all aliases, these are just example paths, use whatever works best for you.

alias fprime="source /fprime-venv/bin/activate" alias bbbconnect="ssh debian@192.168.7.2" alias sendover="scp /SRL/RefTopologyAppDictionary.xml debian@192.168.7.2:/deployment/dict; scp $HOME/SRL/Ref debian@192.168.7.2:/deployment/bin;" alias runGDS="fprime-gds -n --dictionary ~/SRL/RefTopologyAppDictionary.xml"

Development Notes

Collection of links to useful resources

F prime Documentation

Our own documentation

JPL's documentation v3.1.0

Both of these links are useful in learning Fprime, as the SrlFp repo grows more sensor documentation will be present for review.

Fprimeprime User's Guide

F Prime Prime Wiki

The Fpp wiki provieds a very well documented resource for learning, modifying, and developing fpp files. We use fpp to automate most of the boiler plate required for F Prime code to run.

Notes for getting familiar with Fpp (some subsections to be particularly aware of) :

Fixed point to Floating point conversions

Fixed to Float

When dealing with sensors, we commonly see output in fixed point format as opposed to the more common computing floating point format. To convert between fixed point(Also called Q format) the link above provides plenty of background on the topic.

Common Issues Faced

FPrime GDS - Version Problems

  • First purge, generate, and build. You should see a build-artifacts folder: this indicates that it built correctly. Go into this folder:
    • Ref/build-artifacts/Linux/dict
    • The dictionary file will be the xml file in there. At the top, there is a framework_version, set that version to 3.1.0
    • Relevant github issue

Beaglebone Black Setup (Debian OS)

  • When compiling and building on your local machine, it is possible that you have a different compiler version being used compared to that used by the bbb.

    • The beaglebone black runs Debian 10, and by default uses GLIBC version 2.28

    • To check this on any machine, run the following command:

      ldd --version

    • The compiler version of the machine that the code is compiled on needs to match the version that the executable is being run on. Currently we have a virtual machine set up with the correct compiler version being run, from which we can send over the generated binary executable

    • It is bad practice and potentially dangerous to downgrade the compiler version being used on your machine, so if you for example run GLIBC version 2.35, don't try to change what version your computer uses. Your operating system is meant to run on the compiler version that it comes with, so don't try to change it. That is why we use a VM to compile with the correct version.

    • To get the executable onto the beaglebone black, use scp:

      scp {RELEVANT DIR}/Ref debian@192.168.7.2:~

    • From there you need to make sure you give it the appropriate permissions to be able to run it:

      sudo chmod +x Ref

  • Setting up said VM:

    • After cloning the repo, installing the tools, then building on the machine, run the following to get the proper tools installed:

      sudo apt install crossbuild-essential-armhf

    • The beagleboneblack toolchain on the github has the correct path of CMAKE already set up, so use that toolchain to generate and build

  • We did try to upgrade the GLIBC version on the beaglebone, which involved several of the following tools. We never finished this process however because we got a VM working sooner. Therefore it isn't necessary, but potentially worth finishing in the future:

Internet access with host for bbb

List of Current Projects

Here you can see the different directions we will be taking over the course of the semester!

In Progress

  • RF Downlink - It is important that we get live data from the rocket streamed to the ground in-flight. Further documentation at the link.
  • Sensor Suite - The sensor suite has been mostly completed by the team in years past. Our job this year is to diagnose and fix any of the lingering issues to increase the robustness of the board.
  • Recovery - The goal of the flight computer is to be able to control the entire rocket, which includes recovery. This year we will be adding pyro channels to the board to fulfill this requirement.

Completed

Sensor Apps in Development

Currently, we have developed an adaptor board for the BeagleBone Black which houses several sensors including pressure/temp, accelerometer, gyro, and magnetometer. This coming semester (F2024) we will be fixing some remaining bugs on that board, as well as adding a GPS. Work for sensors specifically will be done in the sensorDev branch, which when finalized will be merged with the dev branch. After testing is completed on the dev branch and we feel confident in a final version of our code, it can be merged into main. Be careful when merging to main, as these should be finalized versions of our programs and will autogenerate documentation. The code that goes here should also be properly commented following C-style guidelines.

Our sensor suite topology will consist of a deployment in conjunction with the FPrime groundstation running on the BeagleBone Black.

Project Assignments

The assignment process will entail the creation of a GitHub issue that will be assigned to an individual/group of individuals. They will then create a branch from the development that will contain all the code needed. Upon completion of the work a pr will be opened and meeting with software lead to review code.

Datasheets

Link to hardware page for the future sensors, picked by the hardware team: testing board links

Datasheets will be added here soon.

GPS testing

{TO BE UPDATED}

We will be incorporating a GPS module into our avionics setup, with the main purpose of using the data we pull from it, as well as data we pull from an altimiter, and cross compare the two sources. It will be a means of verifying whether we are collecting reasonable and accurate data, especially the peak altitude that we hit.

With using a GPS, velocity and altitude lockouts will be very prevelant, and be a reason that it doesn't go onto the final rocket. However, for intermediate testing it will serve a very important role. We currently have gps code on the repo that is provided by JPL, that will run as a sanity-check of sorts. This will be a way for the software team to start cross-compilation and deploying code as soon as possible.

Datasheet

Link to the datasheet of the gps we will be testing:

BeagleBone Black Toolchain

The beaglebone black toolchain will allow us to cross compile on our local machines or vm connections, allowing for execution of fprime on the beagle bone black. We currently have a raspberry pi toolchain already on the fprime repo, but in order to test on the hardware we develop, we will need to write a toolchain for the beaglebone black.

Immediate testing can be done on a raspberry pi, as the immediate priority is to write apps for reading data from sensors. Once we hit this development benchmark and know we are able to get some data, we can make the switch from the raspberry pi to beaglebone black.

List of Past Projects

Here you can see the past iteration of the avionics software framework that had been in development over the past few years.

Over the 2022 summer, the software team came to the decision to pursue an alternative path for software development, that being switching which framework we use. The reason we've diverged from using cFS is fairly lengthy, but can be summed up like this: F' is much more lightweight and suited for our intended purposes, unlike cFS which had many aspects that we were nowhere close to using in terms of our laid out timeline. This made cFS not only difficult to program for, but even led to hardware troubles since our micrcontroller didn't have enough processing power to properly run it. If you have any questions about that decision, or just want to know more about it, feel free to reach out to the current software lead on slack.

Note: On the CUSRL github, there are even older versions of the avionics systems created in the past, such as the CUSRL_Avionics repo, that you're welcome to browse if interested.

Core Flight System (cFS)

The cFS system was a collection of sensor applications built off of NASA's cFS to read and write to/from sensors. It failed to run properly on the BeagleBone Black board due to a suspected scheduler degredation surrounding the linux install.

SRL cFS Repo contains all code developed while cFS was our primary platform. For more information reach out to the current software lead, Jason Popich, or Zoe Roy.

COSMOS Ground Station

COSMOS is a ground station developed by Ball Aerospace, that the software team had taylored to to be the receiving end of telemetry from the flight computer. Apps were developed on this platform that specfically correlated to apps created on cFS, and allowed for specific customization of the ground station.

SRL_COSMOS Repo is where you can find the code developed by while this was still used. If you would like to learn more about this project, reach out to the current software lead, Jason Popich, or Zoe Roy.

This ground station may still be used on the future for the purposes of RF communication, however the team will currently make use of the web-based ground station that comes with F'. For the sake of ease and faster development, the use of COSMOS is going on hold until we reach a point where it can be efficiently incorporated into our development plan.

Current Projects

Here is a list of our current projects! These are opportunities to get involved with!

Testing Board

The Testing Board project is a platform we design and test software and hardware on. It involves designing a custom Printed Circuit Board (PCB), writing software to work on sensors embedded on that PCB, and testing the system.

It is designed primarily as a proof-of-concept demo platform, and will not be implemented on the final rocket. That said, practices and designs implemented on the Testing Board will likely see usage on the final product.

Project Personnel

Project Lead: Parker Lamb

Project Reviewers: Andrew Lee

Issue Tracker

Purchase order sheet: sheets.google.com

Project tracker: https://github.com/orgs/CU-SRL/projects/1

This should be used when new tasks are created, in progress, or completed.

Datasheets

Sub-pages

Testing Board Requirements

Sensor Requirements

The following sensors should exist on the board.

  • Accelerometer
  • Gyroscope
  • Magnetometer
  • Temperature sensor (digital)
  • Thermistor
  • Barometer

There shall be at least one sensor that is used for SPI AND I2C.

Each sensor shall be broken out into their own respective connectors.

Other ICs

There must be a GPS receiver module that can be added to the board.

There must be a CAN bus transceiver. This must be broken out into a connector.

Microcontroller must be broken out for the programming connector.

Microcontroller should have two LEDs connected to two seperate GPIO pins.

System Requirements

  • All devices run on 3.3V
  • Decoupling capacitor on all devices
  • ESD protected
  • 4 layer board (signal, ground, power, signal)
  • All devices must have a datasheet
  • Have an LED power indicator

Purchasing Requirements

  • Entire bill of materials should be under 50 dollars (not including PCB or shipping or 0603 components already in inventory)

Layout Requirements

  • The placement of switches shall be organized and sectioned for each sensor
  • The text overlay on the board shall clearly communicate the function of each set of switches

ARM Cortex M33 Notes

These are some basic notes on the ARM Cortex M33 device we're using.

Cortex Details

We're using the 48-pin QFN ARM Cortex M33 - the pinout is available on figure 1.6 on page 15 of the datasheet.

Port Reference

  • SPI_SSLAx: Slave selection pins (x is 0-3)
  • SPI_MOSI_A: Data output from master (Master Out Slave In)
  • SPI_MISO_A: Data output from slave (Master In Slave Out)
  • SPI_RSPCK_A: Clock pin
  • I2C_SDA2: Serial Data line
  • I2C_SCL2: Serial Clock line

Our Setup

We have two SPI-connected devices (accelerometer and magnetometer), and 5 I2C-connected devices (accelerometer, pressure sensor, gyroscope, magnetometer and temp sensor).

Since 2 of the 4 SPI chip select ports double as I2C inputs on the MCU, we only have 2 accessible SPI ports.

SPI Notes

Serial Peripheral Interface has four relevant ports: SSLAx (connected to chip selects), MOSI (data from master to slave), MISO (data from slave to master), and RSPCK (the clock).

Since the MCU can only communicate with one SPI device at a time, it must "choose" this device. It does this by activating one of the SSLA (Slave Select Low Active), by settling the SSLA for that device to active low.

Therefore, you need a single SSLA pin per SPI device. The MCU has 4 SSLA pins, so it is able to support up to 4 SPI devices.

LDO(LT3080)

Datasheet

Goal of Application: Drop from 4.2 V to a consistent 3.3 V. Also known as a DC-to-DC step-down converter.

Specific Part: LT3080EDD#TRPBF

https://www.digikey.com/short/hdhdfn83

Notes: DD Package, 8-Lead DFN (3mm x 3mm)

Cost: $6.40

Typical Application

3.3V Application

$$V_{out} = R_{set} \cdot (10 \times 10^{-6})$$

$$R_{set} = V_{out} \cdot 10 \times 10^{6}$$

$$R_{set} = (3.3) \cdot 10^5 = 330 \text{ k} \Omega$$

Application of LDO in LTSpice.

What is an LDO?

  • A Low Dropout Regulator(LDO) is a voltage regulator that can get a regulated low output voltage from a higher input voltage.
    • The output is steady, low noise, DC.
    • This is compared to a Linear Voltage Regulator, which requires a higher voltage drop to function as designed.

LDO Parameters

Quiescent Current (IQ) - Current drawn by system when light or no load is connected

Power Supply Rejection Ratio (PSRR) - Ability to reject AC elements of source(e.g. ripple voltage). The datasheet of the LT3080 simply calls it "Ripple Rejection".

Defined by: \(20\log(\frac{V_{ripple, in}}{V_{ripple,out}})\)

Ex: Let \(V_{ripple, in}=2 \text V\) & \(V_{ripple, out}=0.2 \text V\)

$$\text{PSRR} \vert_{dB} = 20\log \left(\frac{V_{ripple, in}}{V_{ripple,out}} \right) = 20 \log \left(\frac{2}{0.2} \right) = 20 \text{ dB}$$

Ex: Let \(V_{ripple, in}=2 \text V\) & \(V_{ripple, out}= 2 \text {mV}\)

$$\text{PSRR} \vert_{dB} = 20\log \left(\frac{V_{ripple, in}}{V_{ripple,out}} \right) = 20 \log \left(\frac{2}{2\times10^{-3}} \right) = 60 \text{ dB}$$

Note: For the PSRR relating to our current application of the part, refer to the "Ripple Rejection, Single Supply" graph. If the \(V_{IN}\) and \(V_{CONTROL}\) pins are powered by different sources, then refer to the "Ripple Rejection, Dual Supply" graphs.

Load Regulation - Ability to maintain specified output voltage under varying load conditions

\(\text{Load Regulation} = \frac{\Delta V_{out}}{\Delta I_{out}}\)

Applications Information

  • For minimizing board leakage: recommends encircling the SET pin and circuitry with a guard ring operated at a potential close to itself, tied to the OUT pin.

  • \(V_{IN}\) must be more than 0.1V to 0.5V greater than the output voltage. This depends on the current that needs to flow through the load. For more information, refer to pages 4 and 8 of the datasheet.

  • There must be a minimum load current of 1 mA

OUTPUT CAPACITOR 2.2u

  • Capacitor must have an ESR(Equivalent Series Resistance) of 0.5 Ohms or less
    • How to find the ESR of a capacitor is explained here
  • Materials with a low ESR include: Ceramic, Tantalum, or low ESR electrolytic

A Note on Ceramic Capacitors

  • Ceramic capacitors are manufactured with a variety of dielectrics, each with different behavior across temperature and applied voltage
  • Most common dielectrics are specified with EIA temperature characteristic codes of: Z5U, Y5V, X5R, X7R
  • Z5U, Y5V dielectrics are good for providing high capacitances in a small package, but tend to have strong voltage and temp coefficients
  • X7R or X5R are better to use, but be aware of their temperature characteristics
  • Try not to find a ceramic capacitor with a piezoelectric response. (It's no requirement, but MIL-STD-202 testing is vibration testing.)

Additional Purchased Components

330K Resistor

ERA-3AEB334V

https://www.digikey.com/short/nzfdzw40

Notes: 0.1% Tolerance, 0.1 W Power Rating(This is fine)

Cost: $0.35

1u Capacitor

C0603C105K8PAC7867

https://www.digikey.com/short/z8pd0t38

Notes: Tolerance: 10%, Temperature Coefficient: X5R, Rated Voltage: 10V, Package: 0603, ESR: 0.008 Ohms < 0.5 (Source: LTSpice). Normally stocking, RoHS compliant, has datasheet. Has gone through MIL–STD–202 testing. Optionally, you could buy another as a bypass capacitor of the 330k resistor. The LDO’s datasheet claims that would lead to “improvement in transient performance” and reduction of system noise.

Cost: $0.10

2.2u Capacitor

C0603C225K8PAC7867

https://www.digikey.com/short/4v45dvz4

*Notes: Tolerance: 10%, Temperature Coefficient: X5R, Rated Voltage: 10V, Package: 0603, ESR: 0.017 Ohms < 0.5 (Source: LTSpice). Normally stocking, RoHS compliant, has datasheet. Has gone through MIL–STD–202 testing.

Cost: $0.23

Ceramic Capacitors

ESR Frequency Characteristics

Source

In an ideal capacitor, the impedance is: \( Z = \frac{1}{\omega C} \). Plotted logarithmically, this looks like:

However, when a real-world capacitor is analyzed, we get a different result:

Data from MCASL168SB5225MTNA01 Capacitor compared with idealized impedance.

In real-world capacitors, there is some power lost due to dielectric substances (the stuff that goes in between the plates of the capacitor, e.g. ceramic), electrodes (the physical metal plates in a capacitor), among other things. We can accurately approximate all of these losses by saying there is some Equivalent Series Resistance (ESR), that changes with the frequency of the input.

Additionally, there is parasitic inductance at high frequencies, that can be approximated with an Equivalent Series Inductance (ESL).

Together, along with a resistor in parallel to the capacitor to represent leakage, we have a much more accurate model of how a real-world capacitor operates.

Putting the model into practice, we can now explain various parts of the real capacitor's impedance plot.

How to find an ESR value of a capacitor

ESR as a function of frequency

Source

The ESR, above all, is an approximation. It is a value that changes with respect to the frequency of the input. The ESR can be calculated by:

$$ \text{ESR} = \frac{\text{D.F.}}{2\pi fC} $$

  • \(\text{D.F.}\) is the Dissipation Factor. It is often given as a percentage. It could also be given as: \( \text{D.F.} = \tan (\delta) \) where \( \delta\) is the “Loss angle”
    • \(f\) is the frequency in which the value of \(\delta\) was measured
  • \(C\) is the listed capacitance

The "loss angle" is a representation of how inaccurately the capacitor is able to get its desired impedance.

When it comes to getting a graphical representation of ESR, it is not reccomended to try and make one up yourself using the formula. Many producers of capacitors have free tools on their websites. You can use them to get a graphical representation of a capacitor's impedance and ESR.

These tools include Murata's SimSurfing, KEMET's K-SIM Capacitor Analysis, or Samsung Electro-Mechanics' MLCC Component Library. (MLCC is an abbreviation for Multi-Layer Ceramic Capacitor.) There are many other tools, by many other names. If you find a part, and want to learn more about it, then digging around on the manufacturer's website for a bit will usually reward you with some way to access the ESR graph directly. It's often tucked under a tab like "Products"/"Components", or one like "Design Analysis Tools". Worst come to worst, you might have to select the capacitor you want on their website and somewhere near it will be a button to "simulate" or "graph" it.

To use these tools, generally it will require you to select a part(in this case, the capacitor you want to simulate). If it doesn't immediately show you a graph, then somewhere on the page you can select a "graph type" or "frequency characteristic". |Z| (or "Impedance") shows a graph of the capacitor's impedance, R (or "ESR") shows a graph of the capacitor's ESR.

These are much more precise tools than calculating it oneself, as the frequency a company measures their Dissipation Factor at can vary. You might even be able to find how the capacitance changes with respect to temperature!

Single ESR value

If there is a single value given to represent the ESR, the frequency of the input is the capacitor's self-resonant frequency. At this point, the impedance of the real capacitor is \( |Z| = \text{ESR} \)

This can be seen through a provided plot that shows the ESR value and measured impedance of a capacitor with respect to the input frequency. Notice how they intersect at the self-resonant frequency, the "bottom of the hump":

MCASL168SB5225MTNA01 Capacitor's impedance compared with ESR.

LTSpice has a database of capacitors if a single ESR or ESL value is needed. Just create a capacitor, right click it, and click on "Select Capacitor". This might be a good resource if you need to get a value specifically for a Linear Technologies (Analog Devices) part. Otherwise, I would stray away from it. The values they give are often very different from what the manufacturers specify.

SMD(Surface Mount) Package/Case/Size

Source

The following is a table of codes standardized by the EIA(Electronic Industries Alliance) regarding package sizes. Not just capacitors can go in these packages.

Out of these, the 0603 package size is reccomended as it is relatively easy to solder.

Temperature Coefficients

Source. I will also be using this catalog to provide the occasional example.

Classes

Temperature coefficients are generally separated by classes. The most common classes are Class I and Class II. Class III does exist, but its use cases are far more narrow.

Class I: Great stability with respect to temperature, voltage, frequency, and time (aging). However, Class I capacitors have very low capacitance values.

Class II: Available for a much wider range of capacitance values; however, temperature has a greater impact on capacitance. Ideal for bypass or coupling applications. Affected by temperature, voltage, frequency, and time.

Class III: Even higher range of capacitance values. Most efficient in terms of space, but worst when it comes to stability. Only use if the stability of capacitance is of little to no value. Could work in a bypass or coupling application.

C0G(NP0)

The main Class I capacitor still in production is the C0G(NP0).

Class II & III Capacitors

The temperature coefficients of Class II & III capacitors are organized as such:

For example, the X5R capacitor will operate from -55 C(X) to 85 C(5) with a capacitance change of at most ±15%(R). This can be seen with the example below:

It is important to note that all that is guaranteed with an X5R capacitor is that the % Capacitance stay inside the red box.

The primary Class III capacitors still in production are Z5U and Y5V.

Here is an example of a Y5V temperature coefficient:

Relevant Calculations and Simulations for Testing Board

The following simulations are from Ash Tribble. Simulation of the LT3080 part from under-voltage

Larger picture of graph...

Transient voltage dip (2ms voltage dip)...

Power Budget For The Board

Power Consumption of Testing Board

List of parts and their peak current consumption:

  1. GPS Ublox_NEO-6 Module - 67mA (47mA average during max performance acquisition mode)
  2. STTS75M2F Temperature Sensor - 100uA (75uA operational average, 1uA standby average)
  3. DPS310XTSA1 Pressure Sensor - 345uA (38uA operational average high precision, 1 temperature and 1 pressure reading per second)
  4. MLX90395KGO-BBA-101-SP Magnetometer - 250mA start-up for less than 3uS (4mA operational average)
  5. ADXL343BCCZ-RL Accelerometer (X2) - (140uA typical)
  6. I3G4250D Gyroscope - (6.1mA typical)
  7. LT3080EDD#TRPBF PMIC - (17mA typical)

Adding all of the maximum values yields a maximum supply current consumption of 341mA.

Adding all of the average operational values yields average supply current of 75mA.

Power Consumption of BBB

We are powering the device using 3.7V battery (not 5V test conditions) and not powering a display. This means we take (idle current with display - idle current without display = display current) and then take (loading a webpage AKA computational stuff IDK - display current = estimated average current consumption). This estimated average current consumption is 360mA.

As part of a factor of safety because I don't know how current consumption changes as our voltage supply changes and they only provide data for 5V supply, I will do P = IV and solve the current consumption at 3.7V such that at 5V and 3.7V, the amount of power the BBB consumes is the same.

This is equal to 487mA.

Available Power

A single one of our Li-ion batteries holds 1.25Ah of total supply current.

Factor of Safety

For a factor of safety, because of how expensive a launch is, let's call it 2.

Thus, the amount of total average current consumption is equal to (BBB power + Testing Board power = Total Power). This is 487mA + 75mA = 562mA. Multiply by 2 to account for our factor of safety and we get 1122mA. This means we get 1.25 / 1.122 = 1.1131 hours of system on-time off of one battery.

New Member On-Boarding Process Documentation

Documenting the on-boarding processes have been used in the past, noting what has gone right and what should be changed.

[PAST YEARS] For hardware, this year we will begin with a soldering workshop using cheap solderable breadboards, basic LEDs, resistors, and anything else the team needs to be soldered right now. The goal of the workshop is to get new members excited about creating something, introduce electronics concepts to people who have no experience, give them a framework for how they can imagine the design that they will be doing in Altium Designer.

The workshop will cover the topics of through-hole soldering, surface mount soldering, multimeter usage, circuit basics if there are new members not familiar with those concepts, explanation of what parts look like, what the parts do, what an IC is, maybe some wire stripping, splicing, etc.

Then Andrew Lee is planning on giving an introduction to Altium Designer lecture. The workshop happened on a friday evening, he will probably go over stuff on the following avionics full team on Sunday and let people get a list of things to get set up with Altium Designer on Saturday (or maybe do this on Friday if we end earlier than expected). He will record this video this time around, be in-person to help out.

Then after assessing the amount of new members, we will cater our projects to match that. If there are a lot, we may begin with development of break-out boards just to help build basic experience, or kick-off a new sensor board project with GPS module which will be seperate from the testing board. Update the documentation after the first avionics meeting with new members to develop that plan.

NOTE: There were 17 people who showed up out of the 29 that joined the slack channel. 7 out of 17ish people joined from talking at classes. In new member meeting during breakout, 3 new members went to hardware, 6 to software, 8 to RF

There were also 3 more people that joined later.

Sub-team leads are doing new member on-boarding meetings this week (hardware on friday and software on saturday night). The attendance to each was:

  • 5 new members showed up to the hardware meeting
  • 10-ish new members showed up to the software meeting