I would assume it just measures the time for one revolution (or partial revolution) of the crank compared to the next revolution of the crank. A misfire cycle would be slower than a non-misfire cycle. I'd guess that if they aren't similar within a certain percentage, you get a misfire CEL.

I mean, there isn't much more that they can do, is there?

If you messed with the timing advance by moving the crank signal around, in certain situations I could see it wreaking havoc with the ECU's misfire check. If you happen to be on the edge of a cell, for instance, and there was a large variation between the two cells you are bordering.

Rembember that the engine has to be in a faily tame state for the misfire check to be used. No acceleration. Pretty much steady cruise or idle.

Shiv, I'm not sure how the Xede works with respect to timing advance changes, like whether you interpolate timing advance between cells, etc... But could you possibly build in a special case for adjusting timing advance while in steady cruise or idle or other misfire detection states, where timing advance changes in the map are smoothed out more? That could keep the changes to the crank angle signal to a minimum when it really counts the most.

 

Yep.. it's the limitatin of the serial communication, not the XEDE itself. Something like 10 samples per second. And when you have 5 maps and a montior screen open, all updating at the same time, you get the idea. To speed things up, close some maps and turn off the data capture on the monitor screen.

Cheers,
shiv

 

I think the problem there is aggressive moves between timing modes would probably be very difficult to make smooth, given that you might jump from the smoothly interpolated mode into "x" in the set timing map in a very short period of time. This coupled with the crappy resolution of the CAS would make it even more difficult.

It's an interesting idea though.

 

The XEDE only allows a small fraction of a degree timing change for each successive engine event, regardless of what timing offsets you have in adjacent cells. It's basically a limited ramp-up/ramp-down rate. This prevents triggering of the misifire code or any problems that could results from a bad map input.

Shiv

 

Ever thought about making the XEDE use USB 2.0? That's way higher bandwidth than the ECU could ever generate.

 

The microprocessor in the xede would still have to generate the data, which would be the limitation.

 

FWIW, in v3, by simply revising the comms protocol and running the logging through a seperate logging program, sample rates are 100 samples/second. The mircoprocessor the XEDE isn't the limitation.

shiv

 

An excellent point about the serial connection speed. Also to consider, when I connect the laptop it becomes part of the system. The open communication link between laptop and EXEDE probably doesn't help if there's a cpu/ram/heat issue. Another piece of the equation I haven't mentioned is the increased random misfires I was seeing when my OBDII data logger was also connected. That and the factory computer stops sending data to the logger after the first few minutes, then in increasingly shorter intervals until I shut off the car and let it "rest". This supports the cpu/ram/heat theory. And yes it's just a theory but one that makes most sense to me with what I know now. I've not had an engine light since simplifying my maps.

Be happy to send maps. email me at sv900@hotmail.com. For comparison, my cam timing is a bit too advanced to be optimal but I am making peak torque consistantly at 4500 and peak horsepower at 6500rpm on 93 octane pump gas. If you let me know what you're running for boost/fuel/ignition values now at 3000, 4500 and 6500rpm I can very quickly scale you a progressive map that won't change your basic settings but should provide that runaway rev feel.

Oh, also, approaching the knock sensitivity limit slowly with a MAF progressive map allows more boost/timing than slamming into it. I monitor timing through the OBDII connection. That way I know exactly when the factory ecu is pulling the timing.

 

I don't think differences in adjacent cell values is what I've been experiencing because I didn't start to see random misfires until I started adding cells to smooth cell transitions.

 

I know that, I very much doubt the processor in the XEDE has a bandwidth/clock speed issue, typically ECM ECU's are very simple and don't run at particularly high clock speeds for reliabilities sake. I meant having a higher bandwidth connection between the XEDE and the computer running XMAP, so there is a more "realtime" view than the sampling speed of a 9600/19200 baud serial connection allows.

Hammerr - what mods do you have?

 

My car is only a couple months old but I've so far got some light weight forged wheels, a Hotchkis (spell?) adjustable rear sway bar with poly bushings (very nice quality and function by the way). Defi boost and A/F gauges, cyinder head and exhaust gas temp gauges. Gtech acceleration meter hard mounted (stock mount sucks). Enginuity OBDII software for my PDA and laptop.

I know that's lots of instruments for little drivetrain mods but I like to see what's going on before I go hog wild with horsepower. Just installed an equal length tubular exhaust header this past weekend. Seems to spool a little better but don't think I'll see any real improvement till I upgrade the exhaust. Still have the factory intake but I'm running without the air box cover.
I work designing custom severe service control valves for the petrochemical industry so am familiar with how to manipulate fluid flow. In preparation for a low restriction intake I've built really oversize stainless steel sheet metal heat shielding for the exhaust header that directs heat out the stock hood vent, and also some aluminized insulated stainless sheet metal guides for the intake that creates a large sealed path from the front grill to the airbox section of the engine bay. I built a ram air sort of scoop that mounts behind the front grill and pushes air into the hollow under the hood. That section is sealed off to the hood and pushes air to the airbox area. All this is invisible from the outside except for the scoop if you look for it. Plan to mount either a Buschur or HKS RS intake as soon as I figure out which one. I'm leaning towards the RS with a pleated washable generic filter from K&N. The stock air filter looks to filter very well but the rubber intake hose with accordian pleats has no chance at wall attachment for clean free flow at higher velocity.
I'll probably mount the Vishnu turbo back exhaust in the spring. The one that has the O2 housing as part of the downpipe. Only one I know of that does that and very very desirable in my opinion.

I do really like the EXEDE piggy back. I did a lot of research and picked the exceed because of it's part stand alone and part piggy back philosophy. The piggy back is notably more complicated to tune to a gnats *** because the factory ecu "learns" and it's manipulating parameters mostly unseen to you. Kind of a moving target when you're trying to split hairs. Guess it appeals to the masochist in me. However, because this car's also for commuting, keeping the stock ecu is attractive to me. Besides, damn near anyone can tune a standalone. In hindsight, I like the knock sensor sensitivity and the way the computer protects the engine from detonation. If I ever go big ball bearing turbo I'll probably also break down and get an AEM standalone. I am really looking forward to the Vishnu V3 firmware.

I've got 6,000 very hard miles on the car in 2 months and everythings tight as new still. The dealership purchase experience was worse than a series of root canals but my hat's off to Mitsubishi engineers. If you look on the Porsche forum Rennlist you can see my 98 911C2S wide body is up for sale. This car makes the 911 feel like a Buick.

Damn look at the length of this post. Well you did ask what mods I had.

 

That still isn't terribly fast, actually. At least not compared to a standard RS232 link.

19,200bits/second = 1920 bytes/second

If you were streaming 1 byte per sample, you should be able to get 1920 samples/second. Or at least close. You are probably going to need a few bytes per packet to dictate time, and to indicate the start of a packet, etc... Assuming you aren't using some sort of request/reply protocol, that is, which is fairly inefficient. It might, though, what do I know?

And 19,200bps is a fairly slow serial link. 115k is more like it.

My point was that you aren't going to saturate an RS232 link with a data stream from a relatively slow microprocessor (unless the microprocessor isn't doing anything else). USB isn't needed.

 

Fundamentally that's what it's doing but using just that metric you couldn't readily distinguish between a misfire and say a gear change or bump in the road. There are more factors/heuristics involved (at a minimum of course, MAF).

 

For those who care (what? nobody?), the XEDE serial link is 115.2kbps and each v3 log packet includes (up to) 29 distinct 16-bit values i.e. a max of 5800 payload bytes per second or about 46kbps when it's in v3 streaming log mode (no request/reply).

Not a lot of data but as you point out it's just one of many things the XEDE is doing at any given time. In addition to calculation, mapping, servicing requests from the DTE, etc., the XEDE is taking full resolution (relative to the noise floor) samples of analog inputs hundreds of times per second. Not too bad for a 15MHz processor when you consider that similar 286-class PC's of yesteryear had a hard time with anything more than a 9600 baud modem (and that was under DOS). Credit ChipTorque (or discredit IBM?) here.

Actually it still could, just not sure of how much practical value the additional data would be (at least to human tuners), given that there are an order of magnitude fewer discrete breakpoints in the maps with which tuners could take act upon the additional data (not as useful to have data at 5rpm intervals if your breakpoints are at 500rpm intervals).

 

I'm no Computer Science guy, but if I recall Microprocessors and Electronics, I thought there were 8 bits in a byte, hence 19,200bits/sec would equal 2400 bytes/s?