Differences between ecuEdit and ecuFlash map data

[JRSCCivic98]

I've noticed that in an 02 WRX rom that I have (OEM) ecuFlash shows different info for the wastegate duty table on AT map, but ecuEdit shows identical tables for both duty maps on AT and MT. What's that all about? Which one is correct? I'm using the predefined xml in ecuFlash for the ROM file, but generated the one in ecuEdit with xmlwrite. I'm having a hard time knowing which program to trust for tuning. We need to get these variances found and fixed... more and more people are starting to use these tools and a lot of them depend on xmlwrite to generate their xml files... it would be nice to know what's right and what's wrong.

[NeverLies]

1 - Launch IDA
2 - Start to disassemble your ROM
3 - Check which XML/software give the right information

This is the only way to do a good job

[Freon]

Well step one would be just open both XML's in Notepad and see if they're pointing to the same offsets. That isn't that hard to do and doesn't require a decompiler.

[NeverLies]

Yeah, sure, but how would u know then which one is correct ?

And while playing with IDA (or your favorite decompiler ), I'm sure he will better understand ECU behavior and find new maps

[Freon]

One step at a time...

[JRSCCivic98]

I forgot to state that I've got my silver platter waiting on the table.

While I understand where everyone is comming from on this, what's important here is that the tools made available to users should be as bug free as possible. A slight variance on these values and it could hose someone's ECU. A lot of the new people getting their hands on these tools don't have the knowhow on breaking down the ROM files manually and depend on "ready made" tools such as xmlwrite to create the defs for them. This brings me back to the original statements made by me months ago that there's not one "comprehensive" app that has correct functionality in it or rather... a high percentage of correctness in it's capabilities. This again comes from people just writing apps for themselves to cover their ROMs only and then just releasing the software for everyone's use. While I can't sit here or for that matter all of us sit here and expect free software to be at the same level of commercialy available software it would be nice to have just one app that works well and correctly.

Like I said, I'm not trying to start a war or anything... I just think that everyone's efforts would be better spent on "one" "perfect" solution rather then 10 piecemealed ones. For example, Colby has one app that now does flashing and tuning, but he's missing a lot of defs for it. If xswrex could build a library of correct offsets (yes, that means with proper cel size views ) for it and have Colby bundle it in the setup imagine how a well-rounded app it would be.

Let's work smart, not hard... That's all I'm trying to say. Trust me, I feel bad always stating these things because I don't have the nessacery knowledge that you guys have to create these great pieces of work from scratch, but I think what we're missing in this community is "Project Management".

Good day to everyone.

[RICK SCHU]

I thought the 03 wrx maps had different ROMs for auto and manuals and that only the 02 wrx had the same revision for both with the separate AT and MT maps:

From scoobypedia:

"Note: In 2002, ECU revisions were the same for automatic and manual transmission ECUs. As of 2003, the last digit of ECU revisions denotes the transmission type. ‘L’ denotes manual transmissions while ‘K’ denotes automatic transmissions. For 2004 and 2005, ‘F’ denotes manual transmissions while ‘E’ denotes automatic transmissions. "

[JRSCCivic98]

Fix it... meant 02.... typed 03. Either way, the maps are the same... from what I've seen. This is a A4SGD10C ROM to be specific.

[RICK SCHU]

All the 02 maps I've seen have exactly the same duty cycle and boost tables for the AT and MT. I know Enginuity is correct as I've modified my ECUTEK tune, which uses boost switching by going between the AT and MT WDC and boost maps. I've changed my default map to all zeros as a "valet" map (AT) and I've modified my other tables (MT) changing pretty much every cell. The changes have worked exactly as I've entered them.

[RallyImprezive]

I forgot to state that I've got my silver platter waiting on the table.

While I understand where everyone is comming from on this, what's important here is that the tools made available to users should be as bug free as possible. A slight variance on these values and it could hose someone's ECU. A lot of the new people getting their hands on these tools don't have the knowhow on breaking down the ROM files manually and depend on "ready made" tools such as xmlwrite to create the defs for them. This brings me back to the original statements made by me months ago that there's not one "comprehensive" app that has correct functionality in it or rather... a high percentage of correctness in it's capabilities. This again comes from people just writing apps for themselves to cover their ROMs only and then just releasing the software for everyone's use. While I can't sit here or for that matter all of us sit here and expect free software to be at the same level of commercialy available software it would be nice to have just one app that works well and correctly.

Like I said, I'm not trying to start a war or anything... I just think that everyone's efforts would be better spent on "one" "perfect" solution rather then 10 piecemealed ones. For example, Colby has one app that now does flashing and tuning, but he's missing a lot of defs for it. If xswrex could build a library of correct offsets (yes, that means with proper cel size views ) for it and have Colby bundle it in the setup imagine how a well-rounded app it would be.

Let's work smart, not hard... That's all I'm trying to say. Trust me, I feel bad always stating these things because I don't have the nessacery knowledge that you guys have to create these great pieces of work from scratch, but I think what we're missing in this community is "Project Management".

Good day to everyone.

+1. Well put.

[Jeramie]

I forgot to state that I've got my silver platter waiting on the table.

While I understand where everyone is comming from on this, what's important here is that the tools made available to users should be as bug free as possible. A slight variance on these values and it could hose someone's ECU. A lot of the new people getting their hands on these tools don't have the knowhow on breaking down the ROM files manually and depend on "ready made" tools such as xmlwrite to create the defs for them. This brings me back to the original statements made by me months ago that there's not one "comprehensive" app that has correct functionality in it or rather... a high percentage of correctness in it's capabilities. This again comes from people just writing apps for themselves to cover their ROMs only and then just releasing the software for everyone's use. While I can't sit here or for that matter all of us sit here and expect free software to be at the same level of commercialy available software it would be nice to have just one app that works well and correctly.

Like I said, I'm not trying to start a war or anything... I just think that everyone's efforts would be better spent on "one" "perfect" solution rather then 10 piecemealed ones. For example, Colby has one app that now does flashing and tuning, but he's missing a lot of defs for it. If xswrex could build a library of correct offsets (yes, that means with proper cel size views ) for it and have Colby bundle it in the setup imagine how a well-rounded app it would be.

Let's work smart, not hard... That's all I'm trying to say. Trust me, I feel bad always stating these things because I don't have the nessacery knowledge that you guys have to create these great pieces of work from scratch, but I think what we're missing in this community is "Project Management".

Good day to everyone.

+ 1 for what he said.

When he meantioned it a long time ago, I thought he was wrong, but at this point I would have to agree! Can't everyone just work togethor?

[RICK SCHU]

There is a reason the software is in beta - it is for advanced users who are willing to take a risk on it and help report any bugs so that eventually a version suitable for the public (both the tuning software and XML defs) can be available eventually. It is not designed for someone who knows nothing about tuning or computers for that matter. It is designed for someone who will know when something doesn't look right.

The same thing can apply to other software. I wouldn't load a beta version of Windows Vista on my grandmother's computer. I might try it out myself and who knows, I might experience a major bug and lose all my data or maybe my security will be compromised. Of course, I'll take steps (backup copies and not leaving sensitive data on drive), that will minimize my risk, but it would still be there.

Maybe more disclaimers should pop up when using this software, so that noobs will know what they are getting into.

[JRSCCivic98]

Thanks for playing. ecuFlash is not in Beta. There is no Beta designation in the Help/About display screen. ecuEdit may be in Beta, but a much better term here should be "unfinished" or "Alpha". There is a difference between Alpha and Beta software releases. Alphas have functionality and stability/bug issues. Betas have complete functionality that's been tested at least inhouse (by a large R&D staff) and deemed usable by outside sources with the possibility of small bugs still evident. However these bugs will not or should not cause the overall capability of the program to subside to that of an Alpha capability program.

So, with that said, we're all Alpha and Beta testers here... and we all report these problems. However, when these reports are contered with statements such as the ones listed above by NeverLies and Freon, one has to wonder where the line is drawn between public Beta testing and public program bug fixing.

Let me put that in simple terms for those of you who think I like to bend the statements I make... If I find a problem and report it, I expect people responsible for fixing them to fix them... not tell me I have to fix them myself. I don't care how open source this project is. Open source doesn't mean... "We create a program and if it works great, if not, you need to fix it yourself."

If this continues to be the mentality of everyone involved with the development of these great programs then you can be sure that commercial software will always be the prefered solution. This is one of the major reasons why you don't see Linux being used by the majority of the public... it's used by a small and select group of people... regardless of how capable it is.

So, there's no need for popups to happen for the noobs... what's needed is better development support.

Again, don't anyone start yelling back that I complain too much... just read the post and try and understand the logic behind it. Pretend you don't know anything about programming and you'll see how these so called "noobs" feel when they want to use these tools.

[RICK SCHU]

Call it alpha, beta, whatever you want to call it - these are not finished products that should be used by noobs. We are dealing with a piece of software that even a "small" unforeseable bug in the editing of your ROM in the right spot, could cause you to end up with a blown motor or an ECU for a door stop. We are not talking about some program in development that might just cause your computer to freeze up - we are talking about killing your ECU, leaving you without a car till you buy a new one or worse, blowing your motor leaving you with a big headache and stranded in the middle of the freeway. This is not territory for noobs to get involved. Sure, they could buy streettuner and blow their motors, but ponying up the $800 for AP and ST means it is limited to people who are really serious about tuning. Not some noob with a CAI, BOV, MBC who heard he could get an $80 cable and mess with all sorts of stuff with a free program.

The problem with people reporting bugs or issues is that it is usually along the lines of - "I think the boost maps might be wrong. Someone needs to fix this". Why don't people get their hands dirty and come up with a solution or prove that there is a definite problem? Dive into the XML - find out what's wrong - compare it to the other programs - find the correct address - do some research - what should the correct values be - whatever, rather than "I expect someone to fix this." For example, I noticed v6 of xmlwrite created a bad definition file for Enginuity. I looked at the XML generated verses v5. Found it was generating a bad ROMID at the beginning. I posted it in the correct thread and showed the XML that was wrong and what it should be. Now the creator of that program has acknowledged the problem and I'm sure it will be fixed in v7.

Now, I could have just said, "xmlwrite creates a bad definition file for Enginuity now". That might be fine for a team of developers, but most of these people are individuals developing these programs, for free, in their spare time. If you are going to report a problem, do a little research. You don't have to be a programmer. Find out what is causing the problem. Give them as much of a head start as possible. Post snipets of xml data that needs to be corrected, screenshots of the problems, whatever. Don't "expect" that it should be fixed - do your part.

[Freon]

Jesus. The guy starts a thread with a specific question, and rather than try to help out you start a general rant on how misdirected the whole software project is.

JRS, are you sure you want to be involved here? What are your goals? How do you feel your comments in this thread help the project or the original poster? I don't see your comments here as constructive to either the project as a whole, and certainly not the problem in the original post.

So, to be constructive myself, I suggest if you see a bug, report it to the author or post in the appropriate thread with specific details. This is not the place to blow up if you've got a problem with the project.

Yes, absolutely, this is cutting edge stuff. The average joe who doesn't have a background in computer science or software and tuning should probably NOT be messing with this stuff, yet. You won't see me on NASIOC trying to get every Tom, Dick, and Harry to ditch their AccessPort and go Openecu... It's not ready for prime time.