Tesla Owners Online Forum banner
2081 - 2100 of 2106 Posts

· Registered
Joined
·
1 Posts
Huge thanks to @JWardell and all other contributors.

Hooked into VehicleCan on a Model 3 earlier this week and was primarily interested in GPS information.
My car transmits ID04FGPSLatLong every ~1000ms on VehicleCan, unfortunately ID3D9UI_gpsVehicleSpeed is unusable (sometimes available for short periods of time). I was able to extract heading from ID2D3UI_solarData (UI_solarAzimuthAngle - UI_solarAzimuthAngleCarRef), perhaps this info will be of use to someone.
 

· Registered
2019 SR+
Joined
·
119 Posts
Does anyone know new location (or format) of brake temperatures message on the vehicle bus?
I've collected that data on message 3FE as follows:
Code:
BO_ 1022 ID3FEbrakeTemps: 5 VehicleBus
SG_ BrakeTempFL3FE : 0|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempFR3FE : 10|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempRL3FE : 20|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempRR3FE : 30|[email protected]+ (1,-40) [0|0] "C"  Receiver
but as of 2022.28.1 seemingly random values are returned.


EDIT:
Dumped and tested some values, and it seem they added 12 bit of checksums and counters at the bottom bytes, shifting everything else up by the same 12 bits.
Useful data now looks like this:

Code:
BO_ 1022 ID3FEbrakeTemps: 8 VehicleBus
SG_ BrakeTempFL3FE : 12|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempFR3FE : 22|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempRL3FE : 32|[email protected]+ (1,-40) [0|0] "C"  Receiver
SG_ BrakeTempRR3FE : 42|[email protected]+ (1,-40) [0|0] "C"  Receiver
 

· Registered
Joined
·
5 Posts
Hey! I create a project called tesberry, which is converting all CAN messages to MQTT messages in a convenient human readable way. It is possible to read and send messages into the can bus via MQTT using e.g. NodeRED on a Raspberry Pi. It's still WIP but it's already working great and I was able to open the frunk using my driver door handle with a logic I implemented in NodeRED.

I'm definitely open for contributions and feedback if anyone is interested.

 

· Registered
Joined
·
27 Posts
Hello everybody, after firmware update 28.2 meaning of many bits in can bus messages has changed, now my display shows headlights ON icon when I turn left (!) and foglight ON icon when I turn on auto steering...Is there an updated version of the DBC file ? Mine is dated august 2021. Many thanks
 

· Registered
2019 SR+
Joined
·
119 Posts
Hello everybody, after firmware update 28.2 meaning of many bits in can bus messages has changed, now my display shows headlights ON icon when I turn left (!) and foglight ON icon when I turn on auto steering...Is there an updated version of the DBC file ? Mine is dated august 2021. Many thanks
I've also noticed that, and it looks like the data is still in message #3F5 - it's all zeroes with no lights and changes to something when you press "blink" in app.
However, format changed and would likely need another round of manual decoding and comparing the bits in message to actual car lights.
 

· Registered
Joined
·
2 Posts
Hello everybody !

First thanks to all the contributors and to @JWardell that shared the dbc for the Model 3 and the Can analysis on Youtube !

Now, my question. Does anyone know the location (or format) of TPMS message on the vehicle bus of the S Plaid ? The dbc from the model 3 used to work for this message. But not anymore and I can't figure out if the id for TPMS data changed or if they added some bits as in @kornerz answer.

The previously used message :
BO_ 537 ID219VCSEC_TPMSData: 5 ChassisBus
SG_ VCSEC_TPMSDataIndex M : 0|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCSEC_TPMSBatVoltage0 m0 : 24|[email protected]+ (0.01,1.5) [1.5|4.04] "V" Receiver
SG_ VCSEC_TPMSBatVoltage1 m1 : 24|[email protected]+ (0.01,1.5) [1.5|4.04] "V" Receiver
SG_ VCSEC_TPMSBatVoltage2 m2 : 24|[email protected]+ (0.01,1.5) [1.5|4.04] "V" Receiver
SG_ VCSEC_TPMSBatVoltage3 m3 : 24|[email protected]+ (0.01,1.5) [1.5|4.04] "V" Receiver
SG_ VCSEC_TPMSLocation0 m0 : 32|[email protected]+ (1,0) [0|4] "" Receiver
SG_ VCSEC_TPMSLocation1 m1 : 32|[email protected]+ (1,0) [0|4] "" Receiver
SG_ VCSEC_TPMSLocation2 m2 : 32|[email protected]+ (1,0) [0|4] "" Receiver
SG_ VCSEC_TPMSLocation3 m3 : 32|[email protected]+ (1,0) [0|4] "" Receiver
SG_ VCSEC_TPMSPressure0 m0 : 8|[email protected]+ (0.025,0) [0|6.35] "bar" Receiver
SG_ VCSEC_TPMSPressure1 m1 : 8|[email protected]+ (0.025,0) [0|6.35] "bar" Receiver
SG_ VCSEC_TPMSPressure2 m2 : 8|[email protected]+ (0.025,0) [0|6.35] "bar" Receiver
SG_ VCSEC_TPMSPressure3 m3 : 8|[email protected]+ (0.025,0) [0|6.35] "bar" Receiver
SG_ VCSEC_TPMSTemperature0 m0 : 16|[email protected]+ (1,-40) [-40|214] "C" Receiver
SG_ VCSEC_TPMSTemperature1 m1 : 16|[email protected]+ (1,-40) [-40|214] "C" Receiver
SG_ VCSEC_TPMSTemperature2 m2 : 16|[email protected]+ (1,-40) [-40|214] "C" Receiver
SG_ VCSEC_TPMSTemperature3 m3 : 16|[email protected]+ (1,-40) [-40|214] "C" Receiver

Any help would be appreciated !
 

· Registered
Joined
·
2 Posts
Hey ! To answer my own question, I found the TPMS signals for the bluetooth sensors of the S Plaid. Here they are :

BO_ 602 ID25ATPMSsensors: 8 ChassisBus
SG_ TPMSFLpressure : 0|[email protected]+ (0.025,0) [0|6.375] "bar" Receiver
SG_ TPMSFRpressure : 8|[email protected]+ (0.025,0) [0|6.375] "bar" Receiver
SG_ TPMSRLpressure : 16|[email protected]+ (0.025,0) [0|6.375] "bar" Receiver
SG_ TPMSRRpressure : 24|[email protected]+ (0.025,0) [0|6.375] "bar" Receiver
SG_ TPMSFLunknown : 32|[email protected]+ (1,0) [0|0] "" Receiver
SG_ TPMSFRunknown : 40|[email protected]+ (1,0) [0|0] "" Receiver
SG_ TPMSRLunknown : 48|[email protected]+ (1,0) [0|0] "" Receiver
SG_ TPMSRRunknown : 56|[email protected]+ (1,0) [0|0] "" Receiver
 

· Registered
Joined
·
6 Posts
Hi all.

I'm working on Tesla model 3 with direct connection with the CAN bus.
I'm using python3 pyserial package.

While I was trying to read the speed (ID 0x257) (filtering incoming data with b'\x08\x00\x00\x02\x57'), I found that so many packets make no sense. Most of the packets are not real speed, not sure what exactly are they. However I was able to catch some reasonable values that represent the real speed.


Here is a sample data:
Notes:
  • Real data (representing real speed) are marked with the symbol '>' at the beginning of the line.
  • I only printed the data field (8 bytes).
  • Each byte is printed in binary and decimal.
Code:
>01111000 120    01001110 78    00011111 31    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
>speed_decoded: 0.0

>01110010 114    01001000 72    00011111 31    00000000 0    00000010 2    10100000 160    00000111 7    00000000 0
>speed_decoded: 0.0

>01110111 119    01001101 77    00011111 31    00000000 0    00000010 2    10100000 160    00000111 7    00000000 0
>speed_decoded: 0.0

00001000 8    00000000 0    00000000 0    00000111 7    00000000 0    00001000 8    00000000 0    00000000 0
speed_decoded: -40.0

>10100101 165    01100110 102    00100001 33    00000010 2    00000010 2    00000111 7    00000000 0    00000000 0
>speed_decoded: 2.7200000000000046

>10101010 170    01101011 107    00100001 33    00000010 2    00000010 2    00000111 7    00000000 0    00001000 8
>speed_decoded: 2.7200000000000046

>10101100 172    01100101 101    00100001 33    00000010 2    00000111 7    00000000 0    00000000 0    00001000 8
>speed_decoded: 2.7200000000000046

>11011000 216    10001000 136    00100001 33    00000011 3    00000111 7    00000000 0    00001000 8    00000000 0
>speed_decoded: 2.8800000000000012

>11010111 215    10000111 135    00100001 33    00000111 7    00000000 0    00001000 8    00000000 0    00000000 0
>speed_decoded: 2.8800000000000012

11011111 223    10001111 143    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0    00000000 0
speed_decoded: -30.400000000000002

11010011 211    00001000 8    00000000 0    00000000 0    00000111 7    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0    00001000 8
speed_decoded: -40.0

10100001 161    00001000 8    00000000 0    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

10101000 168    00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0
speed_decoded: -40.0

01110101 117    00001000 8    00000000 0    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

>10110000 176    01001101 77    00011111 31    00000001 1    00000010 2    11011000 216    00000100 4    00000000 0
>speed_decoded: 0.0

>10011010 154    01000111 71    00011111 31    00000001 1    00000010 2    00000100 4    00000000 0    00000111 7
>speed_decoded: 0.0

10000000 128    01000110 70    00000100 4    00000000 0    00001000 8    00000000 0    00000000 0    00000111 7
speed_decoded: -34.56

00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0    00001000 8
speed_decoded: -40.0

This is not only happening when trying to read the speed. It happens in so many IDs such as 0x102 for door status.

Is there some way to filter these unneeded data?
Also, Sometimes, suddenly vehicle stops sending speed data for ~10 seconds or more.

I've been struggling for days. If anyone has ever seen similar behavior, please let me know.
 

· Registered
Joined
·
2 Posts
I want to drive a Model 3 front drive unit in a classic car EV conversion by supplying the right CANBUS messages to the unit. I know there is a product from Ingenext that works with a rear drive unit and battery, but I’m hoping to drive the front drive unit.

I downloaded SavvyCAN, the model3.dbc and started trawling through a bunch of the logs that @JWardell had posted in the summary of this thread. However, I haven’t seen the 0x1D5 front torque message appear in any of them yet, and I’m not sure if that’s reporting torque or commanding it. I also read that the rear drive unit is the master and that in later model teslas there is a separate “magic” can bus for the torques.

Questions: Should I expect to see torque commands to the front drive unit in the model 3 captures of the standard CAN busses here? If not where should I be looking? Any other general advice on how to proceed? Where would I find a pin out for the control connector on the model 3 front drive unit?
 

· Registered
Joined
·
6 Posts
Hi all.

I'm working on Tesla model 3 with direct connection with the CAN bus.
I'm using python3 pyserial package.

While I was trying to read the speed (ID 0x257) (filtering incoming data with b'\x08\x00\x00\x02\x57'), I found that so many packets make no sense. Most of the packets are not real speed, not sure what exactly are they. However I was able to catch some reasonable values that represent the real speed.


Here is a sample data:
Notes:
  • Real data (representing real speed) are marked with the symbol '>' at the beginning of the line.
  • I only printed the data field (8 bytes).
  • Each byte is printed in binary and decimal.
Code:
>01111000 120    01001110 78    00011111 31    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
>speed_decoded: 0.0

>01110010 114    01001000 72    00011111 31    00000000 0    00000010 2    10100000 160    00000111 7    00000000 0
>speed_decoded: 0.0

>01110111 119    01001101 77    00011111 31    00000000 0    00000010 2    10100000 160    00000111 7    00000000 0
>speed_decoded: 0.0

00001000 8    00000000 0    00000000 0    00000111 7    00000000 0    00001000 8    00000000 0    00000000 0
speed_decoded: -40.0

>10100101 165    01100110 102    00100001 33    00000010 2    00000010 2    00000111 7    00000000 0    00000000 0
>speed_decoded: 2.7200000000000046

>10101010 170    01101011 107    00100001 33    00000010 2    00000010 2    00000111 7    00000000 0    00001000 8
>speed_decoded: 2.7200000000000046

>10101100 172    01100101 101    00100001 33    00000010 2    00000111 7    00000000 0    00000000 0    00001000 8
>speed_decoded: 2.7200000000000046

>11011000 216    10001000 136    00100001 33    00000011 3    00000111 7    00000000 0    00001000 8    00000000 0
>speed_decoded: 2.8800000000000012

>11010111 215    10000111 135    00100001 33    00000111 7    00000000 0    00001000 8    00000000 0    00000000 0
>speed_decoded: 2.8800000000000012

11011111 223    10001111 143    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0    00000000 0
speed_decoded: -30.400000000000002

11010011 211    00001000 8    00000000 0    00000000 0    00000111 7    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0    00001000 8
speed_decoded: -40.0

10100001 161    00001000 8    00000000 0    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

10101000 168    00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0
speed_decoded: -40.0

01110101 117    00001000 8    00000000 0    00000111 7    00000000 0    00000000 0    00001000 8    00000000 0
speed_decoded: -40.0

>10110000 176    01001101 77    00011111 31    00000001 1    00000010 2    11011000 216    00000100 4    00000000 0
>speed_decoded: 0.0

>10011010 154    01000111 71    00011111 31    00000001 1    00000010 2    00000100 4    00000000 0    00000111 7
>speed_decoded: 0.0

10000000 128    01000110 70    00000100 4    00000000 0    00001000 8    00000000 0    00000000 0    00000111 7
speed_decoded: -34.56

00000111 7    00000000 0    00000000 0    00000001 1    00001000 8    00000000 0    00000000 0    00001000 8
speed_decoded: -40.0

This is not only happening when trying to read the speed. It happens in so many IDs such as 0x102 for door status.

Is there some way to filter these unneeded data?
Also, Sometimes, suddenly vehicle stops sending speed data for ~10 seconds or more.

I've been struggling for days. If anyone has ever seen similar behavior, please let me know.
The issue is solved by increasing the baudrate of the "CAN to USB SoC" to the max (~920kb/s).
 

· Registered
Joined
·
6 Posts
@JWardell ,Thank you.I have found the chassis bus but not the yellow conncetor ,I get the ID238 and ID239,i am tring to check the data ,but maybe i failed .I verified the segment below on my model 3.the segment in the red box is vevified ,but the data in the blue was always the same,even i start the navigation.
actually i want to decode the navigation data of the model 3 on the screen.

View attachment 34097
Hi Frank.

You mentioned that you were able to find the chassis bus but not the yellow connector. Can you send an image of the chassis bus connector or describe it?
 

· Registered
Joined
·
6 Posts
Hi Frank.

You mentioned that you were able to find the chassis bus but not the yellow connector. Can you send an image of the chassis bus connector or describe it?
(Posting this here for whomever interested.)
Chassis bus is Left CAN in the following two tables (20-pin connector for pre-2019 and 26-pin connector for post-2019 tesla model 3).


Font Parallel Number Pattern Rectangle
 

· Registered
Joined
·
5 Posts
I am working on a small screen for the model 3/Y to display things like speed, SOC ...etc. But first I would like to say thanks to all contributors and @JWardell for sharing the dbc!!!

Watch Gadget Font Gas Display device


I am trying to find a way to know if the car screen is in day/light or night/dark mode.

For example I used 353 UI_displayOn for the on/off status and 273 UI_displayBrightnessLevel for brightness.

Does anyone know if there is a CAN message available for the dark mode? I went through the entire DBC file but couldn't find any. I have a suspicion that only the screen uses that and there is no need for it to be available on the CAN bus. I am also open to use any other kind of logic to conclude the mode status. I know some commercial model 3/y screen do have that option but I am not sure if they set it from CAN or they simply have an embedded light sensor.
 

· Registered
Joined
·
5 Posts
I think you are right. I just tested and I can see ID2D3UI_solarData on the VehicleBus. It is night so UI_isSunUp i showing 0. I will test it tomorrow morning to confirm it turns 1.

Thanks for the tip. I didn't know that some CAN messages are duplicated on other CAN buses.
 
2081 - 2100 of 2106 Posts
Top