Moderators: EDS50, cgrey8, 2Shaker, Jon 94GT
Knock sensor and ignition advance logic
Hello. In some Ford strategies there is a logic of "self adjustment" ignition angle based on knock sensors. There is a borderline ignition map and few others advancing and retarding spark ignition angle with the appropriate deg/sec. In GM there are two maps. Hi octane and low octane with some variables. After KAM reset, PCM is starting to choose the best spark angle correction for the load points and subtracting them from Hi octane map. How is it working in Fords ? Does it sense knock from knock sensors and fill it to some kind of map in KAM memory ? (Can it be read by DRM ?) Or just using borderline (with all other modifiers) and advancing or retarding the ignition angle in a real time with the given speed (deg/sec) ?
Best regards.
Best regards.
Re: Knock sensor and ignition advance logic
Search these strategy documents for 'knock' to read all about it.
https://github.com/OpenEEC-Project/Strategy-Documents
https://github.com/OpenEEC-Project/Strategy-Documents
Cheers
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
Re: Knock sensor and ignition advance logic
Thank you. I have found that SPKAD is inherited from the previous cylinder. But still I can't find is it saved in KAM memory. If Load and RPM changes the all process of finding best spark ignition advance starts over again ? With all the registers flushed to 0 or SPKAD is saved in registers until the engine turns off ?
Re: Knock sensor and ignition advance logic
No it is not saved in KAM.
Spark is continuously recalculated.
SPKAD will be stored in a register or RAM.
Spark is continuously recalculated.
SPKAD will be stored in a register or RAM.
Cheers
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
Re: Knock sensor and ignition advance logic
So any time if the engine will be in a new load/rpm cell spark calculations will start again and again, even if the engine will back to the previous load/rpm cell ?
Re: Knock sensor and ignition advance logic
It's recalculated continuously whether operating conditions change or not.
A snip of A9L code;
Spark and knock one after the other, as part of the background subroutine list which loops endlessly.
Typical of most Ford strategies.
A snip of A9L code;
Code: Select all
21be: c3,55 vect 55c3 Update_advance # Update spark advance
21c0: 17,6d vect 6d17 UPd_KnkRet
Typical of most Ford strategies.
Cheers
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
John
95 Escort RS Cosworth - CARD QUIK COSY ANTI / GHAJ0
Moates QH & BE
ForDiag
Re: Knock sensor and ignition advance logic
Thank you for your reply. So literally there is just an appropriate spark retard after a knock occurs. Speed of advance is too small to optimise ignition advance.
- cgrey8
- Administrator
- Posts: 11304
- Joined: Fri Jun 24, 2005 5:54 am
- Location: Acworth, Ga (Metro Atlanta)
- Contact:
Re: Knock sensor and ignition advance logic
I've had the same wonder about ignition and knock control myself over the years. It SEEMS logical that the EEC could learn the retard needed for a given RPM/Load/ECT/ACT combination. But older EECs only deal with 1 dimensional and 2 dimensional data structures, and we call them functions and tables. To get more dimensions, more tables are created and usually functions or scalars are used to decide when one table is appropriate vs the other. Some strats have, for example, a Sealevel & Altitude tables which gives the "3rd" dimension a granularity of 2. But this is a really clunky and gets more complicated as you need more granularity in the 3rd dimension. As well, adding a 4th dimension is even more difficult. The add learning on top of this, and you get a really complex structure that takes a fair amount of processing power to interpolate across in a timely manner. Add learning to this and it gets even more complicated. THEN add that often how much spark needs to be pulled will change as the fuel in the tank ages and is refilled and you find that this learned data becomes defunct really quickly and thus doesn't justify its complexity.
Now if the EECs used modern day processors instead of 80s/90s era stuff, the computing power and memory needed would be trivial. Add to this, you could add a 5th dimension to this data structure which would be which cylinder you are learning for. Why is that important? Well the cylinders of engines are not identical. There are differences in head manufacturing, differences in head and intake runner performance, differences in head/wall temperature based on whether the cylinder is near the water inlet port or at the back of the block. And if the heads and/or intake are hand-ported, the potential for indifference is even greater.
To compensate for this, the EEC could learn that regardless of the fuel quality, some cylinders consistently need a certain amount of spark retard while other cylinders might could benefit from some additional advance. So you could easily come up with a short-term advance/retard algorithm that affects all cylinders as knock is detected, but over time, glean a long-term advance/retard on a per-cylinder bases that applies to each cylinder individually based on the current RPM/Load/ACT/ECT...think closed loop spark control where the knock sensor is your feedback.
For example, if the EEC detects that each time the knock sensor is triggered, it's always cylinder 7, the EEC could start retarding JUST cylinder 7 and learn that adjustment. Once 7 has been sufficiently retarded, eventually the knock sensor will trigger on some other cylinder, maybe cylinder 8. Then as cylinder 8 is backed off, it'll discover the next cylinder that creates knock...so on and so forth until all cylinders have been learned OR the cylinders that never reported are using the tune's MAX LIMIT spark allowed for the running condition.
Eventually the EEC will learn each cylinder's limits and thus have a multi-dimensional map of how much each cylinder can suffer before they create knock thus allowing each cylinder to run as close to optimal as possible under a wide variety of typical running conditions. At cruising & moderate acceleration loads, this could have a significant improvement in both fuel economy and overall responsiveness.
Although I have my doubts as to just how beneficial this would be to high load performance since so little time is typically spent at WOT vs CT/PT conditions to learn from. And the higher the load, the less you want to "test" the engine for its knock-limits because knock becomes more destructive as RPM/Load increases, especially on boosted engines. I've heard some engines, like the Hemi, are notorious for giving you more and more power as advance goes up until a cylinder detonates, then it's parts-replacement time. Thus the 1st time it knocks while at full boost, becomes the last time it knocks.
But that doesn't mean this strategy isn't without merits. I suspect some modern day strats use a technique like this to eek out every bit of efficiency from the engine possible in order to maximize fuel economy. At the very least, the mfgs likely do this to a significant number of "test engines" and discover that the engine design and manufacturing process is consistent enough that every engine of a given type has an extremely similar cylinder-to-cylinder spark tolerance and thus they can program this uniqueness into into tunes used on those engines thus avoiding unnecessary knocking in production vehicles.
For those familiar with modern day strategies, have you actually seen anything like this?
Now if the EECs used modern day processors instead of 80s/90s era stuff, the computing power and memory needed would be trivial. Add to this, you could add a 5th dimension to this data structure which would be which cylinder you are learning for. Why is that important? Well the cylinders of engines are not identical. There are differences in head manufacturing, differences in head and intake runner performance, differences in head/wall temperature based on whether the cylinder is near the water inlet port or at the back of the block. And if the heads and/or intake are hand-ported, the potential for indifference is even greater.
To compensate for this, the EEC could learn that regardless of the fuel quality, some cylinders consistently need a certain amount of spark retard while other cylinders might could benefit from some additional advance. So you could easily come up with a short-term advance/retard algorithm that affects all cylinders as knock is detected, but over time, glean a long-term advance/retard on a per-cylinder bases that applies to each cylinder individually based on the current RPM/Load/ACT/ECT...think closed loop spark control where the knock sensor is your feedback.
For example, if the EEC detects that each time the knock sensor is triggered, it's always cylinder 7, the EEC could start retarding JUST cylinder 7 and learn that adjustment. Once 7 has been sufficiently retarded, eventually the knock sensor will trigger on some other cylinder, maybe cylinder 8. Then as cylinder 8 is backed off, it'll discover the next cylinder that creates knock...so on and so forth until all cylinders have been learned OR the cylinders that never reported are using the tune's MAX LIMIT spark allowed for the running condition.
Eventually the EEC will learn each cylinder's limits and thus have a multi-dimensional map of how much each cylinder can suffer before they create knock thus allowing each cylinder to run as close to optimal as possible under a wide variety of typical running conditions. At cruising & moderate acceleration loads, this could have a significant improvement in both fuel economy and overall responsiveness.
Although I have my doubts as to just how beneficial this would be to high load performance since so little time is typically spent at WOT vs CT/PT conditions to learn from. And the higher the load, the less you want to "test" the engine for its knock-limits because knock becomes more destructive as RPM/Load increases, especially on boosted engines. I've heard some engines, like the Hemi, are notorious for giving you more and more power as advance goes up until a cylinder detonates, then it's parts-replacement time. Thus the 1st time it knocks while at full boost, becomes the last time it knocks.
But that doesn't mean this strategy isn't without merits. I suspect some modern day strats use a technique like this to eek out every bit of efficiency from the engine possible in order to maximize fuel economy. At the very least, the mfgs likely do this to a significant number of "test engines" and discover that the engine design and manufacturing process is consistent enough that every engine of a given type has an extremely similar cylinder-to-cylinder spark tolerance and thus they can program this uniqueness into into tunes used on those engines thus avoiding unnecessary knocking in production vehicles.
For those familiar with modern day strategies, have you actually seen anything like this?
...Always Somethin'
89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, FMS Explorer (GT40p) headers, aftermarket T5 'Z-Spec', GUFB, Moates QuarterHorse tuned using BE&EA
Member V8-Ranger.com
89 Ranger Supercab, 331 w/GT40p heads, ported Explorer lower, Crane Powermax 2020 cam, FMS Explorer (GT40p) headers, aftermarket T5 'Z-Spec', GUFB, Moates QuarterHorse tuned using BE&EA
Member V8-Ranger.com
Re: Knock sensor and ignition advance logic
A couple of thoughts on this.
Even in the older EECs you can actually have as many dimensions as you want, fairly cheaply. How ?
A lot of the funcs were already actually lookups to scale a value to a table row or column number for a table lookup. I think there are a few RPM x TEMP ones in almost every bin, where both column (RPM) and row (temp) of the a table are first 'scaled' via two func lookups. I think all/many have one or more RPM x Timer tables too... not sure.
There's nothing at all to prevent the output of that table being a further row or column lookup, so if you do this on both row and column of final table, you in effect get a 4d lookup. Sure, you can argue (rightly) there's some loss of accuracy, but the linear interpolate methods are reasonably good, so it's not that bad overall. Lookups are definitely not a 'cell by cell' answer.
I don't know if later EEC bins have a cyl by cyl memory for knock - doesn't seem too hard to do for me, as all later bins know what cyl they are sparking anyway , and it's only an 4/6/8 cell lookup (or does it have extra dimensions, in which case it's probably 4/6/8 tables in KAM ?. The retard calc doesn't have to fit within a single spark period (desirable if it's pinging, but could have a 'global' temporary retard for this) and it's what, temp x RPM x load based? Don't know if the knock detector has any 'knock amplitude' or anything to feed in.
Now , one thing I believe modern boxes do but EEC never did, is to deliberately advance timing to get a ping, and cyl by cyl, to get the maximum timing (per cyl) and so max economy and clean burn. I read somewhere that this is now done all the time across all running conditions. (Toyota maybe ?, but if they do, others will too) This also paves the way for automatic adjust for different fuels and ratings.... and when you add in all the sensors now with VVT and so on, remembering that many engines now have their cams independently adjustable, it's probably not 'special' anymore.
I did read that Toyota have an engine which can seamlessly switch from Atkinson cycle to Otto and back, which would save probably 40% fuel or more. Atkinson = hybrid, typically about double fuel economy of Otto. Toyota expand the VVT spread even more to achieve this apparently. May make hybrids less desirable, no battery, no extra weight ... I wonder how complex the EEC is for THAT engine ???
Even in the older EECs you can actually have as many dimensions as you want, fairly cheaply. How ?
A lot of the funcs were already actually lookups to scale a value to a table row or column number for a table lookup. I think there are a few RPM x TEMP ones in almost every bin, where both column (RPM) and row (temp) of the a table are first 'scaled' via two func lookups. I think all/many have one or more RPM x Timer tables too... not sure.
There's nothing at all to prevent the output of that table being a further row or column lookup, so if you do this on both row and column of final table, you in effect get a 4d lookup. Sure, you can argue (rightly) there's some loss of accuracy, but the linear interpolate methods are reasonably good, so it's not that bad overall. Lookups are definitely not a 'cell by cell' answer.
I don't know if later EEC bins have a cyl by cyl memory for knock - doesn't seem too hard to do for me, as all later bins know what cyl they are sparking anyway , and it's only an 4/6/8 cell lookup (or does it have extra dimensions, in which case it's probably 4/6/8 tables in KAM ?. The retard calc doesn't have to fit within a single spark period (desirable if it's pinging, but could have a 'global' temporary retard for this) and it's what, temp x RPM x load based? Don't know if the knock detector has any 'knock amplitude' or anything to feed in.
Now , one thing I believe modern boxes do but EEC never did, is to deliberately advance timing to get a ping, and cyl by cyl, to get the maximum timing (per cyl) and so max economy and clean burn. I read somewhere that this is now done all the time across all running conditions. (Toyota maybe ?, but if they do, others will too) This also paves the way for automatic adjust for different fuels and ratings.... and when you add in all the sensors now with VVT and so on, remembering that many engines now have their cams independently adjustable, it's probably not 'special' anymore.
I did read that Toyota have an engine which can seamlessly switch from Atkinson cycle to Otto and back, which would save probably 40% fuel or more. Atkinson = hybrid, typically about double fuel economy of Otto. Toyota expand the VVT spread even more to achieve this apparently. May make hybrids less desirable, no battery, no extra weight ... I wonder how complex the EEC is for THAT engine ???
TVR, kit cars, classic cars. Ex IT geek, development and databases.
https://github.com/tvrfan/EEC-IV-disassembler
https://github.com/tvrfan/EEC-IV-disassembler
Who is online
Users browsing this forum: No registered users and 94 guests