## Pico CAN Webinar Q & A

Ask for and share advice on using the PicoScope kit to fix vehicles here.
Steve Smith
Pico Staff Member
Posts: 1671
Joined: Sun Aug 25, 2013 7:22 am

### Pico CAN Webinar Q & A

Many thanks to all who viewed and contributed to the CAN webinar held last week here at Pico https://www.youtube.com/watch?time_cont ... jvB_901hzA sorry this reply is late.

A number of questions were raised during the webinar that we could not clearly answer on the night and so I wanted to cover those now:

The first question, what is the voltage threshold of CAN? Or in other words, at what voltage does the CAN node decide the signal is either high or low?

When we decode the CAN physical layer (using math CAN Hi - CAN Lo) we set our voltage threshold (crossing point) at 1 V as this is midway between 0 & 2 V. https://www.picoauto.com/library/traini ... onus-class

With CAN nodes it is not that simple as there is no clearly defined value!

In a perfect world we hope to obtain a square waveform on our BUS, without noise, slope or delay whereby the CAN node could plot the rising and falling edges of each bit.
Real World
Using 0 - 2 V as an example, the CAN node would choose the center point (1 V) as the threshold voltage or crossing point in order to determine the change of BUS state from Recessive to Dominant

However, given we do not live in a perfect world the CAN nodes utilize a form of adaption to the environment with a number of tolerances built into the operation of the CAN controller.

Think about the environment of a typical automotive CAN BUS which is subjected to noise, connectivity challenges, harness routing limitations, wiring lengths and varying environmental operating conditions. (My thoughts here turn to Agricultural vehicles) Could we ever achieve the perfect square wave at 0 – 2 V with a center crossing point of 1 V?

The CAN nodes therefore adapt and look for the central midpoint of the square wave on offer at the CAN terminals. The CAN node will calculate the mid-point and allow for approximately 10 % hysteresis (typically noise) around this calculated mid-point in order to allow for voltage shift or fluctuations during reception of a CAN frame.

A great explanation of hysteresis and the effects on crossing points can be found here on page 157 https://www.picoauto.com/download/docum ... ide-en.pdf of our user guide. Whilst this applies to setting a trigger on PicoScope, the CAN controller is performing a similar exercise around the calculated midpoint of our switched BUS voltage (The transition from Recessive to Dominant voltage levels)

Again this is one of the true beauties of fault tolerant CAN given its ability to adapt (within reason) to the harsh environment in which it performs. Take a look at how this message decodes fine even with a fluctuating CAN frame crossing point.
Crossing point drift
The above capture can be found here topic20981.html?&p=93851&hilit=fault+tolerant#p93851

How could we ever guarantee delivery of the perfect noise free, square wave with a fixed crossing for the CAN controller to decode?

I think the answer is never, but Bosch have thought of this already

I will follow up with other raised questions ASAP

I hope this helps, take care……Steve

Steve Smith
Pico Staff Member
Posts: 1671
Joined: Sun Aug 25, 2013 7:22 am

### Re: Pico CAN Webinar Q & A

Question 2 “If Pico decodes a can message, how we ensure that the automotive controllers do as well? Or put it differently, can it be that acceptable voltage ranges in nodes maybe differ than acceptable ranges set in Pico software?”

This is a great question as we can never assume all CAN Controllers have decoded correctly just because PicoScope has decoded successfully.

PicoScope will decode CAN data based upon the threshold voltages selected during the decode set up (which may not be present on the entire CAN BUS).

We assume that all CAN controllers are receiving identical voltage levels from the CAN BUS on their respective terminals, but this is not the case. A fault may exist in a CAN branch wire to one CAN ECU/node leaving this node unable to decode, whilst the remaining nodes decode successfully (Inc. PicoScope)

With regards to voltage ranges in nodes, the post above will help explain how each CAN node is able to deal with varying voltage thresholds on their respective CAN BUS terminals.

In such a scenario where one CAN node has failed to decode due to extreme CAN BUS voltage variation we have a number of possible scenarios.

1. Serial data reports loss of communication to a CAN node that cannot decode CAN BUS data
2. Multiple CAN nodes reporting loss of communication with one particular CAN node (pointing the finger)
3. Serial “Data BUS Check” listing “Nodes on line” reveals one missing node
4. Decoded data displayed in PicoScope may reveal multiple recessive bits within the RTR, ACK fields or CRC errors
5. Using a dedicated CAN Decoder/Logger would also reveal the field errors mentioned at point 4 above, but decoded at the Silicone level rather than PicoScope at the Physical layer.

We must remember that PicoScope is not a dedicated CAN Decoder/Logger but an Oscilloscope with limited decoder/logger features. Decoding CAN data based on voltage levels captured at a single measurement point on the CAN BUS (Physical layer) is potentially flawed given the voltage levels may not be the same throughout the CAN BUS!

The following forum post looks a little deeper at unique voltage signatures associated with CAN nodes topic21680.html#p98339

Decoding at the Silicone Layer (via a dedicated CAN logger) allows you to capture exactly what each node can see, as each node will display its interpretation of data from the voltages present on their respective CAN terminals.
Here we “By-Pass” the Physical layer measurement to obtain feedback from each CAN controller within each node on the BUS.

With that said, should the Silicone layer display errors (via your CAN logger) then we need to check the Physical Layer with PicoScope either at one erroneous node (for single node decode errors) or the complete BUS if multiple nodes are reporting decode errors

I hope this helps, take care……Steve

Steve Smith
Pico Staff Member
Posts: 1671
Joined: Sun Aug 25, 2013 7:22 am

### Re: Pico CAN Webinar Q & A

Question 3 Testing CAN with Active Termination

This was a feature I was not aware of until the question was raised during the Pico CAN Webinar.

After some considerable reading it makes perfect sense why Active CAN BUS termination would be utilized with automotive networks. If we return to why passive termination (fixed resister/location) is necessary then active termination makes perfect sense.

Passive termination is predominately about limiting voltage signal reflections by matching the impedance of the CAN “twisted pair” wiring. Without termination, signals are reflected back into the wiring (like an echo) where they collide with existing CAN messages (traffic). These collisions have the adverse effect of corrupting CAN messages by altering their respective voltage levels and of course, bit timing.

Passive Termination limitations

Typically, passive termination is installed at each end of the CAN BUS which can be challenging from a manufacturer point of view (as a technician, try to find the “true” ends of a CAN BUS)

Passive termination can only maintain BUS impedance if the recessive voltage remains at the specified level. Should we encounter voltage or circuit errors that change the characteristics of the BUS resistance, the passive terminating resisters will respond accordingly, resulting in fluctuations in BUS impedance so risking data corruption.

With the above in mind, Active Termination tackles these issues head on with the advantage of finite control of the BUS impedance under varying load (traffic) conditions

Active termination serves an identical purpose to passive termination but with the superior advantage of being “dynamic” This allows the vehicle manufacturer to position the termination resisters in any CAN node so allowing a greater level of freedom during vehicle development.

Active termination allows for multiple vehicle configurations both during and post production (thinking here of vehicle conversions)

Active termination will have the ability to closely monitor and control BUS impedance under varying circuit conditions where voltage and BUS traffic conditions change. Impedance will therefore remain stable throughout so ensuring the integrity of CAN data.

Taking this a step further, active termination will allow for the optimum BUS impedance during times of exceptional BUS loading from heavy CAN traffic. This is achieved by momentarily shortening the effect length of the BUS (by changing termination resister location) so reducing data “travel time” (propagation).

This will no doubt give priority to areas of the network that may benefit from selected termination to ensure delivery of accurate CAN data.

The following link will help with an introduction to Active Termination and lead you to other sources of information https://diag.net/msg/m4aucx15et3rbnbqltwr588we9

So, thoughts now switch to “how will we test such networks?”

From here on in these are my thoughts on testing such networks as I have not yet found any vehicle utilizing this technology. (I am sure there are)

BUS voltages will remain similar as I see no immediate need for these to change. Testing the Physical layer for “activity” and voltage thresholds will therefore be the same, however we will have to be conscious of the BUS termination state.

It may be that all CAN nodes will have a termination resister by default (active on demand) or it may be that selected nodes will have the ability to become “active” terminating nodes when required.

Access to accurate technical data and training will be paramount once more as knowledge is power (especially product knowledge)

With sufficient knowledge combined with a Scope and OE Scan tool, we may be able to drive the BUS into varying states of termination whilst capturing these events with PicoScope.

It will be very interesting to capture the effects on CAN messages during the transition from one terminating resister to another as I am convinced it will be visible! (This in itself will be valuable diagnostic evidence of functionality)

I hope some of this helps and please feel free to add further information or share your experiences of these additional challenges we face with CAN

Take care……Steve

scienceofdiagnostics
Newbie
Posts: 2
Joined: Wed Mar 27, 2019 10:40 pm

### Re: Pico CAN Webinar Q & A

Excellent follow ups Steve. I'm still doing some research on the suggested diagnostic strategies for active termination as well as a few other things.

I'm a brand new member here, but I'll try to post what I find between here and on DN as time allows.

We'd love to see you over there occasionally as well.

Steve Smith
Pico Staff Member
Posts: 1671
Joined: Sun Aug 25, 2013 7:22 am

### Re: Pico CAN Webinar Q & A

Thank you for the feedback and welcome to the Forum. Thank you for your contributions to the Webinar too along with your support here with Active Termination.

The Diagnostic Network is awesome and I do try to check in where I can but time just vanishes day in day out.

Question 4
FlexRay networks, do they use termination resisters?

There are a number of “physical” similarities between CAN and FlexRay that we can be grateful for and these include termination resisters (which are used at the end of the FlexRay BUS) the familiar twisted pair cables and the voltage differential between them.

Typical termination resister values range between 80 and 110 ohms and so the need to refer to the relevant technical data is imperative

Reading through a BMW manual, their approach on measuring termination resisters on FlexRay networks comes with a warning of misinterpretation!

The concern surrounds the various FlexRay termination options that may result in misinterpretation of the measured resistance value! I can only think at this stage that the use of multiple termination resisters could result in differing values depending on your measurement point on the BUS. I guess we cannot rely 100% on resistance measurements too?

Again referring to BMW (F31) they are using various configurations of FlexRay networks on the same vehicle. As an example, the Gateway Module (ZGM) to Steering Column Switch Cluster (SZL) is a single “point to point” BUS with termination resisters in both modules, yet Stability Control, Chassis Management and Engine Management are on another bus with resisters inside the Stability Control and Engine Management modules.
I then counted a further 6 FlexRay networks with a total of 12 terminating resisters

Armed with accurate technical information will help here but once again the scope becomes invaluable to test the network dynamically.

Information on measuring FlexRay signals using the TA375 High Impendence Probes can be found here: topic21591.html?&p=98044&hilit=TA375#p97872

In the above forum post I mentioned how the decode feature for FlexRay was not successful. This was “Pilot Error” on my behalf as you are required to “invert” either the differential voltages (A-B) or the signal captured on Channel A (Channel B does not require inverting for a successful decode) This is a little confusing I know and I will dig deeper as to why.
FlexRay Decode
I hope this helps, take care…….Steve