RomRaider

Quick question and hopefully someone can help. My buddy/tuner was able to get these definitions patched in on Ecuflash but hasn't been able to get them patched in on Romraider. What needs to be done to do so and at what lines do they need to be patched in at?

Thanks,
Sean

RomRaider has all of the ECU definitions in one file, so it takes some hunting to find the right place to make changes. If you search for the 32BITBASE and A2ZJ710J sections of RomRaider's ecu_defs.xml file, you'll find the places to insert the XML.

I haven't actually tried it, but I think you should just be able to paste them in. If I remember right, the format is basically the same, other than having everything in a single file of course.

EcuFlash loads definitions much faster than RR, so it has been the tool of choice for tweaking definitions. Qoncept was is/working on speeding up RomRaider's load time, but I don't think that got included in the most recent release.

Send me a pm, I already have a def I patched to use with romraider.

NSFW
Thanks again for getting back to me. My buddy's just having a hard time going through all the lines to find where to patch the definition in at. He thought he had it but it didn't change anything so I thought I'd post up.

fastblueufo
You have pm!!!

Thanks everyone,
Sean

any one working on a 08 Port ???

I'll fix the links some time in the next few days. Shackspace is gone but I have a Dropbox account now.

8/16/2011: Links fixed now.

Having a difficult time modifying the XMl's to recognize the SD patch, anyone have one they can share?

I downloaded an XML editor and managed to get the romraider XML's to work. It shows me the speed density tables in romraider etc. Now should I/ how should I go about modifying the definitions in openecu?

From the "Speed Density algorithm path for SuperH 7055f ECU v0.02" asm file attached to the first post:



Shouldn't that be a call to pull2d, rather than pull3d? The dyndef table looks like it's 2D, and a pull2d symbol is defined futher down in the file, but never used.

Can you describe the 'rich conditions' in more detail?

If it's going rich while load is increasing, like right after you release the clutch and go to full throttle, then I suspect that the root of the problem was not SD, it was this stuff:

viewtopic.php?f=25&t=7442

This is reassuring, since after porting the SD code to my own ROM, I found that the SD-calculated MAF was about 35% lower than the MAF readings that I've been using.

I tried starting over on the derivation of the constant that the SD code uses to roll up all of the unit conversions, and came up with something about 35% larger. Funny coincidence. I haven't tried flashing a ROM with that change yet but I intend to try it soon.

Does your SD system use the same kind of "SD constant" as the 16bit rom? If it does check out my Map Builder spreadsheet, it uses all of the gas law physics in the same way as you were describing in the IAT comp thread (and goes along with the spreadsheet you mentioned from freon's thread). I had to bring the injector scaler conversion factor into the calculations because flow scaling is inversely proportional to its hex value. And in many places I had to calculate with data in its un-converted (as the ecu uses it) form (basically just the hex values in decimal form).

There is a constant, but it doesn't seem to be used in the same way as the 16-bit constant and offset.

It's only used to encapsulate all of the units-of-measure conversions that need to be done in order to do "n = PV/RT" using the units-of-measure that the ECU uses internally. Actually it goes a step further so it's "MAF = RPM * PV/RT * constant." And then that gets scaled by a VE percentage that comes from a 3D table.

In order to get MAF values that are consistent with the MAF values I've been getting before going to SD, I would need to have VE percentages over 100% in most of the table. And keep in mind that manifold absolute pressure is an axis on the VE table, so VE > 100% is basically saying that the air in the cylinders is denser than the air in the manifold. I have no trouble believing that actually happens at some RPM/pressure combinations, due to resonance, but I can't believe that it's happening whenever MAP is greater than 10psi (-5psi MRP).

Another possibility is that the MAF numbers we're all accustomed to are actually 30% higher than the true number of grams per second entering the motor.

I re-did my calculation of the SD constant and now it doesn't align with true MAF or with Freon's constant. And I can't see anything wrong with my math or Freon's. Math is hard. I'm going to bed.

I figured out where my math diverged from Freon's, and mine was in error... His is correct. I think that having my IAT coming from right behind my air filter was also contributing to the difference, but only 10% at most.

So Freon, Merp, and I all found that Freon's SD math (which I believe is correct) calculates MAF numbers that are significantly lower than what our MAF sensors have been telling us. I can't figure out why.

I have some theories, but I don't really like any of them:

A) It could be that our MAP sensor are way off, but I'm sure someone would have noticed by now if boost gauges and dyno sensors read 25% higher than the stock sensors.

B) It could be that our IAT sensors are way off, but if I manually re-calculate VE using ambient temperature I'm still 25% off. And my CAI reads about 2-5 degrees F hotter than ambient temperature, which seems pretty reasonable to me.

C) It could be that our VEs are indeed over 100% when we're above (in my case) about 10psi MAP, at any RPM. I don't think that's true though. Being above 100% VE in a relatively small RPM range would be believable (resonance could explain that) but being above 100% VE for the whole RPM range doesn't make sense to me. Keep in mind that we've defined VE as something relative to manifold pressure, not relative to atmospheric pressure, so being in boost doesn't automatically imply VE > 100%.

D) It could be that Subaru's "grams per second" MAF numbers are actually about 25% higher than reality, so we've all gotten accustomed to inflated numbers. This seems like the least bad theory but I still don't believe it yet.

E) It could be that VE really does exceed 100% at all engine speeds when the manifold is above 10psiA. My intuition says "no way!" but the universe has no obligation to behave intuitively. Maybe there's something about this that I'm overlooking, which makes it totally reasonable.

F) It could be something I haven't thought of yet... Anyone got ideas?

And, whatever the reason for the discrepancy between SD-calculated-MAF and sensor-MAF, what should we - the people working on open-source SD hacks - do about it?

A) Do nothing, and just get used to VE tables that claim the engine is over 100% VE most of the time.

B) Do nothing, keep the VE percentages reasonable, and just get used to MAF and load numbers that are about 30% smaller than usual. When switching from MAF to SD, tuners will need to rescale all of the tables to accomodate for the fact that the calculated load will be about 30% smaller than before. This would be a pain in the ass, and it would not be practical switch between SD and MAF modes just by toggling the 'enable' switch that Merp added. Also, data logs wouldn't make sense unless you know what fueling mode the ECU was using, because the MAF and load values would be so different (that's a minor issue today due to injector scaling discrepancies, but this would be quite a bit worse).

C) Add a magic multiplier to the code so that you can keep realistic-looking numbers in the VE table and yet still end up with familiar MAF numbers. No table rescaling necessary. Merp's enable/disable switch would let you easily switch fueling modes. We could even add a fallback mechanism so that if the MAP sensor fails, the car switches to MAF mode.

I lean toward C, because having a hidden magic number that makes everything align bothers me slightly less than having VE > 100% across the board.