Here http://www.dsmtuners.com/forums/tuni...#post151946058 Thomas Dorris from ECMTuning (DSMLink) says that there is airflow smoothing that has to be removed for SD to work great. Has that been done? Read that whole thread, some of it is pretty interesting, especially his posts. They have what sounds to be a really great SD setup in their newest version, so any knowledge he's willing to share would be good to take in.

 

Very interesting. A few pages back, John mentioned the airflow filtering/smoothing I believe. I would have to have mrfred or John look at that again to see if it may be causing an issue.

I had DSMLink in my DSM and I know Thomas Dorris has some awesome knowledge of the ECU. I can possibly run this by him (my issue with IPW), but I will hold off for now. I'm sure he is busy with his own stuff and doesn't want to mess with the Evo ECU just to help us out. But feel free to point him here for his input if you wish.

 

The MAF smoothing algorithm shouldn't have an effect on IPW like you are seeing. I think the best next step will be for you to duplicate your logs with the car back in MAF mode.

 

OK, I will do that today then. It's been a couple of weeks since I ran on MAF, so it will be a good test to make sure the spark plugs aren't getting fouled and misfiring.

One thing I took from that thread linked above is that Tom Dorris mentioned that they had SD setup with two tables like we have (map VE and RPM VE), but they eventually moved to a 3D table. I was thinking about that some too, because looking at my VE tables, there are some conditions that just can't be met with the two 2D tables. I'm pretty certain that isn't my issue, but just thinking ahead for future SD development and improvements.

 

I just flashed back to my non SD ROM and the issue is completely gone....I haven't analyzed my logs yet, but I was watching IPW during the drive and didn't see any dips/jumps nor did I feel any hesitation. I can post up some graphs of cruising through the same area if need be once I get to look at them. So, it has to be something related to the operation of SD. Unforunately, from my logs, I can't quite tell what it is.


Eric

 

There was a fair bit of discussion on this when jcsbanks was formulating his SD patch. Ultimately, the two 2D tables worked well for him and were less imposing to tune than a single 3D. However, it wouldn't be difficult to replace the two 2D tables with a single 3D table.

 

Here is a screenshot from the MAF log, showing a cruise right through the issue area while using the SD ROM:


Note the IPW is very smooth and tight. It only varies by one loggable step, rather than jumping between 2-4ms like with SD. This is the same exact range where the problem exists with SD.

So, I'm at a loss right now. Since I can't read the ROM code, I guess I have to wait until someone can figure it out (mrfred, jcsbanks, etc) or if anyone else has some input that we haven't thought of yet.

Hopefully we can get this figured out soon though, because I want to toss on my 4" Dejon intake and Amsoil 4090 filter. I could do it now, but I want to get this figured out first before committing to full time SD.


Eric

 

One thing that really makes the 2 2D maps not work well is having a small turbo at high boost (my setup). At 20psi or less, my HP (& VE) holds up very well in the higher RPM's; at higher boost, my HP (& VE) drops quite a bit after 6 grand. My logs verify this, as the AFR's are solid at low boost, but go very rich as the RPMs rise with the boost turned up. I really don't want to have to fudge the AFR map to keep my AFRs in line, but I may have to.

Having another 2D table would do the trick while keeping the SD system easy to tune (VE wise). Just have a second RPM vs VE table, which only fully takes effect at say, a little higher boost than you would ever actually run. As the boost rises, the RPM based VE would actually go between the two RPM vs VE tables.

 

Why not just use the map ve table to fix that? If your VE is lower with higher map, then you just need to use a couple bins at the higher map levels and adjust the VE.

But, in the long run, I think one 3D table would be the best. It may take longer to get everything in there and tuned properly, but it gives the best adjustment possibilities.

 

The airflow smoothing is already removed with the SD patch.

Can you or anyone else try this patched ROM with a JDM MAP sensor?

It is odd though that the correlation between the IPW spiking, the MAP sensor and load can't be seen as the SD patch is actually really simple in the variables it replaces, and I always thought if you could verify their behaviour that was the patch tested. I'm sure I would have noticed IPW spikes like this on mine as this was a daily driver area for me, I had continuous Pocket PC logging display on the dash and it was always as smooth as butter.

3d table is relatively easy to code, don't let my original plan be the model people necessarily stick to, it was just my preference. I think it will be a poisoned chalice though for most except for situations like jrohner.

 

John, gear head stated that he was using the JDM 3-bar with this same issue and he posted a log to show. That's why I sort of gave up on the OMNI 4bar being the culprit. Also, since my map 16bit varied by maybe 2kpa at most, it didn't seem to be an issue.

It may very well be the OMNI 4-bar, though, and I haven't ruled out anything 100% yet. Or it may simply be something particular to this ROM. I will just have to wait for more people to test the JDM 3-bar with this ROM. Or, I can swing by logic one day to test his JDM 3-bar, but I think he is about to test SD himself. Once we get a couple more people testing SD, we can have a more definitive answer.

Here's a quick question....Does SD in any way have anything to do with the map scaling tables that need to be changed to log boost on the US Evos? The table(s) that change the mdp scaling from the 1-bar to the 3-bar? This ROM doesn't have those tables at all sicne it didn't have a map/mdp sensor at all. I didn't think these tables had any effect, but I'm just throwing around ideas now.


Eric

 

In that case I'm out of ideas. I didn't do the 9653 SD conversion, so nothing I can debug, and with other projects I really can't get into this again.

It does puzzle me how replacing just two variables and logging them as smooth and correct can do this. Worth checking over everything again about how the conversion has been done?

 

What value are you using for the "MAP Comparison"?

 

Which table are you referring to? If you are talking about the tables I was asking about, I didn't touch any of those tables since I never heard of them existing on this ROM (I believe your 'log boost' thread mentioned it's a USDM only mod). At least to log boost on this ROM, nothing needs to be done at all. And maybe I was wrong to assume that nothing had to be done with those tables for the SD patch to work as well? I didn't think I saw anything posted for this ROM for those particular tables.

On a sidenote, got a bit sidetracked this weekend. I parked my car for 10 minutes in my old Chicago neighborhood, in the middle of the day, on a busy street, and someone smashed my passenger side window and tried taking my indash motorized screen. Luckily, it looks like I got away with just a broken window and broken center bezel around the HVAC controls and screen. Still sucks, but if it's just a window, I guess I got lucky.

 

It probably won't make a difference, but change the "MAP Comparison" value to 1.2 V. It is the correct value for an OMNI 4-bar MAP sensor.

Too bad about the broken window, but you definitely got off easy. Window and bezel are easy to fix and not too much money.