R2 Puffer schaltet sich über Servos ein

[thomas1130]

Ja.., theoretisch könnte ein Servo auch induktiv Laden bewirken. Aber dann ist entweder die Bereit-Schwelle in der Software zu klein, - oder der C war nicht wirklich leer, nur knapp am Rand.

ja und ja..

Der Buffer entlädt sich nicht - oder zumindest nicht in einem Zeitraum von Minuten - der ist knacke voll - das merkt man daran, dass man den Heli noch lange "steuern" kann..

Und ja - es ist mMn ein Flaw in der Buffer_SW - durch einen ultrakurzen Stromimpuls seitens der Servos wieder auf "on" zu gehen..

Aber davon reden wir doch die ganze Zeit schon

[Gast]

Eben nochmal "gespitzelt". Hah! Habe ja auch x-mal Docu, sogar etwas schon ewig auf j-log.eu : http://j-log.eu/wp-content/uploads/c...l_ger_v4p8.pdf ..Den peanuts werden aber alle haben.

Ausschalten - Schaltung:
. - Ja, C wird wirklich getrennt, um nicht im Output zu wirken (FET switch)
. - Kein extra Entladen. Drei Cs in Reihe, dabei jeweils 330 Ohm parallel zu jedem C. Für Spannungsteilung, - Entladungseffekt nur "eingebaut". - Darüber dauert's, so ein Farad-Monster zu entladen.

Nun kommt aber was hinzu: Offenbar Servos "als Stromgeneratoren" direkt angezielt. - Siehe PDF im Link: "Effektive Pufferung von Servo-Rückstömen" - Kann aber nur auf Software gewirkt haben, wenn überhaupt extra umgesetzt.

Wird wohl so sein, wie bereits vermutet:
. - Cs nur etwas unter Limit entladen.
. - Induktive (positive) Spannung kommt von manuell bewegtem Servo. Somit kurz mal Ladungsquelle. Cs re-charged, - R2buffer hopst dadurch mal kurz rein mit Restladung gegen sofort wieder fallende "BEC-Spannung".
.... Verwenden eines "BUCK Charger" wird dabei entstehenden Ladungseffekt schneller wirksam machen.

Tja.. Flaw? -- Eigentlich nicht. So ein Buffer weiß ja nicht wirklich, was die momentane Modell-Situation ist, - ob sein Tun momentan noch sinnvoll.
Hilft dann nur:
. - Ewig warten, bis Cs richtig leer, - oder
. - Buffer mal kurz abklemmen.
. - Spaßvariante zum Enladen wäre schnell mal Ubec-Kurzschluss. Das erfordert Verwenden einer geeigneten Stelle, die dadurch nicht schnell "abnutzt".​

[Heli87]

Er Entlädt sich schon selbst und das auch relativ flott.
An den alten Buffern waren ja noch mehr LEDs dran.
Ja beim 2.Flug des Tages ist er immer schneller voll, aber da sind nach einer Stunde vielleicht noch 30% der Spannung übrig, da nur noch 1-2 LED leuchteten beim nächsten Anstecken.

[thomas1130]

Tja.. Flaw? -- Eigentlich nicht. So ein Buffer weiß ja nicht wirklich, was die momentane Modell-Situation ist, - ob sein Tun momentan noch sinnvoll.

Ja eh - und genau da liegt dann halt der Vorteil vom (natürlich anderer Preis) Mikado Buffer - der weiß durch die Anbindung ans FBL sehr wohl die "momentane Modellsituation"....

Aber wir haben hier ja auch nicht davon gesprochen, ob das ein "riesen Drama" wäre - für mich persönlich nicht, gehe damit seit Jahren problemlos um - sondern jemand hat ja nur gefragt, ob das bei anderen auch "passiert" - oder sein Puffer "defekt" ist.. -> nein - er ist nicht defekt - bloß doof (oder eben blind) 😎😁

[Gast]

Genau 👍

Tja, seit Okt 2019 zu spät: Wäre auch gegangen, dem Buffer mehr "Sicht" seitens Modell-Situation zu geben.
Ich machte es für CVS16 Auswertung in JLog via PWM vom ESC.
Das reicht aber nicht. Außerdem: Von JLog an R2buffer? Nö, wäre doch doof, JLog für "Sicht" haben zu müssen. PWM ist auch kein wirklich geeignetes "Auge", hierbei.
K.A, wie sicher die Sicht via dieses FBL gemacht ist. Wäre aber auch doof, dadurch für Buffer an's FBL geklebt zu sein. - Ok, Mikado will sowas, natürlich, wie alle. 😀😡

Scheint sich also "in Ahnimus" hier durch alle Pinsler geklärt zu haben.
. Ja, eigentlich Peanuts. R2buffer's "automatisches Einschalten/Anpassen" bewirkte es, weil geliebte Eigenschaft der Farad-Monster die zu langsam Abkratzen lässt nach Poweroff.

[Gast]

Moderne Schnapsidee: Cam + AI im Buffer, - um das aktuelle Gefummel zu beurteilen. -- Muss nur noch'n Auto-Blei-Akku dafür mitgetragen werden. 🤣

[papads]

Der Flaw liegt wohl eher bei den Servos anstelle beim Buffer.
Eine Diode im Servo würde dem Spuck wohl ein Ende bereiten.

Gruß Werner

[Gast]

2 Varianten für den ON-Grund (außer dem Urknall Pseudo-Ubec durch induktive voltage) :

. a) Es bräuchte evtl. etwas künstliche Latenz im selbst Einschalten/Anpassen, wenn die Eingangsspg. steigt. (Software-Änderung)
. b) Oder: Der Grund war, dass nicht abgeschaltet wurde per Knopp am Buffer, - dadurch Pufferbereitschaft stehen bleibend.

Bin hier im Lab am "Leben Einpacken für Wegschmeissen". Wahnsinnig aufwändig. Macht Ekelpickel, daher immer wieder Ablenkung. Ich beschnarschte die Schaltung nochmal detailliert.
Es gibt ja 2 FET switches. Der ganz links im Blockschaltbild ist der entscheidende, - der rechts "nur" für sicheres/schnelleres charging via Buck Charger, wenn C Spg. noch viel geringer als IN voltage. http://j-log.eu/Bufferv4.png
. (Außerdem zum Dämpfen der Last durch C Laden. So ein C wäre ansonsten quasi ein Ubec-Kurzschluss.)

Klar, ohne Sicht der Weichware weiß man nicht, welcher FET switch per OFF-Knopp betätigt wird. Seitens Schaltung macht aber der linke FET nur dafür Sinn. Der rechte auch OFF für spätere Charging Bereitschaft.
Der Buck Charger hätte hier nur unerwünschtes Ready durch "Pseudo-Ubec IN" (induktive voltage) unterstützen können, - wenn nicht vorher OFF-Knopp gedrückt wurde.
(Sprich, - ein Finger hier als FBL benötigt 😊)

(Aber natürlich nicht wirklich klar, - ob das Monitoring der Eingangssog. den linken FET hier selbst einschaltete nach OFF mit Knopp. Dann wäre a) die passendere Sicht.)​

------------
Klar, Werner, - finde das auch Sch...

[thomas1130]

2 Varianten für den ON-Grund (außer dem Urknall Pseudo-Ubec durch induktive voltage) :

. a) Es bräuchte evtl. etwas künstliche Latenz im selbst Einschalten/Anpassen, wenn die Eingangsspg. steigt. (Software-Änderung)
. b) Oder: Der Grund war, dass nicht abgeschaltet wurde per Knopp am Buffer, - dadurch Pufferbereitschaft stehen bleibend.

Nichts anderes sag ich die ganze Zeit

Es ist ein "Bug" des Puffers - in gewisser Weise zumindest - denn a) - wenn die SW eine gewisse zeitliche Komponente bei der EIngangsspannung überwachen würde, wäre das Problem kein Problem

zB Spannung <1s -> NICHT einschalten - Spannung >1s -> on -
Die Hardware ist ok - die Software nicht ganz zu Ende gedacht..


( b) - ja - er wird immer per Knopf ausgeschalten - bei mir zumindest )

[Gast]

Tja, Namensvetter, - trotzdem mystisch. Bevor wir über reguläres Einschalten, dann charged C an output geschaltet, reden, - braucht es startup der MCU.
Die bezieht ihre Spannung in 3.3V via Spannungsregler aus Ubec.
Tja...
. - Liegt da doch noch für MCU Leben ausreichende Spg. dauerhaft an (kann nur Ubec sein),
. - oder ist es ein echter Flaw im powerup, an dem direkt die Schaltung beteiligt ist?

Fand hier beim "Ekel.Räumen" auch einen R2buffer. Mache vielleicht mal "Mess-Spiel", später (wenn ich den weggeräumten wiederfinde..)

----------
Hah! (die Schaltung ist mir ungeliebt beschriftet) Der 3V3 Spannungsregler wird aus C befüttert, wenn rechter FET switch noch on. Selbstbefütterung.
Beibt rechter switch on nach Knöppchen? Nicht vorstellbar, - aber dann messbar.

[thomas1130]

Fand hier beim "Ekel.Räumen" auch einen R2buffer. Mache vielleicht mal "Mess-Spiel", später (wenn ich den weggeräumten wiederfinde..)

Bin gespannt

Sachverhalt: Flug -> Buffer VOLL - Akku abstecken -> Modell wird vom Buffer versorgt -> Buffer Taster 2 sec später - Modell "aus" - 10sec später Servo bewegen=Stromimpuls induzieren -> Buffer geht wieder on -> Modellempfangselektronik wieder on (Servos, FBL, etc) - natürlich nicht lange, aber bestimmt für 10-20sec.. - genug das die Servos wo gegen laufen können..

[Heli87]

Ich glaube noch nicht das der Mikado das besser macht.
Oder startet der seine Arbeit erst nach erfolgreicher Initialisierung der Neo? Dann wäre das Teil ja schön lahm und das für ein Backup System.

[thomas1130]

Ich glaube noch nicht das der Mikado das besser macht.
Oder startet der seine Arbeit erst nach erfolgreicher Initialisierung der Neo? Dann wäre das Teil ja schön lahm und das für ein Backup System.

Ja - das müsste einer bitte mal ausprobieren

Wäre für mich Teil des USP..

[Gast]

Mist.. Muss wohl mein "Mess-Versprechen" zurückziehen.. Eben 2x gewühlt im "für Wegschmeissen verpacktes Leben".. Keinen R2buffer gefunden.
Bin nicht 100% sicher, aber sieht so aus, als hatte ich Tomaten auf den Augen.. 3 HV²BEC (einer in wohl verwirrt habender R2 Verpackung), 1 selbstgemachtes Pack aus 3 dicken Cs..
Werde trotzdem noch mal Spitzeln in nun vernebelter Unordnung.. 👺

[Gast]

Uff! Eben "wieder entdeckt" im vierten Wühlen: Hier liegen ja auch x Pappkartons mit "RC" Markierung. Fand nun einen Bufferv4 (3 2.7V 25F in Serie) und einen v3 (3 2.7V 50F in Serie).
Den v4 hatte ich offenbar auch mal an S32 (JLog3), testweise. Strippen an den Buffer gelötet, an das Interface, was dann output statt input des Buffer sein sollte.

Tja.. August 2016 "Zwangsumzug" aus einem Haus hierher. Nur 7km, aber wieder schlimmes Elektronik-Leben-Verpacken. Das endete dabei nach 40+J: https://www.qsl.net/dl7uae/
Schmiss auch ~1 Tonne servers weg von anderem Kram wie https://www.pressetext.com/news/040706027 https://www.welt.de/print-welt/artic...er-Hacker.html​ ...
Ich war dabei bis heute schlampig. Ein Thema (https://luciaphone.ch/de/) hatte ja gerade schweren "Aktiven-Platzbedarf", - dann parallel auch JLog2.x-->JLog3(S32)

Sorry, will nicht wieder als Schlampe mein Räumen unterbrechen lassen. Danach erst Fummeln zum Analysieren. ..(Kriege jetzt schon Pickel.. Nach Räumen alles schwer zu finden.)