Was Dir wichtig ist, bekommst Du auch, Ingbert. Das KOSMIK-Thema ist geritzt, ich muss es nur noch auf den Prototypen übertragen, den Linus bald schicken wird.
---------------------------------------------
Ich bin noch die Antwort auf eine Frage schuldig, die ich selbst stellte bzw., die mir in Helifreak gestellt wurde:
Was ist der Unterschied zwischen Imot, Ibattery und ImotPeak im Logging?Nun.. Ich schreibe das absichtlich nicht auf der HP, und ich muss mich entschuldigen, dass ich immer so "direkt" bin:
Das ist "eine Show für's Volk", oder: Ich ziehe mir nicht die Hose mit der Kneifzange an.
Imot ist der in der Motorphase gemessene Strom. Ich gehe mal davon aus, das der soweit stimmt, dass hier nicht solche Hausnummern zu späterem aufwändigem Data Processing (JLog) kommen wie beim JIVE. Die Voraussetzungen hat man allemal, der Prozessor STM32 im KOSMIK hat um Größenordnungen mehr Performance als der veraltete Signalprozessor von TI (EOL) im JIVE, dazu eine um ein Vielfaches höhere Taktfrequenz und ergo auch einen viel schnelleren A/D-Wandler. Ich nehme jedenfalls an, dass hier nicht so dramatsch die Conversion Time des ADC mit der momentanen PWM (Duty Cycle, Frequenz) interagiert wie im JIVE.
Also:
Imot ist DER Wert, - und kein anderer.
"Und kein anderer"? Warum?
Tja.. Im KOSMIK sind 3 Shunts, und zwar in den 3 Motorphasen, der BEC hat noch einen Shunt für Ibec, - aber es gibt keinen Shunt, der den Gesamtbatteriestrom vor den Low ESR Elkos misst!
Warum in den 3 Motorphasen? Nun, es heisst, der KOSMIK mache über das erste Drittel der PWM FOC (Field Oriented Commutation, sinusförmige Modulation). Das könnte durchaus sein, der Anlauf mit dem KOSMIK sieht danach aus. Allerdings kann der STM32 allein so was nicht über das gesamte PWM-Band, dazu hätte es eines speziellen ASICs bedurft, den es nicht gibt im KOSMIK (der übernimmt die phasenversetzte Sinusmodulation der PWM auf den 3 Motorphasen). Möglicherweise ist das keine "Sparnummer", sondern wohlüberlegt: Will man Highpower, und dabei nicht den Zwang, ESC/Motor-Kombinationen handhaben zu müssen, dann hat Blockkommutierung durchaus Vorteile.
Die 3 Shunts sind eine Entscheidung des Designers, hätte nicht sein müssen, ginge auch mit nur einem Shunt. Dass es drei sind, ist wohl dem "Barfuß-FOC" geschuldet.
Also: Woher kommt denn nun
Ibattery?
Kurze Antwort: Nirgendwoher, aus der Trickkiste, kann daher auch nicht wirklich stimmen.
Ibattery ist offenbar nur eine Umrechnung von Imot anhand der momentanen PWM (Duty Cycle). Man schaue sich mal in der Grafik den Verlauf von Imot (pink Kurve), Ibattery (grüne Kurve) und dazu den der PWM (gelb) an. Ist PWM 100%, fallen beide Kurven zusammen.
Bleibt noch
ImotPeak..
Tja.., das fand ich dann doch schon etwas "mutig".., daher rührt meine etwas unfeine Formulierung mit der "Hose" und der "Kneifzange".
Ich hätte nun gedacht, man setzt einen Integrator (Tiefpass, ein "Stoßdämpfer, sozusagen) auf den gemessenen/bearbeiteten Imot (sieht auch etwas nach Integration aus), macht die Stromkurve im Log weniger "fickrig", mehr "sexy", - und gibt den unintegrierten Wert als ImotPeak raus.
Allerdings.., so ist es wohl doch nicht so richtig: Es haut fast genau hin: ImotPeak=Imot*sqrt(2)
Der nur amplitudenversetzte Verlauf der 3 Stromkurven zeigt ganz deutlich die Scharade. Allein schon die Low ESR Elkos im Eingang hätten sonst phasenmäßig andere Verläufe gezeitigt, ein Software-Integrator ebenso, also unterschiedliche Steigungen im selben Zeitpunkt.
Nun wundert's mich nicht mehr, dass mein erster Blick auf den Verlauf der Werte, gerade bei konstantem Gas und konstanter Belastung, soviel Skepsis in mir hervorrief.
Bleibt noch: Der Primärstrom wird also doch nicht gemessen, - also wie im JIVE. Somit hatte der Designer bzgl. des anteiligen Primärstroms (batterieseitig) des BEC zwei Möglichkeiten:
a) Er rechnet diesen hoch und um anhand:
... Sekundärstrom Ibec
... Verhältnis momentane Ubec zu Ubat
... Bekannter mittlerer Wirkungsgrad und seiner Abhängigkeit vom Niveau der Eingangsspannung Ubat und der Temperatur tBEC
(So mache ich es mit JIVE/JLog.)
b) Er pfeift auf die mAh, die der BEC verbraucht, da sie eh relativer Peanuts sind im Verhältnis zu den mAh durch den Motor. Evtl. setzt er einen emprischen Korrekturfaktor nach oben an, addiert einen hochgerechneten durchschnittlichen Verbrauch durch den BEC.
Offenbar hat man sich für b) entscheiden. Der BEC hat keinen variablen Anteil an den mAh.
Conclusion?
Nun.. Der KOSMIK ist als ESC sicher das momentan beste, was man auf dem Modellbaumarkt bekommt.
Der BEC ist im Vergleich zu anderen (außer HV²BEC) auch das Beste, er ist aber eigentlich auch "von der unteren Stange". Wenn man vom Machbaren ausgeht, aber auch von den heranwachsenden Anforderungen durch den massiven Einzug von HV-Servos (Peakströme und deren Wirkung auf einen "old-school" synchronen BUCK, hohe und energiereiche EMF), dann ist er nicht das Non-Plus-Ultra.
Worum es hier eigentlich ging: Logging und Telemetrie sind mit der heißen Nadel gestrickt, kann man nicht anders sagen.
Nach einem etwas "unglücklichen" Verlauf der Kommunikation mit Kontronik zu dem Thema (Anbindung von JLog), muss nun auch JLog mit dem leben, was die Kelle gibt, - sprich, als "TelMe", - aber auch als "SD-Sniffer" (die in den Logfile gehenden Daten abgreifend), was ich eigentlich noch als Variante 2 vor hatte. Das werde ich nun wohl lassen, denn außer Ubec und Gas würde man nichts weiter gewinnen. -- Allerdings wäre wohl auch eine "native Anbindung" von JLog nicht besser dran gewesen. Ich glaube nicht, dass der Designer mit sich über die Entstehung ausgegebener Werte hätte diskutieren lassen.
Anmelden
Registrieren
FAQ
Suche
