Wi‑Fi jako łącze UAV

Wi‑Fi może przenosić telemetrię, komendy, konfigurację, logi i wideo tym samym stosem IP, ale nie jest deterministycznym przewodem Ethernet. Medium jest współdzielone i półdupleksowe, nadajnik musi konkurować o airtime, a rate adaptation, retransmisje i kolejki tworzą zmienne opóźnienie. Nominalne „1200 Mb/s” nie określa użytecznego bitrate w locie ani czasu dostarczenia małej komendy. Poprawny projekt zaczyna się od osobnych wymagań dla każdego strumienia i kończy testem utraty oraz odzyskania łącza.

Jaką funkcję ma pełnić Wi‑Fi#

Jedno radio może obsługiwać kilka przepływów o różnych cechach:

Przepływ	Typowe wymaganie	Co jest najważniejsze
heartbeat i stan	mały bitrate, ciągły	świeżość i wykrycie utraty
komendy operatora	mały bitrate	bounded latency, autentyczność
telemetria	mały/średni	utrata kontrolowana, kolejność
wideo	duży, zmienny	jitter buffer, adaptacja bitrate
mapy/chmury	duży	throughput, możliwość przerwania
konfiguracja	mały, rzadki	niezawodność i autoryzacja
log po locie	bardzo duży	goodput, brak wpływu na sterowanie

Nie każdy UAV powinien używać Wi‑Fi jako podstawowego sterowania. Może ono być łączem payloadu lub serwisowym, podczas gdy niezależny system RC zapewnia control/failsafe. Jeśli Wi‑Fi jest jedyną drogą komend, analiza awarii obejmuje AP, klienta, switch, routing, proces aplikacji i zasilanie każdego elementu.

Warstwy systemu#

Łącze należy analizować warstwami:

aplikacja: MAVLink / wideo / SSH / API
transport: UDP / RTP / TCP / QUIC
sieć:     IPv4/IPv6, routing, firewall
MAC:      802.11, contention, retry, WMM
PHY:      pasmo, kanał, MCS, szerokość, anteny
RF:       EIRP, path loss, noise, interference

Pomyłka na jednej warstwie często wygląda jak problem innej. Kolejka aplikacji może podnosić ping mimo dobrego RSSI. Interferencja może obniżyć MCS bez utraty association. Błąd MTU może dotyczyć tylko dużych pakietów wideo.

Standard i generacje#

Aktualnym skonsolidowanym standardem jest IEEE 802.11-2024, opublikowany w 2025 r.; obejmuje MAC i wiele PHY oraz włącza wcześniejsze poprawki. Nazwy Wi‑Fi 4/5/6/6E/7 ułatwiają identyfikację generacji, ale urządzenie może obsługiwać tylko część funkcji.

Do projektu trzeba zapisać konkretnie:

pasmo i kanały;
20/40/80/160 MHz albo inne dopuszczone szerokości;
liczbę spatial streams;
MCS, guard interval i coding;
tryb AP/station/mesh;
firmware oraz regulatory domain;
antenę i EIRP;
funkcje WMM, encryption i roaming.

Wysoka generacja nie gwarantuje zasięgu. Szeroki kanał zwiększa peak throughput, ale zbiera więcej szumu/interferencji i może mieć mniejszą gęstość mocy. Dla telemetrii stabilny kanał 20 MHz bywa lepszym punktem odniesienia niż maksimum marketingowe.

Pasma 2,4, 5 i 6 GHz#

Niższa częstotliwość ma mniejszą stratę wolnej przestrzeni dla tych samych anten izotropowych i lepiej dyfraktuje, lecz pasmo 2,4 GHz jest często zatłoczone. 5 GHz oferuje więcej kanałów i większy bandwidth, ale ma większą stratę oraz regionalne wymagania, m.in. dla części kanałów. 6 GHz zapewnia nowe spektrum tam, gdzie jest dopuszczone, lecz jego zastosowanie i limity zależą od kraju oraz klasy urządzenia.

Regulatory domain nie jest ustawieniem wydajności. Określa dozwolone kanały, moc, DFS/TPC i warunki pracy. Błędny kraj może stworzyć nielegalną emisję albo wymusić niespodziewaną zmianę kanału. Projekt produkcyjny blokuje konfigurację zgodnie z rynkiem docelowym.

Dynamic Frequency Selection może wymagać nasłuchu i opuszczenia kanału po wykryciu chronionego sygnału. Dla łącza sterującego jest to jawny tryb przejściowy: trzeba wiedzieć, czy AP zmienia kanał, wyłącza radio i ile trwa ponowne połączenie.

Budżet łącza#

Moc na wejściu odbiornika można oszacować:

P_rx[dBm] = P_tx + G_tx + G_rx - L_path - L_cables - L_misc

Dla wolnej przestrzeni:

FSPL[dB] = 32,44 + 20log10(d_km) + 20log10(f_MHz)

Margines:

M = P_rx - S_rx(MCS, BW, PER_target)

S_rx jest czułością dla konkretnego MCS, szerokości i wymaganego packet error rate. Najszybszy MCS wymaga znacznie większego SNR niż najwolniejszy. Link nie „ma jednego zasięgu”: wraz ze spadkiem marginesu rate control redukuje modulację, a airtime pakietu rośnie.

FSPL jest punktem odniesienia dla line of sight, nie prognozą lotu przy ziemi. Wielodrogowość, Fresnel obstruction, polaryzacja, body shadow, bank angle i interferencja tworzą fading. Projektuje się zapas do wymaganego MCS, nie do samego progu association.

Strefa Fresnela#

Nawet przy optycznej widoczności obiekty mogą wejść w pierwszą strefę Fresnela. Jej promień w punkcie toru:

r_1 = sqrt(λ d_1 d_2 / (d_1 + d_2))

Niski lot za wałem, drzewami albo dachem pogarsza link wcześniej niż prosta linia na mapie. Antena naziemna umieszczona wysoko często daje większą poprawę niż kilka dB mocy.

Odbicie od gruntu może sumować się konstruktywnie lub destruktywnie. Minimalne RSSI może wystąpić na określonej wysokości/odległości mimo dobrego wyniku metr wcześniej. Próba musi obejmować trasę, a nie tylko punkt końcowy.

Anteny#

Antenę wybiera się z charakterystyką 3D. Omnidirectional whip ma zwykle null wzdłuż osi, więc pionowy montaż na UAV nad stacją może być niekorzystny. Patch zwiększa gain w sektorze kosztem pokrycia poza nim.

Wymagania integracyjne:

polaryzacja zgodna w manewrach;
brak carbon fiber i metalu w near field;
odstęp od GNSS, RC, LTE i przetwornic;
krótki, znany kabel o małej stracie;
strain relief złącza U.FL/MMCX;
diversity/MIMO z właściwą geometrią;
wzorzec zmierzony na kompletnej platformie.

2×2 MIMO nie oznacza automatycznie podwojenia zasięgu. Spatial multiplexing zwiększa throughput w bogatym multipath, a diversity może poprawiać odporność. Rzeczywisty tryb zależy od chipsetu i kanału.

Przy roll/pitch UAV polaryzacja zmienia się. Dwie anteny o uzupełniających orientacjach mogą ograniczyć głębokie zaniki, lecz ich przełączanie lub combining należy potwierdzić w driverze.

PHY rate, throughput i goodput#

PHY rate nie jest bitrate aplikacji. Airtime zużywają:

preambuły i nagłówki PHY/MAC;
interframe spaces i backoff;
ACK/block ACK;
retransmisje;
beacon i management frames;
encryption oraz agregacja;
ruch w przeciwnym kierunku;
inne stacje na kanale.

goodput = payload_bits_delivered / observation_time

Duże agregaty poprawiają throughput, ale mogą zwiększyć czas oczekiwania małej wiadomości i koszt błędu. Małe pakiety mają duży narzut. Testuje się histogram latency pod pełnym wideo, nie tylko iperf bez ruchu sterującego.

Airtime jest zasobem#

802.11 używa współdzielonego, półdupleksowego medium. Stacja o niskim MCS zajmuje kanał długo, choć wysyła mało danych. Jeden daleki klient może obniżyć zdolność całej komórki.

Przybliżony udział:

airtime_i ≈ frames_i · (preamble + payload_i/PHY_rate_i + ACK + contention)

Nie sumuje się nominalnych bitrate klientów. W mesh pakiet przesyłany przez dwa hop na tym samym kanale zużywa medium wielokrotnie. Half-duplex relay nie tworzy nowej pojemności.

Channel busy time jest lepszym wskaźnikiem przeciążenia niż RSSI. Linux Wireless opisuje survey API obejmujące active time, busy time, tx time i noise; te metryki warto logować na AP.

CSMA/CA i zmienność opóźnienia#

Przed nadawaniem stacja sprawdza medium i losuje backoff. Jeśli kanał jest zajęty, czeka. Collision lub brak ACK prowadzi do retry z większym oknem. Powstaje long-tail latency.

Średni ping może wynosić 10 ms, podczas gdy 99,9 percentyl przekracza limit sterowania. Dlatego raport obejmuje:

medianę;
p95/p99/p99.9;
maksymalny wiek ważnych wiadomości;
burst loss length;
czas bez nowych danych;
recovery time.

Hidden node występuje, gdy dwie stacje słyszą AP, ale nie siebie. Ich transmisje kolidują u odbiornika. RTS/CTS może pomóc w pewnych warunkach kosztem airtime; wymaga pomiaru, nie domyślnego włączenia.

Rate adaptation#

Driver wybiera MCS na podstawie powodzenia transmisji. Szybki spadek sygnału przy zasłonięciu kadłubem może być szybszy niż adaptacja. Po powrocie link może ostrożnie zwiększać rate.

Monitorować należy:

tx/rx bitrate i MCS;
retry count i failed frames;
RSSI per chain;
noise/SNR;
channel busy;
aggregation state;
disconnect reason.

RSSI z jednego kierunku nie opisuje uplink i downlink. AP i UAV mogą mieć różne moce, anteny oraz noise figure. Łącze jest tak dobre jak słabszy kierunek, szczególnie gdy video płynie w dół, a ACK/komendy w górę.

Tryb infrastrukturalny#

W klasycznym układzie jedna strona jest AP, druga station. Linux Wireless definiuje AP jako urządzenie utrzymujące listę stacji i politykę bezpieczeństwa; station uwierzytelnia się i asocjuje.

AP na ziemi ma zalety:

łatwiejsze chłodzenie i zasilanie;
wyżej umieszczona/directional antena;
prosta kontrola kanału;
możliwość podłączenia GCS po Ethernet.

AP na UAV upraszcza bezpośrednie dołączanie urządzenia operatorskiego, ale każde wyszukiwanie/roaming oraz zarządzanie klientami odbywa się w powietrzu. Należy ograniczyć nieautoryzowane stacje, inaczej konkurują o airtime.

Ad-hoc, direct i własne rozwiązania#

IBSS/ad-hoc tworzy sieć bez AP, ale wsparcie driverów i bezpieczeństwa jest nierówne. Wi‑Fi Direct/P2P ma negocjację ról, która może nie pasować do deterministycznego startu. WDS/4-address służy bridge, lecz kompatybilność vendorów trzeba potwierdzić.

Nie wybiera się trybu na podstawie nazwy. Kryteria to:

czas startu i reconnect;
obsługa encryption;
dostępność w konkretnym driverze/firmware;
zachowanie MAC address/bridge;
telemetria radiowa;
możliwość stałego kanału;
aktualizacje i wsparcie.

Linux Wireless zaznacza, że nie wszystkie sterowniki obsługują AP, IBSS, mesh i monitor, nawet jeśli chipset teoretycznie ma daną funkcję.

Mesh 802.11s#

802.11s pozwala mesh points tworzyć multi-hop bez centralnego AP. HWMP wybiera ścieżki na warstwie MAC. Mesh portal łączy mesh z inną siecią, a mesh access point obsługuje jednocześnie klientów.

W UAV mesh może przekazywać telemetrię przez przekaźniki lub pojazdy naziemne, ale wprowadza:

dodatkowy airtime per hop;
zmienną trasę i reordering;
peer/link state machines;
większy attack surface;
trudniejszą synchronizację kanałów;
dependency od położenia innych węzłów.

Metryka ścieżki nie zna wymagań flight safety, jeśli nie została tak zaprojektowana. Najmniejszy koszt MAC nie musi oznaczać najmniejszego p99 latency.

Mesh testuje się przy utracie każdego węzła, przełączeniu ścieżki i asymmetric link. Zabezpieczony mesh wymaga obsługi SAE/MFP przez konkretny driver i firmware; nie wolno zakładać interoperacyjności z samej obecności opcji.

Roaming między AP#

UAV może przelatywać między komórkami. Standardowy klient decyduje, kiedy opuścić AP; może trzymać słabe połączenie zbyt długo. Scan aktywny/pasywny zajmuje czas, a zmiana kanału przerywa dane.

Budżet handover:

t_handover = detect + scan + authenticate + associate
           + key + DHCP/routing + application recovery

Fast transition redukuje część etapów tylko przy zgodnej infrastrukturze. Stały IP nie eliminuje przerwy MAC. Test wymaga ruchu, obciążenia i szyfrowania, nie ręcznego przełączenia obok AP.

Dwie równoległe karty na różnych kanałach mogą dać make-before-break, ale potrzebują deduplikacji, routingu i niezależnych anten/zasilania. Jeśli oba interfejsy zależą od jednego USB hubu, nie są pełną redundancją.

IP i routing#

Statyczne adresy przyspieszają kontrolowane wdrożenie, ale wymagają zarządzania konfliktami. DHCP upraszcza flotę, lecz jego awaria może zablokować warstwę aplikacji mimo association.

Warto rozdzielić:

management network;
control/telemetry;
payload/video;
serwis i aktualizacje.

VLAN/VRF i firewall ograniczają propagację awarii, ale driver/bridge musi zachować QoS markings. NAT nie jest mechanizmem bezpieczeństwa. Każda usługa powinna mieć jawnie dozwolone źródła oraz porty.

UDP#

UDP ma mały narzut i nie wprowadza retransmisji blokującej nowsze dane, dlatego pasuje do telemetrii czasu rzeczywistego. Nie zapewnia jednak kolejności, niezawodności, kontroli przeciążenia ani ochrony przed duplikacją.

IETF RFC 8085 wymaga, by aplikacje UDP kontrolowały congestion, rozmiar wiadomości, checksum i bezpieczeństwo. W kontrolowanej sieci radiowej nadal potrzebne są:

sequence number;
timestamp i expiration;
deduplication;
ograniczenie bitrate/pacing;
uwierzytelnienie danych;
reakcja na loss i RTT;
unikanie IP fragmentation.

Komenda sprzed dwóch sekund nie staje się poprawna tylko dlatego, że dotarła. Odbiorca sprawdza freshness oraz stan maszyny.

TCP i head-of-line blocking#

TCP gwarantuje kolejność i retransmisję. Dla konfiguracji, logów i plików jest właściwy. Gdy segment zginie, późniejsze bajty nie są oddawane aplikacji do czasu naprawy; dla sterowania tworzy to head-of-line delay.

Oddzielne połączenia dla logu i komend zapobiegają bezpośredniemu HOL między nimi, ale nadal konkurują o radio i kolejki. Bulk TCP potrafi wypełnić buffer AP, powodując bufferbloat dla UDP.

QUIC udostępnia wiele strumieni i nowoczesne bezpieczeństwo, lecz ma własny congestion control oraz koszty CPU. Wybiera się go na podstawie implementacji i pomiaru, nie hasła „UDP, więc bez opóźnień”.

RTP i wideo#

RTP dodaje numery sekwencji, timestamp i raporty przydatne w real-time media. RFC 3550 definiuje m.in. fraction lost oraz interarrival jitter. Wideo potrzebuje osobnego budżetu:

t_glass-to-glass = exposure + encode + queue + radio
                 + receive + jitter_buffer + decode + display

Największym winowajcą może być encoder GOP lub jitter buffer, nie Wi‑Fi. Długi GOP poprawia kompresję, ale utrata keyframe degraduje obraz do następnego punktu odzyskania.

Adaptacja bitrate powinna reagować na goodput i loss, zanim kolejki narosną. Stałe wysyłanie bitrate większego niż kanał nie daje gorszego obrazu stopniowo — tworzy stale rosnący wiek klatek.

Priorytetem jest świeżość. Receiver może odrzucać stare frame zamiast odtwarzać zaległość. Recording wysokiej jakości można prowadzić lokalnie, a radio wysyłać podgląd adaptacyjny.

Multicast i broadcast#

W 802.11 group-addressed frames często nie mają normalnego ACK/retry per odbiorca i bywają wysyłane z basic rate. To zwiększa airtime oraz ryzyko utraty. Multicast IP nie gwarantuje wydajnego multicastu radiowego; AP może konwertować go na unicast zależnie od funkcji.

Broadcast discovery powinien mieć małą częstotliwość i rozmiar. Nie należy przesyłać pełnej telemetrii broadcastem tylko dlatego, że odbiorców może być kilku.

RFC 8085 wymaga szczególnej kontroli congestion oraz MTU dla multicast/broadcast. W systemie zamkniętym implementuje się membership, rate cap i source authentication.

QoS: WMM i DiffServ#

802.11e/WMM dzieli ruch na access categories, które mają różne parametry contention. IP używa DSCP. RFC 8325 opisuje mapowanie DiffServ do 802.11 User Priority i wskazuje, że bez spójnej polityki znaczenia mogą zostać utracone między warstwami.

Praktyczna klasyfikacja może wyglądać:

Klasa	Ruch	Polityka
control	komendy i failsafe state	mała kolejka, strict rate cap
telemetry	stan i heartbeat	mała kolejka, pacing
video	RTP	adaptacyjny bitrate
bulk	logi/aktualizacje	najniższy priorytet, możliwość wstrzymania

Oznaczenie wszystkiego jako voice niszczy QoS. Priorytet nie rezerwuje capacity i nie zastępuje admission control. AP, bridge i client muszą zachować markings, a test sprawdza zachowanie przy saturacji.

Kolejki i bufferbloat#

Duży buffer poprawia throughput przy burst, ale przechowuje stare pakiety. Dla sterowania lepsza jest krótka kolejka i drop starego niż sekundowe opóźnienie.

Mierzy się sojourn time per queue. Active Queue Management oraz fair queuing mogą ograniczyć bufferbloat, lecz konfiguracja musi pasować do zmiennego Wi‑Fi rate. Shaper ustawiony poniżej aktualnego goodput przenosi kolejkę do kontrolowanego miejsca.

Video encoder powinien mieć feedback z sieci. Sam limit średniego bitrate nie ogranicza peaków I-frame. Token bucket i pacing łagodzą burst.

Power save#

Tryb oszczędzania energii buforuje ruch do momentów wybudzenia. Zmniejsza pobór, ale zwiększa latency/jitter. Linux iw pozwala sprawdzić i ustawić power save; konkretne zachowanie zależy od drivera oraz AP.

Na UAV radio pracujące ciągle może pobierać kilka watów wraz z companion computerem. Decyzja jest systemowa:

control link: zwykle priorytet latency;
sensor upload: możliwy duty cycle;
serwis na ziemi: power save akceptowalny.

Nie wystarczy wyłączyć power save w user space, jeśli firmware ma własne stany oszczędne.

Bezpieczeństwo#

Sieć musi zapewniać poufność, integralność, wzajemne uwierzytelnienie i zarządzanie kluczami. W praktyce stosuje się aktualnie wspierane mechanizmy WPA2/WPA3 odpowiednie do urządzeń, z unikalnymi credentials i ochroną management plane.

Zasady:

brak wspólnego fabrycznego hasła floty;
rotacja i odwołanie klucza pojedynczego UAV;
wyłączone zbędne usługi;
firewall default-deny;
osobne konto serwisowe i operatorskie;
podpisane aktualizacje;
rate limiting logowania;
audyt zdarzeń association/authentication;
kryptografia aplikacyjna dla komend krytycznych.

Szyfrowanie WLAN kończy się na AP/bridge. Jeśli pakiet idzie dalej przez Ethernet/LTE/Internet, potrzebuje ochrony end-to-end. MAC filtering nie jest uwierzytelnieniem.

System musi bezpiecznie zachować się przy deauthentication, utracie klucza, błędnym czasie certyfikatu i pełnym dysku logów. Nie opisujemy technik zakłócania ani obchodzenia zabezpieczeń; odporność weryfikuje się przez kontrolowane testy utraty, przeciążenia i błędów konfiguracji.

Heartbeat i stan łącza#

Association nie znaczy, że aplikacja działa. Heartbeat powinien przechodzić tą samą ścieżką co komendy i zawierać monotoniczny sequence oraz timestamp.

Stan może mieć poziomy:

RF associated
IP reachable
secure session established
application heartbeat fresh
operator authority valid
command stream fresh

Failsafe reaguje na najwyższą potrzebną warstwę. Ping do AP nie potwierdza, że GCS odbiera telemetrię. RSSI nie potwierdza uplink.

Progi używają persistence i hysteresis. Jedna utracona ramka nie wywołuje lądowania, lecz kilka sekund starych komend nie może pozostawić trybu „connected”.

Redundancja#

Dwa radia są niezależne tylko wtedy, gdy nie współdzielą krytycznych punktów:

zasilania/regulatora;
USB hubu;
anteny lub przewodu;
pasma/kanału/interferencji;
procesu routingu;
AP i backhaulu;
klucza/konfiguracji.

Można duplikować małe komunikaty na dwóch ścieżkach z sequence/deduplication. Video zwykle wybiera jedną ścieżkę lub adaptuje. Bonding na warstwie Ethernet może ukryć awarię, ale jego failover latency musi być zmierzone.

Niezależne RC jako last-resort nie zastępuje automatycznego zachowania po utracie IP, bo operator może również nie mieć widoczności.

Integracja sprzętowa#

Karta Wi‑Fi może używać USB, SDIO, PCIe lub Ethernet bridge. USB ma wygodę, ale podatność na złącza, reset busu i wspólny hub. SDIO wymaga dobrego drivera i sygnałów PCB. PCIe zwiększa złożoność zasilania oraz EMI.

Sprawdzić należy:

obsługę trybu w mainline/vendor driver;
stabilność firmware i recovery;
możliwość odczytu per-chain RSSI/retries;
temperaturę oraz thermal throttling;
regulatory database;
start po brownout;
MAC address persistence;
watchdog radia i procesu sieciowego;
długoterminową dostępność exact module.

Adapter konsumencki może zmienić chipset bez zmiany nazwy handlowej. BOM powinien zawierać VID/PID, revision i firmware.

EMI i współistnienie#

Radio Wi‑Fi może desensytyzować inne odbiorniki przez harmoniczne, intermodulację, wspólną masę lub przeciążenie LNA. USB 3.x i przetwornice także generują szerokopasmowe zakłócenia.

Plan obejmuje:

separację anten;
filtry i ekranowanie;
kabel/coax routing;
pomiary z każdym nadajnikiem osobno i razem;
GNSS C/N0, RC LQ, LTE RSRP oraz Wi‑Fi retries;
pełną moc napędu i obciążenie CPU.

Współistnienie dwóch Wi‑Fi na sąsiednich kanałach nie jest gwarantowane przez różne SSID. Front-end może zostać przeciążony mimo braku overlap kanałów.

Obserwowalność#

Log na UAV i stacji powinien mieć wspólny czas oraz:

association/disconnect events z reason code;
channel, bandwidth, MCS/NSS/GI;
RSSI per chain i noise;
tx retries, failed, rx drop;
channel busy/tx time;
queue length/drop/sojourn;
per-flow bitrate, loss, reorder i RTT;
application message age;
video encode/decode timestamps;
CPU, memory, temperature i supply;
pozycję, attitude i antenna state.

Bez pozycji nie da się odtworzyć shadowing. Bez application age łatwo uznać buforowane dane za działające łącze.

Plan testów#

Laboratoryjny#

Zweryfikować exact chipset, driver, firmware i regulatory domain.
Zmierzyć throughput, RTT distribution i loss dla każdego kierunku.
Saturate video/bulk i sprawdzić control queue.
Wprowadzić attenuation oraz burst loss w kontrolowanym torze.
Restartować AP, client, DHCP, routing i aplikację.
Testować brownout, temperaturę i obciążenie CPU.

Terenowy#

Trasa ma ground truth odległości i wysokości. UAV wykonuje yaw/roll, zasłonięcie kadłubem, lot niski i wznoszenie. Test powtarza się na kanałach o różnym zajęciu.

Rejestruje się oba kierunki. GCS wysyła mały probe z timestamp, UAV odpowiada niezależnie od video. Wynik to mapa percentyli, nie jeden zasięg.

Handover/mesh#

Wyłącza się każdy AP/węzeł i mierzy application outage. Ruch trwa podczas zmiany ścieżki. Sprawdza się reordering, duplikaty, utratę sesji secure i stale routes.

Failsafe#

Stopniowo zwiększa się loss/latency, rozłącza radio, zamraża aplikację i pozostawia association. Platforma najpierw działa w SITL/HIL, potem na uwięzi i małej energii. Reakcja nie może zależeć od ręcznego rozpoznania przez operatora.

Kryteria odbioru#

Łącze jest zakwalifikowane, gdy dla jawnej obwiedni trasy, attitude, kanału i interferencji spełnia:

p99/p99.9 age komend i telemetrii;
maksymalny burst loss;
minimalny goodput w obu kierunkach;
video latency przy adaptacji;
czas wykrycia utraty i failsafe;
reconnect/handover time;
stabilność termiczną i zasilania;
bezpieczeństwo session/key management;
brak degradacji GNSS/RC/pozostałych radii;
odtwarzalny log ze wszystkich warstw.

Kryteria dotyczą całego systemu: antenna–radio–driver–network–application. Udany ping i test prędkości na stole nie kwalifikują łącza UAV.

Najczęstsze błędy#

Traktowanie PHY rate jako goodput.
Brak marginesu dla wymaganej modulacji.
Test tylko downlink wideo, bez uplink ACK/komend.
Szeroki kanał w zatłoczonym paśmie bez survey.
Antena z nullem skierowanym na stację.
Video i sterowanie w jednej długiej kolejce.
Wszystkie pakiety oznaczone najwyższym priorytetem.
UDP bez sequence, freshness i congestion control.
Multicast jako „darmowe kopiowanie”.
Mesh bez policzenia airtime per hop.
RSSI jako jedyny health metric.
Association traktowane jako sprawna aplikacja.
Wspólny klucz całej floty.
Redundancja przez dwie karty na jednym hubie.
Brak testu DFS, restartu i frozen process.

Powiązane tematy#

Systemy RC UAV — niezależne łącze sterujące i metryki LQ.
LTE jako łącze UAV — sieć operatorska i transport przez Internet.
MAVLink — telemetria oraz identyfikacja wiadomości.
Transmisja wideo UAV — encoder, RTP i latency.
Budżet łącza radiowego — EIRP, czułość i fade margin.
Sieci mesh dla UAV — routing, wielohop i mobilność.
EMI/EMC flight controllera — współistnienie radii i cyfrowej elektroniki.
Failsafe jako maszyna stanów — freshness, persistence i reakcja.

Przypisy#

Bibliografia jest generowana z centralnego rejestru. Warstwę MAC/PHY oparto na IEEE 802.11-2024, tryby i 802.11s na dokumentacji Linux Wireless, mapowanie QoS na RFC 8325, transport UDP na RFC 8085, a metryki real-time video na RFC 3550. Dokładne kanały, moce i funkcje wymagają sprawdzenia bieżących przepisów oraz dokumentacji konkretnego chipsetu, sterownika i kraju użytkowania.

Źródła z centralnego rejestru

IEEE 802.11-2024 — Wireless LAN MAC and PHY Specifications [standard techniczny]
Linux Wireless: Wireless operating modes [dokumentacja projektu]
Linux Wireless: IEEE 802.11s mesh networking [dokumentacja projektu]
Linux Wireless: Automatic Channel Selection and channel survey [dokumentacja projektu]
IETF RFC 8325: Mapping Diffserv to IEEE 802.11 [standard internetowy]
IETF RFC 8085: UDP Usage Guidelines [Best Current Practice]
IETF RFC 3550: RTP — A Transport Protocol for Real-Time Applications [standard internetowy]
Sumit Sharma, „Drone Development from Concept to Flight” [książka]
Ty Audronis, „Drony. Wprowadzenie” [książka]