Uhrzeit einstellen ohne original Radio ?

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.

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

Ne, so schnell geben wir nicht auf, jetzt wo wir doch bereits einen deutlichen Erkenntnisgewinn erlangt haben.

Und anscheinend hast Du Blut geleckt was den CAN angeht Das was ich im Wiki z.B. über die Uhrzeit geschrieben habe war nur eines von vielen vielen CAN Decodings die ich durch geführt habe. Dazu kannst Du einiges lesen hier im Forum und im Wiki. Gern beantworte ich auch Deine konkreten Fragen, aber damit würden wir das Thema hier etwas zu sehr dehnen.

Okay, ich denke ich habs nun!

Versuche das, sollte die Uhrzeit auf 17:00 Uhr stellen:

ATZ
ATAL
ATCAF0
ATV1
ATBI
ATSH 100
STP 53
00 01 00 00 11 00 00 00
00 00 00 00 11 00 00 00

Hat bei mir geklappt. Erklärung dazu liefere ich morgen.

Danke für Dein Durchhaltevermögen, es war mir eine Ehre

Und nun, für die wissbegierigen unter uns, die vollständige Erklärung dazu:

Der CM327 ist quasi baugleich mit dem TRE27 und ELS27. Allen gemein ist das diese aus demselben Schaltplan entspringen. Die Adapter-Hersteller machen sich da nämlich herzlich wenig Mühe mit und übernehmen meist 1:1 die Anwendungsbeispiele aus den Datenblättern der Hersteller. So entstehen zig Lieferranten von ELM327-Clones, wie auch unsere o.g.

Als man den ELM327 für Ford adaptierte war schnell der Wunsch den manuellen Umschalter für MS-CAN weg zu bekommen. Hieraus entstanden dann die bereits gezeigten "Huckepack-Platinen", mit denen ein Relais (oder IC) über das RTS-Signal des UART-Chips geschaltet wurde:

Der UART wandelt einen Seriellen-Eingansstrom (meist USB, aber durchaus auch RS232, Bluetooth or WiFi) in für den Prozessor verträgliche Signalpegel. Der UART ist ein separater und nicht im IC dem Prozessor enthalten. Davon gibt es diverse Vertreter wie den CP2102, den CH340 und natürlich den Platzhirsch FT232 von FTDI. Letzterer steht für Qualität und Spezifikationstreue, ist aber auch sehr teuer und daher nicht in den Billig-Adaptern zu finden und wenn, ist es eine Raubkopie.

Das Ansteuersignal für den Umschalter wurde dann kurzerhand aus einem der Nebensignale für die serielle Übertragung gewonnen. Aus den Urzeiten benötigte man für eine sichere Übertragung noch zusätzliche Handshake-Signale wie RTS (Ready-To-Send) und DTR (Data-Terminal-Ready), welche man per Software auf 0 oder 1 stellen konnte

Einen so nachgerüsteten ELM327 konnte man dann ab einer bestimmten Version z.B. mittels ForScan ansteuern. Die war in der Lage die Existenz des Umschalters automatisch zu erkennen, oder man stelle sie entsprechend ein, wie hier zu sehen an der Option "RTS relay":

Nun haben wir ewig versucht das unsere o.g. Adapter (eben keine ELM327) darauf irgendwie reagieren. Haben sie aber nicht. Es war grad so also hätte das setzen/rücksetzen von RTS überhaupt keinen Effekt. Also habe ich meinen TRE27 geöffnet, eine Messleitung an den Pin 3 vom FTDI-UART und GND gelötet und gesehen das HTerm, welches wir zur Übertragung nutzten, das Signal mittels dem im HTerm vorhandenen "RTS"-Button einwandfrei ansteuern konnte. Auf meinem Adapter war der Pin 3 jedoch nirgendwo hin geführt und konnte somit keine Funktion erfüllen.

Also fing ich nochmal an zu recherchieren und bin darauf gestossen das es neben dem ELM327 noch einen weiteren, bermühmten Chip gibt, der ebenso äufig und gern kopiert wurde, der STN1110. Der macht im Grunde das gleiche wie der ELM, hat nur ein anderes Protokoll und wird von anderen Programmen unterstützt. Aber ForScan hat ebenso eine STN-Unterstützung. Nun habe ich mir, aus reinier Neugier mal das Datenblatt von diesem Chip besorgt und durchgearbeitet und bin darüber auf den STN1170 gekommen: https://www.obdsol.com/solutions/chips/stn1170/ Die Suche danach brachte mir Platinen die unserer verdächtig ähnlich sahen, also habe ich mir dessen Datenblatt vorgenommen und siehe da, das Schaltbeispiel passte zu meinen Erwartungen. For allem die Beschreibung "Medium Speed CAN (MS-CAN) – Ford proprietary network" erweckte großes Interesse

Darin fand ich auch die Infos zum umschalten des CAN-Bus und das dieses eben nicht mittels RTS gemacht wird, sondern mit STP. Wenn man einen solchen Adapter and z.B. ForScan betreibt, dann meldet der sich nicht mit ELM oder STN im Init-String, bzw. ForScan testet ob bei STI (das Gegenstück zu ATZ oder ATWS) eine ensprechende Rückmeldung kommt. Und wenn ja, dann kommuniziert es mit dem Adapter ganz anders.

Unsere Adapter enthalten also sowohl einen ELM als auch einen STN Befehlssatz, sind quasi zwei Adapter in einem. Aber nur mit den STN-Befehlen lässt sich der MS-CAN ansprechen.

Der Rest war einfach. Mittels eines CAN-Sniffers und meines Labor-CAN konnte ich schnell erkennen das er nun sauber auf MS-CAN sendet.

Puh, lange Geschichte für eine anfangs triviale Aufgabe. Aber der Erkenntnisgewinn ist dafür um so höher

Sehr gern, aber man muss das Rad nicht neu erfinden da es schon wirklich ne Menge guter Programme gibt. Was aber immer hilfreich wäre ist eine entsprechend Engine, also die Grundstruktur dafür um basierend darauf eben "großartige Dinge" (jetzt kling ich schon wie Trump) tun zu können. Will sagen: Die Basisarbeit ist eine stabile und saubere Kommunikation mit dem Adapter zu schaffen und ggf. Adapterspezifische Dinge dahinter zu abstrahieren. Also ne Art HAL für OBD-Adapter. Das interne Objekt besitzt dann Methoden um z.B. einfach eine beliebige Bytefolge an einen beliebigen Bus zu senden. Das wiederrum könnte man mit einer übergeordneten Flußsteuerung versehen um z.B. auch echte Kommunikationen und Datenströme zu verarbeiten.

Auf diese Methoden können dann GUI-Felder verbunden werden um Eigenschaften zu setzen und Methoden auszulösen.

Das ganze ist schon ne Menge Arbeit wenn man es richtig macht und es empfiehlt sich ein Github Projekt dafür anzulegen. Ich habe das mal begonnen in PHP und dann in Python, aber ehrlicherweise ist gerade wegen dem Lowlevel Treiber Zeugs C++ eher geeignet dafür. Gaaanz früher auf dem Mac habe ich viel für unsere Firma in RealBasic programmiert. Wenn ich mir das heute so ansehe kommt mir da aber nur ein kalter Schauer über den Rücken, das ist wie VisualBasic echt keine Sprache für mich. Das schöne war der Visual GUI Builder, das gabs damals nicht so oft in der Qualität.

Will sagen, wenn Du da Ambitionen und Zeit für hast würde ich mich freuen das Grundgerüst mit Dir definieren zu können.

Viele Themen, ich versuch mal in Deiner Reihenfolge drauf zu antworten:

1.) OBD-Framework

Aus meiner Sicht muss die Kommunikation mit dem Adapter intern über einen Treiber laufen. Dieser übersetzt den Programmbefehl in einen Adapter-Befehl. Z.B. wenn ein ELM327 angeschlossen ist den Programmbefehl "Setze Baudrate auf 125 KBaud und aktiviere den MS-CAN Bus" zu "RTS ON + ATSPB". Und wenn ein STN11xx angeschlossen ist dann eben in "STP 53".

Die eigentliche Übermittlung der Daten sollte asynchron als Hintergrundprozess laufen. Ebenso und auch unabhängig davon der Empfang von Daten und Rückmeldungen. Dazu zählt auch das möglicherweise fragmentieren und defragmentieren von größeren Datenströmen. Die Kommunikationsschicht setzt dann alles richtig zusammen.

Aber je stabiler und besser die Schnittstelle intern definiert ist desto leichter lassen sich Higherlevel Services darauf aufschalten. Und bloß eine weitere Terminalemulation braucht echt keiner. Wenn dann reden wir direkt über ELM/STN Befehle. Logging, Tracing, Record und Playback natürlich eingeschlossen. Und wenn man ganz cool ist erweitert man diese Funktionen um externe Dateien und kann somit auch Skripte ausführen. Bis hier hin ist es schonmal ganz schön viel Arbeit.

Somit stellt sich dann auch nicht die Frage was man damit alles anfangen könnte, denn das ergibt sich dann von ganz allein

2.) Wenn Du noch nie eine App entwickelt hast ist dieses Projekt eine Nummer zu groß. Ich schätze Du brauchst ca. 1-2 Jahre bis Du darin einigermaßen fit bist. Abgesehen davon musst Du für Apps auch einiges an Geld in die Hand nehmen, sonst kannst Du die hinterher bestenfalls auf gerooteten Geräten installieren. Diese Idee würde ich erstmal zurückstellen. Mit was programmierst Du denn jetzt gerade und auf welcher Plattform? Hast Du eine Entwicklerlizenz bei Microsoft und kannst somit auch signierte Programme erstellen?

3.) Zum Sniffer

Mir erklärt sich das nur dann, wenn Du dem Sniffer einen Filter verpasst hast und wirklich nur nach "AT" suchtest. Denn dann ist der Grund das ForScan einfach gleich erkannt hat das es sich nicht um einen ELM sondern einen STN handelte und mit diesem ausschließlich mit "ST" Kommandos gearbeitet hat. Eine andere Erklärung könnte natürlich sein das der ForScan garnicht auf den virtuellen COM-Port connected, sondern über die Geräteliste von Windows gleich den Adapter erkennt und sich über die Windows-API dort anbindet. In dem Fall bekämst Du auch bei einem Sniffer ohne Filter nichts mit.

4.) Zur Baudrate

Mein TRE27 war auf 2 MBaud eingestellt. War garnicht so einfach erstmal ein Terminalprogramm zu finden bei dem man das auswählen kann! Bei den meisten ist bei 115200 Baud schluß, spätestens jedoch bei 900irgendwas. Für die Baudrate gibt es einen Default und ein AT/ST Kommando um diese zu ändern. Den Default kann man ebenfalls ändern (sieh "AT PP ...") und auch dauerhaft speichern. Bei direkt Zugriff über die API vom Treiber muss man sich aber über Baudraten keine Gedanken machen

5.) Gefahrlos am CAN-Bus spielen...

Na, das ist schlichtweg nicht drin. Der CAN ist kein Spielplatz und auch kein Internet. Dort ist alles auf die reine Aufgabe designed. Da reicht schon ein falsch angeschlossener Adapter und Du hast nur noch "Motorstörung" im Display blinken. Das einzige was gefahrlos geht ist Read-Only lauschen und sich ggf. selbst irgendwelche Aktionen oder Darstellungen von den gelesenen Werten zu machen. Eine Liste oder gar irgendwelche Unterlagen vom Hersteller gibt es nicht, ausser Du machst sie dir selbst. Die hüten die Hersteller wie ihren Augapfel.

Senden würde ich jedem erst dann empfehlen wenn er genau weiss was er da tut. Das hat auch noch ein weiteres Problem zur Folge, das man aber nur versteht wenn man die Basics von CAN kennt was ich jedem, auch Dir nur dringend ans Herz legen kann. Ein CAN-Bus wird ganz anders verwendet wie z.B. ein Computernetzwerk. Hier mal exclusiv ein Mini-Exkurs für Dich ins Thema:

• Auf dem CAN gibt es keine Empfänger oder Senderadressen, der CAN ist Nachrichtenorientiert.
• Die Zuordnung, welches Steuermodul auf welchem Bus welche IDs sendet ist rein vom Hersteller bestimmt.
• Der CAN arbeitet nach dem CSMA/CA Verfahren, er vermeidet also Bus-Kollisionen durch geeignete Methoden in der Hardware
• Jede Nachricht hat eine ID (die CAN-ID) und Nutzdaten.
• Im Mondeo MK4 arbeiten wir nur mit dem Standard-CAN, also 11-Bit CAN-ID und max. 8 Byte variable Nutzlast (DLC kontrolliert).
• Die ID, der Inhalt und Aufbau der Nachricht ist grundsätzlich frei definierbar, außer man verwendet eine bereits festgelegte Definition wie eine der zahlreichen ISO-Protokolle.
• CAN-Botschaften werden oft periodisch gesendet auch wenn sich deren Inhalt nicht ändert. Die Periode orientiert sich an der Wichtigkeit und Änderungsfähigkeit der Nachricht. Hintergrund dabei ist das damit auch eine Präsenz angezeigt wird und andere Module entsprechend darauf reagieren können. Die Periode liegt beim Mondeo zwischen 10 ms und 1000 ms. Es gibt einige wenige, bei einem bestimmten Ereignis nur einmalig auftrentende CAN-Botschaften.
• Versucht man also eine Nachricht mit einer ID zu senden die bereits von einem anderen Modul periodisch gesendet wird ist es sehr wahrscheinlich das Kollisionen entstehen und die eigenen Daten dadurch nicht empfangen werden. Bzw. das Empfänger die Daten verwerfen weil sie gleich danach wieder von einer Original-Nachricht überschrieben werden. Oder sich ein Modul abschaltet weil es ständig sich unplausibel ändernde Werte erhält. Auch gibt es Module die Änderungen nur sehr langsam aufnehmen (Integral) wie z.B. die Außentemperatur.
• Es ist also nicht nur notwendig die IDs und die Bedeutung ihrer Daten zu kennen, sondern auch wie diese von den Steuergeräten verarbeitet werden und welche Wechselwirkungen sich daraus ergeben.

6.) Aktivieren von Funktionen (Start/Stop, Standheizung)

Das ist alles andere als einfach. Denn hier ist es nicht mit einem senden einer einzelnen CAN-Botschaft getan. Letztlich sind beide genannten Dinge Änderungen in der Fahrzeugkonfiguration. Um diese Änderung durchzuführen ist eine UDS-Sitzung (Programmier-Sitzung) notwendig, inkl. einer Software die auf das Steuergerät geladen wird und die Änderungen übernimmt und ausführt (2nd Stage Bootloader). Das ist kein Kindergeburtstag sondern da muss man sich schon echt gut auskennen. Allein erstmal den Seed-Key Schutz knacken um überhaupt eine solche Kommunikation aufzubauen. Dann die ganzen Interna von Ford zu kennen, denn die UDS-Befehle sind nur zum Teil genormt, jeder Hersteller macht da so sein eigen Ding.

So ganz ohne Konzept einfach mal so drauf losprogrammieren halte ich für den denkbar schlechtesten Ansatz. Du bist doch Programmierer? Hast das womöglich sogar gelernt? Und das was Du da schreibst ist ganz klar ein Anti-Pattern für mich und da prophezeihe ich Dir jetzt schon das Du nicht weit kommen wirst und zwischendurch ein paarmal von vorn anfangen musst...

Damit will ich Dich nicht demotivieren, nur helfen, denn ich fürchte Du unterschätzt die Komplexität der Sache noch.