Nur für JLog2.5, 2.6 zutreffend – keine Unterstützung des KOSMIK durch JLog2!
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.
Die Firmware des KOSMIK muss wenigstens 4.0 sein!
Nach seinem Powerup muss KOSMIK einmal einen Gasimpuls gesehen haben, bevor er Telemetrie sendet!
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.
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.
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 die Polzahl mitteilen. 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 die Polzahl des Motors. 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. des Ratio (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.