Jack, Michael, and others: I've uploaded a bunch of CSV and TXT (roadster_can decoder) files for some charges and a drive today. I tried to capture all the bus events for various exit scenarios in a charge, and one complete drive. You can find them at: https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/master/vehicle... I'll summarise what I see here: 20120218.charge.slidestop The test here was to start a normal charge on the car, then slide the plug switch back to abort the charge. I also intended to record the three entry events of (a) opening the charge port door, (b) plugging in, and (c) sliding the switch forward to start the charge. The important messages are: 0 NOTE A Tesla Roadster 2.5 std model, charge with slide-to-stop charging 0.7411 100 88 00 AD 01 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 429mins) 0.7415 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 0.7418 100 95 04 07 64 57 02 0E 1E ->VDS Charger v1.5 (done) (conn-pwr-cable) (standard) 7.6619 100 96 68 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: closed) (pilot: true) (charging: false) (bits 68) 8.2501 NOTE Open Charge Port 8.6407 100 88 00 00 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 0mins) 8.6413 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 8.6417 100 95 0D 07 64 57 02 0E 00 ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard) 8.6268 100 96 6C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6C) 22.6644 NOTE Connect plug 34.0036 100 88 00 00 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 0mins) 34.0039 100 89 00 03 00 00 46 ->VDS Charger interface (speed 0mph) (vline 3V) (Iavailable 70A) 34.0042 100 95 0D 01 64 57 02 0E 00 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard) 34.0932 100 96 6C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6C) (start charging by sliding switch forward) 35.1030 100 96 7C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7C) 35.4141 100 88 00 00 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 0mins) 35.4144 100 89 00 CB 00 00 46 ->VDS Charger interface (speed 0mph) (vline 203V) (Iavailable 70A) 35.4147 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) ... 103.8708 100 88 0D 01 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 13A) (duration 1mins) 103.8713 100 89 00 DE 00 0F 46 ->VDS Charger interface (speed 0mph) (vline 222V) (Iavailable 70A) 103.8716 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 104.1169 100 96 7C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7C) (stop charging by sliding plug switch back) 104.2846 100 96 64 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: false) (charging: false) (bits 64) 104.5674 100 88 06 01 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 6A) (duration 1mins) 104.5677 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 104.5681 100 95 17 07 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (conn-pwr-cable) (standard) 0 NOTE VDS Display: Stop Charging: Connect power cable So, looks like: Opening the charge port is reflected in the Doors message (96) Connecting the plug shows up by appearance of data on the Charger interface message (95), and the conn-pwr-cable sub-state (0x07) going to (0x01). Sliding the switch forward to start the charge moved the charger state on message 95 to 'charging'. with the sub-state going to 0x05. Sliding the switch back to abort the charge moved the charger state on message 95 to 'stopped charge', with the sub-state going back to 0x07. Interesting the 'pilot' bit on message 96 goes true->false when we aborted the charge. 20120218.charge.vdsstop The test here was to start a normal charge on the car, then abort the charge by pressing STOP on the VDS. The important messages are: 3.6289 100 96 64 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: false) (charging: false) (bits 64) 3.8795 100 88 00 01 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 1mins) 3.8798 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 3.8801 100 95 17 07 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (conn-pwr-cable) (standard) 4.2215 NOTE Slide forward to start charging 4.9275 100 96 6C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6C) 5.2898 100 88 00 01 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 1mins) 5.2900 100 89 00 00 00 00 46 ->VDS Charger interface (speed 0mph) (vline 0V) (Iavailable 70A) 5.2904 100 95 17 01 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (??sub-state?? 1) (standard) 13.7412 100 96 7C 00 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7C) 14.4598 100 88 00 01 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 1mins) 14.4600 100 89 00 DF 00 00 46 ->VDS Charger interface (speed 0mph) (vline 223V) (Iavailable 70A) 14.4603 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 68.3520 100 96 7D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7D) 68.9127 100 88 0D 02 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 13A) (duration 2mins) 68.9129 100 89 00 DC 00 0F 46 ->VDS Charger interface (speed 0mph) (vline 220V) (Iavailable 70A) 68.9133 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 68.9206 102 05 03 00 00 00 00 00 00 VDS-> Start/stop charge (st/st 0) 69.0871 102 0A VDS-> (message from VDS 0A) 69.3529 100 96 6D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6D) 69.6230 100 88 05 02 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 5A) (duration 2mins) 69.6233 100 89 00 73 00 00 46 ->VDS Charger interface (speed 0mph) (vline 115V) (Iavailable 70A) 69.6237 100 95 15 03 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) So, looks like: We continued from the previous run, so the pilot bit started false. Resuming the charge, by sliding forward the plug switch, caused message 95 sub-state to go from conn-pwr-cable (0x07) to 0x01. The pilot went true at this point. Eight seconds later the charge started, and charging went true and message 95 sub-state went to 0x05. We abort the charge from the VDS. We see the STOP charge message on ID#102, followed by the wakeup message (which is what we do as well). Pretty quickly, we get back charging: false, but the pilot bit remains true. Charging mode goes to stopped-charging, with sub-state by-request (0x03). 20120218.charge.breakerstop The test here was to start a normal charge on the car, then abort the charge by tripping the breaker in front of the Tesla HPC. The important messages are: 1.8169 100 96 65 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: false) (charging: false) (bits 65) 1.8872 100 88 00 02 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 2mins) 1.8875 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 1.8878 100 95 15 07 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (conn-pwr-cable) (standard) 2.6613 NOTE Slide to start charging 3.1683 100 96 6D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6D) 3.3176 100 88 00 02 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 2mins) 3.3178 100 89 00 00 00 00 46 ->VDS Charger interface (speed 0mph) (vline 0V) (Iavailable 70A) 3.3184 100 95 15 01 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (??sub-state?? 1) (standard) 11.9370 100 96 7D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7D) 12.0077 100 88 00 02 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 0A) (duration 2mins) 12.0080 100 89 00 D5 00 00 46 ->VDS Charger interface (speed 0mph) (vline 213V) (Iavailable 70A) 12.0083 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) ... 70.6345 100 96 7D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7D) 71.1244 102 04 44 VDS-> (message from VDS 04) 71.3331 100 88 0D 03 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 13A) (duration 3mins) 71.3334 100 89 00 DC 00 0F 46 ->VDS Charger interface (speed 0mph) (vline 220V) (Iavailable 70A) 71.3338 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 71.3999 NOTE A second or two before breaker stop 72.6603 100 96 65 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: false) (charging: false) (bits 65) 72.7309 100 88 04 03 00 FF FF 0D ->VDS Charger settings (limit 13A) (current 4A) (duration 3mins) 72.7313 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 72.7317 100 95 17 07 64 57 02 0E 00 ->VDS Charger v1.5 (stopped-charging) (conn-pwr-cable) (standard) So, looks like: The pilot bit was false to start - I guess I had slid the plug switch back in order to be able to restart the charge. The usual startup of the charge, with pilot going true when we slide the plug switch forward. Breaking the charge circuit caused pilot to go false, charging to go false, and the charger mode to go to stopped-charging with conn-pwr-cable (0x07) as the sub-state. 20120218.charge.done The test here was to start a normal charge on the car, and allow it to run to completion. I also intended to record the three entry events of (a) opening the charge port door, (b) plugging in, and (c) sliding the switch forward to start the charge. The important messages are: 22.0793 100 96 65 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: false) (charging: false) (bits 65) 22.1600 100 88 00 03 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 3mins) 22.1603 100 89 00 FF FF 7F FF ->VDS Charger interface (speed 0mph) (vline 65535V) (Iavailable 255A) 22.1606 100 95 0D 07 64 57 02 0E 00 ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard) 22.5999 NOTE Slide to start charge 23.1314 100 96 6D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6D) 23.5430 102 04 44 VDS-> (message from VDS 04) 23.5993 100 88 00 03 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 3mins) 23.5996 100 89 00 00 00 00 46 ->VDS Charger interface (speed 0mph) (vline 0V) (Iavailable 70A) 23.5999 100 95 0D 01 64 57 02 0E 00 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard) 32.2599 100 96 7D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7D) 32.8601 100 88 00 03 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 3mins) 32.8604 100 89 00 DE 00 00 46 ->VDS Charger interface (speed 0mph) (vline 222V) (Iavailable 70A) 32.8607 100 95 01 05 64 57 02 0E 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 1008.9627 100 96 7C 08 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7C) 1009.3349 100 88 0E 13 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 14A) (duration 19mins) 1009.3352 100 89 00 D8 00 00 46 ->VDS Charger interface (speed 0mph) (vline 216V) (Iavailable 70A) 1009.3355 100 95 01 05 64 57 02 0E 02 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 1009.9722 100 96 6C 08 02 21 0C 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6C) 1010.0430 100 88 02 13 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 2A) (duration 19mins) 1010.0432 100 89 00 19 00 00 46 ->VDS Charger interface (speed 0mph) (vline 25V) (Iavailable 70A) 1010.0436 100 95 04 09 64 57 02 0E 02 ->VDS Charger v1.5 (done) (xxMin-2kWH) (standard) So, looks like: The usual startup stuff. This time, we don't seem to detected the plug being connected. The vline and Iavailable are still crazy. When the charge completes, message 95 goes to charge mode 'done' (0x04) and sub-state 0x09 Pilot bit stays true throughout. 20120218.charge.topoff The test here was to see what happens when we press TOPOFF on the VDS after a charge has completed. The important messages are: 5.7872 100 96 6D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 6D) 6.0977 100 88 00 13 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 19mins) 6.0980 100 89 00 00 00 00 46 ->VDS Charger interface (speed 0mph) (vline 0V) (Iavailable 70A) 6.0984 100 95 04 01 64 57 02 0E 02 ->VDS Charger v1.5 (done) (??sub-state?? 1) (standard) 8.0804 102 05 03 00 00 01 00 00 00 VDS-> Start/stop charge (st/st 1) 8.2079 100 88 00 13 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 19mins) 8.2082 100 89 00 00 00 00 46 ->VDS Charger interface (speed 0mph) (vline 0V) (Iavailable 70A) 8.2085 100 95 0D 0A 64 57 02 0E 02 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 10) (standard) 11.8674 100 96 7D 00 02 21 0C 00 00 ->VDS Doors (l-door: open) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 7D) 12.5279 100 88 00 13 00 FF FF 46 ->VDS Charger settings (limit 70A) (current 0A) (duration 19mins) 12.5281 100 89 00 DD 00 00 46 ->VDS Charger interface (speed 0mph) (vline 221V) (Iavailable 70A) 12.5285 100 95 01 05 64 57 02 0E 02 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) So, looks like: Nothing unusual. The top-off appears to be the same as a normal start/stop charge command. The message we would send to start the charge is 0x03 0x00 0x00 0x01 0x00 0x00 0x00, as this is what the VDS sends. Michael's "Heating" Logs The 0-49 log shows: 0.0 100 95 0D 07 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard) ... 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) The 100 log shows: 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 95 0F 0B 63 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) 0.0 100 95 0D 01 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard) 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) 0.0 100 96 3C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C) 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) Conclusions Slide-to-stop had final charge state 0x17 and pilot going true->false just before we got the stopped-charge indication from the charger. The sub-state said connect-power-cable. VDS stop had final charge state 0x15 and pilot remaining true when we get the stopped-charge indication. The sub-state said 'on request'. Breaker stop had final charge state 0x17 and pilot going true->false just before we got the stopped-charge indication from the charger. The sub-state said connect-power-cable. It looked indistinguishable from slide-to-stop. A normal charge completion was indicated by the charger state 'done' (0x04). A top-off is identical to a normal charge. I can't immediately see where the VDS is getting its information for its "line voltage lost sync" on the breaker trip charge. The charger messages between breaker-trip and slide-to-stop look identical. I can't even see any other can bus messages around the time that look different. We do seem to have identified some more sub-states on the charger message 95. For charge states, we now have: 0x01 charging 0x02 top off (although I'm not seeing this) 0x04 done 0x0d preparing to charge 0x0f heating 0x15 stopped charging (vds stop) 0x17 stopped charging (power disconnection) and, in general, 0x15-0x19 stopped charging For sub-states, we now have: 0x01 starting charge (power cable has been connected) 0x02 scheduled start 0x03 by request 0x05 charging 0x07 connect power cable 0x09 done 0x0b heating If we want to sms notify on slide-to-stop and breaker-trip, but not vds-stop, then it looks like the pilot bit being false when then charge stopped state message is received is a pretty good way of doing it. Regards, Mark. On 18 Feb, 2012, at 4:20 AM, Jack West wrote:
Mark and Michael, others,
I tested the following changes to can.c in my cold car:
case 0x95: . . if ((car_chargestate >= 0x0d) && (car_stopped)) //change test to include preparing. { //when heating fails state goes to preparing, not stopped car_stopped = 0; net_notify_status; } . . case 0x96: if (car_chargestate == 0x0f) can_databuffer[1] |= 0x10; //make heating state look like charging
I also added a heating case to net_msg_alert
I did this to test:
Open charge port, plug in car. App shows charge port open Slide pilot on SMS STAT = charging, heating APP = shows normal 'non charging' screen VDS = heating % complete (heating at 7amps/240V) Slide pilot off //simulate failure APP = standard, preparing (alert). //would be nice to see 'charging stopped' SMS = charging, preparing (alert) Slide pilot on APP = shows normal non charging screen. // would be nice to see 'charging, heating' SMS = no alerts SMS STAT = charging, heating
It seems this could be better. Would be nice if heating state showed up as charging on apps. I'm not sure what happens if I heat to 100% and begin charging because if I do that then I can't test the cold car state. I realize that heating is a state that will affect only a very few users but I'm certainly one of those and I'm willing to keep plugging away at it. Any suggestions will be appreciated, as always.
Jack
On Feb 15, 2012, at 11:45 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Temperature here would have to drop 25celcius or more for me to be able to test ;-) That said, I here we're going to have a cold snap this weekend - it will perhaps drop to +15celcius or lower...
Then again, I'm interested in seeing what is going to happen in a couple of months when we reach 35celcius ambient here. Is there a mysterious "Cooling" state?
Mark.
On 16 Feb 2012, at 4:35 PM, Jack West wrote:
Mark and Michael,
This didn't get the right results. It seems that the heating state does not error out into a stopped state. If you lose the pilot while heating, the car just goes back to preparing, so no alerts. Stopping heating 'by request' does get a 0x15 state so that part is OK. I messed with it quite a bit but can't seem to get the logic programmed right.
Seems like we want the app to read "charging" when we are heating and "charging stopped" if heating state fails. But not get any alerts when heating ends and charging commences normally. I also tried looking at the pilot B2b3 to check for failure. I'm doing my best but you guys seem to have quite the knack for knocking this stuff out. I am pretty good at catching salmon though :)
Best, Jack
On Feb 15, 2012, at 10:28 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Jack,
Sorry for late response.
Yes, that looks good. You could also optimise it with "can_databuffer[1] |= 0x10" (I've never tried that on PIC, but it should work).
Regards, Mark
On 15 Feb 2012, at 11:34 AM, Jack West wrote:
Mark and Michael,l,
I'm all for making things easy. Sounds like a good solution. Just to clarify:
can.c line #243
case 0x96: if ((car_chargestate = = 0x0d) || (car_chargestate = = 0x0f)) can_databuffer[1] = can_databuffer[1] | (0x10);
I'm pretty rusty at programming and only want to help, not make more work.
Jack
On Feb 14, 2012, at 6:05 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Would it be easier to 'fix' the issue by just setting bit4 high in can_databuffer[1] of 0x96 if the chargestate was 'preparing' or 'heating'?
It would make it easier for the Apps to handle.
Mark.
On 15 Feb 2012, at 10:51 AM, Jack West wrote:
> Michael and Mark, > > I'm glad you were able to test this out and confirm Michael. My car was too warm to test the heating cycle today. I'm proposing the following and will test it out tonight or in the morning (as soon as my car chills out). > > can.c > > Line #243 > Case 0x96: > if ((car_charging) && !((can_databuffer[1] & 0x10) || (car_chargestate == 0x0f))) > car_stopped = 1; > car_charging = ((can_databuffer [1] & 0x10) || (car_chargestate == 0x0f)); > > And > > Line #229 > case 0x95: > if (car_chargestate = = 0x0f) // heating state is treated as charging > car_charging = 1; > > Jack > > > > > > On Feb 14, 2012, at 3:43 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: > >> >> Bizarre. I guess they don't count it as 'charging' until current is going into the pack directly (as opposed to coming out of the wall). >> >> I converted your logs (thanks) to roadster_can.pl compatible format, and it all looks quite clean. There are some very strange message states (in particular, the percentage jumps all over the place), but I don't see any unexpected charging->notcharging->charging transitions. Charging is OFF for the whole of the 0-49 log, and only goes on after pre-heat in the 100 log. >> >> The 0-49 log shows: >> >> 0.0 100 95 0D 07 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard) >> ... >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> >> The 100 log shows: >> >> 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 63 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 0D 01 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) >> 0.0 100 96 3C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C) >> 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) >> >> [ side note - it seems the pilot does go false at some points in your logs ] >> >> Regards, Mark. >> >> On 14 Feb, 2012, at 7:01 PM, Michael Stegen wrote: >> >>> Mark, Jack, >>> >>> I can confirm that the charging bit is not set when pre-heating the battery. >>> It's only set when it goes from pre-heating to charging. >>> >>> Maybe we should just look at the State (0x95) instead of charging bit (0x96) and state. >>> >>> I have uploaded my logfiles fom when i did the test here: >>> http://www.stegen.com/pub/bat_heating.rar >>> >>> Inside the rar archive are two logfiles, one pre-heats till 49% then i press stop from the VDS. >>> The otherone pre-heats till 100%, and then the charging begins. >>> >>> Note that the "preparing to charge" state is also entered after the pre-heating ended and before the actual charging starts. >>> >>> -Michael >>> >>> >>> >>> >>> >>> >>> >>> Op 14-2-2012 4:01, Mark Webb-Johnson schreef: >>>> Urgh. >>>> >>>> I think we really need to get a good trace of what you are seeing. >>>> >>>> Is it possible for you to run the 1.2.0-rc3 code in the car, using 202.52.42.80 server, do a full charge (including pre-heat), then let me know UTC time it started? If possible, check up on it with an App during the charge (when an App is connected, the car reports in once every minute - otherwise only once every ten minutes). I have a full log running on the development server at the moment, and 1.2.0 code sends the detailed charging bytes as well as the summary status text. >>>> >>>> Regards, Mark. >>>> >>>> On 14 Feb 2012, at 2:22 AM, Jack West wrote: >>>> >>>>> Mark, >>>>> >>>>> One possibility that might explain what I saw: >>>>> >>>>> In heating substate the car does not turn on b4 of B2 in 0x96. Therefore logic does not see the car as charging when in the heating state so flags are not set, etc. >>>>> >>>>> I'll look into this in more detail tonight. >>>>> >>>>> Jack >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Stegen Electronics >>> Kwartslaan 95 >>> 3162 RD Rhoon >>> The Netherlands >>> >>> Tel: +31 10-5016960 >>> Skype: stegen.com >>> www.stegen.com >>> >>> _______________________________________________ >>> 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 >
On Feb 14, 2012, at 6:05 PM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
Would it be easier to 'fix' the issue by just setting bit4 high in can_databuffer[1] of 0x96 if the chargestate was 'preparing' or 'heating'?
It would make it easier for the Apps to handle.
Mark.
On 15 Feb 2012, at 10:51 AM, Jack West wrote:
> Michael and Mark, > > I'm glad you were able to test this out and confirm Michael. My car was too warm to test the heating cycle today. I'm proposing the following and will test it out tonight or in the morning (as soon as my car chills out). > > can.c > > Line #243 > Case 0x96: > if ((car_charging) && !((can_databuffer[1] & 0x10) || (car_chargestate == 0x0f))) > car_stopped = 1; > car_charging = ((can_databuffer [1] & 0x10) || (car_chargestate == 0x0f)); > > And > > Line #229 > case 0x95: > if (car_chargestate = = 0x0f) // heating state is treated as charging > car_charging = 1; > > Jack > > > > > > On Feb 14, 2012, at 3:43 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote: > >> >> Bizarre. I guess they don't count it as 'charging' until current is going into the pack directly (as opposed to coming out of the wall). >> >> I converted your logs (thanks) to roadster_can.pl compatible format, and it all looks quite clean. There are some very strange message states (in particular, the percentage jumps all over the place), but I don't see any unexpected charging->notcharging->charging transitions. Charging is OFF for the whole of the 0-49 log, and only goes on after pre-heat in the 100 log. >> >> The 0-49 log shows: >> >> 0.0 100 95 0D 07 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (conn-pwr-cable) (standard) >> ... >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 18 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> >> The 100 log shows: >> >> 0.0 100 95 15 03 64 A4 01 16 00 ->VDS Charger v1.5 (stopped-charging) (by-request) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 00 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 31 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 95 0F 0B 63 A4 01 16 00 ->VDS Charger v1.5 (??state?? 15) (??sub-state?? 11) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 0D 01 64 A4 01 16 00 ->VDS Charger v1.5 (preparing-to-charge) (??sub-state?? 1) (standard) >> 0.0 100 96 2C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: false) (bits 2C) >> 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) >> 0.0 100 96 3C 00 02 21 38 00 00 ->VDS Doors (l-door: closed) (r-door: closed) (chargeport: open) (pilot: true) (charging: true) (bits 3C) >> 0.0 100 95 01 05 64 A4 01 16 00 ->VDS Charger v1.5 (charging) (??sub-state?? 5) (standard) >> >> [ side note - it seems the pilot does go false at some points in your logs ] >> >> Regards, Mark. >> >> On 14 Feb, 2012, at 7:01 PM, Michael Stegen wrote: >> >>> Mark, Jack, >>> >>> I can confirm that the charging bit is not set when pre-heating the battery. >>> It's only set when it goes from pre-heating to charging. >>> >>> Maybe we should just look at the State (0x95) instead of charging bit (0x96) and state. >>> >>> I have uploaded my logfiles fom when i did the test here: >>> http://www.stegen.com/pub/bat_heating.rar >>> >>> Inside the rar archive are two logfiles, one pre-heats till 49% then i press stop from the VDS. >>> The otherone pre-heats till 100%, and then the charging begins. >>> >>> Note that the "preparing to charge" state is also entered after the pre-heating ended and before the actual charging starts. >>> >>> -Michael >>> >>> >>> >>> >>> >>> >>> >>> Op 14-2-2012 4:01, Mark Webb-Johnson schreef: >>>> Urgh. >>>> >>>> I think we really need to get a good trace of what you are seeing. >>>> >>>> Is it possible for you to run the 1.2.0-rc3 code in the car, using 202.52.42.80 server, do a full charge (including pre-heat), then let me know UTC time it started? If possible, check up on it with an App during the charge (when an App is connected, the car reports in once every minute - otherwise only once every ten minutes). I have a full log running on the development server at the moment, and 1.2.0 code sends the detailed charging bytes as well as the summary status text. >>>> >>>> Regards, Mark. >>>> >>>> On 14 Feb 2012, at 2:22 AM, Jack West wrote: >>>> >>>>> Mark, >>>>> >>>>> One possibility that might explain what I saw: >>>>> >>>>> In heating substate the car does not turn on b4 of B2 in 0x96. Therefore logic does not see the car as charging when in the heating state so flags are not set, etc. >>>>> >>>>> I'll look into this in more detail tonight. >>>>> >>>>> Jack >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> >>> -- >>> Stegen Electronics >>> Kwartslaan 95 >>> 3162 RD Rhoon >>> The Netherlands >>> >>> Tel: +31 10-5016960 >>> Skype: stegen.com >>> www.stegen.com >>> >>> _______________________________________________ >>> 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