Question 1:
“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 and 2 V. You can read more about this in the following Scope School Bonus Class piece.
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.
Using 0 – 2 V as an example, the CAN node would choose the centre 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 that we do not live in a perfect world, the CAN nodes utilise 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 centre 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 midpoint and allow for approximately 10% hysteresis (typically noise) around this calculated midpoint in order to allow for voltage shift or fluctuations during the reception of a CAN frame.
A great explanation of hysteresis and the effects on crossing points can be found on page 157 in the PicoScope 6 User’s Guide. While this explanation applies to setting a trigger in 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 perfectly fine, even with a fluctuating CAN frame crossing point.
You can find the capture from above and relevant information in the following forum topic.
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 has thought of this already
Question 2:
“If Pico decodes a CAN message, how can 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 the Pico software?”
This is a great question, as we can never assume that all CAN controllers have decoded correctly just because PicoScope has decoded successfully.
PicoScope will decode CAN data based on 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 actually not the case. A fault may exist in a CAN branch wire to one CAN ECU/node leaving this node unable to decode, while the remaining nodes decode successfully (including PicoScope).
With regards to voltage ranges in nodes, the point 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.
- Serial data reports loss of communication to a CAN node that cannot decode CAN bus data
- Multiple CAN nodes reporting loss of communication with one particular CAN node (pointing the finger).
- Serial “Data bus Check” listing “Nodes on line” reveals one missing node
- Decoded data displayed in PicoScope may reveal multiple recessive bits within the RTR, ACK fields or CRC errors
- Using a dedicated CAN decoder/logger would also reveal the field errors mentioned in point 4, but decoded at the silicone level rather than at the physical layer as by PicoScope.
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 floored giving that the voltage levels may not be the same throughout the CAN bus.
The following forum topic looks a little deeper into unique voltage signatures associated with CAN nodes.
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 bypass 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), we would 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.
Question 3:
Testing CAN with Active Termination.
This was a feature I was not aware of until the question was raised during the live stream.
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 resistor/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 and risking data corruption.
Active Termination advantages
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 resistors in any CAN node, allowing for 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 resistor 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.
This link will help with an introduction to Active Termination and lead you to other sources of information.
So, thoughts now turn to “how to test such networks?”
From here on in, I have provided 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 resistor 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 as knowledge is power (especially product knowledge).
With sufficient knowledge combined with a scope and an OE scan tool, we may be able to drive the bus into varying states of termination while capturing these events with a PicoScope.
It will be very interesting to capture the effects on CAN messages during the transition from one terminating resistor 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.
Question 4
FlexRay networks, do they use termination resistors?
There are a number of physical similarities between CAN and FlexRay that we can be grateful for, and these include termination resistors (which are used at the end of the FlexRay bus), the familiar twisted pair cables, and the voltage differential between them.
Typical termination resistor 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 resistors 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. At this stage, I can only think that the use of multiple termination resistors could result in differing values depending on your measurement point on the bus. I guess we cannot rely 100% on resistance measurements either?
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 resistors in both modules. Yet, Stability Control, Chassis Management and Engine Management are on another bus with resistors inside the Stability Control and Engine Management modules.
I counted a further 6 FlexRay networks with a total of 12 terminating resistors.
Being armed with accurate technical information will help here, but once again the scope becomes invaluable to test the network dynamically.
You can find information about measuring FlexRay signals using the TA375 High Impendence Probes here.
Note: In this forum post, I mentioned how the decode feature for FlexRay was not successful. This was a 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.
