Discover hidden functions in your car (using CAN bus sniffing)
All modern vehicles today is controlled by multiple Electronic Control Units (ECU), which you can think of as small computers controlling all electrical components in your car. Using the OBD-II port and an AutoPi it is possible to communicate with the ECUs.
One of the ECU’s is called the Engine Control Module (ECM). This is responsible for communication with a lot of subsystems, like transmission, power steering, windows and doors. These subsystems communicates on a network bus called Controller Area Network (CAN), by broadcasting messages on the bus. A message could look like this:
The ‘024’ is the sender ID of the message, and the rest is the data containing the actual data. For example it could be a message containing instruction to roll down a window. With access to the CAN bus through the AutoPi, it is possible to send commands to your vehicle, and thereby inject commands on the CAN bus. The only problem is that individual commands to control specific parts of your vehicle, is not easily available.
A common method to identify commands is to listen/record the data flow on the bus, manually perform the action in your car you want to identify (like rolling down a window) and then identify the command on the recorded data stream. This is commonly known as CAN sniffing and is normally a very advanced way to discover hidden metrics in your car. But with AutoPi this has been reduced to only a few steps, that you need to run from the AutoPi Cloud and everyone can expand the possibilities of their car. The steps are:
- From the AutoPi Cloud, start CAN monitoring
- In your car, perform the action you want to record 5 times or more
- Let AutoPi Cloud analyze the recorded data in order to identify your action
- Name and save the action in the AutoPi library for everyone to use in the future
CAN sniffing explained
Monitoring the CAN bus is complicated, because so much data flows in modern cars. So identifying individual messages from the stream of data is difficult.
A common way of identifying a specific message is called “divide and conquer”. The idea came from a classic computer algorithm, of same name, used in many aspect (like sorting). Easily explained, you know that the message you are looking for can be compared to finding a needle in a haystack. With the divide and conquer algorithm, you divide the haystack in two equal parts and look through half the haystack for the needle. If you don’t find the needle, you break up the remaining half in two new stacks, and looking in one of these. You continue this process until you find the needle.
You can apply this to finding CAN messages as well. Let's say you want to discover the command for controlling the power windows, then the steps involved are:
- Record messages flowing while pressing the window switch in the car.
- Divide the recorded messages into two halfs.
- Replay/send all data from one part to the car’s CAN bus. If the window rolls down you have the right part.
- Keep doing this procedure until you have identified the exact message you are looking for.
Once you identified the specific command, you need to replay/send it to make sure you have the right one.
All of this sounds very complicated (which it can be), but with AutoPi all of this has been automated in a simple tool you can access from the AutoPi Cloud.
Using AutoPi to discover new commands in my car
With the AutoPi Cloud, the tedious process of finding CAN commands for your vehicle has been automated in a simple user interface.
Above image shows the user interface used to discover new CAN commands. The steps are very simple. You need to physically be in your car to do the discovery:
- Open the CAN explorer. It will tell you if there is connection to the car
- Press the record button
- Now perform the function you want to record 5 times. Like pressing the “left front window” switch
- Press the stop record button
Using discovered CAN commands to build something cool
So what can you do with your new CAN command? Why not use it to tie up a cool speech command to your car.
The AutoPi Cloud comes built in with an If-This-Then-That trigger system. Using this system you can add your own triggers and trigger the new found CAN command.
The image above shows the interface for adding new triggers to the system. Adding a new trigger is very simple.
- Select your input source. This is the beacon. As an example select the “googleAssistantSpeech” source
- Add a critearia, this is the text spoken. We will add “Roll down left front window”
- Now you add your output source. this is the reactor. We select the “carIntegrator” and from the dropdown menu, we find our new command “left front window down” and select this
- Press save
Other blog posts for further reading
Speak to your car with Google Assistant - almost like K.I.T.T. from Knight Rider
Wouldn’t it be cool if you could speak to your car and give it commands? We remember our childhood in the last millennium where Michael Knight (David Hasselhoff) and his intelligent Pontiac Trans Am named K.I.T.T. solved crime together. While we may not be able to have a meaningful conversation with our car just yet, it’s now a possibility to talk to your car and give it commands to execute. We are here giving a short introduction to how this can be accomplished using the AutoPi.io system and Google Assistant.
How-to build a Raspberry Pi touch screen car computer
Integrated car computers are not only for expensive cars like the Tesla Model X nor is it only for complex car DIY projects that require you to have a degree in engineering. Not many people know how easy it is; by combining a few components it is possible to make it for any car. Follow this guide to see how it can be done.
Switching from Raspberry Compute to Raspberry Zero
During the design phase of the AutoPi, it was decided to use the Raspberry Compute Module. The Raspberry Compute Module is small, versatile and expandable in a lot of ways, which suited the AutoPi project perfect. All the pinouts from the Broadcom BCM2835 processor is available through the SODIMM DDR2 interface on the Compute Module. This gave us a lot of possibilities during the design phase of the AutoPi and therefore the Compute module was an obvious choice for us as a main processor.