Re: [Ovmsdev] Ampera remote start/stop function
FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds. What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc? I will try to get a HW filtered logger going next. Sorry for the delay. Regards, Richard --- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote: From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM Richard, Given the volume of data, I suspect this is going to be hard. For the Roadster, one technique we had was to PING the bus at specific points of the test. e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs. The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to. It looks something like this (Tesla Roadster annotated log extract): 1006.1565 588 00 00 841006.1570 1A0 00 00 00 001006.1573 590 01 00 00 00 00 00 00 001006.4738 NOTE PING: TD11 transmit1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8)1006.8353 343 00 00 04 00 00 0A 20 F01006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C) We kept each individual command in a separate test and log file, for clarity. Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs. The commands we are looking for on the Volt/Ampera are: Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00.Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved?Onstar remote door lock (from an awake car).Onstar remote door unlock (from an awake car).Onstar remote start.Onstar remote stop. As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app? Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well. I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)? Regards, Mark. On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote: Wow that's great decoding work.Sorry about the overruns.Would it help to get another capture, with several iterations? Sent from my phablet, scuse the typos Mark Webb-Johnson <mark@webb-johnson.net> wrote: I've been working through the logs (if anyone else needs a look, let me know). I started by converting to crtd format, so I could use some of my tools on it. Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs: 096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F13F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787 Looking at your logs, I see five new ones have shown up: 22A 362 385 7E4 7EC 22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros. The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs: 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA 10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C 10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA 10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA 10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request. OBDII standard requests are:0x01 - Request Current Powertrain Diagnostic Data0x02 - Request Powertrain Freeze Frame Data0x03 - Request Emission-Related Diagnostic Trouble Codes0x04 - Clear/Reset Emission-Related Diagnostic Information0x05 - Request Oxygen Sensor Monitoring Test Results0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle0x08 - Request Control of On-Board System, Test or Component0x09 - Request Vehicle Information0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent StatusGMLAN enhanced services are: 0x10 - Initiate Diagnostics0x12 - Read Failure Record0x1A - Read Diagnostic ID (DID)0x20 - Return To Normal0x22 - Read Data By Parameter ID (PID)0x23 - Read Memory Address0x27 - Security Access0x28 - Disable Normal Communications0x2C - Define Dynamic Data Packet ID (DPID)0x2D - Define PID by Memory Address0x34 - Request Download0x36 - Transfer Data0x3B - Write DID0x3E - Tester Present0xA2 - Report Programming State0xA5 - Enter Programming Mode0xA9 - Check Codes0xAA - Read DPID0xAE - Device ControlSo, what we are seeing is: 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA==> Respond diagnostic ID A5 is 0103 10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D 10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log? 10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt? 10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000 10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E110:44:50.680 R11 7E4 03 22 83 75 00 00 00 00==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA==> Respond extended PID request for pid 8375, value 060A2D 10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00==> Extended PID request for pid 4389 The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok. Looking at the idle can bus from 10:41, waking up at 10:44 is interesting: 10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 0010:41:37.203 R11 3D1 01 36 80 00 00 00 00 0010:41:37.203 R11 3E9 00 00 00 00 00 00 00 0010:44:47.323 R11 7E4 02 1A A5 00 00 00 00 0010:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA10:44:47.353 R11 1EB 02 52 It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up. I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded. Regards, Mark On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote: Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292 Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292 Car plugged in, locked, finished charging (green led blinking) walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done -rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292 Car plugged in, locked, finished charging (green led blinking) walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done -rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz --- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote: From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM Rens, The car-side technical discussion is going on here: http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing... We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible. The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands. Regards, Mark. On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote: Hello, Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app. In winter I like the remote start/stop function of the Ampera to pre-heat the car.I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie.http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=emHas somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function?I would like to hear your thoughts on this? Best Regards, Rens _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows----- _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -----Inline Attachment Follows----- _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Richard, I originally used this one: http://www.cananalyser.co.uk/cando.html Not cheap, but high speed. Windows only. It has some sample software that can log data, as well as transmit (for simulation). Very basic, but ok. I now use: http://www.can232.com/?page_id=16 Just an RS232 interface, so you need to roll your own software for it, or use one of their sample projects. Cross-platform: windows, linux, mac. Both have hardware filters and can cope with 1MBps on the wire (although no idea how fast they can actually log). I prefer the simplicity of the can232, but the cando is more turn-key (with software). I've been working on my own reverse-engineering tool, which supports the can232, but I haven't managed to spend enough time on it to make it worthwhile releasing yet. I know Michael in Germany is using something else for his Volt - Michael, can you provide details? Regards, Mark. On 26 Feb, 2013, at 2:11 PM, rgjones@sbcglobal.net wrote:
FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds.
What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc?
I will try to get a HW filtered logger going next.
Sorry for the delay.
Regards, Richard
--- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM
Richard,
Given the volume of data, I suspect this is going to be hard.
For the Roadster, one technique we had was to PING the bus at specific points of the test.
e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs.
The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to.
It looks something like this (Tesla Roadster annotated log extract):
1006.1565 588 00 00 84 1006.1570 1A0 00 00 00 00 1006.1573 590 01 00 00 00 00 00 00 00 1006.4738 NOTE PING: TD11 transmit 1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8) 1006.8353 343 00 00 04 00 00 0A 20 F0 1006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C)
We kept each individual command in a separate test and log file, for clarity.
Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs.
The commands we are looking for on the Volt/Ampera are:
Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00. Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved? Onstar remote door lock (from an awake car). Onstar remote door unlock (from an awake car). Onstar remote start. Onstar remote stop.
As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app?
Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well.
I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)?
Regards, Mark.
On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote:
Wow that's great decoding work. Sorry about the overruns. Would it help to get another capture, with several iterations?
Sent from my phablet, scuse the typos
Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I've been working through the logs (if anyone else needs a look, let me know).
I started by converting to crtd format, so I could use some of my tools on it.
Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs:
096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787
Looking at your logs, I see five new ones have shown up:
22A 362 385 7E4 7EC
22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros.
The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00
Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request.
OBDII standard requests are: 0x01 - Request Current Powertrain Diagnostic Data 0x02 - Request Powertrain Freeze Frame Data 0x03 - Request Emission-Related Diagnostic Trouble Codes 0x04 - Clear/Reset Emission-Related Diagnostic Information 0x05 - Request Oxygen Sensor Monitoring Test Results 0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems 0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle 0x08 - Request Control of On-Board System, Test or Component 0x09 - Request Vehicle Information 0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status GMLAN enhanced services are:
0x10 - Initiate Diagnostics 0x12 - Read Failure Record 0x1A - Read Diagnostic ID (DID) 0x20 - Return To Normal 0x22 - Read Data By Parameter ID (PID) 0x23 - Read Memory Address 0x27 - Security Access 0x28 - Disable Normal Communications 0x2C - Define Dynamic Data Packet ID (DPID) 0x2D - Define PID by Memory Address 0x34 - Request Download 0x36 - Transfer Data 0x3B - Write DID 0x3E - Tester Present 0xA2 - Report Programming State 0xA5 - Enter Programming Mode 0xA9 - Check Codes 0xAA - Read DPID 0xAE - Device Control So, what we are seeing is:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 ==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA ==> Respond diagnostic ID A5 is 0103
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 ==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 ==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log?
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 ==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt?
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 ==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 ==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 ==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E1 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 ==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA ==> Respond extended PID request for pid 8375, value 060A2D
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 ==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 ==> Extended PID request for pid 4389
The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok.
Looking at the idle can bus from 10:41, waking up at 10:44 is interesting:
10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 00 10:41:37.203 R11 3D1 01 36 80 00 00 00 00 00 10:41:37.203 R11 3E9 00 00 00 00 00 00 00 00 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.353 R11 1EB 02 52
It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up.
I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded.
Regards, Mark
On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote:
Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292
Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz
--- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM
Rens,
The car-side technical discussion is going on here:
http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing...
We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible.
The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands.
Regards, Mark.
On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote:
Hello,
Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app.
In winter I like the remote start/stop function of the Ampera to pre-heat the car. I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie. http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=em Has somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function? I would like to hear your thoughts on this?
Best Regards,
Rens
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, yes i can. i use the CANUSB Adapter (shown below) from Lawciel. Works well under Windows (XP). In an Virtual Machine in an MacBookPro too. Now it is connected to one RaspberryPI. Works good in Serial Mode. It works good too when the Raspi sends the Serial Port over TCP (ser2net) to an XP in the VM on the Mac. No Corrupt Data seen. Bye Michael Am 26.02.2013 um 15:42 schrieb Mark Webb-Johnson:
Richard,
I originally used this one:
http://www.cananalyser.co.uk/cando.html
<CANdoTopSideFull.jpeg>
Not cheap, but high speed. Windows only. It has some sample software that can log data, as well as transmit (for simulation). Very basic, but ok.
I now use:
http://www.can232.com/?page_id=16
<CANUSB.png>
Just an RS232 interface, so you need to roll your own software for it, or use one of their sample projects. Cross-platform: windows, linux, mac.
Both have hardware filters and can cope with 1MBps on the wire (although no idea how fast they can actually log). I prefer the simplicity of the can232, but the cando is more turn-key (with software).
I've been working on my own reverse-engineering tool, which supports the can232, but I haven't managed to spend enough time on it to make it worthwhile releasing yet.
I know Michael in Germany is using something else for his Volt - Michael, can you provide details?
Regards, Mark.
On 26 Feb, 2013, at 2:11 PM, rgjones@sbcglobal.net wrote:
FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds.
What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc?
I will try to get a HW filtered logger going next.
Sorry for the delay.
Regards, Richard
--- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM
Richard,
Given the volume of data, I suspect this is going to be hard.
For the Roadster, one technique we had was to PING the bus at specific points of the test.
e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs.
The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to.
It looks something like this (Tesla Roadster annotated log extract):
1006.1565 588 00 00 84 1006.1570 1A0 00 00 00 00 1006.1573 590 01 00 00 00 00 00 00 00 1006.4738 NOTE PING: TD11 transmit 1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8) 1006.8353 343 00 00 04 00 00 0A 20 F0 1006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C)
We kept each individual command in a separate test and log file, for clarity.
Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs.
The commands we are looking for on the Volt/Ampera are:
Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00. Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved? Onstar remote door lock (from an awake car). Onstar remote door unlock (from an awake car). Onstar remote start. Onstar remote stop.
As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app?
Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well.
I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)?
Regards, Mark.
On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote:
Wow that's great decoding work. Sorry about the overruns. Would it help to get another capture, with several iterations?
Sent from my phablet, scuse the typos
Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I've been working through the logs (if anyone else needs a look, let me know).
I started by converting to crtd format, so I could use some of my tools on it.
Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs:
096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787
Looking at your logs, I see five new ones have shown up:
22A 362 385 7E4 7EC
22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros.
The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00
Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request.
OBDII standard requests are: 0x01 - Request Current Powertrain Diagnostic Data 0x02 - Request Powertrain Freeze Frame Data 0x03 - Request Emission-Related Diagnostic Trouble Codes 0x04 - Clear/Reset Emission-Related Diagnostic Information 0x05 - Request Oxygen Sensor Monitoring Test Results 0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems 0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle 0x08 - Request Control of On-Board System, Test or Component 0x09 - Request Vehicle Information 0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status GMLAN enhanced services are:
0x10 - Initiate Diagnostics 0x12 - Read Failure Record 0x1A - Read Diagnostic ID (DID) 0x20 - Return To Normal 0x22 - Read Data By Parameter ID (PID) 0x23 - Read Memory Address 0x27 - Security Access 0x28 - Disable Normal Communications 0x2C - Define Dynamic Data Packet ID (DPID) 0x2D - Define PID by Memory Address 0x34 - Request Download 0x36 - Transfer Data 0x3B - Write DID 0x3E - Tester Present 0xA2 - Report Programming State 0xA5 - Enter Programming Mode 0xA9 - Check Codes 0xAA - Read DPID 0xAE - Device Control So, what we are seeing is:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 ==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA ==> Respond diagnostic ID A5 is 0103
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 ==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 ==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log?
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 ==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt?
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 ==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 ==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 ==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E1 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 ==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA ==> Respond extended PID request for pid 8375, value 060A2D
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 ==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 ==> Extended PID request for pid 4389
The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok.
Looking at the idle can bus from 10:41, waking up at 10:44 is interesting:
10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 00 10:41:37.203 R11 3D1 01 36 80 00 00 00 00 00 10:41:37.203 R11 3E9 00 00 00 00 00 00 00 00 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.353 R11 1EB 02 52
It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up.
I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded.
Regards, Mark
On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote:
Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292
Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz
--- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM
Rens,
The car-side technical discussion is going on here:
http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing...
We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible.
The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands.
Regards, Mark.
On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote:
Hello,
Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app.
In winter I like the remote start/stop function of the Ampera to pre-heat the car. I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie. http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=em Has somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function? I would like to hear your thoughts on this?
Best Regards,
Rens
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Michael, What software do you use for CANUSB? Regards, Mark. On 26 Feb, 2013, at 11:27 PM, mikeljo@mac.com wrote:
Hi,
yes i can.
i use the CANUSB Adapter (shown below) from Lawciel. Works well under Windows (XP). In an Virtual Machine in an MacBookPro too. Now it is connected to one RaspberryPI. Works good in Serial Mode. It works good too when the Raspi sends the Serial Port over TCP (ser2net) to an XP in the VM on the Mac. No Corrupt Data seen.
Bye Michael
Am 26.02.2013 um 15:42 schrieb Mark Webb-Johnson:
Richard,
I originally used this one:
http://www.cananalyser.co.uk/cando.html
<CANdoTopSideFull.jpeg>
Not cheap, but high speed. Windows only. It has some sample software that can log data, as well as transmit (for simulation). Very basic, but ok.
I now use:
http://www.can232.com/?page_id=16
<CANUSB.png>
Just an RS232 interface, so you need to roll your own software for it, or use one of their sample projects. Cross-platform: windows, linux, mac.
Both have hardware filters and can cope with 1MBps on the wire (although no idea how fast they can actually log). I prefer the simplicity of the can232, but the cando is more turn-key (with software).
I've been working on my own reverse-engineering tool, which supports the can232, but I haven't managed to spend enough time on it to make it worthwhile releasing yet.
I know Michael in Germany is using something else for his Volt - Michael, can you provide details?
Regards, Mark.
On 26 Feb, 2013, at 2:11 PM, rgjones@sbcglobal.net wrote:
FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds.
What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc?
I will try to get a HW filtered logger going next.
Sorry for the delay.
Regards, Richard
--- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM
Richard,
Given the volume of data, I suspect this is going to be hard.
For the Roadster, one technique we had was to PING the bus at specific points of the test.
e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs.
The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to.
It looks something like this (Tesla Roadster annotated log extract):
1006.1565 588 00 00 84 1006.1570 1A0 00 00 00 00 1006.1573 590 01 00 00 00 00 00 00 00 1006.4738 NOTE PING: TD11 transmit 1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8) 1006.8353 343 00 00 04 00 00 0A 20 F0 1006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C)
We kept each individual command in a separate test and log file, for clarity.
Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs.
The commands we are looking for on the Volt/Ampera are:
Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00. Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved? Onstar remote door lock (from an awake car). Onstar remote door unlock (from an awake car). Onstar remote start. Onstar remote stop.
As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app?
Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well.
I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)?
Regards, Mark.
On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote:
Wow that's great decoding work. Sorry about the overruns. Would it help to get another capture, with several iterations?
Sent from my phablet, scuse the typos
Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I've been working through the logs (if anyone else needs a look, let me know).
I started by converting to crtd format, so I could use some of my tools on it.
Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs:
096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787
Looking at your logs, I see five new ones have shown up:
22A 362 385 7E4 7EC
22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros.
The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00
Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request.
OBDII standard requests are: 0x01 - Request Current Powertrain Diagnostic Data 0x02 - Request Powertrain Freeze Frame Data 0x03 - Request Emission-Related Diagnostic Trouble Codes 0x04 - Clear/Reset Emission-Related Diagnostic Information 0x05 - Request Oxygen Sensor Monitoring Test Results 0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems 0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle 0x08 - Request Control of On-Board System, Test or Component 0x09 - Request Vehicle Information 0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status GMLAN enhanced services are:
0x10 - Initiate Diagnostics 0x12 - Read Failure Record 0x1A - Read Diagnostic ID (DID) 0x20 - Return To Normal 0x22 - Read Data By Parameter ID (PID) 0x23 - Read Memory Address 0x27 - Security Access 0x28 - Disable Normal Communications 0x2C - Define Dynamic Data Packet ID (DPID) 0x2D - Define PID by Memory Address 0x34 - Request Download 0x36 - Transfer Data 0x3B - Write DID 0x3E - Tester Present 0xA2 - Report Programming State 0xA5 - Enter Programming Mode 0xA9 - Check Codes 0xAA - Read DPID 0xAE - Device Control So, what we are seeing is:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 ==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA ==> Respond diagnostic ID A5 is 0103
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 ==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 ==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log?
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 ==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt?
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 ==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 ==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 ==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E1 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 ==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA ==> Respond extended PID request for pid 8375, value 060A2D
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 ==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 ==> Extended PID request for pid 4389
The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok.
Looking at the idle can bus from 10:41, waking up at 10:44 is interesting:
10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 00 10:41:37.203 R11 3D1 01 36 80 00 00 00 00 00 10:41:37.203 R11 3E9 00 00 00 00 00 00 00 00 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.353 R11 1EB 02 52
It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up.
I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded.
Regards, Mark
On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote:
Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292
Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz
--- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM
Rens,
The car-side technical discussion is going on here:
http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing...
We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible.
The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands.
Regards, Mark.
On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote:
Hello,
Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app.
In winter I like the remote start/stop function of the Ampera to pre-heat the car. I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie. http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=em Has somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function? I would like to hear your thoughts on this?
Best Regards,
Rens
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Hi, UPS, forgot. On XP it is Canhacker. At the Raspi, self programed C Routines. VERY Dirty! :) Bye Michael Von unterwegs gesendet Am 27.02.2013 um 00:58 schrieb Mark Webb-Johnson <mark@webb-johnson.net>:
Michael,
What software do you use for CANUSB?
Regards, Mark.
On 26 Feb, 2013, at 11:27 PM, mikeljo@mac.com wrote:
Hi,
yes i can.
i use the CANUSB Adapter (shown below) from Lawciel. Works well under Windows (XP). In an Virtual Machine in an MacBookPro too. Now it is connected to one RaspberryPI. Works good in Serial Mode. It works good too when the Raspi sends the Serial Port over TCP (ser2net) to an XP in the VM on the Mac. No Corrupt Data seen.
Bye Michael
Am 26.02.2013 um 15:42 schrieb Mark Webb-Johnson:
Richard,
I originally used this one:
http://www.cananalyser.co.uk/cando.html
<CANdoTopSideFull.jpeg>
Not cheap, but high speed. Windows only. It has some sample software that can log data, as well as transmit (for simulation). Very basic, but ok.
I now use:
http://www.can232.com/?page_id=16
<CANUSB.png>
Just an RS232 interface, so you need to roll your own software for it, or use one of their sample projects. Cross-platform: windows, linux, mac.
Both have hardware filters and can cope with 1MBps on the wire (although no idea how fast they can actually log). I prefer the simplicity of the can232, but the cando is more turn-key (with software).
I've been working on my own reverse-engineering tool, which supports the can232, but I haven't managed to spend enough time on it to make it worthwhile releasing yet.
I know Michael in Germany is using something else for his Volt - Michael, can you provide details?
Regards, Mark.
On 26 Feb, 2013, at 2:11 PM, rgjones@sbcglobal.net wrote:
FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds.
What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc?
I will try to get a HW filtered logger going next.
Sorry for the delay.
Regards, Richard
--- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM
Richard,
Given the volume of data, I suspect this is going to be hard.
For the Roadster, one technique we had was to PING the bus at specific points of the test.
e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs.
The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to.
It looks something like this (Tesla Roadster annotated log extract):
1006.1565 588 00 00 84 1006.1570 1A0 00 00 00 00 1006.1573 590 01 00 00 00 00 00 00 00 1006.4738 NOTE PING: TD11 transmit 1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8) 1006.8353 343 00 00 04 00 00 0A 20 F0 1006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C)
We kept each individual command in a separate test and log file, for clarity.
Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs.
The commands we are looking for on the Volt/Ampera are:
Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00. Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved? Onstar remote door lock (from an awake car). Onstar remote door unlock (from an awake car). Onstar remote start. Onstar remote stop.
As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app?
Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well.
I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)?
Regards, Mark.
On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote:
Wow that's great decoding work. Sorry about the overruns. Would it help to get another capture, with several iterations?
Sent from my phablet, scuse the typos
Mark Webb-Johnson <mark@webb-johnson.net> wrote:
I've been working through the logs (if anyone else needs a look, let me know).
I started by converting to crtd format, so I could use some of my tools on it.
Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs:
096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148 160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206 214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F1 3F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787
Looking at your logs, I see five new ones have shown up:
22A 362 385 7E4 7EC
22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros.
The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00
Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request.
OBDII standard requests are: 0x01 - Request Current Powertrain Diagnostic Data 0x02 - Request Powertrain Freeze Frame Data 0x03 - Request Emission-Related Diagnostic Trouble Codes 0x04 - Clear/Reset Emission-Related Diagnostic Information 0x05 - Request Oxygen Sensor Monitoring Test Results 0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems 0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle 0x08 - Request Control of On-Board System, Test or Component 0x09 - Request Vehicle Information 0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent Status GMLAN enhanced services are:
0x10 - Initiate Diagnostics 0x12 - Read Failure Record 0x1A - Read Diagnostic ID (DID) 0x20 - Return To Normal 0x22 - Read Data By Parameter ID (PID) 0x23 - Read Memory Address 0x27 - Security Access 0x28 - Disable Normal Communications 0x2C - Define Dynamic Data Packet ID (DPID) 0x2D - Define PID by Memory Address 0x34 - Request Download 0x36 - Transfer Data 0x3B - Write DID 0x3E - Tester Present 0xA2 - Report Programming State 0xA5 - Enter Programming Mode 0xA9 - Check Codes 0xAA - Read DPID 0xAE - Device Control So, what we are seeing is:
10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 ==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA ==> Respond diagnostic ID A5 is 0103
10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 ==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D
10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 ==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log?
10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 ==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt?
10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000
10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 ==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 ==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 ==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E1 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 ==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA ==> Respond extended PID request for pid 8375, value 060A2D
10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 ==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 ==> Extended PID request for pid 4389
The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok.
Looking at the idle can bus from 10:41, waking up at 10:44 is interesting:
10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 00 10:41:37.203 R11 3D1 01 36 80 00 00 00 00 00 10:41:37.203 R11 3E9 00 00 00 00 00 00 00 00 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.353 R11 1EB 02 52
It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up.
I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded.
Regards, Mark
On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote:
Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292
Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292
Car plugged in, locked, finished charging (green led blinking)
walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done
-rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz
--- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM
Rens,
The car-side technical discussion is going on here:
http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing...
We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible.
The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands.
Regards, Mark.
On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote:
> Hello, > > Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app. > > In winter I like the remote start/stop function of the Ampera to pre-heat the car. > I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie. > http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=em > Has somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function? > I would like to hear your thoughts on this? > > Best Regards, > > Rens > > > _______________________________________________ > OvmsDev mailing list > OvmsDev@lists.teslaclub.hk > http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows-----
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
Thanks for all the suggestions. <Personally I like dirty C code> I am working on getting a better CAN reverse engineering setup and will get you some cleaner onstar dumps. That wont be at least till the weekend assuming the hardware gets here. Regards, Richard --- On Tue, 2/26/13, Michael Jochum <mikeljo@me.com> wrote: From: Michael Jochum <mikeljo@me.com> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Cc: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Tuesday, February 26, 2013, 10:35 PM Hi, UPS, forgot.On XP it is Canhacker.At the Raspi, self programed C Routines. VERY Dirty! :) ByeMichael Von unterwegs gesendet Am 27.02.2013 um 00:58 schrieb Mark Webb-Johnson <mark@webb-johnson.net>: Michael, What software do you use for CANUSB? Regards, Mark. On 26 Feb, 2013, at 11:27 PM, mikeljo@mac.com wrote: Hi, yes i can. i use the CANUSB Adapter (shown below) from Lawciel.Works well under Windows (XP). In an Virtual Machine in an MacBookPro too.Now it is connected to one RaspberryPI. Works good in Serial Mode.It works good too when the Raspi sends the Serial Port over TCP (ser2net) to an XP in the VM on the Mac.No Corrupt Data seen. ByeMichael Am 26.02.2013 um 15:42 schrieb Mark Webb-Johnson: Richard, I originally used this one: http://www.cananalyser.co.uk/cando.html <CANdoTopSideFull.jpeg> Not cheap, but high speed. Windows only. It has some sample software that can log data, as well as transmit (for simulation).Very basic, but ok. I now use: http://www.can232.com/?page_id=16 <CANUSB.png> Just an RS232 interface, so you need to roll your own software for it, or use one of their sample projects.Cross-platform: windows, linux, mac. Both have hardware filters and can cope with 1MBps on the wire (although no idea how fast they can actually log). I prefer the simplicity of the can232, but the cando is more turn-key (with software). I've been working on my own reverse-engineering tool, which supports the can232, but I haven't managed to spend enough time on it to make it worthwhile releasing yet. I know Michael in Germany is using something else for his Volt - Michael, can you provide details? Regards, Mark. On 26 Feb, 2013, at 2:11 PM, rgjones@sbcglobal.net wrote: FYI I tried to get more logs but keep running into a data overrun problem with my simple 200Mhz ARM based can logger. This even with logging only IDs that meet mask 0x7e0. The vendor sample code I have does not use filters, so the filtering is in SW, but even with writing logs to ramdisk I still see overrun errors. The HW supports filtering and I will try that next, but it seems when onstar does an enquiry there is a huge burst of CAN activity that perhaps will still overrun this low power hardware. I mean The (non masked) logger saw >59,000 lines (many overruns) in just a few seconds. What PC (Windows or preferably Linux) USB/CAN & software do you recommend for capturing logs, setting filters etc? I will try to get a HW filtered logger going next. Sorry for the delay. Regards, Richard --- On Sun, 2/24/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote: From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Sunday, February 24, 2013, 4:48 PM Richard, Given the volume of data, I suspect this is going to be hard. For the Roadster, one technique we had was to PING the bus at specific points of the test. e.g.; Start log, wait 30 seconds, PING, send unlock command, PING, wait for car's response, PING, wait 30 seconds, Stop log. Save specific log file, with documented PINGs. The PINGs we used were just to transmit a 0 byte CAN bus message on an unused arbitration ID (which would then indirectly also show up in the can bus logs). If you have some way to inject a message directly into the can bus logs, without actually transmitting on the bus, that is also fine. We just need some markers in the files as close as possible to the events they relate to. It looks something like this (Tesla Roadster annotated log extract): 1006.1565 588 00 00 841006.1570 1A0 00 00 00 001006.1573 590 01 00 00 00 00 00 00 001006.4738 NOTE PING: TD11 transmit1006.5559 100 96 E8 00 02 A1 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits E8)1006.8353 343 00 00 04 00 00 0A 20 F01006.8364 344 52 35 50 37 6E 39 6F 3A --- TPMS (f-l 29psi,13C f-r 29psi,15C r-l 39psi,17C r-r 40psi,18C) We kept each individual command in a separate test and log file, for clarity. Using that technique, we get 30 seconds of pre-command normal data, the unlock command and car's response sandwiched between three pings, and then 30 seconds of post-command normal data. By comparing the messages pre, during and post, it is much easier to see what has changed and try to isolate likely candidates for what we are looking for. My best guess is that these commands will be 7E? request/response style, but they could also turn up on normal can arbitration IDs. The commands we are looking for on the Volt/Ampera are: Wake up [onstar status update request] car (can bus is idle, something is sent, then suddenly bus is active and lots of stuff happening). Candidate for this now is 7E4 02 1A A5 00 00 00 00 00.Sleep (this maybe a 2 minute timer, or some other specific command). Does closing the App send a command to immediately shut the bus/car down, or is there a timer involved?Onstar remote door lock (from an awake car).Onstar remote door unlock (from an awake car).Onstar remote start.Onstar remote stop. As Michael J points out, it is also useful if you can give us what the car / app shows at each point. Such as for the remote start cabin pre-heat, what is the ambient and/or cabin temperature show in the car and on the app? Regarding Michael J's suggestions for filters, I agree. In particular a filter on just IDs 7E? (16 arbitration IDs) would be very useful and would reduce volume and overruns. But, it is also useful to get a full dump as well. I realise that this is a lot of time-in-the-car for you, but am encouraged by the first results you got. Perhaps we should just concentrate on the easier #1 through #4 to start with (wake, sleep, lock, unlock)? Regards, Mark. On 25 Feb, 2013, at 7:50 AM, Richard G Jones wrote: Wow that's great decoding work.Sorry about the overruns.Would it help to get another capture, with several iterations? Sent from my phablet, scuse the typos Mark Webb-Johnson <mark@webb-johnson.net> wrote: I've been working through the logs (if anyone else needs a look, let me know). I started by converting to crtd format, so I could use some of my tools on it. Looking at a bunch of other logs provided by volt/ampera drivers, we've so far seen 108 unique can arbitration IDs: 096 097 098 0AA 0B1 0B9 0BA 0BB 0BC 0BD 0C1 0C4 0C5 0C7 0C9 0D1 0D3 0F1 101 120 12A 130 135 137 139 140 148160 17D 182 185 186 1A1 1A3 1C3 1C4 1C5 1C6 1DF 1E1 1E5 1E9 1EB 1ED 1EF 1F1 1F3 1F4 1F5 1FB 200 202 204 206214 222 224 226 228 230 236 238 287 2C3 2C7 2F1 2F9 32A 32C 348 34A 3C1 3C9 3CB 3D1 3DC 3DD 3E3 3E9 3ED 3F13F9 3FB 3FC 451 4C1 4C5 4C7 4C9 4CB 4D1 4D7 4D9 4E1 4E9 4F1 500 514 52A 530 589 770 772 773 778 77D 77F 787 Looking at your logs, I see five new ones have shown up: 22A 362 385 7E4 7EC 22A is jumping all over the place. 362 is all zeros. 385 is zeros up until 10:56:05.178, when it changes to show what may be temperature, and then at 10:57:47.007 it seem to switch back to zeros. The 7E4 and 7EC ones are the most interesting, as they are OBDII style request/response. Here are the relevant logs: 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA 10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA 10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C 10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA 10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 10:44:50.680 R11 7E4 03 22 83 75 00 00 00 00 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA 10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00 Note that 7E4 is the Hybrid Powertrain Control Module B, and 7EC is the reply to that request. OBDII standard requests are:0x01 - Request Current Powertrain Diagnostic Data0x02 - Request Powertrain Freeze Frame Data0x03 - Request Emission-Related Diagnostic Trouble Codes0x04 - Clear/Reset Emission-Related Diagnostic Information0x05 - Request Oxygen Sensor Monitoring Test Results0x06 - Request On-Board Monitoring Test Results for Specific Monitored Systems0x07 - Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle0x08 - Request Control of On-Board System, Test or Component0x09 - Request Vehicle Information0x0A - Request Emission-Related Diagnostic Trouble Codes with Permanent StatusGMLAN enhanced services are: 0x10 - Initiate Diagnostics0x12 - Read Failure Record0x1A - Read Diagnostic ID (DID)0x20 - Return To Normal0x22 - Read Data By Parameter ID (PID)0x23 - Read Memory Address0x27 - Security Access0x28 - Disable Normal Communications0x2C - Define Dynamic Data Packet ID (DPID)0x2D - Define PID by Memory Address0x34 - Request Download0x36 - Transfer Data0x3B - Write DID0x3E - Tester Present0xA2 - Report Programming State0xA5 - Enter Programming Mode0xA9 - Check Codes0xAA - Read DPID0xAE - Device ControlSo, what we are seeing is: 10:44:47.323 R11 7E4 02 1A A5 00 00 00 00 00==> Read diagnostic ID A5 10:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA==> Respond diagnostic ID A5 is 0103 10:44:47.533 R11 7E4 03 22 83 77 00 00 00 00==> Request extended PID 8377 10:44:47.536 R11 7EC 06 62 83 77 06 0A 2D AA ==> Respond extended PID 8377 is 060A2D 10:44:47.744 R11 7E4 02 1A A4 00 00 00 00 00==> Read diagnostic ID A4 10:44:47.746 R11 7EC 10 09 5A A4 1C 1C 1C 1C ==> Weird response - seem shifted over one. But, presumably a response to diagnostic ID A4. Maybe corrupt in the log? 10:44:47.762 R11 7E4 30 00 00 00 00 00 00 00==> Bizarre. Corrupt? 10:44:47.766 R11 7EC 21 1C 1C 1C AA AA AA AA ==> Bizarre. Corrupt? 10:44:48.622 R11 7EC 07 62 41 AB 00 00 00 00 ==> Response to an extended PID request for 41AB, value 000000 10:44:49.105 R11 7E4 03 22 41 AC 00 00 00 00==> Extended PID request for pid 41AC 10:44:49.187 R11 7E4 03 22 41 AB 00 00 00 00==> Extended PID request for pid 41AB 10:44:50.011 R11 7E4 03 22 43 9B 00 00 00 00==> Extended PID request for pid 439B 10:44:50.309 R11 7E4 03 22 83 E1 00 00 00 00 ==> Extended PID request for pid 83E110:44:50.680 R11 7E4 03 22 83 75 00 00 00 00==> Extended PID request for pid 8375 10:44:50.683 R11 7EC 06 62 83 75 06 0A 2D AA==> Respond extended PID request for pid 8375, value 060A2D 10:44:50.757 R11 7E4 03 22 41 A6 00 00 00 00==> Extended PID request for pid 41A6 10:44:52.575 R11 7E4 03 22 43 89 00 00 00 00==> Extended PID request for pid 4389 The log file has a large number of 'data overrun errors' around 10:44:48 and 10:44:49 - I suspect that a few of few of the requests/replies were lost around that time. The start (10:44:47) of the log looks ok. Looking at the idle can bus from 10:41, waking up at 10:44 is interesting: 10:41:37.203 R11 2C3 06 59 06 A0 06 A0 CA 0010:41:37.203 R11 3D1 01 36 80 00 00 00 00 0010:41:37.203 R11 3E9 00 00 00 00 00 00 00 0010:44:47.323 R11 7E4 02 1A A5 00 00 00 00 0010:44:47.335 R11 7EC 04 5A A5 01 03 AA AA AA10:44:47.353 R11 1EB 02 52 It certainly looks like the 7E4 02 1A A5 00 00 00 00 00 woke things up. I'll keep looking, but it seems that the log file is inconsistent as the logger got overloaded. Regards, Mark On 23 Feb, 2013, at 3:13 AM, rgjones@sbcglobal.net wrote: Hello Folks, I just captured CAN data during onstar commands for remote start/stop lock/unlock. Below are my notes. Where should I send the log file? Regards, Richard San Diego 2013 Volt #119292 Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292 Car plugged in, locked, finished charging (green led blinking) walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done -rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt Fri Feb 22, 2013 10am PST VIN: 1g1re6e49du119292 Car plugged in, locked, finished charging (green led blinking) walk up to car fob - unlock open passenger door - get in close passenger door. 10:41 start android onstar app request status update (push refresh icon on app) 10:43 - app shows doing refresh see CAN activity 10:44 app finally updates - 120V battery fully charged 36 mile ev range 152 fuel range Oil life remaining 86% odo 3955 miles 10:45 can updates stop onstart remote door lock 1052 - sent lock cmd 1052 locked - lots of can 1053 remote start sent. failed as key in vehicle 1054 1054 remote unlock 1054 done 1055 leave via passenger door, close it. keyfob lock 1055 leave key out of range of the car 1055 remote start req 1056 app says "cabin temp being set for optimal comfort" lots of CAN Dash still off, but orange engine light is on. 1057 send cancel engine start. 1057 - engine light off - app says done -rw-r--r-- 1 root root 17471412 2013-02-22 10:59 volt_130222_1_CAN_log.txt gzip volt_130222_1_CAN_log.txt tattler:~# tail volt_130222_1_CAN_log.txt 10:58:02.055852 S. id=0x000001c4 dat=0xca:0x62:0xc1:0x10:0x04:0x00:0x03:0xfe 10:58:02.057282 S. id=0x000001c5 dat=0x2c:0x03:0x2c:0x03:0x2e:0x01 10:58:02.058671 S. id=0x000001f4 dat=0x00:0x00:0x00:0x00:0x00:0x00 10:58:02.060073 S. id=0x00000287 dat=0xc1:0x00 10:58:02.062044 S. id=0x000002c3 dat=0x06:0x5b:0x06:0xa0:0x06:0xa0:0xca:0x00 10:58:02.062468 S. id=0x000000bc dat=0x37:0x00:0x00:0x40:0x00:0x00:0x00:0x00 10:58:02.062785 S. id=0x000000aa dat=0x2c:0x03:0x2c:0x03:0x04:0x53:0xfb:0x00 10:58:02.063088 S. id=0x000000c9 dat=0x00:0x00:0x00:0x27:0x00:0x10:0x08:0x00 10:58:02.063392 S. id=0x000001ed dat=0x01:0x90:0x00:0x00:0x00:0x00:0x18:0x01 10:58:02.063691 S. id=0x000001ef dat=0x00:0x00:0x00:0x00 gzip volt_130222_1_CAN_log.txt -rw-r--r-- 1 root root 1888643 2013-02-22 10:59 volt_130222_1_CAN_log.txt.gz --- On Sat, 2/16/13, Mark Webb-Johnson <mark@webb-johnson.net> wrote: From: Mark Webb-Johnson <mark@webb-johnson.net> Subject: Re: [Ovmsdev] Ampera remote start/stop function To: "OVMS Developers" <ovmsdev@lists.teslaclub.hk> Date: Saturday, February 16, 2013, 12:03 AM Rens, The car-side technical discussion is going on here: http://gm-volt.com/forum/showthread.php?12958-CAN-bus-reading-remote-viewing... We're after pretty much the same things as the DashDaq people, so there is a lot of overlap.
From the App, it is no problem. We can use HomeLink for testing at the moment, and implement something properly when we know it is feasible. The problem is that we need CAN bus dumps while OnStar / KeyFob pre-heat and remote start/stop is commanded. For that, we need someone with a Volt in the USA and CAN-USB logger to help us try to find the commands. Regards, Mark. On 16 Feb, 2013, at 7:56 AM, Rens Meijer <r.meijer@atlantis-it.nl> wrote: Hello, Last week I received the OVMS V2 module to monitor my Ampera. I already had an OVMS V1 module to monitor the Tesla Roadster, so it works nicely from 1 app. In winter I like the remote start/stop function of the Ampera to pre-heat the car.I found this Youtube that in the US it is possible with the OnStar system to remote start/stop the car. See at 2.21 in the movie.http://www.youtube.com/watch?v=IOJMVbQnNIU&sns=emHas somebody already made a CAN bus log during the remote start/stop by using the remote control? If you are able to find the sequence, how easy would it be to configure the current home buttons in the app to implement the start/stop function?I would like to hear your thoughts on this? Best Regards, Rens _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-----Inline Attachment Follows----- _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -----Inline Attachment Follows----- _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev -----Inline Attachment Follows----- _______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
participants (4)
-
Mark Webb-Johnson -
Michael Jochum -
mikeljo＠mac.com -
rgjones＠sbcglobal.net