BTF - BLHeli Telemetry Feeder, ein BLHeli Telemetrie Protokollwandler
 ^ 

BLHeli Telemetrie ohne Flugcontroller!    >aktualisiert 26.01.24<

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. Aber Achtung: Nicht jeder BLHeli_32 ESC kann Telemetrie oder er kann keinen Strom/Kapazität messen.

Seit der Firmwareversion 32.6 können wir BLHeli_32 so konfigurieren, dass die Telemetriedaten permanent gesendet werden. Das von mir im November 2018 vorgestellte Windows-Programm BLHeliTelemetryView nutzt das, um die Daten mittels eines USB-UART Wandlers anzuzeigen und zu speichern.

Eigentlich wollen wir die Daten aber auf unserem Fernsteuersender sehen! Das verwendete Format kann jedoch kein mir bekanntes RC-System direkt verarbeiten. 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:
  1. FrSky D8 Hub (nur BTF aus den Jahr 2019)
  2. FrSky S.Port
  3. FlySky iBus Telemetry

Seit Firmwareversion 32.8 kann BLHeli_32 S.Port Telemetrie direkt ausgeben. Der BTF ist damit für diesen Zweck ü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ägtpro 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.

Was ist neu in BTF 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.
 BTF-Intro

BTF-Taranis


Den ESC konfigurieren

Es gibt noch eine Hürde die nicht ohne ist, wenn wir uns noch nie mit BLHeli beschäftigt haben. Leider müssen wir nämlich davon ausgehen, dass ein BLHeli32_32 ESC im Auslieferungszustand nicht so eingestellt ist, dass er uns die Telemetriedaten automatisch liefert. Zwei softwaremäßige Voraussetzungen müssen gewährleistet sein:
  1. Firmware größer als Version 32.5
  2. In der Konfiguration muss "Auto Telemetry" auf "ON" eingestellt sein.

    Beides können wir mir 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.
    Die BlHeliSuite32 gibt's hier: https://blhelisuite.wordpress.com


Hardware bauen

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

BTF-Tiny85BTF-Tiny85
Schaltbild

und

Realität

Widerstände und LED sind optional - es geht auch minimalistisch:
BTF-Minimal_frontBTF-Minimal_insideBTF-Minimal_back

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 BTF-Digispark_frontBTF-Digispark_back

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-ProMiniBTF-ProMini_frontBTF-ProMini_back


Die Status LED

... kann mehrere Betriebszustände anzeigen:
  • Programmstart: 2x blinken
  • Datenverkehr (Normalbetrieb): Flackern
  • Warten auf Daten vom BLHeli ESC: LED Dauerlicht
  • Warten auf Daten vom Receiver: LED aus (nicht bei D8Hub weil nicht bidirektional)

Download

BL-Heli-Telemetry-Feeder Firmware  -  enthalten sind vorkompilierte Binaries und die Quelltexte.
Neu 26.01.2024 : Komplette Überarbeitung; neue Sensornamen in Anpassung an das BLHeli-interne S.Port-Protokoll.

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 BHF 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 Januar 2024


Zur Startseite

 

Haftungsausschluss    Datenschutzerklärung    Impressum

© Frank Steinberg