Naja, wenn 4 Batterien aggregiert werden, dann würden diese 4 BMS schon am selben CAN-Bus hängen.
Mit Victron Venus auf einem Rpi funktioniert das in jedem Fall.
ok das habe ich irgendwie verdrängt
weil die bisherigen bms die ich hatte einen sepraten port für die kommunikation untereinander hatten
aber evtl. kannst du ja irgendwie die canbus pakete oder signale von den slaves so abändern dass es keine probleme gibt? bin jetzt kein canbus spezialist
oder man könnte an das master irgendwie ein gesondertes canbus modul hinzufügen dass den inverter mit daten versorgt unabhängig von dem anderen canbus
sma kann offiziell pylontech. pylontech hat aber so wie ich sehe auch einen separaten port für die kommunikation der bms, welcher nicht über can läuft.
soweit ich weiß macht das fast jedes bms so. der master sendet über can und der rest hängt an den internen com ports.
Projekt 80kWh / 26kWp Inselanlage - SMA Sunny Island
Sind Photovoltaik-Inselanlagen meldepflichtig?
Warum braucht man keinen 3phasen Batteriewechselrichter?
-- Sammelthread PV Anlagen Beispiele Umsetzung --
Die "Energiewende" kostet eine Kugel Eis..... pro kWh am Stromzähler.
Meine HW hat nur einen CAN Port.
Nachrichten, die einmal auf dem Bus sind, kann man nicht wieder vom Bus runternehmen.
Das ist ein echter "shared bus".
Falls das bei SMA Probleme gibt, wäre der erster Ansatz, zu schauen, ob dass bestimmte CAN IDs betrifft.
Meine eigene Kommunikation findet bewußt auf IDs statt, die sich nicht mit dem Adressbereich der Pylontech Nachrichten überschneidet, so dass, wenn jemand sein System vernünftig ausgelegt hat und HW Filter nutzt, er praktisch nichts davon mitbekommt.
Ich kann die verwendeten IDs relativ einfach verändern.
Falls das nicht funktionieren sollte, müßte ich mir irgendein kleines Board mit 2 CAN ports besorgen und das als "filternde Bridge" konfigurieren. Das wäre zwar lästig, aber auch kein ultimatives Drama.
Eine CAN Implementierung des NMEA2000 Protokolls würde alle Probleme lösen. In diesem Fall freilich nur für Victron. SMA müsste bei größeren Batterien eben draussen bleiben.
@nimbus4 Momentan betreibe ich ein 3x3 Array aus Multiplus mit RS450-200 an 32 Pylons über den LV Hub. Bei den Pylon US5000 Pouches habe ich bereits nach einer Saisson und 43 Ladezyklen den ersten Aussetzer mit Kapazitätsverlust von rund 12% zu beklagen. Daher favorisiere ich für weiteren Ausbau eine eigene Zusammenstellung aus prismatischen Zellen.
Das Folgeprojekt ist von den Modulen, Multis und Ladereglern größer und bereits soweit fortgeschritten, daß es kein Zurück mehr gibt. Batterien werden es voraussichtlich erst mal 40 Racks mit 16s, also auf jeden Fall >0,5MWh. Aufgrund der vielen Einzelracks würde ich keine 200 Amp Version benötigen sondern plane mit Strömen <0,1C. Momentan habe ich JK zur Probe. Batterien und BMS sind in der Stückzahl aber noch nicht beschafft. Jemand der mich mit einem Texas BQ von JK abbringen möchte, würde aber offene Türen einrennen. Reflow Ofen und ein älterer Bestückungsautomat Heeb fürs Hühnerfutter bis Bauform 603 stehen hier auch rum. Allerdings derzeit leider niemand mehr der davor sitzen möchte um die Reels einzurichten.
Eine CAN Implementierung des NMEA2000 Protokolls würde alle Probleme lösen.
Wenn es für das NMEA2000 Protokoll wirklich Nachfrage gibt, wäre ich durchaus bereit, das zu implementieren.
Batterien werden es voraussichtlich erst mal 40 Racks mit 16s, also auf jeden Fall >0,5MWh. Aufgrund der vielen Einzelracks würde ich keine 200 Amp Version benötigen sondern plane mit Strömen <0,1C.
Du wirst vermutlich mit 280 Ah Zellen arbeiten. < 0.1 C wären dann kleiner 28 A (Ent-)ladeströme.
Das entspricht praktisch genau dem, was ich mit den zwei 3er Anlagen hier seit mehreren Jahren machen, da kommt es nur sehr selten zu Strömen > 30 A. Der MOSFET-Schalter ( in 14p Konfiguration ) und der Shunt erwärmen sich dabei nur minmal. Nennenswert warm wird es nur, wenn Balancing aktiv ist. Das wäre mit dem aktuellen HW-Stand also völlig problemlos möglich.
Um das mal konkret zu machen:
- Wann würdest du für das Projekt HW benötigen?
- Müßte das dann über NMEA2000 laufen?
- Würdest Du MOSFET-Schalter und Shunt auf den Zellen oder abgesetzt montieren wollen?
Reflow Ofen und ein älterer Bestückungsautomat Heeb fürs Hühnerfutter bis Bauform 603 stehen hier auch rum. Allerdings derzeit leider niemand mehr der davor sitzen möchte um die Reels einzurichten.
Interessant! Aus Neugier: mit Juki oder Yamaha Feedern?
Ich habe auch Zugriff auf Bestückungsequipment.
Ich fertige alle meine Prototypen und Kleinserien selber.
FYI: Für den MOSFET Schalter und den Shunt benötigt man eine Dampfphase, da sich ein Reflow ( insbesondere ein kleiner ) mit dem Auflöten von bis zu 45 mm2 CU Streifen schwer tuen wird. Meine Standardbaugröße für Hühnerfutter ist 0402.
Der begrenzende zeitliche Faktor meinerseits ist vor allen Dingen, dass ich mit dem MOSFET-Schalter ( und unterschiedlichen MOSFET Typen ) noch eine Reihe von Tests und Messungen machen möchte, bevor ich eine größere Mengen bestücke.
Wenn es für das NMEA2000 Protokoll wirklich Nachfrage gibt, wäre ich durchaus bereit, das zu implementieren.
Von CanOpen gibt es aber weitere Protokollvorschläge welche nicht nur das BMS sondern ein gesamtes DC Netz mit Erzeugern und Verbrauchern auf der Anwendungsschicht 7 abbilden können. Da kenne ich aber noch gar keinen Hersteller der das implementiert hat. NMEA würde eben bei Victron schon heute gut funktionieren und ist im Yachtbereich langjähriger Standard. Was sich in der Zukunft durchsetzt steht in der Kristallkugel. Weder die PV/Batterie-Frickler noch die Hersteller sind heute schon so weit, daß sie wissen welche Vorteile vom CAN Bus ihnen mit den nachgebauten kompatiblen Protokollen entgeht.
Vor ein paar Wochen habe ich da auf dem CAN Bus meiner Pylons getraced. SMA, Pytes und Pylontech haben nachweislich jeweils eigenen nicht öffentlich kommunizierten Frevel in ihren CAN Protokoll-Nachbauten eingebaut um die Sache von einer Punkt zu Punkt Verbindung etwas aufzubohren. Konkret gehören bei Pylon 3 Hardware Leitungen auf den Stecker pins 1,2,3 dazu, welche in einigen Fällen nicht verbunden sein dürfen, in anderen Fällen aber verbunden sein müssen. Hierüber werden zusätzliche Geräteadressen übermittelt. Trennt man eine oder mehrere Leitungen auf, so läuft das Protokoll mitunter über Stunden, bis es wegen einer Kollision derart kracht, daß diese nicht mehr aufgelöst werden kann. An dieser Stelle habe ich das mit dem Reverse Engineering des CAN Protokolls aufgegeben. Es sind nicht nur einzelne CAN-IDs welche das Protokoll ausblasen. Aus gleichem Grund läuft auch der LV-Hub von Pytes nicht mit dem von Pylontech und umgekehrt. Einfach Finger weg und was "gescheites" machen. Gute Protokollkonzepte für Multimaster mit Tokens und Autokonfiguration gibts genug.
Du wirst vermutlich mit 280 Ah Zellen arbeiten. < 0.1 C wären dann kleiner 28 A (Ent-)ladeströme.
Das macht auch alleine Sinn wenn eine Batterie mindestens 10 Stunden für eine Nacht überbrücken kann. Im Winter sind die Nächte sogar länger und der Frühnebel verzieht sich schon im Herbst oft viel zu spät.
- Wann würdest du für das Projekt HW benötigen?
Es ist ein nicht kommerzielles Projekt wo ich für mich persönlich mache und mit meinem eigenen Taschengeld finanziere. Insofern und da bereits eine ähnliche Anlage EEG angemeldet läuft, gibt es keine Termine.
- Müßte das dann über NMEA2000 laufen?
Für JK plane ich momentan mit RS485. Solange auf deinem CAN aber mehr als 15 Slaves gehen habe ich mit dem bisherigen kompatiblen CAN bei nur einem Batterie Aggregator auch kein Problem. Die Cerbos haben ja einen extra Can Port alleine für das BMS. Mehr als 16 Busteilnehmer sollte mit 11 bit CAN Identifiern auch nicht wirklich schwierig zu machen sein. Jeder normale CAN Treiber ist schon von Haus aus für 127 Busteilnehmer spezifiziert. Die Limitierung der "kompatiblen" kommt alleine daher, dass die Chinesen alle nur 4 Dipschalter eingebaut haben.
- Würdest Du MOSFET-Schalter und Shunt auf den Zellen oder abgesetzt montieren wollen?
Bietet sich vermutlich an. Über die Mechanik habe ich mir bislang nur soweit Gedanken gemacht, daß ich mir ein passendes halboffenes 19" Blech-Abkant Chassis zeichnen werde welches ich beim Laser-Lohndienstleister dann in Stückzahl 50 rausschiessen lasse. Wenn ich alle Teile zusammen habe, mache ich ein 3D mit Solidworks (notfalls auch Freecad). Gewindestangen für die Verpressung integriert, Hochstrom Steckverbinder hinten, Bedienelemente so es welche gibt gegenüber vorne, so daß nicht alle Kabel über die Frontplatte hängen. Aus einem alten Lager habe ich noch genügend fahrbare stabile Gestelle welche das Gewicht für jeweils 6-8 Racks tragen können. 5 Gestelle a 1m nebeneinander kontaktieren dann auf dem 4m langen DC Bus an der Wand dahinter. Darüber sind dann unsere blauen Freunde verschachtelt, so daß alle Kabel <1m bleiben.
Interessant! Aus Neugier: mit Juki oder Yamaha Feedern?
Das weis ich nicht. Ich weis nur, daß es eines der ersten von Heeb verkauften Modelle ist und viele Teile wie auch die Feeder in Japan eingekauft wurden. Ich habe davon aber genug in 8mm, 12mm und sogar einige 16mm. Sie werden über einen externen Pneumatikzylinder angesteuert und haben keinen eigenen Motor. Der Automat hat keinen Werkzeugwechsler und kann keine Trays bedienen. Stangenfeeder habe ich aber einige. Das Betriebssystem bootet von Diskette in einem propietären Format und ist in Forth geschrieben. 402 gehen auch noch, aber mache ich ungern weil ich dazu die Pick-Nadel austauschen muss, damit die nicht längs im Durchmesser eingesogen werden kann. 603 bis 20pin SOIC läuft aber alles mit einer Pick Nadel. Eine Schleuniger-Jet Hohlwelle und eine Dampfphase stehen auch noch rum, sind aber schon einige Zeit nicht mehr gelaufen. Ist auch nur für eigene Prototypen und dann unregelmässig. Mit Mustern oder auch Stückzahlen <100 lockt man halt kaum einen Lohnfertiger hinter dem Ofen vor. Wenn die Stückzahlen dann mal 4-stellig werden, sieht das wieder anders aus.
Von CanOpen gibt es aber weitere Protokollvorschläge welche nicht nur das BMS sondern ein gesamtes DC Netz mit Erzeugern und Verbrauchern auf der Anwendungsschicht 7 abbilden können. Da kenne ich aber noch gar keinen Hersteller der das implementiert hat.
Ich denke, für den Moment würde es nur Sinn machen, etwas zu implementieren, wofür es auch eine Gegenstelle gibt.
"CiA® 418: CANopen device profile for battery modules" habe ich mir mal angeschaut. Das ist extrem rudimentär. Das kann ich mir in einem ESS nur vorstellen, wenn man es massiv proprietär "aufbohrt"
Es ist ein nicht kommerzielles Projekt wo ich für mich persönlich mache und mit meinem eigenen Taschengeld finanziere.
Das ich ja eigentlich eine ziemlich luxuriöse Situation, dass es da keine harte Deadline gibt.
Solange auf deinem CAN aber mehr als 15 Slaves gehen habe ich mit dem bisherigen kompatiblen CAN bei nur einem Batterie Aggregator auch kein Problem. Die Cerbos haben ja einen extra Can Port alleine für das BMS. Mehr als 16 Busteilnehmer sollte mit 11 bit CAN Identifiern auch nicht wirklich schwierig zu machen sein. Jeder normale CAN Treiber ist schon von Haus aus für 127 Busteilnehmer spezifiziert.
Im Moment sind es bei mir auch genau diese 15 Slaves.
Grundsätzlich könnte man das zwar erhöhen, ich bin aber nicht überzeugt, dass man sich damit einen Gefallen tut:
Nehmen wir mal an, man würde 100 Slaves an einem Master betreiben.
Dann würden der Master zum Aggregationszeitpunkt mit hunderten CAN-Nachrichten bombadiert.
Da die MCUs typischerweise nur sehr kleine HW-Buffer ( hier 64 byte ) haben, könnte das dann dazu führen, dass die MCU dann ~100 ms praktisch nur damit verbringt auf Interrupts vom CAN-Controller zu reagieren.
Das müßte mit sehr hoher Priorität erfolgen und würde auch mit anderen Hochprioritäts-Aufgaben wie dem Management von Bluetooth- oder WLAN-Verbindung konkurieren.
Danach müßte dann das eigentliche Aggregieren der Batteriedaten erfolgen.
Mit zunehmender Anzahl als Slaves müßte das BMS, das als Master definiert wird, also neben seinen eigentlichen Aufgaben eine erhebliche Zusatzrechenlast aufbringen.
Das führt bei gemeinsamer HW für Master und Slaves zu einer sehr ineffizienten HW-Auslegung, da Speicher- und Rechenleistungsreserven vorgehalten werden müßen, die praktisch nie genutzt werden.
Ich denke, wenn man >> 16 Slaves aggregieren möchte, sollte man dass auf getrennter HW, wie einem Rpi machen.
Da hat man dann praktisch beliebige Möglichkeiten und könnte im Zweifelsfall wohl auch 1000 Einzelbatterien aggregieren.
Aus Redundanzgründen würde ich eine große Anzahl von BMS dann auch nicht auf Gedeih und Verderb auf einen CAN-Bus zwingen.
An einem Rpi kann man über USB praktisch beliebig viele CAN-Ports anbinden, so dass eine Segmentierung mir hier auch sehr sinnvoll erscheinen würde.
Kannst Du dieser Argumnetation folgen?
Sie werden über einen externen Pneumatikzylinder angesteuert und haben keinen eigenen Motor.
Das ist bei Bauteilen >= 0402 der Standard. Ich arbeite auch fast nur mit Pneumatik-Feedern.
Das Betriebssystem bootet von Diskette
Also ein richtiger Oldtimer.
Mit Mustern oder auch Stückzahlen <100 lockt man halt kaum einen Lohnfertiger hinter dem Ofen vor.
Von dem Leid kann ich aus der Vergangenheit auch klagen.
CANopen device profile for battery modules" habe ich mir mal angeschaut. Das ist extrem rudimentär
Richtig. Deshalb hat es sich in den letzten 10 Jahren auch nicht durchgesetzt. Es hat aber alle möglichen Features in den Grundlagen dass man es aufgebohren kann und es trotzdem robust funktioniert.
Kannst Du dieser Argumnetation folgen?
Ja, das Konzept mit einer Master Batterie halte ich auch für mangelhaft. Grundsätzlich gehört die Aggregation in eine übergeordnete und unabhängige Instanz welche dann auch gleich die Plausibilitätsprüfung vornehmen kann. Bei Victron ist diese mit einem Cerbo praktisch von Haus aus vorhanden. Reine WR sind aber von der zur Verfügung stehenden Rechenpower und den Schnittstellen schwächer ausgestattet so daß sich eben die Hilfskonstruktion mit einer Master Batterie durchgesetzt hat.
Die chemischen Vorgänge in den Batterien sind in der Regel langsam und eine Zykluszeit <1 Sek würde selbst bei 100 Busteilnehmern noch locker eingehalten und könnte damit als "Echtzeit" akzeptiert werden. Das Abholen der Werte auf Interrupt, der Speicherbedarf <1kbyte und auch die Rechenzeit sind ein Klacks der auf einem Linux System im Hintergrund laufen kann ohne es groß zu belasten. Um die Zykluszeiten nicht allzu sehr zu überschreiten ist NMEA2000 für 50 Busteilnehmer begrenzt. Selbst das wäre zur Vernetzung von 40 Batterien und 6 Ladegeräten sogar noch direkt ausreichend.
Mit einem zusätzlichen Raspi als LV Hub Hardware oder Aggregator hätte ich auch kein Problem. Käufliche LV Hubs von Pylontech oder Pytes sind nicht nur teuer, sie werden auch nicht funktionieren und mit den kompatibel nachgebauten Protokollen nur Ärger machen. Um 3 Master in einem 2-stufigen Konzept mit bis zu 3x16 Batterien zusammenzufassen, braucht man das bei Venus aber nicht mal. Deshalb plane ich das JK gerade mit RS485. Grundsätzlich sollte das auch mit passenden CAN Adaptern funktionieren wenn man ein äquivalentes Gegenstück zu Serialbattery hat.
Aufgrund deiner Ausführungen im Vorstellungs Thread nehme ich an, daß der Consol Port zur Wartungszwecken direkt als USB ausgeführt ist was ja auch Sinn macht.
Wie berücksichtigt dein Design die vielen WR Anwender (Deye?) welche auf RS485 angewiesen sind?
Sind die Screendumps der gezeigten GUI aus dem BQ Studio oder hast du da selbst was geschrieben? Was hat BT mit Chrome zu tun und warum gehen andere Browser nicht? Für LAN ist dein ESP32 vermutlich nicht ganz der richtige uC weil er mit dem WLAN keine Phy ansteuern kann?
Nachdem der Sicherheits Thread ja irgendwie abgestürzt ist und Shunts vielleicht gar kein Sicherheitsproblem sind, rätsle ich noch immer, warum das JK den Strom so falsch misst und das hier trotz billigen Shunts so viel besser sein soll. Auf der JK Platine kann man einen externen AD Wandler hier identifizieren. Rechtes Foto vorletzte Reihe im TSSOP14 etwas links unter dem letzten FET und über der Reihe 4 pin Optokoppler. Den Stempel kann man nicht wirklich identifizieren, aber es ist irgend ein Nachbau vom MSP/MCP 3428 mit SPI zur galvanischen Trennung. Der SO8 rechts davon ist hoffentlich der dazugehörende Operationsverstärker und die fette SMD Drossel daneben soll wohl die analoge Versorgungsspannung glätten damit der Wert nicht allzusehr wackelt. Wenn der Layouter alles richtig gemacht hat, sind von den 16 bit Auflösung vielleicht 15 nutzbar. In Lade und Entladerichtung sind das dann jeweils noch 14 bit. Bei 200 Amp / 16384 wären das immerhin noch 12mA Auflösung. Wahrscheinlich ist ein 5 Euro Wandler für JK aber viel zu teuer oder sie haben was Anderes verbockt. JK zeigt eine 0,5 Amp Auflösung was mit einem 9 bit Wandler ginge wenn die dann nicht auch noch falsch wären.
So ein "wildes" Konzept habe ich aber auch noch bei keinem anderen BMS gesehen.
Und ich lehne mich mal aus dem Fenster und behaupte, man kann ein vergleichbares Sicherheitsniveau auch mit weniger Aufwand erreichen.
Weiß Du ob, die HW bei Pylontech schon immer so aussah?
Das richt für mich alles danach, als hätten die schon mal große Problem mit der Zuverlässigkeit des MOSFET-Schalters gehabt.
Die US2000 sind in D sicher schon 10 Jahre erhältlich und haben damit zu den Ersten ihrer Gattung gehört. Jedenfalls lang bevor es bei Texas irgendwas mit BQ gegeben hat. Aufgrund der unterschiedlichen FW die getrennt gepflegt wird weis ich, daß dort noch kein Cortex M4 drin gewesen ist sondern etwas Älteres. Es ist daher anzunehmen, daß ein paar Jahre nach Markteinführung das gesamte BMS mit den bis dahin gemachten Erfahrungen von Grund auf neu aber nach aussen hin kompatibel als Redesign für die US2000C und folgenden Baureihen aufgesetzt wurde. Möglicherweise spiegelt sich diese Firmengeschichte nicht nur in einem etwas wirren Protokoll sondern auch in einer ebensolchen Hardwareschaltung des BMS wieder. Wenn man auf der Pylontech Webseite guckt, beschäftigt sich die Firma aber gar nicht mehr mit solchen "Classic" Produkten sondern möchte AC gekoppelte Gesamtlösungen anbieten um die Wertschöpfungskette und den Profit zu steigern. Längst fällige Racks in der 10 und 15kWh Klasse überlässt man Markbegleitern. Es wird sie von Pylontech wahrscheinlich nie geben. Die gesamte Produktlinie wird gar nicht mehr weiterentwickelt weshalb ich auch von Pylontech komplett weg möchte. Die Preise für einen US5000 haben sich seit Erscheinen mit etwas über 1000 Euro für Pouch Zellen praktisch kaum bewegt. Pylontech hat zwischenzeitlich eine ordentliche Marktreputation und nimmt hier einfach noch mit was der Markt hergibt bevor die Produktion zugunten neuen Produkten eingestellt wird. Wann das sein wird steht in der Kristallkugel aber es gibt schon genug Nachbauten die wegen fallender Preise und Gewinnmöglichkeiten selbst schon wieder vom Markt verschwunden sind. Auf der Party mit den HV Batterien sinkt die Stimmung momentan ja auch gewaltig.
Die chemischen Vorgänge in den Batterien sind in der Regel langsam und eine Zykluszeit <1 Sek ...
Zu dem gleichen Ergebnis bin ich auch gekommen und das Aggregieren läuft bei mir mit 1 Hz.
Aufgrund deiner Ausführungen im Vorstellungs Thread nehme ich an, daß der Consol Port zur Wartungszwecken direkt als USB ausgeführt ist was ja auch Sinn macht.
Ja genau, die "Console" liegt auf USB.
Außerdem ist sie aber auch über Bluetooth in der GUI zugänglich:
Sind die Screendumps der gezeigten GUI aus dem BQ Studio oder hast du da selbst was geschrieben? Was hat BT mit Chrome zu tun und warum gehen andere Browser nicht?
Die Screenshots stammen von einer selbst enwickelten GUI, die im Browser läuft.
Die GUI ist im Grunde einfach eine Website ( html und javascript ).
Um aus dem Browser auf BT Geräte zuzugreifen, gibt es "Web Bluetooth".
Leider hat das bis jetzt im wesentlichen nur Chrome implementiert.
Ich habe mich für diesen Weg entschieden, weil ich so sehr einfach zu einer Lösung komme, die grundsätzlich auf Linux, Windows und Mac läuft.
Über WLAN könnte diese Webseite auch direkt vom BMS bereitgestellt werden, was sehr elegant wäre.
Alternativ hätte ich mich in Qt einarbeiten müssen.
Für LAN ist dein ESP32 vermutlich nicht ganz der richtige uC weil ...
Genau, an einen ESP32C3 kann man LAN nur beschwerlich anbinden. Es gibt aber auch andere. ESP32 Varianten. Die erste Revision meines BMS lief übrigens noch auf einem STM32L4.
Bezogen auf größere Anlagen sehe den Ethernet Anschluss aber auch eher am Aggregator und nicht wirklich an jedem Slave.
rätsle ich noch immer, warum das JK den Strom so falsch misst und das hier trotz billigen Shunts so viel besser sein soll.
Ganz offen gesagt denke ich, dass die Personen, die bei JK und anderen Anbieteren ähnlicher BMS die Schaltung für die Strommessung entwickelt haben, entweder ein genaues Coulomb Counting nie wirklich auf der Anforderungsliste stehen hatten oder die Anforderungen, die dafür an die Strommessung gestellt werden, nicht wirklich verstanden haben.
Die Tatsache, dass die offensichtlich versuchen ein Coulomb Counting mit einer Auflösung von 0.5 A zu realisieren, zeigt ganz klar, dass da entweder konzeptionell oder in der Umsetzung etwas mächtig schief gelaufen ist.
Dass TI bei deren AFE in einer ganz anderen Liga unterwegs ist, wundert mich überhaupt nicht.
Das Erstaunliche ist eher, dass die das so günstig anbieten.
Um das noch mal zu konkretisieren: Mit dem 400 uOhm Shunt liegt der Messbereich bei +-300A.
Im Coulomb Counting sehe ich Stromwerte ab ~ 2 mA. Das entspricht einem Dynamik-Äquivalent von > 18 bit und eine Sensitivität von 800 nV.
Das ist natürlich nichts, was grundsätzlich spektakulär wäre. Ein DMM6500 oder gar ein DMM7510 hat Analog-HW, die da mithalten könnte. Diese Geräte kosten aber 1500 - 4000 €. TI kann so etwas für 2 USD anbieten, weil sie das Know-How und die eigenen Fertigungsanlagen haben und die Mess-HW speziell auf diese Aufgabe optimiert haben.
Unter anderem, weil ich mir gut vorstellen kann, dass viele kaum glauben können, wie gut das Coulomb Counting bei meinem BMS ist, biete ich ja an, dass ich kostenlos Muster bereitstelle, damit jeder das selber verifizieren kann. Mein BMS könnte man grundsätzlich auch parallel zu einem anderen installieren. Um die Unterschiede in der Genauigkeit rauszustellen, fände ich so einen 1 zu 1 Vergleich sogar ein sehr interessantes Setup.
Die US2000 sind in D sicher schon 10 Jahre erhältlich und haben damit zu den Ersten ihrer Gattung gehört. Jedenfalls lang bevor es bei Texas irgendwas mit BQ gegeben hat.
Ja, vor 10 Jahren war das in der Tat noch eine völlig andere Situation.
Wie berücksichtigt dein Design die vielen WR Anwender (Deye?) welche auf RS485 angewiesen sind?
Die Aussage verstehe ich nicht wirklich. Die Deye's haben nach meinem Kenntisstand einen CAN Port zur Anbindung der Batterie!?
Die Aussage verstehe ich nicht wirklich. Die Deye's haben nach meinem Kenntisstand einen CAN Port zur Anbindung der Batterie!?
War ich auch nicht wirklich sicher. Wahrscheinlich kommt das weil der alte JK gar kein CAN hatte. Da haben bei Deye alle die RS485 genommen und für Victron wurde dafür Serialbattery gestrickt. Tatsächlich kenne ich auch nur Victron und Fronius halbwegs. Von SMA halte ich mich fern und habe keine Marktübersicht von den gängigen "48Volt Clubs" welche für ein solch tolles BMS aber nützlich wäre.
Bezüglich der Aggregation ist ein mehrstufiges bzw. baumförmig verzweigtes Konzept vielleicht doch sinnvoll um diese mit kleinen Resourcen auf der Batterie direkt machen zu können. Die alten Pylon Modelle ohne C konnten ja grundsätzlich nur 8 Slaves. Später wurde das auf 12 und mit der C-Serie auf 16 aufgebohrt. Danach wurde der LV Hub dazu ergänzt. Auf der RS485 funktionieren bis heute nur zwölfeinhalb Racks. Das habe ich durch Ausprobieren mit Fhem rausgefunden. Die Requests funktionieren für alle bekannten Befehle bis zur Adresse 12 aber einige Befehle funktionieren auch noch auf Adresse 13. Darüber geht gar nichts mehr, obwohl die Master Batterie 15 Slaves aggregieren kann.
Letzte Woche habe ich ein Rack aus der 32 Rack Verschaltung rausgenommen um es mit einem Labornetzteil manuell zu balancieren. Das ist nach gut einer Woche auch gelungen so daß es zurück konnte. Um das in einer lokalen 16er CAN Gruppe wieder einzufügen oder anzuhängen, muß man nicht nur die gesamte Gruppe neu booten, sondern diese auch von den anderen Gruppen isolieren. Die Gruppen-Master sind alle auf einem CAN Bus, die Slaves innerhalb der Gruppe auf einem anderen CAN Bus so daß dies eigentlich gar nichts miteinander zu tun hat. Also immer die isolierte Gruppe neu booten, abwarten bis der Master 3 Mal piepst und dann mit weiteren Gruppen und dem Hub verbinden. Dann den Hub neu booten und hoffen daß er alle Gruppen sieht. Nicht gerade das was man als Protokoll irgendwie abgucken und kopieren sollte.
Eine mehrstufige Aggregation könnte die Vorteile aber auch nur mit einer zweiten CAN Schnittstelle ausnutzen weil sonst auch wieder alle Telegramme auf einem Bus erscheinen und koordiniert werden wollen. Aber selbst mit kurzen CAN Identifiern dürfte das auch noch machbar sein. Wenn man nicht gerade 8 bit Integer nimmt, geht bei mehrfacher Aggregation auch keine Genauigkeit verloren. Für CanOpen mit PDOs und SDOs habe ich halt schon mehrfach in verschiedenen Assemblern eigene Stacks geschrieben. Mein ehemaliger Arbeitgeber war aber auch CiA Mitglied, so daß ich auf alle PDF Dokumente komfortablen Zugriff hatte. Optionale Dinge wie Autokonfiguration, Heartbeat u.v.m. gibt es dort auch viele, aber die braucht man ja erst mal gar nicht damit es grundsätzlich mal zuverlässig funktioniert. Daher kommt es, daß ich mich nur wundern kann mit was sich die Batteriebastler mit den kompatiblen CAN Protokolle hier rumschlagen müssen.
Die erste Revision meines BMS lief übrigens noch auf einem STM32L4.
Schade daß du nicht bei den STM32 geblieben bist. Das ist das was ich hier auch regelmässig mache. ESP32 ist für mich völliges Neuland welche in den Anfangszeiten einen ziemlich schlechten Ruf bezüglich ihrer Zuverlässigkeit hatten. Das scheint aber Geschichte, denn Eltako hier im Nachbarort hat ihre Neuentwicklungen unlängst auch von PIC auf ESP32 umgestellt. Einige Dinge gehen damit schon einfacher als mit Anderen uCs. Wenn man sich bei STM nicht auf den von Cube generierten Code mit allen seinen Fehlern verlassen möchte, wird es auch schnell mühsamer.
Bezogen auf größere Anlagen sehe den Ethernet Anschluss aber auch eher am Aggregator und nicht wirklich an jedem Slave.
Eine LAN Anbindung sehe ich auch nicht bei jedem BMS erforderlich. Zur Anbindung einer komfortablen Visualisierung aber schon. Eine billige Lösung ist eben BT mit einer Handy-App aber nur für eine oder maximal wenige Batterien. Darüber hinaus ist ein Webserver komfortabel der natürlich mehr uC Resourcen frisst. Von STM32 gibt es keine Modelle mit eingebautem MAC und PHY obwohl genau dies immer wieder im STM Forum nachgefragt wird. ST möchte das nicht machen, weil das offensichtlich auch im Stromverbrauch Nachteile bringt. Bei Texas gibt es hingegen eine Cortex M4 Baureihe welche MAC und PHY integriert hat. Man braucht also nur noch eine RJ45 Buchse direkt anschliessen und mit der passenden Bibliothek hat man einen Webserver. Der Texas M4 ist übrigens auch im Pylontech LV-Hub drin aber Ethernet dortselbst nicht rausgeführt. Es sieht also aus, als ob es bei Pylontech auch mal so geplant war denn in den BMS habe sie einen billigeren chinesichen Cortex M4 Nachbau drin. Aufgrund der massiven Isolationsschlitze und Optokoppler für 1200 Volt wird die LV-Hub Platine vermutlich auch im HV Hub bei Pylontech in einer alternativen Bestückung verwendet. Das erklärt auch den hohen Preis und Aufwand gegenüber den Pytes Nachbauten die hier einiges vereinfacht haben.
Alternativ hätte ich mich in Qt einarbeiten müssen.
Hut ab und Alles richtig gemacht. Entwicklung und Pflege einer QT Anwendung sehe ich für eine Einzelperson die auch noch HW entwickelt als kaum machbar. Zur Datenübernahme von meinem Heeb Automat aus Expedition, Altium und Eagle habe ich auch eine eigene QT Anwendung. Dazu hatten wir aber mal einen ziemlich fitten Praktikanten der daran rumgedoktort hat. Ist zwar FOSS aber wir verwenden das nur intern ohne Support zu machen. Das wäre noch eine ganz andere Nummer. Ein weiterer gängiger Weg zur Visualisierung wäre irgend ein chinesisches Gateway zum Beispiel für von Waveshare mit Etherne zu irgendwas zu nutzen. Es gibt viele Modelle. Das ist "billig", kommt mit Treibern welche von Anderen für alle möglichen Betriebssyteme gepflegt werden und stellt dort eine virtuelle Schnittstelle oder einen Socket zur Verfügung. Darauf können dann wieder systemunabhängige Pakete wie Fhem (Perl), OpenHAB (Java), Grafana oder eine Kombination mit und ohne Datenbanken darauf aufsetzen. Für einen "normalen" Anwender ist sowas natürlich undiskutabel, aber die Zielgruppe des BMS wäre ja auch bevorzugt die Frickler Szene.
Da haben sich ja zwei richtig zusammen gefunden.... 
.
Könnt ihr euch vorstellen, den Grundgedanken des 7 Schicht Modells Mal auf die nötigen verschiedenen Kommunikationnen anzuwenden, die man für das PV Akku Thema braucht? Ich sehe gerade in eurer Diskussion, dass man in immer mehr verschiedenen Protokollen denken muss, statt das es eine konzeptionelle Standardisierung mit freier Wahl der Komponenten und Anbindung gibt.
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter
Letzte Woche habe ich ein Rack aus der 32 Rack Verschaltung rausgenommen um es mit einem Labornetzteil manuell zu balancieren. Das ist nach gut einer Woche auch gelungen so daß es zurück konnte. Um das in einer lokalen 16er CAN Gruppe wieder einzufügen oder anzuhängen, muß man nicht nur die gesamte Gruppe neu booten, sondern diese auch von den anderen Gruppen isolieren. Die Gruppen-Master sind alle auf einem CAN Bus, die Slaves innerhalb der Gruppe auf einem anderen CAN Bus so daß dies eigentlich gar nichts miteinander zu tun hat. Also immer die isolierte Gruppe neu booten, abwarten bis der Master 3 Mal piepst und dann mit weiteren Gruppen und dem Hub verbinden. Dann den Hub neu booten und hoffen daß er alle Gruppen sieht. Nicht gerade das was man als Protokoll irgendwie abgucken und kopieren sollte.
Das hört sich so an, als hätte dort niemand auf dem Schrim gehabt, dass in einem solchen Setup mal ein einzelnes Gerät rausgenommen und wieder reintegriert werden könnte.
Bei meinem Aggregieren läuft beispielsweise auf dem Master für jeden Slave ein WDT. Ein Slave der nicht mehr antwortet wird also automatisch rausgenommen und der freie Platz kann dann neu zugeteilt werden.
Eine mehrstufige Aggregation könnte die Vorteile aber auch nur mit einer zweiten CAN Schnittstelle ausnutzen weil sonst auch wieder alle Telegramme auf einem Bus erscheinen und koordiniert werden wollen.
Deswegen würde ich das auf einem kleinen SBC wie einem Rpi machen. Da kann man nahezu eine beliebige Anzahl von CAN-Ports verwenden.
Wenn ich mit meinem BMS eine virtuelle Batterie aus 48 Einzelpacks realisieren wollte, würde ich einem Rpi über USB 4 CANports verpassen, die Batterien zu 3 Sub-Strings mit jeweils 16 Einzelbatterien aufteilen und über den 4ten CAN Port dann zum WR gehen.
So hätte man eine simple, günstige Lösung
Bei einer so großen Anlage alle Batterien auf einen CAN-Bus zu zwingen würde ich schon deswegen nicht machen, weil dann ein einziger schwerer HW defekt auf dem Bus, alles stilllegt. Eine Segmentierung bietet direkt auch eine gewisse Redundanz und den Aggregator könnte man grundsätzlich sogar auch mehrfach ausführen.
Für CanOpen mit PDOs und SDOs habe ich halt schon mehrfach in verschiedenen Assemblern eigene Stacks geschrieben
Mit CanOpen arbeite ich seit ~ 20 Jahren. Das nutze ich in verschiedenen Projekten.
Das Grundkonzept von PDOs und SDOs nutze ich auch in proprietären Protokollen z.B. über Ethernet
Fürs Aggregieren bei meinem BMS habe ich CanOpen auch aktiv in Betracht gezogen, mich aber bewußt dagegen entschieden.
Ethernet nutze ich in eigenen Schaltungen seit ~ 25 Jahren.
In FPGAs nutze ich sogar meine eigenen MACs.
Schade daß du nicht bei den STM32 geblieben bist.
Das Preis-Leistungsverhältnis von den größeren STM32 ist im Vergleich zu den ESP32 schlicht unterirdisch.
Und dass man bei den STMs, wenn man nicht gerade von ST direkt beliefert wird, in Boom-Zeiten Bauteile praktisch nur noch über Broker zu Wucherpreisen bekommt, ist auch inakzeptabel.
Die ESP32 waren in den letzten Jahren immer verfügbar und sind so günstig und vielseitig, dass man sich da im Zweifelsfall auch einen größeren Vorrat anlegen kann.
Zur Datenübernahme von meinem Heeb Automat aus Expedition, Altium und Eagle habe ich auch eine eigene QT Anwendung
Interessant. Ich nutze dazu VisualBasic in Excel. Kann da die Pick&Place Liste, die BOM und eine "Assembly Variant" Datei einlesen und das Tool spuckt mir dann die Konfigurationsdatei für den Bestückungsautomaten und eine Einkaufsliste aus.
Das hört sich so an, als hätte dort niemand auf dem Schrim gehabt, dass in einem solchen Setup mal ein einzelnes Gerät rausgenommen und wieder reintegriert werden könnte.
Session initiate, error recovery, autorepeat request, establish/release fehlt einfach. @Carolus Es müssen nicht bei jedem Protokoll immer alle Schichten voll implementiert sein. Routing wird es etwa bei CAN nie geben. Aber es hilft ungemein dort nachzuschauen falls es nicht sowieso selbstverständlich ist, wenn man unbedingt ein völlig eigenes Protokoll neu erfinden möchte.
Von Matthijs Vader (dem Victron Chef) gibt es ein White Paper zur Kommunikation. Das ist dem Markt wie die vielen blaue Kisten um Jahre voraus. Die alten seriellen 9 bit RS485 und VE.net Protokolle stehen dort bereits als deprecated. Wenn man nicht gerade Ethernet mit ModbusTCP oder MQTT machen möchte, bleibt noch CAN und das ist dann eben VE-CAN oder NMEA2000, kurz N2K. Venus kann die Aggregation von Haus aus trotzdem noch nicht, hat aber alle Voraussetzungen das mit zusätzlicher Software nachzurüsten.
N2K funktioniert, transportiert Produkte in eine andere Klasse für die derzeit noch gutes Geld verlangt wird. Man kann hier mal auf den Screenshot Tab schauen was im Yachtbereich herstellerübergreifend üblich ist. N2K will aber schlappe 4000 USD für einen Link wo man sich die Spezifikation als PDF runterladen kann. Möchte man das dann noch kommerziell machen, muß man sich wie bei USB eine Hersteller ID kaufen und das Produkt zertifizieren lassen.
Die Tatsache, dass die offensichtlich versuchen ein Coulomb Counting mit einer Auflösung von 0.5 A zu realisieren, zeigt ganz klar, dass da entweder konzeptionell oder in der Umsetzung etwas mächtig schief gelaufen ist.
Tatsächlich zeigt JK zumindest im unteren Bereich 0,4A Schritte, was aber auch nicht viel besser ist. Der zur Rettung neu eingeführte Korrekturfaktor ist sogar nur als ein Integer mit der kleinsten Größe von 1 Amp einzugeben. Weder Seplos noch Daly sollen in der SOC Rechnung aber viel besser sein.
Deswegen würde ich das auf einem kleinen SBC wie einem Rpi machen. Da kann man nahezu eine beliebige Anzahl von CAN-Ports verwenden.
Interessant. Ich nutze dazu VisualBasic in Excel.
Excel ging mir irgendwann auf die Nerven. https://sourceforge.net/projects/cad2board/
Der Umgang mit einem reinen CAN BMS als "kompatible Blackbox" scheint immer klarer zu werden: Was für BMS mit RS485 funktioniert, sollte mit CAN äquivalent funktionieren. Zumindest für den Sonderfall von Linux (oder der Venus Variante von Victron Energy) bietet sich ein Umweg über das USB Protokoll an. Anstelle der LV-Hubs können für jede Master-Batterie eine exklusive CAN Schnittstelle an einen USB Hub angeschlossen werden. .Zusammenrechnen kann es ein auf Venus funktionierender Aggregator. Damit werden dann wirklich etwas größere Batterien mit 16,32,48 usw. BMS möglich. Für CAN muß man leider etwas tiefer in die jüngste Computergeschichte eintauchen um zu verstehen was man tut.
In Bad Liebenzell gab es in der Zeit von 2013 bis 2021 einmal eine Firma Geschwister Schneider Technologie Entwicklungs UG (HRB Stuttgart 745239) von Maximilian und Rebecca Schneider. Seit der Erfindung von CAN bei Bosch hat es schon immer Frickler gegeben, welche eine nicht vorhandene CAN Schnittstelle an ihrem PC benötigt hätten. Diese waren etwa von Vector Informatik damals aber noch sündhaft teuer. So sind die Geschwister Schneider auf die Idee gekommen, etwas bezahlbares für USB zu entwickeln. Damit mit den neuen USB2CAN Kabeln überhaupt irgendjemand irgend etwas anfangen kann, haben die Geschwist er Schneider dazu auch einen passenden Socket Treiber entwickelt. Dieser wurde bereits 2013 in der Linux-CAN Mailing Liste als Open Source Code gepostet.
Im Jahr 2016 gab es nun einen gewissen Hubert Denkmaier, welcher ebenfalls das Problem einer fehlenden CAN Schnittstelle an seinem PC hatte. Er kam dazu auf die Idee, ein CAN Kabel mit dem STM32F072 zu bauen. Allerdings hatte auch er das Problem, daß es zu diesem Kabel keine passenden Treiber gegeben hat. Für USB unter Windows und Linux gab es bereits die CDC Communication Device Class. Diese Klasse war aber vorwiegend zum Betrieb von virtuellen RS232 COM Schnittstellen gedacht. Über die Unterklasse ACM-Abstract Controll Modell lassen sich mit dem seriellen slcan Treiber Dateninhalte einer CAN Schnittstelle auf seriell asynchron umbiegen. Das bringt aber Einschränkungen und Komplikationen mit sich. Deshalb hat Hubert D. dazu in der Linux-CAN Mailing Liste nach einem solchen CAN Socket Treiber angefragt. Die Antwort dazu kam von Max Schneider und man kann sie hier nachlesen. Hubert D. hat jedenfalls seinen STM32 so programmiert, daß genau dieser vorhandene Linux Treiber ohne Änderungen gepasst hat. Weiter hat Hubert D. in der Folge auch seine Hardware und Firmware als Open Source veröffentlicht. Ein gewisser Linus Torvalds auch als Hüter des Linux Kernels bekannt, fand die Architektur dieses Projekts ebenfalls gut und hat es kurzerhand als GS_USB Socket in den Linux Kernel übernommen.
So kommt es, daß man ein solches USB2CAN Kabel heute nicht nur in Ubuntu, sondern auch seit der Venus Version 2.90~18 einfach einstecken kann. Wie man in beiliegendem Screendump sieht, funktioniert dies dann auch sofort. Zwischenzeitlich gibt es von Hubert Denkmaiers Kabel hunderte Kopien und weiterentwickelte Forks mit neueren uC Typen. Dies können mitunter auch FD-CAN, mehrkanalige Einzelkabel oder Hardware-Zeitstempel für Bus-Debugger. Über eine gezielte Enumeration von mehreren CAN Schnittstellen hat sich für Venus jemand mit passenden udev Regeln Gedanken gemacht. Beim Einsatz von mehreren gleichartigen CAN Interfaces werden hiermit feste Schnittstellennummern zugewiesen. Die Billigkopien in Alibaba & Co für CAN Interfaces sind unter diesem Hintergrund ziemlich unübersichtlich. Wahrscheinlich braucht man etwas Glück irgendwas brauchbares geliefert zu bekommen.
Momentan konnte ich ganz grob die nachfolgenden Versionen für CAN Schnittstellen recherchieren:
MCP2515 / 2518
kommt zum Betrieb auf Raspberry über diverse CAN Aufsatzplatinen ohne USB zum Einsatz. Der MCP2515 ist ein reiner CAN Controller welcher über SPI an den Mikrokontroller angeschaltet werden muß. SPI hat im Gegensatz zu I2C von Haus aus keine Adressierung, weshalb das Konzept schlecht skalierbar ist. Bei mehreren CAN Schnittstellen müssen dafür die Chip Select der einzelnen MCP2515 zusätzlich über IO Pins angesteuert werden. Umgekehrt belegt jede CAN Schnittstelle auch eine eigene Hardware Interrrupt Leitung am Controller. Nachdem es längst uC mit einem oder mehreren eingebauten CAN Schnittstellen gibt, halte ich den Baustein zwischenzeitlich ebenso wie seinen Phillips Vorgänger SAJ 1000 und Nachfolger MCP2518 für veraltet.
Allgemeines zu USB2CAN mit STM32 Controllern
Der F103 ist so ziemlich der erste Cortex M3 welcher von ST überhaupt zur Markteinführung der 32 bit Cortex angeboten wurde. Er hat zwar USB und CAN an Bord, ist aufgrund einer Fehlkonstruktionen ím internen Taktgenerator für einen USB2CAN Adapter aber unbrauchbar. Die PLL im Clock Tree kann mit ihren nachfolgenden Teilern für die einzelnen USB und CAN Peripherien nicht so eingestellt werden, daß die vorgegebenen Baudraten auf beiden Schnittstellenarten gleichzeitig passen. ST hat dies aufgrund vielfacher Beschwerden einzelner Kunden im ST Forum an späteren Versionen der STM32 Serie deshalb korrigiert.
Ein weiteres Manko ist bei ST dann aber bei einigen kleineren STM32 Gehäusen als absichtlichen Kompromiss oder vielleicht auch nur versehentlich unterlaufen. Bei der Initialisierung der STM32 wird im Anwendungscode entschieden, welche Peripherieteile als Spezialfunktionen im uC intern auf welchen IO Pin geroutet werden. Üblicherweise können dies 2,3 oder noch mehr unterschiedliche Funktionen sein, welche für einem einzelnen uC Pin alternativ ausgewählt werden können. Einige kleinere Gehäuse der STM32F haben aber so wenig Anschlüsse, daß sich die durchaus intern gleichzeitig vorhandene CAN und USB Peripherie einen einzigen Pin nach Außen teilen muß. Ein gleichzeitiger Betrieb als USB2CAN ist damit ebenfalls nicht möglich.
Firmware Updates für STM32 Controller
Die auf den CAN Kabeln vorhandenen STM32 Controller müssen zwingenderweise die passende Firmware haben. Die Firmware ist dafür verantwortlich, daß das USB Device nach der Enumeration entweder vom slcan oder vom gs_usb Treiber erkannt wird. Sollte irgendein STM32 Kabel also vom gs_usb Treiber nicht erkannt werden, so muß darauf zunächst die passende Firmwere „Candlelight“ geflasht werden. Entwickler machen das nach dem Compilieren normalerweise mit einem JTAG Kabel über welches auch der Debugger läuft. Da „normale“ Anwender zumindest normalerweise weder compilieren noch debuggen, haben sie auch keinen Compiler, keinen Debugger und kein JTAG Kabel am Start. Nachdem ein USB2CAN Kabel aber zwingenderweise immer einen USB Anschluss hat, gibt es die Möglichkeit hier ohne zusätzliche Werkzeuge über die in Windows und Linux ohnehin vorhandene USB-DFU Klasse passende Device Firmware Updates zu machen. Hierzu aber ein extra Kapitel damit es nicht zu unübersichtlich wird.
STM32F072 C8T6
oder auch STM32F042-C6 sind als Cortex M3 ist der ursprünglich auf den CAN Steckern verwendete Controller.
Die passende Firmware dazu gibt es hier: https://github.com/candle-usb/candleLight_fw
Hardware Schaltung gibts von Hubert D: https://github.com/HubertD/candleLight
STM32G0B1
ist ein Low Cost Entry Level Cortex M1 Controller. Das Design stammt von der Linux Automations GmbH in Hildesheim und kann im Gegensatz zur F072 Variante auch CAN-FD. Die Flexible Datarate Variante CAN-FD wäre für höhere Anzahlen von Batterien zwar nützlich, ist momentan aber bis auf Weiteres nicht relevant. Es ist leider davon auszugehen, daß an den kompatiblen „closed source“ Protokollen sowieso nichts gedreht werden kann.
https://github.com/linux-automation/candleLightFD/blob/main/release/candlelightfd-S01-R01/candlelightfd-S01-R01-V01/candlelightfd-S01-R01.pdf
Auf dem STM32G0B1 läuft die Anpassung der Firmware von Marc Kleine-Budde (Pengutronix).
STM32G431
als Cortex M4 uC von der chinesischen Makerbase-MKS über Alibaba / Alibaba derzeit in der Version 2.0 verfügbar. Die Version 1.0 hatte noch einen STM32F072. Die V2.0 ist auf den neuen uC angepasst. Die Pro-Version ist zusätzlich optisch isoliert. Es scheint derzeit keine Firmware Quellen zu geben?
Hervorragend!
Ich bin kein Amateur, aber ich lerne trotzdem noch.
Bürokratie schafft man nicht durch neue Regeln oder Gesetze ab.
SOC ist ein NTCV Parameter