I am getting a few sync errors occasionally, the fault is a Long Tooth Gap detected but I can't seem to see what the Syvecs is complaining about from the sync error log.
Could someone take a look at these SyncError logs for me and give me any feedback, I have a 60-2 crank wheel and am using the standard MR2 distributer for cam signal which is single key. My trigger levels are set as follows:
Cam is Falling Edge:
High trigger : 1.0v
Low Trigger: 0.5v
Crank is Rising Edge:
High Trigger: 3.0v
Low Trigger: 1.0v
I've also attached the cranking and initial run log for reference.
Thanks in advance.
Michael.
Sync Error Review Please
Sync Error Review Please
- Attachments
-
- Cranking5.txt
- (282.4 KiB) Downloaded 793 times
-
- syncerror6.txt
- (10.15 KiB) Downloaded 784 times
-
- SyncError5.txt
- (10.15 KiB) Downloaded 806 times
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Sync Error Review Please
Michael,
I'll have a look at the synclogs tomorrow - this machine hasn't got a VM installed to allow me to run the SSuite (I'll get round to it one day). But I have at least spotted an issue with what you have posted :
Crank is Rising Edge:
High Trigger: 3.0v
Low Trigger: 1.0v
Sounds like you may have got the wrong idea about the thresholds!
When we are using a "normal" falling signal then the waveform starts at (or near) 0V, it rises slowly, reverses direction, falls rapidly through 0V on downward, then changes direction again and rises slowly back up to 0V. When we are running rising edge then the sequence is upside down - so it drops and then rises before falling again.
The triggering can be understood by considering the two thresholds as "arm" and "fire". On a falling edge, so we don't pick up a load of noise, we must go up above the high threshold in order to "arm". Then to "fire" we need to drop down back below the low threshold. Since most sensors sit around 0V at rest, the falling threshold will be around 0V and the high threshold will be high enough to reject noise but not so high as to reject valid signals.
When running rising edge the situation changes. We must drop down below the low threshold to "arm", then we need to rise up above the high threshold in order to "fire". So for rising edge, the high threshold will normally be near 0V, and the low threshold will be low enough (it will almost certainly be negative for a VR sensor) to reject noise but not so low as to reject valid signals. So in this case you should probably be closer to a High of 1V (assuming that is where it sits when the engine is stopped) and a Low threshold of -1 (minus one) volts. (the gap between 1V and 3V is 2 V, so we need to subtract 2V from 1V to get to minus one volt).
If you do NOT use the rest voltage of the sensor the you open yourself to a world of pain and wandering timing. The rest voltage is the ONLY "constant" here - ideally it does not matter how fast the engine is turning, the sensor will always cross this voltage at the same angle. BUT if you use a voltage above or below then it will get there sooner, or later (in angle terms), depending on how fast the engine is turning (and hence how big the waveform is).
Hope this helps,
Pat.
I'll have a look at the synclogs tomorrow - this machine hasn't got a VM installed to allow me to run the SSuite (I'll get round to it one day). But I have at least spotted an issue with what you have posted :
Crank is Rising Edge:
High Trigger: 3.0v
Low Trigger: 1.0v
Sounds like you may have got the wrong idea about the thresholds!
When we are using a "normal" falling signal then the waveform starts at (or near) 0V, it rises slowly, reverses direction, falls rapidly through 0V on downward, then changes direction again and rises slowly back up to 0V. When we are running rising edge then the sequence is upside down - so it drops and then rises before falling again.
The triggering can be understood by considering the two thresholds as "arm" and "fire". On a falling edge, so we don't pick up a load of noise, we must go up above the high threshold in order to "arm". Then to "fire" we need to drop down back below the low threshold. Since most sensors sit around 0V at rest, the falling threshold will be around 0V and the high threshold will be high enough to reject noise but not so high as to reject valid signals.
When running rising edge the situation changes. We must drop down below the low threshold to "arm", then we need to rise up above the high threshold in order to "fire". So for rising edge, the high threshold will normally be near 0V, and the low threshold will be low enough (it will almost certainly be negative for a VR sensor) to reject noise but not so low as to reject valid signals. So in this case you should probably be closer to a High of 1V (assuming that is where it sits when the engine is stopped) and a Low threshold of -1 (minus one) volts. (the gap between 1V and 3V is 2 V, so we need to subtract 2V from 1V to get to minus one volt).
If you do NOT use the rest voltage of the sensor the you open yourself to a world of pain and wandering timing. The rest voltage is the ONLY "constant" here - ideally it does not matter how fast the engine is turning, the sensor will always cross this voltage at the same angle. BUT if you use a voltage above or below then it will get there sooner, or later (in angle terms), depending on how fast the engine is turning (and hence how big the waveform is).
Hope this helps,
Pat.
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Sync Error Review Please
Michael,
I've had a chance to look at the synclogs now and have found the following :
1) The crank waveform is not a VR sensor as I though it might be - it is Hall Effect. Not sure if it is connected to an AB or AU input - if it is AU then the thresholds are not adjustable.
2) The waveform shows a slow rise and a fast fall - this is "normal" for a sensor that does not have a good strong pull up, either internally or externally
3) Due to the slow rising edge it is the wrong edge to use for the crank sensor - you need to use the falling edge instead since this is fast and clean rather than slow, sloppy and a bit random
4) One of the Error logs shows that the sensor failed to register a tooth and that is what caused that loss of sync - there is nothing that you can do in the ECU to correct for a defective sensor that refuses to register teeth - you need to reposition or replace that sensor.
5) After switching to falling edge, your reference angle will move so you'll need to re-zero that with a timing light - lock the timing and then adjust the reference angle until the light and the ECU agree on the advance.
Hope this helps,
Pat.
I've had a chance to look at the synclogs now and have found the following :
1) The crank waveform is not a VR sensor as I though it might be - it is Hall Effect. Not sure if it is connected to an AB or AU input - if it is AU then the thresholds are not adjustable.
2) The waveform shows a slow rise and a fast fall - this is "normal" for a sensor that does not have a good strong pull up, either internally or externally
3) Due to the slow rising edge it is the wrong edge to use for the crank sensor - you need to use the falling edge instead since this is fast and clean rather than slow, sloppy and a bit random
4) One of the Error logs shows that the sensor failed to register a tooth and that is what caused that loss of sync - there is nothing that you can do in the ECU to correct for a defective sensor that refuses to register teeth - you need to reposition or replace that sensor.
5) After switching to falling edge, your reference angle will move so you'll need to re-zero that with a timing light - lock the timing and then adjust the reference angle until the light and the ECU agree on the advance.
Hope this helps,
Pat.
Re: Sync Error Review Please
Thanks for taking a look Pat, your explanation makes perfect sense and I will switch my crank sensor to falling edge as you suggest.
You do a great job of these technical explanations
It does seem that occasionally I get a late rising edge and in some cases a late falling edge which is weird and may as you say be related to a bad sensor or position of the Sensor.
I do have one question for you though, what sample rate does the syvecs use for the Crank and Cam sensors, looking back at the Sync Logs they seem to be showing quantization even on the cranking/idle log and that could be contributing to the change in shape of each pulse? Sort of implies that the sync logs are not displaying raw data but some sort of triggered event data.
If the signal is actually quantized at idle then how could it trigger correctly at high RPM, it seems to only have 1 to 2 sample points per pulse.
Regards
Michael.
You do a great job of these technical explanations
It does seem that occasionally I get a late rising edge and in some cases a late falling edge which is weird and may as you say be related to a bad sensor or position of the Sensor.
I do have one question for you though, what sample rate does the syvecs use for the Crank and Cam sensors, looking back at the Sync Logs they seem to be showing quantization even on the cranking/idle log and that could be contributing to the change in shape of each pulse? Sort of implies that the sync logs are not displaying raw data but some sort of triggered event data.
If the signal is actually quantized at idle then how could it trigger correctly at high RPM, it seems to only have 1 to 2 sample points per pulse.
Regards
Michael.
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Sync Error Review Please
Michael,
You're welcome regards the help
Sampling rate for the Crank and Cam sensors is again a little bit of a misnomer / misunderstanding.... there is no "sampling" in the traditional sense one might associate with a sensor (eg 100Hz sampling on analogue inputs on lesser ECUs), so it would be incorrect to state that we "sample" the signal every 10 microseconds, even though the SyncScope might perform an A/D conversion on the signal at that rate (configurable in the SyncScope section) - but that does not take part in getting a lock on the crank rotation (it is merely for diagnostic purposes so you can look back at the signal to figure out what was wrong).
Conceptually, you can consider the lock onto the crank signal as a digital phase locked loop latching onto a user defined sequence of signal events, operating in the angle domain. Threshold traversal is detected asynchronously - ie as soon as it happens, with "no" delay (to be pedantic, there will be a propagation delay through the logic). Threshold comparison is done by comparators and DACs - the DACs set the references and the comparators determine if the signal is above or below the references. The result is a 2-bit encoding of the current signal level, relative to the references. The task of determining whether something of interest has happened or not now reduces to edge detection on that 2-bit signal.
It is at this point that one might argue that we are "sampling", since we need to cross clock domains from the external asynchronous domain into the internal synchronous domain inside the angle clock hardware. Most digital designers will be familiar with the methods used to do that and one could suggest that this inter-clock-domain signal synchroniser is equivalent to the sampling you refer to. It should come as no surprise that the synchronous clock domain is running somewhat faster than the analogue side of things Doing direct digital synthesis of the angle clock tick would be nigh on impossible if this was not the case!
The "quantisation" you refer to in the cranking SyncLog is perhaps more correctly termed aliasing, since we are seeing the effects of insufficient sampling bandwidth to properly capture the signal detail (Nyquist bandwidth etc - the sampling rate is too low to pick up the higher order harmonics that would sharpen the edges of a square wave whose fundamental is in band, but then it is there to give an overview of the signal whilst cranking, not as a HiFi recording of it). This is to be expected since the cranking SyncLog needs to be sufficiently long in order to yield meaningful information - ergo the sampling speed is quite slow. IIRC it may be as slow as 1kHz, running for 10 seconds, to yield 10 seconds worth of capture data. Note that the SyncScope can run up to 100kHz, and that the angle clock domain is at least a thousand times as fast as the cranking SyncLog (but sampling at that speed you'de only get 0.01 seconds worth of cranking data, not very useful!).
You can see triggered event data in the SyncLog - look out for all the RED vertical lines. These are trigger events - every time that the trigger conditions are met, you get a red line. These are recorded separately from the A/D results since they can occur much, much faster. When rendered on screen, they are placed as accurately as the can be, relative to the sampled data (which is interpolated between samples). For "less busy" crank patterns (eg 36-1 on VR sensor) the cranking SyncLog is adequate to confirm that you have the right number of teeth and that you are triggering on the right edge. Here it is bandwidth limited BUT still fast enough to be useful
With regard to "quantisation" at high RPM - remember that an S6/8 can place a spark to within 0.25 degrees of crank rotation at over 20,000 RPM, and it can do it without ignition scatter Please feel free to draw your own conclusions about how fast things must be running in order to do that, and also bear in mind that the FPGA used to implement the angle clock hardware supports multiple clock domains.
Hope this helps,
Pat.
You're welcome regards the help
Sampling rate for the Crank and Cam sensors is again a little bit of a misnomer / misunderstanding.... there is no "sampling" in the traditional sense one might associate with a sensor (eg 100Hz sampling on analogue inputs on lesser ECUs), so it would be incorrect to state that we "sample" the signal every 10 microseconds, even though the SyncScope might perform an A/D conversion on the signal at that rate (configurable in the SyncScope section) - but that does not take part in getting a lock on the crank rotation (it is merely for diagnostic purposes so you can look back at the signal to figure out what was wrong).
Conceptually, you can consider the lock onto the crank signal as a digital phase locked loop latching onto a user defined sequence of signal events, operating in the angle domain. Threshold traversal is detected asynchronously - ie as soon as it happens, with "no" delay (to be pedantic, there will be a propagation delay through the logic). Threshold comparison is done by comparators and DACs - the DACs set the references and the comparators determine if the signal is above or below the references. The result is a 2-bit encoding of the current signal level, relative to the references. The task of determining whether something of interest has happened or not now reduces to edge detection on that 2-bit signal.
It is at this point that one might argue that we are "sampling", since we need to cross clock domains from the external asynchronous domain into the internal synchronous domain inside the angle clock hardware. Most digital designers will be familiar with the methods used to do that and one could suggest that this inter-clock-domain signal synchroniser is equivalent to the sampling you refer to. It should come as no surprise that the synchronous clock domain is running somewhat faster than the analogue side of things
Doing direct digital synthesis of the angle clock tick would be nigh on impossible if this was not the case! The "quantisation" you refer to in the cranking SyncLog is perhaps more correctly termed aliasing, since we are seeing the effects of insufficient sampling bandwidth to properly capture the signal detail (Nyquist bandwidth etc - the sampling rate is too low to pick up the higher order harmonics that would sharpen the edges of a square wave whose fundamental is in band, but then it is there to give an overview of the signal whilst cranking, not as a HiFi recording of it). This is to be expected since the cranking SyncLog needs to be sufficiently long in order to yield meaningful information - ergo the sampling speed is quite slow. IIRC it may be as slow as 1kHz, running for 10 seconds, to yield 10 seconds worth of capture data. Note that the SyncScope can run up to 100kHz, and that the angle clock domain is at least a thousand times as fast as the cranking SyncLog (but sampling at that speed you'de only get 0.01 seconds worth of cranking data, not very useful!).
You can see triggered event data in the SyncLog - look out for all the RED vertical lines. These are trigger events - every time that the trigger conditions are met, you get a red line. These are recorded separately from the A/D results since they can occur much, much faster. When rendered on screen, they are placed as accurately as the can be, relative to the sampled data (which is interpolated between samples). For "less busy" crank patterns (eg 36-1 on VR sensor) the cranking SyncLog is adequate to confirm that you have the right number of teeth and that you are triggering on the right edge. Here it is bandwidth limited BUT still fast enough to be useful
With regard to "quantisation" at high RPM - remember that an S6/8 can place a spark to within 0.25 degrees of crank rotation at over 20,000 RPM, and it can do it without ignition scatter
Please feel free to draw your own conclusions about how fast things must be running in order to do that, and also bear in mind that the FPGA used to implement the angle clock hardware supports multiple clock domains. Hope this helps,
Pat.
Re: Sync Error Review Please
Well Pat, that is a truly awesome explanation.
It is an ingenious approach, and to properly understand the intricacies of your explanation I would require a lot more back and forth so I won't waste anymore of your time on that. I understand enough now to move forward, perhaps if we meet in person some time.
I would never have thought that you could do the triggering using phase locked loops.
Thanks for the explanation, I've switched to falling edge and adjusted the reference now. Just need to fix the sensor now
It is an ingenious approach, and to properly understand the intricacies of your explanation I would require a lot more back and forth so I won't waste anymore of your time on that. I understand enough now to move forward, perhaps if we meet in person some time.
I would never have thought that you could do the triggering using phase locked loops.
Thanks for the explanation, I've switched to falling edge and adjusted the reference now. Just need to fix the sensor now
-
stevieturbo
- Posts: 1339
- Joined: Sun Dec 07, 2008 2:04 pm
Re: Sync Error Review Please
As I didnt understand the half of that....another query.
What causes a "long tooth gap" error ?
And on occasions on the sync logs which provide a 0-360 and a 0-720 reference
The 0-720 has been out of phase.
I know this as the cam trigger ( say old Subaru 3,1,2,1 ) would sometimes show the 3 teeth after the 0deg, and on occasions the sync log shows the 2 tooth just after 0deg.
Any reasons for that ?
Clearly it is sync'd and running ok in both instances otherwise the engine would not run correctly ( 4 coils ) So why does the sync log differ ?
I've seen it on my own car too with 36-1 and single huge tooth covering 360deg of rotation, so each edge indicates first or first or second phase.
What causes a "long tooth gap" error ?
And on occasions on the sync logs which provide a 0-360 and a 0-720 reference
The 0-720 has been out of phase.
I know this as the cam trigger ( say old Subaru 3,1,2,1 ) would sometimes show the 3 teeth after the 0deg, and on occasions the sync log shows the 2 tooth just after 0deg.
Any reasons for that ?
Clearly it is sync'd and running ok in both instances otherwise the engine would not run correctly ( 4 coils ) So why does the sync log differ ?
I've seen it on my own car too with 36-1 and single huge tooth covering 360deg of rotation, so each edge indicates first or first or second phase.
-
pat
- Syvecs Staff - Cleaner
- Posts: 356
- Joined: Fri May 23, 2008 10:23 am
- Location: Out there... somewhere
- Contact:
Re: Sync Error Review Please
Michael,
just to clarify, the triggering is not implemented as a PLL - the lock onto the signal may be envisaged conceptually as a digital PLL.
Stevie,
Long tooth gap errors are just what they purport to be - a long tooth gap What this means is as follows : let's imagine that we normally see 1 tooth every millisecond, that we're expecting the next tooth to come along in 1ms, so we wait for it.... now, to account for the engine speeding up or slowing down, we do permit the next tooth to arrive a little early (speeding up) or a little late (slowing down). You can set this in the minimum and maximum gap widths tables. So... let's say the gap is 10 degrees and we expect it to complete in 1ms - but we set the maximum gap to 15 degrees.... that would equate to 1.5 milliseconds instead of 1. At the point that the angle clock gets to 10 degrees from the last tooth, it is paused - it cannot continue until the tooth actually comes along otherwise it would be running too fast. At this point we allow some time to pass (another 0.5ms) but after this time an error is generated - basically we SHOULD have seen the tooth by now, but we haven't for some reason, therefore there is something wrong and we lose sync. The opposite is a short tooth gap, where we see a tooth too soon.
You will quite often see a long tooth gap error as the engine stops - that is normal since the angle clock still expects to see things and clearly that's not going to happen if the engine has stopped! If there is an engineEnable input and that is used to stop the engine, then it should suppress the error since it is expecting to stop.
With regard to the 720 references in the syncLog, that I would need to look into to be 100% certain on G10, BUT normally what will happen is that 360 sync will be acquired (you will also see this in G10) and the engine will run in wasted spark, batch fire, until it gets 720 sync. When running in 360 sync, the angle clock still runs up to 720 so a guess has to be made on the phase - it is irrelevant if the guess is right or wrong since it is running in wasted spark, batch fire so the end result, in terms of injection pulses and sparks is identical. Then, after a number of revolutions, it will try to go into 720 sync (2 revolutions minimum for G10), and at that point if it was out by 360 then that error will be corrected. Of course the interesting thing with G10 is that you cannot get 360 sync without also getting 720 sync, the pattern is "keyed" by the cam. So for this pattern it is perhaps a little interesting that you can initially sync up 360 degrees out - but this may be explained by the fact that in the first instance the "key" on the cam is used to identify a reference tooth on the crank so you get the right crank angle, and not necessarily worrying about the phase at this point - you can still fire even if you don't know the phase. Then the phase detection is delayed by 2 revolutions before finally going 720... unless of course you delay starting until 720 sync is acquired, but you will be cranking for some time!
Hope this helps,
Pat.
just to clarify, the triggering is not implemented as a PLL - the lock onto the signal may be envisaged conceptually as a digital PLL.
Stevie,
Long tooth gap errors are just what they purport to be - a long tooth gap
What this means is as follows : let's imagine that we normally see 1 tooth every millisecond, that we're expecting the next tooth to come along in 1ms, so we wait for it.... now, to account for the engine speeding up or slowing down, we do permit the next tooth to arrive a little early (speeding up) or a little late (slowing down). You can set this in the minimum and maximum gap widths tables. So... let's say the gap is 10 degrees and we expect it to complete in 1ms - but we set the maximum gap to 15 degrees.... that would equate to 1.5 milliseconds instead of 1. At the point that the angle clock gets to 10 degrees from the last tooth, it is paused - it cannot continue until the tooth actually comes along otherwise it would be running too fast. At this point we allow some time to pass (another 0.5ms) but after this time an error is generated - basically we SHOULD have seen the tooth by now, but we haven't for some reason, therefore there is something wrong and we lose sync. The opposite is a short tooth gap, where we see a tooth too soon.You will quite often see a long tooth gap error as the engine stops - that is normal since the angle clock still expects to see things and clearly that's not going to happen if the engine has stopped! If there is an engineEnable input and that is used to stop the engine, then it should suppress the error since it is expecting to stop.
With regard to the 720 references in the syncLog, that I would need to look into to be 100% certain on G10, BUT normally what will happen is that 360 sync will be acquired (you will also see this in G10) and the engine will run in wasted spark, batch fire, until it gets 720 sync. When running in 360 sync, the angle clock still runs up to 720 so a guess has to be made on the phase - it is irrelevant if the guess is right or wrong since it is running in wasted spark, batch fire so the end result, in terms of injection pulses and sparks is identical. Then, after a number of revolutions, it will try to go into 720 sync (2 revolutions minimum for G10), and at that point if it was out by 360 then that error will be corrected. Of course the interesting thing with G10 is that you cannot get 360 sync without also getting 720 sync, the pattern is "keyed" by the cam. So for this pattern it is perhaps a little interesting that you can initially sync up 360 degrees out - but this may be explained by the fact that in the first instance the "key" on the cam is used to identify a reference tooth on the crank so you get the right crank angle, and not necessarily worrying about the phase at this point - you can still fire even if you don't know the phase. Then the phase detection is delayed by 2 revolutions before finally going 720... unless of course you delay starting until 720 sync is acquired, but you will be cranking for some time!
Hope this helps,
Pat.
-
stevieturbo
- Posts: 1339
- Joined: Sun Dec 07, 2008 2:04 pm
Re: Sync Error Review Please
Subaru in question is G11 crank with old cam wheels and manual cam checklist.
On my own with the 36-1 I do occasionally get the long tooth error recorded, it never affects running though. Was just curious why.
I guess then I could increase the max gap widths a little ? At present these are 5deg higher than the 10deg actual gap window. ie 15deg.
Must admit I was surprised when it first ran as those numbers were in the tables anyway, they kind of made sense to me so I just tried them and hoped for the best and it seemed to work lol
At least actual gap made sense, didnt really know what max/mins were for but your explanation makes sense.
On my own with the 36-1 I do occasionally get the long tooth error recorded, it never affects running though. Was just curious why.
I guess then I could increase the max gap widths a little ? At present these are 5deg higher than the 10deg actual gap window. ie 15deg.
Must admit I was surprised when it first ran as those numbers were in the tables anyway, they kind of made sense to me so I just tried them and hoped for the best and it seemed to work lol
At least actual gap made sense, didnt really know what max/mins were for but your explanation makes sense.