So like the other discussions, here is one for the VAG's

Personally I will be playing around with my VW Jetta TDI

Who else is planning on seeing what can be done in this category?

We should start a database/table of discovered address mappings somewhere, once we get our hands on the bus data that is :)
Collectively, discovery should go a lot smoother.

hope to see this grow and see some awesome projects come out of it

Cool!

I can tell you the VW has a 'CAN Gateway' that filters data to the OBDII port. I'm really interested in how to tell that gateway to forward packets to the OBDII connector. I actually have an Audi available to hack on, but I've been to busy testing, packing, shipping devices to get to hacking on that Audi.

Once everyone has their hardware we can work together to figure this out! I have a VAG adapter available to borrow also.

And speaking of a address mapping solution, this is something I hope to build into the App and have a database on my web site for everyone to share their findings. But building the hardware has gotten in the way of this. Hopefully I'll have the process more streamlined after this so I can get to building that DB.

@exvarkin‌ Im with you on this, and would cant wait to help! I Also have a VAGCOM kit, but not sure how to leverage it for discovery yet. @Derek‌ , I didnt know there was gateway, good info, I should look through the VAGCOM software to see if there are any flags for controlling it. Thanks for all your hard work!

Also I have access to a Evo X, know of any restrictions for Mitsubishi similar to the VW 'CAN Gateway' ?

I've seen a lot of chatter about the CBT on Evo forums and I know one member backed the project. It should be interesting to see what he comes up with. I think his biggest concern was controlling the TPMS.

Not to continue the off-topic Mitsu discussion, but it looks like there is indeed a gateway setup in that as well. The ETACS-ECU serves as the gateway between the middle speed, high speed and diagnostic CAN networks. Looks like most of the interesting stuff (convenience, infotainment, etc.) is on the middle speed CAN-B network, so you'd have to tap into that bus at any of the ECUs on that bus, such as the radio or combination meter.

I have a VW Up, which I'm planning to hack the s**t out of as soon as I recieve my CBT. So I'll be on the VAG page as well ;)

I have finally got my VW Amarok to talk to my CBT today, I started streaming packets down. Now i just need to find a decent way to compare Idle Can .CSV files with Active Can .CSV files. Anyone have a suggestion on a good sniffing style program?

Some connection method info that might help people connecting to VAG cars with their CBT.

<b>Method 1 - K-wire:</b>
The OBD cable that ships with the CBT is wired so that it connects to the K-wire in VW's OBD port. This is the generic (government mandated) diagnostics connector that you can use to get very simple data out of the car. The K-wire connects to the car's CAN Gateway which is setup to only provide the bare minimum legally required data on this port. This is the same data you can get to with a Bluetooth OBD dongle or generic ebay auto diagnostic tool.

It's a very simple protocol - single command out, single response back. No handshake or connection required. The requests to make, responses that are received and the formulas to decode returned data into human readable values are all publicly available around the web - search for 'OBD PIDs'.

<b>Method 2 - CANBus from OBD Port</b>
VW diagnostic programs (both the factory programs and professional grade 3rd party apps like RossTech VCDS) access devices on the CAN networks using the CANBus pins on the OBD port. These are cabled as if they were power train CAN wires, but they actually connect directly to the CAN Gateway. I need to check the pin spots but from memory they are available at Pin 8 (Can High) and Pin 7 (Can Low) on the OBD connector.

You can connect at 500kpbs as the CAN Gateway will translate requests onto the lower baud busses as required.

This CAN connection is data-on-request, so if you connect and start logging the traffic you won't see anything. The CAN Gateway only passes data down this bus if it is specifically requested.

To request data you need to handshake with the CAN Gateway, negotiate connection settings, request a set of data from a particular CAN device and read the data that is returned. With the right requests you can access data from any of the 3 busses from the one connection - so your CBT can request RPM from the Engine controller, Odometer from the Instrument Cluster, Window Position from the Front Right Door controller etc.

The protocols to request this data, and the formats the data come back in, is all VW proprietary and they don't publish the specs. To use this method you'll need to reverse engineer the process for the data you wish to request. If you tap the bus on the back side of the OBD connector then for example you can connect a VAGCOM cable to the OBD connector itself, and use VCDS to request and view data from the CAN controllers. If you do this with the CBT logging the bus you will see the data that flows with those connections and you can sift through to find the patterns you want.

The downside of this connection method is although you can access any controller on any of the 3 busses, you only get data on request, so if you don't know you're looking for something then you can't see it. For example, if you want your CBT to catch a steering wheel button press, you won't see this data on this bus connection unless you were asking the Steering Wheel Controller for the button status at just the right time.

<b>Method 3 - Directly Tapping CAN Busses</b>
This method involves finding the 3 CAN Bus wires in the harness and physically tapping into each of them to wire into the 3 busses on the CBT.

The best spot for this is to find the CAN Gateway (under the dash, driver's side) - follow the CAN power train wires from the OBD connector back to the Gateway box which will have connections to all 3 busses). Connect to the power train bus at 500kpbs, and the convenience and infotainment busses at 100kbps.

Tapping the busses on the car side of the gateway give you access to most traffic that runs across the busses. VW uses a 'tree' style CAN layout, so there are some controllers that are connected to the network as 'branches' off a parent controller, where the parent controller doesn't necessarily pass all data onto the main bus. If you're trying to access something on a branch you won't be able to watch for the traffic passing by - you'll have to request it yourself.

Watching the traffic gives an easier method of finding the data you want - simply log the bus traffic, repeat an action (for example pushing one steering wheel button repeatedly) and watch for patterns in the data. Once identified, just write some code to evaluate every CAN packet that goes by on the bus and match the pattern. There's no need to write data requests and listen for responses - you just eavesdrop on the chatty bus traffic and wait for the data you're interested in.

This is ideal for on-demand data (like button pushes, lock/unlock actions etc) and for frequently transmitted data (for example vehicle speed, RPM etc on the power train bus). If you want less common data (fuel sender resistance perhaps?) that none of the controllers usually pass around on the bus themselves you'll have to form a request and drop it onto the bus yourself to catch the response.

<blockquote>I have finally got my VW Amarok to talk to my CBT today, I started streaming packets down. Now i just need to find a decent way to compare Idle Can .CSV files with Active Can .CSV files. Anyone have a suggestion on a good sniffing style program?</blockquote>

A trick I learned from watching my hardware guru is to find a common marker point in both files and then use an online plagiarism tool to compare the data. Those tools will go through and find all the similarities, leaving you with a list of differences that gives you a good place to start in figuring out what is chatter and what is the actual data you're trying to find.

I have an Audi A4 (B7). I've been able to successfully sniff out the DIS messages from my RNS-E using the same method that @jamesatfish wrote up at http://forum.canb.us/discussion/91/identifying-steering-wheel-button-packets-an-example (excellent write up!).

I can successfully send a message to the DIS by using the CBT command 02020261484579205345787908. I see the message for a split second before the RNS-E overwrites it by sending a new command ID 0x0261 with the radio station that's currently selected, but at least I know my setup is working.

If the RNS-E is off and I send my same message using the CBT, nothing is displayed on the DIS. Is there a command that the RNS-E is sending to the DIS to "enable" radio messages? Through all my bus sniffing, I haven't been able to find anything specific.

The RNS-E sends the DIS packets every second (or quicker) so as you've seen if you just inject a new message packet once it'll be over-written fairly quickly.

If you want your messages to persist you'll need to use the CBT in 'man-in-the-middle' mode, with your software passing through all packets except for 0x261, which you replace with your own payload.

Modules that want to communicate with the DIS need to join the 'ring', which is how they register their intent to send data for display. It's how your DIS knows if there is a navigation module attached, or a Bluetooth module etc, and thus displays the relevant pages.

With your RNS-E off, it will not have joined the ring and as the DIS will ignore packets from unregistered modules, your messages don't get displayed.

Do you know how to join the "ring"? That'll be useful if I ever replace the RNSE with an aftermarket radio. My ultimate goal is to display the boost pressure instead of the radio information.

The exact code varies depending on what options you've got in your car, but look for packets with frame IDs from 0x420 - 0x4A0.

You should see a series of packets with a format like:

(0x436) 16 02 C0 04 00 00 (6 bytes)
(0x428) 16 01 00 00 00 00 (6 bytes)
(0x436) 08 01 00 00 00 00 (6 bytes)

The first byte in each packet matches the frameID (420+byte0).

Essentially that series of packets equates to:

ID 436 asking to join the ring
ID 428 is the last device in the ring saying it's OK to join
ID 436 responds back to ID 428 acknowledging the message

Once you're on the ring, you may need to send keep-alives (0x661) on a regular basis if you see them on the bus in your car.

Oh, and if you haven't figured it out already, 0x263 is the ID for the 2nd line at the top of your DIS, if supported on your car.

Yes, I see the 0x436 and 0x428 IDs, along with a few 0x661 keep-alives. Here's a trace that I captured from the moment the ignition was turned on, until the RNS-E started sending 0x261 and 0x263.

<pre><code>436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
436 16 02 C0 01 00 00 00 00
60E C5 00 00 00 00 00 00 00
351 45 01 00 21 1B 75 8F 18 speed
623 00 12 29 46 15 04 20 15 time
653 02 02 04 00 00 00 00 00
436 08 01 00 00 00 00 00 00
428 16 01 00 00 00 00 00 00
604 00 00 00 00 00 00 00 00
661 00 01 12 00 00 00 00 00 audio source
351 45 01 00 21 1B 75 8F 18 speed
353 0F C7 0B C0 7E 22 09 00
436 08 01 00 00 00 00 00 00
625 DB B3 CF 6A 39 00 00 00
428 16 01 00 00 00 00 00 00
604 81 00 00 00 00 00 00 00
661 81 01 12 A0 00 00 00 00 audio source
351 45 01 00 21 1B 75 8F 18 speed
662 00 00 00 00 00 00 00 00
42F 16 01 00 00 00 00 00 00
42F 0F 02 80 00 00 00 00 00
6D1 A1 0F 8A FF 4A FF 00 00
6D0 10 C5 22 10 00 00 00 00
6D1 B1 00 00 00 00 00 00 00
436 08 01 00 00 00 00 00 00
42F 16 01 00 00 00 00 00 00
6D1 20 C6 3C F0 00 2A 20 41
6D1 11 56 58 20 2A 20 00 00
635 00 00 01 00 00 00 00 00 light state
261 20 20 20 20 20 20 20 20 DIS line 1
263 20 20 20 20 20 20 20 20 DIS line 2</code></pre>

So it sounds like the DIS ring has a hierarchy, with the radio station information being lowest priority, maybe bluetooth caller ID or navigation being the next higher priority, and highest priority being things like light bulb or battery low warnings. Instead of doing the man-in-the-middle to filter out the radio station DIS information from the RNS-E, I could probably spoof a bluetooth message using ID 0x265/0x267 because I don't have a bluetooth module--just need to know what the "ring" request from the OEM bluetooth is. Does anyone know?

I have a few more traces that I wanted some help understanding.

When the ignition is turned on, but the radio fuse is pulled, I only see ID 0x428 sending the same payload indefinitely:
<pre><code>ID Len Payload
428 6 08 02 80 00 00 00</code></pre>

When is the ignition is turned on (knowing that the radio would turn on too), I see this (filtered for only items in the 0x420-0x4A0 range, up to the first 0x261 message):
<pre><code>ID Len Payload
428 6 08 02 80 00 00 00 (repeated many times, but truncated here)
428 6 08 01 00 00 00 00
436 6 16 02 80 00 00 00
436 6 16 01 00 00 00 00
428 6 08 02 00 00 00 00
428 6 08 01 00 00 00 00
436 6 08 01 00 00 00 00
428 6 16 01 00 00 00 00
436 6 08 01 00 00 00 00
428 6 16 01 00 00 00 00
261 8 20 20 20 20 20 20 20 20
436 6 08 01 00 00 00 00
428 6 16 01 00 00 00 00
436 6 08 01 00 00 00 00
428 6 16 01 00 00 00 00
261 8 39 39 2E 35 00 20 20 20</code></pre>

Why are there multiple 0x436 being sent, and with different payloads? Looks like the radio continually sends 0x436 with payload '08 01 00 00 00 00' indefinitely.

If I then remove the radio fuse, and with the CBT, send the 0x436 ID with payload '08 01 00 00 00 00', I'm still unable to see any of my custom messages on the DIS. For some reason, if I send the message with 6 bytes (0202043608010000000006), the CBT seems to hang...it works if I pad two more bytes of 00 and change the length to 8 (02020436080100000000000008). Maybe I need to code this into firmware instead of just sending the 0x436 and 0x261 from the serial port because the car's expecting these at a much faster rate?

jamesatfish....thank you for the excellent write up, it certainly helped me make sense of this, I am new to this, I bought Vcds to do repairs on our 2 Vw, and now I have a CBT, I would like to start logging raw data and learn. I have 04 Jetta and 2012 Passat Kessy, I think I'll begin my hack with the Jetta, it is more forgiving, at least it uses a physical key.

Is there an App in the works for Android?

Hi guys! In the past three years as a hobby I'm trying to identify the codes of devices and their meanings.
My car: Skoda Octavia II FL 2011 with VAG CAN BUS.
I made a shield for the Raspberry Pi according to the scheme http://lnxpps.de/rpie/.
<img src="https://dl.dropboxusercontent.com/u/25895838/IMG_4220.JPG" />

I connected to the CAN BUS at door. I think this line is connected only to the comfort bus (may be I'm wrong):
<img src="https://dl.dropboxusercontent.com/u/25895838/IMG_4191.JPG" />

To communicate with CAN BUS I use <a href="https://gitorious.org/linux-can/can-utils">can-utils</a>.
All perfectly work, I can control my windows with commands such as:
cansend can0 181#0200 // Open the driver window fully
cansend can0 181#0800 // Close the driver window fully

For OSX and iOS I wrote a app that displays a data in real time for devices in the individual cells:
<img src="https://dl.dropboxusercontent.com/u/25895838/canbussniffer.png" />

Using this app, I found some CAN devices:
181 - Control/Read status of Windows
381 - Read status of front left Door (open/close)
470 - Read status of front right Door (open/close)
291 - Read status of back right&left Doors (open/close)
531 - Control/Read status of Lights&Winking
5D1 - Read status of Windshield
591 - Read status of CentralLock
67A - Reverse gear engaged

Many IDs I can't define, If someone can help with finding IDs, I'll be glad!
I wan't to found a speed, rpm, distance, parking distance, fuel consumption
and other IDs.

I've read that the Skoda is pretty similar to the Audi/VW, so I'd expect it to have 3 separate canbus's too: comfort, infotainment, and engine. The speed and rpm are on the engine canbus, and I believe the speed is also available on infotainment canbus for the nav to read. Since you're on the comfort bus, you likely don't have the data you're looking for. I tapped into the comfort and infotainment buses behind the instrument cluster, which was pretty easy. I followed this pinout on my B7 A4: http://www.audizine.com/forum/showthread.php/486720-RB4-Cluster-connection-pinout?p=7611852&viewfull=1#post7611852.

Hi to all people here, I have a question about the CAN wiring on my VW Polo 1.4D year 2003.
I try measure the CAN bus on my car with my DSO through the OBD-II connector on the car
connected the DSO CH1 to OBD-II pin 6 ( CAN-H ) and the DSO CH2 to OBD-II pin 14 ( CAN-L )
But I got only a crappy signal like this:
<img src="http://www.code-elektronic.com/tmp/can bus.bmp" />

I try the same measuring on my Renault Clio II 1.5DCI and it work perfect, I can see the CAN communication on my DSO.
I try the same measuring on another VW Polo 1.4MPI year 2008 and I got the same problem like on the older one Polo.

Can somebody tell me why is this happening on the VW cars?

I mean I cant sniff any data from the CAN network or what?

Thanks a lot.

Hi, in my Skoda Octavia OBD-connector connected to gateway and I cant sniff CAN BUS with OBD II, so I connected to CAN BUS in door.
But now, when I know CAN IDs, I can send CAN commands and receive answers with OBD II. СAN BUS Data is transmitted to OBD II only on request.

AhA! that is the trick.
Thanks man!
There are no way to measure the CAN network in the car through the OBDII and a scope?
Is it maybe possible to get a CAN signal on the OBDII connector with an OBD brakeout box?
Hmmm or we can put an ELMA scanner on the OBDII and whit the Hyperterminal send and request the CAN commands
and monitoring the signals whit a DSO to check if there are any disturbing in the CAN network?
I mean is a shorten or not or broken CAN wire...