Note: Below is for a 2012 KDJ150 (Diesel) Kakadu and may not work with GRJ150 and later GDJ150 models. There should be enough info below to convert to the 7E02182 PIDs used on these models for the temp sensors.
SG2 is a much lower level device that requires a more intimate understanding of how data is used within a computing environment. For instance, TP operates on a much higher function level by filtering the response messages and converting the hexadecimal values into decimal and storing them in single bytes labelled A, B, C, D, etc. for manipulation along with some inbuilt functions such as int16(A:B) which converts 16 bits of information into a 16 bit integer (this is equivalent of 256*A+B which most will be familiar with). This makes it relatively easier to understand and fiddle with.
On the other hand, with SG2 the user is required to understand how the messages are returned and apply the appropriate filter to correctly identify and extract the required information. There is a good PDF floating around explain how this works if you look for it. You will need to be able to understand and interpret the hexadecimal system along with twos compliment for negative numbers. However, this paper does not describe how SG2 handles large data packets which appears to be present in firmware 4.0 and above (hence the SG2 website requirement for some of the codes). I assume for this explanation this paper has been read along with the Wiki page on OBD2 and PID protocols.
A good starting place which explains each of the scenarios would be to make a gauge for the transmission oil pan temperature sensor, torque convertor temperature sensor, torque converter lock status and turbine rotational speed. To accomplish this you require PID 0xD9 and 0xDA and various different RXF filters which will be explained. I have previously posted about this for TP where I assumed it appeared the temp sensors are only 8 bits. I have since been able to get Techstream working and can confirm they are 16 bits and scaled down in order to get the decimal place.
TXD
The TXD part is fairly straight forward and understandable for both SC2 and TP. So I won’t dwell too much. Using SG2 the TXDs used will be TXD: 07E121D9 and TXD: 07E121DA. At this stage it’s important to understand that both devices pack these TXDs with additional bytes to simplify usability. More information can be found on the Wiki page. In TP, the PID will be 21D9 and 21DA and both headers 7E1.
RXF
This is where it gets a bit messy based on the way SG2 handles the response. TP automatically filters the data for you and deals with it (high level) where as with SG2 you need to understand the message structure to locate the info (low level). This is explained in the PDF regarding Xgauge coding structure however doesn’t discuss how the large data packets are handled with firmware 4.0 and above.
We’ll start with the RXF required to locate the torque converter lock up bit. The TXD will be 07E121DA and the message received back will be something like “07E9xx61DAaabbccdd” where xx is the data length (in bytes) and aa, bb, etc. correlate to TP with bytes A, B, C and D. The SG2 filter using an offset to ensure it has picked up the correct response from the ECU. In this case we are mostly concerned about the two bytes 0x61 and 0xDA. The 0x07 header value begins as an offset of byte 1 (don’t ask why the designer didn’t use 0 for this). This make bytes 02 = 0xE9, byte 03 = xx byte 04 = 0x61 and byte 05 = 0xDA. Thus, the RXF will become RXF: 02E9046105DA. The leading 0 of the offset can be used for special inputs, in this case, assigning the second offset of 0461 to 2461 tells the SG2 we want to display the value as either ON or OFF.
Now, with PID 0xD9 where the temperature sensors sit and the turbine speed, you will be familiar with the bytes in TP labelled E and F, and G and H. This is a large response from the ECU and is handled very differently to the above example. Typically, the response from TXD: 07E121D9 will be “07E9xxyy61D9aabbccddeeffgghh”. The turbine speed resides in data byte aa (A in TP). What we can see is the additional “yy” byte. I haven’t really tried to figure what this is yet, but it causes the required RXF filter offsets to be shifted. Thus, to locate byte A, the RXF becomes RXF: 02E9056106D9.
Again, to try and complicate things even more, when accessing the data for bytes E to H for the two temperatures, the SG2 seems to store this somewhere else unrelated to the 0x61D9 response and is based on the original TXD query. In this case, the bytes E onward can be filtered by applying RXF: 02E903210000. Again though, we can do more to the data by assigning one of the special functions in offset 2. Buy setting this to “8” the RXF becomes RXF: 02E983210000. Adding this means that the data is divided by 10 and a decimal place is inserted. It just needs to be remembered that you will then need to multiply the data in the MTH function for this. Using the value of “4” will give two decimal places and need multiplying by 100.
Hopefully this now gives an insight into the codes you see on the SG2 website. It’ll also require you to do some fiddling with the RXF depending on the size of the payload and where the data you want is located.
RXD
The RXD is fairly easy to explain now that RXF has been discussed. The first byte (leading two numbers) tells SG2 how many bits (remember a byte consists of 8 bits) with the first bit being assigned 00 and the second byte (last two numbers) is how long the data is in bits. Again, these are hexadecimal numbers.
I’ll start here with the turbine speed as it uses a single byte of data and not a specific bit. So for the turbine speed, we have established it is the first returned data byte aa (or A in TP). We know the offset byte for 0xD9 was 06, thus the 7th byte in the sequence consists of bits 48 to 55. We then need to convert this to hexadecimal, 48 = 0x30 and thus RXD will be RXD: 3008. When it comes to the temperature sensors, keeping in mind the offset for 0x0321, meaning bytes E will actually start from bit 24 = 0x18 and is 2 bytes (16 bits) long 16 = 0x10 and the RXD: 1810 (bytes E and F) and RXD: 2810 (bytes G and H). For the torque converter lock up bit, the TP equation I come up with previously was bit(A:4) so bit 4 in byte A. This will convert to RXD: 2B01 (bit 43, single bit in length).
MTH
The math function is again straight forward. The MTH input consists of 6 bytes of information, 2 for the multiplier, 2 for the divisor and 2 for the add/subtract. Again, we need to remember the add/subtract represent negative numbers as the twos compliment. First of all, the torque converter lock bit doesn’t need any maths and it’s either on or off, so the MTH is simply MTH: 000100010000.
The turbine speed is detailed (searched on the internet) as being the turbine rotational speed in 50rpm increments. This means that the conversation equation in TP is (12750/255)*A. To convert this to MTH in SG2, we need to convert to hexadecimal 12750 = 0x31CE and 255 = 0x00FF and the MTH will become MTH: 31CE00FF0000.
The temperature sensors have scaled two bytes of data from 0 to 255 (in decimal) thus in TP the equations are int16(E:F)/257-40 and int16(G:H)/257-40. The int16(xx:yy) is a simpler way of writing 256*xx+yy making the equation more readable, it basically converts two bytes (16bits) into an integer. Remember in RXF for the temp sensors we used an offset of 0x8321? Well now we need to multiply the data by 10. Normally the MTH will be MTH: 00010101FFD8 (257 = 0x0101, -40 = 0xFFD8 signed twos compliment to match the TP equations), but because we are multiplying by 10 because the RXF offset divides by 10 we end up with MTH: 000A0101FE70 (10 = 0x000A, 257 = 0x0101, -400 = 0xFE70).
***Update: temp scaling changed to 257=(2^16-1)/(2^8-1)***
Final settings
So now the part we’ve all been waiting for… drum roll please… These have been verified using Techstream.
Transmission oil pan temperature (°C)
In SG2
In SG2
In SG2
In SG2
SG2 is a much lower level device that requires a more intimate understanding of how data is used within a computing environment. For instance, TP operates on a much higher function level by filtering the response messages and converting the hexadecimal values into decimal and storing them in single bytes labelled A, B, C, D, etc. for manipulation along with some inbuilt functions such as int16(A:B) which converts 16 bits of information into a 16 bit integer (this is equivalent of 256*A+B which most will be familiar with). This makes it relatively easier to understand and fiddle with.
On the other hand, with SG2 the user is required to understand how the messages are returned and apply the appropriate filter to correctly identify and extract the required information. There is a good PDF floating around explain how this works if you look for it. You will need to be able to understand and interpret the hexadecimal system along with twos compliment for negative numbers. However, this paper does not describe how SG2 handles large data packets which appears to be present in firmware 4.0 and above (hence the SG2 website requirement for some of the codes). I assume for this explanation this paper has been read along with the Wiki page on OBD2 and PID protocols.
A good starting place which explains each of the scenarios would be to make a gauge for the transmission oil pan temperature sensor, torque convertor temperature sensor, torque converter lock status and turbine rotational speed. To accomplish this you require PID 0xD9 and 0xDA and various different RXF filters which will be explained. I have previously posted about this for TP where I assumed it appeared the temp sensors are only 8 bits. I have since been able to get Techstream working and can confirm they are 16 bits and scaled down in order to get the decimal place.
TXD
The TXD part is fairly straight forward and understandable for both SC2 and TP. So I won’t dwell too much. Using SG2 the TXDs used will be TXD: 07E121D9 and TXD: 07E121DA. At this stage it’s important to understand that both devices pack these TXDs with additional bytes to simplify usability. More information can be found on the Wiki page. In TP, the PID will be 21D9 and 21DA and both headers 7E1.
RXF
This is where it gets a bit messy based on the way SG2 handles the response. TP automatically filters the data for you and deals with it (high level) where as with SG2 you need to understand the message structure to locate the info (low level). This is explained in the PDF regarding Xgauge coding structure however doesn’t discuss how the large data packets are handled with firmware 4.0 and above.
We’ll start with the RXF required to locate the torque converter lock up bit. The TXD will be 07E121DA and the message received back will be something like “07E9xx61DAaabbccdd” where xx is the data length (in bytes) and aa, bb, etc. correlate to TP with bytes A, B, C and D. The SG2 filter using an offset to ensure it has picked up the correct response from the ECU. In this case we are mostly concerned about the two bytes 0x61 and 0xDA. The 0x07 header value begins as an offset of byte 1 (don’t ask why the designer didn’t use 0 for this). This make bytes 02 = 0xE9, byte 03 = xx byte 04 = 0x61 and byte 05 = 0xDA. Thus, the RXF will become RXF: 02E9046105DA. The leading 0 of the offset can be used for special inputs, in this case, assigning the second offset of 0461 to 2461 tells the SG2 we want to display the value as either ON or OFF.
Now, with PID 0xD9 where the temperature sensors sit and the turbine speed, you will be familiar with the bytes in TP labelled E and F, and G and H. This is a large response from the ECU and is handled very differently to the above example. Typically, the response from TXD: 07E121D9 will be “07E9xxyy61D9aabbccddeeffgghh”. The turbine speed resides in data byte aa (A in TP). What we can see is the additional “yy” byte. I haven’t really tried to figure what this is yet, but it causes the required RXF filter offsets to be shifted. Thus, to locate byte A, the RXF becomes RXF: 02E9056106D9.
Again, to try and complicate things even more, when accessing the data for bytes E to H for the two temperatures, the SG2 seems to store this somewhere else unrelated to the 0x61D9 response and is based on the original TXD query. In this case, the bytes E onward can be filtered by applying RXF: 02E903210000. Again though, we can do more to the data by assigning one of the special functions in offset 2. Buy setting this to “8” the RXF becomes RXF: 02E983210000. Adding this means that the data is divided by 10 and a decimal place is inserted. It just needs to be remembered that you will then need to multiply the data in the MTH function for this. Using the value of “4” will give two decimal places and need multiplying by 100.
Hopefully this now gives an insight into the codes you see on the SG2 website. It’ll also require you to do some fiddling with the RXF depending on the size of the payload and where the data you want is located.
RXD
The RXD is fairly easy to explain now that RXF has been discussed. The first byte (leading two numbers) tells SG2 how many bits (remember a byte consists of 8 bits) with the first bit being assigned 00 and the second byte (last two numbers) is how long the data is in bits. Again, these are hexadecimal numbers.
I’ll start here with the turbine speed as it uses a single byte of data and not a specific bit. So for the turbine speed, we have established it is the first returned data byte aa (or A in TP). We know the offset byte for 0xD9 was 06, thus the 7th byte in the sequence consists of bits 48 to 55. We then need to convert this to hexadecimal, 48 = 0x30 and thus RXD will be RXD: 3008. When it comes to the temperature sensors, keeping in mind the offset for 0x0321, meaning bytes E will actually start from bit 24 = 0x18 and is 2 bytes (16 bits) long 16 = 0x10 and the RXD: 1810 (bytes E and F) and RXD: 2810 (bytes G and H). For the torque converter lock up bit, the TP equation I come up with previously was bit(A:4) so bit 4 in byte A. This will convert to RXD: 2B01 (bit 43, single bit in length).
MTH
The math function is again straight forward. The MTH input consists of 6 bytes of information, 2 for the multiplier, 2 for the divisor and 2 for the add/subtract. Again, we need to remember the add/subtract represent negative numbers as the twos compliment. First of all, the torque converter lock bit doesn’t need any maths and it’s either on or off, so the MTH is simply MTH: 000100010000.
The turbine speed is detailed (searched on the internet) as being the turbine rotational speed in 50rpm increments. This means that the conversation equation in TP is (12750/255)*A. To convert this to MTH in SG2, we need to convert to hexadecimal 12750 = 0x31CE and 255 = 0x00FF and the MTH will become MTH: 31CE00FF0000.
The temperature sensors have scaled two bytes of data from 0 to 255 (in decimal) thus in TP the equations are int16(E:F)/257-40 and int16(G:H)/257-40. The int16(xx:yy) is a simpler way of writing 256*xx+yy making the equation more readable, it basically converts two bytes (16bits) into an integer. Remember in RXF for the temp sensors we used an offset of 0x8321? Well now we need to multiply the data by 10. Normally the MTH will be MTH: 00010101FFD8 (257 = 0x0101, -40 = 0xFFD8 signed twos compliment to match the TP equations), but because we are multiplying by 10 because the RXF offset divides by 10 we end up with MTH: 000A0101FE70 (10 = 0x000A, 257 = 0x0101, -400 = 0xFE70).
***Update: temp scaling changed to 257=(2^16-1)/(2^8-1)***
Final settings
So now the part we’ve all been waiting for… drum roll please… These have been verified using Techstream.
Transmission oil pan temperature (°C)
In SG2
- TXD: 07E121D9
- RXF: 02E983210000
- RXD: 1810
- MTH: 000A0101FE70
- NME: cAT
- PID = 21D9
- Min = -40
- Max = 215
- Scale = x1
- Unit = °C
- Equation = int16(E:F)/257-40
- Header = 7E1
In SG2
- TXD: 07E121D9
- RXF: 02E983210000
- RXD: 2810
- MTH: 000A0101FE70
- NME: cTC
- PID = 21D9
- Min = -40
- Max = 215
- Scale = x1
- Unit = °C
- Equation = int16(G:H)/257-40
- Header = 7E1
In SG2
- TXD: 07E121D9
- RXF: 02E9056106D9
- RXD: 3008
- MTH: 31CE00FF0000
- NME: rTC
- PID = 21D9
- Min = 0
- Max = 6000
- Scale = x1
- Unit = RPM
- Equation = (12750/255)*A
- Header = 7E1
In SG2
- TXD: 07E121DA
- RXF: 02E9246105DA
- RXD: 2B01
- MTH: 000100010000
- NME: TCL
- PID = 21DA
- Min = 0
- Max = 1
- Scale = x1
- Unit =
- Equation = bit(A:4)
- Header = 7E1
Comment