Page 5 of 5

Posted: Wed Feb 14, 2018 12:00 pm
by Hairyscreech
To back you up on that the E30 thermostat is 80 to 88 degrees and that is central/vertical on my gauge, I hit that last cell while still at the 1/4 mark on the gauge, so likely about 50-60 degrees.

I have been plugging it into a few tables today to see how if fits, looks ok but might be worth testing this out on a few other tables.

It seems to work for the D4 IAT as well but I could only find one table with D4 on.

If you wanted to test it put a resistor with a value matching one of the temperatures in place of the CLT and check what cell that puts the ECU into. I believe that table is always active even at idle so it should be easy to check.

It would imply that there is no CLT or IAT transfer function though, with no requirement to work across several different kinds of hardware and no need to spit out OBD2 PIDs there is no need for the temperature to be anything but an abstraction in the code.
A simple more=more value in the code with the only direct relation to temperature being the voltage to the A2D converter, more temperature=more voltage=higher value with no direct conversion factor.

Posted: Wed Feb 14, 2018 12:40 pm
by olafu
Hairyscreech wrote:I believe this is simply the raw 256 bit values from the A2D converter. I get that the A2D is 10bit and would then have to convert into 8bit somewhere in the code, that would simply be the 0-1023 converted to 0-255.

The A2D works from 0-5v, with 255 values available that's 0.019531V/value.
The sensor is not liner but using the calculations I put on the "M5x temp sensors" sheet in the dropbox and working out the voltages expected at the A2D based on the voltage divider layout and using this V/value I built a table of temperature Vs D7 value.
I found that the a 0v value would be ~-40 DegC and a 5v value ~215 DegC.
While the sensor would never actually measure a full 0v or 5v due to the way it works and should never see these kind of temperatures is gave me the boundaries.

I have updated the sheet in the dropbox to show this working so if anyone wants to double check it then feel free, the more eyes checking these things the better.

Plugging the resulting numbers into the D7 based tables gives some sensible results:
The "coolant temp correction for acceleration" table has the following:
Raw value - 49 103 143 175
Temp DegC - 0 30 50 66

Running the car from cold results in a steady climb up that table and it sits in the 66+ cell once 3/4 warm. (E30 temp gauge so not electrically damped like an E36).

I am going to put the values into some of the unknown D7 tables and see what temperatures it suggests, it will help confirm if the theory is correct and maybe what those tables are. :?:
10bit A/D converter can be used in 8bit by using only 8 most significant bits.
Example: register addresses 46 and 47 seems to be MAF values. So, they are 16bit, but i didn't note which is 8 most significant. But, if other one is overflowed, it increses by one that other one, and that overflowed will start from zero. If you read only that "increase one by overflow" you get 8bit maf value.

Posted: Thu Feb 15, 2018 12:28 am
by Hairyscreech
Its interesting you post that as it looks like some of the code does that to get offsets, there are a couple of times something is added to an Exxxh or Fxxxh number and put into an 8 bit register, this obviously can only drop the extra values off the end of the register.
Seems like it is a dirty trick to prevent having to subtract numbers. (which I think is more processor intensive?)

I'm not sure the A2D converter is used like that though as the values in the tables suggest a full range scaled down to 8bit with 255 meaning 5v (about 215 DegC).
Unless I am understanding the math/mechanics of the thing?
Are you suggesting it could be 0-1020 by only using the first 8bits of the 10bit value?
Essentially dropping the first 2 bits and making the value off by 3?

Edit - I think I just got it, in the first example it would be dropping the most significant bit/bits and essentially "going around the clock" to get back from high hex values to low hex values but the A2D example is a little different:

If the value is 10 bits then 1/2 = 512 = 10 0000 0000.
Dropping the first 2 bits gives 10 0000 00| (00 dropped) and thus 8bit 128 value.
The way binary works you wont fill up the most significant bits until the highest values for a given number of bits, so discarding the least significant automatically converts to a different size without changing the numbers % value.
70% of 10 bits becomes 70% of 8 bits by just dropping the first 2 bits.

I just had a play and it actually converts 10bit numbers to 8bit very well, it is an elegant solution that saves a lot of math in the processor.
(I did say my computer science was lacking - :lol: )

I gather this will mean if I have a quick hunt for some 10 to 16 bit values and take a look to see if some are being addressed in a funny way or are being deliberately bit shifted then we might find the A2D code?

Posted: Thu Feb 15, 2018 12:03 pm
by olafu
Direct copy from 80196 user's manual A/D section:


Analog Inputs to the 80C196KB System are handled
by the A/D converter System. As shown in Figure
11-4, the converter system has an 8 channel multiplexer,
a sample-and-hold, and a 10 bit successive approximation
A/D converter. Conversions can be performed
on one of eight channels, the inputs of which share pins
with port 0. A conversion can be done in as little as 91
state times.

Conversions are started by loading the AD_COMMAND
register at location 02H with the channel number.
The conversion can be started immediately by setting
the GO bit to a one. If it is cleared the conversion
will start when the HSO unit triggers it. The A/D command
register must be written to for each conversion,
even if the HSO is used as the trigger. The result of
the conversion is read in the ADÃ￾RESULT(High)
and AD_RESULT(Low) registers. The AD_RESULT(
High) contains the most significant eight bits of
the conversion. The AD_RESULT(Low) register contains
the remaining two bits and the A/D channel number
and A/D status. The format for the AD_COMMAND
register is shown in Figure 11-1. In Window
15, reading the AD_COMMAND register will read
the last command written. Writing to the AD_RESULT
register will write a value into the result register."


0 Channel selection (+1)
1 Channel selection (+2)
2 Channel selection (+4)
3 GO-bit (when written to "1" conversion will start asap)
4 X
5 X
6 Least significant result bit
7 Second least significant result bit

By reading 02H is used to check ADC status and last used channel. Bit 3 will clear to "0" automatically, when conversion is finished, so, when reading 02H and bit 3 is "1" it means AD conversion is running, converter is busy.

Posted: Fri Feb 16, 2018 5:24 am
by Hairyscreech
Well noted. :D

I have used that to edit the disassembly I have and it highlights the times when the program uses the A2D quite well.

Just by spotting the A2D write on 02H and then read on 03H then 02H you can find all 5 reads of the A2D in the 413 ROM.

Lets see if anything useful can come of that.

Edit - Further note, anywhere the program has a JBS (jump if bit set) for the AD command register 02H then it is waiting for the A2D read to finish.
That's done to put the program into a brief loop to give the ~42 micro seconds for the A2D to finish.

This is all becoming a little bit too much like learning things... :lol:

Posted: Tue Feb 27, 2018 4:42 am
by Hairyscreech
MyKK - I spotted a post by you here: ... 4DME-M60-s

Regarding those TPS limits tables, how did you find those and know what the RPM thresholds were/are?

When I was looking at the transfer function area those 12 bytes where they are located was the only thing I could not work out.

On my last tuning run in the E30 I couldn't get the WOT tables to activate, this might help resolve that as I think the issue is a tiny difference in the angular range on the E30 throttle.

Posted: Wed Feb 28, 2018 3:27 pm
by Evil
For the TPS thresolds, the RPM values are those in the XDF shared by Olafu about this, sooner in this thread.
I have never checked if it was correct for my 403, but the thresolds are working for sure, I modified them for my ITBs because TPS range was very shorter on them..
I think that the different thresolds by RPM are to avoid Idle/PT switching when cruising. I put the same value in all cells with no problem but maybe due to my particular setup...

Posted: Wed Feb 28, 2018 3:31 pm
by Mykk
The idle/pt & pt/WOT threshold tables came from Olafu in this thread. I believe he had knock tables in the same xdf

Posted: Sat Mar 03, 2018 12:23 am
by olafu
I never found RPM axis data for idle/pt/wot tables, i think it is shared for multiple tables and it is somewhere close of those threshold tables. RPM's for those thresholds in my XDF was purely found by testing and tracing. They are not very accurate.

I did take a break in playing with this device, because HEX's started to flow out from my ears. :lol:

Posted: Sun Mar 04, 2018 7:16 pm
by revlimit
Hairyscreech wrote:To back you up on that the E30 .
any photos of your M20 converted to M3.3.1?

Posted: Wed Mar 07, 2018 2:42 am
by Hairyscreech
olafu wrote:I never found RPM axis data for idle/pt/wot tables, i think it is shared for multiple tables and it is somewhere close of those threshold tables. RPM's for those thresholds in my XDF was purely found by testing and tracing. They are not very accurate.

I did take a break in playing with this device, because HEX's started to flow out from my ears. :lol:
I know that feeling. I have been taking a step back and working on other projects a little as well, my key focus has been to get the E30 working right so less finding new stuff and more making what we have work right.
Also been putting together some coil overs for it and trying to get a friends Drift Cup car ready for this season.
All been keeping me busy.

I want to try and work out which sensors are on each of the A/D inputs as the next step, that will ID several functions in the Code as the reading of those sensors. I started trying to trace to boards back using the Hi-res photos I took but I think I need another board out of the car to check and ebay is only bringing them up @£150+ :x

Revlimit - At the moment, not really. I have a few but not hosted them anywhere since photobucket killed the internet (a decision I expect they may regret long term).
I will look at getting some sorted out, it is not too pretty as a better engine will be built and things tidied up a bit when that happens but its all in there and everything functioning.

General question for all - I have found over the last few weeks I am not getting tuner pro to trace the WOT fuel maps, the ECU is 100% hitting WOT, verified by the step change in the fuelling if I change those maps and INPA but I cant get those maps to trace.
Any ideas what could be causing the issue? Short of an issue with the older laptop and TunerPro I cannot think why they wont trace. Everything else seems to be working/tracing fine bar those WOT fuel maps.
Going to try using my newer laptop again and see if its that, otherwise I guess the arduino logger will make the hit tracing a little redundant.
Edit - I also tried lowering the trigger point for the WOT using Olafu's tables, has worked as it now seems to click to WOT earlier but no change in the tracing issue.

Posted: Thu Mar 08, 2018 7:49 am
by Mykk
Have you change the 'Table of tables' addressing, perhaps WOT address has been changed to part throttle address?

If the cell hit tracing seems to disappear from all of the fuel tables, idle, PT & WOT despite WOT protocol perhaps there is a problem with an input sensor or the DME has recognized something is unplugged.

When I deleted my idle air control valve the Idle control tables wouldn't come live or respond to tuning. The car idled, and idled smooth but drew it's data from an unknown source/table. I ended up simulating a load on the IAC wires by installing LED's and then the idle tables come live and would cell hit trace.

Posted: Thu Mar 08, 2018 8:03 am
by Hairyscreech
No, this one has been tuned up from a stock bin to avoid any cumulative errors, I don't think there is anything up on the ToT front.

I did wonder if it was a TPS issue so plugged the car in to INPA and checked that INPA gave the correct TPS signal and clicked to WOT at ~70% throttle.
It was all ok on that front and working fine in INPA so I think it is going to WOT but just not showing it on the table.

Could there be something up with my tunerpro config or is it possible this old pentium 4 toshiba is not fast enough to show the WOT table tracing perhaps?
Would be a shame as its a tough metal cased unit and the battery lasts ~6 hours and a couple of days on stand by. (hence why I am using it instead of my good laptop).

Posted: Fri Mar 09, 2018 12:25 pm
by olafu
WOT tables was blocked by some faults or some special conditions. I can't remember, but maybe vehicle speed sensor? cam sensor? I don't know why, but something discrepancy happened. WOT was recognized by TPS, but wot tables was not in use. Also, for a while from engine start, there is no any WOT tables in use..?

Posted: Sat Mar 10, 2018 5:11 am
by Hairyscreech
Interesting, ok, VSS might be a culprit, The VSS plug on most E30s has long expired and gives intermittent connection, very occasionally I get the typical E30 speedo waving. I will start there.

It looks like it may be worth me spending some time confirming all of the sensors are consistent and withing their book values. They all seem to function and no codes are thrown but that does not mean they are correct.

Posted: Tue Mar 13, 2018 6:38 am
by Hairyscreech
I have been doing some work with the load calculation in the ECU and can now confirm exactly how it works:
Load formulae: Tl = Q/(n*K)

Tl - load [ms]
Q - airmass [kg/h]
n - rpm [1/min]
K - constant [kg/h*min/ms] reciprocal, factor=400

Let for example at full load we have:
Q=120g/sec -> 432 kg/h
n = 5000
K = 0.012
Load = 432/5000*0.012 = 7.2 ms

K = 1/K value in the bin *400.
Assuming the 413 K value is A9D6 (43726) then the constant is 1/43726 * 400 = 0.0091479
I think this is done like this to be able to get the best resolution possible for K/the K value.
The K value is not an abstract value, we should be able to calculate it.

If the load calculation is as above then assuming 100% VE at 1000RPM a B25 would consume:
*60=75000 L/Hour
/1000 *1.225= 98.175Kg/Hour
So: 98.175/(1000*0.0091479) = 10.04ms of load, or theoretical pulse width.
Fuel for stoich= 98.175/14.7=~6.25Kg fuel

Bosch use N-heptane as the reference fuel @ 684Kg/M^3 density.
166cc/min / 60=2.7666cc/sec
/1000= 0.0027666cc/ms
*6= 0.1666cc/rev
*60= 9999.59cc/hour
/1000 = 9.99959L/hour
/1000 = 0.00999599 M^3/Hour
*684 = 6.839Kg/Hour

So if we want the 6.25kg/hour ideal:
Reversing the calculations up to the point of cc/rev/injectors gives us: 0.025382cc/rev/injector
*1000*60 = 1522.90
/166=9.1741 ms

91.875/(1000*9.1741) = ideal constant = 0.0100014
/400 = 0.0000250035
1/0.0000250035 = 39994 or 9C3A

Now this begs the question why BMW are not using an ideal value for the injector constant, have they offset the values for differences in temperature?
If the assumption was made that the injectors run at ~50 deg C then the density would be more like 630kg/M^3 and the stock K value would give about 6.28Kg/H fuel delivery!
This would not be an invalid assumption as the injectors are mounted next to the head @~100DegC and are cooled by air and fuel flow that could already be around 30 DegC. If you have touched an M20 manifold on a warmed up engine then you know how hot they get, the injectors must be similar.

This raises the question if the believed injector constants are actually a little more subtle and require adjustment to suit engine size as well as injector size as they are a function of the theoretical MS pulse width that is needed to maintain stoichiometric ratio for a theoretical 100VE.

This brings me to the next point, I did say before that tuning the K value might not be the best way to do things considering what alpine did. However I think that this may be in error.
All the BMW produced BINs have a different K value even when they have the same injectors, they are also all within a similar value range.
I believe this K value should be used as both a tuning factor for adjustment of injector size and engine size to attempt to maintain an ideal VE correction factor of 128 for the part throttle tables.

Posted: Tue May 15, 2018 12:13 pm
by olafu
WOT acceleration problems :?

M50B25TU, 240/240 cams, open loop, rest stock.

Is there somewhere positive deltaRPM fuel correction factor?

AFR is very good when engine is under max load and constant rpm, but rapid acceleration at high load goes very lean. Error is multiplied as higher is rate of acceleration.
As an example: constant rpm wot is 12.8-13 AFR, but 5 seconds wot dyno run from 3000 to 7000rpm AFR is 14-15.

Any help?


Other notes:
ECU does individual load/rpm knock correction map for each cylinder. It's stored somewhere in SRAM.

I did some tests.
- Set knock control load threshold to "0", so knock control is always "armed".
- RPM 3000, about mid load.
- Set whole 1. cylinder knock threshold table to "0"
- 1. cylinder timing is retarded by "fake knock". 1. cylinder misfiring.
- Set knock control load threshold to 254 and then let engine idle.
- Engine is idling smooth, no misfiring.
- Set all knock settings to "factory values"

- Then, when engine reaches about 3000rpm at mid load, and knock control load threshold is reached, 1. cylinder will misfiring by retarded ignition.
There is no knock, so, timing starts to rise to no-knock values. In few seconds there is no misfiring, and advance is back in normal value.

- ECU will remember, if knock was detected in some conditions. Timing will not return, if conditions are not similar as knock has occured.

- IMO, In tuning, knock control load threshold is good to set to 254, or disable knock control by something way else. But knock must be controlled by other ways.

Posted: Sat May 19, 2018 9:40 pm
by olafu
D2 "descriptor" seems it's RPM negative delta. D2 value increases when engine speed is decreasing, and D2 is higher when speed decreasing rate is higher.

Posted: Sat May 19, 2018 10:48 pm
by olafu
Hairyscreech wrote:I believe this K value should be used as both a tuning factor for adjustment of injector size and engine size to attempt to maintain an ideal VE correction factor of 128 for the part throttle tables.
I think such same way: D5 and D6 are 8bit load values, D5 filtered and D6 raw, but only 8bit. So, max. load value must be lower than 255(dec) but still as great as possible. Low max. load value reduces resolution. "K" is used to fit load in 0-255 scale.

Posted: Tue May 29, 2018 2:09 pm
by Evil
Olafu: for your wot problems, the same thing happend To me in lower proprtions (between 1/1.5+ on afr on first and second gear acceleration).
I almost solved the problem by rising values in the last column of "acceleration enrichment quantity".
I dont know if its the best solution but it worked for me. I have a light riche spike when I press throttle on 5th gear but its not really embarassing, something like -0.5 on afr for a second.

Posted: Mon Jun 04, 2018 8:34 am
by Hairyscreech
I was actually getting similar up until this weekend, I have been struggling to get the acceleration enrichment right for the M20 and first changed the "0xDC21 D0*D5 4x4 Acceleration enrichment quantity by RPM and LOAD" to reflect the equivalent in the 173 maps and this had some effect but not enough, I then tried upping the acceleration fuel globally by adding to the last two columns of the "0xDC37 D7 4x1 Coolant temperature correction for accel enrich quantity" table, this had the expected global effect of upping the fueling at all points in the acceleration but I still found that I was too lean up top.

After a few runs on Saturday I noticed that I was staying rich as long as I held the throttle down from low load and RPM all the way through, if I lifted a little and reapplied the throttle I would go back towards lean for acceleration.

That made me wonder if there is a table effecting the amount of enrichment you get depending on the load and RPM you are at when you trigger the enrichment.
I think this table is what we have labeled as "0xDC63 D0xD7 4x4: Acceleration enrichment delta LOAD attenuation".
I reduced the numbers at higher RPM and loads and it was like a different car after, I was seeing down to 12:1 at higher RPM and loads instead of the ~14.2:1 I was seeing.

I need to do some more digging to find out how this truly works but this might help.

Posted: Thu Jun 21, 2018 10:51 am
by olafu
I wil try those, when we have our dyno in working order again. Thanks!

Posted: Sat Jun 23, 2018 3:10 am
by Triangulé
what scales did you took for these "acceleration maps"
I would like to work on that also.

Posted: Sat Jun 23, 2018 7:06 am
by Greenday694
I thank you guys for all your hard work I've been following this post religiously. I have definitely learned a lot. but not enough to be able to really contribute anything solid. I was able to use a lot of your knowledge to tune a couple of my friends modified na E36s and 1 low boost turbo setup. But no success on my own car. I've tried a bunch of combinations raising and lowering different values trying to get my car to run as if stock off of boost steady cruise and idle yet at the same time at 1.5 bar of Boost give me enough fuel. I have to set everything to the almost opposite extremes. Drop everything so that it will idle and low RPM Cruise and then raise everything up on the higher RPMs and boost. so I guess my question is, is this DME capable of doing what I'm asking of it? Thax

Posted: Wed Dec 19, 2018 11:40 am
by olafu
Anyone hear about Daqarta..?
Interesting software. It spits crank and cam sensor signals out from PC sound card.

I didn't run any tests yet with this software, but if you want to run your ecu on the table, without engine, this will help you.

I'm very curious to see how square wave camshaft signal comes out from sound card.

Posted: Sun Jan 06, 2019 4:45 pm
by Hairyscreech
Nope, but I guess I have now :)

A bench test ECU might be the final destination of the ECU in the car at the moment as I have a RusEFI unit to go into the car once I have worked a few things out.

If the square wave is not very good then it would be trivial to send that signal to an arduino and have it toggle a pin high/low to get a cleaner signal.
Given the Motronic cam signal is only one on/off pulse every 2 rpm I would have expected it to be ok?

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Thu Feb 28, 2019 1:32 pm
by Evil
Hi all,
Does someone knows unit and factor for datas in dwell time table? I will soon use some "high performance " coilpacks for my turbo setup, and will have To tune this table for the new coilpacks..

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Fri Mar 01, 2019 11:54 am
by Hairyscreech
I have in my notes file courtesy of our man in Finland:

"actually timing table for primary current switching on before desired ignition event, and same x*0.75 conversion works with it.
if you want to calculate new dwell table for different coils, correct formula seems to be (this includes all, no need to conversion): Actual RPM divided by 125 and then multiplied by desired dwell in milliseconds.
DWELL_TABLE_VALUE = RPM / 125 * primary_ms
And different direction: primary_ms = DWELL_TABLE_VALUE * 125 / RPM. "

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Fri Mar 01, 2019 1:47 pm
by Evil
Nice !
I didn't understand why raw values were increasing with rpm... :lol:
With the good equation things are way better.
Thank you very much !

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Sun May 05, 2019 6:41 am
by JAS
Trying to understand how to rescale loadaxis after changing K.value for bigger injectors.
Havde don scaling for injectors and Voltage offsets and started up car,adjusted fuelsmaps so car is running pretty smooth.
But when I trace in maps with load it only reaches about half scale on load axis.
Have read here and everywhere for our to find a solution but I´m stuck.
Also tried to rescale the coluom labels for a lower load but that didnt help.
Is there any constant relating to load you can adjust,like K-value for injectors?
I´m realizing this is more advanced and complicated than I thought...
To adjust and get car starting cold as warm was the easy part...

Would appreciate some help!

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Tue May 07, 2019 5:32 am
by Triangulé
please read my thread, olafu and i have explain how to do it.

Re: M3.3.1 motronic (413 and 506) tuning and XDF update?

Posted: Wed May 08, 2019 4:40 am
by JAS
Ok thanks.