Yes that is possible. But since the service ID´s (and PID´s either) are in a different range, you need to do all the equations yourself. Racechrono works with SID 0x01 to show current data, UDS uses 0x21. You set RC to not use the OBD2 standard and use the channel editor to set your values. Additionally you will need an initialization sequence, to change the header data, keepalive message and so on.
But you will need to know about those pid´s, equations, and so on. This depends on the manufacturer.
So I have the PIDs and equations through sniffing. I know how to call stuff like 0x22XXXX or 0x23XXXXXXXX for data, but what I'm trying to do is start a diagnostic session (10 03) and then call "fast" periodic data (2C 03 and 2A 03).
My Kawasaki f.e. takes: ATWM8011F1013E\\nATSH8111F1\\nATFI\\nATSH8011F1\\n021080
Which means: ATWM8011F1013E -> Set Keepalive message ATSH8111F1 ->Change header to format 0x81 ATFI -> Fast Initialization ATSH8011F1 -> Change header to format 0x80 (with length byte) 021080 -> Start Diagnostic Session (Length + Start)
Afterwards, you can define your fast channels with your equations.
There is a section for OBD II channels, where you can add your custom requests. You have to select the channel, to where the data belongs to (f.e. RPM). Then add the SID & PID and the equation. Like: Channel: Engine RPM Parameter ID: 07e0 Equation: bytesToUint(raw, 7,2)
Where the equation should take the 7th byte and two bytes in total, which should lead to f4 0c or 62476 in decimal. Which must be calculated further. By dividing by 100 and multiplied by 2 or something. That´s what you must find out.
Can you tell me more about your logger, how you grab the data and which vehicle you are trying to analyze? Just seeing the raw data, not knowing if it is complete or there might be a header around it, without any indication I cannot help you any further.
The data you posted does not have any lead to any kind of format I know from K-Line. So I guess it´s incomplete. Like the OBD Link does the header and checksum calculation on it´s own and you only see the data via bluetooth.
This isn't for K-line. It's ISO 15765 (11 bit CAN) or 14229 (UDS).
So 0x7e0 is the header not the PID, and converting the bytes to usable data isn't an issue. However, 0x6e0 or 0x6e1 are not headers.
The other logger is from HPTuners and it works with their VCM Scanner software. It only connects to the PCM (0x7e0), so I'm trying to use their method to get ABS, BdyCM, etc. I have sniffed the packets a few different ways, but I can post more data if you want to see it. Assume its something like wireshark. What I posted above is the cleanest way I could show what I'm trying to do (cut down on requests and delay). The data doesn't look as clean as stuff like USBtoCAN because its also looking at the USB protocol, FTDI stuff and the payload.
Comments
Racechrono works with SID 0x01 to show current data, UDS uses 0x21.
You set RC to not use the OBD2 standard and use the channel editor to set your values.
Additionally you will need an initialization sequence, to change the header data, keepalive message and so on.
But you will need to know about those pid´s, equations, and so on. This depends on the manufacturer.
So I have the PIDs and equations through sniffing. I know how to call stuff like 0x22XXXX or 0x23XXXXXXXX for data, but what I'm trying to do is start a diagnostic session (10 03) and then call "fast" periodic data (2C 03 and 2A 03).
https://racechrono.com/forum/discussion/comment/10064/#Comment_10064
My Kawasaki f.e. takes:
ATWM8011F1013E\\nATSH8111F1\\nATFI\\nATSH8011F1\\n021080
Which means:
ATWM8011F1013E -> Set Keepalive message
ATSH8111F1 ->Change header to format 0x81
ATFI -> Fast Initialization
ATSH8011F1 -> Change header to format 0x80 (with length byte)
021080 -> Start Diagnostic Session (Length + Start)
Afterwards, you can define your fast channels with your equations.
I’m assuming I add 021003 to init. 02 - length, 10 - diagnostic session, 03 - extended.
For periodic data requests where do I add 0x2c01 or 0x2a01 for example?
I have another logger I sniffed and the output is this:
0x7e0: 10 08 2c 01 f2 00 f4 0c (rpm)
0x7e8: 30 00 0F
0x7e0: 21 01 02 00 00 00 00 00
0x7e8: 04 6C 01 F2 00
0x7e0: 03 2a 03 00
0x6a0: 00 0c 09 00 00 00 00 00
0x6a1: 00 0c 09 00 00 00 00 00
0x7e8: 01 6A
0x6a0: 00 0c 09 00 00 00 00 00
0x6a1: 00 0c 09 00 00 00 00 00
0x6a0: 00 0b fc 00 00 00 00 00
0x6a1: 00 0b f9 00 00 00 00
…
a lot of 0x6a0 and 0x6a1 data
…
0x7e0: 02 2a 04
So I think 0x7e0 is the only Tx data and 0x7e8, 0x6a0 and 0x6a1 are Rx data. This is only 1 pid coming from the pcm.
Where would I add the 0x2c 03 or 0x2a 01 to individual PIDs? The command itself? I can’t get it to work.
You have to select the channel, to where the data belongs to (f.e. RPM). Then add the SID & PID and the equation.
Like:
Channel: Engine RPM
Parameter ID: 07e0
Equation: bytesToUint(raw, 7,2)
Where the equation should take the 7th byte and two bytes in total, which should lead to f4 0c or 62476 in decimal. Which must be calculated further. By dividing by 100 and multiplied by 2 or something. That´s what you must find out.
Can you tell me more about your logger, how you grab the data and which vehicle you are trying to analyze?
Just seeing the raw data, not knowing if it is complete or there might be a header around it, without any indication I cannot help you any further.
The data you posted does not have any lead to any kind of format I know from K-Line. So I guess it´s incomplete. Like the OBD Link does the header and checksum calculation on it´s own and you only see the data via bluetooth.
This isn't for K-line. It's ISO 15765 (11 bit CAN) or 14229 (UDS).
So 0x7e0 is the header not the PID, and converting the bytes to usable data isn't an issue. However, 0x6e0 or 0x6e1 are not headers.
The other logger is from HPTuners and it works with their VCM Scanner software. It only connects to the PCM (0x7e0), so I'm trying to use their method to get ABS, BdyCM, etc. I have sniffed the packets a few different ways, but I can post more data if you want to see it. Assume its something like wireshark. What I posted above is the cleanest way I could show what I'm trying to do (cut down on requests and delay). The data doesn't look as clean as stuff like USBtoCAN because its also looking at the USB protocol, FTDI stuff and the payload.
I THINK this is what the data means:
0x7e0: 10 08 2c 01 f2 00 f4 0c (rpm)
0x7e8: 30 00 0F
0x7e0: 21 01 02 00 00 00 00 00
@TriB is what wireshark gives me. It’s a mess but this is FILTERED for only Tx and Rx payloads. For reference, f40c is RPM and 032b is acc pedal.