Reasons To Cut Injection/Ignition With Hysteresis

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by Fred »

jbelanger wrote:But my statement about having switches for features was for injection and ignition cut. If I want either or none, I want to be able to do so without going through the code that performs the cut because I don't want to have to diagnose the possibility of the code using a wrong value to perform the cut however unlikely it is.
Firstly, you must be used to software that repeatedly has issues with stability despite many years of development, such as ms (microsoft, of course...). Secondly, unit testing. Thirdly, even if there is a switch, who is to say that it even uses the configuration value for on/off that is supposed to be passed to it from the config? If you are code debugging (as opposed to debugging your setup and config) then there is a problem. That *might* be a valid excuse now, at the beginning, but it definitely won't be later. Unit testing and integration testing and user testing before each and every release will ensure that there are no regressions, ever. Software should only improve, it shouldn't go backwards...
If there is a bug that causes a wrong value I want to see it in a datalog or some other way but not through an unwanted side effect that could actually cripple an engine under the right circumstances and where you could maybe just limp home with switching off some safety measure but get stranded otherwise.
Stranded implies that you got somewhere successfully. What changed. If new code was loaded, and it flat out doesn't work, you've still got the computer, you can put the old one back on (default for dumb users will be to rip first always, smart users will check that box if they don't have a copy of the old stuff). If new code wasn't loaded, the codes behaviour will be the same as the trip to wherever you got to. If you're taking a not-fully-tuned car to a new environment (higher, lower, hotter, colder) then you should take a computer to finish the job. Abe was talking about getting near stranded at the top of a mountain due to backwards "it DOES work this way" baro correction on his system, he just pulled out the pc, richened the whole map up, and drove down again. As for visible in datalogs, of course, that goes without saying, doesn't it?
And who was talking about MS? ;)
That would be me! It's a perfectly good alternative for those that want a half arsed solution :-)
I'm just concerned that you may end up causing more problems for the intelligent users (and those helping others) to protect just a few idiots.
Fair enough, and I don't want to put too much (or any) idiot proofing on the device. Only where it seems unavoidable or of benefit to the majority. Take the duty cut idea. Abe and I sat and ate some in'n'out in his garage with the door open last night and watched the cars go by, and the parked ones not move. He was giving me an earful about exactly this, just as you are, but in person, and not publicly, and the entire time we sat there, there wasn't a single vehicle in sight that would be affected. It would be almost guaranteed that NO OEM cars would be affected, and any modified cars setup in an intelligent way won't be affected either. Injector sizing and fuel demand/supply engineering (which is what we are really discussing here) is a fundamental part of configuring a new engine build. Only someone cheap/tight or stupid would ever run into this.

As for the rev limit stuff, set (part of engine setup and initial tuning) and forget.
But I may be the idiot here
I HIGHLY doubt it! :-p
and I certainly have done stupid things and will do more in the future.
I don't doubt it at all! :-) No one is exempt from making a few mistakes. I've certainly made my share too!

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by jbelanger »

Fred wrote:
If there is a bug that causes a wrong value I want to see it in a datalog or some other way but not through an unwanted side effect that could actually cripple an engine under the right circumstances and where you could maybe just limp home with switching off some safety measure but get stranded otherwise.
Stranded implies that you got somewhere successfully. What changed. If new code was loaded, and it flat out doesn't work, you've still got the computer, you can put the old one back on (default for dumb users will be to rip first always, smart users will check that box if they don't have a copy of the old stuff). If new code wasn't loaded, the codes behaviour will be the same as the trip to wherever you got to. If you're taking a not-fully-tuned car to a new environment (higher, lower, hotter, colder) then you should take a computer to finish the job. Abe was talking about getting near stranded at the top of a mountain due to backwards "it DOES work this way" baro correction on his system, he just pulled out the pc, richened the whole map up, and drove down again. As for visible in datalogs, of course, that goes without saying, doesn't it?
Actually, I was thinking about an event such as a broken sensor where the code could go into another mode such as a limp home mode if that is even possible here or you simply disable a feature to not use the broken sensor (such as a baro correction). Then you are actually running under potentially different conditions which could expose some bugs that were not present under normal conditions and that you did not fully test and/or tune. So it may not be as simple to correct or to plan for and avoid as what you describe above.

And I was not questioning the datalog content but just mentioning where I'd look for clues on a questionable behaviour.

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by Fred »

jbelanger wrote:Actually, I was thinking about an event such as a broken sensor where the code could go into another mode such as a limp home mode if that is even possible here or you simply disable a feature to not use the broken sensor (such as a baro correction). Then you are actually running under potentially different conditions which could expose some bugs that were not present under normal conditions and that you did not fully test and/or tune. So it may not be as simple to correct or to plan for and avoid as what you describe above.
The tune, OK, but responsibility for that lies with the tuner. As for on/offable stuff. Good code with clean well defined interfaces and no side effects and tests wrapped around it doesn't suddenly throw a bug at you. I have hard code sensor over-ride stuff available, and I've used it to eliminate bad sensor readings that I got in Florida on the Volvo a year and a half ago. The tune was all over the place, so I hard coded (by switching the value of an if condition) 20C as IAT and then it just varied mildly with temp from day to night. We had our tune such that it was OK at either extreme and good in the middle. Later code didn't know it didn't have a genuine IAT, it just sees a number and works. It's excessive logic and configuration that actually complicate both the code and the setup, confusing both the devs and the users, respectively. In any case, I probably shouldn't be telling daddy how to suck eggs, if anything, just get on with it and prove my statements with a stable working system.
And I was not questioning the datalog content but just mentioning where I'd look for clues on a questionable behaviour.
Sure, I wasn't trying to imply that you were. :-)

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by BenFenner »

Fred wrote:you can set max duty cut to 1%(won't run at all), 20%(why?) 80%(conservative), 85%(a reasonable default), 97%(maxing things out) or 100%(risking instability due to dead time vanishing on some cycles due to dynamically changing real available time window and the injector just staying on(it'll go suddenly rich)), etc. If 100% still earns you a cut, then you have other options:
  • Up your fuel pressure some amount.
  • Change your injectors to something more suitable.
  • Lower your boost level
  • Tune it such that it runs the same as if the injectors were almost wide open, but you can see that in the tune, by lowering the lambda component of the tune, and seeing that it will be lean.
I'd been holding my tongue on this one but I'm going to mention it now just so you'll know where some people are coming from.

On Dan's e30 BMW 325is (M20B25 engine code) we installed VEMS before adding the turbo bits. Doing some N/A tuning with an otherwise completely stock BMW engine we logged injector duty cycles of 103% toward power peak. I know. That's impossible. If I had to bet, I'd say the firmware math was wrong, or the schedule algorithm created some anomaly, but the logs consistently showed close to 100% and over 100% injector duty cycle around power peak. Again, obviously the injectors weren't going over 100% but I do believe they were actually reaching 100%. The stock A/F curve (stock ECU) for an M20B25 goes very lean around power peak. It goes from 13.0:1 around torque peak to as low as 15.0:1 at power peak and then gets a little richer toward redline. For whatever reason BMW chose small injectors and that seems to have forced lean mixtures at power peak. Attempting to bring the A/F ratios to normal, sane values at power peak using the fuel table in VEMS brought no results obviously as the injectors are run around 100% from the factory.
BMW seems to have run the injectors from God in those engines.

My point to all this? Where am I coming from? I'm coming from experiences that showed over 100% duty cycle (I know, I know) from injectors in an OEM setup. Whether the VEMS designers expected that to ever happen or not, at least they didn't have some (well meaning, but ultimately too restrictive) injector duty cycle based cut that couldn't be set high enough to let this engine run as it did rolling off the BMW assembly line.

You see what I mean? How annoying would that be?
Last edited by BenFenner on Thu May 05, 2011 8:27 pm, edited 1 time in total.
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by BenFenner »

To keep us on track. Fred correct if wrong please.

Current list of proposed rev limiters (ign and/or fuel cuts):

RPM based (always on)
MAP based (always on)
Duty cycle based (proposed always on)
Sync loss based (always on)
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by Fred »

Ben, you contradicted yourself. If you're running the vehicle richer, on VEMS ("Another ECU" lol) then you're NOT running it as BMW supplied it. The 103% that VEMS shows is that it intended to supply 3% more fuel than what you actually got. Thus you could have leaned your map out in that area slightly and got EXACTLY the same result. Do you see how this is exactly the same result? IE, the cut would not have affected the way the engine ran, just what you put in the tables and settings. IE, you'd see that it was going lean there, at a glance, and in the process of finding the cut, and fixing it you would be made explicitly aware of your hardware limitations.

The cut would come when your intended fuel supply was less than the actual fuel supply. This is bad. You could adjust your intended to match the actual and not hit the cut.

The list is correct.
  • RPM cut is always required and configurable to the max value for RPM in FreeEMS (32767.5) or lower. Default will be 5 or 6k such that most engines are over protected or protected just right. Configuring such things is part of setting up the engine, only those who fail to follow the setup procedure (once documented) and/or review all of the settings themselves first, will be affected.
  • MAP based is not always required, but if set by default to something like 160kPa will never be hit by any NA engine and will allow safe and modest boost for someone stupid enough to not configure their box.
  • Duty cycle affects what you input into the box in terms of tune, forcing you to make reality and your tune match, but will always allow the same running conditions that you'd get if it wasn't there. All it does is force you to explicitly ask for them.
  • Sync loss is necessary and hard cuts all main outputs, the duration and/or hysteresis will be configurable, possibly with some aggressive limits to prevent people from disabling it all together and with some middle of the range sensible defaults. Note, this will only apply to loss of sync, not to fresh sync at startup. Hard cut for sync loss happens anyway and always, it's part of the fundamental operation of the decoders. All this adds is necessary hysteresis to prevent engine damage during repeated constant loss of sync.
Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by BenFenner »

Fred I think I wasn't clear enough. When tuning with VEMS we got the exact same A/F ratio behavior as stock. We found that no amount of fuel table manipulation would make the ratios any richer. When viewing the logs for injector duty cycle we found our answer. BMW drives their injectors on this engine at what would seem to be above 90% for a good portion of WOT and reaching 100% for at least some time. I can't attest for sure, but I assumed the duty cycle values logged are just calculated from pulse widths versus available crank revolution time. 103% pulse with is a result of that math, however wrong it may be. We were not us telling the ECU to deliver 3% more fuel than factory. VEMS fuel table is tuned with volumetric efficiency representation or approximation (as I'm sure we are all at least somewhat familiar) and we were around 80% VE at power peak. Putting in higher values didn't result in any more fueling even though the pump was up to it.


RPM cut and others being always "on" personally won't affect me any. But I can feel for the others who would like a definitive and functional "off" feature so they don't have to have anything nagging in the back of their head about rollover errors (maybe putting limit to 32767.5 actually rolls the variable over to 0 due to a bug?) or any other type of wacky bug. If it's off, it is off. There's no guess work. I know you'd say that there could be bugs in the "off" code... So I don't have any good argument for that. I guess we might just have to pick one method and go with it. It's not like it's impossible to change down the road. It might be painful, but sometimes making any choice and moving forward is better than dicking around for weeks and weeks and not going anywhere. I know.

As for defaults, that's probably a non-issue. Unless there are "sanctioned tunes" I don't see them having any bearing on anything anyway. I guess a bare-bones "tune" or "calibration" of some kind needs some defaults... But obviously everyone goes over those with a fine toothed comb before even cranking their engine for the first time. ;D
eezo20v
TO220 - Visibile
Posts: 10
Joined: Sun Mar 27, 2011 12:26 pm
Location: Perth, Western Australia

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by eezo20v »

BenFenner wrote:RPM cut and others being always "on" personally won't affect me any. But I can feel for the others who would like a definitive and functional "off" feature so they don't have to have anything nagging in the back of their head about rollover errors (maybe putting limit to 32767.5 actually rolls the variable over to 0 due to a bug?) or any other type of wacky bug. If it's off, it is off. There's no guess work. I know you'd say that there could be bugs in the "off" code... So I don't have any good argument for that. I guess we might just have to pick one method and go with it. It's not like it's impossible to change down the road. It might be painful, but sometimes making any choice and moving forward is better than dicking around for weeks and weeks and not going anywhere. I know.
Like I said, we have given all strategies the ability to be turned off for this exact reason. It takes the guess work out of whether the code/strategy is running or not.

We've had to put in place strategies that disable/turn off individual cylinders due to an injector getting stuck open on a bus and burning out a $20k cat converter and consequently throwing flames out the exhaust, setting fire to a dog!!

What happens to a guy that just wants ignition only on a carby setup?
What happens to someone that just wants to run injection as a piggy back type setup?
The powers that be will need to make decisions on these types of scenarios.

I think these discussions should be moved to another thread.
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by Fred »

BenFenner wrote:Fred I think I wasn't clear enough.
You sure were, you just weren't thinking clearly enough. Blame it on the tornado or something :-)
When tuning with VEMS we got the exact same A/F ratio behavior as stock. We found that no amount of fuel table manipulation would make the ratios any richer. When viewing the logs for injector duty cycle we found our answer. BMW drives their injectors on this engine at what would seem to be above 90% for a good portion of WOT and reaching 100% for at least some time.
Sure, but you could have manipulated the tables to result in exactly the same AFR with 100% duty reading instead of 103...
I can't attest for sure, but I assumed the duty cycle values logged are just calculated from pulse widths versus available crank revolution time.
Almost certainly, yes.
103% pulse with is a result of that math, however wrong it may be.
No, it's not wrong, what it means is that the pulse width that you requested is 3% longer than the pulse width being delivered (by virtue that you can't run at more than 100% duty). Which means...
We were not us telling the ECU to deliver 3% more fuel than factory.
...that yes you were telling the ECU to deliver 3% more fuel than the factory was, because neither the factory, nor VEMS, nor MS, nor Microtech, nor Motec, nor Autronic, nor Haltec, nor SDS, nor any other ECU can run more than 100% duty cycle, ever.
VEMS fuel table is tuned with volumetric efficiency representation or approximation (as I'm sure we are all at least somewhat familiar) and we were around 80% VE at power peak. Putting in higher values didn't result in any more fueling even though the pump was up to it.
The pump has fuck all to do with this. And if you're at or in excess of 100% already, of course you can't go higher. No matter how shitty and low the pressure was, more duty = more flow, even if not much, and more than 100% duty is never possible.
RPM cut and others being always "on" personally won't affect me any.
Tell me, who *will* it affect? No one with any automotive engine. And very few hobby engines either. If someone with a hobby engine that spins higher than 32757.5RPM then they may customise the firmware for their application. Anyone that is affected by the rev limit will be much MORE affected by the fact that their RPM can't actually be calculated or stored... So far, I'm happy with 0.5 RPM resolution and the highest revving engine used in a human carrying vehicle of IC nature (wankel, otto, miller, etc, NOT turbines...) is, afaik, around 20k, so we have some headroom there! Don't forget, that while you've been working and buying houses and so on and so forth, my brain has done nothing except think about engine management for 2 years straight. I've been developing and designing this system for 3 years, and the last 1.5+ have been full time, without work.
But I can feel for the others who would like a definitive and functional "off" feature so they don't have to have anything nagging in the back of their head about rollover errors (maybe putting limit to 32767.5 actually rolls the variable over to 0 due to a bug?) or any other type of wacky bug.
You've been using too much crappy low quality software! Good software is correct, not only by design, not only by inspection, but by being *PROVED* correct with unit testing! Such fears are, will be, and will be proven to be, totally unwarranted. Besides which, if such a bug exists, it should be found, not avoided!!!! Imagine bug free software proven to be correct by thorough unit testing in all non-realtime areas. Imagine the future of FreeEMS at the same time...
If it's off, it is off. There's no guess work. I know you'd say that there could be bugs in the "off" code... So I don't have any good argument for that.
Damn straight I will! And damn straight you don't! Besides which, for something like "fuel control off all together" the setting "number of scheduled fuel events = 0" means exactly that it is off... Using a value for a condition is perfectly legitimate. I'm good at what I do, and that is software development, leave me to the implementation details, thanks.
As for defaults, that's probably a non-issue. Unless there are "sanctioned tunes" I don't see them having any bearing on anything anyway.
What do you mean by sanctioned tunes? Explain, please. And yeah, you're right, they won't affect anyone that sets up their system properly. Only morons that leave the defaults in place and expect them to be correct.
I guess a bare-bones "tune" or "calibration" of some kind needs some defaults... But obviously everyone goes over those with a fine toothed comb before even cranking their engine for the first time. ;D
Exactly, whether you were being sarcastic, or not. If a default rev limit was 500rpm, that would be stupid as it would prevent the thing from starting and idling...

Google convention over configuration. Basically it comes down to having sensible defaults and fucking with a minimum of stuff. That is how good software is written and setup. Clearly it's not always possible to have a default that works for everyone with such a wide diversity of vehicles to try to please.
It takes the guess work out of whether the code/strategy is running or not.
Unit testing takes the guess work out, nothing else. Not even code reviews.
We've had to put in place strategies that disable/turn off individual cylinders
Easy, already possible by way of flexible architecture.
What happens to a guy that just wants ignition only on a carby setup?
What happens to someone that just wants to run injection as a piggy back type setup?
See comment to ben on zero events = off. Such vehicles have run and are currently running.
I think these discussions should be moved to another thread.
You're probably right, but I gave up on that some time ago, it's been derailed for a while. I may change the name of the thread, or just leave it, I'm not overly bothered, however I will bring up another cut that shall be enforced and for the same reason as the duty cut. Perhaps there are more similar ones?

MAP sensor maximum value! If the ADC count reaches the maximum possible on the MAP sensor, and maybe other sensors too, it should probably cut, however this should only take effect if it is the only available sensor to go by. If the vehicle is NA and has a TPS, it should fall back to that if out of range. Temperature sensors should probably fall to defaults, rather than cut, though either and probably "just use it" should also be options. It would suck to have your vehicle disabled by a faulty coolant temp sensor rather than just going to a limp mode. Not compulsory, for sure. If all cars were boosted it could be, though. TPS is no good for that...

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
BenFenner
LQFP144 - On Top Of The Game
Posts: 360
Joined: Wed Jul 09, 2008 3:15 pm

Re: Reasons To Cut Injection/Ignition With Hysteresis

Post by BenFenner »

Fred wrote:
BenFenner wrote:103% pulse with is a result of that math, however wrong it may be.
No, it's not wrong, what it means is that the pulse width that you requested is 3% longer than the pulse width being delivered (by virtue that you can't run at more than 100% duty).
I assumed the logged pulse width would be actual pulse width and not some stupid theoretical value that I told it to perform. Under that assumption, I thought the math was bad.
Your assumption makes more sense.
When you rear my concern under my assumption, you'll see I am making good sense. Maybe I forgot to mention that 100% injector duty cycle at power peak did not, in fact, provide even stock levels of fuel. Only going up to the 103% value by modifying the fuel table (wasn't even aware we were going "over" 100% at the time obviously) would give us the stock fuel delivery. I maintain it is likely a bug in VEMS. I know over 100% duty cycle is impossible, and said so many times.
Fred wrote:
BenFenner wrote:VEMS fuel table is tuned with volumetric efficiency representation or approximation (as I'm sure we are all at least somewhat familiar) and we were around 80% VE at power peak. Putting in higher values didn't result in any more fueling even though the pump was up to it.
The pump has fuck all to do with this.
It sure does. And I mentioned it because if you have an inadequate fuel pump you can also run into situations where modifying the fuel table produces zero results. I was just making sure to eliminate that variable. The injectors had reached their limit. Not the fuel pump.
Fred wrote:
BenFenner wrote:RPM cut and others being always "on" personally won't affect me any.
Tell me, who *will* it affect? No one with any automotive engine.
I guess it would affect those who believe things should be done a certain way, regardless if the immediate result is the same as doing it another way?
Maybe they are confused?

Like I said before. I'm just so glad I could get the fueling I needed from VEMS despite what seemed to be an apparent bug (to me). 100% duty cycle wasn't enough. 103% was enough. And the mixture readings actually changed between the two settings. Over 103% gave no more however.
In the real world, I was able to get the fuel I needed without some VEMS developer putting some immovable cap on injector duty cycle. Yah, maybe 1 in 1,000 would have reported that bug, and if VEMS were open maybe it would be more likely that I would have reported it... But more than likely I'd just be badmouthing VEMS for it's asinine limits. Wrongfully or not.
Fred wrote:You've been using too much crappy low quality software! Good software is correct, not only by design, not only by inspection, but by being *PROVED* correct with unit testing! Such fears are, will be, and will be proven to be, totally unwarranted.
I think this is the crux of the problem right here. I am much too used to poorly designed systems. I can and will give this project the benefit of the doubt and assume it will avoid many of the pitfalls of other, more poorly designed and implemented projects. I will be a convert. Lead and I'll follow.
Fred wrote:
BenFenner wrote:As for defaults, that's probably a non-issue. Unless there are "sanctioned tunes" I don't see them having any bearing on anything anyway.
What do you mean by sanctioned tunes? Explain, please. And yeah, you're right, they won't affect anyone that sets up their system properly. Only morons that leave the defaults in place and expect them to be correct.
I'm assuming that the configurations placed on the FreeEMS will be able to be saved to one all-encompassing configuration file. These are called "tunes" or "calibrations" or similar. When the firmware is first loaded, the configuration of the user-configurable settings could use some defaults. Right? So you'll have to put some defaults in. However, they don't even have to be sane defaults. They could be horrible defaults. Or they could be great defaults. The better they are, the more people will rely on them. At some point they can be good enough where the many of the defaults might be relied on by many people so much so that they are left alone mostly. Especially if these defaults are engine-make specific or close to that. Then you're getting to be in the business of providing sort of a default, sanctioned "safe" configuration for engine makes. it's a slippery slope. Not a bad one... It just is.

So, you have a spectrum. Crappy defaults on one end, and fully sanctioned default configurations on the other end. If you're not going to do fully sanctioned default configurations... Then personally I don't think it matters how good the defaults are. You as the user should go over them all with a fine toothed comb anyway. So they could be total crap and it wouldn't really matter. It only matters if you've given the user some explicit reason to assume the configurations will be decent. AKA: "Sanctioned tunes".

Getting sick of reading my shit yet?
Fred wrote:
BenFenner wrote:I guess a bare-bones "tune" or "calibration" of some kind needs some defaults... But obviously everyone goes over those with a fine toothed comb before even cranking their engine for the first time. ;D
Exactly, whether you were being sarcastic, or not. If a default rev limit was 500rpm, that would be stupid as it would prevent the thing from starting and idling...
Who cares if the default is 500 rpm? The user should go over the config and catch that.

Or how much do you expect to hold their hand with sane defaults? Just a thought is all...
And if you're holding their hand a bunch, why not just make the small leap to sanctioned tunes?
Fred wrote:I will bring up another cut that shall be enforced and for the same reason as the duty cut. Perhaps there are more similar ones?

MAP sensor maximum value! If the ADC count reaches the maximum possible on the MAP sensor, and maybe other sensors too, it should probably cut
You're obviously doing a better job than I am. I seriously was and still am trying to come up with sensible cuts... And MAP sensor out-of-range sounds like a sensible cut for sure. And I hadn't thought of it. =(
Post Reply