Vorangestellt: Gemessen wird mit einem Shunt, der eine Leiterbahn ist, unkalibriert. Sein Wert schwankt über die Exemplare der JIVEs, weil die Dicke der Kupferschicht von Platine zu Platine fertigungsbedingt etwas streut. Man geht davon aus, dass das bis zu 10% ausmachen kann, inklusive eventueller Sonderausreißer, die z.B. durch einen Wechsel des Platinenherstellers zustande kommen könnten. Kupfer hat einen TK, ob der durch die Firmware des JIVE kompensiert wird, ist nicht bekannt, wahrscheinlich eher nicht (siehe nun hier). - JLog2 ab Firmware-Version 3.2.2 und JLog1 ab 2.81 erlauben daher, Rohstrommesswerte, wie sie vom JIVE kommen, zu “kalibrieren”. Anhaltspunkt der Kalibrierung und gleichzeitig Grund der Einführung dessen sind die durch den Logger kumulierten mAh, hier kumulieren sich auch am Ende sichtbare Fehler.
Zuvor müssen die Messwerte des JIVE “genießbar” gemacht werden. So, wie diese im Rohzustand aussehen, sind sie nicht verwendbar. Grund: Tastverhältnis und Frequenz der PWM, die zum Drehzahlstellen verwendet wird, sind in weiten Grenzen veränderlich. Dem überlagern sich eventuell auch die Kommutierungswechsel, weil mit nur einem Shunt gemessen wird, in der Sammelschiene des Stellers gegen Minus des Antriebsakkus. - Das Ganze interagiert nun mit der fixen Sample Time des Analog/Digitalwandlers eines der beiden Microcontroller im JIVE.
Die Polzahl des Motors spielt ebenso noch eine kleine Rolle, wie vermutlich auch teilweise die Induktivitäten der Wicklung.
Das On-the-Fly-Umrechnen in “genießbare” Motorstromwerte erfolgt mit einem Potpourri von Exponentialfunktionen höherer Ordnung, wobei dies in Quadranten erfolgt, jeder Quadrant folgt einer anderen Formel. Diese Quadranten überlappen sich teilweise, es gibt auch “Superquadranten”, die alle bzw. mehrere Qudranten (deren Formeln) zusätzlich überdecken. In JLog1 bis zur Firmware-Version 2.7(1) erfolgt das in sieben Quadranten, in JLog2 und JLog1 ab 2.8 in 16 Quadranten.
Das 16-Quadranten-Modell ist granularer in allen Bereichen, es beseitigt vor allem eine gewisse, mit JLog1 zuvor in Kauf genommene Ungenauigkeit “ganz oben” und “ganz unten”. Das “Ganz-Unten” ist eher Schmuck am Nachthemd, das “Ganz-Oben”, etwas zu wenig errechnend im ursprünglichen JLog1, hatte ich absichtlich so gelassen, weil ich regelrecht Angst hatte, die Werte würden von den Anwendern nicht angenommen werden, waren sie doch die Messungen von Loggern gewohnt, die alle integrieren, – Spitzen abschneiden, Täler füllen. - Es gibt nämlich noch einen weiteren Aspekt, der die weitaus realer geloggten Strom-Peaks teilweise so viel höher erscheinen lässt als mit einem nativen Logger vor dem Steller: Die Low-ESR-Elkos im Eingang des Stellers verringern den Innenwiderstand der Spannungsquelle im dynamischen Sinne teilweise geradezu dramatisch, was ja deren Zweck ist (um Schaltverluste in den FETs zu vermindern). Der messende Shunt sitzt zwischen diesen Elkos und den FETs, sieht somit die Peaks in ihrer für die FETs realen Höhe, während das ein Logger (Shunt, Hall-Element) “draußen” gar nicht sehen könnte. - Das Imot Processing erfolgt im Wesentlichen PWM-geführt, der PWM-Wert wählt den Quadranten.
Die folgenden Bilder geben mal einen Eindruck, wie anders der durch den JIVE gemessene Strom nach Höhe und im Verlauf zu dem aus dem Processing fallende ist. So ein Vergleich erfolgt, indem man eine langsame Gasrampe durchfährt, dabei jeden dynamischen Effekt der Low-ESR-Elkos eliminierend. Zeitgleich misst man mit einem kalibrierten(!) Logger zwischen Steller und Antriebsakku. Die Ergebnisse werden hinterher anhand der Drehzahl übereinander gelegt. Die Snapshots sind Kurvenvergleiche aus Excel, stammen noch von der JLog1-Vorversion “KLog”. Man sieht sehr schön, wie das weniger granulare 7-Quadrantenmodell “unten” und “oben” systematisch etwas Abweichung einbaut, teilweise auch im mittleren Bereich. - Das sind genau die Bereiche, in denen nun das 16-Quadrantenmodell “mit Deutscher Gründlichkeit” für Genauigkeit und absolute Kurvendeckung zur Messung außen sorgt. Nur eine eventuelle Parallelverschiebung der Stromkurve durch streuende Shunts muss/kann mit der “Imot-Kalibrierung” in JLog korrigiert werden, konfigurierbar mit JLC.
Wahnsinn, oder?
Das Eckige ist teilweise auf ein manuelles Abfahren der Gaskurve zurückzuführen, weil nicht immer ein Rampengenerator zur Verfügung stand. Dabei haut dann auch gleich die Dynamik durch die Low-ESR-Elkos in’s Kontor. Für das Bearbeiten des 16-Q-Modells hatte ich es einfacher, konnte den Motortester “SAC” verwenden, der verschiedene, parametrisierbare Gaskurven generiert und gleichzeitig als nativer Logger mit kalibriertem Shunt und anderen Sensoren agiert – sowie JLog in seiner Software implementiert(!), sodann alles zusammen auf einen JLog1 im LOGmode 2 als OpenFormat schreibt bzw. als Livestream ausgibt. Man hat also gleich die beiden Kurven im LogView, sogar während der Aufzeichnung aus dem Livestream, so wie hier ausschnittsweise:
(“SAC” ist eine andere Entwicklung von mir, leider wird das Ergebnis, ein Labormuster, nun nicht mehr vom Initiator gewollt..)
Falls nun jemand fragt, wie denn das Formelwerk des Imot Processing zustande gekommen ist: Tja…, ehrlich gesagt, so richtig nachempfinden kann ich das selbst nicht mehr. Die Grundidee lieferte Excel mit seinem Formelgenerator. Der Rest war systematische Geduld und Spucke und jede Menge Sitzfleisch. Die Idee mit den Gasrampen und die, Excel zu bemühen (das mir, als alter Excel-Muffel ), hatte Sebastian.
(Und bevor jemand fragt, wie denn nun der JIVE mit solchen Messwerten die Stromüberwachung machen kann: Das ist nicht bekannt, aber man kann davon ausgehen, dass dessen Firmware die Werte anhand der PWM insofern berichtigt, dass sie als Basis dienen können, ohne dass das Monitoring in Software u.U. einem Irrtum aufsitzen könnte.)
Okay, hier wird systembedingter Messwahnsinn in logging/telemetrie-geeignete “Richtigwerte” gewandelt.. Gibt’s denn auch was rein positives dabei? Jawoll, gibt es: Der im JIVE verwendete ADC wird glücklicherweise so betrieben, dass dessen Sample Time es uns ermöglicht, die Amplituden der Stromspitzen in realen Werten zu sehen. Also, Messgenauigkeit ist vorhanden, und das sogar im dynamischen Sinne des Stromverlaufs. Es wäre nun Frevel gewesen, so ein Kleinod mittels Messwertintegration in solche “sexy geschwungenen”, aber im Zeit-Amplitudenbild wenig realen Kürvchen zu verwandeln. Ergo produziert JLog Strom-Logs, die sozusagen wie ein “irres Gewackel” im Vergleich zu den Logs integrierender Logger (was alle anderen Logger im Modellbaubereich sind) aussehen. Hinsichtlich “I-Motor” ist das optisch noch gut verdaubar, bei “I-BEC” aber wird’s nervig, sogar nichtssagend, wenn man nicht die Zoom-Funktion von LogView ausgiebig und zielgerichtet benutzt. - ”I-Motor” ist eine böse, schonungslose Sache, zeigt es uns doch das, was die FETs im Steller zu knabbern kriegen, – abzüglich dessen, was wir evtl. doch nicht sehen, nur mittels eines sauteuren Speicheroszilloskops zu sehen bekämen(?)
Um das oben Dargestellte nun besser verstehen zu können und das Interpretieren der Peaks leichter zu erlernen (deren Sichtbarkeit ist ja ein Novum für Logger im Modellbau, weil aus dem Steller stammend), liefert JLog2 auch “I-Motor/Int”, wobei “I-Motor” einer Integration zugeführt wurde, deren Zeitkonstante in etwa der von Unilog entspricht. Wir sehen hier gleich, die Peaks reichen nicht so hoch, die Täler sind nicht so tief. (Trotzdem reichen die Spitzen durch die Wirkung der Elkos immer noch höher.) Der Stromverlauf ist ruhiger, entspricht aber nicht mehr der Realität des Stellers. Bzgl. Peaks im realen Zeitverlauf müssen wir eben immer in Betracht ziehen, wie lange denn so ein Peak seine Amplitude hielt! Nach Power=U-BAT * I-Motor betrifft das auch die Peak-Leistungen. Um den Antriebsstrang seines Modells auf einen Blick zu quantifizieren, sind dann eher “I-Motor/Int” und entsprechend “Power/Int” geeignet. Die realen “Wackelwerte” dienen uns vor allem durch Hinein-Zoomen der Forensik: War da eventuell eine Fehlkommutierung, sollte ich besser KSA-Modus einschalten?
Nach diesem kleinen, ansatzweisen Ausflug in das Innenleben des JLog wünsche ich weiterhin: Happy Logging!
Ach ja: Und bei offensichtlichen Abweichungen, meist bemerkbar via mAh, nicht vergessen, ImotShunt im JLC zu benutzen!
Um den Antriebsstrang seines Modells auf einen Blick zu quantifizieren, sind dann eher “I-Motor/Int” und entsprechend “Power/Int” geeignet. Die realen “Wackelwerte” dienen uns vor allem durch Hinein-Zoomen der Forensik: War da eventuell eine Fehlkommutierung, sollte ich besser KSA-Modus einschalten?