Special Requirements For Timing/Output Event Scheduling

[BenFenner]

With all due respect, Ben, (quite a lot) if you need TDC or ATDC timing in a normal load region, your setup SUCKS

Timing required for horribly shitty engines and octanes is indistinguishable from timing required for super high flowing engines at low boost levels (don't confuse boost levels with flow). The SR20s you're used to have highly inferior flowing intake manifolds, heads, smaller valves, and lesser cams than mine. I'm talking about timing required to make best torque. Not timing needed to keep detonation at bay.
Off topic a bit though, so I'll stop.

The main area for TDC or ATDC timing is at VERY low revs and very high loads, 100kpa at 300rpm requires some retarded timing.

We'll just leave it at that then. We need ATDC timing. Give it to us. =P

Re 0.3 or 0.4 or other increments, sure, this is an OK idea, but it will result in the inability to choose exact degree timing figures at various levels. I'd prefer something that divided into 1 cleanly inside our precision level.

Makes sense. I was going to suggest 0.33333333333333 increments but I know that's not happening.

Right now I'm leaning towards 10 - 53.75, but I'd be just as happy with 8.75 to 55, really. I've got to ask, though, would the difference between 53.75 and 55 be measurable?

I couldn't tell yah. Possibly not on my engine. Possibly so on others?
Either way, I still maintain that a 63.75 degree spread is just not quite enough. I'd hate to run into that sort of barrier, shitty human tuner or no.

How many kpa is that at? How can your octane level support that, and NOT support reasonable in boost timing???...

Here's my current timing map:

http://i4.photobucket.com/albums/y113/b ... 1297429629

Keep in mind I'm getting ready to remove much more timing in the boost section and that the 160 kPa row is the last properly tuned row. I'd imagine if I tuned the 220 kPa section properly I'd be into the negative numbers or close to it.
Past 8k rpm is also not tuned. I'm also waiting for EGT data to go more advanced during cruising. I do have 52 or 56 at the most right now though. And like you said, things get real retarded real quick at high pressure and low rpm.

(Notice how not being able to use whole numbers doesn't really phase me any. )

[BenFenner]

I'm having an internal battle with resolution versus breadth and I'm really starting to hate the idea. Add my vote to the more than 8-bit crew. 8 bits is just not enough for this. However, you could do like AEM does and have the resolution adjustable based on breadth of values. Have a small breadth of values? You can get tons of resolution. Have a wide breadth? You get less resolution. A band-aid for sure. =/

[jbelanger]

However, you could do like AEM does and have the resolution adjustable based on breadth of values. Have a small breadth of values? You can get tons of resolution. Have a wide breadth? You get less resolution. A band-aid for sure. =/

And if you start with some resolution and you change something on your engine and you need a bigger range then you're screwed (not really but it's pain).

8 bits is just not enough for this.

+1

Jean

[BenFenner]

And if you start with some resolution and you change something on your engine and you need a bigger range then you're screwed (not really but it's pain).

Not if you do it well. With AEM if you need more resolution it's a simple matter of rescaling the table which gives more resolution, and matches your current cell values to the nearest available. If you drop your breadth down some you can rescale the table and gain resolution, matching values to their nearest again. It is as simple as a right click. Not the best way to do things, but more flexible than you'd think.

[jbelanger]

And if you start with some resolution and you change something on your engine and you need a bigger range then you're screwed (not really but it's pain).

Not if you do it well. With AEM if you need more resolution it's a simple matter of rescaling the table which gives more resolution, and matches your current cell values to the nearest available. If you drop your breadth down some you can rescale the table and gain resolution, matching values to their nearest again. It is as simple as a right click. Not the best way to do things, but more flexible than you'd think.

That's interesting but still a hack. That also means that the timing table raw data is meaningless without the table resolution information and that if the resolution is changed or corrupted, the timing is wrong. So a single bit error can seriously screw up the whole table.

It is better to do it right from the start and use enough bits to not have a hack from the start.

Jean

[Fred]

I haven't had time to reply to the other posts, but this one needed attention...

That's interesting but still a hack. That also means that the timing table raw data is meaningless without the table resolution information

How is it a hack? It's designed in! As for the raw data being meaningless, that's plain false. The raw data, can/should/will/might contain the scale information... just as the current variable size tables have their sizes built in, and without that, guess what, the "raw data" is useless. Except the raw data includes that information, the block holds both the data, and the sizes. The same would be true of this.

and that if the resolution is changed or corrupted, the timing is wrong. So a single bit error can seriously screw up the whole table.

You have to trust your memory to some extent, this is a fact of life of computing. You don't store every variable in two flash blocks, copy them to two registers, do the operations on them twice, and compare the results at the end... you trust your code data is correct, perhaps with the exception of a boot time checksum, ditto your tuning data with boot time sanity and checksum checks. You have to trust your data, or the whole assumption of using a computer to do this task is flawed...

It is better to do it right from the start and use enough bits to not have a hack from the start.

Software development, in general, works like this:

• Understand the problem domain
• Gather requirements from user base
• Filter out bullshit
• Take a stab at meeting those requirements
• Test with users
• Refine original stab

No one in this thread has, so far, shown me a real requirement for greater than 63.75 degree ignition timing range, or greater than 127.5 degree fuel timing range (which with the exception of the siamese and outboard setups is of (relatively) little importance anyway).

Additionally, what is sad is that people that I also respect a great deal, and who have tuned hundreds of varied cars in the real world (as opposed to none or a handful) are agreeing with me elsewhere and not posting here. The only real consequence of that is that it looks like "Fred vs. World", when actually it's far more balanced...

We currently have 16 monstrous tables, several of which could be removed or down sized. Each takes up RAM space too. There are compromises here. One design decision (which I do not regret) was to be able to keep all tuning in ram and save the whole lot at once or in pieces when ever you like. We can reduce the ram usage by ditching that and only allowing one table tuned at a time. OR, we can reduce all the table sizes. OR, we can ditch the table/tune switching feature, OR we can reduce table sizes where resolution is in gross excess, or we can run XGATE out of flash only, ETC.

My point? You can't have your cake and eat it too.

Additionally, Ben, this thread is not the place for your dry humour XOR stop patronising me about engine dynamics, flow levels, pressure levels, knock limited timing and so on! Knowing you, you were just being funny in your impossible-to-read-over-the-internet way (which I love, when in a suitable context), but if not, don't be a prick.

Fred.

PS, back in a few days.

[jbelanger]

First, I don't think I need a lesson in software development. Second, I don't have a real stake in this so you can (and will likely) do what you want. Third, my only real requirement is future-proofing for what you can't foresee now and using 8 bits for timing information makes me uneasy (but that could change if there were more people posting on this subject).

And a hack can be designed in if you take the term in the broader sense and in this case, neither you or I can actually say if it was designed in or done after (unless you're very familiar with this system). As for my other statement being plain false, I'm not interested in arguing with you over this.

Have fun with your project.

[Fred]

First, I don't think I need a lesson in software development.

Whilst that is probably true, you're saying all sorts of things that indicate otherwise. I wouldn't have laid out that process in that way if you weren't.

Second, I don't have a real stake in this so you can (and will likely) do what you want.

No, I'll do what makes the most sense for the largest group of potential users, and what can be justified with real world examples and solid propositional logic founded in facts. This has always been true.

Third, my only real requirement is future-proofing for what you can't foresee now

Like this! Google YAGNI unless you already know what it means. Perhaps spend some time on c2.com if you didn't. The operating parameters of the internal combustion engine are an extremely well understood thing. The entire problem domain is old. There are dozens of implementations out there. What could possibly pop up out of the blue that isn't already understood? Not much...

and using 8 bits for timing information makes me uneasy (but that could change if there were more people posting on this subject).

They're not posting, but take my word for it, they are sharing their opinions with me, and they match.

And a hack can be designed in if you take the term in the broader sense and in this case, neither you or I can actually say if it was designed in or done after (unless you're very familiar with this system).

You're right, but it certainly sounds like it's well integrated from Ben's comments.

As for my other statement being plain false, I'm not interested in arguing with you over this.

That's a bit of a cop out...

Have fun with your project.

Is this really how you react because I disagree once in 3 years? Something else is going on here.

Second, I don't have a real stake in this

Did I see your name in the sig of the latest ms2 firmware the other night? Are you offended at the shit that I constantly give ms now that you have a small part in it? I think it's funny that you refer to other software as hacky when the ms firmware is, or at least was(I sincerely hope you're watering it down!), 100% hack.

Fred.

[jbelanger]

Don't make it look as if it is some sort of conspiracy. I just don't agree with you on many points (not just those mentioned here) and I don't like how you're acting more and more like you know everything and better than anyone else. And that your view (and bias, which we all have) is the only valid one. It's ok to have strong opinions but there's no need to put down everything (or everyone) else especially if you ignore or don't see the full context.

So my involvement in other projects has nothing to do with my posts here. If there was any conflict in my view, I wouldn't have made my little contributions on the few hardware issues that came up lately.

So it might be a cop out but you're just getting very tiresome.

Jean

[jbelanger]

Being a little bit less tired today, I'll add some questions here you should be able to answer easily since you already made your decision.

• How many variables/parameters are going too be in the engine timing domain?
• Do they all have their own range and precision?
• Do you have to related them to the actual engine position and if so with what precision? Are you going to use an angle clock at some point?
• How much processing is required to bring each variable to the common domain?
• How often do you need to make those computations?

And from a user point of view:

• How does the user see that data?
• How does he decide how to set the range and precision?
• Does he even need to do it or is it done for him?
• If something changes in his setup and the current range/precision/reference doesn't make sense how is this handled?
• Is there an issue with using older data then?
• If you have many tables for ignition timing (or injection timing) do they all have the same range/precision/reference?
• If you import a table with a different range/precision/reference does it change the imported table to match the others in the current tune, or change the others to match the new one?
• How do you educate the world that you imported a table but you can't have the exact same numbers you had before no matter what you do?

So as you can see, I have concerns other than just data representation. And by the way, your software development cycle left out quite a few steps in the 'meeting the requirements' phase where you need to answer some of the questions above before you can validate a choice such as using 8 bits for some data. And in any case, I doubt you have a complete list of user requirements (other than your own (and some others) as a user and as of now). It's not an issue to not have the complete list because you know this will evolve and you want to most complete list you can get (as you are doing) but you don't want to make decision early on that would make things quite difficult later. And using 'cute' acronyms is not going to make much a difference on what is needed or not.

By the way are you so short on memory right now or are you planning ahead? Don't forget that there are other compatible chips with significantly more memory but not that much more processing power.

Jean