NefMoto

I have been trying to figure out how to change the software to adapt to a mapsensor that can measure higher values than the stock one  (1,5bar) Tony do you have any input on this.? I want to use the AEM 2,5bar sensor.
I have been looking at these maps.
DSLGRAD. think this could be the one to make the direct conversion i Volt vs Hpa
But again alot of other maps need to be changed also. Factors and offset need to be adjusted in other maps so the software will convert the values the right way.

Please type in you inputs on this.

I spent a while looking into this myself.

The main problem is that the MAP sensor value is stored in an 8bit variable. This variable has a maximum value of 2550mbar, because it has a scale of 10, and the maximum value an 8bit variable can hold is 255. So even if you change the sensor to one that reads higher and update the sensor voltage to pressure conversion map, the ecu can't store any value higher than 2550mbar.

If you want to change the variable scale or offset to another value, then you will have to find every other pressure value in the ecu and update them as well. You could also change the 8bit variable into a new 16bit variable, but then you woul have to update all places using the old 8bit variable to the new 16bit variable, and change the 8bit assembly instructions into 16bit instructions. Both of these approaches would be very labour intensive.

The other option is to not rescale the sensor voltage to pressure convesion map after upgrading to a higher reading MAP sensor. If you do this the ecu will believe you are running less boost than you actually are. You can get away with running this way if you tune any important maps referencing the MAP variable to be in line with your new sensor. There may be unknown side effects to underscaling and having the ECU belive you are running at a lower pressure than you actually are.

Hope this helps.

Tony

I've not looked at this closely enough but I'm surprised by this.  Internally the ADC is 10bit IIRC.  Most of the output from the scaling functions (in my d box there are two functions for MAP ADC scaling - one appears to be a relic) is as words.  One output is a byte.  I assumed the byte was going to be used for comms  - a little like the MAF cannot report more than 364.08 g/s via VAGCOM but internally the ECU can go higher.

Have you got the function decoded?

Spen

I have disassembled just about every function that reads in sensor data in the ME7. I was also very surprised that the MAP value was being stored in an 8 bit variable. The main problem I found was that the internal scale of the MAP variable limits the maximum value to 2550mbar. If you were to rescale the variable to allow for storing a higher pressure, you would then need to rescale every pressure constant in the ECU. All pressure constants in the ECU seem to use an implicit scale of 10.

Thanks Tony, your comments make it worth investigating!  ME7 is well constructed and I'd like to see if I can understand why the designers accepted such a limit.     I'll post my disassembled output once I have it.

Tony, you are correct.  The map sensor goes through a y=mx+c normalization and then is stored as a byte. :( 

What is worse is that "requested boost in front of the throttle body" is a byte too :( 

All in, that is a lot of work to change for minimal gain.

Exactly. It is going to be a major pain to make the ME7 handle more than 2550mbar. You would need to rescale every pressure value in the ECU. I think there may be some short cuts you could take, but at this point I don't see it being worth the investment in time to support pressures higher than 2550mbar.

This would be why the APR 3+ files all clip at 2550 and then just rely on the maf readings after at high boost.  But then again, they just run it pig rich to be safe anyways....If it were easy, I'm sure they would have done it.

On a side note, I see many TDI mappers swapping the pressure sensor.   

You could swap the sensor, and not rescale the values in the ECU. This would cause all of the pressure values in the ECU to be underscaled. It can work, but you will be running at a higher pressure than your ECU thinks.

Here are the maps to rescale a MAP and install anything you like

gradient for manifold pressure sensor - DSSGRAD - hpa/Volt
offset for manifold pressure sensor - DSSOFS - hpa

In my car I have install 300Kpa maps instead of 255Kpa stock!

:)

So, for install a 350-400Kpa map sensor must be decreasing dsxgrad and  increasing dsxofs?

Tony says above that the value is stored in an 8bit value though so I don't see how you could just toss in a new sensor and change those calibrations. Seems it would just clip at 255.

The ECU can't read above 2550mbar no matter what sensor you put in it. I am 100% sure of this on the B5 Audi S4.

in 1.8T engines works perfectly!

If you datalog the boost pressure, does it ever read higher than 2550mbar?

If you rescale a map using an 8bit boost pressure on it's axis, do map cells with axis values higher than 2550mbar ever get accessed?

The main problem with the S4 ME7 is that almost all maps in the ECU use the 8bit boost pressure variable which has a limit of 2550mbar.

Some of the TDi engines can read higher than 2550, but the maps are still scaled up to 2550.

I don't know if this extends to other variants, including 1.8t.

It is very frustrating.  You shouldn't remove control of the boost from the ecu, it's a key function, yet it can't control it very well above 2550mbar :(

As already stated it would be quite a task to either rescale the scales for every map / constant so that there was a factor between the byte and the actual pressure.  Or even harder cast that byte to int16 throughout the code!

I don't see this is a problem. We were doing the same thing with unscaled MAFs for a very long time, with very few side effects from "low" load... and EVERYTHING is based on load!

From what I can tell, there are only a few maps that use the MAP

1) PID (duh)
2) relative pressure max

are the obvious ones. I dont know enough about ME7.1 to know if it is used elsewhere.

The only other thing I can think of is perhaps comparing it with the ambient sensor on start up .. maybe it throws a dtc if there is a mismatch?

Has anybody just tried it?

If the ambient thing is a problem, you could probably mess with the offset/slope a bit to put 1 bar from (say) a 3 bar MAP to match 1 bar from the stock MAP (not sure what the effect would be on the top end, i'd have to think on it), and then, like you said, the ecu would just think you are running less pressure than you are.

Aside from these two maps, there are also a number of maps that predict the change in load based on the change in intake pressures. That is the only other system I can think of that relies on pressure.

I am really against underscaling load. It is possible to make it work of course. But underscaling load has a number of side effects:
-Your data logs are all off and can't be directly compared to regular cars
-You have effectively disabled all of the high load protection systems in the car

If you are willing to rescale all of the maps in the car that deal with component protection to now enable protection at lower loads, then you can run with underscaled load and not have issues.

Any idea if being off a bit would be a problem? Say I just use 3 vs 2.5 bar sensor


Agreed. Just saying, it was done with load, and load is a MUCH bigger deal than MAP

It may cause some problems with the ECU predicting the "slow path" load changes. I would think this would cause the ECU to undershoot or overshoot it's load control.

Perhaps there are maps in ME that can be tweaked to compensate?

There are maps that convert manifold pressure into cylinder pressure and into turbo pressure. I assume those could be used to adjust the slow path calculations when using an underscaled MAP.

Know any IDs off hand? :)

Here is some of the definitions of the relevant maps I have in my old map editor software.

There are addresses from the MBox 0002 bin file. "TwoDConsecutiveIntervalMap" means the map format is: height, width, height lookup table, width lookup table, height x width map table data.

TwoDConsecutiveIntervalMap("Correction Factor for going from intake pressure to cylinder pressure during max camshaft advance", 0x81BC16, UINT16, 1.0 / 32768.0, 0.0, "Factor", "", OneDimensionalMap(engineSpeedVar_UInt16_F87A), OneDimensionalMap(loadVar_UInt16_F990)));//10x10

TwoDConsecutiveIntervalMap("Correction Factor for going from intake pressure to cylinder pressure during min camshaft advance", 0x81BB22, UINT16, 1.0 / 32768.0, 0.0, "Factor", "", OneDimensionalMap(engineSpeedVar_UInt16_F87A), OneDimensionalMap(loadVar_UInt16_F990)));//10x10

TwoDConsecutiveIntervalMap("Conversion factor from pressure to load", 0x81BDA6, UINT16, 1.0 / 219545.6, 0.0, "Factor", "%/mbar", OneDimensionalMap(engineSpeedVar_UInt16_F87A), OneDimensionalMap(camshaftOverlapAngleVar_UInt16_3822E8)));

TwoDConsecutiveIntervalMap("Internal Exhaust Gas Partial Pressure", 0x81BD0A, UINT16, 1.0 / 25.6, 0.0, "Pressure", "mbar", OneDimensionalMap(camshaftOverlapAngleVar_UInt16_3822E8), OneDimensionalMap(engineSpeedVar_UInt16_F87A)));

Thanks Tony.

Are you pretty sure all of those are used for more than just speed/density?

From what I recall, they are used to predict the change in load based on the change in pressure. It is used by the "slow path" torque demand system to predict how the load will change. The "slow path" uses these maps to determine if it needs raise or lower the boost pressure to meet the desired load.

When I release my data logger, you will be able to log the variables showing the ECUs expected load change based on the pressure change.

Interesting; i did a scatter plot of req load vs req boost and i dont see much variance depending on current MAP... would definitely be nice to have more data to log to see how req boost varies with a given req load.

I never did understand that calculation....

As far as I can tell, these are all in my map packs already:


This appears to be KFPBRNW at 1BC42. Its axis data starts at 1BC1A, not 1BC16 though, unless I got something wrong

KFPBRK

KFURL

KFPRG

My definitions says 1BC16 because there are four bytes for the height and width of the map.

I looked at it a bit few nights ago and the only "Quick" way would be to run larger MAP sensor (400kpa) from european TDI car. It has the same plug and housing.

It will read underscaled naturally. The Maps Tony listed can be used to make the MAP work as well as couple others dealing with minimum ambient pressure (700mbar), conversion of boost into air mass KVLAD and possibly few others, forget which ones now but WinOLS definition pack has quite a few you can touch.

There interesting one is DSLGRAD "Gradient pressure sensor for charge pressure" with default value of 541.0 hpa (0.541 bar). This is nothing else than scaling for our default sensor, 1v=0.541 bar. If only we didn't have that silly 2559mbar limit we could very easily stick any sensor you wanted in there and easily scale it up.

Yea, neither DSLGRAD or DLSOFS will help us here.

So long Tony can build in an adjustable multiplier into his data logger so that we can see real boost when logging, running underscaled MAP sensor sounds doable so long you adjust few things here and there.

I can't wait to have ACTUAL ECU controlled PID on ove 23psi of boost car instead of hardwiring N75 into boost tables.

The good point of getting a bigger underscaled sensor is that you can run +2550 mbar of boost with PID tuning... :)

So, let's roll up our sleeves and list EVERY single map/axis that needs to be rescaled.

What is the 1013 constant I see being divided into pressure variables?
Edit: 1013 = 1 ATM in mbar/hPA. These constants need to be found and  modify with new scale also. Fun.

request manifold pressure conversion:
fpbrkds_w
via
KFPBRK
KFPBRKNW

actual pressure conversion:
DSLGRAD
DLSOFS

ambient pressure conversion:
DSUGRAD
DSUOFS

referencing maps/axis (here's where is work begins):
a factor needs to be figured out first from the modification above

group by referenced variable

PU/PU_W (ambient):
PUMN
PUMX
PUSPSMX
PUE
DPUPVDK
FHOE ?
...

pvdks_w/pvdkdsl_w/pvdkds/pvdkmx_w/fpvdkdsl_w/pvdkspud (actual pressure):
PVDKMX
PVDKMN
PVDKPSMX
DPDSVLU
PVDKPUD
KVLAD
LADFIL ?
FPVMXN2
PBKVVSTGPV
...
ps_s/pssol_w/plsol_w/plsol (requested manifold pressure):
KFLDFK
PSPVDKUG
KLAF
...

There really is no need to bastardise the scaling, the std sensor is fine, you just need to have external logging.

bastardise?  i would think this would be how bosch does it for cars equipped with 3bar+ sensors. the overall scale is adjusted to match sensor. FF no longer = 2560. FF = 30xx mbar and thus every bit from 00 to FF represents a larger hPa value and requiring every map that references hPa to be rescaled or axis rescaled. No?

what if you want DV control for pressures above 2560?