Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Odd charging behavior (seen in logs)

This site may earn commission on affiliate links.
I contacted Clipper Creek this past week and am in the process of gathering some additional information to share with them about the issue. Based on what has been reported to them, the issue is restricted to the Roadster. The technician (correctly) pointed out that the Roadster EVSE charging protocol pre-dates the J1772 standard and is therefore not 100% compliant with the 2010 standard.

They have been responsive and genuinely interested in assisting me with my questions. If the problem is as suspected, the CCID test at the end of the cycle causes the Roadster to start a new session, fixing it could cause issues for other folks with J1772 compliant vehicles. Charging the Model S with HCS-40 works fine for me.

Did you hear of any follow up with Cipper Creek?
 
Clipper Creek is still working on it. We know of three cars that experience the issue - hjr's, mine, and (yea!) Jason who is the head of Clipper Creek. So, they can reproduce the issue at will, and it is believed to be specific to that model of charger.

About a week ago I got an email from them noting that the symptom did not appear to occur with Tesla's J1772 adapter cable (vs hcsharp's CAN-JR adapter), which is really interesting. No information yet on what is different between the two, or whether that result has been replicated on other cars or other adapter cables. They said it may have been a single occurrence. BUT if anyone else has one of the original Tesla J1772 adapter cables and an HCS-40 charger (or can find a way to put the two together), PLEASE let us know. You don't even have to do a full charge. Just hit the "stop" button on the car's VDS while charging, and it should stop. If it starts up again on its own in a few seconds, you've replicated the issue.
 
About a week ago I got an email from them noting that the symptom did not appear to occur with Tesla's J1772 adapter cable (vs hcsharp's CAN-JR adapter), which is really interesting.
I thought that both the Tesla adapter cable and the CAN-JR are passive devices; that is, no components other than wires and connectors. If that is correct, then the only difference between the two would be small variations in resistance of the connections through the device. That seems unlikely to be the explanation.
 
Did you hear of any follow up with Cipper Creek?
ClipperCreek figured out what was causing the Roadster to cycle when a charging session ends. I was able to duplicate the behavior here by changing the firmware on one of my own chargers to do the same thing theirs does. It's easy to fix, except that it's not. If they fixed it they would have to re-test it on 20 other EVs that might be using those EVSEs. You can understand their reluctance.

OTOH there is strong evidence that the firmware fix by CC would work fine with all the other vehicles because their other EVSE lines perform the CCID test in a manner that is more Roadster friendly and have no issues with other cars.

CC does not think it has anything to do with the adapter They can't rule it out without a lot of testing which they don't plan to do. slcasner is exactly right about both adapters being passive devices and the only differences might be due to subtle variations in impedance. This might explain why some people get the infamous extension cord error when using Tesla's J1772 adapter but it's not related to this issue at hand. The same is NOT true with the CAN SR but that's irrelevant.
 
Clipper Creek accepted a return of the HCS-40 for a full refund upon our having convinced them of the compatibility issue. They have been extremely cooperative in investigating this right up to the point of helping us resolve the problem, as noted above. I cannot blame them totally, but it seems that since many of us bought the original CC product sold by Tesla (HPWC) and now we have expressed interest in buying their product, that they might have an incentive to make a fix.

Since we Roadster owners no longer have a direct line to Tesla I wonder if maybe CC has a better relationship than we original Roadster owners - as it seems a very simple code fix for Tesla to implement. All they need to do is allow the charger to test itself AFTER the charging cycle as well as at the start.....

Do any of you guys have the juice at tesla headquarters to push for this... there has not been any firmware upgrade in 4 years! maybe there is nobody left at tesla who knows about Roadster (or cares?).
 
Clipper Creek accepted a return of the HCS-40 for a full refund upon our having convinced them of the compatibility issue. They have been extremely cooperative in investigating this right up to the point of helping us resolve the problem, as noted above. I cannot blame them totally, but it seems that since many of us bought the original CC product sold by Tesla (HPWC) and now we have expressed interest in buying their product, that they might have an incentive to make a fix.

Since we Roadster owners no longer have a direct line to Tesla I wonder if maybe CC has a better relationship than we original Roadster owners - as it seems a very simple code fix for Tesla to implement. All they need to do is allow the charger to test itself AFTER the charging cycle as well as at the start.....

Do any of you guys have the juice at tesla headquarters to push for this... there has not been any firmware upgrade in 4 years! maybe there is nobody left at tesla who knows about Roadster (or cares?).
Actually there was a Roadster firmware update about 3 months ago. I don't have it yet so not sure if it addressed this issue but I doubt it. It would be a lot easier for Clipper Creek to fix it in their EVSEs. Having said that, changing the Roadster firmware would make the Roadster more in compliance with J1772 and would make it work better on existing CC chargers, not just the units they build or reprogram going forward.
 
Actually there was a Roadster firmware update about 3 months ago. I don't have it yet so not sure if it addressed this issue but I doubt it. It would be a lot easier for Clipper Creek to fix it in their EVSEs. Having said that, changing the Roadster firmware would make the Roadster more in compliance with J1772 and would make it work better on existing CC chargers, not just the units they build or reprogram going forward.

I have the 3.0 ESS upgrade so I guessing I have the latest firmware, and I'm still seeing the issue.
 
How about if everyone claiming to have, or thinking that they have, the "latest firmware" actually specify which version they have (and what their Roadster model is)? That's @spaceballs and @CSPHD, by my reckoning. That way, we can all be sure we agree on what those latest firmware versions are.

For reference I've added my current firmware version to my signature, viz., FW:3.7.1 (53)
 
I emailed Tesla, giving them my VIN, and details of the firmware update now available for roadsters in the USA. I asked when/if the firmware would be available here in Hong Kong, and got this reply:

Thank you for contacting Tesla with your enquiry of adding hardware for Roadster.

Good grief. So, I tried again, pointing out that this is not a hardware but a software update, and got this reply:

We will push it to your car once the new firmware is available in HK.

Now planning to join Wonko the Sane in his Asylum on that Californian beach.
 
I'm running vehicle-firmware-5.0.3.42
5? I thought the 1.5's were 3.stuff and the 2.x's were 4.stuff.

Mine says 4.0.56 34, according to the logs. Are we referring to the same set of bits?

greg@server:~/projects/tesla/VehicleLogs/5YJRE1A16A1000834> wine ~/bin/VMSParser.exe -p 201611161603.tar | grep -i firmware
rt t2 t3 cb firmware count bytes tag notes
01 FF 83 29 4.0.56 34 71 3053 VINF Vehicle Info: VIN, firmware version
 
5? I thought the 1.5's were 3.stuff and the 2.x's were 4.stuff.

Mine says 4.0.56 34, according to the logs. Are we referring to the same set of bits?

greg@server:~/projects/tesla/VehicleLogs/5YJRE1A16A1000834> wine ~/bin/VMSParser.exe -p 201611161603.tar | grep -i firmware
rt t2 t3 cb firmware count bytes tag notes
01 FF 83 29 4.0.56 34 71 3053 VINF Vehicle Info: VIN, firmware version

firmware tag notes
4.6.5 23 VINF Vehicle Info: VIN, firmware version
4.6.5 23 XX05
5.0.3 42 DAY Daily Status (stored in permanent section)
4.6.5 23 DAY Daily Status (stored in permanent section)
5.0.3 42 DAY Daily Status (stored in permanent section)
 
Grepping for "firmware" just pulls the line for the vehicle information records from the summary table. A better way to look at your firmware version is to look at all of the vehicle information records, paying attention to the dates. For example:

VMSParser -p -r VINF example.tar

I'll bet you'll find the VINF record that has version 4.0.56 is very old, like late 2009.

The VINF records also appear in the transient section, at the beginning of every block, so that's another way to look at recent records.

VMSParser -r VINF example.tar
 
Grepping for "firmware" just pulls the line for the vehicle information records from the summary table. A better way to look at your firmware version is to look at all of the vehicle information records, paying attention to the dates. For example:

VMSParser -p -r VINF example.tar

I'll bet you'll find the VINF record that has version 4.0.56 is very old, like late 2009.

The VINF records also appear in the transient section, at the beginning of every block, so that's another way to look at recent records.

VMSParser -r VINF example.tar

Ah! That makes more sense... I'm on 4.6.8, which appears to have been installed at my first service in 2014.

12/19/2013 13:30:29 | 1387488629 | VINF | L 5YJRE1A16A1000834 '4.6.5 40'
02/11/2014 15:31:23 | 1392161483 | VINF | L 5YJRE1A16A1000834 '4.6.8 40'
...
03/28/2016 13:56:35 | 1459198595 | VINF | L 5YJRE1A16A1000834 '4.6.8 40'
 
A better way to look at your firmware version is to look at all of the vehicle information records, paying attention to the dates. For example:

VMSParser -p -r VINF example.tar

I'll bet you'll find the VINF record that has version 4.0.56 is very old, like late 2009.

The VINF records also appear in the transient section, at the beginning of every block, so that's another way to look at recent records.

VMSParser -r VINF example.tar
Tom, did you figure out why for my car the command "VMSParser -b example.tar" only showed firmware updates through 3.6.12 in 2014 whereas the commands you mentioned here correctly show the 3.7.1 update that came with the 3.0 battery upgrade?