StreetScooter WORK B16C fährt und lädt nicht – BMS-Codes 101/102 und auffällige Zellwerte

StressScooter · 8. Oktober 2026 um 14:26

Hallo zusammen,

erst einmal vielen Dank an Heye und alle, die hier ihre StreetScooter-Reparaturen und Reverse-Engineering-Ergebnisse dokumentieren. Auch LRBen für das Teilen der DBC-Unterlagen und Jacobsmess für den Hinweis darauf möchte ich danken. Heyes Projektbericht, LRBens DBC-Beitrag und eure Vorarbeit hier haben mir schon sehr geholfen, meinen eigenen Wagen zu untersuchen.

Ich habe vor Kurzem einen defekten StreetScooter WORK Box aus den Niederlanden gekauft: B16C, Erstzulassung Dezember 2020, 47.987 km, laut Angebot mit 40-kWh-Akku. Die genaue Revision des tatsächlich eingebauten Akkus muss ich noch anhand des Typenschilds bestimmen. Ich setze deshalb noch nicht voraus, dass er identisch mit Heyes Akku ist.

Der Benutzername StressScooter passt inzwischen ganz gut: Der Wagen fährt nicht und lädt den HV-Akku nicht. Immerhin habe ich inzwischen CAN-Mitschnitte und einige konkrete Befunde.

Ich habe meinen Fall auch bei OpenInverter eingestellt. Dort wurde der Beitrag zunächst in die Moderationswarteschlange gestellt.

Was der Wagen macht

Das Kombiinstrument zeigt seit Übernahme durchgehend 0 % SOC, dazu Schildkröte und Batterie-/Antriebswarnungen. Beim Startversuch erscheint „Werkstatt“. Ein Schließen der HV-Schütze höre ich nicht.
Der Schlüssel im Schloss unter dem Sicherungskasten steht waagerecht.
Der Ladestecker verriegelt bei geschlossener Zentralverriegelung. Die rechte grüne LED an der Ladebuchse blinkt schnell.
Der Ladeziegel zeigt „Charging“. Bei einem dokumentierten Versuch standen dort aber nur etwa 229 V / 1 A / 0,2 kW. Der separate LEAB CHAMP 1207 lädt die 12-V-Batterie nach; die über CAN gemeldete Bordnetzspannung stieg von etwa 12 auf 13 V. Das bestätigt noch keine Ladung des Traktionsakkus.
Die Handbremse war mechanisch angezogen, wurde anfangs aber nicht erkannt. Ich habe ein abgeknicktes Kabel am Handbremsschalter repariert. Jetzt wird die angezogene Handbremse im Kombiinstrument korrekt angezeigt, und im CAN steht HandBrakeOn. Auch „Tür offen“ wird im Kombiinstrument korrekt angezeigt. Das Bremspedal wird ebenfalls in den CAN-Daten erkannt.
Den „Affengriff“-Reset habe ich ungefähr zehnmal erfolglos versucht. Auch mit repariertem Handbremskabel und korrekter Handbremsanzeige hat er keine Wirkung. Kein hörbares Schützklicken, weiterhin weder Fahrbereitschaft noch HV-Ladung.
Ein Vorbesitzer hatte den Parksperrenaktuator vom Getriebe abgebaut und elektrisch angeschlossen außerhalb seiner Einbauposition hängen lassen. Die Sperrklinke selbst ist noch im Getriebe. Der Aktuator ist ein Nidec 405.712 / 10258490 und hat sich bei meinen Versuchen nicht sichtbar bewegt. Das ist ein offener mechanischer bzw. steuerungsseitiger Befund; ob er auch die Ladung verhindert, ist noch nicht geklärt.
Der Fahrtrichtungshebel ist ein APEM BF240SD1BK0000. Versorgung und beide Analogausgänge habe ich am Hebel geprüft; dort entsprechen sie der Spezifikation. Den vollständigen Signalweg bis zum Steuergerät bestätigt das noch nicht.

Verbaut sind ein Kostal-HV-Lader D16X1761A7C1_01, HW 002 / SW 002, und ein Bosch-Inverter INV3.3 STDA13, SW i420. Die Typenschilder habe ich fotografiert.

CAN-Mitschnitt und BMS-Diagnose

Ich zeichne mit ESP32 und SN65HVD230 an OBD-Pins 6/14 bei 500 kbit/s und 11-Bit-IDs auf. Der Aufbau hört ausschließlich mit: Listen-only-Modus, TX-Eingang des Transceivers fest auf rezessiv. Ich habe mit dem Sniffer keine Diagnoseanfragen, CAN-Resetbefehle oder Aktuatorbefehle gesendet. Die oben erwähnten Resetversuche erfolgten über die Bedienelemente des Fahrzeugs.

Vorhanden sind etwa 319.000 Frames aus 15 Mitschnitten vom 7./8. Oktober. Ich werte sie offline mit der Community-Datei 11kW Kostal Charger.dbc aus. Ob jede Zuordnung zur Firmware meines Fahrzeugs passt, ist noch zu prüfen. Alle folgenden IDs und Nutzdaten sind hexadezimal.

Die decodierten Packspannungsfelder melden ungefähr 413–416 V, obwohl im Tacho 0 % stehen. Das BMS meldet errorInBattery, gleichzeitig gesetzte Zellüberspannungs- und Zellunterspannungsflags sowie offene Schütze. Die HV-Freigabe steht auf 0, der angeforderte Ladestrom ebenfalls auf 0 A.

Diese drei Diagnoseframes tauchen in fünf längeren Mitschnitten wiederholt auf:

382#4000FF0000138705
382#40090265C49166B7
382#400A840000000000

Mit der DBC ergibt sich:

Feld	Decodierter Wert
`master_st_batt`	255 = `BMS_STATE_ERR`
`master_err_0_code / part / cell`	101 / 196 / 145
`master_err_log0_code / part / cell`	102 / 183 / 132

Die Tabellenwerte sind dezimal. Für die Codes 101/102 und die Codierung von part/cell fehlt mir eine verifizierte Erklärung. Ich interpretiere sie weder als reale Zellnummern noch als normale OBD-P-Codes.

Eine Stolperfalle in der DBC: 0x06E BMS_State = 7 / Initializing ist ausdrücklich als fester Wert kommentiert. Daraus leite ich deshalb keine hängengebliebene BMS-Initialisierung ab.

Auffällige Zell- und Temperaturwerte

Die folgenden String-/Slave-/Kanalnummern sind Bezeichnungen aus der DBC, noch keine bestätigten Positionen im Akku. Es handelt sich um vom BMS gemeldete Werte, nicht um unabhängig an den Zellen gemessene Spannungen und Temperaturen.

Viele Spannungskanäle liegen bei ungefähr 4,0–4,07 V. Einige fallen deutlich auf:

String 1 / Slave 6: Kanal 2 und 4 melden 0 mV, Kanal 3 und 6 jeweils 4999 mV. Das ist zusätzlich zu Kanal 5, den die DBC bei V6-Varianten als unbeschaltet beschreibt.
String 2 / Slave 4 / Kanal 10: Der gemeldete Wert sank über die Mitschnitte von 476 auf 411 mV. Am selben logischen Modul änderte sich temp2 von 13,0 auf 44,3 °C, allerdings nicht gleichmäßig ansteigend. Im letzten Mitschnitt lagen die beiden anderen Temperaturfelder dieses Moduls bei 20,9 und 23,6 °C; die Temperaturkanäle der übrigen Module bei etwa 19–21 °C. Draußen waren ungefähr 18 °C.
String 2 / Slave 7 / Kanal 10 und 11: Zwei benachbarte Werte ändern sich gegenläufig, während ihre Summe exakt gleich bleibt. Beide Kanäle stehen jeweils im selben Frame:

382#96030D9112050FDE   -> 3473 + 4613 = 8086 mV
382#96030D9C11FA0FDD   -> 3484 + 4602 = 8086 mV

Bei diesem letzten Beispiel frage ich mich, ob ein gemeinsamer Messabgriff oder die Eingangsstufe der Zellmessung beteiligt ist. Das ist eine Hypothese, keine Diagnose. Tatsächliche Zellabweichungen und eine unpassende Protokollzuordnung muss ich davon noch unterscheiden.

Hier auch die letzten Rohbeispiele für den besonders niedrigen Spannungskanal und die Temperatur:

382#9303019B0F810F95   -> S2/Slave4/Kanal10: 411 mV
382#9304FB6501BB00D1   -> S2/Slave4/temp2: 44,3 °C; temp3: 20,9 °C

Eine weitere Auffälligkeit: 0x485 decodiert die erlaubten HV-Spannungsgrenzen zu Minimum 707 V und Maximum 320 V, beispielsweise bei 485#000000C3021410C5. Das sind Grenzwertfelder, keine gemessenen 707 V Akkuspannung. Ob das eine Folge fehlerhafter Zellwerte, ein Fehler-/Ersatzwert oder eine DBC-Abweichung ist, weiß ich noch nicht.

Wo mir eure Erfahrung helfen würde

Kennt jemand die BMS-Codes 101/102 samt Zusatzbytes oder hat eine passende Codetabelle bzw. Firmware-Referenz? Wie lässt sich am besten feststellen, zu welcher BMS-Softwarevariante diese Nachrichten gehören?
Hat jemand das 0-/4999-mV-Muster oder gegenläufige Nachbarkanäle schon an diesen Akkus gesehen? Gibt es bekannte Fehler an Messabgriffen/Modulplatinen oder dokumentierte Kennwerte für ungültige Messungen?
Gibt es, nach Identifikation der Packrevision, eine belegte Zuordnung der String-/Slave-/Kanalnummern zu den physischen Modulen und Temperaturfühlern?
Weiß jemand, wie die Parksperrenrückmeldung die Ladefreigabe beim B16C beeinflusst? Und sollten die Statusnachrichten dieser Kostal-Revision am OBD-Anschluss sichtbar sein? Ich sehe 0x618, aber keine der in der DBC beschriebenen OBC-Statusnachrichten 0x611 bis 0x614.

Heyes später gefundene defekte Crimpverbindung im Batterie-Ladezweig ist für mich ein guter Hinweis, auch die Verkabelung zu prüfen. Meine BMS-Befunde könnten auf einen anderen Fehler hindeuten. Ich versuche deshalb, Beobachtungen und Interpretation auseinanderzuhalten.

Ich plane, den HV-Akku am Wochenende aus dem Fahrzeug auszubauen.

Weitere Rohframes, Zellkanaltabellen und Bauteilfotos kann ich bei Bedarf ergänzen. Ich möchte die Fehlersuche dokumentieren und bestätigte Protokolldetails sowie die spätere Reparatur wieder mit der Community teilen.

Vielen Dank!

StressScooter

MdM · 8. Oktober 2026 um 18:13

Wow, da hast du schon viel Arbeit reingesteckt aber auch viel weitere Arbeit vor Dir.

Das Problem zu den Fehlercodes, keiner, außer theoretisch Streetscooter, wird dir vermutlich erklären können, was die Codes genau bedeuten. Vom Wortlaut und deinen Schilderungen würde ich vielleicht doch schon einen Zellenfehler annehmen, obwohl ich da natürlich rate und vermutlich noch weniger weiß als du. Wenn Du eine Streetscooter Werkstatt in deiner Nähe hast, würde ich da mal eine Diagnose machen. Die Werkstatt benutzt SIA und Diag RL, Diag ist für die Batteriediagnose. Eine reine Diagnose wäre vermutlich überschaubar und kostet nicht wirklich viel, Alles weitere würde ich aber nicht in der Werkstatt machen lassen, weil dann wärst du automatisch wieder der nebulösen Geschäftsstruktur von Streetscooter unterworfen. Würde danach jetzt auch mal die HV Batterie aufschrauben und dort Spannungen messen. Hinzu kommt die wenigsten Werkstätten sind Zebra Werkstätten, die also offiziell Batterien aufschrauben dürfen. Du scheinst dich ja auch schon mit CAN intensiver auseinandergesetzt zu haben und hast bereits programmiertechnische Kniffe.

Da wäre tatsächlich der Heye, der auch einen B16C sein eigen nennt, dein erste Ansprechpartner.

StressScooter · 8. Oktober 2026 um 18:45

Danke dir für den Hinweis! Ich sollte mir tatsächlich mal das StreetScooter-Werkstattnetz hier in der Umgebung anschauen. Aber kann mir die Fänge einer Firma wie StS ganz gut vorstellen. Die Software ist nach etwas Suchen natürlich auch nirgends zu haben.

Den Wagen dort zumindest einmal mit SIA/Diag RL auslesen zu lassen, wäre einen Versuch wert. Vielleicht bekomme ich damit die Fehlercodes und die auffälligen Zellwerte besser eingeordnet.

Idealerweise läuft dabei mein CAN-Logger mit, tief unter dem Armaturenbrett vergraben . Dann könnte ich hinterher nachvollziehen, welche Diagnoseabfragen gestellt werden und was das BMS darauf antwortet. Das wäre für die weitere Fehlersuche und das Reverse Engineering natürlich interessant.

MdM · 8. Oktober 2026 um 20:50

hehe, der Trick mit dem Can Logger, der ist gut, da musse erstmal drauf kommen.

Das eigentliche Problem, ist der Transport zur Werkstatt. Aber unter Umständen erhältst du dann auch eine PDF mit einigen Diagnosewerten. Die Fehlerauflistung ist aber immer noch kryptisch, vielleicht bist du auch nachher enttäuscht, weil du bereits so vieles auslesen konntest, zumindest hast du aber Kontakt zu potentiellen Leuten, die vielleicht auch ein paar Fragen nebenbei beantworten können.

Heye · 8. Oktober 2026 um 21:43

Moin StressScooter,

erstmal: Herzlich willkommen im Forum und herzlichen Glückwunsch zu deiner tollen Anschaffung! Und ich muss auch sagen: Chapeau! Du hast wirklich schon eine Menge herausgefunden.

Lass mich mal Punkt für Punkt meine Gedanken zu deinen Symptomen runterschreiben:

Ich bin mir ziemlich sicher, dass wir den gleichen Akku (V6-16M) haben. Vielleicht mit unterschiedlicher Firmware. Aber ich glaube nicht, dass es unterschiedliche 40kWh-Akkus gab.
0% SoC heißt (wenn die Batterie nicht tatsächlich leer ist) etwas. Ich habe nur vergessen, was...
Die Verriegelung der Ladebuchse wird vom BCM gesteuert und ist von allem anderen ziemlich unabhängig. Wenn sie automatisch verriegelt, wenn du den Ladestecker einsteckst, heißt das aber, dass sich BMS und BCM auf dem CAN-Bus zumindest sehen können und wenn das Entriegeln per Fernbedienung funktioniert, können sich ZVS und BCM auch sehen. Das Ver- und Entriegeln der Buchse sollte stattfinden, nachdem auch die Blinker aufgeleuchtet haben.
Das schnelle Blinken wird durch das BMS gesteuert.
Dass der 12-Ladeziegel lädt, heißt, dass das BMS korrekt mit dem CP-Signal interagiert.
Das Handbremsenproblem hatte ich auch. Es sollte aber von fast allem (abgesehen vielleicht vom Affengriff) unabhängig sein.
Den Aktuator ausgebaut zu lassen, ergibt für mich wenig Sinn, solange er noch funktioniert. Für die Kalibrierung (nach dem Affengriff) muss er in beide Maximalpositionen verfahren und die PLCU muss einen Anstieg des Stromverbrauchs registrieren.
Ich habe den Affengriff noch nicht wirklich verstanden, aber ich glaube, dass er vor allem für die VCU/PLCU gedacht ist. Seltsam, dass er nicht funktioniert. Geht dein Türsensor? Es müsste eine Warnleuchte im CDIS zu sehen sein, dass die Fahrertür offen ist. Ein Klacken der Schütze wäre aber ohnehin nicht zu erwarten, da der Affengriff die Schütze öffnet (bzw. die VCU abschaltet, die sonst das BMS die Schütze geschlossen halten lässt). Die Schütze werden bei dir aber von vorneherein nicht geschlossen.

Die Werte im BMS_Diag / 898 / 382h sind leider beim B16C (zumindest bei meinem) eher unzuverlässig. Aber ich finde es schonmal spannend, dass du zumindest String 2 / Slave 4 siehst. Mit den Problemen mit den gemeinsamen Messabgriffen habe ich bei meiner D16-Batterie auch zu kämpfen. Die Symptome klingen wirklich sehr ähnlich.

Ich weiß nicht, ob es überhaupt einen StreetScooter gibt, zu dem die besagte CAN-Datei wirklich genau passt. Bei meinem B16C ist das zumindest nicht der Fall, darum würden mich ein paar fehlende Nachrichten nicht weiter wundern.

Zu den BMS-Innereien kann ich leider wirklich noch nicht viel sagen. Ironischerweise weiß ich zur V6-16M mit am wenigsten, weil ich mit der Batterie mehr fahre als bastle Dauert noch ein bisschen. Aber bald weiß ich dann hoffentlich mehr.

In der D16-SDA-Batterie stehen 101 und 102 für Zell-Unterspannungsfehler und Zell-Überspannungsfehler. Auf die Bedeutung der Zusatzbytes kann ich aus der D16-SDA-Firmware nicht schließen.

Dein BMS_VCU_BatLim sieht auch wirklich seltsam aus, das kann ich mir gerade noch nicht erklären.

Die Parksperre sollte mit der Ladefreigabe gar nichts zu tun haben. Die Parksperre ist im System VCU/PLCU und das Ladegerät ist im System OBC/BMS. Das Problem, dass er nicht lädt und die LED schnell blinkt, würde ich darauf zurückführen, dass das BMS nie die HV-Schütze schließt, was auch Sinn ergibt, denn es scheint ja zu denken, dass die Spannungen jenseits von gut und böse sind. Das wäre jedenfalls das erste Problem, das ich angehen würde.

Ich denke auch, dass im nächsten Schritt die Batterie geöffnet werden muss. Das ist bei der V6-16M leider ein ziemlicher Akt. Ohne vernünftige PSA würde ich das wirklich nicht machen und es ist (wenn ich mich nicht ganz blöd angestellt habe) nicht ohne weiteres möglich, die beiden Strings jeweils in zwei Hälften zu teilen, bis der obere String abgetragen ist. Dazu würde ich dir auf jeden Fall ans Herz legen, dir den Bericht im OI-Forum genau anzuschauen und auch die Modifikation der unteren Modulbrückenabdeckung vorzunehmen, dass beim nächsten Mal (und das kommt bestimmt) die Batterie leichter zu öffnen ist.

Vielleicht (das ist jetzt ein spontaner Gedanke) wäre es möglich, mit einer Art Keil den oberen String so weit anzuheben, dass die Modulbrückenabdeckung ausgebaut werden kann.

Mir ist nicht klar, wie die Zuordnung der Strings und Module zwischen CAN und Physik aussieht, aber ich bin mir relativ sicher, dass die BMS-Slaves bei der V6-16M alle gleich sind und sich die Nummerierung aus der physischen Verkettung der Signalleitungen (NXP TPL) ergibt. Ich würde so vorgehen, jeweils nur ein Modul ans BMS anzuschließen, in den BMS_Diag-Daten sollten dann auch nur Daten für ein Modul zu sehen sein. Wahrscheinlich wäre das BMS darüber nicht sehr glücklich, aber bei der SDA-Batterie hat das schon funktioniert und ich glaube nicht, dass es einen permanenten Fehler o.Ä. hinterlassen würde.

Dafür müssten natürlich auch die Pins bestimmt werden, mit denen das BMS mit Strom und Klemme 15 versorgt werden kann.

Falls nur zwei oder drei BMS-Slaves defekt wären, könntest du die auch einfach austauschen, ein Forumsmitglied hier hatte neulich welche zu einem vernünftigen Preis angeboten.

Wirklich spannend fände ich auch, ob sich bei deinem BMS die Firmware auslesen ließe. Bisher habe ich nur ein Modul mit einem (glücklicherweise wirkungsarmen) Leseschutz entdeckt.

Die Idee mit dem CAN-Logger beim Auslesen das Fahrzeugs hatte ich damals auch, aber wirklich viel gewinnt man dadurch nicht, weil der eigentliche Wert in der Zuordnung der Fehlercodes zu ihrer Bedeutung liegt. Technisch sprechen die meisten Steuergeräte zur Diagnose unauthentifiziertes Standard-UDS (zumindest mehr oder weniger). Die mitgeschnüffelten Authentifizierungs-Schlüssel (bei schreibenden Zugriffen nötig) würden bei deinem Fahrzeug dann wahrscheinlich auch bei zukünftigen Ausleserunden wieder einspielbar sein, aber ich fand es einfacher, direkt mit den Firmware-Binaries zu arbeiten, aus denen auch ersichtlich wird, wie man an die Diagnosedaten herankommt.

In ca. einem Monat weiß ich hoffentlich deutlich mehr zur V6-16M, wenn die SDA in meinem Auto fährt und ich das andere BMS in den Fingern habe.

Edit: Und noch etwas: Könntest du den Thread vielleicht in die StreetScooter-Kategorie verschieben? Da gucke ich häufiger rein

MdM · 8. Oktober 2026 um 23:59

@Heye in mindestens 2 Punkten muß ich dich vielleicht korrigieren, der Ladeziegel lädt vermutlich nichts, zumindest wahrscheinlich die HV Batterie nicht, sondern die 100W Grundlast, wenn ich das richtig verstanden habe, das kommt vermutlich durch das Ladegerät für die 12V Batterie, denke ich, Größenordnung ca 60-70W, je nach 12V Batteriestand, zumindest ist das bei mir so.

der Affengriff funktioniert nicht, weil meiner Meinung nach das Hauptschütz sicherheitstechnisch blockiert ist, so wie bei meinem B16, meiner Meinung nach ist der Affengriff quasi eine Art Hardreset der die verbauten Fahrzeuggeräte dazu bringt, neu zu booten. Ist Theorie.

MdM · 9. Oktober 2026 um 07:45

Mal eine blöde Frage: Hat jemand von euch schonmal CAN Mitschnitte vom Affengriff gemacht?

Heye · 9. Oktober 2026 um 09:36

Genau, ich meine den LEAB-12V-Ladeziegel. Die 100W decken sich mit dessen Verbrauch. Vom Affengriff habe ich noch keinen CAN-Mitschnitt, aber ich glaube nicht, dass ich da etwas interessantes finden würde, hier meine Gedanken dazu.

Der Affengriff braucht die folgenden Eingaben:

Offene Fahrertür (BCM -> P-CAN -> VCU)
Handbremse angezogen (BCM -> P-CAN -> VCU)
Gaspedal (VCU) und Bremse (VCU, BCM) voll durchgedrückt
Fahrmodus-Hebel auf D (VCU)
Zündung an- und ausschalten (BCM -> Kl. 15 -> VCU)
Pedale weiterhin gedrückt halten

Der Fahrmodus-Hebel und das Gaspedal können von keinem anderen Steuergerät gelesen werden als von der VCU, aber Fahrertür und Handbremse sind auf dem P-CAN sichtbar, auch für die VCU.

Meine Hypothese ist jetzt, dass die VCU (hängt an Dauerplus) sich beim Affengriff neu startet und ggf. die gespeicherte Position der Parksperre zurücksetzt. Dabei kann sie die HV-Enable-Leitung und das HV-Enable-Signal auf CAN natürlich nicht aktiviert halten (beides ist nötig, damit die HV-Schütze geschlossen bleiben). Ansonsten bleibt der Affengriff auf die VCU beschränkt.

In DBC, BCM-Firmware und BMS-Firmware habe ich bisher keinen Hinweis drauf gefunden, dass es sozusagen ein "Affengriff-Signal" gäbe und bin mir relativ sicher, dass ich das inzwischen wüsste, wenn das der Fall wäre.

Zur Frage, ob das BMS den Affengriff blockieren kann: Ich kann es mir nicht vorstellen. Das könnte man testen, indem man den Datenstecker von der Batterie trennt und dann den Affengriff probiert. Das könnte ich machen, wenn ich demnächst sowieso wieder an der Batterie dran bin.

Lieber wärs mir natürlich, eine VCU und ihre Firmware in die Finger zu kriegen

MdM · 9. Oktober 2026 um 13:24

oh, danke, für die Präzisierung, aber vielleicht können wir uns etwas annähern.

die Rückmeldung des Affengriffes wird oft mit dem Klacken des Hauptschütz beschrieben, sonst gibt es keine einfache Kontrollmöglichkeit für den User (als Beispiel das Display CDIS zeigt sich vom Affengriff unbeeindruckt und leuchtet weiter). Also gibt es nur das Klacken als Kontrollmöglichkeit. Wenn es aber tatsächlich nicht klacken sollte, dann kann der User ja auch nicht wirklich feststellen, ob der Reset angestoßen worden ist oder ob die Geräte einen Reset durchführen.

Deine Theorie ist aktuell, daß nur die PCU resetet wird.

Was ist denn mit der Möglichkeit, daß die neu gestartete PCU wieder Kontakt zum BMS und den anderen Geräten aufnimmt ?

Also das Klacken ist ja der Regelfall, es muß also durch den Affengriff einen neuen Impuls geben, das Hauptschütz der HV Batterie zumindest kurz aus und einzuschalten.

Der Affengriff könnte vielleicht über die PCU noch immer den Reset auslösen, (Löschen der Speichereinträge), danach nimmt die PCU Kontakt zu den anderen Geräten auf, aber das BMS blockiert nach der Neukommunikation mit der PCU das Schalten des Hauptschützes, weil beim Neubooten der HV Batterie Fehler (hier vielleicht unplausible Spannungswerte einer Zelle), der noch immer existiert, wieder durch das BMS registriert wird. Somit wird Hochvolt auch nicht aufs Fahrzeug geschaltet und es fehlt das Klacken.

Meine andere Theorie wäre, daß das BMS total unabhängig arbeitet und somit auch das Schalten des Hauptschützes unterbindet, weil der alte Fehler im BMS gespeichert ist und der Speicherinhalt des BMS auch durch die Neukommunikation mit der PCU nicht überschrieben wird?

Heye · 9. Oktober 2026 um 18:48

Die PCU/VCU (wahrscheinlich zwei verschiedene Namen fürs gleiche Bauteil, wie C2C/TCU) ist ja wie das Motorsteuergerät beim Verbrenner. Und geschlossene Hauptschütze verhalten sich wie ein laufender Motor. Beim Reset des Motorsteuergeräts geht der Motor zwangsläufig aus, entsprechend gehen beim Reset der VCU die Hauptschütze auf.

Beim D16 gilt folgendes (Hypothese aus der Firmwareanalyse, noch nicht getestet): Zum Schließen der Hauptschütze braucht das BMS folgende Eingangssignale (Stromversorgung auf Dauerplus vorausgesetzt): Kl. 15 (kommt vom Zündschloss oder BCM bei Keyless), HV-Enable-Leitung (aktiv bei 0V, von der VCU), CAN-Signal zur HV-Aktivierung (ebenfalls VCU).

Um die Schütze wieder zu öffnen, müssen (im Normalfall) von den drei Aktivierungssignalen zwei wegfallen.

Genau das passiert, wenn die VCU zurückgesetzt wird (streng genommen fallen sogar alle drei weg, denn Kl. 15 wurde ja vorher schon abgeschaltet).

Das Klacken ist also ein Effekt, an dem man feststellen kann, dass der Affengriff erfolgreich war (sofern mindestens der Schütz am Minuspol geschlossen war), aber bedeutet nicht, dass Fehler im BMS gelöscht würden.

Eine weitere Hypothese:
150 Sekunden, nachdem Kl. 15 abgeschaltet wurde, sollte sich, vorausgesetzt, dass nicht geladen wird, das BMS auch abschalten. Fehler speichert es, wenn ich mich recht erinnere, nicht persistent, die wären dann also auch gelöscht.

lars72 · 10. Oktober 2026 um 03:35

Gehört zwar nicht zum Thema, aber ich muß euch mal meine Anerkennung aussprechen. Für mich sind diese ganzen CAN- und Steuergerät-Sachen ein Buch mit vielen Siegeln, obwohl ich seit langem im Automobilbereich arbeite. Aber halt eher analog und im Bereich Mechanik. Da habe ich im CAN-Bereich echt den Anschluß verpasst.

Wie habt ihr euch an den Anschluß herangearbeitet, seid ihr da irgendwie als KFZ-Mechatroniker vorbelastet?

MdM · 10. Oktober 2026 um 11:57

@lars72 kein KFZler, verstehe CAN auch nicht wirklich. Im Grunde genommen hast du Software und ein Interface und es gibt ein paar Anschlußhinweise, die beachtet werden sollten. Du erhältst bei listen only, den Datenstrom als Textdatei, eine Werteliste oder ich sage mal Sätze. Diese Sätze sind aber individuell je nach Hersteller codiert. Daher musst du diese Sätze noch mit Software decodieren. Dazu gibt es DBC Dateien, quasi eine Übersetzungsliste, damit kannst du dann Sätze mit Klarnamen generieren, oft in englisch, weil die DBC Datei vermutlich ein englischsprechender Nutzer programmiert hatte. Vermutlich kannst du in der heutigen Zeit auch viel mit KI direkt übersetzen, wenn du die KI überprüfen kannst oder dieser vertraust. Den CAN Bus empfinde ich persönlich aktuell aber sogar als veraltet und kompliziert, weil alles über 2 Draht Kommunikation und Prioritäten abgewickelt wird, du kannst zum Beispiel ein Gerät haben, was den Datenstrom einfach mal so überschreiben kann, quasi alle Geräte die zur selben Zeit miteinander sprechen, funktioniert nicht. Ich weiß auch noch nicht, warum in der heutigen Zeit keine Netzwerkkabel oder Glasfaser gelegt wird, für mich wäre da auch die Diagnose deutlich besser. Der Streetscooter selbst ist ja mehr aus vielen bereits bestehenden Teilen zusammengeschustert worden, also Streetscooter hat sich bei anderen Autoherstellern bedient. Vermutlich sind, waren CAN Geräte günstig, aber wie bereits geschrieben, bin kein KFZler, das ist alles von mir nur Raterei, weil ich gefühlt noch immer wenig über CAN weiß.

lars72 · 10. Oktober 2026 um 12:27

Das CAN alleine ist es ja nicht, man muß ja auch wissen, welches Steuergerät wann und warum von welchem anderen Steuergerät etwas erwartet, es nicht bekommt, und deswegen nicht tut was es soll. Beispielsweise meldet der Klimakompressor (im Streetscooter wohl nicht vorhanden) dass ihm Kältemittel fehlt, deswegen stellt er seinen Dienst ein und verhindert eine Ladung, weil der Akku ja vielleicht beim Laden gekühlt werden müsste. So ums Eck herum halt. Und wenn man dann nicht den groben Überblick hat, was wann mit wem spricht, ist man verloren. Das meinte ich mit "habe den Anschluß verloren".

MdM · 10. Oktober 2026 um 13:38

genau, da bin ich voll bei dir, das kommt aber auch nicht durch CAN an sich, sondern durch eine fehlende, mangelhafte Dokumentation. Zur Zeit hänge ich bei einem Fehler, den bis jetzt noch nicht einmal Streetscooter selbst detailliert erklären konnte oder wollte.

Angeblich hätte auch mal ein TÜV Prüfer zu einem Bekannten gesagt, CAN wäre nicht logisch. Er meinte damit, daß Sensor XY, der nichts mit dem per Diagnose bemängelten Bauteil zu tun hat, defekt wäre, aber das Bauteil den Dienst verweigert und auch die Dokumentation nicht wirklich darauf hinweist, überprüfe den Sensor XY, und ersetze es bei Defekt, dann könnte auch das Bauteil wieder funktionieren.

Oft ist auch der Produktschutz ein Problem, denn man möchte es nicht offenlegen, weil es dann ja theoretisch kopiert werden könnte.