Zaloguj
Bluetooth Low Energy: informacje podstawowe i specyfikacja
Bluetooth Low Energy jest technologią komunikacji bezprzewodowej opracowaną właśnie z myślą o urządzeniach noszonych przez człowieka lub będących w jego pobliżu. BLE nie jest kompatybilne z tradycyjnym protokołem Bluetooth, ale oferuje podobny zasięg przy znacząco mniejszym poborze energii. Obie technologie zwykle koegzystują w urządzeniach bazowych, jak smartfony, tablety czy laptopy, ale nie tylko. Bluetooth Low Energy ma zdefiniowany szereg profili specyficznych dla różnych aplikacji. Profile te definiują sposób organizacji danych w warstwie programowej, podczas gdy implementacja sprzętowa pozostaje stała i od nich niezależna. Inaczej mówiąc – BLE jest implementowane tak samo, jak USB: stała warstwa sprzętowa, różne implementacje programowe zależnie od potrzeb. Podstawowym profilem jest GATT (Generic Attribute Profile – profil ogólny atrybutów). Profil ten określa, w jaki sposób przesyłać niewielkie ilości informacji, zwane atrybutami, między urządzeniem a stacją bazową. Prawie wszystkie inne profile są pochodnymi GATT, stworzonymi do konkretnych zastosowań. Przykładem może być profil HOGP (HID Over GATT), pozwalający na użycie urządzeń USB HID w wariancie bezprzewodowym. Opierają się na nim myszki, klawiatury i kontrolery gier BLE. Jedno urządzenie Bluetooth Low Energy może implementować wiele profili, zależnie od rodzaju przekazywanych informacji.
Wyjątkiem od tych standardowych profili jest odmiana opracowana dla sieci typu Mesh – urządzenia BLE mają bowiem możliwość łączenia się z innymi sprzętami, a implementacja profilu MESH ustala sposób tworzenia sieci i przekazywania informacji między poszczególnymi węzłami. Z kolei MMDL (Mesh Models) to zbiór profili, w tym kontekście zwanych modelami, dedykowanych do specyficznych zastosowań. Ten sposób pracy może być szczególnie pożądany przy tworzeniu sieci czujników monitorujących większą przestrzeń, a awaria lub utrata zasięgu, nawet przez kilka z nich, nie powinna wpływać na łączność pozostałych urządzeń w sieci, chyba że awarii ulegnie jedyny „łącznik” między dwoma obszarami tej infrastruktury.
Oficjalna specyfikacja standardu BLE określa zasięg łączności na poniżej 100 m w otwartej przestrzeni, maksymalną moc nadawania między 10 mW a 500 mW, maksymalny szczytowy pobór prądu poniżej 15 mA. Oczywiście zależy to od warunków propagacji i potrzebnego zasięgu. W praktyce większość urządzeń BLE codziennego użytku ogranicza zasięg do około 10 metrów w otwartej przestrzeni. Prędkość transmisji „w powietrzu” wynosi 128 kbps, 500 kbps, 1 Mbps lub 2 Mbps. Prędkość transferu dostępna dla urządzenia jest odpowiednio niższa ze względu na dodatkowe dane, takie jak preambuła czy suma kontrolna, więc przy prędkości „w powietrzu” 500 kbps użytkownik ma dostępną prędkość do 270 kbps. W przypadku 2 Mbps będzie to wartość 1,37 Mbps – jest to całkiem niezły wynik, wystarczający do implementacji głosowej łączności bezprzewodowej, wymiany danych z opaski sportowej, czy w końcu do grania na konsoli lub komputerze za pomocą bezprzewodowego kontrolera, w którym opóźnienia są zdecydowanie niepożądane. BLE oferuje też wbudowane w warstwę sprzętową szyfrowanie AES-128 w trybie CCM. Implementacja ta pozwala na jednoczesne potwierdzenie „tożsamości” urządzenia i szyfrowaną łączność. Dalsze szyfrowanie nie jest zatem konieczne, choć można je zaimplementować w warstwie aplikacji.
Przegląd układów z Bluetooth Low Energy
Rozważmy typowy scenariusz, w którym trzeba przekazać 1 kB danych z urządzenia noszonego przez użytkownika do jego smartfona. Policzmy średni pobór prądu i czas trwania łączności dla kilku różnych układów. Od razu pojawia się pewien problem: rezultaty wyszukiwania sugerują, iż niemal wszystkie układy BLE występują w komplecie ze zintegrowanym mikrokontrolerem i to głównie ARM. Teoretycznie więc powinniśmy uwzględnić użycie tego wbudowanego mikrokontrolera w naszych obliczeniach, ale nie każdy układ pozwala na zastosowanie owego procesora do aplikacji użytkownika nie związanych z łącznością Bluetooth. Dlatego też nasze obliczenia będą obejmować tylko kwestię łączności, zatem układ będzie aktywny tylko tyle czasu, ile potrzeba by nawiązać połączenie ze stacją bazować i przesłać 1 kB danych używając profilu GATT.
Istotną dla tych rozważań informacją jest moc nadajnika, a ta zależy od warunków propagacji. W przypadkiu, gdy nasze przykładowe urządzenie, czyli opaska sportowaz znajduje się na lewym nadgarstku, a odbiornik – czyli smartfon – w prawej kieszeni spodni, moc nadajnika może wynosić od 0 dBm do +4 dBm. Sytuacja jest zgoła inna, gdy smartfon jest z dala od ciała, które pochłania sygnał Bluetooth – powiedzmy, że mamy do czynienia z odległością dwóch metrów od urządzenia. Wtedy zależnie od warunków propagacji potrzebna moc może wynosić od –12 dBm do 0 dBm. W sytuacji, gdy smartfon jest w ręce użytkownika, wystarczy moc od –20 dBm do –10 dBm.
Byłoby wskazane podanie średniego poboru prądu dla każdego z tych scenariuszy, jednakże producenci są innego zdania i podają maksymalny pobór dla 0 dBm oraz dla fazy odbioru danych, zatem uśredniony pobór zostanie podany tylko dla tych wartości.
Firmę STMicroelectronics reprezentuje w naszym zestawieniu mikrokontroler STM32WB15CC, należący do rodziny STM32WB, której głównym przeznaczeniem są wszelkiego rodzaju urządzenia związane z automatyką domową czy monitorowaniem stanu zdrowia. Transceiver będący częścią układów tej rodziny jest kompatybilny zarówno z Bluetooth Low Energy, jak i z protokołami ZigBee i Thread, choć wariant w układzie STM32WB15CC wspiera tylko Bluetooth 5.4 i Bluetooth Low Energy. Moduł radiowy ma też dedykowany, 32-bitowy mikrokontroler ARM Cortex M0+ przeznaczony do obsługi łączności, podczas gdy główny rdzeń, 32-bitowy mikrokontroler ARM Cortex M4, pozostaje nieaktywny. Układ pobiera maksymalnie 5,5 mA w trakcie nadawania (przy mocy 0 dBm), 4,5 mA w trakcie odbioru i tylko 510 nA w stanie oczekiwania z podtrzymaniem pamięci i z aktywnym RTC. W ramach ochrony komunikacji układ obsługuje szyfrowanie AES-128 dla protokołu Bluetooth, ale wspiera też dodatkowy mechanizm kryptograficzny z kilkoma metodami do wyboru oraz sprzętowy generator liczb losowych. Niewielki rozmiar mikrokontrolera oraz niski pobór prądu czynią go atrakcyjnym wyborem do urządzeń noszonych, właśnie takich jak właśnie smartwatche. A główny rdzeń z wbudowanymi FPU i DMA pozwala na tworzenie dość złożonych aplikacji o szerokim spektrum zastosowań.
Microchip ma w swojej ofercie zarówno same układy SoC z serii PIC32CX-BZ3, jak i gotowe moduły (WBZ35x) oparte o 32-bitowy mikrokontroler ARM Cortex M4F i zintegrowany moduł Bluetooth Low Energy 5.2/ZigBee 3.0. Moduły te mają zaimplementowany wspólny system radiowy, któregom moc nadawania jest regulowana w zakresie od –24 dBm do 11 dBm w krokach co 1 dBm. Czułość odbiornika, zależnie od trybu pracy i prędkości transmisji, osiąga od –95 dBm do –108 dBm. Przewagą użycia gotowego modułu zamiast samego układu jest to, że moduł oferuje certyfikaty związane z dopuszczeniem do użycia nadajnika radiowego, co redukuje koszty i upraszcza projekt. Wadą w pewnych wypadkach mogą być wymiary samego modułu, ograniczające rozmiar docelowego produktu – wynoszą one bowiem 15,5×20,7 mm (wariant WBZ351) oraz 13,4×18,7 mm (WBZ350). Warianty różnią się zastosowanym mikrokontrolerem, co wpływa na liczbę wyprowadzeń. Zwykle Microchip w swoich notach chwali się niskim poborem energii mikrokontrolerów i innych układów już na pierwszych stronach, ale w tym jednak przypadku trzeba sięgnąć po dokładne charakterystyki znajdujące się niemal na końcu noty. Spojrzenie w te wartości jest doświadczeniem rozczarowującym: pobór w stanie uśpienia wynosi 550 μA (typ.). W trybie Deep Sleep jest już lepiej: 1,9 μA (typ.), 60 μA (maks.). W trybie XDS (eXtreeme Deep Sleep) jest jeszcze lepiej, bo pobór prądu spada do 90 nA. Moduł łączności w trybie BLE pobiera 26 mA przy nadawaniu z mocą 0 dBm i 20 mA przy odbiorze z czułością –90 dBm.
W ofercie Microchip znajdziemy też układ ATBTLC1000-QFN – mikrokontroler ARM Cortex M0 z modułem BLE 5.0, zamkięty w obudowie QFN. Układ jest bardzo energooszczędny – w stanie Power Down pobiera 90 nA, a w stanie niskiego poboru prądu z timerem BLE i RTC – 2,01 μA, co jest bardzo dobrym wynikiem. W czasie odbioru sygnałów Bluetooth układ pobiera 5,24 mA, a w czasie nadawania z mocą 0 dBm wartość ta rośnie do 3,91 mA. Mikrokontroler taktowany jest zegarem 26 MHz (wartość mniejsza niż w innych układach) i ponadto oferuje 128 kB pamięci RAM, 128 kB pamięci programu oraz sprzętowe wsparcie AES-128 i SHA-256. Układ sprzedawany jest w obudowie QFN-32 o wymiarach 4×4 mm: Microchip dostarcza SDK z gotowym firmware BLE SIG, wsparciem podstawowych protokołów łączności (w tym GATT) oraz szereg gotowych profili przykładowych. Zintegrowany mikrokontroler obsługuje tylko łączność Bluetooth Low Energy, dzięki zaprogramowaniu wybranych parametrów i profili i wymaga zewnętrznego mikrokontrolera do dostarczania danych oraz sterowania trybem pracy. Pod tym względem działa więc jak moduły radiowe prezentowane w jednej z poprzednich części cyklu.
Ciekawym wyborem może być moduł ESP32 firmy Espressif Systems. Moduły te spotykane są często w wielu aplikacjach IoT, szczególnie w automatyce domowej. Mają jeden lub dwa mikroprocesory 32-bitowe Xtensa LX6 oraz koprocesor ULP (Ultra Low Power). Obsługa Wi-Fi i Bluetooth, w tym BLE, jest realizowana przez dwa niezależne od siebie moduły sprzętowe, ale współdzielące front-end RF. Łączność BLE może być realizowana nawet wtedy, gdy oba rdzenie są uśpione – warunkiem jest jednak dopilnowanie, by przynajmniej jeden z nich był w trybie „snu płytkiego”. ESP32 ma bogaty zestaw wbudowanych peryferiów, wliczając w to też sprzętową obsługę algorytmów AES, SHA i RSA oraz sprzętowy generator liczb losowych. Zatem nic nie stoi na przeszkodzie, by cały projekt zrealizować na tym module. Jednakże pobór prądu jest znaczny, sam moduł Bluetooth pobiera 100 mA przy nadawaniu z mocą 0 dBm, i 90...100 mA w trybie odbioru. Moduł ogólnie pobiera sporo energii: nawet gdy pracuje tylko jeden rdzeń LX6 z częstotliwością 80 MHz, układ będzie i tak pobierał aż 40 mA. Łatwo zatem zauważyć, iż układ ten nie jest energooszczędny. Producent rekomenduje źródło zasilania o wydajności przynajmniej 500 mA. Dlaczego zatem jest wymieniony w zestawieniu? Głównie ze względu na jego popularność i niską cenę samych modułów oraz prostych płytek rozwojowych/prototypowych, jak choćby ESP-WROOM-32.
Firma NXP ma w swojej ofercie kilka interesujących rozwiązań. Najciekawszym z nich jest NHS52S04, ale poza krótkim prospektem reklamowym firma nie oferuje publicznie żadnej dokumentacji ani specyfikacji. Dlaczego ten układ byłby ciekawym elementem zestawienia? Głównie ze względu na jego podstawową cechę – energooszczędność. Niestety, nie dowiemy się, jak wypada pod tym względem układ NXP z rdzeniem ARM Cortex M33, gdyż prospekt reklamowy nie podaje żadnych informacji na temat poboru prądu, a Autor nie uważa za stosowne, by tak podstawowe informacje były traktowane przez producenta jako dane niepubliczne, czy wręcz poufne.
Texas Instruments ma w swojej ofercie kilka rodzin mikrokontrolerów, różniących się głównie rodzajem CPU. Jako przykładowy reprezentant tej firmy wybrany został układ CC2340R53, wyposażony w rdzeń ARM Cortex M0 i oferujący wsparcie standardów Bluetooth Low Energy 5.3, Zigbee i Thread. Przy nadawaniu z mocą 0 dBm układ pobiera 5,1 mA, a przy odbiorze – 5,3 mA. Sam mikrokontroler porzebuje 2,6 mA przy maksymalnej częstotliwości 48 MHz, 710 nA w trybie Standby i 166 nA w trybie całkowitego wyłączenia z wybudzaniem przez zmianę stanu pinu. CC2340R53 ma na pokładzie 512 kB pamięci Flash i 64 kB pamięci RAM, oferuje ponadto opcję aktualizacji firmware drogą radiową – jest to cecha pożądana w urządzeniach noszonych, takich jak opaski sportowe czy monitory tętna. Układ ma też szereg typowych peryferiów – moduły komunikacji szeregowej czy przetwornik ADC. Ciekawostką jest blok monitorujący napięcie zasilania i temperaturę, przeznaczony do testowania stanu baterii.
Peryferium to wywołuje przerwanie, gdy temperatura lub napięcie przekroczą jeden z dwóch zadanych progów.
Analiza czasu transmisji danych i poboru energii
Do naszego zestawienia moglibyśmy wytypować więcej układów od innych producentów, ale powyższa lista stanowi adekwatną reprezentację tego, co jest dostępne na rynku. Następnym krokiem jest zatem dokładne policzenie, na bazie struktury pakietów BLE i czasów transmisji w obu kierunkach, średniego poboru prądu w czasie jednej sesji komunikacji. W naszych rozważaniach pomijamy etap parowania urządzenia z hostem i zakładamy idealne warunki łączności, czyli brak jakichkolwiek zakłóceń.
Pierwszym krokiem – od strony urządzenia – jest nadanie pakietu danych informującego o jego istnieniu. Ten etap nazywany jest Advertisement, a pakiet ma maksymalny rozmiar 47 bajtów, z czego 31 bajtów to dane użytkownika. W fazie rozgłaszania transmisja odbywa się zawsze z prędkością 1 Mbps co oznacza, że jeden pakiet Advertisement będzie trwał maksymalnie 376 μs. Każdy pakiet powinien być wysłany trzykrotnie na kolejnych kanałach „reklamowych”: 37, 38 i 39. Interwał między kolejnymi transmisjami wynosi typowo 20 ms, ale może przyjmować wartości od 3,75 ms do 100 ms. Host, po odebraniu pakietu reklamowego, odpowiada wysyłając pakiet Connection Request zawierający 34 bajty, w tym m.in. adres do przesłania danych i interwał czasowy. Urządzenie potwierdza odbiór pakietu, i połączenie zostaje nawiązane. Pakiet Connection Request trwa 272 μs, a pakiet ACK: 56 μs. Specyfikacja BLE 5.3 podaje, iż maksymalny rozmiar pakietu z DLE (Data Length Extension) wynosi 260 bajtów, z czego 251 bajtów to dane. Po każdym nadanym pakiecie urządzenie oczekuje na pakiet ACK (14 bajtów) przez maksymalnie jeden interwał czasowy (CI) czyli od 7,5 ms do 4 s, zależnie od wynegocjowanego połączenia. W przypadku prędkości transmisji 2 Mbps daje to 1040 μs na pakiet danych i 56 μs na pakiet ACK. Ważna uwaga: im niższa prędkość transmisji, tym większy zasięg, bo efektywna czułość odbiornika rośnie wraz ze wzrostem długości pojedynczego znaku. Tabela 1 zestawia i podsumowuje przykładowy scenariusz wraz z czasami transmisji i odbioru. Przyjęto założenie, że pakiet ACK zostanie wysłany 150 μs po odebraniu pakietu. Transmisję wieńczy pakiet kończący połączenie, trwający tylko 8 μs, bo zawierający dwa bajty.
Po zakończeniu sesji moduł łączności można wyłączyć. Warto zauważyć, że czas powtarzania „reklam” został podzielony na trzy mniejsze interwały, by każdy kanał miał czas na odebranie odpowiedzi z hosta. Przyjęto też założenie, że host nie musi zareagować od razu, stąd trzy nieudane próby. Przeliczmy to zatem na średni pobór prądu wybranych układów, nie uwzględniając niczego prócz zapotrzebowania samego modułu łączności Bluetooth. Wyniki zebrano w tabeli 2.
Rezultaty obliczeń są miażdżące dla układu ESP32 i raczej dyskwalifikują go w zastosowaniach energooszczędnych. Za to układ od firmy STMicroelectronics wypadł najlepiej. ATBTLC1000-QFN produkcji Microchip znalazł się na drugim miejscu, ale ten układ nie za bardzo daje się do wykorzystania w ramach czegoś więcej, niż tylko pośredniczenia w łączności. Lepszym od niego wyborem może być propozycja firmy Texas Instruments. Oczywiście do średniego, łącznego poboru prądu nie dodano zapotrzebowania energetycznego reszty układu, w trakcie pracy lub/i uśpienia. By wyniki były bardziej miarodajne, należałoby stworzyć kompletną aplikację i zmierzyć rzeczywisty pobór prądu.
Jeśli przyjrzymy się czasom podanym w tabeli 1 i zestawimy je z wartościami z tabeli 2 łatwo zauważyć, iż rozsądnym wyborem byłoby wysyłać więcej danych, ale dużo rzadziej, gdyż najwięcej energii wydatkowane jest na nasłuch przy rozgłaszaniu urządzenia. Gdyby przy pierwszej transmisji pakietu Advertisement host odpowiedział, to pobór prądu wyglądałby jak w tabeli 3.
Różnice między układami zmniejszyły się nieco. Nadal jednak ESP32 wypada najsłabiej. W ramach niniejszego opracowania nie będziemy jednak przeliczać wpływu prędkości transmisji na pobór prądu, ani poboru dla większej liczby danych – zainteresowany Czytelnik może to zadanie wykonać samodzielnie.
Podsumowanie
Łączność oparta o Bluetooth Low Energy jest świetną alternatywą dla różnych innych trybów komunikacji bezprzewodowej, zwłaszcza jeśli uwzględni się fakt, że każdy niemal człowiek ma w swoim zasięgu przynajmniej kilka urządzeń mogących pełnić funkcję hosta, z którym urządzenie będzie się komunikować. Producenci dostarczają gotowych rozwiązań w formie kompletnych stosów BLE z przykładowymi profilami oraz wiele materiałów edukacyjnych ułatwiających start. Od strony hosta wszystkie systemy operacyjne, od mobilnych (Androida i iOS’a na smartfonach i tabletach), po Windows, macOS X, czy wiele odmian Linuksa (w tym te działające na komputerach jednopłytkowych) wspierają łączność Bluetooth (także BLE) i oferują gotowe API do aplikacji użytkownika. Realizacja własnego projektu staje się więc czymś relatywnie łatwym i dostępnym dla każdego, dlatego warto na etapie projektu rozważyć wybór układu, który poza wydajnym i energooszczędnym mikrokontrolerem zawiera też wszystko, co potrzebne do dodania tej funkcjonalności. W przypadku elektroniki noszonej przez użytkownika jest to wręcz rynkowy wymóg.
W następnej części naszego cyklu spojrzymy na inne rozwiązanie komunikacyjne, a przy okazji dokonamy praktycznego pomiaru, gdyż nota wybranego układu nie zawiera potrzebnych informacji.
Paweł Kowalczyk, EP
