You can install our site as a web app on your iOS device by utilizing the Add to Home Screen feature in Safari. Please see this thread for more details on this.
Note: This feature may not be available in some browsers.
Wow wk!
Your link is flawed somehow but this worked:
http://skie.net/uploads/TeslaCAN/Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf
Hmm... mine works for me. Can just go to Index of /uploads/TeslaCAN and then click the doc from there if needed.
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 )
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.
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.
Hmm... mine works for me. Can just go to Index of /uploads/TeslaCAN and then click the doc from there if needed.
I certainly am interested.Thoughts? Who is interested in such a thing?
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)
I'm with ya.I'm convinced from a previous life that ties cut off blood flow to the head.
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
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.
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.
Downloaded and saved on USB stick before the men in black Model X's get to your house
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.
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.
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.
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.
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.
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?I will point out that my initial entry method did in fact involve removing some NAND chips from a CID and IC.
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?