FYI, i took my XEDE out, drove it for a couple of days..no misfire, no SES. how long should I keep it off?
If someone else could translate in layman's terms what Hammer just posted, I think it would help a couple of guys here.
I'm not that savvy with XMap, but i have my laptop plugged into my Xede; I have those maps in my screen...
anyone want to give another shot and explain what to do here?

 

It did it with my stock BOV, pre-XEDE and post-XEDE. I might pull the XEDE out and see what happens for a couple of days.

 

I have a completly stock evo with 42000 hwy miles on it. The car drove perfect until about 2 weeks ago while on the way back from work. I was on the hwy accelerating when I noticed the retard in power while climbing the mid rpm range. After this happened the light came on. The light went away after about 10 cycles starting and driving the car but the retard situation was still present. After about 15 minutes of the light dissappearing, it came on again.

If I drive the car carefully I dont notice it, but if I accelerate in a medium to heavy pace at around 4000- 5500 rpm range I noticed a drop of 500-1000 rpm while keeping a steady pedal pressure.

 

Yours could be a coil pack issue. Get it checked out by the dealership. From what i understand the people here facing the P0300 problem have it under part throttle (not accelerating). Yours seems to be sth different.

 

I have a theory on one of these situations (no misfire, but code triggered). I seem to remember a long time ago Shiv posting something saying there was an issue with the Xede where if you changed the timing advance too much too quickly (big difference in numbers in adjacent timing cells) then a misfire code would be triggered. I beleive this was because the way the Xede changes the timing is by lying to the ECU about the crank angle.

So what if the ECU adjusts the timing in the same way (I'm sure Shiv could chime in), rather than change the crank angle to fire the spark it changes some 'relative crank position'. Now if the knock sensor heard some knock, and the ECU yanked timing (by radically altering this relative crank position). Surely that could have the same effect as the Xede had. Or maybe I'm just making this all up and am horribly wrong

I'm going to search for Shiv's post now..

 

Bump, can anyone help me out with my prior queston above?

 

I have an intake/exhaust/ecu flash and I've been getting the code off and on for a while. I get the stumble in 5th gear partial throttle and then the ses lights up.

This weekend I went on a 1000 mile round trip drive. The p0300 didn't show up until about 400 miles into the trip. I drove it for another 75 miles with no stumble. On the trip home the stumble happened about 50 miles into the trip and would happen over and over every 2 minutes or so under light throttle. I finally got fed up after about an hour of driving like this and pulled over to reset the ecu. It didn't happen again the whole 3 hours left in the drive.

 

For those getting the P0300 error, and who use the XEDE, or not use the XEDE....I don't think anybody knows what to do.

Obviously, if there was a solution, somebody would've posted it already.
Getting a sound explanation concerning this problem will be like pulling teeth.

"Pointing fingers" will be a waste of time. Might as well just explore other avenues....

I'm currently saving up on the HKS FCON V.......and i'll let my ECU simply take care of the basic stuff like AC, etc.

Anyone interested in an XEDE? Pm me.

 

FWIW, the misfire issue seems to stem from CAS unstability. With only 4 teeth on the factory crank trigger, we're all still uncertain how Mitsubishi actually accomplishes something (misfire detection) which typically involves more teeth/resolution. The XEDE simply regenerates this CAS waveform with no noticeable abberation. With no documentation from Mitsubishi explaining the EXACT logic behind misfire detection, we're simply trying different ways to supress what seems to be a factory diagnostic shortcoming. Whether this means limiting the CAM amplitude, ramp-up rate, decay, spacing, et,... it's all do-able. And if we suceed, we can rightfully say that the XEDE can fix the problem. But the hard part is finding the actual problem. But that's one of the things we are doing every day so we're no where close to giving up hope.

As for the XEDE causing the misfire problem, we have seen this when running the older version of the firware which doesn't incorporate the analog bypass. This misfire code was actually caused by real misfire since the waveform of the MAF signal (at super low load) was too low frequency for the XEDE to replicate smoothly. So we made the XEDE offer a straight-thru bypass (v. 1.7.14 firware) below a certain load. v3 eliminates that bypass with a revamped MAF scaling feature which takes things a step or two further. As for CAS replication, v3 is designed to be fully "open"-- meaning that we can make changes simply by uploading a new pattern file which makes the testing/development/troubleshooting process a whole lot easier.

Regards,
Shiv

 

Guess I'll just wait for V3 then - I'm happy to be a tester for it btw if you want a car out of state If you're interested get David to give me a call.

Cheers

Rich

 

This is certainly and interesting post, particularly when I have an Xede on order. One thing is certain, if I experience any "misfiring" with the Xede installed and not when it is uninstalled Vishnu will be sending me a refund.

I am not spending $900 to be a "test bed".

Vishnu will need to give me a "gaurantee" that the Xede will work as promised before I take delivery. Is this to much to ask?

 

bbenavitz, your gonna be fine, there are LOTS of people that have installed the Xede and not experienced the misfire problem, infact I experience it more without the Xede than with it.

 

Every indication I’ve seen, and this thread seems to support this conclusion, points to the factory ECU, and quite possibly the EXEDE computer, being marginally powerful. While I was refining my exede maps with additional cells and minimizing the difference in adjacent cell values, the frequency of random misfires increased in direct proportion with the complexity of the maps. By highlighting the cell values and driving the car, I often saw the piggyback computer leapfrog over lots of cells. Particularly in lower gears. This would indicate the sampling speed wasn’t quite up to the task when running the maximum number of rows and columns in all fuel, boost, ignition maps. Since simplifying my maps by removing rows and columns I felt I could do without, the problem has completely gone away. This isn’t so much a criticism of the EXEDE computer, which I really like, just a definition of it’s limitations. I’m an engineer by nature and profession and think I can safely say that all computer hardware and software has limitations. Doesn’t make it bad.

The last couple days I’ve been increasing the complexity of my boost maps again, on the theory that the boost isn’t piggy backing the factory computer and can take more complexity. The wastegate is completely controlled by the EXEDE. So far no random misfires and I’ve gotten back my snappy throttle response. Please allow me to explain: I started by highlighting the cells in the boost map and putting my foot to the floor through the rpm range. The cells that are actually functional are highlighted in amber. I know I’m not telling you anything new but bear with me. By identifying the biggest % of MAF (left map column) that is achievable at each rpm point, I mentally labeled that value as "full" boost for that rpm. Or, full throttle for my car at 2500rpm only registers about 20 percent of MAF, 6000rpm is about 65 percent or so of MAF,…etc. By placing the value 80 in the 2500rpm, 20% cell and also in the 6000rpm, 65% cell, I’m getting 80% of available boost at full throttle and all the cells above those values are essentially useless. Make sense? Now because the factory computer pulls ignition timing back with boost (from +40 all the way down to +0 timing advance when the boost comes on at 3000rpm), if you just put all 80’s in your boost map, initial tip in throttle response is sluggish and turbo like. By placing the value 80 in the 30%, 3000rpm cell and interpolating from 80 down to zero at 2% MAF, roll on acceleration feels more like a normally aspirated car and I get that runaway, loves-to-rev engine character I like. Not to mention a LOT better fuel economy in normal driving. To enhance this effect, I’ve eliminated MAF rows between 60 and 95% and added rows below 30% so I have the same number of cells but more of them at lower MAF% where they’re actually used.

When I also followed the above procedure for fuel and ignition, as well as boost maps (lots of cells, hundreds of different values), is when I started throwing random misfires in increasing frequency.

 

I think Hammerr has a good point here. I'd be hesitant to make changes of that nature without at least knowing the AFR, but it's something I wouldn't mind trying out on a dyno.

Honestly, I think the XEDE probably outstrips the factory ECU in its fine grade resolution - do we know whether people have had a similar issue with other piggyback engine management? I don't read the other engine management forums so I am just wondering.

 

Hammerr, without wanting to say you are wrong, because you obviously have far more research into this than I have, but have you consider that this leapfrogging is really a limitation in the sampling rate of the Xede and not of the serial interface between the Xede and laptop? The reason I say this is that I'm sure we have all seen the tach on the XMAP software, and have seen that when you rev the engine it 'jumps' beetween RPM values rather than moving smoothly, I think this is the serial interface rather than the Xede itself only reading 2-3 times/second.

On a side note, can you send me your maps, I'd be really interested to see if doing something similar with my boost tables yields the same results as you are seeing since they seem very good.