Yes, every software should be modified from the scratch. But I'm talking about approach. Like getting uhfm and then translate into ps_w_raw value by dslofs and dslgrad. And then filtering raw value by LowpassT or something like this. Also dpsfg_w and psfg_w values should be calculated somehow.
So there was community 5120hack project. Yes there were some holes in process. But main idea with the most problem areas were discussed.
You need to do more FR reading. dpsfg_w is the one that is important. psfg_w gets calculated from that via integrator KISRM.
So:
1. Acquire the uhfm - well the ECU does that for you in 1ms raster and places it into a variable. Good.
2. Add a filter map and insert lookup to it in some slow-ish raster, like 10-100ms. I used simple multiplication and nmot_w x rl_w map. I hijacked fvisrm for this, because it's not used anymore. A good scaling is to have e.g. 65535 as pass through value, then you can just right shift result 16, or just take the high bits after 16x16 mult.
3. Modify place where dpsfg_w gets calculated (this is done in synchro-raster) and instead of doing the MAF calculation:
a) Take the raw uhfm_w, convert to pressure via some added constants (I called them DSMGRAD and DSMOFS).
b) Subtract psfg_w from this (you get new dpsfg, pre-filter).
c) Apply filter by multiplying the result by filter value (hijacked fvisrm in my case), this limits the rate of change and gets rid of the extensive jitter. Remember that because it's in synchroraster your filter value needs to decrease with RPM to have same result.
d) Assign result to dpfsg_w.
4) Modify DHFM diagnosis to check for valid pressure sensor readings instead, and make it trip error code, so if your MAP sensor craps out you can still switch to alpha/n.
5) Tie up loose ends. There are some places that use mshfm_w and you need to change those to use msdk_w.
It's a lot of work tbh. This list should help you implement.
But doing it for any bin - it's like a full time job. Even if somebody posts the bin, I think you will spend longer time reversing what is done instead of just writing yourself.
For simpler code writing I recommend using Keil uVision, assembling it to .H86 and then using hex2bin on .H86 file. Then you can use macros and labels, especially for bounds checking.
And once that's all done, now you need to really UNDERSTAND how the ME7 speed-density model works.
This means that it actually really matters what you have in KFURL, KFPRG and KFPBRK.
Because if you have garbage in there then your load will be completely wrong, even in so far that the car will not even stay running.
With a MAF it's irrelevant what you have there because it only uses it to calculate ps_w, and then uses inverse to get back to rl. Thus it makes no difference on load.
This took me few hours on dyno to dial in, and I knew exactly what I was doing. If you don't know what you're doing good luck.
And finally you will have to tweak ESUK, because MAP sensor is much slower than MAF at reading air and you will need more aggressive enrichment.
Even when people bought the SD solution from me, some never got it to work, because they did not have enough knowledge to tune the VE model.
Could I post code? Probably.
Would it be of any use to anyone except to someone using the exact binary the code is posted for? No
Would it be of any use to the average "tuner", who has no clue how the VE system works? No - they never calibrated it and they won't even get the car to start on SD if it's significantly modified from stock.
I posted full custom boost pid for NA ME7 with all the code, I doubt anyone ever used it.
