Close
0%
0%

Switching music with CAN bus

Summary of my struggles with automotive CAN bus sniffing and Bluetooth LE powered microcontrollers (nRF51)

Similar projects worth following
The goal of this project is to design a device which behaves like bluetooth keyboard to switch music on my phone, based on messages received from Chevy Volt's CAN-bus.

Since my Chevy Volt comes with Bluetooth only for hands free calling I have to use third-party transmitter and AUX input for music. Unfortunately steering wheel controls are not working with AUX input, so I figured a workaround. 

I could sniff for packets sent on CAN bus when button on steering wheel is pressed, and then command my phone to change song by emulating keyboard press of media buttons. Bluetooth LE supports HID devices like keyboards natively, so all I have to do is build a Bluetooth LE keyboard which is controlled not by buttons, but with CAN-bus messages.

While idea is pretty simple, execution involves a lot of knowledge and work. I'm trying to describe all my struggles down below in project logs, so feel free to take a look and maybe learn something new along with me. As a fan of open-source ideology, I publish my work on GitHub - all feedback much appreciated.

  • Episode Three: Working prototype

    Wiktor Burdecki04/04/2021 at 12:22 0 comments

    Due to some free time during holidays I managed to get my hands dirty again in this project.

    Pile of jumper wires and free hanging PCBs grew ever more since last time.

    Because of a lot of stupid mistakes and copy-pasted code, writing MCP2515 driver was a real pain in the ass. Since functionality I need from the chip is not much extensive, I developed my own minimalistic solution heavily inspired by open-usb-can project and arduino library for MCP2515. 

    Overall I'm only initializing the chip, masks and filters, and one receive buffer(for now I guess). At last I started receiving some valid CAN frames in my logs.

    First time a song switched was pretty magical. Also I figured I might have overengineered a simple task of changing a song on my PC :D 

    Code already got published to my GitHub, all I have to do now is design a proper PCB and give the software more polish. Maybe in not much time I could finally enjoy music while driving without distracting myself while driving. 

    See ya later and hope Episode 4 will be the last. Also I'm dedicating this episode to Gabe Newell, you know we want it! :P

  • Episode Two: Hardware

    Wiktor Burdecki02/04/2021 at 12:44 0 comments

    Since Raspberry Pi is capable of doing all the things like Bluetooth LE and CANBUS, i consider it too easy in execution and too overkill hardware-wise. This project is intended to be a simple, minimalistic device so highly embedded microcontroller with most needed functions and peripherals on-board is needed. 

    First promising candidate was ESP32 from Espressif, since it has embedded BLE and SJA1000 CAN controller. Problem is, due to hardware limitations involving clock distribution inside the chip, CAN controller can't run slower than 50kbaud. Second problem for me, is that ESP32 is intended to be used more like a module than a chip. This means easier development, but less flexibility when designing a final product.

    Since I haven't found any more BLE+CANbus microcontrollers, my attention was drawn more towards BLE enabled ARM microcontrollers. After some research I established that the best way to get started was Nordic Semi NRF5 family. Chips are already for some time on the market, there are a lot of resources available, and Nordic distributes them with free and very extensive SDK (software development kit) and documentation. Price is maybe not the lowest but still attractive, especially for older NRF51xxx family. To simplify my development stage I bought a simple breakout board with NRF51822.

    I already set up my firmware development toolchain with GCC (GNU C Cross-Compiler for ARM). Starting this way was a very steep learning curve, but payed off in a lot of gained knowledge, especially about the low-level working of microcontrollers (reset/interrupt vectors, linker scripts, startup). My final setup was Ecplise for C/C++ with Eclipse Embedded CDT plugin. My flash/debug probe was at first a J-Link device, but later I managed to get cheap ST-Link V2 working with help of OpenOCD software. To set up Eclipse IDE, this tutorial is a bit outdated but still helpful. After having a working toolchain I created a first warm-up project to get started with development for this microcontroller. After a lot of included headers from SDK, and learning from examples provided in it, I managed to get my first non-BLE application running - simple UART command line interface running on top of FreeRTOS

    Since NRF51 doesn't come with embedded CAN controller i need an external solution to communicate with vehicle. This time choice was simple - the most popular MCP2515 which I also used earlier with RPi to sniff SWCAN bus on my car. It's a pretty simple and robust chip, also comes with hardware CAN frame filtering, which in my case reduces CAN data processing by MCU to nearly zero since receiving data frame means a change of steering wheel button state - all other data from CANbus is discarded earlier by MCP2515 hardware filter.

    After familiarizing with BLE inner workings, and Nordic's SoftDevice software, I already got a working BLE keyboard example running with modified report descriptor to be used as Consumer/Multimedia HID (Human Interface Device). Software wise only thing left is writing C library to support MCP2515 on NRF51 platform, which I'm in the middle of.

    I'll keep you posted ;)

  • Episode One: Vehicle CAN Bus analyzing

    Wiktor Burdecki01/14/2021 at 18:40 0 comments

    Chevy Volt is a very complicated car, also when it comes to it's communication buses. It is equipped with 2 obd2 ports on driver and passenger side. Those ports expose various CAN and SWCAN buses, more about them here.

    Mine primary focus is on a low-speed SWCAN bus on pin 1. It is not like a classic CAN bus, because signal is carried on one wire, with signal levels relative to chassis ground. But fortunately standard CAN hardware like transcievers can be interfaced with it. To make it work all grounds have to be connected together, and also CAN LOW termninal has to be connected to ground. CAN HIGH connects to SWCAN (pin 1 in OBD2 connector). More on GMLAN/SWCAN here

    To make it all work I have to determine what data gets transmitted on the bus when I press a button on the steering wheel. To do it I made an analyzer from a cheap MCP2515 CAN-SPI module and Raspberry pi. CAN module needed a little modification to work with 3,3V from Pi. With a help of a driver, we can get CAN bus in linux, visible as a native network interface with a help of SocketCAN support in current linux kernel. To analyze captured data we can use Wireshark or command line tools from package can-utils. I choose the second way, but I warn everybody that it's harder to configure, since you have to compile can-utils from source. apt-get on raspberry pi downloads very old version of package, which does not have support for 29-bit CAN IDs. Clone git repository, and This link might help with compilation and installation process. Beware, also a libtool package is needed to execute scripts succesfully)

    With working and newest version of can-utils I can start sniffing. I enabled interface can0 with command 

    sudo ip link set can0 up type can bitrate 33300
    

    and then used cansniffer application from can-utils package

    cansniffer can0 -c

    I use my raspberry pi without a screen, so all was done via ssh. At first a huge list of CAN IDs transmitting data showed up. But to minimize amount of data transmitted on the CAN bus, I turned vehicle off, opened the drivers door and waited a while for all modules to go to sleep. Then I turned on the radio with a button on dashboard. Big amount of data showed up in cansniffer, but because it disappears after a moment of inactivity (data not changing for given ID), a list cleared itself to a few rows after a moment. After a few clicks on steering wheel I got CAN ID i was searching for.

    ID 10438040(hex) is transmitting one byte of data on every steering wheel multimedia button event. Event type is determined by this byte's value:

    00-button released

    01-vol up pressed

    02-voldown pressed

    03-next track pressed

    04-previous track pressed

    05-audio source pressed

    06-voice/answer pressed

    07-mute pressed

    Criuse control buttons seem to be on another CAN bus, or need car to be turned on - i haven't seen any chages when pressing them in cansniffer.

    My intent is to use 03, and 04 messages, since rest of them still triggers actions in stock radio/infotainment (on AUX prev/next track does nothing). Next step is to make an embedded sniffer with some microcontroller to sniff data only from 0x10438040 CAN ID. 

    See ya till next update on project! :)

View all 3 project logs

Enjoy this project?

Share

Discussions

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates