Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 46

Thread: Hacking the Can Bus

  1. #21
    Constant Bitrate
    Join Date
    Jul 2009
    Hi rtgree01 that sounds great. I'm still learning how to program effectively for the Arduino but i'm learning a great deal from the books I have. My current setup uses an Arduino Duemilanove but I also have a Teensy++ 2 and Arduino Due. The due is what I'm really working on now, like the Mbed it has 2 Can Bus connections on the board so all you need is a transceiver and you're good to go. I believe it has the same processor as the Mbed, plus it has plenty of I/O's which I have a use for as well.

    My current FE is Centrafuse but it seems like a good deal of Can Bus development is happening on the RR side. I may setup a test environment and see what I can do with RR, it may be in my best interest especially with all the work that people like yourself have done with it already.

  2. #22
    Constant Bitrate Goddy's Avatar
    Join Date
    Dec 2004
    Anyone with some progress? I didn't had any progress. Trying to pick it up again. Soldered all pins on the canbus board so I can hook it up to the arduino. Now need to find the can hi and low wires in the car so I can hook those up to the arduino and start sniffing

  3. #23
    Constant Bitrate
    Join Date
    Jul 2009
    No progress here yet but I will be starting up soon as the weather is warming up. I was debating on going another route and replacing the carpc with a nexus 7 but decided against it. The next step is to design my board to hold the canbus transceivers and connect everything to my arduino due, this setup will replace my current arduino and canbus shield.

  4. #24
    Low Bitrate
    Join Date
    Oct 2008
    Wiltshire, UK
    My BMW experiments and reverse engineering are going well. The board that I made (see post #15) is still running well.
    I have decoded quite a few more of the BMW Can ID's as well as starting to understand how the BMW coding process works.

    The list of BMW Can ID's I have decoded can be found here:-

    I have updated the Arduino Uno Canbus libraries that I am using with the ability to write to the Canbus. There are two libraries depending on what version of Arduino IDE you are using, copy the Canbus directory into the libraries directory in your Arduino environment. In the zip file is a basic .pde showing the format for writing.

    I have now added a cheap RN42 Bluetooth module to my Arduino to wirelessly stream data from the Canbus to a tablet PC / smartphone. I can already receive the data-stream on my Symbian phone (but who uses Symbian now-days?) so I'm currently in the process of writing an Android app. It's just a matter of time to make it all look pretty. To be fair there are lots and lots of OBD apps available for the phones / Tablets but they don't contain anywhere near as much data as I can now extract from the BMW Canbus.

    Now need to find the can hi and low wires in the car so I can hook those up to the arduino and start sniffing
    CanBus wires are generally a twisted pair. Looking at the back of the Radio, PDC, Lighting control or AC unit you should be able to identify them quite easilly as they are tightly twisted together.

  5. #25
    Join Date
    Apr 2013
    Bothell, WA
    Ryan.. I'd be interested in your schematic, BOM and code... I have a charger SRT8, and am planning the use of mBed LPC1768 (s) with a Cubieboard for data logging the CAN buses in the Charger, to sniff all the data crossing the network and logging up to a cloud-based system on an ongoing basis (for later use, decode, etc)... the other use is a sort of rsync of a music collection to a drive on the Cubieboard and using the USB OTG to expose to my headunit (Kenwood KDC-X996) as a USB mass storage device using the Gadget API.

    If you could post or email your stuff thus far with your charger, especially with the mBed controller, schematic and where you connected to the CAN buses in the Charger, it would help me along quite a bit. Your decoding utility sounds very interesting too... I'd be interested in that! (I'm a network engineer... wireshark protocol analysis is basically what I want to do on the CAN messages)..

    I'll certainly make my sharing bidirectional... I'd like to see a sort of community of open ECU tuning develop in the long term, where people can provide access to their car's historical telemetry data to someone to look at for developing a tune.. Sort of like Skydrive sharing for their telemetry data.


  6. #26
    Low Bitrate rtgree01's Avatar
    Join Date
    Aug 2007
    So... guys.... here it is....

    The code is here.
    The Eagle (linky schematic and board layout and bill of materials are in the attached file.

    I am currently working on a new design that should be easier to use.... but I haven't had it built yet...

    There are a bunch of places to splice into the "interior" can bus. That is the bus that the radio, steering wheel controls, and satellite radio (among others) are all on.... You can splice in at the radio, or in the trunk where the satellite radio is. For more info, PM me. I also hooked up to the CAN bus in the obdii port and did some very limited work with that. I don't know if that is the can-c bus or not though....

    I haven't gotten into tuning the ECU, but I'm all for a community of open data....

    Attached Files Attached Files

  7. #27
    Newbie MZ3Alex's Avatar
    Join Date
    Dec 2012
    Has anyone tried working with the Microchip MCP2515 CAN-BUS demo board in Linux? I'm currently trying to communicate with the red LCD screen that is part of the mazda3 head unit as this guy did here:

    The guy wrote some example code on his website ( but I am having trouble understanding how this code works (well really with the format of the CAN-BUS messages actually). He seems to be passing a 64-byte array to the demo-board but I don't totally understand his wording for the format of the array. The part of the code that sets up the array looks like this:
    /* We can now send and receive messages. For example, set normal mode. */
      memset(buffer, 0, 64);
      buffer[58] = 0;      /* CANCTRL = Normal mode. */
      buffer[60] = 0x02;   /* SPI command = Write.   */
      buffer[61] = 0x0f;   /* Register = CANCTRL     */
      buffer[62] = 0;      /* Data = 0 (normal mode) */
      /* Send the message to endpoint 1 with a 100ms timeout. */
      res = libusb_interrupt_transfer(handle, 1, buffer, 64, &numBytes, 100);
      if (res == 0)
        printf("%d bytes transmitted successfully.\n", numBytes);
        fprintf(stderr, "Error sending message to device.\n");
      /* Listen for a message. Note that for a normal application you'll need 
       * to use asynchronous mode because we can't predict when messages will be
       * available. This involves setting up a callback function to handle incoming
       * messages - refer to libusb documentation. */
      /* Wait up to 5 seconds for a message to arrive on endpoint 0x81. */
      res = libusb_interrupt_transfer(handle, 0x81, buffer, 64, &numBytes, 5000);
      if (0 == res)
        if (numBytes == 64)
          printf("Received %d bytes, expected 64.\n", numBytes);
        fprintf(stderr, "Error receiving message.\n");
    He describes the message format like this:
    The format of the 64 byte buffers is pretty simple, and can be determined without much difficulty by looking at the firmware source code. The important fields are:

    Bytes 0..51: CAN messages (see below for details). [IN/OUT]
    Byte 52: Number of CAN messages to send. I have only tried sending a single message at a time. [OUT]
    Byte 55: Transmit Error Counter. [IN]
    Byte 56: Receive Error Counter. [IN]
    Byte 57: CANSTAT register - see datasheet for details. [IN]
    Byte 58: CANCTRL register - see datasheet for details. [OUT]
    Byte 60: SPI command. For incoming messages, this echos back the command that was sent. Commands are 0xC0 (CAN reset), 0x03 (read register), 0x02 (write register), 0
    x80 (RTS - ?), 0xB0 (RD Status - ?) and 0xD0 (Read Firmware Version). [IN/OUT]
    Byte 61: Register. Set to the register to read or write. The response to a read request contains the same value. [IN/OUT]
    Byte 62: Data. The value to be written to a register for outgoing messages, or retrieved from a register for incoming messages. [IN/OUT]

    CAN message format

    Byte 0: Most significant bit (bit 7) indicates the presence of a CAN message. Bit 5 indicates an extended (29 bit) identifier. Bit 4 indicates a remote transmission request (RTR). Bits 0-3 contain the data length.
    [Standard ID] Bytes 1-2: Byte 1 and bits 5-7 of byte 2 contain the identifier, big endian.
    [Extended ID] Bytes 1-4: From most significant to least significant, the message ID is in byte 1, byte 2 (bits 5-7), byte 2 (bits 0-1), byte 3, and byte 4.
    Next [len] bytes: If this is not an RTR message, the content of the message follows (up to 8 bytes).
    Can anyone help me out as to how sending a message works? I'm not totally sure how to input the CAN-BUS message address even because how do you fit 0x290 (the address for the mazda screen), in 3 bits? 0x290 in binary is 001010010000. How does that fie in 3 bits? Or should I be using extended ID? I'm so confused here.

    Can anyone help me a little here?

  8. #28
    Join Date
    Aug 2013
    i always repaired the CAN BUS of Benz e300 2011, with the scan tool

  9. #29
    Join Date
    Apr 2013
    Bothell, WA
    I found mbed and Arduino too low level and lacking in processing capability (using interrupts properly to read the CAN messages at full bus rate on a busy bus is too much hassle.. i'd rather spend the effort on decoding data)...

    so after much start and stopping, I have started down the road with BeagleBone Black (after first trying out Raspberry Pi (no USB OTG connector) and CubieBoard (too much hassle to get a modern Linux kernel running)

    The BeagleBone Black has fairly significant processing capability over mbed and Arduino.. specs here:
    some major highlights and factors driving my decision:
    - 1 Ghz ARM Cortex A8 processor
    - 512 MB DRAM
    - large storage available (MMC supports 32 GB+ SD cards)
    - on-board ethernet, USB
    - off-the-shelf CANBUS hardware available with multiple CAN transceivers (2 different vendors of CANBUS boards ("capes") with transceivers)
    - high-level languages for development (python, perl, ruby, tcl, etc) and wide array of tools available (all of GNU/LINUX)
    - relatively low cost - $45/BeagleBone Black + $60 for a multi-channel CAN Cape, comparable to mbed and Arduino, with significantly more memory and processing capability

    I have drafted a quick writeup of the beginning of my system to collect CANBUS data here:

    - Sam

  10. #30
    MySQL Error scott_fx's Avatar
    Join Date
    Dec 2004
    Los Angeles Ca
    this is very interesting. can i use can-bus to control the gauge dial stepper motors? For instance, say i want to install the toureg cluster into a classic car.
    also, is the 'toureg' screen customizable via can bus?
    my only requirement is that it must be an arduino based system... as that's all i know how to code for :\
    New System in progress:
    Phaze TD1500 ~> Dynaudio MD130
    Phaze TD1500 ~> Seas g18rnx/p
    Zapco Ref 500.1 ~ 12" tc-9
    Behringer DCX2496 ~ Envision Electronics psu
    Transflective Xenarc

    My Car Pc Install
    My Boat Pc worklog

Page 3 of 5 FirstFirst 12345 LastLast

Similar Threads

  1. hacking a printer's LCD
    By natedawgg in forum LCD/Display
    Replies: 3
    Last Post: 03-19-2009, 03:48 PM
  2. Hacking Iguidance
    By Peoples in forum GPS
    Replies: 74
    Last Post: 08-28-2005, 07:40 PM
  3. Hacking Irman
    By Cheekz185 in forum Input Devices
    Replies: 3
    Last Post: 07-13-2005, 01:18 PM
  4. no TS, no hacking, which to buy?
    By DaddyZ in forum LCD/Display
    Replies: 5
    Last Post: 12-09-2004, 11:55 AM
  5. Frodo: 1.0.9 Hacking.
    By hevnsnt in forum FrodoPlayer
    Replies: 7
    Last Post: 10-17-2004, 06:54 PM


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts