Networks: Sleeping-Active-Communicating-Signing off

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

Networks: Sleeping-Active-Communicating-Signing off

Post by Steve Smith »

It has often niggled me about network activity at the point of “wake up” and how multiple networks interact with one another at this point in time

With the above in mind, I thought it would be a good idea to monitor a number of networks found at the Front Electronic Module (FEM) of a 2013 BMW 320 d (F31)

Below we have 5 networks captured (there are more on the vehicle too) using the PicoScope 4823 whilst monitoring parasitic drain using the volt drop method discussed here viewtopic.php?p=96541#p96541

Channel A: PT CAN 500 kbs
Channel B: K CAN 2 500 kbs
Channel C: FlexRay 10 Mbs
Channel D: K CAN 100 kbs
Channel E: LIN 19.2 kbs
Channel F: Parasitic drain via a 0.1 Ω resister +- 20 A input range
Channel G: Parasitic drain via a 0.1 Ω resister +- 500 mA input range
Image 1
Image 1
Focusing on channel G above (parasitic drain) with the vehicle unlocked but “sleeping”; opening the LH front (LHF) door we see the first network to respond is PT CAN with the bus voltage moving to the recessive/idle level (no communication takes place at this stage)

Following the PT CAN network we have FlexRay 2nd, K CAN 2 3rd, K CAN 4th and finally LIN
Note how PT CAN, FlexRay and K CAN 2 all wake but do not immediately start communicating (they simply move to the recessive state)

Please keep in mind, throughout this whole capture the ignition has not been switch on, simply opening the LHF door starts all the activity we see above!

The first network to start communicating is PT CAN which was the first network to move to the recessive state and communication starts approx. 25.8 ms after the LHF door is opened

Armed with this information, my next thought was “what ECUs are communicating during the initial wake up of the networks?”

Using the PicoScope decoders we can dig a little deeper and decode between the time rulers to find out
Image 2
Image 2
Note above how the decoded data within the graph view confirms a number of “Errors” denoted in red. At a glance we can see errors are present at the start of communication in all CAN networks (Channels A, B & D)

Below; the decode table explains WHY when we refer to the “Acknowledge” (ACK) column for our CAN networks. Typically, the ACK field within a CAN packet includes a dominate “0” which confirms the transmitted message has been received by other ECUs on the network and therefore communication must be in progress. An ACK field populated with a recessive “1” suggests the transmitted message has not been received and the most likely reason in this scenario is that other ECUs are not awake!
Image 3
Image 3
Starting with “A PT CAN 500” our first successful acknowledgment is denoted with a dominant “0” (packet 59) at -8.573 ms before the trigger. This is the point where communication actually begins between ECUs on the PT CAN network even though the PT CAN network was “active” prior to -8.573 ms. Note how new IDs now appear (after packet 59) within the ID column confirming more ECUs are now online

Below we have removed the captured waveforms but kept the decoded data within the graph view to enable easier viewing and interpretation of the status or each network
Image 4
Image 4
Note above; after communication begins, there remain periodic errors due to momentary sporadic voltage levels on each network which fail to meet the threshold requirements configured in our decoder. (e.g., PT CAN threshold /crossing point = 3.0 V)

To avoid these scenarios, capturing the Hi and Lo bus signals (for each differential bus) and using a math channel to derive the differential voltage would return improved decoder results during sporadic voltage events as they are tolerated and cancelled out. (This however would require far more than 8 channels)

So, to summarize the status of each network at the point of “wake up” (in chronological order) we have:

1. Channel A: PT CAN 500 moves to recessive state at -44.75 ms, transmissions start at -18.53 ms and successful communication commences at -8.573 ms (Packet 59)
2. Channel C: FlexRay 10 Mbps moves to recessive (idle) state at – 22.09 ms, transmission starts at 19.46 ms and successful communication commences at 36.96 ms (Packet 1)
3. Channel B: K CAN 2 500 moves to recessive state at -21.93 ms, transmissions start at 37.08 ms and successful communication commences at 127 ms (Packet 311)
4. Channel D: K CAN 100 utilizes a different physical layer voltage structure (0 .. 4.5 V) where transmission starts at 37.08 ms and successful communication commences at 247.1 ms (Packet 167)
5. Channel E: LIN utilizes a 0 .. 12 V voltage structure where successful communication starts immediately at 144.9 ms (Packet 1)

Note: times are quoted in relation to the trigger point set at 10% into the capture; therefore, negative times (e.g., -8.573 ms) mean 8.573 ms before the trigger and positive times refer to timing post trigger point

To put all this data into perspective, from the point of opening the LH front door (-44.75 ms prior to trigger) all captured networks are communicating successfully after 291.85 ms (-44.75 ms prior to trigger to + 247.1 ms post trigger)

Whilst the decode table indicates network errors, the design of the networks is such that repeat attempts are made to retransmit (within the error handling rules of the protocol) until acknowledgments are received; and all this activity is taking place before the driver has even sat down and turned the ignition on!

With that said, ECUs will not transmit indefinitely (babbling) as this has the potential to “block” the network, especially if the transmitting ECU is of a high priority. In such a scenario the transmitting ECU will revert to one of three error states, Error Active, Error Passive and Bus Off whilst the receiving ECUs will log each error transmission as a “Receive Error Count” (REC)

1. Error Active: The ECU will transmit “Active error flags” and terminate messages on the bus
2. Error Passive: The ECU will transmit “Passive error flags” but cannot terminate messages on the bus
3. Bus Off: Here the ECU will appear off line and will only attempt to retransmit after a predetermined time where the ECU will return to the Error Passive state and if successful subsequent transmissions are acknowledged, revert to the Error Active state. Depending on system design, an ECU that has moved to a “Bus Off” state may require resetting via cycling the ignition (power supply reset).

Below we have captured PT CAN & K CAN 2 waking from sleep using Vehicle Spy 3 software in conjunction with their Value CAN 4-2 logger to reveal the Receive Error counts (RECs)
Image 4A
Image 4A
Below PicoScope has captured and displayed the above events within the decode table and confirms the errors are predominately with PT CAN where they have been “Acknowledged” (ACK = dominant “0”) but are invalid
Image 4BB
Image 4BB
The more I digest the information above, I can see why we often receive CAN communication codes (“U” codes) when carrying out vehicle DTC scans. The potential for CAN errors to be logged due to a combination of slow “wake up” of ECUs or low battery voltage prior to cranking is huge and would explain why such codes are stored yet not determinantal to vehicle performance (Note: This vehicle has no illuminated warning lights and no drivability/functionality issues)

Moving onto vehicle shutdown (moving from active communication to recessive/idle) I was intrigued to see which of our captured networks are last to “sign off”.

Below the vehicle is locked with the key fob and all networks monitored accordingly.
Image 5
Image 5
Above we can see the first network to “sign off” (fall silent) is Channel D: K CAN 100 (convenience items), followed by Channel B: K CAN 2 500; immediately after we have Channel A: PT CAN 500, then Channel E: LIN and finally Channel C: FlexRay.

Below we have listed the decoded data packets in reverse order (final packet transmitted listed first) where you can refer to the packet “End time” as a direct indication of when the networks fall silent. (N.B other than LIN, note the absence of decode errors during “sign off” unlike the start of transmission mentioned earlier)

In chronological order of “Sign off” we have:

• Channel D: K CAN 100 -1.636 seconds (First to sign off)
• Channel B: K CAN 2 500 -1.630 seconds
• Channel A: PT CAN 500 -1.629 seconds
• Channel E: LIN -1.577 seconds
• Channel C: FlexRay -1.527 seconds (Last to sign off)
Image 6
Image 6
Note: Once again, times above are quoted in relation to the trigger point set at 90% into the capture.

Note how throughout the “sign off” period our parasitic drain is approximately 3 A which then increases after all networks have fallen silent! This got me thinking about shut down times and parasitic activity thereafter.

In order to measure parasitic drain accurately without fear of drift and noise intrusion, the volt drop method was used. However, rather than use a math channel as described here viewtopic.php?p=96541#p96541 a custom probe was created to enable instant display of current flow rather than having to stop the scope to display the math results.

Note below the linear equation used for a parasitic drain resister of 0.1 Ω (y = 10 x + 0)
Image 7
Image 7
The keen eyed will have no doubt spotted 2 channels were used for parasitic drain measurements (Channels F and G) WHY?

Parasitic drain activity not only differs from vehicle to vehicle, but also differs depending on the operating condition of the vehicle under test. (Think of an engine cooling fan running after the vehicle is locked)

In order to capture and accurately measure parasitic drain during periods of “Stand-by” and “Sleep” we require a low input range (+- 500 mA) to take full advantage of the vertical resolution of the scope.

However, during periods of “Shutdown” (as we see above) parasitic drain could be as high as 20 A + where we require a higher input range (e.g., +- 20 A)

To over-come this issue and deliver the best of both worlds, we can use a double BNC adapter and link our respective channels (See below)
Image 0000
Image 0000
Note above how Channel G uses a x1 test lead which ultimately is connected across a 0.1 Ω and measuring volt drop. Channel F is now linked to Channel G where we can now choose different input ranges for optimal resolution at all current flow levels without having to sacrifice resolution in order to keep high transient events of parasitic drain within range.

The image below reveals the benefits of the measurement technique described above
Image 8
Image 8
Note: The networks above appear to wake and sleep at identical points in time, this is purely because of the time base at 50 s/div; zooming in will reveal their true correlation to one another with improved resolution (N.B. Total shutdown to sleep time approx. 3 minutes and 40 seconds)

A couple of paragraphs to the wise:

1. When probing high speed networks please use the High Impedance probes as can be seen above on Channels A through to F. The following link explains the impact probes can and do have on networks such as FlexRay viewtopic.php?p=97872#p97872

2. Modern vehicles will literally commence “power up” upon receiving a successful “unlock” signal from a key fob, or when simply opening a door. This could involve the activation of multiple auxiliaries such as glow plugs, contactors and pumps etc. (not to mention Media systems!) Please be conscious of current flow via a 0.1 Ω parasitic drain resister as this will begin to heat up very quickly indeed

Below we have a thermal image of the 0.1 Ω parasitic drain resister used for the testing above (approx. 1.5 hours of testing where the ignition was never switched on)
Flir Image
Flir Image
The device used above is the Arcol 0.1 Ω HS150 wire wound, chassis mount resister rated at 150 W thanks to the included heat sink which you could supplement with an aluminum plate and cooling fan if required! (Food for thought)

Based on our peak parasitic drain of 18.66 A via a 0.1 Ω resister our voltage drop would be:
V = I x R
V = 18.66 x 0.1 = 1.866 V drop

Watts = V x I
W = 18.66 x 1.866 = 34.820 Watts (peak) which is well within or rated 150-Watt resister

I hope the above helps and goes someway to explaining why we often see CAN error codes (without symptoms) which we can now attribute to the characteristic behavior of fault tolerant, error handling CAN.
(Not all CAN errors are faults!)

Take care…….Steve
Post Reply