J-Log.eu - Forum

https://www.rc-heli.de/board/showthread.php?t=259672
Lass mal den Logfile rüberwachsen, - es sei denn, Du bist ein Unix (Linux) Freak.

Leider kann ein Logviewer die kritischen Zeilen im Log nicht lesen, weil der Comment falsch vom Log Record getrennt ist. Trenner ist nicht "//", sondern ein White Space, " ", z.B.
Setzt man vor das "//" überall ein Space, oder ersetzt es durch Space, dann sind die heißen Zeilen auch lesbar. Leider sind die heißen Sachen alle kommentiert, dadurch für einen Viewer ungültig.

_________________
Tom

Falsch verstanden.

KOSMIK (JIVEpro habe ich nie seziert):

In jeder Motorphase gibt es einen Shunt Widerstand. Das wird gebraucht, weil man im Anlauf FOC (Field Oriented Commutation) macht. Ok, zwei Widerstände hätten auch gereicht.
Der Spannungsabfall über einem der Widerstände ist das Maß für "Imot".
Sofern man die Entkopplung zwischen PWM Duty und Frequenz einerseits und Conversion Time des ADC andererseits richtig gemacht hat, ist das der Motorstrom.

Auf der Batterieseite wird gar nicht gemessen.

Um nun aber auch Ibattery ausgeben zu können, hat man die Peaks offenbar wegintegriert.
Nun ist die Rechnung einfach Imot * PWM/100 = Ibattery
Durch Kumulieren auf Ibattery ermittelt man die mAh, ähh, Ah. Das haut hin.

Was nicht hinhaut, ist Imot im Averaging. Das Ergebnis über die Zeit, in mAh, in viel zu hoch.
Grund ist offenbar, dass man die Messung in dieser einen Phase über 100% der Umlaufzeit stretcht.
Heißt: Die Höhe des Stroms stimmt, allerdings nur in der integrierten Form, die Peaks fehlen. Der Verlauf des Stroms stimmt nicht, weil eine Phase für alle drei genommen wird.

Tja.. Nun wollte man aber die Peaks auch ausgeben.. Mmn unnötig, es so zu machen, aber witzigerweise multipliziert man einfach: Imot * 1.79 = ImotPeak. Das ist blanker Fake, wenn auch als "reine Schätzung" nicht realitätsfremd.

Ein Anwender bemerkte, dass das Average von Imot viel zu hoch ist im zeitlichen Verlauf (mit LogView feststellbar, z.B.).
Er ließ nicht locker, man weiß ja, dass Tom immer Wünsche erfüllt, der Hirsel..
Daher setzte ich dann Ibattery statt der JLog-eigenen Imot-Integration im Log ein als ImotInt. (Imot kommt ja bereits integriert)
Den absoluten Maxwert (kann nur steigen) ImotMax ersetzte ich mit ImotPeak. ImotPeak ist zwar rein rechnerischer Fake, keine Realität, aber die ungefähre Höhe bezweifle ich nicht (aus Erfahrung). Kontronik wollte wahrscheinlich unbedingt zeigen, dass der Maxstrom durch die FETs höher ist als der Strom aus der Batterie. Ich will das auch, also logge ich deren ImotPeak auch.

In die Telemetrien geht weiterhin Imot seitens JLog.

Da der ESC als TelMe nur Imot anbietet, nur der KOSMIK loggt auch die beiden anderen Werte, errechnet JLog analog aus erhaltenem Imot:
Ibattery = Imot *PWM/100
ImotPeak = Imot * 1.79

Klarer?
Es ist nichts grundsätzlich falsch, was die Höhe der Werte betrifft, nur gibt es eben keine konkrete, echte Realität in ImotPeak, - und Imot wurde diese Realität wegintegriert.
(Es wird vielleicht noch einen anderen Grund geben, dass man sich für grundsätzliches Integrieren entschied, auch nicht den unintegrierten Strom als ImotPeak ausgeben wollte: Die Resolution der Messungen beträgt nur 1.0A. Das sieht "ehrenrührig" eckig aus im Log, .. und man loggt ja, im KOSMIK.)

_________________
Tom

Rico, ich schmeiße es hier rein, weil halb RCH ja bereits involviert ist:

Du gabst mir zwei Logs: vom JLog2.6 (oder 2.5?), vom KOSMIK.

Ich dachte, wenn man die Kommentarfehler im KOS-Log beseitigt, könnte man evtl. noch mehr lesen, aber das brachte hier nichts, weil der ESC urplötzlich ein Problem sah, daher vorher keine Kommentare anhing.
Vor Bereinigen;

Nach Bereinigen:

Man sieht, das bringt hier nix, weil nur ein Standardkommentar ab und zu, - dann Peng!

Gut aber, dass JLog auch loggte, auch wenn er leider weder Gas noch Ubec bekommt.

KOSMIK:

Sprich, weniger als 1 Sekunde nach dem Ereignis startete er einen neuen Logfile.

Er hat aber weitergesendet als TelMe, - JLog bekam es fortlaufend. Wir können daher sehen:
Der KOS hat zwar das Logging restartet, aber er hat nicht rebootet! ...wohl aber einen "Warmstart" gemacht, weil er unmittelbar und sofort den ESC reinitialisierte. Irgendwas (drehte noch büsken?) hat ihn aber gestört dabei.

Tja.., nun zu den Logs..

Att #1: KOS Log im Überblick
Att #2: KOS die kritische Phase

Att #3 und 4 von JLog: Im Prinzip dasselbe, nur, dass hinten dran die restliche Session geloggt ist.
(Die Werte an JLog sind nicht ganz identisch mit denen im KOS Log (Jlog sieht peak 311A, peak Batterie ist 272A, der KOS loggt 276 Batt.), offenbar unterschiedliche Momentanwerte.)

-------------

Tja.., also.. Das Setup ist schon äußerst Merkwürden..

Der ganze Spass dauerte nur 50 Sekunden.

Die Basis-PWM ist nur 52%, bewegt sich kaum (max. 58%), die DZ ist auch nahezu konstant zwischen 1350 und 1400 Rotor (14000 Motor).
Dafür bewegt sich der Strom wie wild und bis 200A, - und die DZR holt alles aus dem Timing (Att #5).

Schon mal ziemlich ulkig..

Gas war bisher 52% (nur), dann schaltet man auf 76%.

Was jetzt passiert, war am bisherigen Log vorherzusehen:

PWM geht hoch in einer Rampe (logischerweise) auf peak 90%, die Rotordrehzahl steigt auf 2030, - der Strom tut natürlich das Seinige: von Peak ca. 200A auf 297A. (Ich sehe gerade, ImotPeak ist nur 437A, * Wurzel 2 (ungefähr). Hat man etwas geändert, oder fallen die beiden Werte zeitlich auseinander?)
Der ESC, nichts überhitzt, Batteriespg. steht beneidenswerterweise wie eine Eins, - ist bis eben völlig entspannt.
Dann wird seine innere Schmerzgrenze von 300A erreicht und genügend lange gehalten, die Tendenz ist ja eher, noch etwas höher zu wollen.
Da sagt der ESC, ganz plötzlich, aber auch verstehbar: Ende Gelände, mir zu heiß, nix Warnung, könnte ja auch was Schlimmeres sein (Motor spuckt die Eingeweide aus), - ich schalte ab!

---------

Nun fragt sich der Laie: Ist denn das normal, das Setup des Helis? Ist da alles koscher, oder steckt da ne tote Ratte im Getriebe? (schwergängig oder falsche Untersetzung?)
Hat da der KOS-Owner an den Reglerparametern gedreht?

Jedenfalls, so wie das Teil sich mit nur 50% PWM bereits in Gratnähe bewegte, war die Flugphase mit mehr als nur 50% Gas sozusagen der eingebaute Suizidschalter.

---
535mAh in nicht mal 50 Sekunden. Nach 6Min wäre der Akku leer gewesen (att#6).

---
Dass er erst mal das Autotiming verwendet, PWM sich aber kaum bewegt, ist nicht ungewöhnlich, weil die Bakterie echt ein Wunderding ist (kalt, wie sie wahrscheinlich war).
Verwunderlich ist
- Peakströme bei PWM an der unteren Grasnarbe bzw. minimalen PWM-Änderungen
- die Drehzahl bei nur 76% Gas
- wiederum der Peakstrom durch befehlsgemäßes Erhöhen der DZ. Natürlich steigt dabei der mittlere Strom, aber muss denn der Strom auf dem Wege dorthin gleich so steil steigen? Offenbar schon, siehe erster Anstrich..
Die Batterie ist der Hammer, sie wirkt nicht als dämpfendes "Kissen".
Wo würde denn das enden bei Vollgas? Doch wohl irgendwo oberhalb 350A, - dann in Belastungsspitzen bis 500A. ...und welche max. Kopfdrehzahl hätten wir dann, 2400?
......Ich glaube daher, - meine momentane Theorie, - entweder ist die Untersetzung zu schwach, oder wir haben hier einen "modded motor", der zumindest im Zusammenspiel mit diesem ESC zuviel Drehmomenteinsatz per zuviel PeakStrom einbringt. Man sollte die Kirche im Dorf lassen, oder erst den passenden ESC bauen, bevor man Kupfergräber ohne Limit macht.
K.A., vielleicht hätte dieser Parameter "Innenwiderstand" des ESC Anpassung bringen können. Geht der ESC moderater mit Autotiming und PWM um, kriegt er auch nicht soviel an die Backe von einem Kupferwunder, die harte Batterie on top.

Mmn haben wir hier den KOS in allen Belangen in die Ecke getrieben:
1. Motor mit sehr geringem Innenwiderstand
2. Batterie mit ebenfalls sehr geringer Impedanz
3. Extremuntersetzung für DZ gemäß nach oben offener Richterskala
Faktor 4 wäre dann der Pilot mit 15° collective und ebenso viel cyclic (oder mehr ) an der Hand, bzw. in den Händen eines FBL mit scharfem Setup.
Geht alles, man muss nur auf den KOSMIK 1000 warten.

EDIT: Um es unmissverständlich zu sagen: Der KOSMIK ist mMn in allen Belangen freizusprechen, und dafür zu loben, dass er sich schützte und überlebte (auch mechanisch?)
Leider hat es dabei seinen Kollegen, den Diabolo, den Kopf gekostet.
Wer ist schuld? Ein gewisser Nico, der schmerzlos alles nach den Prinzipien der Gigantonomie kombinierte.

_________________
Tom

Sorry für die etwas harte Schlussfolgerung, Nico! Schließlich trauerst Du um Deinen Diabolo..
Wollte sagen, wenn ich an einer Komponente nach oben drehe, muss es an den beteiligten auch Sinn machen.
Ich muss auch gucken, welche dritte Komponente, die bis dato evtl. unterband, dass Komponente #1 sich voll ausleben konnte, im Spiel beteiligt ist, - die Bakterie.
Der Motor ist schon Wahnsinn, die Batterie auch. Nur der ESC dafür muss noch gebaut werden.

Ich würde mich aber trotzdem fragen, ob es überhaupt Sinn macht, mit so viel Drehmomenteinsatz zu arbeiten, - so hart ran zu gehen, dass dabei der Strom derart extrem bemüht wird, automatisch. Ich sehe so was nicht zum ersten Mal. Das eine Mal, an das sich meine alte Birne noch erinnert (bei HF im K-Board), endete genauso.
Das System muss dem Zweck entsprechend funktionieren, so ein Heli ist ein "System", das Ergebnis im Flugverhalten ist der Zweck.
Einen einzelnen Aspekt auf Teufel komm raus zu metern, macht dann meist wenig Sinn.

Auch erstaunlich, wie offenbar lässig die Regelkreise des FBL damit umgehen, vor allem der Hochachse.
Allerdings ist eines überhaupt nicht belegt: Setzt dieser Stromhunger bei positivem Lastwechsel sich überhaupt fast 1:1 in Drehmoment um?
Es könnte ja auch sein, dass das Eisen im Motor bereits in die Sättigung geht. Ist es nur der Sieg von Ohm über Henry?

Hätte man aber den ESC im Setup vorher für sinnfälligen Stromanstieg eingestellt, - wenn das überhaupt geht, - tja, dann hätte man das Angebot des Motors nicht umsetzen können.

---------
Das ist ein bisschen mit dem vergleichbar, weshalb mich Ralf (Mikado) mal als unerwünschten Meinungsäußerer im entsprechenden Forum einstufte, 2h Tel.gespräch vorangehend (Jahre her): Der "Wunder-Governor". Ich sagte nämlich, mit Logs belegt, dass das Wunder gar nicht realisiert werden kann, weil man mit Rücksicht auf störendes Drehmoment bei DZ-Abfall nicht wie bekloppt die PWM hochdrehen kann. Man muss moderat ran gehen mit dem Anstieg der PWM (in der Gegenrichtung, DZ steigt über Soll, nicht *)). Sprich, der theoretische Zeitvorteil, - FBL weiß, dass jetzt Lastanstieg kommen wird, - ist Peanuts im Vergleich zur selbst aufzuerlegenden, verzögernden Rampe für PWM up.
Das Prinzip ist zu oben vergleichbar: Wenn ich an einer Stelle bessere Möglichkeiten einbaue, muss ich mich immer fragen, ob ich sie umsetzen kann im System, ob sie im Ganzen überhaupt sooo einen unbedingt anzustrebenden Effekt haben, ob es nicht auch negative Side Effects gibt.

*) Deshalb machte Harald Konrath (Gruß nach Wolke #7!) eine asymmetrische Regelung. DZ sinkt -> PWM Rampe mit angemessenem Anstieg. DZ steigt über Soll -> PWM geht flink down. Hatte mal versucht, das auch zu implementieren. Gar nicht so einfach..

_________________
Tom