Vendor Scan My Tesla, a CANBUS reader for Android

[Mash]

My understanding that those are the only relevant oil temperature signals and they look like estimates...

BO_ 918 ID396FrontOilPump: 8 VehicleBus
SG_ FrontOilPumpOilTempEst396 : 32|8@1+ (1,-40) [0|214] "C" Receiver
SG_ FrontOilPumpFluidTemp396 : 24|8@1+ (1,-40) [0|214] "C" Receiver
SG_ FrontOilPumpOilTempEstConfident3 : 3|1@1+ (1,0) [0|0] "" Receiver

BO_ 917 ID395DIR_oilPump: 8 VehicleBus
SG_ DIR_oilPumpFluidT : 24|8@1+ (1,-40) [-40|214] "C" Receiver
SG_ DIR_oilPumpFluidTQF : 3|1@1+ (1,0) [0|1] "" Receiver

BMSmaxPackTemperature - is it the same as BattCellTempMax332?

Also - those look interesting and I would really appreciate if you add them (unless you know they useless):
VCFRONT_tempSuperheatActFiltered,
VCFRONT_pumpBatteryFETTemp,
VCFRONT_pumpPowertrainFETTemp,
VCFRONT_radiatorFanFETTemp

DIR_rotorMaxMagnetTemp, DIF_rotorMaxMagnetTemp,
DIR_statorEndWindingTemp, DIR_statorTemp1, DIR_statorTemp2,
DIF_statorEndWindingTemp, DIF_statorTemp1, DIF_statorTemp2,

And whole blocks of:
ID376FrontInverterTemps, ID315RearInverterTemps,
ID556FrontDItemps, ID5D5RearDItemps,
ID2E5FrontInverterPower, ID266RearInverterPower

 

[amund7]

My understanding that those are the only relevant oil temperature signals and they look like estimates...

BO_ 918 ID396FrontOilPump: 8 VehicleBus
SG_ FrontOilPumpOilTempEst396 : 32|8@1+ (1,-40) [0|214] "C" Receiver
SG_ FrontOilPumpFluidTemp396 : 24|8@1+ (1,-40) [0|214] "C" Receiver
SG_ FrontOilPumpOilTempEstConfident3 : 3|1@1+ (1,0) [0|0] "" Receiver

BO_ 917 ID395DIR_oilPump: 8 VehicleBus
SG_ DIR_oilPumpFluidT : 24|8@1+ (1,-40) [-40|214] "C" Receiver
SG_ DIR_oilPumpFluidTQF : 3|1@1+ (1,0) [0|1] "" Receiver

BMSmaxPackTemperature - is it the same as BattCellTempMax332?

Also - those look interesting and I would really appreciate if you add them (unless you know they useless):
VCFRONT_tempSuperheatActFiltered,
VCFRONT_pumpBatteryFETTemp,
VCFRONT_pumpPowertrainFETTemp,
VCFRONT_radiatorFanFETTemp

DIR_rotorMaxMagnetTemp, DIF_rotorMaxMagnetTemp,
DIR_statorEndWindingTemp, DIR_statorTemp1, DIR_statorTemp2,
DIF_statorEndWindingTemp, DIF_statorTemp1, DIF_statorTemp2,

And whole blocks of:
ID376FrontInverterTemps, ID315RearInverterTemps,
ID556FrontDItemps, ID5D5RearDItemps,
ID2E5FrontInverterPower, ID266RearInverterPower

I read up on the JWardell DBC after your first post, and I found out the signals I show are
SG_ FrontOilPumpFluidTemp396 : 24|8@1+ (1,-40) [0|214] "C" Receiver
SG_ DIR_oilPumpFluidT : 24|8@1+ (1,-40) [-40|214] "C" Receiver

they are not noted as estimates.

About the others, they are temperatures of the transistor inside the fuse box for that electrical circuit. Is that interesting? There are hundreds of these. Well maybe not hundred, but lots. I have wanted to put the amperage/wattage of each circuit in the app at some point, but haven't gotten there yet, it needs to be presented somehow. Maybe still insteresting as just a list.

The drive train stuff you mention such as magnet temps I have looked for in my own logs, but those packets are marked as 'debug', and usually they are not sent on the bus. But sometimes they are. Like recently the individual cell voltages showed up. They have been disabled since some time in 2018. It's probably just a mistake from Tesla, and it will be removed again soon, so I would guess the same with the magnet temperatures.

If you want to look at all these signals you can make a CAN DUMP with scan my tesla, then open JWardell's DBC and the log file together in either Canbus Analyzer or Savvy CAN, but I'll keep a lookout for these signals in my next log dive and see if they still exist in the new firmware.

 

[Mash]

I read up on the JWardell DBC after your first post, and I found out the signals I show are
SG_ FrontOilPumpFluidTemp396 : 24|8@1+ (1,-40) [0|214] "C" Receiver
SG_ DIR_oilPumpFluidT : 24|8@1+ (1,-40) [-40|214] "C" Receiver

they are not noted as estimates.

I hope you agree that something is seriously off with those readings.
If Oil Temp called estimate and there is a confidence flag, what is the FluidTemp in such a case?

About the others, they are temperatures of the transistor inside the fuse box for that electrical circuit. Is that interesting? There are hundreds of these. Well maybe not hundred, but lots. I have wanted to put the amperage/wattage of each circuit in the app at some point, but haven't gotten there yet, it needs to be presented somehow. Maybe still insteresting as just a list.

I'm trying to find out what leads to power throttling and eliminate that. So I need all temperature signals and signals of power limit. I don't know if there is useful data behind those. But right now I don't see what triggers a 35% power cut.

The drive train stuff you mention such as magnet temps I have looked for in my own logs, but those packets are marked as 'debug', and usually they are not sent on the bus. But sometimes they are. Like recently the individual cell voltages showed up. They have been disabled since some time in 2018. It's probably just a mistake from Tesla, and it will be removed again soon, so I would guess the same with the magnet temperatures.

If you want to look at all these signals you can make a CAN DUMP with scan my tesla, then open JWardell's DBC and the log file together in either Canbus Analyzer or Savvy CAN, but I'll keep a lookout for these signals in my next log dive and see if they still exist in the new firmware.

How I can do CAN DUMP? That would be ideal.

 

[JWardell]

There are hundreds and hundreds of temperature and other sensor signals throughout the car and on the can bus. SMT attempts to display the most of interesting of them. We don't necessarily have explanations of each one though, beyond the short name. And some are old or have no actual signal.
As Amund said, if you want to analyze with a fine tooth comb, you should take a full CAN log and step through or graph signals with an app like SavvyCan with a full DBC.
And as for oil pump discussion, at some point last year, they really did swap front and rear IDs. It's why I validate each signal in my DBC with real logs (and I only have RWD, so I have any front signals missing completely)

 

[Mash]

There are hundreds and hundreds of temperature and other sensor signals throughout the car and on the can bus. SMT attempts to display the most of interesting of them. We don't necessarily have explanations of each one though, beyond the short name. And some are old or have no actual signal.
As Amund said, if you want to analyze with a fine tooth comb, you should take a full CAN log and step through or graph signals with an app like SavvyCan with a full DBC.
And as for oil pump discussion, at some point last year, they really did swap front and rear IDs. It's why I validate each signal in my DBC with real logs (and I only have RWD, so I have any front signals missing completely)

How can I take CAN log in SMT or any other phone app without buying USB CAN reader and driving with a laptop? Maybe I'm dumb, but I can't find CAN dump function...

About oil, my issue is that it's not an oil temperature.

I've checked whole DBC and above is my list of what I think makes sense to watch, but, yes, I'd rather take full logs and read it myself afterwards.

 

[Mash]

How can I take CAN log in SMT?

Anyone?

 

[Dangerous Fish]

Anyone?

I'm not sure you can do it in SMT.

 

[Mash]

I'm not sure you can do it in SMT.

Turns out - long-press on record button gives you this hidden screen:

I just don't understand the difference between Raw/debug and CAN dump, but you can't have both.

 

[JWardell]

Turns out - long-press on record button gives you this hidden screen:

I just don't understand the difference between Raw/debug and CAN dump, but you can't have both.

I'm sure @amund7 can answer more accurately, but I assume CSV is in CSV format that you can import into spreadsheet, and raw just writes the data stream from the OBD module. Normally only the data displayed on screen is recorded, full dump I think reconfigures to transmit ALL messages and records them... however the bluetooth dongle only has a small fraction of the bandwidth required and will therefore randomly miss out on a lot of data.

 

[amund7]

I'm sure @amund7 can answer more accurately, but I assume CSV is in CSV format that you can import into spreadsheet, and raw just writes the data stream from the OBD module. Normally only the data displayed on screen is recorded, full dump I think reconfigures to transmit ALL messages and records them... however the bluetooth dongle only has a small fraction of the bandwidth required and will therefore randomly miss out on a lot of data.

You can have both CSV and RAW at the same time, if you want. CSV is human readable - meaning decoded into numbers and signal names, and can be imported into Excel. The raw logs are hex from the bus, but have 2 modes:

- raw/debug: records whatever the app is doing, useful for debugging, only records the packets you're seeing on your tabs at the time.

- can dump: this records ALL data on the bus without filters. this is useful for exporing unknown data and analyze with other software, because this log then contains all data from the bus whether the app knows it or not. Can make an OBDLINK hang up after a while, if so needs to be unplugged/replugged. Useless for slower adapters, they will miss most of the packets, especially slower ones such as temperatures

JWardell, an Obdlink can get up to 1100 (known) packets per second with this app, how much more data is really there on this bus?

 

[JWardell]

JWardell, an Obdlink can get up to 1100 (known) packets per second with this app, how much more data is really there on this bus?

Tesla can hit over 2000 messages per second, they really cram the bus unlike any other vehicle I've seen, and well beyond the capability of OBD dongles..which is why it's best to spend the money on the OBDlinks that at least handle what they can better than others.
We've always seen missing data on SMT captures, entirely because of the dongle's limitation. The ESP32 can handle one bus over wifi, but still fighting with software fast enough to handle two busses without dropping (which is why my dual bus server is still delayed). I guess it does prove the worth of the $4k Vector 4-bus logger I had been using for logging in the past

 

[Mash]

Tesla can hit over 2000 messages per second, they really cram the bus unlike any other vehicle I've seen, and well beyond the capability of OBD dongles..which is why it's best to spend the money on the OBDlinks that at least handle what they can better than others.
We've always seen missing data on SMT captures, entirely because of the dongle's limitation. The ESP32 can handle one bus over wifi, but still fighting with software fast enough to handle two busses without dropping (which is why my dual bus server is still delayed). I guess it does prove the worth of the $4k Vector 4-bus logger I had been using for logging in the past

It's just incredible that we can have issues writing down 0.5mbit of data (32gb card full after 142 hours of 100% busy bus traffic, which I doubt it is, so it's like month of driving) in 2020. What about using Pi? I see git repo for tesla can logger that can upload data by wifi.

 

[JWardell]

It's just incredible that we can have issues writing down 0.5mbit of data (32gb card full after 142 hours of 100% busy bus traffic, which I doubt it is, so it's like month of driving) in 2020. What about using Pi? I see git repo for tesla can logger that can upload data by wifi.

You are not dealing with the raw baud rate of the CAN network. The OBD logger decodes the message into an ASCII message that is probably 10x the data. Then it's transmitted over BLE which is also not ideal for continuous large data rate streams.
And it's not an issue writing to storage either.
Simply way more than a device designed for occasional OBD/J1939 messages can handle.
It's a lot for the lower power/arduino devices as well, but 32-bit faster processors can handle it. Certainly if you are just dealing with the data.
But if you are trying to do more...decode, process, store, run scrips, web servers, etc...now you are pushing the ESP32.
And of course a Pi would be fine.

 

[Zuikkis]

Hi!

Just bought the software and it seems to work. I had a spare Bluetooth OBD2 adapter, it seems to be compatible.

I have 2013 P85+ with last year going on the 8 year battery warranty, so my main interest is the battery condition.

"Nominal full pack" shows 73kWh. What is the value for new pack? Some page quoted 77.5kWh "usable" but I'm not sure if that includes the 4kWh buffer or not, so is the maximum 81.5kWh or 77.5kWh?

I recently charged to 100% and got 453km rated range. This forum has mostly US folks quoting mile ranges, but I think Euro cars are not comparable? 453km would be 281 miles..

The total charge amounts look interesting, aren't they really low? The 132 wh/km certainly is not correct. So is my battery already changed, or perhaps BMS reseted for some reason?

Edit: Ah just read from the docs that AC Charge / DC Charge are not accurate for older cars as they were started from some later firmware release.. So that explains it.

 

[amund7]

You are not dealing with the raw baud rate of the CAN network. The OBD logger decodes the message into an ASCII message that is probably 10x the data. Then it's transmitted over BLE which is also not ideal for continuous large data rate streams.
And it's not an issue writing to storage either.
Simply way more than a device designed for occasional OBD/J1939 messages can handle.
It's a lot for the lower power/arduino devices as well, but 32-bit faster processors can handle it. Certainly if you are just dealing with the data.
But if you are trying to do more...decode, process, store, run scrips, web servers, etc...now you are pushing the ESP32.
And of course a Pi would be fine.

Great summary. We are using hardware that was not at all meant for this, or at best it's a side feature of the OBD2 adapters, and no other cars have the huge amount of data Tesla has, I think.

The adapters, and Scan My Tesla, are designed to filter out the traffic you want to see. With an OBDLINK at up to 1100 packets per second, the app can capture all known signals (around 160 signals I believe) at full speed. Just the unknown data (for this app) really has speed restrictions. But with most other adapters you are down to 50-80 packets per second, then there is a whole different story, lots of useful data is lost. But it's a question of how much money people want to spend on their adapter.

Just 1 correction, Scan My Tesla doesn't support BLE, only Bluetooth Classic. Even the OBDLINK MX+ uses Bluetooth Classic, which is why it needs the MFI approval from Apple (because Apple decided ?). Had it used BLE it would be open for all devices, or that's what my current intel tells me, and I want to implement support for that for the IOS version in the future. Speeds will probably suffer, but at least people can get some cheaper adapters to use.

 

[amund7]

Hi!

Just bought the software and it seems to work. I had a spare Bluetooth OBD2 adapter, it seems to be compatible.

I have 2013 P85+ with last year going on the 8 year battery warranty, so my main interest is the battery condition.

"Nominal full pack" shows 73kWh. What is the value for new pack? Some page quoted 77.5kWh "usable" but I'm not sure if that includes the 4kWh buffer or not, so is the maximum 81.5kWh or 77.5kWh?

I recently charged to 100% and got 453km rated range. This forum has mostly US folks quoting mile ranges, but I think Euro cars are not comparable? 453km would be 281 miles..

The total charge amounts look interesting, aren't they really low? The 132 wh/km certainly is not correct. So is my battery already changed, or perhaps BMS reseted for some reason?

Edit: Ah just read from the docs that AC Charge / DC Charge are not accurate for older cars as they were started from some later firmware release.. So that explains it.


View attachment 611154 View attachment 611155

Glad to see you found all the info you needed! Looks like the FAQ and info pages are finally starting to do the job

The AC/DC charge numbers go into calculating regen, so when they are inaccurate that affects the wh/km as well. But only the historic ('Total') numbers, for trips it should be accurate.

 

[Zuikkis]

Can anyone comment on battery condition? Is 73kWh "nominal full pack" reasonable for 168000km 85kWh pack?

 

[BigNick]

Nominal Full Pack should have been about 81.5 kWh when new.
My pack has just under 44000 miles (~70000 km) and its NFP value is 74.4 kWh.
With more than double the usage on your pack compared to mine, I'd say your pack is in pretty good shape in terms of capacity retention (about 10.5% capacity loss total.)

 

[Mash]

Great summary. We are using hardware that was not at all meant for this, or at best it's a side feature of the OBD2 adapters, and no other cars have the huge amount of data Tesla has, I think.

The adapters, and Scan My Tesla, are designed to filter out the traffic you want to see. With an OBDLINK at up to 1100 packets per second, the app can capture all known signals (around 160 signals I believe) at full speed. Just the unknown data (for this app) really has speed restrictions. But with most other adapters you are down to 50-80 packets per second, then there is a whole different story, lots of useful data is lost. But it's a question of how much money people want to spend on their adapter.

Just 1 correction, Scan My Tesla doesn't support BLE, only Bluetooth Classic. Even the OBDLINK MX+ uses Bluetooth Classic, which is why it needs the MFI approval from Apple (because Apple decided ?). Had it used BLE it would be open for all devices, or that's what my current intel tells me, and I want to implement support for that for the IOS version in the future. Speeds will probably suffer, but at least people can get some cheaper adapters to use.

Looks like with MX+ canbus dump is using filtered data and depends on what is on the tab? So how to gett data with it that is not on the tab?

 

[JWardell]

Great summary. We are using hardware that was not at all meant for this, or at best it's a side feature of the OBD2 adapters, and no other cars have the huge amount of data Tesla has, I think.

The adapters, and Scan My Tesla, are designed to filter out the traffic you want to see. With an OBDLINK at up to 1100 packets per second, the app can capture all known signals (around 160 signals I believe) at full speed. Just the unknown data (for this app) really has speed restrictions. But with most other adapters you are down to 50-80 packets per second, then there is a whole different story, lots of useful data is lost. But it's a question of how much money people want to spend on their adapter.

Just 1 correction, Scan My Tesla doesn't support BLE, only Bluetooth Classic. Even the OBDLINK MX+ uses Bluetooth Classic, which is why it needs the MFI approval from Apple (because Apple decided ?). Had it used BLE it would be open for all devices, or that's what my current intel tells me, and I want to implement support for that for the IOS version in the future. Speeds will probably suffer, but at least people can get some cheaper adapters to use.

Which is why I still encourage you to add panda/canserver wifi support so the crazy ones can get much more data and bandwidth, plus simultaneous data from multiple busses. Working on a dual-bus Model S harness now.