E38 Oil Temp Sensor Input

Can someone shed a little light on the E38 table {G1218} Engine Oil Temperature Sensor options?

I have some customers looking to switch from "Calculated" to "Sensor" in applications where aftermarket coolers are being used. High HP setups where they need to monitor the oil temp over CANbus data, and adjust tables {B5212} {B5213} {B5214} based on a actual sensor value rather than the factory calculated values.

After a few hours of searching the web, nothing to clarify what ECM pin to use, or what these G1218 options actaully change. The - "Sensor and CAN message" is an interesting option. Is that input, from like IC or BCM, or related to output option??

OS I'm testing on is 12628990, 09 LS3.

Tks

-K

It comes in on J2 Pin 23, but it is a multi-purpose input that is shared with Trans Temp (I assume for M6 applications). I don't know of any applications that use it as oil temp (but then, I've never looked too deep either).

Ok that jives with a post I found somewhere showing EOT as pin 23, but under a different model LS.

Noticed how OS plays a big role with that pin. The hardware I have on the bench came from 2011 5.3l with OS 12639835. That pin was non-responsive on EOT or TFT pids. But soon as I loaded an 09 LS3 "6spd" OS, the pin outputs as TFT pid.

So now the question is, wonder how ECM is gonna respond to changing table G1218 when it's all ready assigned pin as TFT by the current OS? Think it would it be better to load an automatic trans OS, where it's typically an unassigned pin? Or try it as is, and see what happens..

This is only a bench testing setup. Trying to nail down a DPID set for stand alone ECM applications.

Here is the two OS I'm comparing. If I can round up an LS3 automatic VIN, I'll load one up also. What happens if I license that unit and then load diff OS bins? Never tried before..

Attachment 21592
Attachment 21593

You license the ECM regardless of the OS.

When you flash an OS, you have to make sure it is compatible with the ECM (in particular, year/model).

EFILive won't let you flash those OS's in to the same ECM, they would be flagged as incompatible.

Thanks for that verification on license. Didn't think it mattered, but haven't played with loading factory bins after the fact. I'm using a Tech2 and MDI to flash these OS changes, which checks hardware comparability first. No issue going from 2011 OS back to the 09 listed above.

I did find some clarification today to help understand these OS differences relating to pin 23. According to GM doc, the 2009 Pontiac G8 with LS3, [only came with an Automatic trans] uses Pin 23 for EOT signal. And so doesn't the 2010 Camaro L99 or LS3 ECM, however depending on transmission option.. But the 08-09 Vette only used the pin for trans temp with 6spd manual. With an automatic trans, that pin is unused. All Vette's used "calculated" EOT, so the pid values seen on any scan tool are calculated values with stock OS.

I don't have 2009 G8 or 2010 Camaro file handy to look at, but I'll bet default setting in G1218 is "sensor." Please take a peak at those if you have a min.

So question remains, how does that table G1218 actually handle the pin 23 and related canbus output values? My goal is just to nail down if we can use EFIlive to activate that pin on any OS, no matter it's default setting. That would allow the other tables correct reference, and it reports true EOT ovr the bus. Or does everyone need to run a specific OS to take advantage of the sensor. Majority of my customer are doing marine swaps where a fresh water to oil cooler is used, and true EOT "should" be much lower than any calculated value in a car... I know this is also of interest to users who track race these cars and install aftermarket coolers.

Attachment 21602

Attachment 21601

There is a number of calibrations that select what shared inputs are used for, eg, Reverse Lockout or Cylinder Shut Off for AFM.
So of course there is one for EOT or TFT, are you able to do .cax files yourself? I'm happy to let you know the addresses if you wanted to play around (will be much faster than waiting for me to add in to an update).
I don't know that changing it fixes everything that needs to be fixed but it might be worth a shot to see what happens.

Edit, here is all the info if you can do .cax files or someone can make one for you.

OS 12628990
Address 0x1FE518
Signed 16bit
0 = Engine Oil Temp, 1 = Trans Temp

OS 12639835
Address 0x1FEDFC
Signed 16bit
0 = Engine Oil Temp, 1 = Trans Temp

OS 12614676
Address 0x1FEDEA
Signed 16bit
0 = Engine Oil Temp, 1 = Trans Temp

Good luck.

Thanks very much. I'll give it a whirl and let ya know how turns out.

After looking through several LS pinouts, OS version controls multiple pins on these units. Very versatile ECM.

What's funny, stock OS 990 on the bench reports that EOT to pid like it's an OPEN circuit.
While "Estimated" EOT tracks straight to ECT without an RPM or oil pressure signal.
TFT pid reports as expected in stock OS when pin 23 is wired to a POTs.

Hopefully I'll get time to try those other two OS listed also...

Attachment 21603

Oil temp should also be constantly broadcast on high speed CAN frame $4D1, for the BCM and other modules on the bus that need it...

Quote:

---

Originally Posted by DURAtotheMAX

Oil temp should also be constantly broadcast on high speed CAN frame $4D1, for the BCM and other modules on the bus that need it...

---

Ya knew what I was after didn't ya.. LOL. But our previous work in this area seems to be a bit incomplete.. When I changed from the 11 truck OS, to a 09 LS3 OS, guess what also looks to have changed? See attached.

Have you logged any traffic off an 09 or 10 LSx engine in a car yet? All the msg ID's are different on the LS3.. So unless someone has an A2L file to share, I'm gonna need to start from scratch again.. And by hardware / OS to determine where they split.... :ranting:

Who'd of thunk it.. Likely why BCM's are diff also. An

Attachment 21604

Ok guys, I started to load a modified tune today to test that pin assignment, and it won't unlock.. But I read the tune out of it after loading the new OS with tech2.

Here is is the msg. For some reason, SN is blank now.

Script exited with code $0537: Controller is locked with a custom key.

VIN: 1G1YY26W595106262
OS: 12628990
Serial: 000000000000

Any suggestions?

Just checked the DL tune file, and SN was all zero when I read it. Maybe it doesn't like that OS... LOL.

Quote:

---

Originally Posted by kidturbo

Ok guys, I started to load a modified tune today to test that pin assignment, and it won't unlock.. But I read the tune out of it after loading the new OS with tech2.

Here is is the msg. For some reason, SN is blank now.

---

Quote:

---

Originally Posted by GMPX

EFILive won't let you flash those OS's in to the same ECM, they would be flagged as incompatible.

---

I did warn you :shock:
It cannot be recovered.

Yeah but GM forgot to warn me first.. Their remote server took a supplied VIN and said; "Send it..." :grin: So I'll let that tool try an recover, while I go shop for another donor unit. Good thing these are dirt cheap.

Is there a Serv No: to year reference guide out there for eBay shoppers?

GM don't check either, I know people think they do but as you've just found out they do not. The corruption is now there for good, no reversing it with TIS once done.
We don't have a service number cross reference but we do have an OS cross reference.
http://content.efilive.com/documents...ty%20Guide.pdf

Thanks much for the input. It's all good, just the cost of learning. Will send that one off to a buddy who likes cracking them open.. I have that OS cross ref, a printed copy even.. :-) Still a crap shoot buying used on Serv No.

Now what has me wondering, those msg ID changes I noted to Ben above. Is that particular OS actually running different network msg ID structure from all others I've viewed, or did the corruption skew that too.
:bangin:

Unlike the E35's I've bricked, this unit still boots, talks, and all pins I tested responding to signal inputs as expected. Even the OBD-II messages look normal. But that GMLAN node traffic looks weird.. So now no choice but restart this exercise in a few days.

Quote:

---

Originally Posted by kidturbo

Ya knew what I was after didn't ya.. LOL. But our previous work in this area seems to be a bit incomplete.. When I changed from the 11 truck OS, to a 09 LS3 OS, guess what also looks to have changed? See attached.

Have you logged any traffic off an 09 or 10 LSx engine in a car yet? All the msg ID's are different on the LS3.. So unless someone has an A2L file to share, I'm gonna need to start from scratch again.. And by hardware / OS to determine where they split.... :ranting:

Who'd of thunk it.. Likely why BCM's are diff also. An

Attachment 21604

---

That looks like "early" GMLAN high speed traffic.

The "late/current" high speed GMLAN traffic will have some ID's with letters in them ($1F5, $1E1, etc), not "numeric only" ID's.

Quote:

---

Originally Posted by DURAtotheMAX

That looks like "early" GMLAN high speed traffic.

The "late/current" high speed GMLAN traffic will have some ID's with letters in them ($1F5, $1E1, etc), not "numeric only" ID's.

---

Hit my neighbor up yesterday who owns a 2012 LS3 Vette about capturing some bus data. He says sure, if you can start the car.. Seems the battery died from setting, he charged it up, but still no crank. He'd done some reading, purchased a new BCM online, and plugged it in a few days back. Still nothing. But as we all know, the BCM needs to be flashed first for VIN match. He didn't... Long story short, he had a local tech come check it out last week with a SnapOn Versus, and they got "No ECM Response".

I suggested he put the stock BCM back in and let me have a look. V2 fails to connect, Error $208. So after checking all ECM fuses, I plug in that little CBT and capture plenty high speed bus data. BCM and stability control units are talking, but I see no ECM related traffic that matches either set of captured E38 msg ID I've seen before. ECM is obviously not waking up, or powering up, who knows.. But I recorded some packets, and spotted a couple easy byte changes like brake pedal switch right off. After about 20 minutes, a tow truck driver shows up to take the car to another shop he'd contacted to looked at it. Which was fine by me. Car is lowered, and there's s no way I was getting to that ECM to verify power and grounds. Likely his ECM is not getting a serial data wake up signal for some reason.

To answer your question, the data sets are definitely different. ID's and byte positions both, nothing matches any of the gas or diesel 07-12 truck sets I have on file. ID structure of the E38 bench setup above matches numbering structure I captured off this Vette's bus yesterday. Minus any ECM traffic. So here is your BCM starter set, with couple 7xx OBD-II IDs tacked on there.. :mrgreen:

Just for fun, I also tried to pull config data off that BCM using EFIlive software since that was at least talking to me. Returned all Zeros.

I'll go grab another E38 for bench testing today. Try not to corrupt this one :throw:

Attachment 21611

early/late GMLAN messages will be dependent on platform....not year.

The C6 vette was one of the first vehicles with high speed GMLAN on the powertrain, but still used Class 2 for the body/interior....thats why they used the early GMLAN ID subset.

When GM went to the new electrical architecture that introduced GMLAN for the body/interior (which would include GMT-900 truck/SUV) and abandoned all Class 2, they switched to the "late" high speed GMLAN config and ID subset....they still use this same high speed ID subset today. ie a 2008 silverado, impala, express van will have mostly the same looking high speed GMLAN ID's and bus traffic as a current 2018 global-A vehicle. Obviously a current vehicle will have many more modules so there will be a lot more additional ID's, but the core high speed ID's are still the same.

It was only the very first high-speed powertrain-only GMLAN-equipped vehicles that used early GMLAN where no ID's/messages are shared. C6 vette, some 2004ish Malibu's and Saturns, cadillac XLR....idk maybe a select few others.

Ok I made it to the boneyard today and grabbed a couple more E38's off the rack. That's gotta be the cheapest used ECM on the market at only $30ea. Basically FREE when compared to the 06/07 Cummins CM849 unit I've been trying to source to test with for a month. Those are complete other end of the scale, $600-$700 used, if you can find someone willing to sell..

First E38 unit I chose is an 06/07 model year to load the LS7 OS and verify oil temp pin and ID set for a customers build in Singapore. The current version on this unit is OS 12609099. Last GM update of Nov 2006.

Vin comes back as:

World Manufacturer Index 2G1 General Motors Chevrolet - Canada
Year of manufacture 7 2007
Model WU Impala LTZ
Engine R LZ8, L81, LUK
Engine size R 3.9 litre V6 MFI, 3.0 litre V6 MFI

Quick comparison of CAN data shows it's using same as our Dmax sets. See attached. I really expected this one to be running that same MSG ID set as the 09 Vette. Discussing this difference with a GM tech buddy, he recalls the Impala being first vehicle to use HSLAN in mid/late 05. Then the 06 Vette release was second. And the E35B we know used new style in 07. So I really expected this Impala to run the "early" style. Nope.... So we'll see how it looks when I load the same year LS7 OS onto it.

Next up. 2009 OS 12628982. Wagers??

Attachment 21619

SSDOS

OS 12628982
World Manufacturer Index 2G1 General Motors Chevrolet - Canada
Year of manufacture 9 2009
Model WT Impala LT 3.5 Sedan
Engine K LZE, L36, L36, LEA
Engine size K 3.5 litre V6 SFI, 3.8 litre V6 SFI

Well that pretty much covers the V6 Impala's. :laugh:

Ok Ben, your turn to show an "Early model" GMLAN example we can compare with.

I'm gonna go out on a limb here and say, it's a Vette thing. The BCM in the Vette's from 6-12 doesn't look anything like ones in other GM trucks or cars I've seen. More like a SAM module found in MB or other German chassis. If this protocol difference was only release date related, why didn't they upgrade the Vette's? Hardware supplier contracts maybe?

Attachment 21620

Quote:

---

Originally Posted by kidturbo

SSDOS

OS 12628982
World Manufacturer Index 2G1 General Motors Chevrolet - Canada
Year of manufacture 9 2009
Model WT Impala LT 3.5 Sedan
Engine K LZE, L36, L36, LEA
Engine size K 3.5 litre V6 SFI, 3.8 litre V6 SFI

Well that pretty much covers the V6 Impala's. :laugh:

Ok Ben, your turn to show an "Early model" GMLAN example we can compare with.

I'm gonna go out on a limb here and say, it's a Vette thing. The BCM in the Vette's from 6-12 doesn't look anything like ones in other GM trucks or cars I've seen. More like a SAM module found in MB or other German chassis. If this protocol difference was only release date related, why didn't they upgrade the Vette's? Hardware supplier contracts maybe?

Attachment 21620

---

Because the vette came out in 2005, 2004 if you count the caddy XLR.

So that very early introduction of GMLAN on the 04 XLR/05 vette was 2 years before GM introduced "common architecture". Common arch was the first GM car/truck electrical architecture that was 100% GMLAN, using GMLAN on the interior and completely abandoning Class 2.

They called it common-architecture because 95% of all the modules were all the same regardless of car/truck/SUV...just different trim plates to accommodate different dash/interior designs. The common-arch era/generation Caddy DTS, CTS, acadia, silverado, tahoe, impala, express van etc all use the exact same door modules, HVAC modules, switchgear, radios, RCDLR, RPA, BCM, CAN messaging etc.

Why GM's first foray into CAN used the older ID subset, and then they retired it on new platforms 1-2 years later when common arch began to be rolled out....I have no idea.

CAN wasnt on the 05 Impala. It started in 06.

Quote:

---

Originally Posted by DURAtotheMAX

Why GM's first foray into CAN used the older ID subset, and then they retired it on new platforms 1-2 years later when common arch began to be rolled out....I have no idea.

---

That's good to know. Whats strangers is the Corvette still using that early GMLAN introduction in 2012.. Musta had a bunch of pre-programmed BCM's on the shelf... lol

What you have for ID's and Byte outputs on that early data set Ben? I've got a few tagged from bench testing so far, but what I need is Tach, Load, and APPS. My test Vette is still in the shop getting a new ECM programmed untill next week sometime. So got me on hold. Shoot me an Email if ya have anything please.

Ross, I'm going to attempt a cax file from scratch to move that pin assignment. I see {G1221} isn't used in the 12609099 OS. Is that a good choice that shouldn't interfere under other E38 OS version either? Only checked a couple others so far. Thanks

-K

Success!!

Attachment 21646

X2 Pin 23 signal now displaying as "True" EOT values under GM.EOILTS. :master:

Should work perfect in stand alone setups.

Related notes so far.
*Trans Temp value reads 350F now. So this might require a DTC or other related table changes.
*Standard OBD-II Engine oil temperature PID 0x5C doesn't report it. Mode 22 Pid looks fine.
*No assigned byte position for EOT values detected in HS GMLAN broadcasts. However, EOT, MAP, and AC Pressure all seem to tie into high priority msg ArbID 0x120 42 5a 62 5a 42 5a 03 11

That needs a little more research, but the hard part's done.

Thanks again Ross.

Did a little more bench testing today. Looks like standard OBD-II 0x5c EOT pid still reports the "estimated" EOT values relating to IAT and ECT inputs. Which brings up another question.

How can we determine which EOT data the following tables are actually using?

{B5212} Rev Limiter By Oil Temp
{B5213} Rev Limiter By Oil Temp Enable RPM
{B5214} Rev Limiter By Oil Temp Disable RPM

Is that controlled by options {G1218} ?

For the pin mod to be effective, we should verify connected tables are also using it correctly.

Attachment 21647

For reference: E38-OS12628594-amp-OS12628990-Oil-Temp-Pin-Assignment

Would ya happen to know that pin address under OS 12614676 ? That is the correct O7 LS7 version, not the 12639835 I previously listed...

Just caught that tonight when I stated to update this 06-07 ECM, and noticed the VIN description said 5.3L .. :unsure:

Glad it worked :cheers: