PicoScope 7 Automotive
Available for Windows, Mac, and Linux, the next evolution of our diagnostic scope software is now available.
Crankshaft sensor direction test
Crankshaft sensor direction test
Hello,
I would like to share small case where we have tested crankshaft speed sensor for crank direction rotation.
Purpose of this test was to verify if the crankshaft sensor recognises the reverse engine rotation as there was complaint the engine runs badly once a while and only after automatic start stop restart. Normal start-up had never any problem. (Faulty sensor could cause misreading and wrong timing).
We were not able to reproduce the issue but as not any other clue what could cause such condition, here is the test of the crank speed sensor.
This is the crankshaft sensor used in automatic engine start-stop systems. In order to allow the engine fire on first cylinder TDC and recognise if the cycle is firing and not exhaust/intake, the engine ECU must know exact crankshaft position, and this can be achieved only if the ECU knows exact position where the crankshaft stopped after engine was switched off. This is done by counting the crankshaft sensor signal pulses but sometimes the engine goes backwards when pushed back by piston being on compression phase and here comes the sensor ability to recognise the speed direction by applying different width on the pulses.
On this capture the engine was started and switched off manually by ignition switch and in first engine off the crankshaft stopped and did not reverse. The second engine stop the crankshaft reversed 8 pulses.
The signal looks not different by simply looking on the waveform unless the low pulse width is measured by rulers, but this is very time-consuming process. Luckily the Pico measurements functions have the low pulse width function that makes this very easy. Measurement of low pulse width between the rulers allows to lock the rulers and move left or right on timeline while the value is updated immediately.
Here is the captured waveform.
The test proved the sensor can recognise the direction of crankshaft, there was not more time for testing and vehicle was returned back to customer.
Thank you for reading and I hope it helps to someone with the crank sensor diagnosis or Pico measurement skills.
Regards,
Roman
I would like to share small case where we have tested crankshaft speed sensor for crank direction rotation.
Purpose of this test was to verify if the crankshaft sensor recognises the reverse engine rotation as there was complaint the engine runs badly once a while and only after automatic start stop restart. Normal start-up had never any problem. (Faulty sensor could cause misreading and wrong timing).
We were not able to reproduce the issue but as not any other clue what could cause such condition, here is the test of the crank speed sensor.
This is the crankshaft sensor used in automatic engine start-stop systems. In order to allow the engine fire on first cylinder TDC and recognise if the cycle is firing and not exhaust/intake, the engine ECU must know exact crankshaft position, and this can be achieved only if the ECU knows exact position where the crankshaft stopped after engine was switched off. This is done by counting the crankshaft sensor signal pulses but sometimes the engine goes backwards when pushed back by piston being on compression phase and here comes the sensor ability to recognise the speed direction by applying different width on the pulses.
The signal looks not different by simply looking on the waveform unless the low pulse width is measured by rulers, but this is very time-consuming process. Luckily the Pico measurements functions have the low pulse width function that makes this very easy. Measurement of low pulse width between the rulers allows to lock the rulers and move left or right on timeline while the value is updated immediately.
Thank you for reading and I hope it helps to someone with the crank sensor diagnosis or Pico measurement skills.
Regards,
Roman
-
Steve Smith
- Pico Staff Member
- Posts: 1672
- Joined: Sun Aug 25, 2013 7:22 am
Re: Crankshaft sensor direction test
Hello Roman, thank you for the post and taking the time out to create this information for others to digest
This is something like you mentioned, not immediately apparent until you analyze the data in-depth
I remember the 1ND Engine from Toyota returning a Cam/Crank code after restarting the engine due to the PCM monitoring the correlation at the point of ignition off
In some cased (being a diesel) the engine would rotate backwards due to compression reactance upon the crankshaft and therefore store a fault code as the expected sequence of cam to crank pulses would change.
If I remember correctly, a new PCM was required
I assume the customer will return for more diagnosis?
If so, could we also capture the camshaft signal too as this would help correlate events between the forward and reverse rotation of the crank (Perhaps add ignition too)
Below we can see the acceleration in the crankshaft after the engine speed has fallen to its lowest level (See circled items)
Using Deep Measure we can then capture data about every pulse in our pulse train
More on Deep measure can be found here topic17711.html (PS6) and here viewtopic.php?p=103559#p103559 (PS7)
The frequency value certainly increases whilst the low pulse width remains fairly constant (Pulses 70 to 76)
What intrigues me is how the low pulse width is constant throughout the forward direction of crankshaft (approx.53 microseconds) yet in reverse it switches to approx. 100 microseconds? (Very cool)
Thank you again for taking this time out to share the above information
Take care.....Steve
This is something like you mentioned, not immediately apparent until you analyze the data in-depth
I remember the 1ND Engine from Toyota returning a Cam/Crank code after restarting the engine due to the PCM monitoring the correlation at the point of ignition off
In some cased (being a diesel) the engine would rotate backwards due to compression reactance upon the crankshaft and therefore store a fault code as the expected sequence of cam to crank pulses would change.
If I remember correctly, a new PCM was required
I assume the customer will return for more diagnosis?
If so, could we also capture the camshaft signal too as this would help correlate events between the forward and reverse rotation of the crank (Perhaps add ignition too)
Below we can see the acceleration in the crankshaft after the engine speed has fallen to its lowest level (See circled items)
Using Deep Measure we can then capture data about every pulse in our pulse train
More on Deep measure can be found here topic17711.html (PS6) and here viewtopic.php?p=103559#p103559 (PS7)
The frequency value certainly increases whilst the low pulse width remains fairly constant (Pulses 70 to 76)
What intrigues me is how the low pulse width is constant throughout the forward direction of crankshaft (approx.53 microseconds) yet in reverse it switches to approx. 100 microseconds? (Very cool)
- Image 1
Take care.....Steve
Re: Crankshaft sensor direction test
Hello Steve,
Thank you very much for super detailed explanation, especially the Deep Measure is very useful as the value can be sorted out by columns which make it very easy to pinpoint the error which would be almost impossible to do manually.
If the vehicle ever comes back and I will be called to attend it, I will post detailed update here.
With regards to this sensors design, I have an example from Audi ABS sensors. These behave very similar even the design is different, there are two wires only and the signal is on the ground wire. However, when it comes to scoping part, it will be basically same as the crankshaft sensor.
This case was faulty ABS unit that caused excessive noise on the RHF wheel speed sensor signal wire and sometimes logged intermittent DTC, car came with two times replaced ABS sensors and the test was originally for the wheel bearing magnetic pick-up ring integrity which was OK.
Here is the difference between the wheel’s direction, basically the left and right wheels rotate opposite direction against the sensors so left and right will have different high pulse width when the vehicle moves one direction. (Blue is RHF and Yellow is LHF wheel)
Here is the waveform where the car is on hoist and driven by gear forward, then stopped and follow by reverse where the pulse width is swapped, note the pulse width when the wheels are stationary.
(The RHF, Ch“A” is more filtered due the high noise)
Thank you very much for super detailed explanation, especially the Deep Measure is very useful as the value can be sorted out by columns which make it very easy to pinpoint the error which would be almost impossible to do manually.
If the vehicle ever comes back and I will be called to attend it, I will post detailed update here.
With regards to this sensors design, I have an example from Audi ABS sensors. These behave very similar even the design is different, there are two wires only and the signal is on the ground wire. However, when it comes to scoping part, it will be basically same as the crankshaft sensor.
This case was faulty ABS unit that caused excessive noise on the RHF wheel speed sensor signal wire and sometimes logged intermittent DTC, car came with two times replaced ABS sensors and the test was originally for the wheel bearing magnetic pick-up ring integrity which was OK.
Here is the difference between the wheel’s direction, basically the left and right wheels rotate opposite direction against the sensors so left and right will have different high pulse width when the vehicle moves one direction. (Blue is RHF and Yellow is LHF wheel)
(The RHF, Ch“A” is more filtered due the high noise)
-
Steve Smith
- Pico Staff Member
- Posts: 1672
- Joined: Sun Aug 25, 2013 7:22 am
Re: Crankshaft sensor direction test
Thank you again Roman, this is awesome stuff and now a case study too thanks to you sharing your ABS adventure
I wanted to add just how "noise" could affect and intrude upon the signal (Thank you for the psdata file)
Below I have removed the low pass filtering from Romans capture on channels A & D
Note: The word "Filtered" only appears in the Channel lozenge button because the 20 kHz Bandwidth limit is set to on, "LowPass has been turned off
Note above (top left) how the raw signals compare in terms of "noise" level
Top right, the math channels demonstrate how the plotted frequency is offended due to noise (The ABS ECU has its work cut out in terms of filtering)
Finally, the lower image highlights the floating nature of the offending ABS signal compared to the clearly defined and fixed base voltage of the good signal (The control of the base voltage is a function of the ABS ECU)
It would be interesting to see the effects of such noise on the switching current flowing through the ABS sensor wiring (Typically 5 to 15 mA) but as ever, hindsight is a wonderful thing and "time spent" is not a luxury, therefore at some point, testing has to stop, a decision then made based on evidence gathered and a component replaced (where applicable)
Thank you once again for sharing
Take care......Steve
I wanted to add just how "noise" could affect and intrude upon the signal (Thank you for the psdata file)
Below I have removed the low pass filtering from Romans capture on channels A & D
Note: The word "Filtered" only appears in the Channel lozenge button because the 20 kHz Bandwidth limit is set to on, "LowPass has been turned off
- Image 1
Top right, the math channels demonstrate how the plotted frequency is offended due to noise (The ABS ECU has its work cut out in terms of filtering)
Finally, the lower image highlights the floating nature of the offending ABS signal compared to the clearly defined and fixed base voltage of the good signal (The control of the base voltage is a function of the ABS ECU)
It would be interesting to see the effects of such noise on the switching current flowing through the ABS sensor wiring (Typically 5 to 15 mA) but as ever, hindsight is a wonderful thing and "time spent" is not a luxury, therefore at some point, testing has to stop, a decision then made based on evidence gathered and a component replaced (where applicable)
Thank you once again for sharing
Take care......Steve
Re: Crankshaft sensor direction test
Hello Steve,
Thank you for the awesome break down of the noise/math channel graphing relation.
I have nothing more to add to this just the fact that when I want to see some graph on frequency, duty cycle etc, there is always the question how much or what frequency to set on the filter. As per my experience there is always good to experiment, start from one side and add higher or lower value on the low pass filter while monitoring the signal and related match channel. Here is handy stronger laptop or PC as it may take few seconds to update on the screen, depends on the buffer size.
The ABS sensor current monitoring. I will try to capture when opportunity comes. Actually, I wanted to try few times, but this usually requires break out leads connected. Such sensors are mostly one part together with cable where is not possible to clamp one wire only.
Then I think it is good to add two more examples:
First is the older non directional VAG wheel speed sensor where was necessary to apply the filtering, I have also set it to AC coupling for easier set up (which I should not).
This car was logging ABS sensor DTC with the warning light but sometimes could go one or more days without any DTC or warning light. The test was done by driving the wheels on the hoist by engine and gear engaged, it took some time and probably good luck to capture the problem.
Picture and waveform follows (some are also uploaded to waveform library).
Second example is directional ABS sensor from MB which is more complicated compared the VAG we discussed above. This car had ABS warning light ON and some DTC related to wheel speed sensors, easily replicated by few km test drive, mostly at carparks or traffic junctions. Some ABS sensors were replaced with no success so when I heard about it, Picoscope had a job again.
The sensors signal wires were backpinned on the ABS ECU socket side because the sensors are well insulated at wheel side and even if not, there would be not easy to install and secure the probe leads from each wheel to Pico. The capture was done while real test drive around the car park.
The test proved the sensors and wheel bearings were OK, reported identical speed on straight and in corners the outside wheels were faster, the math channels graphic visualisation is absolutely fantastic tool for this job. (The live data from diagnostic tester have slow sample rate and in such intermittent cases won’t show any abnormal values, that’s why the Pico)
Now the more interested part which I am not sure how to carry out. Test on the signal integrity, I mean if the sensor reports few pulses as wrong direction or won’t be recognised by the ECU, it will still look nice on the frequency graph.
The signal looks to me more like digital message than simple pulse width differences and when the deep measure is applied, the reading seems to be more complicated because each pulse is actually a combination of many pulses.
So, I have tried the Serial Decoding, in this case Manchester which is monitoring the state change, the bit is decided at rising or falling edge (Anyway, this gave me the most consistent result with my limited knowledge on this topic)
The idea is I can apply filter like "Data - Nor equal - F0 3" which filters out all the F0 3 bytes and leave the rest to manually review. The “F0 3” was absolute majority on the CH C Right front wheel assuming this is ideal signal, and I am focusing on bad ones when searching for evidence of malfunction.
The challenge is how can I find the faulty signal between many thousands when they all look very similar. (This car had no problem with ABS sensors, and they are all OK and accepted by ECU, but I do not have another waveform as example at this time)
Thank you for reading and I hope it helps to somebody with troubleshooting.
Regards,
Roman
Thank you for the awesome break down of the noise/math channel graphing relation.
I have nothing more to add to this just the fact that when I want to see some graph on frequency, duty cycle etc, there is always the question how much or what frequency to set on the filter. As per my experience there is always good to experiment, start from one side and add higher or lower value on the low pass filter while monitoring the signal and related match channel. Here is handy stronger laptop or PC as it may take few seconds to update on the screen, depends on the buffer size.
The ABS sensor current monitoring. I will try to capture when opportunity comes. Actually, I wanted to try few times, but this usually requires break out leads connected. Such sensors are mostly one part together with cable where is not possible to clamp one wire only.
Then I think it is good to add two more examples:
First is the older non directional VAG wheel speed sensor where was necessary to apply the filtering, I have also set it to AC coupling for easier set up (which I should not).
This car was logging ABS sensor DTC with the warning light but sometimes could go one or more days without any DTC or warning light. The test was done by driving the wheels on the hoist by engine and gear engaged, it took some time and probably good luck to capture the problem.
Picture and waveform follows (some are also uploaded to waveform library).
The sensors signal wires were backpinned on the ABS ECU socket side because the sensors are well insulated at wheel side and even if not, there would be not easy to install and secure the probe leads from each wheel to Pico. The capture was done while real test drive around the car park.
The test proved the sensors and wheel bearings were OK, reported identical speed on straight and in corners the outside wheels were faster, the math channels graphic visualisation is absolutely fantastic tool for this job. (The live data from diagnostic tester have slow sample rate and in such intermittent cases won’t show any abnormal values, that’s why the Pico)
The signal looks to me more like digital message than simple pulse width differences and when the deep measure is applied, the reading seems to be more complicated because each pulse is actually a combination of many pulses.
So, I have tried the Serial Decoding, in this case Manchester which is monitoring the state change, the bit is decided at rising or falling edge (Anyway, this gave me the most consistent result with my limited knowledge on this topic)
The challenge is how can I find the faulty signal between many thousands when they all look very similar. (This car had no problem with ABS sensors, and they are all OK and accepted by ECU, but I do not have another waveform as example at this time)
Thank you for reading and I hope it helps to somebody with troubleshooting.
Regards,
Roman