|
Title: True ME7.5 Speed Density Post by: noice on April 13, 2020, 01:33:13 PM Hello mah dudes, trying to staying sane during all this shit that is going on right now I decided to revisit a project that I always wanted to see running: True VAG ME7.5 speed density. The simplest way for this, is to read the pressure into the intake manifold and write it to ps_w.
First thing: Yeah, I have a MAP in the intake. The shitbox I am working on is a 2001 S3 8L with a HKS2835 (GT3071R with a T2 housing) and I am using the 8N0906018AH/360322 software. I will be using the rear 02 sensor for interfacing with the MAP. I will post all the development I did so far for you guys to criticize, none of this software had been tested on a running engine, but everything works fine on the bench. Attached to this post are the modified bin and a damos for this software version. So, we need to read the voltage from the ADC pin, filter this shit, converter it to a pressure value and write it to ps_w. Luckily, Bosch already did most part of the hard work for us in the code of GGDSAS, so I will just copy and paste some shit that I know that works and modify it a little bit. The function located @8A1C00 converts and filters the signal. The original Bosch function is @8618F8. Call @861A44. The function @8A1B70 initialize the values when the ECU is started. Call @861874. For reading the ADC, the function located @8A1A94 is used. Call @822A68. The function @8A1B00 is needed to zero the accumulator. Call @822920. For copying the values to ps_w, I modified the bgsrm-bps function in the original code. We also need to calculate dpsfg_w if we want to keep BGRLP enabled. I also modified the call to bgsrm-bps (located @822920) to land at the right place. I am currently waiting for some parts to make my shitbox run again, as soon as they arrive, I will test this file on the car. If someone want to port it to the 2.7t bin to speed up the development, I will gladly help. However, I will not spoon-feed you. Title: Re: True ME7.5 Speed Density Post by: nyet on April 13, 2020, 02:09:26 PM Thanks for this, and thanks for titling the thread "speed density" and not "MAFless".
Title: Re: True ME7.5 Speed Density Post by: fknbrkn on April 13, 2020, 02:28:11 PM Thanks for this, and thanks for titling the thread "speed density" and not "MAFless". Why are you so triggered with the mafless word? :DTitle: Re: True ME7.5 Speed Density Post by: Gonzo on April 13, 2020, 04:26:47 PM Thanks for this, and thanks for titling the thread "speed density" and not "MAFless". I am going to type MAFless just so when people search for MAFless, this thread comes up. I would never use the word MAFless to annoy anyone, I swear.Title: Re: True ME7.5 Speed Density Post by: adam- on April 14, 2020, 01:16:14 AM Fuckin' mint!
Title: Re: True ME7.5 Speed Density Post by: prj on April 14, 2020, 08:14:26 AM Filtering needs to be a 3d map with high delta breakout from it.
Sampling needs to be crank sync due to pulsations... And some other things. I guess you'll get there when you actually try. Title: Re: True ME7.5 Speed Density Post by: noice on April 14, 2020, 02:20:35 PM Filtering needs to be a 3d map with high delta breakout from it. Sampling needs to be crank sync due to pulsations... And some other things. I guess you'll get there when you actually try. I wrote this code a long time ago and never figured out how to make it sample cranck sync. Today I realized that it was simples than ever: ps_w calculation is already running in the sync raster, so if I sample the ADC at this point, its done. Is it simple as that or am I overlooking something? Title: Re: True ME7.5 Speed Density Post by: noice on April 15, 2020, 06:07:14 PM Figured how to read the ADC whenever I want (if channel injection mode is enabled):
Code: seg003:000A1CB2 bclr ADCRQ #7000h is the ADC channel that i am interested, F0A0 is the ADDAT2 register and FA54 is free RAM. I already wrote an attempt to read the MAP synchronous, I think I can make my car runs tomorrow for testing this. Title: Re: True ME7.5 Speed Density Post by: noice on April 15, 2020, 06:11:13 PM Forget to mention: The conversion time is under 5μs, so we shouldn't have problems waiting for the ADC with that jnb instruction, but if necessary, I (think I) have solution for this.
For filtering, I think a simple lowpass filter will be enough. I mean, its good for the MS6, so... Title: Re: True ME7.5 Speed Density Post by: prj on April 16, 2020, 05:08:14 AM It's not good enough, unless you want to spend half your life re-tuning ESUK from scratch.
Also, because it runs crank-sync the rate of you filtering depends on RPM... Title: Re: True ME7.5 Speed Density Post by: woj on April 16, 2020, 11:39:47 AM Couple of cents from me. First, can't you really find a spare ADC input on your ECU? On my ME7.9.10 I found and tested one spare linear ADC 0-5V channel connected to the "outside", and two with bias resistors for temperature sensors (yes, I know these are pretty much useless for MAP).
Pulsations - I never actually studied how my factory speed-density ECU samples the MAP sensor, not too difficult to look it up though. And in all other ECUs I worked with I did not pay attention either, just assumed it's done right, but... on my previous car the MAP sensor was mounted external to the manifold and had a physical dumper on the vacuum / boost connection line. I experimented with removing that dumper a couple of times, and there were clearly differences in the signal that the ECU was receiving. So perhaps, just perhaps, there could be a physical solution in your case? Title: Re: True ME7.5 Speed Density Post by: noice on April 16, 2020, 04:03:37 PM It's not good enough, unless you want to spend half your life re-tuning ESUK from scratch. Good info. Do you mind sharing your filter implementation? Not asking for the code or anything like that, only a simple model or even type of filter. Also, because it runs crank-sync the rate of you filtering depends on RPM... Yes, its is linear dependent with nmot. We can calculate it very easily on the fly using a cte or even use a 2D lookup for being capable of tunning the "center" of it. Title: Re: True ME7.5 Speed Density Post by: noice on April 16, 2020, 04:07:41 PM Couple of cents from me. First, can't you really find a spare ADC input on your ECU? On my ME7.9.10 I found and tested one spare linear ADC 0-5V channel connected to the "outside", and two with bias resistors for temperature sensors (yes, I know these are pretty much useless for MAP). There is probably a spare port on the ECU, but there is no difference in doing this, only extra work. Pulsations - I never actually studied how my factory speed-density ECU samples the MAP sensor, not too difficult to look it up though. And in all other ECUs I worked with I did not pay attention either, just assumed it's done right, but... on my previous car the MAP sensor was mounted external to the manifold and had a physical dumper on the vacuum / boost connection line. I experimented with removing that dumper a couple of times, and there were clearly differences in the signal that the ECU was receiving. So perhaps, just perhaps, there could be a physical solution in your case? Can you post the disassembly of the ADC been read and the filtering process? Can you post your bin? Do you have a DAMOS/A2L for it? ;D Title: Re: True ME7.5 Speed Density Post by: prj on April 17, 2020, 08:52:50 AM Couple of cents from me. First, can't you really find a spare ADC input on your ECU? Why would you need a spare ADC when the MAF ADC is perfectly good to use?Rear o2 sensor is pretty dumb too. Title: Re: True ME7.5 Speed Density Post by: noice on April 17, 2020, 11:22:52 AM Why would you need a spare ADC when the MAF ADC is perfectly good to use? Rear o2 sensor is pretty dumb too. Why dumb if the original loom reach the sensor and have the same pin as the new connector? Just need to repin a single wire in the ECU connector for supplying 5V and its all good to go. Title: Re: True ME7.5 Speed Density Post by: woj on April 17, 2020, 12:10:02 PM The free ADC - I missed the obvious MAF input, I admit. Still, quite useful to be able to keep it running for testing the MAP based development.
O2 input, not sure about ME that has a 10bit ADC, but IIRC there were older ECUs that had a voltage amplifier on O2 input to improve the signal resolution. I can't say for sure how is the ADC channel sampling done, the code is a bit contrived, I am tired, and nobody is paying me for this, but... the actual ADC sampling is done somewhere in the "depths" of the ECU along with all other channels. The value copying to udss variable (pure MAP voltage signal) seems to be done crank synced (not 100% sure), what I noticed it happens together with the bunch of procedures, where one of them is the one that uses "TRD - Tooth period time for reverse rotation during stop" parameter on my ECU if that helps you locating the right procedure vector on your ECU. But, I did not really commit to verifying this, and have no idea what TRD is for, could as well be I found something totally unrelated. For filtering - I see n-last values averaging when converting udss into pdss (or whatever it is properly called), but I have to look at it again to be sure and get the exact figures. EDIT: OK, the averaging seems to be on the number of reads of udss snapshots that happened since the last crank sync, which makes me suspicious of when is the udss read from ADC that I just described above, could it be tooth sync instead?... Title: Re: True ME7.5 Speed Density Post by: prj on April 17, 2020, 12:47:47 PM Why dumb if the original loom reach the sensor and have the same pin as the new connector? Just need to repin a single wire in the ECU connector for supplying 5V and its all good to go. Because you're replacing the MAF, so the only thing that it makes sense to use is the MAF wires.Simply extending them and changing the connector, which costs peanuts is nothing. Another thing - NA cars have IAT in the MAF (which when converted to turbo and SD is still needed). Anyway you do how you want it, but MAF ADC is the only reasonable option, because it's how it's done from the factory - everything else IS really dumb. That said, changing the ADC channel is super is easy. So if you want to make a huge hack then go on, use the rear o2. O2 input, not sure about ME that has a 10bit ADC, but IIRC there were older ECUs that had a voltage amplifier on O2 input to improve the signal resolution. It's a normal 0-5V input like any other on ME7.Title: Re: True ME7.5 Speed Density Post by: noice on April 17, 2020, 01:22:33 PM The free ADC - I missed the obvious MAF input, I admit. Still, quite useful to be able to keep it running for testing the MAP based development. O2 input, not sure about ME that has a 10bit ADC, but IIRC there were older ECUs that had a voltage amplifier on O2 input to improve the signal resolution. Rear O2 is direct connected to the ADC. This works, it is already wired up and tested. I can't say for sure how is the ADC channel sampling done, the code is a bit contrived, I am tired, and nobody is paying me for this, but... the actual ADC sampling is done somewhere in the "depths" of the ECU along with all other channels. The value copying to udss variable (pure MAP voltage signal) seems to be done crank synced (not 100% sure), what I noticed it happens together with the bunch of procedures, where one of them is the one that uses "TRD - Tooth period time for reverse rotation during stop" parameter on my ECU if that helps you locating the right procedure vector on your ECU. But, I did not really commit to verifying this, and have no idea what TRD is for, could as well be I found something totally unrelated. For filtering - I see n-last values averaging when converting udss into pdss (or whatever it is properly called), but I have to look at it again to be sure and get the exact figures. EDIT: OK, the averaging seems to be on the number of reads of udss snapshots that happened since the last crank sync, which makes me suspicious of when is the udss read from ADC that I just described above, could it be tooth sync instead?... If this is correct, the sampling is not running crank-synchronous. Can you post your original bin? Because you're replacing the MAF, so the only thing that it makes sense to use is the MAF wires. You are missing one point: My code doesn't work yet. So why remove my MAF for something that not even works yet? Changing the ADC channel later on is as simples as changing 2 bytes. Another thing - NA cars have IAT in the MAF (which when converted to turbo and SD is still needed). Anyway you do how you want it, but MAF ADC is the only reasonable option, because it's how it's done from the factory - everything else IS really dumb. That said, changing the ADC channel is super is easy. So if you want to make a huge hack then go on, use the rear o2. This is not a professional solution, my dude. I am not a "pro tunner". I am only a bored engineer with some knowledge in ASM. Title: Re: True ME7.5 Speed Density Post by: woj on April 17, 2020, 01:34:56 PM If this is correct, the sampling is not running crank-synchronous. Can you post your original bin? Not sure it is correct, but prj has not yet implied I am idiot ;), so it could be. From what I saw, raw ADC channels are sampled collectively, "quite often" (an engineering term for you ;). The most recent data collection seems to happen at every crank wheel tooth, and at every crank rotation it is averaged to get a reading for the inlet pressure variable. This makes sense to me at least, regardless of engine speed, you get consistent results for the whole engine rotation cycle. Bin attached. Title: Re: True ME7.5 Speed Density Post by: prj on April 21, 2020, 10:56:03 AM This is not a professional solution, my dude. I am not a "pro tunner". I am only a bored engineer with some knowledge in ASM. You already know more than most so called "pro tuners" who can only shift boxes left to right in winols. Trust me. Sampling isn't crank-sync, evaluation of samples and filtering is. It's not important to get it that super right - sampling is done every 1ms, as long as you get the sample more or less roughly at the same time each time for each cylinder/cycle then it'll be more or less the same signal. Title: Re: True ME7.5 Speed Density Post by: Blazius on April 21, 2020, 12:59:22 PM Also a thing. NA 1.8 (of this platform) specifically does NOT have the standalone IAT in the MAF sensor, but separate just like 1.8T.
Title: Re: True ME7.5 Speed Density Post by: prj on April 21, 2020, 01:31:01 PM Also a thing. NA 1.8 (of this platform) specifically does NOT have the standalone IAT in the MAF sensor, but separate just like 1.8T. Which is irrelevant, because no one with a 1.8 NA will ever need this.Everything that is worth turbocharging has IAT in MAF. Title: Re: True ME7.5 Speed Density Post by: woj on April 22, 2020, 04:41:34 AM sampling is done every 1ms So that is what I was seeing... ;) Indeed, every crank wheel tooth, though technically possible, seemed a bit too optimistic. Title: Re: True ME7.5 Speed Density Post by: DT on April 22, 2020, 10:19:08 AM ------
C16x specs, minimum conversion time is like ~8us @25MHz which is enough time to handle ADC every tooth. But as prj said above the correct interval is 1ms. Apology to woj further down the thread. Title: Re: True ME7.5 Speed Density Post by: woj on April 22, 2020, 11:35:49 AM So where is the flaw in my calculations then? Assumption 60 tooth crank wheel. One engine rotation at 7500rpm:
60sec * 1000 ms = 60000 ms 60000 / 7500 = 8 ms duration of one engine rotation 8 ms = 8000 us Divide that by 60 you get ~133 us. How did you come up with 2us??? Title: Re: True ME7.5 Speed Density Post by: noice on April 22, 2020, 04:16:37 PM You already know more than most so called "pro tuners" who can only shift boxes left to right in winols. Trust me. Sampling isn't crank-sync, evaluation of samples and filtering is. It's not important to get it that super right - sampling is done every 1ms, as long as you get the sample more or less roughly at the same time each time for each cylinder/cycle then it'll be more or less the same signal. Nice, the code in the first post will work then. Just need to move the accumulator to the 1ms raster and move the V to P conversion to the sync raster. Also need to figure out how to filter the signal. So that is what I was seeing... ;) Indeed, every crank wheel tooth, though technically possible, seemed a bit too optimistic. There is only one entry in your bin that is relevant to track the ADC sampling timming, if your assumption was right, all ADC channels would be sampled at every tooth. That is insane. Title: Re: True ME7.5 Speed Density Post by: DT on April 22, 2020, 04:18:10 PM So where is the flaw in my calculations then? Assumption 60 tooth crank wheel. One engine rotation at 7500rpm: :) Sorry woj, I was a bit quick there. 2,2us was my result but didn't take the 60sec/min into consideration.60sec * 1000 ms = 60000 ms 60000 / 7500 = 8 ms duration of one engine rotation 8 ms = 8000 us Divide that by 60 you get ~133 us. How did you come up with 2us??? Title: Re: True ME7.5 Speed Density Post by: noice on May 08, 2020, 01:10:13 PM Had some drawbacks last weeks and couldn't spend much time on this.
Attached to this post is a revised file. There is basically two functions: This first one is a simple accumulator for the sensor voltage. It runs on the 1ms raster. Bosch original code was used to read the ADC, only changing the target RAM address. Code: seg003:000A1D00 umap_acu: ; CODE XREF: Raster_1ms+1C The main function is above. It will take the mean of all readings and convert it to pressure. Than it will filter the signal using a lowpass filter with a variable factor for compensating the variable sample rate. Don't know if this will work, but I implemented this in 5 minutes, so I think its worth trying. After that dspfg_w is calculated and the map value is limited by psmx_w before being write to ps_w. Function is called using the CALLS from bgsrm_bps in the sync raster. In the end, the function jumps to next instruction after ps_w calculation in bgsrm_bps. Code: seg003:000A1E00 SpeedDensity: ; CODE XREF: Raster_sync+50 I'm still waiting for parts for my car, so I couldn't test this file in a running engine, but everything works fine on the bench. Title: Re: True ME7.5 Speed Density Post by: golfputtputt on July 12, 2021, 04:49:05 AM How’d this end up working out?
Had some drawbacks last weeks and couldn't spend much time on this. Attached to this post is a revised file. There is basically two functions: This first one is a simple accumulator for the sensor voltage. It runs on the 1ms raster. Bosch original code was used to read the ADC, only changing the target RAM address. Code: seg003:000A1D00 umap_acu: ; CODE XREF: Raster_1ms+1C The main function is above. It will take the mean of all readings and convert it to pressure. Than it will filter the signal using a lowpass filter with a variable factor for compensating the variable sample rate. Don't know if this will work, but I implemented this in 5 minutes, so I think its worth trying. After that dspfg_w is calculated and the map value is limited by psmx_w before being write to ps_w. Function is called using the CALLS from bgsrm_bps in the sync raster. In the end, the function jumps to next instruction after ps_w calculation in bgsrm_bps. Code: seg003:000A1E00 SpeedDensity: ; CODE XREF: Raster_sync+50 I'm still waiting for parts for my car, so I couldn't test this file in a running engine, but everything works fine on the bench. Title: Re: True ME7.5 Speed Density Post by: Blazius on July 27, 2021, 02:19:56 PM So I have been looking at this recently and noticed a few things with the latest bin posted. If you crossflash this file it wont work out from the box. Some update or whatever would be nice but OP does not seem to check / reply on nefmoto for a while so anyway...
The ADC setup/ variable enable has been changed ofcourse, replaced uushk_w - rear O2 ADC voltage with a custom name for the MAP ADC voltage, set in IRAM ofcourse. A1D00 is again an accumulator for the voltage, works exactly like maf/ etc voltage ones, except with new free target ram. Now the main function... This references some maps that are simply not there in the bin, I am not sure if this was intentional or not but yeah. There is both a gradient and an offset, just like the boost sensor, I assume these should be setup exactly the boost sensor ones, from the looks of it. 17E10 and 17E12. After, there is 1D lookup with nmot. Map referenced at 17E14 also missing. Now how should this map look ? Bosch function ofcourse uses a 2d map nmot and psspvdkd_w its also maxed out on every value so yeah. So how should the filtering map look like? Title: Re: True ME7.5 Speed Density Post by: Blazius on July 29, 2021, 11:21:10 AM Like Bosch set the ratio/nmot time constant map for the lowpass to max values which is like 65553 seconds (1:1 hex, apparenrly cant find any factors) in transverse files but longitudinal file is like higher values on lower RPM and lower values for higher rpm.
However the ME7FR example works with values of 0.01 0.15 where 0.01 is filter off ofcourse, how does this make any sense? Also I am sure 5120 people are familiar with ZDSU which is a single value constant for the lowpass time input instead of being a map but its like 3 seconds but both of these calculations run in the same raster as per GGDSAS. Is it just that higher values = more filtering, lower values lower filtering and shouldnt be paying too much attentions to the numbers themselfs... So technically could just follow bosch and create the filtering map on max values but rather understand the logic behind it to actually have a nice value that will work properly with the fueling without issues. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 06, 2021, 07:00:43 AM The author unfortunately seems to abaddon development of this...
Title: Re: True ME7.5 Speed Density Post by: Blazius on August 06, 2021, 03:57:17 PM The author unfortunately seems to abaddon development of this... I described what you need to do basically to get this code implemented(mostly), so go on give it a whirl if you feel like it. Just because he stopped does not mean we all should... Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 19, 2021, 12:56:13 PM I've just tested the code. There is a bug in sample accumulator. Dont work properly, shows like 30% of value, sometimes 0. I think that one of registers is already used somewhere else. Lowpass filter works too slow, no matter I write into constant. Need to crank 10 seconds to get 900mbar at ps_w.
Title: Re: True ME7.5 Speed Density Post by: Blazius on August 19, 2021, 03:54:03 PM I've just tested the code. There is a bug in sample accumulator. Dont work properly, shows like 30% of value, sometimes 0. I think that one of registers is already used somewhere else. Lowpass filter works too slow, no matter I write into constant. Need to crank 10 seconds to get 900mbar at ps_w. Posted the modded bin. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 20, 2021, 07:18:31 AM Title: Re: True ME7.5 Speed Density Post by: Blazius on August 20, 2021, 09:05:50 AM Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 20, 2021, 03:49:36 PM Well, I can only see the one noice uploaded. Forgive me if Im blind. I've patched some code already, threw out accumulator for now, it seems to work ok. Unless we reach 4k rpm, then lowpass is not enough. Need to write my own accumulator. Is there any other variable we should care about except ps_w?
Title: Re: True ME7.5 Speed Density Post by: Blazius on August 21, 2021, 05:06:42 AM Well, I can only see the one noice uploaded. Forgive me if Im blind. I've patched some code already, threw out accumulator for now, it seems to work ok. Unless we reach 4k rpm, then lowpass is not enough. Need to write my own accumulator. Is there any other variable we should care about except ps_w? I mean post the modded bin that you created/modified? Did you crossflash his file? What MAP sensor are you using btw, how does your filter values look. Did you log the newly created ram locations etc? Not really if you can write to ps_w directly you got 99% sorted I think, you can sort the other expected inputs later on, and maybe add a diagnostic function which it currently lacks. You can also switch the 1d lookup to a 3d map but it should still be fine for testing. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 23, 2021, 09:48:41 AM I mean post the modded bin that you created/modified? Did you crossflash his file? What MAP sensor are you using btw, how does your filter values look. Did you log the newly created ram locations etc? I fixed the code noice written, then ported it to 032DKNot really if you can write to ps_w directly you got 99% sorted I think, you can sort the other expected inputs later on, and maybe add a diagnostic function which it currently lacks. You can also switch the 1d lookup to a 3d map but it should still be fine for testing. Ps_w seems not to be enough. Part throttle is screwed. It drives ok but the throttle can open/close for like 10% in a second.@edit It pulls timing first. MAP sensor signal is filtered corretly (deviation like 10-20mbar). STFT is <10%. Is this torque invervetion? @edit. I figured out that actual load is much higher than requested. Also there seems to be a delay between actual and requested load? (Requested is delayed). There must be load correction var that need to be calculated i think Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 23, 2021, 04:55:36 PM Cant edit again (lol) so gonna put another post. Just reflashed and plugged maf. Ps_w is measured corretly, no diffrence between this calculated with maf and measured by map. Actual load is ok, but there is problem with load request... Its too low
Title: Re: True ME7.5 Speed Density Post by: prj on August 24, 2021, 03:21:39 AM Because you can't just mindlessly assign pressure to ps_w, that will never work, that's also not how the ECU does with SY_DSS = 1.
Integrator needs to run, deltas need to be calculated etc. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 24, 2021, 10:09:41 AM Because you can't just mindlessly assign pressure to ps_w, that will never work, that's also not how the ECU does with SY_DSS = 1. Integrator needs to run, deltas need to be calculated etc. Ive currently calculated dpsfg_W and psfg_w. Still have to done psmx_w limitation. What FR mentions SY_DSS? I find no word about it in ME7 FR @edit I am idiot. I have A2L for this files (also for MAP based ME7). I didnt know that those files contain var adresses @editedit does the pirg_w play any role in engine without EGR? Will it be calculated properly without MAF? Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 26, 2021, 04:20:56 AM Ok, psfg_w was calculated wrong (only needed to assign it like ps_w). Idle is much better now. I see that when MAF dtc kicks in, load goes back to normal. Need to investigate deeper
Title: Re: True ME7.5 Speed Density Post by: prj on August 26, 2021, 04:24:21 AM You also need a 3d table with lowpass with a breakout limit or you will have massive jitter at high rpm and not enough response at low rpm.
MAF diagnostics can't fail unless sensor fails, good idea to add plausibility for it in code, or it will switch to msdk_w. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 26, 2021, 07:09:15 AM You also need a 3d table with lowpass with a breakout limit or you will have massive jitter at high rpm and not enough response at low rpm. MAF diagnostics can't fail unless sensor fails, good idea to add plausibility for it in code, or it will switch to msdk_w. Gonna add 3d map as soon as i get my load problem solved. This doesnt seem to be related with filter because it happens in every condition, even if signal is steady. Zero'ed pirg_w (dont know if it is good idea) but rl_w<65% is following rlsol now. When turbo spools rl_w ramps to twice rlsol... Until now I avoid MAF DTC maxing/zeroing maf flow diag maps. I see that rl_w is only calculated in BGSRM which is currently almost 1:1 ported from NA jetta. I think that something with rsol needs to be fixed? Or maybe throttle angle request is problem? Title: Re: True ME7.5 Speed Density Post by: Blazius on August 26, 2021, 10:04:17 AM Gonna add 3d map as soon as i get my load problem solved. This doesnt seem to be related with filter because it happens in every condition, even if signal is steady. Zero'ed pirg_w (dont know if it is good idea) but rl_w<65% is following rlsol now. When turbo spools rl_w ramps to twice rlsol... Until now I avoid MAF DTC maxing/zeroing maf flow diag maps. I see that rl_w is only calculated in BGSRM which is currently almost 1:1 ported from NA jetta. I think that something with rsol needs to be fixed? Or maybe throttle angle request is problem? Whats with the secrecy though? Care to post your mods? That is the point of this topic. Are you taking care of e_lm btw? i assume yes. Title: Re: True ME7.5 Speed Density Post by: prj on August 26, 2021, 10:44:53 AM Gonna add 3d map as soon as i get my load problem solved. This doesnt seem to be related with filter because it happens in every condition, even if signal is steady. Zero'ed pirg_w (dont know if it is good idea) but rl_w<65% is following rlsol now. When turbo spools rl_w ramps to twice rlsol... Until now I avoid MAF DTC maxing/zeroing maf flow diag maps. I see that rl_w is only calculated in BGSRM which is currently almost 1:1 ported from NA jetta. I think that something with rsol needs to be fixed? Or maybe throttle angle request is problem? Nothing right in this post at all. You got the basics wrong. Believe it or not some people still buy this solution from time to time, so I don't want to open source it yet :( Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 26, 2021, 12:42:51 PM Nothing right in this post at all. You got the basics wrong. Believe it or not some people still buy this solution from time to time, so I don't want to open source it yet :( E_lm and error classes did it, lol. Fueling and ignition is 1:1 to those with maf. Ill add 3d filter map to get signal even better, but its enough now. Everything works like oem. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 26, 2021, 01:08:33 PM Whats with the secrecy though? Care to post your mods? That is the point of this topic. Are you taking care of e_lm btw? i assume yes. Gonna test for few days. If everything is ok gonna post what needs to be changed, so any person with little asm knowledge could do it himself. Title: Re: True ME7.5 Speed Density Post by: Blazius on August 26, 2021, 01:40:58 PM E_lm and error classes did it, lol. Fueling and ignition is 1:1 to those with maf. Ill add 3d filter map to get signal even better, but its enough now. Everything works like oem. Lmao i wanted to ask it earlier but I assumed you did it.Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 26, 2021, 03:14:19 PM Lmao i wanted to ask it faster but I assumed you did it. Ok I got rid of CE and ESP light. Driven 50km so far. It seems that everything is working perfectly, my friend couldnt tell if he was driving SD or stock maf. But there seems to be needed some kind of 3d map like prj said with delta throttle x rpm on filter constant. @edit I thought about getting WB controller with voltage output wired in second o2 ADC. Then implement some kind of AFR control. What do you think about it? Title: Re: True ME7.5 Speed Density Post by: Blazius on August 27, 2021, 02:25:10 PM Ok I got rid of CE and ESP light. Driven 50km so far. It seems that everything is working perfectly, my friend couldnt tell if he was driving SD or stock maf. But there seems to be needed some kind of 3d map like prj said with delta throttle x rpm on filter constant. @edit I thought about getting WB controller with voltage output wired in second o2 ADC. Then implement some kind of AFR control. What do you think about it? 50km is good enough to get more people testing imo. AFR control? What do you mean, also ofcourse you changed uhfm_w to be your MAP voltage instead of the default second o2 adc then right. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 30, 2021, 02:59:32 PM Ok, so basicaly MAP signal seems to be too slow. Even if I het raw input from ADC. Dont know if this is just sensor issue or we need some kind of pressure prediction. Well, I have added some code to predict pressure in function of throttle gradient. But now car seems to statr for 2 seconds (idles perfectly, every var ok) but after 2 seconds it just cuts injection and dies. Dont know if there is some kind of watchdog (because of too long code execution) or I have some ram vars screwed up. Prj is there any kind of watchdog in our lovely ecu?
Title: Re: True ME7.5 Speed Density Post by: prj on August 31, 2021, 02:38:35 AM For me it's not too slow, so I guess we do something differently.
Calling map read functions from interrupt is just retarded. Look how OEM code is doing scheduling and do the same way. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on August 31, 2021, 03:56:52 AM Calling map read functions from interrupt is just retarded. I thought that can be problem. I will relocate it out of interrupt. For me it's not too slow, so I guess we do something differently. What MAP sensor do you use?Title: Re: True ME7.5 Speed Density Post by: jcsbanks on September 18, 2021, 05:08:50 AM I am curious about a historical perspective on Motronic re NA engines with MAF only and how it might inform MED17.
If you turbocharge, remove MAF, add MAP (and process it and make the code like SY_DSS instead of SY_HFM for writing psr_w etc), would it also be usual to add PUT so that the mass airflow calculations at the throttle work with boost? Title: Re: True ME7.5 Speed Density Post by: prj on September 18, 2021, 05:40:47 AM I am curious about a historical perspective on Motronic re NA engines with MAF only and how it might inform MED17. If you turbocharge, remove MAF, add MAP (and process it and make the code like SY_DSS instead of SY_HFM for writing psr_w etc), would it also be usual to add PUT so that the mass airflow calculations at the throttle work with boost? SY_TURBO has nothing to do with SY_DSS. They are two completely independent paths and there are all combinations possible and used. Title: Re: True ME7.5 Speed Density Post by: BlackT on April 10, 2022, 12:05:28 AM Maybe stupid question, but what MAP sensor you use if boost is over 3 bar absolute?
They all can't measure under 0.5 bar so how to calculate SD below that pressure? As far as I can remeber(in days when I have boost gauge) under idiling 1.8T get to 0.3-0.4bar Title: Re: True ME7.5 Speed Density Post by: prj on April 10, 2022, 12:37:15 AM Maybe stupid question, but what MAP sensor you use if boost is over 3 bar absolute? There are 3.5 bar sensors on BMW, which read low enough.They all can't measure under 0.5 bar so how to calculate SD below that pressure? As far as I can remeber(in days when I have boost gauge) under idiling 1.8T get to 0.3-0.4bar Then if you need more range, there are quite a few others as well, or you can take a normal 2.5 bar sensor, do some cutting and put for example a MPXH6400A inside, then epoxy it together - quite cheap solution and you get a P&P sensor. Title: Re: True ME7.5 Speed Density Post by: BlackT on April 10, 2022, 01:49:18 AM Thank you very much, will do that ;)
Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 10, 2022, 10:38:19 AM I backed to the speed density issue. I found out that map sensor signal isnt too slow. The VE model via KFURL was wrong. I corrected it at it worked really well, at least when the temperature outside was steady. It seems that me7 (hfm one) lacks of rl_w IAT correction when we inject ps_w direcly from map sensor. It result in rl_w to rl_sol overshoot when its hotter and undershoot when its colder. Ofc this map can be implemented without a problem but at this moment forcing maf me7 to speed density makes no sense.
Title: Re: True ME7.5 Speed Density Post by: nyet on April 10, 2022, 12:21:45 PM There is no speed density in ME7. Only alpha-n, end of story. Unless you are saying you implemented your own in ASM, including temp correction. You can also fiddle with the IAT parts of the ps/rl rl/ps paths. There are a few already there all in maps, but you'd have to modify the who ftbr stuff probably.
Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 10, 2022, 02:12:15 PM There is no speed density in ME7. Only alpha-n, end of story. Unless you are saying you implemented your own in ASM, including temp correction. You can also fiddle with the IAT parts of the ps/rl rl/ps paths. There are a few already there all in maps, but you'd have to modify the who ftbr stuff probably. Read my older posts please. I've already implemented reading ps_w from second map sensor in intake manifold. Rewrote part of BGRSM. Basically, he problem is that ps->rl conversion is made only using pirg_w, fpbrkds_w and fupsrl_w. There is IAT correction, so if you tune KFURL to rl meet your rlsol it its OK until conditions changes (IAT for example). I think that's because MAF sensor is including IAT factor itself. Prj didnt say a thing about it so I dont know if I do something wrong or what. Title: Re: True ME7.5 Speed Density Post by: nyet on April 10, 2022, 02:27:34 PM Understood. The stock ps/rl rl/ps conversion does, in fact, have IAT correction built in. Even though the MAF has IAT correction baked in, rlsol converts to pssol with IAT correction in ftbr, so inverse (ps to rl) should do the same, with "real" ps going into ps_w.
If it isn't, take a closer look at ftbr/fwft - there is a single fixed scaling in ASM (along with KFFWTBR and FWFTBRTA) which you can fiddle with. Title: Re: True ME7.5 Speed Density Post by: nyet on April 10, 2022, 02:52:18 PM Also maybe i have this wrong, but instead of feeding real a ps into ps_w, shouldn't you run real ps through vpsspls correction, then the ps->rl path via fupsrl to get a rl you can feed into rl_w directly? Unless i'm misunderstanding how people typically do speed density in ME7 (i've never done it personally, just have some ideas on the theory).
Sorry if i'm late to the party i confess i haven't fully been following the thread. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 10, 2022, 03:18:07 PM Also maybe i have this wrong, but instead of feeding real a ps into ps_w, shouldn't you run real ps through vpsspls correction, then the ps->rl path via fupsrl to get a rl you can feed into rl_w directly? Unless i'm misunderstanding how people typically do speed density in ME7 (i've never done it personally, just have some ideas on the theory). Sorry if i'm late to the party i confess i haven't fully been following the thread. In OEM Speed-density ME7 (2.5 NA) its directly written into psdss_w (which is written directly to ps_w). I have to investigate more how temp correction is done in that ECU. Thanks for the tip with ftbr. I see that in BGTEMPK there is a switch speeddensity/hfm for correction using KFFWTBR or KFWTBR. In hfm ECU (1.8t) its axis is rl, for dss ECU its axis is ps. I think thats the reason I lack temp correction @edit ftsr is used only when coverting rl->ps. That is the second reason I Think Title: Re: True ME7.5 Speed Density Post by: nyet on April 10, 2022, 03:43:21 PM In OEM Speed-density ME7 (2.5 NA) its directly written into psdss_w (which is written directly to ps_w) ah and rl then comes from ps_w instead of MAF/RPM, and then used for fueling? Or is rl never used for fueling decisions in speed density? Makes no sense to me. in any case, if ps_w is used to determine fueling, ps_w itself should not be temp corrected, something else needs to temp correct it to get an accurate air mass out of it, whether in speed density or not. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 10, 2022, 04:04:58 PM ah and rl then comes from ps_w instead of MAF/RPM, and then used for fueling? Or is rl never used for fueling decisions in speed density? Makes no sense to me. in any case, if ps_w is used to determine fueling, ps_w itself should not be temp corrected, something else needs to temp correct it to get an accurate air mass out of it, whether in speed density or not. I didn't dive that deep into it. I think that rl is used for fueling in 2.5. The problem I refer is that when IAT is 7 celcius ps_w on idle is 300mbar, when IAT is 40 celcius ps_w on idle is 400mbar. When I make rl meet rlsol using kfurl on 300mbar idle, rl is higher than in reality when its 400mbar As the result idle start oscillating and stft goes -%. I don't know whether it is also connected to tmot or not. If I don't find answer I will just add another map with factor for rl_w based on IAT/tmot and nmot Title: Re: True ME7.5 Speed Density Post by: prj on April 11, 2022, 04:08:39 AM There is already temperature correction according to ideal gas law.
Your problem is that your IAT sensor gets heatsoaked and reports wrong value on idle... Standard charge temp issue. Title: Re: True ME7.5 Speed Density Post by: BlackT on April 11, 2022, 05:26:10 AM Try to turn you TB for 90° IAT will be less heatsoaked
Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 11, 2022, 06:58:58 AM There is already temperature correction according to ideal gas law. Your problem is that your IAT sensor gets heatsoaked and reports wrong value on idle... Standard charge temp issue. Heatsoak on stock plastic-covered iat sensor? Is there a way to software deal with it? @edit prj can be right because I've just checked WOT runs logs and parameters are ok Title: Re: True ME7.5 Speed Density Post by: Blazius on April 11, 2022, 09:01:06 AM There is a Ford sensor that read 200-3000mbar btw with vacuum pipe connection, perfect for this conversion. Its what I have and doing stuff with.
Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 11, 2022, 09:44:30 AM There is a Ford sensor that read 200-3000mbar btw with vacuum pipe connection, perfect for this conversion. Its what I have and doing stuff with. Map sensor is not a problem. I have tries couple of vag sensors and all od them are fast enough. Main problem is iat heatsoaking on idle. I wonder how its done on mafless files with alpha-n. On the worst case ill make switch to make idle work alpha n and the rest on map Title: Re: True ME7.5 Speed Density Post by: prj on April 11, 2022, 10:12:21 AM Map sensor is not a problem. I have tries couple of vag sensors and all od them are fast enough. Main problem is iat heatsoaking on idle. I wonder how its done on mafless files with alpha-n. On the worst case ill make switch to make idle work alpha n and the rest on map Exactly the same problem on alpha/n.Been a while since I looked at ME7, I don't remember anymore how the charge temp modelling worked or how advanced it was. You either model the charge temp or hope that closed loop takes care of it. And btw no IAT correction map is going to solve your idle issues. The simplest charge temp model is a map where IAT and Coolant temp comes in and charge temp comes out. This charge temp is then additionally blended via flow and timers. The core issue is that there is not enough flow over the IAT sensor where it gets any reasonable reading. It starts reading the temperature of the pipe where it's in (so heat in engine bay) because not enough air flows over it to get a good reading. But tbh the majority of this issue can be solved in a primitive way by messing a little with TVUB - setting it a little too high and injector size (or rather FKKVS factor) a bit lower. Then when it gets heat soaked on idle, because of the slightly wrong TVUB it will not go that lean ... Sorry, not going to dig in FR for charge temp modelling. Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 11, 2022, 11:25:02 AM Exactly the same problem on alpha/n. Been a while since I looked at ME7, I don't remember anymore how the charge temp modelling worked or how advanced it was. You either model the charge temp or hope that closed loop takes care of it. And btw no IAT correction map is going to solve your idle issues. The simplest charge temp model is a map where IAT and Coolant temp comes in and charge temp comes out. This charge temp is then additionally blended via flow and timers. The core issue is that there is not enough flow over the IAT sensor where it gets any reasonable reading. It starts reading the temperature of the pipe where it's in (so heat in engine bay) because not enough air flows over it to get a good reading. But tbh the majority of this issue can be solved in a primitive way by messing a little with TVUB - setting it a little too high and injector size (or rather FKKVS factor) a bit lower. Then when it gets heat soaked on idle, because of the slightly wrong TVUB it will not go that lean ... Sorry, not going to dig in FR for charge temp modelling. In me7.5 i see that CWTEMPK is 1, so evtmod is used for ftbr and further for furl. Its input is tmot and tans to i think that some kind of temperature modeling is done. I will test different combinations od CWTEMPK. I wonder about lack od ftsr in ps_w measuring. I will try to relocate iat sensor too and check if it solves the problem Title: Re: True ME7.5 Speed Density Post by: nyet on April 11, 2022, 11:51:27 AM The core issue is that there is not enough flow over the IAT sensor where it gets any reasonable reading. It starts reading the temperature of the pipe where it's in (so heat in engine bay) because not enough air flows over it to get a good reading. Wow!!! I have always been suspicious of this because i've seen really wonky IAT values at idle. Thanks for confirming. Title: Re: True ME7.5 Speed Density Post by: Blazius on April 11, 2022, 12:03:15 PM Map sensor is not a problem. I have tries couple of vag sensors and all od them are fast enough. Main problem is iat heatsoaking on idle. I wonder how its done on mafless files with alpha-n. On the worst case ill make switch to make idle work alpha n and the rest on map Never said that, i mean its a good sensor to use if you wanna convert, no need to modify the intake manifold etc. Indeed they are fast enough, I am not sure where your earlier comments came from. Also not sure why you looking in the 2.5 files when literally 4 cylinder me 7.5 SD exists from Bosch exists, it is prolly a better match from what ive seen. If you do the bg module like them you will get everything baked in like they do oem. Which doesnt eliminate the heatsoak problem (on the 1.8 w stock mani), it literally exists from factory and I have seen it many times. Regardless the whole conversion will be miles better than running alpha n and stuff and the rest will be taken care of by closed loop and calibration from said data. Title: Re: True ME7.5 Speed Density Post by: BlackT on April 11, 2022, 12:22:07 PM Or use IAT from stock MAP. That could solve problem
Title: Re: True ME7.5 Speed Density Post by: kacperoooni on April 11, 2022, 02:27:13 PM Never said that, i mean its a good sensor to use if you wanna convert, no need to modify the intake manifold etc. Indeed they are fast enough, I am not sure where your earlier comments came from. Also not sure why you looking in the 2.5 files when literally 4 cylinder me 7.5 SD exists from Bosch exists, it is prolly a better match from what ive seen. If you do the bg module like them you will get everything baked in like they do oem. Which doesnt eliminate the heatsoak problem (on the 1.8 w stock mani), it literally exists from factory and I have seen it many times. Regardless the whole conversion will be miles better than running alpha n and stuff and the rest will be taken care of by closed loop and calibration from said data. Can you give more info about this 4 cyl SD ecu? Ecu number, motor ID, displacement, car model, anything? My speed density besides the heatsink problem work pretty well tbh Title: Re: True ME7.5 Speed Density Post by: _nameless on April 11, 2022, 03:47:47 PM Can you give more info about this 4 cyl SD ecu? Ecu number, motor ID, displacement, car model, anything? I have working sd code I'd be willing to share. Pm me if you want. My speed density besides the heatsink problem for pretty well tbh Title: Re: True ME7.5 Speed Density Post by: BlackT on April 12, 2022, 09:05:33 AM Is there map in ME7 for injector corection according to IAT?
Title: Re: True ME7.5 Speed Density Post by: Blazius on April 18, 2022, 09:17:47 AM Can you give more info about this 4 cyl SD ecu? Ecu number, motor ID, displacement, car model, anything? My speed density besides the heatsink problem work pretty well tbh 1.4 me7.5.10, you should have it already, pretty sure you said so yourself. Care to share your code? Title: Re: True ME7.5 Speed Density Post by: Blazius on October 27, 2022, 08:50:42 AM Bit quiet in here heh :) ?
So in the past couple days I actually basically finished my 'conversion' during my hardware and rebuild changes. I've been running on the file for a couple hundred KM's now and I cant observe or feel any weird things happening, logs looks good too from what I've seen Miles better than Alpha N obviously, fuel trims without ANY injector tuning(fkkvs and etc all 1's) are within 5%, I am pretty impressed. It's running on a 3 bar MAP on maf wiring with hose connection to the intake manifold (but any other MAP could be used if you mount it properly) making it suitable for easy conversion. (https://i.imgur.com/EpxOLgw.png) MapSensor is the new variable the pressure value from the MAP after conversion from voltage to pressure. The conversion/sampling currently takes place in a 1ms raster then ran through a single value lowpass filter. To do: - Error checking/ Revert to alpha N on sensor failure: Currently if the sensor fails meaning MapSensor= 0 the engine will stall as there is no revert to alpha N load calculation at the moment Extras: - Repurpose KFKHFM or create similar to create a correcte variable from sensor output , Bosch did it. - Change the filter to a map so that filtering can be done vs rpm and load or other variable as a bonus - Take samples at crank sync and average them to lower filter values if needed, however current system works fine as it for the accuracy range even without maxed filtering All in all I am happy it works and its miles ahead of alpha n and other weird stuff ;) Title: Re: True ME7.5 Speed Density Post by: prometey1982 on October 28, 2022, 09:55:49 AM Bit quiet in here heh :) ? HI. Can you share the code?So in the past couple days I actually basically finished my 'conversion' during my hardware and rebuild changes. I've been running on the file for a couple hundred KM's now and I cant observe or feel any weird things happening, logs looks good too from what I've seen Miles better than Alpha N obviously, fuel trims without ANY injector tuning(fkkvs and etc all 1's) are within 5%, I am pretty impressed. It's running on a 3 bar MAP on maf wiring with hose connection to the intake manifold (but any other MAP could be used if you mount it properly) making it suitable for easy conversion. (https://i.imgur.com/EpxOLgw.png) MapSensor is the new variable the pressure value from the MAP after conversion from voltage to pressure. The conversion/sampling currently takes place in a 1ms raster then ran through a single value lowpass filter. To do: - Error checking/ Revert to alpha N on sensor failure: Currently if the sensor fails meaning MapSensor= 0 the engine will stall as there is no revert to alpha N load calculation at the moment Extras: - Repurpose KFKHFM or create similar to create a correcte variable from sensor output , Bosch did it. - Change the filter to a map so that filtering can be done vs rpm and load or other variable as a bonus - Take samples at crank sync and average them to lower filter values if needed, however current system works fine as it for the accuracy range even without maxed filtering All in all I am happy it works and its miles ahead of alpha n and other weird stuff ;) Title: Re: True ME7.5 Speed Density Post by: vwnut8392 on October 28, 2022, 08:17:38 PM Bit quiet in here heh :) ? So in the past couple days I actually basically finished my 'conversion' during my hardware and rebuild changes. I've been running on the file for a couple hundred KM's now and I cant observe or feel any weird things happening, logs looks good too from what I've seen Miles better than Alpha N obviously, fuel trims without ANY injector tuning(fkkvs and etc all 1's) are within 5%, I am pretty impressed. It's running on a 3 bar MAP on maf wiring with hose connection to the intake manifold (but any other MAP could be used if you mount it properly) making it suitable for easy conversion. (https://i.imgur.com/EpxOLgw.png) MapSensor is the new variable the pressure value from the MAP after conversion from voltage to pressure. The conversion/sampling currently takes place in a 1ms raster then ran through a single value lowpass filter. To do: - Error checking/ Revert to alpha N on sensor failure: Currently if the sensor fails meaning MapSensor= 0 the engine will stall as there is no revert to alpha N load calculation at the moment Extras: - Repurpose KFKHFM or create similar to create a correcte variable from sensor output , Bosch did it. - Change the filter to a map so that filtering can be done vs rpm and load or other variable as a bonus - Take samples at crank sync and average them to lower filter values if needed, however current system works fine as it for the accuracy range even without maxed filtering All in all I am happy it works and its miles ahead of alpha n and other weird stuff ;) probably because no one is posting any BIN's is why its quiet. Title: Re: True ME7.5 Speed Density Post by: Blazius on October 30, 2022, 07:20:54 AM HI. Can you share the code? I would like to do some more testing before that, just waiting on one of my mates to finish his build too. But thinking about it what will that accomplish? The few people who can do this have probably already done this or similar thing (why do you think they havent posted it) and you think others can implement it properly instead of getting another launch control situation type stuff around the forums, even with proper instructions posted? It requires disassembly of any bin you want to implement it on, also changing stuff around Keil, building it then patching it in , creating the maps at the right adresses etc. I did say in the past I will most likely post it if it works ok so I will but... yeah... Also its not just about bins bins bins, there are plenty of bins posted already, people just dont follow up it seems. Title: Re: True ME7.5 Speed Density Post by: prometey1982 on October 30, 2022, 10:50:00 AM I would like to do some more testing before that, just waiting on one of my mates to finish his build too. 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. But thinking about it what will that accomplish? The few people who can do this have probably already done this or similar thing (why do you think they havent posted it) and you think others can implement it properly instead of getting another launch control situation type stuff around the forums, even with proper instructions posted? It requires disassembly of any bin you want to implement it on, also changing stuff around Keil, building it then patching it in , creating the maps at the right adresses etc. I did say in the past I will most likely post it if it works ok so I will but... yeah... Also its not just about bins bins bins, there are plenty of bins posted already, people just dont follow up it seems. So there was community 5120hack project. Yes there were some holes in process. But main idea with the most problem areas were discussed. Title: Re: True ME7.5 Speed Density Post by: prj on October 30, 2022, 12:42:45 PM 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. Title: Re: True ME7.5 Speed Density Post by: vwnut8392 on October 30, 2022, 03:56:09 PM I would like to do some more testing before that, just waiting on one of my mates to finish his build too. i was jsut saying in general. i dont drive or own anything ME7 personally, im just watching this because its interesting. yes i understand it involves disassembly to do this properly. any code modifications requires that. last ME7 car i owned i just ran the MAF in blow through configuration and hid it in the FMIC piping so no one could see it. i know most here would scream blasphemy with doing that and than fine a million ways to poke holes in doing it but that seems like what they do best here, look for the negative in what you do and than poke holes in it hoping it sinks just like the original author of this thread disappearing after criticism from certain users. But thinking about it what will that accomplish? The few people who can do this have probably already done this or similar thing (why do you think they havent posted it) and you think others can implement it properly instead of getting another launch control situation type stuff around the forums, even with proper instructions posted? It requires disassembly of any bin you want to implement it on, also changing stuff around Keil, building it then patching it in , creating the maps at the right adresses etc. I did say in the past I will most likely post it if it works ok so I will but... yeah... Also its not just about bins bins bins, there are plenty of bins posted already, people just dont follow up it seems. Looking at all the stuff required from PRJ's post above could some extra effort to dumb down the ECU and make it more pressure dependent and less load/torque dependent be possible? sort of like how standalone works. would be much simpler to configure if the user didnt have to worry about throwing off load calcuations because its obvious that touching certain things directly affect that. MAP pressure would be a more consistent value to base from since your using speed density anyway. i get it would be a lot of work to change all table axis's to be pressure manually but there are very smart and creative people here that could make a tool to do that in a few clicks. for example on KFZW your axis's load over RPM. if you mess something up load wise it throws the reading this table completely out. if the load axis was changed to be MAP pressure instead of load it would be a far more consistent axis and simple to calibrate. if im at this boost pressure and this RPM than my ignition angle is this intead of looking at it with load and realizing that your way out of whack and have to track backwards through a 100 different maps/constants in hopes of finding that one small error that wrecked the whole setup. i understand some of this as i use PRJ's old M2.3.2 speed density for old 5 cylinders which i can attest for works very well. i have not ever mentioned in public before but i have done some disassembly on that old motronic and did to it what i said above. this is for personal use only i did this conversion from load to pressure. like in M2.3.2 the change over from closed loop lambda control to what is essentially open loop MAF based or MAP based in SD code boost fueling is dictated by load. but when you mess with the VE table and other constants/multipliers for fueling you can easily throw the load way out of whack which will affect this tip over point among many other things. basically what i did to circumvent this was convert as much of it to pressure as i could. now instead of that change over being load based like factory it is now MAP pressure based so say if i want it to start fueling straight from the VE table at 10psi than i just tell it that via an added constant and it does it spot on every time. with how he did things he left some open room to do other stuff too like there was 3 linearization maps for MAF that where repurposed for VE table and IAT compensation tables leaving a third unused and not referenced. what i did was re-add that unused table and made it into a VE table subtractor at idle only because you always ended up with this pit in the corner of the VE table or ran out of room and had to mess with the VE constants which directly affect the load over all once again. this table is only referenced when the idle switch in the TPS is pressed and below 1200RPM. its fairly simple, all it does is take the VE table value, the added table value and it subtracts the added table value from the VE table. simple to calibrate idle fuel now. axis's are MAP pressure over RPM. MAP pressure axis mainly in negative values and ends at 0 vacuum where on the table the value is 0 meaning no change or straight through. idea for that came from how it controls idle ignition. only difference is idle ignition doesnt add or subtract from the main table, its only referenced when certain values are met like idle switch and below X RPM. I know im comparing apples to oranges here as ME7 is far more complex in comparison but have looked at some of the stuff like MAF in the ME7 FR vs how the MAF works in the M2.3.2 FR and ME7 has all the same basic functions and flow as M2.3.2 but ME7 has several other layers of complexity added to it and the final output of GGHFM is completely different from what the final output of GRUFU in M2.3.2 FR is. GGHFM's final output is a clean MAF signal. GRUFU's final output is the actual fuel injection or ti. Title: Re: True ME7.5 Speed Density Post by: prj on October 30, 2022, 06:14:23 PM You're not gonna do a stupid pressure based ECU on ME7 lol.
Nor is there any need for it. And M2.3.2 modifying my VE table there is no problem. If you modify the constants you just recalculate the whole table... I mean it's not that hard to correct (A+B)*C to amount to the same thing if you want to change one. Title: Re: True ME7.5 Speed Density Post by: _nameless on November 19, 2022, 07:08:49 AM Real sd me7.5 gtx2871 on pump gas 500cc wm vs mk8 golf r with dq381 trans tune and stage 1
https://youtube.com/shorts/uQYRrKtX9w8?feature=share Title: Re: True ME7.5 Speed Density Post by: kacperoooni on December 06, 2022, 06:30:57 PM 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. Thats why I left SD project, even if I got it to work pretty well, the amount of work to make it work was not worth using it instead of MAF sensor. Title: Re: True ME7.5 Speed Density Post by: fknbrkn on September 19, 2023, 02:35:03 AM 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. Sooo me7 commercially dead (or just not worth it), it would be nice to check SD code ::) Title: Re: True ME7.5 Speed Density Post by: prj on September 19, 2023, 02:54:30 AM Sooo me7 commercially dead (or just not worth it), it would be nice to check SD code ::) I'm making a file dump of all my cal shit, since I don't do cal anymore and couldn't care less if it gets copied around. It's not going to be free, but all that stuff will be on there. Title: Re: True ME7.5 Speed Density Post by: _nameless on September 19, 2023, 06:14:26 AM Sooo me7 commercially dead (or just not worth it), it would be nice to check SD code ::) Title: Re: True ME7.5 Speed Density Post by: fknbrkn on September 19, 2023, 09:29:32 AM Title: Re: True ME7.5 Speed Density Post by: adam- on October 30, 2023, 10:57:23 AM I'm making a file dump of all my cal shit, since I don't do cal anymore and couldn't care less if it gets copied around. Group buy?It's not going to be free, but all that stuff will be on there. Title: Re: True ME7.5 Speed Density Post by: sda2 on November 02, 2023, 01:14:21 PM I posted full custom boost pid for NA ME7 with all the code, I doubt anyone ever used it. We use it ported to MS43, thank you for that! Title: Re: True ME7.5 Speed Density Post by: prj on November 02, 2023, 02:09:44 PM We use it ported to MS43, thank you for that! Unexpected but good to hear that.Title: Re: True ME7.5 Speed Density Post by: tao13 on December 01, 2023, 10:35:05 AM DELETED post, i moved in other topic.
Title: Re: True ME7.5 Speed Density Post by: crackerx on December 02, 2023, 04:59:39 AM Title: Re: True ME7.5 Speed Density Post by: tao13 on August 21, 2024, 12:48:41 PM tn2fgr_w "Doppelte Nennerzeitkonstante FGR-Regler"
mrrgli_w "Initialisierungswert Relatives Moment fur FGR-Regler" must be modified for SD? |