I'll be there but doesn't look good weather wise :frown: Hopefully Sat will be overcast between the two storm coming in
Billy T.
gnxtc2@aol.com
Best ignition setup to run
- Thread starter buizila
- Start date
Welcome!
By registering with us, you'll be able to discuss, share and private message with other members of our community.
I'll be there but doesn't look good weather wise :frown: Hopefully Sat will be overcast between the two storm coming in
Billy T.
gnxtc2@aol.com
BTW, BS3 does not support inductive pickup for COP so lets just leave it that you did a comparison of a 4x crank wheel (IPU) with a distributor for a BS3 and XFI and then it would appear you converted the car over to COP with a Electromotive and compared results. Lets see what BS3 and XIM/XFI do when apples to apples comparison is done. It is quite possible there were wiring problems with the car that the owner (who did the 1st two systems) did not or could not identify.
Well inductive vs Hall, signal jitter, etc are a whole nother topic I think 
I think both are robust enough, provided you do your part not to make them less robust 
And that includes not reversing the VR signal polarity 
The scenario above is just trying to show whether or not the 1 pulse per cylinder scheme is fundamentally an adequate approach in a high performance racing scenario. That was the basic debate here. So far I vote that it is.
Don I think you might be also be implying that sw overhead might affect the counter value. I'm considering the FAST and other aftermarket ECU's here mainly, which don't have alot of timing correction to do at wot (assuming no knock sensor). The stockers do air temp, coolant temp, etc correction though.
But even if you do have ~ "alot" of sw calculation overhead, what I think should be happening is, the reference pulse comes in and that generates a hardware time stamp basically. That point in time has then been saved into a time stamp register, so the sw knows where in time 70 deg BTDC occurred. So it doesn't really matter if you have several degrees of sw overhead from there before you load the timer counter compare register. The counter is generally just free running. As long as you load the timer compare register with the (70 deg time stamp value + 40 deg later spark time value) (in our example) before it's actually time to spark, then the sw overhead is not really a factor. You can lazy around and just get around to it like 1 deg before it's time to actually spark is what I'm trying to say, doesnt matter because of how the hardware timer works.
So then when the free running timer = the timer compare register value, it's fire in the hold!
I dont know what they use, but I'd assume the FAST has at least like a 1MHz counter/timer, not the ancient, snail's pace 64 KHz version the stock ECU was said to have. So 1 bit of error out of 16 bits at 1 MHz rate would be 16x less error than the stocker
TurboTR
I think both are robust enough, provided you do your part not to make them less robust And that includes not reversing the VR signal polarity The scenario above is just trying to show whether or not the 1 pulse per cylinder scheme is fundamentally an adequate approach in a high performance racing scenario. That was the basic debate here. So far I vote that it is.
Don I think you might be also be implying that sw overhead might affect the counter value. I'm considering the FAST and other aftermarket ECU's here mainly, which don't have alot of timing correction to do at wot (assuming no knock sensor). The stockers do air temp, coolant temp, etc correction though.
But even if you do have ~ "alot" of sw calculation overhead, what I think should be happening is, the reference pulse comes in and that generates a hardware time stamp basically. That point in time has then been saved into a time stamp register, so the sw knows where in time 70 deg BTDC occurred. So it doesn't really matter if you have several degrees of sw overhead from there before you load the timer counter compare register. The counter is generally just free running. As long as you load the timer compare register with the (70 deg time stamp value + 40 deg later spark time value) (in our example) before it's actually time to spark, then the sw overhead is not really a factor. You can lazy around and just get around to it like 1 deg before it's time to actually spark is what I'm trying to say, doesnt matter because of how the hardware timer works.
So then when the free running timer = the timer compare register value, it's fire in the hold!
I dont know what they use, but I'd assume the FAST has at least like a 1MHz counter/timer, not the ancient, snail's pace 64 KHz version the stock ECU was said to have. So 1 bit of error out of 16 bits at 1 MHz rate would be 16x less error than the stocker
TurboTR
- Joined
- Jun 18, 2001
- Messages
- 1,459
Ted,
The EM isn't a COP system it is a wastespark system that uses a Type 2 DIS coil pack. That is the reason I'm not using it. I already own the MSD coils for a COP system.
The EM isn't a COP system it is a wastespark system that uses a Type 2 DIS coil pack. That is the reason I'm not using it. I already own the MSD coils for a COP system.
Edit- don't think that was clear enough. There should be a free running system timer. It nevers stops counting. When it gets too big, it just rolls over and keeps counting again. To generate a precision timed event like a spark, you load a timer compare register with a value that = the point in future time that you want the event to occur. Then when the free running timer evenatually = that compare register value, it triggers the event (ie spark). So that means as long as you get around to loading the timer compare register with the desired time point before the free running timer whizzes past, the event will occur at the desired time point.
So in our example above, let's say the 70 deg BTDC ref pulse came in when the free running timer happened to be at say 30,000 us. Hardware saves that time point in the time stamp register: TSR = 30,000.
Then we do the calculations above and determine that the spark needs to occur 1.111 ms after the 70 deg edge came in. Thus we load the timer compare register with a value = (30,000 us + 1.111 ms) = 31,111 us. So the TCR = 31,111.
Meanwhile the free running timer just kept on counting. Soon it reaches a value of 31,111, which equals the TCR value we loaded. When that occurs the event is triggered (sparks fly).
As long as we loaded the TCR before the desired spark event, we got our spark event at the right spot. Didn't matter how long after the TSC got loaded that it took us to load the TCR.
Hope that makes sense.
Interesting side note-our CPU's have a 64 bit counter that free runs. It runs at the native core frequency, say 2.0GHz. Seems that at 2 billion tics per second you would roll that counter over really fast, like seconds. But 64 bits makes a huge number, and it takes surprisingly long to roll that counter over, even when counting at 2 billion tics/sec
TurboTR
So in our example above, let's say the 70 deg BTDC ref pulse came in when the free running timer happened to be at say 30,000 us. Hardware saves that time point in the time stamp register: TSR = 30,000.
Then we do the calculations above and determine that the spark needs to occur 1.111 ms after the 70 deg edge came in. Thus we load the timer compare register with a value = (30,000 us + 1.111 ms) = 31,111 us. So the TCR = 31,111.
Meanwhile the free running timer just kept on counting. Soon it reaches a value of 31,111, which equals the TCR value we loaded. When that occurs the event is triggered (sparks fly).
As long as we loaded the TCR before the desired spark event, we got our spark event at the right spot. Didn't matter how long after the TSC got loaded that it took us to load the TCR.
Hope that makes sense.
Interesting side note-our CPU's have a 64 bit counter that free runs. It runs at the native core frequency, say 2.0GHz. Seems that at 2 billion tics per second you would roll that counter over really fast, like seconds. But 64 bits makes a huge number, and it takes surprisingly long to roll that counter over, even when counting at 2 billion tics/sec
TurboTR
Chris. Is there a problem with type 2 DIS coil packs? Just trying to learn of any shortcomings with wastespark in general. I haven't come across any short comings with the TEC unit, but I'm sure there's got to be something.
Todd. Thanks for the explanation so far. Very interesting. In theory, it would seem very hard to have so much timing variance in actual operation. What would interest me more would be actual studies into this reported variance to see it it's a real problem, and if it is occurring, then how is this variance occurring?
I'm going to start checking timing stability on some of the cars that come through the shop. My curiosity has been stimulated.
I'm going to start checking timing stability on some of the cars that come through the shop. My curiosity has been stimulated.
I'm going to start checking timing stability on some of the cars that come through the shop. My curiosity has been stimulated.
Oh Lord Donnie, I see another one of your tech threads starting.:biggrin:
Nah. I'm not going to get into it that heavy. It would take too much time from working on my car. :biggrin: I'm hoping someone else will take the ball on this one. Todd's got a good start on this going.
LOL I know you want to do it though.:biggrin: We'll just have to see who posts the info first then.
- Joined
- Jun 18, 2001
- Messages
- 1,459
No I just already own the MSD coils and want to use the Accel ICM to run a COP setup. I'm already familiar with Accel's software and like it better than the Wintec4. Just personal preference.
Whew, just found this thread and had to do a lot of reading!
I have not found any real issue with spark scatter using a 3 tooth pickup in my testing. Granted, I haven't tested it to 9500rpm, but I have (primitively)tested it over 7000 using a stock Buick crank sensor. Even using the stock predictive spark strategy, I haven't found any issue when it is set up correctly. I have had to tweak the inductive delay, when using the stock crank sensor at 16+ volts.
I am wondering if perhaps the issue Lonnie saw had to do with noise on the IPU signal
I disagree. The engine can't accelerate fast enough for the timing to get that far off. Todd's math seems to substantiate this.
I think Todd has done his homework and would love to sit down and chat with him sometime.
I have not found any real issue with spark scatter using a 3 tooth pickup in my testing. Granted, I haven't tested it to 9500rpm, but I have (primitively)tested it over 7000 using a stock Buick crank sensor. Even using the stock predictive spark strategy, I haven't found any issue when it is set up correctly. I have had to tweak the inductive delay, when using the stock crank sensor at 16+ volts.
I am wondering if perhaps the issue Lonnie saw had to do with noise on the IPU signal
I think everyone will agree with a 3 pulse crank trigger at high RPM (>7000) spark scatter CAN become an issue. To what degree we can all debate for sometime
I disagree. The engine can't accelerate fast enough for the timing to get that far off. Todd's math seems to substantiate this.
I think Todd has done his homework and would love to sit down and chat with him sometime.
Could have been noise. Usually VR signals are run in shielded cable; maybe they did not do so in the case that quickt mentioned. At least VR is differential signaling, which helps greatly for noise immunity.
My #1 lead suspect for the spark issue quickt was reporting would be a reversed polarity VR sensor connection. 2 things that does- it tends to make the trigger point less solid than cporrect polarity (as mentioned previous in this thread) and 2, it can make the timing slide with changing rpm (because the VR signal amplitude changes with rpm). Both of these fit with what quickt was saying.
If I see timing sliding around on an aftermarket ECU setup, first thing I check is VR sensor polarity. Don't 100% trust the mfgr to mark it right either (things happen), so I use a scope to make sure.
HighPSI, what testing did you do up to 7000 rpm with the stock Buick setup? Set the timing to 1 value in the map and shoot it with a timing light on the dyno, or? Can you comment on the results here please? Thanks.
TurboTR
My #1 lead suspect for the spark issue quickt was reporting would be a reversed polarity VR sensor connection. 2 things that does- it tends to make the trigger point less solid than cporrect polarity (as mentioned previous in this thread) and 2, it can make the timing slide with changing rpm (because the VR signal amplitude changes with rpm). Both of these fit with what quickt was saying.
If I see timing sliding around on an aftermarket ECU setup, first thing I check is VR sensor polarity. Don't 100% trust the mfgr to mark it right either (things happen), so I use a scope to make sure.
HighPSI, what testing did you do up to 7000 rpm with the stock Buick setup? Set the timing to 1 value in the map and shoot it with a timing light on the dyno, or? Can you comment on the results here please? Thanks.
TurboTR
- Joined
- Jun 18, 2001
- Messages
- 1,459
Are you saying spark scatter doesn't exist? What exactly are you disagreeing with in what I said? Your statement says "not that far off" so does it exist or not? I never made any statement as to what degree it may be, just that it simply exists. I do think that over 7000rpm in CAN be an issue that needs addressed. You stated you have no experience testing over 7000rpm do you think it is something that can be an issue in a motor running over 7000rpm? Right now I am running 90% of the track over 7000 rpm and one of the reason for my interest in this thread. To me a higher resolution crank trigger system just makes common sense. All the OEMS have gone to higher resolution systems. I am told that a bumpy road is enough to throw a factory crank sensor off to cause a misfire or spark scatter. To me it would seem a wheelie and hard landing plus the harmonics of a 1200+ hp motor can add up to some "issues".
Well the equation for theta we used above implies that the rpm (omega) doesn't factor into the error from accelerating the crankshaft. The error term from the acceleration comes strictly from the alpha (acceleration rate) and the time delay (squared):
(1/2 * α * t^2)
Interesting to ponder.
TurboTR
(1/2 * α * t^2)
Interesting to ponder.
TurboTR
Chris,
How much spark scatter are you seeing on your car. I haven't seen any up to 7000 (7400 to be exact). I am not dealing with theory, I am basing this on my experience so far. My test was very crude moving a timing light from cylinder to cylinder with an engine on a dyno. I think the real advantage with more pickup points is when looking for misfires and knock control.
I haven't seen a significant advantage going from a predictive spark ignition strategy with over 100 degrees of delay to a one with 25 degrees of delay. Just my experience.
How much spark scatter are you seeing on your car. I haven't seen any up to 7000 (7400 to be exact). I am not dealing with theory, I am basing this on my experience so far. My test was very crude moving a timing light from cylinder to cylinder with an engine on a dyno. I think the real advantage with more pickup points is when looking for misfires and knock control.
I haven't seen a significant advantage going from a predictive spark ignition strategy with over 100 degrees of delay to a one with 25 degrees of delay. Just my experience.
- Joined
- Jun 18, 2001
- Messages
- 1,459
Kudos to you guys who stand over these motors with timing lights at 7000+ rpm!! To be honest after last years fiasco with Diamond pistons I would say this theory was pretty big one on my radar. This year after getting a new piston design from DLS/CP it hasn't been as much a concern. IMO with the current setup if it exists it is at a minimum and timing variances are probably more prevalent with timing chain stretch and crankshaft twist.
My renewed interest in this topic relates more to COP and the tirgger mechanism that would be required for such an ignition system. I am also going to a belt drive on the new motor so I have to go EM, COP or a custom distributor set up like Dave and Tony's. I would rather the COP and have already purchased the coils for this.
IMO if spark scatter can exist on my current setup, even if it is in small amounts, it can be an even bigger problem with a system that relies entirely on an inductive crank pickup sensor and a computer to determine ignition timing without any mechanical limitations. Would you trust a COP setup to run a 3 pulse crank trigger? If not what would you run and why?
I did try discussing this with you in BG and have called to inquire about purchasing an Accel ICM and working with you on it but you showed no interest in the project or working with me. Would love to hear your opinion on what the best setup would be for a COP setup. Thanks for sharing your experiences.
Similar threads
