Hi. I am still learning...

Doing KWP logging of my K1300s bike.

I have some things in common with the ME7Logger fields, including a lot of the factor numbers

I'm stuck though on understanding the ECU responses I have.

RKAT, is a signed int , has factor (FACT_A) of 0.046875 (3/64).
It's supposed to represent fuel trim (additive) as a 'real'

How can it work? It surely can only give -6 to +6 if that's the case ?

Can someone enlighten me ?

Thanks

I was just realising the same

I've been confused because there is a list of some KWP request codes (TELEGRAM..) , which i have logged, and I thought RKAT was one, and RKAT2 was another.. like Left / Right Banks (even though there's only one bank on this engine).

So RKAT and RKAT2 are just splitting the 16 bits into two separate bytes in this table ?
The request is the same.. both come back in the same packet, just strange that they split it like this.

On that basis, how do we calculate this response ? (RKAT = FF, RKAT2 = 7F) ? Isn't that 32767 * 0.046875 ? or -129 * 0.046875 ? neither look good or right..

I was thinking maybe it could be a simplified output of RKAT, for limited diagnostic purposes maybe ?

Data type 7 must mean 16 bit.

I'm just trying to make sure I can understand the factors for my Arduino datalogger.

Ah that makes sense..

I'll try some more number crunching. I really am terrible when it comes to this stuff but I'm trying to learn. 2s complement for signed ints, mod 256 / 8 bit sum crc, blah blah.. it doesn't come to me easy !

Here's the (pseudo) asm code that runs with the table above. I tried to follow it through but I struggled with a value for I2, and also it looked to me like it skipped the factors altogether because COMP_TYPE = "--"

http://www.internetsomething.com/bmskp/RKAT.asm.txt

I doubt it.

the last byte is the crc, so that is byte 10

6,7 is 7f ff
8,9 is 00 00

crc is b2

clearly a 4 byte header, 10 byte payload, 1 byte crc

based on what?

it's 3am here so maybe I need to pick this up again tomorrow. Was up 'til 4am yesterday and 5am day before..


It's KWP code 0x22 readDataByCommonIdentifier, and the RecordCommonIdentifier is 40 04.

the positive response is the 22 with 40 added to it.

i forget the first byte. Next two are source and target.

I think you already know much more than me about this though, but the docs say that the data packet starts after the recordcommonidentifier (40 04), so I was counting from the first 00 byte..

wtf are documents really 1 based? that is idiotic. editing post above