: CAN bus reading / remote viewing of charge state



dpeilow
04-07-2012, 11:09 AM
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

Duncan
04-07-2012, 01:29 PM
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?

mikeg3
04-07-2012, 01:48 PM
If you can get an unrestricted shell prompt on a Volt microprocessor, can viruses be far behind?

I doubt that this can be done, but nothing in IT is impossible except a bug-free Windows release. :)

dpeilow
04-07-2012, 02:43 PM
@Duncan - thanks for the link.

I'm about 50 miles due south of you on the A34 :)

dpeilow
04-07-2012, 05:47 PM
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.

markwj
12-26-2012, 07:52 PM
An update on where we are with OVMS support for Volt/Ampera.

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.
We've now got GPS location, altitude and heading (from OVMS GPS, not from the car) working well.
We've also got VIN and SOC (auto-ranging) from the CAN bus, so we can remotely monitor SOC.
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.

nie-mehr-benzin.de
12-27-2012, 04:40 AM
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

nie-mehr-benzin.de
12-27-2012, 09:13 AM
Yeah..... DashDAQ + CANUSB makes it !

Here is some data from the charger:

5EC Byte 3 Charging Current units 0.2 A (ex. 14.2 A = 0x47)
5EC Byte 4 Charging Voltage units 2 V (ex. 222V = 0x6F)

....going on hacking.

Johannes

nie-mehr-benzin.de
12-27-2012, 11:24 AM
there it goes..

5EC Byte 5 Outside Air Temperature in C unit 0.5C offset +40 (exp.: 0x60 = 8.0 C)
5EC Byte 6 Outside Air Temperature filtered in C unit 0.5C offset +40

;-)

nie-mehr-benzin.de
12-27-2012, 12:16 PM
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

DCFusor
12-27-2012, 12:31 PM
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?

DCFusor
12-27-2012, 12:46 PM
@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).

RScott
12-27-2012, 09:16 PM
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).

nie-mehr-benzin.de
12-29-2012, 02:02 AM
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":



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

nie-mehr-benzin.de
12-29-2012, 08:39 AM
DashDAQ-like reading on ODBII:



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:



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)

tboult
12-29-2012, 11:20 AM
DashDAQ-like reading on ODBII:



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?

nie-mehr-benzin.de
12-29-2012, 12:42 PM
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?

"49,547" is a timestamp (<seconds>,<milliseconds>)

the columns are:

<timestamp> <canid> <numberofbytes> <data>

The result data is:

5EC Byte 2 Charging Current units 0.2 A (ex. 0x43 = 13.4 A)
5EC Byte 3 Charging Voltage units 2 V (ex. 0x70 = 224 V)

the previous example was the raw log from the DashDAQ with all bootup-commands, which the DashDAQ is sending on the bus before reading single data. My previous posts were only "thinking aloud" ;)

To get the data from the charger you have only to send the two 7E4-commands in sequence:

7E4 8 06 2C FE 43 69 43 68 00
7E4 8 03 AA 04 FE 00 00 00 00

nie-mehr-benzin.de
12-29-2012, 01:04 PM
While DashDAQ is reading all available signals from the bus, the sequences are as follows:


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

tboult
12-29-2012, 03:52 PM
"49,547" is a timestamp (<seconds>,<milliseconds>)

the columns are:

<timestamp> <canid> <numberofbytes> <data>

The result data is:

5EC Byte 2 Charging Current units 0.2 A (ex. 0x43 = 13.4 A)
5EC Byte 3 Charging Voltage units 2 V (ex. 0x70 = 224 V)

the previous example was the raw log from the DashDAQ with all bootup-commands, which the DashDAQ is sending on the bus before reading single data. My previous posts were only "thinking aloud" ;)

To get the data from the charger you have only to send the two 7E4-commands in sequence:

7E4 8 06 2C FE 43 69 43 68 00
7E4 8 03 AA 04 FE 00 00 00 00


Ah. thanks. That makes more sense. So we are seeing the DashDaw send a request and then the responses from it. Interesting that the not a PID formated request. I was hoping to adapt this for use in torque with android, but it is very PID centric..

Kratus
12-29-2012, 11:14 PM
Kudos Johannes, great results!

nie-mehr-benzin.de
12-30-2012, 03:58 AM
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:



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)


37,611 5EC 8 FE 31 29 71 60 60 00 00

=> 0x60

...the 4C1 at the same time in the same log was:


37,619 4C1 8 10 C3 30 35 61 00 00 00

=> 0x61

German-Volt2012
12-30-2012, 07:07 AM
I think 4C1 byte 5 is not the outside temperature, because I saw the following data in my logs:



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



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


37,611 5EC 8 FE 31 29 71 60 60 00 00

=> 0x60

...the 4C1 at the same time in the same log was:


37,619 4C1 8 10 C3 30 35 61 00 00 00

=> 0x61

Sorry,

but i think RScott is right. But we are in Germany. And so the Value is Celsius.
I checked my old Logs, and the value is right. T = (hexindez(CAN ID 4C1 Byte 5) / 2 ) - 40

Bye
German-Volt2012

nie-mehr-benzin.de
12-30-2012, 07:17 AM
Sorry,

but i think RScott is right. But we are in Germany. And so the Value is Celsius.
I checked my old Logs, and the value is right. T = (hexindez(CAN ID 4C1 Byte 5) / 2 ) - 40

Bye
German-Volt2012

hmm, but why there are two different values for the same temperature? I'm not describing a Fahrenheit<->Celsius - Problem. The values in 5EC are definitely right, because they are the same as in the DashDAQ display. The 4C1 differ.

nie-mehr-benzin.de
01-01-2013, 01:09 PM
I've decoded the requests.

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


One Single PID:

7E4 8 04 2C FE <PID> 00 00 00

Two PIDs:

7E4 8 06 2C FE <PID1> <PID2> 00

Three PIDs:

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:


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 => 8C (unit 1 C offset 40) )


to request the ambient temperature:


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 => 7C (unit 1 C offset 40) )

tboult
01-01-2013, 06:47 PM
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 )

Burro
01-01-2013, 07:19 PM
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.

John_Hatchett
01-01-2013, 07:20 PM
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 )

No No. You need to put the skies away and get on this right away..... :)

John_Hatchett
01-01-2013, 07:35 PM
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.

Welcome to gm-volt!

Ladogaboy
01-01-2013, 10:00 PM
Thanks for doing this, guys. CAN bus definition files make me want to go suck my thumb in a corner somewhere. The coding is bad enough even when I already know what everything represents.

tboult
01-04-2013, 11:21 PM
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.

Burro
01-05-2013, 05:19 PM
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)


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.

John_Hatchett
01-05-2013, 05:41 PM
So I have a burning desire to display instant watts/mile or something similar on my android/torque setup.

eventually would like to have any extraneous loads, like cabin heating and lighting, extracted from that display.

tboult
01-05-2013, 05:58 PM
So I have a burning desire to display instant watts/mile or something similar on my android/torque setup.

eventually would like to have any extraneous loads, like cabin heating and lighting, extracted from that display.

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.

Burro
01-05-2013, 08:13 PM
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.


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.

Burro
01-05-2013, 08:57 PM
These are the only ones I think I know for the rest of the modules. I havent worked with any GM hybrids before so the 0x7E4 are pretty much all new territory. As before, the scaling should be verified.


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

tboult
01-05-2013, 11:27 PM
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).

John_Hatchett
01-06-2013, 06:10 AM
reasonable device on sale for android/torque setup. $129 Samsung 5" with Bluetooth and WiFi.

http://1saleaday.com/wireless/?cj=true


any ideas on how to capture the command for "hold mode" from a MY2012 Ampera to see if we can command a MY2012 Volt into hold mode?

MY2013 Volt owners would probably love to have a "12 Amp Charge" command as well.

tboult
01-06-2013, 09:40 AM
reasonable device on sale for android/torque setup. $129 Samsung 5" with Bluetooth and WiFi.

http://1saleaday.com/wireless/?cj=true


any ideas on how to capture the command for "hold mode" from a MY2012 Ampera to see if we can command a MY2012 Volt into hold mode?

MY2013 Volt owners would probably love to have a "12 Amp Charge" command as well.


Well I'm using an old Google Nexus phone (too old to really be usable as a phone, perfectly fine for torque), Also used a droidX (bought used for about $35 as the phone side had a bad EIN, however I am now using that or a project as it has a better camera so went back to the nexus S). Before that I used an even older G1.. Torque does not need much of a CPU.. $125 seem a lot, its 1/4 of the way to a dashdaq, but to each his own.

Torque won't work for full bus snooping, for that I use other software talking to my laptop (macos), but I could probably get you a setup to do that for either mac or PC. For full bus snooping I use a usb-based device as bluetooth may not be fast enough to capture all the bus traffic reverse engineering hold mode would be fun..

It is, however, likely Hold mode needs a firmware update to save added state in the ECU. For mountain mode the setpoint fo SOC was pre-determined long ago so it is likely hard coded in the firmware as a constant. For Hold-mode some ECU will have to store the desired new SOC so it can operate around that new set-point. Thus I expect that its not just sending a command, but also a "firmware" fix. I think that is what GM means by the statement that hold-mode takes hardware updates. (though to me a firmware fix is not hardware, to others it is)

dpeilow
01-06-2013, 09:45 AM
Looks like you guys have made good progress. Any luck with remote commanding cabin pre-conditioning?

I'd love to have an Android app showing realtime power and energy graphs, Tesla style.

tboult
01-06-2013, 10:31 AM
Looks like you guys have made good progress. Any luck with remote commanding cabin pre-conditioning?

I'd love to have an Android app showing realtime power and energy graphs, Tesla style.


At least for now that was not even on my radar to try. but I could see the folks in the EU wanting that. Me I just want data, not really commands. I have onstar and dont' precondition now. I could see preconditioning being a bite more complex as one as to wake the car's systems, but at least it does not need a firmware change ;-)
That is more of a low-level canbus hack monitoring thing (which I guess I could do) to see what happens when I hit the remote-start key fob as well as remote initiate via on-star).

My goals are getting to the data we 2011/2012 users don't get (like real-time kWh feedback) and graphs/logs of energy/power over time/location, which only dashdaq users get now.

John_Hatchett
01-06-2013, 11:50 AM
If I am understanding some of the materials, it seems like an soft ECU can spoof any other vehicle ECU by remapping the original ECU onto a temporary bus id, echo it back onto the bus using the original bus id, and selectively replacing values like SOC. If that is the case, then hold mode might be accomplished by remapping the actual SOC values into a range of normal CS mode cut in values, i.e. just subtract a snapshot value from the real SOC and put it back on the bus.

dpeilow
01-06-2013, 12:02 PM
At least for now that was not even on my radar to try. but I could see the folks in the EU wanting that. Me I just want data, not really commands. I have onstar and dont' precondition now. I could see preconditioning being a bite more complex as one as to wake the car's systems, but at least it does not need a firmware change ;-)

That would be fantastic if you could try. Pre-conditioning was so useful during the recent cold snap but I can only do it at work for my return trip. My garage at home is too far from the apartment for the key fob to reach in the morning.

If it can be done, I'll order an OVMS immediately :-)

All the other stuff will be great too, but bells and whistles compared to remote pre-heat.

tboult
01-06-2013, 12:07 PM
If I am understanding some of the materials, it seems like an soft ECU can spoof any other vehicle ECU by remapping the original ECU onto a temporary bus id, echo it back onto the bus using the original bus id, and selectively replacing values like SOC. If that is the case, then hold mode might be accomplished by remapping the actual SOC values into a range of normal CS mode cut in values, i.e. just subtract a snapshot value from the real SOC and put it back on the bus.

From my reading that is not how the dynamic PIDs work, and even if they did its not clear the core systems are using dynamic PIDs..

Dynamic PIDs provide a way for a instrument to request data in less overhead. If one issues a dynamic PID, the other data stil keeps flowing on the bus, and the ECU still responds to normal PIDs. One of the points of the DPID is to allow lots of data to flow without repeated requests.. but if the normal request happens it is still honored.

One could spoof data on the bus and answer questions that are intended for a real ECU, but this is likely to cause problems as the receiver will get two sets of conflicting data... and someone would through a error or worse.
(I though about doing that for the ERDTLT, and just spoofing temp data.. but the I realized the OAT goes into HPCM2 which is likely where the decisions are made.

I would expect the same type of thing happens, the core control for switching to hold mode is probably in the ECU that directly measures the battery.. So one could not spoof the battery level.. it would need to keep sending commands to keep the engine on, while the EPCM2 sends it commands to turn off.

Burro
01-06-2013, 12:56 PM
I have agree with tboult. What you are asking to do is much more complex than just requesting information. PIDs don't have anything to do with this type of request, it will all come across the bus as general CAN messages between modules. It is easy enough to monitor the bus to see what happens when different things are requested but in order to simulate information you would need some way to remove the module from the bus during that simulation. Given the complexity of the interaction, I don't think it would be a good idea.

Since I don't have a Volt I will give a generic example. Say you want to remote start the vehicle. In order to accomplish this, you monitor the bus during a typical remote start and figure out that message 0x100,8,12,34,56,78,11,22,33,44 must be sent across the bus. That is easy enough to accomplish but the module that natively sends that message will be sending out something different. Best case scenario is that the car simply won't start. Now, if you could isolate the module from the bus, you might get the car to start but in addition to message 0x100, that same module also sends out 0x101, 0x102, 0x103, and 0x104. Now you need to know what information those messages contain in order to accurately simulate them. Any variation in that content could have dire consequences. Simply sending the same messages you recorded in the earlier bus monitoring session might be good enough, it might not.

tboult
01-06-2013, 05:12 PM
For the precondition-remote start I think it may be doable. Since the car already has two modules, one that is receiving the remote control's signal, and the on-star modules. Thus I would conjecture that it is likely what ever module can send remote start signal, is aware the other might also, so at least in the EU, where there is no onstar module, sending the sequence as if its on-star doing the remote-start, should not make the remote-control's module freak out.

I see hold mode I see it as much more difficult to spoof, as the other modules in the car for real would want to keep doing their jobs, which would want to turn off the ice.

My ideas for hold-mode spoofing were originally to mess with the OAT signals, and/or to splice into the OAT thermistor and be able to change the effective temperature by changing resistance. However that is much more hacking and I've not had much time, and with maybe 1-2 gallons a year lost to ERDTLT, its not a priority. Figuring out the stuff on the bus is at least fun for me

RScott
01-06-2013, 08:26 PM
So I have a burning desire to display instant watts/mile or something similar on my android/torque setup.

eventually would like to have any extraneous loads, like cabin heating and lighting, extracted from that display.

As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

So going back to watts/mile, that's doable with method #2. You can get take 2 separate readings of the battery SOC (to determine net kWh used), as well as figure out the mileage between the two (slightly trickier, due to a number that rolls over), and determine the watts/mile. If Torque or other apps can use the "Monitor All" mode, and do calculations, they should be able to display watts/mile.

markwj
01-06-2013, 08:57 PM
As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

Mark (from OVMS) here. I'm really grateful to dpeilow for starting this thread, and to all the other contributors here. While my primary focus is OVMS and helping you guys to get it work on the Volt/Ampera, it is also gratifying to see all the other useful stuff come out of this discussion (such as in-car real time displays for performance monitoring).

From OVMS point of view, we are a direct CAN bus interface with full control of the CAN bus (we don't use an ELM chipset, but instead are a direct CAN bus participant). We can both monitor (passive mode 2, in RScott's terminology) and actively request data (mode 1 in RScott's terminology). Looking at what is on the bus, I suspect we will have to do both to get us all the information we require (as some of the data does not seem to be always transmitted for passive collection, and is only available on request).

Regarding remote vehicle monitoring (state of charge, temperatures, charging, etc), I think we have enough now to be able to code this - and have already started work. The Apps are already showing SOC, and with the extended PIDs discovered here we should be able to get charge state, voltages, current and temperatures (including alerts for charge interrupted).

Regarding remote vehicle pre-condition start, what we need to start is a CAN bus dump of a remote start from OnStar (best) or key fob (also may work). The dump should start when the car is idle (hopefully no bus activity at all), and end a few seconds after the car has finished its startup. Hopefully we can identify the new CAN bus commands used to instruct the car to start.

The Tesla Roadster (the first OVMS car) has a VMS on ID#100 and a VDS display/touchscreen on ID#102. The VDS listens for messages on ID#100 to produce its display, and when you issue a command (e.g. lock car, stop charge, etc) the VDS transmits on ID#102 to the VMS. For OVMS, all we do is spoof those exact same ID#102 messages. From the VDS point of view, it doesn't care (it is probably not even listening to those ID#102 messages), and from the VMS point of view, it looks like the VDS is sending it commands. It works very well, and allows us to remotely do pretty much anything that can be done in the car itself (from the VDS). Now, I realise that the Volt/Ampera may be different, but I think there is a good chance this will work (otherwise it would be very hard for OnStar to implement remote start / pre-heat).

Regards, Mark.

tboult
01-06-2013, 09:42 PM
As a reminder for those in this thread, there are two very different ways of getting data from the Volt:

[1] The traditional 'active' method (that the DashDAQ and Torque use), where you make a request for data and get it. This is by far the most common (close to only) method.

[2] The passive ("Monitor All") method, where you can listen to all messages that the Volt sends/receives. I believe that OVMS uses this method.

I believe you cannot easily use both methods at the same time (I.E. you cannot send out a request while in the "Monitor All" mode), but I'm not 100% certain.

So going back to watts/mile, that's doable with method #2. You can get take 2 separate readings of the battery SOC (to determine net kWh used), as well as figure out the mileage between the two (slightly trickier, due to a number that rolls over), and determine the watts/mile. If Torque or other apps can use the "Monitor All" mode, and do calculations, they should be able to display watts/mile.

I've tried some MA in bluetooth to the android but I get many corrupted packets suggesting it cannot keep up. USB passive monitoring was okay but I don't really want a wire every day.

How many bytes are you getting for SOC in MA mode?

If 1 byte then it is too course for instantaneous kWh.. But with only 16kwy/255 each "tick" is .062 kWh. Okay for a running average every min or so) as its about 4 ticks per mile (if one is doing 40miles/charge).

There are fields for instant volt and amps which is what I'm looking for for instant kWh..
If I don't any more help from dashdaq folks, I'll probably do some Y-cable work with MA and torque in parallel so I use what you've learned to try to figure out the PIDs.

RScott
01-07-2013, 10:28 AM
I've tried some MA in bluetooth to the android but I get many corrupted packets suggesting it cannot keep up. USB passive monitoring was okay but I don't really want a wire every day.

How many bytes are you getting for SOC in MA mode?

If 1 byte then it is too course for instantaneous kWh.. But with only 16kwy/255 each "tick" is .062 kWh. Okay for a running average every min or so) as its about 4 ticks per mile (if one is doing 40miles/charge).

There are fields for instant volt and amps which is what I'm looking for for instant kWh..
If I don't any more help from dashdaq folks, I'll probably do some Y-cable work with MA and torque in parallel so I use what you've learned to try to figure out the PIDs.

The Volt does have a massive amount of data constantly being sent. It uses a 500kbps speed, but most OBD2 adapters transmit the data in ASCII, which more than doubles the amount of data being transferred. From my understanding, Bluetooth cannot quite handle the traffic (for passive/MA). Wifi would be ideal, but is expensive (as very few cars would need it).

For SOC, I get 3 bytes: 2 with the SOC, and a null byte. For example, "206 8CBA00" where the SOC is 8CBA (hex) or 36,026 decimal, or 9.0065kWh (36,026/4000).

There are some instantaneous electric usage readings available in MA, but I haven't figured them all out. I believe 3E3 is power flow in/out of the battery (sent about 1-2 times per second), but not certain of that.

Burro
01-07-2013, 12:08 PM
The Tesla Roadster (the first OVMS car) has a VMS on ID#100 and a VDS display/touchscreen on ID#102. The VDS listens for messages on ID#100 to produce its display, and when you issue a command (e.g. lock car, stop charge, etc) the VDS transmits on ID#102 to the VMS. For OVMS, all we do is spoof those exact same ID#102 messages. From the VDS point of view, it doesn't care (it is probably not even listening to those ID#102 messages), and from the VMS point of view, it looks like the VDS is sending it commands. It works very well, and allows us to remotely do pretty much anything that can be done in the car itself (from the VDS). Now, I realise that the Volt/Ampera may be different, but I think there is a good chance this will work (otherwise it would be very hard for OnStar to implement remote start / pre-heat).

Regards, Mark.

Mark,

You may very well be right but I would be surprised if you can remote start the vehicle and keep it running just by sending the request across CAN. Sending a command like unlock a door is easy enough because you aren't fighting the existing control module. You send the command and the module carries out that request. There is no need to continually send the unlock request. I bet after the first time you send the remote start request, either the telematics module or BCM will come to life and contradict the request, shutting the engine down(if it even gets started). If you continually send the remote start request and a competing module sends a shutdown request, the module should default to the safest state which would be engine off.

I know this has been tried before on other GM vehicles. I don't think anyone ever got it to work without editing the module programming. That being said I am all for someone giving it a shot, if any one can get a passive recording of the HSCAN bus during a keyfob remote start event you are probably looking for a signal that contains databytes 04 0B. I don't know the arbitration ID.

John_Hatchett
01-07-2013, 07:08 PM
Regarding remote vehicle pre-condition start, what we need to start is a CAN bus dump of a remote start from OnStar (best) or key fob (also may work). The dump should start when the car is idle (hopefully no bus activity at all), and end a few seconds after the car has finished its startup. Hopefully we can identify the new CAN bus commands used to instruct the car to start.

All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?

tboult
01-07-2013, 07:26 PM
All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?


is your the elmscan with USB or rs232 connector? I still think any ELMSCAN can log all bus data (using MA to monitor all. )It would need the serial port set to its highest speed (1 or 2 mbit).

markwj
01-07-2013, 07:28 PM
All I have is an Elmscan. If I get the OVMS hardware module and cable can I log the CAN bus and send it to you?

With something like ELMSCAN, you need a MA (Monitor All) dump. I think one of the other members on this forum could help with that.

The OVMS module can't (at the moment) get a can bus dump. While it can capture data from buses running at up to 1Mbps, it really doesn't have anything fast enough to get the data out (to a laptop, whatever).

markwj
01-07-2013, 07:45 PM
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.
...
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.
...
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.

OK. Having reviewed all this, it looks like we're going to have to regularly poll perhaps 10 extended PIDs. Most of these don't need to be polled very often (perhaps once a minute or so would be fine).

What we should probably do is setup a table of modules and PIDs we want with corresponding poll times. The code will then check this and poll each one in turn. We can rely on the +0x08 and -0x200 offsets from the module ID (which will allow us to query different PIDs on different modules). The reply doesn't seem to contain information on the PID being returned, so presumably we'll have to use the response ID to match responses to requests. To avoid conflicting with DashDaq, does anyone know if DashDaq uses a specific range, or is there some other way of avoiding conflict?

My question is: what is the best way of polling these? We've seen DashDaq use mode 0x2c with response rate 0x04, but that generates a stream of 160 or so responses and seems excessive for what we need. Do you think it best we use mode 0x2c with response rate 0x01 (single response?), or mode 0x22?

Can someone try a mode 0x2c request with response rate 0x01 and see what comes back? Perhaps:



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 01 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 => 8C (unit 1 C offset 40) )

How may 5EC responses come back?

John_Hatchett
01-07-2013, 08:07 PM
is your the elmscan with USB or rs232 connector? I still think any ELMSCAN can log all bus data (using MA to monitor all. )It would need the serial port set to its highest speed (1 or 2 mbit).

USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

tboult
01-07-2013, 08:47 PM
USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

If OBDwiz does not work, http://sourceforge.net/projects/pyobd2/ has a record all mode which is pretty easy to use.


My concern with spoofing OAT messages is that they are sent from the HPCM2, which is likely the same ECU that makes the decision and sends out message about starting the engine.. so not clear it would listen to us sending data about the OAT. (Note that would not be a PID.. it would have to watch to see what OAT was sending and then spoof it. Since OAT sends data regualrly it would be a fight.

A slightly safter approach might be to try to spoof it with the hood open switch, but that too is directly connected into the HPCM2 (connector X1 pin 52).. so I don't think it could be spoofed. (It also seems to go to the body-control-module, so it may be worth checking if the BCM is sending out anything, but again I expect its a direct connect to the HPCM2 so not spoofable). It would likely be possible to add a swtich (X1 connector is under the passenger seat), to spoof open/close.

tboult
01-07-2013, 08:51 PM
USB. I also have a Bluetooth version that I use with Torque on several vehicles.

My elmscan came with OBDwiz which has a terminal mode so I think it isn't too hard to get into MA mode and log the file. I'll try it when I get the Volt back from my son later this week. He disappears with the car during school breaks.

Could we get "hold mode" by spoofing a low OAT message onto the bus or would that only get it to warm up the coolant?

If OBDwiz does not work, http://sourceforge.net/projects/pyobd2/ has a record all mode which is pretty easy to use.


My concern with spoofing OAT messages is that they are sent from the HPCM2, which is likely the same ECU that makes the decision and sends out message about starting the engine.. so not clear it would listen to us sending data about the OAT. (Note that would not be a PID.. it would have to watch to see what OAT was sending and then spoof it. Since OAT sends data regualrly it would be a fight.

A slightly safter approach might be to try to spoof it with the hood open switch, but that too is directly connected into the HPCM2 (connector X1 pin 52).. so I don't think it could be spoofed. (It also seems to go to the body-control-module, so it may be worth checking if the BCM is sending out anything, but again I expect its a direct connect to the HPCM2 so not spoofable). It would likely be possible to add a swtich (X1 connector is under the passenger seat), to spoof open/close.

Burro
01-07-2013, 10:48 PM
OK. Having reviewed all this, it looks like we're going to have to regularly poll perhaps 10 extended PIDs. Most of these don't need to be polled very often (perhaps once a minute or so would be fine).

What we should probably do is setup a table of modules and PIDs we want with corresponding poll times. The code will then check this and poll each one in turn. The reply doesn't seem to contain information on the PID being returned, so presumably we'll have to use the response ID to match responses to requests. To avoid conflicting with DashDaq, does anyone know if DashDaq uses a specific range, or is there some other way of avoiding conflict?

My question is: what is the best way of polling these? We've seen DashDaq use mode 0x2c with response rate 0x04, but that generates a stream of 160 or so responses and seems excessive for what we need. Do you think it best we use mode 0x2c with response rate 0x01 (single response?), or mode 0x22?


Mark,

I would do everything you can to try to identify the signals as they come across the bus natively. If the stories about scangauge causing problems are due to a limited amount of bus capacity left, you should do as much with the signals that are already there as possible to avoid causing problems in the future when the inevitable request for more parameters comes along. Once you have that done, I don't think it really matters whether you use 0x22 or 0x2C. With such a low raster rate, you really arent buying yourself anything by using 0x2C. I think coding the 18F(assuming you are using the OVMS) for mode 22 action would be much easier than trying to lump all 10 signals into one big 0x2C request and then trying to parse out the results through the continuation frames. I havent looked at your OVMS coding too closely but if you use mode 22 you can probably use some of your existing functions without the need to write all new routines.

If you are set on using 0x2C I would try to lump the signals into manageable packets that don't require the handling of the continuation frame on either the Tx or Rx side. That probably limits you to 2 signals per request. I don't know if the dashdaq always uses identifiers in the Fx range but all the traffic I have seen so far seems to indicate that is the case. With 256 possible identifiers you should be able to find a sweet spot that won't interfere.

Your idea of a table with id's and polling times is a good one. Once you determine that and which signals you can passively acquire, the mode will probably fall into place based on the amount of time you want to spend coding and the memory left on the 2685.

tboult
01-07-2013, 11:36 PM
If there is a table with "needed" data and timing, then passive monitoring could be used as much as possible and when the needed data is not there, then a mode 22 pID request could fill it in. Using PID request could help us identify the data that is just naturally flying around, allowing us to correlated values. and then the PID usage could be reduced as much as possible.

I've been doing some pretty hefty logging these past two days, with 120 PIDs being polled and have not had any problems. I did reduce my polling rate to about 6 polls of 120 per second (so about 720 PIDs per second) and at that rate I never noticed any problems with the car.

markwj
01-08-2013, 09:13 PM
I don't think it really matters whether you use 0x22 or 0x2C. With such a low raster rate, you really arent buying yourself anything by using 0x2C. I think coding the 18F(assuming you are using the OVMS) for mode 22 action would be much easier than trying to lump all 10 signals into one big 0x2C request and then trying to parse out the results through the continuation frames. I havent looked at your OVMS coding too closely but if you use mode 22 you can probably use some of your existing functions without the need to write all new routines.

The 2C is quite messy as it is a 2-stage request. First the setup, wait for reply, then request for data, then wait for data.

Is 22 easier? Given the small number of PIDs being polled and slow poll rate, I don't see the one-pid-per-request of 22 being a problem. Do you have a simple example for a 22 request (for example for the 0x0046 PID on 7E0)?

I pushed the code for polling to github last night. You can see it at:

https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/vehicle_voltampera.c

Not too complex. But, according to first reports it is not getting the responses (which I suspect is because I'm not doing the 2-stage request but merely transmitting both requests together).

What I see on the can bus, for my code is the following pair of messages transmitted once every ten seconds:


7E0 8 04 0C A0 00 46 00 00 00
7E0 8 03 AA 01 A0 00 00 00 00

I don't have the car, so can't know the reply :-)

markwj
01-08-2013, 09:22 PM
I know this has been tried before on other GM vehicles. I don't think anyone ever got it to work without editing the module programming. That being said I am all for someone giving it a shot, if any one can get a passive recording of the HSCAN bus during a keyfob remote start event you are probably looking for a signal that contains databytes 04 0B. I don't know the arbitration ID.

I guess my question is 'how does OnStar do it?'. I had assumed that the car has the functionality built in, and the OnStar module is merely sending the command over the bus to turn on that function. That is how it works in the Tesla Roadster, but the Volt/Ampera is a very different beast.

tboult
01-08-2013, 10:56 PM
The 2C is quite messy as it is a 2-stage request. First the setup, wait for reply, then request for data, then wait for data.

Is 22 easier? Given the small number of PIDs being polled and slow poll rate, I don't see the one-pid-per-request of 22 being a problem. Do you have a simple example for a 22 request (for example for the 0x0046 PID on 7E0)?

I pushed the code for polling to github last night. You can see it at:

https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/vehicle/OVMS.X/vehicle_voltampera.c

Not too complex. But, according to first reports it is not getting the responses (which I suspect is because I'm not doing the 2-stage request but merely transmitting both requests together).

What I see on the can bus, for my code is the following pair of messages transmitted once every ten seconds:


7E0 8 04 0C A0 00 46 00 00 00
7E0 8 03 AA 01 A0 00 00 00 00

I don't have the car, so can't know the reply :-)


Yes 22 is an easier single state call.

Let say you wanted engine RPM then you would send
7E0 03 22 00 0C 00 00 00 00

And this will hopefully return:
7E8 04 62 00 0C 10 7E 00 00

Letting A=10 B=7E from the return, RPM = (A*255+b)/4 or 1055 RPM.


Format of the return data is
requsedID+0x08,
length,
confirm of requested mode+0x40 (i.e. 22 + 40)
2 bytes for PID
length-2 bytes of data


For your request for OAT

7E0 03 22 00 46 00 00 00 00

would response something like

7E8 03 62 00 46 30 00 00 00 00
(answer as before is Temp (now in in Byte 4) where 0x30 => 8C (unit 1 C offset 40) )

Burro
01-08-2013, 11:23 PM
Mark,

I don't use MPLABX so I will need to rebuild the project in MPLAB8 when I get a chance. I did take a look at the Volt specific C file though. It isn't my place to criticize your code but that file is a mess right now. If you are going to poll on mode 22, I would revamp the entire thing. Use ECAN mode 0 and then use the 6 filters to parse out the module response ID's(0x7E8 in tboult's example). Now you can poll RXBxD2 or RXBxD3.

Burro
01-08-2013, 11:38 PM
I guess my question is 'how does OnStar do it?'. I had assumed that the car has the functionality built in, and the OnStar module is merely sending the command over the bus to turn on that function. That is how it works in the Tesla Roadster, but the Volt/Ampera is a very different beast.

It is all conjecture at this point since I dont have the car either but based on past experience I think it works like this:

You send the car the remote start command, if it is through the OnStar system then the telematics module receives the command, wakes up the bus and sends a CAN message(via MSCAN) to the BCM(a gateway module) telling it to start the car. It is easy enough to spoof that command but the problem is that as soon as you send that remote start message the telematics module will wake up and send a message using that same ID that contains a remote start inactive command. So now you have two messages continually coming across the bus with the same id. One says start and the other says do not. Assuming the modules employ proper error handling procedures, the car should turn off.

That being said, if the telematics module doesnt wake up or the remote start request is a one time command and does not require a continuous affirmation then you should be able to simulate it. It is worth a try, I just wouldnt be surprised if it doesnt work.

markwj
01-09-2013, 01:43 AM
Yes 22 is an easier single state call.

Let say you wanted engine RPM then you would send
7E0 03 22 00 0C 00 00 00 00

And this will hopefully return:
7E8 04 62 00 0C 10 7E 00 00


Perfect. That looks much easier to deal with, and gives us what we need. I've asked the guys with the car to check it out for the PIDs that we know.


I don't use MPLABX so I will need to rebuild the project in MPLAB8 when I get a chance. I did take a look at the Volt specific C file though. It isn't my place to criticize your code but that file is a mess right now. If you are going to poll on mode 22, I would revamp the entire thing. Use ECAN mode 0 and then use the 6 filters to parse out the module response ID's(0x7E8 in tboult's example). Now you can poll RXBxD2 or RXBxD3.

Comments / criticism always accepted :-) The code was thrown together as a proof of concept. The problem is that I don't have the car, and there is an 8 hour time difference to those who do, so we're having a lot of back-and-forth. Using 0x22, about 1/3rd of the code goes away (in particular the temporary messy stuff to deal with 1, 2 or 3 pid polls).

According to http://www.evtools.info/ChevyVoltOBD2CAN.html and the dumps we have, the only high IDs seen are: 770, 772, 773, 778, 77D, 77F and 787. The two new ones we've seen (from Dashdaq) are 7E8 and 7EC. Even with other modules around there to talk to, we can probably do this with a single filter (with appropriate checking of the actual ID received).

RScott
01-09-2013, 06:48 AM
You send the car the remote start command, if it is through the OnStar system then the telematics module receives the command, wakes up the bus and sends a CAN message(via MSCAN) to the BCM(a gateway module) telling it to start the car.

That is my understanding. The OnStar module does send lots of CAN messages (e.g. hour of day, latitude, longitude), and when the car is off the bus needs to be woken up.

Without knowing what data OnStar uses, it could either be a toggle ("Remote Start On" or "Remote Start Off"), or a command ("Initiate Remote Start").

Something else worth mentioning at this point is the multiple CAN buses that the Volt uses; last I checked, it looked like there were 5 of them (some using the primary OBD2 connector, some using the auxiliary). Most tools can only read one of them (although they all use the same OBD2 connector, so the right tool can in theory read them all).

Burro
01-09-2013, 08:06 AM
I understand, I debated whether or not to say anything but I didn't want you to continue on that path if it wasnt necessary. The site you referenced has some good info, I wasn't aware of it. The list of Arb ID's that they presented are simply a list of regularly transmitted messages. The 0x7XX messages won't be a part of that because they are sent by the tester. 0x7E0 is normally the lowest id so you don't need to worry about anything less than that if you are going to actively request information. Anytime you request information from a module, that module responds on the original ID + 8. So when you ask for something from 0x7E0 you will get a response from 0x7E8. Those aren't new id's, they just dont exist on the message list because the tester specific ones dont either. Based on the type of information this group would be interested in you will probably only need filter 0x7E8(Engine controller) and 0x7EC(Battery module).

At this point I think it is fair to assume, the ability to request the information is there. This group should come up with a list of PIDs that they are interested in so you can get to work coding it in. The list of parameters supported by dashdaq is floating around in one of these posts, that would be a good starting point. Once the list is constructed someone with a dashdaq and the ability to record raw CAN traffic should request the PIDs one at a time so we can match up the ID's with the name and formulate the scaling.

John_Hatchett
01-09-2013, 05:39 PM
Can I suggest a 3 different groups of messages?

A) OVMS (Onstar functionality replacement for Ampera and non-subscribers)

Charging Status
SOC
240V/120V
Charge Start/Stop
Delayed Charge
Remote start
Remote lock/unlock
Remote disable
Current GPS Location
Battery temperature
fuel status
odometer
EV miles
gasoline consumed
kWh consumed
etc..

B) Volt specific Torque (realtime in car display and drive time commands)
SOC
kWh/100 miles
Drivetrain KW
Accessory KW
EV+ mode (turn off HVAC, seat heaters, etc..)
Mountain Mode Start/Stop
Hold Mode Start/Stop (if possible)
etc...

C) Volt Specific OBDII (deep dive display and trouble shooting diagnostics)
Modules/Cell Voltages
etc...

dpeilow
01-12-2013, 05:46 PM
I second John's suggestions with the only addition of remote cabin temperature adjustment, if possible.

dpeilow
01-13-2013, 05:36 PM
By the way, the Ampera doesn't have Onstar and I was told doesn't even have the module, yet it still remote starts from the key fob. So I guess it is possible to wake the car up without the telematics module.

markwj
01-14-2013, 08:45 AM
A short update:

The service 0x22 is working really well. We're polling a bunch of PIDs now, and getting the data we need.

I just committed a bunch of code to give us:


Tickers to show us whether the car is asleep / awake
Charging / Not Charging state support (the Apps should now show the car charging as appropriate)
Charge Time and kWh derivation
Derivation of Charge Done vs Interrupted (by checking if SOC > 95% when charge finished)
Notification of charge interruption (SMS, PUSH, etc) if charge ends with SOC <= 95%.
car_idealrange and car_estrange kludgy approximation (based on SOC% * 37 miles). We really need to find these on the CAN bus (or extended PIDs) to get this better, but at least now they are non-zero.


That is in addition to the SOC, charging current, charging voltage, VIN, temperatures, GPS location and other ancillary stuff we had before.

So, now we're going to test and fix the bugs for the above. Then, it is on to PID searching for the remaining stuff. Things like TPMS, remote start, lock/unlocking, etc, still to go.

A big thanks to everyone who has helped us get to where we are now. I think we're almost over the hill and then it is regen all the way down the other side.

Regards, Mark.

tboult
01-14-2013, 09:31 AM
I presume your system has some storage for variables.
For your estimate range, you might use their most recent trip length / most recent trip energy useage * full battery size.

You can get EV miles of a trip from
PID 24 87, to 7E1, which returns 2 bytes and then (A*255+B)/160.0 = EV distance in miles on this drive cycle.
(Pretty sure on the conversion though it may need more testing to check the formula.. it might also be (/ 100 = km.. but I only tested on small trips so not positive).

If you track SOC at beginning of a trip and the EV miles on the trip, you can estimate kWh/km and get a better estimate than just multiplying by 37miles.

You might get a better estimate by using a filter and using kWh/km for multiple trips and weighting them.

And reporting kwH/mi or kWh/km on the last trip would be a nice thing anyhow.

markwj
01-14-2013, 08:48 PM
I presume your system has some storage for variables.
For your estimate range, you might use their most recent trip length / most recent trip energy useage * full battery size.

I'd really like to use the same logic as the car (or better yet, just show the car calculation).

We had a problem with the Tesla Roadster support in that our conversion formula Miles->KM was different than the car's. The rounding was slightly different. The car would say 121km range, and the App 120km. It just caused confusion, and wasn't elegant. The solution was to change our formula and rounding to 100% match the car's - so that what is shown on the Apps is just an exact reflection for what is shown in the car.

I'm pretty sure the Volt/Ampera has an estimated range figure shown on the dashboard, right?

markwj
01-14-2013, 08:52 PM
OBDII has a way of scanning for supported PIDs, right? Anyone know how it works?

I see from http://en.wikipedia.org/wiki/OBD-II_PIDs that PIDs 0x00, 0x20, 0x40, etc, report a bitmap of supported PIDs.

Any idea how to scan for supported extended PIDs?

tboult
01-14-2013, 10:42 PM
OBDII has a way of scanning for supported PIDs, right? Anyone know how it works?

I see from http://en.wikipedia.org/wiki/OBD-II_PIDs that PIDs 0x00, 0x20, 0x40, etc, report a bitmap of supported PIDs.

Any idea how to scan for supported extended PIDs?


Tried the scans for 0x00, etc.. .. did not show much was there beyond the mandated standard PIDs.
In torque I can see all the standard engine stuff, but the more fun EV stuff is not in the standard data.

Did not find a way to scan for supported extended PIDs. Until someone posted some dumps of the DashDaq I had not figured out much.. now I have mapped many (see my earlier posts) and when I get home from this trip will do a bit more to veryify things like real-time Volt and Amps and a few others I think I've figured out now.




Nothing I've seen has shown the car's estimate as a PID (its not not in the list of dashdaq data).

markwj
01-15-2013, 07:20 AM
The only way I saw to scan for extended PIDs is to

7E0 03 22 00 01 00 00 00 00
(wait for reply)
7E0 03 22 00 02 00 00 00 00
(wait for reply)
7E0 03 22 00 03 00 00 00 00
(wait for reply)
repeat ad nauseum

65,536 times for each controller. The reply code 0x62 (0x22+0x40) is GOOD, and 0x7F is error. We're finding it takes around 7ms for each reply, so perhaps 7 minutes per controller? That is about 20 times as bad as the PID 0x00, 0x20, 0x40, etc approach, but still workable I guess.

dpeilow
01-15-2013, 02:42 PM
I'm pretty sure the Volt/Ampera has an estimated range figure shown on the dashboard, right?

Right.

Another interesting artifact is that I have been running one of the "trips" from the day I got the car. It shows a slightly different MPG to the lifetime MPG on the main touchscreen. They are only ever so slightly off, but it shows they have two different calculations running (and it's mildly annoying).

markwj
01-15-2013, 08:10 PM
Right.

Another interesting artifact is that I have been running one of the "trips" from the day I got the car. It shows a slightly different MPG to the lifetime MPG on the main touchscreen. They are only ever so slightly off, but it shows they have two different calculations running (and it's mildly annoying).

The roadster has something similar. The Miles->Kilometer formula (and rounding) is different on the VFD vs dashboard LCD.

markwj
01-15-2013, 08:12 PM
The service 0x22 is working really well. We're polling a bunch of PIDs now, and getting the data we need.

Feeling good about this now. We've already got something workable and usable (vehicle location, state of charge, charging status, charge interrupted alerts, temperatures, etc). The hunt is now on for the other information that would be useful and fun to have.

tboult
01-15-2013, 09:04 PM
Feeling good about this now. We've already got something workable and usable (vehicle location, state of charge, charging status, charge interrupted alerts, temperatures, etc). The hunt is now on for the other information that would be useful and fun to have.

Don't know who did the dashdaq dump you had.. but having dashdaq logs + a busdump or dashdaq logs + torque dump would help a lot in mapping.

Most interesting to me are the EV motor info: motor RPMS which I think I identified) and current and voltage for them. But I'll need to test it a good bit more when I return and figure out which is which.

Burro
01-16-2013, 07:38 PM
The only way I saw to scan for extended PIDs is to

7E0 03 22 00 01 00 00 00 00
(wait for reply)
7E0 03 22 00 02 00 00 00 00
(wait for reply)
7E0 03 22 00 03 00 00 00 00
(wait for reply)
repeat ad nauseum

65,536 times for each controller. The reply code 0x62 (0x22+0x40) is GOOD, and 0x7F is error. We're finding it takes around 7ms for each reply, so perhaps 7 minutes per controller? That is about 20 times as bad as the PID 0x00, 0x20, 0x40, etc approach, but still workable I guess.


Mark,

That is the only way to do it. The J1979 PID identifiers(0x00, 0x20, etc...) were created so an aftermarket scan tool could quickly identify the generic parameters supported. The extended PID's don't have anything like that because it is assumed those will be accessed by a manufacturer's tool that already knows that information.

It is a huge waste of resources to do it like that but it does narrow down the PIDs you have to worry about. Looking at the service manual, I see each module only supports a limited number of PIDs through the dealer scan tool, maybe around 50-75 best case. You will probably see many more than that supported. I don't know how you will ever determine what those definitions are but most of the good ones should be available with the dealer tool.

Ideally, if any one is on really good terms with their dealer, a CAN-bus recording while requesting each available PID with the dealer tool will net you the best results in the fastest time. Just record the CAN traffic, the pid requested and the value from the scan tool and you will be much further ahead.

rlempicki
01-30-2013, 12:52 PM
I PM'ed @tboult yesterday and he suggested I post to all.

"Hi @tboult,

I've been following you posts on the GM-Volt forum and Android Torque forum for several months now and have learned a great deal regarding the Volt and especially data logging on the Volt. I, like you, am trying to obtain as many PIDs as possible for the Volt to use on the Torque app. I greatly appreciate the table you made, especially the HV volts and amps to use for Inst Power calculations. I hope to be able to contribute to your table over the next few weeks or so.

In regard to Inst Power, I believe it needs to be multiplied by 3 to get the correct answer. Actually, it is the HV Amps that need to be multiple by 3. What I did to get this factor was to plot energy use based on %SOC (assuming that each 1% SOC corresponded to about 0.1615 KWH [10.5 KWH/65%]) vs. energy use based on the integration of Inst Power over time i.e. I make a cumulative reading of watt-hrs by taking the average Inst. Power between two consecutive polling frames and multiply by the time between these two polling frames [usually around 0.1 seconds in my case] yielding watt-seconds and then divide by 3600 to get watt-hrs. The correlation to SOC is r=0.9998, except the Inst Power cumulative data is ~3-fold less than the SOC data (slope=0.32). Of course the SOC data is vary granular while Inst. Power is smooth and passes nicely through the center of granular SOC values. The data above is from a 25 mile drive including hilly country roads and interstate driving.

The factor of 3 scaling is also confirmed from the reading of "KWH Used" on the Volt's display of 5.6 KWH and the final cumulative "KWH" based on the Inst Power PID of 1.87 KWH.

Again, thank you for all your hard work and posting what you learn. I'm very excited about Inst. Power since I can now express energy usage data in terms of KWH/100 miles.

I attached a jpg containing several graphs showing the data I mentioned in different ways:"

http://gm-volt.com/forum/attachment.php?attachmentid=10961&d=1359481985

rlempicki
01-30-2013, 12:56 PM
I PM'ed @tboult yesterday and he suggested I post to all.

@tboult's reply to my PM:

"Reviewing my notes.. I see I was not sure if it whould be /64 or /20..
I already corrected the amps for charging to be /20 as I calibrated that over long period.
you might test your data with 64/20 rather than "3" and see if its a slightly better fit.
which sounds right (you say the slope is 3.2 not 3.33)"

rlempicki
01-30-2013, 01:15 PM
@tboult reply to my PM:

"Reviewing my notes.. I see I was not sure if it whould be /64 or /20..
I already corrected the amps for charging to be /20 as I calibrated that over long period.
you might test your data with 64/20 rather than "3" and see if its a slightly better fit.
which sounds right (you say the slope is 3.2 not 3.33)"

Sorry - I don't mean to be having a conversation with myself. Seems to be happening more often since I recently turned 50.

@tboult - You are correct that 20 is the best fit.

Note that this Inst. Power calculation has resulted in power values as high as 125 KW during full throttle which others have commented on other posts is inaccurate since it should not by higher than the main drive motor of 111 KW. However the 111 KW value is only based on voltage and current measurements at Motor B while the 125 KW value is based on measurements from the HV battery. I would suspect that the additional 14 KW is being used at Motor A, but I am not sure. Another interesting note is that I never see the power usage go above 111 KW at full throttle going from a standing start to 70 mph, but do see it going to 125 KW at full throttle from a rolling start, say going from 35 MPH to 70 MPH. Maybe GM adds a few extra HP to Motor A during passing???? Just a guess.

rlempicki
01-30-2013, 02:49 PM
@tbout - just noticed using the Torque App to calc. Inst Power can give you different data than if you calc. Inst Power base on amps*volts from the same polling frame in the log file. I could be wrong, but it appears that the Torque app sometimes may be grabbing volts and amps from two different frames and thus being inaccurate. This seems to be Torque specific since I have done other analogous types of calc. (i.e. combining two different pids) using ScanXL with not problems.

tboult
01-30-2013, 03:22 PM
Sorry - I don't mean to be having a conversation with myself. Seems to be happening more often since I recently turned 50.

@tboult - You are correct that 20 is the best fit.

Note that this Inst. Power calculation has resulted in power values as high as 125 KW during full throttle which others have commented on other posts is inaccurate since it should not by higher than the main drive motor of 111 KW. However the 111 KW value is only based on voltage and current measurements at Motor B while the 125 KW value is based on measurements from the HV battery. I would suspect that the additional 14 KW is being used at Motor A, but I am not sure. Another interesting note is that I never see the power usage go above 111 KW at full throttle going from a standing start to 70 mph, but do see it going to 125 KW at full throttle from a rolling start, say going from 35 MPH to 70 MPH. Maybe GM adds a few extra HP to Motor A during passing???? Just a guess.


Thanks Rlempicki for the insights and help. I just did a calibration run using your idea and with /20 I still did not get it to match the SOC (maybe I did something wrong in the timing I used in the integration, will check again later).

I too saw the 125kWh when I floored it.. but although I suspected some of it was heating (23F here).. and in high agressive acceleration the second motor should be off. My OBD was running many fields (about 50 so its 2-3 second between samples) so I don't think i sampled the motor outputs at the same time -- as its max was only 91kW.

Yes torque is collecting fields and then reports them, but its instantkw should always be from the same time for volt and amp, just not from the same times that the field called volt andth efield for amp that is logged is sampled (it resamples rather than reuses the data).

rlempicki
01-30-2013, 03:52 PM
Yes torque is collecting fields and then reports them, but its instantkw should always be from the same time for volt and amp, just not from the same times that the field called volt andth efield for amp that is logged is sampled (it resamples rather than reuses the data).

OK, I see - since my update times are about 1 second, the values of any 2 or more PIDs I collect can be offset by as much as 1 sec. Thanks.

rlempicki
01-31-2013, 03:05 PM
I too saw the 125kWh when I floored it.. but although I suspected some of it was heating (23F here).. and in high agressive acceleration the second motor should be off. My OBD was running many fields (about 50 so its 2-3 second between samples) so I don't think i sampled the motor outputs at the same time -- as its max was only 91kW.

I did a test run yesterday - temps in mid-50s, all accessories off and I still saw 125 kW under full throttle. I then did some internet browsing and found a number of resources indicating EV motors are in the 85-90% efficiency range (couldn't find any numbers specific to the Volt). Thus the value of 125kW at the battery might be what is pulled from the battery to get 111 kW at the motor shaft which equals an efficiency of 88.8% and falls within the range I found on the internet. Of course I am just speculating at this time but this makes since the power usage based on Inst Power PID calculations match up extremely well to SOC-based power usage and with the expected EV motor efficiency.

BenTuras
02-01-2013, 07:12 AM
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

rlempicki
02-01-2013, 09:53 AM
Hi,

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

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'.

Yeah, I have the Samsung Galaxy TAB with Torque Pro also - I really enjoy this combination.

I also found "-" for some PIDs in the original csv file, but found the updated files corrected many of these. However I do things differently - I just use the information from the file to manually enter only those PIDs I'm interested. If it returns "-" for a given PID then I remove it.

The main reason I only monitor specific PIDs is that the PID update rate dramatically slows down with too many PIDs in Torque Pro. Unfortunately I can't get my updates any faster than 1 per second even with a single PID selected. I know my Bluetooth setup is faster than that since if I use the same Bluetooth OBDii adapter with my laptop and ScanXL I get polling updates as fast as 10 per second with 40 PIDs being monitored. Thus I think the slow pooling rate is due to suboptimal OBDii AT communication commands being used by Torque Pro.

Another improvement that Torque Pro could make is to have an additional column for each PID in the log file that records the exact polling time that the information was obtained for each value for each the PID. Currently only one time is given for a row of PID values resulting in some of the PIDs being offset by as much as the average polling time. In reality, each value from each PID is collected at a different time since OBDii polling is a sequential process, not a parallel process. This is the method used by ScanXL. Unfortunately this double the size of log file.

John_Hatchett
02-01-2013, 10:04 AM
time to add some versioning to the csv, can I suggest a simple date stamp suffix.

ie. GMVolt-130201.csv

tboult
02-01-2013, 10:18 AM
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

Thanks.. I move on to a new file
http://vast.uccs.edu/~tboult/VOLT/VPIDs-labeled.csv
(The DD an others came from my naming them for my experiment level (so I could track changes in formulas and stuff over time), But now I'm just updating the overall file with my most recent labeled file, though since I posted the DD maybe I'll also keep updating that one).

Note there have been corrections since the old DD so you should definitely update.

The motor labels were backwards and the units were wrong, but I think I've gotten overall, MGA and MGB volts, Amps and Watts down, will go looking for motor RPMs today.. Logs when you ICE running might be helpful (I hate running the ICE just for testing)


Its been a while since I've done a full run with all fields, as the smaller the number of fields the faster it can cycle (which is more useful for figuring out units).

A "-" for an answer generally means that it did not answer (i.e. I have an invalid PID), or that the conversion formula failed, i.e. if it returns only 1 byte and you do A*256+B.. then since the data does not have a field for B, it will fail. (Though sometimes it treats the missing B as a zero.. I've not figure out why it is sometimes - and other times 0)

While some manufactures, like toyota, use much longer answers, it seems GMs approach is more PIDs with smaller answers. Most of the data fying around in the car is not actually using the PIDs, its using raw canbus transfers without polling. Other tools like dashdaw seem to use mode 2c to collect PIDs into larger groups but still I found no fields wither mode 22 PIDs have used C or D, though youare welcome to try a run and see what you get.. Its hard to know what could be there if you don't exercise them.

rlempicki
02-01-2013, 01:21 PM
The motor labels were backwards and the units were wrong, but I think I've gotten overall, MGA and MGB volts, Amps and Watts down, will go looking for motor RPMs today.. Logs when you ICE running might be helpful (I hate running the ICE just for testing)

As always, thank you for the crap-load of hard working you are doing.

I don't have access to all my data and car (I'm out of town for a few days) but think PID 0c is rpm and PID 04 and/or 43 are Engine Load.

tboult
02-01-2013, 01:32 PM
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.


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.


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?

dpeilow
02-01-2013, 04:03 PM
Any news of further progress on remote commanding the climate control / pre-heat?

(I'm moving office location in 2 weeks and now won't be able to reach with the key fob in the evening either :( )

rlempicki
02-01-2013, 04:11 PM
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?

I have these values from doing some ScanXL runs but will not be able to get them to you until next week. I have a nice dump of values from 100's of PIDs (but do not have the PID command code). I will PM the file to you next week. You should be able to use this data, which has PID textual description and units, to match up with your data to help with equation/factor calculations. The file includes data from turning the AC on and off, EV-only mode, CS-mode, MM-mode while driving (I think), MM-mode while stopped for 10 minutes and I believe also while charging using at a 120V.

rlempicki
02-01-2013, 04:16 PM
Any news of further progress on remote commanding the climate control / pre-heat?

(I'm moving office location in 2 weeks and now won't be able to reach with the key fob in the evening either :( )

You should be able to do it from the internet (MyVolt.com) or iphone app. Or did you mean something else?

dpeilow
02-01-2013, 05:17 PM
You should be able to do it from the internet (MyVolt.com) or iphone app. Or did you mean something else?

European owners don't get that luxury I'm afraid. That's why we'd be eternally grateful if you guys on the other side of the Pond can scan the bus while activating these features remotely to see how it can be replicated in OVMS.

BenTuras
02-03-2013, 08:59 AM
Thanks.. I move on to a new file
http://vast.uccs.edu/~tboult/VOLT/VPIDs-labeled.csv
Note there have been corrections since the old DD so you should definitely update.

The motor labels were backwards and the units were wrong, but I think I've gotten overall, MGA and MGB volts, Amps and Watts down, will go looking for motor RPMs today.. Logs when you ICE running might be helpful (I hate running the ICE just for testing)

Thanks, I picked up the update and had a trip of an hour, logging every single value with it. Then placed it in Excel and made a minimum value and maximum value column, leading to these results:


GPS Time Sat Feb 02 16:13:25 CET Sat Feb 02 17:03:34 CET 2013
Device Time 11:02.2 01:35.5
Longitude 4.21806545 4.590393599
Latitude 51.5353171 51.95731531
GPS Speed (Meters/second) 0 42.11429
Horizontal Dilution of Precision 4 48
Altitude 25.14657348 69.79279818
Bearing 0 359.8136
G(x) -5.5162406 11.10909557
G(y) -1.72382522 13.82890892
G(z) -5.7843914 9.69172859
G(calibrated) -0.37902629 1.02032697
!! HV Discharge Amps(A) -140.0500031 347.3999939
!! HV Volts(A) 334.71875 392.53125
!! Inst. W (W) -47949.61719 129254.5156
!! MGA Amps(A) -101.699997 188.0500031
!! MGA Volt(V) 2 387
!! MGA W(W) -36815.39844 64313.10156
!! MGB Amps(A) -139.1000061 342.5499878
!! MGB Volt(V) 2 387
!! MGB W(W) -50771.5 109743.0469
!! SOC(RAW)(%) 26.27450943 83.92156982
!! SOC(Usable(%) 0.073454 0.9603318
!Charger HV Volt (V) 0 0
!Charger HV Watt(W) 0 0
!Charging HV? 41 B7(V) 0 0
!Control Module Voltage(V) 0 14.91600037
!Engine Coolant Temp(°C) 10 89
!Engine Oil Temp(°C) 15 88
!Engine RPM(rpm) 0 3861.75
!EV Miles this Cycle(V) 0 13.07022953
!Fuel Level(%) 42.74509811 89.80392456
!HV Battery Temp (°C) 13 25
!Hybrid Pack Remaining (SOC)(%) 26.27450943 83.92156982
!Last Charge AC Wh(Wh) 0 0
!OATemp(°C) -40 7
!Obboard Charger Voltage(V) 0 0
!OnBoard Charger Current Amps(A) 0 0
!Power Electronics Cooling Temp(°C) 8 13
!Speed kph(kph) 0 255maybe driving reverse with 1km/u -> -1 -> 255 ?
!Speed mph(km/h) 0 0
!Tran Temp(°C) 15 15
*H2 Volt from VICM?(V) 370 370.5
*M AC High Side Preassure(psi) 5.07632065 5.65647173
*M Commanded Throttle Pos(%) 12.54901981 12.54901981
*M Engine Torque(Nm) 0 0
*M Engine Torque m1(Nm) 0 0
*M Fuel System Status(B1) 0 0
*M Intake Air Temp IAT(°C) 7.5 7.5
*M Intake Manifold Press(psi) 14.64881134 14.64881134
*M Long Term Fuel Trip Bank 2(%) 50.19607925 50.19607925
*M Short Term Fuel Trip Bank1(%) 50.19607925 50.19607925
*M Short Term Fuel Trip Bank2(%) 50.19607925 50.19607925
*M Spark Advance(Deg) 0 0
*M Torqe Delivered(V) -136 -136
*Outside Temp Filtered(°C) 5.75 6.75
*Outside Temp Raw(°C) 5.75 6.75
*Transmission ISS 19 41(RPM) 0 0
0-100kph Time(s) 0 0
0-200kph Time(s) 0 0
0-60mph Time(s) 0 0
1/4 mile time(s) 82.93099976 82.93099976
1/8 mile time(s) 11.41499996 82.93099976
100-0kph Time(s) 0 338.3110046
40-60mph Time(s) 0 41.66199875
60-0mph Time(s) 0 336.3129883
60-120mph Time(s) 0 0
60-80mph Time(s) 0 188.7480011
80-100mph Time(s) 0 0
? unknown Volt?(V) 0 0
??H1 Gear Ratio 19a1(V) 0 0
??H1 Output Shaft Speed 1942(RPM) 0 0
??H2 Amp from VICM(A) -4.30000019 -2.3499999
??H2 Charging 43 74(V) 0 0
??H2 Charging LV? 43 7E(V) 0 0
??HV 43 2E(V) 0 0
?H1 1C 2F(V) 0 0
?H1 1C 30(V) 0 0
?H1 1C 36(V) 0 0
?H1 1C 37(V) 0 0
?H1 24 11(V) 0 0
?H1 24 16(V) 0 0
?H1 24 17(V) 0 0
?H1 24 2B(V) 0 0
?H1 24 2C(V) 0 0
?H1 28 78(V) 0 0
?H1 28 81(V) 0 0
?H1 28 82(V) 0 0
?H1 28 AF(V) 9999 9999
?H1 28 B0(V) 9999 9999
?H1 28 BC(V) 0 0
?H1 28 BD(V) 1 1
?H1 28 E8(V) 0 0
?H1 40 D0(V) 0 0
?H2 13 AF(V) 0 0
?H2 40 E7(V) 0 0
?H2 41 B2(V) 400 566
?H2 41 B4(V) 2500 2500
?H2 41 B6(V) 0 0
?H2 43 2B(V) 6691 6702
?H2 43 58(V) 0 0
?H2 43 5A(V) 0 0
?H2 43 5D(V) 0 0
?H2 43 6D(V) 0 0
?H2 43 6E(V) 0 0
?H2 43 6F(V) 0 0
?H2 43 7F(V) 0 0
?H2 43 B0(V) 0 0
?H2 43 BB(V) 0 0
?H2 82 B2(V) 0 0
?H2 82 B5(V) 0 1560
?H2 82 B7(V) 0 0
?H2 83 34(V) 0 0
?H2 83 5A(V) 0 0
?H2 83 5C(V) 0 0
?H2 90 5C(V) 0 0
?M ECM 20 3F B1(B1) 0 0
?M ECM 20 7E B1(B1) 0 0
?M ECM 28 10 B1(B1) 0 0
?TCM 19 9E 1byte(V) 0 0
?TCM 19 D4 1byte(V) 0 0
?TCM 1A 18 1byte(V) 0 0
?TCM 1A 1F 1byte(V) 0 0
?TCM 28 51 1byte(V) 0 0
?TCM 28 52 1byte(V) 0 0
?TCM 28 53 1byte(V) 0 0
?TCM 28 54 1byte(V) 0 0
Absolute Throttle Position B(%) 14.11764717 84.31372833
Acceleration Sensor(Total)(g) -0.331449 0.31037077
Acceleration Sensor(X axis)(g) -0.69897997 1.01137328
Acceleration Sensor(Y axis)(g) -0.17572121 1.29643214
Acceleration Sensor(Z axis)(g) -0.74821603 1.18471742
Accelerator PedalPosition D(%) 19.6078434 85.49019623
Accelerator PedalPosition E(%) 9.8039217 42.74509811
Accelerator PedalPosition F(%) 0 0
Air Fuel Ratio(Commanded)(:1) 0 14.69999981
Air Fuel Ratio(Measured)(:1) 0 0
Ambient air temp(°C) -40 7
Average trip speed(whilst moving only)(km/h) 1 110.2166367
Average trip speed(whilst stopped or moving) 0 98.64260864
Barometer (on Android device)(mb) 0 0
Barometric pressure (from vehicle)(psi) 14.35873604 14.64881134
Catalyst Temperature (Bank 1 Sensor 1)(°C) 14 941
Catalyst Temperature (Bank 1 Sensor 2)(°C) 0 0
Catalyst Temperature (Bank 2 Sensor 1)(°C) 0 0
Catalyst Temperature (Bank 2 Sensor 2)(°C) 0 0
Commanded Equivalence Ratio(lambda) 0 1
Cost per mile/km (Instant)(£/km) 0 1032.609253
Cost per mile/km (Trip)(£/km) 0.00047368 0.15649307
CO₂ in g/km (Average)(g/km) 0 120.1166534
CO₂ in g/km (Instantaneous)(g/km) 0 339.3528748
Distance to empty (Estimated)(km) 243.9385834 356.6613159
Distance travelled since codes cleared(km) 1037 1109
Distance travelled with MIL/CEL lit(km) 0 0
EGR Commanded(%) 0 0
EGR Error(%) 0 0
Engine Coolant Temperature(°C) 10 88
Engine kW (At the wheels)(kW) 10.70364761 100.4345169
Engine Load(%) 0 100
Engine Load(Absolute)(%) 0 97.64705658
Engine Oil Temperature(°C) 0 0
Engine RPM(rpm) 0 3877.5
Ethanol Fuel %(%) 0 0
Evap System Vapour Pressure(Pa) -3273 1011.75
Exhaust Gas Temperature 1(°C) 0 0
Exhaust Gas Temperature 2(°C) 0 0
Fuel cost (trip)(cost) 0.00004231 4.94084835
Fuel flow rate/hour(l/hr) 0 19.04437065
Fuel flow rate/minute(cc/min) 0 317.406189
Fuel Level (From Engine ECU)(%) 42.74509811 90.19607544
Fuel pressure(psi) 42.20598221 83.54174042
Fuel Rail Pressure(psi) 0 0
Fuel Rail Pressure (relative to manifold vac 0 0
Fuel Remaining (Calculated from vehicle prof 56.86274338 83.13725281
Fuel Trim Bank 1 Long Term(%) -3.125 0.78125
Fuel trim bank 1 sensor 1(%) -100 8.59375
Fuel trim bank 1 sensor 2(%) 0 0
Fuel trim bank 1 sensor 3(%) 0 0
Fuel trim bank 1 sensor 4(%) 0 0
Fuel Trim Bank 1 Short Term(%) -100 7.03125
Fuel Trim Bank 2 Long Term(%) 0 0
Fuel trim bank 2 sensor 1(%) 0 0
Fuel trim bank 2 sensor 2(%) 0 0
Fuel trim bank 2 sensor 3(%) 0 0
Fuel trim bank 2 sensor 4(%) 0 0
Fuel Trim Bank 2 Short Term(%) 0 0
Fuel used (trip)(l) 0.00002489 2.90638137
GPS Accuracy(m) 4 48
GPS Altitude(m) 25.14657402 69.7928009
GPS Bearing(°) 0 359.8135986
GPS Latitude(°) 51.53531647 51.95731354
GPS Longitude(°) 4.21806526 4.59039354
GPS Satellites 0 18
GPS vs OBD Speed difference(km/h) 0 255
Horsepower (At the wheels)(hp) 14.35382843 134.684906
Intake Air Temperature(°C) 7 17
Intake Manifold Pressure(psi) 3.62594342 14.64881134
Kilometers Per Litre(Instant)(kpl) 0 90.26999664
Kilometers Per Litre(Long Term Average)(kpl) 12.25613213 14.71916294
Litres Per 100 Kilometer(Instant)(l/100km) 0 12.82998562
Litres Per 100 Kilometer(Long Term Average)( 6.7938056 8.15901184
Mass Air Flow Rate(g/s) 0 52.11000061
Miles Per Gallon(Instant)(mpg) 0 255
Miles Per Gallon(Long Term Average)(mpg) 34.62184143 34.62702179
O2 Sensor1 Equivalence Ratio 0 0
O2 Sensor1 Equivalence Ratio(alternate) 0 0
O2 Sensor1 wide-range Voltage 0 0
O2 Sensor2 Equivalence Ratio 0 0
O2 Sensor2 wide-range Voltage 0 0
O2 Sensor3 Equivalence Ratio 0 0
O2 Sensor3 wide-range Voltage 0 0
O2 Sensor4 Equivalence Ratio 0 0
O2 Sensor4 wide-range Voltage 0 0
O2 Sensor5 Equivalence Ratio 0 0
O2 Sensor5 wide-range Voltage 0 0
O2 Sensor6 Equivalence Ratio 0 0
O2 Sensor6 wide-range Voltage 0 0
O2 Sensor7 Equivalence Ratio 0 0
O2 Sensor7 wide-range Voltage 0 0
O2 Sensor8 Equivalence Ratio 0 0
O2 Sensor8 wide-range Voltage 0 0
O2 Volts Bank 1 sensor 1(V) 0.005 1.27499998
O2 Volts Bank 1 sensor 2(V) 0.065 1.27499998
O2 Volts Bank 1 sensor 3(V) 0 0
O2 Volts Bank 1 sensor 4(V) 0 0
O2 Volts Bank 2 sensor 1(V) 0 0
O2 Volts Bank 2 sensor 2(V) 0 0
O2 Volts Bank 2 sensor 3(V) 0 0
O2 Volts Bank 2 sensor 4(V) 0 0
Relative Accelerator Pedal Position(%) 0 0
Relative Throttle Position(%) 0.39215687 70.58823395
Run time since engine start(s) 0 1778
Speed (GPS)(km/h) 0 151.6114349
Speed (OBD)(km/h) 0 255
Throttle Position(Manifold)(%) 16.86274529 83.92156982
Timing Advance(°) -2.5 42.5
Torque(Nm) 135.6808014 135.6808014
Transmission Temperature(Method 1)(°C) 0 0
Transmission Temperature(Method 2)(°C) 0 0
Trip average KPL(kpl) 12.55875969 13.91036701
Trip average Litres/100 KM(l/100km) 7.18873358 7.96240377
Trip average MPG(mpg) 35.47672272 39.29482269
Trip Distance(km) 0 70.8830719
Trip distance (stored in vehicle profile)(km 4842.499512 4913.382324
Trip Time(Since journey start)(s) 0 2926
Trip time(whilst moving)(s) 0 2678.00708
Trip time(whilst stationary)(s) 0 248.9909973
Turbo Boost & Vacuum Gauge(psi) -10.87783051 0.14503765
Voltage (Control Module)(V) 0 14.91600037
Voltage (OBD Adapter)(V) 12.5 15.19999981
Volumetric Efficiency (Calculated)(%) 61 126

tboult
02-03-2013, 11:22 AM
thanks BenTuras .. I'll look at this when I return from my trip.

The usable SOC has been fixed (needed a *100)

the speed in kph is interesting.. since its not showing any speed in mph..
Might change that formula to
(Signed(A)*256+b) to see what it reports (that will handle signed 2 byte data
or maybe
(Signed(A)) if its signed one byte.

I've wondered if the units might change when changes the units in the car or between volt/ampera


Is there some trick to "add all" or do you do it one PID at a time.

BenTuras
02-03-2013, 02:14 PM
thanks BenTuras ..

My pleasure :-)


the speed in kph is interesting.. since its not showing any speed in mph..
Might change that formula to
(Signed(A)*256+b) to see what it reports (that will handle signed 2 byte data
or maybe
(Signed(A)) if its signed one byte.

Yeah, I was thinking that too, at the end of my trip I saw the speed of 255kph and the last thing that I do is reverse into my parking spot.
Signed one byte will not be enough tho, -127kph to +128kph is not enough ;)


Is there some trick to "add all" or do you do it one PID at a time.

Alas not, I have to add them one by one to be logged, with the risk of hitting clear list, which doesn't have a confirm, so one slight slip of positioning my finger and I can start all over again.

Thanks for all the effort that you put into this !

RScott
02-04-2013, 02:43 PM
Thanks, I picked up the update and had a trip of an hour, logging every single value with it. Then placed it in Excel and made a minimum value and maximum value column, leading to these results:

Thank you for sharing that information, it is very, very useful.

I'm going to use that to help verify some of the OBD2 information that I have been passively collecting ("Monitor All"). The min/max ranges should also help identify some of the many fields that I haven't begun to figure out yet.

BenTuras
02-04-2013, 03:17 PM
Thank you for sharing that information, it is very, very useful.

I'm going to use that to help verify some of the OBD2 information that I have been passively collecting ("Monitor All"). The min/max ranges should also help identify some of the many fields that I haven't begun to figure out yet.
My pleasure. If you like me to test a range of PIDs, just create a csv file for me and I will load it in my Galaxy and activate all PIDs to log during my daily 2x90km commute.

AndY1
02-05-2013, 03:10 AM
http://www.youtube.com/watch?v=B7v79M861yk

MIN FUEL
02-05-2013, 10:45 AM
My pleasure. If you like me to test a range of PIDs, just create a csv file for me and I will load it in my Galaxy and activate all PIDs to log during my daily 2x90km commute.

Sorry for the newby question, but how do you download the csv file to torque? I am using Torque, but have only been able to set up a couple of PID's. It looks like there are quite a few more. It seems it would be easier to load the file than input each one. Any help would be appreciated.

tboult
02-05-2013, 12:43 PM
Sorry for the newby question, but how do you download the csv file to torque? I am using Torque, but have only been able to set up a couple of PID's. It looks like there are quite a few more. It seems it would be easier to load the file than input each one. Any help would be appreciated.

You copy the csv file to the .torque/extendedpids directory, e.g.
I mount the phone on my mac and say
cp ~/VOLT/VPIDs-labeled.csv /Volumes/NO\ NAME/.torque/extendedpids/


http://torque-bhp.com/wiki/PIDs

pjwood
02-05-2013, 02:54 PM
European owners don't get that luxury I'm afraid. That's why we'd be eternally grateful if you guys on the other side of the Pond can scan the bus while activating these features remotely to see how it can be replicated in OVMS.

Please, indicate the hardware required to monitor such commands. Maybe even a link ('er two). I've had OBDII / CAN bus software, but for VW, not GM. If this amounts to a wire, some software and just about any laptop, I may be able to help.

dpeilow
02-05-2013, 06:43 PM
^ well I don't have it but I think that is what this whole thread is about.

rlempicki
02-06-2013, 04:29 PM
@AndY1

Nice video. How do you get your data to update so fast? I've tried everything I could and can only update each PID about once per second, even if only monitoring 10 PIDs. I'm using a Samsung Galaxy Tab 2 10.1 inch and a the OBDLink MX Bluetooth adapter which is quite fast if I use my laptop and ScanXL software.

Do you or any one else have any suggestions to increase PID update speed on Torque? I played with all the settings but maybe I'm doing something wrong.

Thanks.

PS You may already know this, but you can view a Watt-Hours/km gauge by dividing your "Inst W" by your "Speed".

rlempicki
02-06-2013, 04:59 PM
@tboult

I've logged a number of trips including hard accel, high speeds and 240 charging data in order to work out the factors that best predict changes in %SOC and the reported "kWh used" by using "Inst Watts" measured from the battery and "Inst Watts" measured from Motor B and Motor A. To do this, I simultaneously solved several equations using the following constraints: 1% change in SOC must correspond to 161.5 watts +/- 2 watts; max. power generated by Motor B must be 111 kW +/- 1 kW; after subtracting idle wattage - kW flowing into the battery during regenerative braking must be =< "Motor A + Motor B" regen. kW (you can't put more energy into the battery than is being generated); and the predicted "kWh used" must be +/-100 watts from "kWh used" reported on the center console display.

In order to get all of this to all work out, the current equation for Inst Watts at the battery needs to be reduced by factor of 0.96 and the Inst Watts from the the two motors need to be increased by a factor 1.08.

AndY1
02-07-2013, 01:14 AM
@AndY1

Nice video. How do you get your data to update so fast? I've tried everything I could and can only update each PID about once per second, even if only monitoring 10 PIDs. I'm using a Samsung Galaxy Tab 2 10.1 inch and a the OBDLink MX Bluetooth adapter which is quite fast if I use my laptop and ScanXL software.

Do you or any one else have any suggestions to increase PID update speed on Torque? I played with all the settings but maybe I'm doing something wrong.

Thanks.

PS You may already know this, but you can view a Watt-Hours/km gauge by dividing your "Inst W" by your "Speed".

I don't know, I left it all by default and entered the PIDs I wanted manually.

Thank you for the suggestion! I will do that! Am I correct in assuming I can do that the same way the Power PID is done, by multiplying the Amps * Voltage of the battery?

P.S.: Is the rounding function in the Torque round()? I ask this if I wanted to divide the Watts by 1000 to get kWatts with only integer values.

P.S.2: I'm using Samsung Galaxy Note and some cheap blue colored OBD2 adapter from eBay.

Edit: Is this the right formula for the Wh/km?
[222429]*[222414]/[22000D]

The first one is Amps, the second one is Watts, the third one is Speed in km/h. I left the ModeAndPID empty, the same as for Inst. W, but what do I enter for OBD Header? Inst W. has 7E1 OBD Header. Do I enter the same OBD Header or do I leave it empty?

rlempicki
02-07-2013, 05:44 AM
I don't know, I left it all by default and entered the PIDs I wanted manually.

Thank you for the suggestion! I will do that! Am I correct in assuming I can do that the same way the Power PID is done, by multiplying the Amps * Voltage of the battery?

P.S.: Is the rounding function in the Torque round()? I ask this if I wanted to divide the Watts by 1000 to get kWatts with only integer values.

P.S.2: I'm using Samsung Galaxy Note and some cheap blue colored OBD2 adapter from eBay.

Edit: Is this the right formula for the Wh/km?
[222429]*[222414]/[22000D]

The first one is Amps, the second one is Watts, the third one is Speed in km/h. I left the ModeAndPID empty, the same as for Inst. W, but what do I enter for OBD Header? Inst W. has 7E1 OBD Header. Do I enter the same OBD Header or do I leave it empty?

Yes, that is the correct equation, but I also add 0.25 to the speed in order not to divide by zero when not moving. Not sure about the rounding function - others might know.

tboult
02-07-2013, 08:39 AM
@tboult

I've logged a number of trips including hard accel, high speeds and 240 charging data in order to work out the factors that best predict changes in %SOC and the reported "kWh used" by using "Inst Watts" measured from the battery and "Inst Watts" measured from Motor B and Motor A. To do this, I simultaneously solved several equations using the following constraints: 1% change in SOC must correspond to 161.5 watts +/- 2 watts; max. power generated by Motor B must be 111 kW +/- 1 kW; after subtracting idle wattage - kW flowing into the battery during regenerative braking must be =< "Motor A + Motor B" regen. kW (you can't put more energy into the battery than is being generated); and the predicted "kWh used" must be +/-100 watts from "kWh used" reported on the center console display.

In order to get all of this to all work out, the current equation for Inst Watts at the battery needs to be reduced by factor of 0.96 and the Inst Watts from the the two motors need to be increased by a factor 1.08.


Nice analysis job, and while I've gone ahead and updated my PID sheet, I did it differently (I updated amps which indirectly updates watts but it then consistent with the definitions.).

My bigger concern is that the assumptions undertlying this may be off. I'm thinking amps and volts are raw sensor data and it seem unlikely the conversion fomula is some odd factor.. A sensor/20 as actual amps makes more sense to me than
sensor/18.5185 . So maybe the issue is the SOC is not clean (remember you are integrating and that introduces errors especially), meaningful andor the predicted kWh used. In both cases there could be accumulation of sensor error (with things like voltage float while the system is running).

tboult
02-07-2013, 08:41 AM
I don't know, I left it all by default and entered the PIDs I wanted manually.

Thank you for the suggestion! I will do that! Am I correct in assuming I can do that the same way the Power PID is done, by multiplying the Amps * Voltage of the battery?

P.S.: Is the rounding function in the Torque round()? I ask this if I wanted to divide the Watts by 1000 to get kWatts with only integer values.

P.S.2: I'm using Samsung Galaxy Note and some cheap blue colored OBD2 adapter from eBay.

Edit: Is this the right formula for the Wh/km?
[222429]*[222414]/[22000D]

The first one is Amps, the second one is Watts, the third one is Speed in km/h. I left the ModeAndPID empty, the same as for Inst. W, but what do I enter for OBD Header? Inst W. has 7E1 OBD Header. Do I enter the same OBD Header or do I leave it empty?


yeah leave the header empty.. I should have left it empty in InstW as well.

Don't know about the round.. never tried it.

As rlempicki said, might want to avoid /0

rlempicki
02-07-2013, 09:48 AM
Nice analysis job, and while I've gone ahead and updated my PID sheet, I did it differently (I updated amps which indirectly updates watts but it then consistent with the definitions.).

My bigger concern is that the assumptions undertlying this may be off. I'm thinking amps and volts are raw sensor data and it seem unlikely the conversion fomula is some odd factor.. A sensor/20 as actual amps makes more sense to me than
sensor/18.5185 . So maybe the issue is the SOC is not clean (remember you are integrating and that introduces errors especially), meaningful andor the predicted kWh used. In both cases there could be accumulation of sensor error (with things like voltage float while the system is running).

Yes, I agree completely and have the same concerns. Thus the factors I mentioned are most likely correcting for random/interference noise due to sampling errors as a result of logging updates of only 1 per second, logging of individuals PIDs used in downstream calc. in which the PIDs may possibly be offset by as much as 1 second, the error you mentioned that is due to small errors that accumulate to larger errors over time (i.e. integration drift), and as you also mentioned voltage float while running - I've seen this on the Volt where I have run it a little hard, glanced at my SOC gauge in Torque, turned-off the car, come back 5 minutes latter and see that the the SOC jumped up 2% (as if I was charging). I see this all the time on my voltage gauge while using my trolling motor for fishing. If I want a true measure of my trolling motor battery SOC, I need to wait a couple minutes after turning the motor off.

AndY1
02-07-2013, 12:52 PM
yeah leave the header empty.. I should have left it empty in InstW as well.

Don't know about the round.. never tried it.

As rlempicki said, might want to avoid /0

Dividing by zero results in an character for infinite and is accurate. If you're not moving and consuming power, your consumption actually is infinite Wh/km.

AndY1
02-11-2013, 02:21 AM
Added Wh/km data:


http://www.youtube.com/watch?v=r3so4gcYPrI

brewster
02-11-2013, 04:14 AM
Added Wh/km data:


http://www.youtube.com/watch?v=r3so4gcYPrI

Hey AndY1, how hard would it be to calculate/show a Trip average efficiency and a Long term average efficiency?

Great video, really enjoy seeing each one you produce. :)

kdawg
02-11-2013, 03:32 PM
Added Wh/km data:




Does your Ampera have a kW display? If yes, how accurate is the OBDII compared to the Volt's display?

I'll have to try this w/my 2013 Volt.

kdawg
02-11-2013, 03:56 PM
tboult, can you link the updated CSV file?

How did you come up with this formula? Also, it seems to be missing part of it, since the result would not be a percentage.
!! SOC(Usable SOC-U 015B ((A*100/255)-21.5)/65.0

AndY1
02-21-2013, 02:35 AM
Does your Ampera have a kW display? If yes, how accurate is the OBDII compared to the Volt's display?

I'll have to try this w/my 2013 Volt.

No, it doesn't. It's 2012 Ampera. That's why the Inst. kW data is so usefull to me.

kdawg
02-21-2013, 08:21 AM
No, it doesn't. It's 2012 Ampera. That's why the Inst. kW data is so usefull to me.

I still haven't had time to do any testing...... soon.

tboult
02-21-2013, 08:51 PM
tboult, can you link the updated CSV file?

How did you come up with this formula? Also, it seems to be missing part of it, since the result would not be a percentage.
!! SOC(Usable SOC-U 015B ((A*100/255)-21.5)/65.0

Sorry.. been offline most of the week as I travel.

http://vast.uccs.edu/~tboult/VOLT/VPIDs-labeled.csv

Yes that was broken.. it was suppose to be A*100/255 0 21.5/65*100
(It as a fraction in the 0-1 range.. not percent in 0-100).
The 21.5 is the low battery mark (from my measurements) and 65 is the usable SOC..
I forgot how I did it before to make sure its pos and not > 100
but I don't freek if I see -5% or 105%.. (both of which I've seen on rare occasion)

brewster
02-21-2013, 10:41 PM
Sorry.. been offline most of the week as I travel.

http://vast.uccs.edu/~tboult/VOLT/VPIDs-labeled.csv

Yes that was broken.. it was suppose to be A*100/255 0 21.5/65*100
(It as a fraction in the 0-1 range.. not percent in 0-100).
The 21.5 is the low battery mark (from my measurements) and 65 is the usable SOC..
I forgot how I did it before to make sure its pos and not > 100
but I don't freek if I see -5% or 105%.. (both of which I've seen on rare occasion)

I believe there is a typo for above SOC formula ...
I think it should be ((A*100/255-21.5)/65)*100

kdawg
02-21-2013, 11:11 PM
The 21.5 is the low battery mark (from my measurements) and 65 is the usable SOC..


Ok, mine has gone as low at 19.5%

rogier
02-22-2013, 04:22 AM
Hi,

I'm doing some embedded programming in order to read data from the Volt and the DD-file data posted here are really helpful (kudos for you all). I do have some trouble understanding the "Equation" part of the these definitions. The basics are clear but one thing is not:

- What is the difference between 'B' and 'b' ?

rgrds rgr


B is upper case, b is lower case.

In torque formulas it does not matter


Note the logs I posted were with different sets of fomulas than the current spreadsheet. (its why i was changing names a lot before).


Sorry about the typos.. was late (100+ hours weeks are a drag).. at least the link is correct.

@ kdawg I've seen mine down at 15% raw SOC, but the ICE had already states.. I've seen 21.0 without ice running (but was going downhill and slow). Was your 19 in CS mode or downhill in CD?

rogier
02-26-2013, 09:45 AM
Can someone try a mode 0x2c request with response rate 0x01 and see what comes back? Perhaps:


I have done some testing with:

0x7E0 8 02 2C FE 00 46 00 00 00 (set up)

0x7E0 8 03 AA <response rate> FE 00 00 00 00

response rate:
0x01: 1 0x5E8 response
0x02: 5 0x5E8 responses, one every 1000ms
0x03: 25 0x5E8 responses, one every 200ms
0x04: "01 60" response in 0x7E8 but no 0x5E8
0x05 and up: 0x7F fault code in 0x7E8

rgrds rgr

KrazyEd
03-25-2013, 05:02 AM
I have these values from doing some ScanXL runs but will not be able to get them to you until next week. I have a nice dump of values from 100's of PIDs (but do not have the PID command code). I will PM the file to you next week. You should be able to use this data, which has PID textual description and units, to match up with your data to help with equation/factor calculations. The file includes data from turning the AC on and off, EV-only mode, CS-mode, MM-mode while driving (I think), MM-mode while stopped for 10 minutes and I believe also while charging using at a 120V.

I was looking for one of the cheap Bluetooth elm units to play around with, and, accidentally ordered a USB ElmScan5. I am using
the OBDWiz software that comes with it. Is there anything that can be done with that? I have only played with it a time or two
but, not seeing much information. I was looking into the ScanXL pro with the GM add on. Any idea how this compares to the
DashDaq at about a third the price? I don't really have time to do logs right now, Mostly looking for real time information on
the computer screen, similar to what I have on my Grand National. I have to think that a quarter century later, I should be able
to get more information. Not much invested in the ElmScan5 yet, so, better options can be considered.
Thanks for any suggestions.

physans
05-13-2013, 12:15 PM
I was looking for one of the cheap Bluetooth elm units to play around with, and, accidentally ordered a USB ElmScan5. I am using
the OBDWiz software that comes with it. Is there anything that can be done with that? I have only played with it a time or two
but, not seeing much information. I was looking into the ScanXL pro with the GM add on. Any idea how this compares to the
DashDaq at about a third the price? I don't really have time to do logs right now, Mostly looking for real time information on
the computer screen, similar to what I have on my Grand National. I have to think that a quarter century later, I should be able
to get more information. Not much invested in the ElmScan5 yet, so, better options can be considered.
Thanks for any suggestions.

Any luck KrazyEd? I have the exact same question (and am planning to order an elm327 reader to use with torque once I have the answer).

tboult
05-13-2013, 01:30 PM
I've been using very cheap Vgate ELM327 units both Bluetooth and usb.
THe bluetooth ones like
http://i01.i.aliimg.com/img/pb/066/402/415/415402066_526.JPG


From dealers like
http://www.ebay.com/itm/ELM327-VGATE-Bluetooth-OBD2-Automotive-Diagnostics-Scanner-Tool-V2-1-for-Android-/271189531537?pt=Motors_Automotive_Tools&hash=item3f2427db91&vxp=mtr

http://www.ebay.com/itm/ELM327-VGATE-Bluetooth-OBD2-Automotive-Diagnostics-Scanner-Tool-V2-1-for-Android-/271189531537?pt=Motors_Automotive_Tools&hash=item3f2427db91&vxp=mtr

I've bought 5 of these (doing some student projects with them), one of which failed to work the rest were fine. Might be good to buy US so its cheaper and faster to replace if there is a problem.

If I were to buy another I'd probably go with
http://www.ebay.com/itm/OBDII-OBD2-diagnostic-Vgate-iCar-iV350-ELM327-compatible-Bluetooth-power-switch-/181136361207?pt=LH_DefaultDomain_0&hash=item2a2c9186f7

Just so I did not have to unplug it to power it down. (The others will stayed powered even when the car is off.)


I use torque, with Volt specific PIDS.
See this thread
http://gm-volt.com/forum/showthread.php?23601-OBD-2-Hardware-Software-Recommendations-for-a-Volt
for more discussion on the PIDs. I keep my most current labeled Torque PID list at
http://vast.uccs.edu/~tboult/VOLT/DD-labeled.csv

cadillackid
05-13-2013, 04:31 PM
I have a Kiwi device I have used in my other cars with torque.. havent tried it in the volt yet.. it has a hard power switch on it to turn it off and on which is noce when I want to pair my phone with handsfree instead of The OBD port..

I still want to read the HVAC related PID's jst no one seems to care about those in the diagnostics / tuning world!

-Christopher

Rampage_Rick
05-13-2013, 11:20 PM
http://vast.uccs.edu/~tboult/VOLT/VPIDs-labeled.csv

I'm getting 403 (Forbidden) errors. Wanted to see if there were any updates to the CSV since March 9th.

tboult
05-13-2013, 11:34 PM
I'm getting 403 (Forbidden) errors. Wanted to see if there were any updates to the CSV since March 9th.

Sorry about that..

I've moved to a google doc
https://docs.google.com/spreadsheet/ccc?key=0AvK9F6VeA7dvdFUwSjBzR2FQM1BJTWZoLW43ZFdoT FE#gid=0
and started a tread on that
http://gm-volt.com/forum/showthread.php?45097-OBD2-and-Vold-PIDs-for-Adroid-Torque-in-GoogleDoc


@ cadillackid what do you mean hy HVAC pids? can you look at the list for the dashdaq and let me know what you are looking for and I'll see what I can do (in a week or so)
http://gm-volt.com/forum/showthread.php?15893-DashDaq-capability

AndY1
06-07-2013, 09:27 PM
Can anyone think of a reason, why is my Ampera, for the last two months , regularly charging the car to 86.7% (SOC PID) instead of 85.9%, which was the max value before if I charged the car without repluging it at the end?

Check out the SOC at the beginning of this video a while ago:


http://www.youtube.com/watch?v=-DxwJHPk-H0

AndY1
06-11-2013, 12:45 AM
Since this Sunday, the charge ends at 87.1% SOC.

WopOnTour
06-11-2013, 11:38 AM
See my response to your "other" thread on this topic here:
http://gm-volt.com/forum/showthread.php?39489-Only-getting-about-9.6kWh-from-a-charge-with-18C-outside-and-battery-at-24C&p=659921#post659921
The SOC readout will vary depending on how long after charging had ceased you obtained your readings, which affects SOC estimation conditions such as cell temperature.
BTW there's really no reason to simultaneously post the exact same information in two threads. Please pick a thread and stick to it.
WOT

AndY1
06-14-2013, 01:13 AM
My measurements time, after it finished charging is consistent. I have my charging set to end 15 minutes before my departure in the morning.

dpeilow
11-15-2013, 02:30 PM
Nothing new on OVMS remote pre-conditioning for a while. Has this project hit a total brick wall?

edwardang
04-17-2014, 04:58 PM
With 3-year free trial period ending for many NA Volts, I predict a sudden renew interest in OVMS support for Volts soon.

Does anyone know the status of OVMS support for Volts? Better yet, any recent experience with it?

volt2chevy
01-15-2015, 11:10 AM
Can anyone think of a reason, why is my Ampera, for the last two months , regularly charging the car to 86.7% (SOC PID) instead of 85.9%, which was the max value before if I charged the car without repluging it at the end?

Check out the SOC at the beginning of this video a while ago:


http://www.youtube.com/watch?v=-DxwJHPk-H0
i have seen 89 almost 90% soc readings in my volt when parked and pluged in

also normal? balancing periode?

Sammy
10-02-2015, 05:16 AM
Hi everyone,

I found this thread a while ago and got heaps of usefull information about requesting data via OBD2 from the Opel Ampera.

But I recently tried a simple request of "Charger AC Current" & "Charger AC Voltage". But the respond was slightly diffrent than a expected.

My Request was (got it from here):
7E4 8 06 2C FE 43 69 43 68 00
7E4 8 03 AA 04 FE 00 00 00 00

and the response:
5EC 8 FE FF E1 39 00 00 00 00

Can anyone explain to me, where the FF in the middle is coming from?
If this part wouldn't be there everything would look reasonable to me.
Charger AC Current: 0xE1 == 225 --> 225 * 0.2 = 45 A
Charger AC Voltage: 0x39 == 57 --> 57 * 2 = 114 V


Any help on the issue would be appreciated!

cheers Sammy

solder
10-15-2015, 05:47 PM
My Request was (got it from here):
7E4 8 06 2C FE 43 69 43 68 00
7E4 8 03 AA 04 FE 00 00 00 00

and the response:
5EC 8 FE FF E1 39 00 00 00 00

Can anyone explain to me, where the FF in the middle is coming from?

Sounds like the response to 4369 is 16 bits. Can you verify this by requesting the values individually with service $22? i.e.

7E4 03 22 43 69
7E4 03 22 43 68

(response will be on 7EC)

werdup
04-13-2017, 11:04 AM
Old thread, but how do you read SOC while the car is off? While on, SOC is reported frequently. After turning off the car, I can no longer get SOC from the car. I'm using PID 22005B