NefMoto

I recall seeing a few posts by somebody (forget who) talking about workarounds for fueling when you hit maximum rl_w/ps_w (another good reason to work hard towards migrating to an RS4 based tune and a bigger MAP).

But I can't recall who it was, or what they said they are doing.

I'm dorking around with FKKVS to compensate, but I really don't like it.

Can somebody point me to the thread? My search foo is failing me.

BTW: thanks to tony for getting the forum back up :)

I probably did.

Downscale KFKHFM and upscale KFLF at the same point.
Edit axes to suit.

The problem is not rl_w but ps_w.

Stupid ECU scaling.

Are the axes shared by any other maps, or can I just edit them willy nilly

Oh, also, what is a "safe" value to scale down KFHFM (and KFLF up)?

Also, do you pick a bunch of cells to scale a fixed amount, or do something nice with a linear line?

Are there any possible side effects?

The axes are only for those maps IIRC.

Just make it taper down from say 150 load to 220 load.
And adjust KFLF in the same way.

That will get you close.

After that make some logs and see how far actual is off requested and correct KFLF to suit.

It really sounds a lot more complicated than it is.

Nye,

I'm interested in investigating this a little bit. I can provide RAM variables if you are willing to take some logs of this limit. I have locations now, but it might be a few days before I have time to work out the factors.

When prj first wrote of this, I was curious how this is just now coming to light?  Haven't people on the forums tuned to 600+HP on rs4's before this?

Also, prj, you had this issue on  the k-box, right? So this isn't an issue that can be solved for us m-box guys by switching to the k-box?

AFAIK they ran super underscaled MAFs, and/or tweaked FKKVS to hell and back to get fueling up.

Why do you think GIAC started with a 100mm MAF back in 2002 lol

Nothing to investigate. rlroh_w gets converted to ps_w and then back to rl_w.
And ps_w has the same hard cap of 2560mbar.

I had the issue on a 1.8T. On the RS4 I am also pretty close to hitting it. My ps_w is 2450mbar right now at it's peak.

The scaling for ps_w on K-Box is exactly the same 0.0390625, making the maximum value 2^16*0.0390625 or 2560.0 mbar.

I'm aware, but I would like to look into a possible solution.

The solution is pretty much to rescale all pressure in the ECU by a factor of two.
So that it can do 3 bar absolute boost...

ps_w and all the other pressure values are connected.

I know....I've gone through the code some and read the posts, but it is much easier to see with logs.

I think that we can do this and fit a higher bar MAP sensor without too much difficulty. Just ALOT of tedious work.

I don't have the problem (luxury) of maxing out the MAP/pressure variables at the moment and am currently just curious.

Nbd...I can wait on this until it gets in my way.

If you want logs, I have tons of different logs from a 1.8T I tuned recently.
I just upgraded the exhaust on my RS4 so I can try to hit the limit on it as well, but I think 1.7 bar on K04's is pushing it a little...

Basically, I have a functional emulator, a functional brain and a functional car, plus a mile long airfield strip I can go to at any time.
If you want - let's do this ...

My MAP is already maxed as I am running 1.6 bar now.

As a bonus, the PID (and PID trims) will be a LOT more stable if we have a lot of MAP headroom...

http://nefariousmotorsports.com/forum/index.php?topic=110.msg18757#msg18757

Just to start. The more I look at it, the more unappealing it becomes.

I currently run a 3bar MAP, but it's only good for logging with ME7Logger (raw voltage with factor/offset to give me psi).

Yea...very tedious.

Did you rescale the linearization or just slap it in there?

This is a nice to have and something I have looked at doing but no time for it.  In practise it really isn't hard to tune around as prj notes.  I have a stroked 1.8 I'm tuning now which should be doing around 600hp, I'll see how that comes along.

Rick

How about making a dedicated thread for it, and starting with the rescaling work, assuming a factor of two?
Also, do not just post a huge list of maps or variables, but post for each variable why you think it should be changed.

Some things are obvious, others are not.
Stuff like KFBRK and KFBRKNW can be just zeroed out as I understand it. This is done from factory as well on some files IIRC.

Rescaled it.


That was a starting point. We need to start with a list, then discuss/decide if it shuold be modified. However, identifying ALL the maps that should be considered is the first step. Hence the list (tho incomplete) of maps.

And where did you get a factor of 2 from? The factor will be dictated by the MAP sensor used. If you are going to go thru all that that trouble, why start with a 'shoot from the hip' factor when the MAP sensor specs will give you an exact factor?

sorry this should be continued in a dedicated thread as stated above.

I like this train of thought and would like to assist in any way I can, once I get my car into shape to where I'm able to boost above 2560mBar without running out of fuel first.  I think this could possibly go hand-in-hand with the desired swap for us M-box people to go to K-box, since to do the uprated ps_w, we'd have to start over with a file with all of these tedious changes made anyways.

Thinking about the potential higher-rated MAP sensors, does anyone have any thoughts on which sensor we might use?  Is there a different Audi part that would be form-swappable with our MAP, in the TBB?
I'm currently running a Zeitronix 0-5V 5-bar boost sensor (that isn't manufactured by Zeitronix) in addition to my stock MAP sensor, to log boost above the stock MAP threshold, and when I was deciding to do this, I did some research on the Zeitronix 3 and 5 bar pressure transducers.  I'll have to review my notes for actual values, but the 5-bar sensor had tighter tolerances than the 3-bar on accuracy, so even though the 5-bar has a larger range, it's precision was right about the same as the 3-bar (accurate to just under .1psi IIRC).  The 5-bar sensor is a really good one, though it would be tough to make it fit in the stock MAP hole (which shouldn't be a big deal), and I agree with elRey, if we're going to undertake this project that would require a bunch of work, we should figure out the exact right factor for whatever MAP sensor we use.  If people do want to try to use the 5-bar sensor that Zeitronix (and a ton of other people) use, I would be willing to sell them a sensor at distributor's cost for this project, just hit me up.


That would disable variable timing, no?

Hell no. Why would you use a MAP sensor as the base? The pressure does not have to max out where the MAP sensor maxes out and vice versa.
And a factor of two is the easiest to do. That way you can theoretically read 2560*2 = 5120 mbar. Or up to 4 bar of boost.
Whether you use the range or not is completely irrelevant. You are just changing the factor for the pressure inside the ECU by a factor of two.
This also means you can do the rescaling work *once* and then the file can be used with any sensor up to 5 bar by changing DSLOFS and DSLGRAD.

Not at all, what makes you think that?

I was actually thinking of KFNW & KFNWWL when I wrote that.  But considering KFPBRKNWS is titled "factor to correct pressure at combustion chamber by active Camshaft control", and the fact that it eventually affects rl_w, doesn't that mean that it will affect proper use of the NWS cam switching usage (on boxes that weren't 0 to begin with in those maps)?

I don't think so.

Resolution. The larger the scale the lower the resolution.

This is completely irrelevant. The pulsations in the intake and the smoothing of the read MAP values lowers the precision way more than 20mbar in case of an 8 bit variable.
And with 16 bit, it's not even important.

You are thinking too much in numbers and theory - from a practical point of view, I have used 8 bar sensors with 8 bit resolution and that means a stepping of 0.03 bar.
You are worried about the difference between 0.01 bar and 0.02 bar. Can you give at least one example of why that would even remotely affect anything?

Thanks for another really good thread! :)

Agreed, thanks guys.

Do we have a concensus?

Let's formulate a solid plan, then we can split up the work and tackle this.

Who's in?

prj, elray...anyone else? Silentbob?

I'm in... but I'm retarded.  Let me know if there's something you want hard-tested, or whatever a non-programmer/disassembler can contribute towards.

honestly, i think prj is pretty much the only one of us in a position to make real progress on it...

I'm definitely out of my depth for most of this right now, unless i spend a lot of time with a disassembler.

Silentbob said he'd send me a list that he drafted up, but I guess he got caught up in other things and never got that far.
Do you guys have a good suggestion for a plug and play MAP sensor I could run on my RS4 that is bigger than 2.5 bar ?
Obviously this is not needed to make these modifications and have them work, but just asking.

This Saturday I am spending the day on the airfield with my emulator plugged in. I can try loads of stuff.
We might as well continue in this thread, since everyone is posting here, does not matter at this point.

I will be using my K-Box binary. But I think ultimately it's not going to matter too much...
So assuming a factor of two and stock MAP sensor.

Going through elRey's list:
fpbrkds_w, KFPBRK, KFPBRKNW - this is not pressure conversion. This is just a "correction factor". Also, because this is a division, no changes are needed here.
DSLGRAD and DSLOFS - have to be divided by two. This way the maximum value it will go up to is half of the current value.
DSUGRAD and DSOFS - exactly same story - divided by two.
PUMN, PUMX, PUSPSMX, PUE, DPUPS - divide by two.
DPUPVDK - already all zero in K-Box
FHOE - divide by two
PVDKMN, PVDKMX, PVDKPSMX - divide by two
DPDSVLU, PVDKPUD - divide by two
KVLAD - multiply by two (constant for converting boost pressure to flow)
LADFIL - leave it alone
FPVMXN2 - leave it alone, it's a relation between two pressures (multiplier)
PBKVVSTG - this is a constant without axis in K-Box, leave it alone.
KFLDF - axis divide by two
PSPVDKUG - seems like a factor between two pressures, leave it alone.
KLAF - the map needs to lose every second value, and the new values copy pasted into the first half. The rest of the values have to be found somehow. I might be wrong here.

Additonally:
KFLDIMX - divide pressure axis by two

So - I got this started (of course not taking credit from elRey who posted the initial list of things), come on :)

Im also riding the ps_w cap as of now. It is my understanding this is done just by rescaling pressure affected maps, but what is the best way to half ps_w to begin with? KFKHFM?

I will getting into this tonight and start with that list.

I believe there is a plug and play 3bar ford sensor somewhere. Not sure about 5bar

3 bar is fine, does not have to be 5 bar...
Part number would be awesome.

I am also hitting the ps_w cap on my RS4. Had to downscale KFKHFM...

I have now gone through that list myself, started to find the maps I need to scale and define those I didnt have.

Hoping to define the last maps/constants tomorrow and write a scaled file to log.

What do you think of this approach to deal with the ps_w scaling:

KISRM, divided by 2 = ps_w divided by 2.

KFPRG, divided by 2 = Internal backpressure reference divided by 2.

KFURL, multiplied by 2 = Conversion factor of ps_w to rl_w multiplied by 2.

It's not so simple, some other things will go wrong as well - KLAFTE and so on.

Is not the input of KLAF and KLAFT(E) a relationship between pressures? And since we are scaling down pu_w, ps_w and boost by an equal amount, we should not have to worry about those maps?

In the case of KLAFT(E):
975 / 2560 = 0,380859375

487,5 / 1280 = 0,380859375

Is there benefits to scale ps_w via KFKHFM and fueling back up in KFLF vs. scaling ps_w down via KISRM and then rl_w right back up via KFPRG+KFURL? KFPRG should be scaled either way, since the output is in hPa which then is added/subtracted to ps_w.

Im just thinking out loud here, these are only my speculations.

If i'm reading this right, even if we don't get a larger MAP, we can fix the ps_w limit problem this way?

If you are rescaling everything else, then of course this will work.
But I thought you said only rescaling the three variables you mentioned - that wouldn't work.

If the boost limit right now is ~22psi, then when you add.5 (~7 psi) you're capped around 29-30 psi.  Some people are going to boost 30+ psi, so my vote is to go with a 5-bar for the headroom so that those high-boosters won't have to do all of the map modifications a second time.

I understand, I could have formulated myself better :)

I meant I went through the list you added your comments to, get a headstart trying to getting a better understanding of what im dealing with, and I intend to scale those too. I just asked about the idea I had about scaling ps_w in particular and the adjacent conversion "back" to rl_w.

I totally agree with just divide everything by 2, both for simplicitys sake and to do it once - have enough headroom for any desired boost. I think I will put in a 4bar VW TDI sensor and be done with it.

Yep, but the sensor can be 3 bar for example... The hard part is not changing the sensor (that's just DSLOFS and DSLGRAD), but making the ECU read more boost.
So my suggestion was to use a 5 bar scale, but of course for most people a 3 or 4 bar sensor will be fine.

Btw, I left my emulator in my car - daily driving with it.
So I can play with things...

I just need to get myself together, take my 551K tune that I am running right now and adjust lots of stuff.
But I also need a bigger MAP sensor before I do this. Does anyone have a part number for me, of what I should order?

This is what I was looking into (but it isn't plug and play)... you'd have to fab up a housing and a plug for the harness

http://cache.freescale.com/files/sensors/doc/data_sheet/MPXH6400A.pdf

Take a stock MAP, cut it up, add a little hose, and route it to this guy.

Or take an off the shelf standalone boost gauge sensor, and wire it up.

You'd still need to do a bit of fabbing, and it isn't plug and play.

I'm still looking for the stock fit 3bar MAP but i can't seem to find it.

See here for other info

http://s4wiki.com/wiki/Manifold_air_pressure#OEM

I have heard that people have used these

0 281 002 401: 0.2-3.0 bar (038 906 051 C - Audi TTMKII/VW Jetta V TDI)

... but i haven't personally tried it.

This one is the one I referenced earlier, and this gets my vote.

http://www.aemelectronics.com/5-bar-75-psia-map-stainless-steel-sensor-kit-655

Actually, I think that there are at least a few people capable of contributing on here.

I will be diving in shortly, I'm just wrapping up my current project.

I think we need to be much more methodical about it though. I will start by identifying all of the functions related to pressure, work down to actual variables, and the follow the path of these variables.

Looking into this a little while back, some deep google searching turned up a couple of supposed plug and play OEM sensors. I don't think hacking in some aftermarket sensor is the best option.

Interesting, this question brought something up I didnt think about before.

In short, yes to my understanding. But since ps_w is connected with the other pressure variables, the better approach would most likely be to scale the other pressure variables too(as prj also advocates).

BUT, this rises the good question, since it is very common for the 2.7tt guys to underscale load. When underscaling load(scale MLHFM by x %?), ps_w is also scaled but not the other pressure variables it is connected with(pu_w, boost variables).

If there is bad side effects by only scaling ps_w and not the other variables, it should surface when underscaling load, no?

Bische: exactly. I was absolutely suggesting that.

I know the concept of underscaling load is anathema to many, but the fact is, it does work with some minor tweaks to get part/idle working right.

IMO underscaling KFKHFM and overscaling KFLF (as prj has suggested, albeit only at high load) does exactly this; the question is, can we just do it across the board? If so, underscaling ps_w across the board is probably ok too.

50% is probably too much, but certainly there is some ballpark where it will work.

I think the best solution when in need to underscale load, is to do a complete ps_w/pu_w/boost scale as we discuss, and then downscale rl via KFURL to a desired level. This also lets you use any MAP sensor desired and control boost in closed loop up to 4bar.

I did not come as far as rewriting my tune to be completly downscaled yesterday, but I managed to find/define the maps I believe would be needed to scale. I think I can manage to rewrite my file tonight and flash it tomorrow and take some logs.

Anyone else currently working on this?

Now finally I have scaled my file to the best of my knowledge, flashing it tomorrow morning to test it out.

I ended up changing 18 maps/constants and I did a 50% scale, hopefully my tune now is capable of handling 5120mbar :)

I will write a clean version of my notes when I have spare time.

AWSOME

So, in theory, the only thing you should have to change for a different MAP is DSLGRAD?

DSLGRAD and DSLOFS.

Bische, keep in mind the list I gave was not complete. I am sure something was missing from it...
But okay, let us know how you get on.

I have an emulator 24/7 plugged into my car but I am just too busy right now...

Yes, I understand. I found some more in need to be scaled, KFDLULS and FRFLSDP for example. Im sure there is more stuff that will be floating up that needs to be changed, but we need to this started :)

Then there is some stuff in %LDUVST/%DLDUV and possibly in %BGPLGU, I could not find my codeword for %BGPLGU.

%BGMSZS is hard to follow at times, but I think I have got the maps/constants I need covered there.

So I haven't dug into all of these functions yet, but just to make sure I'm understanding it correctly, in essence we are 're-scaling' all of the maps, to read correct numbers with regard to boost/load/etc above the current cap, as opposed to simply 'underscaling' one or two things to make the ECU think that it's running less load, etc, right?  Or is this all just a more thorough 'underscaling' that will still not be the actual numbers?

They're making the representation of all ps_ variables half as big, to give more headroom.

So, for example, the conversion factor for displaying ps_w is not  0.0390625, but 0.078125, such that 0xffff is 5120mBar rather than 2560mBar

So it'll have accurate readings for the values, just twice the max value (and half the resolution).  Good, that's what I thought/was hoping, but the last couple of post made me want to double check.

(http://i.imgur.com/JOYOO.jpg)

Ps_w and boost is stock factor, ps_w2 has the factor doubled

Awesome.

Any side effects?

Btw, if you want to make a screenshot, hit print screen :P

Thanks prj  :)

I have just taken a quick look on the logs while in the car, but I noticed three things while driving it and from the quick gaze at the log:

1. When the car is cold, the warmup idle just goes to 1200rpm for 1 sec then down to warm idle RPM. But it runs 100% clean, which leads me to believe there is some map in need of scaling in the warmup idle function.

2. The negative gradient maps in %BGMSZS, PSSOLPGRD, PSSOLNGRD and PSSOLPF does indeed need to be scaled. I didnt think this would be noticeable at first, but I can tell just from driving the car these need to be scaled accordingly.

3. This is not really related to this hack, but I became aware that something is fishy with my FRLFSDP. I did scale the axis in this map -50%, and the car ran ~8% richer just as if I was adding 8% KRKTE. My axis definition must be wrong in this map, I need to go to the bottom with that one.

Other than these minors I have yet to get any side effects, car runs great, boost control is still great. The biggest plus right now is that the stomache cringe when boosting is now gone, knowing the ECU is still in its reading range lol. 5120 hack FTW ;)


 ;D

I was so excited I got this working and I had no internet in the car so i snapped a fast one with the phone :)

Ok, here is cleaned up list of the maps I changed for the 5120 hack:

[%BGMSZS]

KVLAD      - Multiply by 2
PSSOLPGRD   - Divide by 2
PSSOLNGRD   - Divide by 2
PSSOLPF      - Divide by 2

[%BGSRM]

KISRM      - Divide by 2
KFPRG      - Divide by 2
KFURL      - Multiply by 2

[%DLDUV]

DLDUVES      - Divide by 2

[%DLDR]

KFDLULS      - Divide both axis and table by 2

[%GGDSAS]

DPDSVLU      - Divide by 2
DSLGRAD      - Divide by 2
DSLOFS      - Divide by 2
DSUGRAD      - Divide by 2 (DSUOFS was zero, otherwise divide by 2)
FHOE      - Divide by 2
PUE      - Divide by 2
PUMN      - Divide by 2
PUMX      - Divide by 2
PVDKMN      - Divide by 2

[%GGPBKV]

PBKVVSTG   - Divide both axis and curve by 2

[%LDRPID]

KFLDIMX      - Divide axis by 2

[%LDUVST]

KFSDLDSUA   - Divide both axis and table by 2
HSLDSUA      - Divide by 2
LDUVRS      - Divide by 2

[%RKTI]

FRLFSDP      - Divide axis by 2

This is what I'm talking about!

Nice progress.

what about the few ATM constants? (1013 hPa)

Do a search in doc for '1013' to find where they are.

There are a bunch of axes in LDRPID... do they need fixing?

I mean, either way, the PID probably has to be recalibrated... but having the axes setup correctly will speed the process.

These are really nice

VW Part Number - - - 03K 906 051 ( 03K906051 )
Bosch Part Number - - - 0 281 006 060 ( 0281 006 060 ) ( 0281006060 )

4 bar absolute pressure

(http://i1219.photobucket.com/albums/dd425/euroshack/TDI%20Club/03K906051-1.jpg)
Mapping for boost sensor linearisation:

0.215V 200mbar
3,803V 3408mbar

Wow, awesome find!

:P
http://s4wiki.com/wiki/Manifold_air_pressure#OEM

Well why didn't you throw that out earlier :P

He did ^^

I guess he did throw out the link, but he mentioned the 3bar instead of the 4bar.  I'm just giving him crap :)

Heh to be fair I had only heard of somebody using the 3bar... I had no idea the 4bar actually existed AND that people had tried it.

Good info to hear that it does, indeed, work. Going to try to get one for myself.

I don't think this is a problem, because if you look at those constants, they are only used for multiplication and division.
At least that is what I found when I last looked at them.

I've seen these listed at darksidedevelopments.com in the Ukraine;

 http://www.darksidedevelopments.co.uk/products/vw-4-bar-map-manifold-pressure-sensor-03k-906-051.html

Ukraine???

LOL, stupid phone. Uk....

Just a note, I don't have any experience with the above company, just found them surfing last night...

Latest update of the list im running:


If anyone finds anything more, feel free to add to the list. I have only listed those that were in need of scaling in my binary, there has been a few maps/singles that have been zero'ed or not in use in my file, that may or may not be in others -these are not on the list.

i've put this here for now

http://s4wiki.com/wiki/Manifold_air_pressure:Rescale_project

WARNING!

Before attempting any pressure scaling you must check if your car uses brake force amplifier(%GGPBKV)!

I just became aware of this, and if this function is in use it must be scaled. I dont really know what would happen if not scaled, but I dont want anyone to have their brakes messed up!

In the 1.8t and S4 2.7 binarys I have with this bit defined, it is CWGGPBKV = 6dec. 6dec = Brake amplifier function turned off.

Please verify your CWGGPBKV in %GGPBKV if you are going to scale the file.

O32RP, 032QN, 032TL, 032HN CWGGPBKV = 2.

There you go.

We have another problem with the scaling:
(http://img72.imageshack.us/img72/3549/fhow.jpg)

Would it be possible to locate this number in ASM and divide it by 2? That would be so damn awesome

Yes, what file are you working with?

What number are you talking about? Ah I see the red rectangle now...

that was brought up earlier:

0x6A965  - Change from 0xA4 to 0x94
0x6A969 -  Change from 0x62 to 0x72

OR

0x6A956 - Change from 0x87 to 0x0E
0x6A957 - Change from 0x02 to 0x05

I think there a few other places you need to do this too.

I have posted it on the forum before, im on the phone now but the box# is 8E0909518M


To be honest, I missunderstood your post and was thinking you was referring to values in the module %ATM and I searched up and down and found nothing lol

Now I understand you was referring to the unit atmosphere :)


You are a rockstar matchew!

I changed the first two value you listed and now my fho_w is scaled, around 0.9xx instead of 0.4xx.

Should I change the other two values you listed?

Thanks again matchew!

No, You can do EITHER to get the same effect. DO NOT do both.

:)

Why is this needed exactly?

To scale fho and fho_w back up, instead of dealing with like 20 modules that uses this variable.

I'm on vaccation and do not have access to either winols or bin files. what is max and min? Would it be possible to taper to /2 or /3 on KFKHFM and x2 or x3 on KFLF at highest load. I hope I remember correctly that the value is a factor for multiplication.
Why bother you might ask. Well a large enough MAF with matching boost would generate to much load.

Alright, that was my understanding -just wanted to double check.

For future file scaling reference, can we look for a certain pattern of data to find these values to scale them? Or is it needed to go back in ASM to find them in each file?

Thanks again  :)

Ok, so I have one more issue(that im aware of), that is during cold start -or I think I have narrowed it down to cat heating cycle during start. Also have a readiness of 65dec which is very likely are related.

I logged a cold start today which im attaching a plot graph and the log for anyone interested.

Is somebody making changes to M-box yet? I will be facing a choice of underscaling or going the right way very soon once my tial 770 engine is broken in.

Thanks!

You should join us with the switch to k-box :)

I skipped few months of summertime and back with vengeance :). Finally finished the car, 2.9 with 770s etc, boy was a lot of work what!

Anyway, I will bring myself up to date. Two quick questions though:

Will it pass obd2 emissions?
Is k box immo equipped?

Not sure on the obdII, but I gas been assuming it would. Yes on immo,, and i'm planning in having an immo active k-box with higher map sensor and multi map switching.

Yes.
Yes - just de-immo your EEPROM.

Before I blow money on this - the pinout and plug is compatible, right?

pinout and plug compatible only sensor diameter can be different

Diameter...
You mean the distance between the two mounting holes?

there are two o-ring diameters in vag cars, take a look:
http://www.pagparts.com/images/MAP-Sensor-style.jpg

I can check 4bar diameter tomorrow but if I remember correctly it is different than s4/rs4.

This is actually perfect since it will go into allroad (which has immo hardware).

Aha!
Okay, thank you. Please check...
I would rather find a plug and play sensor if at all possible.

Do you know if the S4/RS4 has the bigger flange or the smaller flange? If it has the bigger flange, then it is easy to make an adapter, but if it has the smaller flange then nothing can be done I think, unless a very clever adapter is made...

I already check it. S4/RS4 is old style bigger flange - you can use 3bar map sensor 100% plug and play 0 281 002 394 - 038 906 051A

4bar is new style smaller flange, you can make adapter. It is replacement if somebody have 2,5bar 038 906 051B or 3bar 038 906 051C MAP sensor

The pictures I saw of the 4bar sensor, it came with a rubber o-ring adapter to fit the bigger diameter holes as well.

Thank you both... Ok so the 4 bar won't fit without an adapter.

jibberjive - tell me more about the adapter. Where can I buy a sensor that will come with it?

Just ordered the 3 bar

I just googled the part number, and looked at the pictures.  One place that shows it is the one that was linked a couple of pages back

(http://cdn1.bigcommerce.com/server3600/f4487/products/60/images/1905/DSC_8506__50974.1351675176.800.600.JPG)
(http://cdn1.bigcommerce.com/server3600/f4487/products/60/images/1907/DSC_8505__67996.1351675214.800.600.JPG)
http://www.darksidedevelopments.co.uk/products/vw-4-bar-map-manifold-pressure-sensor-03k-906-051.html

So I have been running the 5120 hack for some time now, been working on different flanks of my tune -logging flashing driving everyday(its my daily driver). Everything just works as it used to, except for one thing, the cold start idle.

Either it does what I captured on the log I uploaded(maybe 1/10 times), but almost every time it just revs up to ~1400 and falls right back down to my idle rpm which is 900rpm. It is running rough during the rev up, like the 0.5sec it takes to rev up after ignition, then snaps back down to idle and running flawless.

I think I have found what is causing it though, KFWDKPP - one of the inputs to this map is not correctly scaled because of a 1013atm division, fpvdkds. So I have scaled the axis accordingly, multiplied it by 2:
(http://img846.imageshack.us/img846/1584/kfwdkpp.jpg)

Been going back and forth whether Im ordering a 4bar MAP sensor now or not, im afraid my stock block wont take much more boost anyway, im running 20.5psi ramping to 22psi after ~4700rpm -where my torque peaks.

Also attached a 3rd pull graph showing ps_w doing its business, the requested looks a bit wavy as I had some ASR activity during that pull.

You are doing great.
I will look into that division when I have time, maybe provide an ASM hack for it.

Outstanding. I can't wait to try this out.

Any chance you can regularly update a stock M file with ONLY the MAP changes?

That way I can make sure I have a mappack ready for it.

He is working with an M file.


Change 0x5F017 from 0x34 to 0x44, this halves the load axis look up ram value. Change the axis back to stock.

Let me know.

It would be best if all this work would be based on the 4bar sensor. Then there would be margin for the few guys that work with high boost, without the need to hack this hack again.

I'm pretty sure it's just double the stock value, which is above 4 bar if I've read everything right.

Yes. The point to this project is to have a file that will work up to a 5bar MAP

So to work for a 4 bar map we would just use 1.6 as the ratio compared to stock rather than 2 and 633 instead of 1013 right?

Thanks :)


I am working on a 1.8t, 8E0909518M


Thanks again, I tried this out and now it just did like what it did in the log I uploaded. DK oscillates the first ~20sec, then i had cold start idle RPM.

I think we need to half the top and bottom 1013's on this page in addition to the fho_w one you helped me with:
(http://i.imgur.com/3TALq.jpg)

The bottom one doesn't exist for reasons that you should be able to tell by looking at the pic you posted.

The top one can be halved by changing the following bytes:

0x6A3F2 - Change from 0x87 to 0x0E
0x6A3F3 - Change from 0x02 to 0x05

0x6A22E - Change from 0x87 to 0x0E
0x6A22F - Change from 0x02 to 0x05

I think there a few other places you need to do this too.

You are right, im stupid  ;D

Thanks, I will test that out and report back!

No, for a 4 bar MAP you only need to change DSLGRAD and DSLOFS.
Read this thread through before asking questions or people will soon get pretty grumpy at you.

I was hoping for a 2.7t M box

Yes, I figured. I feel we are pretty close to the goal now, then we need to wrap it up and figure out a smart way to hack the ASM for the 1013 divisions(if there is a way besides to disassemble each and every file?).

Then I guess it is wiki time, but I dont feel like it is a good idea to prepare files with this hack and upload for everyone to use, at least not at this point. It would be very good if at least one or two more persons trace the diagrams and implement the hack themselfs, there is likely stuff I have overlooked that someone more experienced may pick up.

When I get to the bottom with the cold start issue I will update my map list.

Well gee. I'm sorry I have read the thread and must have missed that. I'll read again...

Now I see it. Thanks. That's pretty simple then really.

Yes, it is... the entire initial idea and now the implementation is made with the fact in mind that you can use any MAP sensor up to 5 bar, and only change two values.
All the rescaling only has to be done once...

Good stuff indeed.
Reminds me of the days when I was helping dev 3 bar support in the Megasquirt... glory days :-)

It shouldn't be too difficult for people to find the constants in hex given a file or two with the locations already identified.

I plan to go through the disassembly and do an M box file when I get some time. I just have to wrap up a couple of thing first. I won't be able to do any testing though, my baby turbos aren't up to it.

And we have cold start idle back!

I changed all four of those values, returned KFWDKPP axis to stock and the 0x5F017 bit you gave me back to stock.

Ill do some more logging today after work.

Sounds good.

You dont really have to turn the turbos to 23psi+ to test this out?

Your welcome!!!

Thanks for all your help, this would not be possible without your help!

You are a hero :)

After a few starts the cold start idle is not there anymore, drops right to 900rpm again. I find that very strange.. And I dont have the varibles to log this and reverse back to the culprit, ie. Do this the proper way.

I have a few new varibles im going to log after work today, ill get back tonight and share my findings. I do think as matchew says, we need to half more 1013's to get everything in line.

But im going to try get more data first, I dont want to bug you disassemble kings anymore with these ATM divisions, until I have done what I can with what I have.

So I have found something, pvdk_w is doubled, according to my understanding. I have a few things to try now, need to do some flashing and logging.

Try this, I took literally 30 secs to look at this.

Change 0x69290 from 0x4D to 0x9A
Change 0x69291 from 0x65 to 0xCA

Change 0x694EE from 0x4D to 0x9A
Change 0x694EF from 0x65 to 0xCA

matchew, you are a ROCKSTAR!

I defined the last ASM division(-> fpvdkds_w) you gave me as 16bit LoHi, as per my my own assumption, and did the changes per your intructions(I did the changes and afterwards realised it was a word). Could you please give me/us what exactly this change in code does?

And to this new code change you gave me now, what am I altering? I am assuming this change should be done in addition to the last ATM change I did(-> fpvdkds_w)? I am trying to get a better picture of what I am actually doing here with the invalueable help you are providing us.

I hope everyone that is learning something from this thread is giving matchew +rep, he is the one freely sharing the work/information to get this project up and working.

So does this latest update work?

It is to be done in addition to everything else that I have listed that works.

(http://i.imgur.com/3TALq.jpg)

Alright, I have been taken some logs and I can confirm this change halfed the top 1013 and get fpvdkds_w sane. I can also mention that my pvdk_w was NOT doubled, I made a mistake when I scaled up my logger definition and scaled up pvdk_w when I was not supposed to.

Ok, with fpvdkds_w confirmed we end up having more trouble here:
(http://img202.imageshack.us/img202/1175/pvdkdivision.png)

(fpvdkds_w * fkmsdk_w) * 1013 = pvdk_w

pvdk_w is then divided at a couple of places with other already scaled pressure variables, one of them ends up screwing up the input to KFWDKMSN. That is what I think is causing my less than optimal cold start.

I have made the last change matchew gave us(which I believe will half the ATM constant that calculates pvdk_w, mentioned above), I will log it tomorrow on my way to work and report my findings.

Pvdk_w confirmed scaled down now, had to modify matchews last ASM change to get it to work. I will post what I did and the log when I get home.

had a VERY interesting drive to work, car drives like complete HORSESHIT lol. Its either no throttle or full throttle..

I got a nasty feeling some dyslexia came into play here. 44E/F not 4EE/F :$

I figured, no worries I catched it when the numbers didnt match :) Here is what I did:

Change 0x69290 from 0x4D to 0xA6
Change 0x69291 from 0x65 to 0x32

Change 0x6944E from 0x4D to 0xA6
Change 0x6944F from 0x65 to 0x32

That scales pvdk_w down, but it makes the DK control out of whack, the reason is another 1013 division seen here:
(http://img208.imageshack.us/img208/8971/frhodkrw.png)

Ultimatly this doubles the throttle plate sollwinkel(KFWDKMSN), according to my understanding, it is a bit hard to follow the path from here to wdkba.

Attached a graph of the scaled fpdk_w and the log. Oh, the boost numbers on that graph is scaled x2 in the logger definition, pvdk_w is not.

Yeah I went the wrong way, that is what I get for rushing.

Are you sure you want to continue with this?

How do you mean? Yes ofcourse, I want this to be fully functional and there is one division left to hack. I know that last 1013 will solve the DK business because I went around this problem this morning by multiplying the KFWDKMSN axis by 2 and the car drives normal again.

But that is t the correct way to do it since it doesnt take the msndko_w into account, the correct way is to divide the ATM constant. I understand you if you dont feel like digging the last one out.

This is very interesting topic, can't wait for the summary of all the maps and constants needed to change, so we could finally have one universal way to fix this problem

Change 0x6BEB4 from 0x4D to 0xA6
Change 0x6BEB5 from 0x65 to 0x32

This will half the constant.

Let us know how you get on :)

Waiting for the end result are you? and then I suppose you will ask over 1000 questions about how to apply it to your specific files and why it has to be done to the nth degree?

I understand that you think that this is the last location, but from quickly looking through the disassembly of the file there is atleast another 10 locations, thats just from the code that ive looked at.

Thank you for your time prj, I really appriciate it :)

Of course I will post the result!


I meant that was the last ATM division to get the DK control back up working as intended, which is the major malfunction I have had after scaling the pressures. I know and have stated before there is very likely stuff I have overlooked or just not come to think of while tracing the modules, but as far as I am aware, I have only had trouble with this DK control and readiness not setting.

When I started this project I did expect to have alot more trouble than this honestly, Im glad I didnt though. I would never have come this far without you guys help. I feel like we are close to the goal, but if there is something you know that needs to be changed, please let us know :)


EDIT: Went through the FR and we have now scaled all ATM constants but one, and that is the one not used with SY_TURBO=1.

Funny. Forum is created for asking questions and giving to others information that you know. If I'll need I'll ask 1 million questions because I'm trying to learn new things here. Also I'm trying my best to share some new information that WASN'T mentioned already. Ok, enough offtopic.

If he doesn't, I will, unless you are willing to maintain the s4wiki tuning page :P

 ::)

This is confirmed, scaled the KFWDKMSN axis back to stock and halfed the ATM constant. Frhodkr_w is now back to sane.

Car runs like a champ again, celebrated with some donuts in the 6" snow we had last night :)

Good to hear. Let us know if there are any more anomalies.
We have about 15" of snow and it's not stopping nor melting.

I will do, going to drive it a few days now and see if the readiness settles. Last I checked it was 40, SAI and Oxygen sensor.

Not far away from where I live there have been some massive snowfall, almost 2' in 24hrs :D

Even though I'm not involved, thanks for all the work put in guys, hopefully you're near the end. I've read through this thread multiple times and check it daily to hopefully implement this in my car when its done, but that may take a while since questions are a no-no.

Questions are fine, just don't expect someone to spoon-feed you all the locations like is being done now on the first car during testing.

I understand. So the way I see it is the only way to find where those other constants are is to dissasemble the file? Since this routine is present in all ME7.x files, is it possible for a program to be made that searches out only this routine in other bins? Kind of like findmap that is here on the forums? I have little programming experience beyond my high school java course, so excuse me if this is a dumb question.

It is possible to make a tool, but it is likely there are slight differences in the routines, and you will need to disassemble the file anyway.

Update:

My readiness after a couple of days got down to 32, which is Oxygen sensor. I have verified which logs it is stuck on post cat testing cycle, I have this one in a spacer and im not too worried about it, I cannot find anything in the FR that relates this to the pressure scaling so im probably just going to code it out. Odd thing is it always did pass readiness before this project, must be a coincidence I guess.

However im not sane anymore with my cold start idle, sometimes it goes up and idles at 1200 as it always has, sometime it just goes directly to 900rpm which is my set warm idle rpm? I have to go through this one more time, this isnt really a problem but im pretty OCD about stuff like this and I want the car to run as it is supposed to. One more thing that kills me, is that the %BBKHZ cat heating module is missing in the the FR?

As time permits I will wrap up a .ols with my stock binary and a version with the 5120 hack along with the map definitions for those maps/constants and the updated list of changes. I will upload this in a new thread dedicated to this, and keep the first page updated as we go and more files floats up, thoughts?

What have you got at address 0x181C0?

CWSLS = 1

You can find the BBKHZ module in the Alfa FR.

/bow

I think I have found something, look at my attchment, fho_w should not do that according to my understanding. I believe it flips to FHOE and hence the curve from the low pass filter.

I have a new file going in tomorrow to try something out.

Any chance of you uploading the stock and final file yet so I can see all that was changed?
Cheers :-)

You can see everything I have changed documented in this very thread  ::)

I will put up a .ols when I have figured out why my KH is acting up, I dont want to upload a file when I know something is wrong with it. The info needed is in here for the ones wanting to do work on this, I hope this is understandable.

Also, being holidays now im trying to spend time with my two boys and not have my mind in the Funktionsrahmen constantly, thats what I have a regular daytime job for ;D

I actually wanted to see what was changed at the code level to make it easier to move it over to an M-Box ;-)
If you could post your original bin some time you get a chance that will be all I need, I can't seem to find it!

Actually, once we get some ps_w headroom, do you forsee any problems with not underscaling load? Is it ok to just let the load cap out, assuming we don't care to use anything but the end of the maps?

Or are there other issues with having a load maxed out?

If we have to start all over again and rescale *load*... well.. i think that will be quite a bit more work than the ps effort...

There is no cap on load. Only issue will be the 8 bit maps where anything higher than 255 will be 255.

The input to KFKHFM and KFZW (for example) appears to be the 8 bit load, which maxes at 255*.75 = 191.25

No such problem with KFZW if you use proper software.
And I don't see why you would want to adjust KFKHFM over 190+ load anyway.

Either way, it's not a really big deal, it can be just changed to 16 bit if needed for some reason.

I have already worked out 16 bit load axis for KFZW. Not a big deal.

Others can be done on a case by case basis.

This is not needed on 2.7TT, it's enough to use K-box, where it's already done.

It is the same really. The same code used in the K-box is available in the M-box.

There are way less changes required to use 16 bit load axis' in the M box then there is to use an RS4 binary on an S4.

It is literally a few bytes and otherwise all OEM code.

A S4 will never ever hit ps_w cap in stock form.
And if you are boosting 1.5+ bar then you already will benefit from starting with the RS4 file...

I get your point though.

Care to share the M-Box changes :-D ?

When I get the time and a car to test on

Feel free to take a drive up to State College and we can test all you want on my single turbo setup :-P

Alrighty, back from holidays and stuffing my mouth way beyond application sufficient. Lets get this bitch done.

Did some logging, since before the vacations I did isolate the interminent KH(cat heating) to react on how long between I turned ignition on, and then started the car(or ECU boot and b_stend). I have attached a screen showing one log of turnkey start, ignition and start in one motion > start logging, which takes a few seconds to connect. The other log is ignition on > start logging > start engine at the first log "tick". The latter gets KH, first one is not, and this is consistent.

Went back in the Alfa FR looking at %BBKHZ(thanks prj for the heads up) for any clues, found FHOKH, which is a altitude threshold for KH init flag b_kh. Stock value is 0.74 fho_w, anything below at start kills b_kh.

A page back I posted a graph showing what I believe is a funky fho_w, it does curve up from 0(?) to actual. fho is filtered through a low pass(pu_w is also filtered through the "same" low pass, but does not produce that curve on boot??), but I dont feel like it should behave like that and I have a feeling this has to do with the ATM division you guys helped me with to get the fho_w back to sane?

I did try to double the time on the low pass(ZDSU), from 3sec to 12sec, this made the curve much shorter(duh) but still not short enough to get under 0.74 and enable b_kh. This is pure theory though as I cant log the ECU before I boot it, I can just compare the remaining of curve when the logger starts to read.

Anyway, for now I have a new file with FHOKH killed, putting value to 0. Possibly going in for logging this weekend, latest on monday. If that does "cure" the problem we know where is to look at least.

Thank you for a great forum, really.

Yeah, the RPM funkyness on the first log, is me backing out of the garage :P

In all seriousness... If I was to drive down to Philly on a weekend would you be game for working on M-Box conversion and testing of this? :-)

Why dont you do the work yourself?

Im sorry for being an ass now, I really am, but this is a pretty damn time consuming hack to do and I bit my lip the last time you asked for someone else to do the work for you. Even with the list I made and posted, you still need to find an assload of random maps through out the binary to make it happen.

All the info is there and my stock binary is in the archive. If this was something easy to do you would see alot more members on here posting about theyre progress. If you want this so bad, you can make it happen.

Hey man,

I don't think you're being an ass... an it certainly is time consuming, that's the only reason I haven't done it yet is because I haven't had much time to work on it...
And I certainly wasn't asking for someone to do it for me... just anything that would cut down on the time it would take.
Can you point me in the direction of your stock binary please? For some reason I couldn't find it... maybe I was looking for the wrong thing...

Anyway one of the reasons I suggested a get together and tweak was because of some of the other ideas for tweaks and features that I have... very sorry if it came over as me being a lazy asshole because that is far from what I meant to do.

I've been too busy working on the car (Build thread on AZ http://www.audizine.com/forum/showthread.php/505784-My-first-Audi-2001-5-S4-with-Custom-Single-Turbo-setup) and working at work to mess with the decompile yet...

Speaking from experience, it is a lot more work to rigorously *document* a coherent, unified, generalized, correct list of changes (that anybody can read and implement) than it is to hack together a bunch of stuff by memory and voodoo.

That said, you might find that making such a list helps your project along... and forcing yourself to do so also exposes flaws in your approach and reasoning, and often exposes mistakes.

People generally pretend they don't want to do this because they think it is giving a handout. They're wrong, imo. If you can't explain something such that anybody can understand and use it, you likely don't understand it 100% yourself :)

Yes, it is a lot of work. Nobody likes documenting what they do.. its no fun, its time consuming, and it almost always delays project completion.

And as far as noob questions go; you know you are DONE when nobody asks you questions anymore. As long as there is somebody asking, you know your documentation is incomplete. Which is another side benefit of an exhaustive, general explanation: it cuts out 99% of the questions.

Just my two cents.

Alright, but if you dont have the time to tackle such additional project, you will be better off putting this on hold until you can free up some time for it.

I skimmed through your build, an from what I can see you have plenty of other parts of your tune to rectify before doing the 5120 hack. Dont get me wrong here, but if you was to start implement this at your current state, you would only add soo many more potentional problems. Start tuning your first boost PID with ALL the pressures scaled is just asking for trouble.

And, running at 18psi, you still have like 4psi left in there before youre hitting any caps. I dont have much experience with tuning a 2.7t, but at ~22psi I know it will output an assload of power even on pump gas, at least enough for other things around to start breaking down..

If I were you I would shoot for 22ish and get it running 100%, verify it runs good. And then with dedicated time, start to take steps get the most out of it. Hell, thats just my 2cents, do as you please - the info is there. My ECU number is 8E0909518M.


I 100% agree on all you said.

Even if I was to do such extensive project on my own and not planning to post it, I would still write down what I did, just for the reasons you mention. My first "documentation" (hand written in swedish/german, I write bad as fuck) was not looking anything like the proper list I posted, if I was not to write a clean version of it, LOL no one would have understood it [:D]

I dont mind documenting, though I agree its not fun since it steals potential progress, but I have at least gone back to my own notes 50times+ to back check. Without having it documented, one would need to trace those damn diagrams AGAIN just to refresh their mind for that specific reasoning/logic behind a change. I can with ease say I have saved time for myself during this project, due to documentation.


Update:

I can verify it is fho_w that kills b_kh, via FHOKH. Flashed the car today with FHOKH = 0 and I have cold started the car 3 times, turnkey one motion, all with KH :)

I am attaching a graph from todays log, and i will start wroking on the .ols to post up.

You are 100% in line with my plan. I'm not going to do the map hack until I'm running 100% at 22psi.
I just like to plan ahead ;-)

Thanks for all your hard work for the community!

Easier said than done. 18 is easy, 22, not so much. The PID needs at least 4-5 psi headroom to work properly w/o resorting to WGDC capping games.


Start with 21-20 psi :)

22psi spike is fine, but for 100% PID control you have to be below 21.

This is very true. Without headroom a pid system will be out of control. So I will be needing it soon...
I deal with closed loop pid systems at work all the time. We build CNC controls and machines...

I'm actually the PID and drive tuning guru at work lol

So if I made sense of this correctly I should be able to update the tables on the first page of this thread and still run my stock 2.5 bar map sensor but all the readings should be half of what they actually are until DSLGRAD and DSLOFS are scaled correctly and larger map sensor is installed.

Refer to the 5120 thread at the top of this section :-)

After posting I noticed this should have been in there instead Whoops  :-[