mAh

Jeder “normale” Logger (den ich lieber “nativ” nenne) kann wegen des Kumulierens von Strommessungen über die Zeit nur so vorgehen: Er nimmt den zum Zeitpunkt n gemessenen Strom bis zur nächsten Messung zum Zeitpunkt n+1 als konstant an. Das funktioniert aber ganz gut. Der native Logger sieht den wahren Strom, der dem Akku entnommen wird.

Bei JIVE/JLog sieht das etwas anders aus: Der JIVE misst nicht den Strom, der primärseitig, also zum Akku hin fließt. Der Strom zerfällt als Input für JLog in drei Komponenten:

1. Motorstrom: Der für die mAh zur Basis zu nehmende Strom ist natürlich das Ergebnis der Umrechnung, nicht der Messwert, den der JIVE liefert. Enthält der Stromverlauf sehr viele Peaks mit hohen Stromanstiegsgeschwindigkeiten, haben wir gewissermaßen “Blindstrom” dabei, – Strom, der aus den Low-ESR-Elkos kommt, wobei später aus dem Akku ein Strom fließt, um die Elkos nachzuladen.

2. Primärstrom des BEC: Den misst der JIVE nicht, er misst den Ausgangsstrom. Der BEC ist ein Schaltspannungsregler (“Buck-Regler”), der Primärstrom hängt zwar vom Ausgangsstrom ab, ist aber auch eine Funktion des Verhältnisses aus eingestellter Ausgangsspannung zu momentaner Akkuspannung, dem Niveau der Akkuspannung, der Temperatur, des Wirkungsgrads und des  Designs. Der Wirkungsgrad wird von der Höhe der Akkuspannung und der Temperatur beeinflusst.

3. Strombedarf anderer elektronischer Komponenten des Stellers: Die kann man wegen der Verwendung von FETs in den Treiberstufen der drei Endstufen als “Grundstrombedarf” oder “Ruhestrom” definieren. Er ist aber abhängig vom Niveau der Akkuspannung und auch etwas von der Temperatur im Innern des JIVE.

Dazu kommt: Herr der Zeit ist der JIVE mit seinen Zeitstempeln. Die kommen, im Gegensatz zu den Verhältnissen eines nativen Loggers, nicht immer äquidistant. JLog errechnet jeweils die Delta Time zwischen zwei Kumulierungsschritten.

Der JLog hat also mit dem JIVE als “Messinstrument” in gewisser Weise nur eine virtuelle Basis, aus der er per Modell den Primärstrom (Strom aus dem Akku) hochrechnet.

Das funktionierte schon mit JLog1 ab Version 2.6 sehr gut, was die Treffsicherheit betraf. Vergleichsnormal war jeweils ein Unilog, der, mit seinem Shunt zwischen JIVE und Akku messend, den Primärstrom und damit die mAh auf direkte Weise bestimmt.

Mit JLog2 konnte das nochmals seitens der Genauigkeit verbessert werden. Die Abweichungen gegenüber Unilog lagen in Tests bei max. 0,266%, waren ansonsten i.Allg. unter 0,1%.

Allerdings ist der betreffende Shunt zur Strommessung im JIVE ein Stück Leiterbahn auf einer der beiden Platinen. Da die Dicke der Kupferschicht fertigungsbedingt etwas variiert, schwankt der Widerstandswert des Shunts auch etwas über die Exemplare der JIVEs. Daher gibt es ab Firmware-Version 3.2.2 nun die Möglichkeit, die Strommessung im Loggger via den Konfigurator JLC bis zu +/-15% zu “kalibrieren”. Das wirkt auf den Wert des Rohstromes, wie er vom JIVE kommt. Daraus erfolgt eine aufwändige Berechnung des Messwertes “Imot”, der im Log, im Livestream und Telemetrie erscheint und in die Ermittlung der “mAh” eingeht, wobei die Umrechnung im Wesentlichen durch “PWM” geführt ist. Es gibt also keinen linear proportionalen Bezug zwischen dem Prozentwert der Kalibrierung und deren Wirkung auf das Endergebnis der mAh. Man muss eine passende Kalibrierung erfliegen, wobei eher weniger Korrektur in “%” wahrscheinlich mehr prozentuale Wirkung auf mAh zeitigt.

Es verbleiben noch drei theoretisch mögliche Fehlerquellen, die unter gleichen Bedingungen (die es nie gibt ) gewisse Schwankungen bewirken könnten:

1.  Der TK des Shunts. Eine Kompensation kann bei Bedarf im JLog nachgepflegt werden, wir kennen die Temperatur der FETs, und das wird im Wesentlichen auch die des Shunts sein.

2.  Schwankende Distanzen der Timestamps vom JIVE:  Da gibt es zum Einen sog. “Doubles”, zwei Messwertpakete unter demselben Zeitstempel. JLog fügt dann einen 50ms-Zwischenschritt ein, um die Daten zu differenzieren. Das hat aber keine negativen Auswirkungen auf exakte mAh.  -  Wenn der Signalprozessor im JIVE in einer bestimmten Weise mit der Kommutierung beschäftigt ist, können mal stochastisch einige Zeitschritte ausfallen, die Datenpakete gehen dann zeitlich auf größere Distanz, nur kurzzeitig. Ab einer bestimmten Distanz wird es kritisch seitens des oben beschriebenen Prinzips, nach dem alle Logger die mAh berechnen. Das “Loch” (Delta Time) wird u.U. zu groß, man nimmt zu lange einen “Stromberg” oder ein “Stromtal” als konstant an. Die Granularität der Abtastung kann kurzzeitig mal unter die Anforderungen des Änderungsaufkommens des Stroms gehen.

3.  Teile der Stromspitzen sind in ihrer Höhe den Low-ESR-Elkos geschuldet, dem geringen Innenwiderstand der insofern teilweise virtuellen Spannungsquelle. Was aus den Elkos kommt, sehen wir, was in diese nachgeladen wird, nicht, müssen wir ja nicht. An sich ist das energetisch Peanuts, die Peaks sind entsprechend schmal, nur werden sie natürlich in dieser Höhe auf die Zeitdifferenz zwischen zwei Kumulierungschritten im Berechnungsmodell ausgedehnt.

Summasummarum ist aber klar, dass diese Fehlerquellen, die im Handling des JIVE-Protokolls durch JLog in den Punkten 2 und 3 nicht kompensierbar sind, auf das Gesamtergebnis der mAh nur marginalen Einfluss haben können.

Übrigens, weil JIVE/JLog ja die Messwerte nicht integrieren: Es macht im Ergebnis überhaupt keinen Unterschied, ob man den Strom vor dem Kumulieren integriert. Das integriert sich selbst, was ich anhand eines Peaks zu lange als konstanten Strom annehme (zwischen zwei Zeitpunkten n und n+1), das nehme ich im Gegenzug auch bezüglich einen Minimalwertes zu lange als konstant an. Das Kumulieren der Strommesswerte anhand von Zeitschritten ist selbst ein gigantischer Integrator.