TephraMOD V6 - testing!
I concur. The wiki is modifiable by anyone and is a great resource for just such a task. I submit that you and others should help to make contributions to it to bring it up to speed.
I think the problem you'll find here is that:
1) Code people are so behind on code and questions that updating the wiki falls far on the list. Of course thats the unfortunate part of the tail wagging the dog, but unfortunately their time is probably better spent elsewhere.
2) Most people (us peons) are not willing to do the searching first, reading first, or to put in the time/effort to update the wiki or even read it when necessary. It is an unfortunate thing that we are all guilty of partially because of time constraints and else because of lack of effort. If this was not the case then the wiki would be fully up-to-date every moment.
3) Even if the wiki was perfect and current, new users still get frustrated trying to get their foot in the door (or gain their rights of passage) and resort to diluting useful information/conversation hubs. Unfortunately it is often the case that no amount of introductions, walk-throughs, or detailed wikis (and big, bold pointers to them) can prevent this.
I'm not trying to be a jerk, and I'm not trying to be destructive or get on your nerves, but your pleasant picture of a perfect world just doesn't seem to work as perfectly in a world with real constraints. I appreciate the effort, but in this world the onus remains on you [as in: every end user] because in the end the people who can do the good work have the option to continue to do it or just stop. We can aid their decision to continue to do it through our own support and efforts or we can make their life harder and aid their decision to eventually stop... Either way the solution to move things in the correct direction eventually lies in [y]our hands, not theirs.
I think the problem you'll find here is that:
1) Code people are so behind on code and questions that updating the wiki falls far on the list. Of course thats the unfortunate part of the tail wagging the dog, but unfortunately their time is probably better spent elsewhere.
2) Most people (us peons) are not willing to do the searching first, reading first, or to put in the time/effort to update the wiki or even read it when necessary. It is an unfortunate thing that we are all guilty of partially because of time constraints and else because of lack of effort. If this was not the case then the wiki would be fully up-to-date every moment.
3) Even if the wiki was perfect and current, new users still get frustrated trying to get their foot in the door (or gain their rights of passage) and resort to diluting useful information/conversation hubs. Unfortunately it is often the case that no amount of introductions, walk-throughs, or detailed wikis (and big, bold pointers to them) can prevent this.
I'm not trying to be a jerk, and I'm not trying to be destructive or get on your nerves, but your pleasant picture of a perfect world just doesn't seem to work as perfectly in a world with real constraints. I appreciate the effort, but in this world the onus remains on you [as in: every end user] because in the end the people who can do the good work have the option to continue to do it or just stop. We can aid their decision to continue to do it through our own support and efforts or we can make their life harder and aid their decision to eventually stop... Either way the solution to move things in the correct direction eventually lies in [y]our hands, not theirs.
Last edited by fostytou; May 15, 2009 at 11:31 AM.
Not that it matters but I thought it might be worth pointing out.
Evolving Member
Joined: Feb 2008
Posts: 254
Likes: 1
From: SoCal
For minor version numbers, sure, but not for the initial primary version number, as in this case.
Evolving Member
Joined: Feb 2008
Posts: 254
Likes: 1
From: SoCal
fostytou,
You make some valid points, but in my significant experience in real world software development it actually results in LESS work for all involved, expecially the support network, if there is a single, well laid-out, clear site with all of the relevant information for people to refer to.
You are right that most people either don't have the time or are too lazy to read through 800 posts, which results in the relevant info being spread out all over the place, the same questions being asked over and over again, and excess time and effort on behalf of all those involved.
And you are right that the onus is on all of us to help out. Look for me to become more involved helping out as I come up to speed.
You make some valid points, but in my significant experience in real world software development it actually results in LESS work for all involved, expecially the support network, if there is a single, well laid-out, clear site with all of the relevant information for people to refer to.
You are right that most people either don't have the time or are too lazy to read through 800 posts, which results in the relevant info being spread out all over the place, the same questions being asked over and over again, and excess time and effort on behalf of all those involved.
And you are right that the onus is on all of us to help out. Look for me to become more involved helping out as I come up to speed.
fostytou,
You make some valid points, but in my significant experience in real world software development it actually results in LESS work for all involved, expecially the support network, if there is a single, well laid-out, clear site with all of the relevant information for people to refer to.
You are right that most people either don't have the time or are too lazy to read through 800 posts, which results in the relevant info being spread out all over the place, the same questions being asked over and over again, and excess time and effort on behalf of all those involved.
And you are right that the onus is on all of us to help out. Look for me to become more involved helping out as I come up to speed.
You make some valid points, but in my significant experience in real world software development it actually results in LESS work for all involved, expecially the support network, if there is a single, well laid-out, clear site with all of the relevant information for people to refer to.
You are right that most people either don't have the time or are too lazy to read through 800 posts, which results in the relevant info being spread out all over the place, the same questions being asked over and over again, and excess time and effort on behalf of all those involved.
And you are right that the onus is on all of us to help out. Look for me to become more involved helping out as I come up to speed.
I completely agree with you. It is just a matter of getting everyone on-board the open information boat. If it is there and easier to find, it is bound to be asked less, incorrectly questioned less, incorrectly interpreted less, and overall more helpful. I appreciate anything you have to add. Please note the link to the wiki in my sig (if you are having trouble finding your way there).
EDIT: I added some of the points you brought up to the Tephra Section:
http://evoecu.logic.net/wiki/TephraMod
Last edited by fostytou; May 15, 2009 at 02:35 PM.
David, thanks for the explanation.
I submit that if there was a well organised and well maintained fixed download location, with both the latest official release, and also the currently in-development release (alpha/beta test releases), each with a list of:
- feature upgrades
- bugs fixed
- known problems
- relevant notes
- etc.
that it would actually significantly decrease the amount of support time both you and others generously dedicate to answering questions. Most established community-driven software projects are organized this way for this exact reason, and also for ease of use.
This thread would then likely only contain entries from people submitting feedback and error reports related to the latest test release. And then anyone asking questions already answered could simply be referred to the download location for more info.
Actually, in the software world it is very unusual for a software release to skip a version number, so in this case despite spending several hours reading many hundreds of posts, it was not expected.
I submit that if the software releases were better organized as suggested above:
- none of the extra 1/3 of the 800 posts would even be necessary (mine included)
- only those submitting feedback or discovered problems (and those interested) would even have to read the 800 (which would then be significantly reduced in number) posts in the first place
I'm trying to provide constructive suggestions here that sould significantly increase the ease of use, and decrease the amount of time required for all concerned (development and support community in particular).
And again, I am very grateful for the time and effort that everyone in the community spends both developing and supporting EcuFlash.
I submit that if there was a well organised and well maintained fixed download location, with both the latest official release, and also the currently in-development release (alpha/beta test releases), each with a list of:
- feature upgrades
- bugs fixed
- known problems
- relevant notes
- etc.
that it would actually significantly decrease the amount of support time both you and others generously dedicate to answering questions. Most established community-driven software projects are organized this way for this exact reason, and also for ease of use.
This thread would then likely only contain entries from people submitting feedback and error reports related to the latest test release. And then anyone asking questions already answered could simply be referred to the download location for more info.
Actually, in the software world it is very unusual for a software release to skip a version number, so in this case despite spending several hours reading many hundreds of posts, it was not expected.
I submit that if the software releases were better organized as suggested above:
- none of the extra 1/3 of the 800 posts would even be necessary (mine included)
- only those submitting feedback or discovered problems (and those interested) would even have to read the 800 (which would then be significantly reduced in number) posts in the first place
I'm trying to provide constructive suggestions here that sould significantly increase the ease of use, and decrease the amount of time required for all concerned (development and support community in particular).
And again, I am very grateful for the time and effort that everyone in the community spends both developing and supporting EcuFlash.
Also, it wouldn't hurt to have a small doc in each release(both final and beta) explaining the "How-To" parts as well as fixes and known bugs. This will also cut down on constant questions.
I'm EXTREMELY grateful for everything Tehpra, MalibuJack, MrFred, fostytou and everybody else involved in this. This is NOT a knock on them at all.
Moreover, i think the WIKI is a great place to host this info. I would be more than willing to help organize this stuff on the wiki. I have extensive tuning experience and use to work with Hondata, so i am very versed on how to keep software versions in-line and organized, especially involving ever changing versions. I delt with this a lot when i was helping Hondata develop K-Pro and other software/hardware tuning tools.
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
internet explorer was a classic example of skipping a major version.
v3,v4 were internal releases, v6 was a test release - but then due to my car incident work sorta stopped for a while, and then I re-wrote the code and came up with a new way of packaging everything so v7 was born...
v3,v4 were internal releases, v6 was a test release - but then due to my car incident work sorta stopped for a while, and then I re-wrote the code and came up with a new way of packaging everything so v7 was born...
Well I am having some weird issues, car drives OK but my logging is messed up. Here is what is happening. I no longer am getting the p0505 code (turned off that periphery bit). But what is happening is my 1 byte load is jumping low when I am doing pulls.
I have attached two log files so you can see what I mean:
Log 1 - 3rd gear pull (towards the middle of the log)
See how the load climbs the hits rock bottom then shoots back up again?
Log 2 - 2nd to 3rd gear pull (does it in both gears) - same issue as above
Again, this happens in all gears during pulls while capturing a log.
Anyone know what is causing this?
P.S. - I have my 1 byte load values the same 1.2 in my ROM and 1.2 in EVOScan....
I have attached two log files so you can see what I mean:
Log 1 - 3rd gear pull (towards the middle of the log)
See how the load climbs the hits rock bottom then shoots back up again?
Log 2 - 2nd to 3rd gear pull (does it in both gears) - same issue as above
Again, this happens in all gears during pulls while capturing a log.
Anyone know what is causing this?
P.S. - I have my 1 byte load values the same 1.2 in my ROM and 1.2 in EVOScan....
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
Zach - what is the max load do you expect to hit?
in that log1, you go from 252 -> 16.8 -> 14.4 -> 304.8
a 1.2 loadfactor allows for a max of 306load, any higher and it will loop over.
I would say you are hitting ~322 load there, so you need to think about using the 1.3 loadfactor...
1.3 * 255 = 331, so that fits nicely... maybe even 1.4..
Just remember the HIGHER the loadfactor the less resolution you get...
ie a LF of 1.5 means it goes 0 -> 1.5 -> 3 -> 4.5 -> 6...... etc
not really a big deal
in that log1, you go from 252 -> 16.8 -> 14.4 -> 304.8
a 1.2 loadfactor allows for a max of 306load, any higher and it will loop over.
I would say you are hitting ~322 load there, so you need to think about using the 1.3 loadfactor...
1.3 * 255 = 331, so that fits nicely... maybe even 1.4..
Just remember the HIGHER the loadfactor the less resolution you get...
ie a LF of 1.5 means it goes 0 -> 1.5 -> 3 -> 4.5 -> 6...... etc
not really a big deal
I didn't think I would be hitting that kind of load already....I will make the switch to 1.4 so when I start turning up the boost I am covered....sounds like a good reason why my load is messed up though
~Z
~Z
ok I see LOTs of posts all over the place about this and that, but wanted to share my experience. USDM 2005 Evo SSL, former v5.0 or v5.08? 96530006 convertee. Grabbed V7T5, copied over as many tables as possible from my old rom to the new one, left all my old XML in place to see what would happen....Tephra I LIKE the new system! I brought over immob definition and entire MUT table, etc etc etc, most of my previous mods all just worked, car runs awesome with the one and only exception of mrfred's direct boost mods. I gather this is because of the new gear-based boost setup. For the sake of testing, I zero'd out the error correction table and the car just rips, no problems, same as v5 just w/o the error correction.
Tephra, I didn't see a WGDC cycle for the alt-maps? Am I missing something? I'll go back through and read as much as I can through this thread, but I don't recall seeing anything about it thus far.
Also, THANK YOU for an awesome rom setup, this new one looks promising
Tephra, I didn't see a WGDC cycle for the alt-maps? Am I missing something? I'll go back through and read as much as I can through this thread, but I don't recall seeing anything about it thus far.
Also, THANK YOU for an awesome rom setup, this new one looks promising
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
psi boost should still work - you will just need to change the scalings on the BDEL/ALT BDEL tables in the TephraMod category...
what do you mean by "WGDC Cycle"?
what do you mean by "WGDC Cycle"?
Sorry, typo! I mean the 'alt base wastegate duty' table...I see only one for the base maps.
*EDIT* I see it in the XML, trying to sort it out now
*EDIT* I see it in the XML, trying to sort it out now
Last edited by scheides; May 17, 2009 at 07:41 PM.
Ok, checking back in now. I wanted to really take a hands-off perspective round one at this, and it *almost* worked. Some of the fields I mentioned above were not viewable because of overlapping names (or something) in EcuFlash I'm guessing due to the whole inheriting 96530006's xml.
Anyways, getting mrfred's direct boost to work does indeed look as easy as changing the scaling to 'psiag' on those two tables, then re-naming them (ditch the term 'load' for 'boost').
I'll go flash it on the car and give it a try tomorrow on the way to work.
Anyways, getting mrfred's direct boost to work does indeed look as easy as changing the scaling to 'psiag' on those two tables, then re-naming them (ditch the term 'load' for 'boost').
I'll go flash it on the car and give it a try tomorrow on the way to work.