Cracking the K-line

Cheyenne

UK 2004 T1N 313CDi
I was going to move on to instrument cluster, but if Keith thinks it's important then...

engine oil level = PID 8 #32&33 ============ level(cm) = (256*A + B)/100

Not sure, engine oil quality might be:

oil quality = PID 8 #28 ============== quality = A/10
Sorry for the late reply but only just got back to looking at this.

I've studied the SGII manual but can't fathom out how to convert your code into an X-Gauge, can anyone help please?

Cheers in anticipation.
Keith.
 

Nautamaran

2004 140” HRC 2500 (Crewed)
Fair enough:

I don’t have a ScanguageII, but skimmed the manual I found here:
https://www.scangauge.com/download/1282/

On page 21 it shows how to program a custom command (search more=>more=>cmnds)
Thr example implies you can enter a full header and data field, and the unit computes the checksum.
So... any of the engine ECM messages seen earlier, so 82 12 F1 21 08 (no checksum) where 82 is the format byte, 12 the ecu address, F1 the scangauge address, 21 the Service ID, and 08 the Parameter. The second digit of the format byte holds the length of the data field (Sid & parameter bytes, in this case 2 bytes so format is 82)

Then on page 26 is the description of XGauge configuration... It appears you point the gauge back at your stored command, then tell the gauge the byte field to use and the math to scale and offset the bytes into a readable value = scale x bytes + offset. I don’t know where ScanguageII starts counting bytes, but typical obd formulas starts at “1” with the third response data byte, after the 61 08 command echo. You’ll want the 27th and 28th formula bytes, which is where the oil level bytes are.

Hope this helps you to figure it out?
Take good notes as you muck about with it, and if you succeed in getting an oil level gauge configured you can use the same technique to access all of the engine data Cal has identified. (I look forward to your write-up! :wink:)

-dave

Edit:
I just set up oil level on OBD Fusion..

Metric Unit mm
Module ECM (uses functional addr 0x33)
Mode 21
PID 08
Formula (AA * 256 + AB) / 10
 
Last edited:

Nautamaran

2004 140” HRC 2500 (Crewed)
A major milestone was reached today: simultaneous communications with two modules at once, using two voltage shift circuits. The TCM and ECM are now answering.

Thanks Cal for the helping identify the timing glitch that prevented seeing the engine module's wake-up responses. That analyzer of yours is awfully handy!

Snapshot of current code attached...

-dave
 

Attachments

calbiker

Well-known member
Congratulations Dave, job well done! :bounce:

I'm waiting for the transistor array IC to arrive before I can communicate with multiple k-lines.

Glad there's no issues with more than one k-line open.

Cal
 

Cheyenne

UK 2004 T1N 313CDi
Fair enough:

I don’t have a ScanguageII, but skimmed the manual I found here:
https://www.scangauge.com/download/1282/

On page 21 it shows how to program a custom command (search more=>more=>cmnds)
Thr example implies you can enter a full header and data field, and the unit computes the checksum.
So... any of the engine ECM messages seen earlier, so 82 12 F1 21 08 (no checksum) where 82 is the format byte, 12 the ecu address, F1 the scangauge address, 21 the Service ID, and 08 the Parameter. The second digit of the format byte holds the length of the data field (Sid & parameter bytes, in this case 2 bytes so format is 82)

Then on page 26 is the description of XGauge configuration... It appears you point the gauge back at your stored command, then tell the gauge the byte field to use and the math to scale and offset the bytes into a readable value = scale x bytes + offset. I don’t know where ScanguageII starts counting bytes, but typical obd formulas starts at “1” with the third response data byte, after the 61 08 command echo. You’ll want the 27th and 28th formula bytes, which is where the oil level bytes are.

Hope this helps you to figure it out?
Take good notes as you muck about with it, and if you succeed in getting an oil level gauge configured you can use the same technique to access all of the engine data Cal has identified. (I look forward to your write-up! :wink:)

-dave

Edit:
I just set up oil level on OBD Fusion..

Metric Unit mm
Module ECM (uses functional addr 0x33)
Mode 21
PID 08
Formula (AA * 256 + AB) / 10
Dave,

Many thanks for the above,
I've spent far too long trying to get my head around this but think I may, just MAY, have come up with the X-Gauge coding. Please could one of you who are more knowledgeable than me have a look and see what you think before I try programming my SGII.

Gauge Engine Oil Level
TXD C233F10128
RXF 044105280000
RXD 2808
MTH 0001000A0000
Name EOL

The Math possibly needs plus 40 mm but I can check this against my Autel reading.

I have used the list of KWP X-Gauges here as a guide...

https://www.scangauge.com/support/x-gauge-commands/standard-obdii/

So, am I on the right track or have I got it totally wrong?

Keith.
 

Nautamaran

2004 140” HRC 2500 (Crewed)
I’ve just some time with the manual...
“Vague” is being generous!
I did find this page, which was helpful:
https://priuschat.com/threads/scanguage-xgauge-how-to-area-please-share-your-knowledge.43139/

After reading it I think I can explain the desired values for you?

We’re using Key Word Protocol, or KWP, so the first three bytes are the header.
In your example C2, 33, F1 are the format, the target address, and the sender address.
The leading C indicates a “functional” address,
(a leading 8 would indicate a “absolute” address)
The 2 indicates that the message data has two bytes: the “01 28”
33 is the functional address of the engine module;
F1 is the absolute address of the scanguage.
The first data byte “01” is the “Service Identifier”, or Mode.
28 is the Parameter Identifier or PID.

The SAE live data values all use Service 01, so documentation usually just discusses the PID value and doesn’t explain why you (or the scanner) needs to prefix it with a 01 byte.

But to request the oil level you need to use Service 21, PID 08.

So the TXD command you want to be sending will be either
TXD C233F12108 (functional) or
TXD 8212F12108 (absolute - with engine module address $12)

RXF is the filter string.
Each four digit group is a byte to match in the ressponse.
For a successful reply the server adds $40 to the Service ID and echoes the PID.
$21 + $40 = $61, so we expect to see something like 84 F1 12 61 08 0C 32 (but with more data) and we can match the 61 08 in bytes 4 & 5 in the response message:
RXF 046105080000

RXD is the BIT offset and numbr of bits to read.
The first byte has an offset of zero, the second skips 8 bits, the third 16 ($10), etc.
We want bytes 32 & 33 of the message, so we skip past 31 x 8 = 248 bits, or $F8 - just under the max value of $FF - and read 16 bits, or $10, so we have:
RXD F810

The MTH value converts the returned value into the computed value.
The gauge multiplies by the first value (4 hex digits), divides by the second (4 hex digits), then adds the third “offset” value (4 hex digits) So MTH 00030002000A would be (Value x 3 / 2 + 10)
The last value is “signed”, with 0001 = +1, and FFFF = -1, FFFE = -2, etc.
For temps, where we would need an offset of -40 ‘C, we would add FFD8

We just want to divide by ten for millimeters, so would use (V x 1 / 10 + 0), which is:
MTH 0001000A0000 (So you did get one right...)

(personally, I would then pull my dipstick, measure the oil’s level above MIN, and adjust the formula’s offset value (last four zeros) so that the gauge displays mm above dipstick MIN)

Good luck! I hope I’m close to being right about these settings...

-dave
 
Last edited:

Cheyenne

UK 2004 T1N 313CDi
Dave, THANKYOU, THANKYOU, THANKYOU!!!

I’ve just some time with the manual...
“Vague” is being generous!
I'm glad it's not only me who thinks so!

So the TXD command you want to be sending will be either
TXD C233F12108 (functional) or
TXD 8212F12108 (absolute - with engine module address $12)
Would you believe I actually had the 8212... code as an alternative TXD but couldn't understand why all the other X-gauges on LL's page started C2.... so ignored it!
At least now I know why.

RXF is the filter string.
Each four digit group is a byte to match in the response.
For a successful reply the server adds $40 to the Service ID and echoes the PID.
$21 + $40 = $61, so we expect to see something like 84 F1 12 61 08 0C 32 (but with more data) and we can match the 61 08 in bytes 4 & 5 in the response message:
RXF 046105080000

RXD is the BIT offset and numbr of bits to read.
The first byte has an offset of zero, the second skips 8 bits, the third 16 ($10), etc.
We want bytes 32 & 33 of the message, so we skip past 31 x 8 = 248 bits, or $F8 - just under the max value of $FF - and read 16 bits, or $10, so we have:
RXD F810
Looks like I totally messed up here but thanks for the explanation.

The MTH value converts the returned value into the computed value.
The gauge multiplies by the first value (4 hex digits), divides by the second (4 hex digits), then adds the third “offset” value (4 hex digits) So MTH 00030002000A would be (Value x 3 / 2 + 10)
The last value is “signed”, with 0001 = +1, and FFFF = -1, FFFE = -2, etc.
For temps, where we would need an offset of -40 ‘C, we would add FFD8

We just want to divide by ten for millimeters, so would use (V x 1 / 10 + 0), which is:
MTH 0001000A0000 (So you did get one right...)
Yep, I managed to work that one out :thumbup:

(personally, I would then pull my dipstick, measure the oil’s level above MIN, and adjust the formula’s offset value (last four zeros) so that the gauge displays mm above dipstick MIN)

Good luck! I hope I’m close to being right about these settings...

-dave
It will be a few days before I get round to programming my SGII but will certainly let you know how I get on. Initially I will compare the reading to my Autel MD802 and then against the dipstick.

Once again many thanks for your help on this.

:thumbup::thumbup::thumbup::cheers::cheers: :cheers:

Keith.
 
Last edited:

Nautamaran

2004 140” HRC 2500 (Crewed)
A view of my newest instrument layout.

I think I'm pretty much "there" for the moment... enough to run with while staying under the distracted-driver threshold?

In data-capture mode (no LCD updates) the k-line is pulling in about 25 "Service 21" calls per second, which is MORE than enough data to go blind staring at if there's ever a problem...

In this "dashboard" mode the time to redraw the complete LCD display is around two seconds, but by being selective with my text redraws (ie only retyping the changing values) I have the refresh rate running a bit under twice per second (660ms each) which is fast enough to see the turbo actuator and boost pressures respond.

The Oil Quality, EGR, and Rail Pressure Relief Solenoid values are not working... they'll take some more hunting for the correct data bytes, but have a home once they're found.

Temps seem to display plausible values, and once everything warms up the displayed Oil Sump value (engine running) is around 30mm. My rested hot-engine oil level is currently about 1/2" or 12mm over the dipstick MIN bar, and the gauge then reads 50 mm before cranking. So I'll be happy driving with anything over 20mm, and check the dip stick below that. In two years I've never needed to add more than a 1/2 quart of oil between my 10k oil changes, so the sump level is really on here to spot any trending RISE in oil level on long trips.

Gear, RPM, and Torque values are in/out numbers across the torque converter from the transmission module. The Slip value is the across the TC Clutch (the GOOD kind:thumbup:), and during launches I can observe the stator creating extra output torque before the clutch goes from Open to Authorized to Active and the numbers again line up.

Calgary is at 3500 feet, so the displayed Air Pressures around 13 psi are normal... 12.92 psi (26.3 inches of mercury) is our median. I've used the Star C3's labels for Atmospheric, Boost, and Intake, but these appear to be in the wrong order as "Boost" appears to be what I would usually call "MAP"?

The last four values are the HP Fuel pump's Quantity Control Valve, the rail pressure, the (soon?) Fuel Rail's Pressure Relief Solenoid, and fuel temp sensor. These also appear plausible.

So now I "just" need to package this up and find a good spot to mount it... perhaps next to the shifter or up on the left speaker grill by the A-pillar? We'll see.

-dave
 

Attachments

calbiker

Well-known member
Can't match David's very cool looking display, and not to mention the awesome content!

I got some transistor array IC's and soldered one into my prototype board. It's a lot easier to wire up a k-line driver with the array than with discrete transistors. The board now has 2 k-line drivers, communicating with the ECM and TCM. One using the array and the other using discrete transistors. Also seen in the photo (standing vertical) is the SD memory shield (data logger).

IMG_2560R.jpg

Here's some logged temperatures. Measurements are taken every 5 seconds. x-axis is time in minutes. There's two tranny temperatures shown: ATFvT and ATFT. They are about 10 deg F apart, with ATFT being greater.

ATFT is our understand what the tranny temperature is. The transmission controller measures the temp sensor voltage, converts the voltage to a representative temperature and we read the code representing this temperature.

The transmission also outputs the temp sensor voltage. We read this voltage and apply the the conversion factor to deg F. This is ATFvT. The conversion factor is given in the '06 Service Manual. I've taken readings when the vehicle is cold. ATFT is 10 F higher than the rest of the sensors. Therefore I believe ATFvT is more accurate.

DriveTemps.jpg
 

Midwestdrifter

Engineer In Residence
A view of my newest instrument layout.

I think I'm pretty much "there" for the moment... enough to run with while staying under the distracted-driver threshold?

In data-capture mode (no LCD updates) the k-line is pulling in about 25 "Service 21" calls per second, which is MORE than enough data to go blind staring at if there's ever a problem...

In this "dashboard" mode the time to redraw the complete LCD display is around two seconds, but by being selective with my text redraws (ie only retyping the changing values) I have the refresh rate running a bit under twice per second (660ms each) which is fast enough to see the turbo actuator and boost pressures respond.

The Oil Quality, EGR, and Rail Pressure Relief Solenoid values are not working... they'll take some more hunting for the correct data bytes, but have a home once they're found.

Temps seem to display plausible values, and once everything warms up the displayed Oil Sump value (engine running) is around 30mm. My rested hot-engine oil level is currently about 1/2" or 12mm over the dipstick MIN bar, and the gauge then reads 50 mm before cranking. So I'll be happy driving with anything over 20mm, and check the dip stick below that. In two years I've never needed to add more than a 1/2 quart of oil between my 10k oil changes, so the sump level is really on here to spot any trending RISE in oil level on long trips.

Gear, RPM, and Torque values are in/out numbers across the torque converter from the transmission module. The Slip value is the across the TC Clutch (the GOOD kind:thumbup:), and during launches I can observe the stator creating extra output torque before the clutch goes from Open to Authorized to Active and the numbers again line up.

Calgary is at 3500 feet, so the displayed Air Pressures around 13 psi are normal... 12.92 psi (26.3 inches of mercury) is our median. I've used the Star C3's labels for Atmospheric, Boost, and Intake, but these appear to be in the wrong order as "Boost" appears to be what I would usually call "MAP"?

The last four values are the HP Fuel pump's Quantity Control Valve, the rail pressure, the (soon?) Fuel Rail's Pressure Relief Solenoid, and fuel temp sensor. These also appear plausible.

So now I "just" need to package this up and find a good spot to mount it... perhaps next to the shifter or up on the left speaker grill by the A-pillar? We'll see.

-dave
How much for one? if you prefer, you do the software, I'll assemble say 20? of them and we can split on the profits. Looks like all it needs is a nice 3D printed case.
 

calbiker

Well-known member
There's been multiple discussions whether lugging the engine (100% load and lower rpm) causes the transmission to stress and heat more. This data indicates it is not the case.

Just before the 6 min mark on the graph I enter the freeway. Speed is about 60 mph when going up a slight hill.

Gear: 5th
rpm: ~2100
Torque: ~ 310 lb-ft
Load: ~ 90 - 100

The graph shows significant increase in the slope of coolant and engine oil temperature. There is not increased slope of the transmission fluid temperature (see the two blue and light blue plots). As mentioned previously, I believe the ATFvT plot is more accurate than ATFT.

Around 185F coolant temp, the thermostat opens and coolant enters radiator and temperature levels off.
 

Attachments

Nautamaran

2004 140” HRC 2500 (Crewed)
What was ambient temp at startup?

Plotting the torque converter slip rpm would give a good picture of how hard it’s working...

-dave
 
Last edited:

calbiker

Well-known member
Ambient was around 65F

Here's slip rpm. When in D or R with brake applied the slip rpm is equal to idle rpm.

Under full load slip rpm is about 1.2% of rpm. No where near the 5% we had in mind.

The plot has slip rpm scale on the right vertical axis. LOD and Torq have axis on left. The horizontal zero are not identical. Torq is outputting negative values.

It's interesting that the transmission displays an input and output rpm. Calculate out/in rpm and you know which gear your're in.

Edit: The Slip rpm spikes are due to gear changing.
 

Attachments

Last edited:

Nautamaran

2004 140” HRC 2500 (Crewed)
Nice. Of course you could also log and plot the actual gear from the TCM... and the clutch state (open/active).

I’ve previously observed negative torque numbers descending grades using SAR pids; -103 horsepower was displayed on my OBD Fusion phone app in low gear down a steep hill last spring... eastbound, east of Roger’s Pass; Bring brakes.

-dave
 

Attachments

Last edited:

Nautamaran

2004 140” HRC 2500 (Crewed)
I believe I have found the oil quality value:
Service $21, Pid $08, message bytes 30,31 (from format byte as byte one), putting it right in front of the oil level value.
The formula is ((256xA) + B) / 256

Arduino C code formula for the TCM.h function is
return this->s21p8->b16(26) / 256. ;

And the ScangaugeII’s X-Gauge values would be:

TXD C233F12108
RXF 046145080000
(the “4” in “45” requests x.xx formatting)
RXD E810
MTH 000101000000


-dave
 
Last edited:

Nautamaran

2004 140” HRC 2500 (Crewed)
This oil quality value matches the one my Autel tool displays, so I think I’ve got it right.

I’m now 8500 miles into my usual 10,000 mile oil change interval, with a 2.29 oil quality reading. I’ll take note of the quality before I go ahead with my oil change at 190k, and may submit the used oil for analysis to see how much further it might have gone, but I’m now curious if anyone has charted their Assyst countdown against the indicated quality on their scan tool?

Ideally this van and I will see MANY more oil changes, and at $70 each I won’t say no to making them last a bit longer, and the oil quality value seems a good guide to doing so safely. I’m also aware that even stretching I may miss two or three, which barely fills the fuel tank one, so this won’t be a life-altering improvement... :shhh:

-dave
 

Attachments


Top Bottom