ECU Diagnostics – part 3 : Test Setup

Ok, so we have an OBD port/connector on our cars that connects directly to the ECU. How are we going to figure out how to talk the right communications protocols to the car to get at its internal data?

We need a test rig to do some experiments with.

If you're looking for a post about "How to..." set all this up then that will be coming at the end of this series of posts in a "How to set up a Raspberry Pi to talk to a Caterham" post

After a bit of research over the years I’d already purchased a few bits and pieces to connect to a CAN bus. There are many ways of doing this but I settled on the following approach from my box of bits and pieces.

Here’s a schematic view of the setup…

Caterham ECU Diagnostic Test Setup

And then this is what it looked like in real life, Easimap is running in the top left corner on the screen of the MacBook. The Raspberry Pi and PiCAN are propped against the front left of the laptop.

OBD Test Setup. Raspberry Pi with PiCAN2, MacBook running Windows and Easimap+MBE985, connected to car through OBD Y-Cable

So what is all that doing? Firsly, lets give a quick run-down on all the bits and pieces:

Raspberry Pi

Raspberry Pi 4

Raspberry Pi: This is a Raspberry Pi 4, but anything from a Raspberry Pi 2 onwards is probably ok. Certainly a 3 or 4 are great. The Raspberry Pi is running Linux and can interface to the PiCAN to extract CAN bus frames.


PiCAN3 sitting on top of a Raspberry Pi 4

PiCAN: Is an interface card that plugs on top of the Raspberry Pi. The PiCAN2 SMPS (switched mode power supply) can also provide power from the CANbus to the PI. If you have a Pi4 and want it to be powered from the CANbus then you’ll need the PiCAN3.


Wireshark showing CAN packets

Wireshark/Tshark: Wireshark is a Network Protocol Analyzer or packet sniffer application that can intercept packets on a network and decode them into a human readable form. It runs on Windows, MacOS and Linux and can decode, or dissect as its known, hundreds of different network protocols and is immensely useful in today’s world of computing. Tshark is the command line version of Wireshark (built from the same source code) and is what I used in this test setup. I used tshark because I was running my Raspberry Pi with no graphical user interface, just remote command line access using ssh from my MacBook. Tshark allows you to capture and view packets just like Wireshark but without the graphical interface.

We’ll be talking about Wireshark in a future post as it soon became apparent that Wireshark wasn’t properly able to decode the CAN bus communications from my car, but more on that in the next post!


Easimap – MBE ECU Windows Diagnostic Application

Easimap: A windows application from SBD that can interface with a 9A4 ECU and extract data. For unlocked ECU’s (not the standard Caterham one) it can also extract/load Maps, and download/upload ECU images (the whole software and data setup of the ECU). Easimap can graphically show ECU data in real-time. Easimap runs on Windows but in this test I was running Windows in a Virtual Machine on a MacBook Pro.


MBE 985 CANbus to USB Interface

MBE985: This is an interface device that converts CANbus data into a USB format that a Windows PC can access using Easimap. Easimap sends commands to the car and receives data back by communicating through the MBE985 over USB which then sends the communications over the CAN bus.

For those of a curious nature, I pulled my MBE 985 apart to see what made it tick. We were wondering if there was much translation going on between what we had seen on the USB interface and what was being sent to the CAN bus. As you can see from the picture below, the MBE 985 is a reasonably complicated interface – more than you might expect in a CAN bus to USB interface.

MBE 985 internals

The interface is using a 25Mhz Infineon processor that has a CAN bus interface built in. It also has a 4Mb Flash chip on the board. So this interface is doing some reasonably serious processing!

OBD Y-Cable

OBD Y-Cable

OBD Y-Cable: In my setup I used this Y-cable to connect everything together. It allows the Easimap/MBE985 combo to connect to the ECU but also allows the Raspberry Pi/ PiCAN to “see” the communication between Easimap and the ECU – In the Internet world we would say that it allows the Raspberry Pi to “sniff” the CANbus traffic. Another way of putting it is to say that the Easimap and Raspberry Pi are “in parallel” with each other on the same bus and both able to see the communications to the car at the same time. The MBE 985, PiCAN and ECU are now three devices on the CAN bus.

MacBook Pro

MacBook Pro Laptop: I used a MacBook as the host to run the Easimap Software but however, that actually only runs on Windows. And in order to get around that small niggle,  I use the Parallels Virtual Machine software to run Windows on the Mac as a “Virtual Machine Host” and then to run Easimap inside that Windows virtual machine. If MS Windows it your thing then you could replace this Mac/Parallels/Windows/Easimap configuration with a PC/Windows/Easimap setup.


Parallels Virtual Machine Software for Mac

Parallels:  This is a Virtual Machine application that allows a Mac to run other operating systems “on top” of MacOS. It can run Windows, Linux and even another copy of MacOS. You don’t need this if you’re running Windows on the bare metal (i.e. Windows directly on the computer).

With all that connected up we can start to investigate how Easimap talks to the car’s ECU.

Capturing Packets

I guess there are a number of ways of figuring out what Easimap was doing. For instance, we could have had  a go at disassembling the Easimap software… But that would have been a massive task and very unlikely to yield any results in a non-geological time frame. I’ve disassembled other people’s code in the past… and it took months.

The best approach was probably going to be a technique called “packet sniffing”. And we had two points of entry there too to think about.

One approach that was tried was to “sniff” the packets being sent by Easimap to the MBE985. That would mean sniffing the USB connection between Easimap and the MBE985 and Wireshark is a great way of doing that. James (Aerobod) on Blatchat had been doing this and got some good background info…

But that wasn’t going to be my approach…

I wanted to get direct access to the CANbus. I wanted to see what I would have to signal on the CAN bus itself if I was going to replace Easimap. That meant sniffing the CAN bus frames and pulling apart the communications at that level.

And now to some Packet Sniffing

Ok, so now we have our hardware and software all set up to capture some of the communication between Easimap and the car.

The process will be to:

  • Connect all the hardware and turn it on
  • Run the tshark packet capture on the Raspberry Pi
  • Start up Easimap on the Windows Virtual Machine
  • Now turn on the car (my car has a battery isolator) and then put the car into ignition switch position 2 – that seems to keep the ECU talking
  • Stop the capture and transfer the capture file (.pcapng) over to my Mac for review

I spent about 10 minutes one evening taking a few initial captures, and those files kept me going for over a week. That’s often the way with these things. There’s so much to learn in the initial investigation, that you spend ages looking at just a few seconds worth of data.

Once I had the captures on my laptop I could review and anaylize them with the car and the Raspberry Pi off.

Initial Results – MBE-Broadcast

The CANbus frames I’m going to show now just contain the ID and data parts. The captures also contain the error, extension, etc flags that we talked about in a previous post… but there’s nothing interesting in those bits of the frames now we know we have some good communication between PiCAN2 and the car, so I won’t show them here.

To get a capture on the raspberry Pi we just run the following command. There’s a whole setup process for the Pi that I’ll talk about in its own post and put a link [here] when it’s done. But once that’s done we just run this command.

-> sudo tshark -i can0

And if we want to capture the packets to a file then we could supply a file like this:

-> sudo tshark -i can0 -w /tmp/mycapture.pcapng

When the car is first turned on it starts churning out the following packets:

# Time        ID          Data
8 0.069921880 0x0cbb0001 04 95 ff 28 00 00 00 00
9 0.079854830 0x0cbb0001 03 27 00 1e 00 1e 00 00
10 0.089837445 0x0cbb0001 02 aa aa 00 af d6 00 00
11 0.100195073 0x0cbb0001 01 50 00 00 39 00 95 48
12 0.110361352 0x0cbb0001 ff 00 00 00 00 00 00 00
13 0.119903104 0x0cbb0001 ff 00 00 00 00 00 00 00
14 0.129903793 0x0cbb0001 ff 48 00 00 00 00 00 00
15 0.139997221 0x0cbb0001 ff 95 00 00 00 00 00 00

Those 8 packets get repeated continuously… non-stop… without the Easimap software running. 

A quick description of what we’re seeing here, the columns of data represent:

  • # is packet number
  • Time is the number of seconds since the tshark capture started
  • ID is the CAN bus ID (arbitration field / address)
  • Data is the 8 bytes of data for each frame (in hexadecimal).

Not a lot of that made sense. And to be honest we haven’t really dug into this data stream (note from the future – we do now have batter idea of this MBE Broadcast  Protocol). My car’s engine wasn’t running here, so there’s probably even less of interest in those packets above. It seems to be something proprietary to MBE though and I suspect has some useful information in the stream but because the data is so limited we didn’t delve into it. I’ve called this data stream “MBE Broadcast” (because it comes from the MBE 9A4 ECU) and is characterised by the CANbus ID of 0x0cbb0001 and doesn’t have the same depth of info as the next protocol we’ll look at.

At first we thought these simple messages were all we were going to receive. There was talk on the forums that you needed to send an “unlock” frame to the car and then it would add more data to this Simple data stream. That turned out to be a red herring but initially we thought that the unlock code was in some way opening a CANbus bridge and we’d see more data once it was opened… that isn’t the case as we’ll see later.

We’ll come back to this protocol in a full post on the MBE Broadcast protocol later on.

Next Level of Results – MBE ISOTP

So, we’re not so interested in the MBE Broadcast protocol. Before we had Easimap running we did spend a couple of days trying to figure out if it was useful. But as soon as we got sniffing Easimap communications we knew we wanted to move on.

I’ve called this next protocol “MBE ISOTP” and we’ll have to wait for a future post on exactly why I’ve called it that, but suffice to say, this is the protocol that Easimap uses to talk to the car.

As soon as Easimap starts up, it begins to talk to the car… and we get this initial communication that doesn’t repeat (at least not for a long period after the car starts up):

#  Time        ID         Data
28 0.265548270 0x0cbe1101 03 04 00 0d 26 40 42 43
29 0.266543253 0x0cbe0111 10 0d e4 00 0d 23 39 41
30 0.266872637 0x0cbe0111 21 34 62 65 35 33 30 00
37 0.326052544 0x0cbe1101 03 04 00 5e 26 40 42 43
38 0.327045620 0x0cbe0111 07 e4 00 5e 2b 07 01 00

Then we get this set of 31 packets that repeat continually:

#   Time        ID         Data
80 0.736160089 0x0cbe1101 10 0a 01 00 00 00 00 12
81 0.736958836 0x0cbe1101 21 66 67 a8 a9 00 00 12
82 0.738230722 0x0cbe0111 05 81 aa aa 16 00 12 66
84 0.749027454 0x0cbe1101 10 09 01 00 00 00 00 1a
85 0.749733313 0x0cbe1101 21 52 5c 5d 00 00 00 1a
86 0.750875498 0x0cbe0111 04 81 84 00 00 00 1a 52
89 0.767924313 0x0cbe1101 10 0a 01 00 00 00 00 e2
90 0.768777632 0x0cbe1101 21 cc cd ce cf 00 00 e2
91 0.769825875 0x0cbe0111 05 81 ff ff ff 07 e2 cc
93 0.780880102 0x0cbe1101 10 23 01 00 00 00 00 f8
95 0.781565869 0x0cbe1101 21 30 31 36 37 44 45 4c
96 0.782301116 0x0cbe1101 22 4d 4e 4f 50 51 5a 5b
97 0.783061863 0x0cbe1101 23 5c 5d 64 6a 6b 7c 7d
98 0.783818702 0x0cbe1101 24 9e 9f a0 a1 d8 d9 da
99 0.784526524 0x0cbe1101 25 db 9f a0 a1 d8 d9 da
100 0.785768596 0x0cbe0111 10 1e 81 5e 39 cc 48 dc
101 0.786095776 0x0cbe0111 21 50 9c 89 1e 85 5e 39
102 0.786437863 0x0cbe0111 22 a8 0d 66 a0 00 b0 4f
103 0.786777913 0x0cbe0111 23 00 00 56 95 80 09 00
104 0.787102630 0x0cbe0111 24 80 00 80 a1 d8 d9 da
106 0.798260523 0x0cbe1101 10 0a 01 00 00 00 00 f9
107 0.799080454 0x0cbe1101 21 ba bb bc bd 00 00 f9
108 0.800070197 0x0cbe0111 05 81 78 1e dc 1e f9 ba
110 0.810033090 0x0cbe1101 10 09 01 00 00 00 00 fa
111 0.810853632 0x0cbe1101 21 64 65 6c 00 00 00 fa
113 0.812042780 0x0cbe0111 04 81 8c 1e 00 00 fa 64
115 0.821498922 0x0cbe1101 10 0e 01 00 00 00 00 fd
116 0.822377593 0x0cbe1101 21 20 24 25 26 40 42 43
117 0.823099192 0x0cbe1101 22 4d 24 25 26 40 42 43
118 0.824343987 0x0cbe0111 10 09 81 40 00 00 01 80
119 0.824665352 0x0cbe0111 21 b0 40 40 26 40 42 43

Ok, so we got a good dump of data from the car, but what does it all mean? We were baffled. You can see the packet numbers here aren’t contiguous… in-between these MBE ISOTP packets are the MBE Broadcast packets – interspersed – I’ve removed them here so you can see the “raw” MBE ISOTP packets and what we were now trying to decipher.

Those 31 repeating packets were all being sent and received within a 100ms time frame. And they repeat almost instantly. That probably implies that Easimap is updating its graphical display 10 times a second. At least that sets us a reasonable rate at which we might be able to do the same. A rev-counter display or something similar will be more than responsive enough if we can refresh it at that rate.

Now… Before we can move onto decoding this some more, we need to take a bit of a diversion back into Wireshark, because things weren’t adding up there at the moment. 

ECU Diagnostics – part 2 : ECU, OBD and CAN


Caterhams, like all modern cars, have an Engine Control Unit (ECU) – a black box full of electronics, controlled by a microprocessor that manages how the engine runs.  And because it has a microprocessor it means it runs some software to control everything. It also connects to a bunch of sensors, like temperature, pressure, engine speed, air-flow, lambda etc which it then uses to set the engine’s inputs, things like ignition advance/retard, air/fuel mixture and other stuff.

The ECU on a factory, or self-build car, is manufactured by MBE Systems and seems to be supplied to Caterham through SBDMotorsport in the UK. The model used by Caterham is the 9A4 that runs Caterham specific software and mapping. It is also “locked” – meaning that there is no user accessible way of modifying the software or the map. We’ll talk about maps and software in a later post.

What these MBE ECU’s do allow though, is access to the internal sensor information used by the ECU to run the engine. There are many, many parameters used by the software to make an engine run properly and we hoped to be able to see all this information in “real time” – meaning we can see the data change in front of our eyes, hopefully being updated many times per second.

It’s also important to understand that there is both primary data (taken directly from physical sensors) and derived data (secondary, extrapolated or calculated data derived from the primary data). We’ll hopefully be able to see both.

The standard location for the ECU is underneath the battery in the engine bay:

MBE 9A4 ECU located under the battery and behind the grey plug connecting it to the wiring loom


In order for us to be able to interrogate the ECU and extract all this data, we need some way of connecting a computer into the ECU. Handily, legislation has been in place for a number of years that requires car manufacturers to fit a car with a diagnostic connector. This is known as the OBD port and looks like this:

OBD connector located above the ignition switch on the steering column

It’s through this connector that we’ll be getting access to the ECU and hopefully seeing what’s going on. The OBD port on a Caterham is located above the steering column underneath the dash. On my 2017 car it is loosely mounted, dangling on a short length of electrical cables that run to the connector. So you need to be careful when handling it so you don’t pull any of the cables out of the connector.

There are a bunch of standards that define the physical and electrical OBD connector used on cars. The data that’s sent through this connector (I’ll also call it a port) is mostly open to the car manufacturer as to what gets sent and what standard transmission protocols are supported. It’s also very common that the data sent on these ports is proprietary to the particular ECU manufacturer, each one having their own protocols.

For those reading this that aren’t quite so into communications protocols – a protocol is like a language. Computers and tech stuff communicate between each other using protocols. These protocols define what gets sent between two computers and how to interpret it. For instance, there are now over 8000 protocols that define how devices communicate over the internet, and more are being added every day. Check out the IETF RFC pages to learn more about those protocols and standards.

To make things more complicated, manufacturers of different equipment may interpret the protocol definitions (known as “standards”) differently and so end up with dialects of these languages. So the protocols differ from one manufacturer to another just like different dialects of French or English.

Fortunately, there is one protocol that does seem to be reasonably well followed by most car manufacturers and that gives us something to start with. That protocol is often known as OBD-II (OBD 2). We’ll go into more detail about the protocols supported by the MBU 9A4 in a future post.

As we started this investigation, learning about a Caterham’s ECU diagnostic port, we knew only a few things:

  • SBD Motorsport supplies a piece of Windows software (Easimap) that can get all the available data points from the car
  • OBD-II Scanners can access some data from the car (though not as much as Easimap)
  • People have tried to access the diagnostic data on a Caterham before and not been able to find much

So, we started with a general assumption that because the Easimap software could interrogate the car for lots of data, then hopefully we could too. Though one thing on our minds as we started out on this journey, was whether the data exchange (protocol) used between the car and the Easimap software was encrypted – that would cause a whole further level of investigation and might lead to all this effort being fruitless.

Early on in our investigations we wondered if Caterham and MBE were doing something special (in an electrical sense) on the OBD port that was proprietary. However, a quick check under the dash and we can see that Caterhams have only 4 wires connected to the OBD port. There is 0v, 12v, CAN-L and CAN-H. CAN-L and CAN-H make up a twisted pair, see CAN bus below for more on those signals. So, we could see that none of the reserved connections on the OBD port were being used for anything special.

OBD Connector. 2 x 0v (black), 12v (purple), CAN-L and CAN-H


There’s another twist to the OBD port. It’s one thing to know what it physically looks like, what its electrical connections are and how to connect to it, but its another to be able to understand the data that’s flowing through the connector.

The first layer of that puzzle is to know that two of the twelve electrical connections on an OBD port support a standard called CAN bus. CAN stands for Controller Area Network and is used in industrial and automotive systems. It’s called a network because you can have many CAN bus devices connected in a network. In computing terms a “bus” is something that transfers data from one device in the network to another, we often say that a “bus is shared” between the devices. Modern cars can have more than 50 devices in their CAN bus network; controlling everything from the engine, gearbox, infotainment systems, door locks, windows, lights, brakes and everything in between. My 420R 2017 Caterham has only one CAN bus device, the ECU. It seems that other cars (such as Sigma engined cars also have the rev-counter connected to the CAN bus – but not on my Duratec car).

Most modern cars also have multiple CAN busses: private ones, not directly connected to the under-dash OBD port, for the safety critical components and public ones that are connected to the OBD port and more readily accessible to people like us. These private and public CAN busses are often connected together via a CAN bus bridge. There’s no evidence so far that there is any more than one CAN bus on a Caterham, and therefore no bridges.

CAN bus defines both an electrical connection (wiring, what each wire does, voltages, termination impedances etc) but also a transmission protocol… i.e. what sequences of voltage changes mean (how fast are the changes (bitrate), is it digital or analogue, is it serial or parallel communication, etc.).

So the CAN bus standard defines all this with the following key points for Caterham tinkerers:

  • There are two electrical signals making up a single serial data channel. The two signals are differentially coded, meaning you take the two electrical cables as a pair and use the voltage difference between the two to give you a single signal. The two signals are called CAN-L and CAN-H (CAN Low and CAN High). And Soto measure the data in the bus you measure the voltage difference between CAN-L and CAN-H.
  • When there’s no data being transferred on the bus the two data lines, CAN-L and CAN-H sit at about 2.5V. It’s one of the main ways you can find a CAN bus on a car… looks for pairs of wires that have a voltage of about 2.5V on them, there isn’t much other wiring at that voltage on a car.
  • The two CAN-L and CAN-H signals combine to create a single serial data stream – meaning digital bits are transferred one at a time in succession.
  • CANBus can run up to 1Mbps (mega-bits-per-second). On a Caterham the speed is set to 500,000 bps.
  • There are three main types of CAN bus signalling. Standard addressing (using 11 bit identifiers (IDs)), Extended addressing (using 29bit IDs) and CAN-FD (or Flexible Data – sending larger amount of data in one go). Caterham’s use Extended addressing and not FD.
  • A stream of bits being sent on the bus forms a frame.
  • Each frame contains information about:
    • when the frame starts
    • what type of frame it is (standard, extended, error, etc)
    • how much data is in the frame (up to 8 bytes)
    • error checking
    • acknowledgement bits and
    • end bits
  • Data on the CAN bus can be either:
    • Broadcast: a device on the bus continuously sends data at pre-determined intervals. The 9A4 ECU does broadcast some information on the bus (I’ve called this protocol “MBE-Broadcast”) and I’ll talk about this in a future post
    • Request/Response: This is how the OBD-II protocol works and how Easimap communicates with the car. A device that want’s data (Easimap on a computer or a sniffer/scanner) “requests” data from the ECU and the ECU “responds” with the data. We’ll talk about the “OBD-II” and “MBE-ISOTP” protocol in later post.

For those interested, the format of a CAN bus packet is shown in the diagram below. Later on we’ll see that all we’re really interested in is the ID, Extended ID and the Data Field. The rest of the protocol is either handled by the CAN bus chipset or by the low level software (in my case that’s the Linux SocketCAN kernel driver).

Extended 29bit CAN bus packet format. From the Microchip MPC2515 datasheet. 

If that diagram isn’t making sense then perhaps this paragraph is for you: Each of the oblong boxes running across the centre of the diagram represents a single bit transmitted on the CAN bus. Therefore, time runs from left to right, so the leftmost oblong (bit) on the diagram is sent on the CANbus first, followed by the second, etc etc until the last bit represented by the rightmost oblong on the diagram is sent last. All those bits together are a CANbus frame and can contain up to 8 bytes of data on the MBE 9A4 CAN bus.

If you want more info on what all the stuff means in the diagram then I’d recommend heading over to the CANbus wikipedia link, I can’t add much more to what they say there.

There’ll be a post later in this series about me connecting my Logic Analyzer to the CAN bus and hopefully the screenshots there will explain a little more about how data is sent on CAN bus.

Arbitration Fields, CAN bus IDs and Addresses

Having said that, I hope I can clear up one thing that caused me confusion at first. The diagram above and the wikipedia page shows a field called the “Arbitration Field”.

At the physical level (i.e. the 0’s and 1’s on the electrical wires) the arbitration field controls who gets access to the bus. It does this because if two devices start to transmit on the bus at the same time then the one with the lowest numeric around bitration field code “wins” and continues to transmit, while the second device with the higher arbitration code backs off and tries again later. However, at a higher level, such as SocketCAN (see below), these arbitration fields are also like addresses, in computer terms, and different devices will listen for different arbitration fields which are known as ID’s (identifiers).

And for even higher software levels such as ISOTP (see a future post) they are also known as transmit and receive addresses. 

That’s all a little confusing, but all you really need to know is that Arbitration Fields, CAN bus ID’s and the ISOTP Receive and Transmit Addresses are all the same thing.

CAN bus Software

We’ll be talking some more about the CAN bus software in a future post but for the moment it’s worth pointing out that there seem to be a few ways of accessing CAN bus data for writing your own code on a computer.

I’m mainly interested in using Python as a programming language to do my tinkering and in my opinion the only way to do that is with a Unix derived system. And that means either Linux (RedHat, Ubuntu and their derivatives) or MacOS (BSD based).

… and for those operating systems and for Python there are a couple of ways of poking at the CAN bus.

  1. SocketCAN: this is the way I went. For me it gives closer access to the bus and allows me to use packet capture software like Wireshark. The CAN bus drivers are included in modern kernels and there is good support for other kernel mode protocols like ISOTP that we’ll need later. The CAN bus kernel module creates an interface that makes the CAN bus look like a network socket and so turns CAN bus frames into packets like an IP packet. These packets are then available to software applications like Wireshark so they can be captured and viewed. Python has a good wrapper for SocketCAN which is simply called python-can.
  2. ELM327: Another way to get CAN bus frames into a computer is to use a ELM327, or similar, device. They can connect to phones and computers using Bluetooth or Wifi and have python support through the python-OBD project. They’re good because they mean your computer can be remote from the car. But I’m not a big fan of Wireless for critical connections and I’m hoping that my future OBD dashboard will be critical. They also have to work in “user space” (i.e. not in the kernel) and so can suffer from Linux’s susceptibility to not being as “real time” as some other OSes.

Yet another route for accessing CAN bus is through even smaller computing devices. I’ve spent a lot of time playing with the Arduino and Adafruit Feather devices over the years and I’m thinking that at some point I might switch from the Linux environment to Arduino for this project. These Arduino derivatives have their own programming environment and software drivers for things like CAN bus and they are also more “real time” than OSes like Linux and especially Windows. There are CANbus “shields” for Arduino and even Feather CANbus boards for the Adafruit feather line. But for the moment, Linux is a great way to figure out what’s going on with the car and to get rapid development done.

Example CAN packets

We’ll get into discussing the protocols used on a CAN bus in much more detail in furture posts, but for the moment here’s what three CAN bus frames look like to and from the car. The first two packets in the diagram below are to the car from Easimap and the third is the car’s response back to Easimap. The frames below are how Wireshark (a packet sniffer software tool) displays the frames once captured from the CAN bus, it takes the serial stream of bits and decodes them into what each bit means, displaying them in a more “human readable” form…

Frame 626:
Controller Area Network
...0 1100 1011 1110 0001 0001 0000 0001 = Identifier: 0x0cbe1101
1... .... .... .... .... .... .... .... = Extended Flag: True
.0.. .... .... .... .... .... .... .... = Rem. Tx Req. Flag: False
..0. .... .... .... .... .... .... .... = Error Flag: False
Data: 10 0a 01 00 00 00 00 12

Frame 627:
Controller Area Network
...0 1100 1011 1110 0001 0001 0000 0001 = Identifier: 0x0cbe1101
1... .... .... .... .... .... .... .... = Extended Flag: True
.0.. .... .... .... .... .... .... .... = Rem. Tx Req. Flag: False
..0. .... .... .... .... .... .... .... = Error Flag: False
Data: 21 66 67 a8 a9 00 00 12

Frame 628:
Controller Area Network
...0 1100 1011 1110 0000 0001 0001 0001 = Identifier: 0x0cbe0111
1... .... .... .... .... .... .... .... = Extended Flag: True
.0.. .... .... .... .... .... .... .... = Rem. Tx Req. Flag: False
..0. .... .... .... .... .... .... .... = Error Flag: False
Data: 05 81 aa aa 16 00 12 66

CANbus packets will be printed differently depending on which software you use to look at them. In this particular example from Wireshark:

  • 0x0cbe1101 and 0x0cbe0111 are CAN bus identifiers (ID’s) or Arbitration fields written in hexadecimal (the 0x means hexadecimal). From the discussion above about arbitration, the device sending the ID of 0x0cbe0111 would take priority over the device sending 0x0cbe1101, because 0xcbe0111 is less than 0x0cbe1101 . The first two frames with an ID of 0x0cbe1101 are sent from Easimap and the last frame with an ID of 0x0cbe0111 is the response from the car’s ECU back to Easimap
  • There are various flags shown, extended flag (meaning 29bit IDs), Remote Transmission Request Flag and the error flag.
  • The hexadecimal numbers on the Data line are the data, ie the stuff we’re really going to be interested in like engine speed and fuel mixture. 

Well that’s about it for the basics of ECU’s, OBD and CAN bus. We’ll build on all of this in future posts.

ECU Diagnostics – part 1 : Introduction

I’d been planning to have a look at the car’s On Board Diagnostic (OBD) port for over a year, but hadn’t really got into the project. I’d bought the required cables and some test equipment, but other stuff always seemed to be higher priority. That was all about to change with a post from Mark (CtrMint) on‘s Blatchat.

The thinking behind my project was to create a “device” that could plug into the diagnostic port on my car and provide a readout of what the car was thinking… perhaps that might turn into a simple project like change-lights or a race-computer – but a bit more high-tech than a few LEDs on a black box.

So that was my motivation, a home brew race-computer come dashboard come change-lights.

But back to Blatchat… Mark had asked for help looking into ECU Diagnostics and had started a long thread on what he thought was going on (here’s the thread link for club members). Seeing as it was something on my list too I thought I’d pitch in. I hadn’t appreciated how much I’d get sucked into the project, but now, about a month later and many, many hours of work I think I know enough to provide a few posts on the subject.

By the way, I know I’ve plugged Mark’s website before but he does a great job of blogging his Caterham life.

In all though, I think this is going to be a bit more than a few posts… we’ve been busy. It’ll be more like 15+ posts I think.

There’s a lot to talk about and I want to break it down so others can dip into the subjects and not have to plough through one monstrously long post. Some readers will want to get into all the nitty gritty and others will just want to browse. I’ll try and summarise things at the end for people who just want the conclusion.

We’ll be getting into the details of the protocols being used by the ECU, how we decoded those protocols, what we learnt, what software we used, and what software we had to change and/or write, and what we’re hoping to achieve with what we’ve learnt.

My intention with these posts is not to repeat what you can find in other places on the internet about car diagnostics. This is meant to be about diagnostics on a Caterham and where appropriate to point you at other resources to find out more detail, or even the basics. Hopefully it will pull a lot of things together to show what we did, how we did it and what it means for people wanting to find out more about Caterham ECU diagnostics. I hope that makes sense.

I’ve written the posts to be read by someone who is technically minded (aren’t all Caterham owners? 🙂 ) but who may not be steeped in internet knowledge. Hopefully those of you that are internet nerds won’t mind the extra words and can also find what you need without despairing at my efforts to keep everyone up to speed.


So here we go for a marathon series of posts. I’ll update this page with links to the completed posts as they come along…

  1. Introduction
  2. ECUs, OBD and CAN
  3. Test Setup
  4. Wireshark Patching and OBD-II Results
  5. The Correlator Dead-End
  6. Reading Material
  7. ECU Maps and Mapping
  8. Easimap uses ISTOP (sort of)
  9. The Easimap Protocol Theory
  10. Decoding EC2 Files
  11. Logic Analyzer on a CAN bus
  12. OSI 7 Layers for Caterham Diagnostics
  13. Three Diagnostic Protocols in the MBE 9A4 ECU
    1. Protocol 1 – MBE-Broadcast
    2. Protocol 2 – OBD-II
    3. Protocol 3 – MBE-ISOTP
  14. Software Framework
  15. How To: Raspberry Pi and Software Setup
  16. Where Next