Hacking the Can Bus

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.

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 :)

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.

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:-
http://www.loopybunny.co.uk/CarPC/k_can.html

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.
http://www.loopybunny.co.uk/temp/Kcan.zip


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.

Quote:

---

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.

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.

Sam

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....

Ryan

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:
http://www.mp3car.com/worklogs/14726...-software.html

The guy wrote some example code on his website (http://www.harshbutfair.org/software/canboard.html) 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:

Code:

---

/* 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);
  }
  else
  {
    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)
    {
      processMessage(buffer);
    }
    else
    {
      printf("Received %d bytes, expected 64.\n", numBytes);
    }
  }
  else
  {
    fprintf(stderr, "Error receiving message.\n");

---

He describes the message format like this:

Quote:

---

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. banghead

Can anyone help me a little here?