Documentation

Start here

ESP is a student club at SAIT for embedded systems and hands-on projects, open to every SAIT student. Our flagship project is a 3U CubeSat, run by the exec team with a selected project team. These docs are the shared rulebook for both: if two people would otherwise do something two different ways, the answer should be written here.

Working drafts, meeting notes and anything not ready for the public live in the exec workspace. When something is settled, it moves here.

Onboarding

Club members

1. Sign up on the join page. There's no screening.
2. Join the club chat using the invite in your welcome email.
3. Complete the lab safety walkthrough with an exec before using any bench equipment.
4. Install Git, KiCad and the ESP32 toolchain listed below.
5. Come to a build night and pick a starter project or a workshop.

CubeSat team

1. Apply through the CubeSat application with an essay, then meet the execs in person.
2. Once accepted, accept the GitHub organisation invite and clone your subsystem repository.
3. Read the requirements and interface documents for your subsystem.
4. Pick a starter task from your team's board and pair with someone for your first design session.

Tools we use

Everything here is free for students. Install what your team needs; everyone needs Git and KiCad.

Document numbering

Every controlled document and design file gets a number so reviews can reference it without ambiguity. The format is ESP-SUB-TYPE-NNN, followed by a revision letter.

Example: ESP-EPS-SCH-003 rev B is the second released revision of the third schematic from the power team.

Revisions start at rev - for drafts. The first released version is rev A. Bump the letter any time a released document changes.

Repositories and Git

• One repository per subsystem, named esp-com, esp-eps and so on, plus esp-sys for whole-satellite budgets and ICDs.
• Each repository has the same top-level folders: hardware/, firmware/, docs/ and test/.
• main is protected. Work on a branch, open a pull request, and get one review. Changes to an interface need a reviewer from the team on the other side of it.
• Commit KiCad projects with their libraries so anyone can open them. Don't commit generated fab outputs; attach them to a release instead.
• Tag releases with the document number and revision, for example ESP-EPS-PCB-001-revA.

PCB design rules

• Stack boards use the PC/104 outline and the shared header pinout defined in ESP-SYS-ICD-001.
• Two layers are fine for prototypes. Flight boards default to four layers with a solid ground plane.
• Name power nets with their voltage, for example +3V3, +5V, VBATT. Signal nets use capitals and underscores.
• Every rail gets a labelled test point. Every board gets its document number, revision and the ESP mark on the silkscreen.
• Run DRC with the club rule file before any review. No board goes to fab with unresolved DRC errors.
• Prefer parts with automotive or extended temperature ratings, and check stock at two distributors before committing to one.

Firmware conventions

• Flight firmware targets the ESP32-S3 with ESP-IDF and its FreeRTOS. Structure code as ESP-IDF components, one per driver or service.
• C11 with the repository's .clang-format. Format before you commit.
• No dynamic memory allocation after start-up. Size buffers at compile time.
• The task watchdog is always on in flight builds. Every task has to check in.
• Every command and telemetry packet is defined once, in the ICD, and generated into code from there.
• Log with severity levels. Flight builds keep warnings and errors in non-volatile storage.

Design reviews

Reviews are where we catch mistakes while they're cheap. Each one is a meeting with people outside the team, working from a package sent out a week before.

1. Concept review. Is the mission worth doing and achievable with our resources?
2. Preliminary design review (PDR). Does the architecture meet the requirements? Are the interfaces defined?
3. Critical design review (CDR). Is the detailed design complete enough to build the flight model?
4. Test readiness review (TRR). Are procedures, equipment and hardware ready for a test campaign?
5. Flight readiness review (FRR). Is the satellite ready to hand over to the launch provider?

What goes in a review package

• Requirements and how the design meets each one
• Block diagram and interface list
• Power, mass and link budgets, with margins
• Top risks and what's being done about them
• Open questions you want the reviewers' help on

Lab safety

Nobody uses bench equipment before an exec has walked them through this section in person.

Electrostatic discharge

Wear a wrist strap on a grounded mat whenever you handle bare boards or ICs. Keep parts in their bags until you place them.

Soldering

Run the fume extractor. Wash your hands after soldering, especially with leaded solder, and never eat at the bench. Park the iron in its stand every time you let go of it.

Lithium batteries

• Never charge unattended, and charge inside a fire-resistant bag.
• Use a charger with the right chemistry and cell count. Check for swelling before every use.
• Damaged or swollen cells go into the sand bin and get reported to an exec.

Bench power

Set the current limit before you connect anything. Bring new boards up with a low limit and watch the current as you power on.

Radio licensing

Listening is open to anyone. Transmitting is not. In Canada, transmitting on amateur bands requires an Amateur Radio Operator Certificate from Innovation, Science and Economic Development Canada (ISED), starting with the Basic Qualification.

Amateur satellites also need frequency coordination through the International Amateur Radio Union (IARU) well before launch. The communications team owns that application; start it as soon as the radio band is chosen.

Members who want to operate the ground station are encouraged to study for the Basic Qualification. The club will run a study group.

References

• CubeSat Design Specification: the standard every CubeSat is built to, from Cal Poly.
• Canadian Space Agency: CubeSat programs, including CUBICS.
• ISED Canada: amateur radio certificates and spectrum rules.
• IARU: amateur satellite frequency coordination.
• SatNOGS: open-source ground station network and decoders.
• KiCad documentation: the manual for our PCB tool.
• Espressif documentation: ESP-IDF and ESP32-S3 datasheets and guides.

Editing these docs

These pages live in the club website repository as plain HTML. To change something, edit public/docs.html on a branch and open a pull request, or ask an exec to make the change. Keep sections short and specific: if it takes more than a screen, it probably belongs in its own controlled document.