I'll tell you, i use what i guess is V1, that is based off of the e931 code. It is from 2006 and works absolutely great They started this in 05, so 4years of speed density experience for DsMap, beta testing for EcmLink, The decision should be a no-brainer
That's even without getting into the cost comparison
Not to mention ... there has been zero contact from them to our team... at all. If they had something that I planned on implementing, you know I'd atleast ask them some of the bugs they encountered.. etc.
Lastly, they have released 0 information on how they plan on making it work. If it ends up being based off of Nicks code, the red flag goes up for me. If it ends up working like the maf clamp, that is another red flag... lol. I'm a skeptical guy, and you won't find me running 'experimental code' without some kind of explanation of how they are going about using it.
I really wish the secrecy would just end. I can't stand how things are being ran, all over the place. People are so mis-informed and willing to fight you tooth and nail over it. Someone needs to break these walls down, and get everyone to come to an agreement, that the consumer / enthusiast is more important than the alternative, be it money/power.
But as it has been already said. We've been running native speed density code for over 4 years now, and that includes only additions to the code, which are quite few. It took it this long to find one weird bug, which we have already fixed.
If you'd honestly ask me you wanted to go speed density but you don't feel like your setup requires full stand-alone, I'd say use jackal for 1gs, and go evo8 + sd code for 2gs. The cool part of either is that you know your gunna be out maybe 10% of the cost if you ever plan on going full stand-alone. Ostrich's sell so fast... that Craig at moates.net usually is out of stock, and all the evo jazz, i'm surprised that hasn't taken over the entire planet.
____________________________
JACKAL lead developer
Advertisement
To browse the forums without the advertisements above, Login/Register
Hey guys, just a question.
Does the code modifications aplicable to e931 work on the dsm map BIn also?
I mean If i want to change something that in e931 is at 7000h adress, will it work on dsmap bin too? Or the code is totally different and adresses doesn't match anymore?
Not to mention ... there has been zero contact from them to our team... at all. If they had something that I planned on implementing, you know I'd atleast ask them some of the bugs they encountered.. etc.
Lastly, they have released 0 information on how they plan on making it work. If it ends up being based off of Nicks code, the red flag goes up for me. If it ends up working like the maf clamp, that is another red flag... lol.
But as it has been already said. We've been running native speed density code for over 4 years now, and that includes only additions to the code, which are quite few. It took it this long to find one weird bug, which we have already fixed.
Are you referring to the 29LB and/or 7500RPM issue? I was going to ask on that, since I'm prepping a head to go to 8500RPM. Answered my question before I even thought to ask it!
Lastly, they have released 0 information on how they plan on making it work. If it ends up being based off of Nicks code, the red flag goes up for me. If it ends up working like the maf clamp, that is another red flag... lol.
I'm kind of curious as well! Is V3 new code or based off of e931? If it's e931, i wouldn't be surprised to see some of Nick's code showing up It works well
Hey guys, just a question.
Does the code modifications aplicable to e931 work on the dsm map Bin also?
I mean If i want to change something that in e931 is at 7000h adress, will it work on dsmap bin too? Or the code is totally different and adresses doesn't match anymore?
Anyone?
I currently have done some mods on the e931 code that I wouldn't like to lose if I switch to speed density. So If anybody know if both code adresses are the same or not (except the speed density modification code part) it would be good to know.
Right. You can't modify the code yourself, unless you have Hak's permission. I think it would be fun to mess with the code like I did with Tunerpro - but generally any mods that you want done, you can suggest and they'll probably make their way into the Jackal code later on. Or if you had some experience, you could become part of the development team and really make some things happen.
Hey guys, just a question.
Does the code modifications aplicable to e931 work on the dsm map BIn also?
I mean If i want to change something that in e931 is at 7000h adress, will it work on dsmap bin too? Or the code is totally different and adresses doesn't match anymore?
The ds2's jackal works with are encrypted files.
Now before there is some lengthy bs about it, let me tell you, there are plenty of other ways around it. But the fact that some of our mods, and fixes to Nicks posted code are in the eeprom code, and that is what we are trying to protect.
If you have legitimate mods your willing to share with the rest of the dsmap community Miky, post your *working* code, and I will make sure it gets added to the next release.
However to be frank, I'm really pretty close to the edge of closing dsmap down completely. More people are interested in what they can get from me, and everyones ####ing hard work, than what they can do to further the development. I've got assholes now, specifically just trying to tear us down. I just got a guy that joined, spam with emoticons just to dl the software. It is really taking its toll on me.
The worst part, those people will never see this post.
____________________________
JACKAL lead developer
:O I hope that never happens! There's always going to be leechers hak, don't let them get to you man. I want to run sd using jackal eventually but I'm still playing around with ostrich/tunerpro at the moment. You are a HUGE asset to the dsm community and it would be extremely sad to lose it all because of a few idiots.
It's outrageous to even suggest such a possibility.
Thomas Dorris
ECMTuning, Inc.
How is that considered outrageous when we know 3 other individuals that are actually selling sd code based on specifically our revised code from Nick. You really ought to have some kind of a relationship with me, its good to know how other people are doing. All the people that talk about me, I talk with, even if it gets my account deleted from ddsm.
But I didn't suggest that you are, but the lack of iat compensation is making me start to wonder.
It isn't like it is a bad thing, to look at the notes, I'm just saying, a carbon copy like the other guys, just pisses me off to no end. I've looked at your apps source, since you share it, but if I were to write anything that your source helped me along with you'd be sure to know it.
If you want to have a serious conversation about it, there's plenty of places you can find any of my infos at, I can't stand being moderated here.
____________________________
JACKAL lead developer
The rest of the world. Ask JeffO about it, there is some really good shit that has been written, and we really don't want other people knowing it. The same reason ECMLink is protecting their stuff.
____________________________
JACKAL lead developer
How is that considered outrageous when we know 3 other individuals that are actually selling sd code based on specifically our revised code from Nick.
I know 3 other people that were copying our stuff too. But I've never even hinted that you guys were doing it. So please stop suggesting we are. It's crazy. I thought we had covered that in the other thread a few months back.
Quote:
Originally Posted by hakcenter
but the lack of iat compensation is making me start to wonder.
Lack of IAT compensation? There is no lack of IAT compensation. It's fully supported. We've basically defined a cross over function to gradually transition from coolant-based compensation to air temperature-based compensation based on airflow rate. This solves the issue we noted in our testing where IAT compensation was unnecessary at low airflow but became more necessary as airflow rate increased. The theory is that at lower airflow, the air is heated to engine temperature anyway. So any measured temperature before that point is irrelevant. At higher airflow, the air entering the cylinders retains more and more of its original temperature, increasing the need for temperature compensation.
But that's just a theory. It's the empirical data we're basing the implementation on.
I see you're starting to run into many of the same issues we had some 7 years ago with people copying our stuff and sell it on e-bay. That period of my life was one of most depressing and infuriating times ever. To see someone just blatantly copy your stuff and sell it off as their own makes me see red faster than anything imaginable.
At higher airflow, the air entering the cylinders retains more and more of its original temperature, increasing the need for temperature compensation.
But that's just a theory. It's the empirical data we're basing the implementation on.
I'd have to go ahead and disagree on that. The reason you 'may' want compensation is because, as flow rate increases exponentially, the air flow variance from temperature increases.
At 200cfm, 5-10cfm difference isn't going to matter, from -60 to 240+. What is gunna matter is when your flowing 50lbs/min, that is going to make a substantial difference on the tune, if you are uniformly adding fuel based on idle characteristics.
Depending how people are going to tune the setup, there is no need for compensation anyways.
____________________________
JACKAL lead developer
I'd have to go ahead and disagree on that. The reason you 'may' want compensation is because, as flow rate increases exponentially, the air flow variance from temperature increases.
At 200cfm, 5-10cfm difference isn't going to matter, from -60 to 240+. What is gunna matter is when your flowing 50lbs/min, that is going to make a substantial difference on the tune, if you are uniformly adding fuel based on idle characteristics.
Depending how people are going to tune the setup, there is no need for compensation anyways.
The way I read it, you are both in agreement.
____________________________
11.514 on a 14b
10.31 @142.76MPH on a GT35
The theories are different, the end result is the same.
The faster the air is moving 'speed wise', drops the efficiency of your intercooler.
It is just specifically the 'amount' of air, because the motor is running well beyond 100% VE.
But here is the real question, would anyone have ever noticed the need for compensation, when even the maf sensor cannot account for the actual air charge temps anyways ?
Tune on a cold day and be done
____________________________
JACKAL lead developer
Now before there is some lengthy bs about it, let me tell you, there are plenty of other ways around it. But the fact that some of our mods, and fixes to Nicks posted code are in the eeprom code, and that is what we are trying to protect.
If you have legitimate mods your willing to share with the rest of the dsmap community Miky, post your *working* code, and I will make sure it gets added to the next release.
However to be frank, I'm really pretty close to the edge of closing dsmap down completely. More people are interested in what they can get from me, and everyones ####ing hard work, than what they can do to further the development. I've got assholes now, specifically just trying to tear us down. I just got a guy that joined, spam with emoticons just to dl the software. It is really taking its toll on me.
The worst part, those people will never see this post.
Ok, I'll try to do a list of the goodies I use and post it on the dsmap forum.
The faster the air is moving 'speed wise', drops the efficiency of your intercooler.
You're right, we're going to disagree on this. I fully expected it. But based on the data we have, it's engine temperature that matters.
The intercooler is irrelevant because the IAT is measuring that result for you. Hot day, hot IC, higher charge temps. Cold day, cold IC, cooler charge temps. That's what the IAT is there for. Hotter air will have a higher pressure for a given volume. Our volume is fixed here. So you simply have to account for pressure and temperature (and because it's all dynamic, VE). Unless your VE table is indexed by temperature, it can't account for differences in temperature. You have to do it outside the VE table.
The problem seems to be *where* to measure the air temperature. If you measure it out in the upper IC, then by the time the air reaches the engine, its temperature has changed. We see this effect very clearly in our longs following a cold start. As the engine (water temps) heats up, the compensation need to the airflow calculation changes despite having a constant air temperature the whole time (and a constant IC temp I might point out).
Again, you can achieve a similar result with a VE table of some sort only if the VE table is indexed by temperature. So if we defined a second VE table that had air temp on one axis and coolant temp on the other, you could adjust with that. But since this effect is defined for us by physics, it didn't make sense to force the user to adjust it. So it's done internally with two separate tables. One defines coolant temperature compensation relative to a reference coolant temperature and the other defines air temperature compensation relative to a reference air temperature. Then we provide an adjustment table where the user can defined, based on airflow rate, how much of each factors in. If you don't want to run on air temperature, that's not a problem. Zero it out.
Quote:
Originally Posted by hakcenter
But here is the real question, would anyone have ever noticed the need for compensation, when even the maf sensor cannot account for the actual air charge temps anyways ?
Please explain. A mass air sensor certainly does take into account changes in air charge temps. That's the benefit to measuring mass (or at least he components that go into calculating mass as in the case of our stock airflow sensor). You don't have to deal with these variations as a result because you're measuring mass "directly".
Go test it on a water intercooler packed with ice, and let me know your findings.
Your axis needs to be three dimensional as well. Don't forget to toss in pressure.
I'm sorry, but IMO your responses are too terse to be meaningful. Without some valid explanation of the physics behind what you're suggesting or at least some response to my points above, I have nothing else to add.
I'd like an open discussion of the concepts here, if you're interested in discussing such.
Eventually your going to learn that there is an acceptable amount of variance, that the end user is going to have to tune out. Tuning a car in the cold, is going to keep their tune safe, in the heat.
I'm letting you know that the way you guys are going about your speed density is extremely cumbersome.
We don't need 'science' here to figure out the basic's of air moves faster at higher flow rates from the turbo. Leaving less time for heat exchange from the air to intercooler.
____________________________
JACKAL lead developer
one thing about hak that i have seen from reading in his domain and here is that unless hes got decient info/facts 9 times out of 10 hes deff right or he woudlnt make a stink about it he deff knows his s#$t...end of story. Excuse me, not meaning to into the middle of this or take sides etc. etc. just somethng to note
The problem here is that he's offering insufficient (or at the very least, incomplete) explanations for his theories. And, at this point, there's not much else to discuss as a result.
Personally, I find it inconsistent that he feels heat exchange works one way in the IC but not the same way near the head. Coolant temps play a roll at low airflow. They just do. If you're willing to ignore that at startup, fine. Fuel trims will probably save the day. But we're not satisfied with that.
I also find it odd that he seems to feel an IAT sensor won't compensate for the very effect he's referring to with his IC efficiency comments. That's what IAT compensation is for...to compensate for varying air temperature. It's largely irrelevant what caused it to vary. It varies, you compensate for it and the user doesn't have to do a thing. Cumbersome? Not at all. It's automatic and transparent.
On the one hand, he "demands" an open discussion previously in this thread and slams us for being so secretive, but then when you try to start a discussion about the theories and science behind them, he clams up. It's like we're dealing with dual personalities here.
imagine if his crew joined your crew.....why donsnt anyone start a debate about that..TOM i know alot of things are up for debate it seem everyone has something to say about somthing, but it comes down to is whats a better product and what gets the job done and for the cheapest. also for me, the crew and the people willing to make sacrifices to help out the troubleshooting customers is what puts the extra edge on also. thats what people are coming in the thread to read bro. dont take it the wrong way appoligies if i offended anyone
The problem here is that he's offering insufficient (or at the very least, incomplete) explanations for his theories. And, at this point, there's not much else to discuss as a result.
Personally, I find it inconsistent that he feels heat exchange works one way in the IC but not the same way near the head. Coolant temps play a roll at low airflow. They just do. If you're willing to ignore that at startup, fine. Fuel trims will probably save the day. But we're not satisfied with that.
I also find it odd that he seems to feel an IAT sensor won't compensate for the very effect he's referring to with his IC efficiency comments. That's what IAT compensation is for...to compensate for varying air temperature. It's largely irrelevant what caused it to vary. It varies, you compensate for it and the user doesn't have to do a thing. Cumbersome? Not at all. It's automatic and transparent.
On the one hand, he "demands" an open discussion previously in this thread and slams us for being so secretive, but then when you try to start a discussion about the theories and science behind them, he clams up. It's like we're dealing with dual personalities here.
Thomas Dorris
ECMTuning, Inc.
Do you feel it necessary to over explain everything ? Just because I can explain something in a simple sentance doesn't make me clammy. If my theory is wrong, why don't you go test your 'head heats the air up theory' and run a iced out water intercooler, and post your findings.
The effect should be the same if your correct would it not ?
My whole point is, the stock code already has coolant enrichment, which accounts for the effect your already describing. If your not using it, wupty do.
I don't need a wall of text to feel superior, remember that every day, people with all sorts of iq ranges read what is displayed, and the easier it is to read, the better off everyone is. I don't need the need to type something that is already well known, and matter of fact is on wikipedia.
You speak of a phenomia that is only occuring as boosts increases. Yet coolant temps remain the same. That should be a flag right there in your head. It is the same exact princible with cams, you add time to fill each cylinder with bigger lifts or longer durations.
The intercooler is loosing efficiency because the air is traveling through it at a much higher rate.
Test this out in your car sometime. When your air conditioner is on, is the air the coldest when the fan is on the lowest setting, or the highest? When your heater is on, is the air the hottest when the fan is on the lowest setting, or the highest?
Cumbersome ? Yes. Why? You've already increased the eeprom size for your 1gs, and our code fits still in the stock size. I can only imagine all the extra work you put on the ecu. We have goals, and the minimalistic approach aparently works, it has been working for over 4 years.
____________________________
JACKAL lead developer
This is counter-productive at this point. Sorry for trying to have an actual discussion with content and meaning.
Thomas Dorris
ECMTuning, Inc.
Its pretty evident hes ignoring the questions your providing, I dont honestly think you two are on the same level, hence why he dont want to do an open discussion or go "toe to toe" with you guys. Im an avid dsmlink user, and probley wont even be switching to speed-density, not when 781awhp was made by a fellow dsmlink car with a maf-t...how many DSmap customers did the same? Or run 8 second quarter mile times? Tom and Dave have been backing the dsm community for years, there forums are the best DSM related forums available with A WEALTH OF DSM KNOWLEDGE. We even have members who literally can dial in your cars setup.....for free. Tom and Dave just keep doing what your doing, you guys really are making great sucess with these cars.
firebird, thanks for the support. But that type of reply will only make situations worse, IMO. I'm not looking for a fight. I though Curtis wanted a discussion. But short one-line responses with challenges are not a discussion to me.
Its pretty evident hes ignoring the questions your providing, I dont honestly think you two are on the same level, hence why he dont want to do an open discussion or go "toe to toe" with you guys. Im an avid dsmlink user, and probley wont even be switching to speed-density, not when 781awhp was made by a fellow dsmlink car with a maf-t...how many DSmap customers did the same? Or run 8 second quarter mile times? Tom and Dave have been backing the dsm community for years, there forums are the best DSM related forums available with A WEALTH OF DSM KNOWLEDGE. We even have members who literally can dial in your cars setup.....for free. Tom and Dave just keep doing what your doing, you guys really are making great sucess with these cars.
You can use a hammer and nails, or a nail gun.
Both do the same thing, one does it better.
Just because we don't have 'insane one of a life time dyno's does not make us inferior.
When we post making 30whp gains, on setups already making +300whp, by changing out maf sensors, that is a step in the right direction. I bet that 781awhp cars tune goes out of whack every 3rd day, because that gm maf is just so reliable, there are posts everywhere you look talking about 'how amazingly' accurate and tune reliable they are.
Find me one person that has used jackal with success, that would go back to a metered air flow system.
Ingoring questions? lol, where's the question mark in any of toms replies. Aparently he is stating fact like I am, two conflicting ideas bound to wage war for eternity. I on the other hand assume I'm wrong in any arguement. Someone is not taking the time, who has the resources, to validate either part of the arguement. The funny thing is, the cylinder head, nor the engine block, at higher rpms does not have enough time, to radiate any significate amount of heat, that otherwise would not be apart of basic enrichment.
Should I state the science of how raising cam profiles increases available air for valved motors, which increases power output at higher rpm ? This would be the exact same effect for heat exchange, that being time. So how is the air getting hotter in less time? turbo effeciency. How do you get that air charge cooler when you have less time to do it in ? Think radiator. Ever had a old car that overheated, install a hottter, yes i said hotter thermostat in it, so the water has more time to cool down inside the radiator (Worked great for my bros stang that had no problems besides radiator mis-sized). Either increase surface area (bigger intercooler) or decrease temp (ice water intercooler).
____________________________
JACKAL lead developer