Custom PID Help

Hey all. I have used the RaceChrono Custom PID feature and been testing/using it since the early days. Great results on one of my cars which is more modern/CANBUS etc.

I'm trying to define a few for my track car which is older. OBD2--J1850 VPW 10.4kbps--2003 Corvette Z06

I was poking around in Torque Pro today and some useful PIDs that are apart of the apps "GM pre-defined custom PID set". For example Knock Retard, EGR V (I have my wideband sensor wired to this, so I could log AFR or fuel pressure etc), Trans temp, etc.

These custom PIDs were working in Torque and all of the definitions visible.

When I put the info into RaceChrono, I just get "NO DATA". I tried a bunch of random stuff like different OBD header such as "0x7E0" which is what one of my other vehicles luck. The OBD header is simply "Auto" in Torque.

I took some screenshots of the "command" and "response" within Torque to maybe help shed some light on this for someone who is smarter on this.



  • OK slight update to original post. And ignore the original post picture, I have newer ones.

    I figured out the OBD Header for this particular ECU/car is 6C10F1.

    In my test example of EGR voltage, I get a response of "7F22114B12", just the same as Torque app.

    In the Torque picture, I can't figure out how it is getting A=7C=124

    I think this is the last piece of the puzzle for me to get it working in Racechrono.


  • Here is a good reference for VPW comms:

    Requesting enhanced PID example towards the bottom.

    Maybe this is simply a limitation of the app in it's current form, being pre-CAN and all.
  • edited June 2020
    @aaronc7 The response is not a standard one, and RaceChrono thinks it's an error.

    Are you sure that it is "real" data, and not an error that is invalidly translated to data by Torque? If you are really getting actual data on Torque, I can make this work once my work current load eases off a little bit. And I cannot figure out the A=7C either... There's no such byte in the response...
  • OK I figured it out! Looking at the link from "fast fieros" it showed an example for requesting an enhanced PID:

    Send: $6C,$10,$F1,$22,$PID-hsb,$PID-lsb,$01
    Recv: $6C,$F1,$10,$62,$PID-hsb,$PID-lsb,[up to 5 data bytes]

    I noticed the "01" at the end.... it's my understanding that this means that we are expecting 1 byte reply. I wasn't sure if this was added automatically by Racechrono or what, so I tried adding it manually to the end of the PID. Whala--- a 2 byte response was received and the 2nd byte was the data we need.

    Fuel pressure:

    It seems when I try to datalog both standard SAE pids and these custom ones, the standard ones time out after 1 data pull and then update rate of the custom ones tank (as expected, since we are jumping back and forth between different OBD headers or whatever).

    This is still pretty good though, at least I can log/monitor these things if needed.
  • edited June 2020
    @aaronc7 Very good!

    I think I know why the standard PIDs do not work together with the custom ones. RaceChrono switches to the custom PIDs' header (0x 62 10 F1) in order to poll them, it needs to switch back to the default header to poll the standard PIDs.

    But RaceChrono does not know how to do this properly, as your car uses 29-bit CAN-Bus addressing. RaceChrono uses 11-bit default header 0x7DF, and it's not even supposed to work for 29-bit bus... I'm not sure what the equivalent is for 29-bit CAN-Bus.

    But what ever the 29-bit CAN-Bus default header is, you should enter that to the "Default OBD-II header" setting in your vehicle profile. I believe once you enter correct value there, it will work! If you cannot crack it, I could try to Google it :)
  • edited June 2020
    @aol Good info, I think I can figure it out, but if you find it before I do, please do share!

    It's my understanding that the breakdown is like this:
    6C: physical node to node mode
    10: ECU address
    F1: Scan tool aka return address

    According to the fast fieros link, $6A and $6B are the functional addresses/modes, so I suspect it's one of those for the standard PIDs. I'll mess around some more soon.
  • edited June 2020
    OK, the default header for VPW J1850 is 68 6A F1. Put that in as the default header and works like a charm. To my surprise, logging both default header and custom PIDs only had a very small impact on overall logging rate. On newer CAN vehicles, this seemed to almost halve the logging rate...but for this system, it only had a very small impact on performance. Which is good, because overall it's much slower. As long as I can maintain 5hz average I am happy for this application.

    PID view:
    Standing PIDs only 30-35 pid/s:
    Combo 25-30 pid/s:
  • edited June 2020
    The header switch happens only twice in the cycle, and it affects only the Bluetooth bandwidth as this changes only the internal state of ELM 327 device. That said, each of the commands (including PID requests) means waiting for response too. But this means the header switching overhead does not grow if you add more standard or custom PIDs with the same header, as total switches per cycle is still two.

    PS. I cannot view the screenshots.
  • Good to know. Yeah I had issues clicking the links too. It's removing the .png for some reason in the url. No worries, just showing what I was talking about.

    Well I guess case closed. Thanks for the help and chimining in per usual!
Sign In or Register to comment.