Solarbox Powerbank Prototyp V.01

Hi,

ich hab grad im Wiki den Schaltplan für einen ersten Prototyp eingepflegt.

Dabei handelt es sich um eine einfache Grundschaltung, die vor allem das Prinzip verdeutlichen soll und die noch einiger Optimierungen und Erweiterungen bedarf.

http://wiki.opensourceecology.de/images/e/e8/Mycharger1l_schema.png

Links oben ist der externe Input, das kann ein 9 bis 12V Netzteil sein, oder auch ein Solarpanel. Gleich am Eingang befindet sich eine 10A-Sicherung, selbiges nochmal rechts unten am Ausgang. Durch erstere wird die Schaltung vor Überstrom aus dem Solarpanel geschützt und durch letztere der Verbraucher vor Überstrom aus dem LiFePO4-Akku. D4 ist eine Z-Diode als Überspannungsschutz. R2 und R4 bilden den ersten Spannungsteiler mit dem die eingehende Spannung gemessen wird und sind mit einem Analogeingang vom Arduino verbunden. Als nächstes folgt Transistor Q1 welcher einen MOSFET Q2 treibt und sein Signal aus einem PWM-fähigen Digitalausgang (D6) des Arduino erhält.

Bis hierhin geht der Eingangsbereich in welchem die Spannung durch die Eingangsspannung Vin (bzw. Vsolar) vorgegeben wird. Diese Spannungkann nun durch den Mosfet mittels PWM „gechoppt“ werden und man erhält eine einstellbare und steuerbare Spannung, mit der man z.B. den Verlauf einer bestimmten Ladekurve vorgeben kann, d.h., ab hier folgt nun ein Bereich, in welchem die Spannung diejenige ist, die an der Batterie anliegt (Vbat). Doch zunächst wird noch durch Diode D3 verhindert, das es z.B. bei fehlender Sonneneinstrahlung oder nachts zu einem Rüpckstrom aus den Batterien kommt, der diese leersaugen würde.

Als nächstes folgt ein ACS714 Hall Sensor, mit welchem die eingehende Stromstärke gemessen wird und der demzufolge auch mit einem Analogeingang vom Arduino verbunden ist. Der hier gemessene Strom ist eine Summe aus dem Ladestrom der in die Batterie geht, plus dem Strom der an einen etwaigen Verbraucher geht; abgesehen von einem weiteren externen Verbraucher muss damit zumindest der Arduino versorgt werden (weclher ja über den Mosfet den Strom überhaupt erst hereinbringt). Kurz nach dem ACS714 folgt ein Jumper, der gebrückt ist. Man kann dort ein Multimeter ranhängen und die gemessenen Werte mit denen vom ACS714 abgleichen.

Nun folgt der Batterieeingang, an welchem sich zwei LiFePo4-Akkus mit zusammen 6.4V Nennleistung und z.B. 10Ah Kapazität befinden. Gleich dahinter wird aus R3 und R5 der zweite Spanmnungsteiler gebildet, mit welchem die Spannung im Batteriekreis vom Ardino gemessen wird.

Danach folgt ein einstellbarer S18V20ALV Buck/Boost/Stepup/Stepdown-Konverter, welcher die jeweils anliegende Spannung runtertransformiert auf exakt 5V. Damit ist es egal ob der Arduino gerade einen Ladealggorthmus im batteriekreis ablaufen lässt oder wie stark die Sonneneinstrahlung ist - der Arduino und auch ein etwaiger Verbraucher kriegen immer genau die 5V.

Darum folgt als nächstes eine Abzweigung zum 5V-Spannungskreis des Arduino. Dieser hat zwei mögliche Eingänge, einmal 5V, welcvher eine geregelte 5V-Spannung erwartet und in diesem Fall auch bekommt. Man könnte aber auch über den Arduino-„Haupteingang“ einspeisen, der mit Spannungen bis zu 20V noch klarkommt, weil ein 7805-Spannungsregeler gleich dahinhergeschaltet ist, aber das würde letztlich eine Verschwendung von Energie bedeuten, da der Spannungsüberschuss am 7805 einfach sinnlos verheizt würde.

Anschliessend folgt noch die zweite 10A-Sicherung und der Anschluss für den externen Verbraucher, z.B. ein Laptop oder ein Mobile-Device. D.h., dieser Ausgang sollte ausser einer Anreihklemme auch noch als USB-Buchse ausgeführt sein.

Der Arduino misst nun die Spannung am Eingangsbereich und vor allem am Akku. Sofern die Akkuspannung deutlich unter der Ladeschlussspannung liegt und natürlich auch eine externe Spannungsquelle (Solar oder Netzteil) verfügbar sind, fängt der Arduino an, über den Mosfet den Akku zu laden - zunächst mit Konstantstrom (CC-Modus), d…h., die Firmware passt die PWM-Pulse entsprechend an.

Sobald die Ladeschlussspannung erreicht ist, ist der LiFePO4-Akku noch nicht voll, daher wird nun die Ladeschlussspannung konstant gehalten (CV-Modus), wobei der Ladestrom kontinuierlich absinkt. Die Batterie zieht immer weniger bis sie schliesslich voll ist, d.h., wenn der Ladestrom etwa auf 1/10 des Anfangswerts gesunken ist, ist der Ladelagorithmus eigentlich beendet.

Da es sich aber bei LiFePO4-Akkus auf die Zyklenzahl sehr positiv auswirkt, wenn der Akku sich nicht stets in einem 100%ig aufgeladenen Zustand befindet, wird hernach noch etwas „Kapazität abgelassen“, d.h. da man ohnehin den Arduino als ständigen verbraucher dranhängen hat, geschieht dies quasi von selbst. Wenn nun eine gewünschte Untergrenze erreicht ist und von Seiten des Verbrauchers keine Stromanforderung besteht kann sich der Arduino dann selbst ausschalten oder in einen energiesparenden Sleep-Modus versetzen.

Die Sache funktioniert soweit schon halbwegs, hat aber noch ein paar Haken, so wie etwa den, dass noch eine Art ByPass („Powerpath“) für die externe Quelle eingerichtet werden muss, damit der Verbraucher auch versorgt werden kann, wenn z.B. kein oder nur ein leerer Akku vorhanden ist, aber eben ein Netzteil oder Solarpanel.

Nebst ein paar anderen Sachen, aber davon berichte ich ein andermal. :wink:

Gruss, Oliver

Bild1: komplette Schaltung mit LCD, und links oben sieht man eine der LiFePO4-Akkuzellen.

Bild2: Schaltung Detailansicht: Vorne der S18V20ALV, oben rechts der ACS714 und mittig ein Arduino Nano.

Auf Bild 2 sieht man links am Rand der Lochrasterplatine den externen und den Batterieanschluss und ganz rechts den Ausgang zum externen Verbraucher, alles als Anreihklemmen ausgeführt. Der S18V20ALV vorne ist ebenfalls mittels Anreihklemmen montiert (und somit austauschbar). Auch der ACS714 ist per Pinheader aufsteckbar und wird dann mit zwei Kabelschuhen verschraubt. Als Sicherungen sind hier zwei 10A Flachstecksicherungen vom Auto im Einsatz :wink:

Gruss, Oliver

Hi,

ich hab soeben noch im Wiki eine BOM-Liste für den Schaltplan und als Software den Firmware-Source ergänzt, sowie ein kleines Host-Progrämmchen, welches via USB serielle Sampling- bzw. Logging-Daten empfängt und visuell als Kurve darstellt.

Dieses Programm namens „Liquid“ ist in Processing programmiert, das ist eine Java-nahe Programmierumgebung, in welcher z.B. auch die Arduino-IDE programmiert ist.

Ich hab damit noch nie was gemacht und bin auch jetzt eigentlich eher zufällig dazu gekommen, weil ich Probleme hatte mit einer unpassenden JAVA-USB-Lib-Version, soll heissen eigentlich wollte ich das zuerst direkt in Java programmieren. Muss aber sagen dass dieses Processing irgendwie ganz nett ist.

Ich bin noch nicht ganz sicher ob ich wirklich dabei bleiben soll, zumal ich Liquid später noch zu einem komplexeren graphischen UserInterface ausbauen möchte, aaaaber

  1. zumindest dem Beipackzettel nach scheint Processing genau für solch eine Aufgabe geradezu prädestiniert zu sein

  2. da ist in Processing so ein Java-Button rechts oben i.d. Ecke, ich hab diesbezüglich so eine Ahnung als könnte man damit womöglich Java-Runtime-Code erzeugen (habs aber noch nicht ausprobiert oder doku geschaut)

Wär auf jedenfall ganz nett und ausserdem kommt mir Processing auch ohnehin wie gesagt recht Java-nahe vor, es würde mich also nicht gross wundern, wenn man in Processing Code auch beliebige Java-Objekte bzw. Libs regulär einbinden könnte. Klassischer Fall von rtfm, ich weiss :wink: aber ich kann nicht alles gleichzeitig :wink: jetzt hab ich jedenfalls erstmal den Kram ins WIki gestellt.

Gruss, Oliver

PS:
Achja, hier noch ein erster Liquid-Screenshot, auch wenns noch nicht sonderlich spektakulär ausschaut. Das Programm ist bislang kaum mehr als eine Art Software Oszi, der seine Daten über tx/rx an USB bekommt.

Hi,

ich hab jetzt ein Logo für das SolarBox Projekt erstellt:

Eigentlich würde ich das und anderes gerne in unserem Wiki einpflegen, aber da das derzeit nicht geht, hab ichs erstmal auf meine Makeable Seite gestellt … bzw. dort auch angefangen, eine eigene Porjektseite für Solarbox einzurichten.

http://makeable.de/mlab/makeable/solarbox/

Bis lang ist da noch nicht viel, aber ich hab zumidnest schonmal angefangen,d ie Speztifikationen zu konkretisieren und ein nettes Blockdiagramm erstellt.

Dank der freundlichen Unterstützung von Dacian gibts auch immense Fortschritte, was den Laderegler selbst betrifft, d.h., in Kürze wirds da auch einen Prototyp2 geben.

Hier schonmal ein Vorab-Bild vom aktuellen Schaltplan:

Ich muss da allerdings noch ein paar Sachen ergänzen, insbesondere eine Output-Option für 5V/USB und natürlich, gaaanz wichtig, den Balancer. Immerhin ist letzeterer schonmal in Vorbereitung indem in disere aktuellen version eine Einzelzell-Überwachung realisiert wird, was der erste Schritt bzw. Voraussetzung für den Balancer ist.

Gruss, Oliver

Hi,
es gibt ne neue Version vom Schaltplan.




ich hab da jetzt nen Balancer mit eingebaut, damit ist das Ding soweit rund, bzw. der grobe Rahmen abgesteckt, obs tatsächlich auch funktioniert steht noch auf nem anderen Blatt. Aber zumindest kann ich nun damit anfangen, das Layout für eine Lochrasterplatine davon zu machen. Den NDC7001C gabs leider nur als SOT23, also als SMD-Teil, das wird vermutlich ein ziemliches Gefummel den zu löten. Aber alles andere dürfte kein Problem sein.

Gruss, Oliver

In einem anderen Thread schrieb Jan:

Why does the uC always measure to ground, doesn’t have Arduino a library for differential mode?
Anyway you can just as good connect to the negative pole of the (single) cell instead of ground, then that’s the difference. And as you measure each cell anyway, then the positive of the adjacent (series) cell is just the negative of the other cell. Thus no extra wiring is required. Just add the common signal conditioning (e.g. divider circuitry, filtering, …).

So ähnlich hatte ich mir das auch zunächst vorgestellt, aber so scheints wohl nicht zu gehen, vor dem Problem stehen wohl irgendwie alle, die Einzel-Zell-Monitoring machen möchten.

Soweit ich verstanden habe liegt das Problem darin, dass der ADC im Arduino sitzt und gegen dessen GND misst, Du kannst nicht dem Arduino sagen, das er jetzt mal gerade irgendeinen Minuspunkt innerhalb das Akkupacks als GND annimmt.


And even if the uC ADC can only measure every cell positive terminal to GROUND. Then why not in the aftermath (processing) calculate the difference (because it’s known which uC pin is connected to which conditioner/cell connection circuit)? Start from the GND side and keep track of the last measured voltage value and subtract it from the current voltage value, then that should be the difference. But perhaps I’m missing something. Perhaps your uC can’t do subtraction (very unlikely) or there’s not enough (processing/CPU) time left for calculations?

nenee, das schafft der Arduino noch locker :wink: und so wie Du es beschreibst mache ich es in der aktuellen Schaltung ja auch und ich denke, für zwei Zellen mag das gerade noch so eben hinkommen, aber das Problem wird umso größer, aus je mehr Zellen das Pack besteht.

Eigentlich sind es zwei Probleme, die miteinander zu tun haben.

  1. Das Spannungsteiler-Widerstandsnetz hängt ja ständig dran, d.h. es wird ständig Strom verbraucht, was in einer Akkuanwendung möglichst minimiert werden sollte. Eine Möglichkeit wäre, das mittels Transistor an und abschaltbar zu machen und nur gezielt zum Messen anzuschalten. Deswegen hab ich in der aktuellen Version da mal nen Transistor dazwischengesetzt, siehst Du rechts unten in der Schaltung, der Transistor soll an D7 gehen, bzw. von dort aus getriggert werden. Ich hab den ind ie GND-Verbindung beider Spannungsteiler gesetzt, also einen für beide, bin mir aber gerade unsicher ob das so ok ist. Denn es gibt ja nun eine Verbindung zum Mittelabgriff zwischen den Zellen und ich frag mich ob der Strom dannnicht dorthin fliesst, wenn der Weg nach GND unterbrochen ist. grübel

  2. Das Hauptproblem besteht in der Staffelung: Dere Stromverbrauch vom untersten Spannungsteiler geht auch nur auf die unterste Zelle, aber auf die obere bzw. oberste (bei mehr als 2) Zelle geht der Strom von sämtlichen Spannungsteilern, nicht nur von dem „eigenen“. Damit werden die Zellen unterschiedlich stark entladen und systematisch aus der Balance gebracht - das Gegenteil von dem was wir wollen.

2.b. Je mehr Zellen, desto größere Voltbereiche werden überspannt. D.h, bei der untersten Zelle müssen nur 3,2V auf den 1024Bit des 10-Bit ADC vom AVR abgebildet werden, daraus resultiert eine Aflösung von 3,1mV pro Bit. Bei einem 12s-Akku hättest Du bei der obersten Zelle mit 38,4V eine Auflösung von 37,5mV, das ist schon ziemlich grob. Mehr noch, es versaut Dir das Balancing, wenn Du die Zellen mit bis zu Faktor 12 unterschiedlichen Auflösungen misst und Du zerstörst damit irgendwann die Akkus.

Soweit ich durch Internetrecherche feststellen konnte ist das Mittel der Wahl ein Differenzverstärker, mit dem Du dann tatsächlich zwischen den Zellen misst. Oft wird das dann noch durch einen Optokppler entkoppelt, ich weiss nicht genau, aber kann sein das dadurch jede messung ihren eigenen GND bekommt, aber jedenfalls lassen sich damit wieder die einzelnen Messungen gezielt an- und ab-schalten. Oder es dient zur galvanischen Trennung ?

Leider kenn ich mich Verstärkern nicht aus, geschweige denn das ich wüsste, welcher Verstärker da in Frage käme, aber ich hab in einer Schaltung die Verwendung eines TLC2274 gesehen, siehe http://endless-sphere.com/forums/viewtopic.php?f=14&t=44100 ich glaube, das werd ich mal versuchen nachzubacken. D.h., erstmal nur den Monitoring Teil, den Balancer-Teil hab ich aus einer anderen Schaltung entnommen, die auf einer Atmel-referenz basiert und einen NDC7001C Dual-N-P-Mosfet verwendet. Letzterer kommt als SMD-Bauteil daher und ist für mich deswegen eigentlich nogo, aber da er nur wenig Pins hat (und wenig kostet), sehe ich gewisse Chancen den von Hand löten zu können.

Also, bezüglich Montor und Balancer bin ich noch unschlüssig, aber ich will dennoch schonmal versuchen die Schaltung aufzubauen, vielleicht erstmal auf Breadboard, zum testen und ich layoute gerade eine PCB-Version für Lochrasterplatine.

Dazu verwende ich Fritzing. Das steckt, ähnlich wie FreeCad zwar grad noch in den Kinderschuhen, hat sich aber für Lochrasterplatinenlayouts bislang als recht nützlich für mich erwiesen. Sobald ich das layout hab poste ich mal ein Bild davon und die Sourcen (auf Github :wink:)

Gruss, Oliver

Hier das Fritzing Layout.

In dieser Darstellung hab ich die Verdrahtungsebene über die der Bauteildarstellungen gelegt, damit man den Verlauf der Lines optisch besser nachvollziehen kann.

Ich hab in dem Aufbau den Transistorswitch für den cellmonitor erst mal noch rausgelassen, nicht zuletzt auch aus Platzgründen, ich möchte das PCBnämlich noch in einem anderen konkreten Projekt verwenden, welches ich demnächst hier vorstellen werde.

So, theoretisch könnte ich jetzt anfangen, das Board zu löten, aber ich glaube ich werde vorher erstmal den ganzen Aufbau auf dem Breadboard testen, am besten modulweise. Nach all der ganzen Theorie gehts damit dann ans Eingemachte :wink:

Auf dem Board hab ich auch möglichst versucht, die Bauteile entsprechend der Modulzugehörigkeit zu Gruppen anzuordnen, links oben befindet sich der Balancer, rechts oben der Charger und ein Stück noch mit rechts unten, dann kommt, ebenfalls noch rechts unten der Discharger und links unten sind der Monitor und der Arduino angeordnet.


Gruss, Oliver

Hi,

ich hab jetzt mal versucht, die Sache systematisch anzugehen und alle relevanten Grundlagen für den Aufbau und Betrieb dieses Solarladereglers die ich im Laufe der letzten Wochen und Monate zusammengetragen habe, zu dokumentieren.

http://makeable.de/mlab/makeable/solarbox/

Damit sollte es auch für Quereinsteiger möglich sein, den aktuellen Status des Schaltungs-Designs nachzuvollziehen.

Da die Entwicklung noch nicht abgeschlossen ist, muss natürlich alles ab hier folgende ergänzt werden, insbesondere der Aufbau und das testen dieses Entwurfs, aber zumindest hat man damit schon mal die Basics auf einem Haufen :wink:

Gruss, Oliver

  1. Das Hauptproblem besteht in der Staffelung: Dere Stromverbrauch vom untersten Spannungsteiler geht auch nur auf die unterste Zelle, aber auf die obere bzw. oberste (bei mehr als 2) Zelle geht der Strom von sämtlichen Spannungsteilern, nicht nur von dem „eigenen“. Damit werden die Zellen unterschiedlich stark entladen und systematisch aus der Balance gebracht - das Gegenteil von dem was wir wollen.

2.b. Je mehr Zellen, desto größere Voltbereiche werden überspannt. D.h, bei der untersten Zelle müssen nur 3,2V auf den 1024Bit des 10-Bit ADC vom AVR abgebildet werden, daraus resultiert eine Aflösung von 3,1mV pro Bit. Bei einem 12s-Akku hättest Du bei der obersten Zelle mit 38,4V eine Auflösung von 37,5mV, das ist schon ziemlich grob. Mehr noch, es versaut Dir das Balancing, wenn Du die Zellen mit bis zu Faktor 12 unterschiedlichen Auflösungen misst und Du zerstörst damit irgendwann die Akkus.

Soweit ich durch Internetrecherche feststellen konnte ist das Mittel der Wahl ein Differenzverstärker, mit dem Du dann tatsächlich zwischen den Zellen misst. Oft wird das dann noch durch einen Optokppler entkoppelt, ich weiss nicht genau, aber kann sein das dadurch jede messung ihren eigenen GND bekommt, aber jedenfalls lassen sich damit wieder die einzelnen Messungen gezielt an- und ab-schalten. Oder es dient zur galvanischen Trennung ?

Yes, current consumption per cell is unfortunate and different current consumption per cell is potentially explosive.

Difference amplifier is great, though without level shifting I don’t see how it works. Sad the ADC’s reference can’t be changed on the fly. I saw Dacian uses STM32 (no bad choice, always wondering how that can be produced that cheaply. Okay, he’s neither using CMSIS standard library nor RODOS, that’s a bummer - I know I’m biased with the latter).
The STM32 ADC supports setting a different reference signal if I remember correctly from my previous work on it for motor control. May be alternate function?

In the broader sense of ecology and a better world un-reusable solutions make limited sense (that doesn’t mean Dacian did a bad job, to the contrary, his work can excellently complement some existing open hardware electronics, the code side needs work, but at least he didn’t use Arduino, which hasn’t enough processing power and RAM to build real solutions for this world. e.g. imagine creating a static compensator for Reactive and Active power regulation and cancelling harmonics - or for regulating voltage and frequency of generator-supplied grid islands. Also it’s not so easy to build a project from the command line which is weird. But I know Arduino has advantages too.

Leider kenn ich mich Verstärkern nicht aus, geschweige denn das ich wüsste, welcher Verstärker da in Frage käme, aber ich hab in einer Schaltung die Verwendung eines TLC2274 gesehen, siehe > http://endless-sphere.com/forums/viewtopic.php?f=14&t=44100 > ich glaube, das werd ich mal versuchen nachzubacken. D.h., erstmal nur den Monitoring Teil, den Balancer-Teil hab ich aus einer anderen Schaltung entnommen, die auf einer Atmel-referenz basiert und einen NDC7001C Dual-N-P-Mosfet verwendet. Letzterer kommt als SMD-Bauteil daher und ist für mich deswegen eigentlich nogo, aber da er nur wenig Pins hat (und wenig kostet), sehe ich gewisse Chancen den von Hand löten zu können.

I like that one learns Electronics on the way when creating electronics from scratch.
Nevertheless I hope you are not angry if I point you, additionally to your already found circuit by endless-sphere member circuitsmith, to OpenBMS. There also is a very mature (tested, used, …) 2999+ parts count high power and stackable BMS project out there for electric vehicles, which will integrate nicely with Dacian’s charger (at least that’s the hope). Nevertheless I think at this point it might confuse you. We’ll use it for the Electric car for sure (and if the current oliBMS, circuitsmithBMS and openBMS approach fails, then this mature BMS will save us.



As a sidenot, all the problems of active BMS (battery drain, switching losses, conditioning problems, ADC differential problems, galvanic isolation, uC required, …) encourage to use a simpler balancing method, i.e. passive balancing opposed to active. Of course getting rid of the shunt losses is difficult. But getting rid of most of the parts is possible using analogue circuitry only. I will post details to it over the course of the Electric car conversion. Almost finished another one of the blocking projects (typo3 addon and design task). Once that’s done, I’ll correct the generator model in the engineering spreadsheet (which will finally fix the motor torque) and finish my micro grid design (Electronic load controller, …).


Dazu verwende ich Fritzing. Das steckt, ähnlich wie FreeCad zwar grad noch in den Kinderschuhen, hat sich aber für Lochrasterplatinenlayouts bislang als recht nützlich für mich erwiesen. Sobald ich das layout hab poste ich mal ein Bild davon und die Sourcen (auf Github > :wink:> )

Holy cow! The tide is turned. Thanks man for the good news. Ask if you have questions to Git. But as far as I see, you are learning quick, so should be no problem for you to master Git. And then productivity will increase to new heights. And that’s just in time, if we consider the polarization of the world that is currently underway (mainly poor vs. rich, and also a bit west vs. east, which is a totally superfluous polarization).

Fritzing result looks already quite useful.

Thought for our recent acceleration a schematic file converter may be useful and thus quickly (cough) put together a shell script that fixes the schematic file converter.

Else epic work, comrade. Though it may be even better to combine Dacian’s charger (as it is with STM32) with this incredible electric vehicle BMS.

I’ll be of again for quite some time … need to find fitting parts for the waterwheel. It’s driving me crazy, those parts just don’t fit. I need to get to a lathe …

Aaalso, ich glaub Dacian benutzt gar nicht die ADCs vom STM32, sondern für die Zellenüberwachung ist der ISL94203 zuständig, siehe

https://www.intersil.com/content/dam/Intersil/documents/isl9/isl94203.pdf , auf S.3. Die Pinne VC0 bis VC8 stehen für „Voltage Cell“ und dahintrer hängt ein 12- oder 14 bit ADC, … so genau durchblick ich das nicht aber es ist auf S.27 beschrieben.

Bleibt die Frage, was an die ADCs vom STM32 angeschlossen wird. Ich glaube, das ist einfach nur ein Expansionsport, den man für eigene Überwachungszwecke nutzen kann und es sind ja auch nur 6 Pinne herausgeführt.

but at least he didn’t use Arduino, which hasn’t enough processing power and RAM to build real solutions for this world.
e.g. imagine creating a static compensator for Reactive and Active power regulation and cancelling harmonics - or for regulating voltage and frequency of generator-supplied grid islands. Also it’s not so easy to build a project from the command line which is weird. But I know Arduino has advantages too.

Allerdings, Du vergleichst hier Äpfel mit Birnen, der Arduino ist halt für alles gut, was man mit nem 8-Bit Prozessor erledigen kann. Und wenn ich Arduino schreibe meine ich eigentlich ATmel AVR, aber da ich die Arduino IDE ganz angenehm finde und ja auchbenutze ists ok Arduino zu sagen :wink: Aber ich glaube, Du kannst dessen IDE auch relativ easy von der Shell aus bedienen, letztlich ist die IDE nur ein Front-End, von dem aus AVR-GCC und irgendein brenner wie avr-dude getriggert werden. Ein Arduino ist einfach nur ein Atmel AVR mit nem seriellen Bootloader, wodurch man flüssiger arbeiten kann, als wenn Du immer das komplete Programm flashen musst, also beim entwickeln und testen, meine ich.

Was übrigens noch ein konkreter Grund ist der für eine 32-Bitter spricht, das ist der deutlich geringere Stromverbrauch, Dacian hatte mir dies auch schon nahegelegt. Aber ich sehe auch einen gewissen „educational“ Aspekt in diesem Projekt, daher scheint es mir der bessere Weg, erstmal ruhig weiter den Arduino als weitverbreitete Plattform (besonders in Newbie-Kreisen beliebt :wink:) zu verwenden und zu lernen und zuverstehen, wie man auch noch das letzte bischen an Optimierung in Sachen Stromverbrauch da rausquetschen kann (Sleep-Mode und andere Tricks), nicht zuletzt schärft das (bei einem Anfänger wie mir) auch das Bewustsein dafür, wiso bei einem Solarladeregler der Eigenverbrauch ein wichtiger Punkt ist (, die Profis kämpfen hier noch um die letzten uAmpere :wink:) .

Naja, und wenn ich damit durch bin, dann bin ich wahrscheinlich auch bereit, für nen STM32, aber dann weiss ich auch, warum.

Bezüglich OpenBMS, FechterGoodrum etc.: Da bin ich auch schon drüber gestolpert, aber für mich ist momentan (leider) noch ein wichtiges Auswahlkriterium, dass die Sachen simpel genug sind, das ich sie auch verstehe doer halbwegs nachvollziehen kann, da ist ein EV-BMS mit 16s oder 24s nicht gerade der ideale Quereinstieger-Ausgangspunkt, sondern das ist für mich eher sowas wie die Königsdisziplin :wink:

Aber ich versuch mich dem halt von unten anzunähern, d.h., im Mom arbeite ich an einer Powerbank_implementation mit 2s bzw. 6V, wenn die funxt würde ich das gern auch noch als 4s bzw. 12V Version machen. Damit wäre für mich dieser Bereich abgedeckt.

Ich hab aber im Solarbox-Konzept auch noch eine Klasse od. Stufe namens „Solarbox“ eBike vorgesehen, wobei ich da zunächst einfach nur an ein 12s / 36V System dachte, im Hinblick auf ein einfaches Pedelec, oder meinetwegen auch darauf basierendes Leicht-EV, wie hier diskutiert.

https://discourse.test.opensourceecology.de/t/open-source-auto/547/1

Dort habe ich auch begründet, wieso erst mal soon low-level Teil: Man hat keinen Stress mit Zulassung/Versicherung und TÜV …und ausserdem hab ich selbst ein pedelec und daher selbst den bedarf :wink:

Aber es spricht natürlich nix dagegen, in dieser Sparte auch mehrere Versionen, meinetwegen auch mit 16s oder gar 24s anzubieten, und dafür wäre m.E. der Fechtere/Goodrum-Zephyr schon ein interessanter Kandidat. Was mir daran nicht so gut gefällt ist, das er ohne uController daherkommt, das soll wohl ein Feature sein, aber ich sehs als Nachteil, denn ich möchte gerne Dinge wie die Cutoff-Levels, Entladetiefe etc. frei konfigurieren können, das ginge hier zur Not vielleicht durch ein- und auslöten einiger WIderstände aber ist halt nicht sehr komfortabel / flexibel.

Nixdestotrotz, auf der plus-Seite stehen für mich:

  • langjährig entwickelt und erprobt (wie schon von Dir angemerkt)

  • eine aktive Community

  • uuuund, gaanz wichtig: keine SMD-Bauteile :wink:

Für mich selbst wäre es ein interessanter Ansatz, zu versuchen, das Teil mal auf 12s runterzukochen, aber das ist, wie gesagt, mein persönlicher Geschmack, es spricht auch nix gegen die 16s und 24s Versionen.

Achja, und übrigens noch ein plus: Die haben da eine sehr nette BOM-Liste, in verschiedenen Ausprägungen, einschliesslich einer fix und fertigen Mouser-Bestellliste bzw. eines fertigen oder gefüllten Mouser-Einkaus-Warenkorbs …ich wiessnicht wie ich das beschreiben soll, aber bei zB. bei Reichelt kann man auch solche Projekt-bezogenen BOMs hinterlegen,; man braucht dann nur noch auf kaufen zu klicken. :wink: Übrigens kosten die kompletten Teile für den Zephyr grade mal 97,- EUR, das zeigt, das das Projekt auch kostenmässig optimiert ist, also ein weiterer Pluspunkt.

As a sidenot, all the problems of active BMS (battery drain, switching losses, conditioning problems, ADC differential problems, galvanic isolation, uC required, …) encourage to use a simpler balancing method, i.e. passive balancing opposed to active.

Ja, da bin ich inzwischen auch schon gelandet, vor allem, seit mir klar geworden ist, das dabei gar nocht soooviel Strom verbraten wird … es ist ja nur immer jeweils die vollste Zelle, aus der etwas Luft rausgelassen wird, so dass alle anderen weiter laden und sich ihr annähern können, was die dann sozusagen auf breiter Front tun, bis wieder irgendeine Zelle die vollste ist. Ich glaub nicht das diese Art von „vergeudung“ bei der Effiziens nennenswert ins Gewicht fällt, aber dafür hat man ein deutlich einfacheres System.

Of course getting rid of the shunt losses is difficult. But getting rid of most of the parts is possible using analogue circuitry only.

Bin mir nicht sicher ob ich diesen Punkt richtig verstehe, siehe Fechter/Goodrum. Wenn Du in einem analogen System die gleichen features und Flexibilität wie in einem uC-basierten haben willst, dann dürfte die Teile-Zahl und Komplexität enorm steigen. Wenn Du natürlich die Settings sozusagen hardverdrahtest, dann wirds vielleicht weniger, aber dafür kanns auch deutlich weniger, also hinkt der Vergleich.


Holy cow! The tide is turned. Thanks man for the good news. Ask if you have questions to Git.

Da ich Github ja bereits benutze bin ich diesbezüglich optimistisch, aber danke, gut zu wissen :wink:

Ich mach seit 1986 Unix-Programmierung, zu meiner Zeit nannte man das noch CVS (Concurrent Versioning System) bzw. RCS (Revision Control System). Github ist nichts anderes, nur das die Sachen auf nem Public Server ausgelagert werden, also quasi Sourceforge mit CVS.

Na, wieauchimmer, ich denke im Moment ist von den ganzen endless-sphere Sachen, die circuitsmith-Variante am interessantesten.

Ich hab gestern mal versucht, die NC7001C1 SMD-Mosfets zu löten … da ist mir doch echt ein Zacken aus der Krone gefallen. Mann, soone Fummelei. Es ist definitv klar, das das nix für ein DIY-SBMS taugt. D.h., ev. könnte man da noch was mit SOC23-Adapter-Platinchen was reissen, von daher werd ich die mühsam gelöteten Teile natürlich mal ausprobieren, aber zumindest seh ich im Balancer-Part von circuitsmith eine Alternative.

Ich werd glaubich mal ein Foto von den NC7001ern hochladen.

Gruss, Oliver

Hier das Foto.




Das kleine schwarze Scheissding am Ende der grauen Strippen ist der Dual-Mosfet …ganze 3 mm lang, wobeiman auf jeder seite davon 3 Adern anlöten muss. Das ist echtnen Job für jemand, den se mitm Klammerbeutel gepudert haben :wink: ich habs halt mal ausnahmsweise als sportliche Herausforderung betrachtet, aber ein gangbarer Weg ist das nicht. Und nicht besonders betriebssicher, dreimal dran gewackelt, schon ist eine Ader lose.

naja, ich werds jetzt trotzdem erstmal damit testen, aber auch gleich schonmal andere Teile bestellen.

Gruss, Oliver