Lukeyson

Can anyone point me in the right direction for understanding how the CAN 11-bit addressing works?

I have found the legislated Physical/Functional address allocation at 7df to 7ef. (Yahoo! Groups)

When I scan my car (2003 Australian BA Falcon XR8) the broadcast traffic I see shows headers from 200 to 64f when I sniff. I am able to reverse engineer much of the data carried in these packets, but i don't actually know what the headers MEAN.

Of particular note, the 11-bit Normal CAN is obviously bit-deficient when it comes to the 3-byte headers of J1850 or the 29 bit CAN Extended format.
I have had a few reads of J2178 and still can't figure it out.

Is there anyone that could help me understand how the 11bit CAN Standard Addressing works?


Lukeyson

joeyoravec

Unless it's assigned by standard (x7DF and x7E0-x7EF), it's up to the manufacturer. Traditionally the header represents a destination mailbox. This is somewhat different than the desintation/source concept in some J1850 networks.

Lukeyson

Fair enough.

So are there any standards, other than J2178, that describe how the CAN 11-bit Normal Address identifier is even constructed? Your reference to a 'mailbox' hints that there must be more written somewhere.

I now have J2178 and an older ISO15765-4 - but not J1979 or ISO 11898-1. Are there others I should look for?

The ELM327 spec sheet mentions that bits 8-10 are for the RA and 0-7 are for the TA. But even then the legislated addresses don't make sense to me, let alone the broadcast addresses. J2178 talks about a 'mapping' so I was hoping to find that somewhere.

There must be a logic to the addressing written down somewhere!


Lukeyson

joeyoravec

The 29-bit variant has a target address concept, but with 11-bit there's really no logic except priority when you're fighting for control of the network. Otherwise, the address assignment is completely up to the designer. A quote from part B page 38 of the Bosch CAN specification:


Sure. You could enumerate all parameters and design a network where RPM is broadcast on $XXX, speed on $YYY, engine coolant temperature on $ZZZ, etc. It probably sounded clever in 1991 because each message is short and sweet, but this architecture fails because you never have an infinite supply of hardware filters. Sometimes you see this on an isolated network segment but it's just not realistic for "some guy" to manage this allocation perfectly for an entire car.

So for 11-bit OBD networks they go back to the old way of thinking. You have a functional identifier (x7DF), a physical identifier for tester-to-ECU communication (x7E0-7E7), and a physical identifier for ECU-to-tester communication (x7E8-7EF). At least you can use filters to determine that the message is for you, but you'll need to parse the contents in software to understand what it means.

Lukeyson

I think I found the document you're referring to, as it matches your reference, thanks for your help.

http://www.semiconductors.bosch.de/pdf/can2spec.pdf


Lukeyson

Lukeyson

I have another question.

I am interested in listening to traffic being sent across the CAN bus from another tool (such as a factory tool like a Ford WDS or an aftermarket performance tuning tool such as an SCT XCalibrator 2) and was looking at one of these (OBD2Cables.com) to facilitate a dual connection.

If I understand you right, CAN is more a 'broadcast and filter at receive end' so I should be right to hook up two tools and set my tool to just capture and filter on the conversation between the active diagnostic tool and the ECU.

Do I have this right? Or is there more to device and diag tool addressing that is not part of the CAN identifier?


Lukeyson

joeyoravec

You'e got it. It could be a ***** to reconstruct, since "anything interesting" uses iso15765 flow control on top of individual 8-byte CAN frames. Make sure to use a tool that is capable of sniffing the full-bandwidth or else you're wasting your time. Just shoot me an IM or email if you have more detailed questions.

Lukeyson

Yes, that's the big question for me now isn't it - full bitrate.

I've been learning my stripes using an ELM327 based unit and am constantly hitting buffer overflow - even at 38.4k. Looking at the chipset I it appears that even the USB versions run at slow speed too - and certainly not at full USB 2.0 or even USB 1.1 speeds.

But as a tool to get me started and learning manual commands and reponses via Hyperterminal I have found it useful.

Even your OBDPro tool at 128kbps would struggle to capture a full-speed PCM reflash. Or do you have a more positive experience to report?

I'll post another thread Re: available scantools that can sniff a CAN bus at full rate.


Lukeyson

chewwtoy

I think we should back this train up.... It seems to be me that this is easily a very confusing issue if you see the world through a scan tool.

There are two types of messages on todays CAN enabled vehicles. One is Diagnostics. This is were OBDII comes in and other standards like J2190, ISO 15765, ISO 14229, Keyword 2000, etc. These are diagnostic application level protocols that define how a tool can extract information from the ECUs (Controllers) on the CAN network. This is typically how aftermarket (non-OEM people) can access information from ECUs.

The second type of messages is what your questions alluded to, normal mode messages. These are ECU to ECU communication messages. These messages occur so that ECUs can share information. Example, if you open the driver door, there is a module that will send a specifically addressed message with specifically formated data on the CAN bus. Then you Body Controller Module will then hear that message and turn the dome light on. The other modules on the bus heard the message they simply didn't care. The message was not intended for them. There are hundreds, sometimes thousands, of other examples of this happening every second on your CAN network.

The trick is these normal messages are unique to the specific make, model, and manufacturer. For example a message with the ID of $210 on a 2006 Ford Explorer will not be the same as $210 on a 2006 Toyota Prius. And the kicker is that these messages, their IDs and the data inside are 100% proprietary. That means you don't have access to them, you must sign an aggrement with the OEM in order to even think about gaining access to them and the people who have access to them cannot give them out freely because they are bound by the agreement they signed. So they risk serious penalties for distributing this info.

Long story short the non-diagnostic messages are a secret that can be reverse engineered so good luck...

Lukeyson

Yes, I'm finding that.

In my car in particular, the CAN bus is not all that pervasive. It links the 6 main modules (PCM, Cluster, BCM, A Central Integrated Command Centre Stack, HVAC Module and the TCM which is dual connected to the ISO9141 bus)

So most of what's on the body is directly connected to pins on the BCM. The ONLY time I see anything happen is if this bus communicates to other modules - such as the indicator lamp on the cluster for your door example.

My workshop manual listed all the inter-module communications types, src/dest, and my scanning shows I have a finite number of addresses being broadcast across the bus.

The reason for my initial question is that I have in some cases 2 or more Transmitters sending to the one receiver - once again I use the Cluster as an example, with it receiving Speed/RPM from the PCM, Door/Light status etc from the BCM and Traction Control Indicator status from the TCM - and I was wondering if there was a source-target standard to the 11-bit address so I could mask off a certain number of bits and know which bits were directed towards the IC.

While it's clear now that there is no standard, I will still look harder for a pattern when I reverse-engineer more of these broadcast messages. In total there about 9, and after a 5-minute peak I have already picked out 3 of them and started mapping which bits do what (Bat voltage, door status, light status, rpm) etc.

So after all that, it sounds like I'm on the right track with this, I just don't have the nicety of having sensible src/dst addressing.


Lukeyson

chewwtoy

I see... Source Destination stuff is possible obviously, but I personally have never seen like you see in Class 2 3 byte headers or ISO 9141. As was mentioned earlier, 29bit is definitely used as a Priority/Destination/Source addressing scheme, but is a lot of overhead for most high speed applications. So typically you wont see too many manufacturers use 29bit for their Powertrain buses, but rather for their Chassis buses.

You are definitely on the right track. Reverse engineering is the only way to figure out what is going on here.

After you have finished with your Reverse engineering what do you plan on doing with the info? Are you going to post it somewhere?

Lukeyson

Will I post?

I most certainly will. In fact, I have started already. The details, however, are a bit long-winded, and while I'd like to describe it all, I'm not sure if this is the topic or indeed the Forum that I should use.

As this work is all being done on an Australia specific car that is sold only in Australia, New Zealand and South Africa I will be focussing on that, so international relevance may be limited.

If you're interested I have at least started posting on an Australia Ford Modifications here: www.fordmods.com :: View topic - SCANTOOL Fun

But at the moment you'll only find me rehashing the basics. The gory detail of reverse-engineering Broadcast messages or verifying my current (very small) list of Ford Enhanced PIDS is yet to be done but will likely be journalled in that thread.

The eventual intention is to write some sort of utility that can be integrated with a Media Centre application so that it can be shown on the existing NTSC RGB LCD screen installed in these cars from the factory, such that I can review Polled or Broadcast data with the use of a simple remote control.

The capture of data from other Scantools, however, is more about extending my knowledge of the comms in this car than it is about having a goal, and about discovering more of the PIDs that might interest me.

I was initially triggered by the desire to upgrade from a Manual Climate Control console in one of my cars to an Auto Climate Control console, which requires writing some new values to the Body Control Module and HVAC Control Module. The proprietary nature of the data involved of course prevents me from doing this easily, but by 'piggy backing' on the guys at the dealer workshop if I ever get them to do this work for me means that I'll at least understand how it was done. (If I can capture the bits quick enough that is.)

One of my other projects was to access the factory screen and use if for displaying an in-car LCD camera faced at the back seat (so I can see my kids at night) and a camera at the rear for reversing, or for putting on the back of our Caravan so I don't have to install 'Wing Mirrors' and scratch my car when I go on long trips.

Plus, in many ways, I'm just doing it for the fun of it because I am a hopeless techo head.


Lukeyson