Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register
This site may earn commission on affiliate links.
Probably. The Sumitomo X437A connectors were not too hard to find here (and at an obviously reasonable price). By comparison, we can't find the X437 connectors at all, and need to bring them in from USA (in bulk reels).

I've never liked the OBDII connector. Too klunky and non-standard. The cables we make all start with a sealed moulded female DB9, and use the OVMS style pinout at that end (power, ground, 3x CAN buses, and a single-wire pin for stuff like K-line/LIN). The factory I use can put pretty much whatever we want at the other end. If someone really needs OBDII, they can either cut off the DB9 (and replace), or use an adaptor. The CAN1, power, and ground, on the DB9 are pretty standard for USB-CAN loggers (or as close to a standard as I've ever seen for this).

If you guys think there is a need for this, please let me have the details of what you think is required. My eMail is mark (at) openvehicles (dot) com.



I thought for 3/Y, the best place to tap into the CAN buses was at the rear of the centre armrest thing?

From an OVMS point of view, we really concentrate on tapping into CAN buses. Our goal here is to make it easier to 'open' these vehicles and work on them.

I'll email you with my potential needs for custom cables. I think a lot of folks would love to avoid a big unnecessary OBD connector, and I would love a direct-plug cable with sumitomo passthroughs and plugs directly into my board JST connectors nice and cleanly. I would love to easily plug into two busses both on S/X and 3/Y.

The rear console connector on the 3/Y is vehicle CAN only, the ICE connector is the only spot with all three, but easily reached in the footwell.
 
  • Helpful
Reactions: markwj
I bought a UK (RHD) Model S recently and have benefited enormously from the generous online sharing of DBC files and CAN data by @brianman, @Krash, @amund7's google docs spreadsheet and Liam O'Brien. I'm tinkering with an LED array and would like it driven by the CAN.

I've hit an issue with the Energy (charge) values on CAN3. All sources indicate that the values I need are on messageID 0x382, but they don't appear to be correct any longer. I'm comfortable with my code as @Krash's was good enough to include a sample frame in his pdf. Unfortunately the values now on the CAN bus don't work. For example, Energy Buffer is always 0, and Nominal Energy Remaining is often significantly higher than Nominal Full Pack.

I'm using the following DBC values (which match everywhere - but the latest I've found was early 2019):
```
BO_ 898 BMS_energyStatus: 8 ETH
SG_ BMS_energyBuffer: 50|8@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_energyCounter: 58|4@1+ (1,0) [0|0] "" X
SG_ BMS_energyToChargeComplete: 40|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_expectedEnergyRemaining: 20|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_idealEnergyRemaining: 30|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_nominalEnergyRemaining: 10|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_nominalFullPackEnergy: 0|10@1+ (0.1,0) [0|0] "KWh" X
```

Please could someone share the latest/ currently working snippet for a post-facelift Model S? Or do those values work for you guys in the US/ Canada/ Europe and we're different in the UK for some reason?

Thank you for everything you've shared to get me this far!
 
Giving back: I should add that for those that need them, the Sumitomo connectors (male, female and pins) are available here in the UK from auto-click.co.uk. The service was slow, but that could have been thanks to Coronavirus. They ship to Europe and for a cost they will crimp the connectors onto pig-tails before shipping them out.
 
I bought a UK (RHD) Model S recently and have benefited enormously from the generous online sharing of DBC files and CAN data by @brianman, @Krash, @amund7's google docs spreadsheet and Liam O'Brien. I'm tinkering with an LED array and would like it driven by the CAN.

I've hit an issue with the Energy (charge) values on CAN3. All sources indicate that the values I need are on messageID 0x382, but they don't appear to be correct any longer. I'm comfortable with my code as @Krash's was good enough to include a sample frame in his pdf. Unfortunately the values now on the CAN bus don't work. For example, Energy Buffer is always 0, and Nominal Energy Remaining is often significantly higher than Nominal Full Pack.

I'm using the following DBC values (which match everywhere - but the latest I've found was early 2019):
```
BO_ 898 BMS_energyStatus: 8 ETH
SG_ BMS_energyBuffer: 50|8@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_energyCounter: 58|4@1+ (1,0) [0|0] "" X
SG_ BMS_energyToChargeComplete: 40|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_expectedEnergyRemaining: 20|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_idealEnergyRemaining: 30|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_nominalEnergyRemaining: 10|10@1+ (0.1,0) [0|0] "KWh" X
SG_ BMS_nominalFullPackEnergy: 0|10@1+ (0.1,0) [0|0] "KWh" X
```

Please could someone share the latest/ currently working snippet for a post-facelift Model S? Or do those values work for you guys in the US/ Canada/ Europe and we're different in the UK for some reason?

Thank you for everything you've shared to get me this far!

Tesla changes messages and signals with each firmware update, and a LOT has changed in the past year or two. It's a lot of work keeping a DBC updated for Model 3/Y.
I am starting to wish I had access to a Model S so I cold keep an updated DBC for that as well.
 
  • Like
  • Informative
Reactions: aerodyne and amund7
I am starting to wish I had access to a Model S so I cold keep an updated DBC for that as well

In my reading around the topic I wondered whether the reason that there wasn't a community maintained DBC file on Github or similar was because some people felt Tesla changed the IDs in order to make it hard for anyone else to rely on them. So publishing them in an obvious place might be thought to encourage Tesla to change them more often? I can see that Commai take pull-requests into the DBC files in their panda repository but I guess those of us who have a Tesla don't really need a second self-drive system - so there's very little on there!

I have to say, absolute credit to Amund and Brian for the fantastic catalogues they created. And I've found that most of Amund's spreadsheet is still valid and accurate now. It doesn't detail the specific bytes/ bits, but having the message IDs is a massive leg-up. I can see you do the same for the Model 3 - but to an even more detailed level. Very impressive. I have an S rather than a 3 so haven't been digging around but did have a quick look at all the information you share in the Model 3 thread. Do you keep your dbc file on Github and accept pull requests so the community can help to maintain it? I guess that would be some overhead in itself...
 
In my reading around the topic I wondered whether the reason that there wasn't a community maintained DBC file on Github or similar was because some people felt Tesla changed the IDs in order to make it hard for anyone else to rely on them. So publishing them in an obvious place might be thought to encourage Tesla to change them more often? I can see that Commai take pull-requests into the DBC files in their panda repository but I guess those of us who have a Tesla don't really need a second self-drive system - so there's very little on there!

I have to say, absolute credit to Amund and Brian for the fantastic catalogues they created. And I've found that most of Amund's spreadsheet is still valid and accurate now. It doesn't detail the specific bytes/ bits, but having the message IDs is a massive leg-up. I can see you do the same for the Model 3 - but to an even more detailed level. Very impressive. I have an S rather than a 3 so haven't been digging around but did have a quick look at all the information you share in the Model 3 thread. Do you keep your dbc file on Github and accept pull requests so the community can help to maintain it? I guess that would be some overhead in itself...

But that's exactly what I have been doing for over a year:
joshwardell/model3dbc

I maintain it myself from multiple sources, but always first verify with real data from my car.
 
  • Helpful
Reactions: scottf200
But that's exactly what I have been doing for over a year:
joshwardell/model3dbc

I maintain it myself from multiple sources, but always first verify with real data from my car.

Perfect. What a fantastic reference for all Model 3 owners out there with an itch for electronics - it looks extremely comprehensive. You and others must have spent thousands of hours decoding and collating all that. I hadn't been able to find the same for the S so wasn't sure so thought I'd suggest it just in case.

I've just had a look in your Model 3 file and it's really interesting to see that the Energy data that Amund helped me with earlier is identical on the 3 as the S, only on a different message ID (0x382 instead of . You've helped me fill the gap for that final bit 63 being "full charge complete"!

I've got one final item I'm struggling with - I think I'm misunderstanding "Energy to Charge Complete". I was expecting it to be the difference between the nominalEnergyRemaining (i.e. the current charge level) and the "set limit" value that you set on the console so it charges to, say, 70%. For some reason my `expectedEnergyRemaining : 22|11@1+ (0.1,0)` always shows zero. I've recorded the bus over a long period charging, and it's zero. I've recorded while increasing the charge limit a notch at a time, wait 30 seconds and repeat. But that expectedEnergyRemaining value never changes! You don't happen to know where I'm going wrong do you? I'm currently stepping through your M3 DBC file for clues :)
 
  • Like
Reactions: JWardell
Perfect. What a fantastic reference for all Model 3 owners out there with an itch for electronics - it looks extremely comprehensive. You and others must have spent thousands of hours decoding and collating all that. I hadn't been able to find the same for the S so wasn't sure so thought I'd suggest it just in case.

I've just had a look in your Model 3 file and it's really interesting to see that the Energy data that Amund helped me with earlier is identical on the 3 as the S, only on a different message ID (0x382 instead of . You've helped me fill the gap for that final bit 63 being "full charge complete"!

I've got one final item I'm struggling with - I think I'm misunderstanding "Energy to Charge Complete". I was expecting it to be the difference between the nominalEnergyRemaining (i.e. the current charge level) and the "set limit" value that you set on the console so it charges to, say, 70%. For some reason my `expectedEnergyRemaining : 22|11@1+ (0.1,0)` always shows zero. I've recorded the bus over a long period charging, and it's zero. I've recorded while increasing the charge limit a notch at a time, wait 30 seconds and repeat. But that expectedEnergyRemaining value never changes! You don't happen to know where I'm going wrong do you? I'm currently stepping through your M3 DBC file for clues :)
To give proper credit, the model 3 info it all got started with a thread he/JWardell stated Jul 2, 2018 over here: Diagnostic Port and Data Access - Tesla Owners Online
 
  • Like
Reactions: JWardell
Perfect. What a fantastic reference for all Model 3 owners out there with an itch for electronics - it looks extremely comprehensive. You and others must have spent thousands of hours decoding and collating all that. I hadn't been able to find the same for the S so wasn't sure so thought I'd suggest it just in case.

I've just had a look in your Model 3 file and it's really interesting to see that the Energy data that Amund helped me with earlier is identical on the 3 as the S, only on a different message ID (0x382 instead of . You've helped me fill the gap for that final bit 63 being "full charge complete"!

I've got one final item I'm struggling with - I think I'm misunderstanding "Energy to Charge Complete". I was expecting it to be the difference between the nominalEnergyRemaining (i.e. the current charge level) and the "set limit" value that you set on the console so it charges to, say, 70%. For some reason my `expectedEnergyRemaining : 22|11@1+ (0.1,0)` always shows zero. I've recorded the bus over a long period charging, and it's zero. I've recorded while increasing the charge limit a notch at a time, wait 30 seconds and repeat. But that expectedEnergyRemaining value never changes! You don't happen to know where I'm going wrong do you? I'm currently stepping through your M3 DBC file for clues :)

Last I looked at it, that value was updated. But that's on the Model 3. Lots of things work differently on the S. Furthermore, Tesla has changed and abandoned many of these things over time. I take logs of charging and driving for almost every firmware update, so often I can go back and see if and when something stopped working, especially when evaluating a signal.

I really would need the same for Model S. DBC files going back through time, as well as logs for many of the firmware versions with a well-defined set of actions (charge, drive around block, etc). And also, a planet with a couple extra hours in a day :)
 
I really would need the same for Model S. DBC files going back through time, as well as logs for many of the firmware versions with a well-defined set of actions (charge, drive around block, etc). And also, a planet with a couple extra hours in a day :)

Understood. You've already been very helpful in telling me that it sounds like I'm expecting the right thing, and that the 3 used-to (and likely still does) send data there. I'll keep investigating, and post back here as and when I ground it out. I'll also post back any other signals I find are different on my car, to share them with others.

In the meantime, if anyone else with an S can confirm it works for them - or knows how I could derive either the amount of charging left to reach the target, or the target itself I would be grateful.
 
I am doing some research to add ScanMyTesla to my late 2015 Model S.
When I go to the ScanMyTesla website, I am told that I need 2 things:

1/ An adapter cable
2/ OBD2 Bluetooth adapter

For the cable, I went to the gpstracking site. There they tell me I need an HRN-C T06A11, which includes an HRN-CM24Y1. When I look at the pictures they provide, I can't see how I could use the T06A11. It appears that I only need the CM24Y1.

For the Bluetooth adapter, I went to scantool.net, and chose the OBDLink LX device. Then I noticed a disclaimer: used for all OBD-II compliant vehicles (except hybrid and electric vehicles).

There is a whiff of BS in the air.

Do I really need that T06A121 cable? Can I use the OBDLink LX device on my car?

Thanks for your help.
 
I am doing some research to add ScanMyTesla to my late 2015 Model S.
When I go to the ScanMyTesla website, I am told that I need 2 things:

1/ An adapter cable
2/ OBD2 Bluetooth adapter

For the cable, I went to the gpstracking site. There they tell me I need an HRN-C T06A11, which includes an HRN-CM24Y1. When I look at the pictures they provide, I can't see how I could use the T06A11. It appears that I only need the CM24Y1.

For the Bluetooth adapter, I went to scantool.net, and chose the OBDLink LX device. Then I noticed a disclaimer: used for all OBD-II compliant vehicles (except hybrid and electric vehicles).

There is a whiff of BS in the air.

Do I really need that T06A121 cable? Can I use the OBDLink LX device on my car?

Thanks for your help.
I have all the parts for sale if you want them. My X was bought back. I have an android phone, cable, OBDlink and a cell phone holder. $150 for all of it.