The Central Hub for DSM Community and Information

For 1990-1999 Mitsubishi Eclipse, Eagle Talon, Plymouth Laser, and Galant VR-4 Owners. This is where the DSM platform history is documented and archived. Log in to help us in our mission, and to remove most ads from the browsing experience.

Can we have a real thread about speed density?

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

Sitting on a sbox to heat soak is a bad idea
I wouldn't do it every single day at every single light, but I can assure you, it's fine for short tests.

It may seem like it is not important for idling, but the law applies all the time, and ECT and IAT should be a part of the calculation the entire time.
I think we're finally starting to agree. Glad to see it. I wasn't so sure when you were saying IAT is used for timing retard and nothing else. In fact, in this post you specifically said compensation wasn't needed.

Temperature compensation has to be used in some form.

Also, general throttle response should be increased, from idle to WOT, from CRUISE to WOT, from any throttle position anywhere.
Got a datalog showing this? I'm serious. I've got several showing a correctly dialed in MAS setup compared to a correctly dialed in SD setup, both with great throttle response. I'll gladly post up if we want to discuss.

Ever driven a stock EVO, for example? That thing has GREAT throttle response and it's running off a MAS. Any DSM MAS setup with poor throttle response needs to be adjusted, IMO.

MAS != poor throttle response. Likewise, SD != great throttle response. You have to tune the SD setup to get throttle response.

For example, you have to remove some of (if not all of) that airflow averaging that takes place in the factory code. If you don't, you get really poor throttle response from SD.

If that's already been done for you in the code you're running, then that's the "tuning" I'm' talking about. It was necessary, even if you didn't have to personally do it yourself. Nick mentioned it himself already when he said "The sampling problem is addressed by reusing stock code that smooths the data over several samples, although the number of samples is much reduced from the stock MAF code."

That "much reduced" part is what I'm talking about. If you tried to smooth it over the same samples as a factory MAS setup, you'd see horrible response.

My point? SD by itself doesn't mean great throttle response. SD with proper attention to detail means great throttle response. But the same is true for a MAS setup...proper attention to detail will get great throttle response.

With having the map sensor right there just before basically the cylinders, it becomes the best indicator of accurate cylinder pressure. You'd need of course need to guesstimate the amount of air IN the cylinder, but the map sensor doesn't lie about the charge inside the cylinder.
MAP is "manifold" pressure. Not cylinder pressure. MAP without VE is not a good indication of cylinder pressure. To guess at cylinder pressure, you need to account for VE. And when you take MAP times VE, you have airflow...

Let's walk through an example. My engine at 6000 RPM, 30psi of boost with 80% VE. Less airflow is getting into the cylinder than my buddy's engine running 6000 RPM, 30psi with 95% VE. He's getting nearly 19% more air into his cylinder per firing event than I am (0.95 / 0.8 = 1.1875) at the same RPM and same MAP.

More air also needs more fuel. So he's got more "stuff" crammed into the same volume. This will result in higher cylinder pressure...with the same MAP value. The better indication of cylinder pressure is airflow per rev, not MAP.

Thomas Dorris
ECMTuning, Inc.
 
with lean tip in has been taken care of in the evo community by adding an asynchronous fuel pulse on throttle delta.
Yes, exactly. The factory defines a tip-in table based on throttle delta (funny that we called it the exact same thing!) already. You just adjust those values to get the lean tip-in under control with SD. That and remove (or significantly reduce) the factory airflow smoothing logic...

Thomas Dorris
ECMTuning, Inc.
 
I hope this doesn't come out wrong, but honestly, we've used DMA logging since our first release. We've always had DMA, frame-based logging in DSMLink since I first coded that stuff back in the late 90s. It only got better (much) with V3. Please don't take this as downplaying the EVO work or just random bragging. I just feel that a good logging system is really critical and should have been the first thing EVO guys worked on, IMO.

I'll also suggest that you guys consider frame-based logging with synchronized data "snapshots" taken inside the ECU. Getting all the data elements properly captured as an instantaneous snapshot makes computations on the laptop side MUCH cleaner in a lot of ways than the factory request/response mechanism.
Hi Tom. :) I'll pull this off-topic for one more post, since I'm pretty intimately familiar with the DMA code we're using on the Evos at this point (and I didn't see this post until now). There's a lot of things wrong with how we currently collect data from the Evo ECU, frankly, and there's certainly no harm in pointing that out (I've been doing it for a while now).

The DMA implementation we have right now is very rudimentary: given either an ECU-side lookup table or an address and length (for contiguous memory retrieval), suspend interrupts and transfer the referenced data as a stream, then re-enable interrupts; writing is simpler, but similar. It's not incredibly formal and certainly not pretty, but it's "close enough" as an effective point-in-time frame grab, it functions as a relatively benign addition to the MUT protocol, and most importantly for my pea-sized brain, the code is dead-simple. ;) There's even enough there to make automatic detection possible, meaning you could fall back to MUT pretty easily (meaning retrofitting this to existing loggers shouldn't be that big of a deal).

The biggest problem we have right now is client-side: EvoScan's author (Hamish) doesn't appear to have any interest in adding support for DMA logging, and EvoScan is the most widely-used logger right now. (There's a few of us who monkey around with LogWorks or MitsuLogger, but we're in the minority.) That's a lot of inertia to overcome: the mindset of "I paid $25 for this, I better use it!" would be tough to beat without significantly improving the user experience. And the DMA client most of us are working with right now is basically a weekend hack in VB (a very useful weekend hack, but nothing I'd put an average user in front of yet), which means it's not even in the same league.

And if you look at how all of these programs actually store logged data...well, they're glorified spreadsheets, writing nothing but post-processed data to disk, making formula corrections after-the-fact impossible. Argh. I get angry every time I think about it, because I've lost data this way, by fat-fingering a formula or by accidentally swapping two MUT request IDs. Storing the raw data (with display-time filtering/processing and "math channels") in a reasonably-framed stream format with the ability to associate sources with frames (for multiplexing input sources, like the ECU, plus a few LM-1 sources, etc) is something I've been working on and off on for a while now for my own purposes, but that's only a small piece of what's needed to make a client that's interesting to end-users.

Then you get into re-flashing itself: we're building on the back of another closed-source package (EcuFlash) that we can't actually improve on, so we're stuck with multiple programs to accomplish very closely-tied tasks: tuning and logging. Moving a few tables to RAM and doing live updates to them helps in this regard, but at the end of the tuning session, you still want to permanently flash your changes. Again, though, it's a question of inertia: EcuFlash is "good enough", so there's little impetus to reinvent the wheel (and writing a flashing kernel and client isn't something everyone will have the ability to do).

And really, that's the overarching problem: our user experience sucks. :p (And clearly points out why I think, despite how much fun I'm having screwing around with this stuff, ECMLink is a product that's easily worth the asking price for most users.)
 
That's what speed density is from the get go. If you get 20psi at the manifold your pretty much garuntee'd to get 20psi in the cylinder.
Absolutely not. Sorry. Pressure isn't a separate entity. You get pressure as the result of the number of things (molecules) in an area, the volume of the area and temperature.

Same volume and temperature but more "stuff" (measured in moles here) means more pressure. 20psi at the manifold just means that "stuff" is pressurized to 20psi in the manifold. When the valves start opening and the piston starts moving down, you have 20psi in the manifold trying to push air into the cylinders. But you don't always (in fact you usually don't) get a complete fill of the cylinder.

That's what VE is all about... It's how much "stuff" you were able to push into the cylinder compared to how much "stuff" the cylinder could have held had you been able to equalize the pressure between the manifold and cylinder. That's just what VE is. Less VE means a less complete fill of the cylinder and less pressure as a result.

Kinda like a leak down test
A leak down test is completely static. That's different. You've got 100% VE at that point (well, whatever the leak down results are anyway).

Not to sound harsh, but shouldn't you and your buddies motors be well over 100% VE ? Did you mean 180% / 195% ?
I do not. 100% VE is a perfect fill of the cylinder. You can sometimes get a little over 100% VE, but only under special conditions. You would certainly never expect 180% VE at any time unless you had some serious issues.

Maybe you are confusing cylinder pressure with something else.
No, definitely not. I think you may be confused and/or mislead somewhere. Anyone else want to share an opinion?

Thomas Dorris
ECMTuning, Inc.
 
I don't know about 2G, but I don't think that boost control in the 1G EPROM would be very hard to do. The code is out there for controlling the BCS, you'd just need to use a table.

The SD file I use from the DSM-Ecu Yahoo forums, has a full boost duty cycle table. The factory controller will not cut it though on higher boost. You would need something like the AEM one. I played with it a little using the FPR solenoid to try and help spoolup with some success. It would just take some trial and error to get it set up properly

As far as my file, it is to be what I believe is Ds-Map V1, it's from early 2006, maybe hakcenter can confirm this?
Its based off of E931 code.
I drive about 1k miles a month in all different types of weather and its worked great for me. I definitely won't be going back to MAF sensor any time soon, unless i'm selling the car.
There was a point before this, I was eyeballing a used VPC setup, i'm glad I didn't go that route.
 
Not to sound harsh, but shouldn't you and your buddies motors be well over 100% VE ? Did you mean 180% / 195% ?

Excessively high VE numbers are a result of the way that your system works. Everything that I've been exposed to assumes that 100% VE is ideal since you are generally tuning to match a factory system which never used VE the way that we use it. There are a few exceptions, if you had been using a well tuned MAF before switching to SD and you had been using an aftermarket filter or pipe then you can find yourself with a higher or lower VE because you've mapped around inaccuracies in airflow measuring. You can also see spike in VE on liftoff.

You cannot deny that the closer the 'metering system is to the actual cylinders, the more potential is has for being accurate. MAFs read airflow in both directions so putting one in the IC piping on a turbo car is already a bad idea unless you never plan on letting off the throttle. Maybe your setup's throttle enrichment is more or less very accurate to your peticular vehicle when it comes down to the maf side of things. We can be very certain that by the time the 'measured' air from the maf, reaches the manifold even that the 'new' air at the maf is most likely completely different.

I generally think that very few people care about liftoff conditions when it comes to the MAF reading backwards in the IC pipe, I also think the amount of air blown out that is already on the wrong side of the MAF is pretty small compared to the amount moving over it even at cruise let alone WOT. As for the MAF being poor because it is so far from the cylinders I don't agree. If we live in the same area and I send you a package every day in the mail with something different in it then you can probably call me on any given day and I can tell you what is in the package because it is what I sent you yesterday. Mitsubishi knew how long it took air to travel from the MAF to the cylinders and they made adjustments to the code to make it work out. When we start messing with boltons and piping then we change how that works but MAFs are rescalable and tuneable just like SD systems. SD is cool and fun but if I wasn't so annoyed by the liftoff knock and stutter I was getting with the stock MAF then I probably wouldn't have switched. I probably still wouldn't have switched if it weren't for the fact that no one can seem to agree on everything it takes to make the 2g MAF scale beautifully with the evo8 ecu and the parts for SD were cheaper than an evo8 MAF and a lot cooler.

FWIW I may sound a little loopy right now since I'm recovering from a minor dose of anesthesia but I think sound reasonable.
 
ve is not how much of the cylinder is filled but how much air the cylinder can hold space wise and the actual amount of air it ingests.
I do not like that definition of VE. I know people use it and I fully understand it, but that's NOT what I'm referring to here. Your definition references atmospheric pressure. My definition references manifold absolute pressure.

IMO, it's MUCH more useful to reference manifold absolute pressure here. It automatically normalizes the entire VE table so that 100% is the theoretical best regardless of boost. So any time I refer to VE, it's going to be relative to manifold pressure. I'll never reference atmospheric pressure here.

We're not measuring atmospheric pressure...we're measuring manifold pressure. So you'd want to use VE numbers relative to that.

cylinder pressure and combustion cylinder pressure are not the same.
I'm sorry. I just don't know how else to explain it to you. More air gets into the cylinder with higher VE. That increase in air increases cylinder pressure. You can have more air actually getting into the cylinder for a given manifold pressure just by changing the VE of the engine (different cams, different intake manifold, whatever) as my example before illustrates.

g/rev is dependant on the measured air actually getting there.
You need to explain this more clearly. "g/rev" is just a measurement unit. You have some airflow per rev number whether it's measured with SD, karmen vortex or hotwire. It doesn't matter. Whichever is used will produce *some* airflow per rev number.

And that number is either right or it's wrong. If it's wrong, your measured A/F ratio will indicate this (assuming you have injector compensation dialed in correctly). If it's right, then that amount of air *is* getting there and you can use it as a reliable indication of cylinder pressure.

Thomas Dorris
 
I think you guys are confusing "engine VE" with "total VE". I can see total VE (ve of the system) equal 180% or far more. But engien ve (if there were no turbo) will rarely be over 110%.
 
I think you guys are confusing "engine VE" with "total VE". I can see total VE (ve of the system) equal 180% or far more. But engien ve (if there were no turbo) will rarely be over 110%.

Yes and no. VE is an integral part of our tuning tables. Hak's use is total VE and the usage for link and evoSD is engine VE.

This is a random example of our major tuning tables for SD, this happens to be completely untuned and is what you would find in a base SD rom, it would be enough to start the car and make it to the store.
You must be logged in to view this image or video.


The horizontal table is the VE compensation table, and obviously you find that in the middle VE is very close to ideal and it drops off at each end as you might expect it to.

The vertical table is load vs map which creates an uncompensated value to feed the ecu. Compensated load does not resemble this table at all usually.
 

Attachments

You must be registered for see attachments list
No, you're misusing terms.

V/E is the percentage of displacement filled on the intake stroke.

The fact that you have to adjust for altered combustion efficiency by changing the V/E is simply another way of adjusting the actual fuel amount.

Combustion improves, so we need more fuel, so we change the v/e value in the table and fuel volume is adjusted. The physical v/e of the motor does not change.
 
At speed densities roots, it does not get any simpler than. At xxx pressure, add yyy fuel. Performs very similar to a carburetor, except mechanically the carb knows a lot of stuff.

S/D has nothing in common with a carb.

A carb is a venturi effect device which knows nothing about air pressure or temperature. In order to compensate for changes in them, the tuner must change the jets (or other fuel metering parts) to achieve an optimum tune under the current conditions.

Using S/D, the ecu adjusts fuel delivery based upon the implementation of the gas law and the defined V/E.
 
What are you out to get me or something Hal, seriously. Carbs add fuel based on venturi. Okay break it down ?



More reading here..
Venturi effect - Wikipedia, the free encyclopedia
Pressure-gradient force - Wikipedia, the free encyclopedia

I'm sorry if adding fuel based on the venturi effect, is very similar to SD in that SD adds fuel based on pressure principally.

Oh please, you're really stretching if your saying the S/D application of the gas law is even remotely the same as fueling because of venturi effect.

S/D adds fuel proportionally based off of pressure AND temperature.

A carb (choke circuits excluded) knows nothing about temperature.

If we use your assertion then we can also say that a maf system works like a carb as well. Instead of the air passing over a venturi, it's passing over/thru some form of sensor.
 
Anyone who doesn't know what SD is is only going to be more confused by your examples and comparing SD to carbs. I'm also not sure that it is important that this thread make an attempt to educate that sort of user since I think the discussion is well above the level of understanding let alone interest of those members. There are already a number of basic discussions about SD but most of them only focus on one system or are heavily glossed over. What I'm interested in is a fairly high level discussion of SD and the future of it in DSMs in terms of development, implementation, and theory. Now we do have to all be on the same page and it is important to be fairly uniform in our definitions but I also expect that we can pick up most of that from context if we try.
 
The advancements in the last few years, specifically around the EVO and 2g ecu options, will make S/D available to a much larger number of enthusiasts without having to use add on devices (vpc, etc).

Whether S/D is appropriate for any one person is ultimately up to them, but one of the great by products of the S/D evolution is the knowledge gained about how the oem ecu works.

That knowledge then leads to yet more enhancements.

Knowing why the ECU is doing what it does is a priceless aid in not only getting a proper tune, but in trouble shooting issues.
 
Calculating airflow and cylinder pressures is kind of dopey if you ask me. I've never seen those as options to be logged or calculated in any stand alone system I've used. I wasn't buying it when you guys said it's not in them "for simplicity". The only reason it's in link and jackal is for simplicity of interaction with the stock ecu. If it was superior or important, it would be in the $10k motec system. It is also dumb to me to try and create a VE table. The VE table is, or should be your fuel table. If you look at a 3d fuel table in a stand alone, it is a graphical representation of your torque curve, which is a graphical representation of your VE. Target AFR's are a required redundancy in jackal for now, and I'm not sure if they exist in link.

One thing I'd like to know about is the g/rev cap. There obviously isn't this problem in either jackal or link (certainly not with a stand alone since they don't even use it) where you hit a certain power level and your car shuts off. I wonder how they get around it. If I have it right, link got past the extended table cap in V2 by using an assumption table after the cap was passed. Is this the case in V3?

It would be fair to mention that this cap currently applies to the spark table on jackal. After you exceed the #12 load table you are running on the #12 load table spark map.

One cool thing you can do with speed density is use the ECU as an electronic boost controller. What options do all these systems have for boost control? Running jackal I see there is one that is RPM based, but I don't know how it works. The stand alones have tables, and I've never seen the one for link. For FWD, pulling boost based on speed can really help out the traction issue.
 
Now we get into the realm of s/d as a air metering methodology vs a tuning methodology.

If you have a tuning methodology that uses a v/e table and afr target then you can simply enter the desired target, and assuming that the v/e table is built properly, the system will supply the appropriate amount of fuel.

If you have a tuning methodology which is just the fuel table (or v/e table), you adjust the table as needed until you hit your target.

Different ways to get the same result, the desired air/fuel ratio at the defined load point.

Neither one is right, neither one is wrong... just different variations on the use of pressure and temperature to get the desired amount of fuel.
 
One cool thing you can do with speed density is use the ECU as an electronic boost controller. What options do all these systems have for boost control? Running jackal I see there is one that is RPM based, but I don't know how it works. The stand alones have tables, and I've never seen the one for link. For FWD, pulling boost based on speed can really help out the traction issue.

This doesn't require speed density at all. The stock code uses load based targeting which is superior in many ways to psi based targeting. After that if you want to target based on pressure you only need a MAP sensor and not SD. The evo8 ecu has come to the point of having gear and rpm based boost control.
 
If there is to be really any kind of discussion I need Tom to understand the terms.
Believe me. I understand the terms. If you want a counter example, read this page.

Volumetric Efficiency 101

The wikipedia article needs to be updated to indicate the confusion people have when talking about VE. I really didn't think anyone used "total VE" so regularly when discussing SD systems.

Regardless, I'm out of this endless argument. I've stated my position and my reasoning and I've seen nothing presented to change any of it.

Thomas Dorris
ECMTuning, Inc.
 
Don't confuse my post with a part of the engine management discussion, I was referring to controlling boost which doesn't car if you are using SD or a MAF or voodoo as long as it has a method for determining when to have the BCS pressurize the wastegate reference.

If you still don't know why load targeting is better let me give you an example. My car is a perfect example in that I have a 16g and 560cc injectors. I have quite a bit more turbo than injectors so I can give the turbo and boost management some leeway without worrying about damage or heatsoaking from an overspun turbo. In this case I have to worry about my injectors tapping out. In my case 22psi is a safe static boost to run but that can vary from 225 peak load to 255 peak load. One end of that spectrum is slower than necessary while the other is barely within a safe range. If my desired load is 240 then that could happen at 20-24psi depending on conditions from a cold night freeway pull to a heatsoaked intercooler pushing through the twisties on a track that has baked in the sun all day. It also helps to make sure that you stay within a tuned section of the map and makes tuning easier. If I want to tune the entire map then I can individually set load ranges and tune for them or I can choose a target column and then only tune within about 30 load of that.
 
That makes sense if you don't have enough fuel. Running a turbo that outpaces your fuel capacity is stupid.

You can control it based on whatever you want, but boost makes the most sense since that is what you are trying to control. You would have your boost table follow your VE if you were trying to keep from outpacing your injectors.

With load based based boost control you would get additional boost on a hot day to compensate for the lower airflow. This is not what you want to happen.
 
OK, I lied. One last post on this VE topic. I decided I wanted to find the definition of VE.

So I asked myself who I would consider an authoritative source. I immediately thought of Corky Bell and/or A. Graham Bell. I referenced every book I have here from those guys and to my dismay, they all cleanly side-stepped the question entirely!

Ok, to the web! Well, no, that doesn't help either. You find references all over the place talking about both forms of VE. The wikipedia article, of course, just regurgitates text found elsewhere on the web, so it's hardly a definitive source. And then you find a number of pages like these that specifically mention the two forms of VE:

Volumetric Efficiency 101
Volumetric Efficiency

So which is it? Do you reference manifold pressure or do you reference atmospheric when calculating "VE"? Which you choose radically changes how you use "VE". So it seems like a pretty critical piece of data.

But, apparently, nobody agrees on the real definition of VE. And given how many thing Curtis and I disagree on, it seems this will remain yet another one.

hakcenter said:
If there is to be really any kind of discussion I need Tom to understand the terms.
No, apparently we both need to understand the terms the other is using. Don't try to make this one-sided. There are simply two definitions and forms of "VE". You'll need to accept that.

I will continue to use MAP-relative VE and I'm sure you'll continue to use the other. No surprise there.

I will also continue to use mass airflow per rev for load because I still firmly believe that's a more accurate and a more universal reference for engine load. MAP as load only has one advantage, IMO. It helps to normalize the axes between fuel, timing and VE. But only on one particular car. Which is fine. I'm not saying it sucks. It just is what it is. And that one advantage alone makes it appealing. But I'll never agree it alone more accurately reflects cylinder pressure.

Thomas Dorris
ECMTuning, Inc.
 
That makes sense if you don't have enough fuel. Running a turbo that outpaces your fuel capacity is stupid.
Why is it stupid? This is common and not at all dangerous. Choose a setting that doesn't make your car run out of fuel and do what you like. When you have money later you can invest it in more fuel or you can do something else with it.
You can control it based on whatever you want, but boost makes the most sense since that is what you are trying to control. You would have your boost table follow your VE if you were trying to keep from outpacing your injectors.
You only consider boost to be what you are trying to control because that is what you are used to, what we are really trying to control is flow since boost is actually a pretty worthless measure of what we want going on with the car. Load in this case is the exact same use as VE the way that Jackal uses it if I understand that system correctly.

With load based based boost control you would get additional boost on a hot day to compensate for the lower airflow. This is not what you want to happen.

Why wouldn't I want that to happen? That is exactly what I want to happen, I want to use the same amount of air on any given day regardless of conditions. Why would I care if pressure is static? Hell, we all use SD so you should understand that pressure doesn't mean anything on its own, it needs to be compensated for to get to the airflow numbers you want and to use your components fully.
 
With load based based boost control you would get additional boost on a hot day to compensate for the lower airflow. This is not what you want to happen.

You may get a slightly higher boost psi, but you always get the same amount of air in the cylinder(g/rev), which makes tuning easier.

And Load is more related to torque, which makes traction control easier.
 
Add Value - Be Respectful - No Trolling - No Misinformation - Participate Often!
Support Vendors who Support the DSM Community

Build Thread Updates

Latest Classifieds

Back
Top