Beiträge von Go4IT

Ne, tiefer kommt da nix. Hey Leute, ich bin keine 25 mehr, ich muss aus dem Karren ja noch aussteigen können...

Danke! Ihr habt Recht, die Handbremse ist das wahrscheinlichste. Die nutze ich sooo selten, kann gut sein, das prüfe ich mal wie ihr beschrieben habt. Ansonsten könnte es ja nur der Kolben sein der nicht mehr ordentlich zurück fährt.

Kann man den Kolben unter Druck einfach wechseln ohne den Sattel auszubauen bzw. Bremsflüssigkeit zu verlieren?

Der Rep-Satz für 9€ ist ja schon spottbillig.

Achja, früher bei meinen ersten Autos habe ich den Kolben einfach mit einer Schraubzwinge "zurückgestellt". Ich weiss das das nicht empfehlenswert ist, sollte man sich einen Rücksteller kaufen? Im Grunde macht der ja auch nichts anderes...

Zitat von Rudi

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.

Zitat von Rudi

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.

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.

Als ich die neuen Räder montiert hatte und damit die paar Kilometer zum TÜV fuhr und dort noch warten musste habe ich mir die nochmal aus der Nähe angesehen. Dabei viel mir auf das das Rad auf der Fahrerseite hinten sehr warm war. Beim fahren selbst hat man jetzt so nichts weiter gemerkt, weder zog der Wagen in eine Richtung, noch quietschte es vom langsamen vor- oder rückwärtsfahren.

Später dann fuhr ich nochmal in meine Hobbywerkstatt und als ich den Wagen aufgebockt hatte sah ich schon die bläulich angelaufene Bremsscheibe. Drehen lies sich das Rad nur mit Mühe. Also erstmal runter das Ding, den Bremssattel abgeschraubt und alles mit Bremsenreiniger, Drahtbürste (ja, ich war sehr vorsichtig damit auf dem Kolben unterwegs, ist schon klar, wegen Manschetten und so) gereinigt, auch die Aussenflächen der Bremsbeläge. Dann alles wieder zusammengebaut und das Rad dreht seitdem wieder ganz normal.

Jetzt meine Frage an die Profis hier: Wie macht man richtig eine Bremse wieder gängig? Bzw. wie macht ihr das? Anders als ich es jetzt gemacht hab?

Und was könnte die Ursache sein? Die Bremsbeläge sind noch gut und haben keine Riefen. Auch nicht die Bremsscheibe. Das Handbremsseil schien leichtgängig und die Mechanik machte auf mich jetzt nicht den Eindruck als würde die irgendwo klemmen können. Trotzdem passiert sowas ja nicht einfach so.

Ist da wohl mal ein neuer Sattel fällig? (Da hätte ich ja wieder was zum basteln für meine nächste Anleitung

225er Winterreifen auf 17 Zoll Zubehörfelgen

So, die Räder sind drauf und rein optisch bin ich eigentlich auch zufrieden. Die 2x5 Speichen-Optik erinnert zumindest an die Original-Räder. Die Farbe ist eher silbergrau, passt aber ganz gut zu meinem Micastone-Silver-Metallic Lack. Ich hatte mir zwar eher voll silberne vorgestellt, so wie die Originalräder halt, aber so ist das mit Internet-Bildern...

Eintragung war eigentlich kein Problem. Eigentlich bedeutet, das die Brocks aus einem nicht erklärbaren Grund die ET nicht in die Felge eingeschlagen hatten. Dort ist nur vom Gus "ET" zu lesen. Üblicherweise wird das da wohl nachträglich mit Schlagzahlen markiert. Nicht so bei meinen Felgen und so dauert es etwas länger als geplant bis der TÜV da Gewissheit hatte. Gekostet hat der Spaß 66,- €.

Eingetragen wurde letztlich auch nichts, ich bekam halt nur eine Abnahmebestätigung. Wenn ich die Infos wirklich im Fahrzeugschein haben will, dann müsste ich nochmal zur KFZ-Stelle vom Landratsamt und mir dort einen neuen Schein austellen lassen. Der Prüfer meinte aber das das mitführen der Bescheinigung völlig ausreicht und so lasse ich das jetzt auch mal.

Die Fahreigenschaften finde ich bislang hervorragend. Ich merke praktisch keinen Unterschied zu den 17" 215/50er Sommerreifen. Der Wagen ist weder "Spuranfällig" geworden (so wie ich das mal mit den 18" 235ern hatte) noch langsamer/unagiler. Also das war anscheinend eine gute Wahl.

Soweit die guten Nachrichten...

Dann habe ich in meiner Werkstatt die Reifen (neu) auf die Felgen (neu) aufziehen lassen. Zuhause wollte ich dann am nächsten Tag die Radmuttern nachziehen und die Felgen/Reifen von den Kleberesten befreien und da hat mich ja beinahe der Schlag getroffen!

Dicke, fette Riefen an der Felgenkante auf ALLEN vier Rädern:

Man fühlt richtig das es 1-1,5mm tief ist. Da war ich dann erstmal bedient. Zumindest war die Werkstatt direkt einsichtig das hier bei der Montage wohl was schief gelaufen sei. Dort werden jetzt vier neue Felgen bestellt.

zu a) Sind ja auch pfuschneu Aber damit hatte ich leider Pech (anderer Thread)

zu b) Ja, sind ja auch Zubehörfelgen dran...

zu c) Gefällt mir persönlich einfach besser als der komplett schwarze Wabengrill... Aber wenn Dir hier schon ein Farbunterschied auffällt, dann willst Du die Seitenschweller nicht sehen...

zu d) Elender Jungspund, komm erstmal in mein Alter, dann sprechen wir uns nochmal!

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.

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.

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).

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...

Nur mal auf die Schnelle ein paar Impressionen nach der Frontspoiler-Montage. Details folgen...

Zitat von BBG-AE185

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.

Zitat von Rudi

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

Zitat von Rudi

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.

Leider hab ich kein LEG zur Verfügung, daher hatte ich mir vor dem Umbau mit Klebeband den Verlauf der Lichtkegel an die ca. 2 Meter entfernte Wand markiert und die Scheinwerfern darauf eingestellt. Ich musste relativ viel verdrehen dafür. Mal sehen, heute fahre ich in die Werkstatt weil im Oktober noch kostenlos das Licht geprüft wird. Falls das trotzdem ok ist, würde ich sie etwas niedriger stellen. So weit wie das noch erlaubt ist.

Zitat von Rudi

>atz

ELM327 v1.3a

>atws

ELM327 v1.3a

>atspb

OK

>atal

OK

>atcaf0

OK

>atv1

OK

>atbi

OK

>atr0

OK

>atsh 090

OK

>14 0a 1a 11 00 00 80 00

CAN ERROR

Das RTS war die ganze Zeit über GRÜN.

Alles anzeigen

Ich freue mich über Deinen Eifer bei der Sache, andere hätten schon längst aufgegeben!

Der oben gezeigte Ablauf sieht aber trotzdem OK aus. Der CAN ERROR kommt meines Erachtens daher das die eingestellte Baudrate mit der am Bus befindlichen nicht übereinstimmt und da wird ein solcher Fehler erkannt. Ich glaube es ist wirklich noch das Problem das wir immer noch nicht den richtigen Bus ansteuern. Vielleicht gibt es zum RTS noch eine Alternative...

Also auch wenn die Firmware "nur" eine 1.3 ist, ist der Adapter als solches durchaus nicht so schlecht. Im Vergleich mit anderen am Markt sicher einer der Besseren. Im Umfeld von ForScan und ELMConfig wird er hervorragend seine Dienste tun. Ich habe einen ähnlichen Adapter, aber nicht denselben. Vielleicht kannst Du Deinen mal aufschrauben und hochauflösende Bilder vom PCB machen, da sieht man vielleicht mehr bezüglich einer Umschaltlogik. Irgendwo am USB/Serial Wandler muss, je nach Chip ein Signal dafür abgegriffen werden:

Vielleich kann man ja nachvollziehen wo welches hin geht. Solche PCBs sind ja meist nur doppelseitig.

Ich bin inzwischen ein Stückchen schlauer. Die Umschaltung erfolgt wohl in den Adapter mit automatischen HS- /MS-CAN Umschaltung mittels des RTS-Signals. Im Gehäuse sitzt dann ein kleines 2xUM Relais welches über eine Transistorstufe oder ein Monoflop angesteuert wird:

Den Zustand des RTS-Signals kannst Du im HTerm ganz einfach über einen Toggle-Switch ändern:

Im Ruhezustand läge der CAN-Ausgang an 6+14 vom OBD-Port, was HS-CAN entspricht. Auch würde es meiner Vorstellung entsprechen wie es sein sollte

D.H. da Du die ganze Zeit ohne RTS gesendet hast, ging alles auf den HS-CAN Bus und damit ist klar das nichts von dem hat funktionieren können.

Wenn Du also jetzt die Daten sendest (erst dann ist es relevant, aber setzen kannst Du es gleich von Anfang an), dann mit aktivem RTS, dann sollte das auf den MS-CAN gehen und auch Wirkung zeigen.