Problem job: DAF CF engine cut-out solved with PicoScope diagnostics

Engine ECU found to be causing warm engine cut-outs and non-restart

Problem job: DAF CF engine cut-out solved with PicoScope diagnostics

Having a good understanding of how an automotive network is created is becoming more and more important, but fundamentally it is just about voltage, reports Pico Automotive as it looks back on a recent problem job.

A Pico Automotive spokesperson said: “Don’t panic straight away, just because there are 30 fault codes all shouting communication issues.

“There are some simple and basic things we can do to determine what is going on, and with PicoScope, we can delve even deeper.”

First, technicians should talk to the customer as they may have the key piece of information that was missed on the job card.

Vehicle suddenly cut-out

The spokesperson added: “The complaint this time is: the vehicle suddenly cut out and then wouldn’t restart.

“Using a little intuition may help in this situation so open-ended questions can lead to further information from the customer.

“Keep them talking: ask them about the weather, how long they were driving, if this fault has happened before, if any other work has been carried out recently, any warning lights on the dash before the fault happened, the speed they were doing, what gear, and so on.”

In this case, the customer explained that the vehicle was fine from cold but after driving for some time it suddenly cut out.

“Coming to look at the vehicle the next day meant that it had plenty of time to cool down and we were able to look at the vehicle in the same conditions as the driver did right before the fault occurred.

“Also, you should never overlook serial diagnostics if you have the opportunity to take a look.

“In this case, we had 12 active diagnostic trouble codes of which 11 are reporting CAN communication faults.

“To add further detail, four of these were directly pointing to the engine ECU.

“With this in mind, I felt it was necessary to observe the CAN lines to the Engine ECU.

“Verifying how the network is set up is a must at this point, as there are several networks on all vehicle types.

“This could mean that an ECU of interest might not be on the network you are connected to, so always double check a wiring diagram.

“For us, the ECU of interest was the engine ECU and it happened to be involved in a number of networks including one that with the OBD port in it.

“This network was a typical setup, utilising two 120 Ω terminating resistors joining CAN H and CAN L together.

“These will normally be situated in an ECU at the end of the network, and so a simple resistance check on the CAN network can be carried out to verify its integrity.

“Here we could utilise the breakout box to easily gain access to the terminals, but we could also confirm the network was no longer active and shut down.

“It is good practise to only carry out a resistance check to a network when it is no longer active, and normally you would disconnect the battery to prevent the network from waking up.

“Disconnecting the battery on this vehicle was not practical due to some additional equipment fitted, so observing the breakout box LEDs for inactivity was the next best thing.

“With the network no longer active, a quick resistance check saw the magic 60 Ω we would expect to see from two 120 Ω resistors in parallel.”

To try and catch the fault in action, the technician used the PicoScope’s ability to capture against time.

“I’ve used 2 ms/div which gives us more time in total but allows us to maintain enough detail to decode on.

“We utilised the inbuilt math of A+B and A-B to get a better understanding of the network and to decode the signals in the same way the controllers did.

“It also helped show us the resilience of CAN and how even with interference the messages still got through without being affected.

“You can find the Math Channels by clicking Tools > Math Channels.


CAN H is on Channel A, CAN L is on Channel B and underneath we have one result of adding CAN H to CAN L and also one where CAN L has been subtracted from CAN H.

The waveforms showed some interference on the CAN lines.

“It is picked up quite clearly in packet 1 on the A+B channel but when we subtract them the way the CAN controller does, any interference that was there no longer exists proving the CAN’s fault tolerance.

“Something else I’ve noticed, having looked at a few HGV and off-highway vehicles, is that the networks allow for a lot more interference.

“Normally with cars, when we add CAN H to CAN L, we end up with a very straight line at 5 V (2.5 V + 2.5 V = 5 and 3.5 V + 1.5 V = 5 V.)

“With trucks there always seems to be an allowable deviation of the 5 V.

“It’s never a huge amount but can be up to 0.4 V.

“However, when we look at the physical layer, A-B, everything is very even and allows us to use the inbuilt serial decode tool.

“After running the truck back up to temperature, we start to experience the fault, with a slight hesitation, before the engine suddenly stops.

“By leaving the scope to continue capturing after the event, meant we had both pre- and post data to look at.


Complete network silence for two buffers, which totalled at 40 ms, before a single packet could be seen along with further silence

“What we noticed, is that there were significantly less CAN traffic on the network.

“To begin with, we needed to perform a serial decode on the physical layer to start identifying individual IDs.

“To do this click Tools > Serial Decode. You will now have the opportunity to create a decoder by clicking Create and select CAN from the list.

“The setup box will appear, and you will be asked to select what data you will be decoding.

“In our case, we will be using A-B, which will be present in the dropdown box.

“This will only display channels that are active on the grid, so if any have been hidden from view you will not be able to select them.

“The next option is to select your threshold.

“This is the voltage you are telling the software to use as a ‘crossing point’ for the decoder.

“For the purpose of the test, we applied a crossing point of 1 V.

“Hysteresis can come right down to 20 mV, as we should be seeing a straight line up and down on our Math channel.

“Using the marquee zoom, draw around a packet of data.

“Then you can use the time rulers to mark either side of the smallest bit.

“In the lower right-hand corner, you will see a figure in kHz.

“This will equate to your Baud rate.


With the settings done, our CAN decode setup should look something like this.

“We will now be presented with a table where the packets of data have been converted into HEX code for the current buffer.

“I purposely selected the buffer just before the first ‘silent’ buffer (with no CAN traffic) as the one to start from as that is where the fault was not present.

“I have 10 packets of data that all decode correctly with no errors.

“I mentioned earlier that J1939 is much more standardised than J2534.

“This means we can actually pull this data apart and start identifying IDs.

“By creating a link file we can convert the IDs into real words.

“From our serial data, we had a number of ECUs reporting a problem with the Engine ECM so it would make sense to look for the Engine ECM ID in our decode table.

“The first thing we needed to do was to determine which ID is the Engine ECM.

I won’t go into too much detail here, but I do want to show the possibilities that PicoScope can bring when it comes to serial decoding.

“We must remember, though, that PicoScope is not a dedicated CAN decoder/logger but an oscilloscope with limited decoder/logger features.

“That being said, there is still an awful lot we can do.

“To begin with, we need to understand how the message ID of a J1939 message is made up.

“The message header is made up of 29 Bits but to keep things simple we will look at the message in HEX.

“Each message has a unique Parameter Group Number, PGN, which contains the Suspect Parameter Number, SPN.

“All we are interested in this stage is the PGN as this points to a group table that refers to an ECU.

“To find the PGN in the header we look to the two middle bytes in an ID, for example – 0C F0 04 00 which means we are only interested in F0 04.

“We now convert F004 into a decimal, and by using a programmer calculator we get the number 61444.

“A quick search through the SAE standards for PGN 61444 confirms to us that this is for the Electronic Engine Controller 1.

“Therefore we can be confident that 0C F0 04 00 represented the Engine ECU or EEC1.

“To then apply this to our decode table we need to fill in this information in our link file and save the file.

“To get this file click on the tab in the decode table marked Link. You will then see an option to Create File.

“Once clicked, it will ask you to save a CSV file.

“Select an appropriate location and then locate and open the saved CSV file.

“With the file open, there are a number of fields available that look like the decode table in PicoScope but with the additional ID Description header.

“Copy the ID from PicoScope exactly as it is in the decode table and add the description in the ID description column.

“For us, this was Engine Controller 1.

“Make sure you save any changes.


To tell PicoScope to look at this link file and replace any IDs with the description we have listed in the link file, click Link > Open, navigate to the link file location and select it. Once selected you should now see the IDs replaced with a language we can understand.

As luck would have it, it was the engine ECU we were looking for.

“Now we could sort through the data and look for this ID and any faults associated with it.

“We expanded the decoder to every buffer by selecting All Buffers in the dropdown box where the current buffer was selected.

“We could now export all this data to Excel for further analysis, or we could use the filter option in the decode table.

“Select Filter and then type the ID you would like to display, for us it was Engine Controller 1.

“We knew the fault occurred at buffer 96, so started the search from there.

“We noticed that Engine Controller 1 was no longer present after buffer 96, and appeared to have gone offline despite this ID being very active throughout every buffer previous in the capture.

“Could this mean that the Engine ECU was at fault?

“It would make sense and we certainly had proof with our raw CAN Data.

“We could see that after buffer 96 something happened, the network was silenced, and from here on out the engine ECU was no longer online.

“This gave us enough reason to send the ECU away for testing, and sure enough, it was confirmed as faulty.

“A new Engine ECU was fitted, coded and reprogrammed and the vehicle was back on road.

“This was an intriguing case and one that could have been costly for both the owner and us with the wrong diagnosis, but thanks to the PicoScope we had enough evidence to justify the path we took with the repair.”

For further information about Pico Automotive, select ‘more details’ below.

Have your say!

1 0

Lost Password

Please enter your username or email address. You will receive a link to create a new password via email.