Skocz do zawartości

Dev Kit ESP32 - komunikacja BLE (wymiana danych: mikrokontroler z telefonem - aplikacją Android / iOS).


LeciZNamiPilot

Pomocna odpowiedź

Witam ponownie forum!

Chcę zrobić niewielki projekt w oparciu o płytkę developerską ESP32, wraz z enkoderem i GPS-em. Jeśli muszę podać więcej szczegółów to podam, ale w skrócie:

Projekt ma zliczać obroty enkodera i co jakiś czas, gdy użytkownik naciśnie przycisk połączony z płytką ESP32, wyzwalane będzie przerwanie IRQ, które obsłuży dwie rzeczy:

- prześle dane - liczbę obrotów enkodera od ostatniego wyzwolenia (użycia przycisku),

oraz

- prześle aktualne współrzędne - dane z GPS (w miejscu w którym naciśnięto przycisk).

To jest podstawowa funkcjonalność, którą chcę uzyskać. Będzie kilka innych rzeczy, ale nie chcę o nich pisać, żeby uprościć opis.

 

Dane to będą krótkie stringi, kilkanaście znaków, maks. kilkadziesiąt. Wysyłać chcę z ESP32 do telefonu informacje za pośrednictwem Bluetooth Low Energy (BLE).

Trochę już czytałem na temat BLE, ale mam pytania, do osób które już wdrażały BLE w ESP32 o jakieś podpowiedzi, porady i wskazówki. Dokumentacja protokołu jest rozbudowana i nie znam jeszcze wielu rzeczy.

Z czego najlepiej skorzystać (jakie "serwisy" do przesyłania stosunkowo krótkich stringów, jak najlepiej rozwiązać parowanie urządzeń,  czy warto i jak uśpić BLE na krótki czas - do kilku minut i Wasze inne rozwiązania problemów/ trudności jakie napotkaliście). UUID chce mieć na stałe zapisane, by ułatwić parowanie obydwu urządzeń.

Dziękuję za wszelkie porady i wskazówki!

Myślałem, żeby z ESP32 dla ułatwienia zrobić server, a telefon uczynić klientem. To chyba by wystarczyło, aczkolwiek, nie wiem czy to do końca dobry pomysł, na wypadek jakiejś utraty łączności - nie mogę pozwolić żeby część danych nie dotarła do telefonu, a więc dobrze byłoby potwierdzać odebranie danych (???).

Z góry dziękuję za pomoc i podpowiedzi!

 

 

 

 

 

Link do komentarza
Share on other sites

Nic wspólnego nie miałem z ESP32 a tym bardziej BLE na ESP32, ale "standardowo" Nordic UARTo podobny. Przynajmniej nie trzeba nic (prawie) konfigurować w Bluetooth Serial Terminal - działa po prostu (z apką nie próbowałem, choć się przymierzam, w Android Studio - natywnie). Z innymi też nie trzeba, bo się przypisze co do czego w przypadku BST. A własna apka, to nie ma różnicy. Inne też jak uBlox, czy tam swoje UUID usług i ich charakterystyk, ale jak już jest jakiś "standard" od kogoś kto się na tym zna.

Kontroler jako serwer, a telefon - klient, to chyba nie jest niespotykana konfiguracja.

Usypianie i łączenie na samo przyciśnięcie przycisku to chyba dobry pomysł - BLE samo w sobie sprawnie się łączy, przynajmniej tak zaobserwowałem. Jak będą sparowane i powiązane, to i tak automatycznie się połączy. Zawsze możne być potem jakieś sprawdzenie czy wszystko zostało przesłane. Po obu stronach. Czy z ESP wyszło i czy telefon dostał i zakończył. Jest też opcja, bez samego połączenia, bejkonami, tylko telefon cały czas nasłuchuje, choć w praktyce, jakoś baterii to nie doi mocno, szczególnie jak sprzętowe filtrowanie w apce w telefonie się zrobi - to testowałem mocno. To też oczywiście zależy od ilości urządzeń dookoła. Ale też jest limit 27 bajtów, choć to można dużo tam upchać teksty i liczb, jak się zechce.

Jak jest telefon, to czy GPS potrzebny?

 

Edytowano przez matsobdev
  • Lubię! 1
Link do komentarza
Share on other sites

(edytowany)

Telefony będą różne (z Androidem oraz Iphone), ale GPS będzie wraz z ESP32, dlatego że jest dużo dokładniejszy, niż GPS w większości telefonów. To jest główny powód.

Cytat

Usypianie i łączenie na samo przyciśnięcie przycisku to chyba dobry pomysł

To jeszcze jest do przemyślenia, bo ile ESP32 obudzi się szybko, to np. GPS potrzebuje sporo czasu żeby się obudzić (oczywiście można usypiać tylko BLE).

Zainteresuje się BEACON-em.

Dzięki za podpowiedzi!

 

 

Edytowano przez LeciZNamiPilot
Link do komentarza
Share on other sites

Jak ja testowałem (dwa telefony, jeden rozgłaszał, drugi nasłuchiwał), to jeśli apka nie zostanie ubita, hula sobie w usłudze w planie głównym (foreground service) to po nocy reakcja odbiornika była natychmiastowa. To też testowane do granic wytrzymałości, choć wersja Androida może mieć znaczenie, dose itd. w Androidzie.

Link do komentarza
Share on other sites

Zarejestruj się lub zaloguj, aby ukryć tę reklamę.
Zarejestruj się lub zaloguj, aby ukryć tę reklamę.

jlcpcb.jpg

jlcpcb.jpg

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

(edytowany)

Znalazłem bardzo krótki wstęp do SPP i Beacona na ESP32 -> LINK.   Tylko, że w przykładzie pierwszym (bo w Beaconie nie jest to chyba potrzebne??) nie ma informacji na temat parowania urządzeń czy obsługi rozłączania parowania, itd.

Z tego co zrozumiałem, dane rozsyła się Beaconem zmieniając po prostu jego nazwę. Co rozumiem, że ułatwia zestawienie komunikacji (w sensie znacznego uproszczenia kodu), ale też chyba jest to zbyt okrojona funkcjonalność jak na moje potrzeby 😉  W teorii w nazwie Beacona można przesłać niemal dowolne dane, ale ....czy to się w praktyce przyda - będę musiał sprawdzić, przetestować. Ale dziękuję za pomysł!

---

Znalazłem 4 tutki, w których problem jest omówiony, przynajmniej częściowo:

 

Build a ESP32 based Bluetooth iBeacon
https://circuitdigest.com/microcontroller-projects/esp32-based-bluetooth-ibeacon

ESP32 BLE Server - GATT Service for Battery Level Indication
https://circuitdigest.com/microcontroller-projects/esp32-ble-server-how-to-use-gatt-services-for-battery-level-indication

ESP32 Bluetooth Low Energy (BLE) on Arduino IDE | Random Nerd Tutorials
https://randomnerdtutorials.com/esp32-bluetooth-low-energy-ble-arduino-ide/

ESP32 BLE Server and Client (Bluetooth Low Energy) | Random Nerd Tutorials
https://randomnerdtutorials.com/esp32-ble-server-client/

 

Muszę temat zgłębić, w razie problemów - wrócę z bardziej konkretnymi pytaniami, a jak wszystko się uda, to pochwalę się gotowym projektem.

Edytowano przez LeciZNamiPilot
Link do komentarza
Share on other sites

No tak, jak powiedziałem, tutaj nie ma połączenia, parowania/wiązania. Jak FM, ktoś nadaje, ktoś odbiera. Tutaj "zwykły" UART będzie chyba najlepszy. Komunikacja po GATT, w sumie jakie UUID nieważne, pewnie i tak to 128 bitowe do wyboru. Ważny sposób komunikacji, zapis do charakterystyki, odczyt, powiadomienia, i cośtam jeszcze było. Sprawdź metody wymiany danych z charakterystykami - read, write, notify, indicate. Jedne będą bardziej pasowały niż inne. Choć pewnie i tak da się to zrobić, żeby było niezawodne za każdym razem. Jeśli odległości nie są znaczne i nie ma zbytniego oszczędzania mocy nadajnika, to raczej będzie działać. Można tylko uruchamiać BLE po naciśnięciu przycisku, czekać chwilkę na automatyczne połączenia klienta i wtedy nie będzie długi czas głucho na połączeniu. No i testować. Choć to może być upierdliwe w pewnych zastosowaniach, ale taki pilot do dekodera DVB-T z Androidem, na BLE, nieco dłuższy przestój, telewizor wyłączony, włączam, dioda mignęła, 2 sekundy i albo się włączy, albo nie 😄 Np. 20 minut oglądania bez dotykania pilota, klik głośniej i podobnie... Dioda miga, pilot działa. Ale testując Pico W i sparowane i powiązane z telefonem, po zasileniu Pico bezbłędnie się łączył i to szybko. Choć jak nie trzeba spać, to połączenie pewnie będzie się utrzymywać, jak konfiguracja temu nie przeszkodzi.

Edytowano przez matsobdev
  • Lubię! 1
Link do komentarza
Share on other sites

Jak się uśpi całość (esp i gps), to po wybudzeniu trzeba będzie czekać na hot (albo i cold) start gps. A to są dziesiątki sekund.

Moduły gps (przynajmniej te z ublox) ciągną jakieś 50mA, więc bez odłączania ich zasilania i tak szybko wydoją baterię. Chyba że jest jakaś funkcjonalność "usypiania gps" bez zatrzymywania śledzenia satelitów. Nic mi o czymś takim nie wiadomo. Samo zasilanie anteny gps to kilkanaście mA.

Komunikacja po BLE jest stosunkowo prosta. W uproszczeniu: robi się na serwerze charakterystykę typu indication (czyli notyfikację z potwierdzeniem odbioru, żeby zdarzenie dotarło do odbiorcy) i subskrybuje się to na kliencie.

 

  • Lubię! 1
Link do komentarza
Share on other sites

Dołącz do dyskusji, napisz odpowiedź!

Jeśli masz już konto to zaloguj się teraz, aby opublikować wiadomość jako Ty. Możesz też napisać teraz i zarejestrować się później.
Uwaga: wgrywanie zdjęć i załączników dostępne jest po zalogowaniu!

Anonim
Dołącz do dyskusji! Kliknij i zacznij pisać...

×   Wklejony jako tekst z formatowaniem.   Przywróć formatowanie

  Dozwolonych jest tylko 75 emoji.

×   Twój link będzie automatycznie osadzony.   Wyświetlać jako link

×   Twoja poprzednia zawartość została przywrócona.   Wyczyść edytor

×   Nie możesz wkleić zdjęć bezpośrednio. Prześlij lub wstaw obrazy z adresu URL.

×
×
  • Utwórz nowe...

Ważne informacje

Ta strona używa ciasteczek (cookies), dzięki którym może działać lepiej. Więcej na ten temat znajdziesz w Polityce Prywatności.