cam sync - Page 2 - Performance Forum

Forum Post / Reply
You must log in before you can post or reply to messages.
Re: cam sync
Thursday, February 11, 2010 8:42 AM
Whalesac wrote:
Joshua Dearman wrote:LOL...cam sync for a DIS. That's about the same as buying dog food to feed fish.

I'm not sure why you hate the idea so much Joshua. It cannot replace a physical Hall effect sensor, I agree. Maybe there is something I'm missing, but I would like you to explain though, how it doesn't detect when cylinder #4 is under compression when there is a clear dielectric difference between the air in the compression stroke to the air during the exhaust stroke. It's true that both plugs fire (i.e. waste spark), but the cylinder under compression receives the majority of the energy from the drop of the secondary coil due to the higher electrical resistance from this dielectric differences between cylinders #1 and #4 during a single spark event. If they just took the cylinder #1 firing events and divided by two like you mentioned earlier, there would be no way to determine the correct firing order for the injectors without input from the crank reluctor as well, making this product complete garbage. If you read the hyperlinks I posted above, MSD even states that the wire needs to be wrapped around the #4 spark plug wire and that the cam sync generator will detect when the #4 cylinder is under compression.

Therefore, even though you can run batch fire just fine, I don't see why there is a problem running a cam sync generator for the low RPM SFI the Jbody employs. As a EE I'm not seeing where you're coming from, or maybe I'm just not visualizing the circuit correctly.


Well, I'm not the guy that believes I'm always right, so if I'm wrong please correct me. But the way I see what is going is that the only thing the MSD is sensing is a magnetically induced frequency from the actual spark which is the result of the circuit decay. Now, there is no circuit until the voltage has meet and surpassed the dielectric resistance of the mixture of gasses between the electrode and the case. At which point a very short duration complete circuit is made and then decays which creates the spark. Now, exhaust gasses and good air + fuel do have different resistances....yes....this is actually how the ecotec ignition controller works....but it also compares the two spark channels. The MSD only polls one of the spark plugs, not both. So there is no real comparison to be made to know which one is doing what. All this unit can see is one sided decay which = spark. Now with limited info all you can do is divide time between by 2 and generate a square-wave signal.

Also notice, these MSD boxes are made for ECU's that dont run COP....in that respect there is no(or likely no) latching of cam timing to crank timing..so in reality you can imaging it would be possible that if you just give the ECU a dumb square wave following RPM but not necessarily latched with the crank it would be happy since it only uses this signal as a routing for which injector to fire. So I see the circuit design for the injectors being only two real actual injector outputs form a processor and then use the cam signal to fire a transistor setup to 'switch' the wire the signal actually travels thru...basically a 2 output to 4 output design in essence. Where the cam signal is used to 'switch' the signal down to the proper injector. Even if the processor uses 4 actual outputs the processor will still just use the cam signal as an actual high/low Input sensing setup and use the processor to control this same concept. Either way, this MSD box would still work.

Anyway, so if your running a closed-loop system with an O2 to control proper AFR, you have to generally worry little about the proper timing of the injector. It is reasonably simple to assume this signal generator can actually randomly send a time/2 square wave signal to fire the injectors whenever(whether it be at the right sequence or opposite) and the AFR can be fixed with the O2 to fuel the engine properly...(if there would even be a significant difference for offset fueling, which from my experiences with MS it makes little difference) and the spark timing is still run in DIS with only polling the crank sensor for accurate timing...no cam sensor required or used.

If there were two wires, one on plug #1 and one on #4, and this unit was meant for vehicles with COP, then yes, I would obviously have to admit this unit is doing more than just generating a dumb signal...obviously. But in this case, it is marketed for non-COP, non-cam/crank latching ECU's with closed-loop fueling....which tells me it's a dumb controller running a time/2 square wave signal.

I could be wrong tho..... I would like to hear more about your thoughts on this.

Lets also not forget this follows your spark timing which in-and-of-itself is a terrible idea since your spark timing is dynamic in reference to the crank anyway...that right there is enough for me to not like the entire concept. Also, this is why I believe the ECU's dont latch cam to crank signals either since it should at that point be sending a CEL at soon as your ignition timing is advanced far enough to skip over the 'latching' timing mark of the crank wheel. If our ECU's DO latch...then I blame terrible crank resolution (7X)...ugh...my head hurts...but not as bad as my keyboard hurts right now...

Thoughts?

EDIT: I guess you could rightfully say the MSD stores the last induction signal and compares it to the next event to 'sense' which event cylinder #4 was actually at(either compression or exhaust) when the plug fired...yes...yes...touche. But I still don't think that is the case as I'd imagine this would be more mass marketed towards other vehicles to adopt as well. Could it be that the saturn application is the only application they are aware of needing something like this....maybe...but I doubt that. I guess I'd have to do more research on how the saturn's signaling works since I'm pretty much comparing it blindly to ours....so that may be a shame on me. But I'm pretty confident they are close to a dead nuts match in operation and signaling.

EDIT X324890572439857: General spelling and such


Edited 3 time(s). Last edited Thursday, February 11, 2010 6:59 PM

"Never argue with an idiot. They'll drag you down to their level, then beat you with experience!" -Anonymous

Re: cam sync
Thursday, February 11, 2010 9:33 AM
I've always wondered, just HOW badly does not running the CPS/running in batch fire hurt city driving, and low speed cruise fuel economy?



Re: cam sync
Thursday, February 11, 2010 11:53 AM
Well I'll find out next month. I'm taking a 5,000 mile trip around the country with the Cav running in batch fire. Lot's of time to calculate mileage :-)



2010 Subaru Impreza WRX Limited
1999 Cavalier Z24 Supercharged
1999 Grand AM SE (Beater Car)
1997 GMC Sierra
2007 Honda CBR 600RR
2005 Honda TRX450R
Re: cam sync
Saturday, February 13, 2010 1:23 AM
Joshua Dearman wrote:Lets also not forget this follows your spark timing which in-and-of-itself is a terrible idea since your spark timing is dynamic in reference to the crank anyway...that right there is enough for me to not like the entire concept. Also, this is why I believe the ECU's dont latch cam to crank signals either since it should at that point be sending a CEL at soon as your ignition timing is advanced far enough to skip over the 'latching' timing mark of the crank wheel. If our ECU's DO latch...then I blame terrible crank resolution (7X)...ugh...my head hurts...but not as bad as my keyboard hurts right now...


That's a very good point I had not considered, but the MSD does not control the fuel. The PCM controls the fuel. I may be wrong, but the PCM doesn't use the cam sensor for anything more than a window, right? That is, it doesn't matter if there is a slight delay or advance compared to the rising edge of the pulse, just as long as the fueling events fall within that window. In this sense, like I said, low RPM operation I would suspect, would be sufficient to handle SFI. Off idle and PE, however, seem like they would be problematic.

I'm having a difficult time trying to refute what you've written...believe me though, I'm trying *. I believe I was thinking that the negative end of the coil itself is grounded when triggerd while the coil (inductor or time varying voltage source) feeds both #1 and #4 spark plugs in parrallel. In this instance, the current through the cylinder under compression would be lower, providing a smaller signal than the cylinder in its exhaust cycle giving the MSD a way to compare. Instead though, I think the #1 and #4 are fired in series, which I agree would provide no reference to compare against.




I have no signiture
Re: cam sync
Saturday, February 13, 2010 12:20 PM
Yes, the PCM does control fuel, but it either polls the cam at startup where advance is ~10deg.) to 'sync' with it and then no longer cares about it cause it just mathematically will follow the cam via crank teeth, or it constantly uses the signal to 'route' the injector signal to a certain injector. As far as I'm aware those are the only two ways ECU/PCM's do it and every ECU/PCM is one or the other. I'm not sure which way our computers do it, but only at startup would most likely alleviate any issues with advance > next crank tooth issues(as far as the MSD is concerned).

The Computer uses the cam signal for more than a window, the computer will see the crank timing notch twice for every cycle on cyl #1, without the cam signal it will have no idea which crank timing notch really meant 10degATDC-compression or 10ATDC-exhaust. So yes, this is where the 'window' would apply. As far as exactly how the computer expects to see and does what if it doesn't see it ect.(ie: does it have tight or loose timing expectations for this window to occur?) I have no clue about that without testing.

I honestly haven't looked to see if the coils are parallel or series, but yeah, your absolutely right. There would be nothing to compare if they were in series. However I also don't think that unit does store past and compare to recent waveform just because the time length of the waveform/time resolution required and the ability to store, read, compare, analyze, ect. While I know even an 8Mhz processor would be likely to keep up, I doubt MSD went to that expense. I would imagine the unit would be much more costly if the was that smart. I could be wrong tho.

PS. Didn't you once get an oscilloscope screen shot of the cam sensor in reference to the crank VR?







Edited 3 time(s). Last edited Saturday, February 13, 2010 7:42 PM

"Never argue with an idiot. They'll drag you down to their level, then beat you with experience!" -Anonymous
Re: cam sync
Saturday, February 13, 2010 8:32 PM
Joshua Dearman wrote:
PS. Didn't you once get an oscilloscope screen shot of the cam sensor in reference to the crank VR?

No. I believe that was Shannen (slowolej). I can't recall which thread that was though.




I have no signiture
Forum Post / Reply
You must log in before you can post or reply to messages.

 

Start New Topic Advanced Search