Hallo Es gibt ein neues Tool, das unter Anderem einen CAN Bus Analyzer/Debugger/Paketinjektor enthält. HUD ECU Hacker ist eigentlich ein unverseller ECU Scanner für OBD2 und proprietäre Protokolle etlicher ECU Modelle und erlaubt auch das Tuning der Delphi MT05.2 ECU. Aber es gibt auch etliche zusätzliche Analyse Tools, unter anderem einen CAN Bus Analyzer. Im Gegensatz zu anderen CAN bus Analyzern, die man so im Internet findet, kann man HUD ECU Hacker mit billigen Adaptern benutzern. Ein chinesischer Tactrix Klon (J2534) für 20€ funktioniert perfekt. Aber auch andere Adapter werden unterstützt. Über die Vor- und Nachteile der verschiedenen Adapter gibt es ein ausführliches Kapitel in der Hilfe. Zuerst muß man im CAN Filter definieren, von welchen CAN ID's man die Daten sehen will. Siehe Screenshots. Nach dem Öffnen des Adapters erscheinen die CAN Pakete in Echtzeit in der Trace Ausgabe. Selbstverändlich können die gesnifften Daten auch in eine Logdatei geschrieben werden. HUD ECU Hacker hat auch einen Coder und Decoder für das ISO 15765 Protkoll, das es erlaubt, bis zu 4095 Bytes in einer CAN Bus Message zu versenden oder empfangen, die in mehreren 8-Byte Frames übertragen wird. J1939 ist auch teilweise implementiert. Im CAN Terminal kann der Benuzter manuell Pakete an ein Gerät am CAN Bus senden. Und das Sahnhäubchen ist, dass empfangene CAN Daten mit Macro Scripten verarbeitet werden können oder auch automatisch gesendet werden könnnen. Die Macro Scripte in der C# Programmiersprache werden in Maschinencode kompiliert und sind damit so schnell wie der Prozessor. Einer der Screenshots zeigt ein simples Beispiel Script, das ein CAN Paket an alle 11 bit CAN ID's von 001 bis 7FF sendet. Es können auch Daten aus empfangenen CAN Paketen in einem Script extrahiert werden. Nach der Installation von HUD ECU Hacker finden sich Beispiel Macro's im Unterordner "Macros". Eines davon zeigt die Extraktion von Calibrationstabellen in eine XML Datei aus dem CAN Bus Traffic mit einer Deni ECU. Außerdem hat HUD ECU Hacker einen eingebauten ECU Emulator, der 100% vom Benutzer in einer XML Datei und optional einem C# Macro Script programmiert werden kann. Der ECU Emulator kann außer der ECU jedes beliebige Gerät am CAN Bus simulieren. Detaillierte Beschreibung in der Hilfe. Siehe Screenshot. HUD ECU Hacker ist Qualitätssoftware, die von einem Software Entwickler mit 40 Jahren Erfahrung im Programmieren und Reverse Engineering geschrieben wurde. Obwohl ich mehrere Jahre an diesem Programm gearbeitet habe, verdiene ich keinen Cent daran. HUD ECU Hacker ist Charityware, das heißt der Benutzer wird um eine Spende an eine gemeinnützige Organisation seiner Wahl gebeten. Download und detaillierte Beschreibung: https://netcult.ch/elmue/hud%20ecu%20hacker/
Angehängte Dateien:
-
CAN_Filter.png
83 KB -
Sniff_CAN_Bus.png
140 KB -
ISO15765.png
140 KB -
CAN_Bus_Macro_Script.png
140 KB -
Macro_Code.png
5,5 KB -
ECU_Emulator.png
150 KB
:
Bearbeitet durch User
Das klingt ja alles ganz spannend, nur über OBD2 hat es nicht so viel mit CAN zu tun.
Angehängte Dateien:
-
CAN_OBD2.png
110 KB
> nur über OBD2 hat es nicht so viel mit CAN zu tun. Du glaubst also, dass es OBD2 nicht auch über CAN Bus gibt? Ich sehe du hast da eine gewaltige Informationslücke. Schau dir mal den angehängten Screenshot an, der die Initialisierung über CAN ID's 7E0/7E8 mit einer OBD2 ECU über das ISO 15765 Protokoll zeigt. Ich empfehle dir, erst mal die ausführliche Dokumentation zu lesen bevor du hier falsche Schnellschuß Rückschüsse postest: https://netcult.ch/elmue/hud%20ecu%20hacker/index.php#CAN_Bus
:
Bearbeitet durch User
Es ist nun mal leider so, dass man bei den meisten Fahrzeugen über den OBD2 nur an den Diagnose-CAN ran kommt, und da herrscht naturgemäß Funkstille. Um Daten zu empfangen muss man sie anfragen. Das hat mit CAN nicht mehr viel zu tun. Könnte man denn die K-line FT232R Option nutzen um einen CAN-Transceiver direkt zu lesen? Kannst Du einen Tactrix Klon mal auf AliExpress verlinken? Würde mir gerne einen kaufen, aber mit PayPal.
Hallo Deine Fragen sind ziemlich konfus. > Um Daten zu empfangen muss man sie anfragen. So generell ist das nicht richtig. Es gibt Geräte am CAN Bus, die permanent Daten broadcasten. Diese Daten muß man nicht anfragen. Und es gibt andere Daten, die man anfragen muß. Wie du im Screenshot im vorigen Post siehst sendet HUD ECU Hacker eine Anfrage und bekommt eine Antwort. > Das hat mit CAN nicht mehr viel zu tun. Wieso das mit CAN Bus nichts zu tun haben soll ist mir ein absolutes Rätsel. Wenn also ein Gerät mit einem anderen Gerät am CAN Bus kommuniziert hat das deiner Meinung nach nichts mit CAN Bus zu tun?? Weißt du überhaupt was CAN Bus ist, was K-Line ist und was OBD2 ist? Ich habe den Eindruck, alle diese Begriffe sind für dich komplettes Neuland. > Könnte man denn die K-line FT232R Option nutzen um einen CAN-Transceiver direkt zu lesen? Jetzt wird es vollkommen absurd! Entweder benutzt dein Fahrzeug CAN Bus oder K-Line. Du willst das jetzt mixen? Du mußt dir schon die Mühe machen, ausführliche Fragen zu stellen, wenn du willst, daß Andere dich verstehen. > Kannst Du einen Tactrix Klon mal auf AliExpress verlinken? Da gibt es unzählige Anbieter. Ich habe die aber in der Hilfe nicht verlinkt, weil die Links morgen schon wieder ungültig sind. Hier ein Tacrix Klon auf Aliepress: https://es.aliexpress.com/item/1005005975425600.html Der kann sowohl K-Line als auch CAN Bus.
Kommt auf da BJ des Fahrzeugs an. Es gibt Fahrzeuge, da gibt es nur DEN CAN. Also einen Bus, der hängt dann teilweise auch auf der OBD Dose und man sieht alle zyklischen Daten + Diaganfragen und Antworten. Bei modernen Fahrzeugen gibt es weit mehr als nur einen CAN, auf die OBD Dose ist dann der Diag-CAN geklemmt, der zum Diag-Gateway geht und welches die Daten bei den einzelnen Steuergeräten abfragt und durchroutet. Demnächst wird das noch besser geschützt, Thema IT Security im Fahrzeug. Aber abgesehen davon: Was nützt dir der Datenstrom ohne dbc? Ein paar Sachen wie Schalter, Drehzahl und co bekommt man ja übers Reengineering raus, aber Sensorwerte und co sind ja nahezu unmöglich zu übersetzen, da man weder den Multiplikator noch den Offset kennt.
> Bei modernen Fahrzeugen gibt es weit mehr als nur einen CAN Das weiß ich. Und wo ist das Problem? Dann mußt du dich halt an den richtigen CAN Bus ranklemmen, der dich interessiert. Du solltest natürlich in der Lage sein, wenn der Stecker des Tactrix Adapters nicht auf die anderen Busse paßt, 4 Drähte zu löten, die CAN Hi, CAN Lo, Ground und 12 Volt mit dem Fahzeug verbinden. > Was nützt dir der Datenstrom ohne dbc? Das ist nicht das Thema meines Postings. Es gibt etliche Leute, die die CAN Bus Daten reverse engineeren. Es gibt etliche Foren, wo Leute viel Zeit investieren, die Daten auf ihrem CAN Bus zu verstehen und zu verwerten. Für diese Leute ist HUD ECU Hacker ein nützliches Werkeug. Für dich offenbar eher nicht. Der Name des Programmes (... Hacker) sagt ja schon Vieles. Das CAN Terminal ist zum Hacken der CAN Daten nützlich und auch zur Fehlersuche. Selbstverständlich für Leute, die sich damit auskennen. HUD ECU Hacker kann im übrigen an JEDES Fahrzeug zum Scannen angepasst werden. Du fügst eine XML Datei hinzu, die die Befehle definert, die gesendet werden und wie die Anworten interpretiert werden. Wie das genau geht, ist ausführlich in der Hilfe beschrieben. Die Motordrehzahl anzuzeigen sind Anfänger Tasks. Forgeschrittenere Leute befassen sich mit Firmware Upload oder dem Anpassen einer ECU an einen Immobilizer. All das kann mit Macro Scripten gemacht werden.
:
Bearbeitet durch User
Elmü M. schrieb: > Du solltest natürlich in der Lage sein, wenn der Stecker des Tactrix > Adapters nicht auf die anderen Busse paßt, 4 Drähte zu löten, die CAN > Hi, CAN Lo, Ground und 12 Volt mit dem Fahzeug verbinden. Ich habe keinen Tactrix Adapter. Daher die Frage wie man den CAN-Transceiver mit dem PC verbindet, um den CAN Bus Analyzer nutzen zu können. Für K-Line hast Du einen FT232R als Option angeboten. Damit sollte man doch einen CAN-Transceiver direkt lesen können (z.B. einen MCP2551). Die Headline "mit billigen Adaptern" hat mich gecatcht - mein billiger Adapter ist ein µC mit CAN-Controller und einem TJA1055. Elmü M. schrieb: > Hier ein Tactrix Klon auf AliExpress: > https://es.aliexpress.com/item/1005005975425600.html Danke, habe mal einen bestellt.
:
Bearbeitet durch User
Hallo > Damit sollte man doch einen CAN-Transceiver direkt lesen können > (z.B. einen MCP2551). Endlich verstehe ich was du meinst. Wenn du das 3 Postings vorher geschrieben hättest, hätte ich dich gleich verstanden. Du hast wirklich extrem naive Vorstellungen! Ich sehe, du hast dich noch nie mit CAN Bus befasst. Was du vorhast, ist !VOLLKOMMEN! unmöglich. Dieser Chip ist nichts weiter als ein primitiver CAN Bus Treiber, der die Signale von einem Mikroprozessor mit TTL Level an die symmetrischen CAN Leitungen liefert, die mit 60 Ohm abgeschlossen werden müssen. Der MCP2551 ist nur ein Leitungstreiber, wie du leicht im Datenblatt siehst. Zitat: When TXD is Low, CANH and CANL are in the Dominant state. When TXD is High, CANH and CANL are in the Recessive state, provided that another CAN node is not driving the CAN bus with a Dominant state. Also mit anderen Worten: Dieser Chip ist nichts weiter als ein Pegelwandler, der Datenkollision erkennt und seinen Sender abschaltet, wenn ein andere Teilnehmer am CAN Bus gleichzeitig Daten sendet. All die CAN Bus Logik muß im Mikroprozessor implementiert sein. Was du brauchst zwischen dem MCP2551 Chip und dem USB Kabel ist nicht ein FTDI Chip sondern ein CAN Bus fähiger Microprozessor. Zum Besipiel ein Teensy 4.0, den du auch mit der Arduino Bibliothek programieren kannst: https://www.pjrc.com/store/teensy40.html Extrem wichtig sind hier die CAN Filter, die in einem CAN Bus fähigen Microprozessor aus der CAN Bus Datenflut das ausfiltern, was interessant ist. Dieser MCP2551 hat keine Filter. Er leifert ALLES was über den Bus läuft in ECHTZEIT. (Die CAN Bus Filter sind auch in meiner Hilfe beschrieben) Was an den TX Pin des MCP2551 geliefert werden muß, um ein Paket auf den CAN Bus zu senden, ist das komplette CAN Paket mit SOF, 11 Bit Header, SRR, IDE, 18 Bit identifier, DLC, 8 Data Bytes, 15 Bit CRC, ACK Slot, EOF. Alles detailliert in der HUD ECU Hacker Hilfe beschrieben. Der Micropozesser braucht außerdem einen FIFO für mehrere CAN Pakete, um diese zwischenzuspeichern, während diese von einem Interrupt Handler verarbietet werden. Jedes CAN Paket wird in einem Puffer mit mindestens 4 Byte für die CAN ID plus 8 Byte für die Daten zwischengespeichert. Wie soll das gehen mit einem FTDI Chip, der dir die Daten im RS232 Format liefert mit Start Bit und Stop Bit? Es ist VOLLKOMMEN UNMÖGLICH einen CAN Bus Treiber Chip direkt mit einem FTDI Chip anzusteuern. Deshalb gibt es ja schließlich die ganzen J2534, ELM327, ObdLink, UsbCAN, VAG K+CAN Adapter. Und wenn du so billig einen Tactrix Klon fertig kaufen kannst, verstehe ich nicht, wieso du dir die Arbeit machen willst, montatelang so etwas Komplexes selbst zusammenzulöten und dann zu programmieren? So einen CAN Bus Mikroprozessor zu programieren ist extrem schwierig und erfordert sehr viel Code. Und du hast mit Sicherheit nicht die Kenntnisse, das hinzukriegen. Elmü
Elmü M. schrieb: > Ich sehe, du hast dich noch nie mit CAN Bus befasst. Das siehst Du falsch. Meine Frage zielte darauf ab, inwiefern dein CAN Bus Analyzer kompatibel/nutzbar ist direkt an einem nackten CAN Bus. Also nicht am OBD2 Stecker. Offensichtlich gar nicht. Bei Dir geht es über J2534 OBD2 Passthrough, hat für mich nicht mehr viel mit CAN zu tun, das sind höherliegende Protokolle. Elmü M. schrieb: > Was du brauchst zwischen dem MCP2551 Chip und dem USB Kabel ist nicht > ein FTDI Chip sondern ein CAN Bus fähiger Microprozessor. Zum Beispiel > ein Teensy 4.0, den du auch mit der Arduino Bibliothek programieren > kannst: > https://www.pjrc.com/store/teensy40.html Ich nutze für den Teensy die <FlexCAN_T4.h> mit sehr komfortabler Bedienung. Elmü M. schrieb: > So einen CAN Bus Mikroprozessor zu programieren ist extrem schwierig und > erfordert sehr viel Code. Ich behaupte nicht das zu können, aber man muss ja das Rad nicht neu erfinden. An einem Arduino ist gar nichts komplex, zumindest nicht für den Anwender.
Da werfe ich doch mal selber was mit in den Raum: https://github.com/jgressmann/supercan Neben meinen eigenen Adaptern die vielleicht etwas schwieriger nachzubauen sind wird von der Firmware z.B. auch das "Adafruit Feather M4 CAN Express" unterstützt. Und primär sind wir mit CAN-FD unterwegs, classic-CAN Adapter gab es schon genug.
Hallo Alex > Meine Frage zielte darauf ab, inwiefern dein CAN > Bus Analyzer kompatibel/nutzbar ist direkt an einem nackten CAN Bus. > Also nicht am OBD2 Stecker. Offensichtlich gar nicht. Also hast du überhaupt nichts verstanden von all dem, was ich dir erklärt habe und in meiner ausführlichen Hilfe geschrieben habe. Meine Screenshots wo "nackte" CAN Pakete zu sehen sind, hast du also auch nicht angeschaut. Sehr schade. War alles umsonst. Alle CAN Adapter, die mein Programm unterstützt, können "nackte" CAN Pakete empfangen und senden. Lediglich das ISO 15765 ist ein "höherliegendes Protokoll", wie du es nennst. Aber das mußt du ja nicht benutzen, wenn du es nicht brauchst. Es ist optional. Wenn du "nackets" CAN willst, wie du es nennst, dann wählst du halt "CAN Raw" und du siehst alle Pakete EXAKT so wie über den Bus laufen. > Also nicht am OBD2 Stecker. Ich habe schon vor langem geschrieben dass du dich an JEDEN beliebigen CAN Bus anklemmen kannst und nicht auf den OBD Stecker limitiert bist. Wenn der Stecker nicht paßt mußt du halt 4 Drähte selber löten oder dir einen Adapter basteln. Kann ja wohl nicht so schwer sein. Ich verstehe nicht warum das schwer zu verstehen ist?
:
Bearbeitet durch User
Hallo Rudolph CAN FD ist nicht implementiert. Könnte ich theoretisch machen. Aber alles, was da in Github an unterstützter Hardware aufgelistet ist, sind nackte Platinen. Die Benuzter meines Programmes wollen fertige Adapter kaufen und nicht erst rumlöten, eine Firmware auf einen Mikrokontroller laden und ein Gehäuse basteln. Wenn du einen handlichen Adapter mit einem robusten Gehäuse kennnst, so wie zum Beispiel der Tactrix, dann ließe sich darüber reden. Ich habe extrem schlechte Erfahrungen mit solchen Selbstbau Projekten gemacht. Ich habe ein Jahr lang an einem extrem komplexen USB Sniffer gearbeitet der mit dem Teensy 3.2 perfekt funktioniert hat. Nach wenigen Jahren wurde dann auf einmal die Produktion des Prozessors für den Teensy 3.2 einfach so eingestellt. Alles umsonst! Auch mit einer anderen Mikroprozessor Platine im Arduino Steckformat hatte ich vorher schon die selbe Erfahrung gemacht. Die war nicht mal 5 Jahre auf dem Markt! Auch eine RFID Karte von Adafruit, an der ich ein Jahr gearbeitet habe. gibt es heute nicht mehr: https://www.codeproject.com/Articles/1096861/DIY-electronic-RFID-Door-Lock-with-Battery-Backup Ich werde diesen Fehler nicht nochmal machen, auf solche Selbstbau Platinen von Adafruit o.ä. zu vertrauen. Die sind morgen nicht mehr verfügbar. Wenn du aber einen universellen standard Adapter im Format wie J2534 für CAN FD kennst, ließe sich darüber reden, den zu implementieren.
Elmü M. schrieb: > Kann ja wohl nicht so schwer sein. Ich verstehe nicht warum das schwer > zu verstehen ist? Dein Programm arbeitet nur mit diesen OBD2 Adaptern. Ich habe einen µC mit CAN-Controller und CAN-Transceiver, nix OBD2 und nix J2534. Das CAN Raw Terminal habe ich gesehen. Ich habe verstanden dass mir im Teensy Code fehlt um es nutzen zu können, und Windows mit einem CAN-Transceiver nix anfangen kann. Stand heute kann ich also nix tun. Ich warte nun auf den Tactrix und dann sehen wir weiter. Ich bin mir aber 99 % sicher dass auf dem CAN in der OBD2 Steckdose keine Daten waren. SAE J2534 ist für mich auch ein höherliegendes Protokoll, über welches man den Adapter überreden kann das zu ändern. Mit solchen Adaptern habe ich mich noch nicht beschäftigt, vielleicht habe ich da auch etwas falsch verstanden. Wenn diese OBD2 Adapter an deinem Auto funktionieren ist ja schön, bei mir jedenfalls nicht.
:
Bearbeitet durch User
> Es gibt ein neues Tool, das unter Anderem einen CAN Bus > Analyzer/Debugger/Paketinjektor enthält. Also ich finde das ja auch interessant, aber unter welchem Linux laeuft das Programm den? :-) Was mich bei sowas immer wundert, sitzt ihr dann Tagelang mit dem Laptop im Auto und hackt immer irgendwas? Man braeuchte sowas als Software auf einem Raspberry PI. Den koennte ich dann im Auto anklemmen und dann entspann ueber WLAN am Schreibt dort arbeiten. Vanye
Vanye R. schrieb: > Was mich bei sowas immer wundert, sitzt ihr dann Tagelang mit dem > Laptop im Auto und hackt immer irgendwas? natürlich. Ich habe gut ein Jahr lang an einem GM Fahrzeug am "Bus geschnüffelt" und war am Ende in der Lage jedes Stellglied per Arduino anzusteuern und alle relevanten Daten am Bus zu dekodieren. Viel Arbeit, macht aber ungeheuren Spaß.
Vanye R. schrieb: > > Was mich bei sowas immer wundert, sitzt ihr dann Tagelang mit dem > Laptop im Auto und hackt immer irgendwas? Man braeuchte sowas > als Software auf einem Raspberry PI. Den koennte ich dann im > Auto anklemmen und dann entspann ueber WLAN am Schreibt dort > arbeiten. Das ist relativ einfach möglich, es gibt z.B. schon seit vielen Jahren CAN auf Ethernet Gateways. Mit zwei Stück davon bekommt man bei Bedarf sogar den CAN-Bus per Ethernet an eine fast beliebige Stelle, je nach Ausstattung des Gateways auch mehrer CAN-Busse gleichzeitig. Wenn es um das exakte Timing auf dem CAN-Bus geht ist das eventuell problematisch, für viele Dinge funktioniert es problemlos.
Elmü M. schrieb: > Jetzt wird es vollkommen absurd! Entweder benutzt dein Fahrzeug CAN Bus > oder K-Line. Du willst das jetzt mixen? Jein! Es gibt durchaus noch solche Mischungen, da geht das am Stecker über K-Line, aber intern auf CAN.
Thomas V. schrieb: > Ich habe gut ein Jahr lang an einem GM Fahrzeug am "Bus geschnüffelt" > und war am Ende in der Lage jedes Stellglied per Arduino anzusteuern und > alle relevanten Daten am Bus zu dekodieren. > Viel Arbeit, macht aber ungeheuren Spaß. Wie machen es denn sonst auch die Anbieter für Werkstattausrüstung(Gutmann&Texa&Bosch&Co) für Multimarken-Diagnose? Die werden vermutlich auch sniffen. Zusätzlich dazu kommen eventuell noch Datenkäufe. Das interessante ist, das solche Zugänge per Gesetz offen gehalten werden müssen, damit freie Werkstätten arbeiten können am Markt. Bin gespannt, wie das mit Security vereinbar ist.
:
Bearbeitet durch User
Joe J. schrieb: > > Wie machen es denn sonst auch die Anbieter für > Werkstattausrüstung(Gutmann&Texa&Bosch&Co) für Multimarken-Diagnose? > Die werden vermutlich auch sniffen. Das geht alles über die Diagnose per OBD Stecker, darüber können üblicherweise alle Steuergeräte gezielt angesprochen werden. Genauso machen es auch die Original-Diagnosesystem der Fahrzeughersteller.
Hallo Dieter, das war keine Frage-Es ging um das Re-Engeneering der Daten.
Joe J. schrieb: > Hallo Dieter, das war keine Frage-Es ging um das Re-Engeneering der > Daten. Wenn es um die Diagnose in der Werkstatt geht kann man sich ansehen was die Original-Diagnosesysteme der Fahrzeughersteller an der OBD Buchse machen. Daraus kann man relativ einfach ableiten wie die Diagnose funktioniert. Zugriff auf den internen CAN-Bus ist dafür nur selten nötig da die Diagnose über den OBD Stecker abläuft.
Ich sag mal so, CAN-FD ist der aktuelle Stand, ich habe gerade erst eine ECU geflasht über CAN-FD auf dem Diagnose CAN, das Fahrzeug dazu ist auch schon ein paar Jahre in Serie. Wenn Dich das noch nicht betrifft, gut für Dich, aber kommen wird das. :-) Und ein CAN-FD Adapter unterstützt auch Classic-CAN. Und wie ich schrieb, das Adafruit Feather M4 CAN ist zumindest eine Platine die man fertig kaufen kann: https://www.adafruit.com/product/4759 Gehäuse, tja, das hat es nicht. Meine Platinen sind für was anderes gedacht: https://github.com/RudolphRiedel/USB_CAN-FD Nur verkaufe ich die nicht und leider ist auch noch keine Firma auf die Idee gekommen die Dinger herzustellen, soweit ich weiß. Wir haben auch Software, nur ist die proprietär und war vorher schon vorhanden, die unterstützt auch andere Interfaces. Also wenn das für Dich nicht interessant ist, dann ist das eben so.
Bevor man da Arbeit investiert sollte man sich überlegen wofür. Ich denke damit ist alles gesagt. Elmü M. schrieb: > Wenn du aber einen universellen standard Adapter im Format wie J2534 für > CAN FD kennst, ließe sich darüber reden, den zu implementieren. Heißt ja nicht automatisch uninteressant. Mach doch einen eigenen Thread auf?
Hallo Alex > SAE J2534 ist für mich auch ein höherliegendes Protokoll, "für mich"? J2534 ist nicht nur für dich! J2534 ist für alle und es ist überhaupt KEIN Protokoll. Das ausführliche PDF Dokument zu J2534 findest du auf meiner Homepage. Wenn du die ausführliche Beschreibung gelesen hast, hast du den Link bereits gesehen. Da ist alles erklärt. Du mußt dir halt nur mal die Mühe machen, zu lesen bevor du hier dein Unwissen kund tust. J2534 ist der "OpenPort" Standard der auf der untersten Ebene ein USB Gerät ist, das mehrere USB Interfaces enthält und im Gegensatz zu FTDI keinen COM Port erzeugt, wenn der richtige Treiber installiert ist. Aber in erster Linie beinhaltet J2534 die sogenannte Windows DLL, welche es Programmierern leicht macht, mit einem J2534 Adapter über eine standardisierte API Schnittstelle zu kommunizieren. Die API Befehle und deren Parameter sind alle in dem PDF Dokument erklärt. Der große Vorteil davon ist, dass jeder Adapter Hersteller seinen eigenen Adapter bauen kann und dieser dann über eine standardisierte Schnittstelle genutzt werden kann. Ich schreibe also einmal in HUD ECU Hacker den Code, der die J2534 Schnittstelle programmiert und der Benuzter meines Programmes kann dann irgendeinen J2534 Adapter benutzen, egal ob dieser von Tactrix oder von Drewtech hergestellt wurde. Jeder Hersteller liefert seinen Adapter und Treiber, aber die PC Software muß nur einmal geschrieben werden für alle J2534 Adapter. J2534 ist also eine API Schnittstelle und kein Protokoll. J2534 Adapter können in der Regel die Protokolle: - CAN Raw ("nacktes" CAN wie du es nennst, beinhaltet auch J1939) - ISO 15765 (CAN Bus) - ISO 9141 (K-Line) - ISO 14230 (K-Line) - J1850 - Auch einige proprietäre Protokolle wie Honda lassen sich mit J2534 programmieren. - Das proprietäre KW1281 Protokoll von Bosch geht nicht, das ist aber auch uralt und extrem langsam. > Wenn diese OBD2 Adapter an deinem Auto funktionieren ist ja schön, > bei mir jedenfalls nicht. Dann ist an deinem Auto also etwas kaputt. Es macht ja wohl keinen Sinn, dass da ein OBD2 Stecker ist und der angeblich zu nichts nutze ist. Ich kann daraus nur schließen, dass du was falsch gemacht hast. Oder hast du eine Oszilloskop angeschlossen und nichts gesehen? Dann liegt das wohl daran, dass du erst mal einen Befehl an deine ECU senden mußt bevor du eine Antwort bekommst. Der OBD2 Standard ist bei allen Fahrzeugen, die nicht uralt sind, gesetzlich vorgeschrieben zur Überwachung der Abgas Emissionen. Wenn du so einen Stecker hast, dann funktioniert der selbstverständlich auch! Da kann sich dann z.B. der TÜV dranklemmen oder eine Werkstatt. Wenn der bestellte Adapter bei dir ankommt, installierst du in HUD ECU Hacker den Tactrix Treiber und schaltest HUD ECU Hacker in der Autodetect Modus und du wirst sehen, dass dein Stecker sehr wohl zu etwas nützlich ist. Elmü
Hallo Vanye > Was mich bei sowas immer wundert, sitzt ihr dann Tagelang mit dem > Laptop im Auto und hackt immer irgendwas? Mit Sicherheit nicht. Wer sich ernsthaft mit dem Hacken einer ECU befaßt, der hat eine ECU auf dem Tisch liegen, an 12 Volt angeschlossen und über den CAN Bus und einen Adapter mit dem PC verbunden. Da kann man z.B. das Flashen des Firmware Uploads cracken, was man zum Tuning braucht. Die meiste und zeit-aufwändigste Arbeit ist aber das Reverse Engineeren des ECU Codes. Und das ist meist ekliger Assembler Code. So was: FUN_c26dca c26dca 88 80 mov [-r0],r8 c26dcc da c1 ac ae calls FUN_c1aeac c26dd0 f0 d4 mov r13,r4 c26dd2 f2 fc 6a c0 mov r12,[0xC06A] c26dd6 da c2 52 88 calls FUN_c28852 c26dda f0 84 mov r8,r4 c26ddc d7 40 80 03 extp #0x380, #1 c26de0 f2 fc ee 08 mov r12,[0x08EE] c26de4 f2 fd 62 c9 mov r13,[0xC962] c26de8 da c2 52 88 calls FUN_c28852 c26dec f0 c4 mov r12,r4 c26dee d7 40 80 03 extp #0x380, #1 c26df2 f3 f2 f4 08 movb RL1,[0x08F4] c26df6 2d 1c jmpr cc_EQ,LAB_c26e30 c26df8 f3 f4 3c c9 movb RL2,[0xC93C] c26dfc 49 44 cmpb RL2,#0x4 c26dfe 2d 02 jmpr cc_EQ,LAB_c26e04 c26e00 49 41 cmpb RL2,#0x1 c26e02 3d 16 jmpr cc_NE,LAB_c26e30 Wenn man das verstanden hat, kann man dann z.B. den Algorithmus finden, wie man den Security Access zu einer ECU bekommt. Die ECU sendet eine Zufallszahl und die Software, die eine Firmware hochladen will, muß über eine geheime Formel den richtigen Schlüssel berechnen und zur ECU senden. Dann kann man in HUD ECU Hacker ein Macro Skript schreiben um das zu testen. Oder wenn du z.B du einen Sensor hast, bei dem du nicht weißt, ob er richtig funktioniert, kannst du dich über CAN Bus damit verbinden und die Daten sehen, die er sendet. > Man braeuchte sowas als Software auf einem Raspberry PI Nein. Der nützt dafür überhaupt nichts. Elmü
Der Tuner, der mein Auto getuned hat, er geht auch über die OBD2 Schnittstelle rein. Da ist nichts "zu und unerreichbar". Man muss halt die richtigen Befehle kennen. Ich denke "gehackt" ist da vieles nicht. Da wurde sicher vorhandenes Wissen geteilt. Von einem Mitarbeiter, der diese Daten hat Auf jeden Fall rennt mein Auto ganz fürchterlich.😆 Ich habe mich vor Jahren angefangen mit der Diagnose zu beschäftigen. Wenn ich jünger wäre, würde ich auch ins Tuning einsteigen. Total interessant, dass man "sein Auto bauen kann."
:
Bearbeitet durch User
Frank O. schrieb: > Total interessant, dass man "sein Auto bauen kann." Oder sein Auto in einen tonnenschweren Ziegelstein verwandeln kann, wenn man nicht weiß was man tut.
Elmü M. schrieb: > > Die meiste und zeit-aufwändigste Arbeit ist aber das Reverse Engineeren > des ECU Codes. Und das ist meist ekliger Assembler Code. So was: Was ist am Assembler Code des C166/ST10 eklig? Der lässt sich doch gut lesen. Aus welchem Fahrzeug ist das denn, das dürfte schon etwas älter sein.
Frank O. schrieb: > Der Tuner, der mein Auto getuned hat, er geht auch über die OBD2 > Schnittstelle rein. Das funktioniert bei den meisten älteren Autos weil Firmwareupdates damals so implementiert waren. Heute ja oft daran vorbei over the air. > Da ist nichts "zu und unerreichbar". Doch, natürlich, auf dem OBD Bus gibt es bei nicht uralten Autos nur die gesetzlich geforderten Abgaskontrollbefehle. Alles andere ist nicht zugänglich sondern läuft auf weiteren anderen CAN Bussen hinter einem Gateway oder nennen wir sie besser Firewall. > Man muss halt die richtigen Befehle > kennen. Eben die Gateway-Befehle sind nicht dokumentiert, oft auch noch verschlüsselt und weder du noch die Fremdhersteller von Diagnosesoftware bekommen sie vom Automobilhersteller, der sie teilweise selbst nicht kennt weil das ganze Zeug unzureichend dokumentierte Zulieferteile sind. Joe J. schrieb: > Das interessante ist, das solche Zugänge per Gesetz offen gehalten > werden müssen, damit freie Werkstätten arbeiten können am Markt. Vergiss es. Zahnloses Gesetz. Die Zugänge sind alle verrammelt. Die freie Werkstatt hat ein Diagnosegerät von einem Drittanbieter. Der kann die gesetzlichen Abgaswerte, hat weitere Zugänge "Parkbtemse lösen, Benzinpumpe ansteuern" teilweise gesnifft und lässt sich das je nach Automodell teuer bezahlen und andere "Blinker an/aus" hat er einfach nicht. Ende Gelände. Nirgends gibt es eine Hersteller-Doku, wie ein Sensor oder Aktor über den CAN Bus redet. Ausser selten mal ein geleaktes Dokument eines OEM ohne Automodellbezug. Da ist man vollkommen auf Tools wie diesen HUD ECU Hacker angewiesen und endlose Hacking-Sessions. Keine freie Werkstatt hat Bock, so was zu machen. Das machen nur Autotuner, die für ihre Arbeit Phantastillionen fordern. Frank O. schrieb: > Total interessant, dass man "sein Auto bauen kann." Vergiss es. Wer wirklich 'sein' Auto baut, schmeisst die Hersteller-ECU raus und installiert eine dokumentierte ECU eines Fremdanbieters. Nicht dass die Hersteller-ECU nicht alles könnte was man braucht, aber sie ist eben undokumentiert und verrammelt. Joe J. schrieb: > Oder sein Auto in einen tonnenschweren Ziegelstein verwandeln kann, wenn > man nicht weiß was man tut. Eben. Selbst simpelste Autoreparatur ist inzwischen weitgehend verhindert. Nicht nur weil die versteckten Plastikrastnasen abgebrochen sind beim Versuch Zugang zu bekommen, sondern weil es mit dem einfachen Austausch eines Teil lang nicht getan ist. Die Dinger sind verdongelt auf diese Fahrgestellnummer und ohne Freischaltung mit Onlineverbindung zum Automobilhersteller (so lange du noch Glück hast dass es ihn gibt) bekommst du das Ersatzteil nicht eingebunden, diesen Zugang haben natürlich nur Markenwerkstätten. Schon die Theorie, dass man über das Diagnosesystem erfährt, wo das Problem liegt, Steuergerät stromlos oder kaputt, Kabel Kontaktproblem oder Signalstörabstand zu schlecht, vom Steuergerät angesprochenes Bauteil defekt oder Leitung dorthin, ist Humbug. Zwar liegen die gesamten Diagnosezustände intern vor, aber sie sind nicht zugänglich, werden nicht kommuniziert, schon gar nicht an den Fahrer per Multifunktionsdisplay, aber viele auch nicht an die Diagnosesysteme selbst der Markenhersteller. Autos sind heute Schrott ab Werk. Je luxuriöser und teurer, je schneller wertlos weil unreparabel.
Michael B. schrieb: > Nirgends gibt es eine Hersteller-Doku, wie ein Sensor oder Aktor über > den CAN Bus redet. Ausser selten mal ein geleaktes Dokument eines OEM > ohne Automodellbezug. Da ist man vollkommen auf Tools wie diesen HUD ECU > Hacker angewiesen und endlose Hacking-Sessions. Keine freie Werkstatt > hat Bock, so was zu machen. Würde ich nicht sagen. Die Hersteller liefern Dokus gegen bares. Ein Beispiel ist, das du Schaltpläne auf Herstellerportalen abrufen kannst. Ebenso gibt es Dokus zu den Formeln und Einheiten für Parameter/Diagnosedaten. Ist natürlich für Privatpersonen tlw. aber uninteressant, da nicht immer einfach zugänglich oder zu teuer. Zumindest bei den Diagnose- und Konfigurationsdaten ist das so.
:
Bearbeitet durch User
Michael B. schrieb: > Autos sind heute Schrott ab Werk. Je luxuriöser und teurer, je schneller > wertlos weil unreparabel. Das ist korrekt. Zumindest finger weg von den neuen Modellen, die allesamt bei den Kunden nachreifen - klassische Bananenprodukte. Wenn ich sehe, was an Fehlereinträgen bei Neufahrzeugen auslesbar ist..Spasshalber pflegen wir im Unternehmen Ranglisten - um die meisten Fehler in den Steuergeräten bei Kollegen mit neuen Firmenfahrzeugen zu dokumentieren. Das ist schon krass. Aber das Problem haben alle Hersteller irgendwo.
:
Bearbeitet durch User
Michael B. schrieb: > Vergiss es. Wer wirklich 'sein' Auto baut, schmeisst die Hersteller-ECU > raus und installiert eine dokumentierte ECU eines Fremdanbieters. Nicht > dass die Hersteller-ECU nicht alles könnte was man braucht, aber sie ist > eben undokumentiert und verrammelt. Gibt es so etwas für einen bestimmten Type?
Angehängte Dateien:
-
Delphi_MT05.3.png
210 KB
Hallo Michael > Selbst simpelste Autoreparatur ist inzwischen weitgehend verhindert. Es ist beeindruckend wie sich der Markt in wenigen Jahrzehnten von einem Extrem zum anderen geändert hat. Ich habe noch ein Phillips Röhrenradio aus der Zeit, als UKW gerade moden war, bevor Stereo auf den Markt kam. Auf der Rückwand ist der Schaltplan aufgedruckt und an der Seitenwand ist ein Tütchen mit 2 Ersatzsicherungen angetackert. Das Radio funktionierte heute noch! Damals lebten wir noch in einer anderen Welt! Heute undenkbar. Damals waren Geräte noch dazu gedacht, repariert zu werden. In den 80'er Jahren habe ich Fernseher reparieret. Es gab Schaltpläne vom Hersteller und Ersatzteile. Damals galt das Motto "Der Kunde ist König". Zu der Zeit kostete aber ein neuer Fernseher auch 1000 Mark! Die Globalisierung hat das alles kaputt gemacht. Lange bevor China zu einem global Player wurde, kamen japanische Ferneher auf den deutschen Markt. Vollkommen unreparierbarer Schrott. Danach kamen die Chinesen und Koreaner und es wurde noch schlimmer. (Ich werde nie wieder ein Produkt von LG kaufen!) Und die unzähligen deutschen Marken, die ich damals repariert habe, sind alle Pleite gegangen, weil der König Kunde lieber billigen Schrott aus Asien gekauft hat als deutsche Qualität. Das beste Beispiel war dann der Kampf zwischen Video 2000 und VHS. Video 2000 von Phillips und Grundig war viel besser, aber teurer. Wer hat den Kampf gewonnen? Das billige aber schlechtere VHS aus Japan. Daraus haben deutsche Firman natürlich gelernt: Es lohnt sich nicht, Qualitätsprodukte herzustellen! Der geizige Kunde läßt sie im Regal verstauben. An der Entwicklung ist der König Kunde selber schuld, der lieber den Billigschrott aus Asien kauft, der NICHT dafür entwickelt wurde, reparierbar zu sein. ___________________________________ Allerdings muß ich sagen im Falle von Autos und Motorrädern ist es auch gut, dass die Elektronik so kompliziert ist. Alle modernen Fahrzeuge haben einen Immobilizer, der es unmöglich macht ein gestohlenes Auto ohne den original Schlüssel zu starten. Wenn die (CAN Bus) Kommunikation zwischen ECU und Immobilizer leicht zu cracken wäre, gäbe es mehr Autodiebstähle und morgen wäre dein Auto vielleicht nicht mehr da, wo du es geparkt hast. ___________________________________ > Die freie Werkstatt hat ein Diagnosegerät von einem Drittanbieter. > Der kann die gesetzlichen Abgaswerte, hat weitere Zugänge > "Parkbtemse lösen, Benzinpumpe ansteuern" teilweise gesnifft > und lässt sich das je nach Automodell teuer bezahlen. Da ich ja selbst so eine Diagnosesoftware seit 4 Jahren entwickele, kann ich hier aus Erfahrung sprechen: Dass der "Drittanbieter" sich das teuer bezahlen läßt, ist für mich vollkommen verständlich. Ich nehme mal an, dass du dir nicht mal in deinen schlimmsten Albträumen vorstellen kannst, wie viel Arbeit in HUD ECU Hacker steckt. Wie viel Arbeit es ist, einfach "nur" die Parameter der ECU anzuzeigen. Siehe angeängter Screenshot. Was glaubst wie lange ich daran gearbeitet habe? Und was Firmware Upload angeht oder einer ECU beizubringen, mit einem neuen Immobilizer zu funktionieren, ist noch mal eine ganz andere Hausnummer. Ich kann es vollkommen verstehen, dass "Drittanbieter" sich das teuer bezahlen lassen. Bei all den unzahligen Arbeitsstunden, die da in Reverse Engineering investiert wruden, kann es sogar sein, dass die da gar nicht viel dran verdienen. Denn wie viele Kunden kaufen schon so eine hoch spezialisierte Software? Das ist nicht die Masse an Kunden, die sich jedes Jahr ein neues Handy kauft! Und auch ich kann nicht den Rest meines Lebens umsonst arbeiten. Ich muß auch meine Rechnungen bezahlen. Und so denke auch ich darüber nach, in Zukunft bezahlte Extra Features in HUD ECU Hacker einzubauen. Elmü
:
Bearbeitet durch User
Angehängte Dateien:
-
J2534.png
540 KB
Sorry aber hier passiert gar nix. Absolute Ruhe, wie erwartet. Zündung ist an und auf dem Teensy ist Traffic.
Elmü M. schrieb: > Ich habe schon vor langem geschrieben dass du dich an JEDEN beliebigen > CAN Bus anklemmen kannst und nicht auf den OBD Stecker limitiert bist. > Wenn der Stecker nicht paßt mußt du halt 4 Drähte selber löten oder dir > einen Adapter basteln. Kann ja wohl nicht so schwer sein. Ich verstehe > nicht warum das schwer zu verstehen ist? Hab mir den Tactrix mal genauer angesehen. Da ist ein TJA1050 drauf. Das Layout des TJA1055 ist größer, umlöten ist nicht 1:1 möglich. Könnte man allenfalls mit Apdapterplatine versuchen, aber dann bekommt man das Gehäuse nicht mehr zu. Selbst wenn ich es umlöten würde, so kann man immernoch nicht die 83.333 kbaud auswählen, es gibt nur 250.000 und 500.000 zur Auswahl. Ich sehe keine Möglichkeit wie das mit JEDEM beliebigen CAN-Bus gehen soll.
Hallo Alexander Wieder mal bestätigst du deine fehlenden Kenntnisse. Du glaubst, dass du einfach einen Befehl an den CAN Bus sendest, den du irgendwo gefunden hast und dann sprudelt der CAN Bus vor lauter Daten? Du hast wriklich sehr naive Ideen. > und auf dem Teensy ist Traffic. Also jetzt widersprichst du dir selbst! Es sind Daten auf dem Bus, aber sind keine zu sehen? Und wo ist der Screenshot der Daten ? Alles was auf dem CAN Bus passiert wirst du auch in HUD ECU Hacker sehen, vorausgestetzt natürlich du hast den Adapter richtig konfiguriert. Und natürlich vorausgesetzt du hast alle Kabel richtig angeschlossen. Und hast du versucht dich im AutoDetect Modus mit deinem Auto zu verbinden? Das ist der aller erste Test ! Davon schreibst du aber gar nichts! Du wählst ECU Model = "Autodetect (All OBD2 compliant ECU's)" Hast du das versucht? Wenn dein Auto OBD2 compliant ist, dann geht das. Sonst muß dein Auto sehr alt sein. Es sollte selbstvertändlich sein, dass du dich dafür mit dem OBD2 Stecker verbindest und nicht mit dem Body CAN Bus. > Das Layout des TJA1055 ist größer, Keine Anhnung was das wieder für eine absurde Idee ist? Es gibt absolut keinen Grund am Tactrix IRGENDETWAS rumzulöten! Der Tactrix ist ein universeller Adapter an dem es NICHTS zu ändern gibt. > Selbst wenn ich es umlöten würde, so kann man immernoch nicht die 83.333 > kbaud auswählen, es gibt nur 250.000 und 500.000 zur Auswahl. Also jetzt wird es WIRKLICH peinlich! Du hast also auch keine Kenntnisse von grundlegender Windows Bedienung! Das Control, wo du die Baudrate auswählen kannst, heißt ComboBox. Dort kannst du entweder aus der DropDown Liste auswählen oder manuell die Baudrate eintippen. Du tippst du einfach 83333 ein und der Tactrix macht das ohne Probleme. Wie du hier siehst fehlen dir nicht nur CAN Bus Kenntnisse, sondern auch grundlegende Windows Kenntnisse: Open J2534 adapter, Protocol: CAN Raw, 83333 baud Command ID: 7E0, Response ID: 608 ConnectFlags: NONE Adapter: OpenPort 2.0 J2534 ISO/CAN/VPW/PWM Vendor: Tactrix Inc. Serial Number: TAhJALxt Firmware Version: 1.17.4877 Pass-Thru API Version: 04.04 Windows DLL Version: 1.02.4820 Jul 6 2016 17:20:04 Measure the vehicle voltage at the J2534 adapter Battery voltage: 11.89V Set pass ALL filter Clear Rx buffer Und schon ist der Adapter mit 83.333 kBaud geöffnet ! Wenn du schon dabei scheiterst eine Baudrate einzutippen, na dann gute Nacht. > Sorry aber hier passiert gar nix. Absolute Ruhe, wie erwartet. Ich arbeite seit 4 Jahren mit dem Tactrix Adapter und es ist mir noch NIE passiert, dass er Daten auf dem CAN Bus nicht anzeigt. Das ist auch kein Wunder, denn dafür wurde er ja schließlich entwickelt. Du bist der Einzige, der hier Probleme hat. Wieso klappt das bei mir und bei dir nicht ? Ich sehe ganz klar wie du schon im Vorraus mit vollkommen negativem Denken an die Sache rangehst. Statt wie ein Wissenschaftler zu arbeiten gehst du von vornherein davon aus, dass das sowieso nicht funktioniert. Dann lass es doch ! Wenn du keine Ahnung von CAN Bus hast und nicht mal in der Lage bist, meine Postings hier zu lesen, wo ich dir die Dinge erkläre, dann gibt es für dich keinerlei Hoffunung. Du willst ja nur bestätigen, dass du Recht hast und es nicht funktioniert. Selbstvertändlich wirst du Betätigung dafür leicht bekommen indem du Kabel falsch anschließt oder die falsche Baudrate benutzt oder Befehle sendest die deine ECU nicht kennt. Da dir grundlegende Kenntnisse fehlen und du auch nicht bereit bist zu lernen, rate ich dir, den CAN Bus den Experten zu überlassen.
:
Bearbeitet durch User
Angehängte Dateien:
Elmü M. schrieb: > Alles was auf dem CAN Bus passiert wirst du auch in HUD ECU Hacker sehen Auf dem Diagnose-CAN (OBD2 Stecker) passiert aber nichts!1elf Alexander schrieb: > Es ist nun mal leider so, dass man bei den meisten Fahrzeugen über den > OBD2 nur an den Diagnose-CAN ran kommt, und da herrscht naturgemäß > Funkstille. Um Daten zu empfangen muss man sie anfragen. Das entsprechende Wake-up command habe ich gesendet. Dieses soll (nach meinem Verständnis) den gesamten CAN-Traffic über das Diagnose-Gateway zu Diagnosezwecken spiegeln/tunneln. https://github.com/rnd-ash/mercedes-hacking-docs/blob/master/Chapter%203%20Connecting%20to%20the%20Vehicle.md#mercedes-benz-model-codes Wenn der Adapter ordnungsgemäß konfiguriert ist (500.000 kbaud) blinkt als Bestätigung auch die LED der Klimaanlage wenn ich die Msg sende (bei 250.000 kbaud nicht). Allerdings scheint es das falsche Wake-up command zu sein, denn auf dem Diagnose-CAN bleibt es still. Elmü M. schrieb: > Da dir grundlegende Kenntnisse fehlen und du auch nicht bereit bist zu > lernen, rate ich dir, den CAN Bus den Experten zu überlassen. Ich habe mir eine Platine entworfen für den TJA1055 und diese am Komfort-CAN angeschlossen. Ich lese mit einem Mikrocontroller den CAN-B bei 83.333 und das funktioniert einwandfrei. Empfangen wird das Klimabedienteil und gesteuert wird der Klimakompressor. https://gitlab.com/aIecxs/w211-ac-control Ich denke grundlegende Kenntnisse besitze ich und ich bin auch bereit zu lernen. Wenn Du mir sagst wie ich einen High Speed CAN Transceiver TJA1050 an einen Low Speed/Fault Tolerant CAN Bus anschließen und beschalten muss, dann probiere ich es gerne aus. Ansonsten nützt mir der Tactrix relativ wenig. Das was da über OBD2 von der ECU kommt ist für mich uninteressant, das kann ich auch mit einem ELM327 und der Torque App über Bluetooth auf dem Handy haben, und flashen kann ich mit C4 und Vediamo. Elmü M. schrieb: > Ich sehe ganz klar wie du schon im Vorraus mit vollkommen negativem > Denken an die Sache rangehst. Ich respektiere deine Arbeit und bewundere deine umfangreiche Dokumentation. Da steckt eine Menge Lebenszeit drin. Ich erwarte auch keinen kostenlosen Support. Du hast aber hier speziell den CAN Bus Analyzer beworben, an dem ich primär interessiert war.
:
Bearbeitet durch User
Alexander schrieb: > Wenn Du mir sagst wie ich einen High Speed CAN Transceiver TJA1050 an > einen Low Speed/Fault Tolerant CAN Bus anschließen und beschalten muss, Das funktioniert tatsächlich. Der FT-CAN muss terminiert sein, der HS-Transceiver wird einfach direkt an CAN_H und CAN_L geklemmt. Das ist natürlich keine Lösung für die Serie, aber so kann man zumindest messen wenn man das falsche CANpiggy drin hat.
Das mag funktionieren wenn man mit Spannungsteilern die Pegel anpasst. Problem ist es hält dann den Bus wach. Terminieren darf man da nix, der Bus ist schon terminiert.
Angehängte Dateien:
Hallo, zum letzten Mal > Wenn Du mir sagst wie ich einen High Speed CAN Transceiver TJA1050 an > einen Low Speed/Fault Tolerant CAN Bus anschließen und beschalten muss, > dann probiere ich es gerne aus. Das ist VOLLKOMMENER UNSINN! Diese TJA chips sind nichts weiter als primitive Treiber / Spannungswandler. Die haben mit der Baudrate nichts am Hut. Die haben ja nicht mal einen Quartz. Die geben nur an den Bus weiter was der Prozessor ihnen sendet. Das gesamte CAN Bus Timing wird im Prozessor gemacht, nicht in diesen Chips. Du hast im Tactrix einen CAN Bustreiber Chip der bis 1 Mbaud funktioniert. Selbstverständlich kann der auch langesamere Baudraten. Ich habe den Tacrix hier mit 5 kBaud (FÜNF!) am Daten Übertragen. Der Tactrix funktioniert mit 5 kBaud und mit 1 Mbaud. Und rate mal was dazwischen liegt! 83.333 kBaud geht selbstverständlich auch. Am Tactrix gibt es GAR aber absolut GAR Nichts dran rumzulöten! Der Tactrix ist ein hochwertiger unverseller Adapter. > Ansonsten nützt mir der Tactrix relativ wenig. Ich kann es jetzt wirklich nicht mehr hören! Ich sage es dir jetzt zum letzten Mal: Du kannst den Tactrix am Mercedes Body CAN Bus mit 83333 Baud einwandfrei benutzen. Ich habe keine Ahnung was du da die ganze Zeit falsch machst? Aber ich habe es hier ausprobiert und es geht einwanbdfrei. Hier der Beweis: Ich habe 2 Tactrix Adapter. Einen originalen von Tactrix und einen chinesischen Klon. Ich habe beide mit 83.333 kBaud geöffnet und kann problemlos Daten übertragen von einem zum Anderen in beide Richtungen. Siehe erster angehängter Screenshot. Um zu bestätigen, dass der Tactrix auch die Baudrate richtig erzeugt, habe ich für dich auch noch einen Oscilloskop Screenshot angehängt. 83333 baud bekommst du zum Besipiel wenn du einen 12 MHz Quartz durch 144 teilst. 12000000 / 144 = 83333 Die Periodendauer eins Bits ist exakt 12 µs. 1 / 83333 Hertz = 12 µs Wie du auf meinem Oszilloskop siehst, hat der Tacrix diese Baudrate extrem präzise eingestellt. 5 Bits = 5 x 12 µs dauern genau 60 µs, wie du siehst. So, und wenn du mir jetzt nochmal erzählst, dass der Tactrix bei dir nicht funktioniert, dann liegt das an deinen fehlenden Elektronik Kenntnissen, die ich schon in deinem ersten Posting festgetellt habe, aber nicht am Tactrix Adapter. Ich kann dir da leider nicht mehr weiter helfen. Elmü
:
Bearbeitet durch User
Elmü M. schrieb: > dann liegt das an deinen fehlenden Elektronik Kenntnissen, Deine Aussage der TJA1050 ginge an jedem beliebigen CAN Bus ist einfach falsch... Du hast anscheinend nicht mal ins Datenblatt geschaut. Beitrag "Low Speed Can Pegel Terminierung" Alexander schrieb: > Problem ist es hält dann den Bus wach. Osche R. schrieb: > Wahrscheinlich schlägt der dominant timeout zu. Wenn der > Highspeed-Transceiver zu viele dominante lowspeed-Bits nacheinander > sieht, glaubt er, da wäre ein Kurzschluß und schaltet ab. > > Für die Transceiver ist immer eine minimale Bitrate spezifiziert. > > > Davon abgesehen passt die Terminierung nicht und der > Eindraht-Rückfallbetrieb geht ebenfalls schief. Ich melde mich wieder falls ich das J2534 "Protokoll" auf einem Mikrocontroller zum laufen gekriegt habe, vielleicht kann ich (und andere) damit Dein Programm ja irgendwann auch mal nutzen. Bis dahin vielen Dank. https://github.com/rnd-ash/j2534-arduino-win
:
Bearbeitet durch User
Angehängte Dateien:
Elmü M. schrieb: > Ich habe den Tacrix hier mit 5 kBaud (FÜNF!) am Daten Übertragen. > Der Tactrix funktioniert mit 5 kBaud und mit 1 Mbaud. Der TJA1050 hat eine Dauerdominanzabschaltung, die nach min 250us typ 450us max 750us zuschlägt, siehe Datenblattauszug. Auf dem CAN-Bus folgt nach maximal 5 Dominanzbits ein rezessives Stuffbit. Das bedeutet, dass der TJA1050 beim Senden ab 20kBaud und drunter nicht mehr funktionieren könnte und ab 6.6kBaud und drunter sicher nicht mehr funktionieren wird. Die Signalisierung von Fehlerzuständen, die bei CAN sechs dominante Bits in Reihe benötigt, könnte sogar schon ab unter 24kBaud beeinträchtigt sein. LG, Sebastian
:
Bearbeitet durch User
Ich habe den Eindruck, dass a jemand mehr aus der (PC-)Software-Ecke kommt und Andere vielleicht mehr aus der Hardware- und embedded Ecke, für die folgendes gar keine schreckliche Vorstellung wäre: Elmü M. schrieb: > montatelang so etwas > Komplexes selbst zusammenzulöten und dann zu programmieren? > > So einen CAN Bus Mikroprozessor zu programieren ist extrem schwierig und > erfordert sehr viel Code. Für die ist vielleicht auch ein Selbstbau-Projekt etwas Anderes als der Erwerb eines Teensy: Elmü M. schrieb: > Ich habe extrem schlechte Erfahrungen mit solchen Selbstbau Projekten > gemacht. [...] Nach wenigen > Jahren wurde dann auf einmal die Produktion des Prozessors für den > Teensy 3.2 einfach so eingestellt. Alles umsonst! Jedenfalls würde es der Lesbarkeit dieses Threads enorm gut tun, wenn da jemand etwas auf die Bremse träte, gerne auch rein mechanisch angesteuert. Ich finde den Thread nämlich eigentlich interessant
Elmü M. schrieb: > Diese TJA chips sind nichts weiter als primitive Treiber / > Spannungswandler. FT-CAN (TJA1055) und HS-CAN (TJA1050) haben unterschiedliche Pegel. FT-CAN: CANH dominant 5 V, rezessiv 0 V CANL dominant 0 V, rezessiv 5 V Es reicht, wenn der dominante Pegel auf einer Leitung vorhanden ist. D.h. der Bus funktioniert auch, wenn eine Leitung unterbrochen ist. Die Treiber sind open drain bzw source mit Pullup-Widerstand für den Ruhepegel. HS-CAN: CANH dominant 5 V, rezessiv 2,5 V CANL dominant 0 V, rezessiv 2,5 V Um Reflexionen zu vermeiden, wird die Leitung an ihren Enden mit Wellenwiderstand (100 - 120 Ohm) abgeschlossen. Der stellt gleichzeitig den Ruhepegel ein. Der HS-CAN kommt aber auch mit rezessiven Pegeln von 0 V bzw 5 V klar. Daher kann man einen TJA1050 auch an einen FT-CAN klemmen. Das ist natürlich keine Serienlösung, aber für ein nur temporär angeklemmtes Diagnosegerät durchaus machbar. Damit lässt sich der o.g. "Tactrix Adapter" auch an einem FT-CAN verwenden.
Angehängte Dateien:
-
hs_can.png
4,8 KB
Soul E. schrieb: > HS-CAN: > CANH dominant 5 V, rezessiv 2,5 V > CANL dominant 0 V, rezessiv 2,5 V Ich kenne den HS-CAN dominant mit 1,5/3,5V. So ist jedenfalls die Lehrmeinung.
Soul E. schrieb: > Damit lässt sich der o.g. "Tactrix Adapter" auch an einem FT-CAN > verwenden. Ich probiere es mal aus. Ich habe schon andere Projekte gesehen wo das angeblich gehen soll mit den Arduino Platinchen über SPI, da ist ja auch ein TJA1050 drauf. Bei mir hat das damals nicht geklappt, allerdings hatte ich nur einen mit 8 MHz Quarz. Ich hatte auch versucht mit Widerständen die Pegel anzupassen. Damit die Fahrzeugbatterie nicht nach drei Tagen leer ist habe ich es anders gelöst. https://www.mikrocontroller.net/topic/goto_post/7253407
:
Bearbeitet durch User
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.