These instructions apply to any $6E BIN with the WBo2 AFR patch (ARAP, APYP, etc.). Thanks to MikeT88IROC350 at ThirdGen.org for testing these changes.

When reporting of WBo2 AFR was added, reporting of the following items was eliminated:These instructions reinstate that reporting. In addition, they provide reporting of MAF Sensor Voltage.
xx
Hex values referenced below:x
There are 3 reporting options, each of which requires changes to the ADX and BIN (see “Reporting Option Table” below):x
Required ADX Changes Regardless of Reporting Optionxx
After the above ADX changes, the Table below provides the BIN changes and the additional ADX changes required to report according to the desired Option.

Reporting Option Table


Scaled MAT Table

 

This is good stuff here. It was a fun project getting the changes to work. Hopefully other fellow TGO'ers can make use of it. Just need a little bit of experience with TP, to make the changes.
I'm attaching a link to one of the original posts, regarding the topic of getting the WB data into the ALDL stream.
Mike

https://www.thirdgen.org/forums/diy-...ml#post4216094

 

Anyone using this w the Zeitronix ZT-2 WB. I’m thinking about merging my WB readings w my $D0A LT5 Mask.

 

My MAT scaling table is a bit different. Here's what I have been using lately for $32B MAT scaling (for data display purposes only) expressed as a 17 row table with fixed spacing and h = 16.



This scaling was developed from the INVADMAT table shown below which came from a hard copy of original $32B source material. This is the only thing that I've seen to actually document the MAT scaling. Note the old comments are a bit misleading, so I applied the -40 °C offset as shown in my table above. I believe this to be correct.

Note: This code excerpt shown is for the proms installed in the I2U unit, not the ecm/memcal, but it is included in the project. Scaling should be representative.

 

A couple of things:
1) Your reference appears to be to $32B and not $6E. They may be the same, but don't know. My reference is specifically to $6E.
2) My use of the descriptor "Scaled MAT" may not be semantically correct, but it was used to indicate that the A/D it refers to is different than the A/D from the sensor. I don't believe it's the same as the scaling you are referring to, and this distinction is important.

Sorry for the length here, but it's needed for me to make sense of this.

Background
In $6E, an inverted A/D value is obtained from the MAT sensor and is immediately inverted by the code (so it's no longer inverted). The resulting non-inverted value is stored in 2 variables: L0061 and L0130. If the L0061 value does not indicate a MAT sensor error, a value is extracted from a table internal to the code at 0xFFA7, which is stored in L0061. Table below:

; L0061 "Scaled MAT" Output from MAT A/D Sensor Input
LFFA7 FCB 0
LFFA8 FCB 42
LFFA9 FCB 61
LFFAA FCB 75
LFFAB FCB 85
LFFAC FCB 95
LFFAD FCB 103
LFFAE FCB 111
LFFAF FCB 120
LFFB0 FCB 128
LFFB1 FCB 137
LFFB2 FCB 148
LFFB3 FCB 161
LFFB4 FCB 176
LFFB5 FCB 199
LFFB6 FCB 227
LFFB7 FCB 255
;==============================================
L0061 is used throughout the code for table lookups requiring MAT. It is these values I've called "Scaled" because they are not MAT sensor A/D, but rather a modified (or "Scaled") representation.

Unlike L0061, L0130 remains untouched in the code and is used for MAT temp reporting by the ADX. Here's a representation of the ADX table commented in the code. There are a couple of differences between this table and most $6E ADX files, but they are inconsequential:
;---------------------------------------------
; MANIFOLD AIR TEMPERATURE TABLE
; Accessed in the ADX by L0130, Packet Offset 29d
;
; DEGREES C Output from Sensor A/D COUNT Input
; ---------------------
; -40 0
; -30 4
; -25 5
; -20 8
; -15 10
; -10 14
; - 5 18
; 0 24
; 5 30
; 10 37
; 15 46
; 20 56
; 25 66
; 30 78
; 35 90
; 40 103
; 45 116
; 50 129
; 55 141
; 60 153
; 65 163
; 70 174
; 75 183
; 80 191
; 85 199
; 90 205
; 95 211
; 100 216
; 105 221
; 110 225
; 115 229
; 120 232
; 125 234
; 130 237
; 135 239
; 140 241
; 145 242
; 150 243
; 200 255
;==============================================

Note that neither of these tables is inverted, indicating that the MAT A/D used to access them is not inverted (low A/D In = low value Out). Also note that the 2 tables are significantly different.

WB Patch
When the WB patch was added to $6E (ARAP and APYP), variable L0130 was eliminated from the code because there were not enough bytes available to retain it. Only L0061 remained because it was needed for MAT table lookups. So without L0031, MAT could not be reported.

That brings us to L0061 which I've called "Scaled MAT". Since it is the only remaining MAT-related variable, and because it's the only MAT-related variable in the Mode 1 ALDL data stream, it's the only way MAT temp can be reported. But L0061 can't be used to lookup a temp from the ADX table because the values do not bear the same relationship. So something had to be done to translate the Scaled L0061 MAT A/D values to MAT temp.

The result was a curve fit of values derived from a code simulation using MAT A/D sensor values that provided known MAT temps (*F) and known Scaled MAT A/D values. The Scaled A/D to temp relationship is represented by the "Scaled MAT Table" in Post #1 above. This table of selected data points was used for simplicity rather than the 6th order polynomial equation necessary for a good non-linear curve fit. Because L0061=Scaled MAT is in the Mode 1 ALDL data stream at 0-based offset 28, it's temperature equivalent can now be reported using a table lookup in the ADX.

Hope this makes sense. If anyone sees this differently, am open to any and all input to make sure this is correct.

 

Interesting stuff.

Sorry, I didn't realize that $6E already had an internal table to scale the MAT at LFFA7. This is something that is not present in $32B. The internal scaling is a bit peculiar however, resulting in some strange units (approx 0.75 °C/bit). More on this later.

I now see that you are re-scaling the already scaled MAT signal (L0061) rather than scaling the raw (inverse MAT) a/d (L0130), which makes sense, since L0130 is no longer available. After trying a few sample points, I see that our results do converge.

Using 96 a/d as an example: 96 scaled by the LFFA7 table is 103. 103 re-scaled by your table returns about 99 °F ( or 37.2 °C). 37 °C ( or 98.6 °F) corresponds directly to 96 a/d counts on my table which is what we started with, so an a/d value of 96 = 37 °C according to both methods. So far, so good.

I have to wonder why the internal scaling of L0061 (the LFFA7 table), wasn't just scaled to output T+ 40 °C in the first place, like the INVADMAT table from my $32B example in order to output the scaled value in °C directly. Instead, its a weird factor of approx. 1.33 for most values resulting in approx. 0.75 °C per bit, which seems to be arbitrary.

If I was running $6E myself, I'd be tempted to replace the internal scaling table at LFFA7 with my table's T+40 values, and simply subtract 40 from L0061 for output in °C and convert to °F if desired in the adx. No lookup table required. This might require some minor re-tuning wherever the scaled MAT signal is used, but seems like a simple, logical solution.

Example implementation:

;----------------------------------------------
; Inverse MAT LOOK UP (Alternate scaling)
;
; intended to output MAT (T + 40) DEG C
;----------------------------------------------

LFFA7 FCB 0 ;
LFFA8 FCB 33 ;
LFFA9 FCB 46 ;
LFFAA FCB 56 ;
LFFAB FCB 64 ;
LFFAC FCB 71 ;
LFFAD FCB 77 ;
LFFAE FCB 83 ;
LFFAF FCB 90 ;
LFFB0 FCB 96 ;
LFFB1 FCB 104 ;
LFFB2 FCB 111 ;
LFFB3 FCB 121 ;
LFFB4 FCB 133 ;
LFFB5 FCB 149 ;
LFFB6 FCB 178 ;
LFFB7 FCB 240 ;
;---------------------------------------------

Using 96 a/d again as an example with my T+40 values instead of LFFA7: 96 a/d would be scaled to 77, instead of 103. 77-40 = 37 °C. Bingo.

Hope this is clear, and sorry for any confusion caused by my previous post. I wasn't quite on the same page at the time, but I think both of our inputs validate each other.

 

Very clear, no confusion and no apology needed.

It appears GM structured things the way they did to provide a linear relationship of MAT A/D to temp. Thus the requirement for the 0xFFA7 table. It contains 17 elements which is the maximum table length that can be used in 8-bit code (elements 0-16).

But as can be seen below, the MAT A/D to temp relationship is non-linear and can't be used. This is why MAT temp is determined from MAT A/D in the ADX via a table lookup. But the internal code Scaled table 0xFFA7 provides a linear relationship from about 0 to 225*F to enable linear internal code table lookups for MAT-based data (eg - startup spark & PW tables, etc.).

 

As a follow up, I dug up an old $6E log to play around with (without the WB02 patch). After a bit of tinkering with the adx, I displayed the inverse MAT a/d (L0130), the MAT scaled signal (L0061), and also simplified the MAT Lookup Table (Deg C) to 17 rows according to my T + 40 table values discussed previously.

As expected, the scaled MAT tracks the LFFA7 table perfectly for a given a/d input, the new (17 point) MAT Lookup Table (Deg C) fits as well, and the old (38-point!) MAT Lookup Table (Deg F) from the adx is still in the ballpark subject to interpolation.

96 a/d -> 103 scaled MAT -> approx 99 °F (your new lookup)
96 a/d -> 37 °C (from new 17-point lookup)
96 a/d -> 98.46 °F (from old 38-point lookup already present in the adx)

A/d values: 64, 80, 96, 112 and 128 have been verified (to explicitly check the input/row values) but the range of data is limited in this particular log. Values in between are interpolated, of course. I will try and find a log of a hot boost supercharged car with a larger range of MAT temperatures.

So for $32B (and $6E with L0130 present in the datastream), the MAT lookup (Deg C) can be simplified to 17 points and can easily be converted into a corresponding (Deg F) table. If 17 rows are good enough for the ecm scaling, both internal and external (I2U unit), its good enough for me.

Here's what an I2U looks like for reference:





For $6E with WBO2 patch or not, I still like the idea of replacing the LFFA7 scaling with my alternate scaling and simply displaying the scaled MAT value directly, minus the 40 °C offset for display in °C along with a simple conversion to °F. $6E users are free to try it for themselves, of course.

Unfortunately, the MAT signal itself just isn't all that interesting or useful. In practice, the MAT sensor is very slow to respond to temperature changes, since it is a coolant temp sensor after all. The open-cage style sensors may be better in this regard, but I have no supporting data. In slot-style maf conversions for tpi applications with an analog Ford style sensor, I like to replace the MAT signal with that from maf's integrated IAT sensor (which requires new lookup tables and corresponding programming changes where applicable). I don't want to muddy the waters here by posting yet another lookup table and resistance chart in order to avoid adding to the confusion.

I will also go ahead and play with the internal scaling to better integrate the IAT into $6E going forward if there is any demand.

 

Another way of simplifying things: we can combine both input/output tables and use the LFFA7 table output values directly as the input and use either my MAT °C or MAT °F table values as the output and create another pair of 17 point lookup tables between scaled MAT (L0061) and temperature in the desired units. I will post up a table when I can. Should be a bit easier to manage than the 39 point table.

No pretty formatting here, but should convey the idea for both units:

Scaled MAT MAT °C MAT °F
0 -40 -40
42 -7 19.4
61 6 42.8
75 16 60.8
85 24 75.2
95 31 87.8
103 37 98.6
111 43 109.4
120 50 122
128 56 132.8
137 64 147.2
148 71 159.8
161 81 177.8
176 93 199.4
199 109 228.2
227 138 280.4
255 200 392

I never would've thought we could have so much fun with MAT scaling.

 

Ain't that the truth, but makes my head hurt.

Interesting analysis and good insight. A few thoughts:
1)
Certainly the 17 element lookup will work. But I believe the reasoning for the larger 39 element MAT ADX lookup table is because the sensor ohms, and thus the resulting sensor A/D counts, are non-linear. With a lookup table, any A/D that matches a data point, regardless of whether a 17 or 39 element table. will provide an accurate value from the table. However, when an A/D count does not match a data point, as you said, an interpolation is required. And for MAT, there is a linear interpolation between 2 non-linear data points. Error is guaranteed in this process. How much depends upon the non-linearity between the 2 data points. With more data points, there is less error and possibly GMs logic for the larger table. Better resolution.

2)
Having said the above, with everything linear, the linearity of the Scaled MAT A/D to temp is good from approx. 0-225*F. Anything outside that, not so much. Because GM is using the Scaled value for only calibration table lookups, they apparently were not worried about anything outside that temp range as evidenced by MAT-only table output values at the extremes being generally close to each other if not the same.

3)
Regarding TPI MAT sensor (actually a hard core coolant sensor) .vs. a true IAT sensor (eg for LT1), I've found the ohm curves to generally be the same. Based on your comment about differences, would be interested in any IATs (part #, etc.) you've seen where a difference exists. Not disputing your observation, just want to avoid them. Tks.

4)
This is a nit but causes confusion. MAT sensor output is not inverted when used despite most documentation, code hacks, etc. referring to it as "inverted". The sensor ohm curve IS inverted (higher ohms = lower temps). But when the sensor is read and an A/D value is returned by the ECM, the code immediately inverts it so the resulting value is no longer inverted. Proof is that the 0xFFA7 Scaled MAT A/D table is not inverted, and it's that way because it's accessed with a not inverted MAT A/D.

Good discussion!

 

Roger that. I relocated my MAT to an IAT, long time ago. After learning about the common "heat soak" issues with the MAT installed in the underside of the plenum, it was the general consensus to move it forward in the airstream. Somebody sells these re-location kits, and I went for it. My IAT is in the plastic duct, between filter and MAF sensor. There is even a "boss" or location, that this sensor fit perfectly. Now, since I been using the WB version of ARAP, for long time, reported MAT was stuck at -40. Didnt really care too much about that, and as the years went by, learned that MAT wasnt used for much in the code. Recently, this winter had a tinkering of getting the data out, to be reported correctly. It's more of "I just want to know" what the incoming air temp really is. The IAT, is a dry-bulb sensor, so it should respond faster than "coolant style" MAT. Time will tell, stay tuned for results........

 

Based on the Delphi info I have, the dry-bulb IAT is considerably faster than the brass MAT/Coolant sensor. According to Delphi, temperature response time is determined based on what's called the "Thermal Time Constant", which is: The time required for the sensor to achieve 63.2% of its steady state value when subjected to a step change in temperature.

Thermal Time Constants:
IAT (GM Delphi # 25036751, 25037225, 25037034): < 15 seconds
MAT/Coolant (GM Delphi 12146312): 20-30 seconds

Also, the resistance curves since we were talking about them earlier. Some slight differences; but in 8-bit hex-code land, they're nothing more than rounding errors:

IAT


MAT/Coolant