There have been many occasions when analyzing psdata files where I wish I had captured additional data from another sensor/actuator or indeed, wondered how & where the vehicle was being driven within a certain section of the waveform.
Typical examples of using dual Apps during diagnosis can be seen here viewtopic.php?p=100929#p100929 (using “split screen” for Serial/Scope data) and here https://www.picoauto.com/library/case-s ... celeration (for Pico NVH/Webcam)
Below we have 5 Apps running simultaneously (not including the operating systems) in order to provide a wealth of data for crunching during analysis
Starting from left to right above, we have the following Apps running to provide frame-by-frame viewing during video playback
1. Serial data displaying 8 chosen parameters of interest along with a description of the vehicle under test
2. PicoScope 7 Automotive utilizing 6 channels to compare against serial data (B1 S1 & B1 S2 voltage)
3. Top Right hand we have Vehicle Spy 3 from Intrepid Control Systems logging Powertrain CAN traffic to the laptop hard drive
4. Bottom right we use the Windows 10 Camera App to capture data from a Webcam mounted above the instrument panel (this could have been recorded for individual playback if I had remembered to press the record button!)
5. A Screenshot program called “Snagit” from TechSmith which records everything you see on the entire screen above, along with any cabin sounds/narration captured by the laptop mic.
You may think this is information overload but there is more!
Whilst not very clear, take a look at the Windows time clock at the bottom right hand of the screen. Unfortunately, the camera App is partially covering the time clock due to my “sizing” error but you can just make out the time which also includes “seconds”. This is a very useful feature as it will allow you to “step” thorough the video (during playback) at 1 second intervals providing sufficient “timed” resolution to correlate events in all the displayed Apps.
In addition, being able to navigate back & forth through the video will enable you to listen to the engine tone and any driver narration relevant to the fault condition. Better still, the Windows time clock will allow for alignment of time stamped CAN messages captured and logged by Vehicle Spy 3.
Hang on, there’s still more! Given the laptop microphone captures all cabin sounds we can use this to our advantage by utilizing the vehicle Sat Nav or Mobile Phone Nav to announce the names of the roads ahead. Add to the above the date, weather conditions and temperature from the Windows Task Bar and you have a wealth of data from which to base your diagnosis
A word to the wise: Once all Apps are running, the recording of all data becomes a hands-free operation, please do not drive and operate the laptop at the same time. Any data that is required to be saved during the road test can be done so by parking the vehicle in a safe location
Please take a look at the video below:
https://drive.google.com/file/d/192TSLY ... sp=sharing
Having now seen the video, there are a number of items to consider to ensure a successful capture with valid data
The first was to change the Windows time clock format to display seconds as the default is hours and minutes. The following link will help here https://www.howtogeek.com/325096/how-to ... y-seconds/
Next, ensure your laptop has sufficient battery for the intended journey as running multiple Apps that are simultaneously streaming data is hard going on any battery
The laptop used for this exercise has 3 USB ports and 4 were required to connect the Scan tool, PicoScope, Intrepid’ s Value CAN 4 and the Webcam. Here we utiilsed a powered USB hub where “power” was delivered via a 12 to 240 V invertor.
Finally, remember to start recording of all Apps prior to starting the journey and of course, save any data from the appropriate Apps when safe to do so. (Which includes the entire screen grab/video software)
Whilst you may have a video of all Apps running simultaneously, the true diagnostic value comes from opening the saved data in each individual App and using the video as reference to locate “events” from the video within your App
For example, in the video at 6:02, PicoScope is paused after repeated application of the brake pedal, however, stepping back through the video to 5:57 we can view the buffer of interest containing the data required based on my narration. Below is our buffer of interest (@ 5:57 in our video) where at some point, the brake pedal was pressed multiple times; but where exactly?
Using the video playback slide/scroll control, you could refer to the serial data in the video and note the precise time the parameter “Brake pedal switch” changed from “not operated” to “operated” and then refer to the area within the graph view of PicoScope for the brake activation event. This however is going to be challenging based on the refresh rate of the scan tool (introducing a delay) compared to the “live” data captured by PicoScope.
An example of this delay can be seen at 10:25 in the video where PicoScope captures the precise behavior of both B1 S1 and B1 S2 during over-run/fuel cut (approx. 0.1 V for 1.5 seconds) yet the scan tool remains fixed 0.82 V & 0.74 V respectively (see below)
So how do we find the precise brake pedal activation point in our capture given we have not connected a scope channel to the brake pedal switch? The answer lies within the CAN data we have captured on channels E & F, the Windows time clock and the driver narration. Once again, referring to the video, between 5:54 and 5:57, I announce the pressing of the brake pedal approx. 3 times and if we look closely at the Windows time clock, this equates to 16:57:30 – 16:57:34. (My apologies for partially covering the time clock with the camera App)
Below we decode the CAN data captured on channels E & F using the math channel E minus F (to assist with “noise” removal)
We then search for our known ID of 1 A0 where PicoScope displays only this ID, allowing for review of the 2nd byte in the “Data field” which equates to brake pedal on (Hex 18) and brake pedal off (Hex 00).
Note; as we scroll down the decode table, we capture the precise time our 2nd byte of interest changes (so indicating brake pedal operation)
Using the “View per channel” feature of PicoScope (within the Views menu) in combination with the additional time rulers for each “view”, we can mark the precise time on the graph where the brake pedal is activated using the “Start Time” in the decode table as guidance
For example, in the decode table above, “Packet 4048” indicates that for “ID 1 A0”, the second byte of the “Data field” has changed from 00 to 18 (Brake off to on) at 4.025 seconds into the graph view
So why bother?
Above we have demonstrated how to detect the activation of the brake pedal whilst capturing oxygen sensor data (which are of no concern to each other here) However, imagine if you were trying to detect operation of a torque converter lock up clucth where this information is only transmitted over CAN (E.g., BMW ZF 8HP transmission)
In this scenario you may have your 4 or 8 channel scope capturing multiple signals such as engine speed, injector operation, fuel pressure, MAF, MAP and CAN Hi/CAN Lo. Once you have CAN data captured alongside your sensor/actuator signals the world is your oyster if you can decode the network into human readable data.
Here you can then use the principle above to mark events such as torque convertor “lock up” with the time rulers and correlate such an event with MAP, MAF or injector operation to eliminate them from your diagnosis. Alternately, you could export all your data in CSV format (active channels and decoded serial data) and graph them accordingly using Excel as we describe here viewtopic.php?p=98241#p98241
Fundamental to vehicle diagnosis involving network decoding is a data logger and we must remember that PicoScope is not a data logger with regards to seamless logging. The following link has this covered topic21743.html#p98467 .
Where PicoScope comes into its own is with correlating sensor/actuator signals against decoded network data.
Consider PicoScope as a microscope providing superior resolution of all acquired data (including network traffic) which is perfect for glitch captures such as misfire etc.
For seamless logging I have been using Vehicle Spy 3 (which I am studying as we go) and I have to say the byte color change feature becomes invaluable when identifying not only ID’s but also bytes relevant to driver input. (Refer to the video around 1:15 to 1:45)
Vehicle Spy 3 also includes a time stamp for each received message so allowing for correlation between the Windows time clock in our video (which includes the displayed Apps) and the transmitted network traffic, whilst also providing seamless coverage of CAN messaging between Pico buffers. (See final 1 A0 message captured by PicoScope below)
Below we correlate the decode table/messages above with the seamless time stamped data within Vehicle Spy 3. Note: The Windows clock is 1 hour ahead of the clock settings for Vehicle Spy 3 (This is a settings issue on my behalf)
Just looking at the decode table for both PicoScope and Vehicle Spy 3 it occurred to me that ID 1 A0 is transmitted every 20 ms or 50 times per second [ 1 / 0.020 = 50] or, at a frequency of 50 Hz. Not surprising given the importance of the braking system and the driver input into the brake pedal
What I have noticed using the techniques above is just how quickly you can scroll through minutes of data using the Webcam as an initial reference, followed by the Windows time clock as a marker to synchronize all Apps thanks to the Snagit software. This removes any guessing leaving you in no doubt where to focus your attention during evaluation of Serial, Scope and Logging data
I hope this helps to provide a number of tips on how to correlate multiple Windows Apps during diagnosis
I will follow up with another similar study ASAP re the BMW transmission mentioned earlier in this post