An sich eine gute Sache, wenn man es richtig macht…
Frage: Würdet Ihr Eurem PC (kein Note-/Netbook) beim Start nur mal so 50 mal den Stecker aus der Steckdose ziehen?
Frage: Würdet Ihr, statt den PC am Netzschalter auszuschalten, mittels eines Stelltrafos so lange die Spannung runterdrehen, bis das Ding einfach und irgendwie stehen bleibt, … und später nur die Spannung wieder hoch drehen, - und dann erwarten, dass er einwandfrei funktioniert? - Zusatzfrage: Würdet Ihr das insbesondere auch dann tun, wenn an dem PC gesteuerte Gerätschaften hängen, z.B. Eure CNC-Fräsmaschine mit Antriebsmotoren unter Saft und Werkzeug eingespannt?
Ich denke, Eure Antwort wäre zweimal Nein.
Nun, so sollte man es dann auch mit der Betriebsspannung für Prozessoren halten, die bei ungeeignetem Aufschalten aus der Stützspannungsquelle “Caps” stammt. Die Rede ist von den beiden Prozessoren im JIVE sowie dem im JLog, der ja via das Diagnostikinterface des JIVE auch an dessen BEC hängt.
“Ungeeignetes Aufschalten”:
a) Die Caps befinden sich ohne Ladestrombegrenzung am Ausgang des BEC. Diese Kondensatoren sind aufgrund ihres Innenwiderstandes und der immensen Kapazität für längere Zeit, wenn sie zuvor (fast) leer waren, der blanke Kurzschluss. Hier wird jeder überlastete Spannungsregler (BEC) anders reagieren, der des JIVE wird das mit multiblen Blackouts tun, Unmassen davon. Seit der v9 der Firmware des JIVE lässt der überwachende Microcontroller des JIVE den BEC sich jeweils innerhalb von ca. 250ms erholen. - Nun passiert das oben seitens Eures PCs Apostrophierte. Die beiden Prozessoren im JIVE erfahren ein Reset im 250ms-Takt, der Prozessor eines JLog am JIVE ebenso.
b) Der Antriebsakku wird abgeklemmt, man belässt aber die Caps am BEC-Ausgang, ohne Entkopplung, die ein Einspeisen IN den BEC-Ausgang verhindert (Man will ja die Flußspannung einer Sperrdiode nicht verlieren.. ) und ohne, dass es eine Unterspannungsabschaltung der Caps gibt: Was passiert? Die Spannung der Caps sinkt allmählich. Wenn ein bestimmtes Limit erreicht ist, kann das einwandfreie Funktionieren eines jeweiligen Microcontrollers nicht mehr garantiert werden. Um Schlimmeres zu verhindern, geht der Prozessor, je nach Einstellung beim Urflashen, in den sogenannten “Brownout”. Vollnarkose. - Nun sinkt die Spannung der Caps immer langsamer und langsamer, deren Belastung nimmt mit fallender Spannung ja ebenfalls ab. - Irgendwann kommt wieder ein Antriebsakku ran, die Spannung geht wieder hoch, je nach Ladezustand der Caps mit den Effekten unter a), die Spannung war aber nie Null. - Die Wirkung davon kann mannigfaltig sein. Wenn die Spannung nicht tief genug fiel, kann das Reset eines Prozessors evtl. nicht funktionieren, der Prozzi erwacht aus der Vollnarkose und unterlässt im Programm Dinge, die er anhand eines Resets hätte tun müssen, macht fälschlich dort weiter, als ihm einer den Holzhammer auf den Kopf schlug. - JIVE: Alle möglichen Initialfunktionen, die für ein einwandfreies Funktionieren des Stellers benötigt werden, liefen u.U. nicht oder nicht richtig ab. JLog: Speicherzellen wurden längst gelöscht (Unterspannung), der Programmzustand ist nicht mehr der angenommene. Mit der Urversion 3.1 von JLog2 äußerte sich das meist dadurch, dass in CONFIG.txt falsche Inhalte zurückgeschrieben wurden.
Mit einem Wort, die Betriebsspannung der Prozessoren, die des JLog, spielt total verrückt, wenn man es sich mit den Caps zu einfach macht. In den neueren Firmwareversionen des JLog wurde nun einiges getan, um die negativen Auswirkungen von “Crazy Supply Voltage” so weit wie möglich einzudämmen: 1. Beim Startup gibt es eine Warteschleife von 5 Sekunden (“Mäusekino” der drei LEDs), in der seitens Programmzustand (evtl. immer wieder gelöschter RAM und Brownouts des Prozessors) und seitens der SD erstmal gar nichts passiert. 2. Das Schreiben in CONFIG.txt wurde auf das absolut notwendige Minimum verringert, – zuvor war CONFIG.txt immer gelöscht und neu erzeugt worden. Da die Konfigurationsdatei ja gleich am Start ausgewertet wird, war sie durch so ein “Spannungskarussel” besonders gefährdet. - Diese Maßnahmen können nicht 100%ig sein, den Logger gegen solchen Spannungsirrsinn resistent machen zu können, sie sind aber wahrscheinlich sehr wirksam und außerdem das Limit dessen, was man machen kann, ohne mit einer voluminösen Hardware auf der Platine des Loggers sein weiteres Glück im Spannungsirrenhaus zu versuchen.
Übrigens, wenn ich die Caps nicht vom BEC-Ausgang entkopple, nicht verhindere, dass IN den Ausgang eingespeist werden kann, kann es noch einen weiteren Effekt geben: Sollte der Antriebsakku ausfallen, also seine Spannung unter die auf BEC-Seite gehen, dann wird die Pufferspannungsquelle in nullkommanix vom JIVE leer kommutiert.
Okay, wenn es “ungeeignet” gibt, muss es ja auch “geeignet” geben:
Marcellinus tut das und beschreibt es hier: Zunächst sorgt er dafür, dass der Ladestrom beim Anschalten nicht über das Limit geht, was zu multiblen Kurzschlussabschaltungen des BEC führen würde. In der Version 2 seiner Schaltung entkoppelt er auch mittels einer “idealen Diode”, dabei den Spannungsverlust eliminierend, der die meisten Anwender ja von der einfachsten Form des Einsatzes einer Sperrdiode abhält, – wobei’s um deren Flußspannung geht, wenn man auch eine Schottky-Diode nimmt.
Das hier ventilierte Thema sollte man ernst nehmen. Leider Gottes sind genug “Experten” in den Foren unterwegs, die ein direktes und dauerhaftes Aufschalten der Caps auf den Ausgang des BEC unbeirrt propagieren, taub für alle Gegenargumente. Witzigerweise sind dann da auf der anderen Seite immer noch genug Leute, verwundernd, warum denn ihr JLog manchmal Mist mit dem Dateisystem der SD veranstaltet..
Daher hier noch drei wichtige Dinge angemerkt:
1. Die Sache wird besonders haarig, wenn man dann noch zusätzlich einen “Antiblitzwiderstand” einsetzt. Damit baut man das schönste R-C-Glied, Slow Motion der Spannung.
2. Es ist nicht nur der Prozessor im JLog, die MicroSD fängt vorher an, nicht mehr einwandfrei zu arbeiten (das ist ja reine Elektronik, ein Flash-Speicher), bevor der Prozessor an die erste sinnvolle (diskret einstellbare) Brownoutschwelle gelangen kann. - Trotzdem, Entspannung: Nach dem Implementieren oben beschriebener Maßnahmen gegen “Crazy Voltage” habe ich Dauertests gemacht, dabei am Stück ca. 300 Brownouts provozierend. Das Ganze erwies sich wesentlich resistenter als zuvor. Allerdings ging dabei trotzdem zweimal CONFIG.txt über den Bach, obwohl nicht geschrieben wurde. Wie das? Siehe oben, die mSD, an der Unterspannungsgrenze, kann dabei gelegentlich Eigenleben entwickeln, versteht offenbar Bahnhof auf ihrem Interface (4-Wire SPI). Allerdings gab es bei diesen Tests noch nicht die 5-sekündige Warteschleife, die kam erst danach und genau aus diesem Grunde hinein.
3. Weiter- und Zuentwicklungen, u.A. aus dem Grund unseres Themas hier, sind das Eine.. Das Andere ist, dass das natürlich nur dann Sinn macht, wenn die JLog-Anwender auch ihren Logger updaten. (Die beschriebenen Maßnahmen gibt es nicht für JLog1, auch nicht mit der Version 2.81, es passt leider nicht mehr in dessen Speicher.)
Und noch was zum Nachdenken über das reine Verwenden von Green Caps (ohne Pufferakku) mit der Ambition, damit auch noch eine Autorotation hinzukriegen:
a) Der Strombedarf der Servos ist unterschiedlich, beispielsweise sind BLS eher genügsam, während Savöx/Align und JR zulangen. Aufgrund des endlichen Innenwiderstands der Caps, es sind ja auch 2..3 in Reihe geschaltet, was den Innenwiderstand erhöht, können Stromspitzen der Servos doch zu Brownouts von Microcontrollern führen, z.B. in einem FBL-Stabi. Während V-Stabi uns dabei nur eine Schrecksekunde beschert, wäre es mit AC3X, z.B., das Ende, denn dieses Stabi würde nach dem Wiedererwachen kalibrieren wollen, kann das aber nicht in der Luft, Zeit kostete es eh.
b) Manche Servos machen komische Sachen bei Unterspannung, Savöx/Align z.B. Die fahren dann einfach auf einen Endausschlag! Tolle Sache…, direkt kontraproduktiv, eingestielt bei Auro oder kurz vor Schluss noch gepflegt umgekippt dank Green Caps… Da war dann wohl nicht der Sinn der Sache.