Wichtig ist, dass JLog beim Einschalten des KOSMIK (Antriebsakku wird angeschlossen) bereits per KOSMIK-Kabel mit einem der drei Option Ports des KOSMIK verbunden ist! Die Firmware des KOSMIK unterstützt unterschiedliche Geräte am Option Port, macht beim Startup eine Geräteerkennung, – erkennt JLog als “TelMe”. Danach, bei laufendem KOSMIK, kann JLog beliebig ab-/angesteckt werden. Es ist egal, an welchen der drei Option Ports man JLog steckt.
JLog’s KOSMIK Port ist einer der drei Wege, JLog mit Betriebsspannung zu versorgen. Der KOSMIK liefert hier stabilisierte 5V an JLog.
Von JLog2.5 zu JLog2.6 wurde absichtlich auf ein anderes, nämlich kürzeres KOSMIK-Kabel gewechselt, um dadurch die unbewussten Chancen des Anwenders dafür zu verringern, dass es durch Fehlverlegung zu Eintrahlungen in das Kabel kommt. Bitte verlegen Sie das Kabel nicht in unmittelbarer Nähe von Hochstromleitungen und -anschlüssen, weder solchen der Motorseite, noch der Antriebsakkuseite. Auch der Motor und der Antriebsakku sind zu meiden. Sollte es sich nicht anders machen lassen, dann vermeiden Sie wenigstens ein Parallellaufen des KOSMIK-Kabels zu Hochstromleitungen. “Nette Kabelschlaufen” sind auch nette “Antennen”. Sollte das Kabel zu lang sein, lassen Sie die zusammengefassten Kabelsegmente direkt aufeinander liegen. – JLog integriert elektronische Maßnahmen zum Schutz des Option Ports am KOSMIK.
Sollten Sie feststellen, dass Ihre Servos am KOSMIK-BEC verrückt spielen, dann liegt eine Masseschleife vor: Entfernen Sie die Masseleitung im KOSMIK-Kabel. Dieses Bild zeigt Ihnen, in welcher Position im Stecker es sicht befindet. Die Farbe kann variieren. Entfernen Sie die hier blau gezeichnete Leitung aus dem Stecker JLog-seitig.
Die Firmware des KOSMIK muss wenigstens 4.0 sein!
JLog muss während des Powerup des KOSMIK (Akku ran) bereits an einen Option Port des KOSMIK angeschlossen gewesen sein, sonst erkennt er kein “TelMe”, keinen angeschlossenen JLog, und sendet keine Daten! Danach, KOSMIK bleibt unter Spannung, kann JLog, so oft man will, ab-/angesteckt werden.
Es kann vorkommen, dass bestimmte vom KOSMIK an JLog gelieferte Daten erst dann ein Update erfahren, wenn der KOSMIK mit dem Motor initialisiert hat.
JLog bezieht alle 50ms einen neuen Datensatz vom KOSMIK. Er loggt mit dem KOSMIK auch mit 20Hz, alle 50ms ein Record. Der KOSMIK selbst loggt mit 10Hz, geht dann aber auf 100Hz (alle 10ms ein Record), wenn er kommutiert. Das bringt keinen tatsächlichen Vorteil, nur den Nachteil großer Logfiles.
JLog empfängt die folgenden Rohdaten vom KOSMIK:
Ubat ……Antriebsspannung (V)
Imot …… Motorstrom (A) *)1 *)a
Ibec …….BEC-Ausgangsstrom (A) *)b
mAh
tFET …… Endstufentemperatur (°C)
tBEC ……BEC-Temperatur (°C)
rpm2 ….. 2-pol-normalisierte Motordrehzahl *)2
PWM ….. “internes Gas”, 0..100%
Was fehlt in der obigen Aufstellung? Richtig, der KOSMIK liefert weder Ubec (BEC-Ausgangsspannung) noch Throttle (Gas), obwohl er selbst beides loggt. Ubec ist nicht so schlimm, sofern dessen BEC-Spannung die R/C-Elektronik versorgt, das liefert i.Allg. jeder telemetriefähige Empfänger.
*)1 (Imot)
Der KOSMIK kennt 3 Hauptstromwerte, die er loggt, er liefert auch mehr, als diesen einen Strom, den JLog “Imot” nennt. JLog nimmt aber nur den einen Strom, das hat folgenden Grund:
Offenbar hat der Entwickler des KOSMIK das Problem umgangen, was entsteht, wenn man den Strom in den Motorleitungen misst, nämlich die Notwendigkeit aufwändiger Umrechnung, die JLog mit dem JIVE hat. Nun, es wird schon auch in den Motorleitungen gemessen, alleine deshalb, weil der KOSMIK bis ca. 30% PWM FOC (Field Oriented Commutation) macht, daher der extreme Sanftanlauf. Das ist eine stromgeführte Kommutierung, braucht mindestens einen Shunt auf der Motorseite. Die Strommessung für Log/Telemetriedaten scheint aber auf der Batterieseite zu geschehen, hier gibt es “realen” Strom. Leider wird dabei auch integriert, in Hardware (R-C-Glied) oder per Software, wodurch der KOSMIK den Strom nicht mit solchen Echtzeitwerten liefert wie der JIVE, was ein Vorteil für Forensik aus dem Log ist. Es wird also der Primärstrom gemessen, allerdings ganz offenbar noch vor dem Primäranschluss des BEC, wodurch der Primärstrom des BEC nicht mit erfasst wird. JLog nennt also den von ihm aus dem Protokoll entnommenen Strom mit Recht “Imot”, Motorstrom.
Warum werden andere Motorstromwerte durch JLog ignoriert? Nun, um es unverblümt zu sagen: Weil diese Werte Fake sind. Genau, Fake. 
… Es gibt einen angeblichen “Imot Peak”. Tja.., der ist unecht. Stattdessen multipliziert man ganz offenbar den gemessenen Primärstrom, schön glattgebügelt durch Integration, einfach mit Wurzel 2, man will ja auch Peakstrom bringen, ein gewisser “JLog” setzte am JIVE die Maßstäbe. OK, wer sich davon hinter’s Licht führen lässt.. Allein, im Log sieht man es ganz deutlich anhand dessen, dass die Steigungen der Kurvenverläufe von “Imot” und “ImotPeak” immer identisch sind, dass man hier veräppelt werden soll. Die Steigungen können nicht identisch sein, allein schon wegen der den Innenwiderstand verringernden Wirkung der Low ESR Elkos. Na ja, und Wurzel 2 als konstanter Multiplikator… … Dann haben wir noch einen dritten Stromwert, der als “Ibat” (Batteriestrom) verkauft wird. So so.., ist es nicht vielmehr so, dass Ibat = Imot * PWM/100 ? 
Schöne Theorie, im Ansatz richtig, aber nicht realitätsnah. Und warum misst “Ibat” keinen Primärstrom des BEC? – Anyway, zu einer Scharade gehören immer zwei.
*)a, *)b
Die Firmware des JIVE Pro glänzt seit geraumer Zeit mit zwei Bugs bzgl. des Daten Outputs an JLog als “TelMe”:
*)a Der Wert des Motorstroms (Imot) friert auf dem momentanen Wert ein, wenn das Kommutieren endet (Motor aus). Zum Glück wirkt sich das nicht auf die mAh aus, da der ESc diese selbst kumuliert und liefert, aber offenbar nicht auf dem fehlerhaften Stromwert basiert.
*)b Ibec (BEC-Strom) ist grundsätzlich fix auf 0,9A. Dieser Wert liegt bereits an zu einem Zeitpunkt, an dem der ESC noch gar nicht bereit ist, (reale) Werte zu liefern, – ein Bug im Protokoll, also.
mAh
Oh, die kommen ziemlich genau, ist ja auch nicht so schwer (wie beim JIVE) angesichts des Punktes, in dem man den Strom misst. Der KOSMIK liefert also die mAh, JLog muss sie nicht errechnen. Nur wenn ein HV²BEC angeschlossen ist, errechnet und addiert JLog die mAh des externen BEC.
Leicht feststellbar ist, dass dabei der Primärstrom des BEC, der Kapazitätverbrauch durch den BEC, ignoriert wird. Tatsächlich ist das in HV-Anwendungen eher Peanuts im Vergleich zum Verbrauch durch den Motor. Ich nehme an, man addiert einen fixen Durchschnittsbetrag, und die genauen Ergebnisse bestätigen die Richtigkeit der Methode.
Trotzdem gibt es ab und zu KOSMIK-Anwender, die Ungenauigkeit der mAh beklagen. Daher unterstützt JLog auch mit dem KOSMIK das “Kalibrieren” durch den User, mittels “Imot Shunt”, der im Konfigurator JLC eingestellt wird.
*)2 (RPM)
KOSMIK kennt wie quasi jeder ESC nur eine relative Drehzahlgröße, nämlich 2-pol-normalisiert. Er weiß nicht, wieviele magnetische Pole der Motor hat, es muss ihn für das Kommutieren auch nicht interessieren. Nur wenn er selbst loggt, wie es der KOSMIK tut, sollte er die Polzahl kennen, um die echte Motordrehzahl aufzeichnen zu können. “Zweipolnormalisiert” heisst: Mit einem 2-Poler als Motor stimmt es, mit mehr Polen ist der gelieferte Drehzahlwert um den Faktor Polzahl/2 zu hoch.
Man muss nun aufpassen! Jlog konnte davon ausgehen, und tut es immer noch, dass die Drehzahl 2-pol-normalisiert kommt. Er wendet die ihm bekannt gemachte (JLC->CONFIG.txt) Polzahl an, erhält die echte Motordrehzahl rpmMot für sein Log und Telemetrieausgabe, – daraus dann via Anwenden der bekannten Untersetzung (Ratio) auch rpmUni == rpmRotor. Soweit, so gut.. Nun hat aber Kontronik inzwischen ein BT Interface nebst App gebracht und dazu das Gegenstück in der KOSMIK Firmware. Ein User der App kann dem KOSMIK nun Polzahl und Gear Ratio (Untersetzung) mitteilen. (Inzwischen gibt es auch die ProgUNIT dafür.) Dadurch stimmt es dann in dessen eigenem Log, aber er gibt nun quasi die “falsche” Drehzahl an “TelMe” in Form von JLog. Ist der JLog kein “GW”, loggt selbst, dann nimmt man das einfach wieder zurück, lässt den KOSMIK weiterhin 2-pol-normalisiert senden. Hat man einen JLog2.6GW, baut auf das Log des KOSMIK (und hat ein KOSMIK BT Interface), dann ist es besser, der KOSMIK kennt Polzahl und Untersetzung. Auf JLog-Seite stellt man im JLC einfach auf 2-Poler, JLog nimmt dann die gelieferte Motordrehzahl 1:1, denn sie stimmt ja. Genauso verführe man bzgl. der Untersetzung (1:1), sollte der KOSMIK bereits die Rotordrehzahl liefern. Dann hätte JLog natürlich keine stimmende Motordrehzahl, denn ein reverses Anwenden der Polzahl ist bisher nicht vorgesehen in JLog. Zusammengefasst: Sind Polzahl und Untersetzung vermittels App “K-PROG” und via BTU eingestellt, JLog wird per JLC auf Polzahl 2 und Ratio 1:1 eingestellt, dann sind rpmMot und rpmRotor für JLog identisch, == rpmRotor.
RPM und Einstellmöglichkeiten im ESC selbst (Polzahl, Ratio)
Wie sich jetzt erst herausstellte, gibt es aber einen wichtigen Grund, den ESC auf Default-Einstellungen zu belassen, 2-Pol, Ratio 1:1: Die Auflösung der bei JLog ankommenden Drehzahl, ob nun für Telemetrie oder dessen Log, leidet erheblich, wenn man den ESC, KOSMIK oder JIVE Pro, umrechnen lässt. Grund ist, dass Kontronik grundsätzlich /10 die Drehzahl ausgibt, im Ergebnis, mit Ratio (Rotordrehzahl) beträgt die Auflösung nur noch 100 RPM, 100 RPM sind 1 Digit. Damit beträgt der Mindestfehler +/-100 RPM, der Theorie (Abtasttheorem) gemäß bis zu +/-200. Hat man Futaba als Telemetrie, wirkt on top deren RPM Display, das nur modulo 6 anzeigt und modulo 60 beschickt werden will. Die Abweichungen wären dann zusammen mit einem KOSMIK/JIVE Pro, der Polzahl/Ratio selbst anwendet, +/-120 bzw. +/-240! – Besser also den ESC weiterhin 2-pol-normiert die Motordrehzahl (Ratio == 1:1) geben lassen. Dadurch behält man die gewünschte Auflösung und JLog kann gleich noch beide Drehzahlen differenzieren, Motor und Rotor. Lässt man den KOSMIK loggen, kann man ja LogView per passender INI-Datei in die Rotordrehzahl umrechnen lassen, - das generiert die INI-Datei. (siehe auch, Deutsch unten auf der Seite)
.
Für Anschlussweisen inklusive jeweiliger Telemetrie informieren Sie sich bitte in Anschlussbilder JLog2.5, 2.6.
.
Hier endet die Handbuchseite eigentlich …
————————————————————————————————————————————————————
Das Folgende kam sukzessive hinzu. Grund: Bugs der ESC’s KOSMIK und JIVEpro. Dabei handelt es sich vornehmlich um einen Hardware Design Flaw des BEC, als “BEC Power-up Bug” allg. subsummiert, – außerdem um Firmware Bugs im Datenprotokoll an JLog als “TelMe”. Da sich nicht jeder die Details antun will, vorab (vor Rewriting des Chapters) hier die Zusammenfassungen und empfohlenen Maßnahmen:
1. BEC Design Flaw: Man kann es als typisches Henne-Ei-Problem charakterisieren: Der BEC Controller braucht Steuerung durch den Prozessor, aber der Prozessor wird vom BEC versorgt und erst zum Leben erweckt. Die Wirkung kann sein, muss es nicht unbedingt, dass die BEC Ausgangsspannung nach Anschließen des Antriebsakkus verrückt spielt. Das kann sich “nur” auf die ersten 10ms erstrecken, es kann aber auch mehrere 100ms währen oder zu einem dauerhaften Schwingen der BEC Spannung führen. Die Folgen sind setup-abhängig und vielgestaltig, könnten sogar ein versorgtes Gerät killen, wenn dessen interner Spannungsstabilisator eine zu geringe sog. “Ripple Rejection” hat, – sprich, dessen Spannungsregelung zu langsam ist. — Die Effekte sind dynamischer Natur, von allem möglichen abhängig, wie: 1) ESC Exemplar, 2) elektrische Last am BEC zum Einschaltzeitpunkt, 3) “Natur” der Lasten im Sinne nichtlinearer Widerstände, 4) Temperatur, 5) ob es draußen regnet . Es gibt ergo kein Schwarz-Weiß, und typische Aussagen in Foren wie, “bei mir ist alles ok, also existiert es nicht”, sind völlig unangebracht. (Ohne Meßmittel, Speicheroszi, z.B., sieht man nur Scheinbarkeiten, – ein User aus Frankreich, z.B., sah 2V BEC Spannung auf seinem Multimeter, natürlich nicht, dass das als Sägezahn schwingt.)
Gegenmaßnahmen:
– Pufferspannungsquelle VOR Power-up anschließen. Dem BEC macht es nichts, er hat eine ideale Diode hinter sich, die in seinen Ausgang einfließenden Strom verhindert. — Übrigens schreibt der Hersteller Kontronik direkt das Verwenden eines solchen Puffers vor, wenn auch ursprünglich sicher aus anderen Gründen.
– Optipower BEC Guard zwischen BEC Ausgängen (Master UND Slave, – entweder vor dem Guard parallel schalten, oder zwei Guards verwenden) und Verbrauchern, – ALLEN: Plus-Leitung im “KOSMIK-Kabel” zwischen JLog und “Option Port” trennen und stattdessen JLog via seinen “JIVE Port” versorgen (“Signal” Pin!). – Hier wirkt die Funktion “Voltage Lockout” des Guard, – er hat aber noch einige andere Sicherheitsfunktionen, Überspannungsschutz bis gaanz viel, z.B.
– Optipower Ultra Guard, am besten in Kombination mit dem BEC Guard: Mit seiner neuesten Firmware wirkt der Ultra Guard im Startup ähnlich einem Akku, bevor er seine reguläre Funktionsweise beginnt. Vorteile gegenüber einem Akku sind z.B. seine eigene Akkupflege (Laden und Balancen), geringerer Innenwiderstand als ein Akku (schnelle Spannungsregelung) und Unabhängigkeit des Setups von der eingestellten nominalen BEC Spannung.
2. ESC Firmware Bugs: Betrifft (zunächst, s.u.) nur die Firmwares des JIVEpro: 1. Der Motorstromwert an JLog als “TelMe” friert ein auf dem letzten Betrag, wenn das Kommutieren stoppt. JLog’s jüngste Firmwares (seit 1./14. August 2015) enthalten einen Workaround dagegen: Imot wird auf Null gesetzt, wenn PWM<11%. 2. Ibec ist auf 0,9(A) dauerhaft eingefroren. Daran kann JLog leider nichts ändern. Bedauerlicherweise beinhalten die jüngsten Updates von Kontronik (Anfang August 2015) keinen Fix dafür, – stattdessen bringen sie einen neuen Bug on top, der beide ESC’s betrifft, KOSMIK und JIVEpro:
Updates KOSMIK 4.6, JIVEpro 1.6: Wie oben gesagt, die seit bereits deutlich mehr als einem Jahr in den JIVEpro Firmwares enthaltenen Bugs wurden nicht gefixt. Es änderte sich leider auch nichts daran, dass Ubec, Gas, effektives Gas (inkl. Offset für Bailout) und Timing weiterhin nicht gesendet werden. Dafür gibt es nun einen massiven Fehler in der ausgegebenen Drehzahl. JLog’s aktuelle Firmwares (seit 7./14. August 2015) enthalten einen Corrector dagegen. Dieser kann aber nur bei verhältnismäßig geringen Motordrehzahlen vollständige Heilung bewirken, z.B. max. 16250 an einem 8-Poler, 13000/10-Poler, 9285/14-Poler. Man muss ihn seitens des ESC-Setups unterstützen, indem man im ESC die Polzahl einstellt, aber Untersetzung auf 1:1 belässt, – dafür stellt man in JLog (per JLC) die Motorpolzahl auf 2 und stellt hier das echte Ratio ein. Nur so erreicht man beides: Korrektur und weiterhin beide Drehzahlen (Motor, Rotor) bei hinreichender Auflösung. — Einstellen der Polzahl im ESC: Mit .NET-basierender (Windows) Software “K Config” plus ProgUnit oder ProgDisc als Interface, oder mit App (Android) und BT Modul (nur das von Kontronik).
Mit obiger Zusammenfassung bewaffnet, kann man nun unten “selektiv lesen”, – und verstehen, so jedenfalls die Hoffnung.
Wer es bis hierher “überlebt” hat, nimmt vielleicht noch folgendes mit:
1. Man beachte, dass ein Puffer am BEC Ausgang, ob nun Akku oder Ultra Guard, zwar die gesamte Elektronik im Modell “bei Laune” halten kann, nicht aber die Elektronik im ESC, wenn dessen BEC Spannung ausfallen sollte. Grund ist besagte ideale Diode ESC-intern am BEC Ausgang, die Einspeisen verhindert. Was im Fall der Fälle also immer noch passieren könnte: Der Motor geht aus, weil der ESC intern spannungslos wurde.
Jetzt fragt sich natürlich der Leser: Warum/wann sollte denn so was passieren? Das fragten wir uns auch, bis wir durch Forensikanfragen von Optipower erstaunlicherweise eines anderen belehrt wurden. Der Motor im Modell ging aus trotz Ultra Guard, dasselbe mit einem Scorpion Backup Guard.
Unsere Untersuchungen ergaben folgendes: Solange der BEC eines KOSMIK Temperaturen unter 45..60°C meldet, kann transienter Strom (Wechsellast) multible Resets des BEC auslösen. Der BEC kommt sofort wieder, nur ist dann schon das Kommutieren gestoppt, – außerdem ist danach das Datenprotokoll an “TelMe” (bzw. JLog) tot. Sofern man einen Puffer betreibt (Akku, R2 Supercaps, Opti Ultra Guard, Scorpion Guard, ..), hat das zum Glück auf die versorgte Elektronik außerhalb des ESC keine Wirkung, – schließlich können FBL’s nicht in-air kalibrieren, viele müssen aber bei Power-up. – Ist der BEC durchgewärmt (>60°C), verschwindet der Effekt. – Ein JIVEpro ist in dieser Hinsicht völlig sauber, zeigt die vorgesehenen (ESC Firmware) bzw. durch den BEC Controller (Chip, TI LM5116) bedingten Reaktionen: Ab 100°C wird die BEC Ausgangsspannung auf 5,0V verringert. (Achtung Captron Demon User!), bei ca. 105..107°C macht der Controller dicht. Die BEC Spannung kommt nicht wieder. – Übrigens: Es stellte sich dabei auch heraus, dass beide ESC’s geloggten/gesendeten BEC Strom bei 28A abschneiden (begrenzen), auch wenn tatsächlich mehr fließt, z.B. 30A gemäß Specs.
Gegenmaßnahmen? Die gibt es eigentlich nicht, – niemand wird vorher seinen BEC durchwärmen. Nur wer auf einem externen BEC fliegt, ist gefeit davor. (Nein, das ist keine Schleichwerbung für unsere BEC’s! ). — Allerdings muss man wieder betonen: Es könnte passieren, es muss es aber nicht. Es gab einige Fälle, die wir von Opti zur Forensik bekamen, und die zwei KOSMIK’s, die wir zum Zeitpunkt gerade verfügbar hatten (1×200, 1×160), zeigten beide das beschriebene Verhalten. Für repräsentative Statistik reicht das nicht aus. Außerdem hängt es ganz offensichtlich vom Strombedarf verwendeter Servos und von deren “Natur” ab.
2. Ströme (außer Ibec) vom ESC, – geloggt durch den KOSMIK, – beide (KOSMIK, JIVEpro) senden nur “Imot” an “TelMe”: Diese Ströme, “Ibattery”, “Imot” und “ImotPeak”, sind von unterschiedlicher Brauchbarkeit. Seit 1./14. August 2015 loggt JLog alle drei Ströme (nicht nur Imot und den integrierten Wert darauf (ImotInt)), – auch an einem JIVEpro, weil die drei Ströme, ausgehend von bereitgestelltem Imot + PWM, voneinander berechnet werden können. Klick
.
…und nun viel “Spaß” mit der aneindergestoppelten Historie notwendig gewordener Erweiterungen dieses Chapters des Manuals (bevor sich die Zeit zum Aufräumen findet)
————————————————————————————————————————————————————
.
————————————————————————————————————————————————————
“Power-Up Bug” – KOSMIK und JIVE Pro BEC Hardware Design Flaw
Wie erklärt man den “Powerup Bug”, ohne sich wieder Unmut sich überlastet fühlender Leser zuzuziehen?…
Nach dem Powerup (Antriebsakku Anstecken) des BEC kann dieser während der ersten 100+ Millisekunden einen gewissen “Spannungsirrsinn” produzieren, der jegliche versorgte Elektronik in Mitleidenschaft ziehen kann. Abhängig von angeschlossenen Lasten (Verbrauchern) kann das soweit führen, dass der BEC niemals erfolgreich startet und die eingestellte Spannung belastungsfähig bereitstellt. Der Grund dafür ist ein prinzipieller Design-Fehler, den ALLE KOSMIK und JIVE Pro haben, und der vermutlich nie durch den Hersteller beseitigt werden wird. Der Fehler besteht darin, dass erst der Microcontroller im ESC starten muss, um den BEC unter Kontrolle zunehmen. Allerdings stammt dessen Betriebsspannung letztendlich (über weitere, dem BEC nachgeschaltete, interne Spannungserzeugung) auch aus dem BEC, den er steuern soll. Tja.., wie soll das zuverlässig funktionieren ohne “Time Tunnel”? Das Ei muss erst die Henne legen, damit die Henne das Ei legen kann.
JLog, CVS16 und insbsondere das Dateisystem der SD-Karte sind als Spannungsversorgte potentielle Opfer. Ein R2 Buffer (Supercaps) kann evtl. gar nicht beim Powerup am BEC betrieben werden.
Bisher gab es nur zwei Möglichkeiten, sich zu behelfen:
- Powerup ohne jede Last am BEC (erst nach 1 Sekunde anstecken)
- Einspeisen einer Pufferspannung während des Powerup (mit unserer neuesten Firmware auch per Opti Ultra Guard)
Da uns (R2) unsere Zeit langsam zu schade wurde, um sie in Support Cases zu verbrauchen, die zu gefühlten 98% auf dem “Powerup Bug” beruhten, gaben wir dem Optipower BEC Guard u.a. das “Voltage Lockout”, in einer Ausführung, die den o.g. BECs während des Powerup über den Berg hilft. – Oh nein, auch das Voltage Lockout des BEC Guard wurde keinesfalls den Kontronik BECs auf den Leib geschneidert. Das hätte erfordert, nach Erscheinen einer On Voltage nach Powerup grundsätzlich sichere 200..500ms Wartezeit einzubauen, bevor man den BEC belastet. Das erfolgte nicht, das Voltage Lockout ist für jeglichen BEC, und die Praxis zeigt, dass es in seiner heutigen Implementierung bisher auch jedem KOSMIK/JIVEpro BEC langt, so weit “über den Berg” zu kommen, dass er den Rest der ca. 100ms “anständig” überbrückt, bis ihn sein Master endlich unter die Fittiche nimmt. Voltage Lockout: Warten, dass 5V überschritten werden (ca. 5,05V). Dann Wait von 2ms. Dann auf Ausgang durchschalten in einer Spannunsgrampe von ca. 2ms Laufzeit (Rampe: Die meiste Elektronik stirbt beim Einschalten.;)) Danach folgt die Ausgangsspannung der Eingangsspannung. Der BEC Guard trennt den Ausgang wieder vom Eingang, wenn ca. 3,5V unterschritten werden. (Neben dem Voltage Lockout hat der Guard jede Menge weitere Funktionen, – er sorgt für saubere Spannung und schützt vor Überspannung erdenklicher Höhe durch einen defekten BEC.)
Entscheidend ist, JEGLICHEN BEC Output via den BEC Guard zu führen, also “Master” und “Slave”! Das macht man entweder mit zwei BEC Guards, oder man schaltet Master und Slave parallel und führt sie durch einen BEC Guard. Gut dabei wäre, kein Y-Kabel zu verwenden, sondern einfach beide Kabel an den Eingang des BEC Guard zu löten. Wir haben extra breitere Pads am Guard dafür vorgesehen. –> Gut wäre ebenso, auch JLog, CVS usw. aus der sauberen Ausgangsspannung des Guard zu versorgen, sprich, ergo nicht mehr via JLog’s “KOSMIK Port” aus dem “Options Port” eines KOSMIK oder JIVE Pro! Auf jeden Fall muss man jeden Bypass der BEC Ausgangsspannung vermeiden, – man sollte zumindest die rote Leitung im Servokabel zum S.Bus2 oder S.Port eines Empfängers entfernen (Futaba, FrSky), wenn JLog weiterhin vom “Options Port” des ESC wie ein “TelMe” mit Betriebsspannung versorgt wird!
.
Achtung! JLog nicht mehr aus dem “Options Port” des KOSMIK/JIVEpro zu versorgen, ist zunächst eine empfehlenswerte Option. Tut man es nicht, könnte man sich einen Bypass um den BEC Guard herum legen, wenn man zusätzlich nicht die rote Leitung im Verbindungskabel JLog/S.Bus2,S.Port Port — Empfänger (Futaba) entfernte. JLog liefert hier +3,3V AUSGANGSspannung seines internen Spannungsreglers, um mehrere unterschiedliche Typen JLog-eigener Sensor oder ein Unidisplay mit Betriebsspannung zu versorgen. Der Bypass um den BEC Guard herum wäre dann: KOSMIK/JIVEpro Options Port –> JLog/(kleiner)Spannungsregler Eingang –> 3,3V Spannungsregler Ausgang –> S.Bus2/S.Port Connector –> Empfänger, FBL, R2 Buffer etc. Der ganze Effekt des “Voltage Lockout” des BEC Guard wäre dadurch aufgehoben!
Man kann man das JLog-Stromversorgungsproblem am einfachsten so lösen: Man zieht die rote Leitung JLog-seitig aus dem Servokabel zum Empfänger heraus und steckt sie auf den inneren (“gelben”) Pin (“Signal”) des “JIVE Port” von JLog. That’s it. SPEKTRUM: Der XBus des TM1000 versorgt ja JLog mit Spannung. Mit HiTec Telemetrie muss man JLog eh via den “JIVE Port” versorgen. Ist der JIVE Port anderweitig in Benutzung durch einen (alten) JIVE, dann zieht man eben dessen gelbe Leitung (am besten auch JIVE-seitig) und steckt hier die rote Leitung vom Empfänger in den Stecker.
Da der Optipower BEC Guard kein Chapter hat in diesem Handbuch, an dieser Stelle ein Hinweis:
Das “Voltage Lockout” des BEC Guard hat eine Einschaltspannung von knapp über 5V, die Ausschaltspannung beträgt ca. 3,5V. Die Einschaltschaltspannung wird nicht erreicht mit BECs von Kontronik’s JAZZ Serie, die liefern nur max. 4,95V! (Diese BECs sollte man eh nicht mehr verwenden! Die SMD Induktivität ist maximal gut für gefahrlose 1,5A, zumindest bei Kurzschluß hat man die 50%-ige Chance, dass sie durchbrennt. Im JAZZ 80 sind zwei dieser BECs auf abenteuerliche Weise parallel geschaltet. Das skaliert nicht! Geht einer der beiden BECs in die Knie, folgt zwangsläufig der zweite auf dem Fuße. Danach muss der Laststrom signifikant sinken, damit BEIDE BECs wiederkommen.)
Ein R2 Buffer (Supercaps) am Ausgang eines solchen BEC (ohne BEC Guard) bringt dessen Design Flaw besonders gern zur Wirkung: Abgesehen davon, dass es erst kürzlich einen KOSMIK BEC gab, der bereits bei 200mA Laststrom während der ersten 5 der ca. 100ms ohne Kontrolle nach Powerup sich so überlastet fühlte, dass der Ausgang nur am Schwingen war: Der Ladestrom des R2 Buffers ist einstellbar, Maximum sind 700..900mA. Das ist nicht viel, kann aber bereits zu viel sein für ein BEC mit solchem Bug, s.o. Aber außerdem: Die Ladestromregelung macht eine Elektronik im Buffer, – und auch diese Elektronik hat einen Mindestspannungsbedarf (Betriebsspannung). Bleibt der BEC nun darunter bzw. schwingt wieder unter das Limit, dann kann auch der maximale Ladestrom nicht mehr garantiert werden. Die Wirkung im fraglichen Unterspannungsbereich ist, dass mehr Ladestrom in die Kondensatoren geht. Was dann passiert, ist a) BEC exemplarabhängig, b) abhängig von der Natur anderer paralleler Lasten, c) abhängig vom momentanen Ladezustand der Caps und evtl. auch von deren Kapazität (25 oder 50F), denn der Ladestrom ist ja dann ungeregelt. Der BEC könnte zu schwingen anfangen, versorgte Elektronik funktioniert bzw. initialisiert nicht, z.B. ein FBL. Irgendwann hat sich die Ladespannung der Caps bei dem ganzen Affenzirkus hochgeschaukelt, die Ready LED des R2 Buffers beginnt, zu leuchten. Ein FBL wird dann trotzdem nicht initialisieren, weil es keinen sauberen POR (Power On Reset) bekam. Klemmt man nun den Antriebsakku ab und wieder an, wird alles sauber initialisieren, sozusagen wie von Geisterhand, – aber keinesfalls verwunderlich. Ein BEC Guard zwischen BEC und Buffer (und aller anderen Elektronik) bringt es in den Zustand, dass es immer und sofort funktioniert.
Und da wir uns schon in angrenzende Gefilde begeben mussten, – BEC Guard, Ultra Guard, R2 Buffer… So kann man sie zusammen verwenden. – Übrigens haben wir seit einiger Zeit eine neue Firmware für den Ultra Guard, was dem ermöglicht, seinerseits so einem Kontronik BEC “über den Berg” helfen zu können, – was außerdem auch in Setups mit zuviel Leitungs- und Kontaktwiderstand zuverlässig verhindert, dass SPEKTRUM Sats gleich beim Powerup das beliebte Blinken anfangen (nach Reboot). Der Ultra Guard wandelt sich nun zunächst in eine “dumme Batterie”, nachdem er eine adäquate Spannung (ca. 5V) nach Powerup sah. — Das könnte in besonders harten Fällen den Ultra Guard gegenüber dem Voltage Lockout des BEC Guard in Nachteil bringen, denn es könnte sein, dass 5V Aktivierungsspannung erst gar nicht erreicht werden, da der BEC ja seine Verbraucher sieht, mit dem BEC Guard aber erst mal nicht. (Unter diese Spannungsschwelle zu gehen, ist leider kontraproduktiv wegen der Einschaltwirkung durch Back EMF manuell bewegter Servos.) — Er stützt somit sofort. Erst ein wenig später bestimmt er die nominale R/C-Spannung, um danach in der gewohnten UG-Manier ultraschnell einzuspringen, wenn die R/C-Spannung schwächelt, – der “universelle Spannungsspachtel” angesichts dessen, dass die längst unzeitgemäßen Servosteckverbindungen immer noch mit unzeitgemäßen Kontaktwiderständen für signifikante Spannungsabfälle durch zeitgemäß hohe Servoströme sorgen dürfen. Hier ein Wirkungsbeispiel: vorher, nachher.
.
JIVE Pro
Im Gegensatz zum KOSMIK hat der JIVE Pro nicht nur einen einzigen “Options Port”, an den sich JLog als “TelMe” anschließen kann, es gibt auch noch einen Unterschied des Ports zu denen des KOSMIK:
Beim KOSMIK kommen als Betriebsspannung für TelMe und andere dort anzuschließende Geräte stabilisierte +5V heraus. Natürlich kann es auch damit Probleme beim Powerup des ESC geben, s.o. Beim JIVE Pro kommt hier aber nur einfach die BEC-Spannung heraus. Nun sieht es so aus, als hätte ein Pro gerne und relativ häufig noch einen anderen Bug: Die dort heraus kommende Betriebsspannung ist oft mal weit unter der aktuellen BEC-Spannung. Ein JLog (oder jedes andere Gerät) an diesem Port wird also gar nicht oder fehlerhaft seitens seiner Betriebsspannung laufen, zumindest wird die Gesundheit des Dateisystems der SD-Karte dabei auf’s Spiel gesetzt. Ein anderer häufiger Effekt ist, dass der Pro ab und an beim Powerup in den Program Mode geht, wenn ein JLog an seinen Options Port angeschlossen ist. Der Pro gibt sich dabei gewissermaßen selbst einen Befehl. Basis ist, dass jede Elektronik in Unterspannungssituation ein undefinierbares, nichtlineares, Ohmsches Gebilde ist, so auch JLog. – Ergo muss man zumindest für den JIVE Pro leider knallhart konstatieren: Der “KOSMIK Port” ist als Stromversorgungsquelle für JLog ganz zu vermeiden, stattdessen versorgt man ihn aus der BEC-Spannung vom Master/Slave Port via JLog’s “JIVE Port”, s.o. Das Verwenden eines Optipower BEC Guard ist dringend zu empfehlen, für JIVE Pro UND KOSMIK sowieso, denn er heilt das Powerup-Problem der BEC-Ausgangsspannung per “Voltage Lockout”.
.
.
Liebe Leute, gefühlte 98% der JLog-Supportcases gehen auf den BEC Design Flaw in KOSMIK und JIVE Pro zurück. Nun gibt es eine generelle Lösung, die wir (R2) sogar entwickelten und fertigen, es geht aber immer so weiter, wenn der Optipower BEC Guard und das ganze Thema von JLog/CVS Anwendern mit KOSMIK oder JIVE Pro nicht z.K. genommen wird…
Ich bin nun schon drauf und dran, dafür und für Optipower BEC Guard und ULTRA Guard ein extra Chapter zu eröffnen, – aber das ist nicht im Sinne des Prinzips zwischen R² und Optipower…
Ich möchte Euch hier noch auf andere Design Schwächen hinweisen, diesmal geht es nicht um Kontronik’s BEC, – andere Design-Fehler, die Euch ebenso in’s Bockshorn jagen können, – und mit denen der BEC Guard für den unbedarften USER sogar als Schuldiger erscheinen könnte:
Ausgerechnet R² selbst (eigentlich zum Glück), in Form unseres Mehmet, durfte das am Setup eines Test-Helis für ganz andere Zwecke feststellen:
Der Heli hat 400er Größe und sollte Align Servos verwenden, die Savöx herstellt. Ohne BEC Guard initialisierte manchmal alles, mit BEC Guard eher selten. Dann irgendwann beim Testen, Zonk, und das FBL war tot.
Was passiert, wenn man einen BEC strommäßig überlastet? Nun, das ist Design-abhängig, aber im allgemeinen wird er die Ausgangsspannung soweit reduzieren, dass sich der Maximalstrom einstellt, – und nicht einfach komplett abschalten. Die Spannung wird dabei nicht wirklich linear verlaufen, an einem Oszi wird man sehen, dass es oben auf der Spannung schwingt, aber relativ hochfrequent.
Durch den Design Flaw des BEC von KOSMIK bzw. JIVE Pro, nur während des Power-Up, erwirbt der eine parasitäre Schaltfunktion. Der Anwender sieht z.B.: Oops, die LEDs meines JLog gehen gar nicht an, der Rest ist auch so gut wie tot. Der normale User wird maximal mit einem Multimeter bewaffnet sein, Er misst und sieht z.B. ca. 2V. An einem Oszi würde er sehen, dass das nur ein integrativer Wert ist, in Wirklichkeit ist die Ausgangsspannung ein Sägezahn mit hoher Amplitude.
Nun kommt der BEC Guard in’s Spiel: Seine Funktionen sind vielfältig: Überspannungsschutz, spezifiziert bis 100V, aber in einem Test schützte er sogar noch gegen hochenergetische 1500V Impulse hoher Flankensteilheit (aus einem Gerät mit Tesla Coil). Er clamped (beschneidet) und “bügelt” die Spannung, ob nun der BEC selbst der Verursacher von Spannungsimpulsen ist, oder “Rückspannungen” von Servos, Back EMF. Eine seiner Funktionen ist aber auch das “Voltage Lockout”, und das ist das, was dem BEC von KOSMIK und JIVE Pro während des Power-Up über den Berg helfen kann. Klettert die BEC Spannung knapp über 5V, dann wartet er noch 2ms, hat die Spannung dann immer noch das Niveau, schaltet er die Eingangsspannung (BEC) durch auf den Ausgang. Das tut er zum Schutz der Verbraucher hinter ihm nicht abrupt, sondern in einer linearen Spannungsrampe, die ca. 2ms bis Maximum braucht. Das verhindert auch Überwingeffekte durch sog. “Blindkomponenten”, durch Kondensatoren im Zusammenhang mit induktiven Komponenten. — Das war der “Hin-Weg”. Es gibt aber auch den “Rück-Weg”: Fällt die BEC Spannung unter ca. 3,5V, schaltet er wieder ab, um zu verhindern, dass versorgte Elektronik “am Rad dreht”, was spätestens bei Unterschreiten von 3V i.allg. der Fall ist.
Aus dem “Voltage Lockout” resultiert eine mögliche Verhaltensänderung, wenn zuvor bereits eine unbemerkte Überlastsituation für die Spannungsgquelle (BEC) vorlag. Der Anwender, nur mit einem Multimeter bewaffnet, wird das evtl. dahingehend fehlinterpretieren, dass der BEC Guard der Problemverursacher ist, obwohl er ein vorhandenes Problem nur deutlicher (erstmalig) sichtbar werden lässt: Die BEC-Spannung kommt hoch, 2ms später wird sie innerhalb o.g. 2ms (Rampe) entsprechend “allmählich” belastet. Der BEC fühlt sich überlastet oder wird es tatsächlich, seine Spannung bricht wieder ein, weil seine Überstrombegrenzung zieht. Sinkt seine Ausgangsspannung dadurch unter ca. 3,5V, schaltet der BEC Guard wieder ab. Dadurch wird der BEC wieder komplett entlastet, seine Spannung geht schlagartig wieder auf Sollwert, BEC Guard schaltet wieder durch, …. und das ganze Spiel geht von vorne los. Ergebnis: Eingangs- und Ausgangspannung schwingen, ähnlich einem Sägezahn, und ein träges Multimeter wird irgendeine, aber viel zu geringe Gleichspannung vorgaukeln. (Dabei wird der BEC Guard selbst heiß, weil er für besagte Spannungsrampe immer wieder einen verlustbehafteten Quadranten durchläuft, – normalerweise nur 1x, hier bis zu 250x pro Sekunde.)
Die Ursache kann nun der BEC selbst sein, zu schwach, Regelcharakteristik ungeeignet (zu lahm, zu geringe Ripple Rejection), – sie kann aber ebenso gut im Verhalten angeschlossener Lasten (vornehmlich Servos) zu suchen sein bei Anlegen der Betriebsspannung.
Letzteres war hier der Fall. Diese Align Servos haben ganz offenbar einen Design-Fehler. Erscheint die Betriebsspannung, sind sie kurzzeitig so gut wie ein Kurzschluß. Faszinierend.., dabei verhalten sich gleichwertige Servos vom selben Hersteller, nur direkt unter seinem Brand verkauft (Savöx), nicht so. (..sie haben nur die andere bekannte Macke, dass sie bei Unterspannung auf Anschlag laufen) – Dass angesichts der Sägezahnbetriebsspannung das FBL während der Tests irgendwann den Geist aufgab (Mehmet war stinksauer), lag an seinem (zu) billigen internen Spannungsregler (LDO, linear) mit zu geringer Ripple Rejection. Des Regelung ist einfach zu langsam. Irgendwann schaffte er es, den Microcontroller per Überspannung zu killen, ohne selbst dabei kaputt zu gehen. – Vorher, ohne BEC Guard, war es natürlich dasselbe, Mehmet wunderte sich, warum es so oft nicht klappte mit dem Power-Up, warum sein Labornetzteil anstelle des BEC auch die Hufe streckte. Mit dem BEC Guard klappte es aber zuverlässig fast nie, und das Timing veränderte sich, 2+2 Millisekunden, das macht dann etwa 250Hz Sägezahnfrequenz abzgl. Verzögerungen seitens BEC.
(Heli war ein Dominator 450L, das böse Servo DS430M auf der TS, das DS525M auf dem Heck schien ok zu sein. BEC war erst das vom Roxxy960-6, dann vom YGE60, beide 3/5A, beide unschuldig. Das gekillte FBL ein MSH Brain. – Hier gab es nur eine saubere Lösung: Raus mit den DS430M. Stattdessen werkeln jetzt Savöx SH-0265. Für das gekillte Brain kam der eigentliche Anlaß des Tests rein, – ok, Mehmet hatte mehr Gründe, Spieltrieb, ich glaube, das nennt man “Hobby”. )
Ich habe das mal nachgestellt, indem ich ein Labornetzteil nahm, dahinter einen BEC Guard, dann die Strombebrenzung so einstellte, dass die Last am BEC Guard auf jeden Fall mehr Strom zieht bei eingestellter Ausgangsspannung des Netzteils. Das Netzteil wurde nicht auf Abschaltung sondern auf Strombegrenzung gestellt, – so, wie auch ein BEC i.allg. reagiert. Dann das Ganze noch so getunet, dass bei Strombegrenzung die Ausgangsspannung des Netzteils auf jeden Fall unter 3,5V fällt, der BEC Guard also wieder abschaltet.
Dann sieht man den Effekt sehr schön. Gelb ist die Ausgangsspannung des Netzteils, was den BEC simuliert, blau ist die Ausgangsspannung des BEC Guard, an dem die Last hängt. Man sieht auch sehr schön, dass die Strombegrenzung des Netzteils, und das ist, im Gegensatz zu einem BEC, vom linearen Typ und auch etwas mehr “High-Tech”, nicht mehr wirklich linear verläuft, sondern es gibt ein Schwingen auf der Top-Amplitude.
.
