HM-10 i HM-11 czyli Bluetooth BLE i meandry chińszczyzny

Ostatnio dodałem dwa moduły BLE do oferty Nettigo. To HM-10 i HM-11. Ten pierwszy w zasadzie mamy już w ofercie, jednak z różnych powodów zdecydowałem, że wersja bezpośrednio od producenta będzie ciekawym uzupełnieniem. Po pierwsze – dostępność bez przylutowanego adaptera. Jeśli pasuje Ci ten moduł, możesz go użyć w swoim projekcie, na własnym PCB. Ważne gdy potrzebna jest miniaturyzacja.

Jak dalsza miniaturyzacja jest potrzebna – to oprócz HM-10 jako niezlutowana para moduł + adapter mamy teraz również HM-11. HM-11 ma ten sam chip, ten sam firmware, tylko mniejszy rozmiar. Okupił to utratą części IO ale kilka zostało.

Bluetooth 4.0 wspierany przez HM-1x to jest zupełnie inna bestia niż stary, dobry Bluetooth 2.1 z HC-05, znanego dobrze fanom Arduino. HC-05 w uproszczeniu, to bezprzewodowa rura z Serial. Podpinasz do mikrokontrolera, wysyłasz dane przez UART – bajty wypadają z rury na drugim końcu. Czy to będzie kolejny HC-05 z innym mikrokontrolerem czy jakaś aplikacja na telefonie/komputerze.

W przypadku modułów HM-1x sytuacja jest nieco bardziej skomplikowana. Dlaczego? Bo wraz z BT 4.0 zmienia się filozofia działania. Zamiast połączenia punkt-punkt znanego z HC-05 mamy możliwość wysyłania danych/odbierania danych/otrzymywania notyfikacji od różnych usług. Czemu to tak skomplikowano? Bo taka architektura nie wymaga by było cały czas połączenie między urządzeniami, a to znaczy znacznie mniejsze zużycie energii. Więc jeżeli planujesz budować niewielkie urządzenia z zasilaniem bateryjnym ale o długim czasie pracy, BLE – Bluetooth Low Energy jak inaczej nazywany jest BT 4.0, to coś, co warto rozważyć.

Nie ukrywam, że sam nie jestem wielkim praktykiem jeśli chodzi o używanie BLE, ale ostatnio kilka razy mnie okoliczności zmusiły i niniejszy post jest formą uporządkowania i utrwalenia mojej wiedzy, może tobie też się przyda.

Przygotowanie do pracy

OK, wróćmy do HM-1x. Jak wspomniałem zarówno nowy BLE HM-10 jak i jego mniejszy brat HM-11 są w postaci modułu SMD i adaptera. Jeśli nie wrzucasz modułu na własną płytkę PCB jako element SMD – najpierw musisz zlutować moduł i adapter. Adapter ma pocynowane pady (a padów jest tylko niewielka część, reszta to po prostu rysunek na silkscreenie) i przylutowanie jest pewnie możliwe z użycie hot-air, ale z praktyki wiem, że lutowanie zwykłą lutownicą nie jest żadnym kłopotem. Robiłem to zawsze z ostrym grotem stożkowym do lutownicy, standardowy pewnie też da radę, ale tego nie próbowałem. Rozstaw padów jest jednak niewielki, więc lepiej używać tego cienkiego…

Całość zagadnienia sprowadza się do dobrego przyłożenia modułu do adaptera, przylutowanie jednego punktu (pady są pocynowane, ale dobrze dodać więcej cyny), sprawdzenie czy wszystko dobrze jest spasowane (czy wszystkie pady są na właściwych pozycjach). Jeśli się zgadza – lutować dalej – jeśli nie, rozgrzać to pierwsze pole i skorygować położenie.

Możesz próbować lutować zupełnie luźno położony moduł HM na adapter. Jednak jeśli chcesz być spokojniejszy że nie potrącisz przypadkiem adaptera i wszystko się przesunie – możesz skorzystać z pomocy zwykłej klamerki. Niewielkie rozmiary powodują, że łapie ona bez problemu moduł i trzyma na właściwej pozycji.

Po przylutowaniu pierwszych punktów można wypiąć klamerkę i lutować dalej. Po chwili mamy gotowy moduł do podłączenia.

Podłączanie

Pierwsze testy – z komputera. Korzystam z najszybszego konwertera USB/Serial (najszybszy, wiadomo, bo czerwone są szybsze!). Ma on też tą zaletę, że ma zworkę wybierającą tryb pracy 3.3V lub 5V. Co ważne, to nie tylko napięcie, które jest podawane na pin Vcc konwertera. Do tego napięcia są dostosowane poziomy logiczne na szynach TX/RX. Moduły HM-1x są przystosowane do pracy z poziomami logicznymi 3.3V. Wspomniany wcześniej moduł HM-10 z większym adapterem ma wbudowane konwertery poziomów logicznych, także do pracy z układami 5V (starsze Arduino) trzeba albo wybrać starszy HM-10 (MOD-1441) lub użyć konwertera poziomów logicznych (jak nasz np 4-ro kanałowy MOD-636)

Moduł ma 6 wyprowadzeń ale do podłączenia są potrzebne 4 – Vcc, GND, TX i RX. Pozostałe dwa to 3.3V i GND. Adapter ma wbudowany stabilizator napięcia (można zasilić moduł maksymalnie 6V) i to jest właśnie wyjście z tego modułu. Dodatkowy pin 3.3V i GND może posłużyć do zasilania jakiegoś czujnika np DS18B20 albo DHT. Czemu o tym wspominam będzie wyjaśnione dalej.

Podłączamy wszystko co potrzeba do (Vcc, GND, TX, RX) z konwertera i zaczynamy rozmowę z modułem. Tutaj się przyznam, że miałem sporo kłopotów, których ostatecznej przyczyny nie doszedłem. Na moim laptopie z Ubuntu, moduł uparcie nie chciał przyjmować poleceń gdy korzystałem z miniterm.py lub picocom. Dane były odbierane ale nic nie mogłem wysłać. Skrypt napisany w pythonie gadał jak trzeba, a także Serial Monitor z Arduino IDE nie miał problemu. Nie udało mi się ustalić przyczyny, mimo popędzania batem GPT nie doszliśmy do żadnych definitywnych konkluzji. Zakładam, że to problem z moim rozgrzebanym systemem.

By wykorzystać możliwości modułów, trzeba je skonfigurować. Korzysta się do tego z komend AT. Nazwa pochodzi od tego, że polecenia zaczynają się od AT i ponoć AT pochodzi od słowa attention. Protokół ten powstał w latach 80-tych na potrzeby sterowania modemów w czasach przedinternetowych.

By sprawdzić czy komunikujesz się z modemem wyślij komendę AT do modułu (prędkość 9600). Moduł powinien odpowiedzieć OK. Jeśli tego brak, sprawdź czy nie zamieniłeś TX z RX – częsty błąd. Możesz też dostać odpowiedź OK+WAKE – znaczy że modem był uśpiony i właśnie „wstał”.

Struktura komend AT to zwykle AT+XXXX? gdzie XXXX oznacza właściwe polecenie, a znak zapytania parametry. Te parametry to albo dokładnie znak zapytania lub jakieś wartości. Gdy jest to pytajnik to polecenie oznacza zapytanie o dany parametr. Gdy wartość – coś ustawia. Np AT+MODE? oznacza zapytanie o tryb pracy. Modem odpowiada np OK+Get:0 Gdy komenda jest błędna zwykle moduł w ogóle nie odpowiada. Tutaj mamy OK, czyli że komenda była poprawna, + jest separatorem, a Get:0 oznacza że wartość odczytana to 0. Wydanie komendy AT+MODE2 oznacza ustawienie trybu pracy na 2. Odpowiedź modemu to OK+Set:2. Znowu, OK oznacza że komenda jest poprawna, + separator, a Set:2 – tryb został ustawiony na 2.

Lista komend jest dostępna w karcie katalogowej HM-10. Jest sporo tych komend i by w pełni wykorzystać moduł to trzeba poznać je, są one też związane z pojęciami dotyczącymi BLE, więc to jest też temat do zgłębienia.

Skoro zaczęliśmy od AT+MODE. Moduły mają trzy tryby pracy: 0, 1 i 2. Tryb zero jest zbliżony do dawnego połączenia znanego z HC-05 – co druga strona wyśle, pojawia się na UART. Sprawdźmy. Ustaw moduł w tryb 0 AT+MODE0 i telefonem podłącz się do modułu BT.

Aplikacje na telefon

Jeśli potrzebujesz apki do „dłubania” w BLE to polecam nRF Connect. Sam korzystam z Androida, nRF Connect jest tez pewnie na iOS. Ta aplikacja ma możliwość dokładnego grzebania w protokole BLE. Jeśli tylko chcesz komunikacji i sterowania wystarczy coś prostszego – polecam Serial Bluetooth Terminal i z niego będę tutaj korzystał.

Dzięki prostocie i wsparciu modułów HM-1x przez SBT korzystanie z modułów będzie trochę przypominało stare dobre HC-05, czyli rurę z danymi. Jeśli jesteś zainteresowany – zainstaluj wspomniany nRF Connect i zacznij zaglądać „pod maskę”. Ale tutaj ten temat na razie zupełnie pominę, bo nie czuję się na siłach objaśniać szczegółów i zasad działania BLE.

Na ekranie głównym SBT klikamy „hamburgera” by dostać się do menu, tam Devices, zakładka Bluetooth BLE i SCAN w górnym prawym rogu. Po chwili powinien pojawić się tam HMSoft – tak się domyślnie HM-10/11 przedstawia. Jeśli nie ma, to upewnij się że moduł nie jest uśpiony. Klikasz i jest połączony.

Jak widać – nie ma żadnego parowania. To jest ustawienie domyślne modułu a nie cecha BLE. Można włączyć parowanie, ale jako że to BLE 4.0 to nie oczekuj tutaj zaawansowanych możliwości w zakresie bezpieczeństwa. To taki prosty w zastosowaniu moduł do amatorskiego testowania BLE. Jeśli myślisz o czymś poważniejszym na HM-10 to tylko jakieś publicznie dostępne usługi – np czujnik temperatury, który każdy potencjalnie może odczytać.

No to wysyłamy!

Teraz wystarczy coś wpisać w SBT i pojawi się to na UART modułu a odpowiedź wpisana w Serial Monitor pojawi się w aplikacji SBT. W MODE 0 cały strumień danych jest przesyłany w jedną i drugą stronę.

Ciekawsze rzeczy zaczynają się gdy przełączymy moduł w MODE 1 lub 2. Wrzućmy komendę na UART: AT+MODE2. Uwaga – jeśli do modułu jest podłączony jakieś urządzenie przez BT, wówczas on ignoruje komendy na UART. Trzeba najpierw odłączyć telefon od modułu, dopiero potem wysłać komendy zmieniające konfigurację.

Masz już HM-10 w MODE2? Teraz podłącz telefon i upewnij się że SBT nie wysyła znaków końca linii (hamburger -> Settings -> Send -> Newline: None) i wyślij do telefonu AT. Nic nie pojawi się na UART modułu (który obserwuję cały czas korzystając z Serial Monitora) natomiast moduł „sam z siebie” odpowie OK. Spytaj się o nazwę – AT+NAME? albo wersję oprogramowania AT+VERS? a moduł odpowiada.

W trybach 1 i 2 przez BT, zdalnie możesz normalnie sterować i konfigurować moduł. Musisz tylko wysłać dokładnie komendę, bez dodatkowych znaków końca linii. Jeśli moduł czegoś nie rozpozna – przekaże to dalej na UART. Zobacz sekwencję komunikacji w MODE2:

Wszystko co jest komendą AT zostało wykonane a to co nie było (*) zostało wysłane na UART. Komunikat wysłany na UART (FG) został doręczony do telefonu… Brak newline całość zaciemnia, ale widać dobrze jak to działa.

W MODE 1/2 można zmienić całą konfigurację modemu korzystając z komend AT. Poznajmy więc absolutne minimum – PIN podczas połączenia. PIN musi mieć 6 cyfr i domyślnie jest to 6 zer. Ustawiamy PIN przez AT+PASS112233 – nowy pin to 112233. Samo ustawienie nie wystarczy – potrzebna jest aktywacja parowania/bondingu. Masz dwie opcje AT+TYPE2 lub AT+TYPE3. W obu przypadkach musi się odbyć procedura parowania z podaniem pinu, ale przy TYPE3 urządzenia zostaną powiązane (bonding) – kolejne połączenie odbędzie się już automatycznie. Czyli TYPE2 – za każdym razem przy podłączaniu będzie potrzebny PIN a przy TYPE3 tylko przy pierwszym.

Teraz docieramy do tytułowych meandrów. Zgodnie z dokumentacją ta cecha powinna być dostępna od wersji firmware V7xx lub dla wcześniejszych wersji fw w wariancie HMSensor, tymczasem fw się przedstawia jako HMSoft, standardowy firmware, w wersji v610. Tyle w dokumentacji. A tymczasem – działa. O czym mówię?

Otóż, CC2451 na którym jest zbudowany HM-10 i HM-11 ma wbudowany czujnik temperatury. I jest on wspierany przez firmware. Ale… jeśli chcesz z niego korzystać – nie wydaje się nic warty :) Cały czas pokazuje mi temperatury w zakresie 22-25°C. Po półgodzinnym pobycie w lodówce (z wyłączonym zasilaniem) i włączeniu na chwilę od razu zwraca wartość 22.31°C. W piekarniku nagrzanym do 40°C pokazuje 24.80°C. Niby kierunek jest zgodny, ale użyteczne to nie jest.

Ale! Razem AT+TEMP? firmware ma wspierać AT+SENSOR?. Mamy trzy opcje – 0, czyli wbudowany sensor, 1 – DHTxx, 2 – DS18b20. HM-10 obsługuje zewnętrzne sensory podłączone do pinu PIO011 (fizyczny pad nr 34) a HM-11, który pinów ma znacznie mniej, do PIO03, fizyczny pad 13.

Wspomniałem, że adaptery nie mają wszystkich metalowych padów, część jest tylko silkscreenem. Selekcja IO które mają prawdzie pady to też jakiś meander mentalności chińskiego inżyniera ;) W HM-10 pin na zewnętrzne sensory jest normalnym padem, a w HM-11 nie. Niemniej, nie jest to problem, łatwo się przylutować z przewodem zarówno w HM-10 z padem jak i w HM-11, bezpośrednio do modułu.

Teraz trochę kłębowiska kabli. Bierzemy któryś z wodoodpornych DS18b20 na kablu, lutujemy przewody do kawałka gniazda. Między Vcc (czerwony kabel) a sygnał (żółty) lutujemy rezystor ok 4k7 (ja wlutowałem dwa 2k2, bo takie miałem pod ręką). I podłączamy wszystko razem do wspomnianych wcześniej pinów GND i 3v3 out na adapterze.

Ja akurat miałem taki sensor DS18 przygotowany do podłączenia do NAM, więc kolejność kabli na wtyczce już miałem ustaloną. Gdybym robił to na potrzeby tego testu, to bym zlutował je w innej kolejności, tak by można wsadzić gniazdo na dwa piny GND i 3V3 a tylko do trzeciego podłączyć kabelkiem port modułu HM-1x obsługującego sensor. Nie chciałem przelutowywać kabli, więc kłębowisko jest większe. Wtyczka z DS jest założona na pin z GND, zasilanie jest podłączone przewodem jumper wire F-M a sygnał z przylutowanego kabelka.

No i teraz AT+SENSOR2 i AT+TEMP? Za pierwszym razem zawsze mi zwraca 085.00 ale już kolejne odczyty są sensowne.

Jak widać, temperatura zmienia się dość wyraźnie. Wystawiłem sensor za okno, gdzie jest ok 15-16°C i DS poprawnie wskazuje temperaturę. Nie to co internal sensor

Czas na małe podsumowanie

Artykuł mi się już rozrósł, więc utnijmy to na razie, zrobimy potem dogrywkę.

HM-10 i HM-11 to niewielkie moduły BLE oferujące podstawowe funkcjonalności w ramach BLE 4.0 (a więc dość wiekowy standard). Jeśli nie masz doświadczenia w BLE a chciałbyś zacząć wykorzystywać tą technologię to chyba HM-10 i HM-11 są dobrym punktem startowym.

Poza komunikacją UART oferują bezpośredni odczyt temperatury/wilgotności z sensora. Można również sterować wyjściami, odczytywać stan wejść i napięcia na wejściach. To wszystko bez udziału mikrokontrolera.

Wersje HM-10 (MOD-2391) i HM-11 (MOD-2392) mają firmware V610 wspierające odczyt sensorów. HM-10 będący już dłużej w naszej ofercie (MOD-1441) obecnie nie (wersja fw V605). Przy kolejnych zamówieniach postaramy się aby miały te funkcjonalności, może i MOD-1441 je też nabędzie, bo oparty jest o ten sam HM-10.