TephraMOD V5.8 - testing help required
Jul 23, 2008, 07:19 AM
#121
Ted, I agree with a lot of what you're saying. It is frustrating to have to search through various threads trying to piece together what you need to do for your particular ECU. I also don't have any problem with a reasonable "subscription fee" for tephra's updates. I have already contributed as I'm sure you have done too.
The issue is one of organization which is common in these kinds of open source projects. Some folks, like myself, are learning about tuning as we go along while others, like yourself, are quite knowledgeable and some, well... they just think they know what they're doing. Heck, maybe I fall in that last group.
I think tephra and the others (like mrfred) are doing this because they enjoy it and I'm not sure tephra wants to run it as a business. (I could be wrong of course.)
Anyway, my point is that maybe he just needs a bit of help with the (dull) administrative stuff while he keeps working on the code. The consolidation of the ROMs is a good first step, maybe we just need someone to manage a small set of them (maybe someone for the 8s, 9s and soon 10s). I've been thinking about uploading my XML file that has been working fine with tephra's 5.8 and mrfred's direct boost (all for 94170015). If we just had a page (or a thread) to keep the ROM, XML and relevant links it would go a long way toward solving the problem. I'd do it now, but I am at work and can't post the files.
I guess in a round about way I'm volunteering to put some time into keeping track of this stuff, at least for the 8s. I don't mind putting things together for other cars/ROMS but I have no way to check them.
The issue is one of organization which is common in these kinds of open source projects. Some folks, like myself, are learning about tuning as we go along while others, like yourself, are quite knowledgeable and some, well... they just think they know what they're doing. Heck, maybe I fall in that last group.
I think tephra and the others (like mrfred) are doing this because they enjoy it and I'm not sure tephra wants to run it as a business. (I could be wrong of course.)Anyway, my point is that maybe he just needs a bit of help with the (dull) administrative stuff while he keeps working on the code. The consolidation of the ROMs is a good first step, maybe we just need someone to manage a small set of them (maybe someone for the 8s, 9s and soon 10s). I've been thinking about uploading my XML file that has been working fine with tephra's 5.8 and mrfred's direct boost (all for 94170015). If we just had a page (or a thread) to keep the ROM, XML and relevant links it would go a long way toward solving the problem. I'd do it now, but I am at work and can't post the files.
I guess in a round about way I'm volunteering to put some time into keeping track of this stuff, at least for the 8s. I don't mind putting things together for other cars/ROMS but I have no way to check them.
Jul 23, 2008, 07:23 AM
#122
The organization situation only gets worse, not better, as the volume of information increases.
The first step is to get all users of each respective model VIII, IX, and X to migrate to the latest ROM for that model. That alone significantly reduces the volume of work for each upgrade. If you are interested in programming your ECU, then the first thing you must do is upgrade to the latest version for your specific model, otherwise, you miss out on future support and upgrades.
We should all agree to do this.
The first step is to get all users of each respective model VIII, IX, and X to migrate to the latest ROM for that model. That alone significantly reduces the volume of work for each upgrade. If you are interested in programming your ECU, then the first thing you must do is upgrade to the latest version for your specific model, otherwise, you miss out on future support and upgrades.
We should all agree to do this.
Jul 23, 2008, 07:33 AM
#123
The second step is to create, test, and post a working v5.8 ROM for the VIII, IX (and X?). The ROMs will have the factory maps (which are user-defined anyway), and have working 3D MUT tables, all properly configured. We'll also post versions with direct boost control, for those who choose to run JDM MAP and/or who are otherwise limited to running <30psi.
With the ROMs should be published a working XML datafile for EVOScan 2.4.
With only 2-3 ROMs to work with, the picture suddenly becomes far easier.
With the ROMs should be published a working XML datafile for EVOScan 2.4.
With only 2-3 ROMs to work with, the picture suddenly becomes far easier.
Jul 23, 2008, 08:28 AM
#124
Evolving Member
What I'm also hearing is that there needs to be a post, hopefully stickied, that points out the very fact that each car has a "most up to date" ROM that they can "upgrade to". I say this because after reading a lot of threads (but not having read this one yet) I got the IDEA that this was the case but wasn't sure so I finally asked if I could actually just "upgrade" to 94170015 from my 94170008.
So now I know and when I do it I know I can just worry about getting new updates there ref: 94170015. But with a stickie post, written by someone who is actually in the know, unlike me, then everyone who comes here will realize that they need to upgrade to the latest ROM for their car. And that post could, pehaps, have the completely stock OEM version of that ROM. That is the first step before posting "complete" 5.8v Tephra ROMs be it subscription based or other wise.
Just my $0.02
So now I know and when I do it I know I can just worry about getting new updates there ref: 94170015. But with a stickie post, written by someone who is actually in the know, unlike me, then everyone who comes here will realize that they need to upgrade to the latest ROM for their car. And that post could, pehaps, have the completely stock OEM version of that ROM. That is the first step before posting "complete" 5.8v Tephra ROMs be it subscription based or other wise.
Just my $0.02
Jul 23, 2008, 08:34 AM
#125
At least one of the ROM switches isn't a case of "most up-to-date". 96940011 doesn't have a tephra-modded version because there is literally no room on the ROM for the additional code. So, anyone with a 2005 USDM VIII has to switch to 96530006, which is a Euro ROM for similar models. There's caveats to that, though: you currently lose the immobilizer, and at least a few folks have reported idle issues.
So, not all of these ROM switcheroos are as straightforward as "copy maps, be happy".
So, not all of these ROM switcheroos are as straightforward as "copy maps, be happy".
Jul 23, 2008, 01:42 PM
#128
The international aspect complicates it further though. There seem to be at least four groups of ECUs - JDM/UK, Aus, US, Euro. There are considerable hardware differences between them. Even within JDM IX there are three different versions for each of non-MR and MR which are not compatible. Then the UK has a further six different Evo IX maps, falling into two groups which are not compatible.
I've held off doing realtime mods to Tephra's 5.8 until it is mature and tested, as I think it would just complicate things further. I'm not sure anyone yet really knows what the bare minimum list of ECUs is and what can be safely upgraded to what?
I've held off doing realtime mods to Tephra's 5.8 until it is mature and tested, as I think it would just complicate things further. I'm not sure anyone yet really knows what the bare minimum list of ECUs is and what can be safely upgraded to what?
Jul 23, 2008, 01:45 PM
#129
Evolved Member
iTrader: (17)
Join Date: Nov 2005
Location: NNJ
Posts: 2,544
Likes: 0
Received 0 Likes
on
0 Posts
The organization situation only gets worse, not better, as the volume of information increases.
The first step is to get all users of each respective model VIII, IX, and X to migrate to the latest ROM for that model. That alone significantly reduces the volume of work for each upgrade. If you are interested in programming your ECU, then the first thing you must do is upgrade to the latest version for your specific model, otherwise, you miss out on future support and upgrades.
We should all agree to do this.
The first step is to get all users of each respective model VIII, IX, and X to migrate to the latest ROM for that model. That alone significantly reduces the volume of work for each upgrade. If you are interested in programming your ECU, then the first thing you must do is upgrade to the latest version for your specific model, otherwise, you miss out on future support and upgrades.
We should all agree to do this.
https://www.evolutionm.net/forums/sh...light=standard
I am with you 100% on your suggestions and I will do whatever I can to help these changes be made.
Not only will it make things more simple for new users, but more importantly it will free up the time that the few coders on the board spend troubleshooting people's setups.
Critically I think we need to get the coders to agree to only work on one rom version for each ECU type.
Last edited by dudical26; Jul 23, 2008 at 01:48 PM.
Jul 23, 2008, 01:57 PM
#130
dudical26, I think the final post in the thread you linked probably has about the nearest guide we have to interchangeability - ie match the first four digits. However, there are still probably more than two dozen variants of the first four digits for Evo 7-9, which are often not interchangeable.
Getting the coders to agree is fine, of the four of us (Tephra, Bez, mrfred, me, hoping not forgetting anyone here!) - in four different continents just about - all develop new stuff on four different ROMs, yet you might please many on Evom by just polishing one Evo 8 and one Evo 9 - both US models. Trouble is only mrfred actually has direct access to them to develop/test. I also suspect most of us are more interested in developing new things rather than doing the grind of releases. Tephra is doing a wonderful job, I hope he doesn't burn out!
Getting the coders to agree is fine, of the four of us (Tephra, Bez, mrfred, me, hoping not forgetting anyone here!) - in four different continents just about - all develop new stuff on four different ROMs, yet you might please many on Evom by just polishing one Evo 8 and one Evo 9 - both US models. Trouble is only mrfred actually has direct access to them to develop/test. I also suspect most of us are more interested in developing new things rather than doing the grind of releases. Tephra is doing a wonderful job, I hope he doesn't burn out!
Last edited by jcsbanks; Jul 23, 2008 at 02:02 PM.
Jul 23, 2008, 02:51 PM
#131
I hope he doesn't either. After all, I still don't know what to do to get my 1-byte load working in EVOScan, and I don't see the procedure spelled out in plain English anywhere.
I am willing to do what I can to make this effort better organized, and more friendly to those who don't speak assembler.
I am willing to do what I can to make this effort better organized, and more friendly to those who don't speak assembler.
Last edited by Ted B; Jul 23, 2008 at 02:54 PM.
Jul 23, 2008, 03:15 PM
#132
The MUT table is used by the ECU to lookup each logging request. Each cell in the MUT table represents the address in the ECU's RAM of all the possible logging requests. So request ID "05" for example represents ignition timing. If "05" is sent by Evoscan then the ECU looks up position 05 in the MUT table to get the address of ignition timing in that particular ECU. The ECU then fetches the contents of this address and replies with the value of ignition timing back to Evoscan, which then subtracts 10 and displays or logs the result.
If we want to log something custom we can use something like request "41" that is spare. We need to use Ecuflash to write the address in position "41" in the MUT table of the variable we're interested in. Then we need a line in Evoscan with request 41, the name of what we're logging and the scaling.
I think your problem has come because 2 byte load was splitting the load over two requests and the setup of this in the loggers was never simple. Hence Tephra's one byte solution. If you use something like the TPS logging entry in Evoscan's data.xml as your template (copy it don't overwrite) you can change "TPS" to "Load1byte", change the request number to 41, change the scaling to match what you put in the ECU.
I hope I neither patronise or complicate the issue. Hope this helps.
Whilst fiddling with MUT tables and xmls is a PITA, it does make the whole thing modular and flexible. It would be best to package all this up into a ROM and xml that just works though I think.
If we want to log something custom we can use something like request "41" that is spare. We need to use Ecuflash to write the address in position "41" in the MUT table of the variable we're interested in. Then we need a line in Evoscan with request 41, the name of what we're logging and the scaling.
I think your problem has come because 2 byte load was splitting the load over two requests and the setup of this in the loggers was never simple. Hence Tephra's one byte solution. If you use something like the TPS logging entry in Evoscan's data.xml as your template (copy it don't overwrite) you can change "TPS" to "Load1byte", change the request number to 41, change the scaling to match what you put in the ECU.
I hope I neither patronise or complicate the issue. Hope this helps.
Whilst fiddling with MUT tables and xmls is a PITA, it does make the whole thing modular and flexible. It would be best to package all this up into a ROM and xml that just works though I think.
Last edited by jcsbanks; Jul 23, 2008 at 03:17 PM.
Jul 23, 2008, 04:07 PM
#133
Ok, so if I understand this correctly, the MUT table is a switchboard, like a cable TV box. The ECU sends the desired data to channels (addresses) we specify in the table. EVOScan just 'tunes' into whatever channel we specify to get the desired data, processes it, and it logs it. Yes?
If this is correct, then do we still get the info from the same MUT address as the 2-byte log, but I am converting it to 1-byte using the scaling factor that matches the one in my v5.8 map?
Or, do we have ECUFlash report load to two different MUT addresses and have two independent entries in EVOScan?
This is where I need clarification so I understand what to do to get it working.
If this is correct, then do we still get the info from the same MUT address as the 2-byte log, but I am converting it to 1-byte using the scaling factor that matches the one in my v5.8 map?
Or, do we have ECUFlash report load to two different MUT addresses and have two independent entries in EVOScan?
This is where I need clarification so I understand what to do to get it working.
Jul 23, 2008, 04:22 PM
#134
Perfect analogy there
The whole point of 1byte load is so you can log 2byte load as 1 MUT request, instead of having to use 2 MUT requests.
Less MUT requests = faster logging.
I think we have come along way since v1, and perhaps what really needs to happen is more documentation/instructions on features on my behalf.
I guess I was hoping that it would be fairly self-evident and anyone that couldn't work it out would be helped by others...
The whole point of 1byte load is so you can log 2byte load as 1 MUT request, instead of having to use 2 MUT requests.
Less MUT requests = faster logging.
I think we have come along way since v1, and perhaps what really needs to happen is more documentation/instructions on features on my behalf.
I guess I was hoping that it would be fairly self-evident and anyone that couldn't work it out would be helped by others...
Jul 23, 2008, 04:55 PM
#135
Okay, I don't know if this is really any help but here goes. These are my xml files for EvoScan and EcuFlash. I made a couple of small changes before uploading to simplify things, but my ROM still opens and the tables look good. I suppose I need to upload the ROM itself (with the direct boost and jdm map updates) but I need to clean it out first.
On my laptop the files live in the following locations:
C:\Program Files\EvoScan\EvoScan v2.4\DataSettings\Data.xml
C:\Program Files\OpenECU\EcuFlash\rommetadata\mitsubishi\evo\ 94170015.xml
I suggest you make a backup of the original files and then copy these in place. If you're using vista be careful about how it "protects" you from writing to the Program Files directory. I had to remake the zip file because I copied the original files not the hidden modified ones.
If you want to know what changes to your ROM for the direct boost and so forth, you'll have to find those threads for now.
On my laptop the files live in the following locations:
C:\Program Files\EvoScan\EvoScan v2.4\DataSettings\Data.xml
C:\Program Files\OpenECU\EcuFlash\rommetadata\mitsubishi\evo\ 94170015.xml
I suggest you make a backup of the original files and then copy these in place. If you're using vista be careful about how it "protects" you from writing to the Program Files directory. I had to remake the zip file because I copied the original files not the hidden modified ones.
If you want to know what changes to your ROM for the direct boost and so forth, you'll have to find those threads for now.