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.

Cool work!

Have you seen this post and entire thread.

http://gm-volt.com/forum/showthread.php?5328-Volt-Diagnostic-Tool&p=90997#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.php?5784-So-what-will-the-Volts-OBD-show-on-a-product-like-ScanGuage&p=63472#post63472

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/protocol/can_UK_protocol.php
and this: http://www.gaw.ru/data/Interface/CAN_BUS.PDF
and this: http://www.can-cia.org/index.php?id=164

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.php?5784-So-what-will-the-Volts-OBD-show-on-a-product-like-ScanGuage&p=63472#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.

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

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.

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?

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?

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

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.

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

The trick is figuring out a way to display the maximum amount of data, without overloading the person looking at it. I started with lines instead of markers, but those don't display information well (but are less cumbersome than tons of markers). You can change the color and width, but displaying information (such as speed) with color isn't as easy as I thought it would be.

My latest endeavor with the data is identifying points along routes, and checking to see which of several ways between those points is most efficient (e.g. the normal, faster route versus the scenic route). I've still got a lot of work to do, but the first one looks like it produced very useful results.

Leaving my house, I usually go a different way than when coming back home, for a stretch of about .8-.9 miles. Looking at the data, it looks like I would be slightly more efficient switching the route I come back (.96kWh versus .85kWh), but switching the route that I take leaving would make a very big change (.31kWh versus .56kWh). It looks like I could save .36kWh for most trips I take by changing that one small part of the route that I take, adding an extra 1-1.5 miles of range to the battery.

Again, I've got a lot more work to do with this, but I was amazed at how much difference there was between two different routes that do not seem very different (the terrain, speed limits, and number of stops are similar).

The trick is figuring out a way to display the maximum amount of data, without overloading the person looking at it. I started with lines instead of markers, but those don't display information well (but are less cumbersome than tons of markers). You can change the color and width, but displaying information (such as speed) with color isn't as easy as I thought it would be.

I figured it would be a selectable option. You can see how this guy is using gradient coloring to represent efficency.
http://www.voltstats.net/Stats/OwnerMap

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.

I dunno. You seem to have access to a lot of data I don't on the DashDAQ, and your number range completely encompasses the DashDAQ's range... For example, do PIDs 1632, 1634, 1593, and 1591 look interesting to you? Those would be Motor B current, voltage, speed, and torque, respectively.

I figured it would be a selectable option. You can see how this guy is using gradient coloring to represent efficency.
http://www.voltstats.net/Stats/OwnerMap

Excellent -- that looks like it might work well. My initial attempt at using colors failed, but that looks good.

I dunno. You seem to have access to a lot of data I don't on the DashDAQ, and your number range completely encompasses the DashDAQ's range... For example, do PIDs 1632, 1634, 1593, and 1591 look interesting to you? Those would be Motor B current, voltage, speed, and torque, respectively.

The big difference is that DashDAQ requests the information, whereas I'm just listening to what the car is sending out whenever it sends it. I think there is a ton of information that you can request, if only you know how to do it (which DashDAQ does; not only does it have the Volt info, I believe it also has generic Chevrolet info as well). I believe there are only 102 CAN IDs that are used by the Volt (on the 500kbps bus, at least), although some of them provide multiple pieces of information. I can figure out some of what the car is sending, but I think there are way too many options for what you can request (and some could potentially do things, such as locking doors, that makes experimenting a bit risky). FWIW, I don't have any CAN IDs from 1,424 to 1,903.

It's possible that GM didn't give some of the information that I've found to the DashDAQ people (either because they consider it proprietary, or perhaps there are varying licenses or whatever).

As I sift through all the data, I've found that I need to take more and more notes on everything.

I'm starting a page at http://www.EVtools.info/ChevyVoltOBD2CAN.html that covers what I've discovered so far (I'd simply post here, but would need to keep editing posts all the time). The most useful information:

The 105 CAN IDs:



096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C5 0C7 0C9 0D1 0D3
0F1 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3
1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB
200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1
2F9 32A 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB
3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A
530 589 770 772 773 778 77D 77F 787


And the data I've discovered so far:

0C9 Byte 5 Accelerator 0 (0%) to 254 (100%)
0F1 Byte 2 Brake 0 (0%) to Unknown (254?) Typical pressure on brake pedal generates about 30.
135 Byte 1 Drive Position 0=Park, 1=Neutral, 2=Drive/L, 3=Reverse
1A1 Byte 8 Accelerator 0 (0%) to 254 (100%)
1C3 Byte 8 Accelerator 0 (0%) to 254 (100%)
1EF Bytes 3-4 Gas Engine RPM RPM
1F5 Byte 4 Shift Position PRNDL 1=Park, 2=Reverse, N=Neutral, D=Drive, L=Low
206 Bytes 1-2 Battery SOC .250kWh Units possibly .244kWh
32A Bytes 1-4 GPS Latitude Milliarcseconds
32A Bytes 5-8 GPS Longitude Milliarcseconds
3E9 Bytes 1-2 Speed 1/100 MPH 55MPH would be 5500 (0x157c)

And at some point soon, I hope to be able to provide the program I wrote to collect the data, to allow others the ability to start recording their driving. The neat thing is that the program records all data on the primary CAN bus, so once you've collected the data, it can be used later after new information is discovered (for example, I don't think elevation is sent on the primary CAN bus, but if it is, you will have the ability to use that information later, since it will get recorded).

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.

I've got another version up at http://www.evtools.info/kanc2.htm.

This one is different -- instead of lots of markers, it shows the path (like you'll see in Google Maps if you ask for directions, except these are generated on the GPS data from the Volt). The path is in red where you are using energy, green when you are gaining energy (regen). Both are darker the more electricity used/generated. This one also shows speed, miles in the segment, kWh used in the segment, and kWh per 100 miles (which varies a lot from segment to segment). In this map, you'll see lots of regen, as much of it is downhill.

This one gives you a better idea visually of a route, and where the most efficient and inefficient sections are. I'm working my way to having multiple trips compiled together, to compare different ways of getting from one point to another.

I do have another version of the original that has better markers (color-coded with the speed on them), but I'm still working on that.

I've got another version up at http://www.evtools.info/kanc2.htm.

This one is different -- instead of lots of markers, it shows the path (like you'll see in Google Maps if you ask for directions, except these are generated on the GPS data from the Volt). The path is in red where you are using energy, green when you are gaining energy (regen). Both are darker the more electricity used/generated. This one also shows speed, miles in the segment, kWh used in the segment, and kWh per 100 miles (which varies a lot from segment to segment). In this map, you'll see lots of regen, as much of it is downhill.

This one gives you a better idea visually of a route, and where the most efficient and inefficient sections are. I'm working my way to having multiple trips compiled together, to compare different ways of getting from one point to another.

I do have another version of the original that has better markers (color-coded with the speed on them), but I'm still working on that.
Very cool. It is even cooler when you turn "MAP->terrain" on! And then zoom in (+) gets cooler yet!
Can you put direction of travel or odometer every 1/8 miles or something? Just thinking out loud as I was trying to guys based on green/red of you direction. I can tell if I zoom in on terrain and see the topo lines/numbers.

I guess it's time for an update.

I'm getting a bit too intimate with the numbers; I really ought to take a break. I've found a number that is sent a couple times a minute that appears to be the number of seconds that have elapsed since the car was built. More importantly, I've found the elevation, to go along with latitude/longitude.

I'm not quite sure where I'm headed with all this. The first thing I want to do is make the 'recorder' piece available to anyone who wants it (that hooks up the $30-or-so OBD2 adapter to a laptop/netbook, to record all data that goes over the bus). That way, anyone interested can start recording data ASAP.

As for what to do with the data, I keep doing more, exploring, but haven't gotten as far as I had hoped (as I'm also busy decoding all the data I can, as well as doing some non-Volt things too!). I've added a tool that displays all the log files, letting you see where you went, the length of the trip, the "Bird's Eye" mileage and kWh per 100 Bird's Eye miles (e.g. to better determine which route is more efficient). I've also added code to extrapolate data, so that you can get, for example, speed readings every 1/100 or 1/1000 second (extrapolated, so it isn't exact), which overcomes the problem of getting different data at different times. I'm hoping to get it so that it will keep track of every point along a route (perhaps every foot or 10 feet or so), and store data about that point (average speed, kWh used, elevation, etc.), leading to more ideas about what to add. I'm also thinking of adding a webserver that would let you interface with it and Google Maps (like the 2 I've posted about here).

I'm wondering, too, if all new GM cars have so much data so easily accessible, or if this is new for the Volt.

Have you tried Torque for android? Is it compatible. I've ordered a bluetooth version of ODBII and hope to get i in a few week.
Most cars have a lot of data on the ODBII/Can bus. Google "torque android" to see some of the stuff people have done. I really like the video overlay so N can mount a phone watching me and the road and get the data overlaid on it.

Have you tried Torque for android? Is it compatible. I've ordered a bluetooth version of ODBII and hope to get i in a few week.
Most cars have a lot of data on the ODBII/Can bus. Google "torque android" to see some of the stuff people have done. I really like the video overlay so N can mount a phone watching me and the road and get the data overlaid on it.

The catch is that most (probably all) of these tools work in a "Request Information" mode (you tell the car what information you want, and it sends it to you), where there is a bit of information that is required by law (such as emissions data), and a lot that is proprietary (some to a make, some to a model).

But I'm not aware of anyone else using the "Monitor All" mode (where you don't make any requests, you just sit back and watch what the car is sending on its own). This may be pretty new; a quick peek at another car showed that there was very little being sent. However, none of it is documented, so it takes a lot of time to figure everything out. With "Monitor All", you don't get to choose what you get -- but it is ideal for recording every day driving (whatever you get, you can later analyze).

Torque does look really nice. One drawback, though, is that it likely only supports either the basic PIDs (the ones required by law), or perhaps also the GM-specific PIDs (which can include a lot more), but not the Volt specific ones (which I believe only DashDAQ offers, at an extra cost).

From my reading all 327-based ODB2's should support monitor all mode (its in the chipset
http://elmelectronics.com/DSheets/ELM327DS.pdf)
I agree that figuring out what PID is what will be a challenge.. though I've seen posts from you and others which should help.

Torque allows plugins, and my understanding is there is a demo app that shows all records all it captures, so I'm hoping that records what I need. If not I'll write a Volt-specific app (probably want that anyhow). Mostly I want real-time KWusage, Regen and maybe engine RPM and Fuel usage. But we may want to explore a lot more for school.

Having all the display/recording on a android phone makes it very portable and, if you have an old droid around (which I do), rather cheap.

I'll post again as soon as I get my device and get it going.

From my reading all 327-based ODB2's should support monitor all mode (its in the chipset
http://elmelectronics.com/DSheets/ELM327DS.pdf)

Indeed they do. The catch here, though, is that the software has to support it. I don't have any idea yet if any other cars provide the level of data that the Volt does. And to support it for the Volt, they need to switch to the 500kbps mode (or else the majority of the data would get lost). And I don't believe the Volt uses any standard IDs, so it would be a moot point without that information.


Mostly I want real-time KWusage, Regen and maybe engine RPM and Fuel usage.

I believe all that can be done with the DashDAQ, so it is likely that *if* you have or can get the IDs, you'll be able to get that data.

WARNING: It is a cylon device (or Skynet, depending on the mythology you prefer), which has now taken control of your vehicle.

Torque does look really nice. One drawback, though, is that it likely only supports either the basic PIDs (the ones required by law), or perhaps also the GM-specific PIDs (which can include a lot more), but not the Volt specific ones (which I believe only DashDAQ offers, at an extra cost).

Even the basic Torque allows user defined PIDs (at least on a quick look last night after downloading it, it looks like it does). So if the Volt ECU/PIDs can be identified, Torque may well be able to handle them.


Torque allows plugins, and my understanding is there is a demo app that shows all records all it captures, so I'm hoping that records what I need.

Bluetooth may not be able to keep up with the data rate. YMMV. But if it works, that'd be cool.


I believe all that can be done with the DashDAQ, so it is likely that *if* you have or can get the IDs, you'll be able to get that data.

Yes, the DashDAQ can capture real-time KWusage, Regen and engine RPM (motor RPM and transaxle RPM too - the latter being a much more accurate speed gauge then what it captures from the vehicle speed PID it uses). Fuel usage is a different story. It currently can capture fuel usage, *OR* it can capture motor parameters. It doesn't do both. DrewTech is Beta testing a version of the firmware that corrects that.

OK, here's an updated webpage (http://www.evtools.info/display3.htm) that I think does a much, much better job of showing what the Volt is capable of doing with OBD2 logging. I still have more data to add to the page, and a lot more to decode, but progress is being made!

Here is a preview; with the actual webpage (link above), it is a bit interactive.

http://www.evtools.info/img/display3.jpg

I can guess that "ACC" is accelerator position (DD calls at APP - Accelerator Pedal Position IIRC, and it's 0-100% there too). It looks like BRK is brake, but do you have a feel for whether that's regenerative or requested? The DD's units are in Ft-Lbs (and can range up to 2800 IIRC for requested, and I've not seen more than 800 Ft-Lbs regenerative).

I've never seen the DD call out more than 115-120 kW usage, so I'm really surprised by the 198 in Drive2. Are you sure that means what you think it means? The DD doesn't have a signal for kW in any case, it's got amps and volts and I have to do the math myself. Are you seeing a single signal (that's h*ll on dyslexics!) that you believe represents kWh from the battery?

I can guess that "ACC" is accelerator position (DD calls at APP - Accelerator Pedal Position IIRC, and it's 0-100% there too). It looks like BRK is brake, but do you have a feel for whether that's regenerative or requested? The DD's units are in Ft-Lbs (and can range up to 2800 IIRC for requested, and I've not seen more than 800 Ft-Lbs regenerative).

I've never seen the DD call out more than 115-120 kW usage, so I'm really surprised by the 198 in Drive2. Are you sure that means what you think it means? The DD doesn't have a signal for kW in any case, it's got amps and volts and I have to do the math myself. Are you seeing a single signal (that's h*ll on dyslexics!) that you believe represents kWh from the battery?

Yes, "Acc" is accelerator. "Brk" is the brake pedal position (requested), but unfortunately do not know the units (as I cannot even accurately reproduce the maximum number, unlike the accelerator). The maximum I see for Brk is about 78 (when pushing down as hard as possible on the pedal, what you would normally only occur if, say, they were a pedestrian in front of you).

I believe the kW reading is a total of whatever is being drawn from the battery, including the traction motor, generator motor, accessories, etc. The number I get needs to be multiplied by .09 to get kW, but I believe it is correct. I'm not quite sure what the units would be (the .09 isn't as wacky as it looks, it's 1/10,000 times 3600 seconds divided by 4, as the battery goes by 1/4wH increments).

The 'Drive2.txt' file has a 0->60 test in it (where you see the huge kW numbers, approaching 200). The calculations I ran showed the kW number corresponding nearly exactly to the kWh drain in the battery (2139 vs 2142). When charging at 12A and the car is off, the number I get is 15, which works out to -1.35kW, which seems accurate (as there is some noticeable electric usage in the car right after it is turned off).

Summary: help me pick a $50 present for myself.

I was very excited back in October when these OBD2 threads started popping up -- besides this one, there's a couple on the DashDAQ. Initially I was going to go ahead and get a DashDAQ, but that's a steep price and in the last couple months I've had to reign in my cash flow a bit. So I put that whole thing on pause.

I took a look at this thread, which apparently enables a poor-man's view of the OBD2 data, but I decided I didn't have time to even do that.

Well, now a family member has asked me for a $50 gift idea for myself, and I've already given out all my other ideas (books etc.). So I figured I might as well get one of these cheap OBD2 readers and have a little fun with it, even if it doesn't give me the Volt-specific parameters like MGA/MGB torque, battery points, etc.

The "ElmScan 5" mentioned in the first post in this thread doesn't seem to be available anymore; well, that's according to the scantool.net site although it still appears as a purchasable product on Amazon.com . In its place they offer the "OBDLink SX" scan tool, which terminates in a USB connector so I guess is intended for laptop use. I'd prefer Bluetooth and Android compatibility so I can idly fiddle with it on my cell phone without cable hassle.

Can you all recommend a $50 product for reading OBD2 data, even if it doesn't give you the Volt stuff? If it requires a Windows laptop for reading then I'll live, but interfacing to an Android app would be awesome. If USB only then I can get the necessary cable, but if it can do Bluetooth then that's even better.

The OBDLink SX is right in my target price range ($50) so if that's a decent one that I'll run with that. Just looking for some confirmation. Thanks!

Summary: help me pick a $50 present for myself.

I was very excited back in October when these OBD2 threads started popping up -- besides this one, there's a couple on the DashDAQ. Initially I was going to go ahead and get a DashDAQ, but that's a steep price and in the last couple months I've had to reign in my cash flow a bit. So I put that whole thing on pause.

I took a look at this thread, which apparently enables a poor-man's view of the OBD2 data, but I decided I didn't have time to even do that.

Well, now a family member has asked me for a $50 gift idea for myself, and I've already given out all my other ideas (books etc.). So I figured I might as well get one of these cheap OBD2 readers and have a little fun with it, even if it doesn't give me the Volt-specific parameters like MGA/MGB torque, battery points, etc.

The "ElmScan 5" mentioned in the first post in this thread doesn't seem to be available anymore. In its place there is the "OBDLink SX" scan tool, which terminates in a USB connector so I guess is intended for laptop use. I'd prefer Bluetooth and Android compatibility so I can idly fiddle with it on my cell phone without cable hassle.

Can you all recommend a $50 product for reading OBD2 data, even if it doesn't give you the Volt stuff? If it requires a Windows laptop for reading then I'll live, but interfacing to an Android app would be awesome. If USB only then I can get the necessary cable, but if it can do Bluetooth then that's even better.


I've been using
http://www.ebay.com/itm/Mini-ELM327-OBD-II-OBD2-Bluetooth-Auto-scan-tool-v1-5-/250947197767?pt=Motors_Automotive_Tools&vxp=mtr&hash=item3a6d9e5b47#ht_4464wt_1187
and torque. Still not getting any volt specific (searching for PIDs is a slow process and I'm overworked and my wife thinks I'm spending too time on th volt as it is.) However I'm not having any problem in talking to the vtech via the phone, so to me its a software issue. The torque developer said he may provide Monitor All in the plugin support, though if it gets to be xmax break and nothing happens I may develop my own low level stuff from scratch. (there are various open-source OBDb low-level tools (most are GPL, but I'm okay with a GPL release of what I learn about the volt). If I build on torque there are lots of stuff worth the $5 app fee, (lots of nice graphics and other stuff) so I'm hoping Ian will add what I need.

Summary: help me pick a $50 present for myself.

It sounds like ScanTool pulled a fast one -- deciding to discontinue the ElmScan 5, selling it cheap on Amazon ($30) to get rid of excess stock, and only then announcing that it is being discontinued. I had assumed that $30 was their normal discounted price on Amazon, but it now appears in their "discontinued" section. If anyone is looking to buy one, now is the time to do so while it is showing as available on Amazon.

The main drawback I found to the Elmscan 5 is that it was limited to a 500kbps connection to the computer, which caused data to sometimes get lost. In most cases, it isn't a big deal (as much of the data is transmitted often enough that losing some isn't a problem). But you never know if something useful might get lost. I'm not sure of the OBDLink SX offers a faster connection; their site doesn't mention it. Their claim of a large buffer should get around the problem even at 500kbps, though (the Elmscan 5 has a 256 byte buffer).

Something else to be aware of is that there are some cheap no-name OBD2 readers out there that use counterfeit ELM chips. And some may not support speeds high enough to be worthwhile (if you're thinking of using the "monitor all" mode, 500kbps should be the minimum considered; the ElmScan 5 and presumably the OBDLink SX do 500kbps).

The OBDLink SX is right in my target price range ($50) so if that's a decent one that I'll run with that. Just looking for some confirmation. Thanks!

So, it's Christmas Day and I did indeed get an OBDLink SX. I just now installed the software on a laptop and tested it out with my Volt and it connects up OK and read some values, so I know that the basic setup is good.

Next I'll dig into this thread and see what kinds of things I can look at (and which ECUs to talk to). If anyone wants to give me some initial guidance, I'm all ears! I'm aware that I won't be able to read a lot of the Volt-specific things. It's a start.

Merry Christmas!

As I sift through all the data, I've found that I need to take more and more notes on everything.

I'm starting a page at http://www.EVtools.info/ChevyVoltOBD2CAN.html that covers what I've discovered so far (I'd simply post here, but would need to keep editing posts all the time).

I head up the open vehicles project (www.openvehicles.com) - a smartphone app, server and car module to allow remote monitoring and control of EVs. Our first supported vehicle was the Tesla Roadster, and we've had a lot of enquiries from European users (who are just now getting Volt/Amperas and don't have OnStar for remote cellular access) about OVMS for their Amperas.

It seems we have a lot of similarity between our projects, particular regarding CAN hacking. Thanks for publishing these notes. They are an excellent start with this.

We've got some developers in Germany starting to work on their Amperas - trying to get SOC, GPS Location, Speed, etc, off the CAN bus then on to the OVMS servers for display in smartphone apps.

No specific questions / feedback at the moment, but I'm hoping we can co-operate on this. With the Tesla Roadster, we had four guys working on decoding the can bus and have made excellent progress (decoding almost the entire bus, and 99% of the important stuff). Perhaps something similar to Volt/Ampera can have similar results.

I head up the open vehicles project (www.openvehicles.com) - a smartphone app, server and car module to allow remote monitoring and control of EVs.
...
No specific questions / feedback at the moment, but I'm hoping we can co-operate on this. With the Tesla Roadster, we had four guys working on decoding the can bus and have made excellent progress (decoding almost the entire bus, and 99% of the important stuff). Perhaps something similar to Volt/Ampera can have similar results.

That is something I'm sure a lot of Volt/Ampera owners would *love*.

If you aren't yet aware, OnStar claimed about 5 months ago that they were releasing an API for developers, but they never contacted those that were interested since then (including the person that runs www.voltstats.net, who fortunately got access to an early now-confidential API). But, I believe some people have simply written scripts to log in and download the data as if they were a user accessing the site.

The Volt gets pretty complex (e.g. it has several different OBD2 buses, only one of which I have been able to access, so there may be a lot of data that is harder to access), but fortunately there is a lot of useful data that is easy to access.

All of the data that I have been accessing is through the CAN "monitor all" mode (which listens to whatever the car is sending), rather than sending specific requests (as most OBD2 applications do). The nice thing about that is that all the data is just sitting there waiting to be interpreted (and can easily be logged, even if you have no idea what it is yet). My focus has been on collecting data that can later be analyzed (one of the first ideas being to check two different routes to see which uses less electricity).

I hope to start a new thread soon with the program that I am using to collect the data, so that Volt/Ampera owners who are interested can start collecting data from their cars, either to help decode the CAN data or to save the data for future analysis.

If you aren't yet aware, OnStar claimed about 5 months ago that they were releasing an API for developers, but they never contacted those that were interested since then (including the person that runs www.voltstats.net, who fortunately got access to an early now-confidential API). But, I believe some people have simply written scripts to log in and download the data as if they were a user accessing the site.

With the help of an owner I tried that as an investigation into seeing how hard it would be to 'gateway' US Volts into OVMS. But, not good. The first problem is the api - as you point out it is not really 'published' and little response from GM. The second problem is the architecture itself is similar to the Leaf carvings. The car is not permanently connected, but instead receives a 'wakeup' message from the central servers, at which time it wakes up, transmits its status, then goes offline again.

OVMS works differently. With OVMS, the car connects back to the server and maintains that connection open (using very little data - just a small keep alive once every few minutes, and periodic status updates). If an App connects, the car is immediately informed and immediately starts reporting realtime status. The response to an App connecting is usually 1 to 3 seconds (including all the round-trip times), vs a common 30 to 60 seconds for the Leaf or Onstar systems. But, the key point is that with this always on connection and the ability for the server to talk to the car anytime it wants, we can offload a lot of the work to the server and apps.

The other point is that the amount of information available to owners is a tiny fraction of what is available on the car buses. The manufacturers give the users what the manufacturers want (case in point the recent cripleware update to dashdaq). OVMS is trying to give the users what they want.

We haven't given up the idea of a 'gateway' to the Leaf Carwings and Volt Onstar, but will probably wait for official APIs.


All of the data that I have been accessing is through the CAN "monitor all" mode (which listens to whatever the car is sending), rather than sending specific requests (as most OBD2 applications do). The nice thing about that is that all the data is just sitting there waiting to be interpreted (and can easily be logged, even if you have no idea what it is yet).

Yep, that's exactly what we do with the Tesla Roadster. Works very well. You can also configure the unit to be CAN-bus passive in 'listen' mode, which will have very limited impact on the car.


I hope to start a new thread soon with the program that I am using to collect the data, so that Volt/Ampera owners who are interested can start collecting data from their cars, either to help decode the CAN data or to save the data for future analysis.

You've made an amazing start on the decode. We'll share what we find here and on a master document we'll maintain on our github repository, and encourage you and others to do the same.

Regards, Mark.