Co wybrać podczas implementacji interfejsu Bluetooth Low Energy?

W ogromnej większości aplikacji implementowanie komunikacji przez Bluetooth od zera nie ma sensu i jest zbyt skomplikowane, aby projektant miał z tego jakiekolwiek korzyści. Na szczęście nie jest konieczne, gdyż istnieje mnóstwo dostępnych rozwiązań modułowych, które pozwalają łatwo zintegrować Bluetooth z projektowaną aplikacją. Kluczowym czynnikiem staje się natomiast wybranie rozwiązania, które najlepiej spełnia wymagania danej aplikacji.

W wersji BLE dla uzyskania niskiego poboru mocy twórcy standardu przyjęli, że w typowych implementacjach będzie konieczne przesyłanie jedynie niewielkich pakietów danych w dużych odstępach czasu. Transmisja może trwać nawet tylko kilka milisekund w ciągu pomiarowego cyklu kilkusekundowego, co pozwala elektronice na przejście w stan głębokiego uśpienia, o ile tylko nie musi ona nasłuchiwać, czy nadchodzą nowe pakiety danych.

W zwykłej wersji transceiver Bluetooth zazwyczaj pozostaje w stanie aktywnym znacznie dłużej, gdyż musi odbierać komunikaty podtrzymujące połączenie. Natomiast okres uśpienia może być dostosowywany dynamicznie. Jeśli faza aktywna nie wiąże się z transferem danych, protokół może przedłużyć stan uśpienia.

Dodatkowo prąd pobierany w trakcie odbioru jest mniejszy niż w czasie transmisji danych, przez co krótki czas nadawania jest korzystny. Maksymalne wartości pobieranego prądu przez interfejs typowo mieszczą się w zakresie 10-30 mA, co pozwala na zasilanie aplikacji z baterii guzikowej.

BLE zmniejsza też zapotrzebowanie energetyczne komunikacji poprzez ograniczenie liczby kanałów komunikacyjnych rozgłoszeniowych. Zamiast 32 używanych w wersji classic, korzysta tylko z 3. Mniej kanałów sprawia ponadto, że wykrywanie urządzeń jest szybsze.

Projektanci aplikacji IoT mogą z oferty rynkowej wybrać do interfejsu BLE specjalizowany układ scalony SoC, gotowy moduł lub mikrokontroler z wbudowaną obsługą BLE. Każda z tych opcji ma przełożenie na cenę i czas potrzebny na wprowadzenie rozwiązania na rynek oraz na całkowity rozmiar projektowanego urządzenia.

Wybór anteny radiowej

Rys. 1. Pobór prądu przez transceiver Bluetooth

Antena ma kluczowy wpływ na tworzony produkt wykorzystujący komunikację bezprzewodową. Dobra antena jest niezbędna do zagwarantowania zgodności produktu z wymaganiami prawnymi i dla zapewnienia wystarczającego zasięgu. W modułach jest ona integrowana zwykle wewnątrz ich konstrukcji, a przykładem mogą być produkty firmy Microchip, jak RN4020 lub Panasonic PAN1760A.

To znacząco skraca czas projektowania i testowania, a poza tym producenci takich modułów przykładają dużo starań do optymalizacji anteny konstrukcji, by zapewnić, że będzie ona efektywnie pracowała w szerokiej gamie aplikacji i była mała.

Jednakże użycie modułu może być też kłopotliwe z powodu istniejących ograniczeń w zakresie projektu płytki drukowanej i obudowy, bo całość może nie pasować do założeń konstrukcyjnych aplikacji. Przykładowo, urządzenie klasy wearables (noszone na ciele) musi mieć małą i wygodną obudowę, której częścią jest też antena.

W takim przypadku konieczne staje się sięgnięcie po własne rozwiązanie bazujące na chipie SoC, a więc zapewniające oprócz komunikacji także dostępność procesora aplikacyjnego. Z kolei, jeśli celem jest dodanie obsługi interfejsu Bluetooth do istniejącej rodziny produktów, dla której stworzono już dużo przygotowanego wcześniej oprogramowania, sięganie po nowy, zintegrowany SoC niekoniecznie może być dobrym pomysłem.

Wsparcie protokołu

Rys. 2. Struktura wewnętrzna modułu firmy Panasonic PAN1760A

Jedną z kluczowych zalet korzystania z modułowego transceivera Bluetooth jest to, że realizacja komunikacji nie zwiększa obciążenia głównego procesora, spowodowanego koniecznością obsługi większości funkcji komunikacyjnych. W innym przypadku konieczne jest upewnienie się, że wydajność głównego procesora nie będzie ograniczeniem.

W tym zakresie interesująca może okazać się rodzina układów Kinetis KW35/36 firmy NXP bazująca na rdzeniu ARM Cortex-M0+, taktowanym zegarem 48 MHz. Układ ten obsługuje stos protokołu Bluetooth oraz dodatkowo ma wbudowane interfejsy CAN-FD i LIN, jakie wykorzystuje się w motoryzacji.

Rdzeń ten jest wystarczająco wydajny, by poza samą obsługą protokołu BLE mógł też wykonywać inne operacje, dzięki czemu może pracować zarówno jako kompletny SoC, jak i jako inteligentny transceiver. Typowe przykłady zastosowania KW35/36 obejmują zdalny, bezkluczykowy dostęp do pojazdów oraz monitorowanie stanu opon. Układ obsługuje do 8 jednoczesnych, bezpiecznych połączeń.

Natomiast moduł komunikacyjny firmy Panasonic PAN1760A, w którym zintegrowano obwody filtrujące i antenę, został zbudowany w oparciu o transceiver CC2540 Texas Instruments. Obsługa stosu protokołów odbywa się w nim za pomocą zintegrowanego w ramach SoC dodatkowo mikrokontrolera 8051.

Z kolei moduł BLE RM4020 firmy Microchip może pracować przy wsparciu nadrzędnego procesora w większych systemach lub po zmianie firmware'u, także samodzielnie przy wykorzystaniu wbudowanego rdzenia PIC24. W tym drugim przypadku układy zawarte w module działają niezależnie od hosta, obsługując stos protokołów, ale także dając możliwość oparcia na module aplikacji użytkownika.

Większą wydajność, potrzebną do pracy w bardziej złożonych aplikacjach z interfejsem BLE, można uzyskać dzięki np. rozwiązaniu nRF52832 firmy Nordic Semiconductor. Układ ten zawiera rdzeń ARM Cortex-M4F, 512 KB pamięci Flash i 64 kB pamięci RAM.

Wewnątrz protokołu BLE

W większości przypadków układ SoC obsługujący jest oferowany przez producenta z bibliotekami programowymi, które pozwolą na dostęp do funkcji stosu protokołu. Sam stos BLE jest podzielony na szereg warstw i komponentów, które można zaimplementować w systemie operacyjnym, także czasu rzeczywistego (RTOS).

Może być dostarczony przez twórcę oprogramowania, stanowić własne rozwiązanie firmy lub zostać kupiony jako produkt komercyjny. Stos często będzie się komunikować z systemem operacyjnym przez semafory, flagi i funkcje zwrotne. Kluczowe elementy protokołu BLE to Generic Access Profile (GAP), Generic Attribute Profile (GATT) i Security Manager (SM).

GAP wykonuje szereg zadań, wliczając w to wysyłanie danych rozgłoszeniowych, bez wcześniejszego ustanawiania połączenia punkt-punkt, a także wykrywanie pobliskich urządzeń oraz konfigurowanie połączeń z urządzeniami, które zostały już sparowane.

Natomiast GATT odpowiada za zadania przesyłania i odbierania danych z urządzeń już sparowanych. Pakiety wysyłane przez GATT mogą być skonfigurowane tak, by oczekiwały odpowiedzi, która pozwoli upewnić się, że zostały poprawnie dostarczone. Mogą też nie wymagać potwierdzeń.

Dane wysyłane przez warstwę GATT będą często dopasowane do wymagań jednego z wielu standardowych profili aplikacyjnych Bluetooth. Dzięki wykorzystaniu tych profili, zamiast tworzenia własnych formatów pakietów, twórcy węzłów IoT mogą zapewnić lepszą kompatybilność z innymi urządzeniami, takimi jak czujniki medyczne, które podają informację o ciśnieniu krwi, tętnie czy też z systemami automatyki budynkowej, przekazującymi dane środowiskowe.

Z kolei Security Manager implementuje funkcje, potrzebne do bezpiecznego sparowania urządzeń i przesyłania zabezpieczonych wiadomości po sparowaniu. SM obejmuje funkcje wymiany kluczy szyfrujących, a więc coraz ważniejszego elementu projektów IoT, potrzebne do szyfrowania danych przed ich transmisją.

Oprócz samego szyfrowania przesyłanych danych, ważne jest, by systemy były odporne na ataki. Dlatego czasem okazuje się istotne, by w urządzeniu Bluetooth zaimplementować prosty interfejs użytkownika, tak by osoba je instalująca mogła wprowadzić kod.

Alternatywnie można wykorzystać dodatkowy kanał komunikacji radiowej - np. interfejs NFC, który umożliwi bezpieczne uwierzytelnienie z użyciem telefonu komórkowego z odpowiednią aplikacją albo dowolnego innego narzędzia sprzętowego stosowanego podczas instalacji.

Rozważania na temat API

Rys. 3. Stos Bluetooth z zaznaczonym modułem GAP (Generic Access Profile)

Decyzja odnośnie do tego, czy interfejs Bluetooth będzie obsługiwany przez główny mikrokontroler urządzenia, czy też w ramach gotowego modułu, wpłynie na strukturę oprogramowania. Jeśli aplikacja bazuje na samodzielnym mikrokontrolerze z wbudowanym Bluetooth, dostęp do stosu odbywa się zazwyczaj za pomocą odwołań do funkcji w języku C.

Jeśli układ ten działa jako zewnętrzny, inteligentny transceiver, te same funkcje API mogą być aktywowane poprzez interfejs szeregowy. Protokół może bazować na modemowych komendach AT. Wówczas przenosi komendy z jednostki centralnej do obsługującej Bluetooth i generuje odpowiedzi oraz reaguje na zdarzenia, przekazując je z powrotem do hosta.

Inne narzędzia, które pomagają w tworzeniu profili, mogą obejmować kompilatory, które na wejściu przyjmują pliki XML, definiujące wymagania odnośnie do przesyłanych wiadomości i konwertują je do postaci kodu C i plików nagłówkowych. To czyni przesyłanie niektórych danych łatwiejszym, czego dobrym przykładem są odczyty ciśnienia krwi, wpasowujące się w jeden ze standardowych profili Bluetooth.

Węzły IoT, w których zastosowano oddzielny transceiver lub cały moduł Bluetooth, pozwalają optymalizować zużycie energii poprzez koordynację cykli usypiania. Wykorzystując inteligentny transceiver, nie ma potrzeby, by jednostka centralna pozostawała w stanie wybudzenia, gdy odbywa się komunikacja radiowa.

W momencie, gdy wydana została komenda do przesłania danych, a treść pakietu została umieszczona w odpowiednim buforze, CPU może przejść do stanu uśpienia, podczas gdy odbiór czy wysyłka danych odbędzie się niezależnie (w tle).

Inteligentny transceiver może monitorować nadchodzące pakiety i analizować ich treść, upewniając się, że tylko te z ważnymi danymi spowodują wybudzenie CPU. Rozgłaszane komunikaty, które odnoszą się jedynie do zarządzania siecią, mogą być w pełni obsłużone przez procesor wbudowany w moduł bez odwoływania się do głównej jednostki centralnej urządzenia.

Natomiast komunikaty, które wpływają na węzeł IoT, ale mają niski priorytet, np. odnoszące się do aktualizacji stanu serwera, mogą być buforowane lokalnie. Jednostka centralna sama po nie sięgnie i opróżni bufor, gdy się obudzi lub gdy zostanie wzbudzona w momencie nadejścia ważniejszego polecenia z serwera, wymagającego reakcji urządzenia.

Aby zaimplementować tę funkcję, wystarczy zrealizować programową maszynę stanów, która będzie interpretować nadchodzące dane. Można ją dopisać "na wierzchu" firmware'u Bluetooth, dostarczonego przez producenta transceivera.

Ponieważ transceiver BLE musi być w stanie aktywnym, by móc nasłuchiwać nadchodzących pakietów, może to skutkować poborem energii większym niż planowano. W typowym scenariuszu warstwa GATT przesyła pakiety, które wymagają odpowiedzi od odbiorcy. W rezultacie węzeł nie będzie mógł przejść w stan uśpienia do momentu, gdy otrzyma potwierdzenie lub minie czas oczekiwania na nie.

Niektóre krytycznie ważne pakiety również będą wymagały stosowania potwierdzeń. Jednakże wiele danych będzie można przesyłać bez konieczności natychmiastowego odbierania potwierdzeń. Zamiast tego gwarancję poprawności dostarczenia danych można zrealizować na protokołach w warstwie aplikacji.

Przykładowo, indywidualnie zaprojektowany protokół może synchronizować się ze zdalnym węzłem, gdy wzbudzi się przy następnej okazji. Może w tym celu skorzystać z numerów sekwencyjnych pakietów lub innych kodów.

To pozwala węzłowi przechodzić w stan uśpienia, jak tylko wyśle ostatni pakiet w ramach danego cyklu wybudzenia i uśpienia. Funkcja sniff subrating w BLE pozwala synchronizować ze sobą dwa węzły w taki sposób, że ten nadrzędny będzie przechowywał dane aż do następnego wybudzenia.

Podsumowanie

Dzięki stworzeniu inteligentnych modułów i transceiverów, wspieranych przez zaawansowane biblioteki programowe, producenci osiągnęli cel w postaci uczynienia interfejsu BLE dostępnym dla praktycznie wszystkich projektów IoT.

Wybór rozwiązania, które najlepiej pasuje do danego projektu, będzie zależeć od jego wymagań i celów, jakie obrano w aplikacji, ale duża liczba dostępnych opcji sprawia, że jedno z nich powinno całkiem dobrze pasować.

Farnell element14