two big $EE questions

[steveo]

it's nearly 20 years since EE was released, and i've taken too long of a break from disassembly.

there are two questions i really want to answer this year as i start tuning yet another LT1

1. where does the spark variance in power enrichment mode come from, and can it be tuned. i have (and other people have) observed at least a few degrees of additional timing that can't be explained by other tables.

2. how exactly is the VE table used when calculating airflow in MAF mode. the table lookup isn't skipped when using a maf. setting the VE table to rediculous values such as *1.9 or *0.2 causes a giant swing in AFR, so it's definitely used somehow.

[RobertISaar]

the EE speed-density vs MAF thing has always been something I've been curious about but never investigated..... assuming I have a day off soon, i'll probably dig around and see what comes up.

as for PE advance, that should be fairly easy to find, assuming other spark modifiers have been found/added to the XDF.

[RobertISaar]

looking through the code for VE vs MAF now.

at 6196, the code tests for the "speed-density" bit, if it is set, the MAF calcs appear to be skipped. so, speed-density appears to be in effect at all times.

there's actually so much important stuff missing from the XDF.... and it's ridiculous to accurately identify what a bunch of 2D and a few 3D tables are doing that aren't defined. I'm trying to find what I assume to be a MAF vs speed-density blend factor, but I haven't come across it yet.

[steveo]

that ku4ro guy that was kicking around before was making progress towards understanding fueling calcs but im not sure how far he got.

the thing is the factor which VE affects fueling in MAF mode is kinda the unknown variable. a blend table would make sense.

there are some really odd looking tables that kinda scale like fuel would, but i've never been able to track anything backwards to anything i understand as part of fueling calculations.

[steveo]

... but on the upside, i finally have the stuff to build a bench testing setup, a spare ECM, and i've mastered a lot of memory i/o stuff. i have sockets on order so i can protect against flash failures. so i can do a lot more discovery from the aldl side really soon..

mode 4 in this ecm is great. you can offset timing on the fly. it's nearly as good as an emulator for definining timing tables while driving. you can also do straight fuel offsetting in closed loop by forcing trims to stick in the current blm cell, then adding or subtracting.

[RobertISaar]

a lot of the later PCMs with mode 4 are similar in capabilities. dig far enough and you'll likely find some bits that will allow you to shut off individual or combinations of injectors. interesting for diagnostic purposes, along with seeing what happens when you shut off a bank or alternately shut off cylinders in the normal firing order. I found out a 3100 will apparently idle somewhat happily on 3 cylinders.

we need to get a good collaboration thread going and demystify what is probably the second most complex OBD1 controller GM released.... the 93-95 northstar PCM still feels like it has even more craziness going on.

[steveo]

dig far enough and you'll likely find some bits that will allow you to shut off individual or combinations of injectors

yep; and wrote a routine to use it to do automated cylinder drop test and report a snapshot of each cylinder's map sensor reading to find non-firing or weak cylinders easily. definitely nice to have.


we need to get a good collaboration thread going and demystify what is probably the second most complex OBD1 controller GM released

i wish i could be a bit more helpful with the disassembly. i can write complex branching routines in my own programs but when it comes to reading existing assembly, i still struggle to understand more complex routines. the amount of work that goes into writing a full 'hack' of an ecm is staggering.

[kur4o]

Hi to all.
I didn`t make great big progress lately but I post my latest findings.
The things about maf vs map.
Maf is used all the time except when MAf system error is set. Skip routine is located at loc_6337.
If Byte 2029 bit $08 = zero, Map calculations are always skipped.
If there is a spark adder routine it is located at loc_5F96, but still not sure what is doing.
I found that above 4000 rpm some tables are not updated every processor cycle, including main spark table. That may induce the spark adder but still not sure about it.
The skip routine is based on byte_a5, and it`s related to CYLID.

[RobertISaar]

looking at it with more sleep: interesting:

the XDF I have implies 2028 $2 to be the "speed-density" select bit. when the bit is clear, MAF calcs are allowed. when set, all of the MAF calcs are jumped over(code immediately shoots down to 6379(which goes through the logic of cranking vs low vs high VE tables).

2029 $8 does appear to allow/disallow speed-density calcs...

so, 2028 $2 might be better described as "MAF disable" and 2029 $8 might be better described as "speed-density enable", which would appear to allow the program to run in either exclusively speed-density or exclusively MAF.

[steveo]

2029 bit 8 does appear to be unset in every factory calibration including speed density caprice bins

maybe i should flip the bit and go for a drive with a flat 80% VE table and see what happens

[RobertISaar]

you probably don't want to flash it more times than necessary, but I would try a run with just the bit changed, then a run with the bit changed and a borked VE table, just to make sure it doesn't affect other stuff in the calibration.

[steveo]

i'll probably have a chance tomorrow. the weather is really nice and im doing the two wheel thing right now. good thing it isn't tuneable, or i'd surely be putting any $EE on hold for the entire summer.

[bybyc5]

You guys are way above my pay grade..
I would love to understand the hack process, and read a lot of these threads in awe. And get lost quick!

I would love to be able to set a closed loop target afr in these pcm's. Like in my K1500 16168625, setting this from 14.7 to 14.1 made a world of difference. Now that we have more ethanol added to our fuel which we didn't have as much of back in the early 90's. This does change our true closed loop afr.

I have tuned a few LT1 obd1 PCM's over the years and always wanted a richer closed loop target afr.

Just wondering if you have located this part of the diss-assembly?

Thank you,

Keith

[steveo]

I would love to be able to set a closed loop target afr in these pcm's. Like in my K1500 16168625, setting this from 14.7 to 14.1 made a world of difference. Now that we have more ethanol added to our fuel which we didn't have as much of back in the early 90's. This does change our true closed loop afr.

see attachment. you have to change both to match.


You guys are way above my pay grade..
I would love to understand the hack process, and read a lot of these threads in awe. And get lost quick!

i know how you feel.

i am a total assembly noob, i wish i could help more with it.

i'm a fairly good programmer with low level languages, in fact i could certainly write this entire thing in assembly if i had the time. i've written assembly for control systems before.

but understanding existing assembly like this is just a mindf#%k to me sometimes.

sometimes you find a variable, and you're like ok. this is obviously a fuel scaler thingie. it's multiplied against the injector constant. it's referenced again near a routine that looks at the VE table. obviously increasing it would increase fuel, and decreasing it would decrease fuel.

but what is it, and why is it there!? if it's linear, why wasn't it just rolled into the injector constant!?

and you scratch your head.. and stare at it...

then you see some other comare operation done against it where spark is computed, and you don't even know what to think anymore.

truth is except for simple routines, and my initial re-hack on the EE xdf, guys like robert and kur4o are miles ahead of me. i just test, use, organize, and spread the word about stuff that they find. once the notes are made i can read the instructions and totally understand how it works, but before that it's greek to me.

a complete 'hack' of a simple ecm is known to take a reaaaaly long time from scratch; this is two ecms. so im suprising nobody has invested the time to get everything out of it. but everything new that's found is really exciting to me, even if i can't use it on my own car..

[kur4o]

If you want to change Stoich AFR you also need to change two bytes on Tside
byte_e0e5 and byte_8227 or BLM update won`t happen

All 4 bytes must have same value.

[kur4o]

I need somebody to test Forced Open Loop at Zero TPS patch

Eside byte_616b value changed to $26
Eside byte_616c value changed to $08

[steveo]

will do!

thanks for info on stoich, i thought i'd tested that already

[steveo]

If you want to change Stoich AFR you also need to change two bytes on Tside
byte_e0e5 and byte_8227 or BLM update won`t happen

All 4 bytes must have same value.

those are set to 0x81 and 0x86 in the stock calibration, though; are you sure they need to all be set the same?

[kur4o]

My mistake I somehow ofsett them with one byte

Correct adress is byte_e0e6 and byte_8228.
Stock value should be $93.

Thanks for checking this

[steveo]

that looks better. now i just have to find a way to express this in the xdf that isnt' as ugly as 4 constants that have to match.

[RobertISaar]

could make a Patch item that changes all 4 to 14.1(and have original values go back to 14.7 should the patch be unapplied). that should cover most people's intentions of it, anyways.

[steveo]

i want it variable, and viewable. i love patches, but patches are only good for on-off type changes.

i settled on this 'not perfect but acceptable' solution, using a 2x2 formula and using the offset to jump to another arbitray value to fill the adjacent cell.

although it still relies on the user to not be a dumbass, i hate error prone situations, it'll have to do.

actually kind of a cool way to display 4 arbitrary values? i'll have to use it more when it makes sense..

[bybyc5]

OH WOW !! What a great XDF you have there !!! :rockon:

It has soooo many more functions than the one I WAS using...Now to tuning and data logging again...haven't changed my tune on my Formula in a couple years...sweet, I now have another reason to beat up on my drag radials.

Thank you !!

Keith

[steveo]

cheers, it was so worth it to spend all the time cleaning it up!

i should really upload a fresh version (there's some mistakes in the one online) but i'm waiting to figure out this ve + maf calc thing

i wonder if there are any other XDFs that are really popular and need some love..

[bybyc5]

Stevo

I have been exploring your web pages..Nice Work!! It's good to find an LT1 enthusiast with code writing skills. I especially like your TuneBot tool, what a great idea. Wonder if there is a copy of ve master still floating around. I have not touched my VE tables in my tune. Always figured as long as my maf was working, I was good to go. Maybe I need to rethink this?

I've looked at the tutorial on this website for adjusting ve fueling tables with blm data, but just haven't buckled down to do it. Didn't think it was necessary until now....:mad1:

For the set up I have the car runs and drives great, but have never had any dyno time to finish my WOT tune. 383 gm847 Lloyd Elliot stage 3 LT1 heads+ supporting mods.

I am wondering how to enable the catalog view and tool tips in TunerPro Rt? Thought I read that in a post about being sure to enable those in TunerPro?

Again, Thank you! :thumbsup:

[steveo]

I am wondering how to enable the catalog view and tool tips in TunerPro Rt? Thought I read that in a post about being sure to enable those in TunerPro?

category view. its in the drop down box above the list. you'll find it


Wonder if there is a copy of ve master still floating around.

yeah but it only works with datamaster EE logs. you can google 've master' and find it quickly.

[bybyc5]

[QUOTE=steveo;51110]category view. its in the drop down box above the list. you'll find it

Can't believe all the time I have used this program and never saw the drop down menu..

THX

[steveo]

whether it does anything or not depends on the xdf author of course. there are view levels too, which are great for hiding advanced options from noobs.

[jthompson122183]

anyone finding anything new?

[steveo]

not really.. i was starting to play around again and test some stuff, but my waterpump started barfing coolant and my tires started peeling apart, so it's going to be parked for a while until i save up for new stuff.

plus its nice out, so its bike time.

https://c4.staticflickr.com/8/7777/18223533516_68d0590983_z.jpg (https://flic.kr/p/tLmnBJ)with side fairings (https://flic.kr/p/tLmnBJ) by Steve (https://www.flickr.com/photos/rfesu/), on Flickr

i am also working on a tool that leverages some mode 4 things to provide real-time pseudotuning ability, skewing timing maps, altering idle settings, and disabling cylinders while monitoring rpm/map drop to help figure out per-cylinder balance. the tool is kinda working in linux, but im porting it to windows since no tuners seem to use linux. i'll get it done eventually, but progress is slow, i've never done much gui programming in windows.

[steveo]

played with this theory today:

1. 'maf disable' (already commonly known, and labeled as 've enable')
2. what robert theorized is a 've enable' flag at bit 7@0x2029 allows both lookups to be used (how exactly what the calculation is or its weight is unknown)

all factory bins have both flags UNSET meaning that if it's true, maf disable being set will obviously use VE lookup anyway (otherwise we'd be running n-alpha or car wouldn't run)

the stock f-body MAF table on my car hits blm trims of 116-120 @ low RPM, and 130-134 at higher airflow (the whole table wants to be tiled a bit). my adjusted MAF table runs blm trims 124-128.

my VE table is narrowband tuned, has been painstakingly detailed until it was perfect. i've been running speed density for a month now and my trims are always 122-126.

first test: stock flags (unset unset) and crank VE. i set 10% VE flat. car started and idled ok. suprisingly the car ran ok, but during acceleration and decelleration it felt REALLY WEIRD. maybe it was the butt dyno, but throttle response was dead. this leads me to believe that some fueling events are influenced by VE regardless of these flags, but cruising range seems unaffected.

next test: run my modified VE table with a stock MAF calibration with both lookups enabled. as my calibrated VE table is 8-10% lower at low airflows, my trims should be higher than they'd be without the flag set.

results: running 've enable' without 'maf disable' (theoretically using both tables for lookup all the time) brought my trims at lower airflows to 128-132. that's a BIG difference, leading me to believe in this mode that VE is heavily weighted. the biggest thing was that it seemed really stable, like the trims were a bit on the high side, but there were no spikes or dips.

next test, set 30% VE across the board with 've enable' flag set. result, engine started and kinda idled, but bucked and died under throttle. i shut it off before it had a chance to hit closed loop.

tried calibrated VE table but a bullshit MAF table, 2% airflow. car barely ran for a few secs then died. this confirms that the maf is being used.

so this tells me that we can run a proper hybrid MAF/VE fueling mode, cool stuff

im going to develop a tune in this mode and see how the results are vs. pure speed density or a re-cuved MAF table.

[steveo]

report on trim averages using a calibrated VE table with a stock MAF table with 'both lookups enabled', stock maf table, and calibrated VE table (but the VE table sure was never this close before!)



**** Narrowband Trim vs RPM vs MAP ****
(Igoring cells with counts < 6)
0 10 20 30 40 50 60 70 80 90
0
.... .... .... .... .... .... .... .... .... ....
400
.... .... .... .... .... .... .... .... .... ....
800
.... .... 129 127 126 .... .... .... .... ....
1200
.... .... 129 128 127 128 .... .... .... ....
1600
.... 128 128 127 126 128 .... .... .... ....
2000
.... 127 127 126 126 128 .... .... .... ....
2400
.... 125 126 126 126 127 128 .... .... ....
2800
.... 125 126 125 125 128 .... .... .... ....
3200
.... .... .... .... .... .... .... .... .... ....


vs airflow:



**** Narrowband Trim vs MAF AFGS ****

MAF AFGS TRIM MULT COUNT
0 - 5 128 0.996 757
5 - 10 ---- ----- 0
10 - 15 128 1.000 895
15 - 20 127 0.994 1405
20 - 25 126 0.987 633
25 - 30 126 0.985 260
30 - 35 126 0.982 158
35 - 40 126 0.986 103
40 - 45 125 0.978 37
45 - 50 126 0.984 36
50 - 55 127 0.989 21
55 - 60 126 0.988 19
60 - 65 ---- ----- 6
65 - 70 128 0.999 12
70 - 75 127 0.995 11


p.s. does anyone want me to port my analyzer to windows?

[bybyc5]

Nice work! As I mentioned earlier, I have honestly never tuned my VE tables figuring they were only a backup if my MAF died. I will add this to my list of things to do in my next tune for my car. Albeit your above process is a bit over my head, I do get the gist of it. This I would like to better understand, and realize trial and error ( mostly error!! :mad1: ) is how it's done. Just how would one use your analyzer?

I actually found a copy of ve master in my old win xp pro laptop, and my datamaster license is tied to that laptop. Wonder how good or not ve master will work with my setup. The cam is not that radical and driveability is really OK for even for a manual trans car like mine, however I do have a mystery rich condition at part throttle steady cruise at 2000 rpm. Above that is good. Strange to that according to the cam profile, that is where the cam starts to make power.

[steveo]

however I do have a mystery rich condition at part throttle steady cruise at 2000 rpm.

is the maf reading too much air? (maybe there's a point of really nasty reversion with that cam around 2k?) or are the o2s getting sketchy readings and messing up closed loop in that region?

try and read your logs and look for sketchy sensor readings around that area. for example unstable looking MAF readings can point to intake reversion and pulsation screwing up readings, or weird looking o2 behavior (where closed loop can't seem to stabilize) can point to corrupt o2 readings at that point. for example;

my last lt1 had a point around 20 g/s of maf flow during cruise, the maf would read increased airflow and dump a ton of fuel. but if you monitored MAP and MAF around that range, you'd see it was all over the place, and that it was just the cam causing totally non-linear airflow at that point and confusing things.

my current lt1 had a point under very light loads 1500rpm where it usually trimmed lean and added fuel. but, if you read a log, you see that the o2s are totally insane at that point, i chalked it up to a point where the cam is just doing nasty things and you get totally non-linear exhaust flow.. once i took CORRCL and made it much weaker during that range of airflow, it mostly went away.

im sure you can tune it out


Just how would one use your analyzer?

pretty much do a ton of datalogging and export as CSV format (tunerpro and tunercat can both do that), then just configure the software so it knows what your column names are

there are spreadsheets for doing VE tuning too that work great, but the reason i coded one instead is its a lot of copy/paste and i find results end up better if you use LOTS of logging.

with spreadsheets, or even with history tables in tunerpro, you have to parse and sort all your logs and pick ranges to play with, which is fine for throwing a couple logs in, but my static analyzer is smart enough to do things like reject records with 'timestamps < x' or 'coolant temp < y' or 'pe enabled = yes' depending on what it's analyzing, so you can just throw it a month worth of logs and you get good results with no effort.

if i port it to windows, will you help test it?

[bybyc5]

Sure thing. I would like that, however I am not a code writing person, and would require some coaching. I am not an avid user of excel either, so this may be tiresome for you. If you have the patience to coach, I have the desire to learn.

Not sure if this is jacking the thread though. Maybe move this to a new thread, or emails?

I don't currently have my wide-band set up to data log. I just have a live digital display that can read back hi and low for like a 1/4 mile run, etc. So I will need to set up an input for TunerPro from My LC-1 controller. I'll dig out my Instructions that came with it and get that set up. I have my stock narrow band O2's in use as well.

My current laptop is running Windows 7 pro. The other older laptop ( Win XP Pro ) mentioned earlier is usable if need be, but my current Win 7 laptop is what I have TunerPro already installed on and would prefer using it.

[steveo]

making new thread

[jthompson122183]

in the latest tunercat ecm ee defintion i came across some new stoich afr and egr enable coolant stuff and added it to your eex :rockon:
any chance of getting a copy of your latest eex?
9143

[steveo]

you mean tunercat has a new definition out with different stoich AFR variables than the ones we already found?

here's the current version, sorry i haven't posted it to my website yet.

someone should really poke around on that stoich thing. i could test it out a bit, but i only run pure gasoline here so i'd be a bad candidate.

[jthompson122183]

:rockon:yes sir just got their ecm file yesterday...and started difference a factory tunes against itself but with things changed one at time. Then i used tunerpro to difference the files.:rockon:

[kur4o]

Can you post the starting address of the TC stoich AFR to take a look.
Thanks.

[jthompson122183]

Can you post the starting address of the TC stoich AFR to take a look.
Thanks.
sure, 0x140D2 and 0x1417E

[kur4o]

0x140D2 is used to calculate Overheat AFR

The formula is (Byte_40D2=14.7) - [(Coolant - byte_28df) * byte_28e0] = Overheat AFR
if lower than (byte_28e1=Overheat afr value)

0x1417E is used to calculate Power Enrichment AFR value only. It is the base value that PE correction are made to.

These are not connected with the other 4 stoich targets and can be changed and be different If you need them.
The first 4 stoich targets need to be changed at the same time and have same value in hex, otherwise they won`t work.

[jthompson122183]

0x140D2 is used to calculate Overheat AFR

The formula is (Byte_40D2=14.7) - [(Coolant - byte_28df) * byte_28e0] = Overheat AFR
if lower than (byte_28e1=Overheat afr value)

0x1417E is used to calculate Power Enrichment AFR value only. It is the base value that PE correction are made to.

These are not connected with the other 4 stoich targets and can be changed and be different If you need them.
The first 4 stoich targets need to be changed at the same time and have same value in hex, otherwise they won`t work.

tc just has them as stoich1 and stoich2 in the constants menu. I seen that they where undefined in the eex so I brought to you guys attention.

[jthompson122183]

91469147914891499150915191529153915491559156915791 589159916091619162916391649165

[jthompson122183]

these tables are undefined in eex also 9166

[jthompson122183]

here is what changed when i zeroed the inverse table91699168

[jthompson122183]

here is what changed when i zeroed the end of injection table91719172

[steveo]

funny how he'd just add that stuff without explaining them? i will add the power enrichment stoich value for sure.

[jthompson122183]

there definition help file looks like it hasn't been updated in a long time. so much stuff missing. 918291839184

[jthompson122183]

well i can confirm that raising the EGR Enable - Coolant Temp(Hi Startup MAT) and EGR Enable - Coolant Temp(Low Startup MAT) out of range keeps the pcm from activating the egr. before i would see 12.5v being commanded in the logs, even though the other egr stuff was (supposedly off), not now.

[kur4o]

I think mystery is resolved about when VE tables are used and that ve enable bit is all about.

It looks like byte_12029 bit $08 is for ENABLE MAF DIAGNOSTIC, if maf fails also use VE tables.
In that case VE tables are used only when Maf error code is set.

If you play with the two bits there is three valid combination
USE VE tables only
byte_12028 bit $02 = 1
byte_12029 bit $08 = 0 or 1 (it doesn`t matter because it is skipped)

USE MAF only (PCM will not use VE tables, if MAF fails car will die)
byte_12028 bit $02 = 0
byte_12029 bit $08 = 0

USE MAF and allow VE tables if Maf fails (STOCK SETTINGS)
byte_12028 bit $02 = 0
byte_12029 bit $08 = 1

[steveo]

that actually does make sense. wonder why im getting anomalies with the car seemingly responding to the VE tables. it definitely did seem to affect trims. maybe i need to do more testing to confirm my results.

[jthompson122183]

So is the ve vs maf mode figured out yet? Time to move on to spark variance in power enrichment? Do any of you use Facebook? There's all kinds of lt1 groups with thousands of members that might be interested in helping if they knew about dissasembly. One of the biggest groups is "lt1 nation!!"
Just a thought.

[jthompson122183]

another factory calibration from a 1994 a4 with 2.73

[jthompson122183]

Kur4o said earlier in this thread that If there is a spark adder routine it is located at loc_5F96, looking at the lt1 diss (im very noob)


5F96 57 @135 asrB 5F97 F7 01 4A staB L014A
5F9A DE A1 ldX l_00a1_ref_period_12x
5F9C FC 20 46 ldD L2046 ; $0510 (1296)
5F9F 02 idiv ; integer 1296/00a1 -> X
5FA0 8F xgDX ; -> D
5FA1 04 lsrD ; / 2
5FA2 C9 00 adcB #$00
5FA4 F7 01 4C staB L014C
5FA7 F6 01 4A ldaB L014A
5FAA FB 01 4C addB L014C
5FAD F7 01 49 staB l_0149_tts_GP6ESPKO
5FB0 12 01 20 22 brset L0001, #%00100000, @138
5FB4 86 5A ldaA #$5A
5FB6 10 sBA
5FB7 16 tAB
5FB8 B6 15 F6 ldaA L15F6
5FBB 01 nop
5FBC FE 15 F6 ldX L15F6
5FBF 3A aBX
5FC0 FF 14 54 stX L1454
5FC3 12 23 80 04 brset L0023, #%10000000, @136
5FC7 86 03 ldaA #$03
5FC9 20 02 jr @137

12046 would be the extra spark adder?

[kur4o]

It`s more of a scalar from reference pulse, than direct adder. It needs logging to find out how it works.

[johnny_b]

I need somebody to test Forced Open Loop at Zero TPS patch

Eside byte_616b value changed to $26
Eside byte_616c value changed to $08

Was there any success with the "Open Loop @ 0% TPS" patch?

[steveo]

not as far as I know, but using power enrichment for that purpose works fine for idle enrichment (set <1200rpm tps% to enter pe to zero, use a blm locker, then use pe to nail idle afr)

[kur4o]

This is the latest version of patch.
It should be working version.
You can try of three diferent versions of the patch.
If you want to test it let me know of the result and if there is a problem I can fix it.
Development was dropped due to lack of interest and beta testers.

[johnny_b]

does one of these methods hold an advantage over the other?

As for the BLM locker, if I am flashed with the latest $EEHack patch V3 do I still need to apply the BLM locker separately in TunerPro?

[kur4o]

It`s up to personal preference. It uses different approach and you can setup conditions when OL engages.

You need to apply blm locker to your bin, before flashing it with eehack. Patch v3 is only ALDL communication related.

[johnny_b]

Can you explain a little bit about how to use your patch. I looked over it last night and I saw something about applying ground to a pin?

[kur4o]

Apply the patch as regular patch and flash the bin.

Usage is for grounding pin is optional. When grounding it will overide the CL routine and you will get permanent OL in all conditions, until ground is removed.
When pin is ungrounded the patch will work as usual, enter OL at zero tps.

I suggest you try cell 16 patch first. It goes to OL when cell 16 is selected by PCM.

Cell 16 is the BLM cell at zero TPS.