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

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
Surprise!

Hmm! Lots going on here. I'll have to catch up on everything. :)

But, I figure I'll just come through and shake things up a bit, so: Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf

bobmicdrop.gif
 
I don't think it's an unfair assumption on Renault's behalf. You have a 3 phase connector, with a clear design intent for 3 phase (or we would be using Type 1's), and labelled L1, L2, L3 + N. Theoretically you don't even need a neutral, and who knows someone might come up with a design which doesn't need one at some point in the future. (And in fact Renault might not, but we will have to wait for someone with wk057 or Ingineer or JRickard's skills to dismantle one to find out for certain :D )

We can agree that AFAWK this isn't explicitly stated in the specs for Type-2 what 32A means, at least in terms of phasing, but I think it's a stretch to suggest this is in anyway good practice or envisaged by the standards bodies. We can also agree the real issue is the specs need tying down.

Where we don't agree is if this is a simple oversight. My view is Tesla took a convenient shortcut plain and simple, so I'm not surprised the standards committee and Tesla fell out if this was typical of their cavalier approach to suit their own implementation without adding cost*. This comes at the expense of other potentially more efficient implementations by others who adhere to common working practice of denominating phase using the L1,L2,L3 nomenclature.

(*Which we have discussed before with some additional on board contractors this would have been 100% doable for Tesla to use a single input 32A phase line, but to do so would have been orders of magnitude more expensive than the tying of the pins to a common phase in the UMC).

Either way the moral of the story is don't try to plug a UMC into any other car than a Tesla until someone else has been brave enough to try it first.

Wasn't trying to defend Tesla, or to blame Renault. Just saying that I think they have implemented two different interpretations of the spec. If Tesla believed that the spec meant "draw this much current on each phase" then the UMC would have been configured to signal a 10A limit when using their bridged commando adaptor.

Also I'm not sure because it pre-dates my knowledge of Tesla or of EV-ing generally, but I thought TM participated in standards process about DC charging (i.e. DC-Mid vs CCS etc) but not the original Type 2 spec. Could be wrong though.

Not convinced...

The (clever) idea of the Zoe is the motor works like a transformer wired in delta, and it uses the IGBT's in the power circuitry to effectively regen power back into battery. (This is why it can do up to 44kW from AC!)

What I don't understand is how feeding a single phase into each corner of the delta would lead to a current to neutral (and why I'm not convinced with the 96A return path theory). As you asserted earlier it should do nothing!

It is of course possible the chameleon system measures across L1 and L2, sees 0v apparent and goes into single phase mode. (And indeed chameleon name comes from the fact it can act as a rapid on three phase AC and a fairly mundane 7kW unit on single phase) That would be my suggestion of what was the cause of magic smoke, on single phase you are capped at 16A.

Well I didn't measure current but
1. the 32A MCB protecting my commando outlet tripped twice (and I reset it twice, thinking it was the Zoe's well-known habit of pulling overcurrent during startup :redface:) before finally the UMC/Zoe died
2. specifically it was the neutral contact in the UMC contactor that fused closed (I continuity tested it later).

The Zoe may not have pulled 96A but clearly it went way over 32A on the neutral wire.

Interested to hear that the chameleon charger supposedly uses delta wiring. Do you have a reference? [send it me another way if so; should probably stop the Renault chat on this thread!]
 
Downloaded and saved on USB stick before the men in black Model X's get to your house :) :p

Thanks for all the efforts you've put into the work deciphering this stuff, but also for making TMC a much more valuable resource all round.

So big Kudos where it's due. (Which also applies to a fair few other members in this thread, and I'm sure they know who they are!)


Simon

(p.s. best thread ever!)
 
Slow down WK...... I'm still working on 0x6F2!!!! I've got it in binary and now working on converting to engineering units and storing in ASCII so it is readable in a text viewer. Also revisited and got my passive CAN sniffing working so as not to disturb the buss in any way.
 
Nice work wk057!

Going from a slightly unrelated note, how long until we see "performance tuning" Model S companies?

The drive firmware can, after all, be updated over the CANBUS... all you would need is an original image to modify.

I reckon if you didn't care about motor or battery lifespan you could get a lot more out of the lower end 60/70, though the P90D/P85D are probably at the limit of traction. And of course 40/60kWh upgrades.
 
I don't know what I'm more surprised about.. the charge rate or someone wearing a tie is reading this thread.. ;)



(sorry couldn't resist)

Hehe... that was my son in the reflection... although I had one on too. We were on the way home from a religious event. or believe you me, I'd not had one on.... as a matter of fact I had probably already removed mine.. :biggrin:

- - - Updated - - -

I'm convinced from a previous life that ties cut off blood flow to the head.
I'm with ya.
 
To Ingineer and wk057 - how did you hack into the central console system? I have disassembled the central console but I don't see any obvious entry points. There's a strange micro-USB connector but from what I understand it's password-protected.

Just a hint in PM would be enough.
 
I'll be happy to help with the CAN bus boards. I have a pick and place robot and an oven available (Chinese quality, so don;t use too fine pitched parts or even BGAs). I am located in Germany, but I assume that none of the parts used have export restrictions.
 
I dumped the 4GB and 16GB flash cards. Both are dead ends - the 4GB card contains what it appears to be the modules' firmware and the 16Gb card contains only the mapping software. It's clear that you've either tried something scary (like re-soldering Hynix NAND chips) or exploited the vulnerability in the internal network.

For other people reading the thread, the Ethernet connector on the back of the CID is Rosenberger HSD type B. See my thread: identification - Identify connector - Electrical Engineering Stack Exchange

I'm making a passive Ethernet hub ( Building a passive ethernet hub with anti-parallel diodes - Electrical Engineering Stack Exchange ) to splice it into the connection. This way I'll be able to easily tap into the CID<->IC traffic without having to install powered devices.
 
Hmm! Lots going on here. I'll have to catch up on everything. :)

But, I figure I'll just come through and shake things up a bit, so: Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf

That's awesome! Looking through the document I can confirm that I've found it to ring true. There were some areas I wasn't entirely sure of. For instance, I knew that 0x102 had a 15 bit signed value in bytes 2 and 3 but never could quite convince myself whether it was pack current or not. It sure seems that way. Getting another person who believes it sort of helps. ;)

Good stuff. I'll work to confirm all your results and then create a DBC file that matches. Then anyone using SavvyCAN or Vector CANAlyzer or any of the tools that can convert DBC to their native format can use the DBC to interpret the results.

- - - Updated - - -

I'll be happy to help with the CAN bus boards. I have a pick and place robot and an oven available (Chinese quality, so don;t use too fine pitched parts or even BGAs). I am located in Germany, but I assume that none of the parts used have export restrictions.

The idea of building an open source board specifically for the Tesla is interesting. Yes, it would not have to be directly compatible with Arduino shields which would allow for more freedom in how it is constructed. I'm afraid I probably can't help too much with that as I work at EVTV and so it'd sort of be a conflict of interest for me. I'm actually not entirely sure of the open source status of the candue 2.0 board design. I don't believe that the design is really available out in the open but really if you're going to build a new board the relevant bits are easy to see. The GVRET firmware is open source so you can easily see pin assignments and even use the same firmware on the new boards so long as they use a SAM3X microprocessor. So, there are decent ways to jump start the process.
 
Slow down WK...... I'm still working on 0x6F2!!!! I've got it in binary and now working on converting to engineering units and storing in ASCII so it is readable in a text viewer. Also revisited and got my passive CAN sniffing working so as not to disturb the buss in any way.

It seems that EVTV is releasing the full source for a program that reads this message so I see no harm in fully explaining that message here.

There are 32 messages in a constant loop. They transmit 96 voltages and 32 temperatures in series. The format is:
Byte 0 = The sequence # (0-31)
Thereafter, the data are stored as 13 bit values followed by a single bit value. The single bit specifies whether this value is a voltage or temperature. But, it's easier than that. The first 24 messages are all voltage and the next 8 are temperature. Each message has four values. For temperature it's easy. You divide the value by 100 and you have the temperature in centigrade. For voltage the situation is a bit weirder. It appears that the value returned is input to a linear equation. It looks sort of like the equation might be: cellVoltage = (Reading / 3072) + 2.385

There are 96 cell groups so the pack voltage is all 96 summed up.

If anyone knows of a better equation which is more accurate that'd be cool.
 
Downloaded and saved on USB stick before the men in black Model X's get to your house :) :p

Thanks for all the efforts you've put into the work deciphering this stuff, but also for making TMC a much more valuable resource all round.

So big Kudos where it's due. (Which also applies to a fair few other members in this thread, and I'm sure they know who they are!)


Simon

(p.s. best thread ever!)

They still haven't arrived it seems. :( I was hoping they would because my wife wants to "sit in a Model X." lol

Slow down WK...... I'm still working on 0x6F2!!!! I've got it in binary and now working on converting to engineering units and storing in ASCII so it is readable in a text viewer. Also revisited and got my passive CAN sniffing working so as not to disturb the buss in any way.

:) Well, no worries, as long as I keep your work queue loaded up! hehe

Nice work wk057!

Going from a slightly unrelated note, how long until we see "performance tuning" Model S companies?

The drive firmware can, after all, be updated over the CANBUS... all you would need is an original image to modify.

I reckon if you didn't care about motor or battery lifespan you could get a lot more out of the lower end 60/70, though the P90D/P85D are probably at the limit of traction. And of course 40/60kWh upgrades.

Well, as mentioned up-thead, I won't help anyone unlock anything they haven't paid for, and I suspect others with similar knowledge feel the same. Much more than the CAN data is needed to do anything like this I believe. Few exceptions maybe when utilizing MITM type CAN devices, but probably not a whole lot going to happen on the tuning side of things from read-only data.

To Ingineer and wk057 - how did you hack into the central console system? I have disassembled the central console but I don't see any obvious entry points. There's a strange micro-USB connector but from what I understand it's password-protected.

Just a hint in PM would be enough.

I dumped the 4GB and 16GB flash cards. Both are dead ends - the 4GB card contains what it appears to be the modules' firmware and the 16Gb card contains only the mapping software. It's clear that you've either tried something scary (like re-soldering Hynix NAND chips) or exploited the vulnerability in the internal network.

For other people reading the thread, the Ethernet connector on the back of the CID is Rosenberger HSD type B. See my thread: identification - Identify connector - Electrical Engineering Stack Exchange

I'm making a passive Ethernet hub ( Building a passive ethernet hub with anti-parallel diodes - Electrical Engineering Stack Exchange ) to splice it into the connection. This way I'll be able to easily tap into the CID<->IC traffic without having to install powered devices.

At this time I'm not prepared to release any methods for getting access to the CID or IC. I will point out that my initial entry method did in fact involve removing some NAND chips from a CID and IC.

I didn't end up going with a passive or active ethernet hub/switch. I just took both ends of the ethernet connection to the IC (the cable side and the IC side) and extended them under my dash as RJ45 connections (using some spare connectors from a salvage S's part). Then I used a Raspberry Pi 2 and some USB ethernet adapters to sit in between the two while I needed to. When I was done I put an RJ45 coupling in so that the connection was normal, no active or passive components, just a straight connection through a slightly extended wire.

I am curious, though, if you've found somewhere to actually source these connectors. I haven't found anyone who carries them where I could purchase any.

I'll be happy to help with the CAN bus boards. I have a pick and place robot and an oven available (Chinese quality, so don;t use too fine pitched parts or even BGAs). I am located in Germany, but I assume that none of the parts used have export restrictions.

Very good to know! :) Thanks.

That's awesome! Looking through the document I can confirm that I've found it to ring true. There were some areas I wasn't entirely sure of. For instance, I knew that 0x102 had a 15 bit signed value in bytes 2 and 3 but never could quite convince myself whether it was pack current or not. It sure seems that way. Getting another person who believes it sort of helps. ;)

Good stuff. I'll work to confirm all your results and then create a DBC file that matches. Then anyone using SavvyCAN or Vector CANAlyzer or any of the tools that can convert DBC to their native format can use the DBC to interpret the results.

The idea of building an open source board specifically for the Tesla is interesting. Yes, it would not have to be directly compatible with Arduino shields which would allow for more freedom in how it is constructed. I'm afraid I probably can't help too much with that as I work at EVTV and so it'd sort of be a conflict of interest for me. I'm actually not entirely sure of the open source status of the candue 2.0 board design. I don't believe that the design is really available out in the open but really if you're going to build a new board the relevant bits are easy to see. The GVRET firmware is open source so you can easily see pin assignments and even use the same firmware on the new boards so long as they use a SAM3X microprocessor. So, there are decent ways to jump start the process.

Cool! I haven't messed around much with SavvyCAN's DBC stuff, but it looks pretty cool. Instead I just wrote a log parser in perl for the output format SavvyCAN uses (since that's what I've been using to log live vehicles) as I was deciphering, then used that to whip up my document from the comments in my code. Was more fun that way, and I'm about to pick and choose values to output in a CSV type format for graphing and such. :)

An open-source logger would be pretty cool. For me, I'm kind of selfishly focusing on using the CID/gateway's internal CAN bus monitoring to make a little logger that actually runs in the car itself, which I can display as a little web page that I can view in the car's browser. Should be fun. :)

It seems that EVTV is releasing the full source for a program that reads this message so I see no harm in fully explaining that message here.

There are 32 messages in a constant loop. They transmit 96 voltages and 32 temperatures in series. The format is:
Byte 0 = The sequence # (0-31)
Thereafter, the data are stored as 13 bit values followed by a single bit value. The single bit specifies whether this value is a voltage or temperature. But, it's easier than that. The first 24 messages are all voltage and the next 8 are temperature. Each message has four values. For temperature it's easy. You divide the value by 100 and you have the temperature in centigrade. For voltage the situation is a bit weirder. It appears that the value returned is input to a linear equation. It looks sort of like the equation might be: cellVoltage = (Reading / 3072) + 2.385

There are 96 cell groups so the pack voltage is all 96 summed up.

If anyone knows of a better equation which is more accurate that'd be cool.

Looks like you're a little late to that party on that: Reading Battery Voltages and Temperatures via CAN on Model S

On that note, I haven't verified the EVTV findings on 0x6F2 just yet. Looks good, but I have a feeling the voltage is probably less convoluted than expected.
 
I know we're starting to walk a very fine line to somewhere you don't want to go, but as you've now rooted your actual driving car, and not just the bench setup, can I assume that this part was not required in that case?

It was not. Info discovered after rooting my bench setup allowed me to do the same to my car without the invasisve flash removal. That's about all I'm going to say on that for now.
 
All fascinating stuff, chaps

On a slightly more sinister note, aren't you a little concerned that Vladimir Ripyakarof will turn up at your front door (as opposed to Tesla personnel), and in true villainous style, threaten members of your family until you hand over the necessaries to steal or modify cars?