Who's online and Who said what?

Ask any questions about using PicoScope 6 Automotive software here.
Post Reply
Steve Smith
Pico Staff Member
Pico Staff Member
Posts: 855
Joined: Sun Aug 25, 2013 7:22 am

Who's online and Who said what?

Post by Steve Smith »

One question that is continually raised and with CAN is “Who is online & who said what?

As we know, decoding CAN networks into useful, readable and valid information is challenging. topic21593.html?&p=97888#p97888

Let’s start right at the beginning with a snapshot of CAN traffic.

Here we are able to capture, then evaluate the integrity of the CAN signals (Physical Layer).

The speed and sample rate of the scope allows us to look at CAN signals as though we were looking through a microscope.

Below we have a glimpse of 2 CAN packets travelling through a twisted pair of CAN BUS wires, revealing the correct upper and lower voltage levels (3.5 V CAN Hi & 1.5 V CAN Lo) along with the correct “idle” voltage of 2.5 V
Image 1
Image 1
Note how the voltage “ringing” and “over-shoot” below is typical of automotive CAN signals and can be attributed to a number of factors such as the style of test lead (standard or high impedance) environmental noise, and “end of message” confirmation.
Image 2
Image 2
Remember that none of these are faults and CAN networks are immensely fault tolerant when it comes to the Physical Layer. Here is a typical example topic20981.html?&p=93851&hilit=fault+tolerant#p93851

If the above capture is to be considered “looking through a microscope” at the flowing CAN traffic, then the capture below should be compared to looking at flowing CAN traffic from a distance, but with the option to view in greater detail thanks to a pair of binoculars (referred to as zoom)
Image 3
Image 3
To put this volume of CAN data into perspective, the time across the screen is just 1 second (100 ms/div x 10 div) and using the CAN decode feature of PicoScope we conclude a total of 1066 message in just 1 second of passing traffic!

To display the decoded CAN data take a look at the image below.
Image 4
Image 4
If you are not sure of the “Baud Rate” (network speed) try this technique below.
Image 4B
Image 4B
Note how the decoded example above presents a warning to the user that the “sample rate may be too low” (the properties window indicates 1 MS/s where the ideal would be 2 MS/s min) which consequently may lead to erroneous CAN frames highlighted in red within the decode table.

To avoid this scenario we can use a number of software and hardware features to ensure a superior sample rate (sufficient to decode high speed CAN)

There are a number of decoding techniques listed here:
https://www.picoauto.com/library/traini ... onus-class
topic21593.html?&p=97888#p97888

Focusing further on CAN decoding, how can we ensure a sufficient sample rate to provide efficient serial decoding of high speed CAN, whilst allowing a practical time span on the screen to assist with CAN controller identification? Remember the “end game” here is to reveal the ID’s associated with a number of a number of CAN controllers.

The first tip is to increase the time span across the screen and the number of selected samples. Below I have used 500 ms/div (total time across the screen 5 seconds) with 10 MS which delivers 2 MS/s to ensure the integrity of our decoded CAN data.

10,000,000 Samples across the screen / 5 seconds screen time = 2,000,000 S/s

Next, rather than consume 2 x channels with CAN data, if we are happy with the formation of our CAN signal (see image 1 in this post) use channel A only to capture the CAN Hi signal via a High Impedance Probe (TA375) to minimize noise, ringing and signal intrusion. (Protect the integrity of the CAN signal)

More information can be found here on the TA375 High Impedance probe topic21591.html?&p=97872#p97872

The capture below highlights how the software settings and chosen hardware has a positive effect upon the capture of our CAN Hi network signal. Whilst the software still warns the user of a possible sample rate concern, we can see that every message in the decode table is without error. Note also how we now have a total of 5318 CAN frames to wade through!
Image 6
Image 6
The vehicle in question above is a 2013 BMW 2.0 Diesel F31 Auto where by the shift lever indicates the gear position via the high speed CAN network. (The gear lever is in effect a CAN Controller)

Channel B uses the TA234 current clamp https://www.picoauto.com/products/curre ... rent-clamp attached around the shift lever CAN Hi branch wire to act as a “location finder” for any transmissions sent from the shift lever.

To clarify the above, where we have a voltage differential (CAN Hi - CAN Lo = 0 V -2 V) there will be current flow (CAN Bus load approx. 60 Ohms) from the shift lever when messages are transmitted onto the CAN Bus network. Note the sequential spikes from the current clamp!

Using the Zoom, Time Rulers and Scaling features, we can measure the time span between each spike captured by the current clamp, approx. 30 ms. If we then place the mouse pointer over the decode bar (at either Time Ruler/current peak) within the PicoScope display (graph) a pop up window will reveal information about the CAN packets within the area of the mouse pointer.
Image 7
Image 7
This technique is very dependent on how steady you are with the mouse pointer and so I would recommend zooming directly above one of the Time Rulers and increasing the scale of channel B (x 50) to align the current spikes (Channel B) with each CAN packet (Channel A)

Notice how the peak current flow (within the shift lever CAN Hi branch wire) always coincides with a transmission from a CAN Controller with the ID 1 97 and these transmissions occur every 30 ms!
Image 8
Image 8
This is starting to look like the shift lever has the CAN ID 1 97!

Could we therefore categorically determine not only the CAN ID’s of the Shift Lever but other CAN Controllers using this same technique?

Before we move on there a few pointers to be aware with CAN ID’s:

The CAN ID serves a number of purposes, it informs of 11 or 29 bit CAN and the priority of the pay load (Data) The lower the numerical ID the higher the message priority.
The same CAN Controller can also produce multiple ID’s.

For example, engine coolant temperature ID maybe be grouped in “Temperature Related” messages, where the engine speed ID could be grouped with “Engine related” messages. Both ID’s have come from the same CAN Controller

A clue to the identification (ID) of a CAN Controller can be found in the “Arbitration” given arbitration is won based on message priority.
E.g. If we discover the byte within the “Data Field” that denotes the “Brakes ON or OFF” message, we could assume this data most probably originated from the ABS CAN Controller and hence we have now identified the ABS CAN Controller ID. This is not an exact science as the “Brakes ON or OFF” message could also come from the Cruise Control CAN Controller!

Basically what we are saying is that don’t be surprised if you discover multiple ID’s originate from a single CAN Controller (ECU)

Returning now to CAN ID’s, I mentioned earlier how current flow occurs every 30 ms from the shift lever, lets correlate these transmissions (current flow) within the CAN decode table using the “Filter Function”

Within the decode table click on the “Filter” button and enter 197 above the ID column to list only the CAN packets relevant to ID 1 97

Note how the Start and End time of each transmission from CAN Controller ID 1 97 is identical to the spikes detected by the current clamp (30 ms intervals)
Image 9
Image 9
I should have mentioned here that filtering the current clamp signal is going to be essential as we are pushing the limits of the 30 A current clamp when we are measuring approx. 10 mA

Looking at the Data field in the decode table (highlighted yellow) we can see how the first 3 bytes of data are constantly changing with no activation of the shift lever (not sure why)

If we were now to operate the shift lever we could look for a change in the data field (filtered column 197) that would help confirm we have correctly identified the shift lever as CAN ID 1 97

Now, time to take a breath:

PicoScope is not a CAN Decoder in the true sense of the word! We cannot collect continual streams of endless CAN data as we can with devices such as the Intrepid Vehicle Spy or X-Analyzer 3 loggers and software suites.

We (PicoScope) are decoding the Physical layer (BUS voltages) where these CAN Loggers (Intrepid etc.) are decoding the Silicone layer within the CAN controller. What we have on screen and in the Waveform Buffer is all we have to work with and so we have to get “clever” trying to identify CAN ID’s

An example of CAN decoding (reverse engineering) using dedicated CAN data loggers can be found here:
https://www.youtube.com/watch?v=Csn2pV3 ... e=youtu.be

Using a 3rd channel of PicoScope (Channel C) a pressure switch was placed on top of the shift lever “Park” switch in order to indicate within our displayed waveform when the Park switch was activated. An NVH interface (TA259) was used to provide power to a micro switch which in turn provided an output to PicoScope via the TA259 BNC output.

A couple of tips here, use this technique with the ignition on but engine off to minimize CAN activity and of course, ensure battery support is installed
Image 10
Image 10
Returning now to the decode table select “Display Packets Between Rulers” and “Filter” for ID 197. Scroll down the decode table and look for a change in the data bytes relative to the operation of the Park switch
Image 11
Image 11
Operating the “Park” switch forces a byte change from the shift lever on the CAN BUS where we can see the fourth data byte change from C0 to D5 (press Park) and return to C0 (release Park).

Given the shift lever is transmitting data every 30 ms, there is no change in the frequency of the current spikes. (I was expecting there to be an instant current spike when pressing the Park button) I guess 30 ms transmission intervals is sufficient to ensure any change in the shift lever status/operation is executed in a timely fashion.

All in all there is a lot to digest here with CAN ID’s and there are other techniques to demonstrate. One of which is CAN Controller/ECU disconnection topic21593.html?&p=97888#p97888

I will add to this post 2 other techniques to reveal CAN ID’s ASAP

To close for now, an understanding of the CAN network and structure you are diagnosing is essential and an accurate CAN topology or wiring diagram from the Vehicle Manufacturer is essential. These will reveal CAN “branches” and ensure the CAN line in which you are measuring current, is only capturing current from one source

Remember PicoScope is far more than an oscilloscope, amongst its numerous applications is a serial decode function. Whilst it is not a dedicated serial decoder we can manipulate the software to deliver decode/logger features. Knowing its strengths and weakness and applying the techniques above will help. (When it’s all you’ve got, then it’s all you’ve got!)

To summarize these techniques.

1. Use a single channel to obtain CAN Hi via a TA375 High Impedance Probe
2. Use 500 ms/div with 10 MS across the screen to obtain 3 buffers with 3 active channels
This equates to 15 seconds of data in total = approx. 15,000 CAN packets
3. Using 2 x monitors helps to position your decode table away from your PicoScope screen
4. Filter the current clamp (Low pass 1 kHz) use the zoom and scaling functions of PicoScope
5. Use the Time Rulers as markers/location finders in your captured CAN signal
6. Use the CAN Decode table Filter option for the ID or Data of choice
7. Measure current on a CAN branch wire only (Here we used shift lever CAN Hi)
8. Force a change of state from the CAN Controller (Here we pressed the Park switch)
9. Disconnect the CAN Controller of interest topic21593.html?&p=97888#p97888 Be careful of termination resisters, and “loop through” See Ben’s case study here: https://www.picoauto.com/library/case-s ... ions-fault
10. Force a change of state using an “Active Test” via a Scan Tool
E.g. Operate Cooling fan via scan tool and use cooling fan current as your guide to the CAN data of interest (location finder)
11. Use Excel which I will go through in the next post (As soon as I understand what I am doing)

I hope this helps, take care……Steve

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

Re: Who's online and Who said what?

Post by Steve Smith »

Thanks for reading up to this point, here is a “follow-on” with additional information surrounding points 9 and 10:

9. Disconnect the CAN Controller of interest
10. Force a change of state using an “Active Test” via a Scan Tool

Before we continue ensure the ignition is on, engine is off & battery support installed.

Below we have the low pressure, fuel priming pump control unit disconnected from the CAN network. “Fuel Control” is missing from the vehicle “ECU search” via the diagnostic scan tool

Fuel Pump Controller Offline
FP Offline Scan
FP Offline Scan
FP Offline Scope
FP Offline Scope
Using PicoScope we obtain 2 captures of the CAN network, one with the Fuel Pump Controller disconnected (as above) and one with the Fuel Pump Controller connected (below)

Fuel Pump Controller Online
FP Online Scan
FP Online Scan
FP Online Scope
FP Online Scope
In both captures, decode the data for all buffers (see image 4 previous post) and Export this data to a location on your PC. (You will have 2 x .csv files saved to a location on your PC)

Now open your exported .csv file containing the data with all ECU’s online. (Fuel pump controller connected-FP ON LINE)

Click on column “E” so that the entire list of ID’s are highlighted > Right click and select “Copy”
Now click on column “Q”, Right click and select Paste. This will copy all ID’s captured whilst all ECU’s were on line and copy them to a new column (Q). At this stage it would be good practice to give column “Q” a new header title to avoid confusion with so many lines of data. I have renamed column “Q” header as “ID FP ON”.

To reduce the amount of data (within column “Q”) click on the “Data” tab and select “Remove Duplicates” which removes over 10,000 ID’s; followed by “Sort” A-Z to place the ID’s in column “Q” in a logical order
Next, open your exported .csv file containing the data with the ECU of interest disconnected. (In this case it was the Fuel Pump Controller – FP OFF LINE) Right click on column E and copy the data to column “R” of the “FP ON LINE” .csv file. Now repeat the process above for removing duplicate ID’s, placing the data in a logical order and renaming column “R” (I have used ID FP OFF)

Finally, click on the “Home” tab, highlight columns “Q & R” and select “Conditional Formatting” > Highlight Cells Rules > Duplicate Values and select Unique values.
This will then highlight a number of ID’s that were present when the fuel pump controller was online (Column Q) but missing when the fuel pump controller was disconnected (Column R) Copy and paste these highlighted values into column “S” as these become our unique ID’s of interest

Excel
Excel

Here we have identified ID’s 2 26, 2 F8, 3 35, 3 67, 4 4C, & 5 17 are all missing when the fuel pump controller is taken off line. The ID 0F FF BF B9 is a “curve ball” at present as this ID appeared when the fuel pump controller was disconnected! I will dig deeper on this one ASAP

The video link below will take you through this whole process.
https://drive.google.com/file/d/1K0P1z2 ... sp=sharing

Forcing the fuel pump to activate using the scan tool is the next step, whilst capturing fuel pump current, and CAN Hi data simultaneously in a single waveform buffer.
ID 3 35
ID 3 35
Using the Decode Filter option enter each ID above the ID column to determine the relevance of the ID during fuel pump operation. Starting at the top, 2 26 & 2 F8 could not be found. ID 3 35 however appeared 4 times in 5 seconds at approx. 1 second intervals (look at “Start Time”). Interestingly enough, the first transmission of ID 3 35 was 50 ms before the in-rush current into the fuel pump. Note also how the “Data” column indicates a change in the information carried in the payload, suggesting an information update is taking place.

Moving on, ID 5 17 was the only other ID that was present during fuel pump operation, with transmissions every 646 ms approx. Note how the data field does not change during fuel pump operation, suggesting the data is not relevant to fuel pump operation. (This is an assumption at best and therefore cannot be discounted 100%)
ID 5 17
ID 5 17
Hopefully we are slowly narrowing down multiple ID’s to just two possibilities (3 35 & 5 17)

Using the “Decode Between Rulers” option we can begin to pinpoint the transmissions of CAN ID’s relative to fuel pump activation, so allowing for judgement on the relevance of ID’s 3 35 & 5 17
Decode between rulers
Decode between rulers
Above we can see how we are reducing the CAN data even further thanks to only decoding data between the time rulers. This will allow us to focus only on CAN traffic during fuel pump operation

To summarize at this stage:

ID 3 35 disappears when the fuel pump controller is disconnected from the CAN network
ID 3 35 is transmitted on the CAN bus if the fuel pump is activated or static, however the payload is continually updated at 1 second intervals when the fuel pump is running.
ID 3 35 is first transmitted 50 ms before the in-rush current into the fuel pump (Trigger point)

ID 5 17 disappears when the fuel pump controller is disconnected from the CAN network
ID 5 17 is transmitted on the CAN bus (at 646 ms intervals) if the fuel pump is activated or static, however the payload never changes. (It remains fixed at 00 00 00 00 12 61 00 17)
ID 5 17 transmissions appear periodic in nature with no influence on transmission timing (646 ms intervals) or payload regardless of pump operation either via the scan tool, or with the engine running.

There is still not enough evidence to ignore ID 5 17 but at this stage we know ID 3 35 is our fuel pump controller, whilst remaining mindful of ID 5 17 as we continue decoding other ID’s.
TEST 9 ACTIVE TEST FB LOW FLOW.psdata
FP Active test
(10.64 MiB) Downloaded 321 times
I will follow on ASAP with additional decoding techniques and features of Excel that will help group other ID’s relevant to their CAN Controller (Inc. ID 5 17)

Thanks for reading as I know its “heavy”….

I hope this helps, take care……Steve

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

Re: Who's online and Who said what?

Post by Steve Smith »

The final part of this journey takes advantage of the unique electrical characteristics (electrical signature) of each CAN Controller and discusses the techniques associated with grouping CAN ID’s

The technique covers the last item on the list from the first forum post above
11. Use Excel which I will go through in the next post (As soon as I understand what I am doing)

N.B Ensure the vehicle under test has sufficient battery support, the CAN network physical layer to be functioning correctly (in terms of dominant and recessive voltage levels) and your CAN data is captured using the High Impedance Probes. topic21591.html?&p=97872#p97872

Before I go on, please read the following article from the team at Warwick Control Technologies as the details below replicate their reverse engineering techniques
https://www.warwickcontrol.com/press-re ... gineering/

Until I read the article above I had not considered the fact that each CAN Controller (ECU) would have an “electrical signature”, but I guess it makes perfect sense. As the article describes, when arbitration has been won by the relevant CAN Controller, it can then go ahead and transmit its message/payload on the BUS. At this point in time only one CAN Controller is transmitting as all others fall silent (they have lost priority)

The dominant voltages (CAN Hi 3.5 V & CAN Lo 1.5 V) present on the BUS during the transmission of the message/payload will be unique to the CAN Controller transmitting the message due to manufacturer tolerances within the ECU, connectivity, varying components and its physical location on the BUS

During the transmission of CAN Frames/Packets we can use PicoScope serial decoding to locate just the message/payload of each CAN frame for any ID and then use Deep Measure topic17711.html to obtain the unique dominant voltage values for CAN Hi and CAN Lo during the transmission of the message/payload

Once we have these values, we can export the Deep Measure data into Excel, obtain the modal value for the dominant CAN Hi & CAN Lo voltages and plot them in graph form to link known CAN ID’s with unknown ID’s. I must confess here, I did not know what a “Modal” value was until I got stuck into Excel. Basically it is the number that occurs the most in a sequence of numbers.
For example: CAN Hi dominant voltages during a message transmission might be 3. 555 V, 3.555 V, 3.661 V, 3.514 V & 3.601 V. The modal value would therefore be 3.555 V as it occurs twice in the sequence of voltages described here.

Starting with our known Shift Lever ID 1 97, we use our serial decoding “Filter” tool to locate ID 1 97 and the Time Rulers to partition the message/payload from the complete CAN Frame/Packet. We then apply Deep Measure to channels A and B “Between the Rulers” to obtain accurate values for our CAN message dominant voltages

Partition “message” from CAN Frame
Partition message
Partition message
Apply Deep Measure “Between the rulers” for channel A and B. Below we have the procedure for the application of Deep Measure to channel B (CAN Lo) using 2 V as our crossing point or Cycle Threshold. Repeat this procedure for channel A (CAN Hi) using 3 V for our crossing point.
Apply Deep Measure
Apply Deep Measure
Below we have the dominant voltages (between the Time Rulers) captured via Deep Measure for CAN Hi during transmission of the payload for CAN ID 1 97. Repeat this procedure for CAN Lo looking at “Min Voltage” as these will be the dominant voltage values for CAN Lo
Dominant voltages
Dominant voltages
Using the “Export” button, save each Deep Measure .csv file to a location on your PC. To avoid confusion name the files 1 97 HI and 1 97 LO respectively. Open the .csv file and click on the empty cell below the relevant column of interest. For CAN Hi it will be the column header “Max Voltage V” and for CAN Lo it will be “Min Voltage V”
Locate Modal value
Locate Modal value
Click on “Recently Used” and select MODE.
N.B you may have to search for MODE using the “Insert Function” option, but once you have used MODE, it remains under the “Recently Used” button. This will then open the “Function Arguments” window which will automatically be populated with the cells for applying the MODE function. Click OK and the modal value will appear in the empty cell beneath Max Voltage V. For CAN Hi the unique modal value for our chosen ID 1 97 is 3.540776 V and for CAN Lo the value obtained was 1.491271 V.

Open a new Excel file and save these unique values to 2 new columns with the headings “CAN Hi & CAN Lo.” Repeat the above process for all the known and unknown ID’s you wish to qualify. In the second forum post above I could qualify ID 3 35 as fuel pump controller but there was a grey area surrounding ID 5 17.

With your new Excel file you can include additional columns with the headings “ID” and “Name” to act as a reference and provide a description for the known ID’s. Highlight all the unique values stored in the new Excel file, click on the Insert Tab and select a Scatter Chart. This will now plot all the highlighted unique values revealing the origin of unknown ID’s against known ID’s.

In the example below ID 3 35 (Fuel Pump Controller) has the same electrical signature as ID 5 17 suggesting that both ID’s originate from the same CAN controller.
Scatter Chart
Scatter Chart
In the article by Warwick Control Technologies they have used a clever technique of requesting a response from a number of ECU’s by sending standardized “diagnostic request” CAN ID’s/messages to various ECU’s (via a CAN data logger) and capturing the standardized response from the relevant ECU.
Think of the standard diagnostic request ID 7 E0 or 7 DF from a scan tool and the engine ECU response 7 E8.

If you then capture the modal unique dominant voltages of the response message (ID 7 E8) you can plot them in in your scatter chart along with other ID’s that form around this response. ID’s that cluster together around the same point within your Scatter Chart have the same electrical signature and hence originate from the same CAN controller

Given we don’t have this feature within PicoScope (the ability to generate diagnostic request ID’s /messages) we can use EOBD to request VIN data which will force a standardized response from the Engine ECU (7 E8) so providing us with “known” unique dominant voltages which we can then plot against other unknown ID’s
The following forum post will help here:
topic21593.html?&p=97888#p97888

The video below describes the application of CAN decoding, Deep Measure, Export to .csv and the creation of a Scatter Chart within Excel as I know reading such detail raises questions that a video can answer.
https://drive.google.com/file/d/1L5vDdU ... sp=sharing

What was interesting about other ID’s I plotted in the Scatter Chart was the lack of ID’s around the engine response ID 7 E8 as I would have thought multiple ID’s would be clustered around this ID. Given the vehicle is a BMW F31, whilst the engine ECU is connected to the PT-CAN, communication for engine control is predominantly via FlexRay.

I am going to try this technique of plotting unique modal voltages with another vehicle utilizing a CAN network and so validate the process further.

Thank you again for reading, I hope this helps

Take care…….Steve

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

Re: Who's online and Who said what?

Post by Steve Smith »

Following on from the 2nd forum post above regarding the BMW F31 N47 low pressure Fuel Pump Controller and CAN ID 3 35, the temptation to dig a little deeper into the data field (payload) associated with this ID was impossible to ignore

We summarized the 2nd post with………
ID 3 35 disappears when the fuel pump controller is disconnected from the CAN network
ID 3 35 is transmitted on the CAN bus if the fuel pump is activated or static, however the payload is continually updated at 1 second intervals when the fuel pump is running.
ID 3 35 is first transmitted 50 ms before the in-rush current into the fuel pump (Trigger point)

I would now like to share the attempts to decipher the data field associated with CAN ID 3 35 given we have proven this ID is relative to the operation of the fuel pump.

Below we have the low-pressure fuel pump running at a delivery rate of 120 L/H using a scan tool to carry out an “active test” with battery support installed and engine off. The scan tool provides 3 options to run the fuel pump, 60 L/H, 120 L/H & Full rate (no duty control)
Image 1
Image 1

The fuel pump is driven via the Fuel Pump Controller using a positive duty cycle which can be seen in the black math channel included in the capture above. See here for duty math channels and remember to remove the “minus“ symbol from the formula as we require positive duty for this style of fuel pump. (duty(A) is the formulas used here)

Moving onto decoding the data field from the fuel pump controller (CAN ID 3 35) we opt for decoding “between the time rulers” during fuel pump activation. See here for further tips on decoding

Below we have the decode settings for the CAN traffic present with the fuel pump active:
Image 2
Image 2
Below we have added a filter to the decode table such as to display only ID 3 35 (between the Time Rulers) allowing for complete focus on these relevant data packets
Image 3
Image 3
Notice how CAN ID 3 35 is transmitted on the CAN bus if the fuel pump is activated or static, and the data field (payload) is continually updated at 1 second intervals during fuel pump operation.
Using the Rotation Rulers & Partitions we have customised their values (typically degrees °) to “Seconds” (s) and positioned them on the graph to denote the “Start Time” of each of our fuel pump controller transmissions (post trigger).
This helps to relate the transmission rate of the fuel pump controller CAN messages to fuel pump activity

So how do we now translate the data field into human readable data?

Without the proprietary data base file (.dbc file) from the vehicle manufacturer, the answer is “with a lot of hard work and a little luck!”

Initially we need to understand how the data field in our decode table represents human readable data, in this case, decimal values.

The quick way is to change from Hexadecimal to Decimal in our decode table but remember, our CAN ID of 3 35 in Hexadecimal now becomes 3 53! (Therefore, filter for 3 53 Decimal not 3 35 Hex)
Image 4
Image 4
So how does ID 3 35 (Hex) become 3 53 (Decimal) and why bother?

The main reason we use hexadecimal is the fact we can represent huge numbers with fewer digits which makes for easier interpretation as humans. Whilst the Pico decode table can represent data in Hex, Binary, Decimal & ASCII, using just 2 digits of hexadecimal simplifies the display for analysis.

For example, the decimal number 12,500 in binary = 0011 0000 1101 0100 or 30D4 in hexadecimal

Below we have a reference table that will help with the conversion of Hexadecimal to Decimal values where 2 digits can represent 256 different values (including zero) N.B I have highlighted the conversion of our CAN ID 3 35 (Hex) to CAN ID 3 53 (Decimal)
Image 5
Image 5
Before I go on, you may often see digits/values represented as 0x52 or 0x98, the 0x denotes the values displayed are Hexadecimal values as without letters (A to F) it may not be immediately apparent! (0x52 = 82 Decimal & 0x98 = 152 Decimal)

I am going to return to the decode table in Hex (Image 3 above) rather than decimal to explain how these 2 digits refer to data bits, nibbles & bytes and how they can represent 256 different values as this I hope will bring clarity to how the CAN data/payload is constructed, assigned & interpreted.

Our typical can message will consist of 8 bytes of data; using image 3 above as an example, we can see Packet 1 Data Length Code DLC = 8 (8 Bytes of data transmitted within this packet)

N.B CAN Packet refers to the entire CAN frame consisting of:
ID, RTR, FDF, DLC, Data, CRC, ACK, CRC Valid, Bit Stiffing Valid, Valid & IDE

The Data Field contains multiples of 2 digits (Hex) grouped to represent each data byte (8 Bytes in total)
Packet 1 Data bytes = 00 C8 00 00 00 7E 00 00

Each byte consists of 8 bits (1 bit is the smallest building block of computer storage) either a binary 1 or 0 (CAN differential voltage 0 V or 2 V respectively) which is the language of the CAN network controllers.

A point to note here, the 8 bits are grouped into 2 consisting of 4 bits each and referred to as a “Nibble” (half a byte)

So how does Hexadecimal represent decimal units using binary values and why bother?

Once again, its all about ease of human interpretation of the hypnotic binary system (Computer language to human language)

The following image splits the Data/Payload into each of the 8 bytes numbered from Byte 0 to Byte 7
We also include the decimal/binary values, bits grouped into nibbles & bit numbering/position
Image 6
Image 6
Let’s take a look at the Data/Payload above and in particular Byte 1 0xC8 (200 Decimal)
C 8
8 4 2 1 8 4 2 1 (Bit Decimal value)
1 1 0 0 1 0 0 0 Binary (1 or 0) consisting of 8 bits (1 byte) grouped into 2 nibbles (4 bits)

To calculate the decimal value of 0xC & 0x8 we need to add the decimal units represented by each binary bit. C is therefore equal to 8 + 4 + 0 + 0 = 12 whilst 8 = 8 + 0 + 0 + 0 + 0 = 8 however 12 & 8 is not 200!

So how does the computer know whether the Hex value C8 = 200 or C = 12 & 8 = 8?

This all comes down to manufacturer coding and how the relevant controllers have been instructed to interpret the data transmitted on the CAN network. You may notice the “Bit Position” numbering under each byte in the image above. The bit position numbering sequence will vary between manufacturers and this is where the .dbc files becomes invaluable. However, for the purpose of this exercise we will assume they are numbered as above.

Let’s assume Byte 1 represented by 0xC8 (200 Decimal) equates to a target fuel delivery of 200 litres of fuel per hour transmitted from the fuel pump controller. The controller will have been programmed to transmit this value in the form of 8 bits of data (one byte).

N.B We will prove later Byte 1 does not equate to fuel delivery

For those ECU’s on the network that are interested in “Target Fuel Delivery” they will have been instructed to look at Byte 1 from ID 3 35, starting with bit number/position 48 with a length of 8 bits (bit 48 to 55 inclusive) Remember 8 bits (2 Hex Digits) can represent 256 different values (including zero) and this is referred to as 8 bit resolution.

Think now about the fuel delivery rate of our fuel pump, lets assume 0 to 200 L/H (maximum) which we can represent with 8 bits. 200 L/H / 256 = 0.781 L/H increments of fuel delivery. This may be overkill and while we have 256 increments at our disposal (with 8-bit resolution) we may only utilise 200

If 4 bits were used instead of 8, the ECU’s on the network that are interested in “Target Fuel Delivery” will have been instructed to look at Byte 1 from ID 3 35, starting with bit number 48 with a length of 4 bits (bit 48 to 51 inclusive) Remember 4 bits (1 Hex Digit) can represent 16 different values (including zero) and this is referred to as 4-bit resolution.

200 L/H / 16 = 12.5 L/H increments of fuel delivery which is insufficient for finite control of the fuel delivery rate

Resolution will vary depending on the data transmitted, the more bits utilised to represent the data, the more accurate and fine the measurement will be:

For example:

Headlights On or Off can be represented sufficiently with 1-bit (1 bit resolution) 1=On 0=Off

What about Engine speed (Rpm)?

4-bit resolution = 24 = 16 A resolution of 4 bits can encode an analogue input to one in 16 different levels (0-15 inclusive) 0-6000 rpm / 16 = 375 rpm. Rpm can be resolved down to 375 rpm intervals

8-bit resolution = 28 = 256 A resolution of 8 bits can encode an analogue input to one in 256 different levels (0-255 inclusive) 0-6000 rpm / 256 = 23.44 rpm. Rpm can be resolved down to 23.44 rpm intervals

12-bit resolution = 212 = 4096 A resolution of 12 bits can encode an analogue input to one in 4096 different levels (0-4095 inclusive) 0-6000 rpm / 4096 = 1.465 rpm. Rpm can be resolved down to 1.465 rpm intervals

16-bit resolution = 216 = A resolution of 16 bits can encode an analogue input to one in 65,536 different levels (0-65,532 inclusive) 0-6000 rpm / 65,536 = 0.092 rpm. Rpm can be resolved down to 0.092 rpm intervals

As you can see from the information above, depending on the resolution required for the relevant sensor/actuator, the appropriate bit resolution will be chosen

So how does this all relate to converting the fuel pump controller message into human readable data?

I mentioned at the start of this post that a little luck may be required where no .dbc file is available

Using the scan tool to operate the fuel pump I quickly recognised a pattern in the decimal values of the data field (payload) and the values displayed for fuel delivery rate during the active test!

Here is a summary:

ID 3 35 is transmitted every 1 second during pump operation

Byte 0 no change, remains fixed at 0x00 throughout pump operation

Byte 1 pump on or off cycles through hexadecimal values C8, D9, E9, 9, 19, etc. (increments of 16 in decimal)
These would appear to be a cyclic clock scrolling incrementally, possibly denoting operation time

Byte 2 changes from 0x00 pump off to 0x39, 0x38 with pump operation
Looking at image 1 above, we used a math channel to display positive duty control of the fuel pump (Approx. 48%) This byte could be a reference to Target Positive Duty cycle as the decimal value is 57! A possible correction to the acquired decimal value (57) could be 100 - 57 = 43% target positive duty
N.B This decimal value changes to 24 when driving the fuel pump at 60 L/H and the measured positive duty cycle using a math channel indicates 22 %

Byte 3 changes from 0x00 pump off to changing values mainly 1B, 1D & 1C with pump operation
For this byte at this stage in time I don’t have a theory on the data it could represent

Byte 4 changes from 0x00 pump off to 0x10 pump on and remains at 0x10 even though the pump has stopped at packet 8366.
I suspect this refers to fuel pressure!

Byte 5 changes from 7E pump off to changing values mainly 7D with pump on
7D represents a decimal value of 125 which I suspect is target fuel delivery (L/H)

Byte 6 changes from 0x00 pump off to 0x78 pump on
0x78 represents a decimal value of 120 which I suspect is actual fuel delivery which matches the display of the scan tool during the 120 L/H active test.
N.B This decimal value changes to 60 when driving the fuel pump at 60 L/H

Byte 7 changes from 0x00 pump off to 0x36 pump on
With reference to Byte 2 this could be Actual Fuel Pump Duty Cycle
N.B This decimal value changes to 27 when driving the fuel pump at 60 L/H

Below we can see the decimal values graphed against time which helps bring each byte to life
Image 7
Image 7
Using a combination of CAN decoding, filtering, graphing, & forcing pump operation, we have built a picture of how the data bytes have changed from the Fuel Pump Controller and linked their decimal values to units we can relate too E.g. Time, Delivery Rate & Pressure.

By no means is the above an exact science or 100% accurate as I might be way off the mark with a number of assumptions! Without a .dbc file to describe the CAN ID, byte order, start bit, bit length, formulas & units to apply to the decimal data we are “challenged” to say the least

I hope this forum post will reveal a number of tips when attempting to interpret CAN data and provide a foundation for comparison tests with problem vehicles

Moving on from CAN, the captures above include an accelerometer mounted on the fuel pump lock ring to qualify physical activity from the pump during operation. I noticed during the low delivery rate active test (60 L/H) the pump appeared noisy and laboured! This can be seen in the current flow through the fuel pump and the response from the accelerometer. Notice how duty control remains fixed throughout the 60 L/H test (Positive 22%) confirming the laboured behavior of the fuel pump is not a result of sporadic Fuel Pump Controller “control”
Image 8
Image 8
Using our NVH software we can capture the data from the accelerometer, convert to an audio file and listen to the playback! See here for listening to accelerometers
Image 9
Image 9
Take a listen to the audio from the fuel pump during delivery of 60 L/H
TEST 2 NVH FUEL PUMP AUDIO_A.wav
Fuel pump 60 & 120 L/H
(194.49 KiB) Downloaded 70 times
Whilst this vehicle does not demonstrate any issues at present surrounding fuel priming or performance, it would appear the fuel pump could be towards the end of its service life and I will keep a close eye on fuel pressure as this is my own car!

Thank you for taking the time to read through this post, there is a lot to digest for sure.

I hope it helps, take care…….Steve

Iver
TwoWaves
TwoWaves
Posts: 122
Joined: Mon May 27, 2019 2:55 pm

Re: Who's online and Who said what?

Post by Iver »

Steve.

Wow.
Some mind blowing stuff there. !!!

Grant_Baker
Newbie
Posts: 8
Joined: Tue Feb 07, 2017 10:58 pm

Re: Who's online and Who said what?

Post by Grant_Baker »

Excellent posts/articles, Steve! A lot of tips that may come in handy on CAN or other network testing. As a Lexus dealer Master Tech, I started using Pico in 2013 once the 4223/4423 became an SST. The classroom training I received from Lexus encouraged Pico as the preferred tool for network diagnostics. The serial decoding feature is something I have only recently explored after purchasing a personal 4425 from autonerdz. So to see you using this feature at this level is an encouragement for me to dig a lot deeper. :)

Post Reply