Sicher das es ein PACE BMS ist? Sieht mir nicht wirklich so aus.
Alle sagen, dass Felicity Pace verbaut, daher die Nachfrage.
Die werden kein eigenes BMS haben oder?
@lambdasonde Felicity verbaut eigene BMS und kein PACE... Deshalb ging mein Felicity auch zurück, weil mir der Händler versicherte, dass PACE drin sei...
Habe aufgeschraub und auch im Internet gesucht... Irgendwo auch ein Forum gefunden (frag mich bitte nicht nach einem Link 
), die sich mit dem Felicity BMS auseinandersetzen und hatte dann auch ein Tool, mit dem ich auslesen konnte. Da ging aber auch wirklich nur lesen, konfigurierbar war da rein gar nichts....
Danke für die Info.
Habe ich mir schon gedacht.
Das Tool wäre natürlich schon sehr interessant.
ich lasse den Deye zukünftig die Ladespannung überwachen und das BMS wird hoffentlich balanzieren.
Ich habe gerade die Zellenspannungen im Felicity gemessen mit einem Voltmeter.
Symmetrie ist da. Bei 75% SOC -> 3,336V; bei 99%SOC 3,499V und bei 100% 3,53V.
Danach regelt der Serien-Mosfet ab und der Deye misst eine Gesamtspannung von 58V. Am Mosfet fallen ca. 3V ab, da der Felicity-BMS den Akku wegschaltet.
Fazit: Das BMS tut seinen Dienst.
Jetzt werde ich mal das Tool testen.
Was soll man da sagen? Hättest du Seite 15 gelesen wüsstest du das und hättest es wohl nich gemacht!
Du wirst vermutlich eine BIN brauchen die mit "P1247 anfängt um dein BMS wieder gerade zu ziehen.
Es gibt hier aber auch eine PbmsTools Version mit der man die 16Zellen wieder aktivieren kann, bzw. die Zellenanzahl ändern.
Das ist mit dem "BSL_Blatt Bin Archive" von @Pedaaa inkludiert im Reiter "System config", links-mittig. Schümpft sich "Cell Number Setting".
Danke dir! Ja das habe ich leider übersehen!
Die Einstellung "Cell Number Setting" funktioniert nur bedingt: Dannach wird zwar die Gesamtspannung wieder richtig angezeigt, aber die Zell-Spannungen 14-16 werden dennoch nicht angezeigt. Ebenso wird nach einem Neustart wieder die falsche Spannung angezeigt...
Firmwares mit "P1247" gibt es auch in der Archiv von @Pedaaa, aber die werden ebenso nicht akzeptiert.
Also: Falls Jemmand weitere Informationen bzw. Firmwares hat/kennt bitte mit-sharen. danke!
Da der Supplier aus China mir nicht helfen will (obwohl er das könnte, da bin ich mir sicher), hat mich das ambitioniert ein Reverse Engineering über diese 2 Firmwares anzupacken...:
- P1247V110-12290-2.50.bin ( die Firmware die bei mir funktioniert hat)
- P1247V100-14220-2.14.bin ( eine FW von BSLBATT aus der Archiv von Pedaaa, die auch das Prefix P1247 hat).
Meine Ziele sind:
- Herauszufinden, wieso bei mir nur die BIN P1247V110-12290-2.50.bin akzeptiert wird. Also was ist da anders wie bei den anderen?
- Was ist in P1247V110-12290 anders, sodass nur 13 Zellen ausgelesen werden?
Was ich bis jetzt darüber berichten kann:
- Auf der Platine habe ich die Beschriftung SST21-247-REV1.0 stehen (Daher der Grund warum nur eine Firmware mit dem Prefix "P1247" funktioniert hat, denke ich)
- Die PACE BMS verwendet als Microcontroller den STM32F446VET6 (ARM Cortex-M4, V7, little endian), 100 Pin
- Ich habe Mithilfe von Ghidra versucht die flat Binaries zu decompilieren.
- Bin teils erfolgreich geworden. Nach dem Mapping und der auto-Analyse in Ghidra, bin ich gerade dabei die relevanten Funktionen zu identifizieren.
- Aus einem mir nicht bekannten Grund, liegen die Addressen für eingie in Ghidra vordefinierten Funtionen wie Reset, außerhalb des in Binary vorhandenen Addressbereich. Vermutlich würde hier ein kompleter MCU Dump mehr helfen.
- Bis jetzt habe ich die MAIN-, Init/Setup- und einige String Manipulations-Funktionen festgelegt.
- Die Periphärie konnte ich mittels den Ghidra SVD-Loader gut identifizieren. Ich kann also in Code leichter finden, wo mit den CAN/UARTs und GPIOs interagiert wird, da die Periphärie-Addressen bekannt sind.
- Ich habe ein paar for loops entdeckt, die anscheinend für alle 16 Zellen etwas machen, aber das scheint nicht auf 13 limitiert zu sein. Es gibt irgendwo eine Variable/Loop wo nur die 13 Zellen ausgewertet werden. Den sweet spot habe ich also noch nicht aufgedeckt...
- Ebenso konnte ich paar Variablen identifizieren, aber da tue mir noch schwer mit den Datentypen und Pointer; scheint noch ein langer weg zu sein. Hat schon wer sowas gemacht und kennt Tips & Tricks um die Variablen und ihre Datentypen schneller/automatisiert zu identifizieren, ohne langwierige Code Analyze?
- Ein Differential zwischen den zwei Binaries hilft nicht ganz, da die FW 2.5 größer ist und mehrere Funktionen hat, wie die Version 2.14 (somit sind die Adressen der Funktionen unterschiedlich). Also es scheint, dass die Version 2.5 weitere Features hat, die haupt Struktur (wie zb MAIN Loop) ist jedoch gleich.
- Auf der PCB gibt es ein nicht belegtes Port zum MCU. Ich vermute, ich könnte darüber einen Dump von MCU machen und die MCU direkt flaschen. Ich muss vorerst die PIN Belegung festlegen. Hoffentlich hilft da das Datenblatt von STM32F446 oder die community weiter.
Wer selbst ein Blick über das Ghidra Projekt werfen will, oder mich unterstützen will, oder selbst ein reverse engineering starten will und nicht von 0 anfangen will, kann ich ihm gerne die Files schicken.
Die 16 Zellen werden aktiviert! Stand vor dem gleichen Problem. Du musst die 16Zellen einstellen. Dann das BMS ausschalten. Eine Minute warten. Wieder einschalten dann siehst du auch die Zellenspannungen wieder. Habe mir vorerst auch so beholfen bis ich über den Hersteller die richtige Firmware bekam.Das Pace in China nicht helfen will hab ich auch leitdlich festgestellt.
Ich habe auch ein paar Tests gemacht mit der "falschen" Version. Hätte soweit alles funktioniert. Also verloren ist dein BMS nicht denke ich. Ich fand es nur unschön das der fw Tag in pbmstools nicht passt.
Nach einem Neustart würde bei mir alles behalten.
Vielleicht liegt der Reset außerhalb und der Rest wird über einen watchdog erzwungen. Unschön aber möglich.
Danke für den Tipp. Ich habe es heute Abend auch so versucht, aber die Einstellungen bleiben nicht gespeichert. Egal wie ich den Neustart auslöse, die Spannung springt immerwieder zurück zur Summe der 13 Zellen und die anderen 3 Zellen werden nicht gemessen. Oder wie führst du das "Ausschalten" der BMS aus? Direkt von extern geführten Schalter? Oder trennst du wirklich auch die Zellen vom BMS, sodass dieser wirklich stromlos bleibt, für eine Minute?
Bezüglich Reverse Engineering:
Ich recherchiere gerade, welchen STM debugger ich mir zulegen soll; Ich schwanke zwischen ST-Link, J-Link, oder gar etwas ganz billiges wie Stlink V2 Mini-Debugger oder DollaTek T86 Link OB ARM Debugger; Ich weiß eben nicht wie "geschützt" der Flash speicher des MCUs ist. Weil wenn es read protected ist, dann werde ich vermutlich nur mit dem J-Link o.ä weiter kommen, soweit ich das richtig erfasst habe.
Ich habe die Zellen nicht getrennt. Vieleicht hat es auch mit den Dipschaltern zu tun eventuell geht das nur in einer Position ausfallsicher. Da ich da auch "rum gespielt" habe wegen der rs485 kommunikation. Das war auch mein Hauptgrund warum ich überhaupt die Firmware eingespielt hatte. Ich habe 3 Speicher und bei einem bekomme ich nur die rs485 kommunikation zustande. Die bei denen es nicht geht haben eine neuere Firmware als die Firmware des Speichers mit funktionierender rs485 kommunikation. Untereinander können diese kommunizieren und Can-Bus geht an allen. Nur die rs485 kommunikation nach aussen hin nicht. Ich hatte das Problem bei dem ersten Speicher auch. Das ging auch auf anhieb nicht. Aber nach viel lesen und rumprobieren klappte es schlußendlich. Nur jetzt bekomme ich die beiden neuern Speicher immernoch nicht zum reden.
Versuch dochmal das setzen der werte mit DIP 0,1 oder 2 Adresse. Vieleicht ist das der Grund.
Ich kann meine Kommunikations Protokolle auch nicht umschreiben. Es kommt immer ein write error wenn ich das versuche. Bei anderen hier scheint das funktioniert zu haben. Bei mir geht das nicht. Wo ich anfangs die probleme mit der rs485 kommunikation hatte, habe ich viel bei pylontech speichern geschaut um zu gucken wie das da so geht. Und am Ende ging es ja. Nur wie weiß ich nicht mehr bzw. kann es bei den anderen Speichern nicht aktivieren.
Eventuell lässt die firmware das umschreiben nicht zu. Du hast eine andere Version geflasht. Vieleicht kann der hersteller ja Funktionen nach belieben verfügbar machen bzw. sperren!?
Über den pace support bekommt man leider nicht wirklich was. Dieser Antwortet zwar löblich zeitnah. Aber der Pace-Support verweißt immer auf deinen Lieferranten bzw. Verkäufer, das dieser sich dort mit dem Problem melden soll. Und wenn das über 3-4 Ecken geht (Käufer <> Verkäufer <> Importeur <> pace) kann das ganz schön lange dauern 🙁
Und mein Importer des Speichers (habe den Verkäufer direkt Übersprungen) gibt mir leider auch nicht die informationen wie das Protokoll aufgebaut ist. Er schrieb nur das das Protokoll kompliziert sei und mit dem Umrichter harmonisieren muß. Eine Firmware bekam ich aber vom Importeur, weil ich zwei verschiedene Firmware stände hatte und darum gebeten habe um mein System "konsistent" zu bekommen. Allerdings die neuere Firmware was mein rs485 Problem nicht behebt. Aber damit kam ich zumindest von der 13zellen firmware weg.
Das ist auch ein Grund warum ich an dem reverse engineering bzw. decompiling interessiert bin. Um zusehen wie ich die protokoll manipulieren bzw. einstellen kann.
Es gilt auch noch zu überlegen ob man da wirklich soviel Zeit bzw. Geld reinstecken will. Ich kenne das auch, der Weg ist das Ziel.
Ein neues BMS kostet 140€. Ja sicher ist das nicht wenig für einen dummen Fehler weil man zu euphorisch war und mal eben geflasht hat.
Ich würde den teureren J-Link nehmen, aber was ich da an Preisen gefunden habe kostet der die hälfte vom BMS. Und du weißt dann immernoch nicht ob du einen Dump bekommst.
Was mich auch wundert ist, daß ich unheimlich wenig finde bezüglich der Thematik auslesen vom Pace etc. Ich war auch an dem Punkt das zu machen. Habe dazu tagelang Google befragt, kam mir mit dem Problem aber ziemlich "alleine" vor.
Entweder hat wirklich keiner die Probleme oder das Interesse ausser uns beiden. Oder ich suche "falsch".
Ich spreche das Thema balancing im discharge mode/idle mode mal an. Das findet man nämlich sehr häufig wenn man nach pace bms gemüse sucht.
Alle wollen das! Nur warum ist mir ein Rätzel. Es macht mit meinem Wissenstand keinen Mehrwert. Warum soll ich eine Zelle mehr entladen wenn eh entladen wird?
Warum soll ich eine Zelle entladen wenn weder geladen noch entladen wird?
Man muß außerhalb des BMS schauen wie man da was macht. Strom reduzieren während dem laden und balancing, damit der schwache balancer den Ladestrom eleminiert an der besagten Zelle. Und somit die leereren Zellen nachgezogen werden. Völliger quatsch Zellen zu entladen.
Wenn die Zellen einigermassen gleich (besten falls selektiert) sind werden die sich angleichen. Aber nicht innerhalb von 5 Zyklen. Das ist Sicher.
20-40 Zyklen und die Zellen laufen homogen auch bei einem schwachen Balancer (mit einer überlegten Ladephilosophie, nicht das was das Pace BMS ausgibt - volle kanne bis voll geladen) . Wenn nicht gibt es ein generelles Problem beim Balancer oder den Zellen.
Das BMS "muß" in den Zustand kommen wo die Zellen auseinanderdriften um den SOC und damit den Ladezustand sauber erfassen zu können. Es bringt nichts den Status zu umgehen bzw. zu unterdrücken. Mit einem ausgeglichenen Zellenverbund geht das ziemlich schnell in dem Zustand. Und da wird das BMS dann aktiv um die Zellen nicht zu überladen. Das wird aber schwer bei "volle kanne bis voll geladen". Da gibt es wirklich Änderungsbedarf so das das BMS den Strom schon reduziert bei annähendem "Voll geladen Zustand". Und das muß man (momentan) bei PACE und vielen anderen BMS halt extern lösen.
Das ist meine bescheidene Meinung bezüglich des balancing im idle.- / discharge mode.
Ich gehe deine Fragen punktuell an weil es mehrere sind 😀:
- Wieso ein Firmware upgrade?
Der Grund lag nicht nur an der Balancing Problematik... Ich habe es nicht einwandfrei geschafft, die zwei Batterien in Parallel und über den CAN Bus mit dem Deye Inverter kommunizieren zu lassen. Der Supplier aus China kam mit sehr schwachen Lösungsansätze daher, die ich sowieso schon ausprobiert habe. Entweder ist er so unfähig oder sie legen 0 Wert auf das after-sales Service. Mit einer Batterie kann der Inverter einigermaßen gut arbeiten; wenn zwei in Spiel kommen, fängt er an (1) komische/unwahre Werte anzuzeigen, oder (2) er springt zwischen den Werten der ersten und der zweiten Batterie hin und her, je nachdem wie man die DIP-Schalter stellt. Außerdem "sieht" er die zwei Batterien immer nur als ein einziges Batterie-Pack an.
Aber das Thema spreche ich ein anderes mal an, sobald ich mehr darüber weiß, weil es so ausschaut, dass die Kommunikation zum Inverter mit der neuen Firmware (FW: 2.5, die das 13-Zellen Problem hat) besser funktioniert; jetzt zeigt der Inverter auf die Li-BMS Seite zumindest eine andere Ansicht an, so als würde er verstehen, dass mehrere Batterien in Parallel angeschlossen sind: und zwar eine Liste für alle (möglichen 15) Batterien an, die man parallel anschließen kann (aber alle Werte sind noch auf 0) - Wieso sollte das Balancing stattfinden, auch dann wenn die Batterie nicht lädt?
Der Balancer von PaceBMS ist schwach und bei einer schnelleren Aufladung (bei mir der Fall ab ca. 33A) laufen vor allem 2 Zellen schnell aus dem Ruder; dann kommt es zum OV-Protection und die Batterie bricht das laden auf, was ja zu erwarten ist. Und genau da ist das Problem: wenn jetzt kein Bedarf existiert, die Batterie zu entladen, dann bleibt die Batterie in diesem Alarmzustand, bis eine Entladung stattfindet, oder man startet die BMS neu (oder man führt ein Reset aus). Überhaupt nicht lustig!
Ich weiß, Leute hier in Forum schlagen ein aktiver Balancer vor, und das wird sehr wahrscheinlich auch mein nächster Schritt sein, sobald die anderen Problemen beseitigt sind. Aktuell habe ich die Lade-Leistung auf ca. 30Ah reduziert.
Ich weiß nicht ob das bei euch auch vorkommt, aber sowie ich sehe, sinkt die aktuelle Kapazität der Batterie mit jeder Auslösung der OVP. Über das Problem mit dem Sinken der Kapazität las ich auch in anderen Berichten online. Ich habe einmal für ein paar Wochen nichts unternommen (z.B. die maximale Ladeleistung in Inverter nicht reduziert), und dann sank die tatsächliche Kapazität von 200Ah auf 130Ah runter. Was ich beobachten konnte; sobald es zum OVP kommt, wird der SOC automatisch auf 100% gesetzt und wenn davor die Batterie z.B. auf 95% geladen war, dann sinkt die tatsächliche Kapazität vermutlich um die 5%? (ich habe die Zahlen jetzt nicht genau beobachten können)... - Wieso nicht gleich ein neuen BMS kaufen?
Weil bei einem neuen PaceBMS die Frage offen bleibt, welche Firmware-Version drauf installiert ist. Und kann es dann mit der anderen Batterie kommunizieren (die eine andere FW hat)? In worst case muss ich dann gleich zwei gleich BMS kaufen. :/ Und auch wenn jetzt der J-Link nicht so günstig ist (genuine ist überhaupt extrem teuer), besteht das Potential ihn für andere Geräte rund um den Haushalt zu verwenden.
Ich glaube ich nehme diesen JLink HIER... weil der auch gleich morgen ankommt. Die V8 ist für meine Use Cases genug. Zuerst dachte ich mir, den HIER zu nehmen damit ich schon mal mit was einfaches testen kann und inzwischen einen JLink V9 aus China zu bestellen, der dann in ein paar Wochen kommt - Wieso findet man so wenig über PACE?
Finde ich auch merkwürdig. Vor allem weil man liest, dass diese Hardware oft eingesetzt wird. Über reverse engineering habe ich auch Garnichts gefunden. Ist das alles wirklich so neu? Ich glaube dass, der Preis hier keine Rolle spielt. Du kannst aber auch nicht für eine neuere Firmware eine neue HW kaufen, weil der Hersteller/Supplier die Firmware upgrades nicht zur Verfügung stellen will...
PS: Das Problem mit "Kommunikations Protokolle" umschreiben ist bei mir genauso: write error. Ist aber für mich weniger kritisch, da bei mir Deye den Pylon Protokoll versteht.
Ich denke es liegt eventuell doch an dem Protokoll bei dir. Weil so richtig reden funktioniert ja nicht bei dir. Ich habe 3 speicher a 100AH. Benutze venusos auf einem Raspberry mit canhat. Da es ein pace bms ist und ich alle Daten sauber bekomme denke ich eher das dein Deye inverter da etwas falsch interpretiert. Vieleicht würde es ja gehen wenn du das protokol einfach doch mal ändern könntest.
Wieso sollte das Balancing stattfinden, auch dann wenn die Batterie nicht lädt? Der Balancer von PaceBMS ist schwach und bei einer schnelleren Aufladung (bei mir der Fall ab ca. 33A) laufen vor allem 2 Zellen schnell aus dem Ruder; dann kommt es zum OV-Protection und die Batterie bricht das laden auf, was ja zu erwarten ist. Und genau da ist das Problem: wenn jetzt kein Bedarf existiert, die Batterie zu entladen, dann bleibt die Batterie in diesem Alarmzustand, bis eine Entladung stattfindet, oder man startet die BMS neu (oder man führt ein Reset aus). Überhaupt nicht lustig!
Das sehe ich anders. Dann ist beim laden schon was schiefgegangen bzw. läuft schief. Man kann das jetzt mit einem stärkeren balancer weg kompensieren oder einfach mal die ladestrategie überarbeiten (sofern man die Mittel hat, ich weiß nicht was Deye da alles ermöglicht.). Bei mir rennen keine zwei Zellen mehr davon wenn ich mit max 33A/pack lade. Mehr kann ich leider nicht reindrücken gibt der Lader nicht her. Das Pace BMS schaltet nur knall hart ab. bzw. meldet es meinem system das eine zelle überspannung hat und dann stoppt das laden komplett. Und ob du 98% oder 100% hast. Die Zellen rennen davon wenn diese voll sind. Anscheinend laden deine nicht gleichmässig bzw. ist die streuung sehr groß. Bei mir habe ich solch ein Verhalten nicht wenn die Speicher bzw. der Zellenverbund sich gut angepasst hat.
Aber das scheint auch eine Glaubensfrage zusein. Mit Hardware wird da für mich nur was weggemacht weil die Software hinkt.
Das mit den Kapazitätswerten habe ich auch nur anscheined etwas anders. Die neuere Firmware passt die Kapazität an, pro Ladezyklus -0.02Ah wenn der Soc nicht 100% erreicht hatte bei dem letzten laden. Der Pack mit der alten Firmware steht immer auf 100Ah.
Zudem habe ich gesehen das die ausgegeben Gesamtspannung des Packs bei der alten Firmware etwas erhöht ist. Die Gesamtspannung der Einzellzellen addiert ist geringer.
In der neueren Firmware stimmt der addierte Einzelzellenspannungswert mit der übermittelten Gesamtspannung überein.
Der Importeur hatte mir gesagt das die Unterschiede meiner beiden Firmware's darin bestünde das Kalibrier verhalten abgeändert wäre und diese sonst gleich wären.
Vieleicht war es ja der Gesamtspannungswert + die Kapazitätsanpassung. Nichts genaues weiß ich nicht.
Ja, mit der Kommunikation stimmt was nicht, und das versuche ich noch mit dem Supplier zu klären weil er mir beim Kauf versprochen hat, dass es funktionieren wird, aber er antwortet sehr zähe... Wie gesagt, die Kommunikation ist zweitrangig, solange die Spannungen und die Zellen nicht passen.
Dass die Zellen jetzt nicht sehr gut aufeinander abgestimmt sind, ist glaub ich den meisten hier bewusst, sonst würde es nicht zu sowas kommen. Aber was bleibt da sonst für Alternative? Die einzelnen Zellen tauschen? Und wer versichert mir, dass die 2 neu gekauften Zellen mehr den anderen 14 Stück ähneln als die bereits vorhandenen?
Bei 3 Akku-Packs hast du den Vorteil, dass sich die Ströme aufteilen, bei mir sind 200Ah in einem Pack à 16 Zellen. Da ist der Balancer eindeutig unterdimensioniert. Jetzt verstehe ich wieso andere Supplier meinten, dass die 100Ah Akkus lieber verkauft werden.
Das stimmt schon. Die Ströme teilen sich auf. Das war auch ein Pluspunkt bei der Auswahl der Speicher.
Damit erkauft man sich aber auch das 3 einzelne Systeme am Ende zusammen arbeiten müssen. Bei einem BMS für alle Zellen ist das einfacher.
Aber selbst ein 200Ah Speicher sollte der Balancer packen sofern die Zellen gut zusammen passen und die Verkabelung i.O. ist.
Tauschen der Zellen wird dir sicher auch nichts bringen.
Ich denke da kommst du weiter wenn du die Zellen einmal alle zusammen manuel gerade ziehst.
Und die Zellen die dir abhauen sind i.d.r. die "guten" Zellen mit dem geringsten Innenwiderstand.
Du kannst jetzt weiter so laden und dann wirst du dir die beiden Zellen durch überladen minimal schädigen. Dann sind es andere Zellen die besser sind und immer in overvoltage fahren. Solange bis die minimal geschädigt sind. Dann kommen die nächsten. u.s.w.
Also klatsch dir einen dicken Balancer da rein wenn du es nicht anders lösen kannst mit deiner vorhandenen Hardware bzw. Einstellmöglichkeiten.
Das Wochenende darf mit gute Nachrichten beginnen!
Wie ihr sieht, hat das Reverse Engineering Frucht gebracht!
Ich habe nun geschafft, in der Binary gezielt einige Werte anzupassen, sodass alle 16 Zellen aktiviert werden. 
Ich habe dann auch die Version-Nr angepasst.
Ich überlege schon die Firmware auf den anderen Akku pack auch zu flashen 😆: Ich warte aber ein paar Tage um zu sehen, wie es sich verhält