Still waiting for Hamish to send somthing also.

 

Yes it supports openport 2.0, and there is many you tube videos showing it working in EvoX with openport 2.0 and wideband sensors via serial port.

 

Any chance of answering some of the questions I asked above? Potential customer here with cold feet.

 

I installed the latest firmware (v106.nb0) and a new zip file with the latest "EvoCcanPPC" floder per Hamish's email instructions; still get the "unidentified USB driver" message as soon as I plug in the op2.0 cable! Anyone else have any idea's?

 

Well I got it to connect to the ecu, I had a bad cable in the mix (thought I switched all the cables out last week, I guess not). Now I get the following "OpenPort 2.0 Found WDB FTDI Devices Found: 0 Initialize Vehicle ECU... Connection successful..." but numbers are way off, like 300rpm at idle, STFT -25.0 etc. I can only pull up one gauge template, if I try to make any changes I either get "IO error" or something to the effect "gauge template save function not yet implemented", oh well making some progress I guess. I wish there was a basic primer on hew this is supposed to work, right now I'm just randomly pushing buttons trying to get something to work, like a gauge display with some data!


I just noticed I have been posting in the Evo 9 section, I wonder if I should repost my questions in the EvoX section?

 

kmart888 had a bad cable in the mix, toeng has yet to contact me. you can buy with confidence. and I am supporting kmart888 directly via email now, he is getting values on his non-faulty op2 cable now, we just have to set him up some gauge templates and better mode23 data.xml

acidtonic you have an Evo9, kmart and toeng have EvoX and openport2.0 cable. read through the rest of the thread to convince yourself that it works perfect, you will see that it does. Evo9 you should use openport 1.3U for super fast logging results on the GPS NAv.

 

Hi, kmart888, Hamish.

The "bad cable in the mix" means the cable is faulty and evoscan must resent good cable to me, right?

What way/email address I should to contact to quick help? I prior send email to support.

support@evoscan, evoscan website ticket, this thread, Hamish email-what,

my email: lsuchart@hotmail.com

 

In terms of logging capability, there's nothing out there that compares with EvoScan except MitsuLogger (free alternative, unsupported). DashDAQ is a distant second to either of these for logging the factory ECU. MitsuLogger has no dashboard display package, so if you don't like the level of polish of EvoScan's dash display, you'll probably have to write your own.

 

FYI my "bad cable" was the USB cable I was using between the op2.0 cable box and the "y" cable, I do not know if it was the cable that came included with the EvoScan GPS or not, probably not as I have several lying around. Anyway, it is a common $6 cable at your local Best Buy or simular store.

Hamish contacted me via PM after reading my forum post and pm to him, I asked Hamish to send me the latest files that he knew worked via email in case my card was corrupt, he did but it did not help me as the problem was I was still using a faulty cable not missing files. Seeing as you and I have exactly the same symtoms I might suggest you change out the "usb to mini usb" cable and/or make sure you have the correct devices pluged into the right pigtail's of the "y" cable, it can be connected two different ways and there is no diagram offered that shows the proper way to plug the cables in. Oh and how am I sure my cable was bad? I was not able connect the windows version of EvoScan, which worke previously, when I usee that specific cable.

Now I have to learn to set up the gauges and definitions as there is no documentation, Hamish has offered to help me with this, thank you.

If I learn anything more I'll let you know right here.

How did some of you guys out there with working gauge displays figure out how to set this up this device without basic directions? Don't tell me it is straight forward or self evident, you will really hurt my feelings.

 

most people already know how to edit data.xml so that takes care of the MUT or CAN/Mode23.

I guess people just jumped in and started editing the gauge txt files, the gauge templates have some instructions inside each txt file:
\EvoScanPPC\GaugeTemplates\Examples\Template2 - example1.txt

but people use the Gauge Template Designer in windows, which it edits your gauge template txt file for you now...

 

As your typical shade tree ecu tuner let me back up what Hammish is saying here. Most of us learn to mess about with .xml files when we first started playing with ecuflash and evoscan (pc version). So the basic structure and syntax is just something we "know" by the time we get our GPS unit.

As for the gauge templates, I just started playing with that myself. Again, the comfort I gained from playing with the .xml structure made deciphering the template syntax fairly straight forward and as Hammish says, there actually are instructions, and examples, right there in the templates.

Finally, something to keep in mind here is that so long as you're only messing about with xml and template files, AND NOT WRITING TO THE ECU, there is really nothing you can do wrong that would result in hurting your car or the GPS unit. Just be sure to save copies of files you are playing with (though you can always get replacements online anyway).

The one caution I would give: if you think you might be getting strange readings, by all means don't go tuning your car based on those readings until you know they are valid; that is the only way i can think that a bad evoscan xml could hurt you.

So dig in and start playing

 

Ah yes, I must look at this as Hamish's hobby that is geared toward other hobbiest, but it is not marketed that way! Hamish is a genius at what he does, he and Tephra's dedication to providing the Evo world with a tuning solution is invaluable to the tuning community and there is no other product like the EvoScan ppc, otherwise I would not waste my time with it; I am patiently waiting for his iPad implementation. Still...it would be nice if the product worked in some standard fashion out of the box (dare I say pnp?) then I could see what it was doing and learn how to make the changes that I wanted.

Two weeks ago, when I changed from flashing the ECU with the AP to a pro tune using EcuFlash/EvoScan, I did not know what a rommdata or an xml file was or why I needed a definition file, I'm still not sure how any of this goes together! I was able to implement mode 23 (still do not know why) by following the instructions on the forum by rote without any understanding of what I was doing. I open up an xml file and I do not know what I am looking at, what to change, what syntax to follow, or why. How does the xml file relate to the overall function of EvoScan (windows version), what are all these different roms and why. I am logging data now and making minor changes with help from the forum to the maps based on the logs but I feel as thou I jumped into the deep end of the pool with out a float when I should be in the shallow end with water-wings; I'm looking for those proverbial “water-wings” so to speak! I am 1/3rd way through Mirlins excellent tutorial, maybe it will go into xml files aqnd gauge setup in the 2nd half?

I just looked at 2.1ppc and the one gauge it defaults looks far superior to anything I have tripped across in 2.2beta or 2.2betaNov. I wil be going out to the car later to see if 2.1 works, if it does I may try look at the the underlining xlm file, if I can find it.

I'll download the new gauge software later today and see if I can make heads or tails out of it.

2010 MR-T (SST)
Stock clutch packs
OEM DiaQueen SST fluid
SSP trans Deep Sump
SSP Front mount trans cooler
OEM intake w/dropin
CBRD BBX full Turbo
AMS DP
RRE Rally test pipe
MXP II CBE
DP 1000 injectors
BlaqOps single pump
WORKS tune using OP (cleaned up by Bryan)
Green relay (yeah that’s it, it MUST be a faulty fuel pump relay!)

 

All good points. I suppose I look at the GPS unit, as well as evoscan and ecuflash as tools. There is a line somewhere between handing you a tool and expecting you to have the knowledge to use it appropriately and giving you a tool and providing an instructional class on how to use it. Just like a spanner wrench, you buy it from the store but the store doesn't teach you how to use it.

Another thing to consider ... the knowledge base is constantly expanding. In the case of the XML files they are growing and being corrected all the time by the community. It is moving fast, there is a LOT of info and it is always changing. If people like Hammish waited until we knew all there was to know about the ECU we'd still be waiting for him to ship product.

As for understanding how everything interacts ... perhaps this will help:

To people like you and me ROMs are the incomprehensible instructions (equations) the and values (numbers that go into the equations) stored inside the ECU. There are different ROMs for the different car versions / years.

XML (eXtensible Markup Language) is nothing more than a way of ordering information, any information not just cars, so that us normal people can understand it.

So there are two different XMLs that we have to deal with:

The first are ECUFlash XMLs. They are the translators for those incomprehensible instructions and values (aka the ROM). Just like there are different ROM different cars, there are different ECUFlash XMLs for different ROMs.

The second type of XMLs are those used by EVOScan and the EVOScan GPS. They tell EVOScan where (aka the address) to ask the ECU questions like "what is the RPM?" and "What is the current Timing?" The XML also tells EVOScan how to interpret the answer (i.e. divide by 0.2345 + 23). Just like there are different XMLs for each ROM for ECUFlash there are different XMLs for each ROM for EVOScan.

So now you know what a ROM is in simple terms and you know that there are two XMLs we care about. Why do we care? Because in ECUFlash that XML defines all the tables you see. It defines where in the ROM the table resides, how big it is, and how to present the data in that table to us. If the where and how are defined incorrectly then we are looking at the wrong table, only part of the table, part of another table, interpreting the data wrong, or even interpreting the function of that table incorrectly (i.e. it is named wrong).

So lets consider the Mode23 mod you did, by rote, without understanding what you were doing. You opened ECUFlash, read the ROM from your car, and ECUFlash used an XML file to translate that ROM into something you could at least partially understand. You opened a table that was only 1x1 in size. In that table was a value. In this case that value tells the ECU to do something. Maybe where to read a value from when you are driving, or where to store a value from a sensor, or maybe even to trigger another set of instructions like to trigger "Mode23". I honestly don't know the specifics but the point is, you told the ECU to go do something different by literally changing a value stored inside the ECU.

In another situation, like say the Timing Table, the data stored in that table tells the ECU how much timing to use. For now we'll ignore that the actual full process is way more complicated. The point is that the data stored in the table tells the ECU what to do when you are at a certain load and at a certain RPM.

At this point it is important to remember that the XMLs used by ECUFlash is still nothing more than a translator. The XML in and of itself does nothing *to* the ECU and the ROM, it simply lets you look at the ROM in a way that makes sense. It is the data presented to you by ECUFlash, using the XML to translate it, that really matters.

Do you remember the warning that went with the Mode23 instructions, "If the CURRENT VALUE does not match here STOP AND ASK!!!" So why might the value not match? After all your ROM is stock, virgin, fresh from the dealer? How could the wrong value be in that table? Simple ... ECUFlash is looking in the wrong place for it. And why is it looking in the wrong place? Because the XML told it to. If you were to go change that value anyway who knows what would happen. You might as well send your car payment to a random address and then just hope the bank somehow gets it ;-)

As for the other XMLs, the one used by EVOScan, the issues are similar except now it is all just a matter of the XML telling EVOScan where in the ECU to get certain data like RPM, MAP, Timing, etc. If the XML is wrong then you get the wrong data. The process people like Tephra go through to figure out where to get that data is not easy. Mitsubishi didn't give them fully commented ROM code that says, "RPM is stored here ===>" So they have to play detective by scouring through that incomprehensible mess we call a ROM. Then once they find where they think the data is stored they still have to interpret it to figure out exactly what it means. That is, since the value is something between 0 and 255, what scaling factor should be used to correctly turn it into an RPM or a Timing value that makes sense to us mere mortals.

[phew] ok that is all I have time for. Hope that helps. And ECU Gurus, if I got something wrong beyond extreme over-simplification please let me know and I'll edit the post.

 

Thankyou" It is all as clear as MUD! Just joking, very good explaination and I actually understood 98.4% of it! I guess the AP did all that stuff in background and presets, which is why EvoScan is so much more flexable; one of the reasons I changed but mostly to use the EvoScan PPC sw.

Anyone: I just opened up my "Data.xml" file in the "DataSetting" folder of the "EvoScanPPC" folder using notepad and the first line is "...1994+Mitsu..." which is probably why my data is gobledigook; like over 200 knock counts and 300rpm idle speed when I plug it into my 2010 MR! how do I find the correct data addresses and plug them into "Data.xml"? Fyi I am usig "5558005.xml" in the windows version of EvoScan but it looks to be somthing diferent.

 

Can someone get me the GTR style gauge setup?

When I ordered the gps unit I thought it came with it.
Am I wrong?