MX5 NCcustom PIDs from Torque format - Help

edited January 2021 in General
Good morning everyone,

I managed to find custom OBD2 PIDs for Mazda MX-5 NC, including steering angle, brake pressure switch and accelerator pedal position.

The data are coming from an old thread at forum, people are actually able to use those PIDs in Torque Pro (the total list includes a lot of Mode 22 custom PIDs...)

These are the PIDs of interest for me:

"Name" "ShortName" "ModeAndPID" "Equation" "Min Value" "Max Value" "Units" "Header" "startDiagnostic" "stopDiagnostic" "Scale"
MX5_Brake Pressure Applied Switch BPA_SW 0x22a211 BIT(A:1) 0 1 On / Off 7e0 null null 1

"Name" "ShortName" "ModeAndPID" "Equation" "Min Value" "Max Value" "Units" "Header" "startDiagnostic" "stopDiagnostic" "Scale"
MX5_Accel Pedal Position (full range) APP 0x221340 A*0.3921568627 0 100 % 7e0 null null 1

"Name" "ShortName" "ModeAndPID" "Equation" "Min Value" "Max Value" "Units" "Header" "startDiagnostic" "stopDiagnostic" "Scale"
MX5_Steering Wheel Angle STEER 0x223201 (A*6.25)-800 -485 485 ° ABS null null 1

My problems are:

1. For the brake pressure applied switch the Equation is BIT(A:1). I looked up on Torque website what the BIT fucntion does:
Returns the bit specified at 'bit' from the 'value'. This function replaces the use of the {value:bit} notation"
Not sure what this translate to in RaceChrono equation format... I'm guessing that "A" in Torque does not have the same meaning of "A" in RaceChrono.

2. For the Accel Pedal Position (full range) I managed to read a value, meaning somehow the custom PID is working. Problem is: the only value I'm reading is 25.xx% even if I press 100% of the accelerator pedal. I guess, again, something odd with the equation format of Torque?

3. Steering Wheel Angle... here I'm lost. The main issue here is the header value, that is "ABS", that is not ok with RaceChrono header format acepting only hexadecimal or decimal... This is also the most important value I'm looking to log.

Can someone help? I'm feeling I'm so close to have the solution to these issues!


  • Have you seen ?

    You can probably do something like bitsToUint(raw, 0, 1) for the brake pressure switch.

    See also for some PIDs I've found for ND, there might be some overlap.

  • Thanks, I'll try tomorrow if the corrected formula works for the brake switch, and I'll try your pids for ND2 (i don't think they'll work, but it's worth trying)

    Just out of curiosity: how did you manage to find those PIDs for the ND2?

    Any suggestions for the steering angle?

  • Try 0x760 for the ABS header
  • @aaronc7 amazing, that helped me to solve the steering wheel angle one! Also changed the formula using B instead of A (using A the live data where not changing, i saw that only the last part of the live data string where changing so I used B as extracted value) and multiplied all by 2...

    So, for the steering wheel:

    HEADER: 0x760
    PID: 0x223201
    EQUATION: 2*((B*6.25)-800)

    I checked the rotation at 0 180 and 360 both sense and it is consistent. The limits should be -485 and +485 while it is measuring -475 and +475. At 90° it is changing from 87.3 to 100, I don't know if it is an issue in the formula or it due to the quantization of the instrument

    For the accelerator position. This is the real position of the accelerator pedal, not the throttle valve position. This should vary from 0% to 100%. Following the same approach for the steering wheel I've changed the formula using B instead of A.

    So for the acceleratot pedar position:
    HEADER: 0x7e0
    PID: 0x221340
    EQUATION: B*0.3921568627

    For brake still no luck... For sure it is a matter of getting the right bit extracted. I found that for clutch pedal on Torque the equation is BIT(A:0) so maybe the 0 and 1 are actually the offset, then BIT(A:1) should actually be translated to bitsToUint(raw,0,1)
  • @timurrrr sadly those ND2 codes are not working on my NC2 car
  • Ah, sorry fot the "where" instead of "were", writing from Italy on a dumb-corrector keyboard :smiley:
  • edited January 2021
    @jeby To properly translate the Torque app's equations to RaceChrono, you should look Torque documentation for full understanding what the equations do. Otherwise it's always a bit guess work (yes, I do not know their equations properly either!). But anyways, about bits and bytes, the numbering _usually_ starts from 0. But the bit 0 can be either most significant or least significant.

    BIT(A:1) in torque probably means bit offset 1 of byte A. But since you had to change A to B in RaceChrono, you should use the byte B for this one as well.

    BYTE ---A---- ---B---- BIT 01234567 01234567 I -------- -X------ II -------- ------X-

    So depending on what BIT(A:1) means in Torque, the bit position is as above. I'd say it's likely that the most significant bit is 0, so it would be as choice I) in above chart. In RaceChrono you would get it with equation bitsToUint(raw,9,1). To get the full bytes you can use bitsToUint(raw,0,8) and bitsToUint(raw,8,8) to see what changes when you press the brake!
  • @aol thanks! Yes, the hardest part is trying to understand what the Torque formula means, expecially the variable A, B, C etc... I think I've a looong road ahead of me.
    So far I found this page
    "{A:b} — returns the bth bit of the byte A. Least significant bit is 0, example A = 00001010b = 09h, {A:0} = 0; {A:1} = 1"

    For the steering wheel angle...

    I checked the live raw data for the two limits of the steering wheel:
    For the steering wheel all turned to one side I get
    For the steering wheel all turned to the other side I get

    So, first of all. The original formula from Torque is: "A"*6.25-800. I checked: the lock to lock it is actually 2.7 turns or something, that checks with the -485/+485 I'm reading on the list where I found this value.

    The value of "A" must be centered on 128 (128*6.25-800 = 0°), must start from 51 (51*6.25-800=-481.25) and end to 205 (205*6.25-800=+481.25)... or maybe 50 - 206

    But, checking the live raw data I found nothing like that, if I'm not wrong I'm reading
    A - B - C
    1 - 167 - 16
    1 - 90 - 88

    Correct? as you can see the interval 90 - 167 it is bringing exactly alf the information of the interval 51 - 205...

    So for now I'm workin with B*12.5-1600, but this means that I've half the information I should have (12.5 increment of the values instead of 6.25)

    Am I missing something? Is it possible that the "C" part of raw data contains some usefull information? Or that Torque is parsing the response differently?

    Thank you
  • Sorry if I'm repeating above info, but many times where I used "A" in Torque... I had to use bytestouint(raw,1,1) for Racechrono. For whatever reason in the response, the first byte (byte 0) isn't actual data, but the last digit of the PID itself. Anyways, often times I just look at the actual response in the user interface and usually it's pretty easy to ID what's going on and figure out if you need to do raw,0,1 vs raw,1,1 , etc.

    Torque A is raw,0,1. Torque B is raw,1,1 etc etc.

    2 byte returns are way easier to deal with in Racechrono vs Torque you usually have do something like A*256+B.... vs in Racechrono it's a simple bytestouint(raw,0,2) or whatever.

    Hope this helps!
  • @aaronc7 yes, it helped, most of all helped the advice to look at actual rensponse :) and as you said the way RaceChrono is handling the math is way easier than Torque.

    I think that "A" in Torque is changing depending on mode and PID
    "To get the variables for the *whole* raw data reply, you can now use the following variables:
    R0, R1, R2, R3 (etc) where in most cases R3/4 would equate to ‘A’ in normal mode21/22/01 messages (depending if you’re using canbus or an iso protocol like 9141)"

    This got me thinking... so I started from scratch

    With the steering wheel at centered position raw data shows
    0x 01 80 00
    then moving the steering wheel a little bit
    0x 01 80 14

    That's it, I need both second and third bytes (the first is, as said, part of the PID code)

    8000 converts in decimal to 32768 so my equation started as

    steering wheel all to right was 0x 01 A7 10 so the equation result is
    42768-32768 = 10000

    Using Forscan I measured 500° when steering all to the right, so I see there is a factor 20

    the equation was then
    I tested this and I was happy of the results except that it was only showing integer... I think I will go for (bytestouint(raw,1,2)-32768)*0.05 or float (bytestouint(raw,1,2)-32768)/20

    I really don't understand how this relates to the Torque formula but... well... I don't care much :smile: better to have an equation that is working and you know where it comes from than something just given to you.

    Then I moved to the brake switch: data is switching from
    0x 11 04 02
    0x 11 04 03

    So, looking at the whole response (including first byte) in binary:

    So I actually need only the last digit of the raw data, I think the equation would be

    I'll check as soon as possible.

    Now that I know all this is possible, I'll try to explore the rest of the bus. I know there are devices (like the AiM Solo 2 DL) that can read the brake fluid pressure or something similar (last page on this PDF "Brake Pressure"... whatever that means) so this data should be available somewhere.

    Also, a question: is it possible to log data in RaceChrono Pro without actually moving / aving a GPS signal? We are going to be in lock down starting tomorrow, can't go around with car without valid important reason...
  • edited January 2021
    The original Torque equation for the steering angle is wrong, as its a two byte value and the equation is using only one byte, meaning it may work, but with very bad resolution.

    Notice difference between integers and floats when dividing. If you want decimals you need to divide by 20.0 instead of 20, or float(20) if you want to be explicit. All explained here:

    The brake switch seem to be third byte's least significant bit. Each byte is 8 bits, so the offset for that bit would be 8+8+7 = 23. Try "bitsToUint(raw, 23, 1) * 100.0" for the equation.

    You can record without moving, but you need a GPS signal at the beginning for the data to be logged.

    I hope I covered everything.
  • Yes, thank you. Next step is switching to CAN-Bus reading that seems to be much faster. I already found RPM and Accelerator Pedal Position, need to find steering and brake, probably I'll need to scann all ids from scratch (need to learn how to do it first)
Sign In or Register to comment.