BLHeli_32 Telemetrie als Datenlogger

Steini63

User
Hallo,

ich habe einen BLHeli_32 ESC mit der aktuellen Firmware 32.6 geflasht. Diese Version kann so konfiguriert werden, dass Telemetriedaten permanent ausgegeben werden (Auto Telemetry ON).

Dafür habe ich ein Windows-Programm geschrieben, das diese Daten auslesen, anzeigen und loggen kann:
BLHeliTV.png


Das funktioniert schon ganz gut. Der Charme ist, dass man lediglich noch ein USB-Seriell-Konverter braucht und schon hat man eine Art Motoren-Prüfstand. Leider habe ich nur zwei geeignete ESCs (beide Racerstar). Es wäre schön, wenn ein BLHeli-Kundiger das mal mit seinen Gerätschaften testen könnte.

Details zum Projekt sind als Entwurf auf meiner Homepage zu finden:
http://www.franksteinberg.de/BLHeliTV.html

Freue mich über Rückmeldung
Steini
 

Steini63

User
Update:

Heute hat der Postonkel meinen lang erwarteten neuen ESC in den Briefkasten gesteckt; einen JHE 40A. Der hat für ca. 10€ Schmerzensgeld Telemetrie und einen "Current Sensor" (=Shunt) zu bieten.

  • Motorkabel angelötet,
  • Telemetriekabel angelötet,
  • Firmware 32.6 geflasht,
  • "Auto Telemetry" auf ON konfiguriert.
Läuft und funktioniert mit BLHeliTV - so hatte ich mir das erhofft :)

Inzwischen ist auch eine BLHeliTV-Version vom 03.11. online. Die hat marginale Änderungen (RpM pro Watt wird erst ab 1 Watt angezeigt).
Direktlink zum Download

Steini
 

Steini63

User
kennst du auch einen 60A und 80A Regler mit BLHeli32 Telemetrie?

Eine Suche beim Ali ergibt z.B.:
80A - 70A - 60A

Aber ACHTUNG: Nur beim 70A Modell kann ich einen Shunt erkennen. Die anderen beiden haben vermutlich keine Möglichkeit, Strom zu messen!

EDIT: Wer lesen kann ... Wahrscheinlich geht beim 80A Modell doch Strommessung; Zitat:
With digital current sensor which provides higher accuracy and eliminate drift.


Die BHeli_32 ESCs geben ihr eigenes Format aus. Bei Multicoptern sorgt meines Wissens der FlightController dafür, dass das in ein für die jeweilige Fernsteuerung verwertbares Signal umgewandelt wird und ausgegeben wird. Ich bin Flächenflieger, kann deshalb keine guten Tipps geben, welcher Controller am besten für FrSky geeignet ist.

Ich hoffe, BLHeli_32 wird auch bald für Flächenflieger interessanter. Die 'Auto Telemetry' ist ein erster Schritt. Ein Umsetzer von BLHeli-Telemetrie auf IBus (FlySky) oder SPort (FrSky) könnte mein nächstes Projekt werden. Aber vielleicht kommt mir da jemand zuvor. Am Besten durch Integration in openXsensor. Ich würde mich freuen! Wünschen würde ich mir ein paar ESC-Modelle mit BEC für uns Flächenflieger.

Steini
 

bendh

User
danke für deine Antwort.
Ich bin auch Flächenflieger und finde es schade dass kein FrSky Protokoll ausgegeben wird.
Wenn du solch einen Umsetzer fertig hast, wäre das sicher für viele sehr interessant.
 
Hallo Steini!

Für meinen für März angekündigten Pino medium V3 (Motorsegler von PCM) möchte ich aufgrund der Platzverhältnisse einen möglichst schmalen ESC einbauen und bin über die BLHeli_32-Regler gestolpert. Habe zum Probieren einen HK Turnigy Multistar 41A mit BLheli_32-Firmware geordert. Da ich mit FrSky (Horus 12S) fliege und einen G-RX8 einbauen will, bin ich auf Dein Telemetrieprojekt gestoßen - tolle Sache, vielen Dank für Deine Anstrengungen!

Nun mein Problem: Aufbau, Anschluss und Test waren problemlos. Telemetrie wird angezeigt, allerdings tw. stark verzögert (mehrere Sek.), die grüne LED blinkt rasch (was OK sein dürfte). Und der Fehlerzähler (RBC2) zählt permanent rauf (bis zum Überlauf, dann wieder von vorne), geschätzt ca. 30 Fehler / sek. Das dürfte die Verzögerungen erklären.
Hab' dann Dein Windows-Programm (BLHeliTV) installiert und verglichen, da kommt 1 CRC-Fehler auf ca. 400 Dataframes (14212 Frames, 31 CRC-Fehler), also nicht perfekt, aber viel besser.

Hast Du eine Ahnung, was da im Argen liegt?

Vielen Dank,
Ewald
 

Steini63

User
Hast Du eine Ahnung, was da im Argen liegt?

Schon mal gut, dass du auch Tests mit dem PC Programm gemacht hast. Ich habe bei der Anzahl von Datenframes keinen einzigen CRC-Fehler.

Der Fehler muss ja in der Verbindung zwischen Regler und BLHeli-Feeder liegen. BLHeli sendet eine Prüfsumme in jedem Datenframe mit. Stimmt diese nicht mit den empfangenen Daten überein wird der Fehlerzähler hochgezählt und die Daten werden nicht verwendet.

Ich vermute, dass die Taktfrequenz des Reglers daneben liegt und in der Folge der Baudratenfehler zu groß ist. Ich würde dir zwei neue Hexfiles kompilieren mit Abweichungen nach oben und unten, um zu sehen ob es besser wird. Dazu muss ich deinen Zielprozessor wissen. Protokoll ist ja wahrscheinlich SPort.

Daneben kannst du schon mal ein paar Sachen probieren:
  • Alle Verbindungen zwischen Regler und BLHeli-Feeder kontrollieren
  • Steckverbindungen tauschen
  • Kabel kürzen
  • Kabel verdrillen
  • Mit verschiedenen Widerständen in der Datenleitung experimentieren (0 bis 10kOhm)


Steini
 
Hallo Steini!

Vielen Dank für Deine ausführliche Antwort!
Könnte der Fehler nicht auch zwischen BTF und Receiver (d.h. am SPort) liegen? Die Werte im PC-Programm schauen ja OK aus, d.h. der Datenstrom aus dem ESC scheint ja nicht ganz falsch zu sein.
Ich habe noch weitere Tests mit dem BTF gemacht und dabei auch falsche Werte am Display erhalten (Drehzahl 8-stellig...). Ich vermute, da war die CRC zufällig richtig.

Ich habe die Schaltung mit dem AtTiny85 gebaut, genau so wie das Schaltbild auf Deine Homepage (und das Foto rechts daneben), außer dass ich in der Vcc-Einspeisung noch eine Diode reingegeben habe, da ich mit 6V fliegen will (Spannung hab' ich gemessen, die ist OK). Ich hab' mit AVRDudess geflasht und die Fuses genau wie in Deiner Anleitung gesetzt (und geprüft, ob alles passt).
Die Taktfrequenz des Reglers ist lt. HK 48MHz, wie genau das stimmt, kann ich leider nicht prüfen.
Deine Tipps werde ich noch abarbeiten, mit Verdrillen meinst Du vermutlich, noch eine zusätzliche Massestrippe ziehen und dann verdrillen, weil jetzt habe ich ja nur die Datenleitung zwischen ESC und BTF (ca. 40 cm, ein Steckkontakt).

Nochmals herzlichen Dank,
Ewald
 

Steini63

User
Könnte der Fehler nicht auch zwischen BTF und Receiver (d.h. am SPort) liegen?

Der Fehlerzähler (der als RBC2-Wert ausgegeben wird) zählt die Prüfsummenfehler der Daten vom Regler. Wenn die Werte sauber und regelmäßig auf dem Sender-Display angezeigt werden, muss es an der Strecke Regler-BTF liegen. Dass es mit dem PC-Prog besser geht, kann an einer höheren Fehlertoleranz des USB-Adapters liegen.

Im Link sind zwei Hexfiles für den Tiny85, bei denen die (für die Baudratenberechnung zugrunde gelegte) Frequenz leicht nach oben/unten manipuliert ist:
https://www.FrankSteinberg.de/Foren/BTF-Test.zip

Steini

P.S. Bei dem Tipp mit dem Kabel verdrillen war ich auf dem falschen Dampfer.
 

BOcnc

User
Ich habe mir was für MPX mit dem Attiny85 gebaut. Ich benutze einen 12 MHz Quarz damit das besser funktioniert. Wieviel CRC Fehler es gibt kann ich aber nicht sagen. So schnell wie die Daten kommen kann man die ja auch nicht ablesen.
 
Hallo Steini!

Hab' Deine BTF-SPort_T85_16,3.hex eingespielt und - Bingo - der RBC2 bleibt auf 0 und die anderen Telemetriedaten trudeln regelmäßig mit vernünftigen Werten ein - so hab' ich mir das vorgestellt! Hab' sonst nichts am Aufbau verändert.
Herzlichen Dank für Deinen hervorragenden Support, bei Amazon würde ich fünf Sterne vergeben!

Sobald mein Tenshock-Motor von Reisenauer eintrifft, werde ich einen "realen" Testaufbau machen und schauen, ob alles so funktioniert wie ich mir das vorstelle - ein BLHeli_32 für Flächenflieger ist ja schon ungewöhnlich, dann noch mit einem Innenläufer dran - das wird spannend. Allerdings sind die Regler so günstig, dass ich im Notfall halt auf "Altbewährtes" (vermutlich den 40A oder 60A Regler von FrSky, die neuen "dünnen") zurückgreifen werde.

Übrigens: Die BLHeli_32-Leute arbeiten an direkter FrSky-/SPort-Ausgabe am Regler, eine Beta gibt es schon (32.7.1). Hab's aber noch nicht getestet, wollte zuerst Dein Modul zum Laufen bringen.

MlG,
Ewald
 

Lownoise

User
Übrigens: Die BLHeli_32-Leute arbeiten an direkter FrSky-/SPort-Ausgabe am Regler, eine Beta gibt es schon (32.7.1). Hab's aber noch nicht getestet, wollte zuerst Dein Modul zum Laufen bringen.

Hat das denn schon jemand am laufen bzw. gibts mehr Infos/Links?
Das hört sich ja sehr gut an finde ich!
 
Hallo Lownoise!

Nachdem ich den BTF mittels Franks modifizerter Firmware zum Laufen gebracht hatte, hab ich die BLHeli_32-Beta-Firmware (32.7.1) auf meinen Turnigy Multistar geladen (von hier: https://github.com/bitdump/BLHeli/tree/master/BLHeli_32%20ARM/Rev32.7.1%20SBUS%20and%20S.PORT%20testcode). Damit wird auf dem Telemetrie-Ausgang des Reglers dann das FrSky SPort-Telemetrieprotokoll ausgegeben und dieser kann direkt mit dem passenden FrSky-Empfänger-SPort-Eingang verbunden werden.

Achtung: Geht nicht bei jedem Regler, wenn der Regler nicht in der Liste unter obigem Link zu finden ist (unter dem Namen, mit dem der Regler in BLHeliSuite32 angezeigt wird), geht es möglichweise hardwaremäßig nicht.

Auf meiner Horus X12 wurde die Temperatur korrekt angezeigt, die RPM, Volt, Amp und mAh jedoch unter falschen Namen und Einheiten. Das kommt daher, dass mit den neuen FrSky-Reglern (Neuron, die basieren ja auch auf BLHeli32) neue Telemetriewerte eingeführt worden sind, die auf meiner Horus unter OpenTX 2.2.0 jeodch noch nicht bekannt sind. Da ich noch auf ein Sender / HF-Update von FrSky warte bevor ich meinen Sender aktualisiere, konnte ich nicht überprüfen, ob die Werte dann richtig angezeigt werden. Ich gehe aber davon aus.

Als nächstes möchte ich weitere Flieger auf BLHeli_32 umstellen, dazu brauche ich aber stärkere Regler. Werde jetzt einen iFlight Succex 80A bestellen (geht bis 8S).
Kennt jemand noch stärkere ESCs (ideal bis 10S / 100A), die mit BLHeli_32 funktionieren?

MfG,
Ewald
 

bendh

User
Das Update von OpenTX hat aber überhaupt nichts mit dem HF Update zu tun. Du kannst es also wagen. Dann werden dir auch die Telemetriewerte richtig angezeigt.
Der Vorteil der neuen Bezeichnungen ist, dass sie korrekte Namen haben und bei einer Sensorneusuche deine Werte nicht mehr neu sortiert werden müssen.
 
Danke Bernd!

Das ist mir schon klar, dass die Sachen nichts miteinander zu tun haben. Da ich aber auch noch einige andere Dinge am Sender machen werde (Knüppelschalter, anderer Akku, evtl. ACCESS-Upgrade, wenn das noch kommt), möchte ich das lieber alles zusammen erledigen als in kleinen Schritten. Der Flieger für meinen jetzigen Regler (PCM Pino medium 3.0) kommt sowieso erst in 4-5 Wochen, daher hab' ich es nicht eilig ;).

MfG,
Ewald
 
Moin

Da ich die Tage ein bissl. mit dem BHLELI32 Protokoll gespielt habe, habe ich Steinis Programm quasi im Hintergund ständig als Kontrolle mitlaufen lassen (FTDI Rx zusätzlich mit dran), es rennt perfekt, auch über längere Zeit unter Linux per Wine perfekt. :):)

Sogar die Autoportsuche funktioniert im Linux wie von Geisterhand :eek:

Danke Steini für das Programm :cool:
 

doloebig

User
Ich hoffe, BLHeli_32 wird auch bald für Flächenflieger interessanter. Die 'Auto Telemetry' ist ein erster Schritt. Ein Umsetzer von BLHeli-Telemetrie auf IBus (FlySky) oder SPort (FrSky) könnte mein nächstes Projekt werden.
Steini
ist aus der Ibus Umsetzung was geworden?
Openxsensor kann das wohl nicht.
Für mich wäre schon ein Stromsensor hilfreich aber den gibt es wohl von Flysky in absebarer Zeit nicht.
Grüsse
Doro
 
Ansicht hell / dunkel umschalten
Oben Unten