Eifer bei der Sache, andere hätten schon längst aufgegeben!
Ich nicht.
Ich wär auch dran geblieben.
Rudi : Viel Erfolg
Uhrzeit einstellen ohne original Radio ?
-
Rudi -
26. Oktober 2020 um 11:30 -
Erledigt
-
-
Bilder von Vorder- und Rückseite habe ich mal im Anhang.
Aufgeben ? Nun, mich reizt dieses Thema. Der Ford ist ja nun doch schon etwas in die Jahre gekommen und wenn man ihn mit ein wenig Hardware, ein bisschen Software und etwas Know Hnow nochmal verbessern kann, warum nicht.
Gerade das CCC reizt mich. Offensichtlich sind ja Dinge in den Wagen verbaut, die nur per Software deaktiviert wurden.
Oder das mit dem Reifenumfang. Mein Tacho war immer so 5 bis 7 Km/h vor gelaufen. Durch anpassen des Reifenumfang konnte ich das auf 2 Km/h drücken. Gefällt mir persönlich viel besser.
Tja, was die Baudrate angeht. Ich bin mir eigentlich sicher, das es früher bei den Modems einen AT Befehl gab, mit dem man die Baudrate einstellen konnte. Aber ich finde im Internet nichts mehr bzw. der AT+IPR=Baudrate wird vom CM327 nicht akzeptiert.
Da muß ich mich nochmal auf die Suche machen.
Oder mal nen seriellen Sniffer mitlaufen lassen und schauen, wie ELMConfig das den macht.
Danke für deine Korrektur, ich wußte doch, da war irgendwas.
Ich verstehe dann zwar nicht, warum Änderungen nichts bewirkt haben, wenn ich diese ins BCM geschrieben habe und kaum schreibe ich das selbe ins IPC, wird es übernommen.
Kann aber auch sein, das sich das System nur etwas nagepisst angestellt hat, weil als ich ins IPC geschrieben habe, hatte er auch Tachostand und Verbrauchsdaten nicht mehr angezeigt, Einstellungen im Convers geändert (ESP aus, Berganfahrhilfe aus) und die Klimaautomatik getilt.
Vielleicht wars ja eine Aart gesunder Reset.
-
Aber, die Baudrate zwischen PC und ELM327 sollte ja auch Banane sein.
kann man so nicht sagen. Wenn die Baudrate zwischen Adapter und PC zu gering ist gehen Daten vom CAN verloren. Ich denke aber mal das die angezeigte nicht die wirkliche ist. Die Übertragung findet ja mit der Geschwindigkeit des jeweiligen USB statt.
Die Bilder von Deinem Adapter irritieren mich ein wenig. Auf dem 2. Bild sieht man den Platz wo das Relais zum Umschalten zwischen HS und MS CAN hingehört. 2 Anshlüsse sind mit 0 ohm Widerständen gebrückt. Kann der Adapter beide Busse auslesen?
-
Mit dem Befehl ATDP kann man diese Einstellung abfragen und die steht bei mir auf "ISO 15765-4(CAN 117500)"
Also 500 kilobaud, wenn ich das richtig sehe.
Sprich, mt der falschen Baudrate kann der CAN Error eigentlich nichts zu tun haben.
Ah, gute Idee! AT SP setzt das Protokoll und mit AT DP kannst Du abfragen ob das geklappt hat
Also, wir brauchen für MS-CAN definitiv Protocol "B", also "User1 CAN (11* bit ID, 125* Kbaud)". Das muss nach dem einstellen mit "ATDPB" durch "ATDP" auch zurück gegeben werden. Ist das so bei Dir?
Die von Dir oben genannte Einstellung wäre falsch, sie ist für den HS-CAN. Da können wir aber mir der Uhrzeit nichts machen. Sagte ich ja, das ich a einen Fehler in meiner Dokumentation hatte. Es muss MS-CAN sein, sowohl Baudrate als auch Bus.
-
Aber, die Baudrate zwischen PC und ELM327 sollte ja auch Banane sein. Wichtig ist die zwischen ELM327 und dem CAN Bus.
Das kommt etwas auf den verwendeten Treiber an. Der Standard-Treiber von Windows ist durchaus Baud-Affin. Ein Zusatztreiber, wie er oft bei den Geräten mitgeliefert bzw. installiert wird, ist zu 99% ein VCP (Virtual COM Port) und der wiederum kenn das Konzept von Baudraten nicht. Das wird dort nur emuliert, aber faktisch arbeitet der immer in höchstmöglicher Geschwindigkeit. Die CAN-Adapter wie Dein CM327 machen in der Regel 2 MBaud. Das kannst Du ja mal nachsehen wenn Du ForScan startes und dort in die Settings gehts, bzw. im Log wird das auch angezeigt.
Von daher ja, die Baudrate ist Banane. Wären es wirklich nur 9600 Baud würdest Du damit praktisch keine wirkliche CAN-Kommunkation herstellen können weil der Adapter viel zu langsam wäre. Da die Billig-Chips keinen Empfangsbuffer haben würden, wie schon gesagt, Daten verloren gehen weil Du sie nicht schnell genug abholen kannst. Aber das muss ich alles nicht jucken denn wir wollen nix empfangen und nur ein einzigen Datenpaket senden, dafür würden sogar 96 Baud ausreichen
-
Die Bilder von Deinem Adapter irritieren mich ein wenig. Auf dem 2. Bild sieht man den Platz wo das Relais zum Umschalten zwischen HS und MS CAN hingehört. 2 Anshlüsse sind mit 0 ohm Widerständen gebrückt. Kann der Adapter beide Busse auslesen?
Scharf beobachtet, Respekt!
In der Tat, da macht man die Umschaltung nicht mittels Relais (zum Glück) sondern wirklich voll gesteuert vom Chip. Dafür sind zwei CAN-Transceiver (TJA1050) auf dem Board verbaut:
Diese werden vermutlich am Ausgang mit je HS-CAN und MS-CAN verbunden sein.
Jetzt kann es sein das der PIC2 die ansteuert (genug Intelligenz dafür hätte er). Der PIC2 enthält praktisch die raubkopierte ELM-Software vom Originalchip um diesen so gut es geht zu emulieren.
Es kann aber auch, wie in meinen Zeichnungen weiter oben dargestellt, über den USB/Serial-Wandler kommen. Hier ist ein, wenn auch raubkopierter, FTDI FT232RQ verbaut (das sieht man an dem schlecht nachgemachten Aufdruck am Chip, aber auch am Preis, denn der FDTI allein kostet so viel wie der ganze Adapter).
Seinen RTS-Ausgang habe ich mal markiert:
Der wird evtl./hoffentlich auf der anderen Seite auf die beiden Transistoren gehen und dort das 0 oder 1 in einen Schaltvorgang für den einen oder den anderen TJA1050 umwandeln. Da meine Quellen bestätigen das die Umschaltung über das RTS-Signal erfolgt ist das alles sehr wahrscheinlich.
Die Frage ist nun wie wir das bestätigen/beweisen können das es auch so ist?
Eine gute Idee wäre der Kommunikation von z.b. ForScan auf die Finger zu schauen. Letztlich arbeitet der auch nur mit AT-Kommandos. Evtl. gibt es spezielle Treiber/Treiber-Erweiterungen die das mitprotokollieren der Kommunikation erlauben.
-
kann man so nicht sagen. Wenn die Baudrate zwischen Adapter und PC zu gering ist gehen Daten vom CAN verloren. Ich denke aber mal das die angezeigte nicht die wirkliche ist. Die Übertragung findet ja mit der Geschwindigkeit des jeweiligen USB statt.
Die Bilder von Deinem Adapter irritieren mich ein wenig. Auf dem 2. Bild sieht man den Platz wo das Relais zum Umschalten zwischen HS und MS CAN hingehört. 2 Anshlüsse sind mit 0 ohm Widerständen gebrückt. Kann der Adapter beide Busse auslesen?
Nun, mit dem ELMConfig oder dem Forscan habe ich bisher keine Schwierigkeiten gehabt. Von daher komme ich mal mit einem zaghaften "ja, kann er" daher.
@Go4IT.
Gerade getestet. Mit ATSP B kann ich das Protokoll wechseln, was mit mit ATDP dann auch bestätigt wird.
So, gerade mal ausprobiert. ATSPB stellt ja korrekt um. Das bleibt auch definitiv aktiv, wenn ich die Kommandos eingebe und den Zeichenstring für die Uhrzeit sende, aber der CAN Error bleibt.
Dann habe ich mal mit ATSPA auf Automatik gestellt und mit ATDP ausgelesen. Dann steht er auf CarCode A, also SAE J939 (CAN 29/250)
Sende ich dann den Zeichenstring mit Datum und Uhrzeit kommt trotzdem CAN ERROR.
Sende ich mal Spaßeshalber wieder ATSP6, kommt kein CAN ERROR, aber es passiert auch sonst nichts.
Interessant ist vielleicht auch, das wenn der CAN ERROR mal gekommen ist, ich den Wagen nicht einfach ausschalten kann. Ich muß den Schalter drei mal lange drücken (ca. 1 Sec), bevor er dann aus geht.
-
Ja, Du störst mit den falschen Paketen massiv den HS-CAN. Das passt für mich alles ins Bild und ich bin inzwischen sehr sicher das die Sendung einfach nur auf dem falschen CAN-Bus erfolgt, die Befehle stimmen alle (wie zuletzt geschrieben).
Ich vermute Du hast es sowohl mit als auch ohne RTS ausprobiert? Und auch mal DTR?
Irgendwo hier liegt noch der Hund begraben...
-
In ForScan gibt es ja dieses Setting:
Und das macht mich schon sicher das es wirklich mit dem RTS gemacht wird. Und wenn Dein Adapter mit ForScan zusammen prima funktioniert, dann muss das letztlich am HTerm oder an der Art liegen wie wir das mit dem RTS nutzen?
Ich weiss noch aus den alten Tagen von RS232 das es gewisse Wechselwirkungen gab. RTS/CTS ist ja im Grunde gedacht für Software-Handshakeking und da sollte Hardware-Handshake für aus sein (XON/XOFF).
-
Ich habe es bisher nur mit bzw. ohne RTS versucht.
Gerade aber auch mal was anderes getestet.
Ich kann ja Abfragen direkt an die PID schicken. Laut der Anleitung mit 01 05 die Kühlwassertemperatur abfragen.
Schließe ich den CM327 an das Fahrzeug an und gebe nur ATZ und dann die Befehlsfolge oben, kommt CAN ERROR.
ATDP liefert SAE J939 (CAN 29/250)
Das selbe dann nochmal mit ATSPB und dann 01 05 versucht. CAN ERROR
Dann ATSP6 und 01 05 und ich erhalte Antwort 41 05 50. 50 HEX ist 90 Dezimal, abzüglich dem Nulloffset müßte das Kühlwasser also 50 Grad haben, was mir die Anzeige im Convers auch bestätigt.
Ich gehe nun mal davon aus, das solche Informationen auf dem normalen CAN BUS liegen, den ich also ohne Umschalten erreichen kann.
Wenn ich jetzt, wie auch immer, auf den anderen CAN BUS umschalte und auch den Befehl 01 05 sende, dürfte ich ja keine oder eine andere Antwort erhalten, als oben oder einen Error.
Ich habe das nun aber nicht ausprobiert, weil ich Angst habe, mit diesem Befehl eventuell etwas böses senden zu können.
Ansonsten, wenn der nichts anrichten kann, kann ich damit ja mal mit RTS, DTR usw testen, ob ich den BUS umschalten kann.
-
ATSP6 schaltet auf 500 kbaud und die "normalen" OBD-Abfragen (was Du mit PID bezeichnest) sind immer auf HS-CAN, also 500 kbaud. Von daher ist es normal und ok wenn Du da Antworten erhälst. Unser Problem ist nach wie vor: Wie schalten wir den Adapter auf MS-CAN um?
Schau doch mal in die Einstellungen vom Treiber. Bei mir steht bei Flussteuerung nämlich "Keine" und so sollte es auch sein, denn sonst werden die Handshake-Leitungen vom Treiber gesteuert und nicht von unserem Terminalprogram:
Es wäre für mich überhaupt mal gut zu wissen was Du so an Treibern installiert hast, also zeig doch mal die Liste im Geräte-Manager und den Treiber-Details.
-
Auch wenn Du es mir beharrlich einfach nicht glauben magst, aber es ändert nichts: ATSPB ist die richtige Einstellung.
Das CAN-Protokoll ist auf beiden Bussen ISO 15765-4 mit 11-Bit CAN-IDs, nur eben auf HS-CAN mit 500 Kbaud und auf MS-CAN mit 125 Kbaud.
Alles andere was Du gefunden hast ist sicher interessant, aber eine ganz andere Baustelle. Bei dem was wir tun bräuchten wir nichtmal sowas wie ein Protokoll, denn wir senden genau ein Datenpaket, wissen genau wie es aufgebaut sein muss und erwarten auch keine Antwort (Kommunikation).
Unser Problem ist schlicht und ergreifend das die Ansteuerung des RTS-Signals nicht funktioniert. Das ist die Voraussetzung um, egal was wir dem ELM so alles senden, dieses auch auf den MS-CAN Bus zu bekommen.
Wie schaut es denn mit den Treibereinstellungen aus?
Für mich wäre es sehr hilfreich wenn wir uns jeweils auf eine Sache zusammen konzentrieren könnten als ständig zwischen verschiedenen Themen hin und her zu springen. Das der Adapter grundsätzlich funktioniert wussten wir doch. Also ist auch nicht verwundertlich das er OBD-Nachrichten und Auto-Protokoll-Erkennung, etc. kann. Das mag sicher alles interessant sein, tut hier aber nichts zur Sache und bringt uns auch nicht weiter.
Du könntest mal versuchen ein alternatives Terminalprogramm (hier z.B. PComm Lite) zu verwenden. Damit kann man auch direkt die RTS-Leitung toggeln. Evtl. gibt es da beim HTerm ein Problem... aber erstmal Treiber prüfen bitte.
-
Ich habe gute Neuigkeiten. Mein TRE27 vom Tunnelrats-Electronics UK ist nahezu baugleich mit Deinem Clone. Auch der TRE27 ist letztlich ein Clone, wenn man auch sieht das die Hardware deutlich qualitativer ist. Aber ich denke das ich das damit komplett nachspielen kann und Dich nicht immer bitten muss. Vor allem habe ich das gesamte Messequipment um zu testen ob und wie das funktioniert. Muss also nichtmal meinen Hobbyraum verlassen dafür.
-
Im Anhang deine gewünschten Treiber Bilder.
Prima, jetzt wissen das scheinbar ein Original FTDI-Treiber installiert ist. Das ist schonmal nicht schlecht, denn der Treiber ist wirklich sehr gut.
-
So, zwei Dinge habe ich mir noch angesehen.
Ich habe einen Seriellen Port Sniffer installiert. Mit einem Terminalprogramm sieht man auch prima, das und welche Befehle gesendet werden.Mit FORScan sieht man auch, das der KEINE Befehle an die serielle Schnittstelle sendet. Absolut null, nichts.
Ob der das Teil direkt ansprechen kann, ohne das der Sniffer was mitbekommt ? Ich denke, davon können wir wohl ausgehen.
Auch das ELMConfig zeigt keinerlei Aktivität auf der Schnittstelle. Also nichts, was man Loggen könnte.
Interessant. Welchen Sniffer verwendest Du und wie hast Du den eingerichtet? Der muss ja schon auf den richtigen Port horchen.
ForScan und ELMConfig nutzen nur die Systemtreiber. Ansonsten müssten sie eigene USB-Treiber haben, davon ist nicht auszugehen. Hey, Du bist doch der Programmierer hier, müsstest Du doch alles wissen
Ich untersuche gerade den TRE27 und seine Funktion. Werde jetzt erstmal den RTS-Pin vom FTDI messen ob der mit dem Button von HTerm toggelt.
-
Snifer ist der Serial Port Monitor in der 14 Tage kostenlos Version.
Einrichten muß man da nicht viel, nur Schnittstelle und Baudrate angeben.
Tja, warum der ForScan mit dem ELM327 kommunizieren kann, ohne das der Sniffer das sieht ?
Das sollte nicht das Problem sein. ForScan bzw jedes Programm kann durchaus eine Schnittstelle direkt ansprechen, ohne die Treiber zu nutzen.
Das hat den Vorteil, das man die Fehlerquelle TREIBER ausschließen kann und man mit mehr Geschwindigkeit arbeiten kann, falls der Treiber zu langsam sein sollte.
Das an der Schnittstelle ein ELM327 hängt, der einen definierten Befehlssatz hat, darf man wohl als sicher annehmen, also kann ich den auch einfach so direkt ansprechen.
Seit Windows 7 sind meine Zeiten, wo ich mit Seriellen Schnittstellen gearbeitet habe, eigentlich vorbei, weshalb es da auch diverse Wissenslücken geben kann und wird.
Ob dieser FoCCCus Scan mit meinem Mondeo zusammen arbeitet, habe ich jetzt mal nicht ausprobiert. Der kommuniziert ja offen mit der Schnittstelle und da kann man alles sehen, aber das habe ich oben ja schon gezeigt, was da abgeht.
Ich frage mich langsam, ob es eventuell an meinem Mondeo liegt, das er die Befehle nicht auf die Uhr anwendet.
Du sagtest mal, das man testweise auch einfach mal die Blinker blinken lassen könne.
Magst Du mir mal den Befehl dazu geben ? Dann wissen wir zumindest, ob die bisherigen Befehle funktionieren.
Oder gibt es ein anderes Gerät, mit dem ich mal versuchen kann, zu kommunizieren, ohne das man Schaden anrichten kann, wenn was schief geht.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!