BLE 5.0 — urządzenia GEST używają BLE, by osiągnąć 2-letnią żywotność baterii przy interwałach telemetrii co 30 sekund
Wybór protokołu między BLE a WiFi kształtuje całą architekturę produktu — budżet energetyczny, wymagania wobec bramy, projekt anteny na PCB i doświadczenie użytkownika.
Moc: różnica o rząd wielkości
WiFi utrzymuje asocjację radiową nawet w stanie bezczynności, pobierając stale 1–8 mA. BLE może rozgłaszać przy cyklu pracy <1%, przy średnim poborze poniżej 100 μA. Na baterii pastylkowej CR2032 (225 mAh):
WiFi (telemetria 30s, połączenie 10s): ~8 mA śr. → ~3 miesiące BLE (interwał 30s, połączenie 500ms): ~0.08 mA śr. → ~24 miesiące
Właśnie dlatego GEST używa wyłącznie BLE. 2-letnia żywotność baterii przy wymaganym interwale pomiaru jest osiągalna tylko z BLE.
Kiedy wybrać BLE
- Zasilane bateryjnie czujniki celujące w ponad rok pracy na baterii pastylkowej
- Urządzenia łączące się bezpośrednio ze smartfonami bez huba
- BLE mesh dla sieci czujników w inteligentnych budynkach
Kiedy wybrać WiFi
- Urządzenia zasilane sieciowo, gdzie pobór mocy nie jest ograniczeniem
- Wymagania wysokiej przepustowości (streaming 4K, transfer dużych plików)
- Bezpośrednie połączenie z chmurą bez bramy
BLE Mesh i Thread: poza komunikacją punkt-punkt
BLE 5.0 wprowadziło Bluetooth Mesh, umożliwiając komunikację wiele-do-wielu w obrębie całego budynku. Każdy węzeł może przekazywać wiadomości, więc czujnik w piwnicy może komunikować się z bramą na najwyższym piętrze, przeskakując przez urządzenia pośrednie. To sprawia, że BLE jest opłacalne w dużych wdrożeniach w inteligentnych budynkach, gdzie doprowadzenie punktu dostępowego WiFi do każdej lokalizacji czujnika jest niepraktyczne.
Thread (również działający na sprzęcie 802.15.4) to kolejny niskoenergetyczny protokół mesh zyskujący popularność w automatyce inteligentnego domu i budynków komercyjnych. Jeśli Twój produkt musi integrować się z ekosystemami Apple Home lub Google Home, Thread z Matter jest coraz częściej wybieranym protokołem. Urządzenia Thread mogą działać latami na bateriach AA, zachowując łączność mesh — porównywalnie z BLE pod względem efektywności energetycznej.
Architektura bramy
Urządzenia BLE i Thread wymagają bramy do połączenia z internetem — nie mogą łączyć się bezpośrednio z Twoim zapleczem chmurowym. To dodaje komponent do architektury produktu: brama musi być zawsze online, musi mieć niezawodny zasięg BLE do wszystkich urządzeń i staje się pojedynczym punktem awarii dla łączności z chmurą. W wielu wdrożeniach brama działa na Raspberry Pi, wbudowanej płycie z Linuksem lub w aplikacji na smartfona.
Urządzenia WiFi łączą się bezpośrednio z zapleczem chmurowym bez bramy, co upraszcza architekturę kosztem wyższego poboru mocy. Dla produktów zasilanych sieciowo, gdzie prostota liczy się bardziej niż żywotność baterii — czujniki środowiskowe w serwerowniach, inteligentne gniazdka, monitory przemysłowe — WiFi pozostaje pragmatycznym wyborem.
Kwestie projektowania anteny
Zarówno BLE, jak i WiFi działają w paśmie 2,4 GHz i dzielą tę samą fizykę anteny. Różnica tkwi w mocy nadawania i modulacji: WiFi nadaje z mocą do 20 dBm, BLE zazwyczaj 0–8 dBm. Na superjachcie ze stalowymi grodziami oba protokoły zmagają się z penetracją tak samo — wybór umiejscowienia bramy i typu anteny (wewnętrzna ścieżka na PCB vs zewnętrzna antena prętowa) ma większe znaczenie niż sam protokół.
Nasz zespół sprzętowy uwzględnia umiejscowienie anteny i strefy wolne od RF w każdym układzie PCB już od pierwszego prototypu. Złe umiejscowienie anteny to jedna z głównych przyczyn problemów z zasięgiem w terenie — a znacznie łatwiej naprawić je w projekcie niż po zmontowaniu 10 000 sztuk.
Budujesz produkt IoT?
FSS to pełnostackowy zespół inżynieryjny IoT — sprzęt, firmware, chmura i aplikacje mobilne w jednym miejscu.