Crome Highcam ignition issues debugged / Bandaided
Thread Starter
Honda-Tech Member
Joined: Dec 2006
Posts: 1,456
Likes: 0
From: Holiday, FL
Crome Highcam ignition issues debugged / Bandaided
For those here who have followed my last few post in this thread here https://honda-tech.com/engine-manage...ature-3203164/
I managed to get the det under control between 7-8K. The cause is a known issue with Crome that I've now witnessed firsthand.
First I'll clarify that the ignition shown in the Android TunerView datalogs is indeed following table timing +2 deg that Crome is applying between rows 1-16 and is not total as the total timing would be a bit more than shown since basetiming would bring this into the mid to high 20's in my case.
To be sure of this I double checked my mechanical timing with the service connector jumped and made sure the distributor was set to 16deg @ 750 rpm.
Every test run until I got this under control I noticed that the timing shown in the graphs was roughly 2 deg higher than my table timing until it reached rows 17 & 18 where it seemed to increase to about 4 deg over the table values.
Please note* anywhere after row 17 the timing seemed uncontrollable no matter if i reduced table timing or base-timing or both in combination with one another.
Rows 17 & 18 equaled 7007 & 7500 rpm which was exactly where the problem was happening so I started brainstorming to find away around this.
Most who have used Crome know about this and now use much better platforms however I have of yet to see someone provide enough information about this issue to understand where or what the problem is and so forth.
What I did to fix this in my case was two things
#1 since the logged highcam timing from rows 1-16 where roughly two deg advanced from the actual table timing I simply removed 2 deg off all highcam timing in the table to compensate.
#2 for the issue of all timing @ row 17 or above I simply avoided this by re-numbering my highcam rpm scalars. Since 599 - 2993 rpm on the highcam map is pretty much never used I renumbered the highcam rpm scalars to go from 0, 3500 upto 8979K. Renumbering these scalars freed up 6 rows which allowed me to reach my highest rev point by row 13 instead of row 17 @7000 and 18 @7500 rpm.
Note* that base-timing was left at its defaults since I had been playing around with this until experimenting with reordering the RPM scalars
Below is an example of what happens when the highcam timing is left untouched at all default scalars on a P30 highcam map. Notice the timing start to increase inspite of table timing trying to reduce timing.....
Blue = Boost, Red = AFR, Black = TPS, Yellow = Ign
6944@18 deg @ 8.7psi
7048@19 deg @ 8.5psi
High Cam
Example of timing progression with RPM after reordering rpm scalars that effectively counters this highcam ignition dilemma @row 17 or higher in Crome
7653@13 deg @ 8.5psi
Re-scalared High Cam (similar to P72 Highcam map)
Example of re-scalared Highcam RPM's
I managed to get the det under control between 7-8K. The cause is a known issue with Crome that I've now witnessed firsthand.
First I'll clarify that the ignition shown in the Android TunerView datalogs is indeed following table timing +2 deg that Crome is applying between rows 1-16 and is not total as the total timing would be a bit more than shown since basetiming would bring this into the mid to high 20's in my case.
To be sure of this I double checked my mechanical timing with the service connector jumped and made sure the distributor was set to 16deg @ 750 rpm.
Every test run until I got this under control I noticed that the timing shown in the graphs was roughly 2 deg higher than my table timing until it reached rows 17 & 18 where it seemed to increase to about 4 deg over the table values.
Please note* anywhere after row 17 the timing seemed uncontrollable no matter if i reduced table timing or base-timing or both in combination with one another.
Rows 17 & 18 equaled 7007 & 7500 rpm which was exactly where the problem was happening so I started brainstorming to find away around this.
Most who have used Crome know about this and now use much better platforms however I have of yet to see someone provide enough information about this issue to understand where or what the problem is and so forth.
What I did to fix this in my case was two things
#1 since the logged highcam timing from rows 1-16 where roughly two deg advanced from the actual table timing I simply removed 2 deg off all highcam timing in the table to compensate.
#2 for the issue of all timing @ row 17 or above I simply avoided this by re-numbering my highcam rpm scalars. Since 599 - 2993 rpm on the highcam map is pretty much never used I renumbered the highcam rpm scalars to go from 0, 3500 upto 8979K. Renumbering these scalars freed up 6 rows which allowed me to reach my highest rev point by row 13 instead of row 17 @7000 and 18 @7500 rpm.
Note* that base-timing was left at its defaults since I had been playing around with this until experimenting with reordering the RPM scalars
Below is an example of what happens when the highcam timing is left untouched at all default scalars on a P30 highcam map. Notice the timing start to increase inspite of table timing trying to reduce timing.....
Blue = Boost, Red = AFR, Black = TPS, Yellow = Ign
6944@18 deg @ 8.7psi
7048@19 deg @ 8.5psi
High Cam
Example of timing progression with RPM after reordering rpm scalars that effectively counters this highcam ignition dilemma @row 17 or higher in Crome
7653@13 deg @ 8.5psi
Re-scalared High Cam (similar to P72 Highcam map)
Example of re-scalared Highcam RPM's
Last edited by DC_Legacy; Nov 23, 2014 at 05:14 PM.
Thread
Thread Starter
Forum
Replies
Last Post