Enginuity 0.4.0 Beta

Developer topics relating to software that provides a tuning UI to alter ECU code and data

Moderator: Freon

Enginuity 0.4.0 Beta

Postby qoncept » Thu Nov 17, 2005 2:15 pm

Enginuity 0.4.0 Beta has been released, complete with data logging and 3d graphing.

http://www.enginuity.org/viewtopic.php?p=7046
Last edited by qoncept on Fri Nov 10, 2006 8:52 pm, edited 11 times in total.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby crazymikie » Thu Nov 17, 2005 8:53 pm

Once again- NICE JOB! :)

I think your scaling for RPMS for boost and WG duty are off-

IIRC, you need to take the hex value, and multiply by 50 (decimal) to get RPMS.

I'll see if I can find a car to try this on. Do you think you can add the knock correction map as well?

Thanks!
Mike
crazymikie
 
Posts: 105
Joined: Mon Jan 03, 2005 6:45 pm
Location: Watertown, MA

Postby qoncept » Fri Nov 18, 2005 4:20 am

Mike, which ECU version are you looking at? All of them? Some of the tables are looking a bit goofy, but I'm assuming they only go up to 3600(?) because after that you've already hit peak boost on a stock turbo. But RPM cells from all tables are calculated the same way (it's a single object) so the only reason the WG table could be off and not the others is a problem with the offsets.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby crazymikie » Fri Nov 18, 2005 5:25 am

The target boost tables and wastegate duty cycle tables should go up to 6800 RPM I think- that's where the stock ECU turns off boost control (at least on the 04 ECU). I'm using the ROM that you included (the nodelay one).

Also, the ability to edit the axis values would help a lot- for reference, on my car (turbo back) I needed to push the tables out to more than 5.0 engine load.

Look at 0x2A678 in the nodelay ROM (remeber to use big endian)-

0x88 = 136; 136 * 50 = 6800

Now go to 0x2A676-

0x70 = 112 ; 112 * 50 = 5600

Those values are the RPM axis points for wastegate duty I believe. If you look at the boost target table, the same should apply. What confuses me is at 0x2A66C, the value is 0x9A31, which doesn't make sense.


Please let me know what I can do to help.

THanks,
Mike
crazymikie
 
Posts: 105
Joined: Mon Jan 03, 2005 6:45 pm
Location: Watertown, MA

Postby New2Scoobs » Fri Nov 18, 2005 5:56 am

Do I need to download a base version before installing .11a ?
If so, can you put a copy of it on this forum because I can't get onto your site to download it.

Thanks
New2Scoobs
 
Posts: 60
Joined: Fri Nov 04, 2005 5:55 am

Postby qoncept » Fri Nov 18, 2005 8:39 am

New2Scoobs wrote:Do I need to download a base version before installing .11a ?
If so, can you put a copy of it on this forum because I can't get onto your site to download it.

Thanks

Nope, every version should continue to be the entire package. The app itself is only 64kb uncompressed right now, and with what I plan to do I don't see it ever getting above 1mb.

Mike, I'll take a better look at it tonight. I'm not sure why I'd be having those weird results. As for only the first byte of each RPM point being relevant, one of the older 2002 images had an RPM point, I believe in the timing table, that used both bytes (which confused me for a while). I can't remember the factor right off hand, but I believe I'm taking the 2 bytes and dividing by 5.15 rather than just the first and multiplying by 50. This isn't the cause of the boost and wg table problems, though, because it was doing that before.

I will get around to making the load, rpm, etc points variable. Since someone is interested maybe I'll go ahead and do that next. The main reason I hadn't already is because I wanted the Undo button to function just on the data cells, and honestly now I don't understand what I was thinking. :) Anyway, the weekend is here, so I should be able to get quite a bit of work done.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby crazymikie » Fri Nov 18, 2005 9:26 am

Just let me know if I can help at all. You have my email. :)


Mike
crazymikie
 
Posts: 105
Joined: Mon Jan 03, 2005 6:45 pm
Location: Watertown, MA

Postby cboles » Fri Nov 18, 2005 11:47 am

I can't get the version you posted (.11a) to work. It's not able to find the main class.
cboles
Site Admin
 
Posts: 1233
Joined: Wed Dec 29, 2004 5:45 pm
Location: Seattle, WA

Postby qoncept » Fri Nov 18, 2005 2:59 pm

cboles wrote:I can't get the version you posted (.11a) to work. It's not able to find the main class.

You need the latest JRE *update*
I don't know why they have to make it confusing or why this even requires the latest JRE, but you need to have the "JRE 5.0 Update" from Java. Hopefully this link will work..

http://javashoplm.sun.com/ECom/docs/Wel ... onId=noreg

I'm using the 5.0 beta of Netbeans to code. Maybe that's the problem. I'll check it out.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby qoncept » Fri Nov 18, 2005 9:52 pm

Boost and wg duty tables are fixed. Mike, I can do whatever tables people want. I imagine I'll end up adding everything eventually. I kind of want to quit adding new tables and implement other features first as I'll have to duplicate some work down the road -- I didn't use object oriented design quite as well as I should have to begin with. I may just go ahead and do it though because the other changes I'm planning for now are quite a bit more involved and I may very well be feeling too lazy for them. :)

Any requests for tables while I'm at it? There aren't a whole lot more I was planning on.

Oh, also, I'm a bit confused about a few things.. Any insight on how the "2D Maps" work? IE, 291F9-29204 is boost limit in 2004 WRX. What do the different cells represent? The 3D maps are pretty clear -- 3 ranges of 3 distinct data types, but the 2D maps only have 1..? (BTW, if there are only 2 axes, why is it called a "3D" map?)

282AF-282C8 = FRONT O2 SENSOR SCALING
2808A-280E9 = AIR FLOW SENSOR SCALING
2AEE1-2AEEA = BOOST SOLENOID CEL MAP THRESHOLD
286C3-286CC = INJECTOR OPENING TIME COMP
These are some more 2D maps I'd like to implement, but I don't know how to work with them.

The "Engine Parameters" tab I think will have those parameters plus a few of the common data values -- rev limit, maybe the CL/OL settings. Everything else will go in to an "Advanced" tab. Any suggestions on what belongs in the more basic "Engine Parameters" ? Sorry for all the questions, hopefully it'll all pay off though. :)
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby crazymikie » Sat Nov 19, 2005 5:48 am

The boost limit table should just be a series of boost targets with barometric pressures, so it should look something like (I'm just making these numbers up)

12.0 13.5 14.7 (barometric pressures)
17.0 18.0 20.0 (boost targets where you hit fuel cut)

The boost solenoid cel map threashold works the same way. The difference is that the boost level in this map should only cause you to throw a CEL, whereas the boost limit table will cause you to hit fuel cut.

Injector opening Time Comp is a map that is also called injector latency I think. This map has values for injector opening latency vs battery voltage. It's necessary when you change your injectors out.

The Air Flow Sensor scaling is the map that is used to calibrate the MAF after changing your intake. This map is a set of MAF voltages with values that represent grams of air/sec against them.

I'm not sure what the front O2 sensor scaling is- I can only think that it would allow you to change the AFRs that are associated with the voltages being read by the front O2 sensor. I'm not positive, though- I can try looking at it.

FWIW- these are the tables I think that are necessary (from Spiider's list):
29880-2989F = IGNITION CORRECTION MAP RPM SETTINGS (VERTICAL)
298A1-298BA = IGNITION CORRECTION MAP LOAD SETTINGS (HORIZONTAL)
298BD-2998C = IGNITION CORRECTION MAP DATA VALUES
(I dislike how this maps is all 'jagged' in its stock form)

2A7C9-2A7DA = TURBO DYNAMICS PROPORTIONAL BURST
2A7A3-2A7B4 = TURBO DYNAMICS PROPORTIONAL CONTINUOUS
(If you change your turbo or want to try and get better performance you will use these to affect how the turbo spools)

2808A-280E9 = AIR FLOW SENSOR SCALING
(if you change your intake you'll need this)

291F9-29204 = BOOST LIMIT
2AEE1-2AEEA = BOOST SOLENOID CEL MAP THRESHOLD
(If you up the boost in your car, you might need these)

291C8-291CB = REV LIMIT
(Nice to have - probably not necessary)

286C3-286CC = INJECTOR OPENING TIME COMP
??? = Fuel injector Scaling
(If you change injectors you will need these)

At some point, the knock learning tables would be nice as well- when you start making more power, I believe you should modify these tables appropriately- I don't know for sure since I don't have access to them in StreetTuner, so I've not really tried much with them. To put things in perspective, though, where the stock table scaling goes to 4.2 or so for engine load, I just pushed mine out to 6.0 (and this is on a stock turbo). Depending on what those learning ranges look like, it might be a good idea to modify them.

Please let me know if I can be of help. :)

Thanks,
Mike
crazymikie
 
Posts: 105
Joined: Mon Jan 03, 2005 6:45 pm
Location: Watertown, MA

Postby qoncept » Sat Nov 19, 2005 6:08 am

Mike, that's great. Looks like I've got plenty of work ahead of me. :)

Here's kind of a roadmap of what I plan on eventually doing, in a somewhat chronological order.
* Revise a lot of the code to more easily facilitate future additions (maybe)
* Add the rest of the data values we know of
* STX legal map tester (this may be independent of Enginuity)
* A compare ECU function that will show you the differences, and an option to copy the tables you want
* Datalogging w/wideband support (unless Tari gets it done before that, in which case I'll hold off on it for a while)
* Autotuning fuel from logs
* Realtime gauge display
* Road dyno
* Image dumping/reflashing within the program
* Image manager
* Realtime map editing

The realtime maps are what get me. I'm concerned the STX map tester won't catch, say, a Cobb REAL TIME map because, from what I understand, the changes are made in ROM instead of RAM..? I wish I had an AccessPort to play with, or even StreetTuner. I do have a buddy flashing one map as both realtime and base and sending me the images to compare. Hopefully they'll teach me something.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby crazymikie » Sat Nov 19, 2005 7:37 am

From my understanding of STX rules, you would need to check all boost-related tables- wastegate duty, turbo dynamics, boost targets, etc. It seems to be a grey area, though since leaning out fueling can increase boost from the additional heat or putting a downpipe on the car can cause higher boost levels.

In any case, for normal flashes, if you know the locations of the necessary tables to check for each ECU revision, a simple compare to a known stock image should be fine. In the case of realtime maps, the problem does become more complicated- there must be some logic in there to say 'Look at this table in RAM instead of what is on the ROM iff the RAM table exists.' Since that info is proprietary to Cobb, I'm not sure how hard it would be to test for illegal modifications. Even if the addresses for each map were consistent, it would probably be easy enough to change the address and reflash or soemthing like that.

Also, don't forget the ability to modify the axis values, please :)


Thanks,
Mike
crazymikie
 
Posts: 105
Joined: Mon Jan 03, 2005 6:45 pm
Location: Watertown, MA

Postby cdvma » Sat Nov 19, 2005 8:26 am

qoncept wrote:Mike, that's great. Looks like I've got plenty of work ahead of me. :)

Here's kind of a roadmap of what I plan on eventually doing, in a somewhat chronological order.
* Revise a lot of the code to more easily facilitate future additions (maybe)
* Add the rest of the data values we know of
* STX legal map tester (this may be independent of Enginuity)
* A compare ECU function that will show you the differences, and an option to copy the tables you want
* Datalogging w/wideband support (unless Tari gets it done before that, in which case I'll hold off on it for a while)
* Autotuning fuel from logs
* Realtime gauge display
* Road dyno
* Image dumping/reflashing within the program
* Image manager
* Realtime map editing

The realtime maps are what get me. I'm concerned the STX map tester won't catch, say, a Cobb REAL TIME map because, from what I understand, the changes are made in ROM instead of RAM..? I wish I had an AccessPort to play with, or even StreetTuner. I do have a buddy flashing one map as both realtime and base and sending me the images to compare. Hopefully they'll teach me something.


IMHO keep the app going in its current direction. Keep it an editor and not try and make it one giant all-in-one. Maybee do an app that is a dedicated editor and possibly a different app that is a dedicated logger. There are already a bunch of loggers out there that are really capable and do wideband logging but no good editors. It would be nice to have built-in flashing.

Also the auto-tuning fuel isn't required because the fuel maps are already in AFR targets and will be hit automatically.
cdvma
 
Posts: 86
Joined: Tue Jan 04, 2005 9:18 pm
Location: Roch. Inst. of Tech.

Postby qoncept » Sat Nov 19, 2005 8:45 am

cdvma wrote:Also the auto-tuning fuel isn't required because the fuel maps are already in AFR targets and will be hit automatically.

Maybe I'm a bit confused. The point of the autotuning would be for cells that have an AFR out of the stock O2 sensor's effective range. For example, in the image I'm looking at now, at 3600rpm with a load of 3.36g/s, the target AFR is .66lambda (I just added alternate views for the fuel table as requested earlier). In my logs, the O2 sensor show's it's only effective (maybe not even effective but will only show a range to) .77 lambda. I haven't actually done any tuning yet, so when I do, what exactly will I be tuning with a wideband?

Also, I kind of agree with your opinion on the scope. FWIW, I do intend to make the rom editing fully functional before I begin doing anything else, and actual logging would probably be the last thing I implement. Between complexity and priority, it just doesn't make sense to do it any sooner. I wouldn't bother with the flashing and dumping, but it'll be really easy to just make a gui for the command line version of ecuflash or whatever.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Next

Return to Tuning Software

Who is online

Users browsing this forum: No registered users and 5 guests

cron