SwedeSpeed - Volvo Performance Forum banner

OBD-II / CAN / ISO9141 technical issues

85K views 27 replies 11 participants last post by  jimDK  
#1 ·
There are a couple of other threads on this, but they are more about commercial stuff. Let's talk about the details of OBD-II and other Volvo data access...

As we know, all Volvos from 1996 in the US support some form of OBD-II communication. Most Volvos from 1999-2004 use an ISO9141 interface for this, while 2005- use CAN. To read the car's OBD-II you need a scan tool or other device which uses the right interface. But, the OBD-II protocol, and what you can read from the car with it, is pretty much the same.

Going "down a layer", you can in fact read the raw protocol that's travelling around the various car components, but once you go there you're in proprietary Volvo-land, and it's not at all obvious how to figure it out. Some folks here have been doing so, but only a few. BSR seems to have cracked some or all of it, to make their PPC and diagnostic (http://www.ppc-diagnostic.com/).

So, I'm a Palm developer in my spare time (http://mytreo.net/downloads/details-640.html?KeyguardTime+) and crazy enough to hack on the open source PalmOS client for this bluetooth OBD device (on my Treo 650):

Image
http://www.car-pal.net

It's really useful as a data logger and general monitoring tool. There are lots of other devices like it (though this is the only one I know with Bluetooth). But OBDII devices are not at all a window into the inner workings of the car, they're limited by what the car chooses to reveal.

OBD-II is implemented by a kind of "gateway" device in the car, and it allows sampling of signals called "PIDs" (http://en.wikipedia.org/wiki/OBD-II_PIDs). These are defined by the SAE J1979 spec, and they're rather generic. There is much more detailed information available when speaking the Volvo protocols, this is what dealers use of course.

My V50 has a 500Kbit/s CANbus (our XC90 is ISO9141), and the Car-Pal connects right up. The available OBD PIDs are as follows, most other Volvos seem to be pretty much identical:

3 - fuel system
4 - load
5 - coolant temp
6 - STFT
7 - LTFT
A - fuel pressure
C - RPM
D - speed
E - ign adv
F - air temp
10 - MAF
11 - Throttle
13 - O2 sensor map
15 - O2 sensor
1C - OBD std type
1F - time since engine started

I have found that my Treo can sample all these available PIDs together at about 9.5/second. Interestingly, if I reduce the number of PIDs being scanned, the sample rate actually goes down, I suspect there's a software glitch in my Treo client. But, 9.5 is about all I have seen any OBDII device do, so I am assuming the max sample rate is basically being limited by the car. This makes sense, since OBD-II is really just a compliance thing. There isn't really a big effort to expose the inner workings of the car, or make it a general-purpose interface.

Anyway, the good thing is that the basic OBD-II data is more than good enough for basic monitoring for speed (acceleration), basic air/fuel (off the O2 sensor) which can also give mpg, engine rpm and load, plus some interesting engine parameters like coolant temp, IAT, fuel pressure, fuel trim etc which are useful when tuning. And, it reads engine codes, etc (but only engine and emission codes, not the many others). So, it's really good for data logging and basic diagnostics. These data are basically what the Auterra PDA Dyno, G-tech, and other devices are reading.

Unfortunately, it doesn't read boost (pid 0xb), which of course is what everyone would want to see. I suspect Volvo leaves this off intentionally. It's not required for compliance purposes, and it's a window into the car's algorithms. Maybe I'm just a cynic, but there it is.

Anyway, I'm really interested in knowing if anyone else here is interested in OBD or CAN programming for Volvos, and/or has started down this road. There are bunches of similar projects on other brands. Anyone want to share?

Tom.
 
#2 ·
Re: OBD-II / CAN / ISO9141 technical issues (tmtalpey)

Hi Tom,

This is exciting stuff! I've been holding off on getting a new OBD2 tool since I'm trying to figure out which one to buy based on which author is most likely to offer enhance Volvo support soon.
You've probably aready seen the thread I started on this but for other's sake here it is: http://forums.swedespeed.com/zerothread?id=59569
i
I'm seriousely considering spending $300 on ValueCan so I can us CanCracker from these guys http://www.intrepidcs.com/website/CANCracker.htm

I'm a techie-DYI guy and know my way around cars and electronics but the problem I have with digging into this is time. I'm not sure how far I would actually get if I bought that tool.

I'd like to work on this with you.

Does CarPal use the ELM chipset? Are you able to send raw commands on the CAN bus with CarPal?

LTA
 
#3 ·
Re: OBD-II / CAN / ISO9141 technical issues (LTA)

Yeah, it is kind of fun, a little puzzle to try to figure out...

As to which author might support Volvo, from a pure OBDII perspective the answer is all of them. At a lower level, I'm not too optimistic. Volvo doesn't release any detail at all (unlike other mfrs), and the market volume just isn't there. But, we shall see.

I don't know much about ValueCan, but it looks interesting enough. I'll check it out more sometime soon.

CarPal doesn't use ELM, but it is very similar. Yes, certain raw commands can be sent with it, and other functions. But, like other OBD-capable units, it's not actually a CAN sniffer. If you want to go there, think differently.

I'll contact you offline. Anyone else?

Tom.
 
#4 ·
Re: OBD-II / CAN / ISO9141 technical issues (tmtalpey)

You think we can get the students that worked on this cool system to help us?

I bet they had to sign an NDA and won't spill the beans
Image


LTA
 
#6 ·
Re: OBD-II / CAN / ISO9141 technical issues (Pat S)

Quote, originally posted by Pat S »
I'd be interested in helping also, but I may not be of much help since I am just starting to learn how CAN works. I do have some limited software/db development background.

Pat

Thanks Pat.

I got an e-mail from Alex C. Peper, he says he should have more advanced Volvo support in 1-2 months from now. As for getting into deep into the various Volvo controllers he says it may require hardware changes and no idea on how long that will take.

I offerd to help test and suggested that he'll win many customers should he be able to read special Volvo messaging especially BOOST.

I suspect standard OBD-2 messaging in current model Volvos happens on CAN H (high speed bus) but getting into other controllers may requir comms on the CAN L buss (low speed bus). That's just a hunch and I'm waiting for Alex to respond.

LTA
 
#7 ·
Re: OBD-II / CAN / ISO9141 technical issues (tmtalpey)

Quote, originally posted by tmtalpey »
, and it's not at all obvious how to figure it out. Some folks here have been doing so, but only a few.

Wow that was an old thread...now know a lot more than I did back then! What you see in that screen shot are the periodic CAN messages that are sent out on the bus - they are actually not much use unless you have a copy of the appropriate signal config file and know how to decode it.

While the protocol is structured, Volvo uses "manufacturer specific" request types/identifiers/etc - so it's mostly guess work. For example a request type of A6 means READ CURRENT DATA BY IDENTIFIER. You then need to know what offset or identifier you're looking for on the ECU.

I've actually broken down the process for writing to an ECU - it's reading the current programming I've yet to figure out (although I do have some suspicions). Some of the standard PBL commands include:

86 - shuts the ECUs up and prepares for programming
C0 - starts the specified ECUs primary boot loader
9C - specified base address where the action should take place
F8 - erase the memory block
B4 - commit up to the specified address
A0 - used to jump to another subroutine address
C8 - resets the ECUs to normal operating mode

I was hoping that someone with documentation would contact me or anonymously send some details my way. Unfortunately, I've not been so lucky.

I could probably figure more details out, but this is my daily driver. I can't afford to accidentally screw up one of the ECUs and have to get it flashed with VIDA.
 
#8 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

we R obsessed,

If your goal is to read and write the ECU fuel/air mapping (ie performance tuning) there could be an easy way to get much closer to cracking it:

Attach your CAN sniffer to the bus along with an ECU reader/writer that uses the CAN bus and 'watch' and record what goes on. For example, if one of those black-box ECU tuner things uses the CAN bus then in theory one could snoop on what commands and data and being sent and received during the ECU 'tune' process.

You'd still have lots of deciphering to do but atleast you'd be looking in the right haystack!

Ps. Please tell me what system you're using to sniff you CAN bus. ELM327 bases 'scanners' seem good and do offer CAN monitoring but with their small 256KB buffer and 34.8Kbps RS232 speed it might get choked up with CAN H. Intrepid systems' CanCracker is REALLY cool, but not cheap! Which one are you using?

LTA

Modified by LTA at 9:40 AM 7-6-2006
 
#9 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

we R obsessed: Check your IM.

LTA
 
#10 ·
Re: OBD-II / CAN / ISO9141 technical issues (tmtalpey)

I know there must be serveral VADIS users out there. Does anyone have access to VCT2000? That might help figuring out what goes on high/low CANs. Using VADIS32\BIN\BugTrace.exe it is possible to capture all serial communication that goes on between VADIS and VCT2000.

If request/response messages do not show up, you may need to add following key to registry (this is registry export of it):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Volvo\VADIS\Bucket\VEH]
"DEFAULT_BAUD"="115200"
"VCTLIB_TRACE_MSGS"="1"

Here is sample of BugTrace run where connect to VCT2000 is simulated... If someone with VCT2000 could capture reading of the codes and other data and post it here. Thenmaybe CAN sniffing experts here could see if it maps directly to CAN requests/responses (besides VCT2000 frame info).

Time MOD D E S Trace Data
08:40:36.54 SWM 1 0 4 SWMGR.DLL Initializing
08:40:36.54 VDA 1 0 1 DllMain - Process Attach (0x6b0000)
08:40:36.54 VDA 1 0 4 Vadis version: 6.7a.2775
08:40:36.54 VCA 1 0 1 DllMain - Process Attach (0x6f0000)
08:40:36.54 VCA 1 0 4 Vadis version: 6.7a.2775
08:40:36.54 VHA 1 0 1 DllMain - Process Attach (0x710000)
08:40:36.54 VHA 1 0 4 Vadis version: 6.7a.2775
08:40:36.54 SWM 1 0 4 LoadLibrary(Safecl32.dll) failed, err = 126
08:40:55.92 SWM 1 0 4 LoadLibrary(Safecl32.dll) failed, err = 126
08:45:45.33 VHA 1 1 1 System Logging is OFF
08:45:45.37 VCL 1 1 1 VctOpen: Serial RW timeout set to: 30000
08:45:45.61 VCA 1 1 1 OpenCommPort: port COM1 opened, baudrate = 115200
08:45:45.61 VCA 1 1 1 Force RS232 baud to 115200
08:45:45.61 VCA 1 1 1 Set Download VCT RS232 baud rate = 115200.
08:45:45.61 VCL 1 1 1 Request Frame Size=23 Data=
08:45:45.61 VCL 1 1 1 80,00,0E,00,1F,01,00,00,01,F4,00,00,03,E8,00,01,C2,00,00,00,03,51,81,
08:45:45.95 VCL 1 1 1 Response Frame Size=22 Data=
08:45:45.95 VCL 1 1 1 80,00,0D,00,1F,06,00,00,00,00,1F,01,12,34,00,00,00,00,00,01,18,81,
08:45:45.95 VCA 1 1 1 InitVCT2000: Serial RW timeout set to: 30000
08:45:45.95 VCL 1 1 1 Request Frame Size=17 Data=
08:45:45.95 VCL 1 1 1 80,00,08,00,10,02,00,00,00,00,00,00,00,00,00,9A,81,
08:46:15.96 VCL 1 1 1 RecvLLPFrame returned = 0XFFFF7F18
08:46:15.96 VCA 1 1 1 VctListPackages returned (0XFFFF7F18)
08:46:15.96 VCA 1 1 1 SelectPackage() returned (-33000)
08:46:15.96 VCA 1 1 1 Connect: InitVct_HW() returned (-33000)
08:46:15.97 VCA 1 1 1 DisConnected from VCT
08:46:15.97 VHA 1 1 1 System Logging is OFF
08:46:16.00 VCL 1 1 1 VctOpen: Serial RW timeout set to: 30000
08:46:16.02 VCA 1 1 1 OpenCommPort: port COM1 opened, baudrate = 115200
08:46:16.02 VCA 1 1 1 Force RS232 baud to 115200
08:46:16.02 VCA 1 1 1 Set Download VCT RS232 baud rate = 115200.
08:46:16.02 VCL 1 1 1 Request Frame Size=23 Data=
08:46:16.02 VCL 1 1 1 80,00,0E,00,1F,01,00,00,01,F4,00,00,03,E8,00,01,C2,00,00,00,03,51,81,
08:46:16.15 VCL 1 1 1 Response Frame Size=22 Data=
08:46:16.15 VCL 1 1 1 80,00,0D,00,1F,06,00,00,00,00,1F,01,12,34,00,00,00,00,00,01,18,81,
08:46:16.15 VCA 1 1 1 InitVCT2000: Serial RW timeout set to: 30000
08:46:16.15 VCL 1 1 1 Request Frame Size=17 Data=
08:46:16.15 VCL 1 1 1 80,00,08,00,10,02,00,00,00,00,00,00,00,00,00,9A,81,
08:46:46.15 VCL 1 1 1 RecvLLPFrame returned = 0XFFFF7F18
08:46:46.15 VCA 1 1 1 VctListPackages returned (0XFFFF7F18)
08:46:46.15 VCA 1 1 1 SelectPackage() returned (-33000)
08:46:46.15 VCA 1 1 1 Connect: InitVct_HW() returned (-33000)
08:46:46.15 VCA 1 1 1 DisConnected from VCT
 
#11 ·
Re: OBD-II / CAN / ISO9141 technical issues (sweedespeed)

Yes, those are the command sent to the VCT2000. Those commands setup the initial communication parameters (baud rate) and then query the VCT for it's packages (PFWDL/MONIT/VADIS), free memory, ect. I actually haven't examined these that closely as it's easier for me to just sniff the real CAN frames on the car.

80,00,0E,00,1F,01,00,00,01,F4,00,00,03,E8,00,01,C2,00,00,00,03,51,81,
|--|.................................................................................................................Start of frame
....|---------------------------|..............................................................................Frame header
....|??|---|.......................................................................................................Data size (14)
.......................................|-------------------------------------------------------|.......Frame data
.....................................................................|??|-----------|...........................Baud Rate (115200)
.............................................................................................................|--|....End of frame
 
#12 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

Slight elaboration:

80,00,0E,00,1F,01,00,00,01,F4,00,00,03,E8,00,01,C2,00,00,00,03,51,81,
|--|.................................................................................................................Start of frame
....|---------------------------|..............................................................................Frame header
....|------|........................................................................................................Send data size (14)
.......................................|-------------------------------------------------------|........Frame data
.....................................................................|??|-----------|............................Baud Rate (115200)
..........................................................................................|--------------|........Bytewise checksum
.............................................................................................................|--|....End of frame

There's a lot more going in here of course. I do find it odd that the software would send the baud rate to the VCT2000, over the serial line that's already set to that baud rate.

0x1F4 is 500 decimal, and isn't 0x3E8 a standard COM port i/o address?

Tom.
 
#14 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

Quote, originally posted by we R obsessed »
the 0x1F4 - I've only seen it set to anything on this one frame. In all other cases I have it's 0x0.
Probably a millisecond timeout, or something along those lines.

All this is just the control portion of the Vadis<->VCT comms, of course. Not the most interesting stuff on the planet.

Tom.
 
#15 ·
Hi. I plan to implement the steering wheel buttons in my Carputer and I have bought a CAN-interface http://www.machinebus.com/imag...t.pdf that I plan to use together w/ a Basic stamp. I have no idea how to filter out the buttons on the CAN. I can configure CAN ID filters in the interface but I don't know the ID for the buttons, do any of U know them? Could really need some help here. Best regards L. Kull from Sweden.
 
#16 ·
tmtalpey,

I have a 1999 Dodge caravan. It uses ISO9141 Protocol. I was able to use an ELM323 chip and a PIC microcontroller to communicate with the ECU. Now I am trying to write my own software to run on the PIC microcontroller but I am not getting anywhere.

Based on what you have accomplished as Palm developer, I believe that you might be in a position to help. I would like to know;

1/ what voltage level on the bus would the ECU and the Scan Tool interpret as a "1" and a "0"? and

2/ would this voltage level be the same during the very first part of the Bus Initiation (i.e when sending 33 hex), and during the remainder on the Bus Initiation process?

Thanks very much for your response.
 
#17 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

hehehe I got my hands on some info.
Image


Frame (Max size 0x200):
Frame beginning is always 0x80
16 bit unsigned intager indicating the payload size
1 byte pading of value 0
The Payload - variable size
1 byte pading of value 0
1 byte pading of value 0
3 byte checksum
Frame ending is always 0x81

Payload max size is 0x1f7 per frame.

That one we were looking at is an Init VCT2000 request:
16 bit unsigned at offset 0 command ID (0x1f01)
16 bit unsigned at offset 2 undefined
16 bit unsigned at offset 4 inter frame time (500)
16 bit unsigned at offset 8 complete frame time (1000)
32 bit unsigned at offset 10 baud rate (115200)

The VCT sent back a Acknowledgment response:
16 bit unsigned at offset 0 command ID (0x1f06)
16 bit unsigned at offset 2 application handle
16 bit unsigned at offset 4 message handle
16 bit unsigned at offset 6 ack message ID (aka request command ID)
32 bit unsigned at offset 8 is reserved
1 byte at offset 6 12 acknowledgment value ( 1 = info, 2 = nack, 0 = OK )
---note are ack was OK so it stops here--
16 bit unsigned at offset 13 error/info code (many to list)
16 bit unsigned at offset 15 cause (many to list)
 
#18 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

There is one of my "trac1" files.Time MOD D E S Trace Data
19:01:45.12 SWM 1 0 4 SWMGR.DLL Initializing
19:01:45.13 VDA 1 0 1 DllMain - Process Attach (0x5d0000)
19:01:45.13 VDA 1 0 4 Vadis version: 6.7a.2775
19:01:45.13 VCA 1 0 1 DllMain - Process Attach (0x610000)
19:01:45.13 VCA 1 0 4 Vadis version: 6.7a.2775
19:01:45.13 VHA 1 0 1 DllMain - Process Attach (0x630000)
19:01:45.13 VHA 1 0 4 Vadis version: 6.7a.2775
19:03:33.35 VCC 1 0 4 DllMain - Process Attach (0X2550000)
19:03:33.35 VCC 1 0 4 Vadis version: 6.7a.2775
19:03:33.35 VCC 1 0 6 entry - InitRunTime
19:03:33.35 VCC 1 0 6 exit - InitRunTime
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT received
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT return
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT received
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT return
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT received
19:03:33.35 VCC 1 0 6 WM_CCM_CONNECT return
19:03:33.35 VCC 1 0 6 WM_CCM_POKE received (hwnd = 2490954)
19:03:33.35 VCC 1 1 1 Using Vehicle Profile settings from profile module
19:03:33.37 VHA 1 1 1 System Logging is OFF
19:03:33.47 VCL 1 1 1 VctOpen: Serial RW timeout set to: 30000
19:03:33.47 VCA 1 1 1 OpenCommPort: port COM1 opened, baudrate = 115200
19:03:33.47 VCA 1 1 1 Force RS232 baud to 115200
19:03:33.47 VCA 1 1 1 Set Download VCT RS232 baud rate = 115200.
19:03:33.47 VCL 1 1 1 Request Frame Size=23 Data=
19:03:33.48 VCL 1 1 1 80,00,0E,00,1F,01,00,00,01,F4,00,00,03,E8,00,01,C2,00,00,00,03,51,81,
19:03:34.63 VCL 1 1 1 Response Frame Size=22 Data=
19:03:34.63 VCL 1 1 1 80,00,0D,00,1F,06,00,00,00,00,1F,01,12,34,00,00,00,00,00,01,18,81,
19:03:34.63 VCA 1 1 1 InitVCT2000: Serial RW timeout set to: 30000
19:03:34.63 VCL 1 1 1 Request Frame Size=17 Data=
19:03:34.63 VCL 1 1 1 80,00,08,00,10,02,00,00,00,00,00,00,00,00,00,9A,81,
19:03:36.33 VCL 1 1 1 Response Frame Size=17 Data=
19:03:36.33 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:36.33 VCA 1 1 1 VctListPackages: #pkgs = 0, free mem = 0
19:03:36.33 VCA 1 1 1 VctSelectPackage(, 01:>0000001)
19:03:36.33 VCL 1 1 1 Request Frame Size=30 Data=
19:03:36.33 VCL 1 1 1 80,00,15,00,10,04,00,00,00,00,00,00,00,10,A8,76,A1,01,AE,00,00,00,31,00,39,00,00,03,91,81,
19:03:38.16 VCL 1 1 1 Response Frame Size=17 Data=
19:03:38.17 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:38.17 VCL 1 1 1 Request Frame Size=61 Data=
19:03:38.17 VCL 1 1 1 80,00,34,00,1F,00,00,00,00,01,E8,48,00,03,D0,90,00,00,00,00,00,00,28,A0,00,00,00,00,00,00,00,
19:03:38.17 VCL 1 1 1 00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,04,2F,81,
19:03:39.91 VCL 1 1 1 Response Frame Size=17 Data=
19:03:39.91 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:39.91 VCA 1 1 1 InitVct_HW: Vct Hardware Initialized
19:03:39.91 VHA 1 1 1 Mk=1 Partner=INT Model=384 Year=2001 CG=2 Var=153 CG2=-1 Var2=-1
19:03:39.91 VHA 1 1 1 ECUDiagNum="08631773 A" ECUDiagID=4063 DiagSetupID=242
19:03:39.91 VHA 1 1 1 ECU Address = 0x11 FrameID = 0x000FFFFE BusType=1 TimingID=18
19:03:39.91 VCL 1 1 1 Request Frame Size=15 Data=
19:03:39.91 VCL 1 1 1 80,00,06,00,1D,01,00,00,00,00,00,00,00,A4,81,
19:03:41.38 VCL 1 1 1 Response Frame Size=17 Data=
19:03:41.38 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:41.38 VCA 1 1 1 InitVct_Diagnostic: Vct Diagnostic Application initialized
19:03:41.38 VCL 1 1 1 Request Frame Size=53 Data=
19:03:41.38 VCL 1 1 1 80,00,2C,00,1D,02,00,00,00,01,00,03,01,0A,13,40,11,00,00,00,00,00,00,0C,00,14,00,19,00,00,00,
19:03:41.38 VCL 1 1 1 1E,00,00,00,32,00,14,00,05,00,32,00,64,27,10,27,42,00,00,03,16,81,
19:03:42.95 VCL 1 1 1 Response Frame Size=17 Data=
19:03:42.95 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:42.95 VCA 1 1 1 InitVct_Diagnostic: Vct Diagnostic Protocol initialized
19:03:42.95 VCL 1 1 1 Request Frame Size=35 Data=
19:03:42.95 VCL 1 1 1 80,00,1A,00,1F,04,00,00,01,01,03,00,0F,FF,FE,00,40,00,13,FF,FF,00,00,00,00,00,03,B2,F0,03,00,
19:03:42.95 VCL 1 1 1 00,06,C7,81,
19:03:44.64 VCL 1 1 1 Response Frame Size=17 Data=
19:03:44.64 VCL 1 1 1 80,00,08,00,10,06,00,00,10,02,00,01,00,00,00,B1,81,
19:03:44.64 VCL 1 1 1 Request Frame Size=17 Data=
19:03:44.64 VCL 1 1 1 80,00,08,00,1B,0D,00,00,00,00,00,00,00,00,00,B0,81,
19:04:14.65 VCL 1 1 1 RecvLLPFrame returned = 0XFFFF7F18
19:04:14.65 VCA 1 1 1 VctSync returned (0XFFFF7F18)
19:04:14.65 VCA 1 1 1 InitVct_Diagnostic: Sync() returned (-33000)
19:04:14.65 VHA 1 1 1 InitVctForDiagnosticRequest: InitVct_Diagnostic returned (-33000)
19:04:14.65 VCC 1 0 6 VehDiagInit failed (-33000)
19:04:14.65 VCC 1 0 6 WM_CCM_POKE received (hwnd = 2490954)
19:04:14.66 VCA 1 1 1 DisConnected from VCT
19:04:14.66 VCC 1 0 6 WM_CCM_POKE return
19:04:14.66 VCC 1 0 6 WM_CCM_POKE return
19:04:14.66 VCC 1 0 6 entry - StartExec
19:04:14.66 VCC 1 0 6 exit - StartExec
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT received
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT return
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT received
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT return
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT received
19:04:14.70 VCC 1 0 6 WM_CCM_DISCONNECT return
19:04:14.70 VCC 1 0 6 WM_DESTROY
19:04:14.70 VCC 1 0 6 CcmDeleteWindow, hwnd = 0x26024a
19:04:14.70 VCC 1 0 4 DllMain - Process Detach (0X2550000)
 
#19 ·
Re: OBD-II / CAN / ISO9141 technical issues (we R obsessed)

we R obsessed,

Can you provide more information how communicating with ECUs goes? Do you have a complete example of the message sent to an ECU and a response from there?

My understanding from VADIS is that ECU number for Driver Door Module (DDM) on my S80 should be 43, but I see headers 00 E0 30 A2 with ELM327 based monitoring when moving window up and down. I cannot see how 43 would be encoded in that or 40 (CEM).

Another example is sending power head restraints down. Communication should be from CCM (29) to REM (46), but complete message what I see is
01 70 04 00 00 00 00 00 00 00 00 02 and again I do not see how 29 or 46 would be encoded in it. If I send the same message, then head restraints do go down, but that does not help me really.

When VADIS is communicating with the vehicle it would first do a read block by offset (B9 F0) to read ECU config, but since I do not know to what address to send it, I have not been able to get pass that. Do you know how to send this read block by offset request?

Please note that I ordered my ELM327 based vehicle communication tool from China and it is version 1.5a and must be some knock off version since elmelectronics.com has 1.3 their latest version. Also all the documentet AT command do not work as expected on it. What are you using to communicate with the vehicle?
 
#20 ·
Re: OBD-II / CAN / ISO9141 technical issues (sweedespeed)

Hi all,

Does anyone have any info on this? On my 2001 S80 CANBUS is behind relay and I have been able to brute force search for the request to open the CANBUS for OBD connector using ISO-9141 and what I have been able to reverse engineer from VADIS. Next step is to understand canbus format, but so far I have not been lucky enough to get any request to send a response. I know ECUs e.g 40 and tester is 13 and request to read ECU part number is B9 F0 from VADIS and also (http://www.google.com/patents?id=XmqoAAAAEBAJ&pg=PA4&lpg=PA4&dq=%22D2+protocol%22+Volvo&source=bl&ots=A0mT-drbI7&sig=tW7N_V8HzEhEM0edZOl3vHl0SxQ&hl=en&ei=h8aeSuOPEM-c8QbFsPSyAw&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=%22D2%20protocol%22%20Volvo&f=false). Also do not know if FrameID FFFFE is part of it. How to format a request from that data is still a mystery to me. Is D2 protocol extension of ISO 15765? If it is then http://en.wikipedia.org/wiki/OBD-II_PIDs CAN Bus format section might help.

Thanks,
Sweede
 
#21 ·
Re: OBD-II / CAN / ISO9141 technical issues (sweedespeed)

I'm also interested in this info, I'd like to display a message on the DIM (driver information module) text-message screen in response to an alert from a Valentine1 (radar detector).

I even had a Volvo tech email Volvo technical support:
Quote »

As of now Volvo does not have a program to add software to a vehicle at the dealer ship or support level because of the legal laws in this country.

Volvo developed its own coded can bus language called VOLCANO. . Your friend is correct to state the he can read the information and to write a patch or to add a line of text to a Node is possible. It could note be done at least at this time. Your friend I'm sure understands that writing a line of code could have a detrimental effects on other nodes with in the can bus. He might write a code for the radar detector but that line may also affect how the transmission shifts or how the power seat work. This is called shared protocol and if two nodes share the same id a conflict will arise. He would not only need to know the specific language but all the program commands of the system. IE -both the can bus and possible the Lin system.

Remember Vida is only the deliver tool here. If your friend was to ever write and some how get the program in the car that would only cause problems at VITAL..
If the car ever came in for an update- suppose a recall and Vital determined that the cars program has some been tamper with the down load would stop or worse the pie servers data base for that vehicle would be come corrupted to the point that the car may go into program mode and not be recoverable

-while sound and accurate is unpractical at this time -
Which says to me "bring it on"

Has anyone managed to extract ASCII from the CAN messages?

Here are the notes I've taken so far:
- Low speed CAN network operates at 125Kbps. CAN high speed is 500kbps.

- Low speed CAN is terminated by 120 ohm resistors in the SRS (supplemental restraint) and DIM (driver information) modules ('05 S40).

- The communication between BCM (brake control) and BSC (body sensor cluster) is proprietary (developed by the system manufacturer)

- The communication between SRS and OWS (occupant weight sensors) is proprietary (developed by the system manufacturer)

- "High security" modules: CEM (central electronic), ECM (engine control), BCM (brake control) - must authenticate with each other, unique stored rolling codes.

- Volvo uses the Volcano design system for it's networks (http://www.mentor.com/products/vnd/). This consists of some high level tools, and a software stack that allows API calls. Without knowing what their API calls are, it is going to be very hard to generate our own messages.

- Examples of Volcano calls are volcano_read() volcano_write(), imm_input(), imm_output(), etc... and they create "virtual wires" between components in the car. The code that sends CAN signals is automatically generated by the Volcano compiler, and stored in a central database. When a developer wants to actuate a function on some other module, he looks up the database call and Volcano determines the correct CAN message. This database may be called "PIE" or "SBS" but not sure.

- The Volcano compiler outputs assembly in S record format. S records are standardized and it may be possible to decompile them with the right tools.

- Every CAN message starts with a 13 bit identifier. It includes up to 8 bytes of data, and a checksum.

- The ECM has two CAN addresses, because it has two MCU's. One is hooked to the low and high speed networks, and provides communication between the two. The second is hooked exclusively to the low speed network.

Modified by theshadow27 at 4:14 PM 9-10-2009
 
#22 ·
Re: OBD-II / CAN / ISO9141 technical issues (sweedespeed)

Sweede,

In your example for the headrest:
01 70 04 00 00 00 00 00 00 00 00 02
is in binary:
000000010111000000000100&#8230;00000010
CAN uses a 13 bit address field, so:
Address field (13 bits): 0000000101110 = 0x2e = dec 46
which is the number you expected, no?

Also,
00 E0 30 A2
Is in binary
00000000111000000011000010100010
So, the first 13 bits are:
0000000011100 = 0x1c = dec 28
maybe there is a different module at that address?

JSD
 
#23 ·
Re: OBD-II / CAN / ISO9141 technical issues (theshadow27)

Here is ID list from MY01 VOLVO S60.CAN_BUS lowspeed 125Kbps.100% ID-116 is for RTI unit CD-Version.Any idea for the rest of ID"s?
P.S.All is decemal(not HEX).EU Market.

ID DLC D0 D1 D2 D3 D4 D5 D6 D7
8 8 128 0 0 7 31 64 64 127
12 8 8 152 0 0 128 0 0 0
20 8 13 0 28 64 96 17 8 0
24 8 30 0 0 0 0 0 0 0
28 8 192 0 0 29 63 0 0 0
36 8 64 0 0 0 176 48 0 73
40 8 193 17 0 40 7 0 0 0
44 8 64 0 2 0 0 0 0 0
56 8 64 91 64 1 137 3 20 0
60 8 64 0 0 1 53 144 16 48
64 8 128 0 16 0 15 0 29 28
68 8 192 0 0 39 128 194 0 192
72 8 128 0 8 128 0 253 32 0
76 8 192 169 35 170 143 32 8 29
80 8 0 131 193 9 31 0 0 0
88 8 192 0 33 8 24 48 0 0
92 8 64 0 0 0 0 0 0 0
96 8 0 0 0 0 3 251 0 0
100 8 0 0 0 0 0 22 0 0
104 8 0 0 0 4 71 2 157 30
108 8 0 0 0 0 0 0 1 3
112 8 0 0 0 0 0 0 160 0
116 8 64 0 0 0 0 0 0 6

Modified by dani99 at 9:49 AM 11-10-2009
 
#24 ·
Re: OBD-II / CAN / ISO9141 technical issues (dani99)

Afaik there's no good way to tell except push buttons on the module and look for an address spike. Still waiting on my CAN boards ordered in September
Image
 
#26 ·
Re: OBD-II / CAN / ISO9141 technical issues (dani99)

Quote, originally posted by dani99 »
"Has anyone managed to extract ASCII from the CAN messages?"

Yes,I have a log file.(CAN-BUS 125Kbps can 2.B)

You have CAN messages with ASC-II encoded characters? Please http://********************/smile/ememail.gif !!!