Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
75 commits
Select commit Hold shift + click to select a range
9646b13
feat: add BMS and Fuel Gauge libraries and usage
Dec 12, 2025
ee11403
feat: revise display defines location
Dec 12, 2025
a1d7a9a
feat: begin RSSI FreeRTOS Task structure
Dec 12, 2025
732ea95
feat: add keypad, begin rotary
Dec 12, 2025
f52e6e6
feat: taskify switch demo
Dec 12, 2025
2d642e9
fix: begin use of fallback display demo
Dec 12, 2025
30e8b86
fix: reflect correct display hardware pin mapping
Dec 12, 2025
0e83325
fix: make bms task loop
Dec 21, 2025
72946b5
fix: make adafruit demo rtos friendlier
Dec 21, 2025
c251636
chore: complete drawPowerdown tft update isolation
Dec 21, 2025
690452d
fix: ensure initializers are blocking
Dec 21, 2025
4eaaa88
Create abstract.md
AdrianneQuick Jul 29, 2025
a062a95
Create PDR-July 21.md
AdrianneQuick Jul 22, 2025
dee1cec
Update PDR-July 21.md
RawToast54 Jul 23, 2025
5cd0d1c
Create July 23 - Team Meeting.md
AdrianneQuick Jul 24, 2025
ea3e916
Create July-31-2025-advisor-meeting.md
AdrianneQuick Aug 2, 2025
d993339
Create August 25 - First Meeting of Senior Design 2.md
AdrianneQuick Aug 27, 2025
453dab5
Update August 25 - First Meeting of Senior Design 2.md
AdrianneQuick Aug 27, 2025
07cd924
Create Team Meeting for CDR slide review.md
AdrianneQuick Aug 29, 2025
974756e
Create CDR Meeting Notes.md
AdrianneQuick Aug 29, 2025
831683e
Create Workflow Runthrough #2.md
AdrianneQuick Sep 13, 2025
b3df4c2
Create Workflow Runthrough #3.md
AdrianneQuick Sep 13, 2025
e2e5170
Create Workflow Runthrough #4.md
AdrianneQuick Sep 13, 2025
8ce3343
Create september 4 - Team Slide Review.md
AdrianneQuick Sep 13, 2025
b4e88e6
Create Sept 18 - Members only meeting.md
AdrianneQuick Sep 18, 2025
edb7979
Create Oct 9 Team Meeting.md
AdrianneQuick Oct 12, 2025
a944e1e
Create Oct 10 Advisor Meeting.md
AdrianneQuick Oct 12, 2025
d7c3787
Create Midterm Review.md
AdrianneQuick Oct 12, 2025
c32663a
Update Pin Mapping Table.md
AdrianneQuick Oct 29, 2025
5ad0da9
Create Oct 14 Workshop - PlatformIO.md
AdrianneQuick Oct 16, 2025
8acb72e
Add files via upload
Dominicc1 Nov 6, 2025
187296d
Delete Hardware/KiCAD/audio-modulino/Audio PCB.kicad_pcb
Dominicc1 Nov 6, 2025
3ede033
chore: added MCU modulino Rev A PCB files to testbed
AdrianneQuick Oct 29, 2025
785b87e
fix: make symbolic links relative
Oct 29, 2025
444dbbd
chore: added additional Rev A PCB file to MCU modulino
AdrianneQuick Oct 31, 2025
f81fe04
Delete Hardware/KiCAD/audio-modulino/capstone-project.pretty
Dominicc1 Nov 6, 2025
c036f70
Audio PCB Modulino
Dominicc1 Nov 6, 2025
d1b038e
Delete Hardware/KiCAD/audio-modulino/capstone-project.pretty directory
Dominicc1 Nov 6, 2025
f02173b
Add files via upload
Dominicc1 Nov 6, 2025
6729cda
Add files via upload
Dominicc1 Nov 6, 2025
966a290
doc: added MCU docs and notes
AdrianneQuick Oct 31, 2025
087c4c0
chore: test code for WROVER - i2c, spi, cores, gpios MCU Testing #83
AdrianneQuick Nov 4, 2025
a09166c
Revert "doc: added MCU docs and notes"
AdrianneQuick Nov 14, 2025
0de86d1
Revert "Merge MCU branch with main"
AdrianneQuick Nov 14, 2025
62ae333
Update Pin Mapping Table.md
AdrianneQuick Nov 15, 2025
ee11d0a
docs: organized REV A and REV B pcb and schematic files and put them …
AdrianneQuick Dec 6, 2025
1cab76f
docs: added power modulino schematics for Rev A and Rev B
AdrianneQuick Dec 6, 2025
2c3dbb6
docs: added the correct top-level documentation for the repo
AdrianneQuick Dec 6, 2025
809f778
docs: update README
AdrianneQuick Dec 6, 2025
e96a9dc
docs: update all system schematics for project uniformity
Dec 6, 2025
b7a3611
Audio Reference
Dominicc1 Dec 6, 2025
c2ab6d6
Create PDR-July 21.md
AdrianneQuick Jul 22, 2025
71f30e9
Update PDR-July 21.md
RawToast54 Jul 23, 2025
55e7d2b
Create August 25 - First Meeting of Senior Design 2.md
AdrianneQuick Aug 27, 2025
79a4cd5
Update August 25 - First Meeting of Senior Design 2.md
AdrianneQuick Aug 27, 2025
0fb7258
Update Pin Mapping Table.md
AdrianneQuick Oct 29, 2025
13e927b
Add files via upload
Dominicc1 Nov 6, 2025
a5045c5
Delete Hardware/KiCAD/audio-modulino/Audio PCB.kicad_pcb
Dominicc1 Nov 6, 2025
dcac1cb
Delete Hardware/KiCAD/audio-modulino/Audio PCB.kicad_pcb
Dominicc1 Nov 6, 2025
ed39504
fix: make symbolic links relative
Oct 29, 2025
8b94bed
chore: added additional Rev A PCB file to MCU modulino
AdrianneQuick Oct 31, 2025
40746e1
Delete Hardware/KiCAD/audio-modulino/capstone-project.pretty
Dominicc1 Nov 6, 2025
9a455e8
Audio PCB Modulino
Dominicc1 Nov 6, 2025
819367b
Delete Hardware/KiCAD/audio-modulino/capstone-project.pretty directory
Dominicc1 Nov 6, 2025
5054bf3
Add files via upload
Dominicc1 Nov 6, 2025
927dc2a
Add files via upload
Dominicc1 Nov 6, 2025
399c26c
doc: added MCU docs and notes
AdrianneQuick Oct 31, 2025
bd3da1e
chore: test code for WROVER - i2c, spi, cores, gpios MCU Testing #83
AdrianneQuick Nov 4, 2025
aab0b0d
Revert "doc: added MCU docs and notes"
AdrianneQuick Nov 14, 2025
2191b4a
Revert "Merge MCU branch with main"
AdrianneQuick Nov 14, 2025
fcfc41f
Update Pin Mapping Table.md
AdrianneQuick Nov 15, 2025
67b97a7
docs: organized REV A and REV B pcb and schematic files and put them …
AdrianneQuick Dec 6, 2025
f28e37f
docs: added the correct top-level documentation for the repo
AdrianneQuick Dec 6, 2025
7dcf04e
docs: update README
AdrianneQuick Dec 6, 2025
5bcf155
docs: update all system schematics for project uniformity
Dec 6, 2025
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
109 changes: 109 additions & 0 deletions Documentation/Code_of_Conduct.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,109 @@
# Code of Conduct
OpenAir Lab – Modular Handheld Radio Project

---

## Our Commitment

The OpenAir Lab project is an open, collaborative, educational environment.
We are committed to creating a space where **students, hobbyists, engineers, and contributors of all backgrounds** can participate safely, respectfully, and productively.

We pledge to make participation in our project a harassment-free experience for everyone, regardless of:

- Age
- Disability
- Gender identity or expression
- Level of experience
- Nationality or ethnicity
- Political or religious beliefs
- Sexual orientation
- Socioeconomic background
- Technical skill

We do not tolerate discrimination, harassment, or behavior that makes contributors feel unwelcome.

---

## Expected Behavior

All contributors, maintainers, reviewers, and collaborators are expected to:

### Be respectful and considerate
- Value differing viewpoints.
- Assume good intent from others.
- Provide constructive feedback.

### Communicate clearly
- Use professional, inclusive language.
- Avoid sarcasm, hostility, or personal attacks.
- Ask questions instead of making assumptions.

### Collaborate responsibly
- Follow repository guidelines.
- Review others’ work thoughtfully.
- Credit the work and ideas of others.

### Maintain a supportive environment
- Encourage newcomers.
- Offer help where you can.
- Share knowledge freely.

---

## Unacceptable Behavior

Examples of unacceptable conduct include, but are not limited to:

- Harassment, intimidation, or discrimination
- Insults, derogatory comments, or personal attacks
- Deliberate disruption of discussions or collaboration
- Sharing others’ private information without permission
- Threats of any kind
- Offensive comments related to identity, culture, or background
- Conduct that results in an unsafe working environment (software, hardware, or interpersonal)

Harassment is defined as unwelcome or hostile behavior, including repeated unwanted advances, derogatory jokes, or sustained disruption.

---

## Reporting Issues & Violations

If you experience or witness behavior that violates this Code of Conduct:

### You may report by:
- Opening a confidential issue labeled **"conduct-issue"**
- Contacting a project maintainer directly
- Requesting anonymous escalation to the faculty advisor (if applicable)

All reports will be handled promptly, respectfully, and confidentially.

### Maintainers are obligated to:
- Review and investigate the report
- Respond within a reasonable timeframe
- Take appropriate actions based on the situation

---

## Enforcement

Project maintainers may take the following actions in response to violations:

- A private warning
- Temporary or permanent bans from the repository
- Reverting or blocking contributions
- Escalation to academic or organizational authorities (if necessary)

Consequences will be proportionate to the severity of the misconduct.

---

## Our Responsibility as a Community

Maintaining a healthy environment is **everyone’s** responsibility.
By contributing to the OpenAir Lab project, you affirm that you understand and agree to follow this Code of Conduct.

Let’s build an open, educational, and respectful community—together.

---

*Adapted from the Contributor Covenant v2.0 and tailored for the OpenAir Lab Capstone Project.*
199 changes: 199 additions & 0 deletions Documentation/Contributing.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,199 @@
# Contributing to OpenAir Lab – Modular Handheld Radio Project

Thank you for your interest in contributing to the OpenAir Lab Capstone project!
This repository is intended to be a fully open-source, educational platform for learning RF systems, embedded programming, PCB design, and modular hardware integration.
We welcome contributions from students, hobbyists, engineers, and educators.

This document outlines the guidelines for contributing code, hardware designs, documentation, and issue reports.

---

# Table of Contents
1. [Ways to Contribute](#ways-to-contribute)
2. [Contribution Workflow](#contribution-workflow)
3. [Branching & Pull Request Guidelines](#branching--pull-request-guidelines)
4. [Coding Standards](#coding-standards)
5. [Hardware Standards](#hardware-standards)
6. [Documentation Standards](#documentation-standards)
7. [Issue Reporting Guidelines](#issue-reporting-guidelines)
8. [Community Expectations](#community-expectations)

---

# 1. Ways to Contribute

You can contribute in many ways depending on your background:

### Firmware Contributions
- Implement new subsystem drivers (CC1200, I²C expander, ST7789 display, etc.)
- Improve FreeRTOS task structure or add new features.
- Add example code for modulinos.
- Fix bugs or optimize existing code.

### Hardware Contributions
- Improve module schematics or PCB layout.
- Add testpoints, revise signal integrity, or improve routing.
- Expand the modular ecosystem with new boards.

### Documentation Contributions
- Improve bring-up guides, testing checklists, or diagrams.
- Clarify README sections.
- Add educational explanations for students learning embedded systems.

### Testing & QA
- Run integration tests.
- Report or fix issues found during build, flashing, or board bring-up.

---

# 2. Contribution Workflow

Follow these steps to propose a contribution:

1. **Fork** the repository to your GitHub account.
2. Create a **feature branch** in your fork:
```
git checkout -b feature/<short-description>
```
3. Make changes while adhering to coding, hardware, or documentation standards.
4. **Test thoroughly** (compiles, boots, UI responds, no regressions).
5. Commit using clear messages (see below).
6. Push the branch and submit a **Pull Request (PR)** to the `main` branch.
7. Maintainers will review your PR and may request changes.
8. Once approved, the PR will be merged.

---

# 3. Branching & Pull Request Guidelines

### Branch Naming
Use descriptive names:
- `feature/cc1200-rx-routine`
- `fix/i2c-expander-init`
- `docs/power-modulino-update`
- `hardware/revB-routing-fixes`

### Commit Message Style
Follow this pattern:
```
<type>: <short summary>
Optional long description explaining what changed and why.
```

Types:
- `feat` – new feature
- `fix` – bug fix
- `docs` – documentation changes
- `refactor` – code restructuring
- `hardware` – PCB or schematic changes
- `test` – adding or modifying tests

Example:
```
feat: implement basic SPI loopback test for MCU modulino
```

### Pull Request Requirements
- Provide **clear description** of what was changed.
- Indicate **related issue numbers**, if applicable.
- Include screenshots, logs, or diagrams when relevant.
- Ensure the PR passes any automated checks.

---

# 4. Coding Standards

### General Requirements
- Use **C++17** for embedded firmware (PlatformIO).
- Follow project formatting conventions (braces on same line, 4 spaces).
- Keep code modular (separate driver logic from application logic).
- No hard-coded pin numbers — use `pinmap.h`.

### FreeRTOS Guidelines
- Avoid blocking calls in high-frequency tasks.
- Use queues/semaphores for ISR → task communication.
- Keep ISRs short.

### Error Handling
- Check return codes and failure states.
- Use `ESP_LOGx()` macros where appropriate.

---

# 5. Hardware Standards

### Required KiCad Files
Each modulino hardware directory must contain:
- `.kicad_pro`, `.kicad_sch`, `.kicad_pcb`
- Schematic PDF
- PCB fabrication outputs (Gerber, drill files)
- BOM + iBOM

### Layout Expectations
- Follow Espressif hardware design guidelines.
- Use solid ground planes when possible.
- Decoupling capacitors must be placed close to IC power pins.
- Include silkscreen labels for connectors, testpoints, and critical components.

### Review Expectations
All hardware PRs must include:
- Render images
- Design rule checks (DRC) passed
- Electrical rule checks (ERC) passed

---

# 6. Documentation Standards

Documentation should be:
- Clear and beginner-friendly
- Free of ambiguous or missing steps
- Written in Markdown
- Contain diagrams when helpful
- Stored within the appropriate `/Documentation/` folder

Examples:
- `/Documentation/system_architecture/`
- `/Documentation/testing/`
- `/Documentation/hardware/`

---

# 7. Issue Reporting Guidelines

When opening an issue, include:

### Required fields
- **Description of problem**
- **Steps to reproduce**
- **Expected behavior**
- **Actual behavior**
- **Environment details**
- Board revision
- Firmware version
- Toolchain (PlatformIO/Arduino/ESP-IDF)

### Optional fields (very helpful)
- Screenshots
- Serial logs
- Scope/logic analyzer captures
- Schematics or layout excerpts for hardware issues

---

# 8. Community Expectations

By contributing, you agree to:

- Be respectful and constructive.
- Help maintain a positive, inclusive environment.
- Follow the project’s **Code of Conduct**.
- Write clear, maintainable contributions.

We are building an open-source educational ecosystem—thank you for helping make it better!

---

If you have questions or need clarification, please open an issue or contact a project maintainer.

**Happy building! ⚡📡**
Loading