Write-Up: Torque APP OBD2 Reader

Hm. I interpreted the writeup to mean to look at the 5th digit of the RXF which I saw as: 0321 8 0000000

In any case, I just went down to the parking lot, and using my eq got values from 3900 ~ 5100. So then I figured you were right, and I got rid of the extra multiplication by 10, and then my value hovered around -95. I wonder if the conversion tutorial is missing some order-of-operations parenthesis...

I also copied out a sample of the raw hex values getting returned using the "Test" button at the bottom of the custom PID screen so I can just plug them in to the equation without having to go back down to see if they make sense. I'm guessing that Torque converts the sensor value date from hex to dec then just plugs them into the eq, which should be easy enough to replicate at the computer.

 

Ok I believe your right about that 8. Just went back and re-read it.
Gonna go over my calculations to make sure I didnt mess anything else up haha

 

I have to catch up on this thread and my reader should be here within a week, but should 65136 really be 65536? (If you are going for the bytes in 64k)

 

Or ditch the apple crap and get android

 

So, I went back down just to make sure the sample values I copied out were correct, and I have to admit to being downright confused about how A and B are determined.

If I send a 21D9 command, I get back the following according to Torque's Test button:

Response: 00A
0: 61D912000000
1: 51E053C0000000​

So, the second value is 14 digits, which makes no sense (it's not a power of two). Being confused as I was, I then proceeded to replace the equation with simple A or B values, to see if I could safely make the assumption which one was which.

When the EQ = A, Torque said the equation value was 13.0
When the EQ = B, Torque said the equation value was 0.0
When the EQ= A + B, Torque said the equation value was 13.0 (at least that's consistent)

I'm not sure how either of those values, if interpreted as a hex value can be 13 in decimal. I'm guessing since the lengths are different that it's an implicit big-endian representation with the leading 0's omitted to make them both 64 bits?

Sadly, the two scangauge docs referenced in the thread on the torque forums don't seem to be available anymore.

 

sure thats not hex?? maybe you need to convert hex to binary and than into decimal number it would be an insanely large nuber though​

 

Yup, it's definitely hex - that one is about 25 thousand, and the next one is 1.7 billion.

 

lol 25000 is wrong there bub lol you have count those zeros as leading factors of 2

as every zero 2, 4, 6, 8 , 16, 32, 64, 128...... unless your adding each one than its less which

but also depends on what type of programming they used too as the zero could be inconculsive\


as A would be 107584937787392

and B would be 23046123421696000

or in binary

A 0110000111011001000100100000000000000000000000000000
B 01010001111000000101001111000000000000000000000000000000

 

Heh, yep, that's what I get for miscounting the number of zeros before plugging it into the converter.. shoulda copy/pasted!

OTOH, I still don't get why the values are coming back with what seems like two different precisions - 48 bits for the top value and 64 bit on the bottom - of course, it could just be Torque stripping off the bits it doesn't need...

Maybe we're interpreting them wrong? Does anyone know the OBD protocol well enough to know if we should be interpreting them as some other number type? Perhaps instead of 64bit integers they are floating point values? Which I suppose now that I think about it might make sense, since I doubt a temp would be integer only...

 

looking at those values it is definetly a floating bit, but we need the scaling.......

 

i just punched that calculation into my PLC and made it convert the floating bit into a real number and i think its wrong, but it said 117 scaled, i have to check scaling though

 

Interesting... at least that's a more sane number. How about the other one? Does some combination of them help us arrive at where Torque got 13.0 from?

 

wouldnt take it ..... hmmm idk whats going on here, but my head is spinning, i need to look at OBD code i think, somewhere we have a piece of the puzzle missing, why you get 13 puzzles me, and tbh the 14 number makes more sense than 13 for me, general codes dont come back uneven, it should been a string of 16 though in reality

 

Yeah, seemed odd that the returned values were different lengths, but I think I'll just chalk that up to some code in Torque putting out the shortest string that represented the value.

I'll see if I can install a screenshot app on my phone and post a shot to make sure I'm not misstating something here. Sadly, it seems like the ISO protocol being spoken is not freely available online, so not sure if they're IEE754 floating point or not. Is that what your PLC compiler was assuming?

 

yah my slick 500 went right away to IEE754

i kind of figured it would, but automotive is somewhat different at times, they automate things to a different degree, i did not get a degree in automotive engineering thats for sure, i only got in flow programming, so it s different line of shit, but seriously why isnt there shit open to the public!!!

i may throw it up on the boards at work and see if anyone over sees has knowledge of OBDII we got a few guys that automated a couple of the SAAB plants

 

Apparently I won't be... seems that screenshot taking requires a rooted phone (or being hooked up to a laptop running the android SDK), neither of which is convenient tonight.

 

So I decided to read through the FSM section on the automatic transmission last night, and I gleaned the following information:

1) There are two temperature sensors in the 09 AT, "A" and "B". They read the oil temperature, as one would expect
2) The sensors present the temp as an electrical resistance to the ECU, varying from 79Ω to 156kΩ and the ECU converts it to a temp value in °C
3) The Toyota Techstream tool reads the temps from the ECU through the OBD interface, so it must possible for us to do so, too!
4) The ECM speaks ISO 15765-4 (and possibly SAE J1987, they're both mentioned in the manual)
5) The "B" sensor is placed directly before the oil cooler inlet pipeline, not mentioned where the "A" sensor is
6) The ECU considers the valid temperature ranges to be -40°C to 215°C (-40 to 419F)


So, maybe the protocol #s will help track down info, or maybe we need to look at interpreting those values as resistance values? Still not sure. Someone over on the Torque forums just replied with a different equation to try, so I'll give that a shot too.

 

well than its an RTD which would make sense, so the range is 79Ω= -40°C and the 156kΩ = 215°C

now if thats the case 13 ould be % but that still does not work at 13% of 255 range is -6.85°C sooo


but SAE and ISO are standards like ISO will probably be the canbus or per manafacturer and SAE will the bit the determining factor on message lengths and speeds

 

ISO 15765: Road vehicles — Diagnostics on Controller Area Networks (CAN). International Organization for Standardization, 2004.

• Part 1: General information
• Part 2: Network layer services ISO 15765-2
• Part 3: Implementation of unified diagnostic services (UDS on CAN)
• Part 4: Requirements for emissions-related systems

and SAE is a standard and regulation for safe work practice
SAE J1987EN-Force and Movement Test Method

 

Might be worth trying to find a copy of that one. I'll start poking around