carl0s
Newbie
Karma: +0/-0
 Offline
Posts: 22
|
 |
« on: November 15, 2017, 05:47:09 PM »
|
|
|
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 ?
|
|
|
|
« Last Edit: November 15, 2017, 05:58:12 PM by carl0s »
|
Logged
|
--
Carl
|
|
|
|
nyet
|
|
« Reply #1 on: November 15, 2017, 07:13:18 PM »
|
|
|
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.
|
|
|
|
« Last Edit: November 15, 2017, 07:22:47 PM by nyet »
|
Logged
|
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #2 on: November 15, 2017, 07:26:38 PM »
|
|
|
rkat is 16 bit
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 ?   |
|
|
|
|
Logged
|
--
Carl
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #3 on: November 15, 2017, 07:29:19 PM »
|
|
|
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.. :-/
|
|
|
|
|
Logged
|
--
Carl
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #4 on: November 15, 2017, 07:31:01 PM »
|
|
|
Data type 7 must mean 16 bit.
I'm just trying to make sure I can understand the factors for my Arduino datalogger.
|
|
|
|
|
Logged
|
--
Carl
|
|
|
|
nyet
|
|
« Reply #5 on: November 15, 2017, 07:39:53 PM »
|
|
|
No, that is two different rkat values, like you said.
likely 6,7 and 8,9, little endian.
|
|
|
|
|
Logged
|
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #6 on: November 15, 2017, 07:46:41 PM »
|
|
|
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 |
|
|
|
|
Logged
|
--
Carl
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #7 on: November 15, 2017, 07:48:35 PM »
|
|
|
No, that is two different rkat values, like you said.
likely 6,7 and 8,9, little endian.
I think byte 9 is the CRC so can't be ! |
|
|
|
|
Logged
|
--
Carl
|
|
|
|
nyet
|
|
« Reply #8 on: November 15, 2017, 07:52:10 PM »
|
|
|
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 |
|
|
|
|
Logged
|
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #9 on: November 15, 2017, 07:54:47 PM »
|
|
|
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 |
|
|
|
|
Logged
|
--
Carl
|
|
|
|
nyet
|
|
« Reply #10 on: November 15, 2017, 07:55:46 PM »
|
|
|
I was counting from the first 00... I'm doing that wrong then? Thanks for your help based on what? |
|
|
|
|
Logged
|
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #11 on: November 15, 2017, 07:57:00 PM »
|
|
|
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)" |
|
|
|
|
Logged
|
--
Carl
|
|
|
carl0s
Newbie
Karma: +0/-0
Offline
Posts: 22
|
|
« Reply #12 on: November 15, 2017, 08:05:08 PM »
|
|
|
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..  |
|
|
|
|
Logged
|
--
Carl
|
|
|
|
nyet
|
|
« Reply #13 on: November 15, 2017, 08:06:40 PM »
|
|
|
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)
|
|
|
|
« Last Edit: November 15, 2017, 08:10:18 PM by nyet »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #14 on: November 15, 2017, 08:08:55 PM »
|
|
|
wtf are documents really 1 based? that is idiotic. editing post above
|
|
|
|
|
Logged
|
|
|
|
|
