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 31
    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 :(
Sign In or Register to comment.