I'm fairly certain only "SOC UI" and "SOC Min" are reported via the CAN bus. These bytes are reported under CAN ID 0x302 (
source).
Scan My Tesla computes "SOC" by using the nominalRemaining, nominalFullPackEnergy and buffer, all of which are reported under CAN ID 0x382. You can see how it's being calculated for Scan My Tesla on the
Github repo, specifically:
Code:
p.AddValue("SOC", "%", "br", (bytes) => soc = (nominalRemaining - buffer) / (nominalFullPackEnergy - buffer) * 100.0);
The fact it aligns perfectly with what's displayed in the vehicle suggest to me that's probably how the car is computing it as well.
TM-Spy supposedly uses "SOC UI" for the SOC that's displayed in the app. It appears to match exactly with nominalRemaining divided by nominalFullPackEnergy, thus I've always thought this was the capacity of the battery pack with the buffer (it indicates 0% when nominalRemaining is 0.0 kWh).
The same applies for "Usable full pack" and "Usable remaining" in Scan My Tesla. It's not reported via CAN bus, they're just calculated values which take nominalRemaining or nominalFullPackEnergy minus the buffer. Again, you can see this in the Scan My Tesla source code. If "Usable remaining" shows 0.0 kWh when the display hits 0% SOC or 0% rated miles, I'd imagine this is exactly how the car is calculating it as well (nominalRemaining minus the buffer).
Edit: Since I can't use Scan My Tesla (no android devices), I was curious what some of the other CAN bus reported values were (really just trying to figure out what TM-Spy displays) so I created a simple script in python to decipher raw CAN frames. I created a
repository on Github for anyone that might be interested as well. Basically lets me convert raw CAN frames from TM-Spy recordings. Only supports a few CAN ID's right now and "SOC UI" isn't converting correctly for some reason... always shows a value too high so disregard that for now.