Energy Harvesting Funkschalter ohne Batterie implementieren

Funkschalter sind in vernetzten Gebäuden eine feine Sache. Allerdings mussten die Batterien in regelmäßigen Abständen getauscht werden. Das ist nicht gerade kosteneffizient. Doch neuartige Funkschalter stellen allein durch das Betätigen genug Energie zur Verfügung, um ein Datenpaket abzusetzen.

Keine Kabel verlegen, den Schalter jederzeit beliebig positionieren oder sogar mitnehmen – das sind nur einige der Vorteile, die Funkschalter bieten. Wäre da nicht das leidige Thema der Stromversorgung.

Die derzeit verbreiteten Funkschalter nutzen dafür Batterien, was die Kosten und die Komplexität erhöht und die Benutzer mit dem Austausch der Batterien belastet.
Dieser Artikel beschreibt ein Referenzdesign für Funkschalter mit induktivem Energy-Harvesting. Das Entwicklungskit BLE-SWITCH001-GEVB von ON Semiconductor verbindet das Bluetooth-5.0-Modul RSL10 des Unternehmens mit einem mechanischen Schalter AFIG-0007 von ZF Electronics, der aus dem Schaltvorgang Energie ernten kann. Diese reicht, um einen bluetooth-fähigen Hub oder ein anderes Produkt per Funk anzusteuern. Dies bietet Entwicklern eine bereits fertige, wartungsfreie Lösung für einen Funkschalter und kann auch als Grundlage für eigene Designs dienen.

Aufbau des Bluetooth-Moduls

Im RSL10 sind mehrere Funktionsblöcke integriert, die eine vollständige Bluetooth-5-Lösung bieten (Bild 1). Zur Datenverarbeitung verfügt es über einen Mikrocontroller vom Typ Arm Cortex-M3 für allgemeine Zwecke sowie den 32-Bit-DSP LPDSP32 von ON Semiconductor für spezielle Anwendungen. Das Modul unterstützt diese Prozessoren durch mehrere Peripherie- und Speicherkomponenten: 384 KB Flash-, 76 KB Programm- und 88 KB Datenspeicher. Für die Bluetooth-Kommunikation nutzt das Modul ein 2,4-GHz-HF-Frontend, das die physische Bluetooth-Schicht (PHY) und einen Basisband-Controller umfasst, der die erweiterten Bluetooth-5.0-Protokolle unterstützt. Ausgelegt für Eingangsspannungen zwischen 1,1 V und 3,3 V, erzielt das RSL10 nach dem ULPMark des EEMB Consortium einen Benchmark-Wert 1090 bei einer Versorgungsspannung von 3 V bzw. einen Wert von 1360 bei 2,1 V.

Bei vielen drahtlos vernetzten Anwendungen geht der Energiebedarf, der für wiederholte Funktransaktionen erforderlich ist, jedoch an die Grenzen jedes noch so energieeffizienten Designs. Das Referenzdesign von ON Semiconductor ist auf die sehr kurzen Transaktionen spezialisiert, die mit den Bluetooth-Beacon-Protokollen möglich sind.

Beacons sind kurze Nachrichten nach den Bluetooth-Advertising-Protokollen für den Broadcast einer Bezeichnung oder anderer kurzer Daten für beliebige verfügbare Listener. Zusammen mit speziellen Mobil-Apps sind Beacons mittlerweile in den Bereichen Handel, Unterhaltung, Verkehr und in anderen öffentlichen Bereichen weit verbreitet, in denen sie Informationen zum Standort von Benutzern liefern könnten.

Das Modul von ON Semiconductor nutzt einen speziellen Typ, das sogenannte Eddystone-Beacon. Dieses entspricht einem offenen Standard, der die Hülle und die Nutzdaten von nur wenigen Byte großen Paketen festlegt.

Das Format der Nutzdaten von Eddystone-Beacons kann eine eindeutige ID (UUID), eine URL oder unterschiedliche Typen von Telemetriedaten (TLM), zum Beispiel Temperatur, umfassen (Bild 2). Trifft ein Eddystone-Beacon ein, kann die empfangende App Aktionen bezüglich der UUID durchführen, den Benutzer an die URL weiterleiten oder auf die Telemetriedaten reagieren.

Stromversorgung durch Energy-Harvesting

Eine Übertragung eines Eddystone-Beacons kann nur 10 ms dauern, und das RSL10 benötigt dafür eine Energie von etwa 100 mJ. Dies liegt durchaus im Bereich dessen, was der AFIG-0007 von ZF liefern kann. In diesem befindet sich ein von einer Spule umgebener Eisenkern, der Kontakt zu einem Magnetblock hat (Bild 3, links). Drückt der Benutzer auf den gefederten Betätiger, verschiebt sich der Magnetblock (Bild 3, rechts). Dadurch kehrt sich die Polarität des Magnetfelds der Spule um, was nach dem Prinzip der magnetischen Induktion einen elektrischen Energieimpuls auslöst. Wird der Betätiger losgelassen, springt der Magnetblock in seine ursprüngliche Position zurück und löst so einen weiteren Energieimpuls mit entgegengesetzter Polung aus.

Mit einer Lebensdauer von 1 Million Schaltzyklen erfüllt das 20 mm x 7 mm x 15 mm große Bauteil von ZF die wesentlichen mechanischen, physischen und energiebezogenen Anforderungen an einen Funkschalter. Bei jedem Aktivierungszyklus (Drücken und Loslassen) stellt es ca. 300 mJ zur Verfügung, sodass das RSL10 zwei Eddystone-Beacons übertragen kann.

Typischerweise benötigen Energy-Harvesting-Schaltungen eine Kombination von Spannungswandlern und Spulen, um die generierten Spannungen auf einen Pegel zu bringen, den ein Mikrocontroller benötigt. In diesem Falle vereinfacht der Eingangsspannungsbereich des RSL10 von 1,1 V bis 3,3 V dies. Der Ausgang des AFIG-007 wird durch den Schottky-Vollbrückengleichrichter NSR1030 gleichgerichtet und mit einer einfachen Schaltung bestehend aus einer Zener-Diode SZMM3Z6V2ST1G (D3), einem Filter- und Speicherkondensator (C1) und einem LDO-Regler NCP170 (alle von ON Semiconductor) begrenzt (Bild 4).

Im Kit BLE-SWITCH001-GEVB ist ein AFIG-007 und die obige Versorgungsschaltung mit dem RSL10 auf einer 23 mm x 23 mm großen Platine montiert (Bild 5). Während sich die zentralen Komponenten im 7 mm breiten mittleren Bereich befinden, liegen in den abnehmbaren Seitenteilen die Entwicklungsschnittstellen, darunter eine 10-Pin-JTAG/SWD-Schnittstelle für einen Standardadapter wie den TC2050-IDC von Tag-Connect. Neben der 10-Pin-Schnittstelle befinden sich auf den Seitenteilen Steckleisten für einen Jumper und eine externe 3,3-V-Stromquelle (Vout) zum Programmieren und Debuggen mit einem angeschlossenen JTAG-Programmer, zum Beispiel dem 8.16.28 J-LINK ULTRA+ von Segger Microcontroller Systems.

Entwicklung des Funkschalters

Auf dem BLE-SWITCH001-GEVB ist Firmware vorinstalliert, die so lange alle 20 ms ein Eddystone-Beacon überträgt, bis die Energie aus einer Aktivierung des Schalters aufgebraucht ist. In dieser Beispielsanwendung wird zuerst ein Eddystone-URL-Frame mit der URL https://onsemi.com/idk übertragen. Auf den Einleitungs-Frame folgen Eddystone-TLM-Frames mit Telemetriedaten, die die Versorgungsspannung des Schalters, die Uptime-Dauer und die Gesamtzahl der bisher übermittelten Pakete enthalten.

Die Eddystone-Beispielssoftware ver-anschaulicht die grundlegenden Entwick-lungsmuster für den Aufbau und die Übermittlung der Frames (Listing 1). Wie in dem Listing gezeigt, lädt die Funktion EddyService_Env_Initialize() eine Eddystone-Umgebungsstruktur eddy_env_tag mit den Nutzdaten für ein Eddystone-URL-Frame. Diese baut das Paket auf, verschlüsselt die Daten mithilfe der AES-Beschleunigers des RSL10 und stellt die Nachricht dann mit ke_msg_send() in eine Warteschlange, um übertragen zu werden. Auf unteren Verarbeitungsschichten werden die in der Warteschlange stehenden Nachrichten dann abgerufen, verpackt und übertragen.

Die übertragenen Beacons kann jeder innerhalb der Sendereichweite befindliche BLE-fähige Host erkennen oder ein in der Nähe befindliche Mobilgerät mithilfe einer Beacon-App wie der RSL10-Mobile-App anzeigen. Um mit dem drahtlosen Schalter Geräte zu steuern, lassen sich die Beacons mithilfe des RSL10-basierten BLE-IoT-Entwicklungskits BDK-GEVK von ON Semiconductor verarbeiten und weitere Aktionen durchführen. Zum Beispiel lässt sich eine Lichtsteuerung mit einem drahtlosen Schalter über eine Kombination der Basisplatine BDK-GEVK und der Zweifach-Treiberplatine für LEDs mit Vorschaltgerät D-LED-B-GEVK implementieren.

Um eine Motoransteuerung zu entwickeln, kann die Basisplatine mit der Treiberplatine für bürstenlose Gleichstrommotoren BLDC-GEVK oder mit der Treiberplatine für Schrittmotoren D-STPR-GEVK kombiniert werden.

Am Ende können die Seitenteile einfach abgenommen werden, sodass nur eine 7 mm x 23 mm große Baugruppe mit den funktionalen Komponenten übrig bleibt (Bild 6). Da sich der Betätiger von ZF im hinteren Teil der Baugruppe befindet, lässt er sich unter einem Wippschalter mit Leergehäuse wie dem GIL-2000-2010 von CW Industries anbringen.

Listing 1

struct eddy_env_tag eddy_env;

void EddyService_Env_Initialize(void) {
         /* Reset the application manager environment */
         memset(&eddy_env, 0, sizeof(eddy_env));
         .
         .
         .
         memcpy(eddy_env.advslotdata_value, (uint8_t[16] ) { 0x10, 0x03, ‚o‘, ‚n‘,

‚s‘, ‚e‘, ‚m‘, ‚i‘, ‚.‘, ‚c‘, ‚o‘, ‚m‘, ‚/‘, ‚i‘, ‚d‘, ‚k‘ }, eddy_env.advslotdata_length);

         eddy_env.advtxpower_value = OUTPUT_POWER_DBM; /* Set radio output power of RF */

Eddy_GATTC_WriteReqInd(…)
              .
              .
              .
              valptr = (uint8_t *) &eddy_env.advtxpower_value;
              .
              .
              .
              /* Enable and configure the base band block */
              BBIF->CTRL = BB_CLK_ENABLE | BBCLK_DIVIDER_8 | BB_WAKEUP;
              /* Copy in the exchange memory */
              uint8_t plain_text[16];
              for (int i = 0; i<=15;i++)
                            plain_text[i] = eddy_env.challenge_value[15-i];
              memcpy((void *) (EM_BLE_ENC_PLAIN_OFFSET + EM_BASE_ADDR), plain_text, 16);
          /* Configure the AES-128 engine for ciphering with the key and the memory
          * zone */
           uint8_t encryptionkey[16];
           for (int i = 0; i<=15;i++)
                            encryptionkey[i] = eddy_env.lockstate_value[16-i];
           Sys_AES_Config((void *) encryptionkey, EM_BLE_ENC_PLAIN_OFFSET);
            /* Run AES-128 encryption block */
           Sys_AES_Cipher();
           /* Access to the cipher-text at EM_BLE_ENC_CIPHER_OFFSET address */
           uint8_t encryptedtext_temp[16];
         memcpy(&encryptedtext_temp[0], (void *) (EM_BLE_ENC_CIPHER_OFFSET + EM_BASE_ADDR), 16);
               uint8_t encryptedtext[16];
               for (int i = 0; i<=15;i++)
                               encryptedtext[i] = encryptedtext_temp[15-i];
              if (!memcmp(encryptedtext, eddy_env.unlocktoken_value, 16))
              .
              .
              .
ke_msg_send(…)