After months of stagnation, I am finally making some progress on Tesla Model S and X support. As a start, tonight’s edge update decodes the elusive estimated and ideal ranges. These cars are incredibly complex. Dozens of modules, 4 active CAN buses, an Ethernet network, two displays, and one of the busiest CAN buses I’ve ever seen. The CAN messages themselves are often packed tightly on bit (not byte) boundaries, so real hard to find the individual information items. The architecture itself is quite neat. There is a freertos based CAN gateway at the back of the Centre Information Display (CID). That takes all the CAN buses and gateways them to a single Ethernet connection joining the infotainment and other control systems. If the CID wants to transmit on the CAN bus (for example, to lock/unlock the doors), it sends a command to the gateway that converts it to a CAN bus message. Incoming CAN bus messaged get converted to UDP broadcasts. There is a great diagnostics tool built into the CID, but it is locked down by strong encryption. Rather than tear down my wife’s car, I think this is a better solution: It came from a scrapped, insurance written-off, Model S. I’ve also got this, but not much use for what I am doing at the moment. It didn’t take long to break into the diagnostics displays: And that is my first new message decode - the display SOC%, as well as rated and estimated ranges plus Wh/mile consumption. There is a huge amount of information there. Like the Tesla Roadster 1050 displays, on steroids... Hundreds of messages, all coming off the Ethernet. At the moment, the car is not connected, so I am just looking at messages from the MCU and Gateway themselves. But even that is close to 80 messages. I can see the values transmitted, and bus they are transmitted on, but no idea of CAN ID#, data length, or encoding. So, it is painstaking going through them one by one. The MCU messages themselves are a summary of car status, and look pretty good. Because they are isolated on the bench, it is relatively easy to work with them as a starting subset, and I am concentrating on the ones useful to OVMS (battery status, charge status, etc). It seems we have full charge status available, including supercharging, and the reason for charge termination. Once I’ve got the MCU messages decoded, it will be time for: $ nc mycar.local 3000 | nc bench.local 3000 to send all the data from the car to the bench and see what is displayed. I can then mess with the messages (fuzzing) to try to identify IDs and then data. The result of this work should be full OVMS support, and three DBC files describing the data. It would be much easier to have OVMS directly connected to the Ethernet, but Tesla will probably at some time lock that down, and it is so troublesome to take the dash apart to man-in-the-middle that. Regards, Mark.
