PDA

View Full Version : E35 IAT & IAT2 PIDs.



Cougar281
August 8th, 2010, 04:22 AM
Ross/Paul, just an FYI, all the E35 IAT PIDs are wrong. IAT is nowhere to be found (that I could find), and the PID you have as IAT is in fact IAT2. I don't know what AAT is or really where it's measured (My best guess is one of the two sensors in the grille), but it's nowhere in the intake tract.

With all due respect, it would be nice if you would fix problems (E35 PID problems like this, LLY MAF table limits (http://forum.efilive.com/showthread.php?13733-LLY-MAF-table-limits), etc) and even more importantly, finish existing projects (It's been almost four years since I bought my V2, at which time, standalone functions where supposed to be "coming soon"..... four years isn't exactly soon....) before taking on new projects (IE: Cummins development).

GMPX
August 8th, 2010, 11:14 AM
Ross/Paul, just an FYI, all the E35 IAT PIDs are wrong. IAT is nowhere to be found (that I could find), and the PID you have as IAT is in fact IAT2. I don't know what AAT is or really where it's measured (My best guess is one of the two sensors in the grille), but it's nowhere in the intake tract.

You need to have an understanding of how GM's PID definitions work before blaming EFILive for this problem. Fact is Bosch made a mess of the PID's on the E35, as they did on a number of communications issues with that ECM.
SAE.IAT, this is a standardised PID for the #1 intake temperature sensor, as some of GM's applications use 2 Intake temp sensors (Supercharged GenIV V8 is another one) GM added another non SAE PID called GM.IAT2, specifically for the 2nd intake temp sensor.
It is not up to EFILive (or GM it appears) where the Bosch engineers decided to assign the function of those PID's to. If they report back as supported but the ECM is sending back some other information there is nothing we can do.


With all due respect, it would be nice if you would fix problems (E35 PID problems like this, LLY MAF table limits (http://forum.efilive.com/showthread.php?13733-LLY-MAF-table-limits), etc) and even more importantly, finish existing projects (It's been almost four years since I bought my V2, at which time, standalone functions where supposed to be "coming soon"..... four years isn't exactly soon....) before taking on new projects (IE: Cummins development).
E35 PID problem, you'll need to contact Bosch if you want them fixed, the ECM is broke!

Cummins is not released, black box reading / flashing is released. Yes it has taken a long time, we grossly underestimated what was going to be involved.
The LLY MAF table limits, I had changed them to the maximum mathematical limit of 512 (up from 500), we just have not regenerated the calibrations with the new limits.

You think Microsoft would be where they are today if they were still perfecting Windows 98 and not developing new products? It's foolish to assume you understand how development works at EFILive, me working on Cummins and all the new GM ECM's and OS' had virtually no impact on the Black Box reading / flashing development.

We don't mind some criticism, feel free to vent, it's all good, it keeps everyone on the ball. But really, consider what an LBZ / LMM owner is getting with EFILive and I think these minor issues (I consider a PID wrong minor) pale in to insignificance when you are getting a switchable tune, scan tool, stand alone reading / flashing all for about the same cost as some of the handhelds.

Cougar281
August 9th, 2010, 12:11 PM
Ross, I can't even pretend to know what you guys do over there. When it comes to coding, I'm a complete retard, but look at it from a customers view. Customer sees that you're releasing a product that the biggest feature of is all these standalone functions (read, flash, log, DTC, etc), but right now at release, it's pass through only, with the rest coming soon. Now fast forward about four years and customer sees that the product STILL isn't done, flashing is in beta with at least one more part that isn't even that far (BBFF), and they see that you're now doing development for an entirely new platform. The average customer will just see "Hey, they're starting another project and haven't even finished the one that was expected to be done a few years ago".

As far as the PIDs go, yes, they could be considered minor, although I'd think the ability to see the delta between the IAT1 & IAT2 sensors could be usefull. The current IAT PIDs are causing a bit of confusion. An example of where it would be usefull to see IAT1 would be if I'm trying to lower IAT's via aibox mods. IAT2 will not show the changes the way IAT1 would.

I could be showing my ignorance again, but since you already know a lot about how the PIDs work, I assume you have a Tech2 and hardware/software to scan & log the busses, would it be possible to log the "Engine Data 1" datastream and pick out the PIDs? Or isn't there a whitepaper somewhere? Autoenginuity appears to have the IAT PIDs right (I say "appears" because I don't have it yet, primarily for Non-GM applications since I have EFILive & a Tech2, but IAT1 & IAT2 show up in their PID list (http://www.autoenginuity.com/vehicle_samples/GM/Chevrolet2006Duramax/ChevroletDuramax6.6L2006-Engine-SensorList2.htm)).

Having said that, despite the delays with the V2 and these PID issues, I still think EFILive is the best, highest quality product we have available :cheers: