Autor Thema: OBD Schnittstelle auslesen  (Gelesen 216302 mal)

0 Mitglieder und 1 Gast betrachten dieses Thema.

Offline UweH

  • Duster Junior
  • **
  • Beiträge: 213
  • ich mag's offroad
Re:OBD Schnittstelle auslesen
« Antwort #15 am: 20. November 2010, 19:50:47 »
Nach kleiner Pause vom Testen zurück...

Seit Montag 15.11. habe ich wiederholt die ScanMaster-ELMScan Software V2.1 (Build 802) getestet, indem ich verschiedene Echtzeitdaten ausgelesen habe. Soweit ich das beurteilen kann, sind die ausgelesenen Betriebsdaten bei Verwendung der USB- Schnittstelle bei fast allen Funktionen realistisch  :daumen leider bis auf den Echtzeitwert der Duster Diesel- Betriebsstoff- Verbrauchsanzeige.  /mies
Diese Werte liegen etwa doppelt so hoch, wie die längerfristig gemittelten Werte, die man in der ECU- Anzeige direkt im Fahrzeug ausliest. Bei moderater Drehzahl im 5. Gang liefert ELMScan 10 bis 12 L/100km als Istwert statt etwa 6L/100km.

Auf Email- Anfrage bei WGSoft wurde mir bestätigt, dass
“...bei Turbodiesel ist es leider technisch nicht möglich den richtigen Verbrauch zu ermitteln, da nicht ausreichend Daten über die OBD-2 Schnittstelle zur Verfügung gestellt werden. Solange der Turbolader nicht läuft, sollten die Angezeigten Daten in etwa stimmen...“
Details dazu findet man in diesem Forum HIER


Weitaus mehr Probleme zeigen sich beim Auslesen der Echtzeitdaten im WLAN- Betrieb mit meinem Netbook HP 2133 über die Ethernet 10/100 Mbit/s Schnittstelle.  /nachdenk
Die Funktionen „Verbinden“, „Fahrzeugdaten“, „Systemzustand“, „Fehlercodes“ verhalten sich völlig normal.  :daumen
Unter „Echtzeitdaten“ tritt folgendes Problem auf: startet man „Lesen“, und will das zyklische Auslesen aller verfügbaren Sensoren wieder stoppen, reagiert das Programm nicht sofort auf „Stopp“. Minutenlang werden weiter Daten gelesen. Der gelbe Statuspfeil rotiert schnell zwischen den einzelnen, gewählten PID’s.
Zwischenzeitlich reagiert das Programm auf keinerlei Eingriffe. Wartet man geduldig, stoppt das Programm erst Minuten später.
Das gleiche Verhalten tritt im Menuteil „Echtzeitdaten einzeln“ in numerischer Großwertanzeige auf, es erscheinen zwar die unter den numerischen Daten symbolisierten Min-/Maxwert- Balkenanzeigen aber es fehlen die numerischen Werte. Auch hier keine unmittelbare Reaktion auf „Stopp“.
Unter dem Menuteil „Echtzeitdaten grafisch“ erscheinen keine Kurvenverläufe über der Zeitachse und es fehlen in kleinen Ziffern oben links in den einzelnen Diagrammfenstern die numerischen Werte. Auch hier keine unmittelbare Reaktion auf „Stopp“ des Programms.
Auch der Versuch nur einen einzelnen Wert auszulesen und grafisch anzuzeigen, bringt keinen Erfolg in der Anzeige - numerischer oder grafischer Art.  /haeh
Ähnlich fehlerhaftes Verhalten unter WLAN- Betrieb ergibt sich auch bei Verwendung der Zusatzanzeigen „Tachometer Instrumentenanzeige“ und „Verbrauchsanzeige“. Es fehlen die Werteangaben. Das ganze Programm scheint sich durch den Zugriff auf die Schnittstelle des Netbooks selbst zu blockieren - stürzt aber nicht ab.  ;)
Diese Tests habe ich letzte KW ausgiebig wiederholt, nachdem ich die Konfigurationsdaten der WLAN Schnittstelle hin und her geändert habe. (Wichtig ist die richtige IP und Portadresse im Programm und in der WLAN- Schnittstellen- Konfiguration). Immer das gleiche Fehlverhalten in den beschriebenen Programmteilen.  /wand2
WGSoft kommentiert dies sinngemäß so, dass es wohl sicher an dem Netbook läge. Ist ja möglich.   /idee Nächste KW nehme ich einen „normalen“ Laptop vom Kollegen und teste erneut.
Aber jetzt aufgepasst:
es wundert mich doch sehr,  /nachdenk dass trotz der Probleme unter WLAN ausgerechnet der Motorleistungstest des Programms funktioniert. Hierzu müssen Drehzahl und Geschwindigkeit sensorisch ausgelesen werden. Damit der Datenfluss nicht unnötig ausgebremst wird, habe ich alle nicht benötigten Sensordaten unter dem Menüpunkt „PID Konfiguration“ zum Auslesen deaktiviert.  /cool
Für den Test benötigt man unbedingt einen Beifahrer und eine gewisse Fahrtechnik  /fahren
(falls Vollgasgeben ab der gesetzten Drehzahluntergrenze als Technik bezeichnet werden kann...). Nicht zu vergessen eine leere, abseits gelegene Piste (besser eine private Teststrecke).

Die Auswertung des Leistungstests (4. Gang ausführlich und 1 Grafik 3. Gang, mehr war auf der Piste nicht machbar) anhand von Fotos vom Bildschirm füge ich ein.  /winke

Die rechnerisch ermittelten Beschleunigungs- und Drehmoment- und Leistung- Kurven verlaufen etwas unruhig im Vergleich zur schön glatt gemessenen Drehzahlkurve, die etwa in der Qualität ist, wie die Beispielplots im Manual der Software. Es wurden wie schon geschrieben nur 2 relevante Echtzeitdaten (Geschwindigkeit und Drehzahl) ausgelesen und alle anderen PID’s deaktiviert. Woher kommt das "Gezappel"...  /haeh

WGSoft kommentiert auf meine Emailanfrage hin, dass die Unruhe in den Daten vermutlich durch eine verzögerte Bereitstellung der Daten von der ECU in den Zugriffsspeicher verursacht werden und dass bei aktuellen Steuereinheiten die Daten kontinuierlicher verlaufen sollen.
Mir ist leider auch noch nicht klar, wie viele Daten pro Sekunde geliefert werden und welcher Systemtakt maßgeblich ist - der meines Rechners oder der Zeittakt der ECU des Fahrzeugs.

Das Ergebnis mehrerer Test mit meinem 4x4 Duster (im Automode) und einem Vergleichswagen (Subaru Impreza 2.0D, Permanentallrad) ist unabhängig davon, ob die USB- oder die WLAN- Schnittstelle verwendet wird. Damit ist dieser Programmteil (der mir sehr wichtig war) voll funktionsfähig.  :klatsch

Eine Email- Anfrage an WGSoft bezüglich der Kurvenglättung ergab, dass man in einer Update- Version dem Anwender einen wählbaren Glättungsfaktor in diesen Programmteil einarbeitet.  :daumen Eine von mir vorgeschlagene Möglichkeit zum Datenexport (um mit eigener Mathematik nachzuglätten, Kurven- Fits einzuarbeiten usw.) kann/soll nicht erfolgen. Vermutlich möchte man eine gewisse „Distanz“ zur Profi- Software wahren.  /rotwerd
Bei einem Preis von ca. 75 Euro ist die Software m. E. trotz der noch bestehenden Probleme im WLAN- Betrieb (an meinem Netbook) erstaunlich umfangreich und leicht zu bedienen. Es gibt zusätzlich noch ausgabefähige Berichtsprotokolle.

Ich bedanke mich an dieser Stalle für den schnellen Support von WGSoft. Die Antworten kamen nach ein bis wenigen Stunden sehr zeitnah.

...sollte ich mich jetzt ev. als Beta- Tester fühlen...  /nachdenk (Erscheinungsdatum der Software 08.11.2010, bestellt von mir am 11.11., geliefert am 13.11. und getestet ab dem14.11.2010)

Falls jemand auch diese Software nutzt, bitte melden!

Gruß UweH


 

Offline UweH

  • Duster Junior
  • **
  • Beiträge: 213
  • ich mag's offroad
Re:OBD Schnittstelle auslesen
« Antwort #16 am: 15. Dezember 2010, 21:42:05 »
Hallo OBD-Interessierte,

habe in den letzten 2 Wochen mit der Software ScanMaster-Elm neue Daten aufgenommen. Zunächst konnte ich WGSoft davon überzeugen, dass das Problem mit der Datenaufnahme im WLAN- Betrieb weder am Steuergerät noch an meinem Netbook liegt.  /nene
Hierzu habe ich mit einem Arbeitskollegen parallel an seinem neuen Subaru und wechselweise auch mit seinem Labtop getestet und herausgefunden, dass die Prozessoren beider Rechner im WLAN- Betrieb am Limit von 100%  ??? arbeiteten, was auf einen Softwarefehler deutete.

WGSoft hat auf meine Benachrichtigung reagiert und nachgebessert und wenige Tage später ein neues Update (Vers 2.1, Build 815) am 03.12.10 zur Verfügung gestellt.  :daumen
Des Weiteren wurde meiner Anfrage entsprochen, unter dem Programmteil „Leistung“ (Messung der Drehzahl und Geschwindigkeit und Errechnung der Beschleunigung, des Motordrehmoments und der Motorleistung im jeweiligen Gang) einen Glättungsfaktor in diesen Programmteil einzufügen, um den ermittelten Kurven einen glatten Verlauf zu geben.   :daumen Der Bitte, einen Datenexport der berechneten Kurven aus diesem Programmteil zuzulassen, wurde hingegen nicht entsprochen.

Damit war nun auch der WLAN- Betrieb der Software voll funktionsfähig. Dieser Punkt war mir wichtig, damit im Fahrzeug auf das USB- Kabel verzichtet werden kann und beim Test das komplette OBD- Interface im Handschuhfach verschwindet und das Fach geschlossen ist. Die Bluetooth- Version kam nicht in Frage, weil diese Schnittstelle mein GPS- Handy am Netbook belegt.

Nun konnte ich mich endlich mal dem Erfassen von Messdaten beschäftigen (weniger mit dem Auslesen von Fehler- Codes, es gibt ja keine bei meinem Duster...). Die ersten Tests der Leistungsberechnung und den daraus durch die Software berechneten Kurven (siehe Bild 1) schienen mir ziemlich verspratzelt. Aus diesem Grund habe ich mal alternativ den Programmteil „Echtzeitdaten grafisch“ eingesetzt und Daten zur eigenen Leistungsberechnung aufgenommen.

Die erfassten Daten können zwar in diesem Programmteil grafisch mitgeschrieben und abschnittsweise angesehen werden, was aber jetzt mal außer Acht bleiben soll. Wichtig ist: nur (oder besser immerhin) kann man aus diesem Programmteil die Rohdaten speichern und zusätzlich lassen sich die Daten unter „Export“ auch in einem ASCII- Format (Text und Zahlen in Matrixform) ausgeben, was letztlich für die weitere Berechnung grundlegend ist.

Aber: wie vor 30 Jahren... bleibt es einem nicht erspart diese Daten zu formatieren, wenn man sie in mathematischen Programmen nutzen möchte. Mit Uhrzeit im Text- Format “hh:mm:ss.ddd“ und Text im Format “xxx“ in so genannten Gänsefüßchen eingestellt, kann man schlecht bis gar nicht rechnen. Daher muss man eine Strategie ersinnen und anwenden, die Daten mit Hilfe anderer Programme wie Excel oder dem Windows Editor in ein Zahlen- Format zu bringen.

Nach dieser Hürde erblickt am nun in mathematisch orientierten Programmen z. B. im MathCad erstmals eine Daten- Matrix (siehe eine Ausschnitt weniger Zeilen in Bild 2). In den ersten Spalten #0 bis #2 steht die Tageszeit in Stunden, Minuten und Dezimalsekunden (millisekundengenau). Das ist die ECU- Systemzeit, die als Zeitstempel jedem ausgelesenem Sensorwert zugehörig ist. Man erkennt, dass in diesem Fall, wenn man nur zwei Sensoren (Drehzahl und Geschwindigkeit) ausliest, das Zeitintervall etwa 110 ms pro Datenwert in einer Spalte #3 oder #7 also pro Sensor beträgt und etwa 55 ms immer zyklisch zwischen zwei Sensoren.

Mit Schrecken sah ich erstmals, dass die Geschwindigkeit nur als Integer also ohne Dezimalwerte   /haeh vorliegen. In einem Listing (Wikipedia, siehe hier) aller nach Norm bereitgestellten allgemein zugänglichen Sensordaten (Standard PIDs) musste ich mich davon überzeugen, dass dem wirklich so ist.

Damit wurde langsam klar, dass die Kurvenqualität ohne Kurvenglättung noch schlimmer aussieht als im Bild 1, denn hier ist schon ein Festwert für eine Glättung angewendet. Wie in der Daten- Matrix in Spalte #7 zu sehen ist, sind mehrere Folgewerte im Sekundenintervall 30 s bis 31.1 s gleichwertig, weil die Dezimalstellen fehlen. Das beeinflusst natürlich die weitere Rechnung entscheidend.

Will man das Drehmoment berechnen, benötigt man die Beschleunigungswerte. Diese folgen aus der Differentialrechnung der Geschwindigkeit nach der Zeit und da man hier nur numerische Datensätze hat, muss man sich mit den Berechnungen der Differenzquotienten begnügen, d. h. man bildet die Differenz zweier Geschwindigkeitswerte und dividiert diese durch die Differenz zweier dazugehörender Zeitwerte und das nudelt man durch über den gesamten Datensatz. Sind jedoch zwei Geschwindigkeitswerte gleich, dann ergibt die Differenz Null und wie alle wissen Null dividiert durch ein Zeitintervall bleibt Null. Daher folgen in den Kurven wilde Sprünge zwischen Null und manchmal sinnvollen Werten (siehe Bild 3, ohne Glättung).

So grob, so schlecht... will man es feiner, muss man sich die Datenanpassung der Geschwindigkeitswerte mal genauer ansehen. Dazu greife ich jetzt auf Rohdaten zurück, die ich in gleicher Weise erzeugt habe wie die Daten im Leistungstest, jetzt aber als Aufnahme in Form von Echtzeitdaten. Den Duster beschleunige ich wie gewohnt in einem Gang z. B. den Vierten von einer bestimmten Drehzahl (1500 Upm) ausgehend mit „Bleifuß“ bis zur maximalen Drehzahl (z. B. 3500 Upm).

Zur eigenen Berechnung der Leistung und des Drehmoments gebe ich die gespeicherten und formatierten Daten (siehe Tabelle von Bild 2) an ein Programm namens MathCad. Zur Glättung wendet man auf den Datensatz fertige Routinen an, die so vertraute Namen haben wie STRGLTT, was so viel heißt wie abschnittsweise Anpassung durch Minimierung der Fehlerquadratsumme oder kurz „least squares fit”.

Jetzt kann man sich erst mal in Ruhe  /rauchen die Glättung der Daten in einem kleinen Zeitintervall ansehen. Im Diagramm von Bild 4 sind die Geschwindigkeits- Rohwerte in den roten Punkten und die Fit- Kurve in blau eingetragen. Im Vergleich dazu sieht man an den Drehzahl- Rohdaten (schw. Datenpunkte), dass sie auf Anhieb besser an der Fitkurve der Geschwindigkeit anliegen, da sie mit Dezimalen in 0.25 Schritten ausgelesen werden (siehe auch Bild 2, Tabelle Spalte #3).

Das Resultat der berechneten Kurvenverläufe der Beschleunigung (rote Kurve in Bild 5) und des Drehmoments sowie der Motorleistung (Bild 6) nach diesem kleinen Kunstgriff der Datenglättung ist dann doch versöhnlich anzusehen. Bei der Datenaufnahme war der Motor nicht betriebswarm und die Formel zur Berechnung des Motordrehmoments, die ich noch verbessern muss,  ist noch nicht genau formuliert. Das folgt nun in den nächsten Tagen. Im Vergleich zum Programm von WGSoft ist der qualitative Verlauf meiner berechneten Kurven mit Bild 7 vergleichbar, in dem nun der frei wählbare Glättungsfaktor gesetzt auf den Maximalwert gesetzt ist (vergleiche mit Bild 1).

Demnächst werde ich noch die von mir im MathCad verwendete Formel des Raddrehmoments genauer formulieren.  /nachdenk
Des Weitern muss ich die Testbedingungen ändern und wohl eine höhere Drehzahl so bis 4000 Upm ausfahren, damit die Kurven noch mehr über die Maxima von Motordrehmoment und –Motorleistung auslaufen.

Aber dazu mehr im nächsten Beitrag.  /winke

Gruß UweH

 

DUSTERcommunity.de

Re:OBD Schnittstelle auslesen
« Antwort #16 am: 15. Dezember 2010, 21:42:05 »

Offline docsnydor

Re:OBD Schnittstelle auslesen
« Antwort #17 am: 16. Dezember 2010, 13:36:16 »
Hallo Uwe,

danke für deine Arbeit und die ausführlichen Postings!  :daumen

 

Offline Hendrik

  • Duster Junior
  • **
  • Beiträge: 105
  • Herkunftsland: de
  • Duster Status: Besitzer
  • Ausstattung: Lauréate
  • Baujahr: 2010
  • Farbe: Mahagoni-Braun
  • Motor: dCi 110 FAP 4x2 109 PS
Re:OBD Schnittstelle auslesen
« Antwort #18 am: 16. Dezember 2010, 15:54:09 »
Ja DANKE für die Arbeit !!!!!!!!!!!


Mfg Hendrik
Mfg Hendrik
 

Offline UweH

  • Duster Junior
  • **
  • Beiträge: 213
  • ich mag's offroad
Re:OBD Schnittstelle auslesen
« Antwort #19 am: 16. Dezember 2010, 20:24:43 »
Die richtige "Arbeit" beginnt jetzt erst, dass war wie schon geschrieben nur das Vorgeplenkel.

Hier noch ein Nachschlag:
Habe mal morgens bei der Fahrt zur Arbeit mehrere Daten ausgelesen. Haupsächlich gings mir um die Kühlwassertemperatur und die Geschwindigkeit, um beides über der Zeit anzutragen. "Binkurzweg" hat die Kurve auch schon mal dargestellt aber da ist die X-Achse nicht ganz eindeutig in den Werten.
Zu meinem Datensatz habe ich je Sensor mehr als 21000 Werte (max. Ausleserate) über die Gesamtzeit von etwa 28 Minuten in der Grafik dargestellt. Wie man unschwer erkennt, ist der große Diesel nach etwa 12 Minuten auf Betriebstemperatur (vier Balken) bei einer Ausgangstemperatur von 7°C.

Gruß UweH

 

Offline binkurzweg

Re:OBD Schnittstelle auslesen
« Antwort #20 am: 16. Dezember 2010, 22:49:02 »
...Haupsächlich gings mir um die Kühlwassertemperatur und die Geschwindigkeit, um beides über der Zeit anzutragen. "Binkurzweg" hat die Kurve auch schon mal dargestellt aber da ist die X-Achse nicht ganz eindeutig in den Werten.

Habe ich jetzt mal berichtigt. Sehr interessant, die Verläufe ähneln sich schon stark.
Ansonsten: Respekt! Saubere Arbeit!

+ + + Rundfunkstadt + + + Königs Wusterhausen + + +  Wiege des Rundfunks in Deutschland  + + + + 

Rund um Zossen -- Duster Treffen Video:   Dacia Duster on the road 
 

Offline UweH

  • Duster Junior
  • **
  • Beiträge: 213
  • ich mag's offroad
Re:OBD Schnittstelle auslesen
« Antwort #21 am: 17. Dezember 2010, 21:04:40 »
@ binkurzweg: x-Achse berichtigt... da wiederholen sich doch die Ganzzahlwerte.

Habe heute neue Berechnungen durchgeführt, die allein auf einer Datenmessung von Geschwindigkeit und Drehzahl für den 4. Gang über die OBD- Schnittstelle basieren. Gilt hier für meinen 4x4 110er Diesel.

Im Diagramm „Motordrehmoment über Motordrehzahl“ in Bild 1 ist der Verlauf noch einmal gezeigt. Das Diagramm habe ich auch im Beitrag #16 weiter oben schon diskutiert bezüglich der Glättung. Im Vergleich mit einer etwas geschönten Datenblattkurve (siehe Bild 2) vermutlich von Dacia, hat „lord“ hier mal gepostet, ist der Verlauf gar nicht mal so schlecht und ich habe im Moment wetterbedingt   :'( auch keine Möglichkeit Tests zu fahren.  

Aus der Kurve des Motordrehmoments in Bild 1 habe ich in Intervallen von 250 Upm einige Datenpunkte ausgelesen, um daraus die Raddrehmomente zu berechnen für den jeweiligen Gang unter Berücksichtigung der Ganguntersetzungen und der Achs- oder Raduntersetzung.

Die berechneten Datensätze der Raddrehmomente eines jeden Gangs kann man dann über der Geschwindigkeit antragen wie Bild 3 zeigt. Die Geschwindigkeit lässt sich aus der Drehzahl und dem Radumfang berechnen.
Man kann jetzt im Diagramm einerseits das jeweils maximale Raddrehmoment auslesen und daraus das Schubgewicht errechen, das im ersten Gang rund 1.7 Tonnen beträgt. Andererseits erkennt man, dass es Kurvenschnittpunkte gibt, die - so vermute ich zumindest, denn ich bin hier wirklich nicht der Experte - die Schaltpunkte von einem Gang in den nächst höheren markieren.

Aber vielleicht lässt sich ja noch mehr aus den Daten knautschen. Im Bild 4 ist ein weiters Diagramm entstanden und zeigt für die einzelnen Gänge den Kurvenverlauf der Radgesamtleistung, die wiederum aus Kenntnis von Radmoment, Drehzahl und Winkelgeschwindigkeit des Rades berechnet werden kann. Nun sieht man, dass auch diese Kurven ein Maximum aufweisen. Von Interesse ist die Lage über der Geschwindigkeitsachse.

Legt man beide Diagramme übereinander, wie im Bild 5 zu sehen ist, erhält man zusätzliche Informationen über die Lage der Maximalwerte vom Raddrehmoment und der maximalen Radleistung in den einzelnen Gängen. Wie allgemein gilt, ist die Beschleunigung im Bereich des maximalen Drehmoments am größten und wenn die maximale Motorleistung erreicht ist, bringt eine Drehzahlerhöhung nichts mehr, es steigen nur noch unnötig der Treibstoffverbrauch und auch die Erwärmung (und andere Verschleißwerte....

Daher macht es Sinn einen Bereich zu definieren, in dem man den Gang wechseln sollte. In den farbig markierten Bereichen habe ich den Schaltwechsel gekennzeichnet. Nach ausgiebiger Betrachtung, deckt sich dass auch gut mit meiner Fahrpraxis.

Wenn man nun noch die Kurve des Momentanverbrauchs an Treibstoff dazu nehmen könnte, wäre das Diagramm komplett. Vorausgesetzt die Verbrauchskurve zeigt über der Geschwindigkeit in den markierten Bereichen eindeutig ein Minimum, dann kann man den perfekten Schaltpunkt für den Gangwechsel fixieren, zumindest wenn man sparsam - also unsportlich - fahren will.

Das Programm von WGSoft hat eine Datenerfassung des MAF- Sensors (mass air flow) und basieren auf diesen Daten eine direkte Wertanzeige in L/100km des Kraftstoffverbrauchs aber wie oben auf dieser Seite im Beitrag #15 schon bemerkt, ist die Verbrauchsanzeige für den Turbodiesel ungenau (ca. um Faktor 2 zu viel). Man könnte mal den MAF- Sensor auslesen und sich die Daten exportieren und genauer ansehen....

aber dazu später mehr. Das wäre es für heute. Und was haben wir gelernt? Wo Drehmoment fehlt, muss Drehzahl her... /hahaha

Gruß von UweH

 

Offline UweH

  • Duster Junior
  • **
  • Beiträge: 213
  • ich mag's offroad
Re:OBD Schnittstelle auslesen
« Antwort #22 am: 26. Januar 2011, 22:58:47 »
Gruß an Alle, die hier lesen...

Habe während des „Winterschlafs“ Zeit gefunden, mich mit den Sensordaten der OBD- Schnittstelle zu befassen.

Rückblick: Die von mir erworbene Software von  WGSoft.de (ScanMaster-ELM) hat ein kleines Feature zur numerischen Anzeige des Momentanverbrauchs an Treibstoff. Leider nicht korrekt in der Momentananzeige für einen Turbodieselmotor.

Die EOBD kam erst im Jahr 2003 mit erweiterten europäischen Richtlinien für Dieselfahrzeuge und im Jahr 2005 mit EOBD I und erneut 2008 mit EOBD II für Nutzfahrzeuge. Seither sind auf dem Markt der Software Programme erhältlich insbesondere zum Auslesen der OBD- Sensordaten (siehe hier: OBD II PID’s bei Wikipedia) und nicht nur für die Fehlerdiagnose- Daten.  

Motivation: Die Fahrzeughersteller geben in der Tachoanzeige berechnete Verbrauchswerte an, die vermutlich auch mit bestmöglicher Genauigkeit berechnet werden. Die Formeln und die hierfür verwendeten Sensordaten sind ein gut gehütetes Geheimnis und lassen sich nicht mal so einfach googlen.
(Bem: Ich denke, nur Mitglieder (Fahrzeughersteller) einer mächtigen Lobby der SAE (Society of Automotive Engineering)  erhalten gegen entsprechende Lizenzzahlungen Unterlagen mit Normschriften (dazu zählen auch spezifische Unterlagen der Fahrzeughersteller), die entsprechend detaillierte Auskünfte über die PID- Sensorik der Motorsteuerungen und der Prozessordatenverarbeitung enthalten. Hierzu zählen auch die fahrzeugspezifischen Kennlinienfelder der Motoren, die nur auf Motorprüfständen genaue Daten liefern, die wiederum in Tabellen abgelegt werden und auf die die  ECU des Fahrzeugs zugreifen kann.)
Aber man kann sich mit der Sache mal beschäftigen und sehen, wie vergleichbar eigene Berechnungen sind, wenn man nur minimal viele Sensoren und deren Daten und einige gebräuchliche, allgemeingültige Konstanten zur Berechnung heranzieht.

Was mir an der Tachoanzeige nicht so gefällt ist, dass der numerische Wert unanschaulich mit z. B. 6.2 L/100km  träge in der Anzeige bleibt und je länger man fährt und die Anzeige nicht auf „Null“ zurück setzt, je träger reagiert der Wert auf Änderungen des eigenen Fahrverhaltens oder der Streckenführung (Bergfahrt, Talfahrt,...).

Wenn ich mir überlege, dass ich an ca. 230 Tagen zur Arbeitsstelle hin und zurück 50 km auf gut ausgebauter Landstraße (keine Ortsdurchfahrt, 2 Ampeln, einigen Abbiegestopps, einige Beschleunigungsspuren...) fahre und nun durch Training meiner Fahrweise 1L/100km einsparen könnte, dann beträgt das Einsparpotential immerhin ca. 160 € für die Fahrten zur Arbeit pro Jahr.

Strategie: Wesentliche Voraussetzung für mich ist die Software von WGSoft, die eine umfangreiche Sensordatenerfassung und die tabellarische Ausgabe ermöglicht. Basierend auf einer Formel, die den Dieselverbrauch pro Wegabschnitt in guter Näherung liefert und im Weiteren einer grafischen Darstellung vorzugsweise mit Abbildung der Drehzahl und Geschwindigkeit soll im ersten Ansatz diese Darstellung diskutiert werden.

Durchführung: Bei einer gewählten Fahrstrecke in der Weihnachtspause mit etwas größerer Entfernung zwischen Supermarkt und Haus habe ich auf der Rückfahrt mit warmem Motor über ca. 17km Daten aufgezeichnet. Die Sensordaten umfassen neben der Systemzeit (VST), die Geschwindigkeit (VSS), die Drehzahl (RPM), den angesaugten Luftmassenfluss (MAF), den Luftdruck im Ansaugrohr (MAP), die eingehende Temperatur der Luft (IAT), den Kraftstoffdruck (MFP) und den aus verschiedenen Sensordaten von der ECU berechnetem Lastwert (CLV), der insbesondere für Dieselfahrzeuge seit einiger Zeit auch über die OBD- Schnittstelle ausgelesen werden kann.

Berechnung 1: Im Forum unter http://www.mp3car.com (Stichwortsuche: real time fuel consumption monitoring) findet man einige Diskussionen über eine ursprünglich für Benziner verwendete Formel, die im Ansatz die Sensordaten MAF und VSS, die Konstante AFR (air to fuel ratio) für das Kraftstoff zu Luft Gemisch (1:14.7 bei Benzin od. 1:14.5 bei Diesel) und den Kraftstoffdichtewert FD (fuel density).
Des weiteren benötigt man Umrechnungsfaktoren je nach dem ob das Ergebnis als MPG (miles per gallon) oder als GPH (gallon per hour) betragen soll. In Europa (Canada) bevorzugt man L/100km oder auch L/h, was den Vorteil hat, dass auch für z. B. Traktoren mit Zapfwelle im Stand betrieben eine sinnvolle Verbrauchsangabe erhalten.
Da früher der MAF Sensor wohl bei vielen Fahrzeugen noch nicht eingebaut oder nicht als Sensorwert über OBD auszulesen war, gibt es auch eine erweiterte Berechnung im o. a. Forum, die einen pseudo Wert (IMAF) nutze, der über RPM, MAP und IAT berechnet wird und dann im zweiten Schritt den errechneten IMAF ergibt. In dieser Gleichung stehen dann noch 2 Konstanten, erstens die Molmasse der Luft (MM) und die Gaskonstante (R) und zweitens benötigt man den Hubraum- Wert des Moters (ED, engine displacement) sowie eine für das Fahrzeug individuelle Volumen- Eeffizienz- Anpassung kurz VE, die man als Skalierung im Bereich 0...1 wählen musste.

Bild 1 zeigt nun den Dieselverbrauch den ich aus dieser ersten Formel für meine Daten berechnen konnte. VE ist mit einem Wert von 0.35 eingesetzt. Die Kurve zeigt den berechneten, momentanen Verbrauch  über eine Strecke von 17 km. Der Auslesezyklus (Wert zu Wert von insgesamt 9 Sensoren) betrug ca. 300 ms, was gleichermaßen für alle Rechnungen gilt. Die Kurve enthält keine gleitende Mittelung. Es findet jedoch eine Gewichtung über die zunehmend größere Summe der Wegabschnitte statt (numerisches Wegintegral) und zu jedem dieser Wegabschnitte findet eine Umskalierung des Verbrauchs letztlich auf 100 km statt. Die Startwerte auf dem ersten Streckenabschnitt fallen hier mit Werten über 30 L/100km deutlich zu hoch aus.

Berechnung 2: Um die Sache nun rechnerisch zu vereinfachen verwende ich im 2. Ansatz gleich die gemessenen MAF-Werte und die RPM und die Konstanten AFR und FD. Des Weiteren muss man beim Viertakter berücksichtigen, dass pro Kurbelwellenumdrehung 4 Gemischladungen erfolgen. Die Berechnung ist im Bild 2 gezeigt und verläuft fast identisch zu der Kurve in Bild 1. Alle anderen Bemerkungen wie zuvor.

Berechnung 3: Hier im 3. Ansatz werden die gemessenen Werte für MAF, CLV und das Zeitintervall Delta-t (Differenz zwischen den Messwerterfassungen) und die Konstanten AFR und FD. Die Berechnung ist im Bild 3 gezeigt. Im Unterschied zu den vorangestellten Berechnungen fallen die Startwerte schon deutlich geringer aus und liegen nach einem Kilometer Strecke etwa bei 8 L/100km. Insgesamt verlaufen mir aber die Werte zwischen 5 km bis 17 km etwas zu gering, da ich im Vergleich mit der ECU- Anzeige etwa bei 6.3 – 6.5 L/100km lag (Ende Dezember 2010).

Berechnung 4: Letztlich im 4. Ansatz habe mal eine Berechnung probiert, die über das Verhältnis von Kurbelwellenleistung und Diesel- Heizleistung auf die verbrauchte Dieselmasse führt. Die Verbrauchswerte basieren auf den Daten von VSS, dem Zeitintervall und Delta-t. Als Konstanten  sind hier FD und der Heizwert H für Diesel eingesetzt. Für die Skalierung habe ich einen VE Wert von 0.7, den ich im Moment als so etwas wie einen Wirkungsgrad verstehe. Der Kurvenverlauf ist im Bild 4 gezeigt. Mit dieser Rechnung bin ich noch am ausprobieren, welche Messdaten eher Sinn machen. Interessant finde ich, dass hier im Verlauf der Kurve kurzeitiger Mehrverbrauch deutlicher hervortritt als in den anderen Kurven, was der Fahrstrecke und dem Fahrverhalten entspricht.

Als Beispiel wie unterschiedlich die Rechnung je nach verwendeten Datensätzen ausfällt die Kurve in Bild 5, bei der anstatt Delta-t jetzt RPM und CLV in die Rechnung eingehen. Hier sieht man die Verbrauchsspitzen deutlicher – vielleicht sogar überzeichnet.

Fazit: Um den momentanen Verbrauch besser darzustellen, kann man auf verschiedene Weise den Verbrauch über einer Fahrstrecke abbilden. Ziel ist es hierbei nicht genauer zu  rechnen als es die ECU im Fahrzeug macht. Ich versuche anhand von Diagrammen eine Darstellung zu haben, um aufgrund verschiedener Fahrweisen auf ein und derselben Strecke (z. B. Weg zur/von der Arbeitsstelle) zu erkennen, ob man tatsächlich belegen kann, dass man sich eine Fahrweise angewöhnt, bei der man weniger Diesel verbracht. Das Diagramm dazu zeige ich in den letzten Abbildungen 6 und 7. Es handelt sich hierbei um Konturplots, die auf den x- und y- Achsen Geschwindigkeit und Drehzahl angeben. In diese Ebene ist der Verbrauch projektiert mit interpolierten Zwischenwerten. Die Farbzonen entsprechen einem konstanten Verbrauch, andere Farbe zeigt die nächste Verbrauchsstufe in ganzen Litern. Im Konturplot 6 sind die Ränder numerisch angezeigt.

Im Konturplot 7 sieht man zudem 6 Drehzahl-Geschwindigkeits-Geraden (aus einer der früheren Motorleistungs-/Drehmomentmessung errechnet) für den jeweiligen Gang mit unterschiedlicher Steigung. Entlang dieser Geraden sind nun die Verbrauchsbereiche von Interesse die durchlaufen werden.

Der Konturplot 7 zeigt, dass bei dieser Fahrt insbesondere das Beschleunigen in den kleinen Gängen (der 1. Gang wurde nicht benutzt) und an den oberen Schaltpunkten bei 3000 RPM  Spitzenwerte auftreten.

In der nächsten Zeit möchte ich dann mehrere solcher Plots der gleichen Strecke vergleichen und z. B. die Schaltpunkte verschieden bei 2000/2500/2750 legen. Mal sehn...

Gruß UweH


 

Offline AndreasK

Re:OBD Schnittstelle auslesen
« Antwort #23 am: 01. Februar 2011, 10:03:46 »
...  Die Fahrzeughersteller geben in der Tachoanzeige berechnete Verbrauchswerte an, die vermutlich auch mit bestmöglicher Genauigkeit berechnet werden. Die Formeln und die hierfür verwendeten Sensordaten sind ein gut gehütetes Geheimnis und lassen sich nicht mal so einfach googlen.

Warum Geheimnis? Es gibt ein Kennfeld, welches über Drehzahl und Last die Öffnungszeit der Einspritzdüse festlegt. Mit der Düsengröße und dem Systemdruck ist die Treibstoffmenge (genauer, das Volumen) in ml/ms gegeben. Die Drehzahl des Motors bestimmt die Anzahl der Öffnungen über einen bestimmten Zeitraum, z.B. je Minute 1.250 Öffnungen von 1.2 ms = 1,5 sec Düsenöffnung je Minute, je ms Öffnungszeit 0,02 ml.

Die Verbrauchsanzeige würde dann, würde man im 6ten Gang und 100 km/h durch die Gegend (also über eine Ebene ohne Lastwechsel) zuckeln, ziemlich genau 5l/100km anzeigen.

Das einzige "Geheimnis" ist die Treibstoffmenge pro ms Öffnung. Die Einspritzzeiten lassen sich ja ebenfalls mit Hilfe der OBD-Schnittstelle darstellen. Wenn man die über z.b. eine Tankfüllung hinweg subsumiert, dann kennt man ganz genau auch das letzte Geheimnis der Verbrauchsberechnung.

Die Unterschiede zwischen getanktem Volumen und dem durch den Bordcomputer ermitteltem Verbrauch könnte ja in Dichteschwankungen des Sprits liegen - denn, so heiss wie eingespitzt wird, wird nicht getankt.
Der Duster ist kein "Ich könnte, wenn ich wollte"-Auto, es ist ein echter "Geht schon, wenn's muss!". 4 Räder, 2 Aussenspiegel, 1 Rückspiegel, Lenkrad, vorne 2 Einzelsitze, hinten Sitzbank, Kopfstützen, 3-Punkt-Gurte, 5 Türen, Motorhaube, rundum verglast, Stand- Abblend- und Fernlicht, Scheibenwischer, Hupe, Radio, Klimaanlage, 4WD, ..., Beleuchtung Rücksitzbank, EPH, Zündkerzen und -spulen und schalldämmender Unterfahrschutz.
 

Offline elchtester

  • Duster Kenner
  • ***
  • Beiträge: 432
Re:OBD Schnittstelle auslesen
« Antwort #24 am: 01. Februar 2011, 17:58:20 »
in der neuen c't (4/2011) gibt es einen Test zu 6 OBD2-Diagnosegeräten in der Preisspanne von 15,- 400,- Euro.

Sobald ich einen Link zur Verfügung habe, werde ich diesen hier veröffentlichen.
 

Offline 4X4Duster

Re:OBD Schnittstelle auslesen
« Antwort #25 am: 11. Februar 2011, 13:39:02 »
Hat schon jemand OBD per Bluetooth auf's Navi probiert?

Nur anzeigen und auslesen würde mir reichen.

Gruß

Andreas
I'm very good in doing nothing........
 

Offline stepi186

  • Duster Professional
  • *****
  • Beiträge: 2366
  • Dankeschön: 28 mal
  • Herkunftsland: de
  • white with black
  • Duster Status: Besitzer
  • Ausstattung: Prestige
  • Baujahr: 2019 Duster II
  • Farbe: Arktis-Weiß
  • Motor: Blue dCi 115 4x2 115 PS
Re:OBD Schnittstelle auslesen
« Antwort #26 am: 11. Februar 2011, 18:53:50 »
Hat schon jemand OBD per Bluetooth auf's Navi probiert?
Nur anzeigen und auslesen würde mir reichen.
Gruß

Andreas

Navi nicht aber Handy , schau mal  HIER   1. Post hier im Thread

müsste eigentlich auch auf'm Navi gehen  /weissnich

gruß stepi
in memory of- 110 dci - 107 (130 PS - 290 Nm) RC Ultimate , Original Alu's mit GeländeWR Cooper ,  Platin P53 matt-black 7x16 ET38 mit 235/60/16 Toyo Open country A/T , Orig.-AHK , Orig. Schmutzf. vorn , Gum.Schneematten , Innenraum / Ambienteleuchte W8 , Azuga KR-Wanne , Dopp. Ladeboden-handmade , Heckw. Intervall , Kenwood BT 60U + 4x LSP Pioneer ,  PDC , Check temp III  , Climair vorn , MAL , Tachoscheibe Chronolook individuell mit SMD in weiß , 30 mm Höher mit Federn H&R , Antec Bügel schwarz matt , Voll-LED RL in black , 3. Bremsleuchte LED   ,  LED-TFL statt NSW , Carb.-Wachs..
 

Offline elchtester

  • Duster Kenner
  • ***
  • Beiträge: 432
Re:OBD Schnittstelle auslesen
« Antwort #27 am: 11. Februar 2011, 19:23:19 »
noch mal zu meinem Posting von oben - ich kann den Link hier leider nicht setzen, da ich sonst gegen die Boardregeln verstoße. Ich habe ein Abo von c't und von daher Zugang zum Archiv. Wer den Artikel haben möchte muss eben etwas kreativ werden. ;)
 

Offline Sargnagel

  • Duster Kenner
  • ***
  • Beiträge: 576
  • Dankeschön: 10 mal
  • Herkunftsland: 00
  • Duster Status: Ex-Besitzer
  • Ausstattung: Lauréate
  • Baujahr: 2010
  • Farbe: Perlmutt-Schwarz
  • Motor: dCi 110 FAP 4x4 110 PS
Re:OBD Schnittstelle auslesen
« Antwort #28 am: 09. Juli 2011, 21:40:00 »
Hallo an alle,

kann mir jemand ein OBD2 Diagnosegerät in der Preisspanne bis 150 Euro empfehlen.
Will mich nicht nur auf die Aussagen der Werkstatt verlassen.

MfG Joachim
 

Offline Oliver_Bln

  • Duster Neuling
  • *
  • Beiträge: 24
Re:OBD Schnittstelle auslesen
« Antwort #29 am: 20. November 2011, 03:05:56 »
Hallo dustercommunity  /winke


^^so ein Video mit dem Duster hat mir das WWW leider noch nicht präsentiert

benötige Materialen:

1) Auto = Duster (dCi 110 FAP 4x4 110 PS) **leider nicht vorhanden**

2) PLX Kiwi Bluetooth

^^geiles Gerät (PLX Devices Spokes Model 2011 Jaime Lee) ops! sorry!  **leider nicht vorhanden**

3) Samsung Galaxy S 2 + aLapRecorderHD **vorhanden**
oder ich hätte für Testzwecke noch die contour-hd


4) Software = RaceRender 2  **Free**


Ich weiß viel Technik/Aufwand , aber wer die Beitrag Reihe "Chip-Tuning - Technische Angaben" verfolgt
..der zieht den HUT vor den aktiven User´n / Tester´n und ich glaube dies hier wäre a "Kinderspiel" :-)

MFG OLi aus Berlin  8)

PS: Ja der Duster ist keine Rennsemmel und ja er fährt die Alpen solide hoch und runter !!
ich glaub sollte ihn einfach mal Probe fahren ;-) Berlin <-> Alpen *hmpf* kennt jemand a freundlichen AH :-D
PSS: die gelbe Karte für zu viele Smile`s hab ich bereits erhalten und bevor ich noch eine für zu viel Traffic bekomme ->Nachtii DC
 

DUSTERcommunity.de

Re:OBD Schnittstelle auslesen
« Antwort #29 am: 20. November 2011, 03:05:56 »