March 2013 - OvmsDev - Open Vehicles

Re: [Ovmsdev] OVMS VIN 4E9->4F1->4E1 (was OVMS VIN 4E9->4F1)
by Mark Webb-Johnson 07 Aug '13

07 Aug '13

Michael, OK. I found some old logs you sent me before and these show: 7.628 R11 4E9 E1 80 00 04 6C 00 7.637 R11 514 47 31 52 39 36 45 34 39 8.647 R11 4F1 41 A1 01 A1 00 36 08 88 The 514 looks fine. But, both 4E9 and 4F1 look wrong. In particular, the 4F1 has '41 A1 01 A1 00' - which is what we are seeing for your VIN. But, id #4E1 has: 8.694 R11 4E1 43 55 31 31 36 34 38 39 If the VIN was in 4E1 and 514, that would give us: 8.694 R11 4E1 43 55 31 31 36 34 38 39 7.637 R11 514 47 31 52 39 36 45 34 39 Or, CU116489G1R96E49 for your car. For RScott, his logs show: 41966.094 R11 4E1 42 55 31 30 32 36 38 39 41966.110 R11 514 47 31 52 44 36 45 34 36 Or, BU102389G1RD6E36 for his car. Is that correct? Reading back through the old eMails, I find this from RScott: > The VIN can be constructed by taking the number "1" and converting the CAN IDs 4E9 and 514 to ASCII. So with "4E1 4255313032363839" and "514 4731524436453436", you would end up with 42 55 31 30 32 36 38 39 47 31 52 44 36 45 34 36, where 42 is ASCII for B, 55 is U, etc. So, I think the whole 4E9 was just a typo, as 4E1 is what is mentioned later in the same sentence. I've committed the code with 4E1 into github now. It works ok on my simulator, and hopefully should be ok in your car now. Can you try? Regards, Mark. On 26 Dec, 2012, at 9:12 PM, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > Michael, > > I've put this up on my test bench, set to VA vehicle type, and setting my simulator to 500Kbps CAN speed, then transmitting the following three messages once a second: > > ID#206 A0 10 00 00 00 00 00 00 > ID#4F1 42 55 31 30 32 36 38 39 > ID#514 47 31 52 44 D6 45 34 36 > > Then, with the module in SETUP mode, I get: > > S MODULE? > # Module: > VehicleID:TESTCAR > VehicleType:VA > Units:K > Notifications:IP > > DIAG > # DIAG > > # Firmware: 2.1.1/VA/V2 > # SWITCH: 1 > # 12V Line: 14.0 V > # Signal: 0 > > # VIN: BU102689G1RD6E46 (VA) > # SOC: 64% (0 ideal, 0 est miles) > > That all looks ok. > The message from your car is: > > GERMANVOLT rx msg F 2.1.1/V2,A??,24,0,VA,E-Plus > > 00000040 20 6d 73 67 20 46 20 32 2e 31 2e 31 2f 56 32 2c | msg F 2.1.1/V2,| > 00000050 41 a1 01 a1 2c 32 31 2c 30 2c 56 41 2c 45 2d 50 |A...,21,0,VA,E-P| > 00000060 6c 75 73 0a |lus.| > > Your VIN is showing up as 41,A1,01,A1 - as you say: wrong. > > But, the firmware version and car type look ok. Not sure why they would not show up in the App. Perhaps the corrupt VIN# is messing up interpretation of that message? Perhaps the high bit on the A1 is messing it up. > > Not sure what is going on in your car itself. Can you check any captures you have for the exact id#4F1 and id#514 messages you have, and let me know? > > Regards, Mark. > > On 21 Dec, 2012, at 9:33 PM, mikeljo(a)mac.com wrote: > >> Hi, >> >> thanks. >> >> Works. Get the correct infos from my car. >> Implement the SOC calculation from my previous mail. >> >> - GPS ok >> - SOC ok >> >> BUT: >> - no VIN >> - No Car Type >> - no car firmware >> >> Here some Pics from the App: >> >> <IMG_1075.PNG> >> <IMG_1076.PNG> >> <IMG_1077.PNG> >> <IMG_1078.PNG> >> >> >> The App is the 1.3.2 compiled from the git. This is NOT the one from the Store!? >> >> BTW: You see the GSM Signal is -113dBm. When one door is open i got -87dBm. Heavy attenuation. >> I think i must mount the antenna outside the car. GPS is ok. >> >> >> Bye >> michael >> >> >> Am 21.12.2012 um 02:19 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >> >>> Michael, >>> >>> Parameter #14 (PARAM_VEHICLETYPE) holds the selected vehicle type. This can be set either from the smartphone apps, or via the SMS MODULE command. >>> >>> Regards, Mark. >>> >>> On 21 Dec, 2012, at 4:31 AM, mikeljo(a)mac.com wrote: >>> >>>> Hi, >>>> >>>> i checked it out. It compiles without error. >>>> But i think i missed something: how to switch between the cars? I know you do something, but couldn't find the howto. >>>> I found the ROM Parameter "VA" in "vehicle.c", but how to put this in the ROM? >>>> SMS Command? >>>> >>>> Sorry. >>>> >>>> Bye >>>> Michael >>>> >>>> >>>> Am 20.12.2012 um 15:08 schrieb Mark Webb-Johnson <mark(a)webb-johnson.net>: >>>> >>>>> Michael J: >>>>> >>>>> The following commit should fix this: >>>>> >>>>> * 269cd4f (HEAD, origin/master, origin/HEAD, master) Ampera VIN 4E9->4F1 >>>>> >>>>> Can you check the code now in master head, and see if it has everything you need. It builds and compiles on v2 hardware, but you'll need to change the compiler flags to get it building on v1 (just change TESLAROADSTER to VOLTAMPERA). >>>>> >>>>> What was the end result of the SOC range changes? Any ideas on the solution? >>>>> >>>>> Regards, Mark. >>>>> >>>>> On 6 Nov, 2012, at 5:28 AM, mikeljo(a)mac.com wrote: >>>>> >>>>>> Hi mark, >>>>>> >>>>>> do you think at the VIN? >>>>>> >>>>>> 1 + 514 + 4F1 >>>>> >>>> >>> >> >

11 85

Charging and Driving Logs
by Mark Webb-Johnson 29 Apr '13

29 Apr '13

I have wanted to implement charging and driving logs, for some time now. The idea is the car will record 'drives' and 'charges' and report them back as historical records. This will be independent of the vehicle module, so should work for all supported vehicles. For each drive, we need: End time [4 bytes] Duration (seconds) [2 bytes] Drive mode [1 byte] Start location [8 bytes] End location [8 bytes] Distance driven [2 bytes] kWh used [2 bytes] For each charge, we need: End time [4 bytes] Duration (seconds) [2 bytes] Charge mode [1 byte] Charge location [8 bytes] Current available [1 byte] Current used [1 byte] Voltage [2 bytes] Result (completed, stopped, failed) [1 byte] kWh used [1 byte] That is 27 bytes per drive, or 21 bytes per charge. The problem is that GPRS connectivity may not be there at the end of the drive or charge, so we need to store these records. RAM would be good, but we only have 429 bytes left (and I think 256 bytes of that may be stack). EEPROM is also possible, but full of parameters at the moment. I'm thinking of using the top 4 parameters (#20 through #23) - these appear to be free at the moment, and would give us 128 bytes of permanent storage. Easiest would be 32 bytes for each record. This would be turned on with a FEATURE_CARBITS (suggestion: 0x80), so it would default off (for privacy). Comments / suggestions? Regards, Mark.

2 2

Seeking ideas for 'range' representation
by Mark Webb-Johnson 16 Apr '13

16 Apr '13

Working with the guys at zerocarbonworld / openchargemap on the integration of Open Charge Map to the OVMS Apps, we are trying to find a way to represent range graphically. The first idea was a circle, centered around the car, with the inner edge of the circle being estimated range and the outer edge ideal range (or vice versa if you are coming down the mountains on a _long_ mountain road). Plugging in the values for my car today, assuming I was somewhere in the centre of the UK, it would look something like this: The idea is to represent the range, and then plot the charge points within (and perhaps also slightly outside) that range. That is just one idea. What do people think? Any other suggestions? Regards, Mark. P.S. Work on the Apps for this has already started, so I would appreciate a quick reply. Nothing too extensive - just ideas.Thanks.

6 9

The search for Tesla Roadster CAC
by Mark Webb-Johnson 15 Apr '13

15 Apr '13

Tom, 'roadsters', I'm searching for the CAC value on the Tesla Roadster. Here is a log extract. The first NOTE is just before we called up the diagnostic screen, and the second NOTE was after the screen had appeared. I also attach the matching diagnostics screen. 127.1062 NOTE PING: TD11 transmit 127.1236 400 01 01 00 00 00 00 4C 1D 127.1716 400 02 A3 01 80 C5 80 55 00 127.2220 400 01 01 00 00 00 00 4C 1D 127.2716 400 02 A3 01 80 C5 80 55 00 127.3220 400 01 01 00 00 00 00 4C 1D 127.3716 400 02 A3 01 80 C5 80 55 00 127.4220 400 01 01 00 00 00 00 4C 1D 127.4621 100 80 4B 92 00 64 00 7B 00 ->VDS Range (SOC 75%) (ideal 146) (est 123) 127.4633 100 9C 01 5C 01 ->VDS Trip->VDS (trip 34.8miles) 127.4716 400 02 A3 01 80 C5 80 55 00 127.5239 400 01 01 00 00 00 00 4C 1D 127.5687 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 127.5716 400 02 A3 01 80 C5 80 55 00 127.6236 400 01 01 00 00 00 00 4C 1D 127.6553 102 06 D0 07 00 00 00 00 40 VDS-> (message from VDS 06) 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) 127.6662 420 00 8A 8A 127.6665 588 00 00 84 127.6668 280 00 00 03 00 00 00 00 00 127.6670 1A0 00 00 00 00 127.6674 590 01 00 00 00 00 00 00 00 127.6717 400 02 A3 01 80 C5 80 55 00 127.7220 400 01 01 00 00 00 00 4C 1D 127.7716 400 02 A3 01 80 C5 80 55 00 127.8217 400 03 11 66 00 00 00 77 00 127.8719 400 01 01 00 00 00 00 4C 1D 127.9019 100 96 69 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits 69) 127.9217 400 02 A3 01 80 C5 80 55 00 127.9720 400 01 01 00 00 00 00 4C 1D 128.0244 400 02 A3 01 80 C5 80 55 00 128.0723 400 01 01 00 00 00 00 4C 1D 128.1253 400 02 A3 01 80 C5 80 55 00 128.1723 400 01 01 00 00 00 00 4C 1D 128.2221 400 02 A3 01 80 C5 80 55 00 128.2724 400 01 01 00 00 00 00 4C 1D 128.3221 400 02 A3 01 80 C5 80 55 00 128.3724 400 01 01 00 00 00 00 4C 1D 128.4221 400 02 A3 01 80 C5 80 55 00 128.4319 100 9B 2D 88 73 0C B9 C6 07 ->VDS (message to VDS 9B) 128.4724 400 01 01 00 00 00 00 4C 1D 128.5241 400 02 A3 01 80 C5 80 55 00 128.5388 402 FA 00 C3 59 F4 01 5C 01 402?? Odometer (miles: 12808.9 km: 20613.9) (trip 34.8miles) 128.5724 400 01 01 00 00 00 00 4C 1D 128.5939 NOTE PING: TD11 transmit Most likely candidate is the "102 06" being used to inform the VMS we are looking at the ESS SOC screen, then the VMS steaming a few message with the information requested. We've seen "102 06" a screen switch command, a few times in the past. It seems to awake dormant stuff in the VMS. Looking at the return data, we get: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) as likely candidates for the top part of the screen, and: 127.6596 100 A1 01 41 0C 40 32 1C 00 ->VDS (message to VDS A1) 127.6600 100 A2 01 4B 00 4C FF 00 00 ->VDS (message to VDS A2) 127.6606 100 A1 02 29 0C 40 12 2D 00 ->VDS (message to VDS A1) 127.6610 100 A2 02 50 00 84 FF 00 00 ->VDS (message to VDS A2) 127.6621 100 A1 03 97 0B 41 35 36 00 ->VDS (message to VDS A1) 127.6626 100 A2 03 55 00 EA FF 00 00 ->VDS (message to VDS A2) 127.6632 100 A1 04 8B 0B 41 13 43 00 ->VDS (message to VDS A1) 127.6636 100 A2 04 53 00 0C 01 00 00 ->VDS (message to VDS A2) 127.6642 100 A1 05 87 0B 3F 07 47 00 ->VDS (message to VDS A1) 127.6647 100 A2 05 49 00 FF FF 00 00 ->VDS (message to VDS A2) 127.6653 100 A1 06 86 0B 3F 09 48 00 ->VDS (message to VDS A1) 127.6658 100 A2 06 49 00 3F FF 00 00 ->VDS (message to VDS A2) as the rest. For the 'rest', that it six pairs of A1 A2 lines, with an index value of 01 through 06, and then 12 bytes of data (2x6) for each. Kind of looks like the 6 lines of date based AH log. For the 9E, 9F and A0, we need to find: SOC LIM: 68% (0x44 single byte hex) SOC MIN: 68% (0x44 single byte hex) SOC MAX: 70% (0x46 single byte hex) CAC: 156.99Ah AR:91.54Ah #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) dRMS: 52A (0x34 single byte hex) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) Given: 127.6579 100 9E 44 FD 9C 8A 5B 44 46 ->VDS (message to VDS 9E) 127.6586 100 9F 00 00 00 00 00 B5 21 ->VDS (message to VDS 9F) 127.6590 100 A0 3B 34 00 30 02 11 01 ->VDS (message to VDS A0) Here' s my working (both to show others how such a search is done, and also to document it): We can get rid of some easy ones: 127.6579 100 9E <SOCLIM?> FD 9C 8A 5B <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 B5 21 127.6590 100 A0 3B 34 00 30 02 11 01 Working: 5B8A(hex) = 23434(decimal) 9CFB(hex) = 40187(decimal) and 23434/40187 = 0..5831238957 while Ah/CAC (91.54/156.99) = 0.5833174026 So, those two seem to be good candidates. Interestingly: 40187 / 156.99 = 255.98 Could it be that? 9CFD(hex) = 40187(decimal). Then 40187/256 = 156.98 5B8A(hex) = 23434(decimal). Then 23434/256 = 91.54 Close, but no cigar. We're 0.01 off on the CAC. The Tesla loves bytes, and hates decimals (just like the PIC), so how about if we treat them as separate bytes (essentially rather than /100, try /256): 9C.FD (hex) = 156.99 5B.8A (hex) = 91.54 Woohoo! I think we may have a match. Plugging in these, and some of the other ones I found along the way, gives us: 127.6579 100 9E <SOCLIM?> <CACLSB> <CACMSB> <ARLSB> <ARMSB> <SOCMIN?> <SOCMAX> 127.6586 100 9F 00 00 00 00 00 <kWhRLSB> <kWhRMSB> 127.6590 100 A0 3B <dRMSLSB> <dRMSMSB> <dAILSB> <dAIMSB> <dWhMLSB> <dWhMMSB> And the notes would be: SOC LIM: 68% (0x44 single byte hex) - 100 9E (B2) SOC MIN: 68% (0x44 single byte hex) - 100 9E (B7) SOC MAX: 70% (0x46 single byte hex) - 100 9E (B8) CAC: 156.99Ah - 100 9E (B4 . B3/256) AR:91.54Ah - 100 9E (B6 . B5/256) #Ah: 0.0Ah #kWh: 0.00kWh EVC: 3.7V kWhR: 33.71kWh - 100 9F (B8 . B7/256) RR: 123 miles (0x7B 0x00 tesla-style LSB-first, 2 byte hex) - maybe just from 100 80 (standard message) dRMS: 52A (0x34 single byte hex) - 100 A0 (B4-MSB B3-LSB) dAI: 560mO (0x30 0x02 tesla-style LSB-first, 2 byte hex) - 100 A0 (B6-MSB B5-LSB) dWhM: 273Wh/mile (0x11 0x01 tesla-style LSB-first, 2 byte hex) - 100 A0 (B8-MSB B5-LSB) I did a search for '100 9E' in all my old logs, and find only one other: anon1_charge_heating049.txt: 0.0 100 9E 3F A1 9C 40 52 3F 42 ->VDS (message to VDS 9E) Not exactly surprising, as presumably that diagnostic screen would have had to be open, while the can log was being captured. Very rare. That is a charging log provided by one the the users here. I've labelled it anonymous, because I'm not sure if he publicised the data. Putting the same decode logic in, would give us for him: SOC LIM: 63% SOC MIN: 63% SOC MAX: 66% CAC: 156..63Ah AR: 82.24Ah I did a search for '9C FD' through the rest of my logs (including a large 20 minute one), and is did't show up anywhere apart from '100 9E'. So, my conclusion is that I'm pretty sure this is the CAC value, as well as a bunch of other techy metrics and the last six consumption history records. Nasty is that we have to request it (with a 102 06 D0 07 00 00 00 00 40). We could presumably stop the request (with a 102 06 10 …), but it times out after a while anyway. I think what I'll do is add that to the code for charge completion in vehicle_teslaroadster, and add a decoder to pick the CAC up off the bus and report it back. That way, we'll check the CAC every time a charge completes. If any other vehicles have a useful indication of overall battery health, they can use the same value. Regards, Mark. P.S. What is CAC? It is the "Calculated Amp-hour Capacity" and supposedly a very good indication of the capacity of the vehicle's battery.Tesla Roadster owners are using it to track long-term degradation of their batteries, and Tom Saxton will be very happy with me if I can get this back to him from a reasonable number of Tesla Roadsters. It will be my thank you to him for his work on charge completion time estimation, and definitely worth a few minutes CAN-bus logging in the car (but not so sure about the hours staring through those logs with a decimal-hex calculator :-)

2 4

Got pebbles
by Mark Webb-Johnson 12 Apr '13

12 Apr '13

Wrist notifications.

3 6

Sorry for lack of replies
by Mark Webb-Johnson 01 Apr '13

01 Apr '13

Sorry for the lack of replies to mailing list questions to me. I've been sick (flu, nothing serious), and am still getting over it. Hopefully I'll get to the eMails in the next few days. Regards, Mark

2 2

Quick update on Tazzari CAN Logs
by Patrick Kapsch 14 Mar '13

14 Mar '13

Hi guys, I just wanted to give you a quick update on my reverse engineering on the Tazzari Zero CAN-Bus. I've put together the Y-Cable-Adapter to attach the service-console as well as the USB-Interface to the Bus (see picture attached). As my dealer needs to get back his tools I borrowed, I wasn't really able to dive deeply into the messages, but I found the SOC and a charge-status that indicates whether or not the car charges. I will hopefully be able to write down all values that are provided by next week. LevAhR This is the state of charge in percentage Request: 0x78A 75 21 F9 EF Response: 0x775 0A A1 F9 EF 00 00 03 E8 Value 100.0% 03 E8 represent 1000 = 100.0 % SOC ------------------------------------------------------------- Charge Status Values to determine whether the car charges or not. Request: 0x78A 75 21 F6 E0 Response: 0x775 0A A1 F6 E0 00 00 00 63 Value "reset" (not charging) 0x775 0A A1 F6 E0 00 00 00 00 Value "SUV" (charging) Note: there are more than these two values while the charging comes to an end. I'll know them soon. But for now !=reset should do the job for charging true. I'm still searching for a way to tell if the car is parked or not. As far as I know by now there is nothing on the Bus that indicates this. Is a GPS-Based determination generally possible? The OVMS would have to check the coordinates periodically and compare them. A charging process indicates a parked car as well, and could turn of the GPS comparison. Regards, Patrick Kapsch

2 18

Tesla Roadster VDS Alerts
by Mark Webb-Johnson 09 Mar '13

09 Mar '13

I also went looking for a way of determining when a USB log transfer had completed, in my Tesla Roadster today. This has been asked for some time ago, with a view of reminding the user to download their logs from the car before they get rotated. Along the way, I seem to have found the VDS alert mechanism. Apologies for the blurry-cam image, but this is what it looks like when you download log files to USB stick on the Tesla Roadster: The interesting parts are the ID and Data fields. The ID identifies the screen type (so 25 is "Memory stick transfer in progress") and Data is id-specific. For ID 25, it is the percentage complete (so counting up from 0x00 to 0x64). Looking at my captured logs for this, I find something sticking out: 20.3270 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 27.0199 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 34.0614 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 40.7682 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 47.4682 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 54.7250 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 61.4526 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) 61.7035 100 93 15 19 00 00 00 00 00 ->VDS (message to VDS 93) 68.1515 100 93 15 19 00 01 00 00 00 ->VDS (message to VDS 93) 74.8449 100 93 15 19 00 03 00 00 00 ->VDS (message to VDS 93) 81.5926 100 93 15 19 00 05 00 00 00 ->VDS (message to VDS 93) 88.3173 100 93 15 19 00 06 00 00 00 ->VDS (message to VDS 93) 95.0345 100 93 15 19 00 08 00 00 00 ->VDS (message to VDS 93) 101.7832 100 93 15 19 00 0A 00 00 00 ->VDS (message to VDS 93) 108.5329 100 93 15 19 00 0B 00 00 00 ->VDS (message to VDS 93) 115.2333 100 93 15 19 00 0D 00 00 00 ->VDS (message to VDS 93) 121.9544 100 93 15 19 00 0E 00 00 00 ->VDS (message to VDS 93) 128.6547 100 93 15 19 00 10 00 00 00 ->VDS (message to VDS 93) 135.3657 100 93 15 19 00 11 00 00 00 ->VDS (message to VDS 93) 142.0550 100 93 15 19 00 13 00 00 00 ->VDS (message to VDS 93) 148.7466 100 93 15 19 00 14 00 00 00 ->VDS (message to VDS 93) 155.4689 100 93 15 19 00 16 00 00 00 ->VDS (message to VDS 93) 162.1574 100 93 15 19 00 17 00 00 00 ->VDS (message to VDS 93) 168.8772 100 93 15 19 00 19 00 00 00 ->VDS (message to VDS 93) 175.5805 100 93 15 19 00 1A 00 00 00 ->VDS (message to VDS 93) 182.3072 100 93 15 19 00 1C 00 00 00 ->VDS (message to VDS 93) 189.0204 100 93 15 19 00 1D 00 00 00 ->VDS (message to VDS 93) 195.7380 100 93 15 19 00 1F 00 00 00 ->VDS (message to VDS 93) 202.4180 100 93 15 19 00 20 00 00 00 ->VDS (message to VDS 93) 209.1086 100 93 15 19 00 21 00 00 00 ->VDS (message to VDS 93) 215.8086 100 93 15 19 00 23 00 00 00 ->VDS (message to VDS 93) 222.5388 100 93 15 19 00 24 00 00 00 ->VDS (message to VDS 93) 229.2495 100 93 15 19 00 25 00 00 00 ->VDS (message to VDS 93) 235.9896 100 93 15 19 00 27 00 00 00 ->VDS (message to VDS 93) 242.7136 100 93 15 19 00 28 00 00 00 ->VDS (message to VDS 93) 249.4103 100 93 15 19 00 29 00 00 00 ->VDS (message to VDS 93) 256.1020 100 93 15 19 00 2A 00 00 00 ->VDS (message to VDS 93) 262.7812 100 93 15 19 00 2C 00 00 00 ->VDS (message to VDS 93) 269.4841 100 93 15 19 00 2D 00 00 00 ->VDS (message to VDS 93) 276.2004 100 93 15 19 00 2E 00 00 00 ->VDS (message to VDS 93) 282.9480 100 93 15 19 00 30 00 00 00 ->VDS (message to VDS 93) 289.7051 100 93 15 19 00 31 00 00 00 ->VDS (message to VDS 93) 296.3843 100 93 15 19 00 32 00 00 00 ->VDS (message to VDS 93) 303.1348 100 93 15 19 00 34 00 00 00 ->VDS (message to VDS 93) 309.8240 100 93 15 19 00 35 00 00 00 ->VDS (message to VDS 93) 316.5296 100 93 15 19 00 36 00 00 00 ->VDS (message to VDS 93) 323.2851 100 93 15 19 00 37 00 00 00 ->VDS (message to VDS 93) 330.0081 100 93 15 19 00 38 00 00 00 ->VDS (message to VDS 93) 336.7280 100 93 15 19 00 3A 00 00 00 ->VDS (message to VDS 93) 343.4655 100 93 15 19 00 3B 00 00 00 ->VDS (message to VDS 93) 350.1895 100 93 15 19 00 3C 00 00 00 ->VDS (message to VDS 93) 356.8991 100 93 15 19 00 3D 00 00 00 ->VDS (message to VDS 93) 363.6032 100 93 15 19 00 3E 00 00 00 ->VDS (message to VDS 93) 370.3090 100 93 15 19 00 3F 00 00 00 ->VDS (message to VDS 93) 377.0695 100 93 15 19 00 40 00 00 00 ->VDS (message to VDS 93) 383.8307 100 93 15 19 00 41 00 00 00 ->VDS (message to VDS 93) 390.5810 100 93 15 19 00 42 00 00 00 ->VDS (message to VDS 93) 397.2783 100 93 15 19 00 43 00 00 00 ->VDS (message to VDS 93) 404.0252 100 93 15 19 00 45 00 00 00 ->VDS (message to VDS 93) 410.7490 100 93 15 19 00 46 00 00 00 ->VDS (message to VDS 93) 417.4515 100 93 15 19 00 47 00 00 00 ->VDS (message to VDS 93) 424.1598 100 93 15 19 00 48 00 00 00 ->VDS (message to VDS 93) 430.8664 100 93 15 19 00 49 00 00 00 ->VDS (message to VDS 93) 437.5613 100 93 15 19 00 4A 00 00 00 ->VDS (message to VDS 93) 444.3118 100 93 15 19 00 4B 00 00 00 ->VDS (message to VDS 93) 451.0231 100 93 15 19 00 4D 00 00 00 ->VDS (message to VDS 93) 457.7436 100 93 15 19 00 4E 00 00 00 ->VDS (message to VDS 93) 464.4456 100 93 15 19 00 4F 00 00 00 ->VDS (message to VDS 93) 471.1450 100 93 15 19 00 50 00 00 00 ->VDS (message to VDS 93) 477.8440 100 93 15 19 00 51 00 00 00 ->VDS (message to VDS 93) 484.5432 100 93 15 19 00 52 00 00 00 ->VDS (message to VDS 93) 491.2797 100 93 15 19 00 53 00 00 00 ->VDS (message to VDS 93) 497.9838 100 93 15 19 00 54 00 00 00 ->VDS (message to VDS 93) 504.7310 100 93 15 19 00 55 00 00 00 ->VDS (message to VDS 93) 511.4651 100 93 15 19 00 57 00 00 00 ->VDS (message to VDS 93) 518.1755 100 93 15 19 00 58 00 00 00 ->VDS (message to VDS 93) 524.9232 100 93 15 19 00 58 00 00 00 ->VDS (message to VDS 93) 531.6609 100 93 15 19 00 59 00 00 00 ->VDS (message to VDS 93) 538.3964 100 93 15 19 00 5A 00 00 00 ->VDS (message to VDS 93) 545.1293 100 93 15 19 00 5B 00 00 00 ->VDS (message to VDS 93) 551.8466 100 93 15 19 00 5D 00 00 00 ->VDS (message to VDS 93) 558.5722 100 93 15 19 00 5E 00 00 00 ->VDS (message to VDS 93) 565.2908 100 93 15 19 00 5F 00 00 00 ->VDS (message to VDS 93) 572.0311 100 93 15 19 00 60 00 00 00 ->VDS (message to VDS 93) 578.7234 100 93 15 19 00 61 00 00 00 ->VDS (message to VDS 93) 585.4489 100 93 15 19 00 62 00 00 00 ->VDS (message to VDS 93) 592.1719 100 93 15 19 00 63 00 00 00 ->VDS (message to VDS 93) 599.1091 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 605.8596 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 612.5599 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 619.2644 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 626.0780 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 632.7609 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 636.6933 100 93 14 19 00 64 00 00 00 ->VDS (message to VDS 93) 639.7882 100 93 00 FF FF 00 00 00 00 ->VDS (message to VDS 93) I found that by looking for the ID 25. Didn't find it, so tried 25 (decimal) = 0x19 (hex). A decode of that would be: 612.5599 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) ID: 100 B1=93 VDS alert notification B2 is some indication of whether this is 'opening' or 'closing' B3(LSB),B4(MSB) is ID B5(LSB),B6,B7,B8(MSB) is data So, I'm happy. I can look for "100 93 15 19 00 64 00 00 00" as an indication that someone did a log transfer and it got to 100%. Now, all I need is to work-out how long until the logs rotate? Tom/Whoever: do you have anything good for that? I believe it is drive time based, which may be tricky? Another, slightly concerning thing, is I don't know who transferred the logs. If it went to the service dept, they routinely pull the logs, and that would show up in the same way. Hmmm. Anyway, better than nothing. But, what was interesting, is I then wondered where else '100 93' appears (in particular without the idle condition '100 93 00 FF FF'). Here's what I found: $ fgrep -r '100 93' *|grep -v '93 00 FF FF' 20120218.charge/20120218.charge.breakerstop.txt: 73.1820 100 93 01 BA 03 00 00 20 00 ->VDS (message to VDS 93) 20120218.charge/20120218.charge.breakerstop.txt: 76.2779 100 93 00 BA 03 00 00 20 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 61.7035 100 93 15 19 00 00 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 68.1515 100 93 15 19 00 01 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 74.8449 100 93 15 19 00 03 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 81.5926 100 93 15 19 00 05 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 88.3173 100 93 15 19 00 06 00 00 00 ->VDS (message to VDS 93) … 20130303-vehiclelogtousb/vehiclelogs.txt: 619.2644 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 626.0780 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 632.7609 100 93 15 19 00 64 00 00 00 ->VDS (message to VDS 93) 20130303-vehiclelogtousb/vehiclelogs.txt: 636.6933 100 93 14 19 00 64 00 00 00 ->VDS (message to VDS 93) charge.20111108.txt: 1.2849 100 93 05 8D 04 20 00 00 00 ->VDS (message to VDS 93) charge.20111108.txt: 8.0259 100 93 05 8D 04 20 00 00 00 ->VDS (message to VDS 93) charge.20111108.txt: 13.1271 100 93 04 8D 04 20 00 00 00 ->VDS (message to VDS 93) charge.20111108.txt: 1242.8707 100 93 05 A6 03 02 00 00 00 ->VDS (message to VDS 93) charge.20111108.txt: 1244.8822 100 93 04 A6 03 02 00 00 00 ->VDS (message to VDS 93) trip.20111108.txt: 2.9815 100 93 05 8D 04 20 00 00 00 ->VDS (message to VDS 93) trip.20111108.txt: 9.7319 100 93 05 8D 04 20 00 00 00 ->VDS (message to VDS 93) trip.20111108.txt: 10.0843 100 93 04 8D 04 20 00 00 00 ->VDS (message to VDS 93) A few of those stand out like sore thumbs. 20120218.charge.breakerstop.txt Note in the log file there is: 71.3999 NOTE A second or two before breaker stop 73.1820 100 93 01 BA 03 00 00 20 00 ->VDS (message to VDS 93) Conclusion: ID 0x03BA data 0x00002000 is 'breaker tripped'. Or lost line sync, or whatever the message is (I forget). 20130303-vehiclelogtousb/vehiclelogs.txt This is my vehicle log dump to USB. ID 0x0019, data is percentage complete. charge.20111108.txt No notes on this. It appears to be a log testing various charging scenarios. The ID was 0x048D and data 0x00000020. Later on we get another ID 0x03A6 and data 0x00000002. trip.20111108.txt No notes. Just a drive. The ID was 0x048D and data 0x00000020. My conclusion is that '100 93' is an instruction to the VDS to tell it to display an error screen to the user. The textual message is derived from the error code (probably a lookup table in the VDS). I am not sure how these messages are 'cleared'. You can tap-to-dismiss on the VDS, which removes the alert but leaves a "(!)" on the VDS to show the alert is still a problem. That "(!)" goes away when the cause of the alert goes away. Somehow this is encoded in that B2. We could reverse the textual messages from ID by spoofing the message and seeing what the VDS displays,, but that would mean sending 65,535 errors to my VDS and I'm not comfortable doing that :-) I did find a partial listing: http://www.teslamotorsclub.com/showwiki.php?title=Roadster (reproduced here for historical purposes) Roadster VDS Messages A list of the VDS messages which can appear and if possible, some advice to the owner who sees them. The VDS can operate in Standard or Debug mode. You enter Debug mode either by tapping the VDS six times and entering a special code, or by letting MPT get in your car. ID Text under normal circumstances Debug text (not normally displayed) Notes / Suggestions 25 Memory Stick transfer in progress. ... Car is downloading logs to USB memory stick. 269 BSM: Negative contactor/economizer stuck low 287 Power train Problem Service Required 409 TPMS: Hardware Error Tire pressure cannot be monitored reliably. 604 ESS: Low State of charge: power limiting in effect You need to recharge 936 Charging Problem 937 Charge Problem Extension Cord Detected 954 Line Voltage Lost Sync DMC FW: Line Voltage Lost Sync or UnderFrequency Fault Bad power; try lowering the current and restarting 974 DMC FW: Pole Current Error Fault 981 DMC FW: Bad State Transition Fault Dog tripped over charging cable. Discuss. 960 DMC FW: VBrickMax versus VBattery Error fault You don't want to know. 1092 Do not plug in charge cable while driving Key left in ignition while trying to plug in? 1144 Powertrain Problem Service Required Call your Tesla Shop! 1146 DMC Motor Fan Problem Low fan speed. Only appears in debug mode? [1]. 1170 Tow Mode is not available while car is on ? External Charger Problem ? UMC's red fault light blinking. Unplugged car & UMC, then replugged and all OK. 428 12V Battery Service Required ? Turned out battery fuse was missing. 1103 ABS & Traction Control Problems. Service Required. ? Pulling out ignition key and waiting until car shutdown (15 minutes) cleared it. Tesla couldn't find issue. [1] I only ever saw this message in debug mode, and it was coming up a lot (several times per hour of driving). It completely stopped when I left debug mode. Not sure if this is coincidence. and 954 (0x083A) and 25 (0x0019) match two of the ones in my logs. Still some work to do (in particular to determine how the message is cleared/dismissed). But, how cool would it be to have these screens pop-up in the Apps as well? Sending them back as historical data, to record the event time, would also be helpful. Regards, Mark.

2 2

Re: [Ovmsdev] Re: Ampera remote start/stop function
by Richard G Jones 03 Mar '13

03 Mar '13

Regarding the failure of key fob remote start as discussed in the logs I sent earlier, I realize now that it only works if you press lock shortly before remote start. I had locked the doors before the test but in my haste forgot to retry locking. Was rushing before an appointment have not tried the keyfob remote start on the volt before. Confirmed it works now. I can get a correct keyfob remote start log later. Btw if keyfob remote start works why not use this in ovms?. Why the need for onstar logs? Presumably European amperas have keyfob remote start. Getting onstar logs is interesting of course just wondering what I'm missing re remote start. Sent from my phablet, scuse the typosDavid Peilow <david(a)peilow.com> wrote:Hi, Have a look at the last post in this thread... http://gm-volt.com/forum/showthread.php?29073-How-to-enable-quot-OnStar-quo… SWCAN? David

2 1

Fwd: Forward of moderated message
by Mark Webb-Johnson 03 Mar '13

03 Mar '13

Richard has uploaded some CAN bus captures. They were too big for the list (8MB), so I put them in dropbox. The links to the six captures are here: https://dl.dropbox.com/s/8agr2r2z92d1rgh/Bus%20Traffic%203-03-2013%207-53-4… https://dl.dropbox.com/s/j1yudtxdkslw4xe/Bus%20Traffic%203-03-2013%207-56-0… https://dl.dropbox.com/s/9coy9q2owcbnfcz/Bus%20Traffic%203-03-2013%208-03-0… https://dl.dropbox.com/s/otawinvmyx5h7ge/Bus%20Traffic%203-03-2013%208-04-5… https://dl.dropbox.com/s/qb5x66mwmcrwb9i/Bus%20Traffic%203-03-2013%208-11-4… https://dl.dropbox.com/s/esaxvnln6uxaywg/Bus%20Traffic%203-03-2013%208-16-0… Regards, Mark. > From: rgjones(a)sbcglobal.net > Subject: Re: [Ovmsdev] Ampera remote start/stop function > Date: 4 March, 2013 12:46:30 AM GMT+08:00 > To: OVMS Developers <ovmsdev(a)lists.teslaclub.hk> > Reply-To: rgjones(a)sbcglobal.net > > > Hello Folks, > I finally have some new logs for onstar remote start using a loaner vehicle spy setup. > This appears to support full speed but I do see some errors. > I dont have much time right now to evaluate, so getting the notes and data out there. > Regards, > Richard > > 3/3/13 volt > > Bus Traffic 3-03-2013 7-53-42 am > keyfob lock > > Bus Traffic 3-03-2013 7-56-08 am > KEYFOB UNLOCK > > > Bus Traffic 3-03-2013 8-03-02 am > onstar refresh > 15s before can activity > another 15s aro before app updates > app dashboard tab; > Volt at 7:59 AM 3/3/13 > Battery full EV range 36 miles Total RAnge 138 miles > 120V (indicating plugged into 120V) immediate (charge) Fully Charged > lifetime 55 mpg (we do lots of trips to LA!) 1475 ev miles 4775 ODO > > > Bus Traffic 3-03-2013 8-04-57 am > remote start > doors locked > could not start your vehicle - does not work when key is in the vehicle > > > Bus Traffic 3-03-2013 8-11-46 am > moved away from car with fob. > 807 onstar app remote start > car engine running even tho plugged in! > 808 keyfob unlock > 809 driver door open > keyfob lock > 810 onstar cancel remote start > keyfob unlock > driver door open > driver door closed > > > Bus Traffic 3-03-2013 8-16-05 am > driver door open/close, keyfob lock > keyfob remote start - nothing seemed to happen. did this three times > then onstar remote start -that worked > then onstat remote start cancel - worked > keyfob unlock > driver door open/close > car dash started by itself, then went out by itself > > > > > --- On Sun, 2/24/13, Mark Webb-Johnson <mark(a)webb-johnson.net> wrote: > > From: Mark Webb-Johnson <mark(a)webb-johnson.net> > Subject: Re: [Ovmsdev] Ampera remote start/stop function > To: "OVMS Developers" <ovmsdev(a)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(a)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(a)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(a)webb-johnson.net> wrote: >>> >>> From: Mark Webb-Johnson <mark(a)webb-johnson.net> >>> Subject: Re: [Ovmsdev] Ampera remote start/stop function >>> To: "OVMS Developers" <ovmsdev(a)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-viewin… >>> >>> 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(a)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(a)lists.teslaclub.hk >>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> >>> >>> -----Inline Attachment Follows----- >>> >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev >>> _______________________________________________ >>> OvmsDev mailing list >>> OvmsDev(a)lists.teslaclub.hk >>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

1 0