Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenIch kann zwar am FDTI den Pegelwechsel beim anklicken von "RTS" im HTerm messen, aber bei meinem Board nicht erkennen wohin der geht, bzw. ob er überhaupt genutzt wird. Wie auch immer, er sendet nur auf dem HS-CAN Port, egal welche Baudrate/Protokoll, egal wie der Status von RTS ist. Das scheint sich mit Deinen Erkenntnissen zu decken, auch wenn uns das grad nicht weiterbringt.
Es gibt also noch ein Geheimnis zu lüften...
Ein gutes (naja), ich kann den "CAN ERROR" reproduzieren. Mein TRE27 sendet auch am liebsten auf HS-CAN 
Will sagen das meine Prozedur wunderbar funktioniert, solange ich "ATSP6" verwende. Dann sehe ich mit meinem CAN-Sniffer (Hardware) das Datenpaket. Sobald ich "ATSPB" nehme erhalte ich einen "CAN ERROR".
So weit sind wir jetzt auf demselben Level.
Ok, sowas dachte ich mir, aber wollte sicher gehen 
Was spricht gegen einen neuen Sattel (am besten mit Spange) ausser der Preis?
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...
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.
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
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...
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.
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
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.
