CAN DPID Support

This was spawned as a result of this thread: , but the car I'm messing with now is a new CAN vehicle, and enough of the material was different, that a separate thread made sense to me.

The intent is the same-- I can built out a DPID with whatever I want to log and in a single request, get all of the responses/data in a single (big) response. In addition, this is direct memory logging, so I am not limited to whatever the manufacture decided to make available via PID. For example normally all engine data is available on ECU (0x7E0), but brake pressure/steering angle is only available in the brake module (0x713) etc. All of which really slows down the logging rate. With direct memory logging and DPID, all of those things are available from the ECU.

Anyways, I have candumps of what I am trying to do and I understand what needs to happen, but I am having a bit of trouble setting up the elm327 init command in my vehicle profile.

Here is the raw traffic of building out the DPID and the first response.

can0 7E0 [8] 10 2C 3E 04 08 D0 00 C7
can0 7E8 [8] 30 00 02 AA AA AA AA AA
can0 7E0 [8] 21 75 01 D0 01 21 68 02
can0 7E0 [8] 22 D0 01 3C C0 02 D0 01
can0 7E0 [8] 23 98 1A 01 D0 00 DE 4C
can0 7E0 [8] 24 01 D0 00 98 74 04 D0
can0 7E0 [8] 25 00 C6 9C 01 D0 00 F1
can0 7E0 [8] 26 E0 01 6C 00 00 00 00
can0 7E8 [8] 02 7E 04 AA AA AA AA AA

can0 7E0 [8] 02 3E 05 00 00 00 00 00
can0 7E8 [8] 10 0E 7E 50 00 00 E0 28
can0 7E0 [8] 30 00 00 00 00 00 00 00
can0 7E8 [8] 21 80 53 43 FF A9 47 00
can0 7E8 [8] 22 80 AA AA AA AA AA AA

A little bit of explanation:

Building the DPID:

- 10 2C - 0x2C (44) bytes in this message
- 3E 04 08 - this tells the ECU that we are about to build the DPID, with 08 total parameters being defined
- ECU responds with flow control values for the tool to send the following msgs
- D000C77501 - memory address of the first param (d000c775) and the expected response will be 01 bytes long
- D001216802 - memory address of the second param (d0012168) and expected response will be 02 bytes long
- etc. for all 8 params
- I'm not sure what the "6C" at the end is.
- 7E 04 - ECU acknowledge receipt

The request/response:

- 3E 05 - tool requesting DPID data to be sent out (the 'PID' defined in racechrono)
- 10 0E - 0E (14) bytes in this message
- 7E - "response to 3E request" I believe
- Flow control message from ECU
- 50 - first param response, in this case 1 byte (coolant temp)
- 00 00 - second param response, in this case 2 bytes
- etc for all 8 params

My 2 big questions are getting the init command set up correctly, and does RC support the long "multi frame" requests/responses etc? This is probably part of the ELM327 commands, which I am trying to muddle through at the moment but I've never used it before.

I've tried these 2 init commands so far but no luck. Looking at candump, it's not even sending anything to build the DPID, so I am messing something up for sure.



Any tips on setting up the init command?


  • edited July 2021
    Well, I got it working basically 100% and it's better than I expected.

    As set up above, I defined the DPID for 8 params / 14 bytes total.

    Logging I am getting 30-50hz refresh rate or about 400 total updates a second or 700 bytes/sec. I think as I add more stuff there will only be a minimal decrease in logging rate.

    Normal Mode $01 or $22 logging (not logging from multiple modes or modules) I get around 50 total updates a second at best. Which would be about 5-6hz refresh rate. So this is around 8x faster/better overall, plus I'm not limited by what's available via PID.

    I had to use 2x "ST" commands so generic ELM327 won't work. The keys were:

    STCSEGT1 and STCSEGR1, basically to allow long, multi frames messages for both RX and TX. Init script I settled on is in the screenshots.

    Init command


    Defining PIDs

    Other than being a little labor-intensive to set up, only issues I had was dealing with converting a 4 byte float value.

    4 byte float
  • I about doubled my logged params and logging rate seems to be not taking a hit at all.
  • Well, I think I'm about done tinkering with it but I'll keep spamming my own thread to keep the content here lol.

    Really happy with the end result! Logging 17 things at ~45 hz including steering angle, brake pressure, car's internal accelerometers and something that sounded like slip angle....we'll see what that's about.

    Having BT audio connected and/or playing BT audio does slow down the rate, but didn't really see it dip below 20hz, so that's plenty.

    @aol any chance to get IEEE 754 float support? The primary manifold pressure values for this car are floats, but I found some other params that are in more typical 2 u-bytes etc.? Not urgent for me by any means, but throwing the idea out there! The new "little endian" functions were needed for my car as well, thanks for adding those.

    Quick video I made to show some folks the progress and the responsiveness of it.

  • That's an 2017 Audi S3, right?
  • @aaronc7 added bytesToFloat() and bytesToFloatLe() on my TO-DO list.
  • Just adding to say this is cool. Did you get rid of your c5 track car?

    I didn't realize that CAN had DPIDs as well, though I guess it makes sense.
  • @jlvaldez Nope, still have the C5 as well. It gets neglected mostly though :(
  • @aaronc7 i got an audi s4. i'd like to know how did you figure out the memory address of each parameter. The only device i have is bluetooth elm327. is it possible that i can figure out which memory i should look into. if not what device should i get?
  • @asd0008asd Hey, unfortunately it's not a trivial task. Or I should say it's not a trivial task unless you have a good definition file such as an a2l. I'm not sure what generation S4 you have, but iirc none of them are simos18 ecu, so what I have won't translate.

    You also need an OBDLink device for this to work, as I utilized the "ST" command set to set up the DPID.

    I would recommend OBDLink LX or MX either way. Much more realistic for you to track down some manufacture specific "mode 22" PIDs to add via custom PID feature.
  • @aaronc7 Thanks. Before i read your post, i was thinking about plug 2 device to the obd with a dual connector cable. one for elm327 the other for vw5054 diagnostic equipment. so that i can sniff the CAN bus through elm327. As you mentioned the definition file, i also have a 2012 Audi A3. Is there any way to find a definition file? i dont really understand what is a a2l.
  • A 40-70MB text file full of tons of info... a lot to sift thru but it has every memory and table address etc. Usually only available via shady internet websites, good luck lol.

    That's exactly how I did a lot of my reversing. Simple OBD splitter and some other app such as VCDS or OBD11. Honestly this route is the way to go for Racechrono, exactly what it's set up to do.

    What I did with the memory logging/DPID was kind of a hacky way to do it, but still very cool that the app supports it. I would not expect racechrono to support this kinda thing as each vehicle implements it differently etc.
  • @aaronc7 i already have the .hex file and .a2l file. i also opened them up in winols. is there any way that i can get the memory address for my car as you did for your s3.
  • @aaronc7 i read the a2l file and i found the MEASUREMENT ADDRESS. i tried to reach the ecu memory through UDS $23 or $3E but both returns 0x7f which means error. i tried to use $22 to read my VIN and it worked but i got no more identifiers to look into. is there any way to get the relationship between UDS identifiers and their meanings through A2L file? if not what file will i need?
  • What car and ECU is this exactly? I'll try to dig around some. If it's Bosch it may support $2C but that may require security access

  • @aaronc7 It's a 2012 Audi A3 8P. The ECU part number is 03c906016bl and i think it is a Bosch one.
  • @asd0008asd I am slowly looking into MED PID stuff. There's so many versions and I have no idea if one is compatible with the next.
  • edited January 2022
    @aaronc7 IEEE-754 floating point support coming on next minor release, just got all tests done today. bytesToFloat() will do standard 32-bit and 64-bit floats, and bytesToFloatLe() will do similar, but with reversed byte order.
  • Awesome thank you! @aol
  • This is very cool! Will try to figure out something similar for Toyota GR Yaris.

    I see that when using DPID you configure RaceChrono with 3E05 PID. Does RaceChrono send 3E05 for every measurement configured? Since every measurement values are returned with every response, it would be possible to increase the rate of the values if multiple measurements could be extracted from a single request/response.
  • No idea if the GR Yaris supports DPID, but this is exactly for increasing the update rate. Multiple channels are extracted from one OBD-II response.
  • $3E 05 is very specific for this ecu and is even an aftermarket logging patch

    Most OEM DPID logging would be some form of Mode $2C (Dynamically Define Data Identifier) to build the DPIDs and then either $22 or $2A (Read Data By Identifier Periodic) to get the actual data responses.
Sign In or Register to comment.