AW: J-Log-Rund um die Briefmarke für den Jive
Steht im Manual und den einschlägigen FAQ hier.
Das ist nicht so einfach...
Der JIVE hat seine Limits, bei der Spannungsmessung, bei der Strommessung mit Shunts (Leiterzügen). Die korrigiert JLog nach Mittelwerten, die über etliche Exemplare von JIVEs gefunden wurden.
Viel komplizierter ist es beim Motorstrom: Was der JIVE da als Messwert herausgibt, ist so überhaupt nicht verwendbar. Imot, in Ausgabe durch JLog, ist das Ergebnis einer aufwändigen Berechnung aus dem Rohstromwert, den er vom JIVE bekommt. Der Grund dafür ist, dass das veränderliche Tastverhältnis und die sich ändernde PWM-Frequenz über die fixe Conversion Time des A/D-Wandlers im JIVE das rohe Messergebnis horrend verfälschen.
Außerdem wirken bei hohen Stromanstiegsgeschwindigkeiten die Low-ESR-Elkos, die den Innenwiderstand der Spannungsquelle aus Sicht des JIVE (und nur aus dessen Sicht) signifikant beeinflussen. Das ist aber Realität (bittere Realität für die FETs), etwas, was zw. JIVE und Akku gar nicht messbar ist.
Sicherlich spielt auch die Blindkomponente der Motorwicklung (Induktivität) eine gewisse Rolle.
Vergleichsmessungen mit einem externen Logger sind nur möglich, wenn man mit dem Gas im Mode 1 eine langsame Rampe abfährt, von 0 bis 100%. Dynamische Messungen aus Logs (also reale Flüge) sind im Stromverlauf nicht vergleichbar, also zw. JLog und Unilog oder JLog und EagleTree usw. Der Grund liegt hier ganz woanders: Alle "nativen Logger" integrieren die Messwerte vor Ausgabe, JIVE und JLog tun das nicht, um die Strompeaks möglichst real sehen zu können. So ein Integrator nivelliert alles, schneidet die Peaks ab, füllt die Täler, verschiebt im Zeitverlauf den Mittelwert.
Zurück zum JIVE: Die Shunts unterliegen einer gewissen Streuung, weil die Dicke der Kupferschicht der Platinen von Charge zu Charge nicht absolut supergenau identisch ist. Außerdem ist das Kupfer, das hat einen Temperaturkoeffizienten. Es gibt keine genauen Zahlen, aber die Summe der Streuungen+TC-Wirkung sollte stets unter 5% liegen, nach meiner Einschätzung im Mittel bei 1..2%.
Für die Richtigkeit des Processing des Motorstromes stehe ich gerade. Ich bin gerade dabei, nochmals zu überarbeiten. Bisher wurde in 7 Quadranten bearbeitet, jetzt (JLog2) werden es mehr als 15. In JLog2 habe ich mehr Speicher für solche Faxen deutscher Gründlichkeit.
Ich hatte bisher an zwei Stellen bzgl. Imot bewusst "geschludert":
- Ganz unten, da, wo die Sonne in einem Heli eh nie hinscheint.
- Ganz oben. Da war ich "shiny", ich hatte vor Erscheinen des JLog einen heiden Bammel, dass die Leute, die Logs ihrer integrierenden Logger gewohnt, und dann auch ohne die heftig peak-erhöhende Wirkung der Low-ESR-Elkos in den Integrator geschickt, mir das nicht abnehmen würden. Ergo habe ich ganz ganz oben bisher etwas gekappt.
Trotzdem stimmt es in Summe auch ohne die schamhaft verschwiegenen noch höheren Peaks (wenn PWM von wenig auf nahezu 100% in nullkommanix knallt), das beweisen die kumulativen mAh, die stimmen. - Bei den kumulativen mAh muss man sich vor Augen halten, dass ALLE Logger hier auf eigentlich dünnem Eis tanzen, denn sie messen ja nicht jeden Wert des Stromverlaufs, ergo gehen sie (fälschlich) davon aus, dass der letzte Stromwert bis zum Zeitpunkt der nächsten Messung anhält. "Native Logger" basieren einfach auf der integrierten Strommessung, das heilt etwas das Grundproblem, JLog macht das aber mit dem Strom, der, weil absichtlich ohne Integration, vergleichsweise irre rumwackelt, - und trotzdem stimmt es am Ende.
Mit JLog2 werde ich wohl das letzte Quentchen ungeschminkter Wahrheit, da ganz oben bei den Peaks bei hohen Stromanstiegsgeschwindigkeiten, dem "Volk" an die Backe nageln. Und aus verschiedenen Gründen, auch als "Lehrstück" zu oben Gesagtem, kommt Imot nun auch zusätzlich integriert. Beim Integrationsfaktor habe ich mich an Unilog orientiert. Also wird die Leistung auch zusätzlich ein zweites Mal als auf dem integrierten Strom basierend in's Log gegeben. Insgesamt sind es z.Z. 31 Datenwerte im Log. Untenrum (gaanz wenig PWM) habe ich auch rund gefeilt, eigentlich Schmuck am Nachthemd. Zusätzlich werden die Offsets zur Kalibrierung mittlerer Standabweichungen (Imot, Ibec) nun nicht mehr schlagartig sondern smooth angewendet. Damit hat man dann nicht mehr wie bisher einen Mittelwert von 0,4A bei Ibec im Log, wenn der BEC-Strom zw. 0 und marginal über 0 rumwackelt.
Sorry...
, - kurze Frage, lange Antwort...
---
Ach so, Messintervall: Das ist im Betrieb, Signalprozessor des JIVE kommutiert, nicht äquidistant. Im überwiegenden Falle alle 100ms, manchmal Zwischensteps (50ms), manchmal auch länger. Der JIVE sendet ja Pakete binärer Daten, es sind ca. 130 Messwerte, die aber nicht in ein Paket passen, weshalb teilweise mit virtuellen Datenarrays gearbeitet wird, die aus den realen aktualisiert werden. Das Timing bestimmt der JIVE allein über einen Timestamp in jedem Datenpaket.
JLog2 hat nun auch eine eigene Zeitbasis (alle 100ms), die er benutzt, wenn er keinen Datenstrom (Timestamps) vom JIVE sieht. Das machte sich erforderlich, weil es ja nun auch optionale eigene Sensoren des JLog gibt (1..5x Temp., 1x Drehzahl), die ein Anwender evtl. auch ganz alleine (o.JIVE) loggen will. Außerdem erfordert das Display der JETIbox (JETI-Telemetrie, wenn benutzt), dass die Telemetriedaten ständig gesendet werden, sonst fällt die JETIbox ganz schnell in's Timeout.
.... Ergo muss auch ständig gemessen/ausgewertet und OpenFormat-Records (LogView) gebildet werden, wobei auch gleich die JETI-Telegramme erzeugt werden.
Mich würde mal noch was anderes interessieren (habs mit der Suche nirgends gefunden): Wie genau und wie zuverlässig sind denn die internen Messungen des Jive ? Wie groß ist das Mess-Intervall ?
Das ist nicht so einfach...
Der JIVE hat seine Limits, bei der Spannungsmessung, bei der Strommessung mit Shunts (Leiterzügen). Die korrigiert JLog nach Mittelwerten, die über etliche Exemplare von JIVEs gefunden wurden.
Viel komplizierter ist es beim Motorstrom: Was der JIVE da als Messwert herausgibt, ist so überhaupt nicht verwendbar. Imot, in Ausgabe durch JLog, ist das Ergebnis einer aufwändigen Berechnung aus dem Rohstromwert, den er vom JIVE bekommt. Der Grund dafür ist, dass das veränderliche Tastverhältnis und die sich ändernde PWM-Frequenz über die fixe Conversion Time des A/D-Wandlers im JIVE das rohe Messergebnis horrend verfälschen.
Außerdem wirken bei hohen Stromanstiegsgeschwindigkeiten die Low-ESR-Elkos, die den Innenwiderstand der Spannungsquelle aus Sicht des JIVE (und nur aus dessen Sicht) signifikant beeinflussen. Das ist aber Realität (bittere Realität für die FETs), etwas, was zw. JIVE und Akku gar nicht messbar ist.
Sicherlich spielt auch die Blindkomponente der Motorwicklung (Induktivität) eine gewisse Rolle.
Vergleichsmessungen mit einem externen Logger sind nur möglich, wenn man mit dem Gas im Mode 1 eine langsame Rampe abfährt, von 0 bis 100%. Dynamische Messungen aus Logs (also reale Flüge) sind im Stromverlauf nicht vergleichbar, also zw. JLog und Unilog oder JLog und EagleTree usw. Der Grund liegt hier ganz woanders: Alle "nativen Logger" integrieren die Messwerte vor Ausgabe, JIVE und JLog tun das nicht, um die Strompeaks möglichst real sehen zu können. So ein Integrator nivelliert alles, schneidet die Peaks ab, füllt die Täler, verschiebt im Zeitverlauf den Mittelwert.
Zurück zum JIVE: Die Shunts unterliegen einer gewissen Streuung, weil die Dicke der Kupferschicht der Platinen von Charge zu Charge nicht absolut supergenau identisch ist. Außerdem ist das Kupfer, das hat einen Temperaturkoeffizienten. Es gibt keine genauen Zahlen, aber die Summe der Streuungen+TC-Wirkung sollte stets unter 5% liegen, nach meiner Einschätzung im Mittel bei 1..2%.
Für die Richtigkeit des Processing des Motorstromes stehe ich gerade. Ich bin gerade dabei, nochmals zu überarbeiten. Bisher wurde in 7 Quadranten bearbeitet, jetzt (JLog2) werden es mehr als 15. In JLog2 habe ich mehr Speicher für solche Faxen deutscher Gründlichkeit.
Ich hatte bisher an zwei Stellen bzgl. Imot bewusst "geschludert":
- Ganz unten, da, wo die Sonne in einem Heli eh nie hinscheint.
- Ganz oben. Da war ich "shiny", ich hatte vor Erscheinen des JLog einen heiden Bammel, dass die Leute, die Logs ihrer integrierenden Logger gewohnt, und dann auch ohne die heftig peak-erhöhende Wirkung der Low-ESR-Elkos in den Integrator geschickt, mir das nicht abnehmen würden. Ergo habe ich ganz ganz oben bisher etwas gekappt.
Trotzdem stimmt es in Summe auch ohne die schamhaft verschwiegenen noch höheren Peaks (wenn PWM von wenig auf nahezu 100% in nullkommanix knallt), das beweisen die kumulativen mAh, die stimmen. - Bei den kumulativen mAh muss man sich vor Augen halten, dass ALLE Logger hier auf eigentlich dünnem Eis tanzen, denn sie messen ja nicht jeden Wert des Stromverlaufs, ergo gehen sie (fälschlich) davon aus, dass der letzte Stromwert bis zum Zeitpunkt der nächsten Messung anhält. "Native Logger" basieren einfach auf der integrierten Strommessung, das heilt etwas das Grundproblem, JLog macht das aber mit dem Strom, der, weil absichtlich ohne Integration, vergleichsweise irre rumwackelt, - und trotzdem stimmt es am Ende.
Mit JLog2 werde ich wohl das letzte Quentchen ungeschminkter Wahrheit, da ganz oben bei den Peaks bei hohen Stromanstiegsgeschwindigkeiten, dem "Volk" an die Backe nageln. Und aus verschiedenen Gründen, auch als "Lehrstück" zu oben Gesagtem, kommt Imot nun auch zusätzlich integriert. Beim Integrationsfaktor habe ich mich an Unilog orientiert. Also wird die Leistung auch zusätzlich ein zweites Mal als auf dem integrierten Strom basierend in's Log gegeben. Insgesamt sind es z.Z. 31 Datenwerte im Log. Untenrum (gaanz wenig PWM) habe ich auch rund gefeilt, eigentlich Schmuck am Nachthemd. Zusätzlich werden die Offsets zur Kalibrierung mittlerer Standabweichungen (Imot, Ibec) nun nicht mehr schlagartig sondern smooth angewendet. Damit hat man dann nicht mehr wie bisher einen Mittelwert von 0,4A bei Ibec im Log, wenn der BEC-Strom zw. 0 und marginal über 0 rumwackelt.
Sorry...
, - kurze Frage, lange Antwort...---
Ach so, Messintervall: Das ist im Betrieb, Signalprozessor des JIVE kommutiert, nicht äquidistant. Im überwiegenden Falle alle 100ms, manchmal Zwischensteps (50ms), manchmal auch länger. Der JIVE sendet ja Pakete binärer Daten, es sind ca. 130 Messwerte, die aber nicht in ein Paket passen, weshalb teilweise mit virtuellen Datenarrays gearbeitet wird, die aus den realen aktualisiert werden. Das Timing bestimmt der JIVE allein über einen Timestamp in jedem Datenpaket.
JLog2 hat nun auch eine eigene Zeitbasis (alle 100ms), die er benutzt, wenn er keinen Datenstrom (Timestamps) vom JIVE sieht. Das machte sich erforderlich, weil es ja nun auch optionale eigene Sensoren des JLog gibt (1..5x Temp., 1x Drehzahl), die ein Anwender evtl. auch ganz alleine (o.JIVE) loggen will. Außerdem erfordert das Display der JETIbox (JETI-Telemetrie, wenn benutzt), dass die Telemetriedaten ständig gesendet werden, sonst fällt die JETIbox ganz schnell in's Timeout.
.... Ergo muss auch ständig gemessen/ausgewertet und OpenFormat-Records (LogView) gebildet werden, wobei auch gleich die JETI-Telegramme erzeugt werden.
)
Kommentar