PicoScope 7 Automotive
Available for Windows, Mac, and Linux, the next evolution of our diagnostic scope software is now available.
Holding back
-
Steve Smith
- Pico Staff Member
- Posts: 1587
- Joined: Sun Aug 25, 2013 7:22 am
Holding back
There are a number of times when customers complain of holding back, jerking or hesitation followed by that sweeping statement “it only does it now and again”
The chances of capturing these momentary events with a scan tool are very slim indeed and whilst the scope is our best option it does not come without its challenges
Let’s say you have chosen 4 components to measure (with a 4-channel scope) to help you eliminate a number of “possible causes” when the fault/glitch occurs
The chances are you may choose to set a slow time frame (e.g., 2 sec/div) and hope the event occurs during the current buffer whilst road-testing; whereby you can press pause (use the space bar) and save the data when safe to do so
When it comes to reviewing the data, how can we be sure where the fault/glitch occurred within the 20 second buffer of data?
With a bit of luck, you may have recorded and narrated the capture as we have described here viewtopic.php?p=102191#p102191 or you may have glanced down at the laptop screen and spotted the progress of the waveform just after the customers glitch occurred
Both of these will work but adding an accelerometer to one of your 4 channels (8 if you are really lucky) will provide you with the precise moment of “hesitation” or “jerking” described by the customer. When reviewing the data, you can then use the accelerometer signal as your hands-free marker during analysis of the remaining channels
Below is one such example looking at a momentary hesitation where it was difficult to determine if this complaint was engine or transmission related. (No DTC’s present)
2015 BMW X4 320 d ZF 8-Speed Auto (Yes, it’s this one again! topic22828.html)
Above we have a 3-axis accelerometer mounted on the driver’s seat bolt in the orientation shown in the bottom right image
Channel E captures the fore & aft (X axis) “offending” motion of the vehicle during the momentary hesitation under acceleration and therefore serves as the perfect marker in which to analyze the remaining channels.
What I found interesting about the capture above is the momentary increase in engine speed during the hesitation (Vehicle held in 1st gear throughout capture)
This immediately focused my attention to transmission rather than engine power output as a glitch within the engine management would result in a momentary drop in engine speed
My line of thinking was torque convertor operation or torque convertor “lock up” error resulting in a momentary “slip” of the power transfer from the engine to the transmission
Such an event would momentarily unload the engine resulting in an increase in engine speed
Prior to the application of the accelerometer above I had road-tested the vehicle under the assumption the vehicle exhibited a misfire!
Below I have captured the crank signal, CR fuel pressure and 4 x injectors whilst accelerating the vehicle in 1st gear only (i.e., no gear change to interfere with engine load or speed)
Note the momentary increase in engine speed at 2588 rpm along with stable fuel pressure and injection events. It was this symptom that forced the use of the accelerometer to assist with “marking” the point of hesitation rather than relying upon the momentary increase in engine speed
I had considered the momentary increase in engine speed was because of the fore & aft jerking of the vehicle which could influence the pressure I was applying to the gas pedal! With hindsight, I should have captured the Accelerator Pedal position Sensor but thinking this through, fuel pressure is dependent upon gas pedal position and not engine speed.
Note above how the fuel pressure is stable throughout the momentary increase in engine speed, suggesting the gas pedal input did not change.
Returning to Image 1, note how CAN Hi & CAN Lo are captured on channels A and B respectively. This was deliberate as transmission input and output shaft speeds are transmitted over the PT CAN network.
If we can decode the messaging, we may be able to determine a glitch within the speed signals of these components by graphing the changing data bytes linked to transmission input and output speeds. The question is, which data bytes represent transmission input and output speeds?
Using a CAN data logger is ideal in these scenarios for the following reasons:
• Capture seamlessly streams of CAN data whilst holding each message static on screen
• List each CAN ID in numerical order along with its respective “change count”
• Utilize a color scheme to denote changing data bytes in response to component operation
The data logger I have used periodically over the last 2 years is the ValueCAN 4 from Intrepid along with their Vehicle Spy 3 (VS3) software
The video below highlights how the logger is used in conjunction with a scan tool to derive not only the CAN ID associated with transmission input/output speed but also identify their relevant data bytes
Please download for best quality viewing and audio
https://drive.google.com/file/d/1JPV8dt ... sp=sharing
The video below has simplified the user view by focusing only on the relevant ID (1 AF) and data bytes associated with the input shaft speed
https://drive.google.com/file/d/1JTyExX ... sp=sharing
Note in the video above how we are able to confirm the 2 bytes of data associated with transmission input shaft speed. This is achieved by selecting “Drive” and monitoring how the input shaft momentarily drops to 0 rpm whilst also noting the hex values (D0 07 @ 0 rpm) and their color in response to the changing input shaft speed. VS3 utilizes a dark grey highlighter about continually changing bytes which fade to light grey then white when not changing
Armed with the knowledge that CAN ID 1 AF contains 4 bytes responsible for indicating transmission input /output shaft speeds, we can use the decode feature of PicoScope to extract the CAN data in the area of our glitch/hesitation
Based on the hesitation captured by the accelerometer below, we can decode the CAN data between the time rulers placed at 2.5 seconds and 4 seconds. This feature will not only minimize the amount of CAN data to be processed, but also ensure only the CAN messages relevant to the hesitation are exported rather than 1000’s of messages when exporting multiple waveform buffers.
Note above; thanks to VS3, we are able to identify the relevant CAN ID and then use the PicoScope “Filter” option to single out ID “1 AF”. This will allow the export (to csv) of just 251 relevant messages instead of the entire buffer containing all bus traffic consisting of 5536 messages
With the above data exported to csv and into an Excel spreadsheet, we can get to work on graphing the relevant CAN message bytes as captured in our videos above.
Below we have the exported data from PicoScope into our Excel spreadsheet with the focus upon data bytes 4 & 5 for input shaft speed and bytes 6 & 7 for output shaft speed
If we were lucky enough to have access to proprietary information surrounding the structure and decoding of this CAN data, we would know how to convert such bytes into human readable values.
Given this is the real world and we don’t have such information, we have to make a number of assumptions based on the video content above and our knowledge of “expected” shaft speeds.
For example:
• We know from the video that input shaft speed typically follows engine speed
• We know that when the both shaft speeds are at 0 rpm our data bytes display D0 07 D0 07
• Based on a typical gear ratio for 1st gear, we know that the transmission input shaft will rotate faster than the output shaft
The above information will help qualify the expected results obtained from the spreadsheet, however, but are the actual values important? i.e., as long as our graph represents the expected changes in speed, any anomaly will still remain present.
We could spend more time plotting the changes in data bytes against serial data shaft speeds and then calculate the relevant scale and offset values but on the grand scheme of things this is not necessary!
Let’s take packet 4 above as an example; data bytes 4 & 5 are EC 13 (Hex values)
EC13 Hex converted to decimal is 60,345, I think we can agree our input shaft is not rotating at 60,345 rpm
How about if we reverse these bytes to 13EC?
13EC Hex converted to decimal is 5100; now this is more like it (5100 rpm)
This may not be correct but at this stage all we are looking to do if graph values and identify uncharacteristic “change” for a vehicle that is accelerating in 1st gear
So how do we apply the above formula to every 4th and 5th byte of our data field? Surely this is not a manual process as there are 76 rows of data for each shaft speed (x 2 = 152 in total)
Luckily there is formula that exists thanks to the powers of the “Magical Mystical Martins” (aka Ben) who has assisted here thanks to his J1939 & J1708/J1587 studies here topic22615.html and topic22640.html
The formula we need to apply is =HEX2DEC(CONCATENATE("",MID(I2,13,2),MID(I2,10,2)))
I know, it’s subzero cool
Focusing on cell I2 which contain the 8 bytes of our data field for packet 4, the above formula will locate our bytes of interest, order the bytes correctly (thanks to the ordering of the brackets/parentheses), remove any spaces, join the bytes together (Concatenate) and finally convert the Hex value to decimal (WOW)
E.g., Starting with 40 31 07 EC 13 60 0A 09, the ordering of the brackets and the “MID” function will select the relevant bytes of interest based on their position within the data bytes above and order them as required.
E.g., focusing on MID(I2,13,2), 40 31 07 EC 13 60 0A 09 becomes 13 because the formula returns only the 2 characters (13) 13 places after the start of the data displayed in cell I2 (remember to count the spaces when counting places) Likewise applying MID(I2,10,2), 40 31 07 EC 13 60 0A 09 becomes EC
The ordering of the brackets in our formula places 13 before EC (13 EC) as we require, rather than as they appear in the data field (EC 13)
(CONCATENATE("", will join together our values by removing the spaces, where 13 EC becomes 13EC
HEX2DEC will finally convert out Hex value of 13EC to a Decimal value of 5100 (5100 rpm)
This formula can then be applied to every cell for column P and Q where the values can then be graphed
Note above how the input/output shaft speeds plateau at message count 27 whilst the vehicle is accelerating in 1st gear (The output shaft speed actually decreases!)
This is all very neat but how can we confirm if the event above coincides with our hesitation and increase in engine speed? Note how the plateau in speeds occurs at message count 27.
Referring to the Excel spreadsheet row 27 (message count 27) reveals the packet number 555 in column B (B27). If we return to the PicoScope decode table and double click on packet 555, we are directed to the packet within the scope view along with an indication of our position in the entire waveform buffer thanks to the zoom overview window
I hope we can agree that the plateau within the Excel graph occurs at the precise point of our hesitation (captured by the accelerometer) and during the momentary increase in engine speed.
Below I have graphed the entire buffer of CAN data to help with perspective
To summarize the above:
We are faced with a vehicle that exhibits not only a momentary hesitation/glitch during acceleration, but also during low-speed driving around 30 mph (Using the 1st gear road-test method was best practice to reveal the ferociousness of the symptom)
Using a combination of PicoScope with PS7, Bosch Scan-tool, Intrepid’s ValueCAN 4 Data logger with VS3 and Microsoft Excel we are able to utilize the onboard CAN network to confirm our suspicions around a transmission fault rather than an engine management fault. (Always challenging with “managed” Auto transmissions)
You could argue there was no need as the scan tool could have graphed the input and output shaft speeds! Unfortunately, whilst this is possible, the refresh rate is very poor indeed and limited not only by the scan tool but the onboard diagnostic architecture. The timing of events that may appear on the screen of the scan tool are often way behind the real-time offending events we need to capture
Access to the input and output shaft speed sensors on the ZF 8-Speed transmission is impossible given the TCM is located inside the transmission assembly, therefore the only access is via reverse engineering the CAN network.
This method of diagnosis provided updates on input/output shaft speeds every 20 ms (50 messages per second) which allowed for accurate correlation of digital network data with analog data captured using PicoScope which could then be graphed and correlated accordingly
To conclude:
The momentary increase in engine speed coincides with a plateau in both input and output shaft speeds during acceleration. Such an event would be caused by the momentary unloading of the engine during instantaneous disconnection of vehicle load by either the torque convertor or sporadic operation of the lock up clutch.(No fix has been carried out and the vehicle has been part exchanged for another X4)
I hope the information and diagnostic techniques above will help with similar challenges and limits the numerous variables we are faced with on a daily basis
Take care……Steve
The chances of capturing these momentary events with a scan tool are very slim indeed and whilst the scope is our best option it does not come without its challenges
Let’s say you have chosen 4 components to measure (with a 4-channel scope) to help you eliminate a number of “possible causes” when the fault/glitch occurs
The chances are you may choose to set a slow time frame (e.g., 2 sec/div) and hope the event occurs during the current buffer whilst road-testing; whereby you can press pause (use the space bar) and save the data when safe to do so
When it comes to reviewing the data, how can we be sure where the fault/glitch occurred within the 20 second buffer of data?
With a bit of luck, you may have recorded and narrated the capture as we have described here viewtopic.php?p=102191#p102191 or you may have glanced down at the laptop screen and spotted the progress of the waveform just after the customers glitch occurred
Both of these will work but adding an accelerometer to one of your 4 channels (8 if you are really lucky) will provide you with the precise moment of “hesitation” or “jerking” described by the customer. When reviewing the data, you can then use the accelerometer signal as your hands-free marker during analysis of the remaining channels
Below is one such example looking at a momentary hesitation where it was difficult to determine if this complaint was engine or transmission related. (No DTC’s present)
2015 BMW X4 320 d ZF 8-Speed Auto (Yes, it’s this one again! topic22828.html)
- Image 1
Channel E captures the fore & aft (X axis) “offending” motion of the vehicle during the momentary hesitation under acceleration and therefore serves as the perfect marker in which to analyze the remaining channels.
What I found interesting about the capture above is the momentary increase in engine speed during the hesitation (Vehicle held in 1st gear throughout capture)
This immediately focused my attention to transmission rather than engine power output as a glitch within the engine management would result in a momentary drop in engine speed
My line of thinking was torque convertor operation or torque convertor “lock up” error resulting in a momentary “slip” of the power transfer from the engine to the transmission
Such an event would momentarily unload the engine resulting in an increase in engine speed
Prior to the application of the accelerometer above I had road-tested the vehicle under the assumption the vehicle exhibited a misfire!
Below I have captured the crank signal, CR fuel pressure and 4 x injectors whilst accelerating the vehicle in 1st gear only (i.e., no gear change to interfere with engine load or speed)
- Image 2
I had considered the momentary increase in engine speed was because of the fore & aft jerking of the vehicle which could influence the pressure I was applying to the gas pedal! With hindsight, I should have captured the Accelerator Pedal position Sensor but thinking this through, fuel pressure is dependent upon gas pedal position and not engine speed.
Note above how the fuel pressure is stable throughout the momentary increase in engine speed, suggesting the gas pedal input did not change.
Returning to Image 1, note how CAN Hi & CAN Lo are captured on channels A and B respectively. This was deliberate as transmission input and output shaft speeds are transmitted over the PT CAN network.
If we can decode the messaging, we may be able to determine a glitch within the speed signals of these components by graphing the changing data bytes linked to transmission input and output speeds. The question is, which data bytes represent transmission input and output speeds?
Using a CAN data logger is ideal in these scenarios for the following reasons:
• Capture seamlessly streams of CAN data whilst holding each message static on screen
• List each CAN ID in numerical order along with its respective “change count”
• Utilize a color scheme to denote changing data bytes in response to component operation
The data logger I have used periodically over the last 2 years is the ValueCAN 4 from Intrepid along with their Vehicle Spy 3 (VS3) software
The video below highlights how the logger is used in conjunction with a scan tool to derive not only the CAN ID associated with transmission input/output speed but also identify their relevant data bytes
Please download for best quality viewing and audio
https://drive.google.com/file/d/1JPV8dt ... sp=sharing
The video below has simplified the user view by focusing only on the relevant ID (1 AF) and data bytes associated with the input shaft speed
https://drive.google.com/file/d/1JTyExX ... sp=sharing
Note in the video above how we are able to confirm the 2 bytes of data associated with transmission input shaft speed. This is achieved by selecting “Drive” and monitoring how the input shaft momentarily drops to 0 rpm whilst also noting the hex values (D0 07 @ 0 rpm) and their color in response to the changing input shaft speed. VS3 utilizes a dark grey highlighter about continually changing bytes which fade to light grey then white when not changing
Armed with the knowledge that CAN ID 1 AF contains 4 bytes responsible for indicating transmission input /output shaft speeds, we can use the decode feature of PicoScope to extract the CAN data in the area of our glitch/hesitation
Based on the hesitation captured by the accelerometer below, we can decode the CAN data between the time rulers placed at 2.5 seconds and 4 seconds. This feature will not only minimize the amount of CAN data to be processed, but also ensure only the CAN messages relevant to the hesitation are exported rather than 1000’s of messages when exporting multiple waveform buffers.
- Image 5
With the above data exported to csv and into an Excel spreadsheet, we can get to work on graphing the relevant CAN message bytes as captured in our videos above.
Below we have the exported data from PicoScope into our Excel spreadsheet with the focus upon data bytes 4 & 5 for input shaft speed and bytes 6 & 7 for output shaft speed
- Image 6
Given this is the real world and we don’t have such information, we have to make a number of assumptions based on the video content above and our knowledge of “expected” shaft speeds.
For example:
• We know from the video that input shaft speed typically follows engine speed
• We know that when the both shaft speeds are at 0 rpm our data bytes display D0 07 D0 07
• Based on a typical gear ratio for 1st gear, we know that the transmission input shaft will rotate faster than the output shaft
The above information will help qualify the expected results obtained from the spreadsheet, however, but are the actual values important? i.e., as long as our graph represents the expected changes in speed, any anomaly will still remain present.
We could spend more time plotting the changes in data bytes against serial data shaft speeds and then calculate the relevant scale and offset values but on the grand scheme of things this is not necessary!
Let’s take packet 4 above as an example; data bytes 4 & 5 are EC 13 (Hex values)
EC13 Hex converted to decimal is 60,345, I think we can agree our input shaft is not rotating at 60,345 rpm
How about if we reverse these bytes to 13EC?
13EC Hex converted to decimal is 5100; now this is more like it (5100 rpm)
This may not be correct but at this stage all we are looking to do if graph values and identify uncharacteristic “change” for a vehicle that is accelerating in 1st gear
So how do we apply the above formula to every 4th and 5th byte of our data field? Surely this is not a manual process as there are 76 rows of data for each shaft speed (x 2 = 152 in total)
Luckily there is formula that exists thanks to the powers of the “Magical Mystical Martins” (aka Ben) who has assisted here thanks to his J1939 & J1708/J1587 studies here topic22615.html and topic22640.html
The formula we need to apply is =HEX2DEC(CONCATENATE("",MID(I2,13,2),MID(I2,10,2)))
I know, it’s subzero cool
Focusing on cell I2 which contain the 8 bytes of our data field for packet 4, the above formula will locate our bytes of interest, order the bytes correctly (thanks to the ordering of the brackets/parentheses), remove any spaces, join the bytes together (Concatenate) and finally convert the Hex value to decimal (WOW)
E.g., Starting with 40 31 07 EC 13 60 0A 09, the ordering of the brackets and the “MID” function will select the relevant bytes of interest based on their position within the data bytes above and order them as required.
E.g., focusing on MID(I2,13,2), 40 31 07 EC 13 60 0A 09 becomes 13 because the formula returns only the 2 characters (13) 13 places after the start of the data displayed in cell I2 (remember to count the spaces when counting places) Likewise applying MID(I2,10,2), 40 31 07 EC 13 60 0A 09 becomes EC
The ordering of the brackets in our formula places 13 before EC (13 EC) as we require, rather than as they appear in the data field (EC 13)
(CONCATENATE("", will join together our values by removing the spaces, where 13 EC becomes 13EC
HEX2DEC will finally convert out Hex value of 13EC to a Decimal value of 5100 (5100 rpm)
This formula can then be applied to every cell for column P and Q where the values can then be graphed
- Image 7
This is all very neat but how can we confirm if the event above coincides with our hesitation and increase in engine speed? Note how the plateau in speeds occurs at message count 27.
Referring to the Excel spreadsheet row 27 (message count 27) reveals the packet number 555 in column B (B27). If we return to the PicoScope decode table and double click on packet 555, we are directed to the packet within the scope view along with an indication of our position in the entire waveform buffer thanks to the zoom overview window
- Image 8
Below I have graphed the entire buffer of CAN data to help with perspective
- Image 9
We are faced with a vehicle that exhibits not only a momentary hesitation/glitch during acceleration, but also during low-speed driving around 30 mph (Using the 1st gear road-test method was best practice to reveal the ferociousness of the symptom)
Using a combination of PicoScope with PS7, Bosch Scan-tool, Intrepid’s ValueCAN 4 Data logger with VS3 and Microsoft Excel we are able to utilize the onboard CAN network to confirm our suspicions around a transmission fault rather than an engine management fault. (Always challenging with “managed” Auto transmissions)
You could argue there was no need as the scan tool could have graphed the input and output shaft speeds! Unfortunately, whilst this is possible, the refresh rate is very poor indeed and limited not only by the scan tool but the onboard diagnostic architecture. The timing of events that may appear on the screen of the scan tool are often way behind the real-time offending events we need to capture
Access to the input and output shaft speed sensors on the ZF 8-Speed transmission is impossible given the TCM is located inside the transmission assembly, therefore the only access is via reverse engineering the CAN network.
This method of diagnosis provided updates on input/output shaft speeds every 20 ms (50 messages per second) which allowed for accurate correlation of digital network data with analog data captured using PicoScope which could then be graphed and correlated accordingly
To conclude:
The momentary increase in engine speed coincides with a plateau in both input and output shaft speeds during acceleration. Such an event would be caused by the momentary unloading of the engine during instantaneous disconnection of vehicle load by either the torque convertor or sporadic operation of the lock up clutch.(No fix has been carried out and the vehicle has been part exchanged for another X4)
I hope the information and diagnostic techniques above will help with similar challenges and limits the numerous variables we are faced with on a daily basis
Take care……Steve
-
tintoverano
- TwoWaves
- Posts: 68
- Joined: Mon Dec 14, 2020 3:38 pm
Re: Holding back
hi Steve,
stunning!
so the transmission is not on Flexray, only the transfer box - it helps
I just ordered the probes (100Mhz, 10MΩ) for Flexray this week - today I couldn't get pico to decode the capture I did using 60Mhz 6MΩ probe
cheers
stunning!
so the transmission is not on Flexray, only the transfer box - it helps
I just ordered the probes (100Mhz, 10MΩ) for Flexray this week - today I couldn't get pico to decode the capture I did using 60Mhz 6MΩ probe
cheers
-
Steve Smith
- Pico Staff Member
- Posts: 1587
- Joined: Sun Aug 25, 2013 7:22 am
Re: Holding back
Hello and thank you for the feedback
The Transmission on the X4 uses PT CAN / PT CAN2 with no indication of FlexRay (which surprised me as Audi do)
Decoding FlexRay using the Pico TA375 https://www.picoauto.com/products/test- ... 00-mhz-bnc will be fine as we have discussed here viewtopic.php?p=97872#p97872
I am surprised the 60 MHz 6 MΩ probe would not provide sufficient resolution for decoding, it will great to get your feedback on both these probes when your new probe arrives
Take care......Steve
The Transmission on the X4 uses PT CAN / PT CAN2 with no indication of FlexRay (which surprised me as Audi do)
Decoding FlexRay using the Pico TA375 https://www.picoauto.com/products/test- ... 00-mhz-bnc will be fine as we have discussed here viewtopic.php?p=97872#p97872
I am surprised the 60 MHz 6 MΩ probe would not provide sufficient resolution for decoding, it will great to get your feedback on both these probes when your new probe arrives
Take care......Steve
-
tintoverano
- TwoWaves
- Posts: 68
- Joined: Mon Dec 14, 2020 3:38 pm
Re: Holding back
hi Steve,
thanks again!
I'll report back, the proper probes are on the way to me
cheers
thanks again!
I'll report back, the proper probes are on the way to me
cheers