CAN Bus Trigger

Ask any questions about using PicoScope Automotive software here.
Post Reply
Posts: 24
Joined: Tue Jul 25, 2017 11:52 am

CAN Bus Trigger

Post by ashtray1987 » Thu Mar 29, 2018 5:21 am

Hi Guys,

Do any of you have any suggestion as to which advanced trigger setting would be best to stabilize a CAN bus message so that there are no frames spread across to waveforms. I'm guessing a level dropout trigger might be best.

Reasons being is if I switch on serial decoding, if only a portion of the frame is captured on the display area, the particular frame is considered to have an error. Therefore it is recorded in the table below in red.

What I want to see is only the frames which have genuine errors and not the frames recorded as errors because they were only partially captured in the waveform.

Afterwards I can add a filter onto the frame buffer list to show only messages with errors, and match the Frame ID with the manufacturers CAN bus matrix to determine the part of the CAN bus network with a fault i.e. a loose contact at a control unit. For short circuits we lose every message on the bus so this technique is not useful in such an event.

Any advice you have on such a measurement is highly appreciated.

Thank you.

Pico Staff Member
Pico Staff Member
Posts: 155
Joined: Tue May 16, 2017 1:02 pm

Re: CAN Bus Trigger

Post by ben.martins » Thu Mar 29, 2018 1:12 pm

Hi Ashley,

I've added a reply to your new feature requests in this topic topic14691-10.html

Hopefully it has some of the answers you are looking for.

With regards to your question here, I think your answer might also be within the above topic. Normally the fault will be when there is a difference to CAN H and CAN L which will be picked up using the Maths channel technique with an alarm. This will allow you to decode the area of interest where the mask failed rather than looking at all the data in one go. Even if the decode fails due to the packet not being complete on the screen then you will be more interested in the ones that fail the mask.

Another handy tip is if you double click the failed decode packet in the table it will take you to that packet in the capture. Here you can quickly see if it was because it lost some information when it moves to the next buffer of if there was an actual fault.

Hopefully there will be something you can use here but please feel free to get in touch if you want to discuss anything else.

Kind regards


Post Reply