-
Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
LuckyLuke
Model S P90DL
Found it.....
Pinout seems to be :
1 : ? (seems to be a CAN_H)
4 : Chassis GND
5 : Signal GND
6 : CAN_H
7 : K line ? Gives 0V with voltmeter, should be 12V with the K line pull up
9 : ? (seems to be a CAN_L)
14 : CAN_L
16 : +12V
Will try to see if we can get CAN messages on this OBD connector, but it will be another subject...
Pinout seems to be :
1 : ? (seems to be a CAN_H)
4 : Chassis GND
5 : Signal GND
6 : CAN_H
7 : K line ? Gives 0V with voltmeter, should be 12V with the K line pull up
9 : ? (seems to be a CAN_L)
14 : CAN_L
16 : +12V
Will try to see if we can get CAN messages on this OBD connector, but it will be another subject...
There's an "ordinary" CAN bus on pins 1-9 that uses 500KBPS data rate (2 uS bit width). I've recorded this bus.
Though the levels on pins 6-14 are CAN levels, the protocol is not "ordinary" CAN. The bitrate is on the order of 1 MBPS, but connecting the protocol engine used on pins 1-9 (set to 1 MBPS) collects almost nothing, and also introduces errors on the bus due to the engine's method or generating acknowledges for the few messages it thinks are in the valid format. Some other protocol is being used, which might be a slight modification of CAN, or it might be something running at 1152KBPS like HDLC. I haven't looked into it at the bit level yet. Busy on other things, getting ready for the local Supercharger turn up, likely this week.
nlc: I have a complete log of a charging session. In addition to the ID's you list, the charger transmits ID's 0x244 (both length=0 and 8) and 0x214 (length=8).
These files are LARGE, so I'd like to pass them around offline. Is there a PM function where we can privately exchange email addresses?
I can confirm that ID=0x322 sends the VIN in pieces, once a second, repeatedly for the whole duration of the session.
From what I'm seeing, ID=0x312 is not related to the car's identity.
It's late here, I'm tired, and I'll study this data more tomorrow when I'm more awake!
These files are LARGE, so I'd like to pass them around offline. Is there a PM function where we can privately exchange email addresses?
I can confirm that ID=0x322 sends the VIN in pieces, once a second, repeatedly for the whole duration of the session.
From what I'm seeing, ID=0x312 is not related to the car's identity.
It's late here, I'm tired, and I'll study this data more tomorrow when I'm more awake!
That's great !!
Thus the charger only send 2 identifiers. 0x244 is curious if it have 0 or 8 bytes.
Maybe the 0 byte frame is a request from the car, and the 8 byte frame is the answer from the charger ? Do you have the state of the RTR bit ?
Can't wait to see the log !! Do you know what was the SoC value at the beginning of the session ? And the SoC value at the end of the session ?
Thus the charger only send 2 identifiers. 0x244 is curious if it have 0 or 8 bytes.
Maybe the 0 byte frame is a request from the car, and the 8 byte frame is the answer from the charger ? Do you have the state of the RTR bit ?
Can't wait to see the log !! Do you know what was the SoC value at the beginning of the session ? And the SoC value at the end of the session ?
nlc: Thanks for quick reply. Your thoughts on the data likely to be very interesting to all. Thanks for all the excellent work.
Something I forgot to mention: the signal level on Pilot during the digital stream seems to be 0 to +5V. I didn't have a scope, but was measuring the high level at about 0.7V on the Fluke. The thermometer presentation seemed to go a little higher. There's no 120VAC near the charger, and I don't have a 12V->120V inverter.
Is there anyone else who wants to play in this sandbox? If so, please PM me. It's hard work, but worth the effort.
Something I forgot to mention: the signal level on Pilot during the digital stream seems to be 0 to +5V. I didn't have a scope, but was measuring the high level at about 0.7V on the Fluke. The thermometer presentation seemed to go a little higher. There's no 120VAC near the charger, and I don't have a 12V->120V inverter.
Is there anyone else who wants to play in this sandbox? If so, please PM me. It's hard work, but worth the effort.
wnb: I would be interested in taking a look at your session logging if you don't mind. I haven't had a chance to setup and log my own as of yet, but I could certainly help analyze the data.
How large is the log? I could provide a place to host it also, or you could try Dropbox or similar.
How large is the log? I could provide a place to host it also, or you could try Dropbox or similar.
Hi rdrcrmatt-- Yours is a very reasonable request. We now have 3 recordings of charges, will have a 4th on Wednesday. A few pages back <nlc> noted that he'd found the SoC. We've also found what we think are current (several places, with different scaling each) and voltage. We need to instrument more cars that have different configurations (battery size, options, varying charging locations and conditions, etc.) so we can differentiate what we're seeing. Anyone willing to attach 2 wires in the trunk to their car, please PM me. This is a lengthy project, and we'll keep you posted. Best to all.
pilotSteve
Active Member
Does Elon's "open source" patent policy help you in this effort? Are the protocols described in detail in supercharger patents?
Have you looked to see if this CAN data is also sent to a home (AC) charger? Any chance it sends details about how charged the Tesla is.... so that a smarter charger could (externally) regulate how much power it is given (such as when charging several cars)?
Hearing that it broadcast the VIN via CAN, sadly suggests that the SuperChargers might trust (or perhaps check) that the charging was enabled <sigh> by doing as little as look for the indication in the VIN that the DC charging is enabled (...which would also be investigated by looking at what an upgraded-to-supercharging car "advertised" as its VIN, and seeing if it is something other than the "real" (original?) VIN).
I would have predicted/assumed Tesla was using some public key system to authenticate either the car, or the SuperCharging authorization... but I guess with software updates, they could switch to this if/when hacking becomes prevalent. I guess Tesla could also validate the VIN in a database, and cross-check with GPS etc info, so it may not be that weak.
On the positive side, if the Tesla was sending a VIN to any charger, then some adjustments to Open EVSE could probably also record, or respond to different cars automagically... which might be nice.
Hearing that it broadcast the VIN via CAN, sadly suggests that the SuperChargers might trust (or perhaps check) that the charging was enabled <sigh> by doing as little as look for the indication in the VIN that the DC charging is enabled (...which would also be investigated by looking at what an upgraded-to-supercharging car "advertised" as its VIN, and seeing if it is something other than the "real" (original?) VIN).
I would have predicted/assumed Tesla was using some public key system to authenticate either the car, or the SuperCharging authorization... but I guess with software updates, they could switch to this if/when hacking becomes prevalent. I guess Tesla could also validate the VIN in a database, and cross-check with GPS etc info, so it may not be that weak.
On the positive side, if the Tesla was sending a VIN to any charger, then some adjustments to Open EVSE could probably also record, or respond to different cars automagically... which might be nice.
TonyWilliams
Active Member
Your home charge station does not use CAN messaging, nor does the UMC. The very first step to enable the CAN messaging is the short duty cycle of the 1kHz pulse width, which signals the car for digital communication. The only charge station that will use this short pulse width is the Supercharger.
Duty Cycle --- Max Current
< 3% ------------ Error
3% - 7% ------- Digitial Com Required <--- this is what Supercharger sends the car
10% - 96% ----- 6A - 80A <---- this is what the UMC, any J1772 station, or HPC/HPWC sends the car
>96 --------------- Error
Yes... at a minimum it should be possible to extract the CAN data... and then if we assume the user can't unplug/plug without our detecting it... go back to the analog PWM scheme. This seems like a nice feature... and we could even switch back to this periodically if we wanted to "monitor" progress in a charge.
IF the CAN protocol commands and responses are better understood, it *might* be possible to use the digital CAN protocol to control the AC charging as well, and not even have to worry about any disconnect/reconnect race, and switching back-n-forth.
It is also nice to be able to experimentally send and respond to commands at home, and simply avoid applying power during these investigation tests.
IF the CAN protocol commands and responses are better understood, it *might* be possible to use the digital CAN protocol to control the AC charging as well, and not even have to worry about any disconnect/reconnect race, and switching back-n-forth.
It is also nice to be able to experimentally send and respond to commands at home, and simply avoid applying power during these investigation tests.
Similar threads
