Original code:

jamesatfish

0

jamesatfish

I thought it might be helpful to share an example of how to go from fresh CBT to capturing and actioning steering wheel button pushes.

This example is from a VW Golf Mk5, so the process may not work exactly the same for other cars, but should give newbies some tips to get started.

The process is as follows:

Connect CBT hardware
Log & Process data
Identify packets
Intercept and action

jamesatfish

0

jamesatfish

Connect CBT Hardware

Download the latest CBT firmware from Derek's Github site, build and install onto your CBT.
Identify where you are going to tap into the target CANBus network.

In the VW Golf, the most direct way to grab the steering wheel buttons is to tap the CANBus directly off the steering wheel itself, but that's quite fiddly and splicing the wires there can be quite difficult.

An easier way is to pull out the radio and tap the infotainment bus at the back of the radio, but keep in mind that this will limit your ability to send button commands back onto the CANBus due to the way VW implement the two low-speed busses. You can still capture and parse all the button push data from this point.

Splice CAN High into wire #3 on the ribbon cable provided with your CBT, and CAN Low into wire #4. For the moment you can leave everything else unwired, as you'll get power from the USB connection.
Connect a serial terminal program to your CBT. On the Mac I am using CoolTerm. Configure it to view, log and send HEX data.
Open the 'Send String' feature of CoolTerm and issue the command "011001" (in HEX mode). The CBT should return an English string with an error value - either '0' or 'B' most likely.
If you get the 'B' code, the baud rate setting is wrong. In the VW that's because the low speed busses run at 100kbps but the CBT's default is 125kbps. Use the auto-detect code to set the correct baud rate by entering "010801". Once the serial terminal reports that the correct baud has been found, restart the CBT by cycling the power (disconnecting and reconnecting your USB cable).
Try the "011001" command again. The 'B' error code should have disappeared.

jamesatfish

0

jamesatfish

Log & Process Data

Now that you've got the CBT connected, it's time to start logging data.

Turn the car on - either engine running or engine off but all electronics on. In VWs the steering wheel controls do not work with just ACC power on the ignition.
Enable logging on the CBT by issuing "030101". You'll start to see a torrent of data appear in your serial terminal. How much data depends on how chatty your car is over the CANBus - the VW is quite chatty.
Setup CoolTerm to log the raw hex data to a text file.
Start logging to the text file, then press one of the steering wheel buttons about 10 times in a regular tempo. For example, I press the button every second for 10 seconds.
Stop logging and disconnect the CBT.
Open your log file in a text editor with Find & Replace features. I use BBEdit on the Mac. It should look something like this:

CoolTerm puts in line breaks to tidy up the data but they're in the wrong places. The first step is to remove them altogether, which in BBEdit means finding the newline character '\r' and replacing it with a space ' '. This will give you:

You may notice a repeating '01 0D 03 01' in that sequence. the '03 01' is how the CBT starts a packet dump, and the '01 0D' is how CBT ends the dump. Those values are irrelevant to your data, so I clear them out and replace with a line break character. That is, find '01 0D 03 01' and replace with '\r'. This will give you the raw CAN data with one line per packet.

From this data you can see the protocol emerge. The first 2 bytes are the identifier of the module on the CAN network, the next 7 are the data itself, and the final byte is the length of the packet (i.e. how much of the 7 data bytes are actual valid information).
At this point we need to use something more powerful than a text editor to identify the data, so I open Excel and import the data into a spreadsheet. Use the 'fixed width' import option and you'll end up with 11 columns of data, and one row per packet.
Add a header row at the top and label the rows to make it easier to sort:

Now sort the data by the first 2 columns. This will give you a list of packets sorted by the controller that sent them out.
Scroll down the list and you'll see that some controllers send hundreds of packets, and some controllers send only a few. You know that you only pushed the steering wheel button 10 times, so the controller you're after should have sent only a small number of packets.

Don't just look for 10 packets exactly however - in the VW at least each button push can cause 1, 2 or 3 packets to be sent.

Delete from your data any controllers that have sent more than around 30 packets. You should be left with a small set of controllers to check.

jamesatfish

0

jamesatfish

Identify Packets

Here we use a bit of trial-and-error to figure out what packets are being sent by our steering wheel.

Re-connect the CBT to the serial terminal, start logging to a new file in the terminal program and activate the Bus logging on the CBT using '030101'. The torrent of packets should start again.
Issue the command to filter the CBT packets by looking for a particular controller (Frame ID). Do this by looking at the values in column A & B of your spreadsheet, and issuing the filter command to the CBT with those values. For example, to filter on the first controller in the example data (06 5F) you would send the CBT the command "030101065F".
When that command is processed by the CBT, you'll immediately notice the rate of data in your serial terminal drops away. This is a good thing as it means you're successfully filtering on just one controller.
Whilst watching the data go past (watch the ASCII version of the data rather than the HEX version as it's easier to spot character patterns that way), press your steering wheel button several times. If the data doesn't appear to change, you're likely filtering on the wrong controller. Go back to Step 2, change the Controller (Frame ID) you're filtering against by picking another one from the Excel spreadsheet and try again.
When you find the right controller, you'll notice that the data changes when you push the steering wheel buttons. At this point you can try some of the other buttons on the wheel - you should see the data change again but in a slightly different way than before.

Note that the steering wheel controller in the VW is chatty even when no buttons are being pushed, so there will always be data flowing even if you're not pushing the buttons.

Save your terminal HEX log, and repeat steps 6-8 from the previous post to get each packet into a readable format.
From there the data patterns should be visible without further processing. For example, the VW 'Volume Up' button emerges as follows:

The idle state of the wheel (05 C1) is to send out 1 byte packets with value 0x00. There are 2 packets that jump out in that log where the value is 0x06 instead. By repeating our test it becomes apparent that the full packet

is what is sent out when the Volume Up button is pushed.

jamesatfish

0

jamesatfish

Intercept & Action

Now we want to actually do something with those button pushes, so we need to modify the CBT code to intercept and action those pushes.

The best way to do this is to create your own Middleware and incorporate the code into there, however the quick and easy way is to find the <code>void processMessage( Message msg ){</code> function at the bottom of the CanBusTriple code file.

This function is called every time a full packet arrives on the CANBus. We need to write some code to parse the received packet and match it against the values we identified in the last step. For example, the Volume Up button would be matched by:

<code>if(msg.busId ==1 && msg.frame_id==0x5C1 && msg.frame_data[0]==0x06){</code>

If you're only connected to 1 CANBus at the moment then the msg.busId part is redundant, but it comes in handy when you're grabbing data off multiple busses simultaneously and only want to take action to packets received on 1 particular bus.

Once you've grabbed the packet and identified it's the one you want, you can perform whatever action you like at this point - starting with simply logging in plain text what button was pushed:

<code>Serial.println("Volume Up");</code>

You're done - you have now got your CBT to intercept a button push and perform an action in your custom code.

alan

0

A

alan

i like this approach, i will try it later. thanks

Xag

0

X

Xag

@jamesatfish

Great write up! Thanks!

ichraffsnicht

0

I

ichraffsnicht

nice one!

jamesatfish

0

jamesatfish

No problems at all - hopefully all that is of some help!

henk_kuipers

0

henk_kuipers

In phase "Connect CBT Hardware", I am stuck at step 3. wiring the low speed can bus. I am using this diagram which indicates my low speed can is on OBD wire 3 and 11:
https://plus.google.com/110529970729409407854/posts/UcMB38kwRqb?pid=6128773130273387122&oid=110529970729409407854
In my latest attempt, I rewired the OBD cable and I first only connected the red wire to OBD pin 3 and set the baud rate to 250kbps in the source code. No data. Next, I connected the green wire to OBD pin 11 as well; now I have the Airbag warning and 2 fuses blown again :-(
The things I tried before this are described in another thread:
http://forum.canb.us/discussion/82/807-backers-and-this-is-all-thats-happening#latest
I really wish I knew how to do the wiring so I can log low speed can data....

Derek

0

Derek administrators

Thanks James!

Once I get the Beta release of the app done this will be quite a bit easier.

jamesatfish

0

jamesatfish

@Derek‌ -no worries!

@henk_kuipers‌ I don't know a thing about Volvos but CAN is a low voltage data line and shouldn't be fused anywhere. If connecting the two pins to your CBT blows a fuse I'd check your wiring to see exactly what those 2 pins do.

I'd pull the OBD connector from the car and trace the physical wires to confirm they are what you expect them to be. I've found discrepancies between the VW wiring manuals and the reality of the cars, so check that's not the issue in your case alsoz.

TheDigital_1

0

TheDigital_1

@henk_kuipers - woa blowing fuses... scary. Yeah this definitly should not be happening. Here are a couple of things to check:

If you rewired the OBD cable that came with your CBT. Be careful as the wires do not seem to tin (take on solder) very well. you may have had a connection come lose that is now shorting things out. You might want to open it up and give it a visual inspection.
Again if you are rewiring the cable that came with the CBT. Be careful that you have not rotated the PCB inside the plastic shroud that mates with the cars OBD port. If this some how got rotated... Pin 16 on the PCB will now be mating with the Pin 1 of your vehicle... you can check you have it the right way by looking at the shape of the shroud in this picture and making sure your pin 1 is in the right location. <a href="http://developer.mbed.org/media/uploads/fossum_13/xobdii_port1070929671.jpg.pagespeed.ic.GdyXCBV7-t.jpg">OBD-II Pinout </a>
If you have a simple DMM you should do some voltage and short circuit tests.
Make sure you get the pin numbers right going into the CBT. That two row male header can be confusing. See the below pinout with more pin numbers shown.
<img src="http://i57.tinypic.com/vrajc8.jpg" />

Xag

0

X

Xag

Disconnect the battery and measure between the two can lines. Since they're terminated with two 120 resistors parallel, you should measure 60 ohms. Remember to do resistance measurements only with the battery disconnected!

This is a handy page to check some things on a CANbus.

http://www.alldatadiy.com/alldatadiy/DIY~G~C45827~R0~OD~N/0/138181779/138629620/138629625/138629629/34853741/92093561/100406664/100406677/118664746/160079300

henk_kuipers

0

henk_kuipers

Thanks for all the helpful ideas guys! Hopefully, my next attempt is more succesful now :-) I am getting better and better at soldering wires, that's for sure :))

henk_kuipers

0

henk_kuipers

My latest attempt is in another thread because it looks like KidTurbo's problem:
<a href="http://forum.canb.us/discussion/comment/350/#Comment_350">forum.canb.us/discussion/comment/350/#Comment_350</a>

henk_kuipers

0

henk_kuipers

Wiring trouble is over so I am trying to make sense of the low speed CAN data. I continued to follow the steps above (very useful description, thanks!). I gathered data in different settings that make sense to compare but now I need to set message filters to do some trial and error. However, when issuing the logging with filtering commands I receive 1 message (in my case JSON output) and then logging stops. A need to power cycle the CBT to get logging going again and I don't succeed in setting any message filters at all. I use CoolTerm and send HEX commands like:
03010100D800C8 - log Bus 1 and filter message ID 00D8 and 00C8
03010100400058 - log Bus 1 and filter message ID 0040 and 0058
The ID's are valid ID's from my logfiles. Is my syntax wrong?

henk_kuipers

0

henk_kuipers

Am I sending correct CAN packets?
I am making some modest progress. Because I couldn't get the serial filter command to work I have changed the JSON output code in SerialCommand.h so it shows Message ID and payload of only one particular message ID. A very basic filter. By trial and error, I found the messages of events that occur when for instance the mirrors are folded, the doors are locked, the windows go up/down and the fan (up/down). Finally some meaning in all that data :-)
On to the next challenge, send some CAN packets to make something happen. No successful attempts so far. Hopefully someone can see what is going wrong. For example, when I fold the mirrors I see these messages:
"id":"50","payload":["0","5B","40","5","D9","3","4","0"] - folding
"id":"50","payload":["0","5B","40","5","89","3","4","0"] - finished
"id":"50","payload":["0","5B","40","5","E9","3","4","0"] - unfolding
"id":"50","payload":["0","5B","40","5","89","3","4","0"] - finished
Logging in HEX looks like this:
00 50 00 5B 40 05 89 03 04 00 08
00 50 00 5B 40 05 D9 03 04 00 08
00 50 00 5B 40 05 E9 03 04 00 08
So, I was hoping I could trigger the 'folding/unfolding mirrors " action by sending the following packets:
02010050005B4005D903040008
02010050005B4005E903040008
I thought:
0201 = send on bus 1, 0050 = message id, 005B4005D9030400=payload, 08 = length
But nothing happens. I tried the windows and door lock commands too but no luck. I think I have to recycle the CBT after each failure to try again, so that's what I do...
Another question: in CoolTerm you can set the Transmit option "Terminate send string data" with 0D 0A, should this setting be active? I tried it with and without but it didn't make a difference.

henk_kuipers

0

henk_kuipers

Two things made it easier for me to identify messages:

Change the code so you get JSON output (remove comment "//" before the #define JSON_OUT in SerialCommand.h as mentioned serveral places on the forum).
I altered the JSON output code a bit so I could filter one single message ID , this way I could see if messages change when pressing buttons. It is not a big deal but it helped me a lot in finding out what is going on, this is what I changed:

Original code:

#ifdef JSON_OUT
Output to serial as json string
activeSerial->print(F("{"packet": {"status":""));
activeSerial->print( msg.busStatus,HEX);
activeSerial->print(F("","channel":""));
activeSerial->print( busses[msg.busId-1].name );
activeSerial->print(F("","length":""));
activeSerial->print(msg.length,HEX);

if (msg.frame_id==0x0078)
{
activeSerial->print(F(""id":""));
activeSerial->print(msg.frame_id,HEX);
activeSerial->print(F("","timestamp":""));
activeSerial->print(millis(),DEC);
activeSerial->print(F("","payload":[""));
for (int i=0; i<8; i++) {
activeSerial->print(msg.frame_data[i],HEX);
if( i<7 ) activeSerial->print(F("",""));
}
activeSerial->print(F(""]"));
activeSerial->println();
}

Changed code that replaces the above:

#ifdef JSON_OUT

if (msg.frame_id==0x0078) // ->change this message ID figure out if it changes when you press buttons in the car
{
activeSerial->print(F(""id":""));
activeSerial->print(msg.frame_id,HEX);
activeSerial->print(F("","payload":[""));
for (int i=0; i<8; i++) {
activeSerial->print(msg.frame_data[i],HEX);
if( i<7 ) activeSerial->print(F("",""));
}
activeSerial->print(F(""]"));
activeSerial->println();
}
Disadvantage of this method is that you need to compile and upload the code for each message ID you want to test. It's a drag but it works.

TheBoz

0

T

TheBoz

If I have specific message id's how can I look just that data up?

0x01F0A000

AEMnet Revision 2013-05-29
CAN 2.0
29 bit format unless otherwise specified
500 kBit/sec unless otherwise specified
8 data bytes/message
All multi-byte data packed big endian unless specified (most significant byte transmitted first)
All bits numbered with the LSB = bit0, MSB = bit7

Message ID: 0x01F0A000
Source: AEM V2 EMS/Infinity (P/N 30-6XXX/30-71XX)
Target: Any
Rate: 16.6ms continuous
Byte Label Data Type Scaling Offset Range
0 Engine Speed 16 bit unsigned 0.39063 rpm/bit 0 0 to 25,599.94
1
2 Engine Load* 16 bit unsigned 0.00261230481157781 5.48000026028603 0 to 99.998 %
3
4 Throttle 16 bit unsigned 0.0015259 %/bit 0 0 to 99.998 %
5
6 Air Temp 8 bit signed, 2's complement 1 Deg C/bit 0 -128 to 127 C
7 Coolant Temp 8 bit signed, 2's complement 1 Deg C/bit 0 -128 to 127 C

Log
https://s3.amazonaws.com/uploads.hipchat.com/17476/678926/5yP6DoV7L8ua0ME/CoolTerm Capture 2015-04-04 15-04-13.txt