Łącze satelitarne może zapewnić UAV kanał poza zasięgiem infrastruktury naziemnej, ale nie jest „radiem o nieskończonym zasięgu”. Terminal musi widzieć właściwy fragment nieba, antena pracuje na obracającej się platformie, usługa ma określoną przepustowość, opóźnienie i model rozliczeń, a wiadomość przechodzi przez sieć operatora oraz gateway zanim dotrze do aplikacji. SATCOM najlepiej projektować jako osobną usługę o jasno określonym zakresie, zwykle dla statusu, śledzenia, alarmów i poleceń wysokiego poziomu.

Stabilizacja i bezpośrednia kontrola aktuatorów pozostają lokalne. Nawet gdy operator wysyła przez satelitę zmianę planu misji, flight controller musi sprawdzić autoryzację, świeżość, stan lotu i wykonalność. Utrata terminala, zasłonięcie anteny albo opóźniona wiadomość nie mogą prowadzić do nieokreślonego zachowania.

Spis treści#

Klasy usług#

SATCOM dla UAV obejmuje kilka odmiennych produktów:

klasa charakter danych typowy zakres UAV
krótkie wiadomości IoT dziesiątki–tysiące bajtów, transakcje pozycja, health, alarm, polecenie misji
narrow/midband packet data kilkanaście–setki kbit/s bogatsza telemetria, logi, miniatury
broadband IP Mbit/s i więcej, większy terminal wideo, payload sieciowy, duże platformy
3GPP IoT-NTN/NR-NTN integracja z ekosystemem komórkowym terminale zgodne z konkretnym wdrożeniem/operatorami
bent-pipe/backhaul satelita przenosi łącze do infrastruktury specjalizowane systemy i większe terminale

Parametr „coverage global” nie opisuje dostępności w danym momencie i montażu. Usługa może mieć ograniczenia regionalne, regulacyjne, planowe, widoczności oraz liczby równoczesnych sesji. Wymagania trzeba odnosić do konkretnego operatora, terminala, planu i anteny.

LEO, MEO i GEO#

LEO#

Low Earth Orbit oznacza zwykle setki do około dwóch tysięcy kilometrów. Satelita szybko przesuwa się po niebie, więc terminal przechodzi między wiązkami lub satelitami. Mniejsza odległość daje korzystniejszy budżet łącza i krótszy czas propagacji niż GEO, lecz dochodzą szybki Doppler, handover i zmienna geometria.

MEO#

Medium Earth Orbit zajmuje pośredni zakres. Dla użytkownika właściwości zależą od konstelacji i usługi; samo „MEO” nie określa bitrate ani opóźnienia.

GEO#

Satelita geostacjonarny znajduje się około 35 786 km nad równikiem i pozostaje w przybliżeniu w stałym kierunku dla obserwatora. Jednokierunkowy czas propagacji w próżni dla samej ścieżki geometrycznej jest rzędu setek milisekund po uwzględnieniu drogi przez satelitę; pełny RTT wraz z siecią i kolejkami jest większy. Antena może śledzić stały azymut/elewację, lecz na ruchomym UAV nadal zmienia się orientacja kadłuba.

Nie orbitę, lecz usługę się kwalifikuje#

LEO nie zawsze oznacza mały RTT aplikacyjny, a GEO nie zawsze wyklucza sterowanie wysokiego poziomu. Gateway może być odległy, wiadomość może oczekiwać na transmisję, a protokół może wykonywać retransmisje. Pomiar end-to-end jest obowiązkowy.

3GPP NTN#

3GPP Release 17 był pierwszym wydaniem z normatywnymi wymaganiami NTN. Obejmuje NR-NTN oraz prace nad NB-IoT/eMTC dla sieci nieterestrialnych. Architektura zakłada między innymi scenariusze transparent payload, opóźnienie satelitarne, ruch komórek/wiązek, informacje efemerydalne i kompensację timing advance.

W NR-NTN Release 17 zakładano terminal z możliwością określenia położenia GNSS i dostępem do efemeryd/common TA. Wprowadzone pasma n255 (L-band) i n256 (S-band) nie oznaczają, że dowolny modem 5G potrafi pracować przez satelitę. Potrzebne są:

  • obsługa NTN w chipsecie, firmware i profilu operatora;
  • właściwe pasma oraz antena;
  • zgodna karta/eSIM i usługa;
  • obsługa procedur mobilności i czasu;
  • regionalna dostępność komercyjna.

Release 18 rozwijał NR-NTN i IoT-NTN. Ponieważ wdrożenia zmieniają się szybko, artykuł projektowy powinien wskazywać datę weryfikacji i model terminala, nie tylko hasło „3GPP NTN”.

Tor systemowy wiadomości#

W krótkiej usłudze dwukierunkowej typowy tor wygląda tak:

FC → companion/modem → antena UAV → satelita/konstelacja
   → gateway operatora → API/cloud → aplikacja GCS

Kierunek zwrotny przechodzi analogiczną drogę. Każdy etap ma własny stan:

  • kolejka lokalna i sesja modemu;
  • widoczność satelity;
  • retransmisje radiowe;
  • routing w konstelacji;
  • gateway i kolejka konta;
  • webhook/broker/API;
  • aplikacja operatora.

Potwierdzenie „modem przyjął rekord” nie oznacza dostarczenia do GCS. Potrzebne są poziomy ack:

  1. zapisano w trwałej kolejce UAV;
  2. modem zaakceptował;
  3. sieć satelitarna/gateway przyjęły;
  4. backend dostarczył do aplikacji;
  5. aplikacja wykonała lub odrzuciła transakcję.

Komenda w dół również potrzebuje potwierdzenia aplikacyjnego, jeśli operator ma wiedzieć, że FC ją zaakceptował. Brak ack nie może być interpretowany jako niepowodzenie bez uwzględnienia duplikatów — powtórzenie musi być idempotentne.

Opóźnienie i jitter#

Opóźnienie transakcji:

t_e2e = t_queue_local + t_access + t_space + t_gateway
      + t_backend + t_application

t_access może dominować w usłudze krótkich wiadomości: terminal czeka na widoczność/slot i wykonuje retransmisje. Dla GEO t_space jest znaczne. Dla LEO handover lub chwilowe zasłonięcie może dać długi ogon rozkładu mimo niskiej mediany.

Nie wolno projektować deadline'u na średniej. Potrzebne są percentyle i maksymalny dopuszczalny wiek. Dla statusu pozycji można wysłać nowszy rekord zamiast starego. Dla transakcji konfiguracji trzeba zachować kolejność albo jawnie użyć wersji stanu.

TCP przez ścieżkę o dużym RTT i stracie może reagować wolno; krótkie sesje dodatkowo płacą za handshake. Persistent connection pomaga tylko, jeśli terminal i operator utrzymują sesję. W messaging API bardziej istotny bywa czas kompletnej transakcji operatora niż klasyczny ping.

Anteny i widoczność nieba#

Terminal satelitarny wymaga właściwej polaryzacji, ground plane i obszaru bez przeszkód. Kadłub z włókna węglowego, akumulator, skrzydło, silnik i payload mogą zasłaniać półprzestrzeń. Antena dookólna w azymucie nadal ma zera w elewacji.

Na fixed-wing podczas zakrętu skrzydło i przechył zmieniają widoczność. Na multirotorze akumulator na górze może zasłonić antenę umieszczoną pod płytą. Dwie anteny lub terminal z diversity pomagają tylko wtedy, gdy architektura faktycznie wybiera/łączy tor.

Dla LEO kierunek satelity stale się zmienia. Antena o szerokim pokryciu półsferycznym jest praktyczna kosztem mniejszego zysku. Dla GEO można użyć anteny o większym zysku, ale ruch platformy wymaga stabilizacji/beam steering lub szerokiej wiązki.

Integracja wymaga mapy zysku w 3D kompletnego UAV. Pomiar samej anteny na stole nie uwzględnia ekranowania. Każda konfiguracja payloadu może zmienić wynik.

Budżet łącza Earth-space#

Strata wolnej przestrzeni rośnie z odległością i częstotliwością. System satelitarny kompensuje ją mocą, anteną satelity, kodowaniem i bardzo czułym odbiornikiem. Użytkownik nie powinien samodzielnie zastępować certyfikowanej anteny bez sprawdzenia zgodności i EIRP.

ITU-R P.618 zawiera metody dla propagacji Earth-space, w tym efekty atmosferyczne. ITU-R P.682 dotyczy aeronautycznych systemów mobilnych i obejmuje między innymi multipath oraz odbicia związane z platformą i fazą lądowania.

Bilans końcowy uwzględnia:

  • EIRP terminala w kierunku satelity;
  • zysk anteny satelity i G/T;
  • FSPL dla skrajnej geometrii;
  • straty atmosferyczne, deszczowe i polaryzacyjne odpowiednie dla pasma;
  • zasłonięcie oraz multipath od kadłuba/ziemi;
  • wymagane Eb/N0 i bitrate;
  • margines implementacyjny i dostępność.

W L-band deszcz jest zwykle mniej dotkliwy niż w pasmach wyższych, lecz blokada fizyczna i geometria pozostają krytyczne. Deklaracja operatora o odporności na pogodę nie zastępuje testu montażu UAV.

Doppler i ruch#

Przesunięcie Dopplera w przybliżeniu:

f_d = (v_r / c) f_c

W LEO względna prędkość satelity jest dużo większa od prędkości małego UAV, więc system musi kompensować znaczący, zmienny Doppler. W NTN używane są informacje o położeniu i efemerydach. Nie oznacza to jednak, że ruch UAV jest bez znaczenia: zmienia kąt anteny, multipath i częstotliwość handoverów.

Oscylator terminala ma tolerancję oraz drift temperatury. Moduł zewnętrzny certyfikowany do sieci zawiera wymagane mechanizmy, lecz zasilanie i temperatura integracji nadal wpływają na dostępność.

Krótkie wiadomości i store-and-forward#

Iridium SBD jest przykładem usługi dwukierunkowych, krótkich transmisji do urządzeń IoT. Nowocześniejszy moduł Iridium Certus 9704 obsługuje wiadomości do 100 kB i interfejs JSPR/serial/SPI, lecz limit maksymalny nie jest zalecanym rozmiarem każdej telemetrii.

Małe rekordy:

  • szybciej mieszczą się w oknie dostępu;
  • kosztują mniej airtime i energii;
  • łatwiej je retransmitować;
  • ograniczają konsekwencję błędu;
  • zmniejszają koszty planu rozliczeniowego.

Store-and-forward wymaga trwałej kolejki. Rekord musi przeżyć reset companiona, ale nie powinien przesyłać godzinami nieaktualnej pozycji. Każdy typ ma TTL i politykę zastępowania:

typ kolejka po odzyskaniu łącza
bieżąca pozycja latest-wins wyślij tylko najnowszą + ewentualnie skrót historii
alarm trwała, priorytetowa powtarzaj do ack/wygaśnięcia
health snapshot coalescing scal najnowsze wartości i liczniki
log zdarzeń kolejność zachowana wysyłaj stopniowo z limitem
komenda idempotentna, krótki TTL odrzuć po terminie

Numer sekwencji musi rozróżniać ponowne wysłanie od nowego zdarzenia. Idempotency key w backendzie zapobiega wielokrotnemu wykonaniu tej samej transakcji.

Łącze IP#

Iridium Certus 9770 jest przykładem modułu midband z deklarowaną szybkością do 22 kbit/s w uplinku i 88 kbit/s w downlinku, pracującego w 1616–1626,5 MHz. Producent podaje masę 185 g i wejście 12 V ±2,5 V. To wyraźnie większa klasa integracji niż 12-gramowy moduł messaging 9704.

W IP można uruchomić VPN, TCP/UDP i istniejące aplikacje, lecz narzut jest duży w stosunku do małego bitrate. Keepalive, DNS, TLS handshake i nagłówki mogą stanowić istotną część ruchu. Warto używać:

  • persistent session, gdy ekonomicznie i technicznie uzasadniona;
  • zwartego protokołu binarnego;
  • kompresji nagłówków tylko w kontrolowanej architekturze;
  • batchingu bez przekraczania deadline;
  • jawnego limitu ruchu tła systemu operacyjnego;
  • firewalla blokującego automatyczne aktualizacje przez SATCOM.

Wideo przez narrow/midband wymaga bardzo niskiej rozdzielczości lub obrazów okazjonalnych. Pełne wideo UAV wymaga odpowiednio szerokopasmowego terminala, anteny, zasilania i planu danych.

Projekt payloadu telemetrii#

Minimalna ramka:

typedef struct __attribute__((packed)) {
    uint8_t  version;
    uint8_t  type;
    uint16_t flags;
    uint32_t vehicle_id;
    uint32_t sequence;
    uint32_t monotonic_s;
    uint16_t payload_len;
    /* payload + auth tag */
} sat_message_header_t;

Pola numeryczne używają ustalonej endianess i jednostek całkowitych. Pozycję można zakodować jako stopnie ×10⁷ lub inny jawny format; czas i stan ważności są osobne. Nie należy przesyłać tekstowego JSON dla każdego rekordu tylko dlatego, że backend go lubi, jeśli każdy bajt i energia mają znaczenie. Moduł może mieć JSON-owe API lokalne, ale payload aplikacyjny nadal może być binarny.

Wersja protokołu i capability negotiation chronią przed niezgodnym backendem. Nieznane pola są pomijane zgodnie z regułą, a krytyczna semantyka nie może zmienić się cicho.

Zamiast tunelować cały strumień MAVLink, warto wybrać zestaw komunikatów i częstotliwości. 20 wiadomości/s przez płatny messaging jest zwykle błędem architektury.

Kolejki, priorytety i koszty#

Plan danych może rozliczać wiadomość, bajt, sesję lub czas. Optymalizacja kosztu nie może usuwać alarmu bezpieczeństwa, ale powinna ograniczać zbędne rekordy.

Przykładowy scheduler:

P0: alarm i potwierdzenie krytyczne
P1: heartbeat / pozycja okresowa
P2: health i stan misji
P3: log zdarzeń
P4: diagnostyka i aktualizacje

Każda klasa ma quota, TTL, maksymalną liczbę prób i politykę coalescing. P0 nie powinno być blokowane przez duży rekord P3. Jeżeli modem nie obsługuje preemption w połowie transakcji, rekordy tła muszą być małe.

Monitor kosztu rejestruje rzeczywiste bajty i transakcje operatora, nie tylko payload. Symulator kosztów powinien używać aktualnej taryfy i scenariusza najgorszego, na przykład długiej utraty LTE skutkującej przejściem całej floty na satelitę.

Łącze pierwotne, zapasowe i diversity#

Najczęstsza architektura:

RC / lokalne radio ─┐
LTE/5G ─────────────┼─ policy engine ─ aplikacje
SATCOM ─────────────┘

Policy engine nie powinien po prostu wybrać interfejsu z route metric systemu operacyjnego. Potrzebuje klasy danych, kosztu, deadline i stanu. Pozycja może być duplikowana przez LTE i SATCOM w stanie niepewnym; wideo pozostaje tylko na LTE; alarm wybiera oba.

Histereza zapobiega przełączaniu co kilka sekund. Powrót na tańsze łącze może nastąpić dopiero po okresie stabilności. Wiadomości muszą zachować identyfikator niezależny od kanału, aby backend deduplikował duplikaty.

SATCOM zapasowy trzeba regularnie testować. Terminal, który nigdy nie jest aktywowany do dnia awarii, może mieć nieaktywną usługę, starą konfigurację, przesłoniętą antenę albo uszkodzone złącze.

Companion zbiera wybrane dane FC po UART/CAN/Ethernet, waliduje i umieszcza w kolejce. Nie powinien przekazywać dowolnego pakietu z chmury prosto do portu autopilota.

Komenda BLOS przechodzi bramę:

  1. weryfikacja autentyczności i replay;
  2. sprawdzenie vehicle ID i wersji;
  3. TTL/deadline oraz sequence;
  4. polityka dopuszczonych operacji;
  5. sprawdzenie stanu armed/mode/health;
  6. lokalne potwierdzenie przez FC;
  7. wynik zwrotny z kodem przyczyny.

Zmiany planu misji mogą być transakcją wersjonowaną: companion wysyła hash/wersję, FC waliduje całość i aktywuje atomowo. Częściowo odebrana lista punktów nie staje się aktywną misją.

Utrata SATCOM nie jest sama w sobie sygnałem do natychmiastowej zmiany lotu, jeśli system ma inne łącza. Failsafe ocenia źródła, stan autonomii, energię, GNSS i plan operacyjny.

Bezpieczeństwo end-to-end#

Szyfrowanie/operator transport security nie eliminuje potrzeby ochrony aplikacyjnej. Dane przechodzą przez gateway i backend, a klucze dostępu do API mogą zostać przejęte.

Wymagane elementy:

  • unikalna tożsamość i klucz/certyfikat dla każdego UAV;
  • wzajemne uwierzytelnienie, gdzie dostępne;
  • integralność, numer sekwencji i ochrona replay;
  • krótki TTL komend;
  • rotacja i unieważnienie jednego terminala;
  • rozdzielenie uprawnień telemetrii i komend;
  • audit operatora i backendu;
  • secure boot oraz podpisane aktualizacje;
  • minimalne API i rate limiting.

Stały token wspólny dla floty jest niedopuszczalny. Backend powinien odrzucać wiadomość poprawnie podpisaną, ale przeznaczoną dla innego pojazdu. Czas z GNSS pomaga, lecz ochrona replay nie może zależeć wyłącznie od zegara podatnego na utratę synchronizacji — potrzebne są liczniki/okna.

Zasilanie, masa i termika#

Modem pobiera prąd impulsowo podczas transmisji. Przetwornica, przewody i kondensatory muszą utrzymać napięcie przy najgorszym burst. Brownout może przerwać sesję i zwiększyć liczbę prób, pogarszając energię.

Budżet systemowy obejmuje:

  • moduł i carrier board;
  • antenę, ground plane, kabel i złącza;
  • przetwornicę oraz filtrację;
  • obudowę i uszczelnienie;
  • companion/MCU i pamięć kolejki;
  • subskrypcję/usługę;
  • wpływ aerodynamiczny anteny.

Przykład katalogowy pokazuje skalę: Certus 9704 ma deklarowaną masę 12 g jako moduł, natomiast Certus 9770 185 g bez pełnej integracji. Gotowy terminal jest cięższy. Nie wolno porównywać masy gołego modułu z kompletnym modemem innej klasy.

Termika może być trudna na ziemi bez przepływu. Nadajnik generuje burst, a szczelna obudowa magazynuje ciepło. Test obejmuje maksymalny duty cycle i wysoką temperaturę otoczenia.

Ograniczenia operacyjne i prawne#

Łącze BLOS nie stanowi samo w sobie zezwolenia na lot BVLOS. Operacja, statek, częstotliwości, terminal i operator podlegają właściwym regulacjom. Terminal satelitarny może mieć ograniczenia użycia w określonych państwach lub przestrzeni.

Integracja RF powinna używać zatwierdzonej anteny i konfiguracji. Zmiana PA, anteny lub pasma może naruszyć certyfikację oraz warunki operatora. Usługa może wymagać umowy dla zastosowania lotniczego.

W planie operacyjnym trzeba określić, jakie decyzje wolno podejmować przez łącze o długim/zmiennym opóźnieniu i co dzieje się po jego utracie. Operator musi widzieć wiek telemetrii; mapa z ostatnią pozycją bez timestampu jest niebezpieczna.

Obserwowalność#

Na UAV rejestruj:

  • stan rejestracji i sesji modemu;
  • jakość/metrykę sygnału udostępnianą przez terminal;
  • liczbę prób, czas sesji i przyczynę błędu;
  • kolejkę według klas, najstarszy rekord i dropy TTL;
  • bajty/transakcje i koszt szacowany;
  • napięcie, prąd, temperaturę i resety;
  • orientację UAV przy sukcesie/awarii;
  • ack na każdym poziomie.

Backend rejestruje czas przyjęcia przez gateway, czas dostarczenia aplikacji, duplikaty, odrzucone podpisy, opóźnienie komend i wynik FC. Korelacja identyfikatorem wiadomości pozwala rozłożyć end-to-end latency.

Brak wiadomości może oznaczać brak danych, awarię modemu, niewidoczność satelity, problem operatora lub backendu. Heartbeat aplikacyjny ma sequence i stan źródłowy, a monitoring oddziela te przypadki.

Plan testów#

Test bez RF#

Użyj emulatora API/modemu do wstrzyknięcia opóźnienia, duplikatów, reorder, braku ack i limitu kosztu. Sprawdź trwałą kolejkę, TTL, idempotency i restart w każdym etapie.

Test terminala#

Na otwartym niebie zmierz czas rejestracji, wysyłki i downlinku dla różnych rozmiarów. Obracaj kompletny UAV w azymucie/elewacji, zasłaniaj przewidywane sektory i rejestruj orientację.

Test integracyjny#

  • jednoczesne LTE/RC/SATCOM;
  • utrata łącza pierwotnego i aktywacja zapasu;
  • duża kolejka po długim odcięciu;
  • reset companiona/modemu;
  • wysoki duty cycle i temperatura;
  • brak GNSS w terminalu NTN, jeśli dotyczy;
  • duplikaty tej samej komendy przez dwa kanały.

Test w locie#

Rozpocznij od VLOS i bezpiecznego profilu. Mierz dostępność dla orientacji, zakrętów, wznoszenia, lądowania i konfiguracji payloadu. Nie rozszerzaj zakresu operacji na podstawie pojedynczej udanej wiadomości.

Kryteria odbioru#

obszar przykładowe kryterium
dostarczenie 99. percentyl czasu wiadomości P0/P1 poniżej limitu w profilu testowym
świeżość przeterminowane rekordy nie są wysyłane/wykonywane
orientacja dostępność spełniona dla najgorszych dopuszczonych położeń UAV
kolejka restart nie traci alarmów i nie odtwarza wykonanych komend
fallback przełączenie LTE→SATCOM odbywa się w limicie bez burzy duplikatów
bezpieczeństwo obca, stara i zmodyfikowana wiadomość jest odrzucana
koszt system respektuje quota i raportuje narzut rzeczywisty
zasilanie brak brownout/resetu podczas najgorszego burst i temperatury
FC awaria modemu/companion nie narusza deadline pętli lotu
operator każda pozycja pokazuje czas pomiaru, dostarczenia i źródło

SATCOM jest gotowy dopiero wtedy, gdy przetestowano kompletny tor UAV–operator–UAV. Sukces komendy AT albo logowanie modemu do sieci jest dopiero początkiem integracji.

Powiązane tematy#

Przypisy#

  1. 3GPP, Non-Terrestrial Networks (NTN) — przegląd Release 17/18, https://www.3gpp.org/technologies/deep-dive/ntn-overview (dostęp: 15 sierpnia 2026).
  2. Iridium, Iridium Certus 9704 Module, https://www.iridium.com/products/iridium-certus-9704-module (dostęp: 15 sierpnia 2026).
  3. Iridium, Iridium Certus 9770, https://www.iridium.com/products/iridium-certus-9770 (dostęp: 15 sierpnia 2026).
  4. Iridium, Short Burst Data, https://www.iridium.com/services/iridium-sbd/ (dostęp: 15 sierpnia 2026).
  5. ITU-R, Recommendation P.618-14: Propagation data and prediction methods required for the design of Earth-space telecommunication systems, sierpień 2023, https://www.itu.int/rec/R-REC-P.618-14-202308-I/en (dostęp: 15 sierpnia 2026).
  6. ITU-R, Recommendation P.682-4: Propagation data required for the design of Earth-space aeronautical mobile telecommunication systems, sierpień 2022, https://www.itu.int/rec/R-REC-P.682-4-202208-I/en (dostęp: 15 sierpnia 2026).
  7. NASA/JPL, DSN Telecommunications Link Design Handbook — kolekcja, https://pds.nasa.gov/ds-view/pds/viewCollection.jsp?identifier=urn:nasa:pds:radiosci.documentation:dsn.810-005 (dostęp: 15 sierpnia 2026).

Powiązane tematy

Budżet łącza radiowego UAVPraktyczna metodyka budżetu łącza UAV: jednostki dB/dBm/dBi, EIRP, strata wolnej przestrzeni, horyzont i Fresnel, czułość z bilansu szumu, interferencja, polaryzacja, anteny w kadłubie, margines statystyczny, uplink/downlink oraz plan pomiarów.Wi‑Fi, LTE i 5G jako łącze UAVAktualizacja koncepcji sterowania przez GSM: stabilizacja zawsze lokalna, a sieć komórkowa przenosi misję, telemetrię i opcjonalnie wideo.LoRa w UAVLoRa jako odporna energetycznie telemetria o małej przepustowości: modulacja CSS, SF/BW/CR, time-on-air, sensitivity i link budget, LoRaWAN Classes/ADR, regionalne ograniczenia, payload design, bezpieczeństwo, anteny oraz failsafe.Sieci mesh dla UAVSieć mesh UAV od wspólnego medium i kosztu relay przez 802.11s, routing reaktywny/proaktywny, metryki ETX/airtime, konwergencję w ruchu, gatewaye, multicast i QoS po uwierzytelnianie routingu, obserwowalność i testy topologii.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.GNSS w UAVOd pseudoodległości do rozwiązania RTK: integracja odbiornika, antena, opóźnienie, układy odniesienia i walidacja z innymi sensorami.Failsafe jako maszyna stanówFailsafe jako deterministyczny system decyzji: źródła faultów, persistence i hysteresis, priorytety reakcji, konflikty RC/GNSS/baterii, latch, recovery oraz macierz testowa.Transmisja wideo UAVKompletny tor wideo UAV: kamera i rolling shutter, kodowanie H.264/H.265, GOP i obrazy referencyjne, packetization RTP, utrata pakietów, FEC kontra retransmisja, adaptacja bitrate, zabezpieczenia, pomiar opóźnienia glass-to-glass i testy w locie.

Źródła z centralnego rejestru

  1. 3GPP: Non-Terrestrial Networks — Release 17 and 18 overview [dokumentacja organizacji standaryzacyjnej]
  2. Iridium Certus 9704 satellite IoT module — official specifications [dokumentacja producenta]
  3. Iridium Certus 9770 midband module — official specifications [dokumentacja producenta]
  4. Iridium Short Burst Data — service overview [dokumentacja operatora]
  5. ITU-R P.618-14: Propagation data and prediction methods for Earth-space systems [rekomendacja techniczna]
  6. ITU-R P.682-4: Propagation for Earth-space aeronautical mobile systems [rekomendacja techniczna]
  7. NASA/JPL: DSN Telecommunications Link Design Handbook collection [podręcznik techniczny]
  8. Sumit Sharma, „Drone Development from Concept to Flight” [książka]