MazdaManiac

iTrader: (3)

Sure. There is always more than one way to skin a cat.

Generally, 9° - 11° or so at the torque peak with 350 g/sec or more (9PSI and above on most FI systems) is all you need.
There isn't more power to be made above that at the highest flame-front speeds.
Of course, adjustments will be made if the flame front is slowed by leaner/richer AFRs at the same load.
I've seen 16° there and it was essentially the same output.
What I have found, however, is that later than 5° causes a fairly fast drop in power and anything close to TDC or less can actually cause detonation.

TeamRX8

iTrader: (25)

there are many factors, I suppose any general statement can be challenged as such

hwnd

I'm not sure what you're asking. Who am I? ..I am myself.
Whose ecu? Mine
I provided the map on the RX7 club http://www.rx7club.com/showthread.php?t=876250

Did a good deal of disassembly on 8bit (FD and cosmo) and the 16bit ecu.

hwnd

Looking at this closer - this doesn't even align with the 280ps 16bit ECU ..let alone the 8bit ECU. I currently have it wired up on my bench with an engine simulator running @ 5200 RPM, 0 psi / atmo pressure.

What was your source for this map? I'm not sure that this is the stock FD ign map. It's not aligning with what I'm seeing from the ICD (integrated circuit debugger).
Perhaps I've done something wrong.

MazdaManiac

iTrader: (3)

An actual coil-tapped datalog from a stock FD.

I was asking because you said:
Which sounded like you were claiming that you were the engineer that programmed the original OE Mazda RX-7 timing maps.

TeamRX8

iTrader: (25)

Tapping the coil is not necessarily the same thing as the actual map, but of course we both know that .... and he said reprogrammed, not programmed.

.

MazdaManiac

iTrader: (3)

Of course not - it's better.
It is an actual log of the actual timing of the engine, not the predictive timing of the logic.


I realize that.
But he also said "the stock FD ECU", not "a stock FD ECU". I figured we might have been dealing with a bit of Engrish.

TeamRX8

iTrader: (25)

Only if you ignore mitigating factors that are modifying the output value from the map value, Jerry Lewis can bob and weave better than you, lol

MazdaManiac

iTrader: (3)

The FD is a modified n-Alpha setup. There isn't really much that affects ignition timing beyond the commanded value.

yomomspimp06

i had my laugh for the day...

hwnd

I honestly dont want to get into a debate here but you're spreading rumors.
I've disassembled the firmware (D8/mcu - 6800 family) and its nothing even remotely close to "modified alpha-n" in fact the TPS input (narrow or wide) doesn't contribute much to the final pulse width. It's actually very simple how it works.. the main input running to the tpu are ign, map, o2 & knock. the rest are sampled at other rates. we simply dont need 40 samples of tps per second as where the latter we would.
in the main code loop, all it does is grabs data from specific addresses (ign input, knock, etc) and run those input values through their respective conversion routines (raw into their UoM) and calls a few lookup tables for compensation maps (injector deadtimes for example) and adds that to the main ign and main fuel values. Once thats it, it'll shove those over to the proper pin(s) to turn on the injectors for X amount of times.

there are ZERO calcs for grams of air or any attempts at converting MAP to volume/density. all it does its blindly reads from a 3D table (fuel or ign) with a few values pushed onto the stack (mostly MAP & IGN but coolant temp shows up a lot).

The Denso code (HC16) works very close to the same - in fact a lot of those ECU's I've looked at have very similar looking code. I think Denso has a basic operating system for vehicles and probably tailored it to meet the vehicles requirements.

I based on that on the other SD setup's I've looked at and their routines are, byte for byte, the same in respect to calcing the fuel and ign values.

point is, i have spent a long, long time disassembling the firmware and the G5 (working as a multiplexer) ...it is surely isn't "modified alpha-n";

Here is a quick screen cap from IDA (two in fact) that shows loading the primary inputs (sensors) and how crudely the ECU determines to add / subtract fuel based on the O2 input.

For those who are paying attention, RAW.O2 is the measurement of the voltage read in and SENSOR.O2 is the converted value for the ECU to use in the fuel calcs. its also the value that it spits out when requested via diagnostics channel/port.

btw, my o2 code does read 0v - 5v ...it hasn't seen a narrow band sensor in a loooong time.


..but then again, what do i know?

rx 8speciale

iTrader: (3)

nice info hwnd, the vendor things he knows everything in his mind but he always fail at everything he do in reality.

MazdaManiac

iTrader: (3)

You are totally right on that - brain-fart on my part for the incorrect use of the term "n-alpha".

That was what I was trying to get across, however.
The logged ignition output essentially is the commanded value directly from the ignition table.

Is your entire self-justification for your existence entirely predicated on demonstrating at every possible opportunity what a complete moron you are?

hwnd

I'm curious, how do you know that? The coolant sensor, O2, knock and air temp sensors play a pretty big factor on the overall value of ign.

so again, I'm asking you, where are you getting this information from?
I'm honestly not attempting to make you look bad here but I can prove the stuff you've said so far doesn't even remotely align with the assembly/code/firmware.

Maybe you were not part of capturing those values and you, personally, really need those to be as close to factory as possible but I can assure you - they are not.

if converted to 3D, they look nothing like the maps I yanked from the 2rotor and 3rotor ecus. So even from a visual point of view - they're not close.

So I'm asking, how did you come to think those values are "commanded directly from the ignition table"? (btw, why are you saying 'commanded'? thats a silly word to use to describe the many routines the code jumps through to calc the final value ... just sayin').

rx 8speciale

iTrader: (3)

Now he is going to change again what he saying because he have no clue , im telling you he fails at everything he do. He dont know where he leave his head every day.

MazdaManiac

iTrader: (3)

Of course.
I didn't really do much "science" here - I observed nominal values for IAT and ECT and ran the engine on a DynoPack dyno while capturing the crank-referenced ignition events.
Much of the high-load areas were identical run after run, even as the ECT started to climb (to a point). It is mainly the part-throttle stuff that took some time to find stable, load-related values.
Since I am not a code-junky, I'm not really mentally equipped to hack the ROMs, so captured logs is the best way for me to do it.

We did the same thing with an MR-2 and a first-gen turbo Probe that week. We just needed to understand the factory baselines.

If you read this aloud with a Nigerian accent, it is actually pretty entertaining.
Last I checked, my head was in your mouth.

rx 8speciale

iTrader: (3)

more like your head is in your ***. You dont got nothing on me , you are just a broke tuner, period.

bse50

I'm sorry to jump into this discussion but I think that saying that the coolant sensor, o2, knock and iat play a "big" factor may be a bit of a stretch.
While I don't have the experience that you two have (cracking\programming and tuning respectively) I think that it is fair to say that the ign values are the main culprit along with fuelling, the other values can be treated as circumstancial "modifiers".
Where you really see many factors playing an important role together is our ecu.
With that said, for tuning purposes what the "base" maps are doesn't matter that much in my opinion. Knowing what the actually used maps (after interpolation or "routines" as you call them) are is what matters.
We could all run an engine in a controlled environment without the need to even add those additional routines, however that would be fairly impractical when trying to determine what an engine really needs in road going conditions.
I guess we could say that it is one of the few cases where we get the problem solved backwards. We need to know what really happens before moving back to the science and see what "should" (base map) happen.

What do you think?

TeamRX8

iTrader: (25)

well hopefully someone can post something useful up and get up past this trivial BS blathering ...

hwnd

Dude, just stop. you're in way over your head here.

bse50

Why? You're funny, mr know it all!

Kane

iTrader: (1)

I am not even sure what the question is at this point.

Or do we even have one?

Brettus

iTrader: (2)

Yes - yes we do :


It's been two years since you started this thread - when are you gunna do a proper dyno ?

TeamRX8

iTrader: (25)

yeah, just in case you forgot after all this time

Kane

iTrader: (1)

I did one, 220 HP, remember???