Liste der Anhänge anzeigen (Anzahl: 2)
NB (nicht FL) kann doch OBD
Hallo,
nach intensiver Suche habe ich festgestellt, dass der NB sehr wohl OBD Faehigkeiten besitzt. Das ist auch deshalb naheliegend, weil das Teil in USA bereits mit OBD verkauft wurde, und die Fehlercodes ebenfalls 4-stellige OBS2 Fehlercodes sind (im Gegensatz zum NA). Allerdings entspricht das Protokoll eben nicht dem OBD2 Standard. Es ist ein OBD Derivat, dass wohl seinerzeit zusammen mit Ford entwickelt wurde.
Um mir der ECU zu kommunizieren, braucht man zunaechst ein ELM Modul, dass nach folgendem Schema mit der 17pol. Diagnosebuchse verbunden werden muss:
Anhang 4827
(Die Grafik stammt aus dem forscan.org Forum).
Man sieht, dass die MEM Leitung die K-Line der OBD Schnittstelle darstellt. Ueber diese Leitung ist auch eine selbstgebastelte Kommunikation moeglich. Die elektrische Spezifikation dieser Schnittstelle werde ich spaeter noch genauer beschreiben.
Als naechstes braucht man die "Forscan" App. Da die Schnittstelle nicht dem OBD2 Standard entspricht, kommmt man mit der "Torque" App hier nicht weiter. Zum Testen gibt es die Forscan App auch als Lite Version. Einschraenkung hierbei ist, dass nur ein Parameter zu einem Zeitpunkt ausgelesen werden kann.
Nach Installation und Starten der App verbindet man sich mit dem Fahrzeug und laesst sich die PIDs anzeigen, die der MX5 anbietet. Ich hab die PID meines MX mal als Screenshots zusammengestellt:
Anhang 4829
Wie man sieht, bietet der MX5 ca. 70 Werte zum Auslesen an. Ob auch wirklich alle sinnvoll sind, habe ich nicht durchgetestet. Die, die ich ausprobiert habe, funktionieren. Dass einige der Sensoren doppelt vertreten sind, liegt daran, dass sie einerseits die physikalische Messwerte (idR. Spannung) und andererzeits umgerechnete Werte zurueckgegeben werden (zB. Temperatur in C).
Liste der Anhänge anzeigen (Anzahl: 2)
K-Line
Schliesst man ein Oszi an die K-Line an, ergibt sich folgendes Bild, sofern man ueber den ELM eine PID von der ECU anfordert:
Anhang 4830
Die 7 linken senkrechten Striche sind die Anfragen des ELM an die ECU (7 Byte mit Pausen zwischen die Bytes), der breitere Strich links der Mitte ist die Antwort der ECU (8 bzw. 9 Byte fast ohne Pausen). Nach einer Pause von ca. 120ms wiederholt sich das Ganze. Im Prinzip handelt es sich um eine serielle Schnittstelle, aehnlich der RS232. Allerdings sind die Pegel 12V und 0V, wobei 12V einer logischen 1 entspricht, und 0V entsprechend logisch 0. Die Geschwindigkeit der Schnittsytelle betraegt ungewoehnliche 10400 Baud. Das Uebertragungsformat ist 8N1, dh. nach einem Startbit (log 0) folgt ein Byte (8 Bit), und als Abschluss wieder ein Stoppbit (log 1). Auf ein Paritaetsbit wird verzichtet. Idle (Stille) ist hier ebenfalls log 1. Beim Byte wird das niederwertigste Bit zuerst uebertragen (LSB first)
Anhang 4831
Eine typische Antwort der ECU ist im Oszillogramm zu sehen. Die Kaestchenbreite betraegt 1ms, dh in ein Kaestchen passen etwa 10 Bit (bei 10400 Baud). nach dem Startbit ganz links (erster 1-0 Uebergang ) folgt 00100001 nach einer Pause von etwa 0,2ms kommt das naechste Startbit und die Folge 10101111 usw. Hexadezimal wird also zuerst eine 0x84 und dann eine 0xF5 gesendet (Achtung LSB first: dh Bitstrom rueckwaerts interpretieren).
Fuer mein Projekt (Spritverbrauchsmesser) brauche ich folgende Sensoren, und auf die beschraenke ich mich erstmal auch:
- FUELPW1: Oeffnungszeit der Einspritzduesen
- RPM: (selbsterklaerend)
- VSS: Geschwindigkeit
Fordert man diese Sensorwerte an, kann man auf der K-Line folgende Byte an die MCU mitlesen:
| FUELPW1 |
0x64,0x10,0xF5,0x22,0x17,0x62,0x04 |
| RPM |
0x64,0x10,0xF5,0x22,0x17,0x38,0xDA |
| VSS |
0x64,0x10,0xF5,0x22,0x17,0x4A,0xEC |
Ab hier wird jetzt tlws. Raterei, weil das Protokoll nirgends beschrieben wird. Falls jemand das Ford Protokoll kennt, bin ich fuer Erhellung dankbar....
Man erkennt , dass die ersten 5 Byte immer dieselben sind. Wahrscheinlich bedeutet 0x64 "Anfrage einer PID". 0x10 und 0xF5 sind moeglicherweise Sende und Empfangsadressen der beiden Kommunikationspartner ELM und ECU, da diese sich bei den Anworten der ECU getauscht gesendet werden (s.u.). Fuer 0x22 und 0x17 habe ich leider keine Erklaerung.
Das sechste Byte beschreibt jeweils die PID, dh 0x62 ist die Einspritzzeit, 0x38 die Umdrehungen und 0x4A die Geschwindigkeit. Das letzte Byte ist ein Checksummen Byte. Es berechnet sich einfach aus der Summe der bereits gesendeten 6 Byte, abgeschnitten auf 8 Bit (modulo 0xFF):
0x64+0x10+0xF5+0x22+0x17+0x4A = 0x1EC ( modulo 0xFF: 0xEC)
Die Antworten der ECU sehen jeweils exemplarisch so aus:
| FUELPW1 |
0x84,0xF5,0x10,0x62,0x17,0x62,0x04,0x90,0xF8 |
| RPM |
0x84,0xF5,0x10,0x62,0x17,0x38,0x0D,0xAC,0xF3 |
| VSS |
0x74,0xF5,0x10,0x62,0x17,0x4a,0x26,0x62 |
Ist das erste Byte 0x74, ist der Sensorwert 1 Byte lang, waehrend er bei 0x84 2 Byte lang ist. Abschliessend folgt wieder eine Checksumme, die wie oben berechnet wird.
Interpretation der Werte:
Die uebermittelten Sensorwerte muessen in physikalische Groessen umgerechnet werden. Dabei sind 2 Byte als 16-Bit Zahlen zu interpretieren die wie folgt berechnet werden: 7te Byte * 256 + 8te Byte.
Als Ergebniss erhalten wir in unserem Beispiel also als Dezimalwerte:
| FUELPW1 |
1164 |
| RPM |
3500 |
| VSS |
38 |
Beitrag automatisch zusammengeführt
Zitat:
Zitat von
da_user
Den entsprechenden Artikel von Forscan habe ich hier schonmal in einem ELM327-Thread verlinkt:
https://forscan.org/forum/viewtopic.php?f=4&t=5
Als Software würde ich hier übrigens eher das vollwertige ForScan für Windows empfehlen. Braucht halt einen Laptop od. ähnl. mit Windows. Ist dafür allerdings bei praktisch vollem Funktionsumfang kostenlos.
M.W. hat ja der NA("FL") auch eine solche Diagnosebuchse. Interessant wäre, ob da auch dieser Bus anliegt und man diesen auslesen kann.
Ich vermute nein:
Erstens war zur NA-Zeit noch kein OBD in den USA vorgeschrieben, und zweitens blinkt der NA zweistellige Fehler, waehrend der NB 4-stellige OBD2 Errors ausblinkt.
Aber das sagt mir nur die Kristallkugel. Leider habe ich keinen NA, das muss ein Dritter testen;-)
Liste der Anhänge anzeigen (Anzahl: 3)
Mikrocontroller
Will man einen Mikrocontroller (MCU) an die ECU anschliessen, sind die unterschiedlichen Spannungen zu beachten. Die Kommunikationsleitung hat 12V Pegel, eine MCU kann idR. nur 5V verarbeiten.
Daher ist ein Pegelumsetzer noetig. Ich habe diese Schaltung aus dem AVR-Forum verwendet:
Anhang 4838
Als MCU habe ich einen Arduino Uno mit einem 2.4" TFT Display mit Touch Funktion verwendet. Ich habe es anstelle der Digitaluhr eingebaut. Dazu wurde die Uhr entfernt, der Ausschnitt passend fuer das Display ausgefraest und der Hinterbau passend gedremelt, und das Ganze verkehrt herum wieder eingebaut. Die Spannungsversorgung +12V und Masse habe ich vom Stecker der Digitaluhr entnommen, die Datenleitung direkt an der Motorsteuerung im Fussraum des Beifahrers abgegriffen. (Das war einfacher als es vom Diagnosestecker im Motorrraum abzugreifen). Es ist das gruen-weisse Kabel Nummer 1D aus http://www.mellens.net/mazda/mazda_m...000_wiring.pdf, Seite Z-22.
Eingebaut sieht das Ganze so aus:
Anhang 4839
Der Controller zeigt den aktuellen Verbrauch (hier 8.21 l/100km) den Durchschnittsverbrauch (9.96 l/100km) die aktuelle Geschwindigkeit (30 km/h), die gefahrenen Kilometer im gesammten Messzeitraum (92,6 km) und den Gesamtverbrauch (9.22 l) an. Dazu werden regelmaessig die gefahrene Wegstecke sowie der momentane absolute Verbrauch ermittelt. Der Controller fragt dazu in einer Endlosschleife die aktuellen Werte (Einspritzzeit, RPM und Geschwindigkeit) ab, und ermittelt die Zeit zur letzen Messung (ca 0.5s). Daraus berechnet er die Wegstecke in km (Geschwindigkeit * Zeit) sowie den absoluten Verbrauch in ml (5ml/s * Zeit * 2 * RPM / 60). Dabei ist 5ml/s ist die geschaetzte Einspritzmenge je Duese pro Sekunde (dazu spaeter mehr), das Messintervall in Sekunden, 2 Einspritzvorgaenge pro Umdrehung und die Umdrehungen pro Sekunde. Beide Werte ergeben als Quotient den momentanen Verbrauch, integriert man beide Werte ueber die Zeit, erhaelt man die gefahrene Wegstrecke, den absoluten Verbrauch, sowie den Durchschnittsverbrauch.
Momentan ist die Einheit noch nicht geeicht. Die Abweichung der gefahrenen Kilometer im Vergleich zur Tachoanzeige liegt bei etwa +3% (ca. +3km bei 90km). Das ist akzeptabel und noch korrigierbar. Der echte Verbrauch wurde noch nicht ermittelt. Tatsaechlich sind wirklich erst knapp 100km auf der Uhr, ich habe noch nicht nachgetankt. Der Verbauch mit ca 10l/100km ist aber definitiv zu hoch. Meine Erfahrungen liegen bei etwa 8,5 /100km. Moeglicherweise sind die 5ml/s der Duesen zu hoch eingeschaetzt.
Der Wert habe ich aus der Reparaturanleitung http://www.mellens.net/mazda/Mazda-Miata-1999-2001.pdf Seite 01-14-15. Dort heisst es, dass eine Duese zwischen 66 und 82 ml in 15 Sekunden ausspruehen soll. Nimmt man den Mittelwert 75ml ergibt es genau 5ml/s. Allerdings ist mir nicht klar, auf welchen Motor sich die Anleitung bezieht. Ich habe den 1.6er.
In http://mxfive.at/einspritzduesen-wis...tes-reinigung/ werden die Duesen wie folgt angegeben:
MX-5 NA 1.6 Düse: Blaue Kappe / 212cc@3Bar
MX-5 NA 1.8 Düse: Braune Kappe / 254cc@3Bar
Der MX 5 betreibt die Duesen allerdings mit 4 bar (http://www.mellens.net/mazda/Mazda-Miata-1999-2001.pdf Seite 01-14-16). Geht man davon aus, dass bei 4 bar 1/3 mehr eingespritzt wird als bei 3 Bar, entsprechen die Grenzwerte der Reparaturanleitung etwa diesen beiden Duesen. Moeglicherweise ist dann 66 ml (etwa 4,4 ml/s) der bessere Wert fuer den 1.6er. Das ergaebe dann ca. 8,8l Durchschnitt, was bei reinem Stadtverkehr nicht unrealistisch ist.
Man wird sehen....
Beitrag automatisch zusammengeführt
Neben der Verbrauchsmessung hab ich noch schnell 'ne Ueberwachung fuer die Lamdasonde realisiert. Ich hatte da mal schlechte Erfahrungen damit gemacht: https://mx-5.de/forum/showthread.php...11#post9836111
Die Abfrage ist einfach: PID ist 0x95, die gesamte Abfrage sieht somit so aus:
0x64,0x10,0xF5,0x22,0x17,0x95,0x37
Die Anwort der ECU betraegt nur 1 Byte. Der Wert muss mit 200 geteilt werden, um die Ausgabespannung der Lambdasonde zu berechnen. Graphisch dargestellt sieht das im Stadtverkehr bei mir so aus:
Anhang 4840
Lambda laeuft....
Erste richtige Ergebnisse
Es ist tatsaechlich 6 Wochen her, seit dem letzten Tanken. Momentan fahre ich nur extreme Kurzstrecken, und muss daher kaum tanken. Dadurch ist aber auch der Verbrauch sehr hoch, er liegt bei ca 9,3 l/100km...
Zur Erinnerung: Ich messe in kurzen Zeitabstaenden (ca 0.7 sek), die momentane Geschwindigkeit und die Oeffnungszeit der Einspritzduesen. Daraus berechne ich die gefahrene Strecke und den absoluten Verbrauch. Integriert ueber die Zeit ergibt sich die Gesamtstrecke in km und den Gesamtverbrauch in l. Der Durchschnittsverbrauch in l/100km laesst sich dann leicht berechnen.
Ergebnisse:
Meine berechneten Kilometer betrugen 430,4km der Tageskilometerzaehler zeigte 430,0 an.
Der berechnete Verbrauch lag bei 40,12l, in den Tank passten 39,63l. Die Abweichung liegt bei ca 0,5l.
Im Stadtverkehr ist die Messung nahezu perfekt. Ob es auf Autobahn oder Landstrasse genauso ist, wird die Zeit zeigen.
