Posts made by jpsimos
posted in General Discussion read more

In your case, enabling MCP2515 buffer rollover could solve the issue.
If rollover is already enabled, see the bottom of this post.
Line 5 is where buffer rollover is enabled in this code.

1] CANBus1.begin();
2] CANBus1.setClkPre(1);
3] CANBus1.baudConfig(500); // <-- this might be different for you
4] CANBus1.setRxInt(true);
5] CANBus1.bitModify(RXB0CTRL, 0x04, 0x04); // Set buffer rollover enabled
6] CANBus1.bitModify(CNF2, 0x20, 0x20); // Enable wake-up filter
7] CANBus1.setMode(NORMAL);

Do the same thing on bus 2 and 3 if you use them.

If rollover is already enabled, the bus you are trying to capture might be CAN 2.0b (29-bit extended frames). If you are using the stock firmware, you need to add support for 29-bit mode. Also, make sure the baud rate is correct for the bus.

posted in Firmware read more

If the blue LED appears for a second when you boot the device, it is functioning OK. If not, you might have to program it with a CC debugger the first time, then use USB after that. If you plan on frequently changing / developing the BLE firmware, I suggest buying a debugger. One time, I accidentally flashed some firmware that did not let me enter DFU mode. Also, you should consult the Bluegiga development forms.

posted in Firmware read more

If you guys are familiar with the BLE firmware, you might have noticed that packets are often enough corrupted on the receiving end (Android, iOS, etc). To combat this issue, one can implement a simple one byte checksum into the transmission so the receiving end can generate the same checksum and compare it with the checksum byte received from the CBT.

For example: on the CBT

byte checksum(byte *payload, const byte length){
	byte chk;
	for(byte i = 0; i < length; i++){
	   chk += payload[i];    //value wraps around once it reaches > 255
	return ~chk;

byte bluetoothOut[5];
bluetoothOut[0] = speedMPH;
bluetoothOut[1] = (byte)engineRPM << 8;
bluetoothOut[2] = (byte)engineRPM;
bluetoothOut[3] = (byte)throttlePosition;
bluetoothOut[4] = checksum(bluetoothOut, 4); //5th byte is checksum for bytes 1-4

And for android:

private boolean validCheck(final byte[] bluetooth_rx_data){
    int checksum = 0;
    int cmp = (bluetooth_rx_data[bluetooth_rx_data.length - 1] & 0xFF);
    for(int i = 0; i <bluetooth_rx_data.length - 1; i++){
        int value = (bluetooth_rx_data[i] & 0xFF);
        checksum += value;
    checksum = ~checksum & 0xFF;
    return (checksum == cmp);
posted in Howto read more

Some vehicles come with convenience buttons on the steering wheel that control some functions on the radio like volume, seek, mute, etc.

Not all vehicles come with these buttons but my findings conclude that the radio's firmware accept the commands even if the buttons are not present. On vehicles equipped with the buttons, when presssed the small computer inside the button housing generate and send commands over the GMLAN CAN bus and the radio interprets them.

My vehicle does NOT have the radio buttons, only cruise control buttons.

To demonstrate this, I wrote a little Android app that communicates with my Can Bus Triple that emulates these commands respectively.

For added coolness, I made the Can Bus Triple send the radio's display contents to the app :)

posted in Hardware and Wiring read more

This forum is for the CanBus Triple. You should ground the CAN_L to the ground on the OBD port.

posted in Hardware and Wiring read more

I found a bug in the 29-bit firmware that causes the ID of the message to become corrupt when receiving serial command. I fixed that, now I can do lots of fun stuff.

the CBT rules!

posted in Firmware read more

The CBT desktop software does not support 29-bit messages. If you are a programmer, you can code your own application that connects to the serial port and receives the data and handles it properly. If not, simply use CoolTerm to log the data into a text file then parse it in Excel or something.

posted in Firmware read more

I was able to modify the sleep functionality to fit my implementation with 100% success.

As Derek mentioned above, using a heartbeat message to trigger the wakeup interrupt is needed so the device can wake up properly. I was able to find the ID that broadcasts the vehicle's VIN every one second when the key is in the ignition; it works! I believe in sleep mode the device only uses about one mA (or less). When the device wakes up, all RAM and variables are retained since the sleep assuming the power was not cut.

posted in Hardware and Wiring read more

make sure you are sending raw HEX data to the serial port, not ASCII.

If you send 01 using ascii the CBT will receive (in decimal) 41 42

posted in Hardware and Wiring read more

It seems like you are trying to make a workbench canbus.

First thing is first, there must be ~120 ohms total on the bus, that means 60 ohm termination resistors at each end of the bus, otherwise the controllers will have huge problems sending & receiving data.

Second thing, make sure that all nodes on the bus are operating at the same baud rate. This baud rate is NOT the baud rate of the CBT's serial port, that is for RS232 only.

Third thing, make sure you have your pins connected correctly, here is some reference:

by the way, there won't be any data on your workbench bus unless a node is sending

posted in Hardware and Wiring read more

If you accidentally short the +12v and GND pins the switch that controls the power source will break and the only way to power the device will be USB.

posted in Howto read more

The best way to take control of things is to purchase a Tech II scan tool and an OBD-II Y-splitter so you can have both the Tech II and your CBT on the bus. Simply execute controls using the Tech II tool while your CBT is logging the traffic.

But How??

Every ECU has its own Diagnostic ID for requests and another ID that it will reply to when a request is made.

Find the ID that the scan tool opens a diagnostic session with then find the ID where the ECU sends responses to.

In my opinion, this method is the best for controlling on-board systems because the diagnostic protocol is there for that exact reason

Also, having your CBT rigged up to all available busses increases the probability of controlling all available systems on the vehicle.

It should be noted that on some vehicles / manufactures implement certain limits on diagnostic functions to prevent (some, not all) unsafe conditions.

posted in Hardware and Wiring read more

The CBT is really just a cleanly implemented pcb that has 3 x MCP2515 chips and a programmable MCU to make them do stuff. The register flags you are asking about are results from the MCPs normal operation and can be explored in greater detail by reading the MCP2515 datasheet available from Microchip and also peering at the CBT's PCB design.

posted in Hardware and Wiring read more

I made my cable using products from

You are probably looking for the one with all sixteen pins to open so you can solder the wires depending on your configuration. They are like thirteen bucks. Can't go wrong.

posted in Hardware and Wiring read more

I am directly onto my GM 33.33 bus and I can log data quite successfully. I have found a number of packets that do fun things but when I attempt to replay them nothing happens.

What are some possible causes of this. Are there wake-up packets that I need to send first?

For example, the packet for the interior lights is:

0x10042040 Data [02 00 06 00 05 a5 00 00] Length = 6

Replaying this packet does nothing. Firmware issue? Bit rate issue? wtf mate

Looks like your connection to CANBus Triple was lost, please wait while we try to reconnect.