"Chipping" a CIS ECU - Page 6 - PeachParts Mercedes-Benz Forum

V12 · #76 04-03-2020, 07:25 AM

Confirmed.
There seem to be some tables in the 16bit Hi-Lo format

duxthe1 · #77 04-03-2020, 06:13 PM

I'm thinking it wont be too hard to discern which sensors the 16 bit tables are assigned to. Wiring in some potentiometers on each input and watch which one responds in data tracing should help ID them. I don't suspect there is much tuning benefit. The one tuning strategy I'm mulling over is lowering the IAT reading and then "leaning out" its curve so that the CIS doesn't overfuel because of it. Meanwhile the lower IAT reading will keep the EZL in more aggressive ignition maps.

Due to the state "stay at home" order, haven't driven the coupe in 2 weeks, so no actual progress to that end. Actually took a break from beating my head against the code through most of it, but did make 1 small change to my code. Using IDA Pro I found a cleaner way to disable adaptation than the additional subroutine I had written. The code actually already clears the external RAM locations 70h though FFh, so presumably the adaptations are stored in the lower locations, 00h - 6Fh. With TunerPro its easy to set up a scalar for the data byte that contains the 70h location, which can easily be changed to 00h for complete adaptation disable.

Feeling a bit stir crazy yesterday, I started an XDF file for the 119 LH bin file I have (early 400E with WOT enrichment) and pulled out about 50 maps from the map addresses. I don't have a tester for a 119 LH car so I won't make a lot of progress any time soon on that one but it was a way to waste several hours. The only map out of the whole caboodle that I'm reasonably sure about is the largest one in the file at 32x32, 16 bit. 96% certain that one is the MAF transfer function.

gsxr · #78 04-03-2020, 06:44 PM

Quote:

Originally Posted by duxthe1

Feeling a bit stir crazy yesterday, I started an XDF file for the 119 LH bin file I have (early 400E with WOT enrichment) and pulled out about 50 maps from the map addresses. I don't have a tester for a 119 LH car so I won't make a lot of progress any time soon on that one but it was a way to waste several hours. The only map out of the whole caboodle that I'm reasonably sure about is the largest one in the file at 32x32, 16 bit. 96% certain that one is the MAF transfer function.

Ooooo, now this is interesting stuff! I'd love to know more about the LH mapping. Of course, the LH-SFI v4.1 that Mercedes used was unique to Mercedes (AFAIK), and not used by any other manufacturer.

The one thing it would be neat to experiment with is adjusting both rev limiters, but from what I can tell, there is a whole table (or two) just for the rev limiter function. Doesn't appear to be just a couple of values. Not likely to be anything in the LH for power gain since there's no way to adjust timing.

duxthe1 · #79 04-03-2020, 11:08 PM

At the risk of hijaking my own thread, I posted a few pics of maps from the 119LH.

1st is the 32x32 16 bit map suspected of being the MAF transfer function

2nd is 1 of 8 16x16 8 bit maps, all 8 have this same basic shape with just a couple cells differing in each.

3rd is another 16x16 that is pretty interesting.

Never looked into tuning the LH module so I'm not aware of anything already known about them in that community of enthusiasts . I can read and write the chips though and after diving into the CIS module I've come to be able to recognize the map addresses. In itself that's a decent start to building an XDF file for them. I'd like to get my hands on a few other versions, namely 400E without WOT enrichment, and any 5L version too. Without a test mule, it would be hard to make progress on defining the tables.

gsxr · #80 04-04-2020, 01:20 PM

Neat stuff. Do you have the hex addresses for each of those 3 tables in the LH?

duxthe1 · #81 04-04-2020, 06:29 PM

Those and about 50 others. There is a section of code referred to as "map addresses" which points to most of the maps. Its near the very beginning, right after the interrupt vectors in this LH. It points to the address of most maps within a continuous block of data, so finding them is easy. The hard part is figuring out what they all do.

duxthe1 · #82 04-10-2020, 01:09 AM

Reeling in the hijack, I managed a bit of driving and was able to identify the 16 bit sensor curves. Didn't need to get fancy with potentiometers after all. Monitoring the data tracing it was fairly easy to deduce which sensor each table represents. This adds 3 more defined tables to my .XDF, air flow potentiometer, coolant temp, and intake air temp sensor curves.

duxthe1 · #83 04-12-2020, 03:46 PM

I recently printed out "Functions in the KE control unit" from WIS. Its a 63 page document that spans all versions of KE. Its fairly detailed in its descriptions, at least as detailed as one can expect for a publicly available document. I wanted to refresh myself on the functions in order to try to understand what the programming is doing and why.

In the document there are a few images of characteristic curves and I believe I've matched two against tables in my TunerPro .XDF file. Namely the cranking enrichment. There are two tables 10x1 2d that match the plateau then decreasing curve shown the WIS document. One is a few % larger numbers than the other but the curves are almost identical. I believe that one is coolant temp v/s cranking enrichment and the other is air temp v/s cranking enrichment. These two tables are only active for up to 2 seconds after starting.

Another thing I've recently done is download a few XDFs and BINs for other platforms. The BMW crowd has done more with TunerPro than all the other Bosch guys combined. Many of their .XDF files are comprehensive and there are a few parallels one can draw studying them. The prominent revelation I came to was dealing with the idle tables. The table I had previously used to raise idle had unpredictable behavior when cold. With a new perspective from a few BMW tune files and WIS info, I found two other tables that appear to be the basic idle speed tables. One for P, N and another for D,R. I cant test D,R because I have my neutral safely switch jumpered due to my 722.6 install and therefore lack the D,R input to the module. Reconfiguring my trans setup to simulate the gear recognition has been added to my to do list. It works fine as is, but given the opportunity to do better....

One last thing that had been bugging me is that the load based acceleration enrichment goes away at operating temp. I spent some time chasing it in IDA Pro and believe I found the location of that cutoff temp. I've created a scalar in my .XDF that allows that cutoff temp to be changed. I've even figured the conversion equation to set it using actual temp values instead of raw hex data, and it shows that the cutoff is 82 Degrees C. I haven't had an opportunity to test it yet but I'm at least 75% certain that I've hit the mark. If not I'm fairly well focused on it in the code so there will be a few other things to try to find it.

duxthe1 · #84 04-16-2020, 11:05 PM

Slow day at work yesterday so I pulled the coupe in and installed a relay in the NSS circuit and using the PCS controller switch it open in D / R ranges. In addition to actually being a neutral safety switch, it gives the CIS the ability to switch between P /N idle tables and D / R idle tables. With everything wired up and the PCS output programmed, data tracing confirms that the D/R table is indeed working as expected. What wasn't expected is that if the idle values are too high (over about 900 RPM hot) it is detected as a fault with the idle circuit and enters the idle limp mode. On the 104.980 this results in the ignition module using a very retarded map to prevent the engine revving up with the valve in default "emergency running" position. Not to worry a hot idle of 850 RPM is just dandy, and what I have been after.

My previous attempt(s) to raise the accel enrichment cutoff temp wasn't as successful. Back to the drawing board (IDA PRO) and one other location looks promising. Using my raw hex to deg C conversion formula, this hopeful byte returns 85C for the cutoff point. That's pretty much right in range where the cutoff happens and is used as a conditional jump parameter preceding code that is manipulating the air flow potentiometer value. Fingers crossed, snow today prevented testing.

For anyone interested the formula to convert raw hex to deg C is ( 255*.588 )-(x * .588) -30 The way temp is read into the module results in lower hex values for higher temperatures, and this formula inverts the value and scales it to the range the sensor reads across, which as best I can tell is 150C (-30 to +120)

SpartanV · #85 04-18-2020, 01:57 AM

Very intriguing info.

Does it turn off acceleration enrichment at 82 because that is "running" temp / closed loop?

How detailed is the air intake temp sensor map?

gsxr · #86 04-18-2020, 09:38 AM

The acceleration enrichment is intended for a cold engine only. The system wasn't designed to do that at operating temp, possibly for emissions reasons?

On the LH systems, intake air temp has little effect on real-world power. Not sure about CIS.

duxthe1 · #87 04-18-2020, 12:23 PM

Quote:

Originally Posted by SpartanV

Does it turn off acceleration enrichment at 82 because that is "running" temp / closed loop?

How detailed is the air intake temp sensor map?

The intake air temp sensor curve is a 16 bit 32 cell 2d map.

The AE turns off at "normal operating temp" but it is capable of closed loop well before that. Certainly that's done for emissions, because it damned sure aint for performance.

duxthe1 · #88 04-21-2020, 08:31 PM

Another significant advancement! I've found the accel enrichment cutoff temperature byte.

It wasn't in the section of code where I thought it would be. Using the equation listed a couple posts above I was able to look at where the coolant temp is being used by the code and find instances where the conditional jump is based on a value near 80C. According to my conversion equation the temp where AE is shut off is 83C. This byte is the same in both 104 .bin files as well as the 103 .bin I have. I've now set up a scalar in my .XDF to easily change this value to a much higher temp. I also double checked it by lowering the value and confirming that I could turn off the load based AE at 65C. It works exactly as expected.

Now that I have full access to AE, I had to play with the values in the AE table. I liked having a value of 40h in the fully warm column. For comparison, the stock values for the warmest 2 cells in the AE table are 0 and 19. From a dead stop going to full throttle 40h gave a shot of about 20mA EHA current. Cruising around 55MPH and a quick tip into the throttle gives 5-6mA EHA current.

Now presumably there is a table that sets the length of the enrichment event. It's now on my list to find. Having full access to AE is already a large improvement but it would be nice to fine tune the length the AE events as well as the amount.

SpartanV · #89 04-21-2020, 11:52 PM

Very nice

duxthe1 · #90 05-01-2020, 07:53 PM

I spent the week backtracking and fighting the idle. Ever since I've been messing with the idle, I've been having inconsistent results. Sometimes the idle would be (intentionally) high 8-900 rpm, and sometimes it wouldn't idle at all. Foot off the accelerator equal engine stall bad. No rhyme or reason that I could ascertain.

On the 104.980 the idle goes into a limp mode if the valve is disconnected or if serial communication is broken with the EZL and requires a key cycle to exit limp mode. In the event of an idle valve failure the EZL will pull timing to prevent a high idle.

With the Ostrich I can watch the table for the idle valve output. The values in this table eventually are translated into the current output for the idle valve. What was really confusing me is that when the engine wouldn't idle, this table was remaining inactive showing that the CIS wasn't even trying to idle. I spent a fair bit of effort trying to figure out how my attempts to change the idle targets were breaking the idle function.

Today I had an epiphany about this entire problem. Coincidence. The idle problem appearing soon after beginning to change idle speed in the code was coincidence. As it turns out my 2.5 yr old overload relay was crapping out. The OL relay provides the current for the idle valve on a separate circuit from other consumers. This circuit was failing to provide the necessary current, which was being interpreted as an idle valve failure leading to limp mode, which at my elevation barely idles if at all.

So no other progress to report for the week, beyond learning a lot about how the idle fails. In the course of working through the problem I found two other tables the same size as the idle tables which also become active / inactive based on selector position. After figuring out the OL relay problem I reloaded them with their base values but I'll play around with them and figure out their nature soon. I still want to tune the idle tables to hit my targets at all temps first.