AVR - Energooszczędny moduł BT

Witam,

Zawsze kiedy musiałem skomunikować się bezprzewodowo pomiędzy komputerem, a procesorem, używałem w tym celu popularnych i tanich modułów BT jak na przykład HC04, HC05. Pobierają one sporo prądu, ale wtedy się tym nie przejmowałem. Natomiast teraz chciałbym skomunikować się z urządzeniem, które jest zasilane bateryjnie i tutaj pojawił się problem. Otóż odpada zastosowanie wyżej wymienionych modułów. I tutaj moje pytanie: czy istnieją jakieś moduły (powiedzmy do 150zł), które mają zaimplementowane tryby uśpienia co ogranicza ich pobór prądu? Szczerze mówiąc trudno znaleźć w internecie odpowiadający mi moduł i dlatego liczę na jakieś podpowiedzi i sugestie.

A może w ogóle źle się za to zabieram i można to rozwiązać w inny sposób niekoniecznie przez BT.

Szukaj modułów BLE (Bluetooth Low Energy).

r03c10 wrote:

A może w ogóle źle się za to zabieram i można to rozwiązać w inny sposób niekoniecznie przez BT.

Musiałbyś dokładniej opisać projekt.

Poczytaj na temat nRF51, idealnie nadaje się na twoje potrzeby, zakładając, że dobrze cię zrozumiałem.

Z tego co widzę to wszystkie moduły BLE są w standardzie BT 4.0. Czy zmienia to coś w sposobie samej komunikacji czy działa to tak samo jak w starszych modułach?

A co do nRF51 to są to chyba moduły Wi-Fi, a nie BT? Jeżeli tak to czy można pobierać z nich dane do terminala jak przy zwykłym rs232?

BlE działa inaczej. Nie potrzebujesz parować urządzeń ale za to komunikacja jest inna. Zwykły terminal bluetooth nie będzie działał z BLE.

Trudno coś konkretnego doradzić nie wiedząc co dokładnie chcesz zrobić.
W przypadku BLE urządzenie wysyłając krótką ramkę danych co około 1 sek. typowo pobiera około 50uA@3V. Stosują różne kombinacje może zejść do nawet do 15uA.

Jeśli chodzi o obsługę BLE w systemie Windows to od wersji 8.1 daje się napisać aplikację, która będzie działała identycznie jak terminal. W systemie nie pojawi się jednak standardowy port COM.

Twórcom sytemu Windows nie chciało się wszystkiego zmieniać wiec parowanie dla BLE zostawili. Z punktu widzenia standardu BT taka operacja może powodować jedynie problemy. W Windows 10 po dodaniu nowych funkcjonalności zagadnienie się jeszcze bardziej skomplikowało. Bez parowania można komunikować się z urządzeniami BLE w trybie bezpołączeniowym. Nawiązanie połączenia wymaga jednak już parowania.

Czyli jak rozumiem w przypadku BLE nie da się w prosty sposób odebrać informacji przez port COM. Jak w takim razie się to odbywa?

Wyjaśnię jeszcze raz o co mi chodzi. Otóż moje urządzenie zasilane baterią Li-ion 500mA oparte na procesorze AVR zbiera pewne dane, zapisując je na kartę SD. Chcę mieć możliwość pobrania tych danych w dowolnym momencie na komputer, dlatego moduł BT musi cały czas "czuwać" (odpada HC05- zbyt duży pobór prądu). Zasięg nie gra zbyt wielkiej roli ponieważ i tak urządzenie zawsze będzie dość blisko (max 15m) od komputera. W skrócie chodzi mi o takie coś:

AVR<<BT<<PC (w terminalu lub programie napisanym w C, który będzie otwierał port COM i z nigo odczytywał dane).

A jeszcze co do nRF51 to wszystko wygląda zachęcająco, ale czy mogę w prosty sposób przechwycić dane pochodzące od nich na komputerze? Może istnieją jakieś przejściówki z nRF51 na rs232?

Port COM pojawia się w systemie gdy urządzenie BT udostępnia profil SPP. W przypadku BLE nie jest to możliwe. Zastanów się czy obecność w systemie tego portu jest absolutnie niezbędna.

Teoretycznie ten COM niezbędny nie jest. Tylko jak w takim razie odczytam dane na przykład w Qt Creator albo w Visual Studio. Po prostu przyzwyczaiłem się, że w przypadku zwykłego BT mieliśmy do dyspozycji proste metody w Visual Studio jak: serialport.write(), serialport.read(). Po prostu trudno mi sobie wyobrazić jak czytać i wysyłać dane w inny sposób.

Jeśli wymieniasz VisualStudio to zapewne chodzi o system Windows. Tak jak już wspomniałem BLE obsługiwane jest od wersji Win 8.1. W VS znajdziesz kilka funkcji służących do odczytywania i zapisywania danych. System sam nawiąże połączenie i je zakończy.
Zobacz na co pozwala obiekt Windows.Devices.Bluetooth.GenericAttributeProfile
Zapewne na początku komunikacja będzie się wydawała dość dziwna. Przypomina bardziej odczyt i zapis rejestrów procesora niż obsługę UART.

Nie wiem jakiej prędkości transmisji oczekujesz. W systemie Windows programista chyba nie ma na żadnego wpływu na parametry nawiązywanego połączenia a od nich wszytko zalezy. Typowo 64kB (bajtów) przez notyfikacje odczytuje się przez około 15 sek. Czy jest to do zaakceptowania ?

Jeśli chcesz koniecznie mieć port COM to zobacz iNode Serial Transceiver USB.
Tego typu rozwiązania stosuje się w starszych systemach, gdzie brakuje standardowej obsługi BLE.

Prędkość szczerze mówiąc odgrywa w moim przypadku drugorzędną rolę. Za to do dyspozycji mam tylko Windows 7 i zastosowanie innego nie wchodzi w grę. Myślałem, że na starszych systemach wystarczy doinstalować odpowiednie sterowniki i wszystko powinno działać. Jeżeli chodzi o urządzenie iNode to czy dobrze rozumiem, że odnalazłoby ono każdy moduł BLE (podłączony na przykład do mikrokontrolera) i pozwoliło utworzyć wirtualny port COM czy też jestem w błędzie?

Sterowniki są to programy do obsługi urządzeń i interfejsów przewidzianych przez system. Jeśli system nie przewiduje istnienia BLE to instalacja sterownika tego nie zmieni.
Problem daje się rozwiązać na kilka sposobów. Można np. z poziomu własnej aplikacji bezpośrednio sterować układem odpowiedzialnym na interfejs BT w komputerze. To nie jest jednak prosta sprawa. Innym rozwiązaniem jest podłączenie dongla BT4.0-USB, który ma znany zestaw rozkazów i "widziany" będzie przez system jako standardowy port COM.
Jest to ekwiwalent podłączania HC05 przez RS232 do PC. Z własnej aplikacji można będzie nim sterować i przez ten moduł nawiązywać połączenia z innymi urządzeniami BT.

W przypadku klasycznego BT2.1 moduły mogły pracować w trybie slave i master. W BLE też jest podobny podział. Ten emulowany port COM dotyczy raczej strony slave.
Samo wyszukanie innych modułów BLE przez iNode USB jest akurat banalnie proste. Nawiązanie połączenia i przesyłanie danych jest już trudniejsze. Tak jak już wspominałem komunikacja od strony mastera przypomina zapis/odczyt rejestrów procesora. W zewnętrznym urządzeniu BT są tzw. charakterystyki. Każda ma swój identyfikator. Master musi zapisywać i odczytywać te charakterystyki. Służą do tego odpowiednie rozkazy HCI. Np. zapis ciągu bajtów do jednej z tych charakterystyk powoduje, że pojawią się one na porcie UART w urządzeniu slave. Podobnie jest w drugą stronę. Odebranie ciągu bajtów przez UART w urządzeniu slave powoduje pojawienie się tego ciągu w urządzeniu master. Tu jednak ten ciąg będzie dodatkowo opakowany w ramkę HCI.