Can we have a real thread about speed density?

[J-speed99]

I was wondering if we could have a thread on here where everyone that uses or would like to switch to speed density could post openly without getting deleted or even banned from talking about link? How does it help the DSM community to delete every post that has anything negative about DSMLink in, alot of people would probably like to know.

 

[Rob10_99]

Well, they are a sponsor, they can't be trash talked like "stupid ebay parts". Links product is VERY good and they have YEARS invested in the product and support.
That being that.
Lets first list the options we have for SD.

DSMLink
AEM
HALTECH
Megasquirt
motec
EMS systems of austrailia
Autronic
SDS
Accell
FAST
Jackal
Maft Pro

thx turboglenn!

I'll add to the list if anyone knows of more.

 

[untouchablecc]

Well i have a question about speed density because i wanna switch to it. Does anyone know the gm part numbers for the iat and map sensor because i can prob plug it in at advance where i work and get them maybe cheaper. I cant seem to find the numbers though. Plus i dunno what bar i need do i need a 3.0 or 3.3 . I read on here that a 3.0 is not good past 29 pounds well what if i wanna run past 29 do i go 3.3. I dont think a lot is answered about it.

 

[Rob10_99]

I can't give you exact part numbers, but a 3 bar sensor (32psi boost) is 2 bar pressure, and 1 bar vacuum.
No matter what route you go with SD, driveability and throttle response are greatly increased. Those two points make that option absolutely worth it!

 

[snowborder714]

Part numbers at the bottom of the page - externalsensorlist [ECMTuning - wiki]

For MAP sensors, you subtract 1 bar for atmosphere pressure to get the max psi it can read. So the 3 bar sensor is only good for 2 bar, or ~30psi. The 3.3 would be good for ~33. If you need/want bigger, look into AEM or Omni map sensors (Omni are direct drop in for 2g's).

 

[jrohner]

Speed density is being done on the Evo 8 ECU's, which are quite easy to put in a 2G. I love my Evo 8 ECU so far, and I have switched to speed density; it was quite easy to do. You need to start reading on EvolutionM.net if you want to go this route.

I am running the 96530006 ROM, which is the Australian market Evo 8 code. I am actually on the tephramod rom which was then modded for speed density by someone else. The newer tephramod 6 for this ROM is called 96530706. The tephramod is just a ROM with a bunch of mods done to it, such as map switching (having two totally separate map sets that you can select from, including different fuel, timing, boost, injector compensation), and many other things.

 

[turboglenn]

Well, I can't argue about anything bad with mass air because if a stand alone MAF system was readily available and would let you set a base map based on speed density with the self adjustment of mass air that would be the ultimate IMO (but probably hard to tune)


Other than that i can say i love SD and wouldn't go back to a normal MAF system even with a piggy-back style unit such as link and i like DSMlink a lot

some other systems are

motec
EMS systems of austrailia
Autronic
SDS
Accell
FAST
and a few more i can't hink of right now i'm sure

 

[SpeedAddict62]

Or the stock ECU? If you have a 1g, speed density code has been around for years, available for free.

 

[twdorris]

I'm game. Here's a starting point for you guys to read up on the basics of speed density.

Speed Density 101

Some common part numbers and such can be pulled off this page.

ECMLink Speed Density Setup

I've had every GM MAF there is in my car as well as every Mitsubishi MAF that everyone seems to run, hacked and unhacked. I've also run a variety of MAP sensors on my car with SD. You what a dead honest opinion? They all work just fine. Throttle response is crisp on each and every one.

If you put a little thought into the setup, you can run 9s on a stock (unhacked) 2G MAF sensor... I'm not saying that's the end all solution and everyone should run it. I'm using it as a simple example that you can make just about any configuration work for you if you step back and look at the problems and solve them.

Does SD solve the world's problems? No. Does it work fairly well and fairly easy? Sure, if you take the time. But so does a GM MAF sensor...if you take the time.

I honestly can not tell sometimes if I'm running a 2G MAS, EVO8 MAS, hacked 2G MAS, 3" GM, 3.5" GM, or SD. There are times when I have to open the hood to check just so I know what I'm driving on. They can all be made to work absolutely great.

SD has the advantage of fewer installation hurdles sometimes. The boost sensor is probably going to be there already anyway for logging. So you just need an IAT sensor and a little VE dial in and you're done. It's definitely nice in that regard.

But if you've got the piping and/or desire, you can do the same quick-easy install/setup with a GM MAS or, of course, a factory MAS.

The point is...they all work just fine. So given all my options on my own car, which do I run? Well, at this point, I switch pretty regularly between the GM and SD. The factory MAS just doesn't fit well since I had to install an upper IC sized for the GM. And I can tell no difference in driveability between the GM and SD setups. Throttle response is great with either one. So I usually just leave whichever happens to be wired in at the time unless I have a specific test I want to run.

Also, the IAT sensor can be considered optional if you're going to keep charge temps going into the engine under control (between, say, 50-90F). If you're like me, though, and pound the heck out of the car at the road course with air temps hovering near 180F, you WILL want IAT compensation. Otherwise your mixture will run rich as air temps increase (and lean as they drop).

And, if you have IAT compensation enabled, you will want some way to disable it in favor of coolant compensation (or disable it entirely if you don't care much about cold start mixtures) as airflow rate decreases. I know there are plenty of people that won't believe this. But we've collected SEVERAL logs on several different occasions to prove it to ourselves. It was not expected behavior. It was a measured behavior that we had to devise a solution for.

As for the EVO8 ECU version...can someone tell me if they use IAT compensation? And how is the VE calculated? I was under the impression they were doing a multiplication of RPM-based VE and MAP-based VE (i.e., not a large table of VE numbers, but rather two smaller lists). Is this correct? I ask because that's actually how our first version was implemented as well just because it was easy and seemed like it outta work. But then we found a number of driving conditions that just could not be accounted for well enough. Now, that's picking through logs with a fine-toothed comb looking for every single little variation we could find. So I actually don't think anyone else would really notice it much.

Thomas Dorris
ECMTuning, Inc.

 

[VETTE_50_TH]

The code for the IAT is built into the rom jrohner was talking about earlier. Basically, you wire the iat into an open port for the ecu to read from. Thats at least how i know of it to work. Then, ovbiously airflow is calculated.

James

 

[twdorris]

The code for the IAT is built into the rom jrohner was talking about earlier. Basically, you wire the iat into an open port for the ecu to read from. Thats at least how i know of it to work. Then, ovbiously airflow is calculated.

The IAT sensor would have to go into a compatible input, I'm sure. And the only one I'm aware of would be the factory IAT (or coolant temp). You have to have compatible (and known) pull-up/pull-down resistor combinations to calculate temperature.

But that aside, I'm still left wondering about the details of how IAT is factored in on the EVO8 code. Is it always used to adjust the airflow estimate under all conditions, for example?

Thomas Dorris
ECMTuning, Inc.

 

[blackrosenova40]

Add the Maft Pro to the list, I run it in speed density.

Well, they are a sponsor, they can't be trash talked like "stupid ebay parts". Links product is VERY good and they have YEARS invested in the product and support.
That being that.
Lets first list the options we have for SD.

DSMLink
AEM
HALTECH
Megasquirt
motec
EMS systems of austrailia
Autronic
SDS
Accell
FAST

thx turboglenn!

I'll add to the list if anyone knows of more.

 

[pneumo]

Has everyone forgotten about the HKS VPC? Back in the day it was highly regarded, despite it's idle issues, driveability quirks, high price, lack of support for injectors bigger than 550cc and? I guess it's a good thing it's not available anymore.

TWDorris, you've mentioned before about the need for ECT fuel compensation to taper off at higher airflow levels. I could've sworn that the 12 byte table at FC23 does exactly that (e931 code base). Have I misinterpreted the code?

 

[Ceddy]

The IAT sensor would have to go into a compatible input, I'm sure. And the only one I'm aware of would be the factory IAT (or coolant temp). You have to have compatible (and known) pull-up/pull-down resistor combinations to calculate temperature.

But that aside, I'm still left wondering about the details of how IAT is factored in on the EVO8 code. Is it always used to adjust the airflow estimate under all conditions, for example?

Thomas Dorris
ECMTuning, Inc.

The EVOs have a Fuel Temp sensor that is only used for emissions. The MAF harness is left unchanged, so you can easily switch back to MAF if you wanted.

I'm unsure how IAT compensation is implemented.

 

[twdorris]

The EVOs have a Fuel Temp sensor that is only used for emissions.

Very handy. You could also fab up a small board to drive the IAT sensor appropriately (2.2k up to +5v / 39k down to sensor ground) and buffer the input side of the ECU so you could run the IAT sensor on just about any ol' input. But if the EVOs have a spare temp input already, that's definitely nice.

Has everyone forgotten about the HKS VPC?

I think everyone has tried very hard to, yeah.

Nah, I guess it was an "OK" piece at one time. It had some serious issues, but it was also trying to work within the confines of some serious restrictions placed on it just by the nature of its function.

TWDorris, you've mentioned before about the need for ECT fuel compensation to taper off at higher airflow levels. I could've sworn that the 12 byte table at FC23 does exactly that (e931 code base). Have I misinterpreted the code?

What I've mentioned is a need to switch from ECT to IAT compensation for airflow. The table you're referencing is actually used as an adjustment to another table that's used to adjust fuel delivery for what I presume would be related to cold cylinder walls and poor fuel atomization.

Using that table to adjust for what's actually an airflow metering issue would be similar to adding some value to airflow to account for deadtime, IMO. It could sorta do a similar function for the ECT side of things, but I personally prefer to keep functions working as they were intended.

Besides, ECT compensation is a relatively minor problem anyway. As I mentioned above, you could probably ignore the ECT compensation entirely if you wanted. What you need is a similar weighting function of IAT; at least based on the data we've collected. Logs and such are posted on our SD 101 page if anyone wanted to review and give some thoughts.

Thomas Dorris
ECMTuning, Inc.

 

[dannyd97gst]

Just some FYI I'm sure most of you smart guys know. Chrysler has used sd for years with no problems, Ford and GM guys can't comprehend how on earth sd works. The coolest thing is sd cars for the most part run fine with vacuum leaks maf cars will not. And the new Taurus SHO is using sd and di, which I find humorous b/c I now work at a Ford dealer and the tech's here look like deer in headlights trying to figure out "why".

 

[J-speed99]

Well, they are a sponsor, they can't be trash talked like "stupid ebay parts".

So what your saying is as long as you give tuners enough money you can sell any piece of crap (not saying link is crap) you want and no one can post about how much of a piece of crap it is.

 

[99gst_racer]

I was wondering if we could have a thread on here where everyone that uses or would like to switch to speed density could post openly without getting deleted or even banned from talking about link? How does it help the DSM community to delete every post that has anything negative about DSMLink in, alot of people would probably like to know.

Nobody has ever been banned for talking about DSMlink. That's ludicrous to think that. Any suspensions received were because that person wasn't bright enough to follow simple instruction.

So what your saying is as long as you give tuners enough money you can sell any piece of crap (not saying link is crap) you want and no one can post about how much of a piece of crap it is.

You guys are horrible about staying on topic. And you wonder why posts get deleted...
This thread is about speed density, not how DSMtuners handles supporting vendors.

My post was in no way an invite for off-topic discussion either. If you have something to say that isn't directly related to speed density, then please PM it to me.

 

[the_mork]

Evo8 SD is very interesting in that it is designed to fit very neatly within the stock code so it does some amount of calculation to come up with an uncompensated value which it then places where the MAF signal would generally go. After that the stock code is allowed to take care of all of the environmental and dynamic changes involved in managing an engine. The IAT sensor is there to replace the sensor lost when we pull the MAF out of the car and the scaling for the original sensor is altered to match the GM AIT. Obviously there are some differences because the sensor is moved post-intercooler but once you manage to figure out how to make SD load match up with MAF load then you just have to fine tune to make the car responsive and make transients work well, using the stock code probably helps quite a bit to make it predictable for the average tuner.

I should also mention that I agree SD is not necessarily a better system. I prefer it because it gets rid of the stutter and knock that I was getting on liftoff when my bov purged almost right into the back side of the MAF. Not having an issue with getting the car home if I have an issue with a major boost leak is a plus as well.

 

[twdorris]

Evo8 SD is very interesting in that it is designed to fit very neatly within the stock code so it does some amount of calculation to come up with an uncompensated value which it then places where the MAF signal would generally go.

Yes, exactly. I think that's how it kinda has to work without driving yourself insane rewriting everything under the sun. That's certainly how our implementation works. We define a fixed frequency-to-volume scalar (so we aren't using the factory MAF compensation table, which has no meaning to SD) and then just create a volumetric number that fits into the typical MAF signal location. With the correct scaling, all the factory load stuff works automatically.

IAT we just feed though the stock intake temp compensation field.

Thomas Dorris
ECMTuning, Inc.

 

[the_mork]

So in essence the two systems work very similarly. I'm definitely not smart enough or good enough with programming to think up a system like that but looking at the systems available that approach really does seem to be the best in a lot of ways, it reduces the amount of coding involved, keeps factory reliability and predictability, and is really elegant.

It appears that you don't closely monitor what is happening in the evo8/9 ecuflash community which makes sense since it isn't your customer base and you're more than capable of coming up with your own ideas but I thought you might find it interesting to know that the community has now developed DMA logging which can fill an excel spreadsheet to its limits (2003) in a matter of seconds and livemapping which allows evos to alter pre-defined fields without shutting the car down. Now if only we could come up with nice wizards and auto-tuning programs we could have a very nice newb friendly package but so far the prevailing mentality has been that you should really just learn what goes on which isn't all bad.

I've always liked what I've seen of your product but I've never felt like I could afford it so I do like to keep an eye on what you are up to so I hope you don't mind if I ask a few questions about the direction of your development.

First, why don't you support wideband logging via serial port? Or do you? I tried logging through the rear02 input for a while and I never felt confident that I was getting really good readings because of potential issues like voltage drop or signal noise because of poor connections and varying gauge wire. With serial logging this is nearly eliminated and it really makes it harder (I would guess) to use the AEM UEGO with link.

Second have you looked into gear dependent boost control? I've just tried this and I love it to pieces in every way. Is good boost control of any kind even possible with DSM ecus? If anyone would know that I would imagine it would be you, Jeff, or Steve, I know Ceddy hasn't looked into it quite yet.

 

[jrohner]

Second have you looked into gear dependent boost control? I've just tried this and I love it to pieces in every way. Is good boost control of any kind even possible with DSM ecus? If anyone would know that I would imagine it would be you, Jeff, or Steve, I know Ceddy hasn't looked into it quite yet.

Yeah, I never want to have a MBC again! I have not moved to gear-based boost control yet, but that'll be handy launching on a slippery track.

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. You could do it pretty easy using a slightly modified version of the EGR code, which already has tables and everything.

 

[twdorris]

So in essence the two systems work very similarly.

Sounds like it. Although I'm still curious about how the EVO system responds to changes in IAT at idle. Anyone care to run a quick test? You would basically idle for a minute, logging STFT and selected LTFT and IAT. Then stand on the stutterbox for about 30-40 seconds building 10-15psi to heat soak everything and let the IAT's rise by, say, 40-50F from where they were before then let off the throttle and let it idle for a minute again. I'd like to see what STFT and selected LTFT do at that point.

I thought you might find it interesting to know that the community has now developed DMA logging

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.

livemapping which allows evos to alter pre-defined fields without shutting the car down.

Yeah, copy important stuff to RAM and change on the fly. That's the basis for our stuff as well.

First, why don't you support wideband logging via serial port?

Well, this will be a matter of opinion, but I don't personally care for that. I would prefer to have the data come into the ECU where the ECU can do stuff with it. If I felt there was a question about accuracy, I'd find some way to measure it. For example, if you're running a stock O2 and have wideband coming in on another input, just average the values of the wideband while the stock O2 is cycling in normal closed loop. If the WB reading is averaging around stoich, you can feel pretty confident about the signal.

Second have you looked into gear dependent boost control?

Yeah, definitely. It'll come with time, I promise. There's certainly no reason a DSM ECU couldn't do it. We'll just have to code up the logic and make it happen. It's been on that "todo" list for about a year now. Gotta prioritize things, unfortunately. EVO1-3 first, ECMLink lite next and then boost control. That's the current plan.

Unfortunately, although I've enjoyed the conversation, I think we're getting off topic... We should probably move this offline.

[email protected]

Thomas Dorris
ECMTuning, Inc.

 

[the_mork]

Sounds like it. Although I'm still curious about how the EVO system responds to changes in IAT at idle. Anyone care to run a quick test? You would basically idle for a minute, logging STFT and selected LTFT and IAT. Then stand on the stutterbox for about 30-40 seconds building 10-15psi to heat soak everything and let the IAT's rise by, say, 40-50F from where they were before then let off the throttle and let it idle for a minute again. I'd like to see what STFT and selected LTFT do at that point.

I would happily do this for you but it wouldn't show you anything useful at this point since my car has an overrun FPR.

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.

It doesn't come out wrong at all, I was mentioning it because in another discussion you had it mentioned as a deficiency, it still isn't as clean as yours but we are getting there. It was merely something I thought you might find interesting.

Yeah, definitely. It'll come with time, I promise. There's certainly no reason a DSM ECU couldn't do it. We'll just have to code up the logic and make it happen. It's been on that "todo" list for about a year now. Gotta prioritize things, unfortunately. EVO1-3 first, ECMLink lite next and then boost control. That's the current plan.

Unfortunately, although I've enjoyed the conversation, I think we're getting off topic... We should probably move this offline.

[email protected]

Thomas Dorris
ECMTuning, Inc.

If it helps you at all the coding is actually done already in the ecu, at least for an evo. It just has been misunderstood for a long time and set at a level that it never gets used. We can also take this back to the topic. I think we covered everything that I wanted to mention that wasn't on topic. If there is something else you wanted to say then by all means we can move it to PMs or email or start a new topic.

 

[the_mork]

It is worth noting I think that in general SD systems suffer from a lean tip in issue and the reverse on liftoff. Now I could care less about liftoff behavior as long as it doesn't try to buck but dealing with lean tip in has been taken care of in the evo community by adding an asynchronous fuel pulse on throttle delta.