This is another great example of both the use of Pico, and an effort by someone to show the advantages of the scope. May I be slightly pedantic to start with?
There is a slight contadiction, or wrong choice of description if I may say so, as during cranking - hot or cold - the engine hasn’t actually started! In my book, “Cut-out” would be associated with an engine which has already stopped cranking; has started, and then stopped.
That out of the way, it was good to see that a list of possible causes was considered. This is most important and should if possible include the maximum mount of information from both the customer and anyone else who has had a play beforehand. The latter is always more difficult and often ‘fragile’ since since it often represents a failure of someone else to find the fault, meaning that they are not going to be too keen to admit the fact; nor to assist!
In this case, an important point noted early on was that a serial diagnosis with a scan tool revealed ‘sweet fanny Adams.’ The point here is that this is often the case; but more importantly, even if a scan tool does reveal a code - or several codes - it is often difficult if not impossible to be SURE of the problem, or the cause of the problem. It’s the latter we must always focus on, and for that we need some sound and logical proof. This basically what the scope allows us to do: to prove a suggested or suspected problem.
All too often we tend to rely on the scan tool, and that either through lack of understanding of how it communicates with the various systems, or even how a system or group of systems communicate. We need to understand strategies of systems; how and when they interrelate, as well how they don’t or can’t because of a lack of infoirmation; a lack of communication; wrong or suspect information, etc. Most of this information is coming from various sensors and often shared by numerous systems; themselves usually linked by a communciation Bus,which may or may not be working at the time of testing. Not always easy!
Often we are not all sure what the scan tool is trying to tell us, but the oscilloscope has the ability to ‘get into’ a component and to confirm whether or not it is performing as expected. In other words, we can’t interpret a fault indicated by a scan tool if it gives “wishy washy” information. We simply can’t prove that the information is correct. Often, we either gzet nothing - or we get a host of fault codes. The latter are often ‘bye-products” of a single problem.However, with or without codes present, the oscilloscope gives us the opportunity to look at what is happenning “now” - not a few milliseconds ago, which in todays vehicles is like reading an account of World War II story. Live Data with a scan tool is never ‘live.’ The oscilloscope DOES give LIVE data. The scan tool conveys information seen by the on board computer, and stored in it’s memory. This information is thrown ‘randomly’
