By Jakub Grędzicki — 23 Oct 2026

Model satelity KubiSat - praca inżynierska

Polski skrót pracy inżynierskiej

Skąd się wziął projekt

Przy wyborze tematu pracy inżynierskiej typowe propozycje (CRUD, standardowe aplikacje mobilne) były zbyt wąskie względem zainteresowań: elektronika, oprogramowanie wbudowane, techniki kosmiczne. Zaproponowany został własny temat - model satelity w formacie CubeSat, prowadzony od koncepcji do działającego urządzenia.

Cel pracy inżynierskiej:

Opracowanie oraz wykonanie od podstaw modelu mikrosatelity zdolnego do lotu na balonie stratosferycznym, z podstawowymi pomiarami oraz testem komunikacji na odległość.

Motywacja praktyczna: gotowe moduły space-grade są drogie; przy budżecie konsumenckim da się zbudować model 1U pod misję HAB (High Altitude Balloon), zachowując architekturę zbliżoną do nanosatelitów.

Projekt po obronie trafił do open-source jako KubiSat.

Co to jest CubeSat w tym kontekście

CubeSat to standard nanosatelity o masie rzędu ~1–2 kg i wymiarach będących wielokrotnością jednostki 1U ≈ 100 × 100 × 113,5 mm. Studenckie i amatorskie konstrukcje często zaczynają od 1U/2U; misje użytkowe bywają 3U+.

KubiSat to model 1U pod lot balonem, nie satelita orbitalny. Ograniczenia projektowe są jednak „kosmiczne w miniaturze”:

szerszy zakres temperatur niż typowa elektronika użytkowa,
GPS mający sens do dużych wysokości (rzędu dziesiątek km),
spadek pojemności baterii w zimnie → ostrożny projekt zasilania i obudowy,
komunikacja half-duplex na dystansie użytecznym do śledzenia / komend.

Wymagania (skrót z pracy)

System miał m.in.:

wysyłać pomiary do stacji naziemnej na żądanie lub cyklicznie,
przyjmować zdalną zmianę konfiguracji,
logować dane czujników i podsystemów do pamięci nieulotnej (SD),
weryfikować poprawność przesyłanych danych,
raportować anomalie przez system zdarzeń,
mieścić się w ograniczeniach czasowych (np. odpowiedź na komendę w rzędu sekund).

Wynik końcowy: operacyjny model + prosta stacja naziemna.

Architektura systemu

Całość to dwa sprzężone moduły:

Warstwa	Zawartość
Sprzęt	procesor, sensory, LoRa, GPS, zasilanie, PCB, obudowa 1U
Oprogramowanie	firmware satelity, most naziemny LoRa↔UART, aplikacja Operator

Podział na trzy niezależne PCB (złącza własne) pozwalało rozwijać i testować sekcje osobno - power, controller, sensory.

Wszystkie płytki: KiCad → produkcja JLCPCB (jak we wpisie na blogu - od schematu do obsadzonej płytki).

Warstwa sprzętowa

Moduł zasilania

Wymaganie z bloga / pracy: energia na cały lot HAB z GPS + sensorami + LoRa włączonymi oraz zapas na odnalezienie modelu po zbłąkaniu.

Element	Rozwiązanie
Magazyn	2× 18650 Li-ion 3,7 V / 2000 mAh (szeregowo → pojemność pakietu ~4000 mAh przy napięciu pakietu)
Ochrona ogniw	DW01A + FS8205A (okno ok. 2,4–4,3 V)
Ładowanie USB-C	TP4056 CC/CV, prąd ~780 mA (kompromis termiczny w zamkniętej obudowie)
Ładowanie solarne	CN3791 MPPT, panele ~5,5 V / 110 mA / 0,55 W; cztery panele na ścianach (szereg)
Szyna 5 V	buck LN2220, sprawność ~90% przy ~120 mA
Monitoring	INA3221 (I2C): ch1 bateria/USB, ch2 szyna 5 V, ch3 prąd solar

Rząd wielkości czasu pracy:

~40 mA → teoretycznie ~100 h (bez strat i bez GPS „pełną parą”),
z GPS w trybie wysokiej wydajności (~80 mA) → łącznie ~120 mA → ~33 h,
typowy lot balonu ~3 h → komfortowy zapas na odzysk.

Po locie model jest odzyskiwany - stąd pełnoprawne ładowanie USB na ziemi + eksperyment PV w powietrzu. Przy kwadratowej podstawie najwyżej dwa panele są jednocześnie w pełnym oświetleniu.

Moduł sterujący (OBC + radio + GPS + RTC + SD)

Podzespół	Rola
RP2040 (Pico)	dual-core Cortex-M0+ @ 133 MHz; rdzeń 0 = komunikacja, rdzeń 1 = GPS + telemetria + zapis SD
SX1278 LoRa 433 MHz	half-duplex, SPI @ 8 MHz, +18 dBm; RX ~12 mA / TX ~93 mA / standby ~1,6 mA
NEO-6M GPS	NMEA-0183 ~1 Hz, dokładność pozycji ~2,5 m; zasilanie przez DC-DC z EN na GPIO; backup CR2032
DS3231 RTC	TCXO, ±3,5 ppm (−40…+85 °C); wspólna bateria z backupem GPS; znaczniki czasu pomiarów
SD 2 GB	osobna magistrala SPI; telemetria, sensory, event log

W trybie lotu (zasilanie z baterii) GPS ma pozostać włączony - odnalezienie modelu jest ważniejsze niż oszczędzanie energii; wyłączenie GPS zdalnie jest blokowane w trybie bateryjnym.

Moduł czujników

Płytka celowo prosta: 5 V + I2C + SPI, nagłówki 2,54 mm (do 4 sensorów naraz).

Czujnik	Pomiary	Uwagi
BME280	ciśnienie 300–1100 hPa (±1), T −40…+85 °C (±1), RH 0–100% (±3)	~3,6 µA @ 1 Hz; ciśnienie → niezależny szacunek wysokości (~8,3 m/hPa nisko)
BH1750	1–65535 lx	marker „słońce / cień” przy analizie temperatury

(W późniejszym rozwoju repozytorium pojawiły się też ścieżki pod IMU - poza zakresem oryginalnej pracy inż. opisanej w PDF.)

Obudowa

Fusion 360, zgodność z 1U (100 × 100 × 113,5 mm),
6 części FDM: 4 narożniki + 2 bazy (grubość baz 10 mm),
dystanse poliamidowe 22 mm → stos PCB + dystanse = 93,5 mm (bez naprężeń na obudowę),
mocowania paneli 70 × 70 × 3 mm na ścianach bocznych,
dostęp do baterii / USB od dołu, sensorów od góry.

Warstwa programowa (firmware satelity)

Język: C++, Pico SDK, build CMake (VS Code). Szczegóły po angielsku: wpis o architekturze firmware.

Boot

Init HW: UART0 (debug/comms), UART1 (GPS), GPIO/LED, I2C0 (INA3221+RTC), I2C1 (sensory), zasilanie GPS/sensorów, SystemStateManager.
Peryferia: radio, mount SD, logi, init BME280/BH1750 → flagi w state managerze; ramka potwierdzenia po radiu.
Detekcja trybu: USB vs bateria (PowerManager + INA3221).
Start rdzenia 1: kolektor GPS, pętla telemetrii, obsługa żądania bootloadera.
Finalizacja: status, event „init done”, pętla główna rdzenia 0.

Model komunikacji

Dwa interfejsy, ten sam protokół tekstowy:

UART0 @ 115200 - lab / debug / passthrough GPS → u-center,
LoRa SX1278 - łącze zdalne.

Ramka (wersja z pracy inż.):

KBST;<kierunek>;<op>;<grupa>;<komenda>;<wartość>;<jednostka>;TSBK

Pole	Znaczenie
`KBST` / `TSBK`	znaczniki start/stop
kierunek	`0` ziemia→sat, `1` sat→ziemia
op	`GET` / `SET` / `RES` / `VAL` / `SEQ` / `ERR`
grupa / komenda	podsystem i ID polecenia
wartość / jednostka	payload, opcjonalnie `V`, `mA`, `s`, …

Limit pakietu LoRa 255 B → ~235 B na dane; dłuższe odpowiedzi idą jako sekwencja SEQ + VAL z SEQ_DONE.

Przykłady:

KBST;0;GET;1;1;;TSBK           → wersja firmware
KBST;0;SET;7;1;1;TSBK          → GPS power on
KBST;1;VAL;3;4;25.25;C;TSBK    → temperatura układu RTC

Komendy są w tablicy handlerów z jawnymi prawami dostępu (read/write) - operator nie powinien wprowadzić systemu w stan nieokreślony.

Główne grupy (praca inż.): diagnostyka (1), zegar (3), eventy (5), GPS (7), telemetria (8).

(Repozytorium open-source później dociągnęło m.in. SEQ+CRC-16, beacon zdrowia, watchdog - patrz software/FIRMWARE_STATUS.md i software/commands.md.)

Podsystemy firmware (jak w rozdz. 4 pracy)

Podsystem	Rola
SystemStateManager	flagi: SD, radio, sensory, tryb USB/bateria, verbosity, pause GPS, … (mutex rekurencyjny)
PowerManager	jedyny dostęp do INA3221; progi low/full/solar/USB
EventManager	cirkularny log 8-bajtowych wpisów; flush okresowy lub natychmiast przy eventach power
TelemetryManager	rekordy `TelemetryRecord` + `SensorDataRecord` → CSV `/telemetry.csv`, `/sensors.csv`; zbieranie ~1 Hz, flush co N rekordów
FS (pico-vfs)	FAT na SD, API w stylu POSIX
SensorWrapper	interfejs `ISensor` → BME280 / BH1750
DS3231	czas Unix, strefa, temperatura chipa
GPS / NMEA	parser RMC+GGA; passthrough UART tylko w trybie naziemnym

Podział rdzeni

Core 0                         Core 1
─────────────────────────      ────────────────────────────
poll UART + LoRa               collect_gps_data()
parsowanie KBST…TSBK           collect_telemetry() @ ~1 Hz
execute_command()              flush CSV → SD
odpowiedź tym samym I/F        (oraz obsługa resetu do BOOTSEL)

Stacja naziemna i Operator

Hardware mostu

Osobny Raspberry Pi Pico + moduł LoRa: most transparentny LoRa ↔ UART do PC.

KubiSat Operator (rozdz. 5 pracy)

Aplikacja desktop (.NET / Avalonia), MVVM:

SerialCommunicator - port szeregowy, buforowanie, wykrywanie ramek,
CommandManager - async/await + TaskCompletionSource, timeout,
CommandRegistry / ViewModele - katalog komend w UI,
OxyPlot - telemetria zasilania, sensory, GPS,
auto-odświeżanie ~1 s, eksport wykresów PNG,
pojedynczy fix GPS → link do Google Maps; seria → ślad.

To domyka pętlę: człowiek → Operator → UART → LoRa → satelita → logi/odpowiedzi.

Testy i wyniki (rozdz. 6)

Testy poleceń

Zakładka Testy w Operatorze: każde polecenie pod kątem praw dostępu, formatu odpowiedzi i czasu.

Symulacja lotu (telemetria)

przejazd samochodem ~17 km,
model wyłącznie na własnym zasilaniu,
ciągły zapis GPS + power + sensory,
odczyt CSV w Operatorze jako dane historyczne.

Obserwacje (jak w pracy):

skoki prądu przy pracy radia (odpytanie po wniesieniu do domu),
skok T / RH / lux przy przeniesieniu z auta do budynku,
ciągły ślad GPS.

Wniosek pracy inż.: cele zrealizowane, system działa zgodnie z założeniami.

Wnioski i kierunki rozwoju

Z rozdziału podsumowującego pracy oraz z dalszego rozwoju repo:

Kierunek	Idea
Komunikacja	dodatkowe medium (np. GSM), hardening protokołu (CRC/SEQ/ACK), kontrola dostępu do SET
RTOS	FreeRTOS zamiast ręcznego podziału na rdzenie
Energia	sleep między próbkami, lepszy układ paneli PV (więcej mniejszych → wyższe napięcie MPPT)
Dane	pobieranie plików z SD po radiu, rotacja logów, sync czasu z GPS
Payload	dodatkowe sensory / prosta kamera
Weryfikacja	dłuższe testy, właściwy lot balonowy jako eksperyment

Dane z 24.10.2026

Dnia 24.10.2026 przez końcową część drogi (~17km) na uczelnię satelita był uruchomiony i zbierał dane telemetryczne oraz dane z czujników środowiskowych. Poniżej umieściłem te dane oraz zapis trasy w postaci projektu na Google Earth.

kubisat_trajectory_20261024_082451

Plik KML z zapisem trasy

kubisat_trajectory_20261024_082451.kml