Kontinuierliche Wi-Fi-Konnektivität ohne Beeinträchtigung der Akkulaufzeit

Mit seiner hohen Bandbreite und Allgegenwart bleibt Wi-Fi eine primäre Konnektivitätsanforderung für viele Internet of Things (IoT)-Geräte. Bei Wearables und anderen batteriebetriebenen IoT-Geräten haben die Leistungsanforderungen herkömmlicher Wi-Fi-Lösungen eine kontinuierliche Wi-Fi-Konnektivität jedoch unpraktisch gemacht, so dass Entwickler in der Regel Kompromisse bei der Funktionalität, Leistung oder Batterielebensdauer der Geräte eingehen müssen.

Während die Entwicklung einer maßgeschneiderten Wi-Fi-Lösung zur Optimierung für geringen Stromverbrauch für einige Teams eine Option sein könnte, kann dies ein teures und zeitaufwändiges Unterfangen sein, insbesondere angesichts des Mangels an qualifizierten HF-Designern. Es ist eine umfassendere Lösung erforderlich, die kontinuierliches Wi-Fi auch für IoT-Geräte mit geringem Stromverbrauch praktikabel macht.

Dieser Artikel zeigt, wie Entwickler eine kontinuierliche Wi-Fi-Konnektivität unter Verwendung von Stromsparfunktionen implementieren können, die in ein drahtloses System-on-Chip (SoC)-Gerät von Dialog-Halbleiter eingebaut sind.

Die Herausforderungen bei der Unterstützung von Wi-Fi-Konnektivität für mobile Geräte

Wi-Fi bietet typischerweise die Kombination von allgegenwärtiger Präsenz und Leistungsmerkmalen, die in einer Vielzahl von IoT-Anwendungen benötigt werden, die auf persönlichen mobilen Produkten, intelligenten Heimgeräten und Gebäudeautomatisierungssystemen basieren, um nur einige zu nennen. In der Vergangenheit zwang der relativ hohe Stromverbrauch von Wi-Fi-Subsystemen die Entwickler jedoch dazu, bei batteriebetriebenen IoT-Geräten Kompromisse bei der Batterielebensdauer oder der Signalstärke einzugehen.

Der hohe Energiebedarf traditioneller Wi-Fi-Lösungen stellt IoT-Entwickler vor zusätzliche Herausforderungen. Beispielsweise können Anforderungen sowohl an die Wi-Fi-Konnektivität als auch an eine verlängerte Batterielebensdauer die Größe und Komplexität des Designs erhöhen, um größere Batterien unterzubringen. Bei Wearables oder vielen IoT-Geräten, bei denen größere Batterien möglicherweise nicht in Frage kommen, sind Versuche, die Batterielebensdauer durch Verringerung der Wi-Fi-Signalstärke (und des damit verbundenen Stromverbrauchs) zu verlängern, möglicherweise nicht durchführbar.

Neben diesen Bedenken sehen sich die IoT-Entwickler mit den praktischen Einschränkungen der typischen Wi-Fi-Signalumgebung konfrontiert, in der die Signalstärke aufgrund von Mehrweg-Interferenzen und anderen Hochfrequenz (HF)-Signalcharakteristika erheblich variieren kann. Bei Anwendungen wie Laptops kann ein Verbraucher einen Laptop einfach an einen anderen Ort mit einem besseren Wi-Fi-Signal bringen. Im Gegensatz dazu muss ein Smart Lock oder ein Haushaltsgerät unabhängig vom Installationsort eine zuverlässige Konnektivität und eine robuste Leistung aufweisen.

Um sowohl eine verlängerte Batterielebensdauer als auch eine robuste Wi-Fi-Signalstärke zu unterstützen, nutzen Entwickler in der Regel alle Vorteile der Energiesparmodi, die in den meisten fortschrittlichen Prozessoren, Radios und anderen komplexen Hardwarekomponenten verfügbar sind. Durch die Maximierung der Zeit, die stromfressende Geräte in ihren jeweiligen Niedrigverbrauchsmodi verbringen, können Entwickler Designs implementieren, die die Batterielebensdauer ihrer Systementwürfe verlängern, in der Regel mit geringen Auswirkungen auf die Systemfunktionalität. Bei diesen Designs könnte ein stromsparender Timer das System periodisch kurz aufwecken, um Sensoren auszulesen und Sensordaten drahtlos zu übertragen, bevor es in den Schlafmodus zurückkehrt.

Bei einigen IoT-Anwendungen muss das IoT-Gerät jedoch eine kontinuierliche Verbindung zum Wi-Fi-Netzwerk aufrechterhalten, um eine schnelle Reaktion auf Benutzerbefehle zu gewährleisten, die über mobile Anwendungen, Desktop-Software oder sogar andere Geräte ausgegeben werden. Beispielsweise müssen intelligente Schlösser, Lampen und Schalter in intelligenten Häusern in Verbindung bleiben, um eine sofortige Reaktion auf Benutzerbefehle zu ermöglichen. Das Warten darauf, dass ein Timer-basiertes Gerät schließlich aufwacht, den Befehl erkennt und schließlich eine Tür aufschließt oder ein Licht einschaltet, wäre für die Benutzer einfach inakzeptabel.

Das DA16200 SoC von Dialog Semiconductor und die zugehörigen Module stellen eine effektive Lösung mit geringem Stromverbrauch dar, die sowohl die Anforderungen an eine kontinuierliche Wi-Fi-Konnektivität als auch an eine verlängerte Batterielebensdauer erfüllt.

Implementierung von Wi-Fi-Konnektivität mit einem drahtlosen SoC

Der DA16200 SoC wurde speziell für batteriebetriebene IoT-Designs entwickelt und kombiniert einen Arm® Cortex®-M4F mit einem kompletten Wi-Fi-Funk-Subsystem, das einen vollständigen Netzwerk-Stack betreibt, wodurch die Notwendigkeit eines externen Netzwerkprozessors oder eines Host-Prozessors für die Stack-Funktionalität entfällt. Zusammen mit dem Funksubsystem integriert das Gerät einen vollständigen Satz von Funktionsblöcken und Schnittstellen, die typischerweise in IoT-Designs benötigt werden (Abbildung 1).

<Abbildung 1: Der Dialog Semiconductor DA16200 SoC bietet eine komplette Wi-Fi-Lösung, die eine kontinuierliche Wi-Fi-Konnektivität bei minimalem Stromverbrauch ermöglicht. (Bildquelle: Dialog Semiconductor)

Neben mehreren Standardschnittstellen enthält der Baustein einen 4-Kanal-Analog-Digital-Wandler (ADC) mit 12-Bit sukzessivem Approximationsregister (SAR) zur Unterstützung der Analogsignalerfassung.

Für die Anwendungsausführung enthält die DA16200 mehrere interne Speicher, darunter

• Nur-Lese-Speicher für einen Bootloader, Systemkern, Netzwerk-Stack und Treiber.
• Statischer Direktzugriffsspeicher (SRAM) für Programmdaten. Der Programmcode wird vor Ort (XIP) auf dem seriellen Flash-Speicher ausgeführt, auf den über die externe serielle Flash-Speicherschnittstelle des Geräts zugegriffen wird.
• Einmalig programmierbarer Speicher (OTP-Speicher) zur Speicherung von Geräteinformationen sowie von Kryptografieschlüsseln und einem sicheren Bootloader. OTP-Daten bleiben sicher, da auf sie nur über den OTP-Controller zugegriffen werden kann und sie ansonsten für den normalen Datenzugriff über den Systembus unsichtbar bleiben.

Um Entwicklern zu helfen, die wachsende Nachfrage nach Sicherheit für angeschlossene Geräte zu erfüllen, integriert der DA16200 SoC eine breite Palette von Sicherheitsmechanismen, einschließlich einer Kryptographie-Engine für Advanced Encryption Standard (AES), Secure Hash Algorithmen (SHA) und andere Verschlüsselungen sowie Unterstützung für das Transport Layer Security (TLS)-Protokoll. Das Gerät enthält auch die Arm TrustZone CryptoCell-312 (CC312) Sicherheits-Intellectual Property (IP). Der CC312 wurde für Geräte mit geringem Stromverbrauch entwickelt, unterstützt einen sicheren Bootvorgang und ermöglicht eine Vertrauensbasis für sichere Anwendungen.

Das Gerät vereinfacht die Wi-Fi-Konnektivität dank eines umfassenden HF-Blocks. Zusammen mit der integrierten 802.11-Medienzugriffskontrolle (MAC) und den physikalischen 802.11b/g/n-Schichten (PHY) umfasst das Funksubsystem einen On-Chip-Transceiver mit integrierten Leistungsverstärkern (PAs) und rauscharmen Verstärkern (LNAs), die externe aktive Komponenten überflüssig machen. Im Betrieb führt der Arm-Cortex-M4F-Prozessor der DA16200 einen eingebetteten TCP/IP-Stack (Transmission Control Protocol/Internet Protocol) aus, um Verbindungsoperationen vom Host-Prozessor eines Systems abzulösen.

Zur Versorgung seiner verschiedenen Blöcke, einschließlich des HF-Blocks, integriert der DA16200 SoC einen DC-DC-Wandler, LDO-Regler (Low Dropout) und Leistungsschalter. Der Konverter und die LDOs werden vom RTC-Block (Real Time Clock) des Geräts verwaltet und erzeugen alle erforderlichen Versorgungsschienen aus einer einzigen VBAT-Batterieversorgung. Während der DC-DC-Wandler aus VBAT 1,4 Volt für den RF-Block und den digitalen LDO erzeugt, erzeugt der I/O-LDO die 1,8 Volt, die für den externen Flash und den General Purpose I/O (GPIO) des Geräts erforderlich sind (Abbildung 2).

Abbildung 2: Die Power-Management-Einheit des DA16200 SoC steuert die integrierten Leistungskomponenten des Geräts und versorgt die einzelnen Leistungsbereiche mit Spannung. (Bildquelle: Dialog Semiconductor)

Die Power-Management-Einheit des DA16200 SoC steuert die Versorgung dieser separaten Leistungsbereiche als Teil ihrer Funktion bei der Verwaltung der drei Low-Power-(Sleep-)Modi des Geräts:

• Sleep 1 bietet mit 0,2 Mikroampere die niedrigste Betriebsleistung (μA): In diesem Modus wird das Gerät weitgehend ausgeschaltet, erwacht jedoch innerhalb von 150 Millisekunden (ms) als Reaktion auf einen externen Trigger, der an die beiden Wake-up-Pins des SoCs oder an einen von mehreren digitalen E/As geliefert wird, oder wenn ein analoges Eingangssignal einen vordefinierten Schwellenwert überschreitet.
• Sleep 2 verbraucht nur 1,8 μA unter Beibehaltung der RTC-Funktionalität: In diesem Modus erwacht das SoC in weniger als 100 ms als Reaktion auf externe Weck-Ereignisse oder nach Ablauf eines programmierten internen Timers.
• Sleep 3 bietet einen einzigartigen, kontinuierlich verbundenen Wi-Fi-Modus, der minimalen Strom verbrauchen kann und bei Erkennung eingehender Wi-Fi-Datenpakete in weniger als 2 ms aufwacht: Wie unten beschrieben, bietet die Verwendung von Sleep 3 mit konventioneller TCP-Keeping-Funktionalität die Grundlage für die Implementierung einer kontinuierlichen Wi-Fi-Konnektivität, die weniger als 50 μA Durchschnittsstrom verbraucht.

Dynamische Energieverwaltungstechnologie ermöglicht kontinuierliche Wi-Fi-Konnektivität

Grundlage dieser energiesparenden Schlafmodi ist die proprietäre Dynamic Power Management (DPM)-Technologie von Dialog Semiconductor, die unbenutzte On-Chip-Mikroelemente abschaltet, was zu einem minimalen Stromverbrauch führt, wenn das Gerät keine Daten sendet oder empfängt. Während des Wi-Fi-Betriebs minimiert DPM den Stromverbrauch während des Sende- und Empfangsfunkbetriebs, indem es fortschrittliche Algorithmen verwendet, um benötigte Mikroelemente genau dann zu wecken, wenn sie benötigt werden.

Das Software Development Kit (SDK) DA16200 von Dialog Semiconductor (SDK) enthält eine Kurzfassung der Details des Power-Managements und des DPM-Betriebs mit seiner Programmierschnittstelle (API) DPM Manager. Für die Entwicklung kundenspezifischer Software bietet das SDK Zugriff auf den DA16200-Software-Stack aus Anwendungs- und Systemdiensten (Abbildung 3).

Abbildung 3: Die Software-Architektur des DA16200 SoC bietet einen vollständigen Satz von System- und Anwendungsdiensten, die zur Unterstützung der Standard-Wi-Fi-Konnektivität in IoT-Geräten erforderlich sind. (Bildquelle: Dialog Semiconductor)

Die Implementierung einer kontinuierlichen Wi-Fi-Konnektivität kombiniert die Verwendung des DPM Managers und der NetX Duo TCP/IP-Bibliothek. Die NetX Duo-Bibliothek bietet eine TCP Keepalive-Funktion, die ein TCP-Paket ohne Daten an einen Wi-Fi-Router sendet und sicherstellt, dass der Router die Wi-Fi-Verbindung aktiv hält. Entwickler rufen diese Funktion einfach auf, indem sie die aktuelle TCP-Socket-Option keepalive_enabled auf true setzen und die Anzahl der Sekunden keepalive_timeout zwischen keepalive-Paketen angeben. NetX Duo überträgt die Keepalive-Frames bei Bedarf automatisch.

Während die Keepalive-Pakete die Netzwerkverbindung mit einem Router oder einem anderen Host aufrechterhalten, beruht die Fähigkeit der DA16200, aus dem Sleep 3-Modus aufzuwachen, auf der Erkennung von Standard-Informationselementen der Traffic Indication Map (TIM) oder Delivery Traffic Indication Map (DTIM), die in 802.11-Management-Frames eingebettet sind, und wird verwendet, um Netzwerkstationen wie ein DA16200-basiertes System darüber zu informieren, dass Netzwerkverkehr für sie verfügbar ist. Wenn das DA16200 in den Modus Sleep 3 versetzt wird, stellt die DPM-Technologie des DA16200 sicher, dass das Funksubsystem bei der Suche nach TIM/DTIM-Elementen nur minimalen Strom verbraucht. Wenn das Funksubsystem DA16200 TIM/DTIM-Elemente erkennt, weckt es das SoC auf und beginnt mit der Verarbeitung des normalen Wi-Fi-Verkehrs, wie jede andere Netzwerkstation auch.

Mit der DA16200 DPM-Manager-API müssen Entwickler nur einige wenige intuitive Aufrufe tätigen, um diese Funktionalität zu implementieren. Nach der Definition der erforderlichen DPM-Konfiguration, einschließlich Parameter und Callbacks, verwenden Entwickler DPM-Manager-API-Funktionsaufrufe, um den DPM-Manager aufzurufen und anderweitig mit ihm zu interagieren. Das Betreten und Verlassen von Schlafplatz 3 wird durch die Technologie des DA16200 DPM transparent gehandhabt.

Die im SDK enthaltenen Anwendungsbeispiele veranschaulichen die grundlegenden Entwurfsmuster, die zur Implementierung dieser Arbeitsfolge erforderlich sind (Listing 1).

Kopieren
#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: Mit dem DA16200 SoC können Entwickler mithilfe von Konfigurationen und einigen DPM-API-Funktionsaufrufen eine kontinuierliche Wi-Fi-Konnektivität implementieren. (Code-Quelle: Dialog Semiconductor)

Wie in Liste 1 gezeigt, implementieren Entwickler diese Fähigkeit weitgehend nur mit einer Initialisierungsfunktion (tcp_client_ka_dpm_sample_init_user_config()), die verschiedene Konfigurationsparameter einschließlich des Keepalive-Intervalls (TCP_CLIENT_KA_DPM_SAMPLE_DEF_KEEPALIVE_TIMEOUT) festlegt, und stellt verschiedene Callbacks zur Verfügung, unter anderem für DMP-Wakeup (tcp_client_ka_dpm_sample_wakeup_callback()) und für die Verarbeitung eingehender Datenpakete (tcp_client_ka_dpm_sample_recv_callback()). Um die TCP Keepalive- und DPM-Wakeup-Sequenz zu beginnen, ruft eine separate Funktion (tcp_client_ka_dpm_sample()) einfach eine Konfigurationsroutine (dpm_mng_regist_config_cb(tcp_client_ka_dpm_sample_init_user_config)) und den DMP-Manager (dpm_mng_start()) auf.

Wie bereits erwähnt, führt diese gesamte Sequenz, einschließlich der Standard-TCP Keepalive-Pakete und der DA16200 DPM-aktivierten Wi-Fi-Überwachung, zu einer kontinuierlichen Wi-Fi-Konnektivität, die in der Regel weniger als 50 % des durchschnittlichen Stroms von μA verbraucht.

Dasselbe Entwurfsmuster kann verwendet werden, um das SoC aus seinen Schlafmodi zu wecken, damit es andere Operationen ausführen kann. Eine Beispielanwendung zeigt zum Beispiel die Verwendung des RTC der DA16200, um das SoC zur Datenverarbeitung zu wecken (Listing 2).

Kopieren
#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: Entwickler können stromsparende Timer-basierte Funktionalität mit der DA16200 implementieren, indem sie einige wenige DPM-API-Funktionsaufrufe verwenden, um einen minimalen Stromverbrauch während der Schlafperioden der DA16200 zu gewährleisten. (Code-Quelle: Dialog Semiconductor)

Wie in Listing 2 dargestellt, ruft der Entwickler eine DPM-Manager-API-Funktion (dpm_timer_create()) auf, um einen Zeitgeber (SAMPLE_RTC_TIMER) und eine weitere DPM-Manager-API-Funktion (dpm_app_sleep_ready_set()) zu erstellen, um anzuzeigen, dass das System bereit ist, wieder in den Ruhezustand zu gehen. Die DPM-Engine bestimmt dann, wie schnell das System auf der Grundlage der aktuellen Aktivität in den energiesparenden Schlafmodus zurückkehren kann. Später, wenn der Timer abläuft, führt das System die Callback-Funktion des Entwicklers, rtc_timer_dpm_periodic_cb(), aus, die die erforderlichen Operationen durchführt - in diesem Fall wird einfach eine Benachrichtigung an die Konsole gedruckt. Wenn der Vorgang abgeschlossen ist, führt dieselbe Callback-Funktion die Funktion dpm_app_sleep_ready_set() aus, um dem DPM-Modul mitzuteilen, dass das System bereit ist, wieder in den Schlafmodus zu gehen. Wie zuvor schließt die DPM-Engine den Übergang in den Schlafmodus ab, wenn dies angebracht ist.

Drop-in-Module vereinfachen Wi-Fi-Design

Während das DA16200 SDK das Software-Design vereinfacht, lässt sich die umfangreiche On-Chip-Funktionalität des Geräts in ein relativ einfaches Hardware-Schnittstellen-Design umsetzen. Unter Verwendung des DA16200 SoC zusammen mit einem externen Flash-Baustein, wie z.B. Winbond Electronics' W25Q16JVSNIQ 16 Megabit (Mbit) NOR-Speicher-IC und nur wenigen zusätzlichen Komponenten, können Entwickler ein Wi-Fi-aktiviertes sicheres IoT-Design implementieren (Abbildung 4).

Abbildung 4: Mit seiner umfangreichen integrierten Funktionalität benötigt der Dialog Semiconductor DA16200 SoC nur einen externen seriellen Flash und minimale zusätzliche Komponenten, um ein komplettes Wi-Fi-System zu implementieren. (Bildquelle: Dialog Semiconductor)

Entwickler, die die Entwicklung ihrer eigenen Designs auf der Basis des DA16200 SoC beschleunigen möchten, können sich an Dialog Semiconductor-Module wenden, bei denen sie die Hardwareschnittstelle des SoC nicht mehr implementieren müssen. Zusammen mit dem DA16200 SoC enthalten die Module 4 Megabyte (Mbytes) Flash, HF-Komponenten und wahlweise eine On-Board-Chip-Antenne (DA16200MOD-AAC4WA32) oder einen u.FL-Anschluss für eine externe Antenne (DA16200MOD-AAE4WA32). Die 13,8 x 22,1 x 3,3 Millimeter (mm) großen, von der FCC, IC, CE und anderen Regulierungsbehörden vollständig zertifizierten Module stellen eine Drop-in-Hardware-Lösung zur Implementierung einer kontinuierlichen Wi-Fi-Konnektivität mit geringem Stromverbrauch dar.

Entwickler, die eine kontinuierliche Wi-Fi-Konnektivität und schnelle Prototypen von IoT-Designs auf der Basis des DA16200 SoC erforschen möchten, können sofort die Vorteile des Dialog Semiconductor DA16200MOD-DEVKT Entwicklungskits nutzen. Dieses Kit kombiniert ein DA16200MOD-Modul mit einer USB-Schnittstelle, Schlüsseln und Anschlüssen, um die Entwicklung und das Debugging von DA16200-basierten Designs zu beschleunigen.

Fazit:

Die Fähigkeit, eine kontinuierliche Wi-Fi-Konnektivität aufrechtzuerhalten, ist ein Routinemerkmal von Laptops und anderen angeschlossenen Produkten. Bei Wearables und anderen batteriebetriebenen IoT-Geräten haben jedoch die Leistungsanforderungen herkömmlicher Wi-Fi-Lösungen eine kontinuierliche Wi-Fi-Konnektivität unpraktisch gemacht, so dass Entwickler in der Regel Kompromisse bei der Funktionalität, Leistung oder Batterielebensdauer der Geräte eingehen müssen.

Ein SoC von Dialog Semiconductor bietet eine komplette Wi-Fi-Lösung, die eine kontinuierliche Wi-Fi-Konnektivität bei minimalem Stromverbrauch ermöglicht. Wie gezeigt, können Entwickler mit dem SoC oder den zugehörigen Modulen schnell sichere batteriebetriebene Geräte implementieren, die den Anwendern die Vorteile einer kontinuierlichen Wi-Fi-Konnektivität bieten und gleichzeitig ihre Erwartungen an eine längere Batterielebensdauer erfüllen.