NefMoto

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 ?

rkat_w is 16 bit (denoted by the _w)

Also, don't use all caps. By convention, maps are all caps, variables are lower case.

Thanks :)

I was just realising the same :D

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 ?

(http://www.internetsomething.com/bmskp/rkat_table.png)

(http://www.internetsomething.com/bmskp/rkat_trace.png)

oh.. wait a minute..

it's bytes 6 & 8.. not 5 & 6..


So it's FF 00. (-256).

That still gives me a result of 12 though..  :-/

Data type 7 must mean 16 bit.

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

No, that is two different rkat values, like you said.

likely 6,7 and 8,9, little endian.

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 think byte 9 is the CRC so can't be !

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

I was counting from the first 00... I'm doing that wrong then? Thanks for your help :)

based on what?

Just trying to decipher it..

Actually my notes from just before, I wrote:
"(there 62 is positive response, and the 40 04 is the same commonidentifier as in the request)"

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..

(http://www.internetsomething.com/bmskp/kwp.png)

I don't know why 4 and 5 are not used, but in the rest of your table, the responses always start at byte 4

so in your response,
byte 0 is 8b
byte 1-3 are f1 12 62
byte 4 5 are 40 04
byte 6 7 are 00 00 (rkat)
byte 8 9 are 00 00 (rkat2)
byte 10 11 are 7f ff (fra)
byte 12 13 are 00 00 (fra2)
byte 14 is b2 (crc)

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

OH yeah. I didn't notice that FRA and FRA2 are in the same packet. d'oh!

Thanks! I owe you some beer :)

OK bedtime, work tomorrow.

What do you mean?

00 00 is the correct number I was hoping to find! it calculates.. the engine is off, and the value should come back to zero.

Thanks again!

I understand the problem now :)

The table counts from the beginning of the packet.

The documentation I was reading is just explaining the Returned Data part of the packet..