AW: R2 Buffer V4, 3x50F nirgendwo mehr lieferbar?
Moin!
[SIZE="1"]Upfront: Ich kann nicht für R2 sprechen, war nie dort angestellt oder beteiligt, habe mich dann nur public mit R2 identifiziert zu dessen Aufwertung und, um ganzheitlich zu erscheinen. War in der Entwicklung einiger RC-Produkte von R2 beteiligt, nur aus "Pflichtgefühl" gegenüber RC Anwendern (hatte geldlich nie was davon), - das war auch ein Grund nötiger Identifizierung.
Nein, nicht das drohende Chapter Eleven für R2 war der Grund für meine Kommunikationslosigkeit bzgl. S32, CVS usw. Ich bitte Euch um Entschuldigung, war mir immer sehr peinlich. Der Grund war was anderes, existiert immer noch: Ein anderes, sehr dickes Projekt, was mich seit Juni 2015 zu 7x 16-19 zwingt (nur für JLog->S32 "klaute" ich mal 3 Monate).
Es macht keinen Sinn, Marcellinus wg. Projektunterlagen zum Buffer zu kontaktieren. Das darf er nicht rausrücken, - der InsoVerwalter hat alle Rechte.
Man kann nur was eigenes entwickeln, was ebenso funktioniert, schnell verfügbar ist. (Daher prinzipiell nicht gut, vorher öffentliche Wellen zu machen. Auch wenn man eigenständig designed, könnte es Verdacht auf Asset-Abziehen wecken, obwohl es gar nicht der Fall ist.)[/SIZE]
----------------------------------------------------------------------------------------
Zum techn. Thema:
- Nennen wir einen BEC Output "PS1" und den Buffer "PS2", - denn es ist zunächst das Parallelschalten zweier Power Supplies.
Das macht man via eine ideale Diode hinter jedem PS. Nein, keine Schottky, zu viel Verlust, sondern in aktiver Form ("OR-ing") via einen FET. Das Reverse PCB als Option zum v3 Buffer enthält genau das.
- Pervers ist zunächst, dass PS1 PS2 lädt. Tut man das mittelohmig, löst sich die Perversion. Aber! Der Buffer ist ein Cap (3 in Reihe wg. Spannungsfestigkeit solcher SuperCaps). Er kann und soll mehr bewirken als ein weniger low-impedantes PS2 in Form einer Batt. Daher besteht die Perversion doch, dass PS1 am Eingang von PS2 zwangläufig am Ausgang ebenso mit PS2 niederohmige Berührung bekommen sollte.
- Kommt hinzu, dass man als ein buffering PS Rücksicht auf Rücksichtslosigkeit und Design Flaws nehmen muss.
-. "Rücksichtslosigkeit": Manche Servos, manche FBL, allg. so ziemlich alles, handeln im Startup so, als wären sie allein auf der Welt. Tun sie aber nicht, - all die Einsiedler treffen sich in Eurem Model.
-. "Design Flaw": Leider begehen ein paar BECs Selbstmord, wenn sie im spannungslosen Zustand Nominal-Voltage an ihrem Ausgang sehen.
-. Spezialfall: Flaw in der MCU-Steuerung des BEC in JIVEpro und KOSMIK. Bereits 300mA Initial-Load reichen, um das Startup zu vereiteln. (der spätere Workaround hat Limits..)
Alles ist trivial, - nichts ist trivial ..
Daher machte BufferV4 dann alles anders:
- Das Laden des Cap ist Sache eines software-gesteuerten Buck. Sinn der ßbung:
-. Steuern des Ladestroms,
-. und zwar adaptiv zum Behavior der Eingangsspannung (voltage drop)
FET Schalter an Input und Output gibt es auch.
Damit ist das Gute gesichert (Low ESR Cap + PS2), ohne Schlechtes für Schwächlinge einbringen zu können.
-----
Wichtig ist auch, dass alles "digital" gemacht wird durch niederohmiges Schalten (Buck), nichts lineares dabei ist. Grund:
- Energie ist knapp, besonders im Notstromfalle. Also nix unnötig in Wärme wandeln.
- Wärme muss abgeführt werden. Das kostet seitens Volumen + Masse.
Das "Machen" ist hier zusammengeführt (was sein muss) in Form von Software, daher eine MCU auf dem PCB.
----------------------------------------------------------------------------------------
[SIZE="1"]Zum Wieweiter kann/will ich nichts sagen. Nur so viel: Keep cool, man wird Euch vermutlich nicht hängen lassen.[/SIZE]
Moin!
[SIZE="1"]Upfront: Ich kann nicht für R2 sprechen, war nie dort angestellt oder beteiligt, habe mich dann nur public mit R2 identifiziert zu dessen Aufwertung und, um ganzheitlich zu erscheinen. War in der Entwicklung einiger RC-Produkte von R2 beteiligt, nur aus "Pflichtgefühl" gegenüber RC Anwendern (hatte geldlich nie was davon), - das war auch ein Grund nötiger Identifizierung.
Nein, nicht das drohende Chapter Eleven für R2 war der Grund für meine Kommunikationslosigkeit bzgl. S32, CVS usw. Ich bitte Euch um Entschuldigung, war mir immer sehr peinlich. Der Grund war was anderes, existiert immer noch: Ein anderes, sehr dickes Projekt, was mich seit Juni 2015 zu 7x 16-19 zwingt (nur für JLog->S32 "klaute" ich mal 3 Monate).
Es macht keinen Sinn, Marcellinus wg. Projektunterlagen zum Buffer zu kontaktieren. Das darf er nicht rausrücken, - der InsoVerwalter hat alle Rechte.
Man kann nur was eigenes entwickeln, was ebenso funktioniert, schnell verfügbar ist. (Daher prinzipiell nicht gut, vorher öffentliche Wellen zu machen. Auch wenn man eigenständig designed, könnte es Verdacht auf Asset-Abziehen wecken, obwohl es gar nicht der Fall ist.)[/SIZE]
----------------------------------------------------------------------------------------
Zum techn. Thema:
- Nennen wir einen BEC Output "PS1" und den Buffer "PS2", - denn es ist zunächst das Parallelschalten zweier Power Supplies.
Das macht man via eine ideale Diode hinter jedem PS. Nein, keine Schottky, zu viel Verlust, sondern in aktiver Form ("OR-ing") via einen FET. Das Reverse PCB als Option zum v3 Buffer enthält genau das.
- Pervers ist zunächst, dass PS1 PS2 lädt. Tut man das mittelohmig, löst sich die Perversion. Aber! Der Buffer ist ein Cap (3 in Reihe wg. Spannungsfestigkeit solcher SuperCaps). Er kann und soll mehr bewirken als ein weniger low-impedantes PS2 in Form einer Batt. Daher besteht die Perversion doch, dass PS1 am Eingang von PS2 zwangläufig am Ausgang ebenso mit PS2 niederohmige Berührung bekommen sollte.
- Kommt hinzu, dass man als ein buffering PS Rücksicht auf Rücksichtslosigkeit und Design Flaws nehmen muss.
-. "Rücksichtslosigkeit": Manche Servos, manche FBL, allg. so ziemlich alles, handeln im Startup so, als wären sie allein auf der Welt. Tun sie aber nicht, - all die Einsiedler treffen sich in Eurem Model.
-. "Design Flaw": Leider begehen ein paar BECs Selbstmord, wenn sie im spannungslosen Zustand Nominal-Voltage an ihrem Ausgang sehen.
-. Spezialfall: Flaw in der MCU-Steuerung des BEC in JIVEpro und KOSMIK. Bereits 300mA Initial-Load reichen, um das Startup zu vereiteln. (der spätere Workaround hat Limits..)
Alles ist trivial, - nichts ist trivial ..
Daher machte BufferV4 dann alles anders:
- Das Laden des Cap ist Sache eines software-gesteuerten Buck. Sinn der ßbung:
-. Steuern des Ladestroms,
-. und zwar adaptiv zum Behavior der Eingangsspannung (voltage drop)
FET Schalter an Input und Output gibt es auch.
Damit ist das Gute gesichert (Low ESR Cap + PS2), ohne Schlechtes für Schwächlinge einbringen zu können.
-----
Wichtig ist auch, dass alles "digital" gemacht wird durch niederohmiges Schalten (Buck), nichts lineares dabei ist. Grund:
- Energie ist knapp, besonders im Notstromfalle. Also nix unnötig in Wärme wandeln.
- Wärme muss abgeführt werden. Das kostet seitens Volumen + Masse.
Das "Machen" ist hier zusammengeführt (was sein muss) in Form von Software, daher eine MCU auf dem PCB.
----------------------------------------------------------------------------------------
[SIZE="1"]Zum Wieweiter kann/will ich nichts sagen. Nur so viel: Keep cool, man wird Euch vermutlich nicht hängen lassen.[/SIZE]
Kommentar