J-Log.eu - Forum

Na jedenfalls nicht wirklich ein Problem für Kunden:

https://www.rc-heli.de/board/showthread.php?t=254908

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

_________________
Tom

Achtung! Falls jemand einen JIVEpro in einem Flächenmodell verwendet: JLog könnt Ihr Euch dann sparen:

1. Der Workaround gegen den Drehzahlbug funktioniert nicht, weil JLog dabei PWM als Führungsgröße verwendet. (Gas gibt's ja erst gar nicht.)
PWM ist aber komplett unbrauchbar, wenn man die Bremse drin hat (Klapp-Propeller). PWM geht in den Pausen (nix dreht sich) auf 100%!

2. Die Heilung in JLog gegen einen anderen Bug (Motorstrom friert auf dem letzten Wert ein, wenn der Motor nicht mehr kommutiert wird) funktioniert auch nicht, weil auch dabei PWM verwendet wird, PWM spielt aber Scheibe.

Natürlich wird PWM auch zum Bremsen auf die Endstufen gegeben, aber das sollte man nicht stumpfheil ausgeben.

Mit einem KOSMIK sähe es vermutlich auch nicht besser aus, was PWM und die Drehzahl betrifft.

Winne, unser'n Data Explorer Helden, hat es voll erwischt dabei, er war der unfreiwiliige Tester. Ich hatte vorher nie mit brake enabled getestet, dabei schaltet sich immer mein Netzteil ab.

_________________
Tom

Moin.

Wie sauber funktioniert eigentlich die Korrektur von K spannungstechnisch? Hab einen neuen Jive Pro bekommen und bei Kälte fangen die Saxos Servos an zu spinnen an. Das aber nur, wenn Sie am BEC vom Jive hängen. Die fahren beim Einschalten schön in die Endposition und zerlegen mir die Anlenkung.

Viele Grüße,
Nils

Nein, das ist eindeutig temperaturabhängig.

Sie haben es leider nicht verstanden. Der GF sagt stolz was von, dass sie mit 30 Servos testen. Das zeigt deutlich, dass der Background leider nicht erfasst wurde..

Das ist ein Workaround, keine prinzipielle Lösung.
Man verändert 1..2 Widerstände im Feedback Netzwerk des Buck Controllers so, dass das Ganze die kritische Zeit von nominal ca. 100ms (wovon nur die ersten 10ms wirklich kritisch sind) ohne Erscheinungsform des Design Flaws über die Runden bringt. Es ist aber
- exemplar-
- last-
- temperaturabhängig.

Eigentlich müsste jeder so modifizierte BEC bzw. ESC in den Klimaschrank, um bei wenigstens zwei Ecktemperaturen zu testen, ob der WA bei diesem Exemplar wirklich greift.
(Darüber kann der WA sogar teurer werden als ein Redesign.)

Tja.., macht man nicht, - daher muss jeder bisher Glückliche potentiell damit rechnen, dass es mit eiskaltem ESC anders aussieht.
Lösung: Batteriebetriebener Haarfön.

_________________
Tom

Bei mir schaltet das BEC sauber an, nur spielen am Jive Pro meine Savox Servos manchmal verrückt. Am Jive klappt es ohne Probleme. Kann das auch noch daran liegen? Die Savox sind etwas pingelig, andere Servos haben keine Probleme.

Vg

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

Da liegt der Hase im Pfeffer:
Durch den Design Flaw fühlt sich der BEC beim Einschalten bereits durch weitaus weniger als 300mA "überlastet".
Wenn die Caps des Puffers ziemlich leer sind, provozieren sie das Erscheinungsbild des BEC Design Flaws.

Einfach den Puffer 1s nach Powerup anstecken.
UltraGuard statt Buffer, mit Firmware, wie wir sie ihm seit Mai 2015 verpassen, wäre eine Alternative.
Der UG stützt den armen BEC-Idioten beim Powerup, anstatt ihn bitterböse mit ein paar Milliampere zu "belasten".

Am Anfang des Threads ist ein Bild, das zeigt, wie selbst kleiner Strom beim Startup das Ganze zum Schwingen bringen kann. (am Multimeter sieht es wie zu geringe Spg. aus, weil integriert)
Ob's nun schwingt oder was anderes, - es stört das Startup.

_________________
Tom

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

Weil ein User den Bootloader nicht aufspielen kann, rein technisch.

Also, entweder hat man einen ESC, der bereits diesen BL bekam im Herstellungsprozess, oder mein ESC muss noch einmal nach Hause dazu.

-----
Übrigens gute Maßnahme vom Dev (kenne ihn): Bevor man irgendwas "intelligentes" tut mit dem Microcontroller, gleich eine Spannung an den BEC Controller kommandieren, sodass die nach dem Powerup viel kürzer führungslos ist.
Schließlich sitzt man ja selber (der M-Controller == MCU) auf dem Ast (seine Betriebsspannung wird aus der BEC Ausgangsspannung gemacht).
Ansonsten ist man u.U. als MCU selber angearscht, - wird geboren, stirbt gleich wieder. Dann oszilliert Ubec.

_________________
Tom

Fortsetzung



Dass die BEC Voltage ganz am Anfang büsken crazy ist, kann auch der UG nicht verhindern. Er schaltet sich ja erst zu, wenn er Spannung sieht, wenn ca. 5V erreicht sind.
Das macht der UG seit Mitte 2015 (Firmware), die ersten 5 Sekunden kommt er wie eine Stützbatterie, dann erst tut er sein normales Ding.
Es heilt das Problem für den Startup des BEC. Der ist eigentlich unschuldig, der Design Flaw steckt um seinen Herrn, den Prozessor.
Das heißt aber nicht, dass ein versorgtes Device, was viel zu früh "nach dem Rechten guckt", sich nicht doch beeindruckt fühlen könnte durch das Crazy Voltage Behavior in den ersten Millisekunden.
Dann ist aber dieses Gerät quasi selbst schuld. Ich schreie nicht, "ich ertrinke", weil mir Wasser in's Gesicht spritzte, sondern erst, wenn es über mir zusammenschwappt, und ich die Gusche noch mal an die Oberfläche kriege, um den Schrei abzulassen.

Wenn Du jetzt eine echte Stützbatterie an den BEC-Ausgang hängst, die liefert, bevor die Schei**e los geht, dann sollte Dein Problem (habe ich nicht genau hingeguckt bzw. verstanden) gelöst sein.
Wenn nicht, dann hat es eine ganz andere Ursache.

Das Problem im RC ist ja grundsätzlich:
Obwohl die Geräte verschiedener Hersteller am Ende in einem Setup zusammenarbeiten müssen, tun viele Designer so, als wären sie allein mit ihrem Gerät.
Es ist ergo zweischneidig: Der Eine ist zu spät bereit, der Andere geht zu früh von Bereitschaft aus.
Nimm mal allein die Servos, die ohne Sinn und Verstand nach Powerup sofort losballern mit viel Strom.
Dazu andere "Hirnlose", FBL's, die diese Servos sofort und kollektiv ansteuern.

_________________
Tom