Maf options?

[coffeeandcigars]

Yeah the bolts on the vac-manifold rattled loose. And after another round of testing and further investigating i found the top surface of the VAC-Manifold to be underextruded and therefore leaky. Will need some Epoxy for futrure but spraypainting the surface helped a ton also.
Its now able to idle with functioning lambda regulation. But its still fighting hard and not always suceeding.

In this Graph are plottet AFR over RPM warming up from 31 to 95°C:

Way to many hits above 14.7 but a world of difference to before.


This is some of the logged data of the complete Warmup (15 mins of data):

From this i noticed that my calculated AFM_sim_voltage has very little resolution at idle. I have a hunch the math (lots of floats) i am doing is causing loss of res. Need to investigate...

This one is a closer look at hot Idle lambda control:

I think my RPM signal is not very accurate here, jumping too much...problem for another day.
The AFR is oscillating as i would expect but with way more amplitude than i am used to from the M52 . And its still going full lean every couple seconds.
Its a shame that INPA isnt working...i would love to see what the ECU is doing for STFTs and LTFT right now ECU is propably like: "Help me understand"

As for driving, heres a WOT-Pull with a lets say "interesting" behaviour:

This time its going full lean at 5700 for some reason...until then it at least feels ok and pulls good. But looking at the AFR curve its pretty bad. Complete level shifts from run to run but always the same U-shape with the richest point at ca. 4100 rpm.
I think i need to verify that the DAC Output is behaving as expected after 5700. Have to free up a analog pin and log the actual generated Voltage as well.
And also check if changing my transfer curve has actually an effect on the AFR-curve Well it never f***in ends...

[coffeeandcigars]

Quick Update: after playing with the transfer curve and limiting the DAC Output to the ECUs AFM Input to around 4,8-4,9V it got rid of the abrupt leaning out at 5700 rpm.
Somewhere around 4,9V seems the max that the ECU in my case accepts and yields therefore my max IPW i think i can reach. It wants to command up to 5,1V
As the graph shows its still way to lean up top. I would like to see at least 13,5.

The next logical step would be to learn how to burn chips and alter the fuel maps itself thought of upping fuel pressure but that creates a whole other heap of problems

[coffeeandcigars]

As i have to improve the printed parts and wanted to test the stock intake system again i swapped everything back to stock and did another log:

AFRs are in a safe range . AFM Voltage peaked at ca. 4,8V. Unfortunately i dont have the option of logging IPW at the moment. That would help a lot when comparing these graphs. And to have the confirmation that AFM-Voltage/AFM-Sim-Voltage and IPW are linked at WOT.
The question remains: Are the ITBs actually breathing better and therefore leaner at similar AFM Voltage? Maybe, but maybe the ECU is commanding different IPWs.

Maybe ill try the stock intake with the MAF and see whats happening then (Compare the Airflow, see how the simulated Voltage makes the ECU feel )

[bmwman91]

Good stuff. Yeah, if you have vacuum leaks and stuff, you really need to run a non-leaking stock intake for a while to get the transfer function worked out. Leaks will just mess it up lol.

[coffeeandcigars]

Yeah! The transfer function i originally measured on the stock setup. But that was a while ago and that had also the issue of not having the true voltages because of the Laptop USB...

I "pressure" tested the intake on a blown head i have kept, sprayed it to see the leaks. Currently i am coating the leaking VAC-manifold with resin and also the runners for good measure. Some other spots i noticed could use some rtv when reinstalling, small stuff here and there
Got new O-Rings for the seal to the head (2,4mm vs 2,0; in a softer Durometer), they were just ca. 0,3mm proud when everything was new and now after it got hot a bunch they are too embedded in the grove.
The BASF Carbon-fibre-Nylon and also the Polymaker Glass-fibre-Nylon did suffer from some creeping at the points they were loaded heavily (mainly at bolt-locations and some at compressed O-Rings).
Noticed also that the ITBs itself seem not very well synced. One runner blew way more air than the others when pressurized.
Still a lot of room for improvement


In the meantime i played with the EEPROM. Dumped my original Chip which is Software 1267356214 to compare to the dump from Tunerpros site which is a newer Software version. In WINols they look similar/same in some spots and completely different in others. I guess most maps are the same/similar also the sensor-curves should be identical but the software part obviously isnt
Unfortunately the tunerpro-xdf is a bit off when opening my dump. I think i ll try and burn the newer Software Version from tunerpro on a chip and try it in the car since its back to stock right now. And then see if the provided xdf is good enough to tune the fuel/ignition and maybe look into modifying the AFMs transfer curve in the EEPROM.

Using a teensy 2.0++ and "Teeprom" (found on Github) to read the 27SF256 / 27SF512. Its an awesome little program and with some Relais modules it can switch the 12V necessary for erasing/burning the chips!

[coffeeandcigars]

This is the stock-file-dump from a 89 Euro-spec E30 318is M42b18 Software 1267356214.
(rename to .bin)
318is_89_EUR_M42B18_stock_read_06_08_2022_1267356214.pdf

[coffeeandcigars]

First drive with a self burned Chip worked perfectly =D now the tuning can start

[coffeeandcigars]

Good stuff. Yeah, if you have vacuum leaks and stuff, you really need to run a non-leaking stock intake for a while to get the transfer function worked out. Leaks will just mess it up lol.

hey ive got a question for you
Been playing with the EEPROM and the WOT fueling on the stock setup.
In the XDF from tunerpro they say that the High-PT-fuel map is used around 40-60 TPS and after that WOT-fuel map is used.
I have the suspicion that this is not the case. Because the WOT map has only the rpm axis i think this is just an enrichment that is added to high-PT.
The High-PT map is real a 2D map with load and rpm axis.
As altering the AFM input had an effect on WOT-AFRs the fueling at WOT must be somewhat load dependant i guess.
What do you think?

Do you know if the rpm axis can be rescaled to nicely accomodate a higher revlimit?

[bmwman91]

A couple of things.

1. The publicly available XDFs for the M42 are a mix of incomplete and incorrect. I would not use them for any sort of serious tuning as they will at best not work well (since there are several copies of each map, and while one of the copies is used most of the time, the ECU will switch around depending on conditions), and at worst you can damage something.
2. WOT maps are independent of PT maps. I forget the exact trigger points, but WOT maps will be used when TPS is over some percent, and IIRC also when RPM is above some value.

Since the WOT maps are very simple, the XDFs you found may be correct (not sure if all of the WOT maps are identified in there). I set all maps (all fuel, all ignition) to the same values since I didn't want to mess with guessing which one was being used. RPM is the only axis for WOT maps. The ECU is always reading the AFM signal, which is the primary source for the load value (RPM, TPS, ECT, IAT are also factors), with the load value being proportional to the calculated ideal injector pulse width. The fuel tables and other stuff are all modifiers of this value since the actual required injector pulse width is basically never going to be the ideal one. In the case of the PT maps, RPM and the load value itself are axes for the fuel trim tables since the load value is subject to several inputs, and it can be corrected using itself as an input. In the case of WOT operation, a 2D table is used because it is faster to access, and load is at or near its maximum value so there is no need to have it as an axis (alternately you can think of it as a 3D table with a single value on the load axis).

Be very careful with the PT maps since their accuracy is not guaranteed to be correct in the public XDF. Also, there are two types of PT fuel maps: I am not entirely clear on their precise differences, maybe one set is multiplicative and the other is additive, I forget. In total there are a LOT of PT maps, like more than 10, even though there is really only a need for 4 of them.

You can change the RPM axis values, including changing the maximum axis value. Whenever you change a value on an axis (any axis), remember that ALL axis values below it will be changed as well due to how the values are computed in reverse sequence. You will need to change the RPM limiter value first if you want to rev higher, since the limit is not set by any of the maps.



Lastly, keep in mind that the O2 sensor will potentially cause you challenges with WOT tuning, depending on how correctly things are tuned at PT conditions. Recall that there is a long term fuel trim (LTFT) value which is a multiplicative factor. If the ECU is finding that it is running rich during idle and PT operation, it will apply a global leaning factor to all conditions including WOT (e.g. the ECU says, "I see that I am running 5% rich over the last 5 minutes, so I am going to multiply ALL fuel calculations by 0.95 at all times"). So when you tune WOT fuel maps, you will probably be tuning them for whatever conditions the ECU has adjusted to due to O2 sensor input. Every time you unplug the ECU (or battery) the adaptations are reset, but they are fully established after about 5 minutes of driving with the engine fully warmed up (O2 sensor is ignored when engine is below 80°C IIRC). You can try just unplugging the O2 signal from the ECU to disable all of this, although I am not sure if it causes other changes that you would be fighting at that point. Then again, as long as whatever you do is consistent and the ECU will always end up applying the same amount of LTFT correction, you can try tuning around that. However, if you have known vacuum leaks and do any WOT tuning with them present, you will be tuning in a state when the LTFT is actually making things richer (ECU says, "I am consistently 5% lean, so I will multiply all fuel by 1.05"). If you were to later fix those vacuum leaks, the LTFT would drop back down to a lower value, and your WOT would then be running lean by whatever % the LTFT dropped by.

You should check this video out:

https://www.youtube.com/watch?v=JzbLrn-2jyw

It was a big learning experience for me...fuel tuning is important, but not in as big of a way as you might thing when it comes to making power. Getting "perfect" fuel values is not really necessary for power, so making sure that the engine is safe (not too lean) and the catalytic converter is not being burned out (too rich) are also priorities. Ignition timing is far more important to max power, although it is also the easiest way to destroy the engine if you mess with it too much or mix-up a table value...fuel tables allow a lot more room for error.

[coffeeandcigars]

Thanks again for taking the time and sharing your knowledge!

1. The publicly available XDFs for the M42 are a mix of incomplete and incorrect. I would not use them for any sort of serious tuning as they will at best not work well (since there are several copies of each map, and while one of the copies is used most of the time, the ECU will switch around depending on conditions), and at worst you can damage something.

Yeah unfortunately...but its the only thing i have to work with right now...if i could only throw a ms41 in there its a diyers dream ;)
...i mean there wouldnt be any better candidate than you to open-source this i bet iam not the only one with a M42 that would send a couple bucks your way for opening this up to the community ;)

2. WOT maps are independent of PT maps. I forget the exact trigger points, but WOT maps will be used when TPS is over some percent, and IIRC also when RPM is above some value.

Since the WOT maps are very simple, the XDFs you found may be correct (not sure if all of the WOT maps are identified in there). I set all maps (all fuel, all ignition) to the same values since I didn't want to mess with guessing which one was being used. RPM is the only axis for WOT maps. The ECU is always reading the AFM signal, which is the primary source for the load value (RPM, TPS, ECT, IAT are also factors), with the load value being proportional to the calculated ideal injector pulse width. The fuel tables and other stuff are all modifiers of this value since the actual required injector pulse width is basically never going to be the ideal one. In the case of the PT maps, RPM and the load value itself are axes for the fuel trim tables since the load value is subject to several inputs, and it can be corrected using itself as an input. In the case of WOT operation, a 2D table is used because it is faster to access, and load is at or near its maximum value so there is no need to have it as an axis (alternately you can think of it as a 3D table with a single value on the load axis).

Ok wow then i guessed way wrong

Be very careful with the PT maps since their accuracy is not guaranteed to be correct in the public XDF. Also, there are two types of PT fuel maps: I am not entirely clear on their precise differences, maybe one set is multiplicative and the other is additive, I forget. In total there are a LOT of PT maps, like more than 10, even though there is really only a need for 4 of them.

good to know! I think i dont have a reason to mess with those for my purpose

Whenever you change a value on an axis (any axis), remember that ALL axis values below it will be changed as well due to how the values are computed in reverse sequence.

This has me scrachting my head
Would one theoretically need to find every relevant map first to know where the axis locations are and then change them? All done in a hex editor?

You should check this video out:

https://www.youtube.com/watch?v=JzbLrn-2jyw

...i nearly watched all of their videos in the past but ill watch again!

It was a big learning experience for me...fuel tuning is important, but not in as big of a way as you might thing when it comes to making power. Getting "perfect" fuel values is not really necessary for power, so making sure that the engine is safe (not too lean) and the catalytic converter is not being burned out (too rich) are also priorities. Ignition timing is far more important to max power, although it is also the easiest way to destroy the engine if you mess with it too much or mix-up a table value...fuel tables allow a lot more room for error.

Thats true! I dont like not having knock control with this here. On ms41 its very nice to know that theres a safety net!

So far i did a couple iterations increasing the values in the WOT-fuel maps and logging AFR to see whats going on:

[bmwman91]

Truly, I would love to be able to share what I know about Motronic tuning, but a lot of the knowledge is not mine to give away since it came from years of hard work from someone else who does tuning for a living. I worked with them for a while on Motronic reverse engineering, and I dealt more with the hardware aspect of it, but I also got to access some of the software/XDFs that they had developed.

Now that I have spent a little time with the tuning interface for my aftermarket ECU conversion, I can say that the best way to "open source" the tuning of these cars is with an aftermarket ECU lol. Sure, you can do a surprising amount of tweaking with the stock ECU, but it is still super limited since you cannot really add features, and while there are plenty of small settings to optimize how the car runs, they are not documented and hard to deal with. Of course, I am also well aware that aftermarket ECUs are expensive and not everyone has that much spare cash to spend. If I was not well established in my career at this point, I probably would not have gone with the expensive solution either! Most of the reason why I reverse engineered the Motronic was to see if I could fulfill my tuning needs for minimum cost, with the rest of the reason being that it was fun to satisfy my curiosity.

Not sure if you have seen it, but this is my thread (started the project a couple years ago, decided to just enjoy driving the car for a bit, then picked it back up earlier this summer):

https://www.r3vlimited.com/board/forum/e30-technical-forums/engine-drivetrain/alternative-tuning-w-a-r-megasquirt-etc/9961647-m42-ecu-conversion-link-g4x-e36x

You are obviously a smart guy with attention to detail, so I have no doubt that you could build yourself a wire harness and integrate an ECU too. Unfortunately, it seems like electronics and materials are all a LOT more expensive in the EU than in the US! I have tried to document everything I am doing, and part numbers, so that others can also do a conversion to a modern ECU...one of the most challenging parts of planning is figuring out all of the connectors and terminals that are needed (if you want to do an OEM quality build). Speaking of which, I need to go back through the first post and update the list of part numbers since I learned a lot along the way! One thing I would like to do is to make a DIY / How-To thread for "Wire Harness 101" information.



As far as changing axis values, it can be done to individual maps, no need to change all of them. When I get home I can pull up my documentation for how they work. I figured those out based on public information many years ago, so sharing how they work is not a problem. Your plot is starting to look pretty good...much clearer now. I assume your initial tests were much more lean in the ~3000RPM area? When I was first testing a MAF on stock maps, I would see 16-17 AFR in that area at WOT! So, if you have been increasing the values in that range, things are looking a bit better.

[bmwman91]

coffeeandcigars FYI this PDF has a lot of information which also applies to M1.x.

http://www.paerl.it/volvo/Volvo%20Motronic%204.3.pdf

M4.3 uses an 80C517 MCU, which has identical core architecture to the 80C515 found in our ECUs. The difference is that a bunch of hardware peripherals were added to reduce the need for a large, expensive external peripheral chip.

While the maps themselves are going to be different in M4.3, the general information about axis descriptors, how axis values are computed, and stuff like that is correct. There is also a similar section in the binary data for our ECUs where every map's address is listed, and once you have that you can locate them and determine what the axis values are and the map size. Figuring out WHAT the maps do is another story, but it'll at least allow you to know where stuff is.

[coffeeandcigars]

Truly, I would love to be able to share what I know about Motronic tuning, but a lot of the knowledge is not mine to give away since it came from years of hard work from someone else who does tuning for a living. I worked with them for a while on Motronic reverse engineering, and I dealt more with the hardware aspect of it, but I also got to access some of the software/XDFs that they had developed.

thats a bummer

As far as changing axis values, it can be done to individual maps, no need to change all of them. When I get home I can pull up my documentation for how they work. I figured those out based on public information many years ago, so sharing how they work is not a problem. Your plot is starting to look pretty good...much clearer now. I assume your initial tests were much more lean in the ~3000RPM area? When I was first testing a MAF on stock maps, I would see 16-17 AFR in that area at WOT! So, if you have been increasing the values in that range, things are looking a bit better.

The free-xdf really is shit ...started tuning over fresh after finding the third (and hopefully last, can you confirm?) WOT Fuel map. Also the axis were completely wrong, so ingnore the first AFR plot. I was changing stuff not where i wanted it changed.
Are the values in the fuel maps actual injection times in ms (val*0,05)?
Heres another plot, with the revised xdf (V4 is stock fueling, V5 modified, both limiter 7300 but standard axis end at 6480):

Will do a couple more iterations to get it closer to 13.0 and then try and go more extreme (like 10.5) and see if theres a limit to what itll tolerate. I want to confirm that i have headroom.

Yesterday had the idea that i could just tune map 1 and let excel do a linear interpolation for the different rpm points of map 2+3:

But if i understood you correctly the motronic wouldnt care if i copy the axis of WOT1 for 2 and 3 to make them identical (Do you know why they used 3 similarish maps in the first place)
I think i ll do a test with this new axis that goes up to 7000 and has more even spacing of the Datapoints. The very uneven gaps between points seemed strange to me but maybe they knew what they were doing

(The way they were translating the axis from hex to real values is crazy, at least to me now your earlier post with "reverse sequence" makes sense!)

For full transparency heres the map locations of the 3 WOT fuel maps that i think are correct for 214 software and their axis:
WOT Fuel 1: 49DB

800

1000

1400

1520

1920

2320

2600

2920

3040

3320

3800

4320

4480

5200

6120

6480

WOT Fuel 2: 4A2B

800

1000

1200

1400

1600

1880

2400

2600

2800

3000

3400

3720

4120

4800

5400

6480

WOT Fuel 3: 4B17

800

1000

1400

1600

1920

2200

2600

2920

3120

3320

3800

4320

4480

5200

6120

6480

[coffeeandcigars]

coffeeandcigars FYI this PDF has a lot of information which also applies to M1.x.

http://www.paerl.it/volvo/Volvo%20Motronic%204.3.pdf

M4.3 uses an 80C517 MCU, which has identical core architecture to the 80C515 found in our ECUs. The difference is that a bunch of hardware peripherals were added to reduce the need for a large, expensive external peripheral chip.

While the maps themselves are going to be different in M4.3, the general information about axis descriptors, how axis values are computed, and stuff like that is correct. There is also a similar section in the binary data for our ECUs where every map's address is listed, and once you have that you can locate them and determine what the axis values are and the map size. Figuring out WHAT the maps do is another story, but it'll at least allow you to know where stuff is.

oh thats awesome, thanks a ton!

[bmwman91]

The free-xdf really is shit ...started tuning over fresh after finding the third (and hopefully last, can you confirm?) WOT Fuel map. Also the axis were completely wrong, so ingnore the first AFR plot. I was changing stuff not where i wanted it changed.

There are 3 primary fuel maps, and it looks like you have correctly identified them. There is a fourth 1x16 map which is fuel-related, and it is at a higher address where things are mostly for ignition maps, but it is not used as far as I can tell (at least in the US version). The values are used in a different way (if at all) than the 3 WOT fuel trim maps you identified, so I would leave it alone.

Are the values in the fuel maps actual injection times in ms (val*0,05)?

No, the fuel table values are scaled Lambda values. Many maps have a Load axis (descriptor 0x40), with (values x 0.05) representing the theoretical injector time in milliseconds. For the fuel maps, the table values are a target Lambda * 128, or rather Lambda = Val / 128. AFR = (14.7*128)/Val if you prefer. So, a value of 128 represents no change to the Load value as it is a Lambda of 1.0, and the maps are all used as corrections to the Load value that is initially computed from sensor inputs. Just to be clear, the target Lambda values are not at all related to O2 sensor feedback or anything...they are the "target" of the manual correction that the tuner enters.

Heres another plot, with the revised xdf (V4 is stock fueling, V5 modified, both limiter 7300 but standard axis end at 6480):

Will do a couple more iterations to get it closer to 13.0 and then try and go more extreme (like 10.5) and see if theres a limit to what itll tolerate. I want to confirm that i have headroom.

Looking pretty nice, I definitely see some progress.

Yesterday had the idea that i could just tune map 1 and let excel do a linear interpolation for the different rpm points of map 2+3:

That is indeed one way to do it. Motronic does its own linear interpolation with every table look-up as well, so it will smoothly determine values between map entries. This applies to both 2D and 3D maps. Anyway, you could also just copy the one map (both axis and table values) to the other 2 locations and have them all 100% identical. That is what I did.

But if i understood you correctly the motronic wouldnt care if i copy the axis of WOT1 for 2 and 3 to make them identical (Do you know why they used 3 similarish maps in the first place)

Axis values are free to change. You can even change the length of the axis if you want, although if there is another map that starts at the next byte address after it then you would need to move ALL of the hex data after it and update all of the addresses in the map index. Alternatively (preferably) you could just move the map to a different address where there is a lot of free space (lots of 0xFF values) and update the map index for just that one. In my opinion the 1x16 WOT maps are fine, but some people have increased them to 1x20 and moved them to an address with lots of unused space. Do keep in mind that the larger the table gets, the slower the Motronic is able to read them since it has to traverse the length of the axis starting at the end. FYI at higher RPM, the Motronic cannot access the tables as fast as at lower RPMs since it has many fewer free instruction cycles, so keeping the WOT maps smaller is preferable.

I think i ll do a test with this new axis that goes up to 7000 and has more even spacing of the Datapoints. The very uneven gaps between points seemed strange to me but maybe they knew what they were doing

Ultimately, set axis values to whatever gets you stable AFR values that meet your requirements. Some RPM ranges need more closely-spaced axis values than others in order to handle non-linearities in operation. A few people have reverse engineered the assembly code for how the maps are accessed, and I am told that Bosch has a very fast/efficient method for doing the lookups and interpolation, but I would have thought that a simpler format with evenly spaced axis values would have been a lot more efficient.

(The way they were translating the axis from hex to real values is crazy, at least to me now your earlier post with "reverse sequence" makes sense!)

My theory about why the tables are formatted in such a not-obvious way is that it was done to stop people from easily messing with the maps. Remember that when these cars were new, very few people had internet access, and even fewer had UV erasers and EPROM readers/burners, so it would have been nearly impossible for the average enthusiast to figure out where maps were and how to change them.