Die Wahl des BLE-Hosts für ein batteriebetriebenes Gerät hängt am Ende von Schlafstrom und Stack-Footprint ab, und diese Entscheidung fällt weit bevor irgendein Punkt auf der BLE-5-Featureliste eine Rolle spielt. Zwei Bauelemente, die dieselbe Funkversionsnummer tragen, können sich um eine Größenordnung darin unterscheiden, was sie zwischen Verbindungsereignissen verbrauchen, und genau diese Differenz entscheidet über die Batterielaufzeit.

Der Host ist der einzelne Chip, der sowohl den Funk als auch die Applikation ausführt; seine Auswahl zieht den Protokoll-Stack mit, der im Flash untergebracht werden muss, den RAM, der im Schlaf unter Spannung bleibt, und den Zertifizierungsweg, den der Hersteller anbietet. Ein Münzzellenensor und ein aufladbares Wearable nähern sich dieser Liste von entgegengesetzten Enden, und das Teil, das für das eine passt, taugt selten für das andere. Aktualisierungsanforderungen und Stückkosten ziehen die Entscheidung ebenso stark wie jede Funkspezifikation.

Wann BLE das richtige Funkverfahren ist

BLE ist die Standardwahl für ein batteriebetriebenes Gerät, das kurze, seltene Daten an ein Telefon oder ein nahes Gateway sendet, und das Argument dafür beruht eher auf dem Verbindungsmodell als auf roher Reichweite oder Geschwindigkeit. Das Funkmodul schläft zwischen kurzen Verbindungsereignissen, wacht nach einem Zeitplan auf, den die Gegenstelle mitbestimmt, und verbraucht nahezu nichts, wenn nichts zu übertragen ist. Wenn ein Design stattdessen ein Firmware-Image in Minuten übertragen oder ohne Hops quer durch ein Gebäude reichen muss, verdient die Frage, ob BLE überhaupt das richtige Funkverfahren ist, eine ehrliche Antwort, bevor irgendeine SoC-Vorauswahl entsteht. Für die breite Klasse von Sensoren und Tags, die kurz aufwachen, einen kleinen Zustand übermitteln und dann wieder schlafen, gewinnt BLE beim Energieaufwand pro übertragenem Byte, und genau diese Zahl zahlt ein Batteriegerät letztlich.

Was einen BLE-SoC vom anderen unterscheidet

Hinter der Featureliste steckt ein kurzer Satz von Zahlen, der einen BLE-SoC für ein batteriebetriebenes Design entscheidet. Diese Zahlen stehen im Datenblatt, nicht in der Broschüre, und wer sie in der richtigen Reihenfolge liest, vermeidet ein Redesign, das eine späte Strommessung sonst erzwingen würde.

Die erste Zahl ist der Schlafstrom bei gehaltenem RAM und laufendem Timer, denn dieser Strom fließt nahezu während der gesamten Lebensdauer eines Geräts, das nur wenige Millisekunden am Stück aktiv ist. Bauelemente dieser Klasse liegen in diesem Zustand irgendwo zwischen einigen hundert Nanoampere und mehreren Mikroampere, und die Streuung lässt sich darauf zurückführen, wie viel RAM unter Spannung bleibt und wie der Niederfrequenztakt erzeugt wird. Die zweite Zahl ist der Speicherbedarf des Protokoll-Stacks: Ein BLE-Stack mit Host belegt zig Kilobyte Flash und einen RAM-Block, der im Schlaf aktiv bleiben muss; ein Teil mit 256 kB Flash und einer peripheral-lastigen Applikation kann auf eine Weise knapp werden, die die Funkspezifikation nie andeutet. Die dritte Zahl ist der Funkstrom beim Senden und Empfangen, der die Energie jedes Verbindungsereignisses bestimmt; ein Teil, das sich im Schlaf glänzend verhält, aber 15 Milliampere beim Empfang zieht, kann gegen ein Teil verlieren, das etwas höher im Schlaf liegt, aber beim Empfang die Hälfte davon aufnimmt. Die Arithmetik, die diese Größen verbindet, ist kurz: Bei einem Ein-Sekunden-Verbindungsintervall wacht das Funkmodul etwa einmal pro Sekunde auf, jedes Aufwachen verbraucht eine feste in Mikroamperestunden gemessene Ladung, und der mittlere Strom ist der Schlafwert plus diese Ladung multipliziert mit der Aufwachrate. Verlängert man das Intervall, schrumpft der Ereignisanteil, während der Schlafanteil bleibt, wo er ist; darum ist eine langsamere Aktualisierung meist die günstigste Stromeinsparung in einem BLE-Design, und darum setzt der Schlafwert eine Untergrenze, die keine Verbindungseinstellung unterschreiten kann. Ein Mainstream-Design, das einen bewährten Stack und eine große Beispielsammlung sucht, beginnt oft mit einem Mittelklasse-Host wie dem nRF52832, während ein Design auf der Jagd nach der längsten Münzzellenlebensdauer neuere, stromsparende Teile wie das auf Batterielaufzeit ausgelegte EFR32BG22 in Betracht zieht. Der Takt trägt mehr bei, als er aussieht: Ein Teil, das seinen Schlaf-Timer von einem kostengünstigen 32-kHz-Quarz oder von einem internen RC-Oszillator betreibt, der gegen den Haupttakt abgeglichen wird, spart sowohl den Strom als auch den Platz eines Präzisionsbauteils, allerdings auf Kosten der Taktgenauigkeit, was sich als breiteres Empfangsfenster niederschlägt.

Zwei weitere Zahlen begleiten die Leistungswerte. Empfindlichkeit und Ausgangsleistung bestimmen das Linkbudget, und einige dB Empfindlichkeitsgewinn erkaufen Reichweite zurück, die ein Design sonst durch höheren Sendestrom oder eine größere Antenne bezahlen müsste; die Differenz zwischen einem Teil nahe minus 96 und einem nahe minus 103 dBm kann entscheiden, ob eine Funkverbindung über eine offene Fläche hält oder im hintersten Raum abbricht. Der Firmware-Update-Pfad belegt Speicher, den man leicht vergisst: Ein Gerät, das ein Over-the-Air-Update empfängt, benötigt in der Regel Platz für eine zweite Image-Bank oder einen externen Flash-Chip, und diese Anforderung kann den Flash-Bedarf eines Designs über das hinausschieben, was das günstigste Teil einer Familie bietet.

Eine Frage formt die Vorauswahl um, bevor überhaupt Teile verglichen werden: ob das Funkmodul neben BLE noch etwas anderes sprechen muss. Ein Gerät, das sich auch in ein Thread- oder Matter-Mesh eingliedern muss, benötigt ein Multiprotokoll-Teil, und allein diese Anforderung räumt die Single-Mode-Angebote vom Tisch. Ein Teil, das BLE für die Inbetriebnahme und Thread für den laufenden Betrieb verwenden muss, muss außerdem ein Funkmodul zwischen beiden zeitlich aufteilen, sodass Stack und Silizium diesen Wechsel sauber unterstützen müssen, anstatt ihn nachträglich anzuflicken. Wenn BLE das einzige Funkverfahren ist, das das Produkt jemals einsetzen wird, kommen die günstigeren Single-Mode-Teile wieder ins Spiel.

Wo die Familien stehen

Nordics nRF52-Linie ist der Ausgangspunkt vieler BLE-Designs, begünstigt durch einen Stack und eine Toolchain, die viele Ingenieure bereits von einem früheren Produkt kennen. An der Spitze steht der nRF52840 mit seinem Multiprotokoll-Funk, nativem USB und dem größeren Flash, den ein OTA-fähiges oder Thread-fähiges Produkt typischerweise benötigt. Er trägt einen Cortex-M4F mit einem Megabyte Flash und einem Viertel Megabyte RAM, was dem Platzbedarf dieser Funktionen entspricht, und unterstützt sie mit Hardware-Kryptographie, auf die ein Secure Boot oder eine verschlüsselte Verbindung angewiesen ist. Das Teil kostet mehr als das Mainstream-Mitglied der Familie und zieht im Aktivmodus etwas mehr, sodass es seinen Platz verdient, wenn der zusätzliche Speicher oder das zweite Protokoll eine echte Anforderung und kein Vielleicht ist.

Wenn Sicherheit und ein sauberer Update-Pfad Gewicht haben, teilt der nRF5340 Applikation und Netzwerk auf separate Kerne auf, was den Radio-Stack isoliert vom Applikationscode hält und es erschwert, einen kompromittierten App-Kern in einen kompromittierten Funkkern zu verwandeln. Der Applikationskern kann hochgetaktet werden, wenn er Arbeit hat, und im Leerlauf niedrig bleiben, wenn nicht, während der Netzwerkkern das Funk-Timing eigenständig hält, sodass beide Aufgaben nicht mehr um ein gemeinsames Budget konkurrieren. Die Aufteilung fügt Build- und Debug-Komplexität hinzu, die ein einfaches Beacon nie braucht; sie lohnt sich bei Produkten, deren Firmware über Jahre wachsen und in einem Netzwerk sitzen wird, das jemand aktiv sondiert.

Am anderen Ende der Linie bestimmt der Preis die Bedingungen. Der DA14531 reduziert einen BLE-Knoten auf wenige Cent Silizium in einem Gehäuse, das klein genug ist, um unter einem Knopf zu verschwinden, mit einem bescheidenen Speicherblock, der eine Verbindung und kaum mehr hält, was für ein Einwegetikett oder eine auf den Cent kalkulierte Einzelfunktionsfernbedienung genau der Punkt ist. Der TLSR8258 hält an niedrigen Kosten fest und bietet gleichzeitig einen Multiprotokoll-Funk, eine Kombination, die in der Beleuchtung und anderen hochvolumigen vernetzten Geräten auftaucht, wo ein paar Cent eine Million Mal wiederholt die gesamte Marge ausmachen und dasselbe Teil per BLE mit einem Telefon und per Mesh-Protokoll mit seinen Nachbarn sprechen muss. Keines dieser Teile lässt viel Spielraum, sodass die Applikation schlank bleiben muss; ein Entwickler, der den Platz eines Mainstream-Hosts gewohnt ist, lernt schnell, die Linker-Map vom ersten Build an im Auge zu behalten. Das Argument für diese Teile ist der Preis, und sie erreichen ihn, indem sie auf Flash und die komfortable Reserve verzichten, die ein größerer Host mitbringt.

Texas Instruments beantwortet dieselbe Batteriefrage mit dem CC2640R2F und seiner stromsparenden BLE-Konnektivität, indem ein Cortex-M3 mit einem separaten Sensor-Controller kombiniert wird, der Eingaben abtasten und überwachen kann, während der Hauptkern schläft. Dieser zweite Kern ermöglicht es einem Sensorknoten, Messwerte nach einem Zeitplan zu erfassen und die Applikation nur dann zu wecken, wenn etwas einen Schwellenwert überschreitet, was den mittleren Strom bei genau der Art von Arbeitslast reduziert, die sonst einen vollen Kern fast untätig wach halten würde. Das Teil landet tendenziell in Designs, die bereits im TI-Ökosystem verankert sind, wo Toolchain und restliche Stückliste in dieselbe Richtung ziehen.

Nebeneinander sortieren sich diese Teile weniger nach ihrem Funk als nach dem Speicher und dem Protokollmix drum herum.

Modul oder nackter SoC

Ein nackter SoC bietet die niedrigsten Stückkosten und die engste Kontrolle über die Leiterplatte, zum Preis des HF-Abschnitt-Designs und der Zulassungsprüfung des Funkteils. Ein Modul übergibt beide Aufgaben an seinen Hersteller gegen höhere Stückkosten, und die Wahl zwischen beiden hängt von der Stückzahl und davon ab, wie viel Funkerfahrung das Team aufbieten kann. Ein Team, das schon einige Antennen zur Reife gebracht hat, kann die Einsparung mitnehmen; eines, das das noch nicht hat, kann seinen ersten Abstimmversuch damit verbringen zu lernen, warum die Reichweite hinter den Erwartungen zurückblieb.

Für eine Kleinserie oder ein erstes Produkt nimmt ein vorzertifiziertes Modul wie das BGM220P dem Team das Antennendesign und den Großteil der Zertifizierungsarbeit ab, weil das Modul mit bereits erteilten Funkzulassungen geliefert wird. Die Zulassungen sind mehr als ein einzelner Stempel: Ein fertig entwickeltes Funkgerät muss regionale Regulierungsgrenzen erfüllen, FCC in einem Markt und CE in einem anderen, und ein Bluetooth-Produkt benötigt außerdem eine Qualifizierung bei der Bluetooth SIG, bevor es das Logo tragen und ausgeliefert werden darf. Ein vorzertifiziertes Modul kommt mit einer modularen behördlichen Genehmigung und einem bereits hinterlegten qualifizierten Design, sodass was verbleibt, überwiegend Papierkram ist, der diese Zulassungen erbt, anstatt eine neue Testkampagne, die sich über Wochen hinziehen kann.

Wenn das Volumen steigt, überwiegt der Stückkosten-Aufschlag eines Moduls den Engineering-Aufwand, den es einst einsparte, und ein Produkt, das auf einem Modul startete, wechselt für seine zweite Generation oft zu einem nackten SoC. Dieselbe Logik gilt umgekehrt für ein Nischenprodukt, das diese Stückzahlen nie erreichen wird, wo ein Modul für die gesamte Produktlebensdauer die günstigere Antwort bleibt, weil sich der Engineering-Aufwand für den Wechsel nie amortisiert. Die Host-Entscheidung ist selten dauerhaft, und sie spiegelt wider, wo ein Produkt in seinem Lebenszyklus steht, fast ebenso genau wie sie widerspiegelt, was das Funkmodul leisten kann.