PDA

View Full Version : Any idea why this OEM table is so strange?



GoneNomad
February 24th, 2014, 02:05 PM
Seeking help from EFI tech support...

Why is this 3500 LMM van high altitude table (in the unmodified oem tune)
16444
is so different than the low & medium altitude tables?
16446

Also, none of the tables for an LMM 3500 pickup or 5500 Topkick are like that:
16443

THEFERMANATOR suggested elsewhere (http://duramaxdiesels.com/forum/showpost.php?p=796328&postcount=5) that this could just be a mis-scaled table.

But the table data itself matches what is shown on the map of that table:
16445

My concern is that there may have been some type of read or interpretation error between what is actually on the ECM and what shows up in the table in the .tun file. I did read the oem tune off the ECM three times, and in all cases this table is the same, so at least it's consistent.

If this table does have erroneous data in it, I could run into a problem even if I flashed the same .tun back to the ECM.
But in this case I might not ever see any adverse effect unless the vehicle was at high altitude.

Any suggestions would be greatly appreciated...

GMPX
February 24th, 2014, 03:12 PM
That looks like a case of the table size is not what EFILive is expecting, don't alter the values.
Very odd that is the first instance of this reported for an LMM considering how long programming for them has been out, are you able to please Email support@efilive the stock tune from that vehicle.

Thanks,
Ross

GoneNomad
February 24th, 2014, 04:33 PM
That looks like a case of the table size is not what EFILive is expecting, don't alter the values.
Very odd that is the first instance of this reported for an LMM considering how long programming for them has been out, are you able to please Email support@efilive the stock tune from that vehicle.

Thanks,
Ross

Email sent.

FWIW, the oem tune is posted here (http://www.tunefiledepot.com/index.php?option=com_content&view=article&id=4&Itemid=3&Manufacturer=5&VehicleType=D&Stock=Y):
http://www.tunefiledepot.com/calibrations/stock/GMC/2010%20GMC%20Savana%20Truck%20Automatic%20LMM%206. 6%20Litre%20(12628594).tun

Tordne
February 24th, 2014, 10:34 PM
No email received as yet. Please resend.

GoneNomad
February 24th, 2014, 10:57 PM
No email received as yet. Please resend.

From: gonenomad@xxxx.com
To: support@efilive.com
Subject: re: why is this OEM LMM table so strange?
Date: Mon, 24 Feb 2014 20:38:06 -0700

It's also posted here:
http://www.tunefiledepot.com/calibrations/stock
http://www.tunefiledepot.com/calibrations/stock/GMC/2010%20GMC%20Savana%20Truck%20Automatic%20LMM%206. 6%20Litre%20(12628594).tun

GoneNomad
February 24th, 2014, 10:58 PM
From: gonenomad@xxxx.com
To: support@efilive.com
Subject: re: why is this OEM LMM table so strange?
Date: Mon, 24 Feb 2014 20:38:06 -0700

I sent it again just now. You can also access the tune at this link (http://www.tunefiledepot.com/index.php?option=com_content&view=article&id=4&Itemid=3&Manufacturer=5&VehicleType=D&Stock=Y), also in the post above.
2010 Savana Automatic 6.6 Litre (LMM) 12628594 (ECM) E35 1.8 M

Tordne
February 25th, 2014, 08:22 PM
Came through this time. I have forwarded on.

GMPX
February 26th, 2014, 03:26 PM
Ok the problem is as suspected, on that vehicle instead of the table being the normal 23 x 23, GM made it 17 x 22, why oh why!
The problem for EFILive is it only knows that table as 23 x 23 for that OS (it shares the same OS number as the trucks), for now, just don't touch that table until we figure out a solution to this problem.

GoneNomad
February 27th, 2014, 11:59 AM
Ok the problem is as suspected, on that vehicle instead of the table being the normal 23 x 23, GM made it 17 x 22, why oh why!
The problem for EFILive is it only knows that table as 23 x 23 for that OS (it shares the same OS number as the trucks), for now, just don't touch that table until we figure out a solution to this problem.
Thanks...

But I see the same number of rows (23) and columns (23) in both tables.
However, I am using the northern hemisphere standard for counting ;)
(sorry couldn't resist; don't hold it against me. New Zealand is where I always wanted to go when fleeing the Zombie Apocalypse) ;)

GoneNomad
February 27th, 2014, 12:38 PM
Now that I've stared at it long enough, I also see what the problem may be...

OK, hopefully it's easy to see what I did here:
16451
Every column of cells in the out of whack triangular section in the original table has been moved as far down as each column can go.

The cells that were in the bottom row in the original table are denoted by a light blue background color.

Every partial column of cells that was originally below that triangular section has been moved up as far as each column could go.


It looks like this fits fairly well, however there appear to be a few possible transpositions, which are denoted by the dark blue background.

The thing is, I found this because it was so visually obvious.
What has me concerned is the possibility of other tables that could have errors that aren't so obvious.

As to why this might not have shown up before now, since the LMM has been out so long...
GM didn't build many LMM vans compared to the number of LMM pickups, and far fewer van owners modify their vehicles at all, and of those who do, most send their original tunes off to a tuner and hope for the best, and may never have really scrutinized the tables closely.

GMPX
February 28th, 2014, 12:11 PM
Thanks...

But I see the same number of rows (23) and columns (23) in both tables.
That is the problem, EFILive is expecting that table to be 23 x 23 for that OS, in the Van it is not but it is still plotting it as though it was. I cannot think of any sane reason GM would do that.


However, I am using the northern hemisphere standard for counting ;)
(sorry couldn't resist; don't hold it against me. New Zealand is where I always wanted to go when fleeing the Zombie Apocalypse) ;)
In New Zealand they only just got electricity so I'm ok with that comment ;), (I'm in Australia, so it's like the US v Canada thing going on down here).

GoneNomad
February 28th, 2014, 12:34 PM
That is the problem, EFILive is expecting that table to be 23 x 23 for that OS, in the Van it is not but it is still plotting it as though it was. I cannot think of any sane reason GM would do that.
Thanks... OK, so that means you must have a way of looking at the internal structure to determine the 17 x 22 table size.

This makes me wonder how tuners who've done tunes for LMM vans have gotten around this problem.
The answer is could be that 2010 LMM vans are so very rare (GM only built them for three weeks in Sept. 2009), and so rarely modified, that maybe none of them have tuned one yet.

What still has me concerned is the possibility of other tables that could have errors that aren't so obvious. So if there's a way you have to "audit" the tables in the file for table size errors, which when rendered as 23 x 23 might not be so obvious, that would be helpful.

I guess you've already seen that this table (and others like it) is 20 x 20:
16453
and I hope it's supposed to be that (different) 20x20 size...

joecar
February 28th, 2014, 01:23 PM
If a table has this kind of error (different number of row x cols than expected) then you will see the Z-shaped 3D surface same as you pasted in post #1.

GMPX
March 1st, 2014, 02:49 PM
What still has me concerned is the possibility of other tables that could have errors that aren't so obvious. So if there's a way you have to "audit" the tables in the file for table size errors, which when rendered as 23 x 23 might not be so obvious, that would be helpful.
I'm not really sure what you are asking for, think about it this way, there has been no changes for the LMM calibrations for maybe three or so years, this is the first instance of an odd table size in a rare vehicle, it's not like we should hit panic stations (which is sort of what you are suggesting).

So the other table you have is a 20 x 20, true, are you asking is EVERY table supposed to be 23 x 23 because some others were?

GoneNomad
March 1st, 2014, 08:12 PM
So the other table you have is a 20 x 20, true, are you asking is EVERY table supposed to be 23 x 23 because some others were?
No, but when I asked that question, I had no way to know that 20x20 table was not another misinterpretation of a 23x23 table.
joecar's subsequent answer indicates otherwise, that any table size mismatch would have a tell-tale "Z shaped" map.
Since I don't know who "joecar" is, do you concur?


I'm not really sure what you are asking for, think about it this way, there has been no changes for the LMM calibrations for maybe three or so years, this is the first instance of an odd table size in a rare vehicle, it's not like we should hit panic stations (which is sort of what you are suggesting).
Well, I never said or implied anything about hitting panic stations. This is not a code red, priority one deal. I am aware that it's a low volume vehicle, since I pointed that out too.

So to clarify my non-panicking situation, I am hopeful there will be an eventual solution to this and any other table size mismatches that are discovered, maybe in a month or two? Is that reasonable? ...since you did say:

... for now, just don't touch that table until we figure out a solution to this problem.
...My assumption is that if I flashed even the unmodified OEM tune back to the ECM, a table size mismatch like B1169 might cause a problem, because the unmodified tune has 23x23 when the ECM is expecting 17x22. I am assuming it doesn't automatically put 23x23 back into 17x22 just the way it was on the ECM originally. Is that right or wrong?

As far as:
"What still has me concerned is the possibility of other tables that could have errors that aren't so obvious."
...it still does. If I had to depend on whatever you did to determine that B1169 is 17x22 rather than the expected 23x23, then someone on your end (or using your method, at least) would have to do it. But joecar already answered how to check for other instances of those table size errors: by looking for the tell-tale "Z shaped" map. That being the case, I can do the audit myself. As long as I can find any tables affected this way, finding them shouldn't be a problem.

But checking for any other table size mismatches still doesn't solve the problem with B1169 (and any others that happen to be like it).
___________________________________________

Thanks for your help.

I am fully aware that we DMax van owners have to make do with what we get, and I am thankful that EFILive supports DMax vans at all.

killerbee
March 2nd, 2014, 01:04 AM
In addition to the rarity of the LMM van, it is also a high altitude table. Most tuners have not even looked at it, those that do rarely want to spend time modifying a table that will rarely be utilized for most customers. Not too many race strips at 10,000 ft.

GoneNomad
April 12th, 2014, 03:53 AM
OK, it's now been six weeks since the nature of this problem was identified.

I hope I am not coming across as hitting the panic button to ask if there is a solution forthcoming?

GoneNomad
April 29th, 2014, 11:05 AM
OK, two months later...

If you have a way of looking at the internal structure of the hex file to determine the table size is 17 x 22 instead of the expected 23 x 23, can you also see the values in each cell of that table?

If so, wouldn't it be possible to manually enter those values into the first 17 x 22, and then leave the cells outside that range blank?

Or are the row & column header values in the different sized table also different? (If not, never mind). If so, is there no way to change them?

joecar
April 29th, 2014, 12:18 PM
If that table has a Z shape to it, then do not edit it.

GoneNomad
May 1st, 2014, 06:43 AM
If that table has a Z shape to it, then do not edit it.
Thanks. I understood that the first time it was mentioned.
Still hoping there will eventually be a way to correct this problem instead of just avoiding it.

rhilali
October 21st, 2021, 10:30 AM
Hi, sorry to dig up an old thread, but was wondering if anything got done about this.

I am having issues with my 2009 deleted LMM express 3500 when it runs above 5000ft.

The problems are identical to the ones laid out by another LMM 3500 owner laid out in this thread https://www.dieselplace.com/threads/altitude-electronic-sickness.736202/

In the end he had to delete the altitude tables in order to get his van running with a delete above 5000ft. His van ran fine at these altitudes when brought back to stock (with emissions)

I think this table mismatch is the cause of these problems LMM 3500 vans. Has it been fixed in a newer version?

Tre-Cool
October 25th, 2021, 10:13 PM
since it uses the same calibration numbers as the trucks, can you just use a truck cal?