Clio Elektronik

[Loelle]

Hallo zusammen,
hat sich schon mal jemand intensiv mit der Clio Elektronik beschäftigt?

Ab und zu beschäftige ich mich damit, vor einiger Zeit habe ich ein Prüfstand für die UCL gebaut.
Da gute Stück funktioniert ganz gut, da aber kein Controller angeschlossen ist meldet sich ständig die Kontrollleucht für Elektronikfehler. Nun ist mal wieder Winter und zeit für Bastelein.
Ich habe versucht den Controller auszulesen und habe folgendes rausbekommen.
Die Übertragung geht nur von Controller zur UCL
Rs232 7/e/1
Es werden 13 Byte übertragen.
Im Anhang die von mir zugeordnetetn Bytes.

Wenn ich den Controller an die UCL anschließe ist alles gut.
Simuliere ich das ganze mit einem Arduino kommt zwar die Kommunikation zu Stande aber der Elektronikfehler bleibt. Alle sonstigen Fehler die mit dem Controller zu tun haben sind weg, außer Controllerfehler.

Gruß
Lölle
[attachment 2089 ClioDat.jpg]

 

[r1]

hast Du scho einmal versucht Schirm und Digital Ground zu trennen an der Schnittstelle oder zu verbinden, je nachdem was Du jetzt hast?

 

[Loelle]

Habe ich überprüft. Ist aber nicht das Problem, denn die Kommunikation wird augebaut.
Wenn ich z.B. die Bytes für das Gaspedalpoti ändere wird das auch auf dem XR25 angezeigt.
Der Elektronikfehler geht halt nicht weg. Und es wird Controllerfehler angezeigt.

Byte 13 hat sich als Prüfsummenbyte rausgestellt. Ich habe aber noch keine Ahnung wie das gerechnet wird.

Lölle

 

[Loelle]

Die Berechnung der Checksumme ist gar nicht so schwer.
Alle Bytes außer das letzte zusammenzählen, das letzte abziehen dann nochmal 256 abziehen ergibt 51dez. also 33hex so wie das erste Byte.
Achtung die Bytes haben nur 7 Bit. das 8 Bit darf nicht itgezählt werden.

Lölle

 

[r1]

Klar wird die Kommunikation auch aufgebaut, wenn zwei zu trennende Massen verbunden sind. Nur eine analoge Komponente, die die Massenbrücke sieht meldet das dann eventuell als Fehlersignal weiter. So wie einen Isolationsfehler. Ist ja aber ohnehin nur Spekulation.

 

[Loelle]

so über die Feiertage hatte ich etwas Zeit zum Basteln und habe die Kommunikation nun soweit entschlüsselt, das kein Fehler mehr Auftritt. Wer möchte kann die Information für die Fehlersuche nutzen.
Man kann den Controller mit z.B. dem Programm HTERM simulieren oder auch auslesen. Dazu muss man HTERM auf 2400bd 7 Bit Even Parity und 1 Stopbit einstellen. Die Abgeschirmte Leitung von der UCL zum Controller trennen bzw. einen Abgriff schaffen und je nach Richtung die RS232 vom Laptop anschliessen. Beim simulieren muss getrennt werden und z.B. 33h 00h 14h 00h 00h 00h 47h 00h 73h 03h 76h 00h 47h gesendet werden und alle 200ms wiederholt werden (kann man in HTERM einstellen).
Zum Empfangen sollte man den Zeilenumbruch auf 13 Byte einstellen.
Im Anhang seht ihr die Bedeutung der einzelnen Bits u. Bytes.
Lölle
[attachment 2102 ClioCont.pdf]

 

[thegray]

Hut ab !!!!
:spos:
Sowas eröffnet anderen ganz neue Gedanken-Gänge, denn einfach zu nichts kommt!

 

[Mat1966]

Hi Lölle, ich stoße grad auf diesen Thread, top Arbeit! Ich bin gerade am gleichen Thema (für den Bordlader), die Anänge aus Deinen Postings sind anscheinend nicht mehr sbrufbar, wäre super, wenn Du die nochmal posten könntest.

 

[Loelle]

Hallo Mat1966
Musste erstmal schauen wo ich das abgelegt hatte.
Aber für den Bordlader hilft das glaube ich nicht.
Bin sehr interessiert daran wie es mit dem Lader weitergeht.
Gruß Lölle

 

[Mat1966]

Hi Lölle, danke Dir, das hilft jedenfalls schon mal, die Testumgebung aufzusetzen, ist ja immerhin schon mal beides RS485... Das Bordlader-Protokoll ist wahrscheinlich etwas komplexer, weil bidirektional (nehme ich jedenfalls an). Ich berichte, wie das weitergeht.

 

[Loelle]

moin Mat1966
Ich habe mal von jemannden die anhängede Datei bekommen. Vielleicht kanst du da was mit anfangen, ich konnte es nicht. .txt habe ich angehäng. Musst du für einen Editor so ändern wie es passt.
Gruß Lölle

 

[pingudd]

hübsches Bild

 

[Loelle]

Das, das ein Bild sein könnte habe ich nie in Erwägung gezogen, aber es ist eins.
Ich hatte immer versucht die Datei als hex oder bin anzusehen.
Manchmal ist man vernagelt.

 

[Werni]

Ok, an der Stelle mal ein kleiner Kniff aus der IT:

Das 'echte' Dateiformat (nicht das was die Dateiendung angibt) ist bei den meissten Dateiformaten direkt am Anfang kodiert. Hier ist es ein JFIF kodiertes Bild (kann man lesen wenn mans im Editor aufmacht gleich am Anfang). Bei PDFs findet man mit dem Editor am Anfang z.B. PDF <Versionsnummer>.

Sehr nützlich wenn man gelöschte Dateien von einem Datenträger wiederherstellt, bei dem das Inhaltsverzeichnis mit den Dateinamen kaputtgegangen ist, oder per Schnellformatierung entsorgt wurde. Die echten Daten sind in so einem Fall nämlich noch komplett da...

 

[Mat1966]

Danke, das Bild ist aufschlußreich, da kommt man schon mal wesentlich leichter an die RS485-Pins.