Hallo, im Anhang ein Bild einer CAN-Bus Aufzeichnung, welche mit PCAN-View gemacht wurde. Vielleicht kann mir jemand weiterhelfen, was in den jeweiligen CAN-ID´s steht? Die Werte sind aus einem BMZ Hyperion Batteriespeicher gesnifft und ist aus der Daisychain der Kommunikation zwischen Batteriemodulen zur BMU. Ich vermute, dass das Protokoll, irgendwas in Richtung CAN open CiA418 oder so ist, bin mir hier aber nicht sicher. Gruß Jusch
Angehängte Dateien:
-
BMZ_1.jpg
230 KB
:
Verschoben durch Moderator
Ohne CAN‑Matrix und Signal‑Definitionen sind die Rohdaten ziemlich nutzlos. Du kannst danach googlen oder selbst rekonstruieren, ersteres geht vermutlich schneller.
Jo, viel zu extrahieren ist da nicht. Wenn es Canopen sein sollte, sollten die IDs über ein EDS zu dekodieren sein - da werden die Dinger eingestellen und welche Funktion sie haben. Ansonsten bist Du auf einer spaßigen Reise des ReverseEngineerings unterwegs, viel Glück dabei.
Marius schrieb: > BMZ_1.jpg > ... > im Anhang ein Bild einer CAN-Bus Aufzeichnung, welche mit PCAN-View > gemacht wurde. Wichtige Regeln - erst lesen, dann posten! Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen. Das ist doch nicht sooh schwierig zu verstehen. Guck dir nach ID sortiert an, wie sich die Daten z.B. mit Ladung, Entladung, Temperatur, ... ändern und ob das zu CiA 418 passt. Ohne Referenzdaten oder Doku kann man nichts damit anfangen. Viel Spaß. https://www.can-cia.org/can-knowledge/cia-418-canopen-device-profile-for-battery-modules
sortier mal nach den IDs und der Zykluszeit wenn es eine Dasy Chain ist lassen sich meis ähnliche Blöcke finden zb 181 Spannung Modul 1 182 Spannung Modul 2 183 Spannung Modul 3 381 Temp Modul 1 382 Temp Modul 2 383 Temp Modul 3 (bei dir sehe ich immer 6 Blöcke mit der selben Zykluszeit. da ist wahrscheinlich etwas ähnliches drin.) log mal einen kompletten Lade / Entlade Zyklus mit und plotte alle byte Werte eines Sets aus je einem "Moduldatensatz". Dann siehst du sehr schnell, was da los ist, außer die "verschlüsseln" das irgendwie und setz die daten als csv hier rein
:
Bearbeitet durch User
Das sagt der Chat_5.4:
Ja — **teilweise**. Ich kann aus dem Screenshot einige **plausible
Strukturen und Felder** ableiten, aber **nicht belastbar das komplette
BMZ-Hyperion-Protokoll** rekonstruieren, solange kein
DBC/Protokolldokument oder ein längerer Log mit Zustandsänderungen
vorliegt. Ich erfinde dir da lieber nichts zusammen.
### Was man aus dem Screenshot ziemlich gut erkennen kann
Im Trace sieht man mehrere Gruppen von CAN-IDs:
- `0C2h, 0C3h, 0C1h`
- `102h, 103h, 101h`
- `142h, 143h, 141h`
- `182h, 183h, 181h`
- `1C2h, 1C3h, 1C1h`
- `382h, 383h, 381h`
- `4C3h`
- `6C1h, 6C2h, 6C3h`
- `085h, 202h, 242h, 282h`
Das sieht **sehr stark nach einem zyklischen Multi-Frame-Schema pro
Batterie-String/Modul** aus:
- Suffix `1/2/3` könnte auf **drei Slaves drei Packs drei Module**
hindeuten.
- Die Blöcke `0x100`, `0x140`, `0x180`, `0x1C0` scheinen je Pack
unterschiedliche Signalgruppen zu übertragen.
---
## Auffällige Muster im Screenshot
Ich lese aus dem Bild u. a. folgende Frames:
### Gruppe für „Kanal 2“
- `0C2h`: `01 00 00 00 00 00 00 00`
- `102h`: `00 00 00 00 00 01 1A 59`
- `142h`: `A0 0F A1 0F 03 00 1A 72`
- `182h`: `12 00 14 00 11 00 1A DA`
- `1C2h`: `FF FF 08 00 59 58 1A 61`
- `382h`: `B7 50 ED 00 00 00 0D E3`
- `6C2h`: `C3 E1 10 40 00 00 00 00`
### Gruppe für „Kanal 3“
- `0C3h`: `01 00 00 00 00 00 00 00`
- `103h`: `00 00 00 00 00 01 14 FF`
- `143h`: `99 0F A4 0F 41 00 14 31`
- `183h`: `12 00 13 00 05 00 14 69`
- `1C3h`: `00 00 18 00 58 58 14 5A`
- `383h`: `B7 50 ED 00 00 00 0A B0`
- `6C3h`: `C3 E1 10 40 00 00 00 00`
### Gruppe für „Kanal 1“
- `0C1h`: `01 00 00 00 00 00 00 00`
- `101h`: `00 01 00 00 00 01 1F 76`
- `141h`: `98 0F 9C 0F 81 00 1F 5B`
- `181h`: `12 00 13 00 03 00 1F A3`
- `1C1h`: `00 00 10 00 56 56 1F 04`
- `381h`: `B7 50 ED 00 00 00 10 AF`
- `6C1h`: `C3 E1 10 40 00 00 00 00`
---
## Sehr wahrscheinliche Interpretation
### 1) `0C1h/0C2h/0C3h`
`01 00 00 00 00 00 00 00`
Das wirkt wie:
- **Heartbeat Alive Status gültig**
- Byte 0 = `01` = Gerät online Daten gültig Freigabe vorhanden
Mehr kann man daraus ohne Vergleichsdaten nicht seriös sagen.
---
### 2) `141h/142h/143h` → sieht stark nach **Zellspannungen-Min/Max +
Zellnummer** aus
Beispiel `142h`:
`A0 0F A1 0F 03 00 1A 72`
Wenn man Little-Endian 16-bit liest:
- Byte0..1 = `0x0FA0` = **4000**
- Byte2..3 = `0x0FA1` = **4001**
- Byte4..5 = `0x0003` = **3**
- Byte6..7 = `0x721A` oder CRC/Counter?
Vorsicht: im CAN sind das einfach zwei weitere Bytes `1A 72`; je nach
Endianness `0x721A = 29210`.
Das ist **extrem typisch** für:
- `U_cell_min = 4000 mV`
- `U_cell_max = 4001 mV`
- `cell_index = 3`
Weitere Beispiele passen ebenfalls:
- `141h`: `98 0F 9C 0F 81 00 1F 5B`
- `0x0F98 = 3992 mV`
- `0x0F9C = 3996 mV`
- `0x0081 = 129` → das wirkt **nicht** wie einfache Zellnummer, eher:
- obere Bits = Flags
- untere Bits = Zellindex
- oder zwei 8-bit Felder
- `143h`: `99 0F A4 0F 41 00 14 31`
- `0x0F99 = 3993 mV`
- `0x0FA4 = 4004 mV`
- `0x0041 = 65`
**Fazit:**
Die ersten 4 Bytes sind **sehr wahrscheinlich Spannungswerte in mV**.
Byte 4/5 enthalten wahrscheinlich **Index/Flags zu min/max-Zelle**.
---
### 3) `181h/182h/183h` → vermutlich **Temperaturen** oder weitere
Extremwerte
Beispiel `182h`:
`12 00 14 00 11 00 1A DA`
Als 16-bit little-endian:
- `0x0012 = 18`
- `0x0014 = 20`
- `0x0011 = 17`
Das sieht stark nach:
- **T_min = 18 °C**
- **T_max = 20 °C**
- **Sensor-ID = 17**
Andere Beispiele:
- `181h`: `12 00 13 00 03 00 ...` → 18 °C / 19 °C / Sensor 3
- `183h`: `12 00 13 00 05 00 ...` → 18 °C / 19 °C / Sensor 5
Das ist **sehr plausibel**.
---
### 4) `1C1h/1C2h/1C3h` → wahrscheinlich **Strom SoC SoH /
Statusbits**, aber nicht eindeutig
Beispiel `1C2h`:
`FF FF 08 00 59 58 1A 61`
Mögliche Zerlegung:
- `0xFFFF` = ungültig nicht verwendet signed = `-1`
- `0x0008` = Status oder Zähler
- `0x59 = 89`
- `0x58 = 88`
Die beiden Bytes `59 58`, `58 58`, `56 56` sind auffällig. Das könnte
sein:
- SoC / SoH in Prozent
- zwei gleiche oder fast gleiche Kennwerte
- Durchschnitts-/Grenzwerte
Aber: **nicht belastbar**.
---
### 5) `381h/382h/383h` → sehr wahrscheinlich **Packspannung** oder
**Energie-/Leistungswert**
Beispiel:
- `381h`: `B7 50 ED 00 00 00 10 AF`
- `382h`: `B7 50 ED 00 00 00 0D E3`
- `383h`: `B7 50 ED 00 00 00 0A B0`
Die ersten 3 Bytes sind bei allen gleich:
- `B7 50 ED`
Als 24-bit little-endian:
- `0xED50B7 = 15,552,695` → roh wenig intuitiv
- oder als andere Skalierung Seriennummer Kapazität / Energiezähler
Da nur die letzten zwei Bytes variieren, könnte das Frame sein:
- 32-bit Wert + 16-bit Prüfsumme
- oder 48-bit Datenstruktur mit Counter
Ohne mehr Daten **nicht sicher dekodierbar**.
---
### 6) `6C1h/6C2h/6C3h` → möglicherweise **Float-Wert im IEEE754**
Alle drei:
`C3 E1 10 40 00 00 00 00`
Die ersten vier Bytes little-endian gelesen:
- `0x4010E1C3`
Das sieht sehr nach IEEE754-Float aus. Ich habe den Wert nicht blind
geraten, aber er liegt ungefähr im Bereich **2.x**. Das könnte sein:
- Strom in A
- Spannung pro Zelle in V
- Innenwiderstand
- Kalibrierwert
Da für alle drei identisch, könnte es auch ein
**Konfigurationsparameter** sein.
---
### 7) `202h`, `242h`, `282h` → sieht nach **langen Bitfeldern /
Zell-Balancing / Fehlerbitmap** aus
- `202h`: `A1 0F A1 0F A1 0F A1 0F`
- `242h`: `A0 0F A1 0F A1 0F 9F 0F`
- `282h`: `A1 0F A1 0F A0 0F A1 0F`
Das sind je vier 16-bit Werte um **3999–4001 mV**.
Das könnte sehr gut sein:
- **vier Einzelzellspannungen**
- also z. B. Zellen 1–4 eines Blocks
Dann wären `242h`/`282h` evtl. weitere Zellgruppen.
Das ist eine der **stärksten Hypothesen** im ganzen Bild.
---
## Meine beste Arbeits-Hypothese für die Telegramme
| CAN-ID-Bereich | Vermutung |
|---|---|
| `0Cxh` | Heartbeat Online Freigabe |
| `10xh` | Status/Flags/Counter/Pack-spezifischer Zustandswert |
| `14xh` | Zellspannung min/max und Index/Flags |
| `18xh` | Temperatur min/max und Sensorindex |
| `1Cxh` | SoC/SoH/Strom/Statuswort |
| `20xh/24xh/28xh` | Einzelzellspannungen blockweise |
| `38xh` | Summenwert/Energiezähler/Packspannung mit Zusatzbytes |
| `6Cxh` | Float/Konfigurationswert |
---
## Was ich **nicht** belastbar behaupten würde
Ich würde **nicht** ohne weitere Daten sagen:
- welches Byte exakt **SoC**, **SoH**, **Strom**, **Leistung**,
**Spannung**, **Fehlercode** ist
- ob die letzten 1–2 Bytes eine **CRC**, ein **Rolling Counter** oder
Timestamp/Alive-Counter sind
- ob die IDs proprietär BMZ sind oder nur auf einer
Drittgeräte-Schnittstelle gespiegelt werden
Dafür bräuchte ich mehr als einen Screenshot.
---
## Was du mir geben müsstest, damit ich es sauber dekodiere
Am besten eines davon:
1. **Rohlog als Text**
- z. B. aus PCAN-View exportiert (`.trc`, `.txt`, `.asc`)
2. **Messung bei bekannten Zustandsänderungen**
- Laden EIN/AUS
- Entladen EIN/AUS
- SoC bekannt
- Packspannung bekannt
- Temperaturen bekannt
3. **Längerer Mitschnitt**
- mindestens 30–60 Sekunden
4. **Falls vorhanden:**
- DBC
- BMZ-Dokumentation
- Wechselrichter-/BMS-Protokollbeschreibung
Dann kann ich dir typischerweise:
- Signal für Signal mappen,
- Endianness prüfen,
- Skalierung ableiten,
- eine **Tabelle aller CAN-IDs** erstellen,
- und bei Bedarf sogar eine **DBC-Datei** daraus bauen.
---
## Vorläufige Dekodierung der sichtbarsten Frames
### Wahrscheinlichste Kandidaten
| ID | Daten | Wahrscheinliche Bedeutung |
|---|---|---|
| `0C1/0C2/0C3` | `01 00 00 00 00 00 00 00` | Heartbeat / aktiv |
| `141/142/143` | z. B. `A0 0F A1 0F 03 00 ...` | `Ucell_min`, `Ucell_max`,
Index/Flags |
| `181/182/183` | z. B. `12 00 14 00 11 00 ...` | `Tmin`, `Tmax`, Sensorindex |
| `202/242/282` | `A1 0F ...` | Einzelzellspannungen in mV |
| `6C1/6C2/6C3` | `C3 E1 10 40 ...` | Float-/Konfigurationswert |
---
## Konkretes Beispiel dekodiert
### `142h = A0 0F A1 0F 03 00 1A 72`
Wenn Little-Endian 16-bit:
- Wert 1: `0x0FA0 = 4000`
- Wert 2: `0x0FA1 = 4001`
- Wert 3: `0x0003 = 3`
**Plausibel:**
- minimale Zellspannung: **4000 mV**
- maximale Zellspannung: **4001 mV**
- betroffene Zelle / Gruppe: **3**
### `182h = 12 00 14 00 11 00 1A DA`
- `0x0012 = 18`
- `0x0014 = 20`
- `0x0011 = 17`
**Plausibel:**
- minimale Temperatur: **18 °C**
- maximale Temperatur: **20 °C**
- Sensor/Index: **17**
---
## Kurzfazit
**Ja, grob dekodieren kann man das schon.**
**Belastbar erkennbar** sind vor allem:
- **Zellspannungswerte** um 4.0 V
- **Temperaturwerte** um 18–20 °C
- **zyklische Telegrammgruppen für mehrere Batteriemodule**
**Nicht belastbar** ist aus nur diesem Screenshot:
- vollständige Signalzuordnung aller Bytes
- SoC/SoH/Strom/Leistung/Faultbits im Detail
### Wenn du willst
Lade mir den **PCAN-Export als `.trc`, `.txt` oder `.asc`** hoch, dann
mache ich dir daraus:
1. eine **ID-für-ID-Dekodiertabelle**
2. die **wahrscheinlichen Skalierungen**
3. auf Wunsch sogar eine **erste DBC-Datei**.
:
Bearbeitet durch User
Alexander schrieb: > Schon mal die Frames durch eine KI gejagt? Ja habe ich. Es kommt das ähnliche Ergebnis raus wie bei Karls Q seinem Post. Leider passt hier z.B. nicht die Modulspannung. Diese müsste bei ca. 56,1V liegen. Diese Spannung hatten die Module als der Trace erstellt wurde.
Angehängte Dateien:
Hallo, hat ein bisschen gedauert. Musste mir erst noch ein Adapter etc. bauen um ein BMZ Helios Batteriemodul direkt anzusprechen ohne dass die BMU mit aktiv ist. Im Anhang habe ich mal die Log-Datei angehangen. Gruß Jusch
Marius schrieb: > Leider passt hier z.B. nicht die Modulspannung. Diese müsste bei ca. > 56,1V liegen. Die könnte sich aus der Summe der Zellspannungen ergeben. Wie ist dein BMZ Hyperion Batteriespeicher aufgebaut? Falls die Zellen als 14S verschaltet sind, könnte sich der von dir angegebene Wert ergeben - das Aufaddieren überlasse ich dir. Wo ist "hier"?
Kurzes Update: Ich habe einen Adapter gebaut, womit ich die CAN-Kommunikation von einem Modul aufzeichnen / anschauen kann. Das Protokoll müsste / ist ähnlich wie CiA 454 (EnergyBus) Battery Device Profile. Die CAN-ID 201, 241, 281, 2C1 ist die Zellspannung (max. 16 Zellen), Lesart sind jeweils 2 Byte als Little-Endian-Format, in HEX-Zahlenformat. Die Spannung ist in Volt mit drei Nachkommastellen. Die letzte Zahl der CAN-ID gibt das jeweilige Batteriemodul an, hierbei das Batteriemodul 1. Die CAN-ID 301 sind die Temperaturfühler des Moduls (max. 8 Stück), verbaut pro Modul sind 6 Stück. Temperatur wird in °C angeben, jedes Byte ist ein Temperaturfühler in HEX-Zahlenformat. Für weitere CAN-IDs sind auch Informationen vorhanden. In der CAN-ID 0C1 ist der werden Fehler / Warnungen dargestellt, hierbei ist mir aufgefallen, dass einzelne Batteriemodule sich in dieser ID unterscheiden, bzw. das unterschiedliche Werte drin stehen. Ein Befehl an 082 Byte 0: 01 = Erzeugt eine Antwort des BMS, eigentlich sollte damit eine Fehlermeldung quittiert werden, nur leider macht das BMS dies nicht. Vielleicht habt jemand noch eine Idee, wie die Fehler weiter quittiert werden können.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.