Sensoren ECU uitlezen

LM2902 lijkt mij het meest geschikt kan ook single supply werken.

http://i63.photobucket.com/albums/h148/fragme_dmc/electronics/pb2obd2.jpg
2 digitale ingangen (meer is er niet nodig) en de rest analoog.

Eerst moetje te weten komen welk soort van "schnittstelle" gebruikt wordt voor de desbetreffende sensor. Dit zijn tegenwoordig meer en meer complexe digitale systemen geworden. Vb ABS sensoren werken meestal met een blokgolf van 7/14 mA. De frequentie geeft dan de snelheid van het wiel weer. Daarnaast heb je ook al sensoren die via PWM allerhande informatie sturen. Ook wordt er soms een digitaal protokol vestuurd met 8 bits informatie. Als je dus deze sensoren wil afluisteren, moet je zowel spanning als stroom monitoren zonder ze te veinvloeden.

De sensoren dat ik wil afluisteren zijn nog gewone old school sensoren, dus gewone weerstanden.

Over welke ECU gaat het eigenlijk?
(Of anders: merk en model auto)

Mazda RX-7 FC N/A EU/JPN en USA model (usa model heeft meer pin outs), eventueel (moeten we nog eens kijken) de FD ook.

ECU: N322
N322 18 881C

En de non ecu's gaan ook volgen SA en FB.

[Bericht gewijzigd door Damic op (13%)]

Babbelen die ECU's niet 'gewoon' het KKL-protocol (ISO-9141)?

Euhm nee heeft een diagnose stekker maar geen OBD. Dus ze babbelen brabbel :p

ISO-9141 / KKL is ook geen OBD. ;)

De ECU van mijn auto (Bosch MP3.1) heeft officiëel ook geen OBD diagnose, maar onder de motorkap zit wel een groen 2-polig connectortje waar je via de 'blink-a-lamp' methode storingscodes kunt uitlezen.

Echter, de ECU blijkt wel degelijk een uitgebreidere diagnose techniek te ondersteunen, en wel via het KKL-protocol. Er gaat dan ineens een wereld open, want je kunt dan 'real-time' sensorgegevens uitlezen. Dat 'real-time' is overigens behoorlijk relatief, want de datastroom kabbelt rustig voort met 9600 baud.

Hazo ja, dat is waar. 9600Baud is traag. We zullen nog wel zien. Veel sensoren zitten er toch niet op die we nuttig vinden om te tonen.

edit: mnm, heb je daar nog een voorbeeld van?

[Bericht gewijzigd door Damic op (15%)]

Een voorbeeld waarvan?

KKL-protocol, he enigste dat ik vind zijn usb kabels nar obd connector.

Ik heb zelf eerst een eigen interface gebouwd om KKL-communicatie met de ECU aan de gang te krijgen. Toen dat was gelukt, heb ik op eBay een OBD-II/409.1 KKL USB interface gekocht en heb m'n software aangepast, zodat deze ook met die interface overweg kon. Ook dat is gelukt.

De hele protocol-afhandeling gebeurt in de software, de interface zelf is niets anders dan een RS232-USB bridge met wat level conversion elektronica erachter.

Wow leuk, misschien later. Ik zelf ken nog niet veel van pics en de andere collega kent alleen Arduino.

Weet zelf niet wat het handigste is, eens uitzoeken.

Edit: ik denk dat ik zoiets al eens ben tegen gekomen en wat had aangepast: http://i63.photobucket.com/albums/h148/fragme_dmc/electronics/simple%2…

[Bericht gewijzigd door Damic op (37%)]

Sterker nog: dat is je eigen ontwerp uit dit topic ;)

Ja, wist niet meer dat ik dat had gepost :o

Voor een avr heb ik nog wel code voor je om het uit te lezen. Ik ben hier een paar jaar terug ook mee bezig geweest. Ik meende dat de baudrate niet een standaard baudrate was maar 10400.

10400 baud is de latere versie, het oorspronkelijke KKL babbelt op 9600 baud.

Een schema die zelf heb gebruikt .

http://www.blafusel.de/bilder/obd2/ser_if-c/seriell_c-4.gif

Ik heb nog ergens een schema maar deze kan ik niet online vinden deze is zonder opto coupler .

Dit was met een mc33290deze draaide op 9600 baud.

[Bericht gewijzigd door daandc op (12%)]

Ik dacht dat ik een pic progger had maar blijkbaar een avr progger van hier iemand op het forum, dus ik moet ergens beginnen en omzetten naderend kan volgens mij niet moeilijk zijn (stuur maar per mail)

Moest het zijn dat ie toch op een hogere rate babbelt is dat goed nieuws.

In het schema dat Daandc heeft gepost, wordt de L-line aangestuurd via de RTS-lijn van de COM-poort. De meeste software doet die aansturing echter óók met de TxD-lijn.

De software waar ik momenteel zelf mee bezig ben, doet allebei. :)

Maar je moet toch commando's kunnen sturen naar de ecu en de ecu moet toch kunnen antwoorden dus wat is dan wat?

Ik dacht dat K > Rxd was en L > TXD, maar blijkbaar niet.nvm, had het schema nog niet goed bestudeerd.

In ieder geval ik geraak wat verder: heb 4 ECU kabels die ik kan gebruiken om data uit te trekken. Alleen bij alle 4 staat dat het een open collector uitgang is.
Nu zijn dit algemene schema's en staat er overal de stroom richting bij (uit of in ECU) en dus bij alle 4 de kabels een pijltje weg van de ecu. Natuurlijk gaan ze niet alles weggeven.

De kabels zijn genoemd: DCC1, DCC2, Greenlamp en ? (zie ook deze site: http://2ndgenrx7.freeservers.com/error%20codes.html de 4de kabel is die oranje op die kleine connector)

[Bericht gewijzigd door Damic op (54%)]

Open-collector is letterlijk wat die uitgang van de ECU is: een directe aansluiting op de collector van een transistor in de ECU.
Je moet dus gebruik maken van pull-up weerstanden, omdat de ECU de uitgangspin dus alleen maar naar ground kan trekken (transistor is dan in geleiding, dus de spanningsval over C-E is minimaal).

DCC1 en DCC2 zijn waarschijnlijk de K en de L lijn, alleen is het de vraag welke wat is.

De L-lijn wordt alleen gebruikt om de communicatie te starten (eenmalig), de K-lijn is daarna een bi-directionele lijn waar de gehele communicatie over verloopt. Deze communicatie moet, volgens het KKL-protocol, in leven gehouden worden door maximaal 250ms na de laatst verzonden byte een nieuw commando te sturen (een NOP-commando volstaat).

Hazo, daarmee dat dat zo traag is :)

Mwa, dat 't een half-duplex / single-wire verbinding is, is daar niet echt de oorzaak van. 9600 baud is per definitie ontzettend traag. Overigens is het in dit geval niet eens zinvol om een twee-draads / full-duplex verbinding te hebben, want de ECU geeft toch pas antwoord als 'ie 'n compleet commando binnen heeft gekregen.