J-Log.eu - Forum

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.

_________________
Tom