BlHeli Telemetry Feeder

BTF - BLHeli Telemetry Feeder, ein Telemetrie Protokollwandler für BLHeli_32, AM32

BLHeli Telemetrie ohne Flugcontroller! `>aktualisiert 15.03.26<`

BLHeli_32 ESCs sind sehr häufig telemetriefähig, das heißt sie können Daten, wie die Spannung des Flugakkus, Strom, entladene Kapazität, Motordrehzahl und Temperatur (des Hauptprozessors) ausgeben. Alle diese Daten werden im ESC selber gemessen. Da BLHeli aus der Multicopter-Welt kommt, übernimmt üblicherweise der obligatorische Flugcontroller die Anforderung und Weitergabe an einen telemetriefähigen RC Empfänger. Ab der Firmwareversion 32.6 können wir BLHeli_32 so konfigurieren, dass die Telemetriedaten permanent gesendet werden. Aber Achtung: Nicht jeder BLHeli_32 ESC kann Telemetrie oder er kann keinen Strom/Kapazität messen.

Seit Ende 2024 wird BLHeli_32 wird nicht mehr weiterentwickelt und es werden keine weiteren Lizenzen an die Hersteller verteilt. Es wird also nur noch abverkauft, was bereits bei den Herstellern ist. Die tröstliche Nachricht: Es gibt schon würdige Nachfolger. Die heißen AM32 und ESCape32. Beide können Telemetriedaten im selben Format ausgeben, wie BLHeli_32 (BLHeli_32 hat genau genommen das schon für KISS-ESCs verwendete Protokoll verwendet). ESCape32 ist ein Sonderfall, weil diese Firmware Telemetriedaten nicht nur im KISS-Format ausgeben kann, sondern auch direkt als FrSky S.Port und FlySky iBus. Der BTF ist in diesem Fall überflüssig.

Das von mir vorgestellte Windows-Programm BLHeliTelemetryView kann ebenfalls KISS-Telemetrie lesen und mittels eines USB-UART Wandlers auf einem Windows-PC anzeigen und speichern. Das geht mit ESCs, auf denen die Firmware BLHeli_32, AM32 oder ESCape32 läuft.

Eigentlich wollen wir die Daten aber auf unserem Fernsteuersender sehen! Um die Daten auf dem Senderdisplay bewundern zu können, müssen diese in das Telemetrieformat des jeweiligen Herstellers übersetzt werden. Genau das kann der BLHeli-Telemetry-Feeder (BTF). Aktuell kann der BTF drei Protokolle ausgeben:

FrSky D8 Hub (nur BTF aus den Jahr 2019)
FrSky S.Port
FlySky iBus Telemetry

Seit Firmwareversion 32.8 kann BLHeli_32 S.Port Telemetrie direkt ausgeben. Der BTF ist damit für FrSky Empfänger mit S.Port Schnittstelle überflüssig. Allerdings kann das nicht jeder ESC; falls ja, zeigt die BLHeliSuite32 den Eintrag "S.PORT Physical ID" im Setup an. Für ESCs, die keine S.Port Telemetrie erzeugen können und für die anderen Protokolle bleibt BTF aber weiterhin interessant.

Die Arbeit erledigt ein Mikrocontroller, der mit der BTF-Firmware geladen werden muss. Der gesamte Hardware-Aufwand beschränkt sich im Minimalfall auf zwei Bauteile, dem Mikrocontroller und einen Kondensator. Die Firmware ist lauffähig auf:

AtTiny13 (abgespeckte Version; nur für D8 Hub)
AtTiny45
AtTiny85 oder Digispark-Board
Arduino auf Basis des AtMega168p (Nano, Mini Pro) - Typ 5V 16 MHz
Arduino auf Basis des AtMega328p (Uno, Nano, Pro Mini) - Typ 5V 16MHz
Arduino kompatibles Board auf Basis eines LGT8F328P - Typ 5V oder 3,3V

BTF gibt die Daten nicht nur weiter, sondern versucht auch die originalen Sensoren zu emulieren und bildet einen Mittelwert der Messwerte, BLHeli Telemetrie überträgt pro Sekunde ca. 30 Datensätze mit den 5 Messwerten. Das ist zu viel für unser Auge (und den angeschlossenen Hauptrechner). BTF bildet aus jeweils 7 Werten einen Mittelwert (je nach Protokoll) mit dem Ziel, etwa alle 0,25 Sekunden einen aktualisierten Messwert präsentieren zu können.

Wer ähnliches mit weniger Bastelaufwand und ohne spezielle Programmiergeräte bauen möchte, dem sei openXsensor_on_RP2040 (wird leider nicht mehr weiterentwickelt) oder MSRC-Multi Sensor Telemetry for RC (RP2040) empfohlen. Beide Programme können diverse Sensoren (u.A. verschiedene ESC-Telemetrieformate) auslesen und in verschiedenen Formaten an Rc-Empfänger ausgeben. Den verwendeten RP2040 gibt es sehr günstig auf fertigen Platinen zu kaufen. Die Firmware wird einfach auf ein virtuelles Laufwerk kopiert. Unbedingt ansehen.

Den ESC konfigurieren

Wir müssen davon ausgehen, dass unser ESC im Auslieferungszustand nicht so eingestellt ist, dass er uns die Telemetriedaten automatisch liefert. Sie müssen mittels des jeweiligen Konfiguratonsprogramms wie folgt eingestellt werden:

BLHeli_32:

Zwei softwaremäßige Voraussetzungen müssen gewährleistet sein:

Firmware größer als Version 32.5
In der Konfiguration muss "Auto Telemetry" auf "ON" eingestellt sein.

Beides können wir mit dem Programm BLHeliSuite32 erledigen. Außerdem brauchen wir ein Interface. Das kann ein günstiger Arduino sei, der von der BLHeliSuite32 zum passenden Interface geflasht wird. Jedenfalls ist das ein Thema für sich. Wer das machen möchte, sollte sich die zahlreichen Tutorials im Netz und auf YouTube dazu reinziehen.
BLHeli auf Github: https://github.com/bitdump/BLHeli
BlHeliSuite32 zum Download: https://github.com/bitdump/BLHeli/releases/tag/Rev32.10

AM32:

Für AM32 gibt es mehrere Konfigurationsprogramme. Der Online Configurator hat bei mir bisher keine Verbindung zu einem einzelnen ESC zustande gebracht. Mit dem "Multi ESC Config Tool" klappt es aber zuverlässig. Wichtig ist, Direct Connect zu wählen. Andernfalls wird vermutlich ein Flightcontroller erwartet.
Ist die Verbindung hergestellt, müssen wir 30ms Telemetry auswählen: AM32-Configtool2

Link zu AM32: am32.ca

ESCape32:

Wie bereits geschrieben, kann ESCape32 IBUS (FlySky) und S.Port (FrSky) Telemetrieprotokolle direkt ausgeben. Wir brauchen bei geeigneten Empfängern dieser Marken kein Zwischengerät und der hier vorgestellte BTF ist überflüssig. Einzige Ausnahme: BTF kann das D8-Hub Protokoll von alten FrSky Empfängern ausgeben. In diesem Fall wäre der ESC wie folgt zu konfigurieren.

Für ESCape32 gibt es mehrere Möglichkeiten zum Konfigurieren der Firmware. Am komfortabelsten geht es per Wlan (=Wifi) mit dem "ESCape32-Wifi-Link". Hier stellen wir "KISS-auto" als Telemetrie Modus ein.

Link zu ESCape32: https://github.com/neoxic

Hardware bauen

Möglichkeit 1: AtTiny45 oder AtTiny85 - hier mit Schutzwiderständen in den Datenleitungen und Staus-LED:

Schaltbild

und

Realität

Widerstände und LED sind optional - es geht auch minimalistisch:
BTF-Minimal_front

Möglichkeit 2: Ein Digispark ist ein AtTiny85 mit USB-Bootloader fertig auf einem Board:

Der reale Digispark ist abweichend zum Schemabild einer mit Mikro-USB-Anschluss. Ich habe auf der Rückseite einen Anschluss für ein normales Servo-Verlängerungskabel angelötet. Der freie Pin an 5V hat keine Funktion, er dient lediglich zum mechanischen Fixieren des BLHeli-Daten Pins.
BTF-Digispark

Möglichkeit 3: Arduinos auf Basis des AtMega328p, AtMega168p sind auch geeignet. Es müssen aber 16MHz-Typen sein mit 5V Eingangsspannung.
Auch Boards auf Basis des LGT8F328P funktionieren. Beim LGT8F328P dürfen die Widerstände aber nicht größer als 2 kOhm sein.

Die BMP180 Platine auf der Rückseite hat nichts mit dem BLHeli-Telemetry-Feeder zu tun. Ich habe lediglich zum Testen einen OpenXSensor umgeflasht.

BTF-ProMini

Die Status LED

... kann mehrere Betriebszustände anzeigen:

Programmstart: 2x kurzes Blinken
Datenverkehr (Normalbetrieb): Flackern
Warten auf Daten vom BLHeli ESC: LED aus (Dauerlicht bei D8Hub)
Warten auf Daten vom Receiver: LED Dauerlicht

Download

BL-Heli-Telemetry-Feeder Firmware - enthalten sind vorkompilierte Binaries und die Quelltexte.

Version 2024

Die wichtigste Neuerung ist, dass der BTF jetzt auch mit anderen Sensoren am Datenbus zusammenarbeitet. Das war nötig, weil ich einen sehr ähnlich aufgebauten GPS-Protokollwandler gebaut habe. Der soll natürlich parallel zum BTF funktionieren.
Zusammen mit der S.Port Fähigkeit von BLHeli_32 gab es in OpenTX/EdgeTx neue Sensoren, die erheblich sparsamer mit der Bandbreite auf dem Rückkanal umgehen. Diese verwendet jetzt auch der BTF. Bei einem Upgrade müssen wir eine Sensorsuche ausführen.
Gemäß einem Hinweis von Mike Blandford im Zusammenhang mit S.Port Telemetrie überträgt BTF jetzt Null-Werte an den Receiver, wenn der Wert unverändert ist, Das entlastet ebenfalls den Rückkanal, weil dann kein Wert gesendet wird.
Die D8 Hub Versionen von BTF sind unverändert geblieben.

Version 2025 (hochgeladen 15.03.2026):

Die AtTiny Versionen von BTF nutzen den internen Oszillator. Der ist meistens, aber nicht immer genau genug für die serielle Kommunikation über den Software-UART. Deshalb wird bei diesen Versionen der Oszillator bei jedem Programmstart kalibriert. Referenz ist die Dauer eines KISS-Datenrahmens.
TimeOuts beim Empfang der KISS-Datenrahmens werden erkannt und wie Prüfsummenfehler behandelt (keine Weiterverarbeitung, Fehlerzähler).

Wenn wir die Quelltexte selbst kompilieren wollen, finden wir hier die Software dazu (Great Cow Basic):
http://gcbasic.sourceforge.net/Typesetter/index.php/Home

Die Firmware auf den Controller flashen

AtTiny45 / AtTiny 85
Diese müssen per ISP-Programmer befüllt werden. BTF erwartet, dass der Tiny mit internerm PLL Oszillator läuft (16 Mhz). Dazu muss die Low Fuse auf 0xF1 gesetzt werden.
Ich empfehle dazu AvrDudess zu verwenden. Das ist eine grafische Oberfläche für Avrdude (der im Download enthalten ist).

AtTiny13
Hier gilt im Prinzip dasselbe, wie für die anderen Tinies. Unterschiede: BTF erwartet, dass der Tiny13 mit dem internen Oszillator auf 9,6 MHz läuft. Dazu muss die Low Fuse auf 0x3A gesetzt werden.

Digispark
Der Digispark ist eine fertiges Board mit einem AtTiny85 und USB-Anschluss. Das besondere ist der vorinstallierte USB-Bootloader "Micronucleus". Der ermöglicht es, die Firmware ohne weitere Hardware auf den AtTiny zu bekommen. Allerdings ist dazu ein Treiber zu installieren. Alles dazu erforderliche ist im Download vom Micronucleus enthalten. Mein Tipp: Zum Installieren des Treibers unbedingt die Variante mit der Zadig-Software durchführen.
Das Flashen funktioniert dann so, dass der Digispark an einen USB-Anschluss angesteckt wird, der Bootloader wartet 6 Sekunden auf einen Flashversuch. Danach startet die zuvor geladene Firmware.
Link zu Micronucleus: https://github.com/micronucleus/micronucleus
Aktueller Boottloader: https://github.com/ArminJo/micronucleus-firmware

Arduino (AtMega168p, AtMega328p, LGT8F328P)
Obwohl BTF nicht mittels Arduino geschrieben wurde, lässt sich die Firmware problemlos mit dem Arduino Bootloader laden. Auch hier empfehle dafür AvrDudess. Als Programmer logischerweise Arduino auswählen. Da der Bootloader verwendet wird, haben wir nichts mit dem setzen von Fuses zu tun.
Der Arduino muss folgende Voraussetzungen erfüllen: 5V Typ, 16 MHz, mit AtMega168p oder AtMega328p. Ab der Version 2024 funktioniert auch ein Board mit einem LGT8F328P.Die Anschlüsse sind kompatibel zu den Arduinos mit einem AtMega.

Telemetrie im Sender einrichten

Das folgend beschriebene gilt für die Anzeige der Daten auf einem Sender mit OpenTX oder EdgeTx. Alle Sensoren sollten im OpenTX/EdgeTx Telemetriemenü nach Aufruf der Sensorsuche angezeigt werden. Dort wo es passende Sensoren gibt, versucht BTF diesen zu emulieren. Wo nicht, werden die Rohdaten übertragen und können wie unten beschrieben passend konfiguriert werden..

FrSky D8 Hub Telemetrie

Sensorname VFAS = Akkuspannung [V]
Sensorname Curr = Motorstrom [A]
Sensorname RPM = Motorumdrehungen [rpm]
Es werden eRPM angezeigt. Um den an der Motorwelle anliegenden Wert zu erhalten, müssen wir den Messwert durch die Anzahl der Polpaare teilen (also z.B. "7" für einen Motor mit 14 Magneten). In den Einstellungen zu der Sensorzeile geben wir diesen Wert in der Zeile "Prop" ein. Bei der AtTiny13 Version müssen wir außerdem einen Multiplikator von 10 eintragen (Feld "Multiplik.", engl. "Multiplier").
Sensorname Tmp1 = Reglertemperatur [°C]
Sensorname 000C = Entladene Kapazität [mAh]
Sensorname 000D = Anzahl der Prüfsummenfehler
Der Wert gibt Hinweise auf Störungen in der Verbindung zwischen BLHeli-ESC und BTF.

FrSky S.Port Telemetrie
Hier hat sich gegenüber der BTF-Vorgängerversion viel geändert. Seitdem einige BlHeli32 ESCs selber S.Port sprechen, gibt es auch in OpenTX/EdgeTX angepasste Sensoren, die zwei Werte in einem Datenrahmen (bei S.Port immer 32 Bit) übertragen können. Das halbiert den Datentransfer nahezu.

Sensorname EscV = Akkuspannung [V]
Sensorname EscA = Motorstrom [A]
Sensorname EscC = Entnommene Kapazität [mAh]
Sensorname EscR (OpenTx: Erpm) = Motorumdrehungen [rpm]
Es wird eRPM angezeigt. Um den an der Motorwelle anliegenden Wert zu erhalten, müssen wir den Messwert durch die Anzahl der Polpaare teilen (also z.B. 7 für einen Motor mit 14 Magneten). In den Einstellungen zu der Sensorzeile geben wir den Divisor in der Zeile "Prop" ein.
Sensorname RB1C = Reglertemperatur [°C] *
Sensorname RB2C = Anzahl der Prüfsummenfehler * - Der Wert gibt Hinweise auf Störungen in der Verbindung zwischen BLHeli-ESC und BTF.

* Angezeigt werden nach der Sensorsuche "mAh" für die Sensoren RB1C und RB2C, weil diese Sensoren zweckentfremdet sind.
Sensorname und Einheit können in OpenTX/EdgeTx passend umbenannt werden.

FlySky iBus Telemetrie

Sensorname Tmp1 = Reglertemperatur [°C]
Sensorname A3 = Akkuspannung [V]
Sensorname Curr = Motorstrom
Sensorname Capa = Entladene Kapazität [mAh]
Sensorname RPM = Motorumdrehungen
BTF gibt wird eRPM/100 aus. Leider erschließt sich mir die Logik bei OpenTX/EdgeTx hier nicht. Folgende Einstellungen zu der Sensorzeile ergeben realistische Werte:
OpenTx: "Unit" = rpm; "Multiplikator" (engl. "Ratio") = 0; "Prop" = 3660 (!?) für 14pol Motor; "Prop" = 1826 (!?) für 8pol Motor.
EdgeTX: "Unit" = rpm; "Multiplikator" (engl. "Multipier") = 0; "Blades/Poles" = 366 (!?) für 14pol Motor; "Blades/Poles" = 183 (!?) für 8pol Motor.
Sensorname FM = Version & Anzahl Fehler
Nach dem Start wird kurz die Version angezeigt; 24001 = Jahr 2024, Version 001
Danach gilt:
Tausenderstellen = Anzahl der Reconnects zwischen BTF und iBus Receiver
Einerstellen = Anzahl der Prüfsummenfehler bei der Datenübertragung ESC -> BTF
Beispiel: 12034 = 12 iBus Reconnects, 34 BLHeli Prüfsummenfehler

Frank Steinberg, im März 2026

Zur Startseite

Haftungsausschluss Datenschutzerklärung Impressum

BLHeli Telemetrie ohne Flugcontroller! >aktualisiert 15.03.26<