Bluetooth w UAV

Bluetooth w bezzałogowym statku powietrznym najlepiej traktować jako lokalne łącze serwisowe i konfiguracyjne, a nie domyślny kanał sterowania lotem. Dobrze zaprojektowany interfejs Bluetooth Low Energy (LE) pozwala bez rozbierania obudowy odczytać stan kontrolera, ustawić parametry na ziemi, pobrać krótki log, zidentyfikować moduły albo przeprowadzić kontrolowaną aktualizację. Ten sam interfejs może przenosić telemetrię podczas prób stanowiskowych i lotów w niewielkiej odległości. Nie zwalnia to jednak konstruktora z policzenia budżetu radiowego, zmierzenia opóźnień i utraty pakietów ani z zaprojektowania failsafe'u niezależnego od telefonu.

Określenie „Bluetooth 5”, „5.4” lub „6.2” nie opisuje kompletnego zestawu możliwości urządzenia. Konkretne PHY, Data Length Extension, Extended Advertising, liczba jednoczesnych połączeń i parametry bezpieczeństwa zależą od kontrolera, stosu, konfiguracji oraz drugiej strony łącza. Projekt należy więc specyfikować funkcjami i mierzalnymi wymaganiami, nie numerem wersji umieszczonym w katalogu.

Spis treści#

• Gdzie Bluetooth ma sens
• Bluetooth LE a Bluetooth Classic
• Architektura stosu
• Kanały, PHY i hopping
• Reklamowanie, skanowanie i zestawienie połączenia
• Parametry połączenia
• GATT, ATT i L2CAP
• Przepustowość i opóźnienie
• Projekt danych UAV
• Bezpieczeństwo i cykl życia kluczy
• Współistnienie w paśmie 2,4 GHz
• Antena i budżet łącza
• Integracja z kontrolerem lotu
• Zasilanie i EMC
• Failsafe i ograniczenie funkcji w locie
• Diagnostyka i obserwowalność
• Plan prób
• Kryteria odbioru
• Powiązane tematy
• Przypisy

Gdzie Bluetooth ma sens#

Najlepsze zastosowania wynikają z jego powszechnej dostępności w telefonach, tabletach i laptopach oraz z małego poboru energii modułów LE:

Bluetooth nie powinien być jedyną barierą bezpieczeństwa przed uruchomieniem napędu. Telefon może utracić połączenie, system operacyjny może wstrzymać aplikację, a pasmo 2,4 GHz może być zajęte. Komendy krytyczne wymagają lokalnych warunków zezwalających: stanu rozbrojonego, fizycznej sekwencji serwisowej, ograniczenia czasu i niezależnej walidacji po stronie kontrolera.

W roli łącza głównego Bluetooth jest uzasadniony tylko po kwalifikacji konkretnego systemu w jego środowisku. W typowym portalu konstruktorskim rozsądniej porównywać go z Wi‑Fi, LoRa i klasycznym systemem RC, zamiast zakładać zamienność tych technologii.

Bluetooth LE a Bluetooth Classic#

Bluetooth obejmuje dwa zasadniczo odmienne transporty radiowe. BR/EDR, potocznie Bluetooth Classic, używa 79 kanałów o odstępie 1 MHz i jest kojarzony między innymi z profilami audio oraz portem szeregowym SPP. Bluetooth LE używa 40 kanałów o odstępie 2 MHz: trzech podstawowych kanałów reklamowych i 37 kanałów danych. Obie rodziny pracują w paśmie ISM 2,4 GHz, lecz mają inne procedury dostępu, profile, charakterystyki energetyczne i API.

W nowym module UAV preferowane jest LE, ponieważ:

• telefon nie potrzebuje profilu SPP, którego obsługa różni się między systemami mobilnymi;
• usługi GATT można opisać formalnie przez UUID, prawa dostępu i właściwości;
• urządzenie może przez większość czasu pozostawać w stanie uśpienia lub reklamować się rzadko;
• dostępne są PHY 1M, opcjonalne 2M i opcjonalne LE Coded;
• stos łatwiej ograniczyć do małego, jawnego interfejsu serwisowego.

BR/EDR nadal bywa użyteczny w starszych mostach UART–Bluetooth. Taki moduł może działać jak bezprzewodowy kabel szeregowy, ale prostota interfejsu nie oznacza automatycznie dobrej kontroli dostępu. Przy modernizacji urządzenia warto rozdzielić kompatybilność ze starym narzędziem od projektu nowego, autoryzowanego API.

Architektura stosu#

Bluetooth LE jest stosem warstwowym, nie „przezroczystym radiem”. Uproszczony tor wygląda następująco:

aplikacja UAV / aplikacja mobilna
          │
     profile i usługi GATT
          │
      ATT / SMP / GAP
          │
          L2CAP
          │
        Link Layer
          │
      LE 1M / 2M / Coded PHY

PHY definiuje sposób nadawania symboli. Link Layer planuje zdarzenia radiowe, skacze po kanałach, potwierdza pakiety i wykonuje retransmisje. L2CAP multipleksuje protokoły wyższych warstw i może oferować kanały zorientowane połączeniowo. ATT udostępnia atrybuty, a GATT organizuje je w usługi i charakterystyki. SMP odpowiada za parowanie i dystrybucję kluczy. GAP opisuje role, wykrywanie, łączenie oraz widoczność urządzenia.

W układzie SoC kontroler radiowy i host mogą działać na jednym MCU. W bardziej złożonym module kontroler Bluetooth komunikuje się z hostem przez HCI, na przykład po UART lub USB. Jeszcze innym wariantem jest moduł z własnym stosem i firmowym protokołem komend. Wybór wpływa na aktualizacje, debugowanie i możliwość precyzyjnego sterowania parametrami połączenia.

W UAV należy określić także granicę błędu. Jeżeli stos Bluetooth zawiesi się lub zabraknie pamięci, regulator lotu nie może przestać wykonywać pętli sterowania. Najbezpieczniej umieścić radio na oddzielnym MCU albo przynajmniej w zadaniu o niższym priorytecie, z ograniczonymi kolejkami i możliwością jednostronnego odcięcia interfejsu.

Kanały, PHY i hopping#

Bluetooth LE przesyła dane na 40 kanałach w paśmie 2,4 GHz. Po zestawieniu połączenia urządzenia zmieniają częstotliwość według uzgodnionego algorytmu. Adaptacyjna mapa kanałów pozwala wyłączyć częstotliwości ocenione jako złe. Hopping zmniejsza zależność od pojedynczego wąskiego zakłócenia, ale nie tworzy odporności na szerokopasmowe zajęcie pasma ani na źle rozmieszczoną antenę.

Podane szybkości są szybkościami warstwy fizycznej/protokołowej, nie użytecznym transferem aplikacji. Bluetooth SIG podaje orientacyjnie około 1,4 Mbit/s maksymalnego strumienia aplikacyjnego dla LE 2M i około 100 kbit/s dla LE Coded S=8 w sprzyjającej konfiguracji. Realny wynik zależy od kontrolera, długości PDU, interwału, liczby pakietów w zdarzeniu, API systemu operacyjnego i ruchu w eterze.

LE Coded nie powinien być włączany automatycznie jako „tryb dalekiego zasięgu”. Dłuższy czas zajęcia kanału zwiększa koszt każdej wiadomości, zmniejsza pojemność systemu i może pogorszyć współistnienie wielu urządzeń. Najpierw określa się minimalny payload i dopuszczalny wiek danych, a potem dobiera PHY.

Reklamowanie, skanowanie i zestawienie połączenia#

Urządzenie peryferyjne zwykle rozpoczyna od advertisingu. Krótkie pakiety informują, że urządzenie istnieje i ewentualnie pozwalają rozpocząć połączenie. Central — zazwyczaj telefon lub komputer serwisowy — skanuje, wybiera właściwy egzemplarz i inicjuje połączenie.

Interwał reklamowania jest kompromisem. Częste pakiety skracają czas wykrycia, ale zwiększają pobór prądu i widoczność radiową. Rzadkie reklamowanie oszczędza energię, lecz pogarsza ergonomię. Dla UAV zasilanego z głównego akumulatora koszt energetyczny zwykle nie jest krytyczny; ważniejsza bywa kontrola, kiedy urządzenie jest wykrywalne.

Rozsądna maszyna stanów może wyglądać tak:

OFF
 │ zasilanie
 ▼
NIEWIDOCZNY ── przycisk serwisowy / stan rozbrojony ──► ADVERTISING
                                                        │ autoryzacja
                                                        ▼
                                                   POŁĄCZONY
                                                        │ timeout / start lotu
                                                        ▼
                                                   NIEWIDOCZNY

Stała nazwa zawierająca numer seryjny nie jest dobrym identyfikatorem reklamowym. Można użyć krótkiego oznaczenia sesji, a właściwą tożsamość potwierdzić po zaszyfrowaniu połączenia. Extended Advertising zwiększa pojemność danych i może przenosić część transmisji na kanały dodatkowe, lecz wsparcie telefonu i stosu trzeba sprawdzić eksperymentalnie.

Parametry połączenia#

Połączenie LE składa się ze zdarzeń połączeniowych. Najważniejsze parametry to:

• connection interval — odstęp między zdarzeniami;
• peripheral latency — ile zdarzeń peryferium może pominąć, gdy nie ma danych;
• supervision timeout — po jakim czasie bez poprawnej wymiany połączenie jest uznawane za utracone;
• PHY i parametry długości danych;
• liczba pakietów, które kontroler jest w stanie wymienić w jednym zdarzeniu.

Mały interwał może obniżyć czas oczekiwania, ale zwiększa częstotliwość budzenia radia i obciążenie obu urządzeń. Duży interwał oszczędza energię, lecz tworzy dolną granicę opóźnienia nowych danych. Peripheral latency jest korzystne dla wolnego czujnika, ale nie dla kanału, w którym operator oczekuje natychmiastowej odpowiedzi.

Bluetooth Core 6.2 wprowadził opcjonalne Shorter Connection Intervals, redukujące minimalny interwał z historycznych 7,5 ms do 375 µs. Nie należy zakładać ich dostępności w obecnych telefonach i modułach. System musi negocjować funkcję i posiadać poprawny profil rezerwowy.

Supervision timeout nie jest odpowiednikiem kompletnego failsafe'u. Informuje host, że połączenie wygasło, ale wykrycie może nastąpić później niż termin ważności konkretnej komendy. Każdy rekord sterujący powinien mieć własny numer sekwencji, znacznik czasu lub krótki czas życia.

GATT, ATT i L2CAP#

GATT reprezentuje dane jako hierarchię usług, charakterystyk i deskryptorów. Charakterystyka może pozwalać na odczyt, zapis, zapis bez odpowiedzi, notification albo indication. Notification nie ma potwierdzenia na poziomie ATT, chociaż warstwa łącza nadal realizuje własne potwierdzenia radiowe. Indication wymaga odpowiedzi klienta i ogranicza tempo, ale daje aplikacji serwera informację o dostarczeniu na tym poziomie.

Przykładowy, celowo mały model usług UAV:

Nie należy tworzyć osobnej charakterystyki dla każdego pola o dużej częstotliwości. Narzut transakcji i liczba zdarzeń w aplikacji mobilnej mogą wtedy dominować nad payloadem. Dla telemetrii lepsza jest zwarta, wersjonowana ramka binarna.

ATT MTU określa maksymalny rozmiar jednostki ATT. Domyślna mała wartość jest kompatybilna, lecz ogranicza użyteczny payload. Większe MTU i Data Length Extension zmniejszają udział nagłówków, o ile obsługują je obie strony. MTU aplikacyjne nie jest tym samym co maksymalny PDU Link Layer; stos może fragmentować dane przez L2CAP.

Dla dużego, ciągłego strumienia warto rozważyć L2CAP Credit-Based Connection-Oriented Channels. Kanał kredytowy daje lepszą kontrolę przepływu niż zbiór przypadkowych zapisów GATT. Trzeba jednak sprawdzić API na docelowych systemach mobilnych. GATT jest zwykle bardziej przenośny i łatwiejszy do inspekcji.

Przepustowość i opóźnienie#

Przepustowość należy mierzyć w bajtach danych aplikacji na sekundę. Różnica między szybkością PHY a wynikiem aplikacji obejmuje preambułę, adres dostępu, nagłówki, CRC, odstępy międzyramkowe, potwierdzenia, retransmisje, L2CAP, ATT oraz okresy bez transmisji.

Użyteczny model strumienia to:

throughput_app ≈ payload_w_zdarzeniu / connection_interval × skuteczność

„Skuteczność” nie jest stałą katalogową. Zależy między innymi od liczby PDU mieszczących się w zdarzeniu, harmonogramu kontrolera i jakości kanału. Dlatego wynik z dwóch telefonów może się różnić przy identycznym module UAV.

Opóźnienie trzeba rozłożyć na składniki:

t_total = t_source + t_queue + t_wait_event + t_radio
        + t_host_stack + t_mobile_scheduler + t_application

Największa zmienność często nie powstaje w samym radiu, lecz w kolejce aplikacji i planowaniu systemu telefonu. Pomiar round-trip time bez numeru sekwencji nie ujawni, czy aplikacja pokazuje świeży rekord, czy stary element z bufora.

Dla telemetrii stanu ważniejszy od średniej przepustowości jest wiek ostatniej próbki. Gdy łącze zwalnia, kolejka „wszystkich próbek” powoduje narastanie opóźnienia. Wartość typu attitude lub napięcie może być wysyłana polityką „latest wins”: stara, jeszcze niewysłana próbka zostaje zastąpiona nową. Logi i transakcje konfiguracyjne wymagają natomiast niezawodnej kolejności i kontroli kompletności.

Projekt danych UAV#

Ramka binarna powinna być jednoznacznie wersjonowana. Przykład struktury koncepcyjnej:

typedef struct __attribute__((packed)) {
    uint8_t  version;
    uint8_t  message_type;
    uint16_t sequence;
    uint32_t monotonic_ms;
    uint16_t payload_length;
    uint16_t flags;
    /* payload, następnie kontrola integralności aplikacyjnej */
} ble_uav_header_t;

Układ bajtów, endianess, skale wielkości i jednostki muszą być częścią specyfikacji. battery_mv = 15680 jest jednoznaczniejsze niż liczba zmiennoprzecinkowa bez opisanej jednostki. Flagi ważności pozwalają odróżnić zero pomiarowe od braku danych.

W kanale konfiguracyjnym potrzebna jest transakcja:

1. klient wysyła żądanie z identyfikatorem i oczekiwaną wersją konfiguracji;
2. UAV waliduje zakresy i stan systemu;
3. zmiana jest zapisywana atomowo albo wcale;
4. odpowiedź zawiera kod wyniku i nową wersję;
5. klient odczytuje stan po zmianie, zamiast zakładać sukces.

Komendy nie powinny być mapowane bezpośrednio na zapis dowolnego adresu pamięci ani na surową konsolę powłoki. Publiczne API jest węższe, wersjonowane i sprawdzane. MAVLink można tunelować przez Bluetooth, lecz nadal potrzebuje kontroli dostępu oraz limitowania ruchu. Sam fakt użycia znanego protokołu nie rozwiązuje autoryzacji.

Bezpieczeństwo i cykl życia kluczy#

Bluetooth rozróżnia pairing, czyli ustanowienie materiału kluczowego, i bonding, czyli zachowanie go do następnych połączeń. Szyfrowanie łącza chroni transmisję radiową, lecz polityka systemu musi dodatkowo określić, kto może wywołać daną operację.

LE Secure Connections używa ECDH na krzywej P-256 do ustanawiania kluczy. Dostępne modele kojarzenia to Just Works, Numeric Comparison, Passkey Entry i Out of Band. Wybór wynika z możliwości wejścia/wyjścia obu urządzeń. Just Works nie zapewnia ochrony przed aktywnym pośrednikiem podczas parowania, mimo że późniejsze łącze może być szyfrowane.

Dla interfejsu serwisowego UAV zalecane są:

• LE Secure Connections zamiast legacy pairing;
• uwierzytelnione kojarzenie, jeżeli sprzęt pozwala potwierdzić tożsamość;
• tryb parowania dostępny tylko lokalnie i przez ograniczony czas;
• lista dozwolonych bondów o jawnej pojemności;
• procedura usunięcia pojedynczego bondu oraz pełnego resetu właściciela;
• brak stałych kluczy fabrycznych wspólnych dla całej serii;
• podpisywanie obrazów firmware niezależnie od szyfrowania Bluetooth;
• dziennik zmian konfiguracji i licznik nieudanych prób.

Jeżeli płytka nie ma wyświetlacza ani klawiatury, kanał OOB może wykorzystywać fizycznie kontrolowany nośnik lub złącze serwisowe. Kod nadrukowany na obudowie ma sens tylko wtedy, gdy nie jest publicznie widoczny i istnieje bezpieczna procedura zmiany właściciela.

Prywatność jest osobnym problemem. Stały publiczny adres albo numer seryjny w advertisingu ułatwia korelację obserwacji. Mechanizmy adresów prywatnych rozwiązywanych przez IRK ograniczają to ryzyko, lecz muszą być poprawnie skonfigurowane na obu stronach.

Poziom zabezpieczenia należy sprawdzać dla każdej charakterystyki. To, że połączenie zostało zestawione, nie oznacza jeszcze szyfrowania, uwierzytelnienia ani właściwego użytkownika. Operacje zapisu konfiguracji powinny wymagać silniejszych warunków niż anonimowy odczyt nieszkodliwej wersji protokołu.

Współistnienie w paśmie 2,4 GHz#

Bluetooth LE, Wi‑Fi 2,4 GHz i liczne systemy RC korzystają z tego samego pasma. Kanał Wi‑Fi o szerokości 20 MHz pokrywa wiele węższych kanałów LE. Hopping i klasyfikacja kanałów pomagają, ale odbiornik Bluetooth może zostać chwilowo odczulony przez bliski, silny nadajnik nawet wtedy, gdy nominalnie używa innej częstotliwości.

Najtrudniejszy przypadek to współlokacja: radio Wi‑Fi lub nadajnik wideo znajduje się kilka centymetrów od modułu LE i nadaje z dużo większą mocą niż sygnał pożądany odbierany z telefonu. Liczy się wtedy separacja anten, izolacja, ekranowanie, filtracja i synchronizacja pracy nadajników, a nie tylko odległość UAV–operator.

Układ combo z Wi‑Fi i Bluetooth może oferować sprzętowy interfejs koegzystencji, który przekazuje priorytety i okna czasowe. Dwa niezależne moduły bez takiego interfejsu wymagają badań systemowych. Test „każde radio osobno działa” jest niewystarczający.

Scenariusze kwalifikacyjne powinny obejmować:

• równoczesny uplink wideo Wi‑Fi i transfer BLE;
• aktywny nadajnik RC na platformie oraz przy operatorze;
• obrót kadłuba i zmianę polaryzacji anten;
• pracę silników i ESC w pełnym zakresie obciążenia;
• otoczenie z zajętymi kanałami Wi‑Fi;
• co najmniej dwa modele telefonu z różnymi kontrolerami radiowymi.

Antena i budżet łącza#

Podstawowy budżet łącza ma postać:

P_rx = P_tx + G_tx + G_rx - L_path - L_cable - L_misc
margin = P_rx - sensitivity_required

Czułość zależy od PHY i wymaganej stopy błędów. Nordic podaje dla nRF52840 moc nadajnika do +8 dBm i obsługę 2 Mbit/s, 1 Mbit/s oraz Long Range; są to parametry układu, nie gotowego produktu po zamontowaniu w kadłubie. Texas Instruments dla CC2652R publikuje między innymi najlepszą czułość rzędu −105 dBm. Porównując liczby, trzeba używać tego samego PHY, warunków i kryterium pomiarowego.

Antena chipowa lub ścieżkowa wymaga poprawnego obszaru bez miedzi, sieci dopasowującej i geometrii zgodnej z dokumentacją referencyjną. Akumulator, włókno węglowe, kamera, radiator, przewody silnikowe i ręka serwisanta zmieniają impedancję oraz charakterystykę promieniowania. Kadłub z kompozytu węglowego może silnie ekranować radio.

Pomiar RSSI w jednym ustawieniu nie opisuje niezawodności. Należy wykonać obrót 3D platformy i telefonu, sprawdzić wariant z anteną zasłoniętą przez akumulator oraz z pełnym wyposażeniem. Jeśli używany jest zewnętrzny front-end RF, wzrost mocy nadajnika nie zastąpi poprawnej czułości odbioru, liniowości i zgodności regulacyjnej kompletnego urządzenia.

Integracja z kontrolerem lotu#

Typowe warianty sprzętowe są trzy:

1. SoC radiowy jako osobny procesor — BLE kończy się na module, a flight controller wymienia z nim ramki przez UART, SPI lub USB;
2. BLE w procesorze pomocniczym — ten sam MCU obsługuje radio i funkcje serwisowe, ale nie główną pętlę lotu;
3. BLE w głównym MCU — rozwiązanie zwarte, wymagające szczególnie rygorystycznego planowania czasu i pamięci.

Osobny procesor daje silną izolację awarii i ułatwia certyfikację interfejsu. Wymaga jednak własnego bootloadera, protokołu międzyprocesorowego i strategii zgodności wersji. Interfejs powinien mieć framing, długość, CRC, numer sekwencji i limity czasu. Surowy UART bez mechanizmu odzyskania synchronizacji potrafi po pojedynczym błędzie przesunąć granice wszystkich kolejnych rekordów.

Warstwa pośrednia powinna wystawiać tylko potrzebne dane. Moduł BLE nie musi mieć zapisu do całej mapy parametrów ani dostępu do surowych poleceń wykonawczych. Dobry podział to:

telefon ─ BLE/GATT ─ MCU radiowy ─ kolejka i walidator ─ flight controller
                                                │
                                        polityka stanu lotu

Każdy kierunek ma osobne limity. Zalanie zapisami z telefonu nie może wyprzeć krytycznej telemetrii wewnętrznej ani zająć całej magistrali. Watchdog modułu radiowego może go zresetować bez resetowania kontrolera lotu.

Zasilanie i EMC#

Średni pobór energii BLE jest mały, ale prąd nadajnika ma charakter impulsowy. Kondensatory odsprzęgające i przetwornica muszą utrzymać napięcie w czasie zdarzenia radiowego. Brownout modułu może wyglądać jak losowe zerwanie połączenia, szczególnie gdy jednocześnie uruchamia się inne obciążenie.

Linie zasilania i zegarowe przetwornic impulsowych mogą podnosić tło RF. Z kolei nadajnik 2,4 GHz może sprzęgać się do wrażliwych wejść analogowych albo przewodów bez poprawnej drogi powrotnej. Projekt PCB powinien zachować ciągłą płaszczyznę odniesienia poza obszarem anteny, krótkie odsprzęganie, kontrolowaną linię RF i dystans od szybkich interfejsów.

Test EMC w praktyce obejmuje dwa kierunki:

• czy silniki, ESC, DC/DC i nadajniki pokładowe pogarszają PER oraz czułość Bluetooth;
• czy transmisja Bluetooth zmienia wskazania IMU, magnetometru, GNSS, ADC lub interfejsów cyfrowych.

Więcej o tym rozdzieleniu opisuje artykuł EMI/EMC kontrolera lotu.

Failsafe i ograniczenie funkcji w locie#

Kanał Bluetooth powinien być klasyfikowany według funkcji, nie według samej technologii. Odczyt diagnostyczny może pozostać dostępny w locie, podczas gdy zapis konfiguracji regulatora musi być zablokowany. Aktualizacja firmware wymaga stanu rozbrojonego, stabilnego zasilania i jawnej procedury wejścia.

Przykładowa macierz:

Utrata Bluetooth nie może wywoływać nieprzewidzianej zmiany trybu lotu, jeśli ten kanał nie jest zatwierdzonym łączem dowodzenia. Jeżeli w prototypie służy do sterowania stanowiskiem lub pojazdem, komendy muszą wygasać lokalnie po krótkim czasie i przechodzić do bezpiecznego stanu. Ponowne połączenie nie może automatycznie odtwarzać starego polecenia z kolejki.

Diagnostyka i obserwowalność#

Moduł powinien liczyć co najmniej:

• liczbę reklamowań, prób połączeń i rozłączeń;
• powód ostatniego rozłączenia;
• wynegocjowane PHY, interwał, MTU i długość danych;
• RSSI w czasie oraz liczbę zmian mapy kanałów, jeśli stos je udostępnia;
• bajty i rekordy w obu kierunkach;
• przepełnienia kolejek i odrzucone komendy;
• czas maksymalnego blokowania magistrali do FC;
• resety kontrolera radia i przyczynę resetu;
• wynik ostatniego parowania oraz błędy autoryzacji.

Log powinien używać czasu monotonicznego wspólnego lub mapowalnego na czas flight controllera. Sam komunikat „Bluetooth disconnected” bez powodu, parametrów i stanu innych radii ma małą wartość diagnostyczną.

Sniffer protokołu jest użyteczny do weryfikacji sekwencji i czasów, ale nie zastępuje pomiaru na granicy aplikacji. Najbardziej miarodajny test wstawia numer sekwencji i timestamp w źródle UAV, rejestruje odbiór w aplikacji i koreluje wynik z RSSI, ruchem Wi‑Fi oraz obciążeniem CPU.

Plan prób#

Próby funkcjonalne na stole#

1. Sprawdź wykrywanie po zimnym starcie i po resecie modułu.
2. Zweryfikuj negocjowane PHY, MTU, interwał i prawa każdej charakterystyki.
3. Przetestuj odczyt, zapis, notification, indication i kontrolę przepływu.
4. Wymuś błędną wersję ramki, długość, kolejność i niedozwolony zakres parametru.
5. Zapełnij kolejki szybciej, niż radio może je opróżniać.
6. Przerwij połączenie w każdym etapie transakcji i DFU.

Próby bezpieczeństwa#

1. Spróbuj uzyskać dostęp bez parowania, po parowaniu nieautoryzowanym i po usunięciu bondu.
2. Sprawdź, czy Just Works nie pojawia się jako cichy fallback.
3. Wypełnij pamięć bondów i oceń politykę usuwania.
4. Powtórz starą komendę oraz rekord z wcześniejszej sesji.
5. Sprawdź tryb zmiany właściciela i reset kluczy.
6. Potwierdź odrzucenie obrazu firmware z błędnym podpisem.

Próby radiowe i systemowe#

Wykonaj testy w komorze lub w kontrolowanej przestrzeni z regulowanym tłumieniem, a następnie na kompletnej platformie. Rejestruj packet/record error rate, RTT, percentyle wieku danych i rozłączenia. Zmieniaj orientację UAV, przesłaniaj antenę, uruchamiaj Wi‑Fi, RC, GNSS, silniki i wszystkie przetwornice.

Test zasięgu w otwartym terenie powinien być poprzedzony próbą naziemną, a w locie przeprowadzany zgodnie z przepisami i planem bezpieczeństwa. „Maksymalna odległość, przy której raz się połączyło” nie jest parametrem użytkowym. Potrzebna jest granica zapewniająca wymagany margines i jakość w najgorszej orientacji.

Kryteria odbioru#

Wymagania powinny być liczbowe. Przykładowy zestaw dla serwisowego BLE:

Limity zależą od funkcji. Dla odczytu wersji czas odpowiedzi 500 ms może być doskonały; dla eksperymentalnej pętli operatorskiej byłby niedopuszczalny. Kryterium musi więc wskazywać typ wiadomości, stan UAV, telefon referencyjny i profil interferencji.

Powiązane tematy#

• Wi‑Fi jako łącze UAV
• LoRa w UAV
• Systemy RC
• Budżet łącza radiowego
• MAVLink — architektura protokołu
• UART w UAV
• EMI/EMC kontrolera lotu
• Failsafe jako maszyna stanów

Przypisy#

1. Bluetooth SIG, Bluetooth Core Specification, version 6.2, 3 listopada 2025, https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/Core-62/out/en/index-en.html (dostęp: 15 sierpnia 2026).
2. Bluetooth SIG, The Bluetooth Low Energy Primer, https://www.bluetooth.com/bluetooth-le-primer/ (dostęp: 15 sierpnia 2026).
3. Bluetooth SIG, Feature Enhancements Overview, sekcje LE 2M, LE Coded i Extended Advertising, https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/ (dostęp: 15 sierpnia 2026).
4. Bluetooth SIG, Bluetooth Security and Privacy Best Practices Guide, revision 4, https://www.bluetooth.com/bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/ (dostęp: 15 sierpnia 2026).
5. Nordic Semiconductor, nRF52840 System on Chip, https://www.nordicsemi.com/products/nrf52840 (dostęp: 15 sierpnia 2026).
6. Texas Instruments, CC2652R SimpleLink multiprotocol 2.4 GHz wireless MCU, https://www.ti.com/product/CC2652R (dostęp: 15 sierpnia 2026).

Powiązane tematy

Wi‑Fi jako łącze UAVWi‑Fi jako współdzielone łącze IP UAV: tryby AP/station/mesh, budżet radiowy, airtime, MCS i retransmisje, QoS, transport telemetrii oraz wideo, zabezpieczenia, anteny, obserwowalność, failsafe i testy end-to-end.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.Systemy RC dla UAVArchitektura nowoczesnego łącza RC: packet rate, opóźnienie, czułość, LQ/RSSI/SNR, telemetria i zachowanie po utracie ramek.MAVLink — architektura protokołuDokumentacyjny opis MAVLink 2: format on-wire, system/component ID, CRC_EXTRA, podpisywanie oraz semantyka usług parametrów i misji.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.EMI/EMC w kontrolerze lotuEMI/EMC flight controllera jako problem obwodów i pól: pętle di/dt, węzły dv/dt, powroty prądów, sprzężenia przewodzone i promieniowane, ochrona portów oraz plan testów przedzgodnościowych.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.UART i USART w UAVUART od bitu startu do parsera strumieniowego: tolerancja zegarów, oversampling, błędy framing/overrun, idle-line DMA, poziomy TTL i odróżnienie od RS‑232/RS‑485.

Źródła z centralnego rejestru

1. Bluetooth Core Specification 6.2 [specyfikacja protokołu]
2. Bluetooth SIG: The Bluetooth Low Energy Primer [opracowanie techniczne organizacji standaryzacyjnej]
3. Bluetooth SIG: Feature Enhancements Overview — LE 2M, LE Coded and Extended Advertising [dokumentacja organizacji standaryzacyjnej]
4. Bluetooth SIG: Security and Privacy Best Practices Guide, revision 4 [wytyczne bezpieczeństwa]
5. Nordic Semiconductor nRF52840 — official product data [dokumentacja producenta]
6. Texas Instruments CC2652R — product data and datasheet [dokumentacja producenta]
7. Sumit Sharma, „Drone Development from Concept to Flight” [książka]
8. Ty Audronis, „Drony. Wprowadzenie” [książka]