Welcome to the North American Subaru Impreza Owners Club Thursday September 18, 2014
Home Forums WikiNASIOC Products Store Modifications Upgrade Garage
NASIOC
Here you can view your subscribed threads, work with private messages and edit your profile and preferences Home Registration is free! Visit the NASIOC Store NASIOC Rules Search Find other members Frequently Asked Questions Calendar Archive NASIOC Upgrade Garage Logout
Go Back   NASIOC > NASIOC Technical > Engine Management & Tuning > Open Source Reflashes

Welcome to NASIOC - The world's largest online community for Subaru enthusiasts!
Welcome to the NASIOC.com Subaru forum.

You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, free of charge, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, so please join our community today!

If you have any problems with the registration process or your account login, please contact us.
* Registered users of the site do not see these ads.
Reply
 
Thread Tools Display Modes
Old 05-11-2013, 11:29 PM   #1
Exarch
Scooby Newbie
 
Member#: 208321
Join Date: Apr 2009
Chapter/Region: RMIC
Location: Colorado Springs, CO
Vehicle:
2012 WRX
Extremely Red

Default Base map?

I'm having a bit of drama here and there with romraider.

The vehicle is a USDM 2012 WRX, ECU 8112587007, CAL AE5K611L.

Interface is a Tactrix OpenPort 2.0 with current firmware. RR and ECUFlash are both the most current version with the most current defs.

Unfortunately my ECU ID and CAL ID's aren't officially supported by RomRaider. There are some user-made definitions for RR, as well as a Tactrix experimental definition which ships with ECUFlash, however nothing concrete.

While I can log a decent amount of data from the car, there are some omissions, the most notable of which is anything pertaining to CL/OL decision making or status.

Because of this lack of official support, I tend to view the actual tables and such within the ROM (which can be edited with RR) as suspect to begin with. Doubly so in light of the logger defs being incomplete.

I don't feel that pulling my stock ROM and editing away is in any way safe. There's nothing that I know of which assures that the tables are defined correctly; I believe that I could think I'm editing an AVCS map, when I am in fact editing a fueling table due to a problem with the definitions...

What I'm looking for is a base map to flash to my ECU which I can work on from there which has legitimate definitions within RR and has the ability to be logged with all "extended" parameters. If anyone can point me in a reasonable direction, it would be greatly appreciated.

Note: If the easiest way around this debacle is to buy into Cobb for this car as well, please be sure to point that out.
* Registered users of the site do not see these ads.
Exarch is offline   Reply With Quote
Old 05-12-2013, 06:09 PM   #2
Sypher
Scooby Specialist
 
Member#: 106366
Join Date: Jan 2006
Chapter/Region: MAIC
Location: VA
Vehicle:
2006 WRX
Blue

Default

With any open source definition your taking a risk, always back up your stock rom and I would just change the open loop closed loop delay timer to 0. Thats really all you need to do and change the throttle position % to 30. check your afr's and transition phase then and see if it helps.
Sypher is offline   Reply With Quote
Old 05-12-2013, 06:28 PM   #3
BlazeRex
Scooby Specialist
 
Member#: 268354
Join Date: Dec 2010
Chapter/Region: NESIC
Location: Massachusetts
Vehicle:
02 WRX 05 LGT
Slow Automatics

Default

Cobb has more definitions defined from off the bat. However, if you understood how RR and ECUFlash work, you would understand that if you see what looks like a fueling map, I would highly expect it to be a fueling map. The numbers you see are the numbers in the ECU, and there are internal code strings that link like things together.

I have worked with the AE5K611L def and can tell you it works just fine for what is defined. I will still stress though, Cobb's defs are defined in more detail than opensource curretly is.
BlazeRex is offline   Reply With Quote
Old 05-12-2013, 10:12 PM   #4
Exarch
Scooby Newbie
 
Member#: 208321
Join Date: Apr 2009
Chapter/Region: RMIC
Location: Colorado Springs, CO
Vehicle:
2012 WRX
Extremely Red

Default

For scaling the MAF and establishing the air/fuel relationship, you don't want OL. If you can log the switch, you can throw lines out of a log which are taken in OL. In my case I'll just take your suggestion in reverse to ensure that the OL switch doesn't happen (set timer high, set throttle position to 100% or something) If you do that, you'll probably break something... and log away.

Blaze: I think you're crossing some streams. RR and ECUFlash don't have anything to do with the actual process of reverse engineering a bit dump of a compiled ROM, or the raw definition process. Go read the getting started with IDA thread over on RR's forums to get an idea of how the actual definition process works. http://www.romraider.com/forum/viewt...hp?f=25&t=6303

What I'm saying here is that until someone braver than I tests the definitions, I hold it at about 85% confidence that what RR says is a fuel map is actually a full fuel map. Obviously as I learn more about the RE process my confidence will increase, as will knowing that other people have used it.

Thanks for confirming that AE5K611L does in fact work as-defined though.

I've done some digging around as to what base OS map vendors are using and whether or not they will be willing to provide definitions with their maps. As it ends up Torqued Performance uses the AE5K500L as a base map and will provide defs with a purchase, so right there I have 100% confidence that those defs will be completely legitimate and proven.

I would have gone the Cobb route, which is what I did on my older vehicle, but I wanted to give the OS side of the tuning house a try. Also, at the moment I'm not really flashing anything, as I'm attempting to get SOA to deal with the fact that the car is running crazy lean (8k miles, WELL under warranty). The Cobb solution won't allow logging of a stock ECU, which is what I'm doing at the present.

Edit: Fixed for senior moment.

Last edited by Exarch; 05-13-2013 at 12:33 AM.
Exarch is offline   Reply With Quote
Old 05-12-2013, 10:50 PM   #5
the suicidal eggroll
Scooby Guru
 
Member#: 51961
Join Date: Jan 2004
Chapter/Region: RMIC
Location: Broomfield, CO
Vehicle:
2005 STi
2012 WRX

Default

Quote:
Originally Posted by Exarch View Post
For scaling the MAF and establishing the air/fuel relationship, you don't want OL. If you can log the switch, you can throw lines out of a log which are taken in OL. In my case I'll just take your suggestion in reverse to ensure that the OL switch doesn't happen (set timer high, set throttle position to 100% or something) and log away.
Whoa there...

I know your intentions are to keep the system in CL so you can trust the stock O2's readings, but the error in the stock O2's readings doesn't depend on CL/OL, it depends on exhaust pressure. Setting the CL/OL transition to a throttle position of 100% or setting the CL/OL timer high will do nothing but blow the engine. It doesn't matter if the system is in CL or OL, if the exhaust pressure is high, the stock sensor's readings are wrong. There is absolutely NO reason to EVER increase the CL/OL transition throttle position or timer. There's a reason the system switches to OL when it does (actually it needs to switch to OL sooner than stock, but that's another discussion), and delaying this transition will both damage the engine and lead to incorrect AFR readings anyway.

Last edited by the suicidal eggroll; 05-13-2013 at 11:13 AM.
the suicidal eggroll is offline   Reply With Quote
Old 05-13-2013, 12:29 AM   #6
Exarch
Scooby Newbie
 
Member#: 208321
Join Date: Apr 2009
Chapter/Region: RMIC
Location: Colorado Springs, CO
Vehicle:
2012 WRX
Extremely Red

Default

Eggroll:

You are 100% right, that would have been a horrible idea.

So since I can't see when the car is in CL or OL based on logged data, how then should I proceed with MAF scaling and base fueling adjustments? Every guide I've read states that one should throw out all OL lines before performing the calcs...

Would it be safe to disable OL fueling entirely if I were to also disable boost control and run on spring pressure, or even go all draconian and set fuel cut at 2 psi?

Edit: You're probably going to say, "Get a wideband stand alone, set CL/OL delay so it works right, then just use the reading from the legitimate and accurate sensor..."

Edit Mk 2: Disregard the above, td-d over at RR just updated the definition, so full speed ahead without getting janky. http://www.romraider.com/forum/viewtopic.php?f=3&t=9566

Last edited by Exarch; 05-13-2013 at 02:35 AM.
Exarch is offline   Reply With Quote
Old 05-13-2013, 11:20 AM   #7
the suicidal eggroll
Scooby Guru
 
Member#: 51961
Join Date: Jan 2004
Chapter/Region: RMIC
Location: Broomfield, CO
Vehicle:
2005 STi
2012 WRX

Default

You could use AFR Correction as an indicator, it'll switch to 0.0 and hold there while you're in OL.

Or you could just use manifold pressure, since that's the real problem, not CL/OL status. Just throw out any lines >0 psi and you should be able to trust the resulting AFR measurements.

I would never disable OL, but you could disable CL if you wanted. It can make tracking down AFR issues a bit easier since you're not fighting against the CL system. If you're still using the factory sensor in the factory location, then you'd still want to throw out anything >0 psi though.
the suicidal eggroll is offline   Reply With Quote
Old 05-13-2013, 03:32 PM   #8
BlazeRex
Scooby Specialist
 
Member#: 268354
Join Date: Dec 2010
Chapter/Region: NESIC
Location: Massachusetts
Vehicle:
02 WRX 05 LGT
Slow Automatics

Default

In response to earlier. I understand how RR and ECUFlash work. With using a certain def if you see 14.7 in the upper corner and lower 10's in the lower right , I would be hard pressed to think that's anything but a fueling map. When your definitions are wrong, you'll know...
BlazeRex is offline   Reply With Quote
Old 05-14-2013, 04:04 AM   #9
Exarch
Scooby Newbie
 
Member#: 208321
Join Date: Apr 2009
Chapter/Region: RMIC
Location: Colorado Springs, CO
Vehicle:
2012 WRX
Extremely Red

Default

Quote:
Originally Posted by BlazeRex View Post
In response to earlier. I understand how RR and ECUFlash work. With using a certain def if you see 14.7 in the upper corner and lower 10's in the lower right , I would be hard pressed to think that's anything but a fueling map. When your definitions are wrong, you'll know...
You're missing the point entirely here.

Let's say that the reference cell for a fueling table is at 0xFFFF00C5, but the individual doing the engineering has fat fingers, so ends up defining the address of the table's reference as 0xFFFF00B5. Now you will end up in RR with a table in which some cells don't belong to the table. It is entirely possible to have a value appear in a cell on a table in RR which has absolutely nothing to do with what it is you think you're looking at despite the fact that the value in the box appears legitimate.

In the world of reverse engineering and disassembly, what you are looking at can be strikingly different than what you think you see.

All I'm trying to really get across here in so many words is that screwing with an experimental set of definitions without at least some confirmation as to their validity isn't my bag. Doubly so in light of the fact that there exists a legitimately tried and true pathway forward using a different CALid with definitions which have been proven by way of producing a commercial product in use by a great number of people.
Exarch is offline   Reply With Quote
Old 05-14-2013, 07:52 AM   #10
Bamofo
Scooby Specialist
 
Member#: 159743
Join Date: Sep 2007
Location: Plymouth Ma
Vehicle:
07 STI Limited
TurboMike Tuned 2.35

Default

Quote:
Originally Posted by Exarch View Post

You're missing the point entirely here.

Let's say that the reference cell for a fueling table is at 0xFFFF00C5, but the individual doing the engineering has fat fingers, so ends up defining the address of the table's reference as 0xFFFF00B5. Now you will end up in RR with a table in which some cells don't belong to the table. It is entirely possible to have a value appear in a cell on a table in RR which has absolutely nothing to do with what it is you think you're looking at despite the fact that the value in the box appears legitimate.

In the world of reverse engineering and disassembly, what you are looking at can be strikingly different than what you think you see.

All I'm trying to really get across here in so many words is that screwing with an experimental set of definitions without at least some confirmation as to their validity isn't my bag. Doubly so in light of the fact that there exists a legitimately tried and true pathway forward using a different CALid with definitions which have been proven by way of producing a commercial product in use by a great number of people.
The guys like Merp Td-d and others formulating these maps would not make a mistake like that. The general process is go to romraider and post your rom saying you want logger and ecu defs. If you're feeling brave load up scoobyrom and do it yourself. But if you define a table with an offset by mistake it will look like total garbage. With that being said it seems like you have enough knowledge to think this up so you must know the difference between a good looking table and a trash one... If you send me your rom I'll get the defs made up for you. But you should probably go to github and search subaru. Merps piece will show up. Select the alpha branch and click the zip button. That will give you a folder of the newest roms and tables. Point to that in Ecuflash and you should be golden. If your looking for specific tables include that in your PM.

But as blaze was saying it either works or it doesn't.. Worrying about an offset rarely happens and normally someone catches it before it's released. Especially in the roms included with Ecuflash as a base.
Bamofo is offline   Reply With Quote
Old 05-14-2013, 08:49 AM   #11
quazimoto
Scooby Guru
 
Member#: 70395
Join Date: Sep 2004
Chapter/Region: MAIC
Location: Da-boonies,Va
Default

Quote:
Originally Posted by Exarch View Post
You're missing the point entirely here.

Let's say that the reference cell for a fueling table is at 0xFFFF00C5, but the individual doing the engineering has fat fingers, so ends up defining the address of the table's reference as 0xFFFF00B5. Now you will end up in RR with a table in which some cells don't belong to the table. It is entirely possible to have a value appear in a cell on a table in RR which has absolutely nothing to do with what it is you think you're looking at despite the fact that the value in the box appears legitimate.

In the world of reverse engineering and disassembly, what you are looking at can be strikingly different than what you think you see.

All I'm trying to really get across here in so many words is that screwing with an experimental set of definitions without at least some confirmation as to their validity isn't my bag. Doubly so in light of the fact that there exists a legitimately tried and true pathway forward using a different CALid with definitions which have been proven by way of producing a commercial product in use by a great number of people.
What you are completely missing as well is that Romraider/Ecuflash are non-commercial projects that are for the most part developed/engineered by volunteer contributors. So theoretically it is just one big "experiment" if you are going to think about it that way. They in no way express or imply that the software they provide is in anyway warrantied/fully tested. It is ALL use at your own risk. "Experimental" definitions for the most part have just been a place to compile the definitions for newer vehicles until they can add them to the actual definition set.
quazimoto is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -4. The time now is 10:26 AM.


Powered by vBulletin® Version 3.7.0
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Powered by Searchlight © 2014 Axivo Inc.
Copyright ©1999 - 2014, North American Subaru Impreza Owners Club, Inc.