DIY Electric Car Forums banner
Cancel
Create thread New Garage Forums

Tesla 10Kw Open Source Charger Controller

1 reading
Jump to Latest
130K views 645 replies 35 participants last post by  Kevin Sharpe  
#1 ·
So I've had a first look at the Tesla Gen 2 10Kw charger. Now , making one of these work as is with CAN messages is near on impossible due to the level of integration of the charger and the car. So I decided to have a look inside. Seems it uses 3 x 3.5kw modules linked back to a central logic board. Each modules connects to the logic pcb with 8 wires.

So far i have identified GND , +12v , +5v and a 500k canbus. Two lines seems to carry analog signals and one seems to be open circuit. Attached see some CAN captures from this internal network. I may be wrong but I bet it will be easier to work out these messages and get the individual charger modules to wake up.

So plan is to design a little breakout board so I can monitor the signals on a live car during the charge process and log the CAN messages.

Stay tuned:)
 

Attachments

#76 ·
I got a few twitches out of the charge this morning but then the power went out due to a storm crossing over Ireland today:)

Something else different on the EU HVJB. See that box on the front with some of the orange charge leads going to it? I think this is how they switch between single and 3 phase charging. Will investigate tomorrow.
 
D
#78 ·
There is another difference in the power connections to the chargers. It could be that Damien's was set up for two chargers, mine only had one.

In my version there are two bundles of six wires to the charger. They ran from the AC Master and DC Master plugs (on the main board of the HVJB) directly to the master charger on one side of the HVJB. A pair of straight 6-to-6 connection.

Damien's EU HVJB shows a connection to both the master and slave charger sides of the HVJB. I was expecting there would be another pair of 6-to-6 connections from the AC Slave and DC Slave plugs, but the cables suggest something different.

The differences could be a combination of EU and Single/Dual charges?

Jeff
 
#80 ·
Ended up running my house for over 24 hours from batteries. Mains came back on this evening and I got the charger setup in the workshop feeding the test pack. These power modules are interesting beasts in themselves. They have their own built in HV precharge and main relay. So far if I dump the can capture into the module it precharges , closes the relay then faults out before delivering current. Going to get deeper into it tomorrow and see what I can find.....
 

Attachments

C
#82 ·
I'd have to guess voltage irregularities as well. It's possible that the charger listens to BMS messages and faults if the reported voltage from the BMS isn't pretty close to the voltage it measures itself. I'd probably do a check like that if I were them.

It sounds promising though! If it gets that far then that's a good sign. Maybe post a snippet of log of the bus from a little bit before the fault to a little bit after. It must be setting some sort of fault flag and maybe we can figure out what that fault flag means.
 
#90 ·
That's on the cards for tomorrow Tom. Need to beef up my wiring and add cooling so I can let it run at full power then figure out the necessary messages. I know 0x045c is needed and it has some weird crc byte going on.
 
#93 ·
Ok so in order to run phase one of the charger it takes 3 CAN IDs :

0x0368
0x042C
0x045C

I have uploaded a file to the github ph1_frames.csv
When this is played back to the phase 1 module and mains applies at the right time the module will go through power up and ramp up to 8.5A DC and stay there until the capture ends. Details of the Savvycan settings in the picture attached.

0x045c seems to indicate when the mains must be applied. Work progresses....
 

Attachments

C
#97 ·
Nope. None of those bytes present themselves as a likely CRC or security byte. A proper CRC would have a roughly even distribution of values and almost always is coupled to a counter byte or nibble so that the traffic continuously changes and the CRC/Security byte can then detect trouble easily and quickly. None of that is present. It appears to be three signals with byte 5 and 6 always being zero. The signals are fairly constant too, there just isn't a lot of variation here. Personally I'd try hard coding the data bytes to just one set of values and transmit it over and over. I'm thinking the actually interesting stuff is in the other IDs. I don't know what 0x45C is but I don't think it's that important.

Depending on which version of SavvyCAN you're using you could do lots of fun stuff to make the 0x45C message happen but always be static. If you have a recent enough version you could write a Javascript file that implements the suspected charging protocol directly and then edit it until it works. Or you can turn off transmission of 0x45C in the playback window and add it to the custom frames window triggered by your sending of one of the other messages. Or you could script just that part. Or you could use the fuzzing window but lock it to one ID (0x45C) and the bits you want set. Then fire that up at like 20ms and do your playback with just the other two. SavvyCAN has gotten really large and feature rich but unfortunately the jerk that wrote it never documented any of it. So if you have questions about how to do something just ask.
 
#95 ·
Uploaded charger power_run_ph1.csv this is a capture of phase 1 starting up , ramping up to 8.5A DC 320VDC, 15.5A AC, 230v 50hz. Mains switched manually around message number 700 in ph_frames.csv

And of course the power goes out again just as I'm about to film:mad:
Maybe Elon bought the power company.....
 

Attachments

#99 ·
Ok. New theory. One time today when I was doing a power run I forgot to install the fuse that bypasses my cooker element (approx 10R) on the hv dc side. The charger ramped up to 1.5A and hunted around that current value while holding the battery at exactly 370V until the capture ran out.

one of the last values of 0X045C is 0x57 0x90 0x15 0x2E 0x00 0x00 0x6A 0x8C

take bytes 0 and 1 in little endian so 0x9057 = 36951 x 0.01 = 369.51V

Could this be the voltage target ? Find out tomorrow. Same prat time, same prat channel:D
 
T
#100 · (Edited)
Gents my findings so far.

And nice one on finding that. Mind sharing that capture so i can check if my findings are true?

Just found that the last bytes of that message, 0x045C read 0x8C6A or 359.46 V if divided by 100, plus then overlaying with the capture with the knowledge for damien this looks very much like a Voltage feedback from the control board (maybe from the battery). See updated document with graphs.
 

Attachments

T
#102 · (Edited)
I know, but is that including the one where you mention you hit 370V at 1.5A?

Got most of the commands found, so sending out message 0x368 at fixed values and then in message 0x42C steping byte 1 from 100 to 196 and then applying the AC voltage to see if the charger will click.

Possibly you will also require in 0x42C to step change byte 4, looking at it there is a change it influeces/controls the precharge.

In message 0x45C byte 2 and 3 also do a step change. these sync up with byte 1 in 0X42C.
 
DIY Electric Car Forums
posts
554K
members
94K
Since
2007
A forum community dedicated to DIY electric car owners and enthusiasts. Come join the discussion about electric vehicle conversions, builds, performance, modifications, classifieds, troubleshooting, maintenance, and more!
Full Forum Listing
Explore Our Forums
All EV Conversions and Builds Batteries and Charging Technical Discussion New Member Introductions Electric Motors