*Disclaimer* Im an amateur.  I dont know a lot about coding or C++.  This code is not optimized, complete, or functional. 

Working File:
https://github.com/randumbintelrally/ME7_Logger_Arduino
the configuration is too complicated right now and I have tested this enough on enough ECUs to know it will work on anything but mine.  Will continue working on it and updating

Theres a lot of discussion on here of people wanting to implement ME7logger onto Arduino or RPi.  Prj says its easy and the information is out there and it can be put together pretty quickly.  The thing thats lacking everywhere is code to do it, examples, and specifics.

Ive been wading through this mess longer than I care to admit and trying to wrap my head around it and make working sketches.  I figure there are other people who want this.  And if i fail at it and do nothing more than give someone the database to build something off of, maybe I save them sometime.

Application Layer Protocol for KWP2000 ISO 14230-3
https://forum.arduino.cc/index.php?action=dlattach;topic=334778.0;attach=174852

Init Sequence:
https://www.blafusel.de/obd/vag_kw2000.html

Wiring Diagram for KKL leads.:
https://www.drive2.ru/b/2368649/
Im using the LM339N wired as the diagram shows, but only using pins 3, and 8-14.  Im connecting to the corresponding serial pins on a Teensy-LC, RX = 0, TX=1.

Right now I know the sequences with ME7Logger goes:
KWP2000 Fast Init Attempt
KWP2000 5 Baud Init (address 0x11)
Read System Supplier ECU Software Number
Start Diagnostic Session

At this moment, this sketch will:
KWP2000 5 Baud Init, Read System Supplier ECU Software Number, and start a Diagnostic Development Session

I understand that its not a lot, but its proof of concept.

i cant get the tp2.0 working on the me7.  I have an ECU on the bench.  right now the conversation goes

In:   55 EF 8F      Init Response
Out: 70               Inverse Response
In:    EE              Inverse Address
Out:  02 1A 94 B0     Read ECU Identification For System Supplier Software Number
In:    0C 5A 94 31 30 33 37 33 36 33 33 35 34 FD Positive Response
Out:  03 10 86 63 FC  StartDiagnosticSession DevelopmentSession
In:    03 50 86 63 3C  Positive Response

and then im not sure if its in or out:
21 F0 C4 E0 58 56 F7 84 F6 F0 0E 25 F2

Is it possible that the development session changes the baud rate?  im not sure what the 0x63  is

So another update:

The format change was due to the limitations of the Length in the header.  Once the message exceeds a certain length, the header becomes 0x00 and the the following byte is the transmission length.

Ive gotten through the configuration message.  The ECU is rejecting the tester present message.  Im working on the ECU on the bench, and just logging a single transmission. 

Ive written the following sketch to parse out the commands, addresses, and constant data blocks.

https://github.com/randumbintelrally/KWP2000_Sniffer

The idea is to be able to spy on ME7Logger and be able to duplicate its inputs.

I feel like im a few days away from having a working example of this.  Hopefully my optimism isnt short lived.

prj,
I was originally trying to work through the CAN-BUS lines using an MCP2515.  My concerns were primarily speed.  I had trouble sniffing the ftdi232 lines originally, but ive managed to get it working on a second attempt.  Ive just about got the program cobbled together.

I just got frustrated with everywhere finding people wanting to do this, but there not being any code of anyones project.

Ill be posting more up soon

   

I hate to say this but a open source C or python version of ME7Logger (to talk to a FTDI/CHxx) would be of much more general use, and would get more exposure for your project, and may attract more help, and would be easily portable to arduino if you architect it properly. Some FTDI/CHxx drivers would have to be C, of course, for tricky timing. Windows/Linux/OSX portability would be ideal, though OSX might be tricky.

In fact, if you can cobble together the right docs (no, avoid CAN and TPxx as prj suggests, stick to straight kline for now), I will try to spend some time on it. I do not have access to any ISO or SAE (14230, J3054 respectively) docs, however, so somebody else has to do the research or throw money at ISO.

And yes, prj, do not post any SAE docs here, nobody needs the hassle. ISO is maybe a bit "safer" to leak, but not by much.

PM me, though, if you want to discuss alternatives, depending on how much you trust me.

I might also add some sort of open-source ME7Info tool would be extremely useful; there are one or two projects that might provide a good start.

I dont have my head wrapped completely around everything and I havent tested this on a vehicle to make the correlations and work out the bugs.  But im getting mostly positive responses from an ECU on the bench and its doing everything ME7logger does, except the ECU responses are longer at the end.  Maybe I need the tester present message but ME7logger gets a negative response on that so I havent included it.

This is a long way from done and needs to be entirely rewritten

Step 1:  Load K_Line_Spy_Config.ino onto the Teensy
Step 2:  Use FTDI chip to LM339 chip to access ECU. Attach RX line from Teensy to RX line on FTDI chip
Step 3:  Run ME7Logger configured for your ECU with Serial Monitor Open.  Run to take single sample.
Step 4:  Serial monitor will produce the tables from ME7logger to configure the arrays in the config.h file
Step 5:  Load the Version_1.ino file onto the Teensy with the edited arrays in Config.h

You should get out the raw hex that ME7logger receives.  Not done.  But more improvement.  Im going to e able to start checking it for the 2.7t tomorrow and finding my references.  Then I can hopefully start polishing it up into something functional.

Im sure there are ways I could get more help or exposure, but right now I know what I know because of this site and the problems I have that Im trying to solve.

https://github.com/randumbintelrally/KWP2000_Access
https://github.com/randumbintelrally/KWP2000_Sniffer

This is awesome! 

I'll be using this for the FIS control because the current method is IMO very clunky.  This seems more refined!  Well done!

I confess I dont know much about arduino dev, but .h files should not have code.