$30 OBD2 CAN tool

[RScott]

Hi,

I just bought an OBD2 USB adapter ("ElmScan 5" from Amazon for $30). It uses the ELM327 chip (careful; there are apparently Chinese knock-offs out there). Most people just buy it and use the software that comes with it, or use other pre-made software. However, you can also use it with a terminal program (typing in commands), or write software for it, which I did.

The Volt has 2 OBD2 connectors. I was able to use the one on the driver's side, but couldn't get anything from the one on the passenger's side (it could be a protocol the adapter doesn't understand, or my programming!). I know that there is a SWCAN bus, but there do not seem to be any reasonably priced adapters for SWCAN yet (although it seems like existing adapters could be changed at little cost to handle SWCAN).

Normally, OBD2 works by sending commands to request data ("I want to know the RPMs of the engine", "Here you go!"). However, I used the ELM327's "Monitor All" (MA) mode, which lets you see all the data on the CAN bus. Actually, most, as the Volt uses a 500kbps CAN bus, and the ElmScan is limited to 500kbps -- but it sends ASCII with other information attached, rather than binary, which can cause the buffer to overflow, so you lose a bit. But there are reasonably priced ($50) adapters out there that overcome that.

The MA mode shows output like this:

451000000000000
096BFF00A120000<DATA ERROR
09739800A
09800000A0080000A16
0C700000000
23872<DATA ERROR
...


According to the CAN specs, the first 3 characters are the hexadecimal ID for whatever is sending the data (451, 096, 097, 098, 0C7, 238 in this case).

After about a week, I've found that there are a bit over 100 of the CAN ID's. With that knowledge, I now have it recording all data (that I can later play back, much faster if needed, to see which numbers are changing and how), that can all appear real-time on a screen (3 columns each with about 35 rows, showing the 3-digit CAN ID and up to the maximum 16 characters of data). Some update really fast, others slowly. Some numbers never change, some rarely change, others change many times per second. Some make no sense, some are obvious (e.g. the VIN).

One catch is that you cannot use the MA mode while also requesting data, so you have to stick with whatever you can listen to on the bus. And without SWCAN, it looks like you cannot get thinks like GPS data, changing volume of the radio, door locks, etc.

But, I've been able to decode a number of things so far, such as the VIN (in 2 packets), MPH (which is actually encoded as 1/100MPH, so if you are going 1.23MPH it would be stored as 123), shifter (PRNDL), accelerator position, and I *think* I may have found the battery SOC (which would also allow for current power in watts, and instantaneous kWh/100 miles).

My main goal has been to find a way to track multiple routes and see which one is most efficient in using energy (for example, a slightly longer route may use less energy than a shorter route, if it is less hilly and a more advantageous speed limit). For this purpose, it looks like I may have enough data.

[scottf200]

Cool work!

Have you seen this post and entire thread.

http://gm-volt.com/forum/showthread....0997#post90997

WOT stated this in it:

Finally, there IS some General Motors OBD2 MODE 6 and CAN data published into the public domain that might assist you in your efforts located here:http://service.gm.com/gmspo/mode6/

I put the data I got from the Scanguage here:
So-what-will-the-Volts-OBD-show-on-a-product-like-ScanGuage
http://gm-volt.com/forum/showthread....3472#post63472

[scottf200]

According to the CAN specs, the first 3 characters [12 bits] are the hexadecimal ID for whatever is sending the data (451, 096, 097, 098, 0C7, 238 in this case).

Where were you looking for CAN specs?

The CAN protocol supports two message frame formats, the only essential difference being in the length of the identifier. The “CAN base frame” supports a length of 11 bits for the identifier (formerly known as CAN 2.0 A), and the “CAN extended frame” supports a length of 29 bits for the identifier (formerly known as CAN 2.0 B).

I found this: http://www.specifications.nl/can/pro...K_protocol.php
and this: http://www.gaw.ru/data/Interface/CAN_BUS.PDF
and this: http://www.can-cia.org/index.php?id=164

[RScott]

Finally, there IS some General Motors OBD2 MODE 6 and CAN data published into the public domain

I still need to look at it some more, but it looks like most of that won't be too useful for the type of data I'm looking for. But for figuring out trouble codes, it provides a lot of information. And reading between the lines, it may provide clues as to how data may be transmitted.

I put the data I got from the Scanguage here:
So-what-will-the-Volts-OBD-show-on-a-product-like-ScanGuage
http://gm-volt.com/forum/showthread....3472#post63472

That is definitely useful. I haven't even started looking at what the generic OBD2 PIDs will produce.

Where were you looking for CAN specs?

I didn't look too far (you found some great reference sources there!). I was mainly looking at the very basic information, such as 11-bit versus 29-bit addressing. Fortunately, the OBD2 interface takes care of most of the CAN details, and I can just look at the output.

The one catch is trying to find a way to read the SWCAN bus (the data is sitting there on the OBD2 interface, but I don't know if there is any way to read it with the adapter I'm using). That one uses the 29-bit addressing, and I believe would be for messages classified as something like "non-essential functions".

The interesting thing is that none of the data is encrypted in any way (at least any of the data I've encountered). For example, there's one byte that goes from 00 to FE when you press all the way down on the accelerator. If you're monitoring the ID 1A1, you're going to notice that very easily.

I'll be posting more about the IDs I am able to decode.

[N Riley]

All I can say is: YOU GUYS!!!!

[RScott]

Just to give everyone an idea of where I'm at, you can check out http://www.evtools.info/kanc.htm . It takes raw data and turns it into something a bit more palatable to the average person.

It's a Google Map that has a marker (one for every ten latitude/longitude updates on the CAN bus), and lets you see the route you took, along with basic information (battery SOC, MPH, engine RPM (0 if off), watts used).

More than anything, it's really a 'proof of concept' hinting at what might be possible.

[RScott]

Here are a list of some questions I hope to answer with the data I have been collecting:

o How does the efficiency (kWh/100 miles) change at different speeds? Especially when the second motor engages ~70MPH?
o How does the efficiency of the regen change at various speeds when going downhill?
o How does the efficiency of going at a constant speed compare to having to stop in the middle (e.g. at a traffic light)?
o In Mountain Mode, are the higher engine RPMs more or less efficient than the normal lower RPMs?
o How much extra energy is used in a 'jackrabbit' start versus slow acceleration?
o Which is more efficient (at various speeds), air conditioning or having the windows open?

[Rusty]

o How does the efficiency (kWh/100 miles) change at different speeds? Especially when the second motor engages ~70MPH?

The DashDAQ looks like it'll be really good at answering questions like this, especially the first (when I can get to crunching all the data) BUT...

It looks like you have the same problem in New Hampshire (did I get that right?) I have here in San Diego. D*ng difficult to find a tract of flat roadway for repeatable testing! And are you about to go off-line for repeatable testing due to winter? Of course, that should open up all sorts of other testability options for you. There's a whole separate section of PIDs for HVAC operation...

As to different speed efficiencies, the DashDAQ calls out each motor's speed (RPMs), torque, current, and voltage (though I've never seen either motor's voltage differ from the battery's). I've seen Motor A engaged all the way down to 45 MPH or so, and I've seen it still disengaged up into the 80s.

I don't know if the PID ordinals I get from the DashDAQ (in decimal) match up to the ordinals you're seeing on the CAN tool. Would if help if I post the list again (or send you a PM) of what I'm seeing there?

[scottf200]

Just to give everyone an idea of where I'm at, you can check out http://www.evtools.info/kanc.htm . It takes raw data and turns it into something a bit more palatable to the average person.

It's a Google Map that has a marker (one for every ten latitude/longitude updates on the CAN bus), and lets you see the route you took, along with basic information (battery SOC, MPH, engine RPM (0 if off), watts used).

More than anything, it's really a 'proof of concept' hinting at what might be possible.

That is TOO cool. Helpful to zoom in and changing the map to terrain.

No doubt you are thinking of different options/icons to use for:
a) speeds (24-30,31-35,36-40,41-45,etc)
b) SOC (gradient coloring? and green,yellow,red shades)
c) ICE on/off (as even in CS mode the ICE may turn off)
d) etc

[RScott]

The DashDAQ looks like it'll be really good at answering questions like this, especially the first (when I can get to crunching all the data) BUT...

I'm actually in Massachusetts (the Google Maps I posted was from a trip to New Hampshire), but yes, it's tough finding a good spot for repeated testing. My hope is to simply collect enough data that I can crunch it to produce a lot of useful results with just standard driving, but it's too early to tell right now. If elevation data from GPS is available (as latitude/longitude is), that could be extremely helpful (the software could figure out automatically where the car was driven in flat areas, check for constant speed, etc.).

I haven't found the motor torques yet; if I get those, it would help out a lot.

I believe the DashDaq numbers are unique to DashDaq (the numbers in the 1500-1700 range that I saw posted here). The ID numbers I get from CAN range from 150 to 1927.