Zapewnienie stałej łączności Wi-Fi bez skracania czasu pracy baterii

Ponieważ technologia Wi-Fi jest wszechobecna i charakteryzuje się wysoką przepustowością, pozostaje ona podstawowym wymogiem łączności w przypadku wielu urządzeń z dostępem do Internetu rzeczy (IoT). Jednak w przypadku urządzeń ubieralnych i innych urządzeń IoT z zasilaniem bateryjnym, zapotrzebowanie na moc w konwencjonalnych rozwiązaniach Wi-Fi sprawiło, że stała łączność Wi-Fi stała się niepraktyczna, ponieważ zazwyczaj wymaga od deweloperów pogorszenia niektórych aspektów funkcjonalności urządzenia, wydajności lub czasu pracy na baterii.

W przypadku niektórych zespołów wyjściem może być projektowanie niestandardowych rozwiązań Wi-Fi w celu optymalizacji pracy w trybie niskiej mocy, jednak może okazać się to kosztownym i czasochłonnym przedsięwzięciem, zwłaszcza biorąc pod uwagę niedobór projektantów wykwalifikowanych w technologiach RF. Istnieje zapotrzebowanie na bardziej kompletne rozwiązanie, które sprawi, że stały dostęp do Wi-Fi będzie praktyczny również w przypadku urządzeń IoT niskiej mocy.

W niniejszym artykule przedstawiono, w jaki sposób deweloperzy mogą wdrożyć stałą łączność Wi-Fi przy użyciu funkcji niskiej mocy wbudowanych w bezprzewodowe urządzenie typu system-on-chip (SoC) firmy Dialog Semiconductor.

Wyzwania związane z obsługą łączności Wi-Fi w urządzeniach mobilnych

Technologia Wi-Fi zazwyczaj łączy w sobie dwie cechy - jest wszechobecna i charakteryzuje się sprawnością wymaganą w przypadku szerokiej gamy zastosowań IoT zbudowanych wokół osobistych produktów mobilnych, inteligentnych urządzeń domowych i systemów automatyki budynków, a to tylko kilka przykładów. W przeszłości jednak stosunkowo wysoki pobór prądu przez podsystemy Wi-Fi zmuszał deweloperów do ograniczania czasu pracy na baterii lub siły sygnału w urządzeniach IoT z zasilaniem bateryjnym.

Wysokie zapotrzebowanie na moc w tradycyjnych rozwiązaniach Wi-Fi stawia dodatkowe wyzwania przed deweloperami IoT. Na przykład, wymagania dotyczące zarówno łączności Wi-Fi, jak i dłuższego czasu pracy na bateriach mogą zwiększyć rozmiar i złożoność projektu, w celu zmieszczenia większych baterii. W przypadku urządzeń ubieralnych, a także wielu urządzeń IoT, w których nie można zastosować większych baterii, wydłużenie czasu pracy baterii poprzez zmniejszenie mocy sygnału Wi-Fi (i związanego z tym zużycia energii) może być niewykonalne.

Poza wspomnianymi problemami, deweloperzy IoT napotykają praktyczne ograniczenia typowego środowiska sygnału Wi-Fi, gdzie siła sygnału może się znacznie różnić ze względu na zakłócenia wielościeżkowe i inne charakterystyczne cechy sygnału o częstotliwości radiowej (RF). W przypadku zastosowań takich jak laptopy, konsument może po prostu przenieść komputer w inne miejsce z lepszym sygnałem Wi-Fi. W przeciwieństwie do powyższej sytuacji, inteligentny zamek lub urządzenie AGD musi utrzymywać niezawodną łączność i sprawne działanie niezależnie od miejsca instalacji.

Aby zadbać zarówno o dłuższy czas pracy na baterii, jak i dużą moc sygnału Wi-Fi, deweloperzy zazwyczaj w pełni wykorzystują tryby uśpienia o niskim poborze mocy dostępne w większości zaawansowanych procesorów, radiach i innych złożonych komponentach sprzętowych. Maksymalizując czas, jaki urządzenia zużywające dużo energii spędzają w odpowiednich trybach niskiego poboru mocy, deweloperzy mogą wdrażać konstrukcje wydłużające czas pracy na bateriach, zwykle przy niewielkim wpływie na funkcjonalność systemu. W takich konstrukcjach układ czasowy niskiej mocy może okresowo wybudzać system na krótką chwilę, aby odczytać dane z czujników i przesłać je bezprzewodowo przed powrotem do trybu uśpienia.

W przypadku niektórych zastosowań urządzenie IoT musi jednak utrzymywać stałe połączenie z siecią Wi-Fi, aby zapewnić szybką reakcję na polecenia użytkownika wydawane za pośrednictwem aplikacji mobilnych, oprogramowania stacjonarnego, a nawet innych urządzeń. Na przykład, inteligentne zamki, oświetlenie i przełączniki znajdujące się w inteligentnych domach muszą zachować łączność, aby zapewnić natychmiastową reakcję na polecenia użytkownika. Czekanie na to, aż urządzenie oparte na układzie czasowym się wybudzi, wykryje polecenie i wreszcie odblokuje drzwi lub włączy oświetlenie byłoby po prostu nie do przyjęcia dla użytkowników.

Układ SoC DA16200 firmy Dialog Semiconductor i związane z nim moduły stanowią efektywne rozwiązanie o niskim poborze mocy, które jest w stanie sprostać wymaganiom dotyczącym zarówno stałej łączności Wi-Fi, jak i dłuższego czasu pracy na bateriach.

Wdrożenie łączności Wi-Fi przy użyciu bezprzewodowego układu SoC

Zaprojektowany specjalnie dla konstrukcji IoT z zasilaniem bateryjnym układ SoC DA16200 łączy w sobie procesor Arm® Cortex®-M4F z pełnym podsystemem radiowym Wi-Fi, działającym w pełnym stosie protokołów sieci, co eliminuje konieczność stosowania zewnętrznego procesora sieciowego lub głównego procesora w celu zapewnienia funkcjonalności stosu. Poza podsystemem radiowym urządzenie zawiera pełen zestaw bloków funkcjonalnych i interfejsów wymaganych zazwyczaj w konstrukcjach Internetu rzeczy (ilustracja 1).

Ilustracja 1: układ SoC DA16200 firmy Dialog Semiconductor to kompletne rozwiązanie Wi-Fi umożliwiające zachowanie stałej łączności Wi-Fi przy minimalnym zużyciu prądu. (Źródło ilustracji: Dialog Semiconductor)

Urządzenie wyposażone jest w wiele standardowych interfejsów oraz w 4-kanałowy, 12-bitowy przetwornik analogowo-cyfrowy (ADC) o sukcesywnej aproksymacji (SAR) do obsługi akwizycji sygnału analogowego.

Aby zapewnić działanie aplikacji, układ DA16200 został wyposażony w wiele pamięci wewnętrznych, w tym:

• Pamięć tylko do odczytu dla programu ładującego, jądra systemu, stosu sieciowego i sterowników.
• Statyczna pamięć o dostępie swobodnym (SRAM) dla danych programu. Kod programu wykonywany jest na miejscu (XIP) w szeregowej pamięci flash dostępnej przez zewnętrzny szeregowy interfejs pamięci flash urządzenia.
• Pamięć programowalna jednorazowo (OTP) służąca do przechowywania informacji o urządzeniu oraz kluczy kryptograficznych i bezpiecznego programu ładującego. Dane OTP pozostają bezpieczne, dostęp do nich jest możliwy tylko poprzez kontroler OTP, a w przeciwnym razie pozostają niewidoczne dla standardowego dostępu do danych za pośrednictwem magistrali systemowej.

Aby pomóc deweloperom sprostać rosnącemu zapotrzebowaniu na zabezpieczenia podłączonych urządzeń, układ SoC DA16200 integruje szeroki zestaw mechanizmów zabezpieczających, w tym silnik kryptograficzny Advanced Encryption Standard (AES), Secure Hash Algorithms (SHA) i inne szyfry, a także wsparcie dla protokołu Transport Layer Security (TLS). W skład urządzenia wchodzi również technologia zabezpieczeń w formie własności intelektualnej (IP) Arm TrustZone CryptoCell-312 (CC312). Zaprojektowane z myślą o urządzeniach o małej mocy rozwiązanie CC312 obsługuje bezpieczne uruchamianie i oferuje system Root of Trust dla zabezpieczenia aplikacji.

Urządzenie ułatwia zapewnienie łączności Wi-Fi dzięki obszernemu modułowi RF. Poza wbudowanymi warstwami fizycznymi (PHY) kontroli dostępu do mediów (MAC) 802.11 i 802.11b/g/n, podsystem radiowy zawiera także wbudowany nadajniko-odbiornik ze zintegrowanymi wzmacniaczami mocy (PA) i wzmacniaczami niskoszumowymi (LNA), które eliminują potrzebę stosowania zewnętrznych komponentów aktywnych. Podczas pracy procesor układu DA16200 Arm Cortex-M4F wykonuje wbudowany stos protokołu kontroli transmisji/protokołu internetowego (TCP/IP), aby odciążyć procesor główny systemu od operacji związanymi z łącznością.

Aby móc zasilać różne bloki, w tym blok RF, układ SoC DA16200 zawiera przetwornicę prądu stałego, regulatory LDO oraz przełączniki zasilania. Przetwornica i regulator LDO zarządzane przez blok zegara czasu rzeczywistego (RTC) generują wszystkie potrzebne szyny zasilające z jednego zasilacza z napięciem bateryjnym VBAT. Podczas gdy przetwornica prądu stałego generuje 1,4V dla bloku RF i cyfrowego regulatora LDO z napięcia VBAT, wejście-wyjście regulatora LDO generuje 1,8V konieczne do pracy zewnętrznej pamięci flash i wejścia-wyjścia ogólnego przeznaczenia urządzenia (GPIO) (ilustracja 2).

Ilustracja 2: jednostka zarządzania energią z układem SoC DA16200 steruje zintegrowanymi komponentami zasilającymi urządzenia, dostarczającymi napięcie do jego oddzielnych stref zasilania. (Źródło ilustracji: Dialog Semiconductor)

Jednostka zarządzania energią z układem SoC DA16200 steruje zasilaniem oddzielnych stref zasilania w ramach funkcji zarządzania trzema trybami niskiego poboru mocy urządzenia (uśpienia):

• Pierwszy tryb uśpienia oferuje najniższą moc przy 0,2μA: w tym trybie urządzenie jest w dużej mierze wyłączone, ale budzi się w ciągu 150ms w odpowiedzi na zewnętrzny sygnał dostarczony do dwóch wtyków wybudzających układ SoC lub do jednego z kilku cyfrowych wejść-wyjść, bądź gdy analogowy sygnał wejściowy przekroczy wcześniej zdefiniowany próg.
• W drugim trybie uśpienia zużywa tylko 1,8μA przy zachowaniu funkcjonalności RTC: w tym trybie, układ SoC wybudza się w czasie krótszym niż 100ms w odpowiedzi na zewnętrzne zdarzenia wybudzające lub po zakończeniu działania zaprogramowanego wewnętrznego układu czasowego.
• Trzeci tryb uśpienia oferuje unikalny tryb stałego podłączenia z Wi-Fi, który umożliwia pobieranie minimalnej ilości prądu i sprawia, że układ wybudza się w czasie krótszym niż 2ms po wykryciu przychodzących pakietów danych Wi-Fi: jak opisano poniżej, wykorzystanie trzeciego trybu uśpienia z konwencjonalną funkcją utrzymanie aktywności TCP stanowi podstawę do wdrożenia stałej łączności Wi-Fi, która pobiera prąd o średnim natężeniu poniżej 50μA.

Technologia dynamicznego zarządzania energią umożliwia stałą łączność Wi-Fi

Pod tymi trybami uśpienia o niskiej mocy kryje się opatentowana przez firmę Dialog Semiconductor technologia Dynamic Power Management (DPM), która wyłącza nieużywane mikroelementy w układzie scalonym, powodując minimalne zużycie energii, gdy urządzenie nie nadaje i nie odbiera danych. Podczas operacji Wi-Fi, technologia DPM minimalizuje zużycie energii podczas nadawania i odbierania sygnału radiowego, wykorzystując zaawansowane algorytmy wybudzające potrzebne mikroelementy dokładnie wtedy, gdy są potrzebne.

Opracowany przez firmę Dialog Semiconductor zestaw rozwojowy oprogramowania (SDK) DA16200 zbiera razem szczegóły dotyczące zarządzania energią i obsługi DPM za pomocą interfejsu API DPM Manager. W przypadku tworzenia oprogramowania na zamówienie, zestaw rozwojowy SDK zapewnia dostęp do stosu oprogramowania usług aplikacyjnych i systemowych DA16200 (ilustracja 3).

Ilustracja 3: architektura oprogramowania układu SoC DA16200 zapewnia pełen zestaw usług systemowych i aplikacyjnych wymaganych do obsługi standardowych połączeń Wi-Fi w urządzeniach IoT. (Źródło ilustracji: Dialog Semiconductor)

Wdrożenie stałej łączności Wi-Fi wymaga wykorzystania programu DPM Manager oraz biblioteki NetX Duo TCP/IP. Biblioteka NetX Duo udostępnia funkcję utrzymania aktywności TCP, która wysyła pakiet TCP bez danych do routera Wi-Fi, zapewniając utrzymanie aktywnego połączenia Wi-Fi przez router. Deweloperzy mogą wywoływać tę funkcję po prostu poprzez ustawienie opcji gniazda keepalive_enabled TCP na wartość „true” oraz podanie liczby sekund, keepalive_timeout, pomiędzy pakietami utrzymania aktywności. NetX Duo automatycznie przesyła ramki utrzymania aktywności w miarę potrzeb.

Podczas gdy pakiety utrzymania aktywności utrzymują połączenie sieciowe z routerem lub innym hostem, zdolność DA16200 do wybudzenia z trzeciego trybu uśpienia polega na wykrywaniu standardowych elementów informacyjnych mapy TIM lub mapy DTIM wbudowanych w ramki zarządzania 802.11 i jest wykorzystywana do powiadamiania stacji sieciowych takich jak system DA16200, że za chwile będzie miał miejsce ruch sieciowy. Kiedy układ DA16200 znajduje się w trzecim trybie uśpienia, technologia DPM DA16200 sprawia, że podsystem radiowy zużywa minimalną ilość energii poszukując elementów TIM/DTIM. Gdy podsystem radiowy układu DA16200 wykryje elementy TIM/DTIM, wybudza układ SoC do rozpoczęcia przetwarzania normalnego ruchu Wi-Fi, jak każda stacja sieciowa.

Korzystając z interfejsu API DA16200 DPM Manager, deweloperzy muszą wykonać tylko kilka intuicyjnych połączeń, aby wdrożyć tę funkcjonalność. Po zdefiniowaniu odpowiedniej konfiguracji DPM, w tym parametrów i wywołań zwrotnych, deweloperzy używają wywołań funkcji interfejsu API DPM Manager do wywołania lub interakcji z DPM Manager. Wejście i wyjście z trzeciego trybu uśpienia w przejrzysty w sposób obsługuje technologia DA16200 DPM.

Przykładowe aplikacje wchodzące w skład zestawu rozwojowego SDK ilustrują podstawowe schematy projektowe wymagane do wdrożenia tej sekwencji operacji (listing 1).

Kopiuj
#define TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT            55
[lines deleted]
void tcp_client_ka_dpm_sample_wakeup_callback()
{
    PRINTF(GREEN_COLOR " [%s] DPM Wakeup\n" CLEAR_COLOR, __func__);
 
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_recv_callback(void *sock, UCHAR *rx_buf, UINT rx_len,
                                            ULONG rx_ip, ULONG rx_port)
{
    int status = NX_SUCCESS;
 
    //Display received packet
    PRINTF(" =====> Received Packet(%ld) \n", rx_len);
 
    tcp_client_ka_dpm_sample_hex_dump("Received Packet", rx_buf, rx_len);
[lines deleted]
    dpm_mng_job_done(); //Done operation
}
[lines deleted]
void tcp_client_ka_dpm_sample_init_user_config(dpm_user_config_t *user_config)
{
[lines deleted]
    //Set DPM wakeup init callback
    user_config->wakeupInitCallback = tcp_client_ka_dpm_sample_wakeup_callback;
[lines deleted]
    //Set Recv callback
    user_config->sessionConfig[session_idx].session_recvCallback =
        tcp_client_ka_dpm_sample_recv_callback;
[lines deleted]
    //Set KeepAlive timeout
    user_config->sessionConfig[session_idx].session_ka_interval =
        TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT;
[lines deleted]
}
[lines deleted]
void tcp_client_ka_dpm_sample(ULONG arg)
{
[lines deleted]
    //Register user configuration
    dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config);
 
    //Start TCP Client Sample
    dpm_mng_start();
 
    return ;
}

Listing 1: używając układu SoC DA16200, programiści mogą wdrożyć stałą łączność Wi-Fi przy użyciu odpowiedniej konfiguracji i kilku połączeń funkcji interfejsu API DPM. (Źródło kodu: Dialog Semiconductor)

Jak pokazano w listingu 1, programiści mogą wdrożyć tę właściwość głównie za pomocą funkcji inicjalizacji (tcp_client_ka_dpm_sample_init_user_config()), która ustawia różne parametry konfiguracyjne, łącznie z interwałem utrzymania aktywności (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT) i wyznacza różne wywołania zwrotne, w tym wywołania funkcji wybudzania DMP (tcp_client_ka_dpm_sample_wakeup_callback()) oraz wywołania przetwarzania przychodzących pakietów danych (tcp_client_ka_dpm_sample_recv_callback()). Aby rozpocząć sekwencję utrzymania aktywności TCP i wybudzania DPM, oddzielna funkcja (tcp_client_ka_dpm_sample()) po prostu wywołuje procedurę konfiguracji (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) oraz DMP Manager (dpm_mng_start()).

Jak wspomniano wcześniej, cała sekwencja, łącznie ze standardowymi pakietami utrzymania aktywności TCP i monitorowaniem Wi-Fi z obsługą DA16200 DPM, zapewnia stałą łączność Wi-Fi, która zazwyczaj zużywa średnio mniej niż 50μA prądu.

Ten sam schemat projektowy może być używany do wybudzania układu SoC z trybów uśpienia, w celu przeprowadzenia innych operacji. Przykładowe zastosowanie przedstawia wykorzystanie zegara RTC układu DA16200 do budzenia układu SoC w celu przetwarzania danych (listing 2).

Kopiuj
#define    SAMPLE_FOR_DPM_SLEEP_3        // Sleep Mode 3
 
#define    MICROSEC_FOR_ONE_SEC        1000000
#define    RTC_TIMER_WAKEUP_ONCE        5    // seconds
#define    RTC_TIMER_WAKEUP_PERIOD        10    // seconds
static void rtc_timer_dpm_once_cb(char *timer_name)
{
[lines deleted]
static void rtc_timer_dpm_periodic_cb(char *timer_name)
{
    /*
     *Caution : Don't spend a lot of time in the calback function called by timer.
     */
    dpm_app_sleep_ready_clear(SAMPLE_RTC_TIMER);
 
    PRINTF("\nWakeup due to Periodic RTC timer!!!\n");
    tx_thread_sleep(10);
 
    dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
}
[lines deleted]
void rtc_timer_sample(ULONG arg)
{
[lines deleted]
        /* Periodic timer */
        status = dpm_timer_create(SAMPLE_RTC_TIMER,
                                  "timer2",
                                  rtc_timer_dpm_periodic_cb,
                                  RTC_TIMER_WAKEUP_PERIOD,
                                  RTC_TIMER_WAKEUP_PERIOD);
[lines deleted]
        dpm_app_sleep_ready_set(SAMPLE_RTC_TIMER);
[lines deleted]
    }
 
    while (1)
    {
        /* Nothing to do... */
        tx_thread_sleep(100);
    }
}

Listing 2: deweloperzy mogą wdrożyć funkcjonalność opartą na układzie czasowym niskiej mocy przy pomocy układu DA16200, stosując kilka wywołań funkcji interfejsu API DPM, w celu zapewnienia minimalnego poboru mocy w trybach uśpienia układu DA16200. (Źródło kodu: Dialog Semiconductor)

Jak pokazano w listingu 2, programista wywołuje funkcję interfejsu API DPM Manager (dpm_timer_create()), aby utworzyć układ czasowy (SAMPLE_RTC_TIMER) i inną funkcję interfejsu API DPM Manager (dpm_app_sleep_ready_set()), aby wskazać, że system jest gotowy do powrotu do trybu uśpienia. Silnik DPM określi wtedy, jak szybko system może powrócić do trybu uśpienia niskiej mocy na podstawie bieżącej aktywności. Później, gdy układ czasowy zakończy pracę, system wykona funkcję wywołania zwrotnego określoną przez dewelopera, rtc_timer_dpm_periodic_cb(), która wykonuje wymagane operacje - w tym przypadku jest to wydrukowanie powiadomienia do konsoli. Po zakończeniu operacji, ta sama funkcja wywołania zwrotnego wykonuje dpm_app_sleep_ready_set(), aby powiadomić silnik DPM, że system jest gotowy do powrotu do trybu uśpienia. Tak jak poprzednio, silnik DPM kończy przejście do trybu uśpienia w odpowiednim momencie.

Moduły typu „drop-in” upraszczają projekty Wi-Fi

Zestaw rozwojowy SDK DA16200 ułatwia projektowanie oprogramowania, natomiast rozbudowana funkcjonalność urządzenia w układzie scalonym przekłada się na stosunkowo prosty projekt interfejsu sprzętowego. Korzystając z układu SoC DA16200 wraz z zewnętrznym urządzeniem flash, takim jak układ scalony 16 megabitowej (Mbit) pamięci NOR W25Q16JVSNIQ firmy Winbond Electronics i zaledwie kilku dodatkowych komponentów, deweloperzy mogą opracować bezpieczny projekt IoT z obsługą Wi-Fi (ilustracja 4).

Ilustracja 4: układ SoC DA16200 firmy Dialog Semiconductor, dzięki swojej rozbudowanej, zintegrowanej funkcjonalności, wymaga jedynie zewnętrznej szeregowej pamięci flash i minimalnej liczby dodatkowych komponentów do wdrożenia kompletnego systemu Wi-Fi. (Źródło ilustracji: Dialog Semiconductor)

Deweloperzy chcący przyspieszyć rozwój własnych projektów opartych na układzie SoC DA16200 mogą skorzystać z modułów firmy Dialog Semiconductor, które eliminują potrzebę implementacji interfejsu sprzętowego SoC. Poza układem SoC DA16200, moduły zawierają 4MB pamięci flash, komponenty RF oraz moduł antenowy na płytce (DA16200MOD-AAC4WA32) lub złącze u.FL do podłączenia anteny zewnętrznej (DA16200MOD-AAE4WA32). W pełni certyfikowane przez FCC, IC, CE i inne organy regulacyjne, moduły o wymiarach 13,8 x 22,1 x 3,3mm stanowią sprzętowe rozwiązanie typu „drop-in” umożliwiające wdrażanie stałej łączności Wi-Fi niskiej mocy.

Deweloperzy chcący badać temat stałej łączności Wi-Fi i szybko tworzyć prototypowe projekty IoT oparte na układzie SoC DA16200 mogą od razu skorzystać z zestawu rozwojowego DA16200MOD-DEVKT firmy Dialog Semiconductor. Zestaw ten łączy w sobie moduł DA16200MOD z interfejsem USB, kluczami i połączeniami, aby przyspieszyć rozwój i usuwanie błędów w konstrukcjach opartych na układzie DA16200.

Podsumowanie

Możliwość utrzymania stałej łączności Wi-Fi jest standardową funkcją laptopów i innych urządzeń podłączonych do sieci. Jednak w przypadku urządzeń ubieralnych i innych urządzeń IoT z zasilaniem bateryjnym zapotrzebowanie na energię w ramach konwencjonalnych rozwiązań Wi-Fi sprawiło, że stała łączność Wi-Fi okazała się niepraktyczna. Wskutek tego deweloperzy często muszą rezygnować z niektórych aspektów funkcjonalności urządzenia, wydajności lub czasu pracy na baterii.

Układ SoC firmy Dialog Semiconductor zapewnia kompletne rozwiązanie Wi-Fi umożliwiające zapewnienie stałej łączności Wi-Fi przy minimalnym zużyciu prądu. Jak przedstawiono, wykorzystanie układu SoC lub powiązanych z nim modułów, pozwala deweloperom na szybkie wdrożenie bezpiecznych urządzeń z zasilaniem bateryjnym, które zapewnią użytkownikom korzyści płynące ze stałej łączności Wi-Fi, spełniając jednocześnie ich oczekiwania dotyczące dłuższego czasu pracy na bateriach.