UDS protocol with ELM327?

Probably a dumb question… but is it possible to use UDS protocol (14229) with an ELM327 device like the MX+?

Comments

  • 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.
  • @TriB

    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).
  • There is already a thread, which describes how to set the initial values (protocol, header & keepalive), then fast init and start diagnostic session:
    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.

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

    I THINK this is what the data means:

    0x7e0: 10 08 2c 01 f2 00 f4 0c (rpm)

    • 10 = length
    • 08 = not sure
    • 2c 01 f2 00 = define by Identifier
    • f4 0c = PID for RPM

    0x7e8: 30 00 0F

    • FC frame, 0F = 16ms timing?

    0x7e0: 21 01 02 00 00 00 00 00

    • Consecutive Frame #1
    • After 21, Im not sure what 01 02 00 is


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

Sign In or Register to comment.