Altering data values

Links to datasheets, websites, etc. relevant to the project

Moderator: Freon

Altering data values

Postby qoncept » Tue Oct 18, 2005 10:10 am

I'm a bit confused as to altering values in roms here. I've opened a 2004 WRX rom in a hex editor, and gone to offset 291C8-291CB, which according to Spiider's reference is the rev limit.

The value in the rom I have is 8E 00 8A 00 which, in decimal, is 2382400000. What does this mean? The rev limit is 7200 (right?), do I divide that number by 7200 to find a multiplier (330888.889), and multiply a target rev limit by that?

Thanks for your help, guys
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby cboles » Tue Oct 18, 2005 11:32 am

8E 00 8A 00

is actually 2 16-bit rev limit numbers (one to cut the engine, one to restore - to create hysteresis), stored with their least significant byte first. the two numbers are

0x008E = 142 -> * 50 rpm/unit -> 7100 rpm
0x008A = 138 -> * 50 rpm/unit -> 6900 rpm
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby ahains » Tue Oct 18, 2005 11:44 am

For most folks it is unlikely that you actually want to increase the rev limiter on your car.

Sure, there are cases where this is not true, but if your car is at all close to stock you should not do this.
The stock car is almost certainly choked by the turbo and cams at high RPM.

If you look at a dyno plot and overlay your speed for the gearing ratio of each gear, you can find the optimal (fastest) RPM to shift from one gear to the next. It is VERY unlikely that this point is going to be above ~7k rpm unless your car is specifically built/tuned for high RPM power.

Additionally, the forces exerted on your rods etc goes up with the square of RPM. It is much easier on your engine to make greater power through additional boost at RPM ranges under redline than to extend the power band up above the stock redline.

Obviously I don't know anything about qoncept's car so I can't comment on whether or not he should raise his limit - I just wanted to throw those comments out for anyone else who reads this thread and thinks that they want to raise theirs.

-Adrian
ahains
 
Posts: 83
Joined: Mon Jun 06, 2005 12:59 pm
Location: Renton, WA

Postby qoncept » Tue Oct 18, 2005 12:22 pm

Adrian,
Don't worry, I'm not planning on playing with my rev limiter. I'm just trying to get a handle on what all these values mean and how they're stored so I'll have a clue. :) I chose the rev limiter simply because (I thought) I knew the value of it and could see how it was stored. I also figured it'd be easier to look at a single stored value rather than a table for simplicity. I've never used a hex editor other than to edit text stored in an executable so I'm trying to learn.

Is there any chance someone could go through the offset map(s) Spiider has posted and more clearly define them the way Colby has here, or maybe just plug in some of the real world values so someone like me can figure them out?
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby Spiider » Tue Oct 18, 2005 4:32 pm

Ideally, I'd like to add the real world calculations to the offset doc's I've already produced. Also, I never really wanted to release the data that way, a while ago we talked about XML tables, I'd like to continue with that as well.

Adrian's been helping me with them, maybe we can continue. I haven't had a lot of time or energy to put towards it with some other unrelated software dev I've been doing lately.

My brains fried at the end of the day, nothing left for Subaru's....
Spiider
 
Posts: 191
Joined: Thu Mar 10, 2005 4:16 pm

Postby qoncept » Tue Oct 18, 2005 4:35 pm

I've got plenty of experience with high level programming, but digging through binary files and electronics are a bit over my head. If someone could point me to some sources of that data, tech note or whatever, I'd be more than willing to do my part. I'm also quite busy right now between overtime and class, but I could get it done eventually.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby cboles » Tue Oct 18, 2005 6:14 pm

I'm looking into writing a platform independent map editor in C++ with Qt4 that uses the XML specs we talked about. I'm rewriting EcuFlash with a GUI using it to see how easy it will be. It could be a very worthwhile project since it can be used with ROMs from any vehicle.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby qoncept » Tue Oct 25, 2005 11:47 am

Alright, anyone care to give me a quick crash course (or point me to something that'll explain it) in reading these hex values? I'm trying to make a spreadsheet that looks something like what you'd see in a tuning app for main ignition. The RPM was easy enough, but I'm confused on load.

For RPM, spiider listed 293AA-293C7 on a 2004 rom. 293AA through 293AD are 10 00 18 00 respectively. So do I skip every other block? I figured when I got to load it'd have 00 every other block again, but it doesn't, and I'm not getting a consistent change in values by going through them like I expected, either way.

Sorry I'm such a newb but I don't really know where to look. :oops:
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby ahains » Tue Oct 25, 2005 2:02 pm

qoncept wrote:Alright, anyone care to give me a quick crash course (or point me to something that'll explain it) in reading these hex values? I'm trying to make a spreadsheet that looks something like what you'd see in a tuning app for main ignition. The RPM was easy enough, but I'm confused on load.

For RPM, spiider listed 293AA-293C7 on a 2004 rom. 293AA through 293AD are 10 00 18 00 respectively. So do I skip every other block? I figured when I got to load it'd have 00 every other block again, but it doesn't, and I'm not getting a consistent change in values by going through them like I expected, either way.

Sorry I'm such a newb but I don't really know where to look. :oops:



Spiider was kind enough to show the translation of LOAD data in the OEM image:
0E 14 19 9A 25 1F 30 A4 39 9A 42 8F 4A E1 53 33 5C 29 65 1F 6B 85 71 EC 79 9A 7E B8"

Translates to:

0.44 0.80 1.16 1.52 1.80 2.08 2.34 2.60 2.88 3.16 3.36 3.56 3.80 3.96 (air per cylinder charge in grams)


So when I analyze a few of those values (the decimal places are just a copy and paste from the Windows Calculator utility, I know that they are obviously not all significant digits :)) as follows:

0x0E14= 3604 (base10); 0.44/3604 = .00012208657047724750277469478357381

0x4AE1 = 19169(base10); 2.34/19169 = .00012207209557097396838645730085033

0X7EB8= 32440(base10); 3.96/32440 = 0.000122071516646115906288532675709

Therefore it is clear that the hex values are 0 based (i.e. 0 means 0 grams air / cylinder charge), and they scale by 1 = 0.000122 grams air / cylinder charge.
So 0x0001 = 0.000122 grams air / cylinder charge, and 0x0002 = 0.000244 grams air / cylinder charge, etc.

HTH!
Adrian
ahains
 
Posts: 83
Joined: Mon Jun 06, 2005 12:59 pm
Location: Renton, WA

Postby Jon [in CT] » Wed Oct 26, 2005 7:11 am

The true scaling factor is 1/8192=0.0001220703125 if you want strict accuracy.
Jon [in CT]
 
Posts: 352
Joined: Sat Jan 01, 2005 10:23 am


Return to Technical Information

Who is online

Users browsing this forum: No registered users and 10 guests