J-Log.eu - Forum

Artverwandt (DE) • Re: User bilden User

2017-11-23T12:25:16+01:00

Es gibt einfach Aberglauben, die sich offensichtlich von DAU zu DAU weitergeben..

Dazu gehören Logs in der Funke, oder auch der "unglaublich Vorteil" eines Stabi-Govs

Statistik: Verfasst von thomas1130 — 23. Nov 2017, 12:25

Artverwandt (DE) • User bilden User

2017-11-22T20:03:34+01:00

https://www.rc-heli.de/board/showpost.php?p=3295278&postcount=4

Quote:

P.S. Die Loggingdaten werden Graupner-seitig 19 - 20 mal pro Sekunde gesampled und gespeichert. Damit kann man schon was anfangen

Toller Trick, wenn ich 5 bis 1x pro Sekunde Daten übertrage.

Auch ohne Faktenwissen kann man bemerken, welchen BS man erzählt:
- Der Empfänger ist ein Transceiver im Simplex Verfahren.
- Wie oft pro Sekunde erfahren die Daten mit der höheren Prio ein Update, die Kanaldaten?

Statistik: Verfasst von dl7uae — 22. Nov 2017, 20:03

Artverwandt (DE) • Graupner

2017-08-20T19:20:06+01:00

https://www.rc-heli.de/board/showpost.php?p=3273489&postcount=21

Quote:

Graupner wurde doch 2013 liquidiert und die Markenrechte SJ Incorporated verkauft ?

==> http://www.graupner.co.kr/organization

Statistik: Verfasst von dl7uae — 20. Aug 2017, 19:20

Artverwandt (DE) • Re: https://www.rc-heli.de/board/showthread.php?t=261216

2017-08-05T15:13:50+01:00

Hmm.. Man sieht plötzlich nichts mehr, der Wind (140km/h!) kann mich sonstwo hin geschoben haben, ich kenne den Abstand nach unten nicht mehr..

Diese "Bedrängnis" verstehe ich schon.. Das Ausklinken hätte die Leute retten können, es passierte aber das Gegenteil..

Wieso haben Luftfahrzeuge für solche Einsatzgebiete nicht erweiterte Sichtmittel bzw. Lage-/Positionsregler?
Das sollten sie haben, weil sie sich schwebenderweise häufig in der Situation befinden, dass Fluglage und Position nicht verändert werden dürfen, auch wenn man sie mit Human Eyes nicht mehr bestimmen kann.

Statistik: Verfasst von dl7uae — 5. Aug 2017, 15:13

Artverwandt (DE) • Re: https://www.rc-heli.de/board/showthread.php?t=261216

2017-08-04T14:57:37+01:00

Nur zur Info: Es handelt sich um den selben Piloten, der schon vor ein paar Jahren durch "Fehleinschätzung unter Bedrängnis" den Tod eines Menschen zu verantworten hatte:
http://www.nachrichten.at/nachrichten/c ... t58,875896

Wieso man danach noch weiterfliegen darf ist mir nicht ganz klar..

Statistik: Verfasst von thomas1130 — 4. Aug 2017, 14:57

Artverwandt (DE) • https://www.rc-heli.de/board/showthread.php?t=261216

2017-08-04T13:49:48+01:00

Das Übliche, fast peinlich.
Andererseits durchaus einsehbar, dass Modellpiloten drüber reden. Das physikalische Prinzip ist ja dasselbe am Modell, wenn es auch am großen 1:1 Aspekten unterzogen sein mag, die den meisten Modellpiloten unbekannt sind.

Da ich ja seit 2010 nicht mehr zum Fliegen komme, muss ich mal mitmachen.

MMn machte der Pilot möglicherweise einen Doppelfehler.

Der auslösende Fehler:
Er ließ sich quasi im Schwebeflug von der Seite beladen, bei reduziertem Downwash. Die Kufen hatten zu wenig Bodenkontakt (evtl. erforderte es das Geländeprofil), könnte auch sein, dass der Helfer beim Beladen zusätzlich auf die rechte Kufe trat.
Den Heli mit seinen Möglichkeiten in so einer Situation zu stabilisieren, ist grundsätzlich problematisch, zumal Momente durch einseitiges Festnageln an den Boden direkt provoziert werden beim Gegensteuern. Festeres Absetzen wäre der richtige Weg gewesen, wenn es das Gelände nicht verbot. (Dann wäre der Aufsetzpunkt grundsätzlich falsch gewählt gewesen.)

Kommt das NOTAR System hinzu, und dünnere Luft..

Der zweite Fehler war "menschlich", wahrscheinlich kam Panik auf:
Durch mehr collective drehte er noch schneller um die Hochachse. So einen Heli, drehenderweise, durch Vorwärtflug zu stabilisieren.., da gibt es sicherlich Grenzen seitens der Flugkünste, IM Heli sitzend.
Der Panik-Beschluss war wohl, durch Bodenberührung das Drehen um die Hochachse aufzuheben. Der Panik-Fehler war dabei, zu sehr zu nicken, Rotor bekam Bodenkontakt.

Nur der Pilot weiß, vor allem auch aus seiner Typ-Erfahrung und durch häufiges Fliegen in diesen Höhen, ob das Nichtreagieren des Hecksystems ungewöhnlich war.
War es das, mag seine Aktion genial gewesen sein, die glücklicherweise glimpflich ausging, allen das Leben rettete.
Sprich, der Pilot wäre dann nicht remote zu schelten, sondern zu loben, seiner Erfahrung hohe Anerkennung zu zollen.

Nichts genaues weiß man nicht...

------------
Noch mal angeguckt:
Kann keinen Grund erkennen, mit so viel collective zu "stehen".
Sehe noch weniger Grund, beim Einsetzen des unvorhergesehenen Moments nicht sofort collective rauszunehmen.
Zwei Sekunden später drehte er sich über die Kante. Zu spät, hoch. Wieso dann dieser Nasenkreis?
Kante: Kein Grund erkennbar, so nah an der (links) aufzusetzen. Die Position des Helfers mit Patient darf kein Grund gewesen sein.
Auf jeden Fall hätte der Helfer nicht diese Position wählen sollen, sondern weiter entfernt vom mutmaßlichen Aufsetzpunkt.

Statistik: Verfasst von dl7uae — 4. Aug 2017, 13:49

Artverwandt (DE) • Re: https://www.rc-heli.de/board/showthread.php?t=259672

2017-03-01T12:16:58+01:00

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..

Statistik: Verfasst von dl7uae — 1. Mär 2017, 12:16

Artverwandt (DE) • Re: https://www.rc-heli.de/board/showthread.php?t=259672

2017-03-01T02:25:57+01:00

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;

Quote:

$1;1;143.670;97220;44.5;236;0.47;260;360;35;91;7.9;1.8;33;76;76;30;0
$1;1;143.680;96901;44.2;253;0.47;275;392;35;92;7.9;2.1;33;76;76;30;0
$1;1;143.690;96922;44.0;275;0.47;296;422;35;93;7.9;3.2;33;76;76;30;0
$1;1;143.700;96476;44.2;269;0.47;292;434;35;92;8.0;1.9;33;76;76;30;0//RPMcontrol
info #15 peak current limit reached
$1;1;143.710;95805;44.1;266;0.47;288;433;35;91;7.9;1.7;33;76;76;30;0

Nach Bereinigen:

Quote:

$1;1;143.670;97220;44.5;236;0.47;260;360;35;91;7.9;1.8;33;76;76;30;0
$1;1;143.680;96901;44.2;253;0.47;275;392;35;92;7.9;2.1;33;76;76;30;0
$1;1;143.690;96922;44.0;275;0.47;296;422;35;93;7.9;3.2;33;76;76;30;0
$1;1;143.700;96476;44.2;269;0.47;292;434;35;92;8.0;1.9;33;76;76;30;0 //RPMcontrol
info #15 peak current limit reached
$1;1;143.710;95805;44.1;266;0.47;288;433;35;91;7.9;1.7;33;76;76;30;0

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:

Quote:

$1;1;143.690;96922;44.0;275;0.47;296;422;35;93;7.9;3.2;33;76;76;30;0
$1;1;143.700;96476;44.2;269;0.47;292;434;35;92;8.0;1.9;33;76;76;30;0 //RPMcontrol
info #15 peak current limit reached
$1;1;143.710;95805;44.1;266;0.47;288;433;35;91;7.9;1.7;33;76;76;30;0

.
.
.
$1;1;144.240;98645;45.3;171;0.49;196;255;37;87;7.9;3.4;33;76;76;30;0
$1;1;144.250;98066;45.0;189;0.49;214;280;37;88;8.0;2.5;33;76;76;30;0
$1;1;144.260;97862;44.9;195;
// KONTRONIK Log-File V4.5: \KO_LOGS\LOG_506.DAT
// KOSMIK 200+ HV, Firmware V4.5, DeviceID: 002800443034511533353239
//
//;; Time-; RPM;Battery-;Battery-;Battery- ;Motor- ;Peak- ;Tempe-;PWM;BEC-;BEC-;BEC-;TX;TX-; Tv;Check-;//Betriebszustand
//;; stamp; ;voltage ;current ;discharge;current;current;rature; ; U; I;Temp; ;PWM; ; sum;
$1;1; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0; 0;
$1;1;0.900;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
cut off #13 watchdog reset
$1;1;1.000;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.100;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.200;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.300;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.400;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.500;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.600;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.700;0;48.3;0;0.00;0;0;38;0;7.5;1.0;34;76;76;0;0 //Selftest
$1;1;1.800;0;48.5;0;0.00;0;0;38;0;8.0;2.4;34;76;76;0;0 //Error_Selftest
selftest error #32 error FET off
$1;1;1.900;0;48.5;0;0.00;0;0;39;0;7.9;2.6;34;76;76;0;0 //Error_Selftest

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.

Statistik: Verfasst von dl7uae — 1. Mär 2017, 02:25

Artverwandt (DE) • Re: https://www.rc-heli.de/board/showthread.php?t=259672

2017-02-28T18:58:11+01:00

Quote:

Ich hab mir den anderen Post jetzt nicht komplett angeschaut, aber was er behauptet ist einfach das der Peak-Strom an der Lipo-Leitung gemessen wird. Müsst ich mir erstmal Gedanken drüber machen, hab ich aber grad kein Nerv zu.

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.)

Statistik: Verfasst von dl7uae — 28. Feb 2017, 18:58

Artverwandt (DE) • https://www.rc-heli.de/board/showthread.php?t=259672

2017-02-28T12:10:51+01:00

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.

Statistik: Verfasst von dl7uae — 28. Feb 2017, 12:10

Artverwandt (DE) • Stützakku am HWv4 BEC

2017-02-23T23:26:04+01:00

https://www.rc-heli.de/board/showpost.php?p=3228025&postcount=1

Ich habe keinen Schaltplan und ich werde den Teufel tun, ihn zu ermitteln.
Hab's einfach probiert: Bei 8,4V (2S voll geladen) fließen max. 32mA in den BEC Ausgang, wenn der komplett stromlos ist.
Er hat's natürlich überlebt.

Würde mal aus dem Urin des Elektronikers definieren: Funktioniert.

Statistik: Verfasst von dl7uae — 23. Feb 2017, 23:26

Artverwandt (DE) • JIVE Kühlkörper

2017-02-12T22:42:59+01:00

https://www.rc-heli.de/board/showthread.php?goto=newpost&t=259514

Die Dinger sind in den meisten Setups nur "thermische Kondensatoren". Kühlrippen, und damit räumliches Ausladen und Hebeln, sind meist unnötig, weil keine natürliche Konvektion besteht. Strahlungskühlung ist marginal, meist durch die Farbe des KK eh verhindert. Es wäre also dasselbe, einen Aluklotz desselben Volumens zu verwenden, solange man ihn zwischen den Flügen etwas abkühlen lässt.

Diese Aluplatte am JIVE ist mit CA auf die Deckel der DirecFETs geklebt! Hebelt man die ab, sind oft FETs im A.

Zwangskonvektion (Lüfter) ist gut. Dazu kleine Rippen, und den entsprechenden kleinen Lüfter (Diameter) drehzahlreduziert betreiben, damit ihn die Coriolis-Kräfte nicht so schnell zur Minna machen, die Lager.

Bei Erreichen von >100°C aus Sicht (interne "Messung") des JIVE ist Pumpe, PWM abregeln auf Null innerhalb von 14s. Die Resolution ist zwar 1°C, aber step 2°, man sollte also 85°C als Grenzwert nehmen, sonst kann zu schnell Schicht sein.

Sofern man die Sicht des ESC auf die Temperatur kontrollieren kann, ist es einfach eine anhand der Praxis im konkreten Setup zu beantwortende Frage.
Die meisten JIVE kommen ohne KK aus.
Ich habe bisher nur wenige Logs gesehen, in denen ein JIVE wg. Overtemp abregelte, - ganz legendär ein Log von Christian Samuelis vom Juli 2010 (Testlogs für JLog1), wo er 3 heftige Flüge direkt nacheinander absolvierte bei 31°C im Schatten. Nach 4 Min im dritten Flug waren dann 101°C erreicht. Das Teilchen durfte einfach nicht genügend abkühlen zwischendurch.

Attachment #1 ist von besagtem Flug von Chris, als er eilig mal schnell 3 Akkus entleerte. Man sieht: 14 Sekunden lang warnt die PWM vor, dann aber Klack! Wenn er einmal wg. Overtemp eingeschnappt ist, hilft nix mehr, er wird dann abschalten. Man sieht, wie Chris wohl noch retten wollte, Gas weg nahm. Brachte nix.
#2: Ich hatte mal für Kontronik 2010 einen LogViewer für die internen Daten gemacht, Übertragung per Bluetooth. Man sieht, wie das gute Stück seine Hitzewallung z.K. nimmt, in den Fehlerspeicher tut.

(Habe den einen Screenshot etwas "anonymisiert". Es lesen zuviel Leute mit, die es nutzen, um dann mit aggressivem Marketing aufzutreten.. Sie lassen ihr Brain dampfen. )

Statistik: Verfasst von dl7uae — 12. Feb 2017, 22:42

Artverwandt (DE) • Spannungs- oder Kapazitätsüberwachung?

2016-12-07T20:28:52+01:00

Die ewige Diskussion, gerade wieder in RCH..

Meine 2 Cents:

- Sucht man mit diesem Subjekt nach dem Nonplusultra, dann sind es beide nicht.

1. Entnommene Kapazität kann ein guter Anhaltspunkt sein, allein aber kann er Massakrieren einer Batterie nicht verhindern. Warum:
- temperaturabhängig
- stromabhängig: schließlich hat jede Batterie einen Innenwiderstand, der übrigens auch temperaturabhängig ist
- alterungsabhängig (Batt verliert Kapa, mittlerer Ri steigt)

2. Gesamtspannungsüberwachung kann einen Gau verhindern, allerdings möglicherweise erst in letzter Sekunde, weil in Reihenschaltung gemessen, Totkranke sind dabei kaum erkennbar. Als Anhaltspunkt, wann Schluss sein sollte mit Entladen, nur bedingt geeignet:
- Spannungsbereich ist von der konkreten Technologie (Li-Ion, LiPo, LiFe, LiFePo, ..) und Subtechnologie (unspezifizierte Eigenheiten, 4.2|4.3|4.35 Ladeschlußspg) abhängig
- Gesamtspannung ist stromabhängig über die Reihenschaltung evtl. stark unterschiedlicher(!) Ri der Zellen
- Die Spg. muss in einer geeigneten Zeiteinheit betrachtet werden, um keine False Positives zu produzieren

Wird eine Zelle sauer, - so sauer, dass Sie nur noch ein übergroßer Widerstand ist (Umpolung), dann ist alles zu spät durch die Reihenschaltung in einem Pack.

Wie dann:
- entnommene mAh zu beobachten/limitieren, ist natürlich nicht verkehrt
- jede Zellenspannung einzeln (Gesamtspg. on top)
- Um wirklich sicher zu gehen, dass man es rechtzeitig erfährt, wenn was beginnt, faul zu werden (außer, die Batterie oder eine Zelle fällt plötzlich aus dem Modell ), hilft nur ein's: Das Verhalten jeder Zelle zu beobachten, auch das Verhalten jeder Einzelzelle im Vergleich zum Pack zu beobachten/bewerten.

Jetzt werde ich pauschal abgeurteilt: Meines Wissens nach gibt es im Modellbau nur ein Gerät, was so was macht: CVS16
(OOB: Out Of Balance, OOIRD: Weichei-Zelle erkennen (Spannungsverlauf unter Last im Vergleich zum Durchschnitt im Pack))

Man muss natürlich sagen, viel hilft viel, und kann bei richtiger Anwendung einen CVS ersparen, solange nicht etwas unvorhersehbares passiert:
- Ich kenne meinen Akku, bis zu welcher Entladespg. fühlt er sich hinterher noch wohl.
- Damit kann ich auch die Gesamtspannungsschwelle angemessen einstellen.
- Ich fliege ihn oft, beobachte seine negative Kapazitätsentwicklung.
- und, ganz wichtig, leider viel zu selten praktiziert: Zu Beginn des Ladevorgangs beäuge ich am Charger das Verhalten der Zellenspannungen.

Tja.., wie gesagt, und dann fällt plötzlich das Pack unten raus, oder ein Goldi löst sich (Letzteres hatte ich schon mal ).

Statistik: Verfasst von dl7uae — 7. Dez 2016, 20:28

Artverwandt (DE) • Re: Dataexplorer und Mac

2016-03-22T12:44:13+01:00

Heliskip hat geschrieben:

Hallo,
war immer ganz zufrieden mit dem Dataexplorer um meine Jlogs und UniLogs anzusehen.
Hab's ne Weile nicht benutzt und nix geht mehr.
Mac Mini mit Mavericks (letzte Version) und Java 7

Auch, wenn es schon lange her ist, dass diese Frage gestellt wurde, es könnte sein, dass jemand bei einer Suche hier landet:
Die neueren Versionen vom MAC OS X verwenden ein Java Runtime Environment (JRE) nur noch für ein Browser Plug-in und hält dieses dann auch aktuell. Grundsätzlich sollte man mit Java im Browser vorsichtig sein und nur für bestimmte bekannte Anwendungen zulassen. Das Elster-Portal ist so ein Fall bei mir.

Ansonsten muss die Java Anwendung das JRE mitbringen (Beispiel DeltaWalker) oder man muss ein Java Service Environment (JSE) oder als Java Development Kit (JDK) bezeichnet installieren, DataExplorer. Weil es sicherheitsunkritisch ist gibt es hierfür auch kein automatisches Update.

Hier http://www.nongnu.org/dataexplorer/inde ... leshooting findet man die Download-Links von Apple oder Oracle für das JDK/JSE und auch Hinweise für andere Betriebssysteme.

Winne

Statistik: Verfasst von Winne — 22. Mär 2016, 12:44

Artverwandt (DE) • Zu dem: http://www.rc-heli.de/board/showthread.php?t=249552

2015-05-19T00:48:41+01:00

Das könnte leicht mißverstanden werden, und wird es offenbar auch teilweise.

- Es geht hier nicht darum, mit Dreck zu schmeißen.
- Es geht nicht darum, dadurch eigene Produkte zu pushen, wie jemand unterstellte.
- Es geht überhaupt nicht darum, Haare in fremden Suppen zu finden. Wir können unsere Zeit produktiver totschlagen.

Der positive Teil ist: Offenbar finden K's ESCs breite Anwendung, denn sonst würden Probleme von deren Produkten ja nicht unsere tangieren, und wir müssten nicht darüber sprechen.

Der negative Teil ist der zweite Teil des obigen Satzes: Es berührt uns unmittelbar, und wg. des wachsenden Portfolios immer häufiger. Tangiert sind JLog, CVS, R2buffer, Opti ULTRA Guard, - u.U auch Opti BEC Guard.

Anlass war in einem speziellen Fall, dass eine exklusive Anwendergruppe offenbar argwöhnte, dass der ULTRA Guard Motorabsteller verursachen könnte. Diese Leute stellten dann aber selbst fest, dass es mit einem Scorpion Backup Guard genauso passiert.
Sie schickten dann an Opti ein KOSMIK Log, das wir zu interpretieren hatten.
(Abgesehen davon, bekommen wir inzwischen täglich Fälle zur Analyse. Natürlich sind wir nicht für fremde Produkte zuständig, aber eben für Produkte aus unserem Design/Fertigung, - und wenn die zusammen mit dem betrachteten ESC eingesetzt werden.. So erst kamen wir dazu, diese BEC auf den Prüfstand zu nehmen.)

Zum speziellen Anlass: Abgesehen davon,
- dass der Anwender den BEC überlastete (großes Flächenmodell),
- dass uns das 28A Limit verwunderte,
- erschienen uns Ungereimheiten im thermischen Verhalten des KOSMIK BEC.

Also schauten wir uns das genau an:
KOSMIK 200, KOSMIK 160, JIVE Pro 120.
Programmierbare Stromsenke, Speicheroszis für Ausgangsspannung und Strom.
Logging mit KOSMIK und JLog.
IR Temp. Measurement Equipment.

Wir belasteten nominal, lt. Specs, dabei natürlich am Maximum: Die BECs sind spezifiziert mit Dauer- und Peakstrom, z.B. der KOSMIK 200 mit 10/30A.
Die Stromsenke wurde jeweils so programmiert, dass der Average Current max so hoch ist wie der spezifizierte Dauerstrom. Wem das böhmische Dörfer sind: Das ist noch moderat. Wir sind beim K200 nicht mit 10A Dauerstrom und 30A gepulsten Peaks gekommen, sondern mit einer Kombi, die insgesamt nur einen Durchschnittstrom in Höhe des spezifizierten Dauerstroms erreicht. Am Beispiel K200 waren das:
- 500ms 8.47A
- 50ms 25A

Zuerst nahmen wir den KOSMIK: Oops, was ist das? Der BEC resettete jeweils innerhalb weniger Sekunden.
(Natürlich geht dabei auch der Motor aus. Eine Pufferspannungsquelle am BEC-Ausgang kann das nicht verhindern, man kann nicht in den BEC Ausgang einspeisen.)

Wir verringerten dann schrittweise die Stromamplituden in den beiden Zeitphasen, was aber keine wesentliche Änderung zeitigte, solange man nicht im Peanuts-Bereich landete dadurch.

Der Temp.Sensor des BEC berichtete dabei Temperaturen unter 60°C.

Dann nahmen wir einfach nur einen Dauerstrom von 8A und beobachteten.. Komisch.. Kein Reset, die Temp. steigt deutlich über 60°C ohne Vorkommnisse. -- Die kontrollierte Phase reagiert dann per Firmware bei Überschreiten von 100°C, indem die BEC Spg. auf 5V reduziert wird. Dann kann der BEC (und der Programmierer des ESC) nichts weiter tun, als abzuwarten und auf die Vernunft des Anwenders zu hoffen. Ist der nicht vernünftig, steigt die Temp. weiter, bis dann bei ca. 107°C die Temperature Protection des BEC Controllers (in-chip) der Sache ein abruptes Ende macht.

Nun war der BEC, der ganze KOSMIK, schön durchgewärmt. Wir gingen wieder mit gepulstem Strom ran (mehr realitätsnah), - doch komischerweise wollte der BEC nun fast gar nicht resetten. Häh?!

OK, wir schnappten uns den JIVE Pro, belegten ihn mit gepulstem Strom gemäß seiner Specs,
- 500ms 6.77A
- 50ms 20A
(8A average; wie mit dem KOSMIK jeweils 1ms Stromanstiegszeit)

und der tat, wie ideal erwartet: Keine Resets, - es ging nur eben so lange, bis bei 100°C die rote LED anfing, zu blinken (Übertemp.), und er gleichzeitig die Ausgangsspg. auf 5V reduzierte. Endphase ist dann weiterer Temp.anstieg und harter Cut bei 107°C durch die Overtemp Protection im Chip des BEC Controllers. So ist es normal, so ist es ok.

Positiv im Vergleich zum KOSMIK fiel auf:
- Die thermische Entkopplung zwischen Endstufen (FET Temp.) und BEC (Temp.) ist besser.
- Offenbar hat der BEC eine bessere Wärmeableitung als im KOSMIK, - der Temperaturverlauf ist "harmonischer", wir mussten auch länger warten, bis Overtemp eintrat. Natürlich führten wir weniger Energie zu, weil der JIVEpro nur mit 8/20A spezifiziert ist.

Anders war sein Verhalten nach Reset:
- Der BEC kommt quasi gar nicht wieder (es schwingt). Die Overtemp Protection des BEC Controllers (Chip) schlägt immer wieder zu. Der KOSMIK kam immer gleich wieder, als würde der Chip des BEC Controllers sofort signifikant abkühlen.
Sprich, der BEC des Pro verhielt sich auch hier völlig korrekt.

Nun blieben zwei Fragen zum KOSMIK übrig, von deren Antworten wir zwar eine Vorstellung haben, die wir aber nicht öffentlich machen, weil ohne Zweck:
- 1) Warum ist da eine scheinbar stärkere Wärmekopplung zw. Endstufen und BEC? Warum erwärmt sich der BEC schneller?
- 2) Aber vor allem: Warum resettet er zuverlässig bei Belastung mit transientem Strom innerhalb der Specs nur dann, wenn seine Komponenten noch nicht durchgewärmt sind? Das war ja der ursprüngliche Stein des Anstosses, und das ist die gefährliche Seite.

Das ist insgesamt eine bemerkenswerte Sache, denn dabei geht natürlich auch der Motor aus (s.o.). Für den JLog Support war auch interessant, dass nach so einem Reset das "TelMe Protokoll" am konnektierten Option Port des KOSMIK nicht mehr funktionierte.

Jedenfalls fanden wir hier die Erklärung, warum laut Log des Anwenders bei nur rund 60°C dessen BEC ausfiel (Reset). Der Anwender hatte das (grundsätzlich vorhandene) Problem provoziert, indem er ständig mit hohem, transientem Strom (Servos) daher kam. Nach unserer ersten Analyse (zuviel Servostrom trieb den BEC in den Thermotod) konterte der User natürlich: Wieso?! Der BEC des KOSMIK 200 Cool ist doch mit 10/30A spezifiziert. Recht hat er, - daher mussten wir uns das genauer angucken, - Ergebnis s.o. (Wieviel Peakstrom besagter User zog, können wir leider nicht sagen, weil aus unerfindlichen Gründen bei 28A Schluß ist seitens des Data Processing des ESC (-->Log, -->Telemetrie).)

-----------
Gegenmaßnahmen:
Die gibt es nicht wirklich. Ein sehr niederohmiger Puffer kann die Wahrscheinlichkeit eines Reset verringern, in der Praxis eher als im Lab, wo wir dauerhaft mit transientem Strom i.H.v. s.o. kommen. Supercaps haben daher theoretisch die beste Wirkung (Innenwiderstand, wenn voll), ansonsten nur ein wirklich fetter Stützakku. Unter Lab-Bedingungen haben beide keine dauerhafte Wirkung (werden leer), in der Praxis aber wahrscheinlich, dann sicherlich auch ein Ultra Guard, solange es sich nicht um ein Extrem-Setup handelt, wie in o.g. Untersuchungsfall, ein dickes Flächenmodell, in dem es eh andauernd auf Anschlag ging mit einem K200 (28A Peaks geloggt, Puffer war aber ein Scorpion Backup Guard). Es gibt keine verlässlichen statistischen Erkenntnisse dazu, es gibt aber leider genügend Fälle, in denen es trotz Puffermaßnahme auch unter Praxisbedingungen passierte, inzw. bekommt R2 pro Tag ca. 2 Fälle zur Analyse. Will man es in einer notwendig werdenden Forensik genau wissen, merkt man sich die laufende Nummer des KOSMIK Logs vor jedem Start. Beim Reset wird ein neuer Logfile erzeugt.

Mit irgendeiner Backup-Stromversorgung ist das nicht wirklich schlimm, solange man einen Motorabsteller verschmerzen kann. Unsere ganze Information darüber kann man daher zusammenfassen als: Ein Motorabsteller könnte auch diesen Grund gehabt haben neben Überstrom, Kommutierungsfehler, Akku-Unterspannung, Wackelkontakten etc. Wie gesagt, nur mit einem KOSMIK, nicht mit dem JIVE Pro, nach unseren bisherigen Lab-Ergebnissen. -- Wir mussten es irgendwann genau wissen. Ist zwar "schön", dass Anwender unserer Produkte dadurch auf dem Tripp sind, häufiger nur auf Backup-Energie zu fliegen , aber einige Motorabsteller konnten wir einfach nicht erklären vor den Lab Sessions.

Statistik: Verfasst von dl7uae — 19. Mai 2015, 00:48