GM Volt Forum banner

CAN bus reading / remote viewing of charge state

140K views 150 replies 36 participants last post by  ybpvin  
#1 · (Edited)
Hi,

The European cars (Volt and Ampera) are not going to have any remote monitoring / smartphone functionality like Volts in NA get. There is no equivalent of Onstar over here yet and my efforts to get GM to offer something have been fruitless.

Now, the Tesla guys had a similar issue and so a group of enthusiast owners built a module that interfaces with its CAN bus to read out charge state, start and stop charging and other useful functions:

http://www.teslamotorsclub.com/showthread.php/6655-Open-Vehicle-Monitoring-System

It was designed to work with other cars as well.

Has anyone done any investigation of the Volt CAN bus to start to document the messages on there? If so, it would be very useful to the thousands of owners in Europe who are soon taking delivery if we can get this working.


David
 

Attachments

#2 · (Edited)
There's a thread on this forum about the OBD2 information. Otherwise it may be possible to work out something from the sources for the open-source software for the 2012 Volt/Ampera available at http://www.oss.gm.com/2012VoltAmpera/index.html

P.S. Whereabouts in the UK are you? I'm near Abingdon, Oxon.

Edit to say that having had a look at the sources I can't see anything car specific in it: just the usual kernel, busybox and gcc stuff. Is it possible to get a shell prompt on a Volt?
 
#5 ·
So the OVMS guys have said that if they can get a log file of various events like charging status, SOC, cable connected, etc, then they could make a start with a port.

I read through the various other CAN hacking threads but couldn't see if anyone made a log file available. Could someone please post one? Thanks.
 
#6 ·
An update on where we are with OVMS support for Volt/Ampera.
  1. The physical side is done. The new v2 hardware is working in real Volts/Amperas, and an OVMS-OBDII cable (that supports both Renault Twizy, Volts and Amperas) is done and available.
  2. We've now got GPS location, altitude and heading (from OVMS GPS, not from the car) working well.
  3. We've also got VIN and SOC (auto-ranging) from the CAN bus, so we can remotely monitor SOC.
  4. The development Apps have some images of the cars.

That is a start, but to make this really useful, we need to decode CAN bus messages to determine:
  • Whether the car is ON or OFF
  • Whether the car is charging or not
  • Speed
  • Estimated / Ideal ranges
  • Temperatures

The Twizy guys have shown how this can be done. In a matter of weeks, they got OVMS supporting the Twizy with some really neat tricks. For example; looking at current going in/out of the battery and the car on/off status to indirectly determine whether charging was in progress, and alert on charge interruption.

It would be great to get this done for the Volt/Ampera.

We really need help decoding those can bus messages. Please spread the word about this community project, and jump on board if you know anything about CAN buses, OBDII or GM technical information.

Thanks, Mark.
 
#7 · (Edited)
Mark,

i'll try to capture some data with parallel DashDAQ and CANUSB/CANHACKER running. I hope to decode some new CANIDs these days...

This are the known IDs 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)

regards,

Johannes
 
#10 ·
Ouch,....

the DashDAQ generates much more codes, if it's connected on the ODBII, we have found out:

101,5E9,5EC,7E0,7E8

Perhaps the 101 is a trigger?!:

time canid numberofbytes <data>....
18,220 101 8 FE 01 3E 00 00 00 00 00
20,945 101 8 FE 01 3E 00 00 00 00 00
23,660 101 8 FE 01 3E 00 00 00 00 00
26,385 101 8 FE 01 3E 00 00 00 00 00
29,100 101 8 FE 01 3E 00 00 00 00 00
31,815 101 8 FE 01 3E 00 00 00 00 00
34,557 101 8 FE 01 3E 00 00 00 00 00
37,269 101 8 FE 01 3E 00 00 00 00 00
39,993 101 8 FE 01 3E 00 00 00 00 00
42,707 101 8 FE 01 3E 00 00 00 00 00
45,435 101 8 FE 01 3E 00 00 00 00 00

Thats all for 27 seconds


7E0 and 7E8:


17,843 7E0 8 02 01 00 00 00 00 00 00
19,237 7E0 8 02 01 00 00 00 00 00 00
20,621 7E0 8 02 01 00 00 00 00 00 00
22,006 7E0 8 02 01 00 00 00 00 00 00
23,402 7E0 8 02 01 00 00 00 00 00 00
24,787 7E0 8 02 01 00 00 00 00 00 00
26,180 7E0 8 02 01 00 00 00 00 00 00
27,586 7E0 8 02 01 00 00 00 00 00 00
28,981 7E0 8 02 01 00 00 00 00 00 00
30,379 7E0 8 02 01 00 00 00 00 00 00
31,761 7E0 8 02 01 00 00 00 00 00 00
33,138 7E0 8 02 01 00 00 00 00 00 00
34,530 7E0 8 02 01 00 00 00 00 00 00
35,926 7E0 8 02 01 00 00 00 00 00 00
37,301 7E0 8 02 01 00 00 00 00 00 00
38,694 7E0 8 02 01 00 00 00 00 00 00
40,094 7E0 8 02 01 00 00 00 00 00 00
41,475 7E0 8 02 01 00 00 00 00 00 00
42,858 7E0 8 02 01 00 00 00 00 00 00
44,254 7E0 8 02 01 00 00 00 00 00 00
45,617 7E0 8 02 01 00 00 00 00 00 00
17,844 7E8 8 06 41 00 BE 7F B8 13 AA
19,244 7E8 8 06 41 00 BE 7F B8 13 AA
20,623 7E8 8 06 41 00 BE 7F B8 13 AA
22,008 7E8 8 06 41 00 BE 7F B8 13 AA
23,410 7E8 8 06 41 00 BE 7F B8 13 AA
24,793 7E8 8 06 41 00 BE 7F B8 13 AA
26,187 7E8 8 06 41 00 BE 7F B8 13 AA
27,593 7E8 8 06 41 00 BE 7F B8 13 AA
28,984 7E8 8 06 41 00 BE 7F B8 13 AA
30,385 7E8 8 06 41 00 BE 7F B8 13 AA
31,764 7E8 8 06 41 00 BE 7F B8 13 AA
33,142 7E8 8 06 41 00 BE 7F B8 13 AA
34,535 7E8 8 06 41 00 BE 7F B8 13 AA
35,927 7E8 8 06 41 00 BE 7F B8 13 AA
37,311 7E8 8 06 41 00 BE 7F B8 13 AA
38,701 7E8 8 06 41 00 BE 7F B8 13 AA
40,098 7E8 8 06 41 00 BE 7F B8 13 AA
41,477 7E8 8 06 41 00 BE 7F B8 13 AA
42,863 7E8 8 06 41 00 BE 7F B8 13 AA
44,256 7E8 8 06 41 00 BE 7F B8 13 AA
45,624 7E8 8 06 41 00 BE 7F B8 13 AA

5xx:

27,707 5E9 8 FE 00 00 00 00 00 00 00
...

31,323 5EC 8 FE 31 00 00 62 61 00 00
...

Johannes
 
#11 ·
Thanks very much for the info, keep up the good work! Once we know a bit more, we might even be able to fiddle with some things we want to change...I bought a can bus dev board from CCS, which I'll get lashed up at some point (bought it for Xanbus use, but hey).
I wish GM would just sell us the codes, like they did for dashdaq. We'll get them eventually through legal reverse engineering anyway, so they might as well make a few bucks?
 
#12 ·
@Duncan
The link is for GM's changes to GPL code - they are being a good citizen that way - evidently they rewrote some parts to fit better into the car, and are revealing that (though it's a bit obfuscated since it appears they are just showing the patches - you'd have to find exactly what version of what they patched first to apply these to).

They don't, as allowed by the GPL, contain any of GM's proprietary code that for example, maps the CANBUS id's to anything, at least not so far as I can tell.

tboult once suggested plugging in a serial dongle to the USB port to see if you could get a prompt there, I might try that since it's easy...

But my overall take is that most of the rewrites they did on standard linux utilities were to take things out, save space and cycles, and that would have been one of the more obvious things to remove if they weren't using it for debug (or even if they were - you'd still remove debugging hooks on shipped code if you were savvy).
 
#13 ·
I've got some at http://www.evtools.info/ChevyVoltOBD2CAN.html, but really need to update that page (I've found some more, but not ranges).

If the first byte in 0BC has bit 8 set (leftmost), the car is on; if bit 5 is set, the car is off.

For charging, I can only tell indirectly (e.g. by monitoring the battery SOC in 206, or the battery kW usage in 3e3 bytes 4-5).

Speed is in the first two bytes of 3E9, as MPH*100 (so hex of 0102 would be decimal 258, or a very slow 2.58MPH).

4C1 byte 5 has the outside temperature, in degrees Fahrenheit with an offset of 50 (so 0x76 or 118 decimal would be 68 degrees F).
 
#21 · (Edited)
4C1 byte 5 has the outside temperature, in degrees Fahrenheit with an offset of 50 (so 0x76 or 118 decimal would be 68 degrees F).
I think 4C1 byte 5 is not the outside temperature, because I saw the following data in my logs:

Code:
100,266 4C1      8 10 C3 38 3B 68 00 00 00 
100,807 4C1      8 10 C3 38 3B 68 00 00 00 
101,348 4C1      8 10 C3 38 3B 68 00 00 00 
109,947 4C1      8 10 C3 37 37 66 00 00 00 
110,492 4C1      8 10 C3 37 37 66 00 00 00 
111,033 4C1      8 10 C3 37 38 66 00 00 00

0x68 jumps to 0x66.


...and in another log, as I requested data for the outside temperature (5/6 for raw/filtered)

Code:
37,611 5EC      8 FE 31 29 71 60 60 00 00
=> 0x60

...the 4C1 at the same time in the same log was:
Code:
37,619 4C1      8 10 C3 30 35 61 00 00 00
=> 0x61
 
#14 ·
guys,

look at this, that's what the DashDAQ writes on the bus if it's booting (logfile filtered with canhacker 2.0)

DashDAQ-Screen with one Field "outside temperature":

Code:
21,952 7E0      8 02 01 00 00 00 00 00 00  input
21,958 7E8      8 06 41 00 BE 7F B8 13 AA  output

21,981 7DF      8 02 01 00 00 00 00 00 00  input
21,985 7E8      8 06 41 00 BE 7F B8 13 AA  output
21,986 7E9      8 06 41 00 80 00 00 01 AA 
21,983 7EA      8 06 41 00 80 00 00 01 AA 
21,982 7EB      8 06 41 00 80 40 00 01 AA 
21,988 7EC      8 06 41 00 80 00 00 01 AA 
22,003 7ED      8 06 41 00 00 00 00 01 AA 
21,986 7EF      8 06 41 00 00 00 00 01 AA 


22,328 7E0      8 02 AA 00 00 00 00 00 00  input
22,330 5E8      8 00 00 00 00 00 00 00 00  output

22,392 7E1      8 02 AA 00 00 00 00 00 00  input
22,397 5E9      8 00 00 00 00 00 00 00 00  output

22,456 7E2      8 02 AA 00 00 00 00 00 00  input
22,463 5EA      8 00 00 00 00 00 00 00 00  output

22,522 7E3      8 02 AA 00 00 00 00 00 00  input
22,524 5EB      8 00 00 00 00 00 00 00 00  output

22,587 7E4      8 02 AA 00 00 00 00 00 00  input
22,604 5EC      8 00 00 00 00 00 00 00 00  output

22,651 7E5      8 02 AA 00 00 00 00 00 00  input
22,662 5ED      8 00 AA AA AA AA AA AA AA  output

22,716 7E7      8 02 AA 00 00 00 00 00 00  input
22,726 5EF      8 00 00 00 00 00 00 00 00  output

22,781 7E4      8 10 08 2C FE 43 69 43 68  input
22,788 7EC      8 30 00 14 AA AA AA AA AA  output

22,789 7E4      8 21 80 1F 00 00 00 00 00  input
22,800 7EC      8 02 6C FE AA AA AA AA AA  output

(22,817 101      8 FE 01 3E 00 00 00 00 00  input?)

22,820 7E4      8 03 AA 04 FE 00 00 00 00  input
22,864 5EC      8 FE 14 71 60 00 00 00 00  output
22,897 5EC      8 FE 14 71 60 00 00 00 00 
22,928 5EC      8 FE 14 71 60 00 00 00 00 
22,961 5EC      8 FE 14 71 60 00 00 00 00 
22,994 5EC      8 FE 14 71 60 00 00 00 00 
23,027 5EC      8 FE 14 71 60 00 00 00 00 
23,058 5EC      8 FE 14 71 60 00 00 00 00 
23,090 5EC      8 FE 14 71 60 00 00 00 00 
23,123 5EC      8 FE 14 71 60 00 00 00 00 
23,158 5EC      8 FE 14 71 60 00 00 00 00 
23,189 5EC      8 FE 14 71 60 00 00 00 00 
23,221 5EC      8 FE 14 71 60 00 00 00 00 
23,253 5EC      8 FE 14 71 60 00 00 00 00 
23,285 5EC      8 FE 14 71 60 00 00 00 00
Byte 4 from 5EC is the outside temperature (0x60).

....see

http://www.canbushack.com/blog/index.php?title=service-s-please&more=1&c=1&tb=1&pb=1
 
#15 ·
DashDAQ-like reading on ODBII:

Code:
49,547 7E4      8 06 2C FE 43 69 43 68 00   (input: config for voltage/current of charger)
49,557 7EC      8 02 6C FE AA AA AA AA AA   (OK?)

49,563 7E4      8 03 AA 04 FE 00 00 00 00   (input for display results)
49,589 5EC      8 FE 43 70 00 00 00 00 00   (results, ~160 reads for a few seconds)
Byte 2+3 is current and voltage

Outside temperature:

Code:
27,761 7E4      8 10 08 2C FE 43 69 43 68   (input config 1 for outside temperature)
27,763 7EC      8 30 00 14 AA AA AA AA AA   (OK?)

27,764 7E4      8 21 80 1F 00 00 00 00 00   (input config 2 for outside temperature)
27,777 7EC      8 02 6C FE AA AA AA AA AA   (OK?)

27,796 7E4      8 03 AA 04 FE 00 00 00 00   (input for display results)
27,840 5EC      8 FE 00 00 5B 00 00 00 00   (results, ~160 reads for a few seconds, here: 0x5B in Byte 3)
 
#16 ·
DashDAQ-like reading on ODBII:

Code:
49,547 7E4      8 06 2C FE 43 69 43 68 00   (input: config for voltage/current of charger)
49,557 7EC      8 02 6C FE AA AA AA AA AA   (OK?)

49,563 7E4      8 03 AA 04 FE 00 00 00 00   (input for display results)
49,589 5EC      8 FE 43 70 00 00 00 00 00   (results, ~160 reads for a few seconds)
Byte 2+3 is current and voltage

SNIP


I'd like to see if I am I reading this correctly before I start poking around on my canbus.
Is the first part saying it is sending a message to

mode 49
ID 547
device 7E4
(for config)

looking for data to display
mode 49,
ID 563 to 7E4
looking fro response
from device 5EC?

Is 43h = current 70=Volt? Any idea what are the units?



Also why is this example with OAT so different from the previous OAT example you gave?
 
#18 ·
While DashDAQ is reading all available signals from the bus, the sequences are as follows:

Code:
02,887 7DF      8 02 01 00 00 00 00 00 00 
02,894 7E8      8 06 41 00 BE 7F B8 13 AA 
02,892 7E9      8 06 41 00 80 00 00 01 AA 
02,891 7EA      8 06 41 00 80 00 00 01 AA 
02,891 7EB      8 06 41 00 80 40 00 01 AA 
02,890 7EC      8 06 41 00 80 00 00 01 AA 
02,903 7ED      8 06 41 00 00 00 00 01 AA 
02,891 7EF      8 06 41 00 00 00 00 01 AA 

03,032 7E0      8 04 2C FE 00 42 00 00 00 
03,037 7E8      8 02 6C FE AA AA AA AA AA 
03,047 7E4      8 04 2C FE 43 7D 00 00 00 
03,053 7EC      8 02 6C FE AA AA AA AA AA 
03,067 7E0      8 04 2C FE 15 64 00 00 00 
03,070 7E8      8 02 6C FE AA AA AA AA AA 
03,089 7E4      8 04 2C FE 82 B2 00 00 00 
03,096 7EC      8 02 6C FE AA AA AA AA AA 
03,111 7E4      8 04 2C FE 83 5C 00 00 00 
03,118 7EC      8 02 6C FE AA AA AA AA AA 
03,132 7E4      8 04 2C FE 82 B7 00 00 00 
03,141 7EC      8 02 6C FE AA AA AA AA AA 
03,154 7E4      8 04 2C FE 41 B2 00 00 00 
03,162 7EC      8 02 6C FE AA AA AA AA AA 
03,175 7E4      8 04 2C FE 82 B5 00 00 00 
03,183 7EC      8 02 6C FE AA AA AA AA AA 
03,197 7E1      8 04 2C FE 1C 36 00 00 00 
03,203 7E9      8 02 6C FE AA AA AA AA AA 
03,219 7E1      8 04 2C FE 1C 37 00 00 00 
03,224 7E9      8 02 6C FE AA AA AA AA AA 
03,240 7E0      8 04 2C FE 28 10 00 00 00 
03,246 7E8      8 02 6C FE AA AA AA AA AA 
03,262 7E0      8 04 2C FE 00 46 00 00 00 
03,266 7E8      8 02 6C FE AA AA AA AA AA 
03,284 7E4      8 04 2C FE 40 E7 00 00 00 
03,291 7EC      8 02 6C FE AA AA AA AA AA 
03,306 7E1      8 04 2C FE 28 BD 00 00 00 
03,311 7E9      8 02 6C FE AA AA AA AA AA 
03,328 7E1      8 04 2C FE 28 BC 00 00 00 
03,332 7E9      8 02 6C FE AA AA AA AA AA 
03,348 7E1      8 04 2C FE 28 BE 00 00 00 
03,352 7E9      8 02 6C FE AA AA AA AA AA 
03,370 7E1      8 04 2C FE 24 29 00 00 00 
03,372 7E9      8 02 6C FE AA AA AA AA AA 
03,392 7E0      8 04 2C FE 15 72 00 00 00 
03,395 7E8      8 02 6C FE AA AA AA AA AA 
03,413 7E0      8 04 2C FE 15 70 00 00 00 
03,415 7E8      8 02 6C FE AA AA AA AA AA 
03,435 7E0      8 04 2C FE 15 73 00 00 00 
03,445 7E8      8 02 6C FE AA AA AA AA AA 
03,456 7E0      8 04 2C FE 15 71 00 00 00 
03,462 7E8      8 02 6C FE AA AA AA AA AA 
03,478 7E2      8 04 2C FE 28 51 00 00 00 
03,485 7EA      8 02 6C FE AA AA AA AA AA 
03,500 7E2      8 04 2C FE 28 52 00 00 00 
03,506 7EA      8 02 6C FE AA AA AA AA AA 
03,522 7E2      8 04 2C FE 28 53 00 00 00 
03,526 7EA      8 02 6C FE AA AA AA AA AA 
03,544 7E2      8 04 2C FE 28 54 00 00 00 
03,547 7EA      8 02 6C FE AA AA AA AA AA 
03,565 7E4      8 04 2C FE 13 AF 00 00 00 
03,577 7EC      8 02 6C FE AA AA AA AA AA 
03,587 7E4      8 04 2C FE 41 B7 00 00 00 
03,594 7EC      8 02 6C FE AA AA AA AA AA 
03,608 7E0      8 04 2C FE 00 05 00 00 00 
03,612 7E8      8 02 6C FE AA AA AA AA AA 
03,630 7E4      8 04 2C FE 41 B6 00 00 00 
03,637 7EC      8 02 6C FE AA AA AA AA AA 
03,652 7E4      8 04 2C FE 43 5A 00 00 00 
03,659 7EC      8 02 6C FE AA AA AA AA AA 
03,673 7E4      8 04 2C FE 43 5D 00 00 00 
03,681 7EC      8 02 6C FE AA AA AA AA AA 
03,695 7E1      8 04 2C FE 24 87 00 00 00 
03,697 7E9      8 02 6C FE AA AA AA AA AA 
03,716 7E0      8 04 2C FE 00 0C 00 00 00 
03,718 7E8      8 02 6C FE AA AA AA AA AA 
03,738 7E0      8 04 2C FE 1A 2D 00 00 00 
03,739 7E8      8 02 6C FE AA AA AA AA AA 
03,760 7E0      8 04 2C FE 11 31 00 00 00 
03,768 7E8      8 02 6C FE AA AA AA AA AA 
03,781 7E1      8 04 2C FE 24 14 00 00 00 
03,785 7E9      8 02 6C FE AA AA AA AA AA 
03,803 7E4      8 04 2C FE 43 56 00 00 00 
03,810 7EC      8 02 6C FE AA AA AA AA AA 
03,824 7E4      8 04 2C FE 43 7F 00 00 00 
03,832 7EC      8 02 6C FE AA AA AA AA AA 
03,847 7E4      8 04 2C FE 43 2E 00 00 00 
03,853 7EC      8 02 6C FE AA AA AA AA AA 
03,868 7E1      8 04 2C FE 24 16 00 00 00 
03,873 7E9      8 02 6C FE AA AA AA AA AA 
03,889 7E4      8 04 2C FE 43 2B 00 00 00 
03,899 7EC      8 02 6C FE AA AA AA AA AA 
03,923 7E1      8 04 2C FE 1C 2F 00 00 00 
03,927 7E9      8 03 7F 2C 31 AA AA AA AA 
04,116 7E1      8 04 2C FE 24 17 00 00 00 
04,122 7E9      8 02 6C FE AA AA AA AA AA 
04,139 7E1      8 04 2C FE 1C 30 00 00 00 
04,143 7E9      8 03 7F 2C 31 AA AA AA AA 
04,336 7E0      8 04 2C FE 00 5B 00 00 00 
04,341 7E8      8 02 6C FE AA AA AA AA AA 
04,355 7E1      8 04 2C FE 24 11 00 00 00 
04,360 7E9      8 02 6C FE AA AA AA AA AA 
04,376 7E4      8 04 2C FE 83 34 00 00 00 
04,384 7EC      8 02 6C FE AA AA AA AA AA 
04,398 7E4      8 04 2C FE 43 4F 00 00 00 
04,405 7EC      8 02 6C FE AA AA AA AA AA 
04,420 7E1      8 04 2C FE 40 D0 00 00 00 
04,427 7E9      8 03 7F 2C 31 AA AA AA AA 
04,612 7E4      8 04 2C FE 43 2D 00 00 00 
04,621 7EC      8 02 6C FE AA AA AA AA AA 
04,636 7E4      8 04 2C FE 41 B4 00 00 00 
04,643 7EC      8 02 6C FE AA AA AA AA AA 
04,661 7E4      8 04 2C FE 90 5C 00 00 00 
04,665 7EC      8 02 6C FE AA AA AA AA AA 
04,680 7E4      8 04 2C FE 43 B0 00 00 00 
04,688 7EC      8 02 6C FE AA AA AA AA AA 
04,700 7E4      8 04 2C FE 83 5A 00 00 00 
04,708 7EC      8 02 6C FE AA AA AA AA AA 
04,722 7E0      8 04 2C FE 00 0F 00 00 00 
04,726 7E8      8 02 6C FE AA AA AA AA AA 
04,744 7E0      8 04 2C FE 20 3F 00 00 00 
04,746 7E8      8 02 6C FE AA AA AA AA AA 
04,766 7E4      8 04 2C FE 43 7E 00 00 00 
04,773 7EC      8 02 6C FE AA AA AA AA AA 
04,788 7E0      8 04 2C FE 00 0B 00 00 00 
04,794 7E8      8 02 6C FE AA AA AA AA AA 
04,809 7E1      8 04 2C FE 28 83 00 00 00 
04,812 7E9      8 02 6C FE AA AA AA AA AA 
04,830 7E1      8 04 2C FE 28 AF 00 00 00 
04,832 7E9      8 02 6C FE AA AA AA AA AA 
04,852 7E1      8 04 2C FE 28 81 00 00 00 
04,859 7E9      8 02 6C FE AA AA AA AA AA 
04,874 7E1      8 04 2C FE 28 85 00 00 00 
04,879 7E9      8 02 6C FE AA AA AA AA AA 
04,896 7E1      8 04 2C FE 28 84 00 00 00 
04,900 7E9      8 02 6C FE AA AA AA AA AA 
04,917 7E1      8 04 2C FE 28 B0 00 00 00 
04,920 7E9      8 02 6C FE AA AA AA AA AA 
04,939 7E1      8 04 2C FE 28 82 00 00 00 
04,940 7E9      8 02 6C FE AA AA AA AA AA 
04,960 7E1      8 04 2C FE 28 86 00 00 00 
04,967 7E9      8 02 6C FE AA AA AA AA AA 
04,983 7E4      8 04 2C FE 80 1F 00 00 00 
04,989 7EC      8 02 6C FE AA AA AA AA AA 
05,004 7E4      8 04 2C FE 80 1E 00 00 00 
05,011 7EC      8 02 6C FE AA AA AA AA AA 
05,025 7E4      8 04 2C FE 43 69 00 00 00 
05,033 7EC      8 02 6C FE AA AA AA AA AA 
05,048 7E4      8 04 2C FE 43 68 00 00 00 
05,054 7EC      8 02 6C FE AA AA AA AA AA 
05,068 7E4      8 04 2C FE 43 6C 00 00 00 
05,076 7EC      8 02 6C FE AA AA AA AA AA 
05,090 7E4      8 04 2C FE 43 73 00 00 00 
05,097 7EC      8 02 6C FE AA AA AA AA AA 
05,112 7E4      8 04 2C FE 43 6B 00 00 00 
05,119 7EC      8 02 6C FE AA AA AA AA AA 
05,133 7E4      8 04 2C FE 43 6E 00 00 00 
05,141 7EC      8 02 6C FE AA AA AA AA AA 
05,155 7E4      8 04 2C FE 43 74 00 00 00 
05,162 7EC      8 02 6C FE AA AA AA AA AA 
05,176 7E4      8 04 2C FE 43 6D 00 00 00 
05,184 7EC      8 02 6C FE AA AA AA AA AA 
05,198 7E4      8 04 2C FE 43 6F 00 00 00 
05,208 7EC      8 02 6C FE AA AA AA AA AA 
05,220 7E4      8 04 2C FE 43 58 00 00 00 
05,227 7EC      8 02 6C FE AA AA AA AA AA 
05,241 7E4      8 04 2C FE 1C 43 00 00 00 
05,249 7EC      8 02 6C FE AA AA AA AA AA 
05,263 7E4      8 04 2C FE 43 BB 00 00 00 
05,270 7EC      8 02 6C FE AA AA AA AA AA 
05,285 7E1      8 04 2C FE 24 2B 00 00 00 
05,292 7E9      8 02 6C FE AA AA AA AA AA 
05,308 7E0      8 04 2C FE 00 0E 00 00 00 
05,314 7E8      8 02 6C FE AA AA AA AA AA 
05,329 7E0      8 04 2C FE 20 7E 00 00 00 
05,335 7E8      8 02 6C FE AA AA AA AA AA 
05,349 7E2      8 04 2C FE 1A 1F 00 00 00 
05,351 7EA      8 03 7F 2C 31 AA AA AA AA 
05,543 7E2      8 04 2C FE 19 40 00 00 00 
05,547 7EA      8 02 6C FE AA AA AA AA AA 
05,566 7E0      8 04 2C FE 00 4C 00 00 00 
05,572 7E8      8 02 6C FE AA AA AA AA AA 
05,587 7E1      8 04 2C FE 24 34 00 00 00 
05,589 7E9      8 02 6C FE AA AA AA AA AA 
05,609 7E1      8 04 2C FE 24 2C 00 00 00 
05,616 7E9      8 02 6C FE AA AA AA AA AA 
05,632 7E1      8 04 2C FE 28 78 00 00 00 
05,636 7E9      8 03 7F 2C 31 AA AA AA AA 
05,824 7E1      8 04 2C FE 19 42 00 00 00 
05,826 7E9      8 02 6C FE AA AA AA AA AA 
05,847 7E1      8 04 2C FE 19 A1 00 00 00 
05,853 7E9      8 02 6C FE AA AA AA AA AA 
05,869 7E2      8 04 2C FE 19 41 00 00 00 
05,872 7EA      8 02 6C FE AA AA AA AA AA 
05,890 7E2      8 04 2C FE 19 9E 00 00 00 
05,892 7EA      8 03 7F 2C 31 AA AA AA AA 
06,083 7E1      8 04 2C FE 28 E8 00 00 00 
06,090 7E9      8 02 6C FE AA AA AA AA AA 
06,107 7E2      8 04 2C FE 1A 18 00 00 00 
06,109 7EA      8 03 7F 2C 31 AA AA AA AA 
06,300 7E2      8 04 2C FE 19 D4 00 00 00 
06,305 7EA      8 02 6C FE AA AA AA AA AA 
06,323 7E0      8 04 2C FE 00 0D 00 00 00 
06,329 7E8      8 02 6C FE AA AA AA AA AA
 
#25 ·
While DashDAQ is reading all available signals from the bus, the sequences are as follows:

SNIP..
thanks this looks like its what I've been looking for (I bought a Y-cable so I could try to borrow a dash-daq and do something like this.. ).

Now that I've been reading about dynamic PIDs and mode 2C.. I'm starting to get a clearer picture of what it is doing and how it might be adapted to torque for us pesants. Note if it can be adapted it would mean just a low-cost bluetooth device an an android phone.. so maybe good for those in the EU without onstar.

I have an older list of all the dash-daq fields so I'll try out some of the codes from your table and and see if I can get responses from torque and then match some of these up with names. (All after I get back from skiing )
 
#24 ·
I've decoded the requests.

There are 2 Byte PIDs, which are requested as follows:


One Single PID:
Code:
7E4   8 04 2C FE <PID> 00 00 00
Two PIDs:
Code:
7E4   8 06 2C FE <PID1> <PID2> 00
Three PIDs:
Code:
7E4   8 10 08 2C FE <PID1> <PID2>
7E4   8 21 <PID3> 00 00 00 00 00
Byte 1 is the Message length

With three PIDs, Byte 1 of the first set is 0x10 = 16 Bytes = two requests with 8 Bytes.
For the complete message, the length is "08" ( command "request" (0x2CFE) + 3 PIDs),
0x21 in the first Byte of the second requests means "follows" , i think.


The known PIDs are so far:

request over 7E4, answer in 5EC:
Onboard charger current: 0x4369
Onboard charger voltage: 0x4368
outside temperature (filtered): 0x801F
outside temperature (raw): 0x801E
High Voltage battery Temperature: 0x434F
Power Electronics Cooling Loop temperature: 0x1C43

request over 7E0, answer in 5E8:
ambient temperature: 0x0046


Examples:

To request the High Voltage Battery temperature in one single PID, you have to request:

Code:
7E4   8 04 2C FE 43 4F 00 00 00   (command: request 0x434F)
7EC   8 02 6C FE AA AA AA AA AA   (answer: OK)

7E4   8 03 AA 04 FE 00 00 00 00   (command: display data)
5EC   8 FE 30 00 00 00 00 00 00   (answer: HV Temp in Byte 2, 0x30 => 8°C (unit 1 °C offset 40) )

to request the ambient temperature:

Code:
7E0   8 04 2C FE 00 46 00 00 00   (command: request 0x0046)
7E8   8 02 6C FE AA AA AA AA AA   (answer: OK)

7E0   8 03 AA 04 FE 00 00 00 00   (command: display data)
5E8   8 FE 2F 00 00 00 00 00 00   (answer: HV Temp in Byte 2, 0x2F => 7°C (unit 1 °C offset 40) )
 
#26 ·
Greetings everyone,

I have been watching this thread for a few days. I don't have a Volt but I do have extensive experience with automotive CAN bus applications and I think I can add some value to the discussion.

According to the bus data presented above the DashDaq is using mode 0x2C to request the identifiers. The message structure for mode 0x2C for one, two and three parameters is as described above. Using that example, the ID 0x7E4 is the battery module, 8 is the message length, 04 is the significant bytes in current message, 2C is the mode(dynamically defined data identifier), FE is the requested response ID and the next two bytes are the PID.

The response is as follows: 0x7EC is the battery module response(0x7E4 + 0x08). This offset id response always holds true, that is why you see 0x7E8 as the response to a 0x7E0(engine controller) request. 8 is the message length again. 6C is the affirmative response to the 2C request(0x2C + 0x40). This holds true for any mode request(mode 0x22 request should be affirmed with a 0x62 in the response). If you get a 7F in the response, this means there is an error with the mode request, either it isnt supported or there is a problem with the way the format was requested. FE is the response ID as requested in the previous message. You can request basically any ID between 00-FF. It is just a way for the tool to recognize which identifier(s) are being broadcast. The rest of the bytes in the response are just padding so that it is 8 bytes long.

The next request is 0x7E4 again, letting the bus know you are asking for a response from the battery module. 8 is the message length. 03 is the significant bytes in the message. AA is read data by packet id, which is the ID you requested in the first message(FE). 04 is the next byte and that lets the module know you are looking for a fast response rate. Decreasing numbers here means decreasing response speed. 01 will get you one response and 00 will stop the response all together. The next byte in the message is FE and it lets you know you are getting the PIDs requested in that message as set up in the first message. The rest of the bytes are padding once again.

Finally the response is 0x5E8. This is the ID assigned to the battery module for dynamically defined responses. It is 0x200 less than the standard response ID and should hold true for any module request. As an example, a request from 0x7E0 should generate a response from 0x7E8 unless you are asking for dynamically defined data in which case it will respond with 0x5E8(0x7E8-0X200). 8 is the message length. FE is the response ID you set up in the first message. 2F is the data and rest is padding.

This is a good way to reduce the clutter on the bus because you can request and receive multiple pids in one shot. As opposed to mode 22 which nets you one response per request. If you want to set up more than three you can just change the response ID from FE to one of the others like FD, FC, FB.... add your PIDs and then ask for the response.

A couple of quick notes. If you want to receive the messages for longer than about three seconds you will need to send the 0x101 message that was questioned in previous posts. This is the tester present message and it lets the module know you are still there and expecting a response. All of the generic OBD messages should work in this mode as well. The generic engine RPM ID is 0x0C(or 0x000C). In your original message if you specify this ID you should get engine RPM(make sure you ask 0x7E0 for this information). There are generic OBD Id's all over the net just use your favorite search engine. Finally, these PIDs may also work for mode 22 requests so those of you with a scangauge that are brave enough to still use it, should be able to code it in xgauge. Be cautious you don't clog up the CAN bus with too many requests though.

Sorry for the long post, hopefully some of it makes sense.
 
#30 ·
OBDII PIds lots of them (but mostly unlabeled but with some log data)

Following up.. converting data and using mostly mode 22 fields I was able to get data for most of the field initialized by the dashdaq.

I did testing today with torque with all of the PIDs from the above initialization sequence.
I mapped them all to their respective hardware to help me track down what is what.
(I've uploaded my torque extendedpid file, a log file and the list of expected "dashdaq"
http://vast.uccs.edu/~tboult/VOLT/trackLog-2013-Jan-04_17-58-31.csv
http://vast.uccs.edu/~tboult/VOLT/DD-PID-A.csv
http://vast.uccs.edu/~tboult/VOLT/dashdaq-fields.csv


I setup my my torque on android log all of them.. I've done two trips so far.. Some of them seem to be 2 bytes but my log with 2 byte data failed for reasons I did not yet resolve.

The pid file has the hardware unit and with some effort we should be able to match up data with likely labels (and still have to guess the labels). I'll work on it a bit this weekend but figured others may be better at it or have more time. And if someone with a dashdaq is interested it would be pretty easy to have the dashdaq log all fields and simultaneously have a torque logging and match them up that way. (I can provide a y cable and the android side if anyone is interested).


A few things I've noticed..

Pretty sure that mode 22 0046 is not Ambient Temp.. that is mode probably mode 1 46 (0146) for ambient temp.

Note sure about the outside Temp Filter (801F) and (80 1E) both are listed as being sent to
7e4, which is the Hybrid Control Module #2.. The OAT sensor does come into that unit, but
the formula suggested don't make sense as temps to be even close to what I saw as temps a formula like (A-40)/4 but that did not work either, Maybe that is some type of raw resistance value (which needs table lookup to be a temp). I'll need more days of testing to check that out.

The Power Electronics temp and the two "charger" variable seem right to me (I check with a 120v charger..).

HV Battery Temp does not make sense if its in C. maybe in F if I don't divide by (Reported 51 using (A-40), while outside temp was 28F. Or maybe in C if the divisor is larger.. .. need more data to estimate it well.

I've got some pretty good guesses for some of the unlabeled fields, but I figured I'd save them for now and see if anyone else produces similar guesses independently. Don't want to take the fun out of it for others.
 
#31 ·
First off thanks for the welcome. I hope some of my posts help you guys get the information you want. Now onto the issue at hand. TBoult did a great job getting some information, I think I can decode some of it.

First up is the engine controller(0x7E0)
Code:
Name	                          ShortName	 Mode-PID #	 Equation 	Units	# of Bytes

Ambient Air Temp                     AAT	  22-0046	   X-40          °C	      1

Control Module Voltage	             VPWR         22-0042	  X*.001          V           2

Engine Coolant Temp	             ECT          22-0005	   X-40          °C	      1

Intake Manifold Absolute Pressure    MAP          22-000B	   X+0           kPa	      1

Engine RPM	                     RPM          22-000C         X*.25          rpm          2

Vehicle Speed Sensor	             VSS          22-000D          X+0           kph          1

Ignition Timing Advance
for #1 Cylinder	                  SPARKADV        22-000E   	(X*.5)-64	 BTDC         1

Intake Air Temperature	             IAT          22-000F          X-40          °C           1

Commanded Throttle
Actuator Control	             TAC          22-004C	X*(100/255)	  %	      1

Hybrid/EV Battery Pack
Remaining Charge	           BAT_PWR        22-005B	X*(100/255)	  %	      1
Those are J1979 OBD PIDs, you can find the definitions and scaling all over the internet. Based on the results from earlier CAN traffic you should be able to get PID #'s 1,3,4,5,6,7,A,B,C,D,E,F,10,11,13,14,15,1C and 1F over mode 22. More to come when I have more time.
 
#33 · (Edited)
You and most of the 2011/2012 owners.. its part of what I'm looking to measure..

Trying to figure this out is way more fun then sodoku.. And there is still some low hanging fruit in the logs.
I'll be posting more logs/guesses later today.
 
#34 ·
The rest of the ECU parameters I have a reasonable guess about are below. These should be verified by someone with a Volt and DashDaq or CAN bus analyzer.

Code:
Name				Mode-PID#	Scaling		Units
Fuel System Status		22-1131	        X+0		State Encoded
AC High Side Pressure		22-1564	        Unknown	        kPa
Short Term Fuel Trim Bank 1	22-1570	        X*(100/255)      %
Short Term Fuel Trim Bank 2	22-1571	        X*(100/255)      %
Long Term Fuel Trim Bank 1	22-1572	        X*(100/255)      %
Long Term Fuel Trim Bank 2	22-1573         X*(100/255)	 %
Torque Delivered Signal		22-1A2D	        Unknown          NM
These parameters are GM specific and a little more difficult to find on the internet. I have stumbled across these before on different GM vehicles. Assuming the PID list is consistent between GM vehicles, these should be correct but the scaling should be checked. The rest of the 7E0 parameters are new to me, I can't help with those without actually having a Volt and the right tools. I will look at the rest as time allows.
 
#94 ·
Trying to validate these.. Pretty ure the last one is nto Torque delivered.. it slowly decreased over the course of a 15mile test run.. (presuming its signed, it started at -150 decreased down to 145). not at all like a torque signal, more like a battery power or something (but I already have one of those). Temp would have gone up, so not sure.

May do a ICE run (needed to mess with fuel trim), but don't know how to interpret those signals even if I get them.

What is a normal AC preasure?
 
#35 ·
These are the only ones I think I know for the rest of the modules. I haven’t worked with any GM hybrids before so the 0x7E4 are pretty much all new territory. As before, the scaling should be verified.

Code:
Name				Mode-PID#	Scaling			Units
Output Shaft Speed		22-1942	        X*(1/4) or (1/8)	RPM
Gear Ratio			22-19A1	        Might be X*(4/256)	
Trans Fluid Temp		22-1940	        X-40		        °C
Transmission ISS		22-1941	        Might be X*(8192/65536) RPM
 
#36 ·
Bit more digging with some decent results. Lots items are now labeled, especially about charging.

I'll not be able to work on it for a few days, but figgured I'd upload my load and test.
Test1 was posted above.

Test 2 (note the torque rules were different, most rules looked at A+1000*B so I could see what used a second byte.
These files have the torque commands and the logs. The "run" was around the block, starting at home, with 120v charging, a few miles with agressive EV driving and regen, then with a stop at a local L2 charger (240v), some high-speed highway driving, then more agressive acces/regen (with some netural coasting).
http://vast.uccs.edu/~tboult/VOLT/DD-testb.CSV
http://vast.uccs.edu/~tboult/VOLT/trackLog-2013-Jan-05_14-32-01.csv
Temp was about 38F

Third test I adapted formulas with input from second test, identified more things and did another run on the same circuity, with 2 loops this time so I could get down far enough for MM to start the engine.

http://vast.uccs.edu/~tboult/VOLT/DD-testc.CSV
http://vast.uccs.edu/~tboult/VOLT/trackLog-2013-Jan-05_16-50-47.csv
These were mostly correct formulas for known items or A*256+B for unknown 2 byte items

Analyzing these, combined with the posts from burro here is my current "labeled" torque data.
http://vast.uccs.edu/~tboult/VOLT/DD-labeled.csv

Maybe others can find more labels and/or correct test these. With charging, non-charging driving, stopping and engine running there were lots of patterns in the data. There are interesting patters in the above data/logs.
Some of the Temp fields are probably wrong.. I think some might not be real temps, but maybe they are raw thermistor values?

Some other things I did not understand.. some of items have very high values (>65K), then drop to small values like 138.. so I'm thinking maybe some of these are in some type of 2s-complement form, but I've not seen that in any OBDII documents.


A few interesting ones I believe I identified include Last Charge AC Wh (one I wanted to find.. so I can track my charging easier), HV charging voltage/amps/watts as well, on the other side of the charger (i.e. after voltage conversion), which might be interesting to estimate losses.

My labeling starts with H1 if the data is from HPCM1, and H2 if its from HPCM2 (where the battery module is)
T is for trans and M for the master ECU which might be forwarding data from lots of others.

it was interesting to see how cold my battery gets.. after a day of sitting, plugged in, it seems to be down to 40F.. which was a surprise. Anyone with a DashDaq ever checked battery temp? (maybe there is a scaling problem on my temp).
 
#89 ·
Analyzing these, combined with the posts from burro here is my current "labeled" torque data.
http://vast.uccs.edu/~tboult/VOLT/DD-labeled.csv
Hi,

I have used your DD-labeled.csv with my Samsung Galaxy TAB with Torque Pro.

I am an amateur in this, so I apologise if I ask a dumb question ;)

I have two of them:
1. You are experimenting with the extended PIDs. I saw that an OBDII answer can have up to 8 bytes of data (A B C D E F G H). Still in your experimenting you only display the value of A and B combined in one number 256*A+B. Would it make sense to display 16777216*A+65536*B+256*C+D and enter the same PID for the second four bytes to display 16777216*E+65536*F+256*G+H ?
2. I have logged everything for my 80kms(50 mile) trip to the office this morning, both highway and city traffic. Since I can't charge at the office (yet), I leave with a halve full battery. I now have a huge Excel sheet with values. Some of the columns don't have a value at all, just a '-'. Maybe it is useful for you to have the name/PID of the columns that don't give any information, but on the other hand if you only display 256*A+B, it could be there is a value in C, D, E, F, G or H that still needs to be 'discovered'.

I saw on your website that you have a new version of DD-labeled.csv. I downloaded it into Torque, set up to log everything again and will drive home with it this afternoon :)

Thanks for your work up to now, I am looking forward to the day that I can view all (as in rpm, A, kWh) information about M1, M2 and PM in a nice setup similar to this: http://www.youtube.com/v/M6ssU278Uk0