This thread contains all the relevant data, and also there are KWP2000 specs posted on this forum as well.
It literally took me 2 days from knowing nothing about KWP2000 to getting a working logger.

Of course, nothing even closely as polished as ME7Logger, and of course it does not have the binary processor that ME7Logger has.
But it's not exactly rocket science.

That said, there is nothing you will accomplish functionality wise by making your own logger.
ME7Logger already uses the best possible method to log ME7, period.

Well, make one then.
The complicated part is detecting where the variables are in the bin, not making the logger itself.
And well, finding a bit of free RAM you can safely overwrite, and where the pointer the dynamic table is (unless it's always the same of course, which would make sense).

There is an XLS file in this very thread that shows exactly how ecuxplorer operates.
ME7Logger does _exactly_ the same thing, the only difference is, a higher baud rate is used and the AccessTimingParameters service is used to reduce the inter-byte and inter-message minimums to 0, and achieve the 50hz rate.

setzi62 took ecuxplorer's method and improved it, but the logger it is not original at all.
What is really good about ME7Logger is ME7Info - that is a much finer and more original piece of engineering, and this is what makes the package really good.

Hi guys,

Been poking around a bit with logging MED9.1 over CANBUS.

The information in this thread is really good, especially the traces in the spreadsheets and I’ve had a go at replicating this on MED9.1 over CANBUS. Up to now I’ve been logging using VCDS but I wanted to see how the RAM logging works. prj, I see you looked at something similar here. How did you get on? This might be a bit niche, even for this forum , but if anyone has played with this I’d really like to hear from you! All the services and codes I mention below are described in the KWP2000 protocol.

1)   What service are you using to read the RAM? I tried #23 ReadMemoryByAddress but it was rejected. Instead I used #2C DynamicallyDefineLocalIdentifier and read this with #21 ReadDataByLocalIdentifier.

2)   If you are also using #2C DynamicallyDefineLocalIdentifier, have you seen that only the last entry can have a size > 1 byte?

Valid examples (accepted by ECU)
One memory address:
{0x00, 0x08, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00}
Two memory address:
{0x00, 0x0E, 0x2C, 0xF0, 0x03, 0x01, 0x01, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10}
Three memory address:
{0x00, 0x14, 0x2C, 0xF0, 0x03, 0x01, 0x01, 0x80, 0x00, 0x00, 0x03, 0x02, 0x01, 0x80, 0x00, 0x10, 0x03, 0x03, 0x0F, 0x80, 0x00, 0x20}

Invalid examples (rejected by ECU)
Two memory address:
{0x00, 0x0E, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10}
Three memory address:
{0x00, 0x14, 0x2C, 0xF0, 0x03, 0x01, 0x0F, 0x80, 0x00, 0x00, 0x03, 0x02, 0x0F, 0x80, 0x00, 0x10, 0x03, 0x03, 0x0F, 0x80, 0x00, 0x20}

3)   Do you have the RAM address and scaling of some common variables (RPM, requested boost, actual boost etc)? I’d like to see if I can actually read them, but I don’t have the skill to disassemble myself and find them I’ve attached my bin if it helps.

4)   If there is a size limit of just one byte for all except the last entry in the DynamicallyDefineLocalIdentifier, how do you work around this for 16bit variables (two bytes)? Define two consecutive memory locations (one right after the other) and read one byte from each, effectively reading two byte?

5)   I was able to define at least 17 entries in a single DynamicallyDefineLocalIdentifier. I didn’t try any more than this, but it seemed at least it’s not restricted to just three like the thread suggest on ME7.1

6)   I also found the equivalent RAM tables where this resides in MED9.1 The addresses are 0x80 4334 and 0x80 38CC. For example, if I define a DDLI like this KWP2000 {0x00, 0x08, 0x2C, 0xF0, 0x03, 0x01, 0xAF, 0x80, 0x11, 0x22} it will populate the RAM tables like this:

RAM address - Contents
0080 4334 - 00 01 00 00 00 80 38 CC <- one entry in the DDLI, points to 0x80 38CC
0080 38CC - 00 AF 00 00 00 80 11 22 00 00 <- contains the size and address. In this case, size 0xAF starting at 0x80 1122

7)   I saw 10 DDLI’s in the RAM
0080 4334 - 00 01 00 00 00 80 38 CC
0080 433C - 00 00 00 00 00 80 39 6C
0080 4344 - 00 00 00 00 00 80 39 84
0080 434C - 00 00 00 00 00 80 39 9C
0080 4354 - 00 00 00 00 00 80 39 B4
0080 435C - 00 00 00 00 00 80 39 CC
0080 4364 - 00 00 00 00 00 80 39 E4
0080 436C - 00 00 00 00 00 80 39 FC
0080 4374 - 00 00 00 00 00 80 3A 14
0080 437C - 00 00 00 00 00 80 3A 2C

   I can see that ecuxplorer and setzi62’s ME7Logger write to the RAM tables directly #3D WriteMemoryByAddress but unfortunately when I try this on MED9.1 it is rejected. Has anyone been able to write to the RAM on MED9.1?

9)   Also attached is a log where I define the DDLI and then dump the RAM. This helped me to find the RAM tables that the DDLI lives in.

As always, thanks!

This seems like a bad idea, since you sample the two bytes before and after the value has changed.

@Basono

At which security level (seed&key) did you try use service #23 ReadMemoryByAddress?

20 definitions is the limit, but if I recall it correctly, then each definition signifies a memory range!
So you can define 20 memory RANGES that you can log simultaneously.

This is more than enough considering many variables are placed sequentially after one another.

To find the addresses of the variables you have to parse the table that contains all of them. Look at the MED9 FR, it lists a lot of variables in a certain order. All you need to do is find where this list is stored, parse it, and voila, you have all the variables required.

Whoops. It was staring me in the face

The w in _w is for word. So nmot_w is 16 bits. Answered my own question.

Logged nmot_w again (two bytes this time!) and multiplied by 0.25 (scaling factor). I get the rpm in high resolution

What hardware are you using ? Lawicell ?
Also, C ? C++ ? C# ?