I'll get to the rest later/when it makes sense to.
jbelanger wrote: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.
That's bullshit, Jean! You have no idea what I have and haven't decided or done. You have some good questions there, though the first block are implementation details which are not on the table at this time. It was clearly a mistake to mention the 8 bit thing at all.
The questions are simple ones, and they have two different answers.
The first one:
Q: How much timing table adjustment range is required for ignition, and with what resolution.
A: So far we've had "51 isn't enough range" and "63.75 is enough range" and "1 degree isn't enough resolution" and "0.5 degrees probably isn't enough resolution" Paying attention ONLY to the actual requirements for tunability, can anyone provide a real world case, perhaps something odd like 2 stroke, rotary, whatever, that falsifies these statements?
And the other one:
Q: How much timing table adjustment range is required for fuel timing, and with what resolution.
A: More complex, we've seen that siamese setups have around 100 degree range requirement, and traditional port injected engines like to vary between start and end timing at different loads/rpms but that they don't vary away from that base point timing much at all. We've seen that resolution for fuel timing is far lower than ignition timing.
The decision will be based on logic, not my bias, not at all. If the required range and resolution can fit inside X data type, that is where it will go. That is my criteria for ALL variables in the firmware, nothing is unique to this, no arrogance or feelings or biases or preferences or prejudices come into play here, just "what do we need, then use smallest available type to fulfill that".
That decision process is 100% open, and can be "decided upon" by all of us at the same time, based PURELY on requirements and on the above rules.
jbelanger wrote: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.
You're clearly confused. I don't have a youtube account called CookeSuperior, and rather than going ahead and just doing what I want because I'm awesome and know more than anyone else, I post on the forum soliciting others input, and not just this forum, dozens. What you might have mistaken for what you described, in this instance, is my standing up for others input, others who I do respect more than those who are posting here in this particular field, not standing up for my own opinion. I had none at the beginning of this, just a few vague ideas which I wanted verifying or debunking.
It's a shame that we didn't get the opportunity to have a wine when I was last in your corner of that continent. If you knew me, you'd not be suggesting such things at all.
Fred wrote:It's a shame that we didn't get the opportunity to have a wine when I was last in your corner of that continent. If you knew me, you'd not be suggesting such things at all.
Maybe but I have only your posts to go by and they don't shows that for me and for others. So if that's something that bothers you because it may affect the perception people outside of the current community have of FreeEMS then you may want to think about it.
Fred wrote:The questions are simple ones, and they have two different answers.
The first one:
Q: How much timing table adjustment range is required for ignition, and with what resolution.
A: So far we've had "51 isn't enough range" and "63.75 is enough range" and "1 degree isn't enough resolution" and "0.5 degrees probably isn't enough resolution" Paying attention ONLY to the actual requirements for tunability, can anyone provide a real world case, perhaps something odd like 2 stroke, rotary, whatever, that falsifies these statements?
And the other one:
Q: How much timing table adjustment range is required for fuel timing, and with what resolution.
A: More complex, we've seen that siamese setups have around 100 degree range requirement, and traditional port injected engines like to vary between start and end timing at different loads/rpms but that they don't vary away from that base point timing much at all. We've seen that resolution for fuel timing is far lower than ignition timing.
The decision will be based on logic, not my bias, not at all. If the required range and resolution can fit inside X data type, that is where it will go. That is my criteria for ALL variables in the firmware, nothing is unique to this, no arrogance or feelings or biases or preferences or prejudices come into play here, just "what do we need, then use smallest available type to fulfill that".
That decision process is 100% open, and can be "decided upon" by all of us at the same time, based PURELY on requirements and on the above rules.
Clear?
Fred.
But these questions are biased because they assume that these are totally independent variables. Depending on the overall architecture, they may not as was suggested by my questions. Since you have to have 720 degrees to cover the entire timing domain then you have to be able to have variables that can represent that with the required precision. If you say each can cover only a part of the domain and transformations will be done to internal temporary variables, then so be it.
So the most basic requirement is 720 degrees due to the physical nature of the Otto cycle engine. The other user requirements are valid but are also based on implementation decisions where you have decided (and I'm not making a judgement here) that you needed a more refined requirement for some optimization (data size being one). But as mentioned, that has other impacts on processing which may be more important. These are no longer user requirements but software requirements and architectural decisions.
I disagree, it would be biased to assume they were somehow related, you assume everything is independent when you gather a raw requirement.
Re the basic requirement, sure, it's 720, but:
The Otto engine, and other related types of IC engines have a concept called "TDC" and pressure rising before it, and rising afterwards to some peak and then falling. This is universal. To ignore this fact is to ignore the entire concept of the IC engine. All types of IC engines suffer from severe issues if you light their mixtures off too far before TDC, and all suffer gross overheating and performance loss if you light it off at or after TDC for any appreciable time under any appreciable load. Thus the ignition tuning window (relative to each cylinder's TDC) is narrow by definition of the Otto cycle. How narrow? That is the question.
Many (including me) would say that it was foolhardy to allow the user to enter something vastly wrong in this area (for example, during intake stroke can be hazardous to the health of the user!!!). Right now I have 16 bit precision, and my range is 63.9? or so, all positive. This was a choice (lightly and temporarily made) and implementation decision (again, temporary), but aligns with the basic requirement for a narrow window of timing before, slightly after, and certainly around TDC. This is irrelevant, however, as before any such decisions can be made (independent of the current implementation), the problem needs to be understood, and the fundamental requirement is a real time tunability one, always. Once that is established it can then be decided to use a TDC reference, or just have 720 in the tables and let people tune based on that, or whatever else.
Again, I've decided nothing! I want to know, or be close to knowing, what the actual real world requirements for various platforms are, and then, we will decide, using the above mentioned process, what to do with the system.
Perhaps you're more familiar with use case style reqs?
"As a user I want to be able to adjust my ignition timing for optimal torque and efficiency over the entire operating range of my engine"
This is the fundamental one here.
Then the question is, what sort of timing is required to meet that on, all, or at least the vast majority of, engines.
We can narrow it down instantly to "beginning of compression stroke through to end of power stroke" which is 360 degrees. No one will EVER want to run their engine outside those parameters, and if they do, it is no longer something this project cares about as it is no type of normal IC engine.
However, we're not that naive, and we know that if you light that mixture off too far before TDC it will push the engine backwards! This is clearly not good. History shows us that good timing for most engines under load is between 15 and 45 degrees BTDC, unless your name is Ben Fenner or DSMLover, perhaps. During cranking and at under normal operating RPM and high load TDC and/or ATDC numbers are required, but these are of a very limited range indeed. 5? 10? 15? A well known tuner that I'm in contact with points out that some engines have crappy idle air valves and require ATDC timing to regulate idle speed. This is fair, BUT, likely to be a special case, and thus handled with a separate adjustment. The same could apply to cranking, though I loath such special case stuff except for where it makes good sense. People also like to run obscene advance levels at low pressure and high rpm calling it "cruise" and whilst low pressures and medium rpms are indeed cruise, low pressures and high rpms are a lift off or gear shift situation, only, and as such torque is not only not required it's not desired either. So, we're pretty much back to these things for limits:
Max timing for cruise regions? Ben wants 55+, but Ben needs EGT. Min timing for low rpm high load regions? OEMs seem to like -5 or so How fine do we need to adjust these figures? The finer the better, but past 0.1 degree you don't even know the base engine position that well without specialised equipment. It'd be tricky to do better than 0.5 degrees with a timing light during setup. How close do you need to be able to get two adjacent cells? Given the dynamic range of 60 degrees, perhaps circa 1% would be reasonable? or a little better.
Ignoring all of the other irrelevant-at-this-stage-shit above, if the answers to those three questions, or any of the foundations of them, are in any way flawed, point it out. Note, number of bits and tuning interface and so on and so forth is NOT being discussed at this point. Just the raw requirements. We'll start with ignition.
Fred wrote:Ignoring all of the other irrelevant-at-this-stage-shit above, if the answers to those three questions, or any of the foundations of them, are in any way flawed, point it out. Note, number of bits and tuning interface and so on and so forth is NOT being discussed at this point. Just the raw requirements. We'll start with ignition.
I guess I was still stuck on the 8-bit representation issue and the impact on the rest of the firmware. These questions are an entirely different issue and totally valid. I don't know if they should be issues for the firmware or the user interface of the tuning software but that is not relevant at this point.
jbelanger wrote:I guess I was still stuck on the 8-bit representation issue and the impact on the rest of the firmware. These questions are an entirely different issue and totally valid. I don't know if they should be issues for the firmware or the user interface of the tuning software but that is not relevant at this point.
LOL! WHAT 8 bit representation? No such thing exists. We're still at the requirement gathering stage, remember? :-p
BenFenner wrote:Do we care about cars running nitromethane (drag cars) or anything of that sort?
Maybe, tell us about them?
BenFenner wrote:Do we care about compound turbo setups running 40-60 psi?
Not if they're running on pump gas with high compression, no. No code in the system will ever pander the needs of people who are stupid and setup their shit in fucked up ways.
BenFenner wrote:Are we concerned with injecting for diesel engines?
BenFenner wrote:Are we concerned with injecting for diesel engines?
No.
Is it possible to do such a thing, or is that Fred's passion/vision? You can easily make hefty power at a low cost, by boosting your diesel to some 90+ psi, and controlling the fuel via common rail injectors. Typically you just get your turbo off the wing of a 747, slap in a couple special pistons (Teflon coated/short) and use an EMS that can control such a monster. Wa-la, your cranking 1kHP our of a nearly standard truck engine.
Perhaps an external DDS raking across a chunk of memory could address potential concerns of injector wave forms. Fire the DDS off of FreeEMS's injector output. I think it could technically be included in the plan. I see the hardware as a connector card option, and as us hardware guys typically do, the rest is just a matter of software
I think nitrousnrg has been toying with the though of a better injector driver, potentially a drop in replacement for the lowZ driver he's using on puma. Last I recall, he was thinking of something along the lines of raking memory across the output for a highly configurable injector wave form. I believe the concept would also play well with a diesel wave form. It's been lower priority, as such a device would put the design cycle outside of his the time constraints.
I think Fred's "no" was more of a note that he doesn't plan to include such code, but I think the platform can do it, and I think the Vanilla code is a good base for such growth.
The "No" was a "No, not in FreeEMS-Vanilla, main line in the foreseeable future, and possibly not ever." The reason being is that the requirements are MUCH different and the entire architecture would be wrong, just as if we designed for diesel it would be wrong for petrol. To do both well without excess hackage and dirtiness and complexity is probably impossible. To do both well is not impossible. To do both without excess hackage and dirtiness is possible. But not the combo. We're all about quality here, quality over quantity, and quality over diversity, the aim is to please most people most of the time, with absolute reliability and simplicity.
FreeEMS is, and always was, intended for spark ignition engines of up to 12 cylinders. Some of the mathematics have been designed to not present a restriction if the code was used for diesel or other fuels with vastly different AFR requirements, but if such a thing was incorporated it would be a fork, not something to be integrated, most likely.
