Skip to content

Commit 488a66d

Browse files
balotofibalotofi
committed
updated obc
1 parent 55d5472 commit 488a66d

File tree

13 files changed

+749
-193
lines changed

13 files changed

+749
-193
lines changed

‎_site/index.html

Lines changed: 1 addition & 1 deletion
Large diffs are not rendered by default.

‎eps-members/eps-faq.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,6 +2,7 @@
22
title: EPS FAQ
33
parent: For EPS Team Members
44
layout: default
5+
nav_exclude: true
56
lang: en
67
---
78

‎obc-members/com-pic.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
---
2+
title: Com PIC
3+
parent: For OBC Team Members
4+
nav_order: 5
5+
# permalink: "/obc/overview"
6+
# nav_exclude: true
7+
layout: default
8+
lang: en
9+
---
10+
11+
# Com PIC Communication Guide
12+
13+
The **Communication PIC (Com PIC)** is responsible for managing all communication between the satellite and the ground station. It acts as the interface between the Main PIC and the onboard transceiver. This division ensures a clear separation between command processing and radio interface management, which is particularly useful in didactic missions like BIRDS.
14+
15+
At system startup, the Com PIC is powered on by the **Reset PIC**, which controls and monitors power distribution for all PICs.
16+
17+
**Estimated time to complete:** 7 minutes
18+
{: .label }
19+
20+
---
21+
22+
## Communication with the Main PIC
23+
24+
- **Interface used:** UART
25+
- **Direction:** Bidirectional
26+
- **Data exchanged:**
27+
- Commands for transmission
28+
- Continuous Wave (CW) signals
29+
- Payload data
30+
- **Data size:**
31+
- Commands: Typically 5 bytes (can vary by mission)
32+
- Payload: Variable, up to 255 bytes depending on buffer configuration
33+
- CW: Fixed-size Morse code patterns, ~8 bytes including header
34+
35+
**Notes:**
36+
- The Com PIC listens for packetized commands from the Main PIC.
37+
- A simple command protocol is used where the first byte is a header, followed by command type, payload length, and payload.
38+
39+
---
40+
41+
## Communication with the Transceiver
42+
43+
- **Transceiver model:** ADDNICS
44+
- **Number of pins used:** 11
45+
- **Interface used:** UART
46+
- **Direction:** Bidirectional
47+
- **Data exchanged:**
48+
- Commands for transmission/reception control
49+
- Downlink payload data
50+
- Telemetry reports
51+
- **Data size:**
52+
- Transmit command: Typically 4–6 bytes
53+
- Payload: Up to 255 bytes
54+
- Telemetry status: ~10 bytes
55+
56+
**Pinout example:**
57+
58+
| Pin | Signal | Direction | Description |
59+
|-----|--------|-----------|------------------------|
60+
| 1 | TX | Output | Data to transceiver |
61+
| 2 | RX | Input | Data from transceiver |
62+
| 3 | PTT | Output | Push-to-talk control |
63+
| 4-11| GND, VCC, etc. | — | Power and grounding |
64+
65+
**Notes:**
66+
- The UART baud rate is typically set to 9600 or 19200 bps.
67+
- Error-checking such as checksums or CRC may be applied in software before sending data.
68+
69+
---
70+
71+
## Example Use Case
72+
73+
1. Main PIC compiles a packet of telemetry data.
74+
2. It sends a "send packet" command to Com PIC via UART.
75+
3. Com PIC parses the command and forwards the data to the transceiver.
76+
4. Com PIC waits for an acknowledgment or handles timeout based on configured retry policy.
77+
78+
---
79+
80+
## Next Steps
81+
82+
- Learn more about [Reset PIC →](/obc/reset-pic)
83+
- See how the Main PIC coordinates transmission [here →](/obc/main-pic)
84+
- Explore the [Ground Segment Command Flow](/comm/command-flow)
85+

‎obc-members/define-mission-specs.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,6 @@
11
---
2-
title: How to Define Mission Specifications
3-
# nav_order: 2
2+
title: How to Define Mission Specifications (Template Included)
3+
nav_order: 2
44
parent: For OBC Team Members
55
layout: default
66
lang: en
@@ -9,6 +9,9 @@ nav_exclude: true
99

1010
# How to Define Mission Specifications (Template Included)
1111

12+
**Estimated time to complete:** 7 minutes
13+
{: .label}
14+
1215
> After reading this guide you can find the [accompanying template to fill here](https://birds-project.com/open-source/pdf/template_mission-req.docx) and an [example document here](https://birds-project.com/open-source/pdf/example_mission-req.docx).
1316
>
1417

‎obc-members/flash-memory.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
title: Flash Memory Allocation
3+
parent: For OBC Team Members
4+
nav_order: 6
5+
layout: default
6+
lang: en
7+
---
8+
9+
# Flash Memory Guide
10+
**Estimated time to complete:** 8 minutes
11+
{: .label }
12+
13+
This guide explains the role and structure of flash memory on the OBC (On-Board Computer) board. Flash memory is used to store housekeeping (HK) and mission data from various subsystems, which can later be downlinked to the Ground Station. Communication between the OBC and these memories is handled via **SPI**.
14+
15+
---
16+
17+
## Overview of Flash Memory Usage
18+
19+
Flash memories are shared between the OBC and peripheral subsystems. These are non-volatile memories used for storing telemetry, payload data, configuration states, and communication-related logs.
20+
21+
- **Communication Interface**: SPI
22+
- **Memory Sector Size**: 64 kB
23+
- **Main Partitions**:
24+
- **Main FM**: Primary flash for core OBC operations
25+
- **Shared Mission FM**: Shared by all mission subsystems
26+
- **Shared COM FM**: Shared for communication subsystem needs
27+
28+
---
29+
30+
## Flash Memory Map Summary
31+
32+
Below is the memory allocation template. Each row describes a type of data, its address range, and the sectors it occupies:
33+
34+
| Data Type | Address Range | Sectors | Size (kB) | Used In |
35+
|----------------------|---------------------|---------|-----------|------------------------|
36+
| SAT_Log | `0x00000000` - `0x00170000` | 0–23 | 1536 | Main FM, COM FM |
37+
| Reset_HK | `0x00190000` - `0x01850000` | 25–389 | 23360 | Main FM |
38+
| Address Location | `0x01870000` | 391 | 64 | Main FM |
39+
| Address Data | `0x01880000` - `0x018A0000` | 392–394 | 192 | Main FM |
40+
| Flag Data | `0x018B0000` | 395 | 64 | Main FM |
41+
| RSV_Data | `0x018C0000` - `0x01900000` | 396–400 | 320 | Main FM |
42+
| FAB_HK | `0x01910000` - `0x02BC0000` | 401–700 | 19200 | Main FM |
43+
| FAB_CW | `0x02BD0000` - `0x02EE0000` | 701–750 | 3200 | Main FM |
44+
| Mission STATUS | `0x02EF0000` - `0x03200000` | 751–800 | 3200 | Shared Mission FM |
45+
| PMSN APRS Data | `0x03210000` - `0x03840000` | 801–900 | 6400 | Main FM, Shared COM FM |
46+
| I-C Data | `0x03850000` - `0x03E80000` | 901–1000| 6400 | Shared Mission FM |
47+
| RMSN CAM Thumbnails | `0x03E90000` - `0x041A0000` | 1001–1050| 3200 | Shared Mission FM |
48+
| RMSN CAM Images | `0x041B0000` - `0x044C0000` | 1051–1100| 3200 | Main FM, Shared COM FM |
49+
| TUM Payload Data | `0x044D0000` - `0x04B00000` | 1101–1200| 6400 | Main FM, Shared COM FM |
50+
| ADCS Data | `0x04B10000` - `0x05140000` | 1201–1300| 6400 | Main FM |
51+
| TLE (GPS) Data | `0x05150000` - `0x05460000` | 1301–1350| 3200 | Main FM, Shared COM FM |
52+
53+
---
54+
55+
## Key Notes
56+
57+
- **Address Location** stores the *starting address* of data logs; this address is updated on boot and overwrites old data.
58+
- **Address Data** contains structured metadata (e.g., flag and HK addresses) used by the OBC firmware.
59+
- **Flag and RSV Data** are used for system state management and reserved operations.
60+
- **Mission Subsystems** (like Paraguay, Moldova, and Rwanda missions) store their payload data in designated shared areas.
61+
- **ADCS & GPS** store telemetry relevant to satellite orientation and positioning.
62+
63+
---
64+
65+
## Best Practices
66+
67+
- **Avoid Overwriting**: Some memory areas (e.g., Address Data, Flag Data) overwrite older content—ensure your firmware handles this safely.
68+
- **Mission Isolation**: When allocating new memory for a mission, ensure no overlap with existing sectors.
69+
- **Clear Sector Mapping**: Always update the sector map and inform team members of changes to avoid conflicts.
70+
71+
---
72+
73+
## Visualization
74+
75+
Below is an example **memory map diagram** :
76+
77+
<style>
78+
.mermaid .pieChart text {
79+
fill: white !important;
80+
}
81+
</style>
82+
83+
```mermaid
84+
pie title Flash Memory Allocation (by sector count)
85+
"SAT_Log [1536kB]" : 24
86+
"Reset_HK [23360kB]" : 365
87+
"Address Data location [64kB]" : 1
88+
"Address Data [192kB]" : 3
89+
"Flag Data [64kB]" : 1
90+
"RSV_Data [320kB]" : 5
91+
"FAB_HK [19200kB]" : 300
92+
"FAB_CW [3200kB]" : 50
93+
"Mission STATUS [3200kB]" : 50
94+
"PMSN APRS payload data [6400kB]" : 100
95+
"I-C [6400kB]" : 100
96+
"RMSN CAM Thumb [3200kB]" : 50
97+
"RMSN CAM IMG [3200kB]" : 50
98+
"TUM payload data [6400kB]" : 100
99+
"ADCS [6400kB]" : 100
100+
"TLE [3200kB]" : 50
101+
```

0 commit comments

Comments
 (0)