Vielen Dank für deinen Tipp und deine Hilfe.
Das mit der Kalibrierung und dem Kalibrierungs-Bit funktioniert jetzt.
Es ist also wirklich so das die ersten beiden Bytes meines Logs irgendwo anders her kommen, eventuell von dem Break?
Jetzt versuche ich aber SOC und SOH heraus zu filtern. Ist das richtig das SOC das erste Byte / 2 und SOH das zweite Byte / 2 von Frame 2C ist?
Ist das richtig das SOC das erste Byte / 2 und SOH das zweite Byte / 2 von Frame 2C ist?
nein, SOC und SOH befinden sich im Frame 5 (0x2B) -> Byte 1 SOC, Byte 2 SOH
Mit Interesse verfolge ich diesen Thread schon eine Weile. Ich habe kein IBS-System, sondern wollte eine Batterie-Überwachung basierend auf den hier verfügbaren Informationen selbst bauen. Bin mit der Spannungs- und Stromauslesung gut zurecht gekommen, kann auch die Batterieparameter setzen, scheitere aber an SOC und SOH - und zwar egal, ob ich Sensor 1 oder 2 verwende.
Meine Log-Messages starten immer mit 0xFF ... also so wie bei @xspots. Wie gesagt, für Strom und Spannung kein Problem. Bei SOC und SOH sehe ich zwar Änderungen beim Laden der Batterie (und ja, Calib-Bit = 1), die betreffenden Bytes "laufen" aber durch, d.h. während des Ladens wechselt SOC von 125% (0xFB) auf 1% (0x03) - wobei die Spannung dabei bei 13,2V liegt bei 4A Ladestrom. Überraschenderweise sind die letzten drei Bits im SOC Byte immer "011", SOC ändert sich also in 4er-Schritten.
Liegt das an meiner Hardware-Anbindung (habe das Lin-Breakout und auch einen MCP2004 direkt probiert) oder liegen die Bits anders als angegeben?
Ich habe eine 12V/92Ah VRLA/AGM-Batterie.
Ich habe auch noch Probleme mit SOC und SOH. Ich verwende die Werte aus 0x2B (Byte0 und Byte1 jeweils durch 2 geteilt).
In den Screenshots sieht man einen Ladevorgang. Am Ende des Ladevorgangs ist bei mir auch SOC=125. Das kann ja wohl nicht stimmen. Die Kapazität wird wohl korrekt angezeigt, auch wenn es eigentlich eine 9 Ah Batterie ist.
@Weminem - wenn man Deine Ladeströme anschaut, sind die bei SOC 101% und 125% schon deutlich unter 100mA - vielleicht schneidet ja die Software im professionellen Gerät das dann einfach ab und sagt 100%. Hast Du das mal mit einer größeren Batterie als 9Ah probiert? Bei mir läuft das wie gesagt quer durch und "springt" bei noch deutlich zu geringer Ladespannung (13,2V) über die 125% wieder auf 3% runter - was gegen eine "Software-Deckelung" sprechen würde. Möglicherweise hat mein Sensor die Initialisierung nicht richtig mitbekommen (also nicht verstanden, dass er an einer 92Ah Batterie hängt), obwohl er bei der Initialisierung im Frame 0x7D die 0x5C (= 92) zurück gab (7D: FF:17:03:F5:39:5C:FF:FF:FF). Hab's mehrfach wiederholt, aber Ergebnis bleibt gleich ... ist halt zeitaufwendig eine 92Ah-Batterie zu laden und wieder leer zu bekommen 
Das mit dem "Abschneiden" auf 100 % kann ich mir nicht wirklich vorstellen. Plausibel ist für mich eher die Annahme, dass der Wert nicht durch 2 geteilt wird und das SOC-Byte die Prozent auf das ganze Byte skaliert. Das würde bei meinen Messungen eher passen. Am Ende wäre es bei mir der Rohwert 250, also 250/255 * 100% = 98%.
Aber wenn hier jemand die Doku hat, wieso zerbrechen wir uns überhaupt den Kopf darüber?!?
Am Ende wäre es bei mir der Rohwert 250, also 250/255 * 100% = 98%.
Ne, der SoC geht von 0 ... 200 mit einer Auflösung von 0,5%
Steht auch in dem Github-Code.
Ich empfehle euch, wir mehrmals schon, das ganze mit einem logic analyzer zu überprüfen. Ich denke eher, ihr habt da einen Fehler in eurem Code.
Die gibts für 5 Euro und das Programm dazu ist kostenlos und kann LIN dekodieren.
Aber wenn hier jemand die Doku hat, wieso zerbrechen wir uns überhaupt den Kopf darüber?!?
Weil ich eine Erklärung unterzeichnet habe, dass ich diese nicht weiter gebe 
@nordpilger - Dein Vorschlag mit dem Netzteil "simuliert" doch nur die Spannung ... ich hoffe aber, das "I" in IBS steht für intelligent und dann sollte zumindest ein Integrator auch die rein- und rausfließenden Ströme mit einrechnen!
@wolkenschaufler - Ja, verstehe und respektiere ich! Und bin auch dankbar, dass Du uns trotzdem unter die Arme greifst! Wo wäre denn Deiner Meinung nach unser Problem? Auf der Initialisierungsebene (also der Sensor geht von falscher Batteriekapazität aus und ist von der rein-/rausfließenden Amperezahl "überrumpelt") oder ist das ein HW-Problem, also ein Verrutschen im Bitmuster? Hast Du vielleicht ein Logfile, bei dem SOC und SOH während des Ladevorgangs sauber hochlaufen? Bei mir springt nämlich SOC in 4%-Schritten (und nicht 0,5%) und SOH sieht teilweise ganz wild aus ...
also ein Verrutschen im Bitmuster?
Sowas in dieser Richtung vermute ich. Deswegen die Empfehlung mit dem LogicAnalyzer. Ich konnte da einige Fehler in meinem Code ausmerzen. Zumal das Ding in Kombination mit dem Programm in meinen Augen eine eierlegende Wollmilchsau ist. Den kann man für alles mögliche benutzen.
Hast Du vielleicht ein Logfile, bei dem SOC und SOH während des Ladevorgangs sauber hochlaufen?
Hab ich leider nicht....
Den Logic-Analyzer habe ich sogar - aber bisher nur für I2C eingesetzt :augengross:
@wolkenschaufler - Dein Tipp mit dem Logic-Analyzer hat mich auf die Spur gebracht! Seltsamerweise werden bei mir die Frames 22 (Spannung und Strom), 23 sowie 26 (Capacity) richtig gelesen, während die Frames 24 und 25 (SOC, SOH) falsch reinkommen. Im Logic-Analyzer lese ich 0x73 und 0xC8, was SOC von 57% und SOH 100% entsprechen würde. Also stimmt in meinem Programm was nicht ... Parity?
Ich steige mal in die Tiefen des LIN-Protokolls hinab :confused:
Also ... SoftwareSerial ist zum :kotzan:!!!
Alles mögliche durchprobiert, dann zum Schluss alles auf einen Arduino Mega portiert (der hat mehrere serielle HW-Port's) und siehe da, die Werte kommen richtig!
Jetzt werden zwar auch die Sync-Pulse (0x55) und die LinID nochmal eingelesen, so dass die eigentlichen Daten im 3. Byte beginnen, aber damit kann man ja umgehen ...
nutzt du exakt das Arduinosketch mit der Softwareserial-Schnittstelle? Wenn du eine Hardwareserial-Schnittstelle nutzt liegen die Bytes anders im Array, dann empfängst du auf jeden Fall noch dein selber versendetes Sync Byte + das Frame ID Byte (PID)
Darauf hatte ich schonmal hingewiesen. Die Softwareserial taugt nicht für diese Anwendung, da der Sensor zu schnell antwortet, dazu brauchts ein hardware Buffer...
P.s. ich habe für dieses Projekt ein "Blue Pill" Board auf STM32 Basis verwendet, 8 bit Mikrocontroller nutze ich kaum noch, solltest du dir mal anschauen. Der kann dank STM32duino auch in der Arduino IDE verwendet werden...
... Die Softwareserial taugt nicht für diese Anwendung, da der Sensor zu schnell antwortet, dazu brauchts ein hardware Buffer...
Das Blöde ist ja, dass drei der betrachteten fünf Frames sauber und nur Frame 24 und 25 konsistent falsch eingelesen werden. Sieht für mich nicht nach einem Timing-Problem aus: Dann wären auch die anderen Frames betroffen, denke ich.
Portiert auf einen ESP8266 läuft es - auch mit SoftwareSerial - jetzt könnte man das also auch per WLAN auslesen 
Denkst du, du kriegst den dann auch stromsparend hin? Ich hatte auch mal mit dem gebastelt, aber da war er gerade auf dem Markt und noch nicht sehr stabil .
Denkst du, du kriegst den dann auch stromsparend hin?
Der ESP nimmt um die 120mA im Normalbetrieb (WiFi an). Wenn Du ihn an Klemme 15 anschliesst, geht er mit der Zündung an und die 120mA spielen keine Rolle (so werde ich es machen). Alternativ kann man den ESP8266 in DeepSleep schicken und per Reset aufwecken (z.B. Türkontakt, wenn Du Deinen WW betrittst). Im DeepSleep nimmt er ein paar Mikroampere.
Die Stromaufnahme des IBS sowie des LIN-Interfaces (habe den MCP2004) hat man aber immer ...
Moin,
ich kann auch bestätigen, dass es am Software-Serial lag. Hab's jetzt mit einem Arduino Pro Mini gemacht (bei dem hängt kein USB-UART-IC am Hardware-Serial) und die Frames 0x2B und 0x2C werden nun korrekt eingelesen.
Was mir noch nicht ganz einleuchtet: Im Github-Code wurde Software-Serial benutzt, aber anscheinend hatte der Frank damit keine Probleme o_O
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!
