Die Treiber von FTDI sind Windows-zertifiziert. Diejenigen Treiber, die automatisch via das Netz und "Plug&Play" geladen werden, sind üblicherweise die neusten und aktuellsten Treiber für eine Hardware
Normalerweise macht das keine Probleme, denn ein aktuellerer Treiber ist gewöhnlich auch der "bessere" (warum sonst sollte man sich die Arbeit antun, einen neuen überhaupt zu entwickeln).
Normalerweise schafft ein neuer Treiber keine Probleme, sondern löst sie.
Aber offenkundig gibt es keine Regel ohne Ausnahme. mag sein der aktuelle FTDI-Treiber 2.08.xx ist so ein Kandidat. Als wir 2007 uns für FTDI entschieden haben, funktionierte die Windows-Auto-Installation über das Netz ohne Probleme. Den Treiber, den man so bekam, war der 2.04.06, und das ist der, welcher von TuneECU favorisiert wird. Das ist zufälligerweise derselbe Treiber, den auch ich auf der Kastl-Installations-CD dazu gebe.
Ich habe aber davon gehört, daß einige Kastl-Kunden die Treiber-Installation Mr.Gates und Windows überlassen haben und trotzdem hat alles funktioniert.
Egal, irgendwann bekommt FTDI die Kompatibilitätsprobleme mit einen Treiber-Update sicher in der Griff und dann gehört der Ärger der Vergangenheit an. Bis dahin nimmt man halt den "alten" Treiber für TuneECU, ist doch keine große Sache.
Ich habe so ein OBD2-Kabel bei mir am Prüfstand herum liegen, das habe ich die letzten Tage zusammen mit der aktuellen TuneECU-Software auf einer Triumph Speed Triple 1050 ausprobiert.
Das lief erstaunlich problemlos. Ich brauchte keine neuen Treiber, die bestehenden "Kastl"-Treiber in meinem Schlepp-Top reichten vollkommen, es gab sofort das vertraute USB-Ping und es installierte sich ein virtueller Com-Port im System.
Der Prozessor im OBD2-Kabel ist dabei eine ältere Version von FTDI, die aber immer noch produziert wird. Das Teil ist fix programmiert und macht nichts anderes als Daten von einem seriellen Interface in "USB" und vice versa zu "übersetzen".
Der FTDI-Chip, auf den ich setze, ist die letzte Version. Der kostet so 3-4 Dollar mehr, dafür ist ein kleinen Speicher an Board, in dem ein Buffer, ein Vorratslager, für ein- und ausgehende Datenpakete Platz findet, was die Güte der Verbindung deutlich steigert, wenn es mal zu einer Störung des Datenflusses kommt. Und so was passiert am Motorrad oft und gerne, da allein wegen der Zündung die Umgebung hier alles andere als "Elektronik-freundlich" ist.
Schaut man sich die Signale in den Leitungen an einem Motorrad mit dem Oszilloskop an, staunt man darüber, was sich da für ein Chaos abspielt. Da gibt es Spannungsspitzen von mehreren Hundert Volt (gottseidank schwach und im Milliampere-Rahmen), alles schön überlagert von der Restwelligkeit der Drehstrom-Lichtmaschine, die abhängig von der Motordrehzahl einen "Brummton" in die Elektrik schickt, nicht zu vergessen die Zündfunken, die lustig in jedes Kabel am Eisen hinein knattern.
So ein Motorrad is daher alles andere als ein idealer Ort für subtile Elektronik. Das gilt damit auch für den Daten-Transfer z.B. über eine serielle Schnittstelle, bei OBD2 z.B. So eine Datenübertragung funktioniert über zwei Leitungen im Prinzip wie Morsen, da wird ein Strom ein und ausgeschaltet, um ein Muster zu erzeugen, mit dem dann die gewünschte Message übertragen wird.
Man kann sich natürlich vorstellen, was passiert, wenn Störungenimpuls aus der Motorrad-Elektrik in dieses "Morsen" hinein funken: Das schafft dann Chaos in der Übertragung und läßt die Kommunikation oft und gerne zusammenbrechen.
Obwohl der neueste DTDI-Chip eigentlich mit seinem Buffer oder Datenspeicher, sowie seiner internen Programmlogik eigentlich genau solche Störungen in der Datenübertragung verhindern soll, hatte ich immer wieder in der Vergangenheit mit diesem Problem zu kämpfen: Verbindung abgerissen, keine Kommunikation, gerade wenn das Motorrad auf dem Prüfstand lief. Nicht immer und mit jedem Motorrad, aber doch mit einer gewissen Konstanz. Triumph und die Janpaner machten dabei den wenigstens Ärger, ganz schlimm war Buell und Harley, KTM war irgendwie dazwischen.
Auch ich probierte als erstes, an den Einstellungen des Com-Ports im Windows-System herumzudoktorn, um die Sache stabiler zu machen. Das half aber wenig.
Einen echten Durchbruch bei der Verbindungs-Stabilität erreiche ich aber mit diesem "Trick":
Ich legte die Motorrad-Masse, das (-) Minus z.B. am Batteriepol, über ein Zusatzkabel auf den Schutzleiter in der Steckdose, die zwei Bügel oben und unten, welch an den dritten, gelb/grünen Draht angeschlossen sind und wirklich. nicht nur bildlich, in die Erde gehen.
Der Hintergrund dabei ist folgender: Wenn ein PC oder Laptop mit einem Motorrad über eine Kommunikationsleitung zusammengeschlossen werden, treffen zwei autonome elektrische Systeme aufeinander, der PC, der über die allgemeine Stromversorgung, das Netz im Haus, gepowert wird und das Motorrad, das mit seiner Lichtmaschine unabhängig und selbstständig seinen eigenen Strom macht.
Damit diese zwei Strom-Welten in der Datenübertragung reibungslos zusammenkommen können, ist ein gemeinsamer Massepunkt, der vorzugsweise seinerseits auf eine echte und massive "Erde" gelegt ist, nach meinen Erfahrungen äußerst hilfreich.
Anbei ein Screenshot von dem Map der Speedy in ihrer ECU, das ich anläßlich dieser ersten Annäherung per TuneECU ausgelesen habe, unten im Anhang.
Auch die übrigen TuneECU-Funktionen wie die Diagnose arbeiteten, wie sie sollten. Auffällig war allein die lange Latenzzeit in der Datenübertragung: echtes Schneckentempo, bis z.B. eine neue Drosselklappenstellung auf dem TuneECU-Dashboard angezeigt wird. Das muß schneller gehen. Das originale KTM-Diagnose-Tool beim Händler, mit dem ich mal ausgiebig "spielen" durfte, ist in dieser Hinsicht Größenordnungen fixer als TuneECU. Mit seiner drögen Sampling-Rate macht ein Data-Loging keinen Sinn.
Auf dem Screenshot sieht man - no na - eine Tabelle, in Beispielsfall (denke ich mal) die Air/Fuel-Table. Jede "Elektronik" mit "Logik" und "Programm" zur Datenverarbeitung weist gewisse Ähnlichkeiten auf. Die Logik ist eine binäre, will heißen sie kennt nur 0 und 1. Damit die 0 und 1 - Werte nicht so lange Zahlenwürschte werden, fasst man diese Ausdrücke platzsparend oft und gern in kürzeren Hex-Zahlen zusammen. Auch Tabellen gibt es oft und gerne, schlicht weil das ein elegantes Intrument ist, um mit "Und" und "Dann" logische Verknüfungen zu erstellen, wie z.B. WENN Drehzahl "x" UND Last (=TPS- (Gas-)Stellung) "y" DANN Einspritzmenge "z".
So funktioniert das daher in allen Kastln mit einem "schlauen" Würferl drinnen mit "geheimer" digitaler Intelligenz.
Was man aber stets im Auge behalten muß, ist die Tatsache, daß so eine Tabelle für die digitale Datenverarbeitung stets auf einer Abstraktion beruht und damit eine Vereinfachung der "wirklichen" Wirklichkeit, der berühmt-berüchtigten Praxis darstellt. Im echten Leben entwickelt ein Motor seine Zugkraft nicht zonenweise in Feldern von 400-500 UpM-Sprüngen, sondern stetig, wobei der Verlauf durchaus spannend sein kann mit unterschiedlichen Minima und Maxima, mit "Ups" and "Downs" im Drehmoment.
Diese "natürliche" Dynamik der Leistungsprodukton eines Motors will durch dieses Instrument "Tabelle" erst einmal abgebildet sein. Ich sehe da nur zwei Möglichkeiten: Entweder man wählt das Raster in der Tabelle hinreichend fein mit Stütz-(Referenz-)Punkten alle zig Umdrehungen oder man macht die Grenzen der "Felder" oder Zellen, der Drehzahl- respektive Lastbereiche selber dynamisch, also verschiebbar, um so die "wirkliche" Wirklichkeit abbilden zu können.
Aber hier soll meine "Kurvendiskussion" für heute enden, mit einer Ausnahme: In diesem Triumph-Map sehen wir 32 separate Drehzahlbereiche (oder -zellen) und 20 für die Last. Das wirkt auf den ersten Blick fein gestuft.
Sieht man jedoch genauer hin, bemerkt man, daß gut die Hälfte dieser Stützpunkte für Drehzahl- und Lastzonen "verschwendet" sind, die in der Praxis nicht vorkommen wie z.B. 800 Umdrehungen bei 2% Drosselklappenöffnung.
Die höheren Motorzustände in den Bereichen, in denen man wirklich fährt, werden dagegen vergleichsweise grob abgehandelt.
Darin sieht man, was für ein Motorsteuergerät wirklich das Schwerste ist: Den Motor anlassen und von der Ampel weg anfahren können. Das zeigt die Verteilung seiner "Aufmerksamkeit" für die Last- und Drehzahlbereiche. Wenn die Fuhre sich erst einmal bewegt, ist alles weitere dann nicht mehr so wichtig.
Ich will mit dem Gesagten in keiner Weise das Verfahren im TuneECU schlecht machen. Aber man sollte doch um seine Grenzen wissen, um das Potential dieser Methode voll auszuloten.
Hierfür werde ich gern meinen Beitrag leisten
...
