# Diagnostic Port and Data Access



## JWardell

*Summary:* updated Oct 2, 2019​This thread is our attempt to acquire and decode performance and other data from the serial networks in the Model 3.​We finally gained access, recorded data, and decoded a lot of powertrain CAN data in early 2019.​But there's still a lot more unknown! Additional help would be appreciated from any data and software folks.​Please follow along in the thread to see progress, or skip towards the end to jump into current discussions.​​We also use this thread to detail our hardware and software projects to access, decipher, analyze, and display the data.​​*Instructions to decode logs on your own*​​Below are some links to items in this thread:​​Currently known CAN data spreadsheet​​Model 3 DBC file​​CANBus Analyzer software​​SavvyCAN analysis and capture software​
Model S CAN data spreadsheet​​TMC Thread with Model S and connector information​​Known CAN connector cables​2018 cars: Geotab - EVTV - GPSTA​2019 cars: e-mobility germany - EVTV - GPSTA​​OBDLink MX+ strongly suggested for iOS and Android connection to apps and loggers​​ScanMyTesla app info:​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-226836​​Latest CAN log, from v10:​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-54#post-257176​​Some older logs that I made:​First capture​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-186027​Dual acceleration and regen​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-186339​Drive and Reverse​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-187857​Cold batt charge​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-189154​Charge and drive​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-190116​Cold battery drive, AP, charge​https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-193237​​My CANserver and microDisplay are now available to read and display all the fun can bus data!​



​My original dash display:​
__ https://twitter.com/i/web/status/1094017845124648961​



​
*Original Post:*
I'm hoping some of us nerds can figure out together how to access CAN data in the Model 3. I haven't found much information other than the existence of a diagnostic port hidden somewhere unknown. It also sounds like it will be ethernet with CAN embedded on another layer of data.

I'm hoping to figure all of this out and eventually make something that can grab useful data, maybe even output data to a geek display (dare I say HUD?). It should be possible. Now that my 3 is almost here I will finally have a patient to operate on.

Does anyone have any knowledge of this or come across other useful information that they can share?


----------



## GDN

It's been a while since I read up on them, but over on TMC there are some very techy threads, a couple of the guys that had totally hacked their S are over there, Tesla is on top of their stuff. The security key's, VPN's used, back and forth communication. It's quite impressive. Not to say it can't be done, but most every time he would get close Tesla would shut the door on him.


----------



## scottf200

JWardell said:


> Does anyone have any knowledge of this or come across other useful information that they can share?


Model S (and X) related:
https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/


----------



## JWardell

scottf200 said:


> Model S (and X) related:
> https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/


That's super helpful.

To be clear, I'm talking about the in-vehicle wired data networks, not the cellular or wifi data.

It looks like MountainPass on TMC managed to access data and recommended looking for a twisted pair under the dash in this thread:
https://teslamotorsclub.com/tmc/posts/2768432/

I have plenty of CAN interfaces and software including Vector which work great if there is a physical CAN bus, but I was figuring the model 3 has moved everything over to Ethernet which I'm not sure how to interface with yet.

The digging will start soon!


----------



## Mesprit87

They have that big screen on board, with some password that opens a maintenance menu, I would think the CAN bus is obsolete?


----------



## scottf200

JWardell said:


> To be clear, I'm talking about the in-vehicle wired data networks, not the cellular or wifi data.


I understood that.

I'm using 'Scan my Tesla' & 'TM-Spy' on my 2017 X via an ODBLink LX bluetooth adapter and custom cable I bought on Etsy. 
Scan My Tesla -- https://sites.google.com/view/scanmytesla/home
TM-Spy -- https://teslamotorsclub.com/tmc/threads/using-tm-spy-to-see-model-s-data.63051/


----------



## scottf200

Mesprit87 said:


> They have that big screen on board, with some password that opens a maintenance menu, I would think the CAN bus is obsolete?


From the TMC post he pointed to MountainPass stated:




> We did a fair bit of CAN capturing with the car while we were down there and have decoded a lot of the common messages. There are some similarities to the Model S so we were able to get a head start on that a little bit. We had both analog signal coming from the M1 (shock pots, accelerometer, GPS), as well as a number of CAN signals.


and


> Q: How are you tying into the CAN bus on the 3?





> A: Search for twisted pair wires under the dash and you'll find what you are looking for


----------



## JWardell

scottf200 said:


> I understood that.
> 
> I'm using 'Scan my Tesla' & 'TM-Spy' on my 2017 X via an ODBLink LX bluetooth adapter and custom cable I bought on Etsy.
> Scan My Tesla -- https://sites.google.com/view/scanmytesla/home
> TM-Spy -- https://teslamotorsclub.com/tmc/threads/using-tm-spy-to-see-model-s-data.63051/


I know those exist and connection is relatively easy and documented on the X and the S. But I thought the Model 3 had a new network system that might add an additional network layer before you get to the can data. It's somewhat strange no one has definitively posted it anywhere.


----------



## JWardell

I just noticed @Sasha Anis of Mountain Pass is here on M3OC...maybe they can lend some extra details.


----------



## 96s46p

Would also appreciate any details and photos or diagrams on bus and power harness and connector locations, pinouts, body controllers locations, etc...


----------



## MountainPass

The car has CAN absolutely! You can find them by looking under the driver-side kick panel. Just look for twisted pairs in the harness and start poking at them with your vector scanner. If its CAN it'll be throwing messages at you at 500kbps! 

That's all we'll say for now, I hope it is helpful!


----------



## JWardell

Sasha Anis said:


> The car has CAN absolutely! You can find them by looking under the driver-side kick panel. Just look for twisted pairs in the harness and start poking at them with your vector scanner. If its CAN it'll be throwing messages at you at 500kbps!
> 
> That's all we'll say for now, I hope it is helpful!


Thanks! And it looks like I'll have a specimen in a few days to try it on! Now if only I could find a DBC file around somewhere.


----------



## 96s46p

Some visuals here


----------



## JWardell

96s46p said:


> Some visuals here


Yep, just watched that video an hour ago and said hmm, I think I see a twisted pair in there...
I should know more in the next week or so.


----------



## JWardell

I'm trying to probe around and find some CAN. The red and orange twisted pair are easily accessible in the blue connector, and I see some kind of data signal there, but it's almost as if the bits are RF modulated (see below). Scope can't decode anything with any protocol, tried ground reference and across the pair. The only other twisted pair I see is the extremely thin blue and white wires, can't find where they terminate yet to probe them.
Any suggestions? @Sasha Anis


----------



## JWardell

Server is wonky, can't seem to add an image to the previous post...


----------



## JWardell

You know how it goes after you take a break after hours and go back to realize there is an exposed white diagnostics connector upside-down on the ceiling right above the dead pedal. Impossible to stick wires into so I could only hold them making it difficult to manipulate the scope, but this is much more obviously CAN data. There are two pairs, two CAN busses going to the four forward-most pins, the pin closes to the driver is not connected.

Great news that it is a plug-and-play connector. But need to identify part and order a plug to make an interface.


----------



## 96s46p

I thought that was rumored to be a broadr reach interface that aggregates the can bus data?


----------



## JWardell

96s46p said:


> I thought that was rumored to be a broadr reach interface that aggregates the can bus data?


We had previously theorized that, and maybe it is used throughout the car, but certain folks have verified standard CAN data access. I'll continue to work on it while I have time.


----------



## Krash

Have you thought about connecting female leads to the pins individually? This will be one of the first things I will do to try and connect one of the OBD2 Bluetooth parts. Not as elegant as having the mystery Sumitomo connector but at least you wouldn't have to hold probes. If you do, let me know what size you use.

I'll be pleasantly surprised if you don't need a BroadR interface. Looking at the EDR cable I am cautiously optimistic.


----------



## JWardell

Yes...I have one more fairly free weekend where I can hopefully spend another day on it, and will try maybe a simple .100 SIP connector, and some proper CAN hardware.

If it's Broad-R then we might need an interface like this
http://www.fibrecode.com/usb-oabr-broadr-reach-100base-t1-stick.html

But Tesla's own data kit says it just has a standard Peak CanUSB interface, which I have several of


----------



## JWardell

I think this is it: Molex Mini50

https://automotive.electronicspecif...p-to-establish-automotive-ethernet-guidelines

...and that might mean ethernet, which I don't know as much about

Edit: no, it's something else


----------



## contractorwolf

@JWardell I am interested to hear where you get with this, I wanted to attach an arduino to ODBC connector but just learned today that there isnt one. If you could figure out how to pull mph from any of these connectors let me know. Been thinking about a DIY OLED HUD for speed. Thanks!


----------



## JWardell

contractorwolf said:


> @JWardell I am interested to hear where you get with this, I wanted to attach an arduino to ODBC connector but just learned today that there isnt one. If you could figure out how to pull mph from any of these connectors let me know. Been thinking about a DIY OLED HUD for speed. Thanks!


Yes, the plan is to eventually build an Arduino controlled display or HUD with speed and hopefully geeky live graphs and data.
I got busy after last weekend and haven't had the chance to continue searching for that connector


----------



## contractorwolf

JWardell said:


> Yes, the plan is to eventually build an Arduino controlled display or HUD with speed and hopefully geeky live graphs and data.
> I got busy after last weekend and haven't had the chance to continue searching for that connector


Let me know if you get any further such as diagnosing the live data. I have a 3D printer and can build whatever form factors you might need if you can diagnose the data. I was really bummed that this is not going to be as easy as I had initially planned. I know as soon as the information is out there hardware hackers will come up with a way to do this. Let me know what you find, mine doesnt come in until sept-nov. Which one do you have? color/specs


----------



## Tmo6

I'm totally new to Tesla and vehicle hacking, but want to thank all including @JWardell and @Sasha Anis for giving some info to help a newbie!


----------



## JWardell

Good news! A 5 pin SIP will fit and the pins are standard .100!
They are back from center though making it difficult, here is a picture where I was totally sure and thrilled to have the connector in...and clearly I missed them completely.
I'm going to try to research connectors a bit more this week, but I might be able to get somewhere with this header at minimum.


----------



## 96s46p

http://prd.sws.co.jp/components/en/detail.php?number_s=60983810


----------



## JWardell

96s46p said:


> http://prd.sws.co.jp/components/en/detail.php?number_s=60983810


That sure looks like it would work! Do you know for sure or is it just a guess?
Unfortunately the part number doesn't come up at Digikey, Mouser, Newark or Amazon

Here's the datasheet
http://prd.sws.co.jp/components/series/pdf/en/ts.pdf


----------



## 96s46p

It's just an educated guess. I don't have access to my car right now so I can't do caliper measurements to verify.

https://nexelec.com/SUMITOMO-60983810/


----------



## JWardell

96s46p said:


> It's just an educated guess. I don't have access to my car right now so I can't do caliper measurements to verify.
> 
> https://nexelec.com/SUMITOMO-60983810/


I don't know how you're finding these  Searching for connectors online is so freaking difficult, it's such a visual thing.

I ordered a few plugs and female pins. I will let you know if they work.


----------



## JWardell

The good news is that I can reliably connect to both channels on the diagnostic port with a SIP header adapter I made (below). The bad news is I don't think it's CAN. They are just pulses. I connected the PEAK and tried various software but nothing sees any data, at any common CAN speed. Some bad scope shots below to illustrate.

So back to wondering where exactly @Sasha Anis was reliably receiving 500k CAN. And also wondering what on earth is this data on the diagnostic port


----------



## JWardell

Or...maybe I have to transmit some secret message to activate communications. I hope not.


----------



## MountainPass

Awesome work! But we don't use that port. I'm not sure what kind of signals are on that bus, to be honest, but like you said it's not CAN. 

Keep probing twisted pairs with your PCAN and you'll find something under there!! 

We're trying to source and create a product that will make it easy to just "plug in" to the cars CAN networks. There are three CAN busses in the car. 

We're also working on a display, but I don't think it would be HUD. It would be really cool to see what you guys come up with!


----------



## JWardell

Sasha Anis said:


> Awesome work! But we don't use that port. I'm not sure what kind of signals are on that bus, to be honest, but like you said it's not CAN.
> 
> Keep probing twisted pairs with your PCAN and you'll find something under there!!
> 
> We're trying to source and create a product that will make it easy to just "plug in" to the cars CAN networks. There are three CAN busses in the car.
> 
> We're also working on a display, but I don't think it would be HUD. It would be really cool to see what you guys come up with!


Are you challenging me to a race? An embedded race? 
I'm too lazy and old for that 
I had a tough time locating connectors and ends of all the pairs in there, partly because the left controller is mostly blocked. I really don't feeling like cutting insulation on tiny 28-guage wires without being sure what it does


----------



## 96s46p

I'm sure @Ingineer could tell us exactly where those diagnostic connector wires go and what IC they connect to...


----------



## Krash

96s46p said:


> It's just an educated guess. I don't have access to my car right now so I can't do caliper measurements to verify.
> 
> https://nexelec.com/SUMITOMO-60983810/


Good guess. I tried this part today (without pins) and it is a perfect fit.


----------



## JWardell

Krash said:


> Good guess. I tried this part today (without pins) and it is a perfect fit.


Great to hear. Mine arrives tomorrow. I can update my cable. It's not CAN but maybe then I can try the Tesla black box software. And I need to spend another night probably more twisted pairs too. I could use some California weather for my projects


----------



## jonathan dawn

Pin 1,2 (120 ohm termination) 6,7 and 8,9 of the VCU left are all CAN. Yellow, white; blue, grey; blue, violet.
All 3 should be twisted pair. Dunno difference between pairs 6,7 and 8,9 ..... might be redundant


----------



## 96s46p

Nice, which connector on VCLEFT?



> Model 3 has only 3 main CAN Buses; Vehicle, Chassis, and Party. (There are a few other dedicated private buses as well for certain components) The "Party" bus is also used for fault tolerance in the event one of the other buses is unusable.


So which is which?


----------



## JWardell

jonathan dawn said:


> Pin 1,2 (120 ohm termination) 6,7 and 8,9 of the VCU left are all CAN. Yellow, white; blue, grey; blue, violet.
> All 3 should be twisted pair. Dunno difference between pairs 6,7 and 8,9 ..... might be redundant


That's very helpful...it is very frustrating that the majority of the connections on VCleft are blocked by not easily removable parts of the dash. 
We have had a ton of rain the last several days, seriously getting in my way with this and other car projects. I will get back to it soon.


----------



## jonathan dawn

I will look for can in better location. I am actually thinking maybe we can get off the data connector to the inverter. That's really easy to access.


----------



## S.T

I think that this connector is similar to the model S DLC.
The location of the DLC is the lower left of the driver's seat.


----------



## JWardell

S.T said:


> View attachment 13926
> 
> I think that this connector is similar to the model S DLC.
> The location of the DLC is the lower left of the driver's seat.


There's no question as to the location of the diagnostic connector, it is exposed in the "ceiling" of the footwell and easily accessed.
The question is the location of CAN data that is useful for us.


----------



## Geek

So, for a newbie like me (I am a geek, and can program, but nothing in the context of working on cars as you guys have done here - kudos!), is there anything I can do to connect to the diagnostic connector and get a sense of the messages / data coming from that? Or is that all off limits by Tesla?


----------



## 96s46p

JWardell said:


> There's no question as to the location of the diagnostic connector, it is exposed in the "ceiling" of the footwell and easily accessed.
> The question is the location of CAN data that is useful for us.


That connector he circled is somewhere in the center console. Actually maybe not it might be for the driver seat.


----------



## JWardell

Geek said:


> So, for a newbie like me (I am a geek, and can program, but nothing in the context of working on cars as you guys have done here - kudos!), is there anything I can do to connect to the diagnostic connector and get a sense of the messages / data coming from that? Or is that all off limits by Tesla?


That's just what we are trying to figure out! Once we can figure this stuff with our tools, the hope is to then figure out a way to make an app or dongle than everyone can use easily.


----------



## MountainPass

We're trying to find the OEM connector to make a patch harness that people can use to tap into CAN, as well as for our module. These connectors are proving super difficult to find though, so I'm not sure if we're going to need to have custom ones made or what!


----------



## JWardell

MountainPass said:


> We're trying to find the OEM connector to make a patch harness that people can use to tap into CAN, as well as for our module. These connectors are proving super difficult to find though, so I'm not sure if we're going to need to have custom ones made or what!


I have the diagnostic connector plug and pins...I'll trade you for info on what wires I really need to find raw CAN, I was never able to find it...Of course it's nearly impossible to access the ends of the wires way up in the upper dash, and I don't want to cut into those tiny 28-guage wires. I might need to get a CANgator.


----------



## JWardell

*cough*


----------



## annerajb

JWardell said:


> That's very helpful...it is very frustrating that the majority of the connections on VCleft are blocked by not easily removable parts of the dash.
> We have had a ton of rain the last several days, seriously getting in my way with this and other car projects. I will get back to it soon.


Which of the VC left connectors? are those twisted pairs going too?

Any good location where VCLeft passes thru that can be tapped midway? (maybe on the left seat harness going to the back of the car? Any more specific directions/locations? I wanna connect a Canbus interface to read the messages.


----------



## Sean Reynolds

We should be able to pull CAN off of the abs pump... not sure what make and model the abs pump is but Bosch and Teves both have CAN signals going to them. That could help for researching but obviously not for a nice final solution. e other place I be you would find CAN
is on the main computer itself, or even the infotainment computer. 
I just got my model 3 so I should be able to look this weekend. 
There should be CAN going to all of these.


----------



## Ianlf10

Any updates with this stuff?


----------



## JWardell

Sadly, no. I never found a CAN bus, and haven't been driven to tear my interior apart again. Really wish there was an easier way to get to the connectors to probe them.


----------



## fast_like_electric

Surely not the only location, but the 500 kbps CAN bus is easily accessed behind the panel just below the rear vents (between the front seats). Removing the plastic panel is easiest by sliding both front seats forward first, then slipping the end of an allen key under the panel at the bottom and pulling toward you. Five snap clips to release. Once the panel is removed, you'll see a 20 pin male/female connector junction. CAN_H is pin 18, CAN_L is pin 19. You can also get Ground from pin 20 and Power from pin 4.


----------



## garsh

fast_like_electric said:


> Surely not the only location, but the 500 kbps CAN bus is easily accessed behind the panel just below the rear vents (between the front seats). Removing the plastic panel is easiest by sliding both front seats forward first, then slipping the end of an allen key under the panel at the bottom and pulling toward you. Five snap clips to release. Once the panel is removed, you'll see a 20 pin male/female connector junction. CAN_H is pin 18, CAN_L is pin 19. You can also get Ground from pin 20 and Power from pin 4.


Calling @JWardell.


----------



## GDN

fast_like_electric said:


> Surely not the only location, but the 500 kbps CAN bus is easily accessed behind the panel just below the rear vents (between the front seats). Removing the plastic panel is easiest by sliding both front seats forward first, then slipping the end of an allen key under the panel at the bottom and pulling toward you. Five snap clips to release. Once the panel is removed, you'll see a 20 pin male/female connector junction. CAN_H is pin 18, CAN_L is pin 19. You can also get Ground from pin 20 and Power from pin 4.


This almost makes it sound like it was hiding in plain sight, just teasing @JWardell - I guess this weekend will tell !


----------



## JWardell

fast_like_electric said:


> Surely not the only location, but the 500 kbps CAN bus is easily accessed behind the panel just below the rear vents (between the front seats). Removing the plastic panel is easiest by sliding both front seats forward first, then slipping the end of an allen key under the panel at the bottom and pulling toward you. Five snap clips to release. Once the panel is removed, you'll see a 20 pin male/female connector junction. CAN_H is pin 18, CAN_L is pin 19. You can also get Ground from pin 20 and Power from pin 4.


I certainly never thought of looking in the center console, especially the back! Sounds a lot easier than my previous attempts at ripping apart the driver's footwell. Huge thanks, I will be attempting this weekend (if not tonight...)

Now if anyone wants to PM me some CAN DBC files to decode what I find, I would truly believe in Santa 

PS: Welcome to the forum!


----------



## fast_like_electric

Thanks for the greeting - been a long time lurker, first time poster.

dbc files would of course be nice, but from what I understand most of the divined CAN frame analysis from S/X should apply. 

Also, pins 18 and 19 are the Powertrain CAN bus (aka CAN3 from Model S/X), which is typically the most useful one. The other Model 3 CAN buses are likely on that connector as well. The pinout appears to follow the same hookup as 2015+ model S, when they switched from the 12 pin to the 20 pin diagnostic connector.


----------



## rootandy

Hi together - i am new at the forum here - and from Germany. I try to do a lot in reading CAN busses and things on that and I just read this thread about the tries of reverse engineering of the model 3 CAN-Buses.
I am a Software Developer (, too) and I am about to create some more or less professional reading thing(s) on a raspi basis to log and analyze some driving/charging data and would be happy to support you with finding a solution. As I am from Germany I have no Model 3 in my reachability but if there is any way of getting in touch with a model 3 that I can read I will try to get it 

And most important thing: Big thanks for your work.


----------



## JWardell

I have the panel off... I first went for the top of the three rear panels with the vent/USB, which pulls off very easily. It has the end of a harness to the USB but also a mystery unused port with a few wires.

Anyway bottom fairly simple too with a trim tool, these all pop off by pulling straight back.

Not obvious which pins are witch, but large black wires are in the back corners so I would guess one is those is pin 20. I bet the blue wire is the 12v accessory wire that I have tapped up front.

Probing these stuffed connectors is going to be very difficult with my usual paper clip, but I am afraid to unplug the connector. I assume that would be bad and maybe disconnect the security module. Let me know if you know otherwise @fast_like_electric

I guess it's time for a vacuum...


----------



## fast_like_electric

In your photo, the large gauge black wire right behind the thick yellow wire is pin 20 (ground). CAN_L is right next to that black wire (pin 19), then CAN_H (pin 18). All of those three wires are on the bottom row of the connector - obscured by the other wires.

My guess is that the plug side goes off to some sort of gateway module that bridges those CAN buses to the new automotive Ethernet diagnostic connector. I'm theorizing that as I don't see another reason that they'd maintain the exact same connector and pinout as the X/S diagnostic connector for this junction - and at this odd location. But that is only a best guess.

I just carefully cut into the insulation on the ground and CAN lines (pins 18,19,20) - didn't disconnect anything in the process. Don't know what happens if you do temporarily disconnect the lines. You can use pin 4 or pin 1 if you need power. They are power-moded differently - believe pin 4 is something like a low current version of full time 12V, and pin 1 is more like Accessory.


----------



## JWardell

AND WE'RE IN!! 
Absolutely beautiful!

*-Huge-* thanks to @fast_like_electric !!!

Yellow and white thin wires. Tip: don't cross them while probing or the contractors right underneath you will make you jump 

Now to build a harness and dive in with Vector and some other tools. Hopefully by this weekend.

First, *if anyone can ID this connector* part number or knows where they can be obtained, I would very much like to make a proper in-line plug with a CAN connection.

Also, it would be appreciated if anyone can point me to discussion or files or databases of known CAN IDs from S & X it would save me some time. I will eventually need to drive around and look how numbers respond to controls and displays to associate everything.

Anyway here is what I've been looking forward to seeing for months!


----------



## fast_like_electric

Great progress - congrats for confirming. Will also be interesting if ODB2 request messages are accepted and replied to, such that standard accessories will work (enhanced gauges, HUDs, etc). Believe there is also an app called Scan My Tesla for Android that uses the ELM interfaces - curious if that S/X software will work with Model 3 when hooked up to the Powertrain CAN bus.

In addition to the Powertrain CAN bus, there should be the other less useful CAN buses at that connector too. Pinout and function of those may be different than model S/X.

This post has a lot of Tesla diagnostic connector part number info...

https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/

The Model 3 referenced connectors on that page are for the non-useful 5 pin enhanced diagnostic connector which is believed to be an automotive Ethernet flavor. For the 20 pin Model 3 connector in the console, refer to the references that talk about the 2015+ Model S diagnostic connector.

Partial CAN message breakdown for Model S and X are scattered various places, but here are some starting points...

https://skie.net/uploads/TeslaCAN/Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf

(and)

https://www.instructables.com/id/Exploring-the-Tesla-Model-S-CAN-Bus/

If a more comprehensive Tesla CAN message list is known or generated, that would certainly be welcome. From what I understand, Model 3 is supposed to be very similar to S and X - but with some changes and new messaging as well.


----------



## JWardell

fast_like_electric said:


> Great progress - congrats for confirming. Will also be interesting if ODB2 request messages are accepted and replied to, such that standard accessories will work (enhanced gauges, HUDs, etc). Believe there is also an app called Scan My Tesla for Android that uses the ELM interfaces - curious if that S/X software will work with Model 3 when hooked up to the Powertrain CAN bus.
> 
> In addition to the Powertrain CAN bus, there should be the other less useful CAN buses at that connector too. Pinout and function of those may be different than model S/X.
> 
> This post has a lot of Tesla diagnostic connector part number info...
> 
> https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/
> 
> The Model 3 referenced connectors on that page are for the non-useful 5 pin enhanced diagnostic connector which is believed to be an automotive Ethernet flavor. For the 20 pin Model 3 connector in the console, refer to the references that talk about the 2015+ Model S diagnostic connector.
> 
> Partial CAN message breakdown for Model S and X are scattered various places, but here are some starting points...
> 
> https://skie.net/uploads/TeslaCAN/Tesla Model S CAN Deciphering - v0.1 - by wk057.pdf
> 
> (and)
> 
> https://www.instructables.com/id/Exploring-the-Tesla-Model-S-CAN-Bus/
> 
> If a more comprehensive Tesla CAN message list is known or generated, that would certainly be welcome. From what I understand, Model 3 is supposed to be very similar to S and X - but with some changes and new messaging as well.


Awesome. So the connector is the 20-pin Sumitomo and that TMC thread contains all the part numbers etc. (Last I visited that thread it had no Model 3 info, it has a lot more now!)
I think I will just try tapping in for now. I was able to push sewing pins in, I will try to solder something fancier tomorrow.

I doubt standard ODBII devices would work as that should be a slower bus. It might be useful to interface to all the buses there and gather as much data as possible.


----------



## 96s46p

JWardell said:


> I certainly never thought of looking in the center console, especially the back!


Other than when I proposed it last month you mean 

thanks to @fast_like_electric for sharing the details


----------



## 96s46p

fast_like_electric said:


> From what I understand, Model 3 is supposed to be very similar to S and X - but with some changes and new messaging as well.


I heard the opposite...


----------



## 96s46p

The yellow power wire(s) should be for usb port supply and the blue should be for 12v accessory. The rest go to the security controller (card reader) and the lights and door switches for the center console storage.


----------



## JWardell

96s46p said:


> Other than when I proposed it last month you mean
> 
> thanks to @fast_like_electric for sharing the details


It took me a while to find that just now...looks like you found it in the below thread. Good call! Though at the time, I wouldn't have believed you!
https://teslaownersonline.com/threads/center-console-removal.8156/page-2#post-168624
According to @yonkiman he disconnected the connector. I wonder if he had security troubles or errors when plugging back in.


----------



## fast_like_electric

@*JWardell*
I see from your profile you are in Boston. I'm not sure you are aware, but Massachusetts has a state law where vehicle info must be made available for service purposes. Have you ever visited https://service.teslamotors.com? As a Mass resident, you can get a service subscription that contains lots of details, supposedly including wiring info that is missing from the general public parts catalog. Prices are kinda steep, but there is a 1 hour subscription for $32, or 1-day for $107. 1 hour might be cutting it close to navigate and download useful info, and the $107 may be worth it if you are going to be doing a lot of work with the vehicle.

I'm sure there is a wealth of knowledge locked up in there, but you do need a MA billing address on your credit card to get access. Just a thought, if you were searching for better info.


----------



## JWardell

fast_like_electric said:


> @*JWardell*
> I see from your profile you are in Boston. I'm not sure you are aware, but Massachusetts has a state law where vehicle info must be made available for service purposes. Have you ever visited https://service.teslamotors.com? As a Mass resident, you can get a service subscription that contains lots of details, supposedly including wiring info that is missing from the general public parts catalog. Prices are kinda steep, but there is a 1 hour subscription for $32, or 1-day for $107. 1 hour might be cutting it close to navigate and download useful info, and the $107 may be worth it if you are going to be doing a lot of work with the vehicle.
> 
> I'm sure there is a wealth of knowledge locked up in there, but you do need a MA billing address on your credit card to get access. Just a thought, if you were searching for better info.


I'm aware, but I assume it is the same parts database that was recently published, and I very highly doubt they would publish proprietary data communications. At this point I should be able to figure plenty out on my own given a decent amount of free time. Rich Rebuilds is also nearby and regularly deals with the mechanical side of things and will soon be opening a shop with @EVTuning so there's some chance we can all work together toward some useful goal.
Personally my intentions are to decode and document as much as the messaging as possible for the benefit of everyone, then slowly build an Arduino or other board to live display things similar to a ScanGuageII, and finally one day make some pretty dash display meters or even a HUD that everyone was pining for.


----------



## fast_like_electric

Correct, there isn't going to be CAN communication details on the service site, but wiring diagrams yes. That is, if you want more conclusive info on the wiring of course. Wiring diagrams are not available in the public parts catalog.

I'm also interested in an aftermarket or custom HUD / aux display. Will be trying an el-cheapo one after the holidays. Supposedly works via standard OBD2 J1979 messaging on Model S/X, unclear if these speed/RPM type ODB2 PIDs are implemented on Model 3.


----------



## JWardell

I managed to capture a 2-3 minute trace of data simply turning on, pulling forward, then back again...and the CSV file is a whopping 35 megs! Lots of data here!

I've compared messages to the Model S CAN PDF and sadly, I don't think any data coincides. Only. a few IDs are common, and the data doesn't look the same.

Furthermore there are _hundreds_ of unique IDs, so decoding this is going to be extremely difficult.

Any Excel wizards/data scientists out there feel free to get in touch and I would be happy to send along the CSV.

I'm going to have to separate and export each ID and then see if any data changes over time with simple things like speed and pedal position.


----------



## fast_like_electric

The Model 3 CAN message IDs are indeed different, as well as scaling in several cases. To kick this effort off and help get started, ID 0x405 is the VIN - split into 3 messages.


----------



## Bokonon

JWardell said:


> I managed to capture a 2-3 minute trace of data simply turning on, pulling forward, then back again...and the CSV file is a whopping 35 megs! Lots of data here!


Egads! That's quite a firehose. We need to get this into a queryable repository pronto!

Happy to help with data and tools for making sense of it.

Do any of the off-the-shelf CAN software packages accept CSV or other file input, or do they require a live connection to the bus?


----------



## fast_like_electric

ID 0x528 is Unix time (number of seconds since 1970). 4 byte message, MSB first.

2 messages down, 215 or so to go (at least on LR RWD).


----------



## JWardell

Bokonon said:


> Egads! That's quite a firehose. We need to get this into a queryable repository pronto!
> 
> Happy to help with data and tools for making sense of it.
> 
> Do any of the off-the-shelf CAN software packages accept CSV or other file input, or do they require a live connection to the bus?


It's a very human-readable sequential order CSV file generated by CANopen Magic and fairly human readable. I didn't want to wait till the Vector hardware was available and that will spit out a proprietary format anyway. Here I'll just post it on Dropbox:
https://www.dropbox.com/s/o803kcogb08rlaf/first3.csv?dl=0



fast_like_electric said:


> The Model 3 CAN message IDs are indeed different, as well as scaling in several cases. To kick this effort off and help get started, ID 0x405 is the VIN - split into 3 messages.


Yep, that checks out. Perhaps I'll take down the dropbox link in a day then. I just stripped them from the file.


----------



## GDN

Very cool stuff. I like seeing it deciphered and all the learning. I'm here to like every post you post !!!!


----------



## JWardell

I'm slowly splitting into separate files by ID now, and looking for sensical patterns. Just like decoding the Matrix


----------



## JWardell

0x22A is fairly simple, showing a value that falls from 6073 to 6025. Not the 68% of my battery though. Which reminds me, it might be useful to post the coinciding TeslaFi data, which is too slow to even catch the quick drive:


----------



## Bokonon

JWardell said:


> It's a very human-readable sequential order CSV file generated by CANopen Magic and fairly human readable. I didn't want to wait till the Vector hardware was available and that will spit out a proprietary format anyway. Here I'll just post it on Dropbox


Thanks, this is much more readable and detailed than I was expecting. I'm glad it includes timestamps... much more useful for correlating the messages to specific actions, events, and other data sources (e.g. raw TeslaFi feed) than just a sequence number.



JWardell said:


> Yep, that checks out. Perhaps I'll take down the dropbox link in a day then. I just stripped them from the file.


I think there are GPS coordinates in there too, FWIW. You said you went forward, then back again, right? Did you end up roughly where you started?


----------



## JWardell

Getting tired, but for some sanity, here are the CAN ID files I've done so far if you're interested:
https://www.dropbox.com/sh/hp6yjw58z9xzddq/AADiZ5sg49-rXm2P3bltrdPKa?dl=0

Really the only columns of importance are ID and Raw Message (the last). Ignore the Message type/node fields (it is trying to decode a protocol that is not present)

Some IDs are being sent very often are probably important drivetrain items like motor info, those include 132, 2C1, 2E1, 263



Bokonon said:


> Thanks, this is much more readable and detailed than I was expecting. I'm glad it includes timestamps... much more useful for correlating the messages to specific actions, events, and other data sources (e.g. raw TeslaFi feed) than just a sequence number.
> 
> I think there are GPS coordinates in there too, FWIW. You said you went forward, then back again, right? Did you end up roughly where you started?


Here is the sequence: In back seat, car idle, insert probes, start recording.
Open back door (which will wake car and turn on HVAC and display), open front door, close back door, close front door.
Press brake, car turns on in Park.
Drive ~15feet forward 5mph, hold.
Reverse ~15ft reverse 5mph back into spot, brake, park. stop recording.


----------



## Bokonon

JWardell said:


> Here is the sequence: In back seat, car idle, insert probes, start recording.
> Open back door (which will wake car and turn on HVAC and display), open front door, close back door, close front door.
> Press brake, car turns on in Park.
> Drive ~15feet forward 5mph, hold.
> Reverse ~15ft reverse 5mph back into spot, brake, park. stop recording.


Thanks, this is helpful to have in mind.

I've got the whole file loaded into a SQL database at the moment and am writing scripts to scrub and parse some of the data so that we can query it more easily (example: splitting the decimal-data column into separate unsigned/signed int columns). We'll easily be able to isolate how the values of specific messages change over time, but we should also be able to identify the frequency of each message, and possibly relationships between them.

(EDIT: 20 minutes later, this CAN n00b has realized that the decimal interpretation of the hex values is far less useful than he'd originally thought...  )

If there's anything in particular that you want me to look for that would be easier to find with a query versus by hand, let me know, otherwise I'm just keep basically doing what you're doing, looking at each message one at a time and trying to figure out what the changing values mean. 

General CAN question: for multi-message data like the VIN, am I correct in assuming that the ID is the same for all three, and it's broadcasting the same three segments over and over? e.g.

0x405 (VIN data segment 1)
0x405 (VIN data segment 2)
0x405 (VIN data segment 3)
0x405 (VIN data segment 1)
0x405 (VIN data segment 2)
...etc.?


----------



## JWardell

Yes, I've found quite a few messages that annoyingly alternate between two and some three repeating data. They just repeat like that.
I have found a few messages that seem to have flags that generally coincide with the state of the car, at least between off/powerup/drive. Hoping to find something simple like Park/Drive/Reverse and more items that slowly fall that should coincide with voltage, range, state of charge. Accelerator might be noticeable because it is off most of the time and just barely pressed when moving, but it will be tough if it is packed in a message like Model S.
I wonder if @Ingineer figured out any of this. Sadly his Can-on-screen walkthrough doesn't show any IDs. It does show the insane amount of data here


----------



## Bokonon

For reference, here are the 20 most frequent message IDs, along with the number of occurrences in the sample data:

0x132 9438
0x129 8274
0x2C1 5553
0x154 4991
0x118 4990
0x266 4990
0x016 4989
0x2E1 4724
0x263 4718
0x39A 3776
0x257 2495
0x23E 2359
0x3C2 1897
0x221 1888
0x272 1888
0x282 1888
0x393 1888
0x409 1888
0x545 1888
0x3A2 1887


----------



## Bokonon

I think 0x23E is somehow related to the motion of the car, and may even include the displacement one of the pedals. This message has one behavior for the first 60 seconds and then a different behavior for the last 30 seconds.

During the first phase, the first six bytes are constant (F4 01 3A C0 FA FC) and the last two bytes appear to be a counter of some type that constantly cycles.

When the second phase begins at the 63-second mark, the first six bytes change, with the first two fluctuating within a narrow range, and three of the other four taking on different values. (The last two bytes continue to count.) Then, from about 63.5 to 65.5 seconds, the first six revert to the same value as in phase 1.

From 65.5 seconds to 67 seconds, the first six take on yet another set of values, and then revert to phase-1 until 69.5 seconds. From 69.5 seconds to 76.5 seconds, the first two bytes go through two series of decreases (one quick, one slower), they stay at the low end for a bit.

At 77.5 seconds, phase-1 behavior resumes, except the fourth byte is slightly different this time around (F4 01 3A *BB *FA FC).

Okay, I think that's enough for one night... going to have some interesting dreams.


----------



## Bokonon

Okay, one more thing to look at. It appears that the car enters the "on" state around 44.4 seconds, as there are a flurry of new messages that start appearing around then, whereas no new messages appeared for the prior 30 seconds.

Here are the messages that start showing up when the car powers on, along with the timestamp of the first message in milliseconds. Messages in bold only appear once (1) or twice (2) during the entire session, and may indicate some kind of significant event or state-change. The rest repeat at various higher frequencies for the remainder of the session.

*0x5F4 44415.042 *(1 - power on? power state changed?)
0x154 44487.958
0x266 44502.038
0x118 44502.251
0x016 44512.278
0x126 44512.747
0x257 44513.003
0x1D6 44513.131
0x108 44513.387
0x2B6 44513.515
0x268 44513.728
*0x276 44513.942 *(2 - second time at 44614 ms - data is the same)
0x396 44514.198
0x656 44522.774
0x757 44523.030
0x376 44523.243
0x556 44523.798
0x557 44524.182
0x356 44524.651
0x357 44525.120
0x35A 44525.632
0x35B 44526.997
0x336 44527.381
0x267 44527.808
0x3B6 44528.235
0x3D6 44528.405
0x3D9 44528.661
*0x550 44540.011 *(2 - second time at 83271 ms - data differs slightly = parking brake?)
*0x518 44549.610* (2 - second time at 83280 ms - data is the same)
0x344 44586.943
0x304 44587.199
0x316 44587.455
0x211 44664.595
*0x526 45222.581* (1)
0x3FE 45524.442

Finally, the following two messages are logged exclusively between 54.7 seconds and 78.7 seconds, around 277 times each:

0x388 54691.258
0x328 54699.364


----------



## JWardell

Bokonon said:


> Okay, one more thing to look at. It appears that the car enters the "on" state around 44.4 seconds, as there are a flurry of new messages that start appearing around then, whereas no new messages appeared for the prior 30 seconds.
> 
> Here are the messages that start showing up when the car powers on, along with the timestamp of the first message in milliseconds. Messages in bold only appear once (1) or twice (2) during the entire session, and may indicate some kind of significant event or state-change. The rest repeat at various higher frequencies for the remainder of the session.
> 
> *0x5F4 44415.042 *(1 - power on? power state changed?)
> 0x154 44487.958
> 0x266 44502.038
> 0x118 44502.251
> 0x016 44512.278
> 0x126 44512.747
> 0x257 44513.003
> 0x1D6 44513.131
> 0x108 44513.387
> 0x2B6 44513.515
> 0x268 44513.728
> *0x276 44513.942 *(2 - second time at 44614 ms - data is the same)
> 0x396 44514.198
> 0x656 44522.774
> 0x757 44523.030
> 0x376 44523.243
> 0x556 44523.798
> 0x557 44524.182
> 0x356 44524.651
> 0x357 44525.120
> 0x35A 44525.632
> 0x35B 44526.997
> 0x336 44527.381
> 0x267 44527.808
> 0x3B6 44528.235
> 0x3D6 44528.405
> 0x3D9 44528.661
> *0x550 44540.011 *(2 - second time at 83271 ms - data differs slightly = parking brake?)
> *0x518 44549.610* (2 - second time at 83280 ms - data is the same)
> 0x344 44586.943
> 0x304 44587.199
> 0x316 44587.455
> 0x211 44664.595
> *0x526 45222.581* (1)
> 0x3FE 45524.442
> 
> Finally, the following two messages are logged exclusively between 54.7 seconds and 78.7 seconds, around 277 times each:
> 
> 0x388 54691.258
> 0x328 54699.364


Thanks, it is incredibly useful to know exactly when these states changed, and then apply those times back to other messages. I definitely found messages like 23E that seem to be going through these states and what looks like a 2-second power on sequence.
Of course the temptation is to capture while flooring it onto the highway to see large changes in data, but I'm not confident my poor solder onto a pinhead jammed into the back of a connector will hold under those situations...they slide out quite easily and if they touch, well...you don't want your powertrain shutting down while at WOT! So hopefully this capture will hold us for a while. 
My wife will also be taking the car for the weekend so I won't have another chance


----------



## JWardell

The more I thought about it, the more I realized it would be much easier to spot pedal/RPM/torque etc if they were actually recorded at full range so...I made another quick recording before losing the car for the next few days.
I tried to record quickly but this one is >40MB probably because it is in drive for most of the time. It should turn on, drive, turn left, floor it, regen...turn around and repeat, turn off park. Battery is 60 to 59%, top speed on both runs is, coincidentally, 43mph.
So @Bokonon and anyone else, have at it.
https://www.dropbox.com/s/63w14fffhpk418f/AccelCAN.csv.zip?dl=0

I'm going to look at those high-frequency messages myself to see if I see any obvious patterns.


----------



## Bokonon

JWardell said:


> The more I thought about it, the more I realized it would be much easier to spot pedal/RPM/torque etc if they were actually recorded at full range so...I made another quick recording before losing the car for the next few days.
> I tried to record quickly but this one is >40MB probably because it is in drive for most of the time. It should turn on, drive, turn left, floor it, regen...turn around and repeat, turn off. Battery is 60 to 59%, top speed on both runs is, coincidentally, 43mph.
> So @Bokonon and anyone else, have at it.
> https://www.dropbox.com/s/63w14fffhpk418f/AccelCAN.csv.zip?dl=0
> I'm going to look at those high-frequency messages myself to see if I see any obvious patterns.


Thanks, I'll have a look tonight or later this weekend.

I've setup the database with multiple sessions in mind, so that it will be possible to compare the messages across different runs. I also have saved all of the import/scrubbing scripts, so getting the data loaded should be a lot quicker this time around.

I'm very curious to see what that 0x23E message stream looks like on this acceleration run.

Since it's fresh in your mind, do you happen to remember approximately how many seconds into the recording you were when you stomped on it? And just to clarify, when you say "turn off", are you talking about turning off the recording, or powering down the car?


----------



## JWardell

Staring at the matrix pays off....as they say: Bingo!


----------



## JWardell

Bokonon said:


> Thanks, I'll have a look tonight or later this weekend.
> 
> I've setup the database with multiple sessions in mind, so that it will be possible to compare the messages across different runs. I also have saved all of the import/scrubbing scripts, so getting the data loaded should be a lot quicker this time around.
> 
> I'm very curious to see what that 0x23E message stream looks like on this acceleration run.
> 
> Since it's fresh in your mind, do you happen to remember approximately how many seconds into the recording you were when you stomped on it? And just to clarify, when you say "turn off", are you talking about turning off the recording, or powering down the car?


I meant Park... I think the graphic above clearly shows when the acceleration and regen occur. This could be motor torque or accelerometer Y axis or something similar, pedal would look different.


----------



## JWardell

I'm working my way through messages of my second run one by one in excel to see if I can make sense of any data. I would certainly appreciate any help or thoughts you would like to add to my own. I'll probably have a couple of posts here as I work through. I started with @Bokonon 's list of most frequent messages hoping that increases chances of catching the good stuff.

So to start with ID132...
Three currents? Similar to Model S ID102 pack currents
Bytes 6+5 similar to 4+3 but doubled, similar to unfiltered in MS102
Bytes 2+1 seem to be smoothed a bit...this might be smoothed current value to use?
2+1 offset about 0x9110=37136 ~40k?
4+3 offset about 0x26C0=9920 ~10k?
6+5 offset about 0x4D6E=19822 ~20k?
7,8 always at FF 0F

Chart, note orange bytes2&1 are on secondary axis


----------



## JWardell

ID 129
Not sure what this is, doesn't seem to fit for voltage, torque, power, speed etc
1-??
2-counter repeating from 20 to 2F
4+3-offset at 1FE9=8169
6+5-offset at 2000=8192 but after 34414 offset jumps to FF1F=65311
7,8 always at FF 3F


----------



## JWardell

ID 2C1
Seems to be cycling between 6 different messages with the flag in the 8th byte
Any excel pros out there able to process this one with the cycling rows?









ID 154
Mostly flags and repeating counters
6th byte is 00 until 34414 then occasional data, don't see a second associated byte
There's 34414 again, maybe that's when I hit the brake/turned on the car or shifted to drive.
Data doesn't make sense, maybe brake pedal always hitting limits?


----------



## JWardell

ID 118
This might be pedal position, with byte 1 being a raw value and byte 5 being scaled and smoothed. Goes near full around 35000 and back to zero coinciding with flooring it and beginning of regen as showin in 132.
1-Raw pedal, offset 100 when idle?
2-repeating counter
3-flags/state
4-flags/state
5-scaled smooth pedal?
6-flags/state
7,8-always 00 00


----------



## JWardell

I have some excel questions for those who know what they are doing:
-Is there anyway to speed up chart rendering? With all these data points, it's unresponsive for minutes with every single change, resize, retitle, right-click... I wish I could tell it to wait till I edited everything then gave it the go ahead
-Is there a simple way to convert signed hex to decimal or to a graph? Doesn't seem like excel can really handle anything but 10-bit signed in my google search. Without that all my signed data is going to look like the grey line below.

ID 266
Mostly current or power measurements similar to each other
1-Usually steady around 149
2,5,7- 8-bit power or current values approximately similar
3&4- 12-bit signed power/current


----------



## raptor

Try LibreOffice. Recently ran into a situation where Excel would take up to 10 minutes for certain really complex spreadsheets, LibreOffice ran in less than a minute. It's free, so worth a shot IMHO.


----------



## Bokonon

JWardell said:


> Bytes 6+5 similar to 4+3 but doubled, similar to unfiltered in MS102
> Bytes 2+1 seem to be smoothed a bit...this might be smoothed current value to use?
> 2+1 offset about 0x9110=37136 ~40k?
> 4+3 offset about 0x26C0=9920 ~10k?
> 6+5 offset about 0x4D6E=19822 ~20k?
> 7,8 always at FF 0F


Dumb question, but how are you determining the offset for a given value?

I'm adding some new columns to the database schema that will contain the individual byte values, and calculations for adjacent bytes as 16-bit integers. My ultimate (though perhaps naive) goal would be to calculate the appropriate 8/12/16/etc-bit integer value(s) found in each message once we know the convention.


----------



## JWardell

More cycling messages that I can't process without some Excel help or I think of something.

ID 016
One byte that is always 01

ID 2E1
Cycling through 5 messages

ID 263
Cycling through 3 messages

ID 39A
Cycling through 2 messages

ID 257
First four bytes counters
Last four always 00

ID 23E
Very strange that the data doesn't change until 89974 then goes wild. First six bytes seem independent 8-bit values but change at the same time. I'm basically done with the drive at this point so it's like something kicking in? Weird. Clipped the beginning of the chart.
1-6 individual bytes?
7,8 incrementing counters











Bokonon said:


> Dumb question, but how are you determining the offset for a given value?
> 
> I'm adding some new columns to the database schema that will contain the individual byte values, and calculations for adjacent bytes as 16-bit integers. My ultimate (though perhaps naive) goal would be to calculate the appropriate 8/12/16/etc-bit integer value(s) found in each message once we know the convention.


Offset just guessing at what the offset is if the value is at/near zero. Makes sense for power/current data to be near zero when not moving for example.
Remember that many of these values might not be 8 or 16 bit. Model S doc includes some crazy packed data.

I'm still hoping to find something that is like speed. A little frustrated that after all day I don't really have anything else as clear as 132.
Once we have a handful of things to look at, I can create some live meters on the computer and actually drive around watching them to help confirm what they are.


----------



## Bokonon

JWardell said:


> Offset just guessing at what the offset is if the value is at/near zero. Makes sense for power/current data to be near zero when not moving for example.
> Remember that many of these values might not be 8 or 16 bit. Model S doc includes some crazy packed data.


Got it, thanks.

Yeah, I paged through wk057's doc after I asked that question, and part of my brain melted when I saw how some of the values were encoded.  It's been 15+ years since I've even thought about bit-shifts... working exclusively in the application tier with higher-level programming languages will do that to you. 



JWardell said:


> ID 23E
> Very strange that the data doesn't change until 89974 then goes wild. First six bytes seem independent 8-bit values but change at the same time. I'm basically done with the drive at this point so it's like something kicking in? Weird. Clipped the beginning of the chart.
> 1-6 individual bytes?


I found this surprising too, especially given how 23E behaved in your first, low-speed run.

On both drives, the first six bytes start out as:

F4 01 3A xx FA FC

...where xx is C0 on drive 1, and 95 on drive 2. Drive 1 ends with the same values, except for xx = BB.

Drive 2 behaves a little differently. As you note, around 89974, the first six bytes briefly flip to a complete different set of values:

8B 1D 6D 9C 01 02

...but 40 ms later, they revert to the starting state, only xx (byte 4) is now 9C, the same value it had during the previous frame.

At 91014, the first six bytes start changing again, but return to the initial state 360 ms later. During those 360 ms, byte 4 starts at A5 and decreases to A2. When the initial state resumes, byte 4 retains the value of A2.

A similar thing happens between 91614 and 92494, where the first six bytes start fluctuating again, and byte 4 bounces between B6 and AE before settling on B0 as the other five resume the initial state.

Unlike drive 1, drive 2 does not end in the initial state.


----------



## Bokonon

Comparing the two sessions, the message IDs are mostly the same, but there are a few exceptions (all infrequent messages):

Present in Drive 1, but not in Drive 2 (count)

0x70A (1)
0x529 (1)
0x481 (3)
0x526 (1)
Present in Drive 2, but not in Drive 1 (count)

0x55D (1)
0x522 (1)


----------



## JWardell

Several more unexciting IDs, so I switch to starting at higher priority/100-level IDs

ID 3C2
Cycling through 2 messages
All data almost never changes

ID 221
Cycling through 2 messages
Mostly unchanging flags
Change at 7957

ID 272
Cycling through 2 messages
Looks like all flags

ID 282
Cycling through 2 messages
Looks like all flags

ID 393
Cycling through 2 messages
Looks like mostly flags

ID 102
Barely changing from 22 33 00 00 C2 2C A1 09

ID 119
Always 00 00

ID 126
The first two bytes are what I would expect voltage to look like (V*2?)
The second two look like pedal position or maybe speed
1&2
3&4
5-8 flags


----------



## amund7

hmmm 6 lines of code to adapt CanbusAnalyzer to your files... I think I found a lot in 10 minutes


----------



## JWardell

Another batch for today, I spent a LOT of time nosing around with 108, which seems to finally have the closest graph to speed/rpm, along with some difficult numbers and half-bytes:

ID 139
Always 00

ID 1F9
Always 00

ID 113
Always 01 D7

ID 122
00 00 12 12 D2 00 changing to 00 00 13 12 D2 00 at 18990

ID 123
00 00 12 12 D2 00 changing to 00 00 13 12 D2 00 at 18988

ID 1F8
Always 00 00 00 00

ID 212
States or data that barely change

ID 016
Always 01

ID 00C
States or data that barely change

ID 103
States or data that barely change from 22 33 00 00 C2 2A 21 02

108
Change kicks in at 34957
1 - data. Wild variation doesn't make sense, removed from chart
2nd half of 2 - counter
3 & first half of 2- signed power/current
5&4-signed data...power/current
7&6-signed data...positive when driving...LOOKS LIKE SPEED/RPM...peak 5519 does not coincide with 43 mph or 69 kph though
8- always 00


----------



## JWardell

amund7 said:


> hmmm 6 lines of code to adapt CanbusAnalyzer to your files... I think I found a lot in 10 minutes


Flipping awesome! How do you know the labels for those data are correct though?
Please let me know what is needed for me to do the same with your software


----------



## amund7

JWardell said:


> Flipping awesome! How do you know the labels for those data are correct though?
> Please let me know what is needed for me to do the same with your software


I don't, this is interpreted with the Model S/X formulas (from Scan My Tesla). But some of these look right, such as the Mech Power HP, and torque. Charge and discharge, could those numbers be right for your car? The graphs seem like they could be in the right shape at least.

I just released an updated version of CanbusAnalyzer now, that supports the CSV files you sent (keep'em coming!)

This software is a tool originally created for Scan My Tesla development, to find new packets, and analyze / confirm the already known ones. It might not be so useful for Model 3, but once we get some traction and start getting a few can IDs under our belt, I can add them permanently to this software, and it should get the ball rolling.

I suppose you know a bit of software development, please open Visual studio with the project, go to Parser.cs, there you'll find all the packet definitions. There you can add your own formulas, that's how this tool was meant to be used, trial and error like that. (The Parser.cs file is a direct part of Scan My Tesla, and the intention was to test stuff on logs, then move it into the app once confirmed).

But you can also quickly interpret CAN ids as byte, word, int, or with the same formulas as already known packets.

I probably need to build a separate repository for the model 3 messages, not sure how to deal with this yet, looks like I need to separate it completely from Model S/X, as some of the can IDs overlap.

https://github.com/amund7/CANBUS-Analyzer main repository, and
https://github.com/amund7/CANBUS-Analyzer/releases latest releases. Just download the file 377.zip, it contains a windows installer. 
No hardware required, this only works with scanmytesla .txt 'raw logs' and 'can dumps', plus now your .csv format from 'CANopen Magic Ultimate 9.40'

Let me know if you need help with it, I know it's not exactly user friendly, all thrown together in a hurry


----------



## JWardell

amund7 said:


> I don't, this is interpreted with the Model S/X formulas (from Scan My Tesla). But some of these look right, such as the Mech Power HP, and torque. Charge and discharge, could those numbers be right for your car? The graphs seem like they could be in the right shape at least.
> 
> I just released an updated version of CanbusAnalyzer now, that supports the CSV files you sent (keep'em coming!)
> 
> This software is a tool originally created for Scan My Tesla development, to find new packets, and analyze / confirm the already known ones. It might not be so useful for Model 3, but once we get some traction and start getting a few can IDs under our belt, I can add them permanently to this software, and it should get the ball rolling.
> 
> I suppose you know a bit of software development, please open Visual studio with the project, go to Parser.cs, there you'll find all the packet definitions. There you can add your own formulas, that's how this tool was meant to be used, trial and error like that. (The Parser.cs file is a direct part of Scan My Tesla, and the intention was to test stuff on logs, then move it into the app once confirmed).
> 
> But you can also quickly interpret CAN ids as byte, word, int, or with the same formulas as already known packets.
> 
> I probably need to build a separate repository for the model 3 messages, not sure how to deal with this yet, looks like I need to separate it completely from Model S/X, as some of the can IDs overlap.
> 
> https://github.com/amund7/CANBUS-Analyzer main repository, and
> https://github.com/amund7/CANBUS-Analyzer/releases latest releases. Just download the file 377.zip, it contains a windows installer.
> No hardware required, this only works with scanmytesla .txt 'raw logs' and 'can dumps', plus now your .csv format from 'CANopen Magic Ultimate 9.40'
> 
> Let me know if you need help with it, I know it's not exactly user friendly, all thrown together in a hurry


Thanks, this is spectacular...so much less effort 
I don't have VS, is it possible to just edit the parser file or does it require recompile?
Perhaps add a mode switch so it can swap between S&X and 3 definitions?
Some of the messages look great, like 126, but most of the temps and voltage messages don't.
If you haven't already, look back at my first capture which is much more stationary but at least a second file. I will try to get another capture this week.

Do we expect steering wheel angle and torque to be on a different can bus? I think someone mentioned GPS is on a second bus as well? That would be next step too.


----------



## Bokonon

@amund7 Awesome project! Thanks for sharing this.

One suggestion in particular, though it may take some work...



JWardell said:


> I don't have VS, is it possible to just edit the parser file or does it require recompile?
> Perhaps add a mode switch so it can swap between S&X and 3 definitions?


...if you were to externalize the definitions found in Parser.cs (or at least allow an external configuration file to override those definitions), would that solve both of these issues?

It would allow people without Visual Studio to easily modify the definitions in a text editor with no need to recompile, and also provide an easy way to switch from one vehicle-specific set of definitions to another (e.g. Model 3-specific definition/overrides would live in one file, Model Y in another file, etc.)

The main challenge I see with this approach is finding a way to describe all of the possible parser behaviors, but it seems doable. I have VS (2015/v14, seems like you're using 2017/v15) and am happy to help if I can find a spare moment...


----------



## amund7

Visual Studio is free to download and use, parser file requires a recompile yes.
S and X has steering wheel angle, but not torque AFAIK. Also, nobody that I know has found the GPS coordinates, but many believe it is in there somewhere  I have hunted for it myself, but haven't found it.
I would guess, in the S and X, GPS coordinates have no reason to be on the powertrain bus, or on canbus at all, it should go on ethernet between the two screens just to show the map. That is my guess.

What I found a lot of in the S, on the powertrain bus surprisingly, is HVAC data, cabin temperatures, coolant temperatures, coolant valves and pumps etc.


----------



## amund7

Bokonon said:


> @amund7 Awesome project! Thanks for sharing this.
> 
> One suggestion in particular, though it may take some work...
> 
> ...if you were to externalize the definitions found in Parser.cs (or at least allow an external configuration file to override those definitions), would that solve both of these issues?


Parser.cs is taken directly from Scan My Tesla, the intention was to test that code with logs and graphs, and quickly make changes and additions to move back into the app. How this works is, all the readings/formulas are lambda expressions, stored as a list (or rather a dictionary), they are instantiated and stored at app startup, but is being run each time that can ID comes in. So, it should be doable to serialize these to XML, JSON or other formats, and de-serialize a file back. 
Not sure that file would be human-readable though, as it is actually code... probably binary or semi-compiled ?

What I know I have to do before getting started with a Model 3 app is to really separate the actual hex parser from the packet definitions, now they are way too intertwined.


----------



## JWardell

Yeah well a couple days wrestling with Excel trying to make it do things with Hex that I know could easily do with half a line of code make me not worry much for this.
Of course once I get Vector fired up and create database files this stuff should be easy, since it's designed to do exactly this.

I may not have time to decode more messages for now, the mean question is anyone else, though any of their methods, can find any additional pieces of useful data (or improve upon mine). 
Also those cycling messages are going to be difficult with anything but a custom coded program


----------



## brianman

JWardell said:


> 0x22A is fairly simple, showing a value that falls from 6073 to 6025.


Excel tells me the values are: 0x0000n917 where n is one of { 4, 5, 6, 7, 8, 9, A, B }.

Perhaps the 'n' represents the volume (4 - 11)?


----------



## brianman

JWardell said:


> ID 126
> The first two bytes are what I would expect voltage to look like (V*2?)
> The second two look like pedal position or maybe speed
> 1&2
> 3&4
> 5-8 flags


I took a look at the 0x126 implementation from GitHub and I had to squint a couple times to see what he was doing to handle negative values (which I think is unnecessary for voltage this early).

He's basically halving the voltage value you calculated -- resulting in a peak of 370.5V. I don't know if that's correct or if it should just be biased/offset instead.

Moving forward with the simple halving though -- both for the first two bytes as voltage and the next two bytes as amperage...

I see one power peak around message 36873 of 255.3 kW (370V x 69A) which seems reasonable for the single motor 3.

I see a second power peak around message 63931 of 266.80 kW (368V x 72.5A) which seems a bit high. If I use the -400 approach for voltage instead of /2, then the power comes in at 243.6 kW.

Further, I see some oddities around message 69486 with 335.5V at 396.5A, meaning 133 kW. Even if you were supercharging, that seems very high.

Switching to the -400 bias for voltage it becomes 271V, mapping to 107.4 kW which seems like a much more viable supercharging value.


----------



## brianman

JWardell said:


> a couple days wrestling with Excel trying to make it do things with Hex


In case you find it helpful, here's what the Voltage calculation looks like for one of the cells:


Code:


=HEX2DEC(T69139&S69139)/2

T69139 looks like this:


Code:


=MID($P69139,10,2)


----------



## brianman

JWardell said:


> 108
> Change kicks in at 34957
> 1 - data. Wild variation doesn't make sense, removed from chart
> 2nd half of 2 - counter
> 3 & first half of 2- signed power/current
> 5&4-signed data...power/current
> 7&6-signed data...positive when driving...LOOKS LIKE SPEED/RPM...peak 5519 does not coincide with 43 mph or 69 kph though
> 8- always 00


I see the same 5519 peak that you do for 7&6 (and -4 for the minimum). I would assume this maps to 55.19 mph. Does that value seem reasonable from your recollection of the drive?

The 5&4 value indeed appears to be power, with a peak of 15360 (153.6 kW) @ message 69057 and a max regen around just under 28 kW @ message 83760.


----------



## brianman

amund7 said:


> Parser.cs is taken directly from Scan My Tesla, the intention was to test that code with logs and graphs, and quickly make changes and additions to move back into the app. How this works is, all the readings/formulas are lambda expressions, stored as a list (or rather a dictionary), they are instantiated and stored at app startup, but is being run each time that can ID comes in. So, it should be doable to serialize these to XML, JSON or other formats, and de-serialize a file back.
> Not sure that file would be human-readable though, as it is actually code... probably binary or semi-compiled ?
> 
> What I know I have to do before getting started with a Model 3 app is to really separate the actual hex parser from the packet definitions, now they are way too intertwined.


The decoding part made some sense to me as I read through the code.

How to use the app itself was unclear to me. Can you elaborate? For example, talk through how to get to a chart for a given message ID over time or how to "fiddle" with the Intepret As part of the UI. Thanks.


----------



## amund7

brianman said:


> The decoding part made some sense to me as I read through the code.
> 
> How to use the app itself was unclear to me. Can you elaborate? For example, talk through how to get to a chart for a given message ID over time or how to "fiddle" with the Intepret As part of the UI. Thanks.


Will try:

- Load a file (it starts 'playing back' the file)
- Select 'bits & graph' tab
- Click a message in the left, a nice trick is to sort by description
Now you see graphs.
Invidividual signals can also be selected, or multiple packets, use ctrl-click. Screenshot for clarity, Model S log also for clarity:









To 'interpret as' is a bit fiddly:

- Click a CAN ID in the left pane
- Click the 'as byte' button
Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.
- Behold your graph









Now the 'copy ID' and 'interpret as' buttons need a packet to pre-exist so it can be selected, but with a model S log (or load a model S log before the 3 log) you could do:

- Select a known packet / with description in the left pane
- Click 'copy id' (button will now change into that ID)
- Click a blank/unknown packet ID
Repeat fiddly bits:
Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.

In this screenshot I have interpreted ID 118 with the formulas from ID 266:









Yeah, it could use some polishing, code contributions will be most appreciated.


----------



## brianman

amund7 said:


> Will try:
> 
> - Load a file (it starts 'playing back' the file)
> - Select 'bits & graph' tab
> - Click a message in the left, a nice trick is to sort by description
> Now you see graphs.
> Invidividual signals can also be selected, or multiple packets, use ctrl-click. Screenshot for clarity, Model S log also for clarity:
> 
> View attachment 19416
> 
> 
> To 'interpret as' is a bit fiddly:
> 
> - Click a CAN ID in the left pane
> - Click the 'as byte' button
> Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
> Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.
> - Behold your graph
> 
> View attachment 19417
> 
> 
> Now the 'copy ID' and 'interpret as' buttons need a packet to pre-exist so it can be selected, but with a model S log (or load a model S log before the 3 log) you could do:
> 
> - Select a known packet / with description in the left pane
> - Click 'copy id' (button will now change into that ID)
> - Click a blank/unknown packet ID
> Repeat fiddly bits:
> Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
> Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.
> 
> In this screenshot I have interpreted ID 118 with the formulas from ID 266:
> 
> View attachment 19418
> 
> 
> Yeah, it could use some polishing, code contributions will be most appreciated.


Ah, I think I understand it now. When you click as byte, word, etc. it adds sets of series to the packet/parser logic but it doesn't seem to take effect until you force a data reprocess (switch files, reload, etc.). So that's definitely something we could improve.

Some other nice improvements would be supporting:
- offset words (1,2 instead of 0,1)
- nibbles (4 bits)
- arbitrary irregular bit ranges (ex: bits 3-5 as a 3 bit signed value)

Big picture feature idea:
After manually teasing apart a message into bit ranges with interpretations (which bits, signed/unsigned, scaling, offsetting, units, expected valid range), (1) the ability to label those bits for export as new message parsing descriptor (and committing it to disk), (2) visually indicating the "undocumented" bits relative to all rules produced by (1), (3) indicate stats somewhere (status bar) capturing the "completeness" of the parsing descriptor set relative to (a) all data in the file and (b) all data in the file that doesn't have constant values throughout, and (4) indicate "invalid data" % somewhere in the UI for when "expected valid range" is violated by one or more messages.

With such a tool in hand, a number of hobby reverse engineering projects of my past would have been a lot easier. 

Edit: Hm. Maybe I should start logging these feature ideas with your repo.


----------



## JWardell

A little bit of fun at lunch time...who needs Pole Position? I have live data!

Another capture for you all to play with. Some reverse in here as well. Fun watching gages while driving but a bit hard trying to watch hex values and the parking lot at the same time!
https://www.dropbox.com/s/p6nl2b54uosnj2q/LiveCANrev.csv.zip?dl=0


----------



## JWardell

brianman said:


> I see the same 5519 peak that you do for 7&6 (and -4 for the minimum). I would assume this maps to 55.19 mph. Does that value seem reasonable from your recollection of the drive?
> 
> The 5&4 value indeed appears to be power, with a peak of 15360 (153.6 kW) @ message 69057 and a max regen around just under 28 kW @ message 83760.


Top speed of both runs was 43 mph. I have a scale factor of 0.0082 plugged in my gauge and that's fairly close, but there is probably more logic to that. If the measurement is RPM then there is gear ratio and other fixed factors in there before you get to speed.


----------



## JWardell

JWardell said:


> A little bit of fun at lunch time...who needs Pole Position? I have live data!
> 
> Another capture for you all to play with. Some reverse in here as well. Fun watching gages while driving but a bit hard trying to watch hex values and the parking lot at the same time!
> https://www.dropbox.com/s/p6nl2b54uosnj2q/LiveCANrev.csv.zip?dl=0


Trying to drive while looking at gauges, hold a camera, and hold my flailing laptop proved to be a bit of a challenge, but you are welcome to watch the event if you want:
Video is 4K so you should be able to zoom to see values when you stop the video (unless you have alien stabilization technology). Next time I need to just do this with a fix mounted GoPro...


----------



## fast_like_electric

JWardell said:


> Top speed of both runs was 43 mph. I have a scale factor of 0.0082 plugged in my gauge and that's fairly close, but there is probably more logic to that. If the measurement is RPM then there is gear ratio and other fixed factors in there before you get to speed.


Correct that the speed value in that ID is a 16 bit signed value, with byte 6 as LSB and byte 7 as MSB. Resolution: 1 bit = 1/128 MPH. Range of -256 to +255.9921875 MPH.


----------



## brianman

fast_like_electric said:


> Correct that the speed value in that ID is a 16 bit signed value, with byte 6 as LSB and byte 7 as MSB. Resolution: 1 bit = 1/128 MPH. Range of -256 to +255.9921875 MPH.


So scale of 0.0078125 and offset of -256 in DBC syntax.


----------



## fast_like_electric

brianman said:


> So scale of 0.0078125 and offset of -256 in DBC syntax.


Yes, in Vector DBC speak.

With the messages on the bus, you'll most often see scaling in powers or 2 or 10 (2,4,8,... 10,100,1000,...) and their fractional counterparts (1/2,1/4,1/8,... 0.1, 0.01, 0.001,...).


----------



## JWardell

One thing I'd really love to find is battery temperature (well I'm sure there are several). Useful in wrapping your head around several performance metrics as well as all the cold weather issues we are having.


----------



## Bokonon

JWardell said:


> One thing I'd really love to find is battery temperature (well I'm sure there are several). Useful in wrapping your head around several performance metrics as well as all the cold weather issues we are having.


Can we get a capture of a charging session with a cold-soaked battery (ideally, starting with the snowflake visible)? That should create conditions where battery temp rises rapidly at first while state of charge barely moves, later transitioning into rapidly increasing state of charge with relatively constant battery temp. We should be able to correlate the timeline with TeslaFi.

Only potential issue is that this is going to be a HUGE file, since the transition will probably take 10-20 minutes.


----------



## fast_like_electric

Bokonon said:


> Can we get a capture of a charging session with a cold-soaked battery (ideally, starting with the snowflake visible)? That should create conditions where battery temp rises rapidly at first while state of charge barely moves, later transitioning into rapidly increasing state of charge with relatively constant battery temp. We should be able to correlate the timeline with TeslaFi.
> 
> Only potential issue is that this is going to be a HUGE file, since the transition will probably take 10-20 minutes.


That CANopen Magic Ultimate trace format seems pretty verbose - a lot of unnecessary fields. Really all that is needed in a log is the timestamp, ID, and data. I've found the Vector trace format to be a bit more lean. 10 minutes on CAN3 during drive is about 80MB raw, much less when zipped. Also, when not in drive mode, there are a few less messages on the bus, so that would be smaller yet with just a charging log.


----------



## JWardell

Bokonon said:


> Can we get a capture of a charging session with a cold-soaked battery (ideally, starting with the snowflake visible)? That should create conditions where battery temp rises rapidly at first while state of charge barely moves, later transitioning into rapidly increasing state of charge with relatively constant battery temp. We should be able to correlate the timeline with TeslaFi.
> 
> Only potential issue is that this is going to be a HUGE file, since the transition will probably take 10-20 minutes.





fast_like_electric said:


> That CANopen Magic Ultimate trace format seems pretty verbose - a lot of unnecessary fields. Really all that is needed in a log is the timestamp, ID, and data. I've found the Vector trace format to be a bit more lean. 10 minutes on CAN3 during drive is about 80MB raw, much less when zipped. Also, when not in drive mode, there are a few less messages on the bus, so that would be smaller yet with just a charging log.


Yes, such a long capture of all CAN data would be monstrous. (And if you think this tool's logs are huge, the CSV files that come out of Vector are about 50x larger!)
But in both cases, I can apply filters, so *IF* we know what messages to log, I can log only those messages.

This is why determining what data is in what messages is so important, for many different end purposes. Same goes for making something to display things, you would quickly run out of CPU to process everything coming in.
That's why I'm trying to spread the word for folks to help locate and define data.


----------



## fast_like_electric

JWardell said:


> Yes, such a long capture of all CAN data would be monstrous. (And if you think this tool's logs are huge, the CSV files that come out of Vector are about 50x larger!)
> But in both cases, I can apply filters, so *IF* we know what messages to log, I can log only those messages.
> 
> This is why determining what data is in what messages is so important, for many different end purposes. Same goes for making something to display things, you would quickly run out of CPU to process everything coming in.
> That's why I'm trying to spread the word for folks to help locate and define data.


Unfortunately, you won't be able to start filtering by CAN ID until you know what you are looking for - kinda a paradox.

This is the Vector trace format I've typically seen/used, versus CANopen Magic...

Vector:
RX_MSG c=0, t=47178649, id=0263 l=8, 00996B5F5D7D9545 tid=00

CANopen Magic Ultimate:
"12937","8125.963","8:10:34:51.2531000'",43448.6496238036,"","0x263","","Default: PDO","","Default: RPDO 1 of Node 0x63 (99)","","00 88 72 CD D9 7D 71 1F ",". . r Í Ù } q . ","U:0 S:0","8","00 88 72 CD D9 7D 71 1F"

In any case, might I ask - what is the problem with a large trace log?


----------



## JWardell

fast_like_electric said:


> Unfortunately, you won't be able to start filtering by CAN ID until you know what you are looking for - kinda a paradox.
> 
> This is the Vector trace format I've typically seen/used, versus CANopen Magic...
> 
> Vector:
> RX_MSG c=0, t=47178649, id=0263 l=8, 00996B5F5D7D9545 tid=00
> 
> CANopen Magic Ultimate:
> "12937","8125.963","8:10:34:51.2531000'",43448.6496238036,"","0x263","","Default: PDO","","Default: RPDO 1 of Node 0x63 (99)","","00 88 72 CD D9 7D 71 1F ",". . r Í Ù } q . ","U:0 S:0","8","00 88 72 CD D9 7D 71 1F"
> 
> In any case, might I ask - what is the problem with a large trace log?


Excel chokes on a one meg CSV file. We would be talking about a gigabyte here.
Canopen magic has a lot of additional canopen fields that are not useful, unfortunately can't be configured to write only the time stamp and raw data.
You could also just use the free tools from PEAK or KVasser to get a simpler CAN dump.
Vector's native BLF log format is incredibly efficient. It logs a ton more than just CAN, and a 15MB log will export to ~150MB CSV which contains less data.

But yes, still need to work on IDing data. I'm hoping the three captures I have so far will help.


----------



## fast_like_electric

JWardell said:


> Excel chokes on a one meg CSV file. We would be talking about a gigabyte here.
> Canopen magic has a lot of additional canopen fields that are not useful, unfortunately can't be configured to write only the time stamp and raw data.
> You could also just use the free tools from PEAK or KVasser to get a simpler CAN dump.
> Vector's native BLF log format is incredibly efficient. It logs a ton more than just CAN, and a 15MB log will export to ~150MB CSV which contains less data.
> 
> But yes, still need to work on IDing data. I'm hoping the three captures I have so far will help.


I'm not familiar with how you are using that particular Vector program, but the super basic canlog.exe Vector program from circa 2003 outputs the compact format above. All of their other utilities in their CANLIB development package behave similarly. That data can easily be brought into Excel, setting the field delimiter to spaces when you do the data import. Or just replace all the space chars with commas and call it csv. Though I'd suggest post processing with a different utility before bringing into Excel with all that data. Can always remove frames or superfluous content easily - can't create them if they weren't logged.

In any case, a charging log would be handy to have - big or small.


----------



## JWardell

Perhaps a supercharge log where temperatures, currents, and voltages are changing rapidly would be most useful.
Furthermore without the motors running I bet a lot of messages are sent less often so maybe it won't be so bad.
I'll see what I can do next week. Too bad the supercharger by work is still in limbo.


----------



## Bokonon

JWardell said:


> But yes, still need to work on IDing data. I'm hoping the three captures I have so far will help.


I haven't gotten a chance to compare the third capture with the previous two, but hopefully I can get to it tonight or tomorrow night.

As for identifying battery temperature and charge-related IDs, what about two smaller captures as an exploratory exercise? Something like this:

Initial state: car is parked, not plugged in, target SoC % set below the current SoC %. Battery is cool, if not cold.

1. Start capture 1.
2. Plug in car.
3. Set target SoC % above current SoC %.
4. Allow charging to begin.
5. Wait a minute or two.
6. Stop capture 1.
7. Let the car continue charging for a while so the battery has a chance to warm up. 
8. Start capture 2.
9. Stop charging by setting the target SoC % back to its original value.
10. Wait a minute or two.
11. Stop capture 2.

By comparing either of these captures with the prior captures (an easy exercise with a database), we should be able to identify all IDs unique to the charging process. That would be a start.

We should also be able to splice the two charging captures together (or at least plot and compare them) to see what's going on at the beginning and end of the charging process. We know how we expect values like battery temperature, SoC %, charge current/voltage to behave at the beginning and end of a charging session, so this could narrow the field of possibilities without having to analyze the entire session.


----------



## JWardell

amund7 said:


> Will try:
> 
> - Load a file (it starts 'playing back' the file)
> - Select 'bits & graph' tab
> - Click a message in the left, a nice trick is to sort by description
> Now you see graphs.
> Invidividual signals can also be selected, or multiple packets, use ctrl-click. Screenshot for clarity, Model S log also for clarity:
> 
> View attachment 19416
> 
> 
> To 'interpret as' is a bit fiddly:
> 
> - Click a CAN ID in the left pane
> - Click the 'as byte' button
> Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
> Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.
> - Behold your graph
> 
> View attachment 19417
> 
> 
> Now the 'copy ID' and 'interpret as' buttons need a packet to pre-exist so it can be selected, but with a model S log (or load a model S log before the 3 log) you could do:
> 
> - Select a known packet / with description in the left pane
> - Click 'copy id' (button will now change into that ID)
> - Click a blank/unknown packet ID
> Repeat fiddly bits:
> Fiddly bit 1: Unselect and re-select the CAN ID in the left pane again (to force refresh the graph and signals)
> Fiddly bit 2: Might have to reload the file, or click the << or >> to load the next/previous file in that folder, to stream some new data.
> 
> In this screenshot I have interpreted ID 118 with the formulas from ID 266:
> 
> View attachment 19418
> 
> 
> Yeah, it could use some polishing, code contributions will be most appreciated.


I'm just playing around with this a bit, and trying to look at unknown IDs. 
I figured out that I can click an ID, click interpret as byte or word, then reload the whole file and the graphs appear.
What are the two checkboxes next to the ID?
Is there a way to save the decision to decode certain packets?
Is there a way to decode sizes and locations other than 8 bytes or 4 words?
At one point I clicked one of the top buttons and the program just crashed and exited. Whoops.
But this is a lot faster than trying to explore things with excel!

See below as I managed to get with ID 132


----------



## brianman

Some thoughts:
1. I'd like to make a request from whoever can do capturing to do some small and directed captures for "simple" scenario sequences, to give us targeted data to filter though to tease out the "easy" to decode messages. Examples include sessions that do only one task such as opening doors, changing music volume/balance/fade/source, change climate temperature/direction/defrosting/etc., switch driver profile, change a bunch of settings in a single driver profile. In the previous sentence each comma represents a split between capturing sessions.
2. @JWardell - A good step would be to collect the ideas as individual feature requests that we capture on GitHub or elsewhere. IMO, each feature request should describe the goal / intent of the scenario and optionally suggest ways that the author considered/recommends; it's key to not treat the suggestions as requirements, but rather as an option to address the scenario goals.
3. I'm hacking away at CANBUS-Analyzer repo locally and discussing some ideas with the owner. Hopefully it will be a fruitful collaboration.


----------



## fast_like_electric

brianman said:


> Some thoughts:
> 1. I'd like to make a request from whoever can do capturing to do some small and directed captures for "simple" scenario sequences, to give us targeted data to filter though to tease out the "easy" to decode messages. Examples include sessions that do only one task such as opening doors, changing music volume/balance/fade/source, change climate temperature/direction/defrosting/etc., switch driver profile, change a bunch of settings in a single driver profile. In the previous sentence each comma represents a split between capturing sessions.
> 2. @JWardell - A good step would be to collect the ideas as individual feature requests that we capture on GitHub or elsewhere. IMO, each feature request should describe the goal / intent of the scenario and optionally suggest ways that the author considered/recommends; it's key to not treat the suggestions as requirements, but rather as an option to address the scenario goals.
> 3. I'm hacking away at CANBUS-Analyzer repo locally and discussing some ideas with the owner. Hopefully it will be a fruitful collaboration.


Good idea - like the concept. One comment - the scenarios you mention won't result in messaging on the bus that is currently being logged. Messages related to doors / radio / climate / etc are on the Body CAN bus, not the Powertrain bus. That bus hasn't been investigated yet - at least on this thread. The Powertrain bus primarily has messaging related to the motor drives and the battery system. There are also some gateway'd messages that are useful for fault recording by the electronics involved with those systems (such as the time broadcast). You'll mainly see things like gear position, torque, power, etc on this bus.


----------



## Ajandmj1

So I'm a noob and this is entire forum is a little confusing but extremely fascinating. I was just curious to see if trouble codes could be read through the CAN system or if that's it's own system entirely? Keep up the good work guys (not all heros wear capes)


----------



## JWardell

My wife has taken the car for out-of-state drives for the next few days, but I swear @brianman when I get it back I will do captures during several situations including charging as well as the CAN other busses over the next week. Please stay tuned.
I also plan to start building the Vector project and start some Arduino development during my week off. If I can only get my car back from my wife...


----------



## amund7

I just had a half crazy idea; I could make a quickly hacked version of Scan My Tesla bypass the initial wait-for-model-S-init-trip-counters, then it should be able to do CAN dumps of all packets from model 3. That is, if someone has a way to connect an OBD2 adapter to the bus (can-crocodile)?

If that can be done, then the logs will be pure hex, no timestamp, no other nonsense. My can dumps (from model s) are 20, 30, 100 mb at the most, never gigabytes, maybe if you drove a full day trip.
I am however contemplating implementing the time stamp, because it would be very useful for both graphing, analyzing and archiving (I just built a big database of all my model S logs during 2 years, and placed everything on the timeline, so you can query which software version came when, what day was the battery the coldest etc)


----------



## amund7

JWardell said:


> I'm just playing around with this a bit, and trying to look at unknown IDs.
> I figured out that I can click an ID, click interpret as byte or word, then reload the whole file and the graphs appear.
> What are the two checkboxes next to the ID?
> Is there a way to save the decision to decode certain packets?
> Is there a way to decode sizes and locations other than 8 bytes or 4 words?
> At one point I clicked one of the top buttons and the program just crashed and exited. Whoops.
> But this is a lot faster than trying to explore things with excel!
> 
> See below as I managed to get with ID 132


Checkbox1 = just means this packet is recognized.
Checkbox2 was meant as a bookmark/reminder, come back to this one. Useful when you cross examine several packets, you can sort by that column as well to find the ones you marked.

None of this, including the formulas you make are saved. This program was meant for me to, once I find something interesting by poking around the data, go into visual studio and start programming the formulas, then re-compile and test those formulas on the log data.

Brianman is looking into a lot of this, he already fixed a lot of bugs, and it seems like he has lots of new ideas for this software, so it might be going places and becoming more useful for all of you


----------



## fast_like_electric

Ajandmj1 said:


> So I'm a noob and this is entire forum is a little confusing but extremely fascinating. I was just curious to see if trouble codes could be read through the CAN system or if that's it's own system entirely? Keep up the good work guys (not all heros wear capes)


Retrieval of trouble codes (DTCs) over CAN is likely possible, but unknown method at this time. Effort so far has been to just look at the normal bus traffic. Just looking at messaging, not sending anything extra.

It is a likely that OBD2 style J1979 & J2190 type PIDs & DTCs exist in some form on the CAN buses. They aren't on the typical ECU addresses (7xx IDs are occupied by other messaging), but they are likely hiding elsewhere. Could potentially be available using 29 bit CAN IDs, or something like that.

There are videos which show UDS (Unified Diagnostic Services) information available on the center screen. Someone with access to this screen could log the CAN traffic when accessing the UDS information items. However, access to the diagnostic screen for an owner is not easy - involves rooting, software exploits, etc.


----------



## 96s46p

Good stuff so far. So do we know the full pinout of the center console connector yet? I unplugged it the other day for a minute and nothing happened, no warning. I didn't try to drive or anything of course. Does the female connector demount from the center console? Is there a locking tab + slide?

We should have a collaborative spreadsheet (preferably hosted and easily viewable) of all known (to exist) PIDs, message frequency, and codings (once known). Anyone want to start it?


----------



## JWardell

96s46p said:


> Good stuff so far. So do we know the full pinout of the center console connector yet? I unplugged it the other day for a minute and nothing happened, no warning. I didn't try to drive or anything of course. Does the female connector demount from the center console? Is there a locking tab + slide?
> 
> We should have a collaborative spreadsheet (preferably hosted and easily viewable) of all known (to exist) PIDs, message frequency, and codings (once known). Anyone want to start it?


I'm shocked (pun intended) nothing happened if the connector was unplugged. If it feeds the security module, I doubt you would be able to unlock the car or put into to drive, not to mention errors logged and sent back, but who knows.

Right now I just have a notes text file with comments on each ID I've investigated, and all of that was copied into the posts above along with charts. I would be happy to put that all into a spread sheet form that can be shared by others...stay tuned. I would like some way to allow for varying confidence and multiple guesses. I'm also in process of building a DBC file with the same information. As I've said repeatedly, I would very much appreciate any help from others in figuring out what data maps to.


----------



## Bokonon

JWardell said:


> Another capture for you all to play with. Some reverse in here as well. Fun watching gages while driving but a bit hard trying to watch hex values and the parking lot at the same time!


Interestingly, a new message ID appeared in this session that did not appear in your prior two sessions: ID 0x201. It was logged 2451 times, roughly every 50ms from start to finish. Was there anything active in this drive that wasn't active in either of the other two? Something like a seat heater?

At a glance, it seems like it is a two-part message, alternating between two sets of values. Here are the first eight messages, as an example:

28 06 19 00 B8 91 01 00
B1 0A 20 C0 02 D0 D0 00
28 06 19 00 B8 91 01 00
B1 0A 20 C0 02 D0 D0 00
40 66 19 00 B8 91 01 00
B9 0A 20 C0 02 D0 D0 00
28 06 19 00 B8 91 01 00
B9 0A 20 C0 02 D0 D0 00

With the first part of the message, bytes 2 -8 remain constant (0A 20 C0 02 D0 D0 00), while byte 1 has the following values, increasing in a drunk-man's-walk sort of way:

B1
B9
C1

The second part of the message has a few more moving parts.

Bytes 1 and 2 are all over the place with no discernible pattern. A graph would be helpful!
Byte 3 goes through two or three gradual up-and-down cycles, starting at 19, increasing to 38, then decreasing to 1F, then up to 39, then down to 20, then briefly back up to 30, and finally down to 1C. The period of the cycles shortens over the course of the session.
Byte 4 is constant (00).
Byte 5 decreases from B8 to B6, hitting B4 a few times near the end.
Bytes 6-8 are constant (91 01 00).


----------



## JWardell

Bokonon said:


> Interestingly, a new message ID appeared in this session that did not appear in your prior two sessions: ID 0x201. It was logged 2451 times, roughly every 50ms from start to finish. Was there anything active in this drive that wasn't active in either of the other two? Something like a seat heater?
> 
> At a glance, it seems like it is a two-part message, alternating between two sets of values. Here are the first eight messages, as an example:
> 
> 28 06 19 00 B8 91 01 00
> B1 0A 20 C0 02 D0 D0 00
> 28 06 19 00 B8 91 01 00
> B1 0A 20 C0 02 D0 D0 00
> 40 66 19 00 B8 91 01 00
> B9 0A 20 C0 02 D0 D0 00
> 28 06 19 00 B8 91 01 00
> B9 0A 20 C0 02 D0 D0 00
> 
> With the first part of the message, bytes 2 -8 remain constant (0A 20 C0 02 D0 D0 00), while byte 1 has the following values, increasing in a drunk-man's-walk sort of way:
> 
> B1
> B9
> C1
> 
> The second part of the message has a few more moving parts.
> 
> Bytes 1 and 2 are all over the place with no discernible pattern. A graph would be helpful!
> Byte 3 goes through two or three gradual up-and-down cycles, starting at 19, increasing to 38, then decreasing to 1F, then up to 39, then down to 20, then briefly back up to 30, and finally down to 1C. The period of the cycles shortens over the course of the session.
> Byte 4 is constant (00).
> Byte 5 decreases from B8 to B6, hitting B4 a few times near the end.
> Bytes 6-8 are constant (91 01 00).


Nice find. You can see in the video seats weren't on, nothing should be different however...I did update from 46.2 to 48.12.1 the night before my last recording. Maybe the fart app has its own message


----------



## Bokonon

JWardell said:


> Nice find. You can see in the video seats weren't on, nothing should be different however...I did update from 46.2 to 48.12.1 the night before my last recording. Maybe the fart app has its own message


Whoops! I didn't see the video with your narration until now, I was just going by the screen capture from your laptop.

Interesting that this message is new in 48.12.1... guess we should probably track the firmware version associated with each capture, unless you're expecting Santa to drop a complete DBC file in your stocking.


----------



## JWardell

I've started a Google Docs spreadsheet for CAN IDs here

I haven't finished entering my own data yet but will continue to update it.
I'm welcome to comments on the format. As data varies and some are packed with difference sizes it's a little more textual. I use red/orange/yellow/green fills to indicate confidence. I'll put each CAN network on a separate sheet. And those annoying cyclic IDs will get listed with separate lines, for example 405 with the VIN.



Bokonon said:


> Whoops! I didn't see the video with your narration until now, I was just going by the screen capture from your laptop.
> 
> Interesting that this message is new in 48.12.1... guess we should probably track the firmware version associated with each capture, unless you're expecting Santa to drop a complete DBC file in your stocking.


Chances are the version is in that CAN data somewhere! And yes, *PLEASE SANTA BRING ME A MODEL 3 DBC FILE!* I'll leave out the cookies and milk.


----------



## amund7

Here is the complete signal list for Scan My Tesla, I have put an 'accuracy score' and some comments on each.
Scan My Tesla signal list


----------



## JWardell

A new CAN trace fresh off the presses a few minutes ago, charging a cold battery:
https://www.dropbox.com/s/75elbetuuxud8n3/ColdBattCharge.csv.zip?dl=0

Warning: It's 165MB
I haven't looked at it yet, but just watching live I could clearly see negative currents in byte 132 when the battery was charging.
Here is the log of what occurs:
[pre-log]
Overnight temps 30-35F
Wake up car and turn on climate
Open doors, connect CAN, start software
Unlplug charger [Note: Mobile charger plugged into house, ~200V limited to 24A]
Turn target charge way down so charging doesn't start immediately
[start log]
plug in.
Note despite charging not activating, current draw ramps to 11A. Must be starting to heat battery
Wait a bit, then set target charge high so charging starts
Current on display ramps to 24A
See about -11A on byte 132. Probably sending half power to continue heating battery, half power to charge.
Log for a bit.
Press Stop Charging button on display
Display goes to 0A. 132 goes to +1.5A.
Press Start Charging button on display
Display goes to 24A. 132 goes to ~ -11A
[stop log]

Here is accompanying data from Teslafi:


----------



## JWardell

amund7 said:


> Here is the complete signal list for Scan My Tesla, I have put an 'accuracy score' and some comments on each.
> Scan My Tesla signal list


These are signals for Model S, correct? So we should try to see if we can match to any of these?


----------



## amund7

JWardell said:


> These are signals for Model S, correct? So we should try to see if we can match to any of these?


Yes.

I think some of them work directly, such as 154 and 266 (both hex). Otherwise I thought it could be useful to know what to expect, probably model 3 has more or less the same information on the bus, just encoded differently.


----------



## JWardell

amund7 said:


> Yes.
> 
> I think some of them work directly, such as 154 and 266 (both hex). Otherwise I thought it could be useful to know what to expect, probably model 3 has more or less the same information on the bus, just encoded differently.


Some might not line up, but it will definitely be very helpful, thanks.


----------



## JWardell

amund7 said:


> Here is the complete signal list for Scan My Tesla, I have put an 'accuracy score' and some comments on each.
> Scan My Tesla signal list


So I'm comparing this list to the sample Tesla DBC that I found (which has very few IDs). I'm guessing that DBC is from roadster because it doesn't line up with the scan my Tesla list.

For example, RPM is at ID 108 bit 32 in the DBC file, ID 106 in the Scan My Tesla spreadsheet (which doesn't list start bits!), and ID 108 bit 40 in the Model 3.


----------



## brianman

JWardell said:


> sample Tesla DBC that I found (which has very few IDs). I'm guessing that DBC is from roadster because it doesn't line up with the scan my Tesla list.


Are you talking about the one from https://github.com/commaai/opendbc?


----------



## ScottStout1

Have you guys already found the right port adapter? Wondering if the photo here helps. 

__
https://www.reddit.com/r/teslamotors/comments/a8sj5x


----------



## 96s46p

I wish you could just buy that extension cable somewhere. Which wires are they splitting out?


----------



## brianman

amund7 said:


> Here is the complete signal list for Scan My Tesla, I have put an 'accuracy score' and some comments on each.
> Scan My Tesla signal list


Can you add the "which bits" data for the signals in each message? With that in place, I think I could make progress on a tool to convert the data to DBC format.


----------



## JWardell

I'm staying up to see if Santa brings me a DBC file. Only a few minutes left...
Merry Christmas everyone!


----------



## JWardell

Well, Santa never showed, but thanks to a bit of number crunching, now multiple logs to prove data, and the help of many of you folks putting heads together, I now have some fairly confident data for *HV Battery voltage, 12v voltage, Battery current, Speed/RPM, and odometer*!
Thank you all for the help!

Please have a look at the updated spreadsheet

Here's what my live view now looks like (playing back my acceleration file):









And thanks to that CAN Analyzer software, it even chugs through the giant battery charging log to show nice battery current and voltage graphs:


----------



## amund7

Best. Christmas. Ever.


----------



## brianman

JWardell said:


> Please have a look at the updated spreadsheet


It will be fairly manual, but I think I can craft a DBC file from this.

Can you provide some good data samples (or identify which of the previous attachments are good) to validate against?


----------



## JWardell

brianman said:


> It will be fairly manual, but I think I can craft a DBC file from this.
> 
> Can you provide some good data samples (or identify which of the previous attachments are good) to validate against?


I already have known data in a DBC, although I haven't hooked up live with Vector to test it yet.


----------



## brianman

JWardell said:


> I already have known data in a DBC, although I haven't hooked up live with Vector to test it yet.


I'm prototyping a version of CANBUSAnalyzer that works with DBCs. Can you share your Model 3 DBC?


----------



## JWardell

fast_like_electric said:


> Correct that the speed value in that ID is a 16 bit signed value, with byte 6 as LSB and byte 7 as MSB. Resolution: 1 bit = 1/128 MPH. Range of -256 to +255.9921875 MPH.


Your information for the ID 108 speed makes logical sense with 1/128 resolution (0.0078125 multiplier) but it doesn't quite hit the speeds that I saw on the the display. I was closer with a 0.0082 multiplier. But, I'm wondering if this is real measures speed before artificial liability percentage added as most carmakers do. Curious your confidence or how you arrived at that....and what else have you found


----------



## JWardell

brianman said:


> I'm prototyping a version of CANBUSAnalyzer that works with DBCs. Can you share your Model 3 DBC?


Let me plug in some updates, watch your PM because I'm not ready to push that public yet


----------



## fast_like_electric

JWardell said:


> Your information for the ID 108 speed makes logical sense with 1/128 resolution (0.0078125 multiplier) but it doesn't quite hit the speeds that I saw on the the display. I was closer with a 0.0082 multiplier. But, I'm wondering if this is real measures speed before artificial liability percentage added as most carmakers do. Curious your confidence or how you arrived at that....and what else have you found


I believe the 0.0082 scaling is high. That actual CAN parameter is axle speed, with a resolution of 0.1 RPM / bit. Translation to true MPH is dependent on tire circumference, but in the range of around 762 to 768 revolutions per mile, depending on tire size for a given wheel size. Treadwear factors in as well. I used the 768 number (60 [min/hour] / 768 [rev/mi] * 0.1 = 0.0078125), but as they say, your mileage will vary - if you want to use that parameter for vehicle speed. You can use a site like this to do an approximation of tire parameters...

https://www.tyresizecalculator.com/tyre-wheel-calculators/tire-size-calculator-tire-dimensions
https://tiresize.com/calculator/

With a scaling of 0.0082, that would be assuming a tire circumference equating to 731 rev/mi, which I think is on the high side. Could also check the actual tire specs for what is on the car too, rather than use an estimator. But in any case, that's getting you true MPH, not what the UI displays. Yes, for MPH display there would typically be a safety fudge factor as well.


----------



## amund7

JWardell said:


> Well, Santa never showed, but thanks to a bit of number crunching, now multiple logs to prove data, and the help of many of you folks putting heads together, I now have some fairly confident data for *HV Battery voltage, 12v voltage, Battery current, Speed/RPM, and odometer*!
> Thank you all for the help!
> 
> Please have a look at the updated spreadsheet


I can't make sense of the odometer at 3B2, is there a typo in that packet ID ? I only get super crazy values, all bytes scrambling like random.


----------



## 96s46p

amund7 said:


> I can't make sense of the odometer at 3B2, is there a typo in that packet ID ? I only get super crazy values, all bytes scrambling like random.


He meant 0x3B6


----------



## JWardell

fast_like_electric said:


> I believe the 0.0082 scaling is high. That actual CAN parameter is axle speed, with a resolution of 0.1 RPM / bit. Translation to true MPH is dependent on tire circumference, but in the range of around 762 to 768 revolutions per mile, depending on tire size for a given wheel size. Treadwear factors in as well. I used the 768 number (60 [min/hour] / 768 [rev/mi] * 0.1 = 0.0078125), but as they say, your mileage will vary - if you want to use that parameter for vehicle speed. You can use a site like this to do an approximation of tire parameters...
> 
> https://www.tyresizecalculator.com/tyre-wheel-calculators/tire-size-calculator-tire-dimensions
> https://tiresize.com/calculator/
> 
> With a scaling of 0.0082, that would be assuming a tire circumference equating to 731 rev/mi, which I think is on the high side. Could also check the actual tire specs for what is on the car too, rather than use an estimator. But in any case, that's getting you true MPH, not what the UI displays. Yes, for MPH display there would typically be a safety fudge factor as well.


Remember I'm not trying to match it to actual speed, but what is displayed on the screen. So it should be a particular value, not having to do with tire dimensions, as the display would be making the same conversion. But as I said, it is common for speedometers to add a few percent on to the car's calculated value to be on the safe side of tire variability.


----------



## fast_like_electric

JWardell said:


> Remember I'm not trying to match it to actual speed, but what is displayed on the screen. So it should be a particular value, not having to do with tire dimensions, as the display would be making the same conversion. But as I said, it is common for speedometers to add a few percent on to the car's calculated value to be on the safe side of tire variability.


Right. But at faster MPH's (say 80 MPH), using a 0.0082 scale factor on the rear axle RPM value will not match the MPH display (for me anyway).

Ideally I would think you'd want to use an actual vehicle speed CAN frame instead of converting RPM. Of course, the vehicle speed frame will need to be located.

Great progress - keep up the good work.


----------



## Bokonon

JWardell said:


> A new CAN trace fresh off the presses a few minutes ago, charging a cold battery


As you'd expect, this session has a lot of new message IDs that we haven't seen before. The analysis that follows covers only these new IDs.

*Session-long Repeaters*

The following IDs first appear around 22 seconds and are logged for the remainder of the session. Periods are noted for each.

0x338 (1000 ms) - constant 00 00 00 00 00 00 00 00

0x31C (100 ms) - constant with minor fluctuations in bytes 2 and 3 - a voltage?

0x505 (100 ms) - repeats the same 7 values in a loop:

00 03 5A 9A CE 6B 00 00
0B 00 00 00 00 00 7D 20
19 31 30 39 39 33 34 34
1A 2D 30 30 2D 43 00 00
1B 00 00 00 00 00 00 00
1D 56 4C 58 31 37 33 34
1E 31 31 30 38 30 38 34
0x32C (100 ms) - Steadily increasing values in bytes 3-6 - charge energy added? pack voltage? or (gasp) pack temperature? (sorry, stepping beyond my comfort zone here...  ... though I'd imagine pack voltage and temperature would be reported even when not charging)

0x214 (1000 ms) - constant 00 0F 00 A0 00 00 00 00

0x51E (100 ms) - Repeats the same 12 values in a loop:

14 05 00 00 00 00 00 00
19 31 31 30 31 37 38 39
1A 2D 38 31 2D 46 00 00
1B 00 00 00 00 00 00 00
16 00 00 00 0D 24 8C A3
0A 01 01 00 01 00 84 00
0B 00 01 01 00 00 FF FF
0D 00 00 00 1A C8 BF 34
11 E5 97 1F 4E E0 CA 83
12 29 7E 0F 5A 47 48 D1
13 01 01 04 03 01 00 00
0F 00 00 00 27 5A 6C 5C
0x514 (100 ms) - Repeats the same 3 values in a loop:

01 39 31 37 35 38 32 30
02 00 00 00 00 00 00 00
00 41 4C 4D 31 38 30 36
*One-off Messages*

Starting around 338 seconds (i.e. around 10:51 am), there's an event that occurs that changes the messaging a bit. (I'm guessing that this is the point at which you hit the Stop Charging button?)

At 338 seconds, the following one-time message is logged:

0x424 - 53 80 00 00 00 00 00 00

Between 340.181 and 340.200 seconds, the following six one/two-time messages are logged. I'll group them by ID and list them in order of first appearance here, because I get the sense that they are multi-part. Note that the values for the first three message IDs are the same as the values for the last three.

0x624 - 03 22 0E 00 55 55 55 55
0x624 - 30 00 0A 55 55 55 55 55

0x625 - 10 0D 62 0E 00 00 00 00
0x625 - 21 00 00 00 00 00 00 00

0x5C8 - 1F 00 00 00 00 00 00 00

0x5A8 - 1F 00 00 00 00 00 00 00 (same as 0x5C8 above)

0x626 - 03 22 0E 00 55 55 55 55 (same as 0x624 above)
0x626 - 30 00 0A 55 55 55 55 55 (same as 0x624 above)

0x627 - 10 0D 62 0E 00 00 00 00 (same as 0x625 above)
0x627 - 21 00 00 00 00 00 00 00 (same as 0x625 above)

Similarly, between 343.261 and 343.355 seconds, the following ten one/two-time messages are logged. Note that values in this set of messages are the same as the values in the prior set:

0x600 - 03 22 0E 00 55 55 55 55
0x600 - 30 00 0A 55 55 55 55 55

0x601 - 10 0D 62 0E 00 00 00 00
0x601 - 21 00 00 00 00 00 00 00

0x534 - 1F 00 00 00 00 00 00 00

0x622 - 03 22 0E 00 55 55 55 55
0x622 - 30 00 0A 55 55 55 55 55

0x623 - 10 0D 62 0E 00 00 00 00
0x623 - 21 00 00 00 00 00 00 00

0x608 - 03 22 0E 00 55 55 55 55
0x608 - 30 00 0A 55 55 55 55 55

0x609 - 10 0D 62 0E 00 00 00 00
0x609 - 21 00 00 00 00 00 00 00

0x60A - 03 22 0E 00 55 55 55 55
0x60A - 30 00 0A 55 55 55 55 55

0x60B - 10 0D 62 0E 00 00 00 00
0x60B - 21 00 00 00 00 00 00 00

0x530 - 1F 00 00 00 00 00 00 00

At 343.376 seconds, the following two cyclical messages are logged for the remainder of the session (average period noted):

0x628 (90ms or 180 ms) - seems to be two-part
0x629 (10ms) - lots of repeating values

Finally, at 344 seconds, the following one-time message is logged:

0x515 - 1F 00


----------



## rootandy

Did somebody already have the idea to let the streaming API run parallel to a CAN-Bus Logger and then try to match the data? With a little delay the data should match at some point. Or am I missing something?

What OS are you using for logging the data? If Linux maybe I can help with some small tool (candump + api requesting tool in combination logging to a single file in some user defined format).


----------



## brianman

rootandy said:


> Did somebody already have the idea to let the streaming API run parallel to a CAN-Bus Logger and then try to match the data? With a little delay the data should match at some point. Or am I missing something?


AFAIK, nobody has gotten the streaming API to work for Model 3. For Model S/X, this approach could be quite useful.


----------



## rootandy

brianman said:


> AFAIK, nobody has gotten the streaming API to work for Model 3. For Model S/X, this approach could be quite useful.


Ok I didn't know the Model 3 has no streaming API. And are the data of the standard API present, like for Model S/X?


----------



## JWardell

Bokonon said:


> As you'd expect, this session has a lot of new message IDs that we haven't seen before. The analysis that follows covers only these new IDs.


Thanks. I am going to look at some of those messages next...

Last night I tried stabbing randomly at several messages with the CAN Analyzer software. Almost everything is uselessly jumping around because of all these cycling messages.
*We REALLY need a way to separate or view all these cycling messages!*

Here is what I found interesting:
ID 252 word 0 (2nd and 1st bytes)-0 when not charging or driving, Rising from 1750-1800 when charging (back to zero when I stopped quickly), also rising 5200-5300 when driving.

ID 556 1, 2, 3 all rise with currant ramp or charge level even though they are bouncing/cycling



rootandy said:


> Did somebody already have the idea to let the streaming API run parallel to a CAN-Bus Logger and then try to match the data? With a little delay the data should match at some point. Or am I missing something?
> 
> What OS are you using for logging the data? If Linux maybe I can help with some small tool (candump + api requesting tool in combination logging to a single file in some user defined format).


I'm not familiar with what the streaming API is.


----------



## Bokonon

JWardell said:


> I'm not familiar with what the streaming API is.


It's a separate HTTP API that provides vehicle telemetry in 250 ms intervals. Model 3. It stopped working for Model 3 (and apparently some newer Model S) after a firmware update earlier this year.

https://github.com/timdorr/tesla-api/issues/68



JWardell said:


> *We REALLY need a way to separate or view all these cycling messages!*


Would it be more helpful to have the combined data grouped together as if it were a single >= 16-byte message, or treat each segment as if it were its own message?

It would be nice to add these capabilities to CANBusAnalyzer but I still haven't had a chance to sit down look at that repo yet.


----------



## JWardell

Bokonon said:


> Would it be more helpful to have the combined data grouped together as if it were a single >= 16-byte message, or treat each segment as if it were its own message?
> 
> It would be nice to add these capabilities to CANBusAnalyzer but I still haven't had a chance to sit down look at that repo yet.


That depends on what the data represents. Is it cycling between different items (each pack of battery cells for example) or is it packing a large piece of data into one ID?


----------



## scottf200

JWardell said:


> I managed to capture a 2-3 minute trace of data simply turning on, pulling forward, then back again...and the CSV file is a whopping 35 megs! Lots of data here!
> 
> I've compared messages to the Model S CAN PDF and sadly, I don't think any data coincides. Only. a few IDs are common, and the data doesn't look the same.
> 
> Furthermore there are _hundreds_ of unique IDs, so decoding this is going to be extremely difficult.
> 
> Any Excel wizards/data scientists out there feel free to get in touch and I would be happy to send along the CSV.
> 
> I'm going to have to separate and export each ID and then see if any data changes over time with simple things like speed and pedal position.





Bokonon said:


> Egads! That's quite a firehose. We need to get this into a queryable repository pronto!
> 
> Happy to help with data and tools for making sense of it.
> 
> Do any of the off-the-shelf CAN software packages accept CSV or other file input, or do they require a live connection to the bus?


Consider working with the developer for "Scan My Tesla". They have started a canbus analyzer tool which is on github:
https://teslamotorsclub.com/tmc/thr...reader-for-android.112636/page-7#post-2947744

I use their "Scan My Tesla" app in my model X. It is impressive. I mentioned it here: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/#post-119539


----------



## JWardell

@Bokonon I looked at those IDs with CANbus Analyzer, the one piece of interesting data:
ID 32C 6th byte slowly rises. When using the temperature algorithm, Temp 6 rises from 24 to 77 which could be believable for something.



scottf200 said:


> Consider working with the developer for "Scan My Tesla". They have started a canbus analyzer tool which is on github:
> https://teslamotorsclub.com/tmc/thr...reader-for-android.112636/page-7#post-2947744
> 
> I use their "Scan My Tesla" app in my model X. It is impressive. I mentioned it here: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/#post-119539


That's what we're trying to use


----------



## 96s46p

Bokonon said:


> Would it be more helpful to have the combined data grouped together as if it were a single >= 16-byte message, or treat each segment as if it were its own message?


It's hard to say because you have messages like this where the first byte seems obvious as an index/offset
0x514 (100 ms) - Repeats the same 3 values in a loop:

00 41 4C 4D 31 38 30 36
01 39 31 37 35 38 32 30
02 00 00 00 00 00 00 00
This is the charger serial number.

Then you have other messages where the first byte is more random.


----------



## 96s46p

0x51E (100 ms) - Repeats the same 12 values in a loop:

14 05 00 00 00 00 00 00
19 *31 31 30 31 37 38 39*
1A *2D 38 31 2D 46* 00 00
This is the charger part number 1101789-81-F

0x505 (100 ms) - repeats the same 7 values in a loop:

00 03 5A 9A CE 6B 00 00
0B 00 00 00 00 00 7D 20
19 *31 30 39 39 33 34 34*
1A *2D 30 30 2D 43* 00 00
This is the part number of the 14-50 adapter plug 1099344-00-C


----------



## amund7

Bokonon said:


> It would be nice to add these capabilities to CANBusAnalyzer but I still haven't had a chance to sit down look at that repo yet.


Now is the time, Brianman is contributing a lot, and I am trying to hang on  PM me (or just start looking at the github) if you want to join in.



scottf200 said:


> Consider working with the developer for "Scan My Tesla". They have started a canbus analyzer tool which is on github:
> https://teslamotorsclub.com/tmc/thr...reader-for-android.112636/page-7#post-2947744
> 
> I use their "Scan My Tesla" app in my model X. It is impressive. I mentioned it here: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/#post-119539


Thanks  I am here, working on it, looks like things are happening fast now that Brianman is aboard contributing fresh work to Canbus Analyzer, progress is great!



JWardell said:


> Thanks. I am going to look at some of those messages next...
> 
> Last night I tried stabbing randomly at several messages with the CAN Analyzer software. Almost everything is uselessly jumping around because of all these cycling messages.
> *We REALLY need a way to separate or view all these cycling messages!*


I agree. Have hit my head on this all day, not really found a good way to deal with it. I was looking at 0x401 most of the day, had a hope that it could maybe be a similiar paged packet to the 0x6F2 in the model S and X, with the cell voltages and temperatures. But I couldn't crack it. Scrambling for a way to separate the pages.

Started testing out savvy-can, http://www.savvycan.com/ - as I know DBC files and CANBUS standards already has a way to define and deal with paged messages. But it didn't help, even if SavvyCan has lots of interesting features.

However, I think I have nailed a few other interesting packets, I will create a separate post for it, stay tuned.


----------



## scottf200

JWardell said:


> That's what we're trying to use


I apologize, I was a few pages back in this thread before I realized he showed up and did some handy mods to his tool.

FYI, just an example of some CAN msg layout I forgot I had when I did a Google drive search -- it appears to be for the Nissan LEAF but I was just pointing out the layout they used.
Google sheet --- 1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg
https : // docs . google . com / spreadsheets / d / 1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg/edit#gid=0


----------



## amund7

@JWardell , does these temperatures seem ballpark relevant to your cold battery charge? Maybe you could do a new log, randomly, noting ambient and inside temperatures?

The scaling and naming is free fantasy copied from model S/X, then a bit more fantasy (model S is -40, I tried -20 on these). Celcius.

Formulas, these are the C# / Scan My Tesla notation for these:



C#:


      packets.Add(0x376, p = new Packet(0x376, this));
      p.AddValue("Outside temp", " C", "e",
        (bytes) => (bytes[0] / 2.0 - 20));
      p.AddValue("Outside temp filtered", " C", "e",
        (bytes) => (bytes[1] / 2.0 - 20));
      p.AddValue("Inside temp", " C", "e",
        (bytes) => (bytes[2] / 2.0 - 20));
      p.AddValue("A/C air temp", " C", "e",
        (bytes) => (bytes[4] / 2.0 - 20));


----------



## amund7

RPM, again, formula is copied from Model S, which originally came from wizkid057/Jason Hughes, packet ID from you guys, might hold water?



C#:


      packets.Add(0x108, p = new Packet(0x108, this));
      p.AddValue("Rr motor RPM", "RPM", "",
          (bytes) => rrpm = (bytes[5] + (bytes[6] << 8)) - (512 * (bytes[6] & 0x80)));


----------



## amund7

Mech power (kW), mech power (HP), dissipation, inverter 12v, same as last, I checked HP with official specs, seems ballpark correct:



C#:


      packets.Add(0x266, p = new Packet(0x266, this));
      p.AddValue("Rr inverter 12V", "V12", "", (bytes) => bytes[0] / 10.0);
      p.AddValue("Rr mech power", " kW", "e", (bytes) => mechPower =
          ((bytes[2] + ((bytes[3] & 0x7) << 8)) - (512 * (bytes[3] & 0x4))) / 2.0);
      p.AddValue("Rr mech power HP", "HP", "pf", (bytes) => mechPower * kw_to_hp);
      p.AddValue("Rr dissipation", " kW", "", (bytes) => {
        rDissipation = bytes[1] * 125.0 / 1000.0 - 0.5;
        return rDissipation;
      });


----------



## amund7

Rear torque (checked specs, seems legit)



C#:


      packets.Add(0x154, p = new Packet(0x154, this));
      p.AddValue("Rr torque measured", "Nm", "p", (bytes) => torque =
         (bytes[5] + ((bytes[6] & 0x1F) << 8) - (512 * (bytes[6] & 0x10))) * 0.25);


----------



## amund7

Battery voltage, current, power (calculated):



C#:


      packets.Add(0x132, p = new Packet(0x132, this));
      p.AddValue("Battery voltage", " V", "bpr", (bytes) => volt =
          (bytes[0] + (bytes[1] << 8)) / 100.0);
      p.AddValue("Battery current", " A", "b", (bytes) => amp =
          1000 - ((Int16)((((bytes[3] & 0x7F) << 8) + bytes[2]) << 1)) / 20.0);
      p.AddValue("Battery power", " kW", "bpe", (bytes) => power = amp * volt / 1000.0);


----------



## JWardell

96s46p said:


> 0x51E (100 ms) - Repeats the same 12 values in a loop:
> 
> 14 05 00 00 00 00 00 00
> 19 *31 31 30 31 37 38 39*
> 1A *2D 38 31 2D 46* 00 00
> This is the charger part number 1101789-81-F
> 
> 0x505 (100 ms) - repeats the same 7 values in a loop:
> 
> 00 03 5A 9A CE 6B 00 00
> 0B 00 00 00 00 00 7D 20
> 19 *31 30 39 39 33 34 34*
> 1A *2D 30 30 2D 43* 00 00
> This is the part number of the 14-50 adapter plug 1099344-00-C


Awesome, now how on earth did you figure those out?
To confirm, I just checked my home charger is PN 1101789-81-F and SN ALM18068175820



amund7 said:


> @JWardell , does these temperatures seem ballpark relevant to your cold battery charge? Maybe you could do a new log, randomly, noting ambient and inside temperatures?
> 
> The scaling and naming is free fantasy copied from model S/X, then a bit more fantasy (model S is -40, I tried -20 on these). Celcius.
> 
> Formulas, these are the C# / Scan My Tesla notation for these:
> 
> 
> 
> C#:
> 
> 
> packets.Add(0x376, p = new Packet(0x376, this));
> p.AddValue("Outside temp", " C", "e",
> (bytes) => (bytes[0] / 2.0 - 20));
> p.AddValue("Outside temp filtered", " C", "e",
> (bytes) => (bytes[1] / 2.0 - 20));
> p.AddValue("Inside temp", " C", "e",
> (bytes) => (bytes[2] / 2.0 - 20));
> p.AddValue("A/C air temp", " C", "e",
> (bytes) => (bytes[4] / 2.0 - 20));


Yes as I noted the battery should have been chilled to 30-35F and ambient was 35F, however I believe I preheated the interior before the recording so not sure that corresponds to interior temp but maybe coolant or battery?

I think it would be really helpful in many discussions here to figure out battery temps so we can stop guessing about regen and other performance issues
Of course somewhere in there we should also have max available regen and power

If you could release a new version of CANBus analyzer with all we've IDed so far (if you can't toggle, maybe a model 3 specific compile?) that would be super helpful. I will keep the spreadsheet updated.

Thanks again everyone for the help


----------



## JWardell

96s46p said:


> 0x51E (100 ms) - Repeats the same 12 values in a loop:
> 
> 14 05 00 00 00 00 00 00
> 19 *31 31 30 31 37 38 39*
> 1A *2D 38 31 2D 46* 00 00
> This is the charger part number 1101789-81-F
> 
> 0x505 (100 ms) - repeats the same 7 values in a loop:
> 
> 00 03 5A 9A CE 6B 00 00
> 0B 00 00 00 00 00 7D 20
> 19 *31 30 39 39 33 34 34*
> 1A *2D 30 30 2D 43* 00 00
> This is the part number of the 14-50 adapter plug 1099344-00-C


Any idea what the other ASCII data in 505 is...sounds like some other part number? *VLX17341108084*


----------



## 96s46p

JWardell said:


> Any idea what the other ASCII data in 505 is...sounds like some other part number? *VLX17341108084*


It's the serial number of the 14-50 plug


----------



## JWardell

amund7 said:


> @JWardell , does these temperatures seem ballpark relevant to your cold battery charge? Maybe you could do a new log, randomly, noting ambient and inside temperatures?
> 
> The scaling and naming is free fantasy copied from model S/X, then a bit more fantasy (model S is -40, I tried -20 on these). Celcius.
> 
> Formulas, these are the C# / Scan My Tesla notation for these:
> 
> 
> 
> C#:
> 
> 
> packets.Add(0x376, p = new Packet(0x376, this));
> p.AddValue("Outside temp", " C", "e",
> (bytes) => (bytes[0] / 2.0 - 20));
> p.AddValue("Outside temp filtered", " C", "e",
> (bytes) => (bytes[1] / 2.0 - 20));
> p.AddValue("Inside temp", " C", "e",
> (bytes) => (bytes[2] / 2.0 - 20));
> p.AddValue("A/C air temp", " C", "e",
> (bytes) => (bytes[4] / 2.0 - 20));


I added all 8 bytes of 376 to my GUI with these temp encodings, then watched as I played back both my accel and charge traces.
I really think the 3rd and 5th bytes are coolant inlet and outlet temps of the battery or motor, or something similar.
When charging the 3rd byte gradually gets warmer (heating up coolant), 5th gets a bit warmer at first than stays (cold battery removing most heat)
When accelerating, 5th byte rapidly gets warmer while 3rd reacts more slowly, but 5th cools right back after acceleration when 3rd stays warm.

Remember each ID should be coming out of a particular device. These could be various temps in the battery, or the drive unit, or the HVAC, but I would not expect data from multiple devices mixed into the same message.
As this is the powertrain bus and these are reacting to acceleration, I think we're looking at something in that system, not so much the HVAC. Of course that makes it harder to determine the correct values.
Also, you have these offsets post scale instead of pre scale. Not sure if that is possible in a DBC file and therefore makes me think automotive would always have offsets first. Who knows.


----------



## JWardell

amund7 said:


> RPM, again, formula is copied from Model S, which originally came from wizkid057/Jason Hughes, packet ID from you guys, might hold water?
> 
> 
> 
> C#:
> 
> 
> packets.Add(0x108, p = new Packet(0x108, this));
> p.AddValue("Rr motor RPM", "RPM", "",
> (bytes) => rrpm = (bytes[5] + (bytes[6] << 8)) - (512 * (bytes[6] & 0x80)));
> 
> 
> View attachment 19744


This agrees with what I assume. Simply signed RPM with no offset or multiplier. (The -512*top bit is handling the signed part, technically you should remove the top bit from the left)
Then some unknown multiplier to arrive at speed. I'm using .0082 I need to log at a constant highway speed to dial this in.
There could be another ID somewhere that has speed coded separately.


----------



## JWardell

*Here is a new recording:*
https://www.dropbox.com/s/hnwubvva4vtps8g/1228ChargeDrive.csv.zip?dl=0

Outside temp 35F
Interior 67F should be constant
Start log. Exit car. Plug in charger. Enter car. Ramp to 24A Battery is too cold so I never see more than ~3A going to battery. See 376 temps rise for a bit.
Exit car. Unplug charger. Enter car. Press brake.
Reverse out of driveway, then drive around the block, with a few hits of the accelerator. Park. End log.
Hopefully this has all the CAN IDs from all the logs and some interesting data.
Firmware 2018.50


----------



## JWardell

Also here is my experience with the *Body CAN:*

I tried to get CAN from all the CAN buses listed in the pinout earlier this week, but I could not seem to connect to any at any speed.
Tonight I went out with a scope and started probing. In addition to 18&19 powertrain CAN, I do see what looks like CAN on 13&14 (H&L), however it appears to be a slower data rate (wider bits). All other pins are DC, at least when parked.

I tried like crazy but could not get anything but CAN errors from there. I tried every standard speed from 50k to 1MB. I think I also caught the signal shut downs at time, perhaps if I was generating errors. Sometimes the interior lights would cycle on and off when I was connected (!)

I'm going to have to wait till I'm back at work and go sniffing with a decoding scope again. Maybe this is LIN or an unusual CAN speed.


----------



## fast_like_electric

JWardell said:


> This agrees with what I assume. Simply signed RPM with no offset or multiplier. (The -512*top bit is handling the signed part, technically you should remove the top bit from the left)
> Then some unknown multiplier to arrive at speed. I'm using .0082 I need to log at a constant highway speed to dial this in.
> There could be another ID somewhere that has speed coded separately.


No, this is not correct. See post #167 - this CAN parameter is rear axle speed (not motor RPM), and in 0.1 RPM / bit resolution. Technically you can apply an additional scaling to get motor RPM (or vehicle speed) given the fixed ratio, but that frame signal itself is rear axle RPM. Actual and commanded torque are in the other bytes, vehicle speed is elsewhere.


----------



## fast_like_electric

JWardell said:


> Also here is my experience with the *Body CAN:*
> 
> I tried to get CAN from all the CAN buses listed in the pinout earlier this week, but I could not seem to connect to any at any speed.
> Tonight I went out with a scope and started probing. In addition to 18&19 powertrain CAN, I do see what looks like CAN on 13&14 (H&L), however it appears to be a slower data rate (wider bits). All other pins are DC, at least when parked.
> 
> I tried like crazy but could not get anything but CAN errors from there. I tried every standard speed from 50k to 1MB. I think I also caught the signal shut downs at time, perhaps if I was generating errors. Sometimes the interior lights would cycle on and off when I was connected (!)
> 
> I'm going to have to wait till I'm back at work and go sniffing with a decoding scope again. Maybe this is LIN or an unusual CAN speed.


LIN is not a differential bus (single wire). If you are seeing one pin go high when the other goes low (and vice-versa), you're looking at something else. If you have a screen shot (scope plot) that you wanted to share which shows the two signals (zoomed in to show a few bits widely with timebase info), the bit time should be able to be determined without risking bus errors.


----------



## JWardell

fast_like_electric said:


> LIN is not a differential bus (single wire). If you are seeing one pin go high when the other goes low (and vice-versa), you're looking at something else. If you have a screen shot (scope plot) that you wanted to share which shows the two signals (zoomed in to show a few bits widely with timebase info), the bit time should be able to be determined without risking bus errors.


It looks like CAN to me, with high and low on 13 & 14. Just using my ancient battery scope so I can't easily measure or decode, I will look at it more closely with a better scope when I'm back to work. Perplexed why I can't get a trace from it after multiple attempts.


----------



## amund7

JWardell said:


> I added all 8 bytes of 376 to my GUI with these temp encodings, then watched as I played back both my accel and charge traces.
> I really think the 3rd and 5th bytes are coolant inlet and outlet temps of the battery or motor, or something similar.
> When charging the 3rd byte gradually gets warmer (heating up coolant), 5th gets a bit warmer at first than stays (cold battery removing most heat)
> When accelerating, 5th byte rapidly gets warmer while 3rd reacts more slowly, but 5th cools right back after acceleration when 3rd stays warm.
> 
> Remember each ID should be coming out of a particular device. These could be various temps in the battery, or the drive unit, or the HVAC, but I would not expect data from multiple devices mixed into the same message.
> As this is the powertrain bus and these are reacting to acceleration, I think we're looking at something in that system, not so much the HVAC. Of course that makes it harder to determine the correct values.
> Also, you have these offsets post scale instead of pre scale. Not sure if that is possible in a DBC file and therefore makes me think automotive would always have offsets first. Who knows.


This is a straight copy from model S, where this package reports those 4 values. (The AC temp I am not sure of the correct naming, but it jumps up and down around +2 C when AC is active, could be condenser/refrigerant temperature).
In Model S, I believe a lot of the canbus packets are re-runs from somewhere - for example say a little module for a heated mirror needs to know the battery SOC and outside temperature. But it's tiny, and stupid, and wants to only read one canbus packet. Then someone on the bus (gateway? 17" screen?) would send a packet for this module to be happy, getting those data from other modules. I say this, because I've seen things like battery voltage, amps and/or stator amps repeated in different packets, with different resolution, different package HZ etc.

In the model S, there is a surprisingly big amount of HVAC/cooling system data on the powertrain bus. I have discovered coolant pump speeds (4 of them), every HVAC duct damper angle, every duct temperature, gas temperatures, power draw for heating and cooling, etc etc. So I would expect to find some of this in model 3 as well.

At least we have found something, so we'll leave it open and try to match the scaling to the real world.
What I found very useful for finding temperatures was to leave the car outside, then start driving without pre-heating, log from the 1st sec. Then log all the time on a long drive until everything heats up. I am not afraid of big logs, so if you could make a log like this and send me that would be cool. Also the temperatures at the start and end of the trip from TeslaFi.

Your latest log broke the Canbus Analyzer import filter, it got put off because you have commas inside the text of the known packets. I will try to fix this.


----------



## brianman

For the next week or so, my contributions will be more sparse as I'm travelling again but with a different schedule.

Regarding the cycling messages, you might want to represent them in the DBC with multiplexing. Take a look here at the bottom:
http://pisnoop.s3.amazonaws.com/snoop_help_dbc.htm

@amund7 - DBCTools has supported for "simple multiplexing" (to the degree I was able to tease out an understanding from various snippets on the web) but I haven't looked at "extended multiplexing" yet.


----------



## brianman

This is another page I found useful:
https://github.com/stefanhoelzl/CANpy/blob/master/docs/DBC_Specification.md


----------



## JWardell

amund7 said:


> This is a straight copy from model S, where this package reports those 4 values. (The AC temp I am not sure of the correct naming, but it jumps up and down around +2 C when AC is active, could be condenser/refrigerant temperature).
> In Model S, I believe a lot of the canbus packets are re-runs from somewhere - for example say a little module for a heated mirror needs to know the battery SOC and outside temperature. But it's tiny, and stupid, and wants to only read one canbus packet. Then someone on the bus (gateway? 17" screen?) would send a packet for this module to be happy, getting those data from other modules. I say this, because I've seen things like battery voltage, amps and/or stator amps repeated in different packets, with different resolution, different package HZ etc.
> 
> In the model S, there is a surprisingly big amount of HVAC/cooling system data on the powertrain bus. I have discovered coolant pump speeds (4 of them), every HVAC duct damper angle, every duct temperature, gas temperatures, power draw for heating and cooling, etc etc. So I would expect to find some of this in model 3 as well.
> 
> At least we have found something, so we'll leave it open and try to match the scaling to the real world.
> What I found very useful for finding temperatures was to leave the car outside, then start driving without pre-heating, log from the 1st sec. Then log all the time on a long drive until everything heats up. I am not afraid of big logs, so if you could make a log like this and send me that would be cool. Also the temperatures at the start and end of the trip from TeslaFi.
> 
> Your latest log broke the Canbus Analyzer import filter, it got put off because you have commas inside the text of the known packets. I will try to fix this.





brianman said:


> http://pisnoop.s3.amazonaws.com/snoop_help_dbc.htm


It certainly makes sense that some data can be repeated, especially with this multiplexed stuff. But I just want to be careful that we don't assume messages and data are the same as Model S when there is a very good chance it changed even slightly. That's why it's best to look how the data changes in particular situations.

I also noticed last night that CANBus Analyzer was reading known decoded data instead of raw bytes, but it probably has always been doing that, I just defined a lot more since the older logs were taken.

It might make more sense for me to switch to another tool for logging, CANopen magic was convenient for me only because I'm already very familiar and can set up live gauges easily.
PEAKs PCAN can be used for free data tracing. As you linked to, PIsnoop might be able to as well (and it seems to have a way to deal with multiplexing) and I should have a license for that. Frankly I have to learn CANoe anyway so I may just put the effort into Vector at this point and it makes nice compressed logs that I can later convert to any other format. If it doesn't handle multiplexed out of the box I have the ability to ask them.
I probably won't have any other opportunities to log till later next week though so please make the most of the four I've posted for now.

Edit: Vector has me covered:
https://assets.vector.com/cms/conte...21_Extended_Multiplexing_in_DBC_Databases.pdf


----------



## fast_like_electric

JWardell said:


> If it doesn't handle multiplexed out of the box I have the ability to ask them.
> I probably won't have any other opportunities to log till later next week though so please make the most of the four I've posted for now.
> 
> Edit: Vector has me covered:
> https://assets.vector.com/cms/conte...21_Extended_Multiplexing_in_DBC_Databases.pdf


You mentioned that the cycling / multiplexed messages are causing decoding issues. However, only a handful of the messages are cycled like this (VIN, the EVSE data, battery cell info, other part number info, etc). With the exception of the battery cell info, those other particular messages are not terribly interesting. All of the parameters associated with down the road driving are not multiplexed.

Can you describe what the exact problem is? Is there a particular multiplexed/cycled message you are interested in? I'm happy to focus on a particular frame if I understood better what the issue is.


----------



## 96s46p

fast_like_electric said:


> You mentioned that the cycling / multiplexed messages are causing decoding issues. However, only a handful of the messages are cycled like this (VIN, the EVSE data, battery cell info, other part number info, etc). With the exception of the battery cell info, those other particular messages are not terribly interesting. All of the parameters associated with down the road driving are not multiplexed.
> 
> Can you describe what the exact problem is? Is there a particular multiplexed/cycled message you are interested in? I'm happy to focus on a particular frame if I understood better what the issue is.


There are also multiplexed messages with different data lengths. The problem is that a multiplexed signal may look like a very active signal when graphed or monitored as a single signal so it would be helpful to isolate and identify these. Whether or not some of the data is useful depends on what you want to do I guess.


----------



## JWardell

Updated DBC file with fancy multiplexor messages! Well, just VIN for now. It's a bit of work. But good to test all those 3rd party DBC processors.
https://www.dropbox.com/s/rvuanyn7gazmn3q/Model3CAN.dbc?dl=0



fast_like_electric said:


> You mentioned that the cycling / multiplexed messages are causing decoding issues. However, only a handful of the messages are cycled like this (VIN, the EVSE data, battery cell info, other part number info, etc). With the exception of the battery cell info, those other particular messages are not terribly interesting. All of the parameters associated with down the road driving are not multiplexed.
> 
> Can you describe what the exact problem is? Is there a particular multiplexed/cycled message you are interested in? I'm happy to focus on a particular frame if I understood better what the issue is.


I've been stabbing at random data with excel earlier and CANbus Analyzer more recently, but a very high number of messages seem to have this format, and it is difficult to impossible to graph the data because it bounces back and forth between those multiplexed values. Of course without seeing the graphed data it's tough to determine if it is something interesting or not. (Honestly, everything is interesting!)

Now that I've learned how to put it into the DBC, Vector should be able to visualize it once I move tracing over to that. Still makes it extremely difficult to explore unknown data.
And the DBC descriptions of data are limited, I can't say it's ASCII or three signals are to be appended, etc. Probably more complex stuff to learn in Vector!


----------



## amund7

JWardell said:


> It certainly makes sense that some data can be repeated, especially with this multiplexed stuff. But I just want to be careful that we don't assume messages and data are the same as Model S when there is a very good chance it changed even slightly. That's why it's best to look how the data changes in particular situations.


It is not an assumption. The packet we are discussing had a completely different ID in model S, but I saw a familiar pattern looking at the graphs of this packet's raw bytes, and tried copying the model S scaling and descriptions. I look at it as additional data points, or additional starting points. Of course it needs to be validated, but it's a starting point. It's the same company, the same people, mostly the same sub-contractors, it is (in my mind) safe to assume they would copy their previous work, use the same modules, or solve the same task in the same way as last time.

There are only so many ways to encode, compress, package, scale and send temperatures on canbus, so I believe I am saving time experimenting with all the old formulas I've seen this far (from the same people of the same company).
I believe this goes for mostly any data in this car. I was even contemplating a brute-force approach, try to run EVERY formula from model S on EVERY packet ID coming from the model 3, just look at the graphs and quickly (hopefully quickly) pick out the graphs that seem to contain anything interesting.

But I am also learning from other people in this thread, that are thinking in probabilities and statistics, to look at packet frequencies etc. Interesting stuff!



JWardell said:


> I also noticed last night that CANBus Analyzer was reading known decoded data instead of raw bytes, but it probably has always been doing that, I just defined a lot more since the older logs were taken.


You found the bug I just mentioned, the CSV loader gets thrown off because your file has several commas within one column, that skews all the other commas and columns. I'll need some time to crack that.



JWardell said:


> It might make more sense for me to switch to another tool for logging, CANopen magic was convenient for me only because I'm already very familiar and can set up live gauges easily.
> PEAKs PCAN can be used for free data tracing. As you linked to, PIsnoop might be able to as well (and it seems to have a way to deal with multiplexing) and I should have a license for that. Frankly I have to learn CANoe anyway so I may just put the effort into Vector at this point and it makes nice compressed logs that I can later convert to any other format. If it doesn't handle multiplexed out of the box I have the ability to ask them.
> I probably won't have any other opportunities to log till later next week though so please make the most of the four I've posted for now.
> 
> Edit: Vector has me covered:
> https://assets.vector.com/cms/conte...21_Extended_Multiplexing_in_DBC_Databases.pdf


Please don't switch all the time  It takes a lot of work to implement a new format, and one format is probably no better than the next. I notice how some of you guys panic about a 50 mb file, but who cares, my phone today has what 128 gb of space !??! Canbus Analyzer chews log files gradually and doesn't care until your PC crashes your windows swap file after filling your 4 tb hard drive. It does not matter. But please, agree on 1 format that we can focus on  if Vector is the most widely used, best format, we'll implement that. In this thread though, all I care about is which software you want to use, as you are the only one providing logs 



fast_like_electric said:


> You mentioned that the cycling / multiplexed messages are causing decoding issues. However, only a handful of the messages are cycled like this (VIN, the EVSE data, battery cell info, other part number info, etc). With the exception of the battery cell info, those other particular messages are not terribly interesting. All of the parameters associated with down the road driving are not multiplexed.
> 
> Can you describe what the exact problem is? Is there a particular multiplexed/cycled message you are interested in? I'm happy to focus on a particular frame if I understood better what the issue is.


I have ripped quite a bit of hair out trying to discover the Model S relative to the battery cell voltages/temperatures in model 3. But so far, just ripped hair. I spent a lot of time on 0x401 packet, but whatever I do I can't really crack it, and it seems the counter is too slow, only showing each cell a couple of times in a long log.


----------



## fast_like_electric

JWardell said:


> Updated DBC file with fancy multiplexor messages! Well, just VIN for now. It's a bit of work. But good to test all those 3rd party DBC processors.
> https://www.dropbox.com/s/rvuanyn7gazmn3q/Model3CAN.dbc?dl=0
> 
> I've been stabbing at random data with excel earlier and CANbus Analyzer more recently, but a very high number of messages seem to have this format, and it is difficult to impossible to graph the data because it bounces back and forth between those multiplexed values. Of course without seeing the graphed data it's tough to determine if it is something interesting or not. (Honestly, everything is interesting!)


Do you have a specific example? A lot of the messages have counters and checksums and CRCs. Are you confusing those with segmented messages?


----------



## 96s46p

You can see what should be a multiplexed message here for charge port data as CP_sensorDataSelect cycles through various enum values.





Do we think each "message" corresponds to a single CAN ID and all "signals" under that message are contained within either a single or multiplexed message??


----------



## brianman

amund7 said:


> Please don't switch all the time  It takes a lot of work to implement a new format, and one format is probably no better than the next.


Should probably pick one of the formats supported by SavvyCAN:
http://www.savvycan.com/docs/mainscreen.html#loading-and-saving-frames

Preferably the format we choose would include the BUS information.


----------



## JWardell

amund7 said:


> It is not an assumption. The packet we are discussing had a completely different ID in model S, but I saw a familiar pattern looking at the graphs of this packet's raw bytes, and tried copying the model S scaling and descriptions. I look at it as additional data points, or additional starting points. Of course it needs to be validated, but it's a starting point. It's the same company, the same people, mostly the same sub-contractors, it is (in my mind) safe to assume they would copy their previous work, use the same modules, or solve the same task in the same way as last time.
> 
> There are only so many ways to encode, compress, package, scale and send temperatures on canbus, so I believe I am saving time experimenting with all the old formulas I've seen this far (from the same people of the same company).
> I believe this goes for mostly any data in this car. I was even contemplating a brute-force approach, try to run EVERY formula from model S on EVERY packet ID coming from the model 3, just look at the graphs and quickly (hopefully quickly) pick out the graphs that seem to contain anything interesting.
> 
> But I am also learning from other people in this thread, that are thinking in probabilities and statistics, to look at packet frequencies etc. Interesting stuff!
> 
> You found the bug I just mentioned, the CSV loader gets thrown off because your file has several commas within one column, that skews all the other commas and columns. I'll need some time to crack that.
> 
> Please don't switch all the time  It takes a lot of work to implement a new format, and one format is probably no better than the next. I notice how some of you guys panic about a 50 mb file, but who cares, my phone today has what 128 gb of space !??! Canbus Analyzer chews log files gradually and doesn't care until your PC crashes your windows swap file after filling your 4 tb hard drive. It does not matter. But please, agree on 1 format that we can focus on  if Vector is the most widely used, best format, we'll implement that. In this thread though, all I care about is which software you want to use, as you are the only one providing logs
> 
> I have ripped quite a bit of hair out trying to discover the Model S relative to the battery cell voltages/temperatures in model 3. But so far, just ripped hair. I spent a lot of time on 0x401 packet, but whatever I do I can't really crack it, and it seems the counter is too slow, only showing each cell a couple of times in a long log.


Brute force is fine if it's easy to do. Worth it even if it finds just a few more things. I definitely wish I could select all messages and graph everything as bytes and words, and that's why I've done a dozen or so random ones every other day, but it's not so easy with the current state of the software.

I totally understand about switching data log! Can you provide with a short example trace from the other format it decodes?
COMagic has kind of hit a wall with its capabilities as I can't post-process/decode data to visualize things. It's really not made for standard CAN. I'm at the point that I need to switch to Vector, and also at the point I need to master it (for work too...) But because it supports custom log conversion, I can probably easily convert its logs to the other format CANbus Analyzer supports.
The other half of my point was more to make it easier for others to log, and that would be with a free tool. PCAN-VIEW is an easy answer, but maybe Kvasar CanKing which (I think) can also load a DBC file and show decoded data (another on the list to learn). Or maybe in a couple weeks you awesome software folks can work together to make our own logging and decoding tool and none of this will matter 



fast_like_electric said:


> Do you have a specific example? A lot of the messages have counters and checksums and CRCs. Are you confusing those with segmented messages?


I'm sure I am confusing them all. The point is I can only stare at HEX and graphs of stuff that doesn't jump around. We saw it a lot with a number of messages we identified earlier as interesting. Here's what I have from my notes:
ID 2C1
ID 2E1
ID 263
ID 39A
ID 3C2
ID 221
ID 272
ID 282
ID 393
302
303


----------



## JWardell

96s46p said:


> You can see what should be a multiplexed message here for charge port data as CP_sensorDataSelect cycles through various enum values.


I forgot just how much that @Ingineer video made me wish I had access to that built-in CAN viewer...and the incredible sea of data that we are sifting through!
Now if only those screens showed IDs...


----------



## brianman

96s46p said:


> ...


From the posted text in that video:


> Model 3 has only 3 main CAN Buses; Vehicle, Chassis, and Party.


If anybody has contact info for the video author, perhaps he might have some data that we can use to guide DBC creation.


----------



## 96s46p

Look at 1D9 and 3B9 for varying length


----------



## brianman

brianman said:


> Should probably pick one of the formats supported by SavvyCAN:
> http://www.savvycan.com/docs/mainscreen.html#loading-and-saving-frames
> 
> Preferably the format we choose would include the BUS information.


The GVRET format looks complete enough (timestamp and bus included) but concise enough:
https://github.com/collin80/SavvyCAN/blob/master/examples/GVRET_Log.csv


----------



## 96s46p

amund7 said:


> Now is the time, Brianman is contributing a lot, and I am trying to hang on  PM me (or just start looking at the github) if you want to join in.
> 
> Thanks  I am here, working on it, looks like things are happening fast now that Brianman is aboard contributing fresh work to Canbus Analyzer, progress is great!
> 
> I agree. Have hit my head on this all day, not really found a good way to deal with it. I was looking at 0x401 most of the day, had a hope that it could maybe be a similiar paged packet to the 0x6F2 in the model S and X, with the cell voltages and temperatures. But I couldn't crack it. Scrambling for a way to separate the pages.
> 
> Started testing out savvy-can, http://www.savvycan.com/ - as I know DBC files and CANBUS standards already has a way to define and deal with paged messages. But it didn't help, even if SavvyCan has lots of interesting features.
> 
> However, I think I have nailed a few other interesting packets, I will create a separate post for it, stay tuned.


0x401 definitely looks like cell data, there are 32 messages (plus 4 empty) with what looks like 3 2-byte values so 96 total and could be uint16 cell voltage x 10,000? For example 0x9A0C = 3.9436v?


----------



## fast_like_electric

96s46p said:


> You can see what should be a multiplexed message here for charge port data as CP_sensorDataSelect cycles through various enum values.
> 
> 
> 
> 
> 
> Do we think each "message" corresponds to a single CAN ID and all "signals" under that message are contained within either a single or multiplexed message??


Correct - each message on the giant list on the left side of the screen are all the CAN frames (IDs). The signals on the right side of the screen correspond to content within that selected frame. Very few segmented / multiplex messages - those are only for low priority info that is not time critical - unlike driving control signals. Also - not all messages shown are on the Powertrain bus - its a list of everything on all the CAN buses.


----------



## fast_like_electric

amund7 said:


> It is not an assumption. The packet we are discussing had a completely different ID in model S, but I saw a familiar pattern looking at the graphs of this packet's raw bytes, and tried copying the model S scaling and descriptions. I look at it as additional data points, or additional starting points. Of course it needs to be validated, but it's a starting point. It's the same company, the same people, mostly the same sub-contractors, it is (in my mind) safe to assume they would copy their previous work, use the same modules, or solve the same task in the same way as last time.
> 
> There are only so many ways to encode, compress, package, scale and send temperatures on canbus, so I believe I am saving time experimenting with all the old formulas I've seen this far (from the same people of the same company).
> I believe this goes for mostly any data in this car. I was even contemplating a brute-force approach, try to run EVERY formula from model S on EVERY packet ID coming from the model 3, just look at the graphs and quickly (hopefully quickly) pick out the graphs that seem to contain anything interesting.
> 
> But I am also learning from other people in this thread, that are thinking in probabilities and statistics, to look at packet frequencies etc. Interesting stuff!
> 
> You found the bug I just mentioned, the CSV loader gets thrown off because your file has several commas within one column, that skews all the other commas and columns. I'll need some time to crack that.
> 
> Please don't switch all the time  It takes a lot of work to implement a new format, and one format is probably no better than the next. I notice how some of you guys panic about a 50 mb file, but who cares, my phone today has what 128 gb of space !??! Canbus Analyzer chews log files gradually and doesn't care until your PC crashes your windows swap file after filling your 4 tb hard drive. It does not matter. But please, agree on 1 format that we can focus on  if Vector is the most widely used, best format, we'll implement that. In this thread though, all I care about is which software you want to use, as you are the only one providing logs
> 
> I have ripped quite a bit of hair out trying to discover the Model S relative to the battery cell voltages/temperatures in model 3. But so far, just ripped hair. I spent a lot of time on 0x401 packet, but whatever I do I can't really crack it, and it seems the counter is too slow, only showing each cell a couple of times in a long log.


See post #216 above. Consistent with the 96 cell groups (46 cells in each group), for the total of 4,416 2170 cells in the LR pack. Tallying up those does seem to be in the ballpark of the pack voltage in the other CAN frames. Though not totally conclusive given the 36 seconds to go through all of the frames. But looks promising.


----------



## 96s46p

fast_like_electric said:


> See post #216 above. Consistent with the 96 cell groups (46 cells in each group), for the total of 4,416 2170 cells in the LR pack. Tallying up those does seem to be in the ballpark of the pack voltage in the other CAN frames. Though not totally conclusive given the 36 seconds to go through all of the frames. But looks promising.


On the other bus that data streams much faster up to 2 messages per 15ms


----------



## fast_like_electric

96s46p said:


> On the other bus that data streams much faster up to 2 messages per 15ms


By 'other bus', I assume you mean the bus that connects the individual battery sub-control modules (within the pack) to the BMS?


----------



## JWardell

I've updated the first thread with a summary and quick links, and added a link in my signature to attract some more help.


----------



## 96s46p

fast_like_electric said:


> By 'other bus', I assume you mean the bus that connects the individual battery sub-control modules (within the pack) to the BMS?


No the other bus the battery is connected to which is "body can"?


----------



## scottf200

JWardell said:


> I've updated the first thread with a summary and quick links, and added a link in my signature to attract some more help.


Suggest you to a menu option: View--Freeze--1 row in your spreadsheet to make it more friendly.


----------



## amund7

96s46p said:


> 0x401 definitely looks like cell data, there are 32 messages (plus 4 empty) with what looks like 3 2-byte values so 96 total and could be uint16 cell voltage x 10,000? For example 0x9A0C = 3.9436v?


Awesome man, this looks absolutely right:









A bit disappointed that there seem to be no temperatures in here ?
And byte 2 is constantly '42', through all the log files, wonder what that means.

My code for reading this:



C#:


        int cell = 0;
        double voltage = 0.0;

        for (int i = 0; i < 3; i++) {
          voltage = ((bytes[i * 2 + 3] << 8) + bytes[i * 2 + 2]) / 10000.0;
          if (voltage > 0)
            UpdateItem("Cell " + (cell = ((bytes[0]) * 3 + i + 1)).ToString().PadLeft(2) + " voltage"
              , "zVC"
              , "z"
              , bytes[0]
              , voltage
              , 0x401);
        }

To clarify for any non-coders, the actual formula is 


C#:


((bytes[i * 2 + 3] << 8) + bytes[i * 2 + 2]) / 10000.0

repeated for byte2+3, byte4+5, byte6+7.
Byte0 is the counter, and byte1 is always 42. (Hitchhiker's guide to the galaxy reference for us??  )


----------



## brianman

brianman said:


> Should probably pick one of the formats supported by SavvyCAN:
> http://www.savvycan.com/docs/mainscreen.html#loading-and-saving-frames
> 
> Preferably the format we choose would include the BUS information.


As an experiment, I'm writing a powershell converter with the goal of converting the { AccelCAN.csv, first3.csv, LiveCANrev.csv } samples from @JWardell into a format that SavvyCAN can load directly. For now, I'm using the GVRET format.


----------



## amund7

brianman said:


> As an experiment, I'm writing a powershell converter with the goal of converting the { AccelCAN.csv, first3.csv, LiveCANrev.csv } samples from @JWardell into a format that SavvyCAN can load directly. For now, I'm using the GVRET format.


I already wrote one that converts to the 'general csv' format  .net, let me know if you want it.


----------



## brianman

amund7 said:


> I already wrote one that converts to the 'general csv' format  .net, let me know if you want it.


Nice... but that one's just ID and data right? I think we really want the timestamp and bus information that the GVRET format includes.


----------



## scottf200

amund7 said:


> To clarify for any non-coders, the actual formula is
> 
> 
> C#:
> 
> 
> ((bytes[i * 2 + 3] << 8) + bytes[i * 2 + 2]) / 10000.0
> 
> repeated for byte2+3, byte4+5, byte6+7.
> Byte0 is the counter, and byte1 is always 42. (Hitchhiker's guide to the galaxy reference for us??  )


Haha,
I would think the non-coder explanation doesn't just repeat the code 



Code:


(0x9A0C) base 16 = (39436) base 10

a) ((bytes[i * 2 + 3] << 8) + bytes[i * 2 + 2]) / 10000.0
b) ((bytes[0 * 2 + 3] << 8) + bytes[0 * 2 + 2]) / 10000.0
c) ((bytes[3] << 8) + bytes[2]) / 10000.0
d) ((bytes[3] * 256) + bytes[2]) / 10000.0

3  2  1  0
9A 0C

x9A*256 = 39424
x0C     =    12
          39436


----------



## 96s46p

amund7 said:


> Awesome man, this looks absolutely right:
> 
> View attachment 19806
> 
> 
> A bit disappointed that there seem to be no temperatures in here ?


I think 0x712 could be module temperatures (int16?) in degrees C x 100


----------



## fast_like_electric

96s46p said:


> I think 0x712 could be module temperatures (int16?) in degrees C x 100


Could be. For confirmation of signed data, would need a CAN log below 0 C ambient (and without battery heating). Here's a plot of the 16 parameters over a few minutes (mid-way in a charge cycle). Thinking the data might have an offset and scale instead - a lot of variation that shouldn't be possible unless the measurement system is not very accurate...


----------



## 96s46p

fast_like_electric said:


> Correct - each message on the giant list on the left side of the screen are all the CAN frames (IDs). The signals on the right side of the screen correspond to content within that selected frame. Very few segmented / multiplex messages - those are only for low priority info that is not time critical - unlike driving control signals. Also - not all messages shown are on the Powertrain bus - its a list of everything on all the CAN buses.


We should extract all the messages and signals shown in that video and add them to the spreadsheet


----------



## JWardell

It's been unseasonably warm the last few days so I can't make any cold captures till it gets cold again. I'm sure we won't have to wait too long.


----------



## JWardell

Finally made some progress with Vector. Very nice that I can record a nice log and analyze everything later in playback. DBC scaling and offset worked differently than expect so that file is updated again. I will work to convert the logs to something simple like time, ID, data (is that the native text format for CANbusAnalyzer?). I can also plot signals against each other live (lots of struggling and learning to get to this point).

Here's a run that includes charging, and two full-pedal blasts onto the highway (and even a quick activation of AP). Currents peak at 1440A then quickly have an artificial curved cutback. ID376 temp E responds almost simultaneously with large current demand (inverter?), TempC responds very slowly (coolant?), TempD fixed at 20 (cabin?), temps A & B extremely slowly rising (battery?)


----------



## JWardell

amund7 said:


> Rear torque (checked specs, seems legit)
> 
> 
> 
> C#:
> 
> 
> packets.Add(0x154, p = new Packet(0x154, this));
> p.AddValue("Rr torque measured", "Nm", "p", (bytes) => torque =
> (bytes[5] + ((bytes[6] & 0x1F) << 8) - (512 * (bytes[6] & 0x10))) * 0.25);
> 
> 
> View attachment 19746


Is this correct, you are using same bit of byte 6 twice (1F and 10 masks)?
Should the second part be using different bits, for example E0 mask?


----------



## fast_like_electric

JWardell said:


> Currents peak at 1440A then quickly have an artificial curved cutback.


I believe your scaling has to be off or that parameter is not what you think it is. At a well charged battery, that would be about 550kW, or 730Hp! The LR Model 3 is respectable, but not to that level. The wiring and electronics cannot achieve that high of current - something is amiss.


----------



## amund7

JWardell said:


> Is this correct, you are using same bit of byte 6 twice (1F and 10 masks)?
> Should the second part be using different bits, for example E0 mask?


This is WK057's formula, the 512* part is to extract the negative part of the number to get a signed integer. Looks confusing, but it works.


----------



## amund7

JWardell said:


> something simple like time, ID, data (is that the native text format for CANbusAnalyzer?)


.txt logs from Scan My Tesla looks like this:


Code:


168A90C1C3F00000076
1F801F9F0B6B9070000
23800FF00000000F161
2A800000003DE03CD1B
2D20000D880060000
1021296D8A5B84B4C01
53A01FFB5FFB5FF3240
29A0100FE0000000000
10692219201DC022752
11600406D428187
20A000A0483135B1111
00E21013FFF08FF100B
1548883002B2E490100
22840C0E000
1021096D7A5A84B4C01

Pretty compact, no spaces, no timestamp.


----------



## JWardell

fast_like_electric said:


> I believe your scaling has to be off or that parameter is not what you think it is. At a well charged battery, that would be about 550kW, or 730Hp! The LR Model 3 is respectable, but not to that level. The wiring and electronics cannot achieve that high of current - something is amiss.


I am suspect as well, but continuous currents make sense, I get -24A when charging at 24A, HVAC usually takes ~10A etc. then again that is NOT right because 24A at 205VAC is not 24A at 380VDC. So perhaps this should be scaled in half.
The peak measurement is quickly cut back a bit
Anyone have a giant current clamp to put on the battery? 



amund7 said:


> This is WK057's formula, the 512* part is to extract the negative part of the number to get a signed integer. Looks confusing, but it works.


I'm still trying to figure out how to make Vector decode this.
Just staring at the data, I'm guessing the bottom half of the second to last byte is really the top, and the other byte and a half are in order. Strange. Here's a transition...
02 B2 10 00 00 FD BF D5
02 B2 10 00 00 FE DF F6
02 B2 10 00 00 FF FF 17
02 B2 10 00 00 00 00 19
02 B2 10 00 00 00 20 39
02 B2 10 00 00 00 40 59
02 B2 10 00 00 00 60 79
02 B2 10 00 00 00 80 99

So to me that's [Signed 16] [((Byte 7 & 0F) << 12) + ((Bytes 6-7) >> 4)]



amund7 said:


> .txt logs from Scan My Tesla looks like this:
> 
> 
> Code:
> 
> 
> 168A90C1C3F00000076
> 1F801F9F0B6B9070000
> 23800FF00000000F161
> 2A800000003DE03CD1B
> 2D20000D880060000
> 1021296D8A5B84B4C01
> 53A01FFB5FFB5FF3240
> 29A0100FE0000000000
> 10692219201DC022752
> 11600406D428187
> 20A000A0483135B1111
> 00E21013FFF08FF100B
> 1548883002B2E490100
> 22840C0E000
> 1021096D7A5A84B4C01
> 
> Pretty compact, no spaces, no timestamp.


Are IDs mixed in as well?
Well, maybe someone can make some kind of python converter to strip the Vector ASCII output format to this, although time stamps really are important for an x axis.


----------



## Bokonon

JWardell said:


> Are IDs mixed in as well?


ID is actually the first three digits of each string (e.g., "168A90C1C3F00000076" is 0x168). The remaining characters are the message data.



> Well, maybe someone can make some kind of python converter to strip the Vector ASCII output format to this, although time stamps really are important for an x axis.


I started working on CANBusAnalyzer's file-import capabilities last night. Forgive me if it was posted somewhere in the flurry of links up-thread, but if there's a sample Vector output file I could have a look at, I can look into implementing support for that format.


----------



## amund7

JWardell said:


> time stamps really are important for an x axis.


Agree, currently Canbus Analyzer (and Scan My Tesla) only supports stamps from Scan My Tesla .csv files, but we are looking to change that.

About the formula,


Code:


(bytes[5] + ((bytes[6] & 0x1F) << 8) - (512 * (bytes[6] & 0x10))) * 0.25)

take out the negative part and you're left with



Code:


(bytes[5] + ((bytes[6] & 0x1F) << 8)) * 0.25)


----------



## 96s46p

It's just a 13-bit signed integer. The top 3 bits are a 3-bit counter and the last byte is a checksum.


----------



## JWardell

96s46p said:


> It's just a 13-bit signed integer. The top 3 bits are a 3-bit counter and the last byte is a checksum.


Darn checksums, always messing up clean data! 
Strange that this data is wrapped in an extra layer of robustness.
It might take some time before I learn scripting or whatever is required to process these more complex byte operations in Vector. We'll see.

Top of my wishlist right now is still finding State of Charge and Battery Temp, then maybe power and Regen limit values.
We're also going to need to find additional data for AWD.


----------



## JWardell

I now have Torque working! Assuming ~400 NM is about right, see the graph below.
Currents also halved, ~740A peak.
Updated DBC and spreadsheet

Also I IDed some more messages with matrix ASCII data, do any of these numbers make sense to anyone?
0x330 ASCII for indexes 11, 12- "M641953", "M890613"
0x3C4 ASCII for indexes 19, 1D, 1E- "113558", "ANN1814", "400014Q"
0x72A ASCII for indexes 00, 01 "TG11816", "00003H0"


----------



## fast_like_electric

JWardell said:


> Also I IDed some more messages with matrix ASCII data, do any of these numbers make sense to anyone?
> 0x330 ASCII for indexes 11, 12- "M641953", "M890613"
> 0x3C4 ASCII for indexes 19, 1D, 1E- "113558", "ANN1814", "400014Q"
> 0x72A ASCII for indexes 00, 01 "TG11816", "00003H0"


Frame 0x3C4 is the PCS (power conversion system) module info. Index 1A is also a portion of the part number - full part number is 1135558-00-C. Index 1D and 1E are the serial number. Basically they are the same format as the mobile charger info CAN frames.


----------



## JWardell

fast_like_electric said:


> Frame 0x3C4 is the PCS (power conversion system) module info. Index 1A is also a portion of the part number - full part number is 1135558-00-C. Index 1D and 1E are the serial number. Basically they are the same format as the mobile charger info CAN frames.


Awesome, that's the 400v to 12v DC to DC converter, correct? We should see a different model number for 32Amp SR cars, and maybe 3-phase converters in euro cars
Added this to the spreadsheet.
Any chance other bytes might be temps or currents from the converter?


----------



## fast_like_electric

JWardell said:


> We should see a different model number for 32Amp SR cars..


Perhaps - that is a question many are wondering. Is the 32A limit on the standard and mid-range Model 3's software imposed, or is it different hardware. Someone with a mid-range could do a CAN log to see the part number, or look at the module itself.



JWardell said:


> Any chance other bytes might be temps or currents from the converter?


No. The frames you mentioned are static/fixed. They just contain module info, not dynamic conditions like temperature or current.


----------



## fast_like_electric

Haven't seen any new decodes in awhile, here's one...

ID 0x318 Date/Time/and???
- 8 Bytes
- Sent every 100ms (10 Hz)
Bytes:
1: year, 00-99 last two digits (in decimal) {anything in upper 1 bit?}
2: month, 1-12 (in decimal) {anything in upper 4 bits?}
3: seconds, 0-59 (in decimal) {anything in upper 2 bits?}
4: hour, 0-23 (in decimal) {anything in upper 3 bits?}
5: day, 1-31 (in decimal) {anything in upper 3 bits?}
6: minutes, 0-59 (in decimal) {anything in upper 2 bits?}
7:
bits 7-5: ?
bits 4-1: 3 bit counter
bit 0: ?
8: checksum

The date/time is in GMT (UTC-0), like message 0x528. So you need to apply your time zone offset (and DST) to get the actual time (and correct date at rollover).

Interesting that this message contains redundant information - message 0x528 with Unix time in seconds would be good enough - though not broken out. It is also sent at 10x per second - seems excessive. Model S/X packed other info in the upper bits between the bytes (door and frunk status). Might be interesting to see if any vehicle conditions can flip the non-time/date bits.


----------



## JWardell

fast_like_electric said:


> Haven't seen any new decodes in awhile, here's one...
> 
> ID 0x318 Date/Time/and???
> - 8 Bytes
> - Sent every 100ms (10 Hz)
> Bytes:
> 1: year, 00-99 last two digits (in decimal) {anything in upper 1 bit?}
> 2: month, 1-12 (in decimal) {anything in upper 4 bits?}
> 3: seconds, 0-59 (in decimal) {anything in upper 2 bits?}
> 4: hour, 0-23 (in decimal) {anything in upper 3 bits?}
> 5: day, 1-31 (in decimal) {anything in upper 3 bits?}
> 6: minutes, 0-59 (in decimal) {anything in upper 2 bits?}
> 7:
> bits 7-5: ?
> bits 4-1: 3 bit counter
> bit 0: ?
> 8: checksum
> 
> The date/time is in GMT (UTC-0), like message 0x528. So you need to apply your time zone offset (and DST) to get the actual time (and correct date at rollover).
> 
> Interesting that this message contains redundant information - message 0x528 with Unix time in seconds would be good enough - though not broken out. It is also sent at 10x per second - seems excessive. Model S/X packed other info in the upper bits between the bytes (door and frunk status). Might be interesting to see if any vehicle conditions can flip the non-time/date bits.


Nice! Please continue your incredibly helpful drip of data discovery 
I just added both of these into the spreadsheet.
I'm regretting leaving all my can hardware and software at work this weekend. But I did start some Arduino stuff today...stay tuned.


----------



## JWardell

Thanks to Verygreen over at TMC, ID 0x257 contains UI speeds.
Running through my captures, I can confirm the fourth byte contains the absolute value UI speed (positive in reverse), and is exactly the speed displayed when I recorded the data.
Surprisingly to me, this value aligns precisely with ID 108 axle RPM with the 1/128th RPM scaling 0.0078125. Can RPM exactly equal MPH??

The third byte is another speed but confuses me a bit. It clearly has a -31 offset (31 at 0mph) so it goes negative in reverse, but the scale is strange, not MPH or KPH. After subtracting 31, I see 95 at 76mph giving it a scale of 0.8


----------



## fast_like_electric

JWardell said:


> Thanks to Verygreen over at TMC, ID 0x257 contains UI speeds.
> Running through my captures, I can confirm the fourth byte contains the absolute value UI speed (positive in reverse), and is exactly the speed displayed when I recorded the data.
> Surprisingly to me, this value aligns precisely with ID 108 axle RPM with the 1/128th RPM scaling 0.0078125. Can RPM exactly equal MPH??
> 
> The third byte is another speed but confuses me a bit. It clearly has a -31 offset (31 at 0mph) so it goes negative in reverse, but the scale is strange, not MPH or KPH. After subtracting 31, I see 95 at 76mph giving it a scale of 0.8


Byte 4 is the filtered/adjusted UI speed, in selected units. Always positive as you mention. Bytes 2 and 3 contain the 12 bit unsigned raw speed. Centered at 500 decimal (1F4 hex), resolution 0.05 MPH, range -25 MPH to 179.75 MPH. Bits 11..4 are in byte 3, upper nibble of byte 2 contains bits 3..0.


----------



## amund7

Very excited to announce a new version of Canbus Analyzer, with quite a bit of new stuff:

https://github.com/amund7/CANBUS-Analyzer/releases
(you will need to uninstall the previous version if you have one installed)

Hard work from BrianMan, Bokonon and Scott has moved this project a long way in a short time.
It now supports 
- Model 3 and Model S 'known packets' (model 3 is lagging behind this thread as it's a week or two since I updated the definitions)
- Vector ASCII format
- CSV from CANOpen, and bugfixes so this one still supports the files with some defined packages in it
- Scan My Tesla .txt logs

DBC file support is not far away.

+ many small UI and usability improvements.

It is also very untested, please report bugs or questions to me on PM. Report bugs directly to github (new issue), to avoid derailing this thread.

I will try to stay up to date with this thread and implement signals as they are reported here. (Although, strings and dates I have a hard time with, it is not currently supported)


----------



## Bokonon

amund7 said:


> I will try to stay up to date with this thread and implement signals as they are reported here. (Although, strings and dates I have a hard time with, it is not currently supported)


If it would be helpful, anytime I see a new message decoded in this thread, I can log it on GitHub. I already have to read every message in this thread as part of my moderating duties, so I figure it might save us some time.


----------



## JWardell

fast_like_electric said:


> Byte 4 is the filtered/adjusted UI speed, in selected units. Always positive as you mention. Bytes 2 and 3 contain the 12 bit unsigned raw speed. Centered at 500 decimal (1F4 hex), resolution 0.05 MPH, range -25 MPH to 179.75 MPH. Bits 11..4 are in byte 3, upper nibble of byte 2 contains bits 3..0.


You are again an encyclopedia, thanks! Of course it now works perfectly.
I've updated the DBC and spreadsheet with the two ID 257 speeds.
Hopefully more to come soon.



amund7 said:


> Very excited to announce a new version of Canbus Analyzer, with quite a bit of new stuff:
> 
> https://github.com/amund7/CANBUS-Analyzer/releases
> (you will need to uninstall the previous version if you have one installed)
> 
> Hard work from BrianMan, Bokonon and Scott has moved this project a long way in a short time.
> It now supports
> - Model 3 and Model S 'known packets' (model 3 is lagging behind this thread as it's a week or two since I updated the definitions)
> - Vector ASCII format
> - CSV from CANOpen, and bugfixes so this one still supports the files with some defined packages in it
> - Scan My Tesla .txt logs
> 
> DBC file support is not far away.
> 
> + many small UI and usability improvements.
> 
> It is also very untested, please report bugs or questions to me on PM. Report bugs directly to github (new issue), to avoid derailing this thread.
> 
> I will try to stay up to date with this thread and implement signals as they are reported here. (Although, strings and dates I have a hard time with, it is not currently supported)


Awesome, thank you all for your help! I should have a chance to make a new capture to publish tonight, stay tuned.


----------



## JWardell

I have a new recording for everyone!
This is the first in the new Vector ASCII format which I am more likely to use from now on. Make sure you are using the latest CANBusAnalyzer.
Warning: 17MB zip expands to 143 MB
https://www.dropbox.com/s/qycpnxtib3cdwgh/Model3Log2019-01-06coldDriveCharge.asc.zip?dl=0

Some notes:
park & unplugged
Ambient temp 28F/4C
HVAC was OFF so interior is fairly cold
Battery UI SOC 59% (Teslafi reports 62%)
Start recording
(note current draw <1A)
Turn on HVAC set to 68F
(note current climb to ~18A)
Press brake to activate drive
Shift into reverse, back out slowly
Pull forward and stop
Floor it to ~40mph
Drive around a bit on side roads
Floor it on to highway onramp
Quickly exit.
Get back on highway
at 60-61mph, activate AP set to 65
Reduce AP to 63
Turn off AP
Exit highway and drive home
Park.
Plug in charger at 24A (203VAC 5kW)
Charge begins. Note reduced battery charge rate due to still cold battery
Stop log
End Battery SOC 57%UI 59%Teslafi


----------



## JWardell

Looking at some BMS messages from last night's drive I have some loose feelings:
ID 312 Byte 0 might be battery temp or temp at some high current area...jumps during high acceleration, slowly falls
This kind of follows ID 376 3rd temp (startbit 16) which might be the better measurement of battery temp. 312 temp only occurs when driving, 376 continues and increases rapidly when charging w/battery heater activated.
Not sure of offsets, remember ambient was 4C and I last drove several hours before, so it should have been in the 4-8C range to start.

ID 292 has some state of charge info
I think there is a 12-bit SOC at start bit 16, not sure of scale/offset
Then an 8-bit UI SOC value at startbit 32 0-255 scaled to 100 (.39216) agrees with values recorded


----------



## amund7

312 byte 0 and byte 2 looks interesting, I suppose either coolant pumps, valves etc.
Model S has 3-4 coolant pumps, and a radiator bypass valve that looks a bit like these.
Strange that these seem to run opposite of eachother, can't make sense of that, model S coolant pumps always run equal to eachother, or completely indepently, depending on which mode (parallell/series).
Not sure yet how model 3 does all this, I think the system is simpler with less crossovers and bypasses, and as we know, no battery heater, just the drive unit doing the heating


----------



## fast_like_electric

JWardell said:


> Looking at some BMS messages from last night's drive I have some loose feelings:
> ID 312 Byte 0 might be battery temp or temp at some high current area...jumps during high acceleration, slowly falls
> This kind of follows ID 376 3rd temp (startbit 16) which might be the better measurement of battery temp. 312 temp only occurs when driving, 376 continues and increases rapidly when charging w/battery heater activated.
> Not sure of offsets, remember ambient was 4C and I last drove several hours before, so it should have been in the 4-8C range to start.


There are many - many temperature sensors, not to mention flow and fan rates - both actual and demanded rates. All these result in a slew of CAN signals, of different number of bits / offset / scale based on required measurement precision. Difficult to isolate what is what - easy to try and make something fit that is totally something else.

In order to reconcile any suspect bits and bytes related to battery temperature and a signal that shows trending, you'd need a few known data points - say three logs at approximate known battery temperatures. I think the 16 raw values that were previously pointed out in frame 0x712 are the most promissing, trended correctly but the scale/offset didn't jive. Need more known conditions to crack the code - negative C being the most useful as that hadn't been recorded yet and will clearly show if the data is signed, or unsigned with some offset.

If you have the car soaked overnight (outside and unplugged), its reasonable to assume the pack temperature will be close to ambient after a period of time. Take a short snapshot after a 0 C night, as well as something less than 0 C (coming up in the next few days). You probably already have a log for a warmer temp. If you compare the 0x712 values to those three known temps, you'll be able to get a slope and y-intersept - which is your scale and offset. Clearly more data and wider temp variation is preferred, if you have access to a heated garage for example.

If there is an overall battery pack temperature that is broadcast as well (rather than just all the individual temps for sensors in the pack), I would think you'd be able to match that up as well. Can probably spot some of the many other temperatures as well for further identification (ambient temp, cabin, etc). But you'll also see all the temps for other stuff like the module internal temps too.

Just a suggestion. Some CAN signals easy to divine, others require a more controlled test method.


----------



## JWardell

fast_like_electric said:


> There are many - many temperature sensors, not to mention flow and fan rates - both actual and demanded rates. All these result in a slew of CAN signals, of different number of bits / offset / scale based on required measurement precision. Difficult to isolate what is what - easy to try and make something fit that is totally something else.
> 
> In order to reconcile any suspect bits and bytes related to battery temperature and a signal that shows trending, you'd need a few known data points - say three logs at approximate known battery temperatures. I think the 16 raw values that were previously pointed out in frame 0x712 are the most promissing, trended correctly but the scale/offset didn't jive. Need more known conditions to crack the code - negative C being the most useful as that hadn't been recorded yet and will clearly show if the data is signed, or unsigned with some offset.
> 
> If you have the car soaked overnight (outside and unplugged), its reasonable to assume the pack temperature will be close to ambient after a period of time. Take a short snapshot after a 0 C night, as well as something less than 0 C (coming up in the next few days). You probably already have a log for a warmer temp. If you compare the 0x712 values to those three known temps, you'll be able to get a slope and y-intersept - which is your scale and offset. Clearly more data and wider temp variation is preferred, if you have access to a heated garage for example.
> 
> If there is an overall battery pack temperature that is broadcast as well (rather than just all the individual temps for sensors in the pack), I would think you'd be able to match that up as well. Can probably spot some of the many other temperatures as well for further identification (ambient temp, cabin, etc). But you'll also see all the temps for other stuff like the module internal temps too.
> 
> Just a suggestion. Some CAN signals easy to divine, others require a more controlled test method.


I agree. I've tried to make note of ambient in most of my recordings. Unfortunately we hare having an unseasonably warm winter so far, but I'm sure it will catch up soon!
The other tough part is I have to go out, disconnect the charge cable, quickly disable HVAC, and jam the wires in without my fingers falling off. I'm really overdue for making a proper connector.
We really need to find a source for the plug housing soon.


----------



## fast_like_electric

JWardell said:


> The other tough part is I have to go out, disconnect the charge cable, quickly disable HVAC, and jam the wires in without my fingers falling off.


You'll not want the charge cable plugged in overnight for the cold temp log - you won't have a cold battery if charging kicks in.

However, after starting the log, then plugging in the cable and starting to charge would be informative - as the "battery heater" (stalled drive motor) will engage and you should see only the battery temperatures rise and not most of the other CAN signals that are outside that temperature regulation loop.

I totally understand the part about cold fingers. For me I just scraped back the insulation on the CAN wires and spliced them to a standard DB9 CAN cable (in the absence of readily available connectors).


----------



## JWardell

fast_like_electric said:


> You'll not want the charge cable plugged in overnight for the cold temp log - you won't have a cold battery if charging kicks in.
> 
> However, after starting the log, then plugging in the cable and starting to charge would be informative - as the "battery heater" (stalled drive motor) will engage and you should see only the battery temperatures rise and not most of the other CAN signals that are outside that temperature regulation loop.
> 
> I totally understand the part about cold fingers. For me I just scraped back the insulation on the CAN wires and spliced them to a standard DB9 CAN cable (in the absence of readily available connectors).


I looked at each of the bytes in 714 and they don't look meaningful to me given the nature of my drive and charge. Perhaps they are encoded unusually.

I'm looking at ID 252 now which might have battery power limits. I think the first two bytes are max discharge with a 0.1 scale, followed by max regen power (this is the one I really want to dial in because I barely have any in the winter), but it's signed or 12-bit or something strange I can't quite figure out yet.


----------



## JWardell

JWardell said:


> I looked at each of the bytes in 714 and they don't look meaningful to me given the nature of my drive and charge. Perhaps they are encoded unusually.
> 
> I'm looking at ID 252 now which might have battery power limits. I think the first two bytes are max discharge with a 0.1 scale, followed by max regen power (this is the one I really want to dial in because I barely have any in the winter), but it's signed or 12-bit or something strange I can't quite figure out yet.


Scratch that, I just had them flipped around. The first two words are regen power limit and max discharge in kW with .01 scale, unsigned. Nice and simple.
I can go through my recording and multiply voltage x current when flooring it and when under full (pathetic 50Amp) regen, and they match up almost perfectly:









I'll update the spreadsheet and DBC...


----------



## JWardell

OK, one more update!
Adding to RPM in ID 108, there is Torque actual and requested. When I graphed them against Raw Torque in 154 they were almost identical. The only problem is the scales are a bit weird, in order to get them the same. Perhaps there is a correction factor applied to the Raw torque to get to the actual so maybe they are more sensible, but here is what I have for now:

0x108 Torque Request NM (signed 16, startbit 8, scale .013?) TorqueActual NM (signed 16, startbit 24, scale .026?) Axle RPM (signed 16, startbit 40, scale .0078125)

Here's what they look like:


----------



## amund7

Formulas and naming from Model S/X (from WK057), but seems to match up very well with packet 0x352:



Code:


      packets.Add(0x352, p = new Packet(0x352, this));
      p.AddValue("Nominal full pack", "kWh", "br", (bytes) => nominalFullPackEnergy = (bytes[0] + ((bytes[1] & 0x03) << 8)) * 0.1);
      p.AddValue("Nominal remaining", "kWh", "br", (bytes) => nominalRemaining = ((bytes[1] >> 2) + ((bytes[2] & 0x0F) * 64)) * 0.1);
      p.AddValue("Expected remaining", "kWh", "r", (bytes) => ((bytes[2] >> 4) + ((bytes[3] & 0x3F) * 16)) * 0.1);
      p.AddValue("Ideal remaining", "kWh", "r", (bytes) => ((bytes[3] >> 6) + ((bytes[4] & 0xFF) * 4)) * 0.1);
      p.AddValue("To charge complete", "kWh", "", (bytes) => (bytes[5] + ((bytes[6] & 0x03) << 8)) * 0.1);
      p.AddValue("Energy buffer", "kWh", "br", (bytes) => buffer = ((bytes[6] >> 2) + ((bytes[7] & 0x03) * 64)) * 0.1);
      p.AddValue("SOC", "%", "br", (bytes) => soc = (nominalRemaining - buffer) / (nominalFullPackEnergy - buffer) * 100.0);

SOC is my own calculation, to try to mimic the UI displays in Model S. May not be correct with this car, please report back.
Funny thing is, 'to charge complete' was always 0 in model S, but here it seems to work!

Also, I figured


Code:


      packets.Add(0x292, p = new Packet(0x292, this));
      p.AddValue("SOC UI", "%", "br", (bytes) => (bytes[0] + ((bytes[1] & 0x3) << 8)) / 10.0);
      p.AddValue("SOC Min", "%", "br", (bytes) => ((bytes[1] >> 2) + ((bytes[2] & 0xF) << 6)) / 10.0);
      p.AddValue("SOC Max", "%", "br", (bytes) => ((bytes[2] >> 4) + ((bytes[3] & 0x3F) << 4)) / 10.0);
      p.AddValue("SOC Avg", "%", "br", (bytes) => ((bytes[3] >> 6) + ((bytes[4]) << 2)) / 10.0);

Scaling as in Model S, but with one more added here. Naming and the order of these is uncertain, but the values seem plausible. In Model S these do NOT match the UI displayed SOC, these are internal.


----------



## JWardell

Very excited today to have a working (and very beta) live CAN display in my car!
This is something I dreamed up over a year ago, well before taking delivery.
A big sense of accomplishment considering I was just soldering this up over the weekend, not to mention tapping into unknown CAN data just a few weeks ago.

HUGE THANKS to all of you for helping out!

Adding more data and replacing the terrible LCD display are next (and maybe a call to a Sumitomo rep...) I'm just getting started here.


__ https://twitter.com/i/web/status/1083002858612707329


----------



## TjckTock

scottf200 said:


> I apologize, I was a few pages back in this thread before I realized he showed up and did some handy mods to his tool.
> 
> FYI, just an example of some CAN msg layout I forgot I had when I did a Google drive search -- it appears to be for the Nissan LEAF but I was just pointing out the layout they used.
> Google sheet --- 1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg
> https : // docs . google . com / spreadsheets / d / 1EHa4R85BttuY4JZ-EnssH4YZddpsDVu6rUFm0P7ouwg/edit#gid=0
> 
> View attachment 19742


Hey, I recognize that spreadsheet! ;-) I just upgraded from my Leaf to a Model 3 and was slowly digesting all the great work folks have done here. Didn't expect to see this. :-D Still coming up to speed but plan to help out soon.


----------



## JWardell

TjckTock said:


> Hey, I recognize that spreadsheet! ;-) I just upgraded from my Leaf to a Model 3 and was slowly digesting all the great work folks have done here. Didn't expect to see this. :-D Still coming up to speed but plan to help out soon.


That's funny! Congrats on the car, and welcome!


----------



## 96s46p

amund7 said:


> Also, I figured
> 
> 
> Code:
> 
> 
> packets.Add(0x292, p = new Packet(0x292, this));
> p.AddValue("SOC UI", "%", "br", (bytes) => (bytes[0] + ((bytes[1] & 0x3) << 8)) / 10.0);
> p.AddValue("SOC Min", "%", "br", (bytes) => ((bytes[1] >> 2) + ((bytes[2] & 0xF) << 6)) / 10.0);
> p.AddValue("SOC Max", "%", "br", (bytes) => ((bytes[2] >> 4) + ((bytes[3] & 0x3F) << 4)) / 10.0);
> p.AddValue("SOC Avg", "%", "br", (bytes) => ((bytes[3] >> 6) + ((bytes[4]) << 2)) / 10.0);
> 
> Scaling as in Model S, but with one more added here. Naming and the order of these is uncertain, but the values seem plausible. In Model S these do NOT match the UI displayed SOC, these are internal.


Yes you definitely get 4 similar graphs when you take 10-bit values. The one with lowest values range is 606-632. If you scale to 1024 you get 59%-61.7% which does match the teslafi numbers. Not sure about the other three values which are a bit higher.


----------



## 96s46p

JWardell said:


> Very excited today to have a working (and very beta) live CAN display in my car!
> This is something I dreamed up over a year ago, well before taking delivery.
> A big sense of accomplishment considering I was just soldering this up over the weekend, not to mention tapping into unknown CAN data just a few weeks ago.
> 
> HUGE THANKS to all of you for helping out!
> 
> Adding more data and replacing the terrible LCD display are next (and maybe a call to a Sumitomo rep...) I'm just getting started here.
> 
> 
> __ https://twitter.com/i/web/status/1083002858612707329


It's a HUD because bb-8's head position indicates something?


----------



## 96s46p

JWardell said:


> I looked at each of the bytes in 714 and they don't look meaningful to me given the nature of my drive and charge. Perhaps they are encoded unusually.


0x712 seems to have a lot of negative spike noise but trends around 6.5c to 8.5c in the latest log. I don't know if that is reasonable for battery temps to only increase 2c in your drive. But sitting in a warm garage those values trend around 23c and 30c during charging so they make sense as temps. The noise magnitude seems to be consistent also.


----------



## JWardell

amund7 said:


> Formulas and naming from Model S/X (from WK057), but seems to match up very well with packet 0x352:
> 
> 
> 
> Code:
> 
> 
> packets.Add(0x352, p = new Packet(0x352, this));
> p.AddValue("Nominal full pack", "kWh", "br", (bytes) => nominalFullPackEnergy = (bytes[0] + ((bytes[1] & 0x03) << 8)) * 0.1);
> p.AddValue("Nominal remaining", "kWh", "br", (bytes) => nominalRemaining = ((bytes[1] >> 2) + ((bytes[2] & 0x0F) * 64)) * 0.1);
> p.AddValue("Expected remaining", "kWh", "r", (bytes) => ((bytes[2] >> 4) + ((bytes[3] & 0x3F) * 16)) * 0.1);
> p.AddValue("Ideal remaining", "kWh", "r", (bytes) => ((bytes[3] >> 6) + ((bytes[4] & 0xFF) * 4)) * 0.1);
> p.AddValue("To charge complete", "kWh", "", (bytes) => (bytes[5] + ((bytes[6] & 0x03) << 8)) * 0.1);
> p.AddValue("Energy buffer", "kWh", "br", (bytes) => buffer = ((bytes[6] >> 2) + ((bytes[7] & 0x03) * 64)) * 0.1);
> p.AddValue("SOC", "%", "br", (bytes) => soc = (nominalRemaining - buffer) / (nominalFullPackEnergy - buffer) * 100.0);
> 
> SOC is my own calculation, to try to mimic the UI displays in Model S. May not be correct with this car, please report back.
> Funny thing is, 'to charge complete' was always 0 in model S, but here it seems to work!
> 
> Also, I figured
> 
> 
> Code:
> 
> 
> packets.Add(0x292, p = new Packet(0x292, this));
> p.AddValue("SOC UI", "%", "br", (bytes) => (bytes[0] + ((bytes[1] & 0x3) << 8)) / 10.0);
> p.AddValue("SOC Min", "%", "br", (bytes) => ((bytes[1] >> 2) + ((bytes[2] & 0xF) << 6)) / 10.0);
> p.AddValue("SOC Max", "%", "br", (bytes) => ((bytes[2] >> 4) + ((bytes[3] & 0x3F) << 4)) / 10.0);
> p.AddValue("SOC Avg", "%", "br", (bytes) => ((bytes[3] >> 6) + ((bytes[4]) << 2)) / 10.0);
> 
> Scaling as in Model S, but with one more added here. Naming and the order of these is uncertain, but the values seem plausible. In Model S these do NOT match the UI displayed SOC, these are internal.


I took all your ID 352 and ID 292 formulas and put them into the DBC and spreadsheet, and tested them out.
At least on my last recording, they seem to make sense. The SOCs are weird but I agree calculating from capacities gets better results, and your equation for (remaining-buffer)/(full-buffer) is nearly the same for the SOC reported to Teslafi.
What is shown in the UI in the display is its own animal (especially considering I had a snowflake) and I bet there is some internal temperature correction going on that won't be spit back out to the bus.
....I bet that same correction exists in the phone app, which maybe someone can deconstruct

Here are these values at the beginning and end of my last recording, they seem to make sense. I'm curious what these look like on a nearly full battery, I will have to capture that some day.

















Display: 59%+snowflake to 57%
TeslaFi: 62% to 59%


----------



## fast_like_electric

JWardell said:


> ....I bet that same correction exists in the phone app, which maybe someone can deconstruct


I do not believe that is the case. I've written my own Alexa skill which uses the same underlying Tesla API, and the range and SOC match the car and phone display. Perhaps TeslaFi is the oddball. Yes, the car will display a different SOC than those CAN messages, but the range and SOC should be consistent accross all the human facing interfaces.

Does the SOC displayed on the phone app differ from what is displayed on the car and/or TeslaFi? Or in other words, at the exact same point in time, what is the SOC displayed by the car, phone, and TeslaFi?


----------



## TjckTock

JWardell said:


> Trying to drive while looking at gauges, hold a camera, and hold my flailing laptop proved to be a bit of a challenge, but you are welcome to watch the event if you want:
> Video is 4K so you should be able to zoom to see values when you stop the video (unless you have alien stabilization technology). Next time I need to just do this with a fix mounted GoPro...


What microcontroller board are you using? How many canbus' does it have? I am considering using an LPC1768. Mainly because I can leverage my code from my Leaf Project which has a lot of useful debug features (including monitoring for data on muxed fields, flagging changes, etc). It has two controllers so you can simultaneously look at two of the busses. However, it has been a few years and would be interested in the merits of the uC you chose.

Also, am I correct in concluding that everyone is splicing into the wires due to the difficulty finding the 20 pin connectors in the center console? Can I get a count of how many people would be interested in paying no more than $50 for a set of male & female connectors and pins if I am able to find a supplier? Might be easier if I order more than a couple.


----------



## JWardell

96s46p said:


> It's a HUD because bb-8's head position indicates something?


It _can_ be a HUD, eventually...I have plenty more iterations in mind. It was just a good inside joke.



fast_like_electric said:


> I do not believe that is the case. I've written my own Alexa skill which uses the same underlying Tesla API, and the range and SOC match the car and phone display. Perhaps TeslaFi is the oddball. Yes, the car will display a different SOC than those CAN messages, but the range and SOC should be consistent accross all the human facing interfaces.
> 
> Does the SOC displayed on the phone app differ from what is displayed on the car and/or TeslaFi? Or in other words, at the exact same point in time, what is the SOC displayed by the car, phone, and TeslaFi?


I can do one better and put a display on the screen showing all current SOCs and look at everything at once. I'll try to do that tonight or this weekend.



TjckTock said:


> What microcontroller board are you using? How many canbus' does it have? I am considering using an LPC1768. Mainly because I can leverage my code from my Leaf Project which has a lot of useful debug features (including monitoring for data on muxed fields, flagging changes, etc). It has two controllers so you can simultaneously look at two of the busses. However, it has been a few years and would be interested in the merits of the uC you chose.
> 
> Also, am I correct in concluding that everyone is splicing into the wires due to the difficulty finding the 20 pin connectors in the center console? Can I get a count of how many people would be interested in paying no more than $50 for a set of male & female connectors and pins if I am able to find a supplier? Might be easier if I order more than a couple.


It's a Teensy 3.1 and Adafruit LCD that I have kicking around. Display upgrades badly needed and ordered  Arduino works for me for easy turn around, but Raspberry PI or computer or tablet might work better for others...

I absolutely need to find a better connector solution ASAP. We can obtain one of the housings but not the other. Need to find a Sumitomo supplier that can help us. My plan was to order a few to make myself and once confirmed I'll pay for 50 or so to be made by a CM if that's what it takes. I haven't had time to chase down this part so I would love if someone else could help, I will gladly pay for any passthrough connector. I really do not want to attempt to splice or strip insulation from the tiny 28? gauge wires. I am still painstakingly inserting needles into the back of the crimps, and that keeps getting looser. Need a better solution very soon.


----------



## TjckTock

So.. Do you actually *want* 50 sets? Just checking because of the "if that's what it takes" comment (not sure if it was meant to apply to the quantity or the "made by a CM" comment).


----------



## fast_like_electric

TjckTock said:


> What microcontroller board are you using? How many canbus' does it have? I am considering using an LPC1768. Mainly because I can leverage my code from my Leaf Project which has a lot of useful debug features (including monitoring for data on muxed fields, flagging changes, etc). It has two controllers so you can simultaneously look at two of the busses. However, it has been a few years and would be interested in the merits of the uC you chose.


By far, the coolest and most comprehensive Tesla CAN bus project is documented here...

https://teslatap.com/modifications/tshow-front-end-light-show/

To pull it off, he also needed access to two CAN buses. His choice was the Teensy 3.6 CPU board, which uses a Freescale Cortex-M4...

https://www.adafruit.com/product/3266

If Linux is preferred, the BeagleBone Black has two CAN interfaces. Built-in software drivers exposes them as network sockets - just like Ethernet.

The best solution likely depends on what your particular end-game is. Something which easily enables a nice pretty display, or a more low-level project.


----------



## TjckTock

fast_like_electric said:


> By far, the coolest and most comprehensive Tesla CAN bus project is documented here...
> 
> https://teslatap.com/modifications/tshow-front-end-light-show/


Wow. That *is* awesome. I immediately ran outside to see how it might go on a 3. Unfortunately, I decided there is no way to do it as nicely without ruining the clean front end :'(

My plan ATM is to just make a box to tuck into that space below the connector which I can connect to via bluetooth to control with an Android app. Initially just for reverse-engineering traffic but there are a few other things I want to do which I can do with this basic setup.


----------



## JWardell

fast_like_electric said:


> By far, the coolest and most comprehensive Tesla CAN bus project is documented here...
> 
> https://teslatap.com/modifications/tshow-front-end-light-show/
> 
> To pull it off, he also needed access to two CAN buses. His choice was the Teensy 3.6 CPU board, which uses a Freescale Cortex-M4...
> 
> https://www.adafruit.com/product/3266
> 
> If Linux is preferred, the BeagleBone Black has two CAN interfaces. Built-in software drivers exposes them as network sockets - just like Ethernet.
> 
> The best solution likely depends on what your particular end-game is. Something which easily enables a nice pretty display, or a more low-level project.


Just looked at the video and immediately thought, this would be easy with some neopixels and a diffuser...looks like that's what they used 

Not sure why it needs CAN though when it is controlled over bluetooth by a phone app?



TjckTock said:


> So.. Do you actually *want* 50 sets? Just checking because of the "if that's what it takes" comment (not sure if it was meant to apply to the quantity or the "made by a CM" comment).


I of course just need one. But if it's $200 for one and $300 for 50, I would go with the latter. Certainly can find customers in the future once there are some things to do with it.

I still have to figure out that second data bus as well.


----------



## fast_like_electric

JWardell said:


> Just looked at the video and immediately thought, this would be easy with some neopixels and a diffuser...looks like that's what they used
> 
> Not sure why it needs CAN though when it is controlled over bluetooth by a phone app?


The phone app is just the user interface to change modes and functions. The CAN buses are used for having the light strip display state of charge, running lamps, and the clever mode where the 'eyes' follow the steering wheel. The video shows those modes off pretty good, and there is a lot more info on the multi-page write up on the site. He really took the mechanical and electrical design of the project to a high level.


----------



## 96s46p

JWardell said:


> It _can_ be a HUD, eventually...I have plenty more iterations in mind. It was just a good inside joke.


i know.... But I still like the idea of hacking a motorized bb-8 head


----------



## brianman

Speaking for myself, I'm really missing the streaming data that I used to have in my Model S vehicles. Additionally, even in the Model S vehicles I was always at the mercy of the cell connection to get any data at all.

I had a BlackVue dashcam on my original Model S, which acted as a wifi network. I had a server running in the garage that pulled the videos off overnight for long-term storage. I miss having that facility.

With that as a backdrop, I'd love to (1) attach _as non-invasively and reversibly as possible_ a device to my Model 3 that allowed capturing of CAN information to a storage device within the car and (2) have an easy mechanism to wirelessly (wifi, Bluetooth, etc.) transfer the data when parked at home for long-term storage and analysis. I don't have a good feel yet for the unfiltered data storage requirements on a yearly scale, but I suspect with compression, duplicate removal, and some basic filtering it might not be insane.


----------



## TjckTock

I put together a parts list of what I think we need and have asked for some quotes. Hopefully something will come through.

(for 1 set - I requested 10 sets):

QTY Part number Description
1 6098-5622 TS series 20 way female housing
16 8100-3624 TS series female pin 0.22-0.35mm2 wire
4 8240-0214 TS series female pin 2.0mm2 wire
1 6098-5613 TS series 20 way male housing
16 8100-3622 TS series male pin 0.22-0.35mm2 wire
4 8230-4923 TS series male pin 2.0mm2 wire


----------



## JWardell

brianman said:


> Speaking for myself, I'm really missing the streaming data that I used to have in my Model S vehicles. Additionally, even in the Model S vehicles I was always at the mercy of the cell connection to get any data at all.
> 
> I had a BlackVue dashcam on my original Model S, which acted as a wifi network. I had a server running in the garage that pulled the videos off overnight for long-term storage. I miss having that facility.
> 
> With that as a backdrop, I'd love to (1) attach _as non-invasively and reversibly as possible_ a device to my Model 3 that allowed capturing of CAN information to a storage device within the car and (2) have an easy mechanism to wirelessly (wifi, Bluetooth, etc.) transfer the data when parked at home for long-term storage and analysis. I don't have a good feel yet for the unfiltered data storage requirements on a yearly scale, but I suspect with compression, duplicate removal, and some basic filtering it might not be insane.


The whole goal is to produce something that is plug and play and non-invasive. I am more concerned with live display of data, but adding a wifi module or SD card should be trivial. As you can see by the log files there is a TON of data, but there are plenty of games to play not just with compression but filtering of only interested message before storage or reducing time fidelity.



TjckTock said:


> I put together a parts list of what I think we need and have asked for some quotes. Hopefully something will come through.
> 
> (for 1 set - I requested 10 sets):
> 
> QTY Part number Description
> 1 6098-5622 TS series 20 way female housing
> 16 8100-3624 TS series female pin 0.22-0.35mm2 wire
> 4 8240-0214 TS series female pin 2.0mm2 wire
> 1 6098-5613 TS series 20 way male housing
> 16 8100-3622 TS series male pin 0.22-0.35mm2 wire
> 4 8230-4923 TS series male pin 2.0mm2 wire


Looks right to me. 
The other idea I had was if they had PCB mount connectors. That would be a lot easier than all of these parts and crimping everything. I could turn around a small PCB with the male and female connectors on it in a few days. But I don't think they make them (how do the other end of these Sumitomo harnesses terminate into their respective controllers? Probably a more standard connector)


----------



## TjckTock

JWardell said:


> The whole goal is to produce something that is plug and play and non-invasive. I am more concerned with live display of data, but adding a wifi module or SD card should be trivial. As you can see by the log files there is a TON of data, but there are plenty of games to play not just with compression but filtering of only interested message before storage or reducing time fidelity.
> 
> Looks right to me.
> The other idea I had was if they had PCB mount connectors. That would be a lot easier than all of these parts and crimping everything. I could turn around a small PCB with the male and female connectors on it in a few days. But I don't think they make them (how do the other end of these Sumitomo harnesses terminate into their respective controllers? Probably a more standard connector)


Another thing I wanted to ask, @JWardell , was when you first opened the center column you mentioned you started at the top with the USB and noticed a "mystery unused port with a few wires." Any chance those wires were canbus?


----------



## amund7

brianman said:


> With that as a backdrop, I'd love to (1) attach _as non-invasively and reversibly as possible_ a device to my Model 3 that allowed capturing of CAN information to a storage device within the car and (2) have an easy mechanism to wirelessly (wifi, Bluetooth, etc.) transfer the data when parked at home for long-term storage and analysis. I don't have a good feel yet for the unfiltered data storage requirements on a yearly scale, but I suspect with compression, duplicate removal, and some basic filtering it might not be insane.


This is how I've used Scan My Tesla for 2 years, running on my phone, with an app called DriveSync that uploads and deletes all log files every time I'm on wifi.

With the model 3, I know a lot of people already want an instrument cluster in front of them, a clever mount + a tablet or phone running Scan My Tesla would fix all this, + the above.
If I add a mirrored mode (like Torque has), we can also have a HUD


----------



## JWardell

TjckTock said:


> Another thing I wanted to ask, @JWardell , was when you first opened the center column you mentioned you started at the top with the USB and noticed a "mystery unused port with a few wires." Any chance those wires were canbus?


Good question. Just easily yanked off the vent/USB port section and it was in there. I will check again.



amund7 said:


> This is how I've used Scan My Tesla for 2 years, running on my phone, with an app called DriveSync that uploads and deletes all log files every time I'm on wifi.
> 
> With the model 3, I know a lot of people already want an instrument cluster in front of them, a clever mount + a tablet or phone running Scan My Tesla would fix all this, + the above.
> If I add a mirrored mode (like Torque has), we can also have a HUD


I didn't realize it was an android app with gauges and such (there's no screen shots on the site!). Is your only method of input an ODBII adapter? I feel like we could work to find another way.


----------



## Bokonon

96s46p said:


> 0x505 (100 ms) - repeats the same 7 values in a loop:
> 
> 00 03 5A 9A CE 6B 00 00
> 0B 00 00 00 00 00 7D 20
> 19 *31 30 39 39 33 34 34*
> 1A *2D 30 30 2D 43* 00 00
> This is the part number of the 14-50 adapter plug 1099344-00-C


Random thought... Could byte 8 in 0x505 part 2 be the maximum current allowed under the current charging setup, per the Mobile Connector model and adapter pigtail, or Wall Connector dip switch?

20 = 32 amps would be the right value for this particular capture. It would also be distinct from the lower charge current limit (24A?) that I believe @JWardell has set at his house.

Would be curious to see if this is 0C for the NEMA 5-15 adapter, or various other values (28 or higher) for a Wall Connector setup.

Wonder also if some part of byte 7 somehow identifies the EVSE type. And whether all those 00s would light up at a supercharger.


----------



## amund7

JWardell said:


> I didn't realize it was an android app with gauges and such (there's no screen shots on the site!). Is your only method of input an ODBII adapter? I feel like we could work to find another way.


There are quite a few: https://play.google.com/store/apps/details?id=com.emon.canbus.tesla

I will tell you the reason why I ended up with an Android app. I am like you in that I love playing around with Arduinos, Raspberry Pis etc. But you soon realize that making a good looking and fast display for an any of these is very hard. And if you manage to do that, then you realize you don't want a static display, but a customizable one. So you start making buttons, and clumsy menus. It is lots of fun, but after a while I realized I could never make anything as good looking and intuitive as a phone. Also, everyone has one. So that's my reasoning. As you may know, the Android app is also open source, in case you feel like adding some cloud logging, database storage or something like that for personal projects, or just experiment with something I haven't thought of or had the time to do.

I just use an OBD2 adapter yes, but you need a quality one if you want to capture lots of packets simultaneously. The app filters out just the packets seen on your current tab, to give you the best speed possible. I hope we can arrive at some simple way to connect OBD2 adapter to model 3, like in the other teslas. Getting those adapter cables is always a bit of a hassle though, as they come and go from ebay and other places. I've played with the idea of making a Raspberry Pi or other such hardware to act as a canbus/obd2 emulator that the app could use (could also skip OBD2 and have the app speak any other protocol). But the point has to be, cheap, and available around the world. Either someone would build, sell and ship these (there is profits to be had!), or the hardware has to be easy to buy and put together for people not necessarily programmers or electronics geeks like us.


----------



## fast_like_electric

Bokonon said:


> Random thought... Could byte 8 in 0x505 part 2 be the maximum current allowed under the current charging setup, per the Mobile Connector model and adapter pigtail, or Wall Connector dip switch?
> 
> 20 = 32 amps would be the right value for this particular capture. It would also be distinct from the lower charge current limit (24A?) that I believe @JWardell has set at his house.
> 
> Would be curious to see if this is 0C for the NEMA 5-15 adapter, or various other values (28 or higher) for a Wall Connector setup.
> 
> Wonder also if some part of byte 7 somehow identifies the EVSE type. And whether all those 00s would light up at a supercharger.


Correct, byte 8 is the max allowable current rating of the plug, 1 bit = 1A. Byte 7 is the voltage rating, 1 bit = 2V. Below are the packets for a NEMA 5-15...

0B 00 00 00 00 00 3E 0C Max ratings: Byte 7: 124V (2V/bit), Byte 8: 12A curent limit (1A/bit)
19 31 30 39 39 33 34 35 \ NEMA 5-15 120V/15A adapter plug part number: 1099345-00-C
1A 2D 30 30 2D 43 00 00 /

When you use a non-Tesla EVSE to charge, you don't see any of the 'charger' identification frames 505/514/51E.


----------



## JWardell

Here's a walkthrough of what I have right now:








amund7 said:


> There are quite a few: https://play.google.com/store/apps/details?id=com.emon.canbus.tesla
> 
> I will tell you the reason why I ended up with an Android app. I am like you in that I love playing around with Arduinos, Raspberry Pis etc. But you soon realize that making a good looking and fast display for an any of these is very hard. And if you manage to do that, then you realize you don't want a static display, but a customizable one. So you start making buttons, and clumsy menus. It is lots of fun, but after a while I realized I could never make anything as good looking and intuitive as a phone. Also, everyone has one. So that's my reasoning. As you may know, the Android app is also open source, in case you feel like adding some cloud logging, database storage or something like that for personal projects, or just experiment with something I haven't thought of or had the time to do.
> 
> I just use an OBD2 adapter yes, but you need a quality one if you want to capture lots of packets simultaneously. The app filters out just the packets seen on your current tab, to give you the best speed possible. I hope we can arrive at some simple way to connect OBD2 adapter to model 3, like in the other teslas. Getting those adapter cables is always a bit of a hassle though, as they come and go from ebay and other places. I've played with the idea of making a Raspberry Pi or other such hardware to act as a canbus/obd2 emulator that the app could use (could also skip OBD2 and have the app speak any other protocol). But the point has to be, cheap, and available around the world. Either someone would build, sell and ship these (there is profits to be had!), or the hardware has to be easy to buy and put together for people not necessarily programmers or electronics geeks like us.


As I said, there are a bunch of ways to get to the same goal and different for everyone. But don't tell me pretty displays aren't possible! As I said, stay tuned...


----------



## fast_like_electric

96s46p said:


> 0x712 seems to have a lot of negative spike noise but trends around 6.5c to 8.5c in the latest log. I don't know if that is reasonable for battery temps to only increase 2c in your drive. But sitting in a warm garage those values trend around 23c and 30c during charging so they make sense as temps. The noise magnitude seems to be consistent also.


Took a look at this under sub 0 degrees celcius (car said 18F, or -7.8C). Had to drive the car into the garage to do the capture, so temps going up a bit. ID 0x712 definately signed data (int16), in the ballpark of expected temperature and trending appropriately. However the wide variation between reads of several degrees C seems out of place for a measurement that seems to have a 0.01C / bit scaling precision. Same behavior as at other temps - don't understand the variation. Plot of the 16 variables below - x in seconds, y in degrees C...


----------



## JWardell

fast_like_electric said:


> Took a look at this under sub 0 degrees celcius (car said 18F, or -7.8C). Had to drive the car into the garage to do the capture, so temps going up a bit. ID 0x712 definately signed data (int16), in the ballpark of expected temperature and trending appropriately. However the wide variation between reads of several degrees C seems out of place for a measurement that seems to have a 0.01C / bit scaling precision. Same behavior as at other temps - don't understand the variation. Plot of the 16 variables below - x in seconds, y in degrees C...
> View attachment 20416


Funny, I was also digging into 712 this morning. I even added a few to my display but took it out because they just weren't the right values. They DO in general increase with the other temperatures, but the typical temp scaling that is used elsewhere just doesn't seem quite right.
Minimum Battery Temp in ID 212 does seem correct though when using a -40 offset. I graphed it next to CanBusAnalyzer's built-in decoding of 712 cell temps, and the minimum values were different than the minimum temperature here. I understand it is probably averaging out the spikes but I want to investigate more.

I regret not having what I needed to make a recording this morning, as I not only had a frozen battery with no regen, but several dots in power limit as well. It will be almost as cold tonight, I'm going to let it sit again and grab a recording tomorrow morning. I definitely want to see what these all values read when they go negative.

And yes, I still need to record at a supercharger some day.


----------



## amund7

JWardell said:


> As I said, there are a bunch of ways to get to the same goal and different for everyone. But don't tell me pretty displays aren't possible! As I said, stay tuned...


Wow, that is awesome, you managed to get so much in there, even battery capacities  That's an impressive bit of Arduino coding you have done there!

I did not mean to say pretty displays can't be done, but it's difficult, and MY journey took me to Android. It will be interesting to see what you can come up with


----------



## 96s46p

0x712 only has 1 decimal precision, hundredths is always 0. Standard deviation is < 1 degree (less at higher temps). If they are unfiltered adc samples then it could be sampling frequency vs sampling capicitance effects i.e. incomplete charge on sampling capacitor would always be a low reading. Filtered it would be very stable.


----------



## 96s46p

Do you think the lower 5 bits of can id may be a group/source id? For example battery messages are 132, 212?, 252, 292, 352, 712. All of these have lower 5 bits = 0x12.


----------



## fast_like_electric

96s46p said:


> 0x712 only has 1 decimal precision, hundredths is always 0. Standard deviation is < 1 degree (less at higher temps). If they are unfiltered adc samples then it could be sampling frequency vs sampling capicitance effects i.e. incomplete charge on sampling capacitor would always be a low reading. Filtered it would be very stable.


Good observation about the hundredths being always zero - I concur as well. The troubling part is seeing +/- 3 degree C variation from message to message (same cell group). There is no way the actual temperature is varying this much (up and down) in a few seconds time. Insufient dwell time on the sampling would not account for this seemingly random noise. Yes, less than 1 degree C standard deviaton over several samples, but this is way worse than the voltage measurement standard deviation.

Even if you average all 16 temps as a rolling average, the resultant plot shows similar temperature instability. Using a slow filter over a few minutes you can get a clean trend line, but something seems off that all this is necessary for a seemingly easy to measure temperature - where there is no issue with the voltage readings.


----------



## fast_like_electric

96s46p said:


> Do you think the lower 5 bits of can id may be a group/source id? For example battery messages are 132, 212?, 252, 292, 352, 712. All of these have lower 5 bits = 0x12.


Unfortunately that doesn't appear to hold up for other known messages from the charging system (say 0x505/514/51E), or the drive inverter frames (speed, torque, etc).


----------



## TjckTock

So far, no reply from multiple quote request. I *did*, however, find the pins available from Nexus Electronics. So I went ahead and grabbed some of them and a 5-way harness of the same series (all they had). I think I will _for now_ just pull the canbus pins with a pin extractor and make a separate 5 way connector so I can get started.



TjckTock said:


> I put together a parts list of what I think we need and have asked for some quotes. Hopefully something will come through.
> 
> (for 1 set - I requested 10 sets):
> 
> QTY Part number Description
> 1 6098-5622 TS series 20 way female housing
> 16 8100-3624 TS series female pin 0.22-0.35mm2 wire
> 4 8240-0214 TS series female pin 2.0mm2 wire
> 1 6098-5613 TS series 20 way male housing
> 16 8100-3622 TS series male pin 0.22-0.35mm2 wire
> 4 8230-4923 TS series male pin 2.0mm2 wire


----------



## amund7

96s46p said:


> Do you think the lower 5 bits of can id may be a group/source id? For example battery messages are 132, 212?, 252, 292, 352, 712. All of these have lower 5 bits = 0x12.


In the model S, each cell 'block' has 2 temperature readings, named T1 and T2. Could it be that the 3 has several more, so that there are other flags in the packet telling us which one we are seeing? So that Cell block 1 alternates between 5 different sensors, for instance.

The problem with all of this, is that this packet is already so slow, that with more divisions it becomes almost unusable (and therefore unlikely why they would send it this way)


----------



## JWardell

Cold off the press, just made another capture with very low temperatures, hopefully to concentrate on figuring out temps in all the systems.
https://www.dropbox.com/s/mc2109i7p11uoj6/Model3Log2019-01-13LowTempDriveCharge.asc.zip?dl=0
23MB zip expands to 204 MB Ascii! Driving is at the beginning so you can stop import early if you want.

Overnight temps were about 17F. The UI showed 32F at the beginning because it was in the sun but fell to 27F by the end of the drive. Actual ambient was 21F.
I left the car unplugged overnight so it is nice and chilled.

The log starts with the display off as it does shortly after the back seat.
Then wakes up as I exit and enter the front.
I quickly turn off HVAC.
In drive, there is absolute zero regen, and a good chunk of power limit as well.
I drive at low speeds for a bit to keep things cool, then enter the highway flooring it.
Towards the end when I exit the highway, I sustained 54-56mph for a bit if you want to double check GUI speeds.
After I get home and plug in I let it sit for a while while plugged in.
Hopefully we see battery heater going and temperatures rising.
It only pulls 12A ~2.5kW from the wall from this period, and zero current is going to the battery. (Accelerations will heat things up much faster than battery heating!)
At one point I turn seat heater on full for a bit. Curious if we can determine load maybe from the DC/DC converter increasing output?
I attempted to turn all on but could not without all HVAC turning on which you might quickly see. I shut it all down again and let it charge some more.
Gave up waiting for it to start adding any current to the battery.
The UI shows SOC at 66 to 65 with snowflake. Confirmed phone app agrees.

Quick analysis shows my decoding of ID 212 Byte 7 Min batt temp (scale .5 post offset -40) continues to make sense. Starts at -5.5C


----------



## 96s46p

@JWardell have a look at 0x132 bytes 7&8 during charging


----------



## JWardell

96s46p said:


> @JWardell have a look at 0x132 bytes 7&8 during charging


This should be hours remaining to charge in hours...
Well Byte 7 certainly agrees, though I'm not sure of scaling. I happened to take a photo showing 2hr 45 min at the end when it was around 196.
Byte 8 seems to just be zero when charging, 15 in drive.

And you might notice a detail I left out, I changed charged level in the UI down and up during the first charge, and you see that reflected in this time to charge byte.


----------



## 96s46p

JWardell said:


> This should be hours remaining to charge in hours...
> Well Byte 7 certainly agrees, though I'm not sure of scaling. I happened to take a photo showing 2hr 45 min at the end when it was around 196.
> Byte 8 seems to just be zero when charging, 15 in drive.
> 
> And you might notice a detail I left out, I changed charged level in the UI down and up during the first charge, and you see that reflected in this time to charge byte.


I think it's probably a 12 bit value then 0xFFF = max when not charging


----------



## JWardell

96s46p said:


> I think it's probably a 12 bit value then 0xFFF = max when not charging


It could scaled by 1/60th (that would make sense...) with some offset? I'll need to record when almost done charging...


----------



## fast_like_electric

It is just a 12 bit value, with 1 bit = 1 minute resolution. If you want hours, then yes you can scale to 1/60. Correct that 0xFFF means not charging.


----------



## JWardell

Yep. I just went outside and confirmed it while you were posting  Just dead on minutes. Not sure how I took a picture of 2hr 45 min during that last recording, that was throwing me off.

The spreadsheet and DBC file have been updated.

I also added 266 power and dissipation which were missing....do we have an idea what dissipation means? I don't think it is losses as it is not quote the difference of battery V*A-motor power


----------



## amund7

JWardell said:


> I also added 266 power and dissipation which were missing....do we have an idea what dissipation means? I don't think it is losses as it is not quote the difference of battery V*A-motor power


In Model S dissipation = energy loss, and power from the same packet was named 'mech power', I interpret that as shaft output power.

In Scan My Tesla I assumed dissipation + mech power = total power draw from the drive unit, and that corresponded pretty well with the battery amps + 12v amps, however the dissipation signal is very grainy, always showing 0,5 kw when in gear, which is too much when stationary. From what I've seen looking at your logs, the same logic seem to apply to Model 3, again I am guessing that the power reading is actually mechanical power, or output power if you will. Converts directly to horse power.


----------



## fast_like_electric

amund7 said:


> In Model S dissipation = energy loss, and power from the same packet was named 'mech power', I interpret that as shaft output power.
> 
> In Scan My Tesla I assumed dissipation + mech power = total power draw from the drive unit, and that corresponded pretty well with the battery amps + 12v amps, however the dissipation signal is very grainy, always showing 0,5 kw when in gear, which is too much when stationary. From what I've seen looking at your logs, the same logic seem to apply to Model 3, again I am guessing that the power reading is actually mechanical power, or output power if you will. Converts directly to horse power.


I believe it is different for Model 3. If you look at the wide-open throttle plots, the HP would be too high using just the power CAN signal. Additionally, for Model 3, that CAN signal is elecPower - not mechPower. So I'm pretty sure dissipation has to be subtracted off. If you do that, the WOT plots are right in the ballpark with the 271 HP value by Motor Trend and confirmed by Tesla for the RWD. Max power (and HP) being dependent on high SOC of course as well.


----------



## JWardell

fast_like_electric said:


> I believe it is different for Model 3. If you look at the wide-open throttle plots, the HP would be too high using just the power CAN signal. Additionally, for Model 3, that CAN signal is elecPower - not mechPower. So I'm pretty sure dissipation has to be subtracted off. If you do that, the WOT plots are right in the ballpark with the 271 HP value by Motor Trend and confirmed by Tesla for the RWD. Max power (and HP) being dependent on high SOC of course as well.


From my traces, it seems that is is kW not HP, especially considering it seems to stop approximately at the discharge limit power in 252. Also shows 2.5kW when warming battery which agrees with power draw from wall

If we had a dual motor this would probably be much easier to answer


----------



## fast_like_electric

JWardell said:


> From my traces, it seems that is is kW not HP, especially considering it seems to stop approximately at the discharge limit power in 252. Also shows 2.5kW when warming battery which agrees with power draw from wall
> 
> If we had a dual motor this would probably be much easier to answer


Yes - the signal unit is in kW - that is not unknown. The question is do you need to subract off the dissipation number before applying the kW->HP conversion factor, if you wanted to display and monitor HP. Pretty sure that needs to happen or the HP numbers are too high, as well as the math not adding up with the power draw from the battery.


----------



## JWardell

fast_like_electric said:


> Yes - the signal unit is in kW - that is not unknown. The question is do you need to subract off the dissipation number before applying the kW->HP conversion factor, if you wanted to display and monitor HP. Pretty sure that needs to happen or the HP numbers are too high, as well as the math not adding up with the power draw from the battery.


If so then the scaling we have might be wrong, because they added to more than the power coming out of the battery (and frankly I hope there is not 30kW of losses!)


----------



## Roci

JWardell said:


> From my traces, it seems that is is kW not HP, especially considering it seems to stop approximately at the discharge limit power in 252. Also shows 2.5kW when warming battery which agrees with power draw from wall
> 
> If we had a dual motor this would probably be much easier to answer


I have a dual motor and a WiFi OBD2 adapter with accompanying iOS app (OBD Fusion) which can read custom PIDs from the can bus and display the values in the app, or dump them to CSV. Any idea if an adapter like this could be wired into the can wiring you discovered? The ODB2 pinout shows several additional pins, and I wonder if the protocol requires them to function:

OBD2 Connector Pinout


----------



## fast_like_electric

JWardell said:


> If so then the scaling we have might be wrong, because they added to more than the power coming out of the battery (and frankly I hope there is not 30kW of losses!)


Didn't mean to imply that adding the power and dissipation CAN signals will equal the draw from the battery - that surely won't add up. However, the drive inverter power CAN signal should be close to the power out of the battery, minus any power going to HVAC and 12V.

To illustrate better, here's a plot from one of your original runs - when you floored it twice. Note that the power from the battery (V * A) closely tracks the drive inverter power CAN signal. There's a small offset due to other system power draw - clearly shown at the beginning before the drive inverter signal starts coming in due to shifting to drive. From the plot, it's pretty conclusive that the drive inverter CAN power signal is the power into the drive inverter system, not the power out to the drive shaft.

Now, if you take that 220kW peak, that's 295HP not factoring in the dissipation loss signal. I don't buy it, especially at 65% SOC when the peak power (and HP) will be lower than max rated. However, if you subtract the 20kW dissipation (the yellow plot), that peak is now 200kW or 268 HP, which totally makes sense for 65% SOC and the rated HP of 271.

Also, >20kW dissipation loss is still over 90% efficient, for the process of converting DC to AC and mechanical motion. Even solar inverters which only convert DC to AC are in the realm of 95%. The loss does strike you as a big number, but most people don't drive at wide-open-throttle for very long.

Anyway, that's my logic. Feel free to shoot holes if you guys feel I have something amiss.


----------



## Love

Just stopping by to say I love this thread. I watch it, follow it and read every post in its' entirety.

...But I understand none of it. 😜









Keep up the great work you amazing creatures!


----------



## 96s46p

fast_like_electric said:


> Unfortunately that doesn't appear to hold up for other known messages from the charging system (say 0x505/514/51E), or the drive inverter frames (speed, torque, etc).


This might not be a strict rule and messages may be grouped in different ways but I would not be surprised if all the 0x12 messages were from the bms and all the 0x16 messages were from the drive unit. It might be helpful to at least consider these groups when decoding.


----------



## fast_like_electric

Roci said:


> I have a dual motor and a WiFi OBD2 adapter with accompanying iOS app (OBD Fusion) which can read custom PIDs from the can bus and display the values in the app, or dump them to CSV. Any idea if an adapter like this could be wired into the can wiring you discovered? The ODB2 pinout shows several additional pins, and I wonder if the protocol requires them to function:
> 
> OBD2 Connector Pinout


At least on this thread, no one has commented about successfully attaching an OBD2 scan device to read standard or custom PIDs on Model 3. That sort of device sends a message to a module (or group of modules) and requests a PID via immediate or periodic reply, via the J1979 or J2190 protocols for retrieving PIDs. So far the work here is being done to non-invasively digest the 'down the road' periodic broadcast CAN traffic. What diagnostics may be possible by sending diagnostic commands has not been explored (or shared anyway).


----------



## JWardell

Roci said:


> I have a dual motor and a WiFi OBD2 adapter with accompanying iOS app (OBD Fusion) which can read custom PIDs from the can bus and display the values in the app, or dump them to CSV. Any idea if an adapter like this could be wired into the can wiring you discovered? The ODB2 pinout shows several additional pins, and I wonder if the protocol requires them to function:
> 
> OBD2 Connector Pinout


The problem with OBD2 readers is the standard OBD bus is 125kbps CAN.
Many vehicles have a second "high speed" CAN bus on different pins running at 500kbps, the same as Model 3's bus.
If your OBD interface can support that second can bus, then you could possibly run wires to those pins and get readings. 
In my experience years ago only expensive brand-specialized readers supported that, but things may have changed by now.
(I think the second CAN changes pins depending on brand)



fast_like_electric said:


> Didn't mean to imply that adding the power and dissipation CAN signals will equal the draw from the battery - that surely won't add up. However, the drive inverter power CAN signal should be close to the power out of the battery, minus any power going to HVAC and 12V.
> 
> To illustrate better, here's a plot from one of your original runs - when you floored it twice. Note that the power from the battery (V * A) closely tracks the drive inverter power CAN signal. There's a small offset due to other system power draw - clearly shown at the beginning before the drive inverter signal starts coming in due to shifting to drive. From the plot, it's pretty conclusive that the drive inverter CAN power signal is the power into the drive inverter system, not the power out to the drive shaft.
> 
> Now, if you take that 220kW peak, that's 295HP not factoring in the dissipation loss signal. I don't buy it, especially at 65% SOC when the peak power (and HP) will be lower than max rated. However, if you subtract the 20kW dissipation (the yellow plot), that peak is now 200kW or 268 HP, which totally makes sense for 65% SOC and the rated HP of 271.
> 
> Also, >20kW dissipation loss is still over 90% efficient, for the process of converting DC to AC and mechanical motion. Even solar inverters which only convert DC to AC are in the realm of 95%. The loss does strike you as a big number, but most people don't drive at wide-open-throttle for very long.
> 
> Anyway, that's my logic. Feel free to shoot holes if you guys feel I have something amiss.
> View attachment 20517


I see what you're saying, it's as if to say to subtract the dissipation value from the power value to get the mechanical power output.
Your graph shows a small value so I might have the wrong scale factor in mine too.


----------



## Pierre Champoux

JWardell, I have a TM3D and I run a project to evaluate the interest of thermally isolating the battery (underside), cooling/heating hoses and superbottle. My challenge to go further is that I need to be able to read the coolant and battery temperatures. It is possible for Model S and X but not 3 (up to now...). Please if someone has a way, help me... I will share results.


----------



## JWardell

Pierre Champoux said:


> JWardell, I have a TM3D and I run a project to evaluate the interest of thermally isolating the battery (underside), cooling/heating hoses and superbottle. My challenge to go further is that I need to be able to read the coolant and battery temperatures. It is possible for Model S and X but not 3 (up to now...). Please if someone has a way, help me... I will share results.


Yes we can now read battery and coolant temps. 
Let me be first in line for some thermal battery insulation, mine gets blasted all night with strong freezing winds going up my driveway!


----------



## 96s46p

This matches 0x132


----------



## 96s46p

0x292


----------



## 96s46p

0x212 ?


----------



## 96s46p

0x266


----------



## 96s46p

0x108?


----------



## JWardell

96s46p said:


> This matches 0x132


Oh wow, I *completely forgot* about going through @Ingineer 's video! I'm extremely busy today but I will look at these ASAP. I wonder where he disappeared to

The first question is, are these in order of CAN message bytes or in code order, which we've seen are not the same


----------



## amund7

*OBDLink® MX+*
*Supported Protocols*
*Legislated OBD-II protocols:*

ISO 15765-4 (CAN 250/500 kbps, 11/29 bit)
ISO 14230-4 (Keyword Protocol 2000)
ISO 9141-2 (Asian, European, Chrysler)
SAE J1850 VPW (GM)
SAE J1850 PWM (Ford)
SAE J2411 Single-Wire CAN (SW-CAN) - GM proprietary network
Medium-Speed CAN (MS-CAN) - Ford proprietary network

This is a slightly pricey, but still quite standard OBD2 adapter.
The OBDLink chip also has it's own command set that allows hardware filter inclusion of single CAN IDs, so you get only exactly the traffic you want.


----------



## JWardell

Begininning to find more things shown in the video.

Confirmed ID 118 byte 4 is pedal position, scaled by 0.4 to get percent
Brake pedal status and Drive/Park are also somewhere in this message


----------



## 96s46p

JWardell said:


> Oh wow, I *completely forgot* about going through @Ingineer 's video! I'm extremely busy today but I will look at these ASAP. I wonder where he disappeared to
> 
> The first question is, are these in order of CAN message bytes or in code order, which we've seen are not the same


They are in alphabetical order


----------



## John

JWardell said:


> Confirmed ID 118 byte 4 is pedal position, scaled by 0.4 to get percent


Assume it's a 8-bit value? So 100% = 255?


----------



## fast_like_electric

John said:


> Assume it's a 8-bit value? So 100% = 255?


No, the 0.4 scaling is correct. If you look at a CAN log where wide-open-throttle has been achieved, you'll see the byte max out at 250 decimal (0xFA). 0xFF is typically reserved for uninitialized, unknown, or fault conditions.


----------



## JWardell

Yep, exactly what I assumed, then looked at data and saw 250 when I floored it. .4 is nicer than a never-ending decimal anyway


----------



## JWardell

ID 224 3rd byte appears to be PCS DCDC output current, but I can't quite figure out scaling. It very much acts like a signed byte within a signed byte (inception?) right now the best scaling I have is unsigned 8 scale .5 offset 64, but there are still a few wraps below zero. Maybe it is just acting like the switcher it is and quickly turning output off and back on. Can easily see current rise when I turn on heated seats. Video shows this with .1A resolution so it may be larger than 8 bit.
Video also shows somewhere else in this message is max capable DCDC current.
Would be nice to figure out for 12v battery discussions also happening in this forum

Edit: Appears to be 12-bit signed, start bit 16, scaling 0.1. Zero or maybe -10 offset.


----------



## fast_like_electric

JWardell said:


> ID 224 3rd byte appears to be PCS DCDC output current, but I can't quite figure out scaling. It very much acts like a signed byte within a signed byte (inception?) right now the best scaling I have is unsigned 8 scale .5 offset 64, but there are still a few wraps below zero. Maybe it is just acting like the switcher it is and quickly turning output off and back on. Can easily see current rise when I turn on heated seats. Video shows this with .1A resolution so it may be larger than 8 bit.
> Video also shows somewhere else in this message is max capable DCDC current.
> Would be nice to figure out for 12v battery discussions also happening in this forum
> 
> Edit: Appears to be 12-bit signed, start bit 16, scaling 0.1. Zero or maybe -10 offset.


If that is PCS output current, I would not expect signed data.

Also, from my observations, in addition to that signal being extremely noisy, there are huge spikes. Below is just sitting with the car off, charging. Driving shows similar behaviour. Hadn't taken any special steps to control current draw, so climate control is on.

Seems like a very unfiltered raw signal, whatever it is. Sometimes hard to discern a current / power vs. an instantaneous efficiency number.


----------



## JWardell

fast_like_electric said:


> If that is PCS output current, I would not expect signed data.
> 
> Also, from my observations, in addition to that signal being extremely noisy, there are huge spikes. Below is just sitting with the car off, charging. Driving shows similar behaviour. Hadn't taken any special steps to control current draw, so climate control is on.
> 
> Seems like a very unfiltered raw signal, whatever it is. Sometimes hard to discern a current / power vs. an instantaneous efficiency number.
> View attachment 20672


I had the same first impression. Current should certainly always be positive at that point. But if you think from a hardware perspective, a current sensor typically does have a signed output and often spikes (especially in the presence of nearby electromagnetics). So the data actually does look correct for a typical current sensor on the output of a switching supply. The values are always positive. If you zoom into the spikes, you'll see they are in fact spikes that are not rolling over and often last a few samples.


----------



## JWardell

ID 264 is PCS Charge Line Status (only when charging) containing:

ChargeLine Voltage V unsigned 12 (or 16?) bit, SB 0, scale 0.1
ChargeLine Power kW unsigned8, SB 16, scale 0.08
ChargeLine Current A unsigned8, SB 24, scale 0.5
ChargeLine Current Limit A unsigned8, SB 36, scale 0.5

updated spreadsheet and DBC file.

Confirmed with real Level2 data, but curious what this does when supercharging. The Voltage will max at 409.6V, current at 12kW, etc so maybe SC uses a different message


----------



## JWardell

Here's what you have all been waiting for, a recording while Supercharging!
https://www.dropbox.com/s/0xr3kc375q1rru6/Model3Log2019-01-19supercharge.zip?dl=0

The first file is at the beginning, and the second is at the end.
I had no choice but to plug in next to someone, so it started charging at a slow rate, but after a bit it stopped then started again at 105kW.
The second file starts with the display showing 65% SOC, 50kW/214mi/hr, +29kWh
I then disconnect and drive to a spot and park, just to record a bit of extra info recorded from drive.

A quick look shows some of the AC charging bytes are used, but the scale must change for the higher current and voltage.
The big question is if there are any new massages.

(imagine I'm that guy sitting at the supercharger with this on my laptop screen...)


----------



## Bokonon

JWardell said:


> The big question is if there are any new massages.


I don't know about new *massages*, but I can try to help with new messages. 

Apologies for being absent on the aggregate-analysis front since switching to Vector. I finally had a chance to write a quick converter to get the Vector files into my database, and here are the new messages (and counts) that I noticed versus prior captures:

*2018-12-31chargeHighwayAP*
0x160 3008
0x405 121
0xC3B 30

*2019-01-13LowTempDriveCharge* (just over 2 million messages!)
0xC7B 65
0xCD9 16
0xCDB 16
0xCF9 5
0xCFB 560

*2019-01-19supercharge*
0x215 215
0x217 215
0x244 2150
0x365 215
0x370 215
0x517 215
0x541 2150

*2019-01-19superchargeend*
(no new messages)

With 0x244, bytes 0+1 and 2+3 start out constant and then start falling off sharply in the first supercharging file (byte 2+3 falls at a much steeper slope). In the second file, they decrease much more gradually, before abruptly falling to 0 at the end. I don't know what SoC % you started out with, but if you started around, say, 40%-45%, then these values seem proportional to what I'd expect to see for maximum allowable charge current as a function of SoC % (i.e. the taper curve).

I have a harder time interpreting 0x541 as individual bytes... I suspect there's one or more 12/16-bit values involved, as the plot for byte 2 wraps around a couple of times. There is also a lot more movement at the beginning of the supercharging session than toward the end.

0x215 seem to contain flags/state data. Bytes 1-3 are always 00. Byte 0 is almost always FF except for a blip a few seconds into the beginning of the supercharging session, when it's 3F once and then 1E three times. (Start of session?)

0x217 is a constant 00 01 11 01 00 00 00 00 across the entire supercharging session.

0x365 and 0x370 are constant 0s across the board.

0x517 is a constant 6A 18 00 00 63 3D 00 00, except for two frames when the last four bytes are all 0s. These two frames occur at the very beginning of the capture.


----------



## 96s46p

Bokonon said:


> I don't know about new *massages*, but I can try to help with new messages.
> 
> Apologies for being absent on the aggregate-analysis front since switching to Vector. I finally had a chance to write a quick converter to get the Vector files into my database, and here are the new messages (and counts) that I noticed versus prior captures:
> 
> *2018-12-31chargeHighwayAP*
> 0x160 3008
> 0x405 121
> 0xC3B 30
> 
> *2019-01-13LowTempDriveCharge* (just over 2 million messages!)
> 0xC7B 65
> 0xCD9 16
> 0xCDB 16
> 0xCF9 5
> 0xCFB 560


You may want to check your database because Max can ID is 11bit 0x7ff


----------



## JWardell

96s46p said:


> You may want to check your database because Max can ID is 11bit 0x7ff


There can be 29-bit extended IDs well above 7FF, but I don't see any here.



Bokonon said:


> I don't know about new *massages*, but I can try to help with new messages.
> 
> Apologies for being absent on the aggregate-analysis front since switching to Vector. I finally had a chance to write a quick converter to get the Vector files into my database, and here are the new messages (and counts) that I noticed versus prior captures:
> 
> *2018-12-31chargeHighwayAP*
> 0x160 3008
> 0x405 121
> 0xC3B 30
> 
> *2019-01-13LowTempDriveCharge* (just over 2 million messages!)
> 0xC7B 65
> 0xCD9 16
> 0xCDB 16
> 0xCF9 5
> 0xCFB 560
> 
> *2019-01-19supercharge*
> 0x215 215
> 0x217 215
> 0x244 2150
> 0x365 215
> 0x370 215
> 0x517 215
> 0x541 2150
> 
> *2019-01-19superchargeend*
> (no new messages)
> 
> With 0x244, bytes 0+1 and 2+3 start out constant and then start falling off sharply in the first supercharging file (byte 2+3 falls at a much steeper slope). In the second file, they decrease much more gradually, before abruptly falling to 0 at the end. I don't know what SoC % you started out with, but if you started around, say, 40%-45%, then these values seem proportional to what I'd expect to see for maximum allowable charge current as a function of SoC % (i.e. the taper curve).
> 
> I have a harder time interpreting 0x541 as individual bytes... I suspect there's one or more 12/16-bit values involved, as the plot for byte 2 wraps around a couple of times. There is also a lot more movement at the beginning of the supercharging session than toward the end.
> 
> 0x215 seem to contain flags/state data. Bytes 1-3 are always 00. Byte 0 is almost always FF except for a blip a few seconds into the beginning of the supercharging session, when it's 3F once and then 1E three times. (Start of session?)
> 
> 0x217 is a constant 00 01 11 01 00 00 00 00 across the entire supercharging session.
> 
> 0x365 and 0x370 are constant 0s across the board.
> 
> 0x517 is a constant 6A 18 00 00 63 3D 00 00, except for two frames when the last four bytes are all 0s. These two frames occur at the very beginning of the capture.


These are the FastChargeLimits shown in Ingineer's video...I'm working on massaging the messages now. 

I already have several more less-confident signals in the spreadsheet, keep an eye on it. I should post several new ones I'm working on soon when I have more confidence.


----------



## JWardell

I'm overdue for going outside and shoveling all the ice that's been raining from the sky, so I need to stop here for the day.
Here's a bunch more IDs. Updated spreadsheet and DBC.

0x321
CoolantTempBatteryInlet C u10 SB 0 scale 0.125 offset -40
CoolantTempPowertrainInlet C u10 SB 10 scale 0.125 offset -40
Ambient Temp Raw C u8 SB 24 scale 0.5 offset -40
Ambient Temp Filtered C u8 SB 40 scale 0.5 offset -40
(Ambient meaning outside temp)

0x3D8
Elevation Meters signed 16? scale 1 offset 0
I'm assuming this is signed, I need to drive in a deep tunnel or something..

0x244
FastCharge Current Limit A u16 SB0 scale 0.164? offset 0
FastCharge Power Limit kW u16 SB16 scale 0.025? offset 0
min & max V limits TBD
These are the closest scales I could get to actual values, but not confident

0x541
FastCharge Max Current Limit A u16 SB0 scale 0.164 offset 0
FastCharge Max Power Limit kW u16 SB16 scale 0.025 offset 0
These are the closest scales I could get to actual values, but not confident


----------



## Bokonon

Bokonon said:


> 0xC3B 30
> 0xC7B 65
> 0xCD9 16
> 0xCDB 16
> 0xCF9 5
> 0xCFB 560





96s46p said:


> You may want to check your database because Max can ID is 11bit 0x7ff


Thanks for pointing this out. All of the above IDs are actually ID 0xC (12) combined with the first data byte. My quick-and-dirty import process assumed that Vector's ASCII format zero-padded the ID column to three hex digits, but there is no such padding.


----------



## 96s46p

Bokonon said:


> Thanks for pointing this out. All of the above IDs are actually ID 0xC (12) combined with the first data byte. My quick-and-dirty import process assumed that Vector's ASCII format zero-padded the ID column to three hex digits, but there is no such padding.


I'm guessing 0x160 is also same situation (0x16)


----------



## TjckTock

According to Ingineer there are three main canbus' on the TM3 (vehicle, chassis, and party). Anyone know which of these is the one found on pins 18 & 19?


----------



## JWardell

TjckTock said:


> According to Ingineer there are three main canbus' on the TM3 (vehicle, chassis, and party). Anyone know which of these is the one found on pins 18 & 19?


We are looking at the vehicle bus, I haven't had the chance to look into the other busses with a good scope.
Also would like to find other locations where this bus is easily accessed.
Maybe some place with a more obtainable connector.


----------



## TjckTock

There are four more twisted pairs in that connector so with some luck we might be able to get all three in one location. I need to invest in one of those portable scopes. Mine is wall power and too bulky. I did look at the DC level on the other twisted pairs with a DMM and they are terminated to about the same CM level (2.5V) so I think there is a good chance some are also CAN. I added a sheet to your doc with what I learned so far.

BTW, I can confirm no adverse effects of unplugging the connector other than not being able to drive while disconnected. I turned the power off at the security screen first, but that's probably being overly paranoid.


----------



## JWardell

TjckTock said:


> BTW, I can confirm no adverse effects of unplugging the connector other than not being able to drive while disconnected. I turned the power off at the security screen first, but that's probably being overly paranoid.


I'm sure it's fine while powered down, the question is if it is awakened does it log an issue that gets sent back to the mothership.
Of course at this point I've mistakenly shorted the bus and caused enough errors a few times, and well the phone has yet to ring. I just worry about disconnecting whatever ethernet or other comms are going through that connector to the security module.


----------



## dleonhart

Hi, has anyone determined what connector/harness is used for the model 3 EDR download yet? Crash Data Group confirmed they use the Peak adapter. Here is a pic of all the harnesses included in the kit, and it does appear to have a white connector, which is "similar" to the one located on the passenger's side floorboard door panel. (Where CDG said the connector was located) Obviously, the resolution of this pic doesn't show the type of connectors, but there doesn't appear be Ethernet. If anyone is familiar with the model S & X harness, that might shine some light on which remaining harnesses... just guessing.


----------



## JWardell

dleonhart said:


> Hi, has anyone determined what connector/harness is used for the model 3 EDR download yet? Crash Data Group confirmed they use the Peak adapter. Here is a pic of all the harnesses included in the kit, and it does appear to have a white connector, which is "similar" to the one located on the passenger's side floorboard door panel. (Where CDG said the connector was located) Obviously, the resolution of this pic doesn't show the type of connectors, but there doesn't appear be Ethernet. If anyone is familiar with the model S & X harness, that might shine some light on which remaining harnesses... just guessing.
> View attachment 20895


Why are there 5 harnesses? Roadster, S, X, 3, Falcon 9?


----------



## 96s46p

*TIV-144:* In-vehicle cable for Tesla Model S and Model X
*TIV-145: *In-vehicle cable for Tesla Model S (legacy)
*TIV-996:* In-vehicle cable for Tesla Model 3
*TD2M-601:* Direct-to-module cable for Tesla Model X and 3
*TD2M-602:* Direct-to-module cable for Tesla Model S
Second from left is probably TIV-996


----------



## TjckTock

For the bargain price of $995 you can buy your own kit here. Looks like it is not a pass-thru and intended only for stationary download of data, though.


----------



## hsd06

Here is more info on x118 msg

brake on off byte 3 - bit 3 (when counting 7,6,5,...1) total 1 bit long
acc pedal byte 5 - 8 bits long
prndl - state encoded - byte 3 - 7,6,5,4 bits (total 4 bits long)
park = 2
rev = 4
neutral =6
drive 8


i found CAN in another location, inside trunk, to the left behind the enclosure there is a module with heart beat (i guess some security module, haa!) but the CAN that you guys found has better msgs and resolution

thanks to everyone for contributing


----------



## Bokonon

hsd06 said:


> i found CAN in another location, inside trunk, to the left behind the enclosure there is a module with heart beat (i guess some security module, haa!) but the CAN that you guys found has better msgs and resolution


Chargeport CAN maybe?


----------



## fast_like_electric

Bokonon said:


> Chargeport CAN maybe?


Right. Single wire CAN is used to communicate with Tesla chargers (and superchargers) via alternate modulation on the J1772 pilot pin.

Lots of CAN links (and LIN and two wire Ethernet) in the car - many for a specific targeted purposes such as the Autopilot system. Different than what is currently being looked at here, but lots of stuff going on all over the car.


----------



## b0n3z

TLDR: I tried to order a connector from this company and they wouldn't sell them separately. I even asked if they could provide a source - but nothing.

Company: FleetCarma - SmartCharge

The plan was to splice into this connection cable (white ends). What they call a "Tesla Model 3 Vehicle Interface Cable". This way the cable would just be a pass through cable and allow us to splice into the needed wires.


----------



## JWardell

hsd06 said:


> Here is more info on x118 msg
> 
> brake on off byte 3 - bit 3 (when counting 7,6,5,...1) total 1 bit long
> acc pedal byte 5 - 8 bits long
> prndl - state encoded - byte 3 - 7,6,5,4 bits (total 4 bits long)
> park = 2
> rev = 4
> neutral =6
> drive 8
> 
> i found CAN in another location, inside trunk, to the left behind the enclosure there is a module with heart beat (i guess some security module, haa!) but the CAN that you guys found has better msgs and resolution
> 
> thanks to everyone for contributing


This is the data in that message according to Ingineer's video:
PedalPos %
BrakePedal State
E??
requestDIGear P/D
immobilizerState
KeepAliveRequest
proximity

I had pedal position and I knew the states were in there but didn't have the time to figure out exactly which bits and states were which. So thank you! 

-----

At least that was my response earlier today, before I went down a 3-hour rabbit hole verifying everything....and then mapping every single bit in every state.
So here is what I have so far, and the DBC and spreadsheet are updated. I also got to learn how to encode state values...

0x118
Bytes 0 and/or 1-data TBD
Startbit 16-states TBD
*Brake Pedal 1bit SB 19
Gear u4 SB20 2=park 4=Reverse 6=Neutral 8=Drive*
Brake/hold? 1bit SB 26 - this often goes high when the brakes are on, but not always. Kind of like hold but sometimes I am moving slowly. Might be an iBooster thing
IdleState u4 SB28 4=charging 8=driving 9,10=parked
*Pedal Position % u8 SB 32 scale 0.4*
?State u4 SB 44 0=startup 1=driving 2=charging

I next need to display these live while connected and actively go through each state to see what the values are to be confident of the rest of these. I wasted a lot of scrap paper doing this from the recordings


----------



## JWardell

b0n3z said:


> TLDR: I tried to order a connector from this company and they wouldn't sell them separately. I even asked if they could provide a source - but nothing.
> 
> Company: FleetCarma - SmartCharge
> 
> The plan was to splice into this connection cable (white ends). What they call a "Tesla Model 3 Vehicle Interface Cable". This way the cable would just be a pass through cable and allow us to splice into the needed wires.
> 
> View attachment 20943
> View attachment 20944
> View attachment 20945
> View attachment 20946
> View attachment 20947
> View attachment 20948


Who are these people and how do they know our little secret?? 
Looks like they have made an OBD adapter. And they have sourced the connectors. This is definitely exactly what we need.


----------



## TjckTock

Since pins are readily available, I decided to try printing a housing. I just downloaded the non-functional model from Sumitomo and added holes for the pins. Looks like it is going to work. I will try printing tomorrow with some tougher resin (I used clear for my first try since that is what I happened to have in the printer) but it fits pretty well so I think no tweaks are needed.

(I know the twisted pair is in the wrong place - I was just testing for fit at this point)








It fits!


----------



## JWardell

TjckTock said:


> Since pins are readily available, I decided to try printing a housing. I just downloaded the non-functional model from Sumitomo and added holes for the pins. Looks like it is going to work. I will try printing tomorrow with some tougher resin (I used clear for my first try since that is what I happened to have in the printer) but it fits pretty well so I think no tweaks are needed.
> 
> (I know the twisted pair is in the wrong place - I was just testing for fit at this point)
> View attachment 20957
> 
> It fits!
> View attachment 20958


*YES!*

I was thinking something similar the other night. Sumitomo does prove step files if they are any help.
Frankly when I was tapping into the diagnostic connector I used a SIP header and that worked pretty well, although in this connector the corners are larger pins. 
It might be much simpler to 3d print a socket but have simpler pins coming off a PC board an no need for crimping pins and wiring. Not sure if that works on the other side though.
I know next to nothing about mechanical/3D printing but I'm sure there are people that could help us this way.


----------



## 96s46p

Yeah I was thinking about doing that also but I only have a fdm printer, not sure how well it will come out. Did you design the pin locking tabs in there @TjckTock ?


----------



## TjckTock

96s46p said:


> Yeah I was thinking about doing that also but I only have a fdm printer, not sure how well it will come out. Did you design the pin locking tabs in there @TjckTock ?


I did not. I was thinking I would just glue them in place (inject a drop of resin after the pins are inserted and hand cure with a UV laserpointer). However, the holes are so tight, the tabs dug in so I am not sure even that is necessary. I went ahead and uploaded the STL files to Thingiverse. I might try printing them in nylon on a SLS with Shapeways. I've used them before. Expensive, but the prints are good.

@JWardell - yeah - I started with their stp files. Was pretty easy to convert and modify. They had all the important dimensions there. Agree it would be nice to create a board mount. Crimping is tedious. However, I figure I'm just going to make one and I already have the pins.


----------



## JWardell

TjckTock said:


> I did not. I was thinking I would just glue them in place (inject a drop of resin after the pins are inserted and hand cure with a UV laserpointer). However, the holes are so tight, the tabs dug in so I am not sure even that is necessary. I went ahead and uploaded the STL files to Thingiverse. I might try printing them in nylon on a SLS with Shapeways. I've used them before. Expensive, but the prints are good.
> 
> @JWardell - yeah - I started with their stp files. Was pretty easy to convert and modify. They had all the important dimensions there. Agree it would be nice to create a board mount. Crimping is tedious. However, I figure I'm just going to make one and I already have the pins.


Well if it makes sense to make more than one or ten I'm glad to chip in for a handful, and I'm sure I'm not the only one.
In related news I did finally get a response from Sumitomo to my inquiry saying they have no reps here, but maybe they will help find a distributor.


----------



## TjckTock

I just uploaded to shapeways and was surprised at the price. Looks like you can print a pair in fine detail nylon for $35. I have ordered a pair and will let folks know if they work however Shapeways is slow. Even expedited takes a couple weeks. If anyone doesn't mind burning $35 on a gamble, you are welcome to order your own (there is no markup).
https://www.shapeways.com/product/VDKBPZ662/6098-5613
https://www.shapeways.com/product/DJ42FZZWD/6098-5622


----------



## JWardell

TjckTock said:


> I just uploaded to shapeways and was surprised at the price. Looks like you can print a pair in fine detail nylon for $35. I have ordered a pair and will let folks know if they work however Shapeways is slow. Even expedited takes a couple weeks. If anyone doesn't mind burning $35 on a gamble, you are welcome to order your own (there is no markup).
> https://www.shapeways.com/product/VDKBPZ662/6098-5613
> https://www.shapeways.com/product/DJ42FZZWD/6098-5622


Do they have cheaper pricing for quantity? Are there other places that do?
Isn't it best to wait for Rev 2?


----------



## TjckTock

JWardell said:


> Do they have cheaper pricing for quantity? Are there other places that do?
> Isn't it best to wait for Rev 2?


Yes! I offer no guarantees. However, it will be a while before I can confirm. Best case 2 weeks and then you will have to wait 2 more weeks for your order. If you are impatient *and* a gambler then go for it.

Not much improvement on price with quantity. There are a number of factors but volume of nylon is the primary one (machine time is proportional to volume of sintered material).


----------



## JWardell

"Why does that guy keep moving his car back and forth a few feet?"

This is fun to watch live 

Confirmed that other bit is Hold.


----------



## JWardell

...and if I think about it a bit more, the first Brake Pedal bit might mean Human Brake, while the other might mean Computer Brake....used for hold, but maybe also by AEB and AP. Will need to test with AP in a rapid braking situation.


----------



## rhuber

Thanks @TjckTock for creating a model so that my lazy side didn't win out and lead to me screwing posi-taps into the factory harness. 

Once I print the connectors on my makerspace's SLA printer, I plan to dig in. I did some work on the comma.ai stuff with my civic before trading it for a model 3.

My interest is more around getting raw data/telemetry to feed a system like teslafi, but open source. CAN gives access to a wealth of data that the api doesn't expose. I have a Particle Electron and carloop sitting here that are probably perfect.

My rough plan is to have the particle run from its own battery when the car is off, and drawing power from the car to recharge when the car is active or the battery drops to a low SOC. I'm hoping that selective recharging of the particle battery, as opposed to a constant parasitic draw, will prevent the issues with Tesla 12v batteries when accessories are added. (Anyone know if this is true?)

One more quick question for @JWardell - do you know if CAN data is flowing when the car is idle and/or asleep? In most cars there is CAN activity when the car is off, so I thought perhaps it would be the case here as well. I want to monitor things like battery temp and SOC when the car is powered down.


----------



## TjckTock

rhuber said:


> Once I print the connectors on my makerspace's SLA printer, I plan to dig in.


Give me another day before printing. The female connector is going through some revisions. I just got lucky with the male, the female needed some adjustments. Also, @JWardell noted in the other forum that the male connector is also available at Nexus Electronics so grab that when you order your pins. Nylon is a lot tougher than any SLA resin.


----------



## rhuber

Apologies if this has already been pointed out, but I wanted to find our connector in the @Ingineer video. It appears to be the one under the pedals in his "exploded" video.


----------



## JWardell

I have successfully captured data from the chassis CAN for the first time! Huge credit to @96s46p for finding a good connection point!
Here is the file:
https://www.dropbox.com/s/tv9ilr1he455zpv/Model3Log2019-01-26chassisRevFwd.asc.zip?dl=0

Not a very long capture, but I buckle my seat belt, turn on with brake, shift to reverse, go back a few feet, shift to forward, go forward a few feet, then park. I then twiddle with a few things like interior lights and seat heaters.

I'm very interested to what is present and missing on this bus. If any/enough motor data is present then maybe this is good enough for performance data.

And, more significantly. I was able to successfully perform an EDR download!
With the PEAK adapter and Tesla's EDR software, I had no issues connecting and downloading an EDR file.
I only get an 18k EDR file, which successully generates a report on Tesla's EDR site. However, because I have zero events, there's not much but some HEX data in it. I may post parts of this file over in the EDR thread.

As for the connection, first a warning: We disconnect the passenger seat module and when you put the car in drive you will get a safety restraint error! No idea if this calls home or not. The error does go away after everything is connected again on the next drive.
Raise the passenger seat to full height, then look underneath. There is a small black box with a few harnesses going into it, one of which is yellow. You can either disconnect the yellow connector, or squeeze the sides of the box to remove the box from the seat, then disconnect the connector. Be aware that at the moment I have not been able to get the box to clip back into the seat again.

The yellow connector has four wires, and the yellow and green wires on the end are the CAN wires. BUT the wire colors are reversed! 
This is an Amp connector so we can probably source this easily and make a harness.


----------



## JWardell

rhuber said:


> One more quick question for @JWardell - do you know if CAN data is flowing when the car is idle and/or asleep? In most cars there is CAN activity when the car is off, so I thought perhaps it would be the case here as well. I want to monitor things like battery temp and SOC when the car is powered down.


Data is definitely active while the car is idle, even after the display turns off. No easy way to tell if it's active when fully asleep, without camping out in the back seat for an hour. I bet it still is though, maybe with less nodes transmitting


----------



## TjckTock

OK. I finally have the female connector working. It is on Thingiverse here and can be ordered from Shapeways here for $12 (not tested yet!). It fits very nicely as printed on my SLA printer but I still have to test the nylon part from Shapeways so no guarantees yet. I am a bit concerned about using the SLA part while driving. Even the tough resin is not very and I would hate to have one of those thin walls split, short, and create a fault while driving. So I think I am going to only use it while parked until I get the nylon print from Shapeways.


----------



## amund7

JWardell said:


> 0x72A ASCII for indexes 00, 01 "TG11816", "00003H0"


Did anyone conclude what these mean? Because to me, they remind me of model S battery serial numbers:

T17F0137773
T14F0043390

Could this be the battery serial number you have found? On the S this was actually on a label on the battery, behind the front right wheel.


----------



## amund7

About the connector, if it's the correct part number in the spreadsheet, then I have a few of them lying around. Because, that plug is the same as the diagnostic plug for Model X, and 2015+ model S. You can get them here and there, already crimped to OBD2 connectors, or uncrimped: https://www.ebay.com/sch/i.html?_fr...ble.TRS0&_nkw=tesla+diagnostic+cable&_sacat=0

Are we sure there isn't an end point somewhere with the same plug? So we wouldn't have to create the bridge wire and two plugs. I suppose Tesla would connect to this somehow when the car is in the shop, would make sense if it's a loose plug like this somewhere ?


----------



## TjckTock

Nice! You can unplug the one in the center console and use it for diagnostics when parked. You just can't drive anywhere without the security module attched. Since that one is very easy to reach, it may be the one they use for that purpose. In Ingineer's video there does appear to be a second male connector but I assumed that went to the card reader in the driver side column.


----------



## JWardell

amund7 said:


> About the connector, if it's the correct part number in the spreadsheet, then I have a few of them lying around. Because, that plug is the same as the diagnostic plug for Model X, and 2015+ model S. You can get them here and there, already crimped to OBD2 connectors, or uncrimped: https://www.ebay.com/sch/i.html?_fr...ble.TRS0&_nkw=tesla+diagnostic+cable&_sacat=0
> 
> Are we sure there isn't an end point somewhere with the same plug? So we wouldn't have to create the bridge wire and two plugs. I suppose Tesla would connect to this somehow when the car is in the shop, would make sense if it's a loose plug like this somewhere ?
> 
> View attachment 21058


The male plug is the same, but the issue is we can't yet source a female socket in order to make a pass-through and use the car as the security module will be disconnected.
I don't think there will be any dead-end instances of this connector in the car, because there is the 4-pin ethernet diagnostic port under the steering column. I'm sure Tesla intended all connections to be made through that, but with a computer running internal Tesla software that can connect to the (encrypted?) ethernet.


----------



## TjckTock

JWardell said:


> The male plug is the same, but the issue is we can't yet source a female socket


I just ordered one of these from the list @amund7 provided. It sure looks like a female socket.


----------



## amund7

TjckTock said:


> I just ordered one of these from the list @amund7 provided. It sure looks like a female socket.


Sorry, but that's the male one, I have one of these wired to OBD2 female plug.

That means the female one is dangling below the center screen of any model S and X, just go to a breaker's yard and cut one out


----------



## TjckTock

amund7 said:


> Sorry, but that's the male one


Not according to Sumitomo.


----------



## rhuber

Made some progress and have the Electron connected and sending CAN over LTE. I am experiencing something strange - every time I reboot the Electron, I hear the contactors close and the car wakes up. I am not sure if this is wiring related or something else. I have the electron connected to CAN HIGH, CAN LOW, and with chassis ground via a wire to exposed metal on the car.


----------



## 96s46p

TjckTock said:


> Not according to Sumitomo.


Yes the gender is based on how the pins mate not how the housings mate. Remember if you are making a passthrough you have to keep each wire size the same or larger as the original.


----------



## 96s46p

rhuber said:


> Made some progress and have the Electron connected and sending CAN over LTE. I am experiencing something strange - every time I reboot the Electron, I hear the contactors close and the car wakes up. I am not sure if this is wiring related or something else. I have the electron connected to CAN HIGH, CAN LOW, and with chassis ground via a wire to exposed metal on the car.


This is probably due to some aspect of the CAN controller/transceiver not being Fail-Safe during a reboot.


----------



## amund7

TjckTock said:


> Not according to Sumitomo.
> View attachment 21077





96s46p said:


> Yes the gender is based on how the pins mate not how the housings mate. Remember if you are making a passthrough you have to keep each wire size the same or larger as the original.


It seems I am gender confused. But in any case, I thought this one was the difficult one to source?


----------



## TjckTock

rhuber said:


> Made some progress and have the Electron connected and sending CAN over LTE. I am experiencing something strange - every time I reboot the Electron, I hear the contactors close and the car wakes up. I am not sure if this is wiring related or something else. I have the electron connected to CAN HIGH, CAN LOW, and with chassis ground via a wire to exposed metal on the car.


In my device, I use VP230's to interface to the bus. Pin 8 is Standby. If I float that, it prevents the device from transmitting anything (you can still listen). I routed it through a jumper on my board so I can pull it if I want to be sure I never transmit anything regardless of what the uC is doing. Does the Electron use the same or similar devices?


----------



## TjckTock

@amund7 - Nexus electronics has the male. Between you and JWardell I think we have the complete set. Thanks both of you!


----------



## garsh

amund7 said:


> It seems I am gender confused.


No worries. We are accepting of all people here.


----------



## Feathermerchant

"It seems I am gender confused. "

You're not the only one.
I had a vendor tell me that they decided to go with a convention. It was backwards so I ended up ordering the wrong gender.
It's always pins.


----------



## JWardell

TjckTock said:


> @amund7 - Nexus electronics has the male. Between you and JWardell I think we have the complete set. Thanks both of you!


Nexus has the male but not the female https://nexelec.com/SUMITOMO-60985622/


----------



## fast_like_electric

JWardell said:


> I have successfully captured data from the chassis CAN for the first time! Huge credit to @96s46p for finding a good connection point!
> 
> As for the connection, first a warning: We disconnect the passenger seat module and when you put the car in drive you will get a safety restraint error! No idea if this calls home or not. The error does go away after everything is connected again on the next drive.
> Raise the passenger seat to full height, then look underneath. There is a small black box with a few harnesses going into it, one of which is yellow. You can either disconnect the yellow connector, or squeeze the sides of the box to remove the box from the seat, then disconnect the connector. Be aware that at the moment I have not been able to get the box to clip back into the seat again.
> 
> The yellow connector has four wires, and the yellow and green wires on the end are the CAN wires. BUT the wire colors are reversed!
> This is an Amp connector so we can probably source this easily and make a harness.


So has it been determined that the chassis bus is not on the connector in the center console on the other wire pairs? Or was the intent to just find an alternate location with a potentially more commonplace connector?


----------



## rhuber

I'm watching my car deal with the "Polar Vortex", where it wakes up every 8 or so minutes, presumably to keep the battery warm. According to TeslaFi, it is going between Sleep and Idle quite often. I verified this doesn't happen when the car is in a heated garage and also verified that it is happening to another Model 3, so this is just how the car deals with keeping the pack at safe levels temperatures.

... which mans I have the unique opportunity to log can data when the car wakes up quite often without user interaction/bluetooth key/app access.

I have a Pi with an enormous battery sitting in the car and logging all of this. I've also been logging in to look at some of the data so I can compare to the spreadsheet from the first post in this thread.

First thing of note, `113#00D7` i.e. 0x113 with data 00D7 is definitely a packet that tells (everything?) to wake up. It is always the very first packet on the bus when it goes from Sleep > Idle, and sending this packet wakes everything in my testing.

I have sturdy connection in the car and can drive with my Pi connected, so I have a plan that may help identify more of the data. I use teslafi, and have already written some parsers for the raw logs they allow you to download with timestamps. I'm going to start using the teslafi data as a kind of cheat sheet to identify more of the data on can. I plan to write something that looks for known value changes between minutes in the two datasets. I may also have it automatically try searching for signals with different scaling within values. This is obviously a pretty brute force method, but luckily it will be the computer brute forcing the data, not me.

I'll post updates if/when I find anything useful.


----------



## JWardell

rhuber said:


> I'm watching my car deal with the "Polar Vortex", where it wakes up every 8 or so minutes, presumably to keep the battery warm. According to TeslaFi, it is going between Sleep and Idle quite often. I verified this doesn't happen when the car is in a heated garage and also verified that it is happening to another Model 3, so this is just how the car deals with keeping the pack at safe levels temperatures.
> 
> ... which mans I have the unique opportunity to log can data when the car wakes up quite often without user interaction/bluetooth key/app access.
> 
> I have a Pi with an enormous battery sitting in the car and logging all of this. I've also been logging in to look at some of the data so I can compare to the spreadsheet from the first post in this thread.
> 
> First thing of note, `113#00D7` i.e. 0x113 with data 00D7 is definitely a packet that tells (everything?) to wake up. It is always the very first packet on the bus when it goes from Sleep > Idle, and sending this packet wakes everything in my testing.
> 
> I have sturdy connection in the car and can drive with my Pi connected, so I have a plan that may help identify more of the data. I use teslafi, and have already written some parsers for the raw logs they allow you to download with timestamps. I'm going to start using the teslafi data as a kind of cheat sheet to identify more of the data on can. I plan to write something that looks for known value changes between minutes in the two datasets. I may also have it automatically try searching for signals with different scaling within values. This is obviously a pretty brute force method, but luckily it will be the computer brute forcing the data, not me.
> 
> I'll post updates if/when I find anything useful.


Very interesting, I was just browsing through the cold weather threads and reading all the frozen midwest news and wishing we had some recordings during these crazy low temps. Awesome that you are!
0x113 is GTW_adc2 which appears to be some ADCs with mV recordings, doesn't seem like it would be related to this. I would guess a BMS message would wake it up. But then again any number of systems probably have the ability to wake things up if they sense a low temp


----------



## fast_like_electric

JWardell said:


> Very interesting, I was just browsing through the cold weather threads and reading all the frozen midwest news and wishing we had some recordings during these crazy low temps. Awesome that you are!
> 0x113 is GTW_adc2 which appears to be some ADCs with mV recordings, doesn't seem like it would be related to this. I would guess a BMS message would wake it up. But then again any number of systems probably have the ability to wake things up if they sense a low temp


Curious how you arrived at that. My 0x113 data content is always static at 01 D7 under a variety of conditions, which doesn't seem like any mV ADC data.


----------



## JWardell

fast_like_electric said:


> Curious how you arrived at that. My 0x113 data content is always static at 01 D7 under a variety of conditions, which doesn't seem like any mV ADC data.


Agreed, I always have seen 01D7 there to, strange the code claims it should be 7 bytes. 
I didn't see that message on the Chassis bus, maybe it is something different on the Party bus.


----------



## fast_like_electric

JWardell said:


> Agreed, I always have seen 01D7 there to, strange the code claims it should be 7 bytes.
> I didn't see that message on the Chassis bus, maybe it is something different on the Party bus.


What code?


----------



## Pierre Champoux

JWardell said:


> Very interesting, I was just browsing through the cold weather threads and reading all the frozen midwest news and wishing we had some recordings during these crazy low temps. Awesome that you are!
> 0x113 is GTW_adc2 which appears to be some ADCs with mV recordings, doesn't seem like it would be related to this. I would guess a BMS message would wake it up. But then again any number of systems probably have the ability to wake things up if they sense a low temp


Go this thread:
https://teslaownersonline.com/threads/insulated-battery.10854/page-5#post-200001


----------



## rhuber

TjckTock said:


> In my device, I use VP230's to interface to the bus. Pin 8 is Standby. If I float that, it prevents the device from transmitting anything (you can still listen). I routed it through a jumper on my board so I can pull it if I want to be sure I never transmit anything regardless of what the uC is doing. Does the Electron use the same or similar devices?


I think it was a bit of code I forgot about transmitting some frames for a Honda Civic. Weird that the car reacted to them, but maybe they overlap. Anyway, Doesn't happen since removing those accidental can writes on startup.


----------



## rhuber

fast_like_electric said:


> Curious how you arrived at that. My 0x113 data content is always static at 01 D7 under a variety of conditions, which doesn't seem like any mV ADC data.


Mine is always sending 01D7 when awake and sends a single 00D7 when it first wakes up, so I agree that there doesn't seem to be any data here. A far fetched guess, perhaps 00D7 wakes everything up and 01D7 tells everything to stay awake. I could be entirely wrong and oversimplifying, of course.

$ grep 113#00D7 candump-2019-01-29_212220.log | wc-l
41
$ grep 113#01D7 candump-2019-01-29_212220.log | wc -l
170434


----------



## rhuber

Sorry to flood the thread with my posts, but I have a bit of an update on the data gathering. It has been running for 19 hours, has data where overnight temps dropped to a reported -22F, includes a drive with severely limited power output (I'll post my hilarious 0-60mph test on youtube soonish), a 30ish mile drive, and a charge in a heated garage that is ongoing. I am going to let the charge finish before cutting off the dump, which is currently 1.5 gig uncompressed.


----------



## b0n3z

Hopefully, I might have found our female connector for a Model 3.
Check this thread:
https://teslamotorsclub.com/tmc/posts/3369602/


----------



## rhuber

Update eleventy-billion: The pi battery finally ran out of juice at 1:15am today (props Ravpower). Final file size ended up at 2.3 gig. I was thinking on how to pick apart the data, and realized Elasticsearch+kibana might work well. I'm writing a quick script to convert the data from ASCII candump output to json that I can shove into ES. I'm also going to denormalize the data into a number of formats for every line.

For example this line in candump:
(1548818708.089704) can0 39A#FEFEFEFEFEFEFE00
Would become this json:
{
"ts": 1548818708.089704
"can_id" : "39A",
"hexbytes" : "FEFEFEFEFEFEFE00",
"hexbytestoascii" : "þþþþþþþ"
"hexbyte1": "FE"
.... etc etc (maybe including slicing by 7 bit/10 bit etc, since memory is cheap)
}

I'm also going to insert my teslafi raw data into the same ES cluster.

So here is my question.. What is the best way to share the can captures I've done? I definitely would prefer to anonymize them as much as possible before sharing publicly, but a single large .gz file is pretty unweildy. I can easily convert the data to whatever format makes sense, so let me know what would work well for others. I will share my script to shove the data into an Elasticsearch cluster, but won't share access to the cluster, because that could become pricey pretty quickly.


----------



## JWardell

Oh boy...just noticed @TrevP 's tweet...


__ https://twitter.com/i/web/status/1091026906927947777
I sure hope Elon himself sees this and lends a hand


----------



## Raider1284

Heard you all may be looking for these parts?










This is using using TickTocks awesome model: https://www.thingiverse.com/thing:3379540 repairing the non-manifold geometry and then lots of test prints on my 3d printer! I can print out the male or female end.


----------



## TjckTock

Wow! I didn't think it was possible to print on an FDM printer! Nice job!


----------



## JWardell

Raider1284 said:


> Heard you all may be looking for these parts?
> View attachment 21367
> 
> 
> This is using using TickTocks awesome model: https://www.thingiverse.com/thing:3379540 repairing the non-manifold geometry and then lots of test prints on my 3d printer! I can print out the male or female end.


So are these good enough to order and just use from some online printer or do they still require work?


----------



## Raider1284

JWardell said:


> So are these good enough to order and just use from some online printer or do they still require work?


Its still unknown if these will work with the pins and wiring harness for the car, but they should work if they are the right dimensions. I'd be happy to print some out and send them to people that would be interested. Would you like a set Wardell? I've been talking with b0n3z about these parts and he suggested i post the printed parts here. Happy Friday Everyone!


----------



## TjckTock

JWardell said:


> So are these good enough to order and just use from some online printer or do they still require work?


My shapeways order will arrive Monday so I'll let you know, then. I can confirm now that the male from Nexus and the female from eBay work, though.


----------



## b0n3z

I just received my order from Nexus Electronics. Although I wish they would have responded to my e-mail so I could have added to the order for the possible other missing connector.


----------



## JWardell

b0n3z said:


> I just received my order from Nexus Electronics. Although I wish they would have responded to my e-mail so I could have added to the order for the possible other missing connector.
> 
> View attachment 21383
> View attachment 21384
> View attachment 21385


So can you confirm for sure the below cart is correct and these will work? If so I will order some next week,


----------



## JWardell

Spreadsheet and DBC have been updated with various items including these messages:

0x3D2 Total Discharge kWh u32 SB0 scale .001. Total Charge kWh u32 SB32 scale .001
(note it appears to me that CAN Analyzer app has these swapped)

And on the chassis bus:
0x04F Latitude Deg signed28 SB0 scale 1e-006 Longitude Deg signed28 SB28 scale 1e-006
(note these were removed from my public chassis trace)

Did anyone find any new interesting messages to investigate in the chassis CAN recording?


----------



## b0n3z

JWardell said:


> So can you confirm for sure the below cart is correct and these will work? If so I will order some next week,
> 
> View attachment 21390


I haven't tried the pins (male or female) yet. I have tried the male connector and it worked perfectly. However, I wish Nexus Electronics would have answered my e-mail asking if I could add the Sumitomo Female part 6090-5629 (blue). So I might have to make another order and pay shipping unless they can will-call.

@JWardell or @TjckTock Do either of you have a wiring diagram showing the pin-outs and how to get this all connected to read this data. It would save me some time looking for it if you have it handy. Thank you!

Update - I think I just answered my own question with this:
Maxwell Technologies - Tesla Diagnostic Connector Datasheet


----------



## JWardell

b0n3z said:


> I haven't tried the pins (male or female) yet. I have tried the male connector and it worked perfectly. However, I wish Nexus Electronics would have answered my e-mail asking if I could add the Sumitomo Female part 6090-5629 (blue). So I might have to make another order and pay shipping unless they can will-call.
> 
> @JWardell or @TjckTock Do either of you have a wiring diagram showing the pin-outs and how to get this all connected to read this data. It would save me some time looking for it if you have it handy. Thank you!
> 
> View attachment 21393
> View attachment 21394


OK. Let me know if you have any luck, I might just order anyway.
The pinout is in the last sheet of my spreadsheet, but all you need to make is a straight-through harness anyway, the only pins needed to tap are 18 and 19 for CAN. Of course it's a good opportunity to grab 12v and Gnd as well if you need power.


----------



## 96s46p

For those modeling the connectors are you doing the pin retention mechanisms? I think these are separate pieces, correct? You can see on the blue connector the retainer is white. Pin retention (and wire retention) is the key to a reliable connection.


----------



## 96s46p

rhuber said:


> .
> 
> So here is my question.. What is the best way to share the can captures I've done? I definitely would prefer to anonymize them as much as possible before sharing publicly, but a single large .gz file is pretty unweildy. I can easily convert the data to whatever format makes sense, so let me know what would work well for others. I will share my script to shove the data into an Elasticsearch cluster, but won't share access to the cluster, because that could become pricey pretty quickly.


I would say first remove any sequential duplicate messages per id. If you can filter out counters and checksums that would be a bonus. A minimal csv format like Busmaster .log format is ok or if you want a binary format for compactness. It would be helpful to also see a list of unique IDs you have observed with length and period.


----------



## TjckTock

b0n3z said:


> @JWardell or @TjckTock Do either of you have a wiring diagram showing the pin-outs and how to get this all connected to read this data. It would save me some time looking for it if you have it handy. Thank you!
> 
> Update - I think I just answered my own question with this:
> Maxwell Technologies - Tesla Diagnostic Connector Datasheet


I'm not sure that is relevant for the TM3 - if you go to the spreadsheet, there are some discrepancies. Pins 2 & 3, for example are not a canbus, but rather LED power. There are CAN busses at the other locations but according to user "VC" these are private can busses for the VSEC.


----------



## fast_like_electric

JWardell said:


> Spreadsheet and DBC have been updated with various items including these messages:
> 
> 0x3D2 Total Discharge kWh u32 SB0 scale .001. Total Charge kWh u32 SB32 scale .001
> (note it appears to me that CAN Analyzer app has these swapped)
> 
> And on the chassis bus:
> 0x04F Latitude Deg signed28 SB0 scale 1e-006 Longitude Deg signed28 SB28 scale 1e-006
> (note these were removed from my public chassis trace)
> 
> Did anyone find any new interesting messages to investigate in the chassis CAN recording?


For completeness, the last byte of the 0x04F GPS message is a indication of GPS accuracy. Difficult to determine if this pure DOP (dilution of precision), or the overall accuracy (DOP * device accuracy) in meters. If accuracy in meters, believe scaling is 0.2 m / bit.

https://en.wikipedia.org/wiki/Dilution_of_precision_(navigation)


----------



## amund7

New version of Canbus-Analyzer! This one reads DBC files (pick on the upper right)

I am not sure yet how good the DBC loader is, it is written by Brian-Man, looks very promising but seems to miss a few types of signals, such as boolean, but most of the model 3 DBC file seems good. We'll keep working on that.

https://github.com/amund7/CANBUS-Analyzer/releases

* On closer inspection, looks like the DBC reader is pretty much amazing! Canbus-Analyzer does not support 'enums' such as the text for different gears, different states, but that is not DBC loader's fault, the numerical values still work!


----------



## JWardell

amund7 said:


> New version of Canbus-Analyzer! This one reads DBC files (pick on the upper right)
> 
> I am not sure yet how good the DBC loader is, it is written by Brian-Man, looks very promising but seems to miss a few types of signals, such as boolean, but most of the model 3 DBC file seems good. We'll keep working on that.
> 
> https://github.com/amund7/CANBUS-Analyzer/releases
> 
> * On closer inspection, looks like the DBC reader is pretty much amazing! Canbus-Analyzer does not support 'enums' such as the text for different gears, different states, but that is not DBC loader's fault, the numerical values still work!


Sweet! I just uploaded a DBC with several fixes and updates. Many more should be coming in the next week now that I am back stateside.


----------



## parc2407

I wonder if the Moutain Pass VSC Killer is not in fact a "man in the middle" attack installed just before the car computer where it intercepts some CAN packets like the wheel position sensor, modify them to make it appear it doesn`t slip and resend them to the car.

All the other packets are re-sent to the car without modification in real time. It would make it absolutely stealth, nothing Tesla can do about it.

CAN BUS ---> VSC Killer --> Car computer 

Then again, in the long term that's the kind of project that could be done in open source with a group effort for real cheap if all the CAN packets are understood. I did a project with this board, it has 2 CAN bus (didn't use them) making it a good platform to experiment. Cost < 150$ in volume. We could use a Raspberry Pi for even cheaper with a shield but I don't like the idea, it's not industrial rated (temperature, vibration, etc). It runs Linux.

https://wiki.embeddedarm.com/wiki/TS-7670#CAN

Else a less powerful microcontroller not running a full OS like a MSP430 with a MCP2515 Can bus controler we could achieve a 50$ pricepoint. Not sure if it's fast enough. (the 2515 can go to 125kbps which I think is not enough)

The work they did at the speed they made it is absolutely amazing and if (when!) they release it if the price is not prohibitive that's the kind of thing I'd buy! Kudos to them!


----------



## b0n3z

@parc2407 - I like the way you think! This is why I love a community that is passionate about something.


----------



## JWardell

parc2407 said:


> I wonder if the Moutain Pass VSC Killer is not in fact a "man in the middle" attack installed just before the car computer where it intercepts some CAN packets like the wheel position sensor, modify them to make it appear it doesn`t slip and resend them to the car.
> 
> All the other packets are re-sent to the car without modification in real time. It would make it absolutely stealth, nothing Tesla can do about it.
> 
> CAN BUS ---> VSC Killer --> Car computer
> 
> Then again, in the long term that's the kind of project that could be done in open source with a group effort for real cheap if all the CAN packets are understood. I did a project with this board, it has 2 CAN bus (didn't use them) making it a good platform to experiment. Cost < 150$ in volume. We could use a Raspberry Pi for even cheaper with a shield but I don't like the idea, it's not industrial rated (temperature, vibration, etc). It runs Linux.
> 
> https://wiki.embeddedarm.com/wiki/TS-7670#CAN
> 
> Else a less powerful microcontroller not running a full OS like a MSP430 with a MCP2515 Can bus controler we could achieve a 50$ pricepoint. Not sure if it's fast enough. (the 2515 can go to 125kbps which I think is not enough)
> 
> The work they did at the speed they made it is absolutely amazing and if (when!) they release it if the price is not prohibitive that's the kind of thing I'd buy! Kudos to them!


I agree...considering they did it quickly and specifically by hacking into the CAN, however we still don't really know where each of these messages are sent from and it would be tough to determine for sure they are coming from a particular device as everything is broadcast, and a lot of signals are repeated across networks. It may be simpler, perhaps if a bad message from the antilock system is received just once it is enough for the system to disable traction control for the remainder of the drive. In which case you could just inject one message with error data in it. I may experiment with that eventually.


----------



## b0n3z

Just ordered some more parts. Hopefully these 6098-5629 blue female parts work. I'll let you guys know. I should receive them on 2/6/19 Wednesday.


----------



## b0n3z

BTW - did you guys see what Mountain Pass Performance did? They created a VSC Killer. But look what connections they have! It seems they might have a button for on/off - but more importantly they are using a different connection (at the front passenger side I believe). I thought that location/connection was encrypted...


----------



## fast_like_electric

b0n3z said:


> ... look what connections they have! It seems they might have a button for on/off - but more importantly they are using a different connection (at the front passenger side I believe). I thought that location/connection was encrypted.


The Vehicle (aka Powertrain) and Chassis main CAN buses are not encrypted. They are available at a variety of locations - behind the center console is just a convenient one to get easy access to the vehicle bus. Not sure if the MountainView device needs to tap into just the vehicle bus or if they use the chassis bus as well. Both buses have useful information - some duplicate, some unique. For example, detailed battery info is on vehicle bus only, GPS is on chassis only, but steering angle/speed/gear is on both.

Ultimately a lot of effort has gone into rigging something up for accessing the vehicle bus at the center console connector, but given that there are alternate locations - some of those may have more easy to acquire connectors, and have access to more bus info.

It would be immensely helpful if someone in Massachusetts would subscribe to the one hour web Tesla service subscription and share a summary of some of the key CAN wiring, module connections, locations, and pinouts. I'd do it in a second, but I'm one state away and MA credit card is required.


----------



## TjckTock

I just got my blue parts yesterday (5629) - yes, they do work! I took down the shapeways part - no need to print if you can buy for <$3.


----------



## TjckTock

b0n3z said:


> I thought that location/connection was encrypted...


Apparently not. It may just be using a LFSR checksum to ensure no bit errors cause the vehicle to crash. This looks a lot like encryption but* is not intended for security* (will prevent accidental or random errors but not robust against a deliberate attack). The Nissan Leaf did the same on the throttle and other canbus commands. Didn't want any chance of a single bit error causing the car to lurch ahead. That polynomial was relatively easy to reverse engineer. I bring this up because the distinction is important from a legal standpoint. Reverse engineering a LFSR CRC is legal. Cracking someone's encryption is not.


----------



## fast_like_electric

TjckTock said:


> Apparently not. It may just be using a LFSR checksum to ensure no bit errors cause the vehicle to crash. This looks a lot like encryption but* is not intended for security* (will prevent accidental or random errors but not robust against a deliberate attack). The Nissan Leaf did the same on the throttle and other canbus commands. Didn't want any chance of a single bit error causing the car to lurch ahead. That polynomial was relatively easy to reverse engineer. I bring this up because the distinction is important from a legal standpoint. Reverse engineering a LFSR CRC is legal. Cracking someone's encryption is not.


Actually, that's not what the counter and checksum bytes are for. CAN already has a 16 bit CRC and a guaranteed message delivery and integrity, with all nodes checking every message and erroring out and retrying if corrupt. All handled automatically by the CAN controller peripherals - very robust, and all of this going on behind the scenes (not shown in the CAN message logs).

The reason for the messages with additional counter and checksums (and sometimes CRCs) are for anti-reply and anti-substitution. The messages which were deemed to have critical and/or control information are protected in this way. This prevents someone from injecting a rogue message as the ECU will throw it out as being out of sequence. Sorta the same idea as rolling codes for a garage door opener. The counter/checksum approach is low-tech, but effective.

Only used where deemed necessary, as it is expensive in that it gobbles up 10-12 bits of the 64 bits available per max message size. Size being dependent on the number of bits of the counter (2-4 used by Tesla), and the 8 bit checksum/CRC.


----------



## JWardell

b0n3z said:


> Just ordered some more parts. Hopefully these 6098-5629 blue female parts work. I'll let you guys know. I should receive them on 2/6/19 Wednesday.
> 
> View attachment 21589


I gave up waiting and ordered my parts on Monday, but I bet you will beat me on shipping across the country!



b0n3z said:


> BTW - did you guys see what Mountain Pass Performance did? They created a VSC Killer. But look what connections they have! It seems they might have a button for on/off - but more importantly they are using a different connection (at the front passenger side I believe). I thought that location/connection was encrypted...
> 
> View attachment 21590
> View attachment 21591


They did always say they found CAN somewhere in the footwell. I see a Deutsch connector and the white one almost looks like the diagnostic connector. And the white one might be the diagnostic port connector? Does anyone recognize where these plug in to? I guess we will know once MPP releases installation instructions.



fast_like_electric said:


> The Vehicle (aka Powertrain) and Chassis main CAN buses are not encrypted. They are available at a variety of locations - behind the center console is just a convenient one to get easy access to the vehicle bus. Not sure if the MountainView device needs to tap into just the vehicle bus or if they use the chassis bus as well. Both buses have useful information - some duplicate, some unique. For example, detailed battery info is on vehicle bus only, GPS is on chassis only, but steering angle/speed/gear is on both.
> 
> Ultimately a lot of effort has gone into rigging something up for accessing the vehicle bus at the center console connector, but given that there are alternate locations - some of those may have more easy to acquire connectors, and have access to more bus info.
> 
> It would be immensely helpful if someone in Massachusetts would subscribe to the one hour web Tesla service subscription and share a summary of some of the key CAN wiring, module connections, locations, and pinouts. I'd do it in a second, but I'm one state away and MA credit card is required.


I thought some folks already had service harness info and it wasn't detailed enough to show every can location, is that true?



fast_like_electric said:


> Actually, that's not what the counter and checksum bytes are for. CAN already has a 16 bit CRC and a guaranteed message delivery and integrity, with all nodes checking every message and erroring out and retrying if corrupt. All handled automatically by the CAN controller peripherals - very robust, and all of this going on behind the scenes (not shown in the CAN message logs).
> 
> The reason for the messages with additional counter and checksums (and sometimes CRCs) are for anti-reply and anti-substitution. The messages which were deemed to have critical and/or control information are protected in this way. This prevents someone from injecting a rogue message as the ECU will throw it out as being out of sequence. Sorta the same idea as rolling codes for a garage door opener. The counter/checksum approach is low-tech, but effective.
> 
> Only used where deemed necessary, as it is expensive in that it gobbles up 10-12 bits of the 64 bits available per max message size. Size being dependent on the number of bits of the counter (2-4 used by Tesla), and the 8 bit checksum/CRC.


That is all correct. In other words the added CRCs are to prevent just what MPP is doing 
My first reaction was similar, why are they adding all this extra overhead? But then I've already come across several instances in the past few months at work could have been prevented with it.


----------



## fast_like_electric

JWardell said:


> I thought some folks already had service harness info and it wasn't detailed enough to show every can location, is that true?


If there are folks that have, they haven't shared anything here. The public parts catalog (for everyone) info doesn't detail the wiring beyond showing the harnesses. The purchasable subscription service (different) is supposed to have much greater info - with actual wiring diagrams and other info. $32 for 1 hour, $106 for 24 hour - a variety of pricing. This is the site (not the parts catalog)...

https://service.teslamotors.com/

Ok wow, Just checked the site. It now seems like states other than MA are now accepted. Didn't go through the whole purchase process to see if it works for non-MA though, but it does seem to let you pick other states now along the way to checkout. Not a good time for me to do an 1-hour subscription and get the most out of it, but perhaps others may give it a go and share pertinent info on CAN hookup.


----------



## b0n3z

fast_like_electric said:


> If there are folks that have, they haven't shared anything here. The public parts catalog (for everyone) info doesn't detail the wiring beyond showing the harnesses. The purchasable subscription service (different) is supposed to have much greater info - with actual wiring diagrams and other info. $32 for 1 hour, $106 for 24 hour - a variety of pricing. This is the site (not the parts catalog)...
> 
> https://service.teslamotors.com/
> 
> Ok wow, Just checked the site. It now seems like states other than MA are now accepted. Didn't go through the whole purchase process to see if it works for non-MA though, but it does seem to let you pick other states now along the way to checkout. Not a good time for me to do an 1-hour subscription and get the most out of it, but perhaps others may give it a go and share pertinent info on CAN hookup.


"Complete the Certification Program to become an official Tesla Approved Body Shop and *receive complimentary Account access*" - Anyone know of a friend that works at a Tesla approved body shop?

I want this info also so I can put in a video feed switch for the rear camera. This way I can watch a movie or catch up on TV episodes while waiting for a charge on travels. The other option is to find the harness for the entire screen...(but only when parked).


----------



## fast_like_electric

b0n3z said:


> "Complete the Certification Program to become an official Tesla Approved Body Shop and *receive complimentary Account access*" - Anyone know of a friend that works at a Tesla approved body shop?
> 
> I want this info also so I can put in a video feed switch for the rear camera. This way I can watch a movie or catch up on TV episodes while waiting for a charge on travels. The other option is to find the harness for the entire screen...(but only when parked).


I couldn't resist - pulled the trigger. Full wiring diagrams with pin numbers detailed, connector and pin part numbers, as well as connector locations on the harnessing. I didn't check anything but the wiring info, but the PDF wiring diagram alone is worth the $32 for a 1 hour subscription. Three files, based on the build vintage of the car.


----------



## b0n3z

Confirmed. 6098-5629 blue female parts work!


----------



## JWardell

fast_like_electric said:


> I couldn't resist - pulled the trigger. Full wiring diagrams with pin numbers detailed, connector and pin part numbers, as well as connector locations on the harnessing. I didn't check anything but the wiring info, but the PDF wiring diagram alone is worth the $32 for a 1 hour subscription. Three files, based on the build vintage of the car.


Does it label the signals on each pin?
Does it make you agree to legal agreements? I'm reluctant to agree to something that could bite me later


----------



## fast_like_electric

JWardell said:


> Does it label the signals on each pin?


Yes, basically. You need to search for all instances of that particular connector number in the PDF, then you'd have a full pinout for that connector. The connector part info is detailed elsewhere on the web site - that has part numbers and wire gauge/color but not signal names.


----------



## pavankp

JWardell said:


> I have some excel questions for those who know what they are doing:
> -Is there anyway to speed up chart rendering? With all these data points, it's unresponsive for minutes with every single change, resize, retitle, right-click... I wish I could tell it to wait till I edited everything then gave it the go ahead


I don't know if you are still dealing with Excel, I am reading the thread from the start and got this far. You can do what you are looking for by changing the Formula Calculation Options to Manual. Depending on which version of Excel you use, look for the Formulas tab/menu option, and then Calculation Options within.

This is great work, thanks for doing it and sharing it.


----------



## JWardell

Pavan Pamidimarri said:


> I don't know if you are still dealing with Excel, I am reading the thread from the start and got this far. You can do what you are looking for by changing the Formula Calculation Options to Manual. Depending on which version of Excel you use, look for the Formulas tab/menu option, and then Calculation Options within.
> 
> This is great work, thanks for doing it and sharing it.


Thankfully I have several better tools now to look at data but this is good to know. 
Unfortunately it doesn't seem to work with charts, I just tried opening one of the old ones and switching to manual, but it still chugs for five minutes every time I change anything in the chart. Excel just stinks at handling data I guess.


----------



## rhuber

fast_like_electric said:


> I couldn't resist - pulled the trigger. Full wiring diagrams with pin numbers detailed, connector and pin part numbers, as well as connector locations on the harnessing. I didn't check anything but the wiring info, but the PDF wiring diagram alone is worth the $32 for a 1 hour subscription. Three files, based on the build vintage of the car.


Are you saying they are in normal pdf form and you can download them once and refer to them indefinitely? If so I'll absolutely subscribe for the hour.


----------



## JWardell

I am now MUCH closer to my original concept:


__ https://twitter.com/i/web/status/1094017845124648961


----------



## fast_like_electric

rhuber said:


> Are you saying they are in normal pdf form and you can download them once and refer to them indefinitely? If so I'll absolutely subscribe for the hour.


Correct - the wiring diagrams are standard PDF's. One each for SOP to mid-2018 vehicles, late 2018, and 2019. The connector location and part info are not PDFs - those are HTML. But the wiring diagrams alone are worth the price of admission for standard PDFs that are yours forever. If I would have been thinking at the time, I would have also snagged the Model S and X too.


----------



## fast_like_electric

JWardell said:


> I am now MUCH closer to my original concept:
> 
> 
> __ https://twitter.com/i/web/status/1094017845124648961


Great job! Shaping up quite nicely.

My objective is to do something quite similar, but locating that sort of info and typical gauges in front of the driver. Doing it clean is the challenge. On the way there, we pretty much have the majority of the pertinent CAN info, except maybe cruise control speed. Road curvature, vehicle ghosts, and other autopilot info would be icing on the cake. That's going to be hard to decode without inside info - if it is even on the buses. But indications are that they are based on the UI_* frames listed in the Ingineerix video.


----------



## JWardell

fast_like_electric said:


> Great job! Shaping up quite nicely.
> 
> My objective is to do something quite similar, but locating that sort of info and typical gauges in front of the driver. Doing it clean is the challenge. On the way there, we pretty much have the majority of the pertinent CAN info, except maybe cruise control speed. Road curvature, vehicle ghosts, and other autopilot info would be icing on the cake. That's going to be hard to decode without inside info - if it is even on the buses. But indications are that they are based on the UI_* frames listed in the Ingineerix video.


Well this can certainly be placed in front of the driver, maybe even reflect off the windshield, and of course be made smaller and simpler. But I need to make my back to the future version first  I really do want to continue developing this into a real product.


----------



## John

JWardell said:


> Well this can certainly be placed in front of the driver, maybe even reflect off the windshield, and of course be made smaller and simpler. But I need to make my back to the future version first  I really do want to continue developing this into a real product.


If someone gets really ambitious, it would be super-clean to patch in a hardware video overlay...
Just sayin'.


----------



## GDN

John said:


> If someone gets really ambitious, it would be super-clean to patch in a hardware video overlay...
> Just sayin'.


I'm thinking with the brain power these guys have and are bringing together any of them could've had that done for you in 15 minutes and $100.


----------



## JWardell

GDN said:


> I'm thinking with the brain power these guys have and are bringing together any of them could've had that done for you in 15 minutes and $100.


Actually I'm not even sure what he's asking for


----------



## fast_like_electric

John said:


> If someone gets really ambitious, it would be super-clean to patch in a hardware video overlay...
> Just sayin'.


If I follow, are you saying to overlay the extra instrumentation text (or graphics) on top of the existing center screen display contents? If so that is probably possible, but you'd need to dig into the video signalling between the main computer and the center screen. Could also do it over the backup camera feed too if you were ok with it just being in that area of the screen. Some people are already looking at both those for movie display on that screen (while parked of course), but combining with an overlay would be possible too. Challenge would be overcoming the fear of digging into the screen and mucking something up - physically or electrically. But technically quite possible.


----------



## JWardell

fast_like_electric said:


> If I follow, are you saying to overlay the extra instrumentation text (or graphics) on top of the existing center screen display contents? If so that is probably possible, but you'd need to dig into the video signalling between the main computer and the center screen. Could also do it over the backup camera feed too if you were ok with it just being in that area of the screen. Some people are already looking at both those for movie display on that screen (while parked of course), but combining with an overlay would be possible too. Challenge would be overcoming the fear of digging into the screen and mucking something up - physically or electrically. But technically quite possible.


IMO that is NOT easy at all, involves modifying Tesla software, and a big no-no. The cameras are also not simple analog video feeds. Well, maybe you could overlay another clear LCD panel, but really that would not look great at all. 
I thought he meant a video feed into the box in front of the driver. I say, just tape up an iPad


----------



## fast_like_electric

No Tesla software involved - hardware mods. Supplying (or combining) an alternate video feed to the display or camera feed. The alternate video feed would be generated from say a Pi or something that draws up some pretty gauges or text based on the received CAN info. Same concept that has been done for ages on the old nav radios - taking over the screen hardware to display a different video source. Yes, you're right - there's more going on with the video from the backup camera, and also between the computer and LCD - not just an old analog signal.

I'll leave this one to someone else though as I'm more interested in getting us that driver-centric instrument cluster that was denied us on this car. I'm still hopeful Tesla themselves will implement a real gauge 'app' in the center screen - like was done for Energy, etc. One can hope anyway.


----------



## 96s46p

fast_like_electric said:


> No Tesla software involved - hardware mods. Supplying (or combining) an alternate video feed to the display or camera feed. The alternate video feed would be generated from say a Pi or something that draws up some pretty gauges or text based on the received CAN info. Same concept that has been done for ages on the old nav radios - taking over the screen hardware to display a different video source. Yes, you're right - there's more going on with the video from the backup camera, and also between the computer and LCD - not just an old analog signal.
> 
> I'll leave this one to someone else though as I'm more interested in getting us that driver-centric instrument cluster that was denied us on this car. I'm still hopeful Tesla themselves will implement a real gauge 'app' in the center screen - like was done for Energy, etc. One can hope anyway.


I think someone is selling kits for backup cam feeds for model s on tmc or somewhere


----------



## JWardell

fast_like_electric said:


> No Tesla software involved - hardware mods. Supplying (or combining) an alternate video feed to the display or camera feed. The alternate video feed would be generated from say a Pi or something that draws up some pretty gauges or text based on the received CAN info. Same concept that has been done for ages on the old nav radios - taking over the screen hardware to display a different video source. Yes, you're right - there's more going on with the video from the backup camera, and also between the computer and LCD - not just an old analog signal.
> 
> I'll leave this one to someone else though as I'm more interested in getting us that driver-centric instrument cluster that was denied us on this car. I'm still hopeful Tesla themselves will implement a real gauge 'app' in the center screen - like was done for Energy, etc. One can hope anyway.


I see...it depends how data is sent to the display, and if the computer cares if it is responding or not. These days it is typically LVDS but we can probably figure it out from harness documentation or photos of the computer PCB.

Not sure if you are thinking just an A/B video switch so you can watch a movie while parked, or switching to another computer like a Raspberry Pi that is also receiving all the CAN signals, where we could really re-create most of the information on the existing display with whatever design we can dream up. That would be a LOT of work, but totally doable.


----------



## fast_like_electric

96s46p said:


> I think someone is selling kits for backup cam feeds for model s on tmc or somewhere


Perhaps this?
https://teslamotorsclub.com/tmc/threads/hdmi-interface-to-the-touchscreen.121372/


----------



## fast_like_electric

JWardell said:


> I see...it depends how data is sent to the display, and if the computer cares if it is responding or not. These days it is typically LVDS but we can probably figure it out from harness documentation or photos of the computer PCB.
> 
> Not sure if you are thinking just an A/B video switch so you can watch a movie while parked, or switching to another computer like a Raspberry Pi that is also receiving all the CAN signals, where we could really re-create most of the information on the existing display with whatever design we can dream up. That would be a LOT of work, but totally doable.


If the objective is video substitution (or overlay) on the main screen, there are four points that could be used...

1) Backup camera digital video serial feed
2) Digital video serial link between auto-pilot ECU to main computer
3) Digital video/data link between main computer and display interface board
4) Raw digital panel input between display interface board and LCD

Pros and cons with each. Option 1 probably easiest and most accessible, but likely only useful when used for the 'movies in park' sort of application. This due to the usage of the rear camera now for AP and blind spot detection - different or overlayed video will foul up that function when driving. Option 3 is difficult because the signalling is two way - video to the display, and touch to the main computer - all over the same coax, not a generic standard.

Option 2 or 4 likely the best, depending if you want to take over the whole screen area or just the back-up camera display area. But you'd be digging into the computer and/or display - not something for the faint of heart.


----------



## Feathermerchant

JWardell - I sent you some interesting information. For the rest of y'all watch this video. It has a lot of other stuff in it but we are not alone.





Spoiler - They are developing a pretty easy way to monitor the bus and interface with a USB.


----------



## Bokonon

Feathermerchant said:


> JWardell - I sent you some interesting information. For the rest of y'all watch this video. It has a lot of other stuff in it but we are not alone.
> Spoiler - They are developing a pretty easy way to monitor the bus and interface with a USB.


Thanks for sharing this... it's certainly an interesting project with some familiar-sounding goals!

Note to viewers: anyone who wants the TL;DW version, the segment you want is 27:15 - 30:25. (Continue watching through about 41 minutes for additional detail, though nothing groundbreaking for anyone following this thread.)


----------



## JWardell

Feathermerchant said:


> JWardell - I sent you some interesting information. For the rest of y'all watch this video. It has a lot of other stuff in it but we are not alone.
> 
> 
> 
> 
> 
> Spoiler - They are developing a pretty easy way to monitor the bus and interface with a USB.


Nice, I will see if I can get his attention as he would also be another great resource here. 
He's using an ESP32 WiFi module with Arduino to dump CAN frames to a computer over wifi, great if you have your own custom app running on the other end (same for a phone app)


----------



## amund7

Test build of Scan My Tesla for model 3. Does not show much in the display, but should be great for data capture! If anyone can make this work that would at least be a proof of concept.
It needs to be wired up with an ELM327 or STN1110 compatible OBD2 adapter, best is OBDLink mx.

If it goes wrong, please let me know what errors you get, this is made blindfolded without any Model 3 in my country this far.


----------



## JWardell

amund7 said:


> Test build of Scan My Tesla for model 3. Does not show much in the display, but should be great for data capture! If anyone can make this work that would at least be a proof of concept.
> It needs to be wired up with an ELM327 or STN1110 compatible OBD2 adapter, best is OBDLink mx.
> 
> If it goes wrong, please let me know what errors you get, this is made blindfolded without any Model 3 in my country this far.


I can try it on an older android phone I have, is this all I need, or can you recommend a cheap adapter that will work?


----------



## GDN

JWardell said:


> I can try it on an older android phone I have, is this all I need, or can you recommend a cheap adapter that will work?


@JWardell If you confirm that product in bluetooth for Android is what you want I'll gladly ship you mine for free. I have this product and used to have it plugged in to the 3.5 L Ecoboot pickup. The 2014 version of the pickup didn't have a boost gauge. This was a simple product that would let me tap in and see boost and other things on a cheap tablet. I had taken it out of the pickup when I took it in for service (and the pickup was subsequently stolen) so I have no use for it and would gladly donate it for your cause and research. If you want it PM me your address and I'll send it.


----------



## JWardell

GDN said:


> @JWardell If you confirm that product in bluetooth for Android is what you want I'll gladly ship you mine for free. I have this product and used to have it plugged in to the 3.5 L Ecoboot pickup. The 2014 version of the pickup didn't have a boost gauge. This was a simple product that would let me tap in and see boost and other things on a cheap tablet. I had taken it out of the pickup when I took it in for service (and the pickup was subsequently stolen) so I have no use for it and would gladly donate it for your cause and research. If you want it PM me your address and I'll send it.


My question is if these are capable of 500kbps CAN, or just 125 or 250 for J1939.
I also have a cheap Etekcity Wifi one that I used for a few minutes with a few iOS apps. Of course bluetooth is much nicer so don't affect your network connection, but at least last I looked iOS didn't support the bluetooth adapters


----------



## GDN

Yeah - most of the device manufactures don't support iOS because of the Apple closed infrastructure. To work with iOS Apple forces the mfrs to go through their certification which drives the prices way up, so most bluetooth just support Android.


----------



## John

fast_like_electric said:


> If the objective is video substitution (or overlay) on the main screen, there are four points that could be used...
> 
> 1) Backup camera digital video serial feed
> 2) Digital video serial link between auto-pilot ECU to main computer
> 3) Digital video/data link between main computer and display interface board
> 4) Raw digital panel input between display interface board and LCD


The overlay suggestion was just to avoid the need for display hardware, and to keep the car looking stock.
Yes, my original thought was #4-add an overlay generator between the MCU and the screen using just connectors at the MCU (no wire splicing or anything).
Make the info subtle enough (e.g. title bar with other status indicators), and you can just leave it on. But there is usually plenty of space in the driving pane to show extra stuff, if you don't mind some clutter. You'll need to choose colors that work for both day and night mode.
The idea to overlay the backup camera is cool, so that you can hide it when you want. Though overlays with pass-through can just be turned off.


----------



## amund7

JWardell said:


> My question is if these are capable of 500kbps CAN, or just 125 or 250 for J1939.


If Model S powertrain bus is 500kbps, any OBD2 adapter should connect, but probably it will miss a lot of data. The OBDLink MX/LX are fast, but at least the MX has a bad habit of crashing after a while with lots of data.
If model 3 has more traffic than the S, we might need to look at other hardware, unless we find something better than OBDLink MX. I believe they have a firmware bug, tried to contact them about it, but there is no response from them.
OTOH, when you filter out some of the traffic, an OBDLink can run forever. In that respect it is very much usable for my app, if the goal is to display a few gauges on the screen, and not data mining.


----------



## JWardell

Squashed some bugs and added a line with coolant temps and flow rates. 
I really love driving with this 
I do wish we could get some confidence on the torque scaling though.


----------



## Collin80

JWardell said:


> Nice, I will see if I can get his attention as he would also be another great resource here.
> He's using an ESP32 WiFi module with Arduino to dump CAN frames to a computer over wifi, great if you have your own custom app running on the other end (same for a phone app)


Well, it got my attention. I just read your entire 23 page thread here. Whew, that's a long read! I see that you already kind of found out about my work - I wrote SavvyCAN and created the GVRET file format. I also see that my Vector .ASC loader seems to crash when loading your captures. I'm fixing that at the moment so I can play with all the captures that were posted. Anyway, just wanted to pop in and say hi. It seems like everyone here has gotten a lot of progress! Awesome stuff!


----------



## JWardell

Collin80 said:


> Well, it got my attention. I just read your entire 23 page thread here. Whew, that's a long read! I see that you already kind of found out about my work - I wrote SavvyCAN and created the GVRET file format. I also see that my Vector .ASC loader seems to crash when loading your captures. I'm fixing that at the moment so I can play with all the captures that were posted. Anyway, just wanted to pop in and say hi. It seems like everyone here has gotten a lot of progress! Awesome stuff!


Awesome, and welcome!


----------



## Jack Rickard

And you have mine as well. We'll support your efforts where we can.

Jack Rickard
EVTV


----------



## garsh

Is it wrong that I "squeeeed" like a fan girl when I saw that @Jack Rickard joined & replied?


----------



## Feathermerchant

All Right! Looks like we have the A team on it.


----------



## pavankp

JWardell said:


> Well this can certainly be placed in front of the driver, maybe even reflect off the windshield, and of course be made smaller and simpler. But I need to make my back to the future version first  I really do want to continue developing this into a real product.


I have a reflective HUD in my 3 that I built using GPS and Raspberry Pi. It shows speed and heading (from GPS) so it has about 2 seconds of latency compared to the speed reported on the screen. It is really simple, but happy to share it. I would love to have information from the CAN bus to show on that display, instead of data from the little GPS antenna that I stuck to the back of the center screen.


----------



## bearbu

Great thread! Please keep going crack the CAN bus. 
I am developing a video in product for Model 3 and requires CAN signal from steering wheel.


----------



## JWardell

Pavan Pamidimarri said:


> I have a reflective HUD in my 3 that I built using GPS and Raspberry Pi. It shows speed and heading (from GPS) so it has about 2 seconds of latency compared to the speed reported on the screen. It is really simple, but happy to share it. I would love to have information from the CAN bus to show on that display, instead of data from the little GPS antenna that I stuck to the back of the center screen.


I have one as well that I bought on Amazon for $30 a year ago with the intention of putting in the Tesla, but never did because I find speed to be perfectly visible on the display. 
It's all the other fun data I want to see 



bearbu said:


> Great thread! Please keep going crack the CAN bus.
> I am developing a video in product for Model 3 and requires CAN signal from steering wheel.


What info do you need from the steering? I wasn't concentrating on it but I can. 
We were just discussing methods of displaying video on the display in the last few pages, curious what you are working on


----------



## JWardell

b0n3z said:


> Confirmed. 6098-5629 blue female parts work!
> 
> View attachment 21636
> View attachment 21637


I received my parts yesterday and spent a good chunk of the last two days wrestling with building this connector. What a nightmare, failed crimps, most wires won't stuff all the way, losing pins in the connector, you name it. Have you had better luck?
I really just want to find someone who will make 50 or 100 of these, I'm sure we can find many others would be interested in them.


----------



## fast_like_electric

JWardell said:


> I received my parts yesterday and spent a good chunk of the last two days wrestling with building this connector. What a nightmare, failed crimps, most wires won't stuff all the way, losing pins in the connector, you name it. Have you had better luck?
> I really just want to find someone who will make 50 or 100 of these, I'm sure we can find many others would be interested in them.


Before going too crazy over that connector and location (though it is a convenient one), it should be pointed out that only the Vehicle bus is available there. Has a lot of good messaging, but not all. If the Chassis bus is desired (and its unique messages), that is needed to be tapped elsewhere.

The only places that all 3 main buses are available (Vehicle/Chassis/Party) is at the left and right body controllers, the main controller, and the auto-pilot ECU. People refer to the main computer as the MCU, ICE, Gateway - the module that drives the screen.

On the body and autopilot ECU's, the buses span connectors. The MCU has all three buses on one 12 pin connector, Sumitomo 6098-5713. Don't know how hard it is to physically get to that module.


----------



## JWardell

fast_like_electric said:


> Before going too crazy over that connector and location (though it is a convenient one), it should be pointed out that only the Vehicle bus is available there. Has a lot of good messaging, but not all. If the Chassis bus is desired (and its unique messages), that is needed to be tapped elsewhere.
> 
> The only places that all 3 main buses are available (Vehicle/Chassis/Party) is at the left and right body controllers, the main controller, and the auto-pilot ECU. People refer to the main computer as the MCU, ICE, Gateway - the module that drives the screen.
> 
> On the body and autopilot ECU's, the buses span connectors. The MCU has all three buses on one 12 pin connector, Sumitomo 6098-5713. Don't know how hard it is to physically get to that module.


The chassis bus doesn't have all the signals I'm interested in, so this is fine for my geek display purposes. Obviously an easily accessible location with multiple busses is preferred but it's extremely difficult to access most of the connections on the VCleft/right controllers. 
Still, it would be best if we could identify all the CAN busses and connections, and make the best decision. For example it appears the MPP funbox is using [much more friendly] Deutsch connectors so they are accessing elsewhere, outside the vehicle, probably under the frunk. What I still don't understand is how they are injecting data, and more likely connecting and modifying data from a node. In fact they might not connect to CAN at all but just generate an error signal from a ABS sensor before it plugs into VCfront for example.


----------



## fast_like_electric

JWardell said:


> The chassis bus doesn't have all the signals I'm interested in, so this is fine for my geek display purposes. Obviously an easily accessible location with multiple busses is preferred but it's extremely difficult to access most of the connections on the VCleft/right controllers.
> Still, it would be best if we could identify all the CAN busses and connections, and make the best decision...


There are only a handful of intermediate CAN connector locations like the center console connection point. Just a few other points, when required to bridge from harness to harness. The body modules are basically the primary junctions, with just a few splices of the buses in between. The mentioned MCU is the lowest pin-count connection for any of the buses, and they're all there as a bonus. The Tesla wiring diagram is your friend if you need more detailed info.


----------



## bearbu

JWardell said:


> I received my parts yesterday and spent a good chunk of the last two days wrestling with building this connector. What a nightmare, failed crimps, most wires won't stuff all the way, losing pins in the connector, you name it. Have you had better luck?
> I really just want to find someone who will make 50 or 100 of these, I'm sure we can find many others would be interested in them.


I think I can help on this. It's not difficult to get a manufacturer to custom make it (here in Shenzhen, China)


----------



## JWardell

I managed to finish the connector, seemed to work when I plugged it in, I had CAN data, but then I couldn't shift out of park (DOH!) so clearly one of the VSEC busses is unhappy. No error on screen interestingly.



bearbu said:


> I think I can help on this. It's not difficult to get a manufacturer to custom make it (here in Shenzhen, China)


I was thinking of talking to a few CMs around here but that would obviously help reduce costs significantly. If you know a few there that could do it, I would love to get quotes for 25/50/100/250


----------



## bearbu

JWardell said:


> I have one as well that I bought on Amazon for $30 a year ago with the intention of putting in the Tesla, but never did because I find speed to be perfectly visible on the display.
> It's all the other fun data I want to see
> 
> What info do you need from the steering? I wasn't concentrating on it but I can.
> We were just discussing methods of displaying video on the display in the last few pages, curious what you are working on


I am the one selling the HDMI Interface Box for Model S/X

Will make one for Model 3 soon


----------



## JWardell

The connector and wiring are all working now. It might be time to make a proper video instead of these little teasers.


----------



## b0n3z

JWardell said:


> The connector and wiring are all working now. It might be time to make a proper video instead of these little teasers.


Cannot wait!!!


----------



## amund7

New version of Canbus Analyzer

https://github.com/amund7/CANBUS-Analyzer/releases

Now supports (from DBC files):
- Units
- Multiplexed messages (currently with some limitations, the MUX message needs to be defined before the 'sub-messages', we will try to fix this later)

Command-line switches for loading DBC and log file directly at launch:
/dbc <filename>
/log <filename>

Thanks to Brian-man for doing most of these.

Enums (text values for special values) are coming very soon, already working but needs a bit more testing.


----------



## Mike

Simple sounding question from a quiet observer of this thread:

Will (at some point) one be able to monitor energy consumption between propulsion, HVAC, battery conditioning and chassis/body electric?

Once I saw that information readily displayed on Bolt and Kona (% and kW being used by each of the four categories) I have wished we could see that.

Signed,

Guy from a steam driven, vacuum tubed world who knows nothing of the magic going on in this thread.

PS: thanks for all the exploration and discovery going on here.


----------



## fast_like_electric

Mike said:


> Simple sounding question from a quiet observer of this thread:
> 
> Will (at some point) one be able to monitor energy consumption between propulsion, HVAC, battery conditioning and chassis/body electric?
> 
> Once I saw that information readily displayed on Bolt and Kona (% and kW being used by each of the four categories) I have wished we could see that.
> 
> Signed,
> 
> Guy from a steam driven, vacuum tubed world who knows nothing of the magic going on in this thread.
> 
> PS: thanks for all the exploration and discovery going on here.


That was one of my objectives with this as well, in the absence of any real gauges on the Tesla main screen. With the CAN information decoded at this point, you can get instantaneous power consumption from...

- HV Battery
- Drive system
- HVAC system
- 12V system

Some of this is in amps so you need to do some math with the appropriate voltage to get power for all of the above. The Drive/HVAC/12V consumption should add up to the battery number if everything was calculated correctly. There are some power dissipation fields which also need to be considered in the calculations too.

You mention energy consumption, which is power usage over time. You'd need to integrate the power measurements over a time interval to get that. There are no native CAN messages with that information - except for the battery.

Options for display of info range from additional displays (like JWardell has prototyped), camera/screen video takeover or overlay, Tesla web browser page, phone/tablet/pc app, etc. All require some CAN interface to the vehicle bus to get the info, and pros & cons with each method (clean look, data update rate, latency, etc). Lots of people working on various aspects of this, but what you ask for is definitely possible.


----------



## JWardell

Mike said:


> Simple sounding question from a quiet observer of this thread:
> 
> Will (at some point) one be able to monitor energy consumption between propulsion, HVAC, battery conditioning and chassis/body electric?
> 
> Once I saw that information readily displayed on Bolt and Kona (% and kW being used by each of the four categories) I have wished we could see that.
> 
> Signed,
> 
> Guy from a steam driven, vacuum tubed world who knows nothing of the magic going on in this thread.
> 
> PS: thanks for all the exploration and discovery going on here.


We have all that information, and thank you for sharing ideas, because I would love to know what other folks would like to see in some sort of display. The car even keeps track of thermal losses of each device as well.
I guess the first step (and my next) is to make some sort of plug & play CAN module that can transmit via bluetooth etc to a display, but that display could be a geek one like mine, a HUD on the dash, or like @fast_like_electric wants, something that integrates into the stock display's video.


----------



## JWardell




----------



## Defjukie

JWardell said:


>


This is the coolest thing I've seen in a loooong time.


----------



## Mike

fast_like_electric said:


> That was one of my objectives with this as well, in the absence of any real gauges on the Tesla main screen. With the CAN information decoded at this point, you can get instantaneous power consumption from...
> 
> - HV Battery
> - Drive system
> - HVAC system
> - 12V system
> 
> Some of this is in amps so you need to do some math with the appropriate voltage to get power for all of the above. The Drive/HVAC/12V consumption should add up to the battery number if everything was calculated correctly. There are some power dissipation fields which also need to be considered in the calculations too.
> 
> You mention energy consumption, which is power usage over time. You'd need to integrate the power measurements over a time interval to get that. There are no native CAN messages with that information - except for the battery.
> 
> Options for display of info range from additional displays (like JWardell has prototyped), camera/screen video takeover or overlay, Tesla web browser page, phone/tablet/pc app, etc. All require some CAN interface to the vehicle bus to get the info, and pros & cons with each method (clean look, data update rate, latency, etc). Lots of people working on various aspects of this, but what you ask for is definitely possible.


Thanks for the detailed reply.

I'd be in the clean look camp, and your mention of a tablet may be my way to go.......when that time comes.


----------



## Mike

JWardell said:


> We have all that information, and thank you for sharing ideas, because I would love to know what other folks would like to see in some sort of display. The car even keeps track of thermal losses of each device as well.
> I guess the first step (and my next) is to make some sort of plug & play CAN module that can transmit via bluetooth etc to a display, but that display could be a geek one like mine, a HUD on the dash, or like @fast_like_electric wants, something that integrates into the stock display's video.


This is all just too cool.

From my novice view of these things, I like the sound of a way to integrate it into the existing display video.

Having propulsion, HVAC, battery conditioning and chassis electronics all together, showing each it's portion of the total energy being used for a given time period (say update every 10 seconds) would let one do different driving and HVAC techniques back to back with the same climate and battery states........I. e. how does slowing down 5% compare to turning HVAC (heat) down 5c for effect on Wh/km, things like that.

After numerous tests, one could promulgate a standard operating procedure for cold wx ops and leg distance.......sorry, I'm dreaming here.....


----------



## amund7

Got this one today.... now all I need is a Model 3


----------



## JWardell

Mike said:


> This is all just too cool.
> 
> From my novice view of these things, I like the sound of a way to integrate it into the existing display video.
> 
> Having propulsion, HVAC, battery conditioning and chassis electronics all together, showing each it's portion of the total energy being used for a given time period (say update every 10 seconds) would let one do different driving and HVAC techniques back to back with the same climate and battery states........I. e. how does slowing down 5% compare to turning HVAC (heat) down 5c for effect on Wh/km, things like that.
> 
> After numerous tests, one could promulgate a standard operating procedure for cold wx ops and leg distance.......sorry, I'm dreaming here.....


You don't need a display to tell you to drive around at 40mph with the heat off to maximize range


----------



## Feathermerchant

JWardell said:


> You don't need a display to tell you to drive around at 40mph with the heat off to maximize range


Yes we know but it would be so much more fun.


----------



## 96s46p

Jack Rickard said:


> And you have mine as well. We'll support your efforts where we can.
> 
> Jack Rickard
> EVTV


You guys are talking to the BMS or Batman/Robin boards directly outside the car, right? Could you post what you know about that?


----------



## JWardell

96s46p said:


> You guys are talking to the BMS or Batman/Robin boards directly outside the car, right? Could you post what you know about that?


Oh! Should at least be able to tell what messages come from what device


----------



## JWardell

amund7 said:


> New version of Canbus Analyzer
> 
> https://github.com/amund7/CANBUS-Analyzer/releases
> 
> Now supports (from DBC files):
> - Units
> - Multiplexed messages (currently with some limitations, the MUX message needs to be defined before the 'sub-messages', we will try to fix this later)
> 
> Command-line switches for loading DBC and log file directly at launch:
> /dbc <filename>
> /log <filename>
> 
> Thanks to Brian-man for doing most of these.
> 
> Enums (text values for special values) are coming very soon, already working but needs a bit more testing.


I just realized your software has now replaced a $20k specialized application because it is so quick and easy to explore and verify data as I add it to DBC files. (!!)
Well, I still need Vector to compare data across different messages or drill in to short time periods or view data live, but still, this is now not only a legitimate CAN tool but now preferable to the big boys because of its simplicity.
Nice!


----------



## 0x6d33

Hi all! 

Over the last few days I been using a Raspberry Pi to read the CAN bus under the center console. My main obstacle right now is properly turning off the Pi before the car goes to sleep. I was wondering if there is some sort of message that signifies that the cars is about to go to sleep. 

My end goal is to create some sort of display behind the steering wheel.


----------



## amund7

New version of Canbus Analyzer again 

https://github.com/amund7/CANBUS-Analyzer/releases

Now supports (from DBC files):
- Enums (text values for special values)

Also from last version:
- Units
- Multiplexed messages (currently with some limitations, the MUX message needs to be defined before the 'sub-messages', we will try to fix this later)

Command-line switches for loading DBC and log file directly at launch:
/dbc <filename>
/log <filename>


----------



## Kayt183

Hey, guys.
I'm in the business of repairing Tesla cars in an unofficial service.
now in repair there is a Tesla model 3 with a faulty battery. I took the top cover off today. The voltage on the battery is only 80V. I'll try to connect to the BMS tomorrow. I would like to see the voltage of each cell, as in Tesla model S.
I'm do not know laws of your country, but I can post schematics and connector reference if you need and if it's legal.


----------



## Kayt183

*JWardell, are you sure what ID 0x132 is Battery Voltage V u16 SB 0 scale 0.01? It's data changing to quickly. Also BMS does not send any data with ID 0x126.*


----------



## fast_like_electric

Kayt183 said:


> ... are you sure what ID 0x132 is Battery Voltage V u16 SB 0 scale 0.01? It's data changing to quickly. Also BMS does not send any data with ID 0x126.


The CAN decode detailed for 0x132 is correct. If you have a defective battery pack or BMS, I would imagine you will see a lot of odd things.

ID 0x126 is from the Drive Inverter.



Kayt183 said:


> I would like to see the voltage of each cell, as in Tesla model S.


Individual cell group voltages are on ID 0x401.


----------



## Kayt183

*fast_like_electric, *Thank you, very much.
Filtered data by 0x401 and have a sad view. Cells voltage changes each measurement.
Here are photos of the connection with BMS and Here are Can data and BMS IDs. 
Today we will remove the battery and watch what happened to it


----------



## fast_like_electric

Kayt183 said:


> *fast_like_electric, *Thank you, very much.
> Filtered data by 0x401 and have a sad view. Cells voltage changes each measurement.
> Here are photos of the connection with BMS and Here are Can data and BMS IDs.
> Today we will remove the battery and watch what happened to it


Glad the info was helpful. Please keep us posted on your findings. Monitoring the battery health and behavior long term is something many of us are interested in. The fact you have a broken one this early in its life is rather unique, and something curious to follow.


----------



## fast_like_electric

Kayt183 said:


> *fast_like_electric, *Thank you, very much.
> Filtered data by 0x401 and have a sad view. Cells voltage changes each measurement.
> Here are photos of the connection with BMS and Here are Can data and BMS IDs.
> Today we will remove the battery and watch what happened to it


Also, looking at your 0x401 cell group voltage data (thanks for posting), your battery pack is definitely in rough shape (electrically). Most cell groups sitting at 0.8V to 1.0V. Can clearly see how this adds up to the 80V total you mentioned.

That said, nothing jumps out as bad - they are just very low and currently unbalanced. You don't want Li-Ion cells really ever sitting that low, so if you have the ability to charge, you will want to do that as soon as you feel it is safe to do so.

The BMS/PCS may not want to charge a battery so fully discharged. You might need to get creative to bring it up to 250V manually before letting the car charge it. Doing so might get you back in business. But it remains to be seen if the battery capacity has been permanently compromised by the ultra-low voltage.

Also, if you are removing the battery, it is known there are 4 rows of cell groups in the pack: two rows of 25 on the inside, and two rows of 23 on the outside. That totals 96 groups, which is what ID 0x401 shows (3 groups per message index, over indexes 0x00 to 0x1F). Each cell group has 46 2170 cells in parallel, for a total of 4416 batteries when the groups connected in series. Getting a mapping of the physical position of the cell groups in relation to the CAN indexes would be handy.

It is also believed that 0x712 is the raw battery temperature info, but it is unclear where these 16 temperature points are in relation to the pack.


----------



## JWardell

I've been traveling this weekend (lots of good NOA and supercharging testing) so I'm a bit behind on messages and things, I should get caught up tomorrow



Kayt183 said:


> *fast_like_electric, *Thank you, very much.
> Filtered data by 0x401 and have a sad view. Cells voltage changes each measurement.
> Here are photos of the connection with BMS and Here are Can data and BMS IDs.
> Today we will remove the battery and watch what happened to it


The pack voltage sounds tragically low and I'm worried how it could get that low to begin with...things should have turned off all loads ~300V
This is an extreme generalization and more applicable to power tools batteries, but often the voltage will get too low that the charger will refuse to charge it. If you hook a power supply up to slowly raise the voltage (do you have a 400V bench supply?) you might be able to get it to the level where the real charger can take over. But that's assuming everything is hooked up to take a straight charge voltage...I don't know the details of the design.
I won't ask how a Model 3 managed to get to Russia, unless this is yet another chapter of You You's roadtrip car that died in Greece.


----------



## rhuber

Just catching up after not having much free time to watch the goings-on here. I really like the BTTF style display @JWardell!

I'm going for a "clean" look as well, but mostly because I want to avoid dismantling anything when the car goes in to the shop. I'm prototyping a display that uses the (terrible) web browser built in to the car. Using a Pi as the server, I'm planning to make an easy-to-reproduce way to connect to can and display data us nerds enjoy. Power is one thing I'm currently focused on. I want to avoid destroying my car's 12v battery, so I'm about to try using a MOSFET as the gate to recharging a 3rd party battery bank that will live somewhere in the car (assuming heat/cold can be handled well). The can data allows me to easily decide when it makes the most sense to charge the battery bank.

Lots to do here, but I'm hoping to turn this into a single PCB design that can be ordered from OSH or similar....

Thanks again for all of the contributions from everyone here! Couldn't have gotten anywhere near this far without your shoulders.


----------



## Kayt183

fast_like_electric said:


> Glad the info was helpful. Please keep us posted on your findings. Monitoring the battery health and behavior long term is something many of us are interested in. The fact you have a broken one this early in its life is rather unique, and something curious to follow.


The car only has 1,000 miles. but it's half a year ago had an accident and since then never charged. Most likely at the time of the accident the battery was discharged. And while the car was being sold and sailed from America to Russia, the battery went into self-discharge. Today, the batteries are checked for a fully discharged elements and charged with a low current to about 310 volts and now it's balanced. I was confused with 00 00 at 5 an 6 bytes at the IDs 1A and 1E. Tomorrow I hope to install the battery in it's place and run the built-in charger. Also trying to find temperature sensors in the battery and map data from the can bus to the physical location of batteries. This is my last working day on watch, then I'll be back in 2 weeks, and will share interesting findings : -).


----------



## Collin80

fast_like_electric said:


> Also, if you are removing the battery, it is known there are 4 rows of cell groups in the pack: two rows of 25 on the inside, and two rows of 23 on the outside. That totals 96 groups, which is what ID 0x401 shows (3 groups per message index, over indexes 0x00 to 0x1F). Each cell group has 46 2170 cells in parallel, for a total of 4416 batteries when the groups connected in series. Getting a mapping of the physical position of the cell groups in relation to the CAN indexes would be handy.
> 
> It is also believed that 0x712 is the raw battery temperature info, but it is unclear where these 16 temperature points are in relation to the pack.


I have the BMS master board and a cell module to test with. Good news for people testing these things outside of a car - the BMS master talks CAN immediately when you power it. The 0x401 and 0x712 messages both emanate from the BMS just like you'd think they would. It does appear that 0x712 encodes 16 temperatures. as hundredths of a degree centigrade. I tested in a room set to an air temperature of 54F which would be about 12.22C or 1222 as a reported value. The values actually reported were around 11C to 8.6C. But, the module is on a skid on a concrete floor half a building away from the heaters so I would expect the temperature to report a bit under the 54F setpoint. 47F isn't so bad considering it's a cold floor. So, I think you have a pretty good bet that 0x712 encodes three temperatures each except for the 6th one that has one temperature.


----------



## fast_like_electric

Collin80 said:


> I have the BMS master board and a cell module to test with. Good news for people testing these things outside of a car - the BMS master talks CAN immediately when you power it. The 0x401 and 0x712 messages both emanate from the BMS just like you'd think they would. It does appear that 0x712 encodes 16 temperatures. as hundredths of a degree centigrade. I tested in a room set to an air temperature of 54F which would be about 12.22C or 1222 as a reported value. The values actually reported were around 11C to 8.6C. But, the module is on a skid on a concrete floor half a building away from the heaters so I would expect the temperature to report a bit under the 54F setpoint. 47F isn't so bad considering it's a cold floor. So, I think you have a pretty good bet that 0x712 encodes three temperatures each except for the 6th one that has one temperature.


Correct. Getting a physical map of the pack which shows where the 96 cell groups are and 16 temperatures are vs. the CAN bytes would be useful for data collection and future troubleshooting.


----------



## fast_like_electric

Kayt183 said:


> I was confused with 00 00 at 5 an 6 bytes at the IDs 1A and 1E.


Yes, '00 00' at those cell locations would not be normal. Did that go away when you manually charged the pack up a bit?



Kayt183 said:


> The car only has 1,000 miles. but it's half a year ago had an accident and since then never charged. ... Tomorrow I hope to install the battery in it's place and run the built-in charger.


If you have no luck when you reconnect to the car, you may want to check the pyro fuse in the penthouse. The car will blow this if the accident was severe enough, and also if hv isolation is compromised.


----------



## 96s46p

Collin80 said:


> I have the BMS master board and a cell module to test with. Good news for people testing these things outside of a car - the BMS master talks CAN immediately when you power it. The 0x401 and 0x712 messages both emanate from the BMS just like you'd think they would. It does appear that 0x712 encodes 16 temperatures. as hundredths of a degree centigrade. I tested in a room set to an air temperature of 54F which would be about 12.22C or 1222 as a reported value. The values actually reported were around 11C to 8.6C. But, the module is on a skid on a concrete floor half a building away from the heaters so I would expect the temperature to report a bit under the 54F setpoint. 47F isn't so bad considering it's a cold floor. So, I think you have a pretty good bet that 0x712 encodes three temperatures each except for the 6th one that has one temperature.


Please post a list of all the messages it sends


----------



## Collin80

I was connected to the chargeport bus and these messages are sent:

112
12a
14a
152
172
20a
22a
232
24a
26a
272
2b2
392
3aa
3d2
3f2
401
432
682
712
74a
76a
78a
792
7aa
7f2

I can't connect to the powertrain bus properly at the BMS. It is sending pulses that are long and, while differential, do not seem to conform to proper CAN. They're certainly not 500k CAN like the bus should be running at. Seeing these pulses makes even a Kvaser Leaf Light puke. I wonder if these odd pulses are what was generating the ID 000 messages I see in the published logs? But, the charge port bus is extremely active. It has about 1000 frames per second just from the BMS master. Cell level voltages are reported one message per 10ms so even with the large # of messages you get multiple full updates per second.

You'll notice that some IDs are in common with what you normally see on the main CAN bus. Some are different. Some are the same but seem to have a different # of bytes compared to what you have listed in the spreadsheet. But, 0x401 and 0x712 are formatted just like you're expecting.

I'm noticing that the Model 3 frames output from the BMS conform mostly to a similar scheme I saw on the Model S. That is, certain devices tend to use the same last number for most all their messages. In this case the BMS really likes sending on 0x??2 and 0x??A. Other than 0x401 they all seem to conform to that scheme. So it seems the Tesla engineers are still using that same similar convention. It can help to figure out what a frame is supposed to be by looking at the last digit to see where it is likely to have come from.


----------



## fast_like_electric

JWardell said:


> The pack voltage sounds tragically low and I'm worried how it could get that low to begin with...things should have turned off all loads ~300V


Even when disconnected, there is self discharge of the battery itself, as well as the BMS circuitry load on the cells which is low current but not zero. Over several months sitting, and depending on the SOC at the time, the low pack voltage is to be expected. What is unexpected is if the car really can't cope with this by trickle charging the pack via the BMS itself. As you mention, coercing smart Li-Ion battery packs back into service by rasing the voltage with an external power supply is common recovery mechanism, but hard to believe Model 3 wouldn't have such a recovery via the BMS itself via a much more controlled approach.


----------



## fast_like_electric

Collin80 said:


> I can't connect to the powertrain bus properly at the BMS. It is sending pulses that are long and, while differential, do not seem to conform to proper CAN. They're certainly not 500k CAN like the bus should be running at. Seeing these pulses makes even a Kvaser Leaf Light puke.


Are you sure you are connecting to the Powertrain (aka Vehicle) bus? The bus which goes between the BMS master and the cell group control modules is differential, but not CAN.


----------



## Collin80

Kayt183 said:


> *fast_like_electric, *Thank you, very much.
> Filtered data by 0x401 and have a sad view. Cells voltage changes each measurement.
> Here are photos of the connection with BMS and Here are Can data and BMS IDs.
> Today we will remove the battery and watch what happened to it


Thank you for the captures. I love to collect captures. And, you used CANHacker trace format and SavvyCAN reads that! The only hitch was that you're using a different locale than me and the Russian locale uses commas for decimal separator instead of periods like the US locale. It's a quick find/replace to fix that. It's interesting that you are getting different IDs than I get when I capture from the BMS. It could be that I've got one module installed not all four, or that you've got different firmware. I'm somewhat used to this. Tesla Model S captures seem to vary greatly based on geography and firmware revision.


----------



## JWardell

rhuber said:


> Just catching up after not having much free time to watch the goings-on here. I really like the BTTF style display @JWardell!
> 
> I'm going for a "clean" look as well, but mostly because I want to avoid dismantling anything when the car goes in to the shop. I'm prototyping a display that uses the (terrible) web browser built in to the car. Using a Pi as the server, I'm planning to make an easy-to-reproduce way to connect to can and display data us nerds enjoy. Power is one thing I'm currently focused on. I want to avoid destroying my car's 12v battery, so I'm about to try using a MOSFET as the gate to recharging a 3rd party battery bank that will live somewhere in the car (assuming heat/cold can be handled well). The can data allows me to easily decide when it makes the most sense to charge the battery bank.
> 
> Lots to do here, but I'm hoping to turn this into a single PCB design that can be ordered from OSH or similar....
> 
> Thanks again for all of the contributions from everyone here! Couldn't have gotten anywhere near this far without your shoulders.


No need for all that, really, switched 12v is the blue wire on the same connector that goes to the lighter socket, you can just power from that.
Biggest issue is the car disconnects from wifi every time you drive, so you will have to manually reconnect to the module each time, and the module will have to share internet from its own cell connection in order for the rest of the computer to remain connected.
But yes, the web browser is the a great completely stock way to view info!


----------



## Collin80

fast_like_electric said:


> Are you sure you are connecting to the Powertrain (aka Vehicle) bus? The bus which goes between the BMS master and the cell group control modules is differential, but not CAN.


Well, pretty sure. There are two CAN buses at the master BMS plug. One is labeled CP and the other PT. Unless I got dyslexic I was connected to CP when capturing. Connecting to PT shows just very slow differential pulses. I'm aware that the BMS master to modules comm is differential but not CAN. It's isoSPI. I've tried to connect to that but the modules seem to be really picky and I think Tesla might not have very strictly followed the isoSPI standard. The signals look to require things outside the isoSPI spec in order to generate. It doesn't seem to respond when I try talking directly to the modules. And, I'm pretty sure I'm speaking the proper language. I have isospi hardware, I've also got captures of the SPI traffic from the main CPU on the master board, and I can pretty easily directly read and decode in my head the isospi from an oscilloscope capture. So, I don't think I'm barking up the wrong tree but it refuses to cooperate - it has been extremely annoying. This leads me to believe that the isospi spec has been severely violated by Tesla and maybe that's why they're using custom BMS chips and not LTC6813 chips.


----------



## 96s46p

Collin80 said:


> I was connected to the chargeport bus and these messages are sent:
> 
> 112
> 12a
> 14a
> 152
> 172
> 20a
> 22a
> 232
> 24a
> 26a
> 272
> 2b2
> 392
> 3aa
> 3d2
> 3f2
> 401
> 432
> 682
> 712
> 74a
> 76a
> 78a
> 792
> 7aa
> 7f2
> 
> I can't connect to the powertrain bus properly at the BMS. It is sending pulses that are long and, while differential, do not seem to conform to proper CAN. They're certainly not 500k CAN like the bus should be running at. Seeing these pulses makes even a Kvaser Leaf Light puke. I wonder if these odd pulses are what was generating the ID 000 messages I see in the published logs? But, the charge port bus is extremely active. It has about 1000 frames per second just from the BMS master. Cell level voltages are reported one message per 10ms so even with the large # of messages you get multiple full updates per second.
> 
> You'll notice that some IDs are in common with what you normally see on the main CAN bus. Some are different. Some are the same but seem to have a different # of bytes compared to what you have listed in the spreadsheet. But, 0x401 and 0x712 are formatted just like you're expecting.
> 
> I'm noticing that the Model 3 frames output from the BMS conform mostly to a similar scheme I saw on the Model S. That is, certain devices tend to use the same last number for most all their messages. In this case the BMS really likes sending on 0x??2 and 0x??A. Other than 0x401 they all seem to conform to that scheme. So it seems the Tesla engineers are still using that same similar convention. It can help to figure out what a frame is supposed to be by looking at the last digit to see where it is likely to have come from.


Are you looking at the chargeport sheet in the spreadsheet? It seems the only id you have that we don't have is 0x7f2. I don't know about lengths because you didn't post them. I assume you don't have a chargeport ecu connected so at least we can mark these messages from the bms


----------



## 96s46p

Collin80 said:


> Well, pretty sure. There are two CAN buses at the master BMS plug. One is labeled CP and the other PT. Unless I got dyslexic I was connected to CP when capturing. Connecting to PT shows just very slow differential pulses. I'm aware that the BMS master to modules comm is differential but not CAN. It's isoSPI. I've tried to connect to that but the modules seem to be really picky and I think Tesla might not have very strictly followed the isoSPI standard. The signals look to require things outside the isoSPI spec in order to generate. It doesn't seem to respond when I try talking directly to the modules. And, I'm pretty sure I'm speaking the proper language. I have isospi hardware, I've also got captures of the SPI traffic from the main CPU on the master board, and I can pretty easily directly read and decode in my head the isospi from an oscilloscope capture. So, I don't think I'm barking up the wrong tree but it refuses to cooperate - it has been extremely annoying. This leads me to believe that the isospi spec has been severely violated by Tesla and maybe that's why they're using custom BMS chips and not LTC6813 chips.


Bms definitely talks can on 2 buses Chargeport and Vehicle and it acts as a gateway between them. Internal labeling might not match bus naming for whatever reason. The other bus is probably either waiting for a wake message or needs to be activated by a voltage on one of the other pins.


----------



## Collin80

96s46p said:


> Are you looking at the chargeport sheet in the spreadsheet? It seems the only id you have that we don't have is 0x7f2. I don't know about lengths because you didn't post them. I assume you don't have a chargeport ecu connected so at least we can mark these messages from the bms


Whoops... You're right. I was looking at the powertrain bus in the spreadsheet. But, yes, this is just the BMS plugged in so every message ID I posted definitely comes from the BMS master board.


----------



## rhuber

JWardell said:


> No need for all that, really, switched 12v is the blue wire on the same connector that goes to the lighter socket, you can just power from that.
> Biggest issue is the car disconnects from wifi every time you drive, so you will have to manually reconnect to the module each time, and the module will have to share internet from its own cell connection in order for the rest of the computer to remain connected.
> But yes, the web browser is the a great completely stock way to view info!


I should have been clearer on what I'm looking to do! The broader thing I'm working on is an all-in-one connectivity solution for the car that lets me remotely debug/connect without physical presence. I have a Pi in my car with multiple cameras attached (sentry mode++), but drawing power for a Pi constantly is costly, so I'm using the Particle Electron as a low power controller to remotely turn on the pi and manage charging the large battery pack the pi runs from. I also have a small solar panel on the rear window deck that helps to top off the battery pack. I'm using a mosfet to ensure that I can turn off charging load to the battery pack instead of it having a constant draw from the car's 12v system.

(I still need to test out good sources for 12v unswitched power. Afaik the only known/useful one is the power to the hazard button near the map lights, but it is limited to approx 1 amp.)


----------



## JWardell

rhuber said:


> I should have been clearer on what I'm looking to do! The broader thing I'm working on is an all-in-one connectivity solution for the car that lets me remotely debug/connect without physical presence. I have a Pi in my car with multiple cameras attached (sentry mode++), but drawing power for a Pi constantly is costly, so I'm using the Particle Electron as a low power controller to remotely turn on the pi and manage charging the large battery pack the pi runs from. I also have a small solar panel on the rear window deck that helps to top off the battery pack. I'm using a mosfet to ensure that I can turn off charging load to the battery pack instead of it having a constant draw from the car's 12v system.
> 
> (I still need to test out good sources for 12v unswitched power. Afaik the only known/useful one is the power to the hazard button near the map lights, but it is limited to approx 1 amp.)


Pretty much every output of every controller is current monitored and software controlled, and the blue 12v lighter socket wire is still the best choice as it is switched and allows 15A. It can be easily tapped in the base of the A pillar/footwell, the rear console plug, or in the console itself.


----------



## rhuber

JWardell said:


> Pretty much every output of every controller is current monitored and software controlled, and the blue 12v lighter socket wire is still the best choice as it is switched and allows 15A. It can be easily tapped in the base of the A pillar/footwell, the rear console plug, or in the console itself.


Ah excellent info. Do you know if there is any way to turn on the switched current for the socket without being in the car? I experimented with turning on climate/etc but was unable to remotely trigger current on the switched power sources I tried.


----------



## JWardell

rhuber said:


> Ah excellent info. Do you know if there is any way to turn on the switched current for the socket without being in the car? I experimented with turning on climate/etc but was unable to remotely trigger current on the switched power sources I tried.


As far as I know it is on only when someone is in the car and the display is on. Not sure if it will be on when sentry or dog mode is activated.
Remote activation is a much more difficult ask, perhaps you have something with a permanent 12v connection (to battery or to PCS output under rear seat) and its own remote connection to switch its power.


----------



## Kayt183

JWardell said:


> I won't ask how a Model 3 managed to get to Russia, unless this is yet another chapter of You You's roadtrip car that died in Greece


Sorry, i'm can't understand, Greece is a country or it's slang word? I thought the car came from the US.


Collin80 said:


> Good news for people testing these things outside of a car - the BMS master talks CAN immediately when you power it


I can say more. It does not need external power. BMS (power conversion module) start working with HV battery.


fast_like_electric said:


> Yes, '00 00' at those cell locations would not be normal. Did that go away when you manually charged the pack up a bit?


Yes, it's correct after some charging battery. Added here BMS data after charging to 330V and some temperature data. I'm not found any temperature sensors on the power modules. It's During the night cells in each modules are alligned by the voltage.


fast_like_electric said:


> If you have no luck when you reconnect to the car, you may want to check the pyro fuse in the penthouse.


Pyro and 3 fuses in the penthouse i'm checked in the first time.


fast_like_electric said:


> but hard to believe Model 3 wouldn't have such a recovery via the BMS itself via a much more controlled approach.


May be it's have it, but we need a secret can bus word to start this.


Collin80 said:


> There are two CAN buses at the master BMS plug.


BMS master plug is the one under the back seat on the right?


rhuber said:


> I still need to test out good sources for 12v unswitched power.


You can get 12v under the rear seats on the main connector from BMS


----------



## Love

Kayt183 said:


> Sorry, i'm can't understand, Greece is a country or it's slang word? I thought the car came from the US.


There was a young man named YouYou that took his car from the U.S. to Europe and ended up crashing in Greece (the country).


----------



## scottf200

rhuber said:


> Ah excellent info. Do you know if there is any way to turn on the switched current for the socket without being in the car? I experimented with turning on climate/etc but was unable to remotely trigger current on the switched power sources I tried.


Party Mode is supposed to keep the 12v plugs on too. Feb 15, 2019 twitter post.


----------



## b0n3z

rhuber said:


> I should have been clearer on what I'm looking to do! The broader thing I'm working on is an all-in-one connectivity solution for the car that lets me remotely debug/connect without physical presence. I have a Pi in my car with multiple cameras attached (sentry mode++), but drawing power for a Pi constantly is costly, so I'm using the Particle Electron as a low power controller to remotely turn on the pi and manage charging the large battery pack the pi runs from. I also have a small solar panel on the rear window deck that helps to top off the battery pack. I'm using a mosfet to ensure that I can turn off charging load to the battery pack instead of it having a constant draw from the car's 12v system.
> 
> (I still need to test out good sources for 12v unswitched power. Afaik the only known/useful one is the power to the hazard button near the map lights, but it is limited to approx 1 amp.)


@rhuber I would be really interested in how you did this. If you had ANY pictures or more info on the software or hardware (camera and type of Raspberry Pi used) that would be VERY helpful.


----------



## Collin80

JWardell said:


> Pretty much every output of every controller is current monitored and software controlled, and the blue 12v lighter socket wire is still the best choice as it is switched and allows 15A. It can be easily tapped in the base of the A pillar/footwell, the rear console plug, or in the console itself.


Yes, let's say you try it anyway and tap the power wires going to one of the ECUs. Let's further say you then draw about 300ma to power a board. What happens is that the vehicle knows you did this and slaps your hands. So, there just isn't a lot of headroom available to power electronics from the existing power wires that run to the various control boards. Unfortunately a Particle Electron still takes enough power that I'd imagine the car will know. I know for sure an ESP32 doing WiFi takes enough power to alert the car you are fooling around. So, the lighter socket probably is a good bet. I suppose one might get away with drawing a very minimal amount of current from an existing control harness and then use that to trigger the lighter socket to come on which powers other things. But, the whole point of something like a Particle Electron is to keep the radio humming and radios are not super low power devices.


----------



## JWardell

Spreadsheet and DBC have been updated with several new updates and fixes and a few more signals. I added message cycle times and created some dummy networks which is probably of interest to no one.
Most significant is message 7FF which has factory configuration, including premium/standard settings, paint color and wheels, and potentially useful AWD/RWD config if you're making something that needs to know that (like a display showing value for one motor or two...)
Thanks again to all that have been helping out with signals, decoding, and especially continuous improvements to the tools to handle all this great stuff.


----------



## Kayt183

Here the data from the CAN bus corresponds to the physical location of the cells in the battery. It's raise from blue 1S to 23S, then green from S1 to S25 and so on.


----------



## JWardell

Here's a question I would like folks' opinion on:

ID 108 and 154 have torque and RPM. In our early experimenting we found torque scaling should be 0.2 or 0.25. But I have had a few sources now say this scale is actually 2. That would mean the car puts out 4000NM? No.
Likewise the speed in here was found to be axle speed with a 0.1 scale.
So it seems these bytes' real decoding is for axle rpm and axle torque. But are we not all more interested in motor speed and torque? The car (and every other) is after all rated by torque at the motor.

So I either go with official scaling of 2 and 0.1 respectively for torque and RPM, or I adjust by the 9:1 gearbox ratio and use a scale of 0.22222 and 0.9 respectively, and call this motor torque and RPM.

What do you all think?


----------



## Collin80

I'd go with motor torque and RPM. Nobody ever talks about the axle torque. Axle RPM is somewhat useful but only insomuch as it directly corresponds to the actual vehicle speed. But, we've already got MPH or KPH for that so I think it is most appropriate to think in terms of the motor performance.


----------



## 96s46p

China is getting OBD-II


----------



## scottf200

scottf200 said:


> Party Mode is supposed to keep the 12v plugs on too. Feb 15, 2019 twitter post.
> <snip>


Now done with Sentry on/off.



suprteck said:


> Anyone else notice that the 12v cigarette outlet stays on all the time with car off ever since the newest Sentry mode update. Even with sentry mode off the outlet is still powered. I have my blackvue hooked up to the 12v outlet and worried the 12v battery will drain with the dashcam being constantly on...


----------



## JWardell

Feathermerchant said:


> JWardell - I sent you some interesting information. For the rest of y'all watch this video. It has a lot of other stuff in it but we are not alone.
> 
> 
> 
> 
> 
> Spoiler - They are developing a pretty easy way to monitor the bus and interface with a USB.


Ruh Roh, looks like @Jack Rickard 's video has disappeared  I hope for no nefarious reason


----------



## Roci

I have successfully made contact between my Model 3 and my phone using a Bluetooth Low Energy connection.

Connected to the CAN bus is a MCP2515 board connected to an ESP32 microcontroller. The firmware reads the CAN bus for certain frames I find interesting and then sends them through BLE to any listening device in the car. Right now that's my iPhone running the Blynk app.









Here's the app reading data in real time. I have an AWD so I found it extremely interesting to see how the car applies power differently to the front and rear motors. It seems like the front motor is usually dormant unless a large amount of power is called for.


----------



## JWardell

Roci said:


> I have successfully made contact between my Model 3 and my phone using a Bluetooth Low Energy connection.
> 
> Connected to the CAN bus is a MCP2515 board connected to an ESP32 microcontroller. The firmware reads the CAN bus for certain frames I find interesting and then sends them through BLE to any listening device in the car. Right now that's my iPhone running the Blynk app.
> 
> View attachment 22436
> 
> 
> Here's the app reading data in real time. I have an AWD so I found it extremely interesting to see how the car applies power differently to the front and rear motors. It seems like the front motor is usually dormant unless a large amount of power is called for.


 Very cool! I haven't used Blynk since it first came out but it was nice and easy to get working with an Arduino, and I do love easy 
It seems your battery shows regen but not your rear motor, you might be reading the wrong data or maybe the front motor is doing all the regen?

This is why I really need to do a few captures with a dual motor car.

And really really need to find a place to make a bunch of connectors so more people can do captures.


----------



## eXntrc

Roci said:


> Right now that's my iPhone running the Blynk app.


I wasn't here to follow this thread from the beginning (just got my 3 a month ago) but I do stop by once in a while to check out the progress. I just wanted to say @Roci that I really like the little UI you put together there. I'm really impressed with what you and @JWardell and everyone else are working on here. I hope I get a chance to play with all of this in the future.

I'll keep an eye out for a connector and a simple way to get this setup. I hope someone puts together a nearly ready-made solution. That's why I love this idea of the MCP2515 + Blynk to rapidly prototype a UI.

Please keep up the good work guys. Sorry I don't have a lot to contribute at this stage, but know that even those of us who don't quite understand what you're doing appreciate your hard work.

Cheers!


----------



## Roci

JWardell said:


> It seems your battery shows regen but not your rear motor, you might be reading the wrong data or maybe the front motor is doing all the regen?


Thanks for noticing that . I had a mistake in the Blynk config. I changed out the video, now you will notice that only the rear motor is doing regen, none from the front motor. This was with ambient temp at 30°F and the max regen was limited. I will try again when the battery warms up!



JWardell said:


> This is why I really need to do a few captures with a dual motor car.


I plan to try out @Collin80's ESP32RET and try to get a full capture soon. It is made for specialized hardware though and I am using a generic ESP32 and MCP2515 board, so I'm not sure what modifications will be necessary.



JWardell said:


> And really really need to find a place to make a bunch of connectors so more people can do captures.


Proper connectors would be awesome! I just shoved the wires into the backside of the connector and taped it on, and while it's working fine for now, not a good long term solution.


----------



## WaxJack

JWardell said:


> Ruh Roh, looks like @Jack Rickard 's video has disappeared  I hope for no nefarious reason


Not to worry @JWardell. You can still see the video in the EVTV archives.

http://www.evtv.me.s3-website-us-east-1.amazonaws.com/vidarch.html

@Jack Rickard Any reason it was removed from YouTube? Did Elon get on to you? 

Great work here guys! Love to see what you are doing with an already amazing vehicle.


----------



## JWardell

JWardell said:


> Here's a question I would like folks' opinion on:
> 
> ID 108 and 154 have torque and RPM. In our early experimenting we found torque scaling should be 0.2 or 0.25. But I have had a few sources now say this scale is actually 2. That would mean the car puts out 4000NM? No.
> Likewise the speed in here was found to be axle speed with a 0.1 scale.
> So it seems these bytes' real decoding is for axle rpm and axle torque. But are we not all more interested in motor speed and torque? The car (and every other) is after all rated by torque at the motor.
> 
> So I either go with official scaling of 2 and 0.1 respectively for torque and RPM, or I adjust by the 9:1 gearbox ratio and use a scale of 0.22222 and 0.9 respectively, and call this motor torque and RPM.
> 
> What do you all think?


All feedback has been unanimous, that 108 should represent torque at the motor.
However if 0.25 scaling for 0x154 is to be believed, 2x 9:1 0.2222 scaling of 0x108 does not quite match it. Of course it is a slower averaged message, but it still seems to be a bit too high.
Looking at traces from some of my runs, I see a max of 405.25 NM with 154 at .25, while 108 will show 426.66NM.
It seems a matching scale factor for 108 would be 0.211 or ~2x 9.5:1

1. How confident are we that gear ratio is 9:1?
2. How confident are we that 0x154 scaling is 0.25? I see this is carried over from Model S CAN. But where is the original source of that?

Sorry to dig so deep into this one, but I think torque might be one the messages people are most interested in, and we have two conflicting measurements. While we have hard factual data for others, we don't for this.
We just need a Tesla developer or test engineer to verify this one for sure 

I hope especially with European deliveries ramping up we can get a full-power acceleration log for dual motor soon, we still have yet to confirm front motor messages and how overall totals are reflected.

Also: Does anyone have an idea of other data contained in 0x154?


----------



## b0n3z

Just to let everyone know - I'm trying to reach out to Geotab (they purchased FleetCarma) to obtain this part seperately (cost and shipping). I'll relay the response here. I already have my adapters and pins. However, I feel this would make it much easier for others to play.

Part Number: HRN-CT20T1
https://www.geotab.com/documentation/harness-identification-application/#h.b7fz87envlcm


----------



## Collin80

Roci said:


> I plan to try out @Collin80's ESP32RET and try to get a full capture soon. It is made for specialized hardware though and I am using a generic ESP32 and MCP2515 board, so I'm not sure what modifications will be necessary.


I might be the proper person to ask about that.  The ESP32-CAN library has support for the MCP2515 but it is currently commented out and the MCP2517FD is being used instead. Basically you'd just go into esp32_can.cpp in the library and comment out the MCP2517FD instantiation and uncomment the MCP2515. Obviously change CS and INT if you connected them to different pins. Then it should work but I've never tried ESP32RET with the MCP2515 driver enabled. I pretty quickly changed to the MCP2517FD and kept using that. CAN-FD for the win! Really, the MCP2517FD is barely any more money and WORLDS better than the junky MCP2515.


----------



## Collin80

WaxJack said:


> Not to worry @JWardell. You can still see the video in the EVTV archives.
> 
> http://www.evtv.me.s3-website-us-east-1.amazonaws.com/vidarch.html
> 
> @Jack Rickard Any reason it was removed from YouTube? Did Elon get on to you?
> 
> Great work here guys! Love to see what you are doing with an already amazing vehicle.


I'm pretty sure the reason is a copyright report against the video. You see, for years he's been using the same orchestra piece at the start and end of the videos. He had apparently licensed the rights to that song so technically he is in the clear. But, youtube is trolled by copyright bots that look for any video that might use a copyrighted song and report it automatically. There is no way for the bot to know whether you've licensed the audio or not. No way to know whether your use is "fair use" which is protected in the US. They just plain report you. Then onus is then on the video creator to answer each and every claim against them. You can fight or you can give up. I believe three strikes against you (whether proved valid or not!) will get your account banned. So, I don't know whether he is fighting it or not but I suspect he might. It's a very crappy situation and many youtube creators are getting nailed by this type of thing. There's even a scam going where people will threaten to report your videos if you don't pay them protection money to not mess with you. It's like the digital mafia.

So that's the long answer. The short answer is that youtube kind of sucks and Google just plain doesn't care at all.


----------



## Collin80

JWardell said:


> 1. How confident are we that gear ratio is 9:1?
> 2. How confident are we that 0x154 scaling is 0.25? I see this is carried over from Model S CAN. But where is the original source of that?
> Also: Does anyone have an idea of other data contained in 0x154?


Well, the Model S doesn't use a 9:1 ratio but rather something like 9.8:1 so it's certainly possible it's something else. It would really help if we had the RPM of the motor itself. The Model S reports that so I'd think it should be in there somewhere. But, I can't find anything else that looks like RPM that isn't already covered.

As for other data in 0x154. No, not really. Byte 7 (last byte) seems like it has a counter but sometimes it counts by 0x20 and sometimes by 0x10, then the last 4 bits change but I don't know why. The first three bytes seem to be status flags; at least they change in ways that would suggest they're full of flags. For instance, the third byte seems to change from 00 to 0x10 when driving. Bytes 3 and 4 are never used, 5 and 6 have torque with the upper 4 bits of 6 being a counter of sorts incrementing by 2 each time. There is certainly a specific dance of flags you can see in the first three bytes right before it starts to provide torque. That must mean something. There might be duplication of the gear or drive mode into this frame.

Not so subtle advertisement... SavvyCAN can load the Vector ASC logs and you can use the frame data analysis, sniffer, and flow view windows to find this kind of stuff. But, it will be even better to do it live and watch as things change when you do things.


----------



## JWardell

b0n3z said:


> Just to let everyone know - I'm trying to reach out to Geotab (they purchased FleetCarma) to obtain this part seperately (cost and shipping). I'll relay the response here. I already have my adapters and pins. However, I feel this would make it much easier for others to play.
> 
> Part Number: HRN-CT20T1
> https://www.geotab.com/documentation/harness-identification-application/#h.b7fz87envlcm
> 
> View attachment 22483


Is that part for model 3 or model S? I'm surprised to see an OBD connector, I didn't think there were the right signals for it.
Of course if it's a passthrough it would still be useful.
I wonder if @bearbu managed to get in touch with anyone about making connectors.
Otherwise I might start reaching out when I get back from vacation in a few weeks.



Collin80 said:


> I'm pretty sure the reason is a copyright report against the video. You see, for years he's been using the same orchestra piece at the start and end of the videos. He had apparently licensed the rights to that song so technically he is in the clear. But, youtube is trolled by copyright bots that look for any video that might use a copyrighted song and report it automatically. There is no way for the bot to know whether you've licensed the audio or not. No way to know whether your use is "fair use" which is protected in the US. They just plain report you. Then onus is then on the video creator to answer each and every claim against them. You can fight or you can give up. I believe three strikes against you (whether proved valid or not!) will get your account banned. So, I don't know whether he is fighting it or not but I suspect he might. It's a very crappy situation and many youtube creators are getting nailed by this type of thing. There's even a scam going where people will threaten to report your videos if you don't pay them protection money to not mess with you. It's like the digital mafia.
> 
> So that's the long answer. The short answer is that youtube kind of sucks and Google just plain doesn't care at all.


Google is slowly destroying Youtube just like it does to most of its other sites and hostile takeovers. I really wish there was a formidable alternative.


----------



## Mike

Collin80 said:


> I'm pretty sure the reason is a copyright report against the video. You see, for years he's been using the same orchestra piece at the start and end of the videos. He had apparently licensed the rights to that song so technically he is in the clear. But, youtube is trolled by copyright bots that look for any video that might use a copyrighted song and report it automatically. There is no way for the bot to know whether you've licensed the audio or not. No way to know whether your use is "fair use" which is protected in the US. They just plain report you. Then onus is then on the video creator to answer each and every claim against them. You can fight or you can give up. I believe three strikes against you (whether proved valid or not!) will get your account banned. So, I don't know whether he is fighting it or not but I suspect he might. It's a very crappy situation and many youtube creators are getting nailed by this type of thing. There's even a scam going where people will threaten to report your videos if you don't pay them protection money to not mess with you. It's like the digital mafia.
> 
> So that's the long answer. The short answer is that youtube kind of sucks and Google just plain doesn't care at all.


I have been wondering (and lamenting) about the sudden disappearance of the fanfare that was used at the start and end of each episode.

I miss it......


----------



## JWardell

Collin80 said:


> Not so subtle advertisement... SavvyCAN can load the Vector ASC logs and you can use the frame data analysis, sniffer, and flow view windows to find this kind of stuff. But, it will be even better to do it live and watch as things change when you do things.


Oh wow...and there is a Mac version...and it supports all sorts of log formats...let me just give it a try here..Took a few minutes to figure things out a bit, no idea why packets are white-on-white until clicked, but it seems to work otherwise. Do I see mention of PEAK USB support as well? Can I view graphs live or just packets? Awesome that there are filters.
Now this is something I can play with at home!


----------



## fast_like_electric

Collin80 said:


> As for other data in 0x154. No, not really. Byte 7 (last byte) seems like it has a counter but sometimes it counts by 0x20 and sometimes by 0x10, then the last 4 bits change but I don't know why. The first three bytes seem to be status flags; at least they change in ways that would suggest they're full of flags. For instance, the third byte seems to change from 00 to 0x10 when driving. Bytes 3 and 4 are never used, 5 and 6 have torque with the upper 4 bits of 6 being a counter of sorts incrementing by 2 each time. There is certainly a specific dance of flags you can see in the first three bytes right before it starts to provide torque. That must mean something. There might be duplication of the gear or drive mode into this frame.


A very close summary, but a few points to better detail/clarify. The mysterious 0x154 torque starts at bit 40, is signed, and is 13 bits long (or bits 40-52). The rest of 2nd last byte (3 high order bits - Vector speak 53-55) are just a 3 bit counter. The final byte (bits 56-63) is the checksum for the frame.

The counter/checksum is standard as per typical critical messages. The question here is what is that apparent torque field/signal, and what is its scaling. Definitely interesting behavior with the other fields in the frame as you mention as well.

If you scale the 0x154 'torque' field appropriately and overlay this with torque from 0x108, you'll also see an interesting dead band around zero.


----------



## rmn

JWardell said:


> And really really need to find a place to make a bunch of connectors so more people can do captures.





b0n3z said:


> Part Number: HRN-CT20T1


I can not bring too much to this thread in terms of software but I could definitely build those wire harness. My company assembles in China similar cables and I am sure we can do it. Could you give me more information about the type of OBD female cable that you need? How many pins do you need on the OBD cable?


----------



## b0n3z

JWardell said:


> Is that part for model 3 or model S? I'm surprised to see an OBD connector, I didn't think there were the right signals for it.
> Of course if it's a passthrough it would still be useful.
> I wonder if @bearbu managed to get in touch with anyone about making connectors.
> Otherwise I might start reaching out when I get back from vacation in a few weeks.
> 
> Google is slowly destroying Youtube just like it does to most of its other sites and hostile takeovers. I really wish there was a formidable alternative.


Yes, the GeoTab / FleetCarma part number *HRN-CT20T1* shows the following information (Description: Custom Tesla Model 3 harness):



Code:


HRN-CT20T1
MyAdmin Details
Description: Custom Tesla Model 3 harness
Further Information
Requires: GO9 Device
Length: 30 cm / 12 inches
Max length of connected cables: 2 meters / 6.5 feet

I thought the same. I didn't know we could get OBDII directly from this and I don't know which pins they are using for this. However it looks exactly like an OBDII connector. It may also be proprietary, but I doubt it.


----------



## rmn

b0n3z said:


> I thought the same. I didn't know we could get OBDII directly from this and I don't know which pins they are using for this. However it looks exactly like an OBDII connector. It may also be proprietary, but I doubt it.


I got one of them. Let me know what would you like to see from it.


----------



## b0n3z

rmn said:


> I can not bring too much to this thread in terms of software but I could definitely build those wire harness. My company assembles in China similar cables and I am sure we can do it. Could you give me more information about the type of OBD female cable that you need? How many pins do you need on the OBD cable?


Hello @rmn

Currently this is what I know from this forum thread and another from TMC. I'm using the following parts list:

6098-5613
SUMITOMO TS series 20 way male housing
https://nexelec.com/SUMITOMO-60985613

8100-3622
SUMITOMO TS series male pin 0.22-0.35mm2 wire (need 16)
https://nexelec.com/SUMITOMO-81003622

8230-4923
SUMITOMO TS series male pin 2.0mm2 wire (need 4)
https://nexelec.com/SUMITOMO-82304923

6098-5629
SUMITOMO TS series 20 way female housing (blue) - (6098-5622 not available)
https://nexelec.com/SUMITOMO-60985629

8100-3624
SUMITOMO TS series female pin 0.22-0.35mm2 wire (need 16)
https://nexelec.com/SUMITOMO-81003624

8240-0214
SUMITOMO TS series female pin 2.0mm2 wire (need 4)
https://nexelec.com/SUMITOMO-82400214

As for the gauge of wire needed - I'm still researching that (unless someone already knows). The pin-out is the following below. As for this T cable and what pins would allow a OBDII connector - I'm unsure. I'm also unsure if we need access to ALL these CAN buses.


----------



## fast_like_electric

b0n3z said:


> Hello @rmn
> 
> Currently this is what I know from this forum thread and another from TMC. I'm using the following parts list:
> 
> 6098-5613
> SUMITOMO TS series 20 way male housing
> https://nexelec.com/SUMITOMO-60985613
> 
> 8100-3622
> SUMITOMO TS series male pin 0.22-0.35mm2 wire (need 16)
> https://nexelec.com/SUMITOMO-81003622
> 
> 8230-4923
> SUMITOMO TS series male pin 2.0mm2 wire (need 4)
> https://nexelec.com/SUMITOMO-82304923
> 
> 6098-5629
> SUMITOMO TS series 20 way female housing (blue) - (6098-5622 not available)
> https://nexelec.com/SUMITOMO-60985629
> 
> 8100-3624
> SUMITOMO TS series female pin 0.22-0.35mm2 wire (need 16)
> https://nexelec.com/SUMITOMO-81003624
> 
> 8240-0214
> SUMITOMO TS series female pin 2.0mm2 wire (need 4)
> https://nexelec.com/SUMITOMO-82400214
> 
> As for the gauge of wire needed - I'm still researching that (unless someone already knows). The pin-out is the following below. As for this T cable and what pins would allow a OBDII connector - I'm unsure. I'm also unsure if we need access to ALL these CAN buses.
> View attachment 22499


Tesla reused the X/S 20 pin 'diagnostic' connector in Model 3, but that isn't the pinout nor is it a diagnostic connector - just a harness junction. As it turns out, only the Vehicle CAN bus is on that connector - pins 18 and 19 as mentioned. All other wiring is for accessory and USB power, and private CAN buses to the remote BLE transceivers - connected to the security module. The pinout is in the signal spreadsheet on post 1 of this thread.


----------



## b0n3z

rmn said:


> I got one of them. Let me know what would you like to see from it.


It would be amazing to create a pin-out diagram for that OBD2 connector (what pins it's using from the end connector). I'm also interested in the wire gauge, but I might be able to figure that out from the wiring currently at that connector within the car. Are you able to source more of these for purchase?


----------



## rmn

b0n3z said:


> pin-out diagram for that OBD2 connector (what pins it's using from the end connector)


It's using pins 20 for GND, 19 CAN_L, 18 CAN_H and 4 for 12v from the Sumitomo 6098-5622. And, of course, the OBD connector has only those four pins. Cables I believe are AVSS 1.5mm and 0.3mm.

I can not find this same cable but can make it if that's what you guys need.



fast_like_electric said:


> only the Vehicle CAN bus is on that connector - pins 18 and 19 as mentioned


Yes


----------



## Collin80

JWardell said:


> Oh wow...and there is a Mac version...and it supports all sorts of log formats...let me just give it a try here..Took a few minutes to figure things out a bit, no idea why packets are white-on-white until clicked, but it seems to work otherwise. Do I see mention of PEAK USB support as well? Can I view graphs live or just packets? Awesome that there are filters.
> Now this is something I can play with at home!


Sorry, it's because I ended up causing the background to always be white but the text is set by the operating system like it should be. What this means for dark mode in OSX is that you end up with both the forced white background and the white text of the dark theme in OSX. That doesn't work at all. I will fix this (hopefully very soon) so that it properly picks up the background color. One thing that should work, though, is to use a DBC file and click "Interpret Frames". The defaults for DBC interpreted frames are black text on white background. That would kind of fix the issue but will still look stupid on the dark theme. But, this is part of the DBC system and you are free to set any color scheme you want. Maybe I should make DBC based frame coloring a selectable thing so that you can turn it off if you'd rather the OS pick the colors for you even when interpreting frames.


----------



## 96s46p

rmn said:


> It's using pins 20 for GND, 19 CAN_L, 18 CAN_H and 4 for 12v from the Sumitomo 6098-5622. And, of course, the OBD connector has only those four pins. Cables I believe are AVSS 1.5mm and 0.3mm.
> 
> I can not find this same cable but can make it if that's what you guys need.
> 
> Yes


I think people would definitely buy that cable (for a reasonable price) because it's easy to connect to off the shelf obd readers that support can passthrough and otherwise you can just cut off the obd connector and connect the wires to a custom board.


----------



## Model3MadHacker

Hi guys, I ran across this thread this weekend and have read it beginning to end. Quite awesome progress you guys have made. I had a beagle bone black with a LTE/CAN cape from nimbelink lying around, and today I assembled a data logger for myself using it today. I tested it on one of my other cars to make sure it's working, so I'm ready to tap into the model 3, but I'd prefer to have one of these harnesses you guys are working on to tap in without having to splice into the car wires, so I'm down to order one as well.

The progress you have made is really exciting and I hope to be contributing in a few days. Thanks for all your hard work thus far, and let me know if there is any specific area I should focus.


----------



## JWardell

rmn said:


> It's using pins 20 for GND, 19 CAN_L, 18 CAN_H and 4 for 12v from the Sumitomo 6098-5622. And, of course, the OBD connector has only those four pins. Cables I believe are AVSS 1.5mm and 0.3mm.
> 
> I can not find this same cable but can make it if that's what you guys need.
> 
> Yes


This is great! Preferably a very short harness with flying wires for CAN, 12v, and GND would be the most versatile. I don't think that big harness with the OBD connector will fit if you put the panel back on. Might need to experiment a little. But most importantly it needs to be a straight-through for all 20 pins, and takeoff wires for those four. If there are flying wires than we can easily add whatever is needed for project, like twisted pair with DB9 for general CAN, or maybe directly wire a small wireless transmitter. 
Toughest part is source parts, and probably proper crimpers as well. Sumitomo is famous for being tough to work with. But I'll certainly fund several dozen myself and I'm sure there are others here that would help us get to a reasonable production quantity.



Model3MadHacker said:


> Hi guys, I ran across this thread this weekend and have read it beginning to end. Quite awesome progress you guys have made. I had a beagle bone black with a LTE/CAN cape from nimbelink lying around, and today I assembled a data logger for myself using it today. I tested it on one of my other cars to make sure it's working, so I'm ready to tap into the model 3, but I'd prefer to have one of these harnesses you guys are working on to tap in without having to splice into the car wires, so I'm down to order one as well.
> 
> The progress you have made is really exciting and I hope to be contributing in a few days. Thanks for all your hard work thus far, and let me know if there is any specific area I should focus.


Thanks, and welcome!


----------



## Jack Rickard

WaxJack said:


> Not to worry @JWardell. You can still see the video in the EVTV archives.
> 
> http://www.evtv.me.s3-website-us-east-1.amazonaws.com/vidarch.html
> 
> @Jack Rickard Any reason it was removed from YouTube? Did Elon get on to you?
> 
> Great work here guys! Love to see what you are doing with an already amazing vehicle.


YouTube is suffering a hurricane of copyright claims. The EU parliament passed a law, not actually enacted by any member states yet, basically eliminating fair use in Europe. YouTube has panicked and it is just a ****show.

I'm not specifically targetted, indeed I'm not even the nth part of what all this is causing. But because of the number of videos we have, I really can't deal with it.

I have 355 videos over 10 years. All use the Theme from Lonesome Dove in the opening and ironically I actually licensed this over a decade ago. But the content matching tools YouTube provides doesn't even provide a means for matching licenses. UMG doesn't know how to do it and basically everyone can only automate stuff because with 5 billion videos it is too vast for humanoids. I am BURIED with take down notices for things included years ago. AI indeed. Artificial stupid. I don't even have time to respond to the notices at this point.

IN any event, I';ve pretty much had it. EVTV has always been available at http://evtv.me since 2009. YouTube was always a sideshow for us. We have our own YouTube. And I am currently planning on simply not uploading to YouTube in the future. I've kind of gotten addicted to teasing the trolls in the comments recently. But beyond that it is pretty much a mess for us and always has been. People interested in EV's and solar etc always seem to find us somewhere along the line anyway.

Jack Rickard


----------



## fast_like_electric

96s46p said:


> China is getting OBD-II


Yes, that makes use of a dedicated OBD2 CAN channel (and some non-standard OBD2 pin usage), connected only to the right body module. Not the same CAN bus that is at the center console (Vehicle CAN), which is loaded with normal non-diagnostic messaging.

US vehicles do not have that connector or wiring. Unclear if European vehicles may have it. Regarding what supported OBD2 comms are possible - someone in China (or possibly Europe) would need to advise - after they receive their vehicles.


----------



## rmn

JWardell said:


> If there are flying wires than we can easily add whatever is needed for project, like twisted pair with DB9 for general CAN, or maybe directly wire a small wireless transmitter.


We can do both. Let me know which one would you like and if its a DB9 connector, which pinout should it be. I can do a few cables so you guys can test it, that is no problem at all. If the quantity needs to be above a few ( +10 ) I can look into costs.


----------



## WaxJack

Thanks for the explanation @Jack Rickard and @Collin80. I would much rather use the evtv site anyways.


----------



## JWardell

rmn said:


> We can do both. Let me know which one would you like and if its a DB9 connector, which pinout should it be. I can do a few cables so you guys can test it, that is no problem at all. If the quantity needs to be above a few ( +10 ) I can look into costs.


Mine has about 3" pass through wires, with 4" taps for 12v/ground/CANL/CANH (pins 1/20/19/18) as pictured. The short wires allow me to attach whatever I want to it (at the moment a long twisted pair to DB9), but I hope that is replaced with a small wireless module soon. See the photo below.
Although maybe a slightly longer harness (6 inches?) could more easily be stuffed in the hole below, and would probably be a lot easier to build as well. I welcome feedback.
But IMO there's no sense doing much more than flying wires, as it would be a waste if we're just cutting off whatever connector is added.
Also I found it impossible to crimp two wires into a pin then fit that pin into the connector, I had to solder a connection in the middle of the harness. Many hours were wasted learning that the harder way is the better way 










Please ignore the dog hair and cheez-it


----------



## rmn

JWardell said:


> The short wires allow me to attach whatever I want to it (at the moment a long twisted pair to DB9), but I hope that is replaced with a small wireless module soon. See the photo below.


I am not familiar with OBD parameter IDs but, if you want to attach a wireless module to the two CAN wires that come from the wire harness, wouldn't an OBD connector that allows you to connect a bluetooth OBD reader be a good option?

The kit from FleetCarma for the Tesla Model 3 is exactly that.

Anyway, I will have a few done and let you know. It shouldn't take longer than a week.


----------



## 96s46p

The advantage of a connector is plug-and-play and reliable wire termination. A lot of people don't like playing with wires and a loose wire could bring down the whole bus. The Fleetcarma instructions have you route the obd connector down and under the trim so it sits next to the seat where it probably has better rf signal. J1962 is a little bulky but does have a nice finished enclosed look and should work with obdlink, panda, and maybe some cheaper ones that have a HS-CAN switch. It's probably not ideal for the hw hacker, but having options is good and cutting a connector off is easier than adding one.


----------



## JWardell

I wouldn't sell connectors to folks without the correct connector attached to it, I was just answering from the perspective of building 50-100 at a CM for me or a few of us that will do something more with them.
Also, I thought the OBD harnesses were not obtainable or you were still waiting for a response.


----------



## 96s46p

I would go straight to 1k+ volume for economy of scale. But maybe @rmn can already get it due to combined volume. There will be 500k+ model 3s out there relatively soon. J1962 is cheap, widely available, automotive rated, and non proprietary. But maybe there are other options for a common connector. I don't think geotab will sell them on the cheap so it will be best to go straight to a harness manufacturer.


----------



## Collin80

I just updated the SavvyCAN binaries to fix the various issues with using a dark theme. Now all of the screens should be legible with a dark layout as well. Also, it can now automatically find ESP32RET devices so if you're using ESP32 with wifi you shouldn't even need to know the IP address of your board, it'll find it (update ESP32RET too from the website). So hopefully that helps.

I also found that SerialBus is not supported on OSX though I have no idea why. On Windows and Linux you can use devices like Peak CAN devices with SavvyCAN (and anything socketcan on linux) but on OSX for some reason there isn't any QT SerialBus support so only the *RET devices will work. I hope the QT people add support for OSX soon. In theory on Linux and Windows you can use any passthrough CAN compatible device too. That should open up the Vector hardware to work too with the proper drivers.

Obvious web address: www.savvycan.com


----------



## JWardell

Collin80 said:


> I just updated the SavvyCAN binaries to fix the various issues with using a dark theme. Now all of the screens should be legible with a dark layout as well. Also, it can now automatically find ESP32RET devices so if you're using ESP32 with wifi you shouldn't even need to know the IP address of your board, it'll find it (update ESP32RET too from the website). So hopefully that helps.
> 
> I also found that SerialBus is not supported on OSX though I have no idea why. On Windows and Linux you can use devices like Peak CAN devices with SavvyCAN (and anything socketcan on linux) but on OSX for some reason there isn't any QT SerialBus support so only the *RET devices will work. I hope the QT people add support for OSX soon. In theory on Linux and Windows you can use any passthrough CAN compatible device too. That should open up the Vector hardware to work too with the proper drivers.
> 
> Obvious web address: www.savvycan.com


The interpreted frames are still white-on-while but still this is very nice. I like being about to just click on different messages and see the graphs of each byte.
Paging @fast_like_electric you might want to have a look at this too


----------



## Pierre Champoux

JWardell said:


> All feedback has been unanimous, that 108 should represent torque at the motor.
> However if 0.25 scaling for 0x154 is to be believed, 2x 9:1 0.2222 scaling of 0x108 does not quite match it. Of course it is a slower averaged message, but it still seems to be a bit too high.
> Looking at traces from some of my runs, I see a max of 405.25 NM with 154 at .25, while 108 will show 426.66NM.
> It seems a matching scale factor for 108 would be 0.211 or ~2x 9.5:1
> 
> 1. How confident are we that gear ratio is 9:1?
> 2. How confident are we that 0x154 scaling is 0.25? I see this is carried over from Model S CAN. But where is the original source of that?
> 
> Sorry to dig so deep into this one, but I think torque might be one the messages people are most interested in, and we have two conflicting measurements. While we have hard factual data for others, we don't for this.
> We just need a Tesla developer or test engineer to verify this one for sure
> 
> I hope especially with European deliveries ramping up we can get a full-power acceleration log for dual motor soon, we still have yet to confirm front motor messages and how overall totals are reflected.
> 
> Also: Does anyone have an idea of other data contained in 0x154?


Here is the information about the gear ratio of 9:1 found in the Tesla EPA certification document:


----------



## fast_like_electric

Pierre Champoux said:


> Here is the information about the gear ratio of 9:1 found in the Tesla EPA certification document:


I believe the gear ratio of 9:1 for Model 3 is known and solid. But, that exact 9 to 1 scaling can only be used to scale motor speed to axel speed (or vice versa). For torque, you also have to consider mechanical loss of the gearing, the friction which turns into heat. In very general terms, 90-95% efficiency is typical, as there is about 5-10% loss at each gear mesh point. Because this is Tesla, lets go with closer to 5%.

Lets assume that 0x108 is 'axel torque' at 2 NM scaling, and 0x154 is 'motor torque' at 0.25NM scaling. If you overlay the plots, they don't line up quite right, 'motor torque' looks too big as you mention. But if you factor in drivetrain loss and scale up the 0x108 numbers up to 105%, or scale down the 0x154 number to 95% - the plots align (at least mine do).

So I believe the scaling that you mentioned is likley correct, the discrepancy being the affect of the drivetrain loss. Here is a pretty easy to follow summary of gear ratio and its affect on speed/torque/power.

https://www.engineeringtoolbox.com/gear-output-torque-speed-horsepower-d_1691.html

To more conclusively know, I'd love to be able to pull up that diagnostic screen and see the actual numbers during driving. That would certainly help with mapping some of the more pesky signals.


----------



## JWardell

fast_like_electric said:


> I believe the gear ratio of 9:1 for Model 3 is known and solid. But, that exact 9 to 1 scaling can only be used to scale motor speed to axel speed (or vice versa). For torque, you also have to consider mechanical loss of the gearing, the friction which turns into heat. In very general terms, 90-95% efficiency is typical, as there is about 5-10% loss at each gear mesh point. Because this is Tesla, lets go with closer to 5%.
> 
> Lets assume that 0x108 is 'axel torque' at 2 NM scaling, and 0x154 is 'motor torque' at 0.25NM scaling. If you overlay the plots, they don't line up quite right, 'motor torque' looks too big as you mention. But if you factor in drivetrain loss and scale up the 0x108 numbers up to 105%, or scale down the 0x154 number to 95% - the plots align (at least mine do).
> 
> So I believe the scaling that you mentioned is likley correct, the discrepancy being the affect of the drivetrain loss. Here is a pretty easy to follow summary of gear ratio and its affect on speed/torque/power.
> 
> https://www.engineeringtoolbox.com/gear-output-torque-speed-horsepower-d_1691.html
> 
> To more conclusively know, I'd love to be able to pull up that diagnostic screen and see the actual numbers during driving. That would certainly help with mapping some of the more pesky signals.


I expect there to be some losses, but torque is calculated at the motor by the inverter as it applies power. So that would mean they are not only multiplying by 9 but also compensating for losses just for this CAN message. Not what I would expect really.
But that certainly might explain the difference between 108 and 154.
I'm curious to see how it compares to the front motor.


----------



## JWardell

I have a request for folks:

- PLEASE make some captures of full throttle runs! -

With today's announcement of 5% power upgrades on the way, it would be very nice to see this in the data!

But I don't have baseline captures for AWD and performance.
I have a few of my own, I would love to go out and grab some more right now, but my car is deep chilled below freezing and the snow isn't helping!

I know we haven't seen captures from others yet, so my request is that if you think you might be able to, please take this as a little push for some fun weekend homework!


----------



## Roci

JWardell said:


> I have a request for folks:
> 
> - PLEASE make some captures of full throttle runs! -
> 
> With today's announcement of 5% power upgrades on the way, it would be very nice to see this in the data!
> 
> But I don't have baseline captures for AWD and performance.


I will have a capture of my AWD very soon, making progress with ESP32RET on my hardware, hopefully just a few more tweaks before I can get it to compile. It will be very exciting to see the exact power & torque improvements across the various models.


----------



## fast_like_electric

JWardell said:


> I have a request for folks:
> 
> - PLEASE make some captures of full throttle runs! -
> 
> With today's announcement of 5% power upgrades on the way, it would be very nice to see this in the data!
> 
> But I don't have baseline captures for AWD and performance.
> I have a few of my own, I would love to go out and grab some more right now, but my car is deep chilled below freezing and the snow isn't helping!
> 
> I know we haven't seen captures from others yet, so my request is that if you think you might be able to, please take this as a little push for some fun weekend homework!


Getting specific, Wide-Open-Throttle from 0 to 60 MPH would be quite useful. With a 0.02 sec rate of the vehicle speed message, that would give for excellent resolution.

It would be great to track even that most basic metric across multiple vehicle types (LR RWD supposed to be 5.1 sec, MR RWD 5.6 sec, AWD, Perf, etc). Captures will easily reveal that, as well as power mapping. The power curve had been rumored to have changed at some point already to date - losing some off the line punch yet maintaining the same overall 0-60 time. Would be great to have a record of this, should something change in new firmware at any point - good or bad.

And for best case data, be sure to do any performance runs at high state of charge as that affects max power output.


----------



## sjames

JWardell said:


> I have a request for folks:
> 
> - PLEASE make some captures of full throttle runs! -
> 
> With today's announcement of 5% power upgrades on the way, it would be very nice to see this in the data!
> 
> But I don't have baseline captures for AWD and performance.
> I have a few of my own, I would love to go out and grab some more right now, but my car is deep chilled below freezing and the snow isn't helping!
> 
> I know we haven't seen captures from others yet, so my request is that if you think you might be able to, please take this as a little push for some fun weekend homework!


I have a performance model 3. Would be happy to do some captures once you guys have a harness available.

In particular, I noticed that the messages you've deciphered so far only seem to include torque for one motor. I'd like to be able to monitor both of the motors. I expect we'd need captures from dual motor cars to figure out the front motor's messages.


----------



## JWardell

sjames said:


> I have a performance model 3. Would be happy to do some captures once you guys have a harness available.
> 
> In particular, I noticed that the messages you've deciphered so far only seem to include torque for one motor. I'd like to be able to monitor both of the motors. I expect we'd need captures from dual motor cars to figure out the front motor's messages.


We think we know what messages to look for with a dual motor, but have yet to make a capture with one in order to confirm. All the more reason I would love a dual motor capture before the new firmware is released. 
Basically I'm calling for anyone out there in the woodwork who thinks they can make a capture to help in the next week.
Unfortunately I will be out of the country, but all we need is a capture with some full acceleration, we can analyze data afterwards and hopefully repeat when the new software updates come out and compare.


----------



## amund7

EU dual motor - but what happened to the wire colors !?!?

Am I guessing correctly that pin 18 and 19 should still be CAN? But what happened to the blue, yellow, and 2 black + and - wires?


----------



## JWardell

amund7 said:


> View attachment 22662
> View attachment 22663
> 
> 
> EU dual motor - but what happened to the wire colors !?!?
> 
> Am I guessing correctly that pin 18 and 19 should still be CAN? But what happened to the blue, yellow, and 2 black + and - wires?


Looks like the 12v and GND on 11 and 12 were swapped? No I see more changes. Hmm. And it looks like Tesla also can't get the white connectors 

You should still aim for the thin blue & white pair. I always went in on the other side which was a little easier to access, although back row it tough regardless.


----------



## Roci

@Collin80 I got ESP32RET to compile and run on my ESP32 dev board, and SavvyCan can see it over WiFi, however it doesn't communicate with my MCP2515 board. I set all the config options & driver settings that I could find to support that board, but I'm thinking maybe the clock timing is incorrect, because a lot of the MCP drivers expect a 16MHz oscillator and mine uses an 8MHz. I do know that the following library allows the clock timing to be set to 8MHz and I can get it to communicate with my other project on the same dev board, so perhaps if this isn't an easy config change then I swap out the libraries? MCP_CAN Library for Arduino


----------



## 96s46p

JWardell said:


> Looks like the 12v and GND on 11 and 12 were swapped? No I see more changes. Hmm. And it looks like Tesla also can't get the white connectors
> 
> You should still aim for the thin blue & white pair. I always went in on the other side which was a little easier to access, although back row it tough regardless.


Actually it is a totally different connector, 26pins?


----------



## fast_like_electric

96s46p said:


> Actually it is a totally different connector, 26pins?


Right, and it's that way for all Model 3's built in 2019 - not just export.


----------



## 96s46p

fast_like_electric said:


> Right, and it's that way for all Model 3's built in 2019 - not just export.


And doesn't look like it is in the sumitomo catalog. Added to spreadsheet.


----------



## Collin80

Roci said:


> @Collin80 I got ESP32RET to compile and run on my ESP32 dev board, and SavvyCan can see it over WiFi, however it doesn't communicate with my MCP2515 board. I set all the config options & driver settings that I could find to support that board, but I'm thinking maybe the clock timing is incorrect, because a lot of the MCP drivers expect a 16MHz oscillator and mine uses an 8MHz. I do know that the following library allows the clock timing to be set to 8MHz and I can get it to communicate with my other project on the same dev board, so perhaps if this isn't an easy config change then I swap out the libraries? MCP_CAN Library for Arduino


Yeah, the library does expect a 16Mhz oscillator. That all really only matters for CAN bit speed though. The actual MCP2515 itself runs over SPI and SPI provides its own clock for comm. You might be able to cheat and claim that the CAN speed is 1Mb in order to get 500k speed. Otherwise, the underlying library does allow for setting the crystal speed. You should be able to use a lesser documented call to force the proper crystal frequency:



Code:


CAN1.Init(500000, 8);

That line would init with the assumption of an 8Mhz clock instead. Replace the call to CAN1.begin with that line instead and it will set the crystal frequency too.


----------



## JWardell

96s46p said:


> Actually it is a totally different connector, 26pins?





fast_like_electric said:


> Right, and it's that way for all Model 3's built in 2019 - not just export.


Yikes, Tesla you are making our lives harder! 
Well I'm hoping someone can confirm CAN is still on the same wires, or probe things out.
Or maybe they are adding the other two networks there for our convenience


----------



## fast_like_electric

JWardell said:


> Yikes, Tesla you are making our lives harder!
> Well I'm hoping someone can confirm CAN is still on the same wires, or probe things out.
> Or maybe they are adding the other two networks there for our convenience


@96s46p has added the pinout to the spreadsheet. No changes in wire color or function, just position of the ground moved from pin 20 to 26.

There are no new CAN networks on the revised connector, unfortunately.


----------



## amund7

96s46p said:


> And doesn't look like it is in the sumitomo catalog. Added to spreadsheet.


I have no clue how you figure these things out, but I can confirm that your wiring is correct for CAN+ and CAN-. I've got a connection now, with the can crocodile sniffing those wires. Scan My Tesla test version almost works, shows some moving gauges on the screen, but can dump doesn't work, but at least there's a connection, so I can start debugging!


----------



## JWardell

amund7 said:


> I have no clue how you figure these things out, but I can confirm that your wiring is correct for CAN+ and CAN-. I've got a connection now, with the can crocodile sniffing those wires. Scan My Tesla test version almost works, shows some moving gauges on the screen, but can dump doesn't work, but at least there's a connection, so I can start debugging!


Isn't it much more fun now that you have your own car to play with?


----------



## 96s46p

amund7 said:


> I have no clue how you figure these things out, but I can confirm that your wiring is correct for CAN+ and CAN-. I've got a connection now, with the can crocodile sniffing those wires. Scan My Tesla test version almost works, shows some moving gauges on the screen, but can dump doesn't work, but at least there's a connection, so I can start debugging!


Are the wires the same on both connectors or is it like the 20-pin where some wires are only on the console side?


----------



## amund7

JWardell said:


> Isn't it much more fun now that you have your own car to play with?


Yeah, but it's too much fun to drive it, can't sit down in front of a computer


----------



## rmn

We have made the wire harness with the 20 pin connector and a standard OBD female cable. Following the pinout on the spreadsheet. If anyone is interested in testing it, I can send it, just PM me. @JWardell @b0n3z










About the 26 pin connector for 2019 models, does anyone know which connector is it?


----------



## Collin80

Question for anyone who has done captures on a Model 3 - Do you do so in "listen only" mode? I ask because we tried to use an ESP32 to capture traffic and it does work but will cause odd things to happen in the car if it is not in listen only mode. In normal mode the charging system doesn't really want to work. So, I have to wonder whether it is a problem with the capture hardware or something about the way the car works. I've noticed in captures that frames with ID 0 show up. While it is valid to send frames with ID 0 it is not very common. That seems like an error of some sort.


----------



## fast_like_electric

Collin80 said:


> Question for anyone who has done captures on a Model 3 - Do you do so in "listen only" mode? I ask because we tried to use an ESP32 to capture traffic and it does work but will cause odd things to happen in the car if it is not in listen only mode. In normal mode the charging system doesn't really want to work. So, I have to wonder whether it is a problem with the capture hardware or something about the way the car works. I've noticed in captures that frames with ID 0 show up. While it is valid to send frames with ID 0 it is not very common. That seems like an error of some sort.


I've done captures in both active and listen-only modes - no weird behavior, and there should not be. The main Vehicle CAN bus on this car is very busy, and the intermingling of shorter frames (less than 8 bytes) makes it hard on low cost CAN solutions to keep up. There should not be anything sent on ID 0x000.

I would expect slower hardware to not keep up, and some messages may be missed. Typically no harm, and whether you are informed by the tool of overruns will likely depend. Other odd behavior could certainly be possible with less than ideal sniffers. Some well documented products will detail a max bus load at each speed which they support. Need a pretty good hardware/software setup to capture everything without filtering.

It may take some feedback from the group to determine what works best. I can say that the professional Vector or Kvaser CAN products which are designed for this have no issue.


----------



## 96s46p

fast_like_electric said:


> I've done captures in both active and listen-only modes - no weird behavior, and there should not be. The main Vehicle CAN bus on this car is very busy, and the intermingling of shorter frames (less than 8 bytes) makes it hard on low cost CAN solutions to keep up. There should not be anything sent on ID 0x000.
> 
> I would expect slower hardware to not keep up, and some messages may be missed. Typically no harm, and whether you are informed by the tool of overruns will likely depend. Other odd behavior could certainly be possible with less than ideal sniffers. Some well documented products will detail a max bus load at each speed which they support. Need a pretty good hardware/software setup to capture everything without filtering.
> 
> It may take some feedback from the group to determine what works best. I can say that the professional Vector or Kvaser CAN products which are designed for this have no issue.


My $5 lawicel adapter is offended.


----------



## Kayt183

I'm draw differences in the 2018 and 2019 X930 Connector.
X930 Connector
Also i'm looking for log file of Can bus from moment when car is in the deep sleep and waking up and ready to drive in about 2-5 minutes long. Need to find alert and DTC matrix codes.


----------



## Model3MadHacker

I have my can logger working now, and logged some full throttle runs last night in my P3D-. I'm still on the old firmware, so my files should be a good reference for comparison when we get the 6% performance updates firmware.

For those of you sharing your can logs, are you wiping out your VIN number and other data that is specific to your car?

I'm a unix guy and prefer python these days, so I'm probably not doing things the way the rest of you are. My can capture device is a beaglebone black with a cellular/can cape from Nimble Link ( https://nimbelink.com/products/skywire-beaglebone-black-cape/ ) . Using it I can connect to the car via an LTE modem on the Nimble Link cape and capture can data when I'm not even in the car. If anyone wants more info on this setup, I am happy to help, it's not cheap but I had these parts lying around as we use them for monitoring systems that I develop for water and wastewater applications.

I did a quick test with the data I captured and was able to view the odometer. So cool!

If anyone is interested in how to get real values using python, I use the unpack function from the struct module:

>>> miles = unpack('i','\x4b\xea\x3a\x01')
>>> miles[0] * .000621371
12824.030545993

I'm also going on a 1000+ mile trip tomorrow, and I know there is no way to log the whole trip, too much data, but if there are any specific values I should capture on a long trip to help, let me know and I can filter and log them.


----------



## Collin80

Model3MadHacker said:


> I have my can logger working now, and logged some full throttle runs last night in my P3D-. I'm still on the old firmware, so my files should be a good reference for comparison when we get the 6% performance updates firmware.
> 
> I'm also going on a 1000+ mile trip tomorrow, and I know there is no way to log the whole trip, too much data, but if there are any specific values I should capture on a long trip to help, let me know and I can filter and log them.


Awesome! I like to collect captures so if/when you feel like sharing some logs I'm game. Yes, your VIN number is in the clear in the logs. If that bothers you then filter away the ID for that. I can't think of much else in the data that is all that sensitive. Who cares if other people know the options you have in your car? There is the possibility that your GPS coordinates are in there somewhere. The Chevy Volt does send your GPS coords over CAN all the time so a capture from that can trace where someone is at. But, I don't have any proof that Tesla does this.

Really, CAN isn't too large of a link to capture for long periods but you certainly would not want to do so over LTE. If you could get a local connection of some sort you could capture 1000 miles worth of CAN data. It might be a couple of gigabytes but that's nothing these days. Some data would be interesting long term. I'd like to see pack voltage and temperature over time. I'd also find long term data about power usage vs distance and such to be interesting. If you are going over 1000 miles then you are probably super charging and some captures of that would be cool.


----------



## 96s46p

Collin80 said:


> There is the possibility that your GPS coordinates are in there somewhere. The Chevy Volt does send your GPS coords over CAN all the time so a capture from that can trace where someone is at. But, I don't have any proof that Tesla does this.


Yes you do it's on the chassis can sheet


----------



## Kayt183

I can't quite figure out how to decipher the data in the table. When u16 is specified, for example 23 9E bytes, I count 0x9E23(HEX) = 40483 (DEC), and when u10 is specified, how to count? For example ID212 "Isolation resistance kOhm u10 SB 19 scale 1" I have the 3 and 4 bytes 60 0F = 01100000 00001111 (bin) and the 10 bits from 3th 00000 00001 = 1kOhm or 00001 00000 = 32kOhm? It seems to me too low value is obtained in both cases.
Connect Charger controller at the table. It's 5 seconds sending can data and go to sleep. This have next IDs:
21D, 23D, 25D, 31E, 41D, 50E, 53E, 5FE, 73D, 75D.
Charger Controller


----------



## fast_like_electric

Kayt183 said:


> I can't quite figure out how to decipher the data in the table. When u16 is specified, for example 23 9E bytes, I count 0x9E23(HEX) = 40483 (DEC), and when u10 is specified, how to count? For example ID212 "Isolation resistance kOhm u10 SB 19 scale 1" I have the 3 and 4 bytes 60 0F = 01100000 00001111 (bin) and the 10 bits from 3th 00000 00001 = 1kOhm or 00001 00000 = 32kOhm? It seems to me too low value is obtained in both cases.
> Connect Charger controller at the table. It's 5 seconds sending can data and go to sleep. This have next IDs:
> 21D, 23D, 25D, 31E, 41D, 50E, 53E, 5FE, 73D, 75D.
> Charger Controller


For the isolation resistance, there is an error in the scaling detailed in the spreadsheet. Should be 1 bit = 10K Ohms to match up. Range of 0 to 10.23 M Ohm. That is what aligns with real world measurements, and the video which shows the CAN signals.

That signal is probably not a super popular one to monitor - not easily checked by most. Do know that if it goes too low (HV isolation compromised), the pyro fuse will be blown. That's also possible under certain crash scenarios and/or contactor faults.


----------



## Model3MadHacker

Collin80 said:


> Awesome! I like to collect captures so if/when you feel like sharing some logs I'm game. Yes, your VIN number is in the clear in the logs. If that bothers you then filter away the ID for that. I can't think of much else in the data that is all that sensitive. Who cares if other people know the options you have in your car? There is the possibility that your GPS coordinates are in there somewhere. The Chevy Volt does send your GPS coords over CAN all the time so a capture from that can trace where someone is at. But, I don't have any proof that Tesla does this.
> 
> Really, CAN isn't too large of a link to capture for long periods but you certainly would not want to do so over LTE. If you could get a local connection of some sort you could capture 1000 miles worth of CAN data. It might be a couple of gigabytes but that's nothing these days. Some data would be interesting long term. I'd like to see pack voltage and temperature over time. I'd also find long term data about power usage vs distance and such to be interesting. If you are going over 1000 miles then you are probably super charging and some captures of that would be cool.


I got a good capture yesterday, our first segment was about 250 miles, starting from 100% charge. The log is almost four gigs, and includes the first two full supercharger sessions. It stopped just after we plugged into the third supercharger, and my pc battery was dead so I couldn't restart the logging. I need to preprocess it and filter out my VIN, but I should have it available sometime this weekend for you to look at. For my first two segments, I wasn't driving too fast and was around 98% efficient.


----------



## pavankp

rmn said:


> We have made the wire harness with the 20 pin connector and a standard OBD female cable. Following the pinout on the spreadsheet. If anyone is interested in testing it, I can send it, just PM me.


I would love to buy one from you and test this. I am unable to send a PM, probably because I haven't made enough posts here. Please PM me the details if you can. Thanks.


----------



## 96s46p

Has anyone noticed any changes in 0x352 since the range update?


----------



## Model3MadHacker

I'm interested to know how you guys figured out all the details that are currently known codes. It's amazon how much detail is in some of the info like 7ff where it shows everything from glass roof to exterior color. I know there are still allot of codes that we need to figure out, and honestly I don't know where to start to help figure them out. I have been looking at the data with SavvyCan, and I'm still figuring out this tool.

One thing I noticed is that in code 0x132, ChargeHoursRemaining132 is 4095Min. Does that mean we aren't interpreting that data right?


----------



## Roci

Here's my value, and I'm at a lower SOC of 48.6%, but it still says 4095Min. Perhaps this is a placeholder until you plug in to the charger and then it updates accordingly?








Question about captures: anybody know of a format that can be saved from SavvyCan that can also be read by CANBus Analyzer? My captures are all in GVRET .csv format, but I can't get them to open in CANBus Analyzer.


----------



## Model3MadHacker

I guess I answered my own question by re-reading this thread and looking closely at all the pictures / videos....


----------



## Model3MadHacker

I've been going through the video on Page 11 of this thread about model 3 secret signals making a document listing all the names of the different things that can be monitored and when he drills down on a CAN signal, I'm listing what that CAN id represents, along with sample data. He scrolls through rather quickly sometimes and his camera goes out of focus alot, so there's still allot missing. I'll add to this as I have time over the next few days, but this should us match up the CAN signals from the Tesla Diagnostic software to what we are finding on the BUS and hopefully decode some more signals. I need to go listen to the video a few more times and add all the details. I'm attaching a txt of my current progress, if anyone wants to add more to it, pease do... It would be nice to see which of these we could match up to our current known can codes. Some of the entries for VCLEFT and right should be easy to figure out by pulling door handles and stuff like that. I would assume those codes are on the chassis bus.


----------



## Perscitus

rmn said:


> We have made the wire harness with the 20 pin connector and a standard OBD female cable. Following the pinout on the spreadsheet. If anyone is interested in testing it, I can send it, just PM me. @JWardell @b0n3z


I have started a 'Conversation' with you a few days ago, since traditional PM seems disabled.
Also interested in testing. Please see your profile, conversation area.


----------



## Ingineer

fast_like_electric said:


> For the isolation resistance, there is an error in the scaling detailed in the spreadsheet. Should be 1 bit = 10K Ohms to match up. Range of 0 to 10.23 M Ohm. That is what aligns with real world measurements, and the video which shows the CAN signals.
> 
> That signal is probably not a super popular one to monitor - not easily checked by most. Do know that if it goes too low (HV isolation compromised), the pyro fuse will be blown. That's also possible under certain crash scenarios and/or contactor faults.


FYI: The Pyro is not blown if isolation resistance goes too low. There is a hardware (and software) overcurrent system, and the pyro system is faster than any thermal fuse to blow when there is an overcurrent fault, and will not nuisance-trip over time like a conventional thermal fuse. Model 3 has some interesting failure modes that S/X don't; if you were to open contactors or blow the pyro and the drive unit was at sufficiently high RPM, the back EMF will generate dangerously high voltages. The net result is almost certainly a fireball in the SiCFET inverter. So Tesla will never open contactors or blow the Pyro unless there is a serious issue. Airbag deployment is one of those conditions where the safety of occupants and first-responders is deemed more important than protecting the inverter.


----------



## Collin80

Roci said:


> Here's my value, and I'm at a lower SOC of 48.6%, but it still says 4095Min. Perhaps this is a placeholder until you plug in to the charger and then it updates accordingly?
> View attachment 23053
> 
> Question about captures: anybody know of a format that can be saved from SavvyCan that can also be read by CANBus Analyzer? My captures are all in GVRET .csv format, but I can't get them to open in CANBus Analyzer.


Well, there's so many CAN programs out there that I'm not 100% sure which program you are talking about. Unfortunately it looks like many apps are called CANBus Analyzer. I've tried to support all sorts of formats both for saving and loading but not all loadable formats can be saved. If you can point me to the actual program you are trying to send to then I'll work on getting an export format that it can read. I know that it tends to be good to be able to use a range of programs so I don't have any problem trying to support any export format people need so that they can use a range of products and use whatever works best for the task at hand.

On an only slightly related note:
Model3MadHacker had allowed me preview access to the large logs taken. I have found that SavvyCAN cannot load a log file with 90 million CAN frames. And, yes, the big log file really is just about that big. It turns out QT is built around some signed 32 bit variables even on a 64 bit system so you cannot create an array (QVector) over 2GB in size. I broke the file into three pieces and I can load those - 30 million frames each. This might be as much data as anyone wants to play with all at once anyway. The program works OK at 30 million frames loaded but you will wait a while for it to load. I'm investigating my options for breaking the 2GB limit for loaded frames. So, I guess the moral of the story is to capture for only a few hours per log file. I just added support for both capture types that M2MH has so the bleeding edge source version of SC can directly read them. But, I hope to tomorrow filter out the VIN frames and post them all in GVRET format which you could read in SavvyCAN, Excel, or anything that supports CSV files. At the least you can take the logs in that format and re-output them as something else if you need to. There are a few other things I need to fix up or add to source then I'll create another binary.


----------



## 96s46p

Collin80 said:


> Well, there's so many CAN programs out there that I'm not 100% sure which program you are talking about. Unfortunately it looks like many apps are called CANBus Analyzer. I've tried to support all sorts of formats both for saving and loading but not all loadable formats can be saved. If you can point me to the actual program you are trying to send to then I'll work on getting an export format that it can read. I know that it tends to be good to be able to use a range of programs so I don't have any problem trying to support any export format people need so that they can use a range of products and use whatever works best for the task at hand.


It is linked in the first post with the other resources.


----------



## Roci

Collin80 said:


> I've tried to support all sorts of formats both for saving and loading but not all loadable formats can be saved.


It is the CANalyzer .ASC format, like the captures that @JWardell has posted, which can be loaded but not saved by SC. I do like using both tools to work with these captures, and it's really awesome you and @amund7 have provided these wonderful tools for free and with open source, which is a huge enabler for those of us who don't have access to the expensive Vector software and hardware.


----------



## fast_like_electric

96s46p said:


> Has anyone noticed any changes in 0x352 since the range update?


Most of the Model 3 fleet is still on firmware 50.6 (pre-Sentry mode). The latest 2019.7.11 gets the faster super-charging (and keyfob summon). I don't believe it has been announced yet what version will have the performance and range update - just that it will be addressed with a series of upcoming updates later this month (March 2019).

Yes, ID 0x352 will be interesting to take a look from a battery availability/range standpoint (are they shrinking/changing the buffer, etc). 0x336 as well, regarding max motor performance.


----------



## JWardell

I'm back from freezing my butt off in Iceland, and have a lot to catch up on here, so please give me a few days to crawl through everything and analyze all the new info.

Apparently I star in @Jack Rickard 's new video, where he managed to reverse engineer a wonderfully embarrassing photo of me. I won't have the chance to watch it till tonight or tomorrow, but here it is:


----------



## Bokonon

fast_like_electric said:


> Yes, ID 0x352 will be interesting to take a look from a battery availability/range standpoint (are they shrinking/ch the buffer). 0x336 as well, regarding max motor performance.


Agreed. FYI, some (but not all, apparently) LR RWD vehicles on 2019.5.15 are reporting a bump in rated range immediately after updating. If anyone with LR RWD and the ability to capture has received this firmware already, it would be interesting to see whether 0x352 (or any other values that might affect range calculation) have changed. I'd also be curious whether there are any differences in a LR RWD vehicle that reported a range increase on 2019.5.15 versus one that did not.

My suspicion is that 0x352 has *not* changed for LR RWD in 2019.5.15, and that the additional rated range comes from a reduction in the range calculation's rated-efficiency constant (i.e. the same ~240 Wh/mi that LR RWD vehicles show on the energy screen, rather than the ~250-251 Wh/mi that AWD/Performance vehicles show, and that result in 310 miles of rated range at 100% SoC). But it would be helpful if we could confirm or refute the "buffer reduction" hypothesis through the CAN data directly.


----------



## Kayt183

Model3MadHacker said:


> I've been going through the video on Page 11 of this thread about model 3 secret signals making a document listing all the names of the different things that can be monitored and when he drills down on a CAN signal, I'm listing what that CAN id represents, along with sample data.


I also looked at the video carefully, trying to match the signals, but I didn't finish it. Made only with regard to BMS. Added to the file founded a few items at the CC, CMP. Unrecognized signals end in " _ ". Also i confirm CP_sensorData (?)
I'm think ID 320 is a BMS_alert_Matrix, but it's useless without list of alerts. Every alert need only 1 bit. I can make video of factory mode on the Model X or Model S, but now we have not Model 3 in the factory mode:-(



Ingineer said:


> FYI: The Pyro is not blown if isolation resistance goes too low. There is a hardware (and software) overcurrent system, and the pyro system is faster than any thermal fuse to blow when there is an overcurrent fault, and will not nuisance-trip over time like a conventional thermal fuse. Model 3 has some interesting failure modes that S/X don't; if you were to open contactors or blow the pyro and the drive unit was at sufficiently high RPM, the back EMF will generate dangerously high voltages. The net result is almost certainly a fireball in the SiCFET inverter. So Tesla will never open contactors or blow the Pyro unless there is a serious issue. Airbag deployment is one of those conditions where the safety of occupants and first-responders is deemed more important than protecting the inverter.


Can you comment my can data from the previous page, i' have a very little Isolation resistance or thought wrong?


----------



## JWardell

Bokonon said:


> Agreed. FYI, some (but not all, apparently) LR RWD vehicles on 2019.5.15 are reporting a bump in rated range immediately after updating. If anyone with LR RWD and the ability to capture has received this firmware already, it would be interesting to see whether 0x352 (or any other values that might affect range calculation) have changed. I'd also be curious whether there are any differences in a LR RWD vehicle that reported a range increase on 2019.5.15 versus one that did not.
> 
> My suspicion is that 0x352 has *not* changed for LR RWD in 2019.5.15, and that the additional rated range comes from a reduction in the range calculation's rated-efficiency constant (i.e. the same ~240 Wh/mi that LR RWD vehicles show on the energy screen, rather than the ~250-251 Wh/mi that AWD/Performance vehicles show, and that result in 310 miles of rated range at 100% SoC). But it would be helpful if we could confirm or refute the "buffer reduction" hypothesis through the CAN data directly.


I should have the chance to make some new recordings this week, and I'm still waiting for an update. I will be looking closely at capacities and torque.


----------



## Collin80

Here are some of the captures that Model3MadHacker was gracious enough to capture and allow to be shared (after the VIN number frames were erased).

www.savvycan.com/LargeModel3Captures.zip

Yes, that's 276 megabytes so it might take a while to download. This is not all of the logs but I didn't have time to try to process them all tonight. Still, in this one zip you get over 30 million CAN frames so it might keep people busy for a bit. They're all in CANalyzer Vector ASC format so they should load in the CANBus Analyzer tool too. But, I'm not in Windows and haven't been able to check for sure. And, I have no idea what happens if you load a 30 million frame ASC file into your software of choice. All I can say is SavvyCAN can do it. But, that's a lot of frames to load all at once!

I added output of CANalyzer ASC format to SavvyCAN (obviously) but there isn't likely to be a binary release for a bit as I add a few more things and fix more stuff. In the meantime it is checked into GIT (WIP branch) if anyone feels like compiling it. If you have a very recent version of QT installed (QT 5.11 or higher) you can compile it without any other dependency but you do need to know how to get a C++ compiler and QT installed first.


----------



## fast_like_electric

Collin80 said:


> Here are some of the captures that Model3MadHacker was gracious enough to capture and allow to be shared (after the VIN number frames were erased).


@Model3MadHacker
Many thanks for sharing the logs. Going under the assumption that the decoding is right, looks like you have the Performance Model 3 and 18" wheels/tires? For your full throttle run, looks like about a 0-60 time of 3.9 sec. Tesla states 3.2 sec, but I'm not clear what wheels/tires (probably 20") and SOC (probably 100%).

Related, do you know what firmware version you were running when you did the logs?


----------



## Roci

@Model3MadHacker Kudos!

Likewise I am contributing a capture, of my AWD (non-P) full throttle run at 90% SOC, on software version 2018.50.6. Google Drive Link

Also I've found what I believe is the front motor power signals at ID 0x2E5, here are the front & rear power levels together during my two 0-60+ runs:









Peak numbers are 327 kW combined front and rear, which seems really high when compared to the rated specs on Wikipedia, although this peak is only reached for a brief moment. The raw torque got up to 331 NM, which seems low, so I'm thinking that is only measuring the rear motor?


----------



## fast_like_electric

Roci said:


> @Model3MadHacker Kudos!
> 
> Likewise I am contributing a capture, of my AWD (non-P) full throttle run at 90% SOC, on software version 2018.50.6. Google Drive Link


Looks like you are a bit closer to rated specs at that temperature / soc / tires. 0-60 of about 4.7 sec, 4.5 sec being currently advertised. Tires also 18" (assuming correct decode), so SOC is likely the biggest factor. A log at 100% SOC would be nice to have to compare.

Also, for max rated power (frame 0x336), we now have 3 vehicles spec'd...


Code:


Vehicle:   Drive / Regen
--------------------------
LR RWD:   235 kW / 60 kW
LR AWD:   270 kW / 77 kW
Perf AWD: 375 kW / 77 kW

Clearly that CAN message is electrical power, so apply your favorite scale factor of 80-90% effeciency to get mechanical kW, and multiply by 1.34 to get total drive motor HP. That's advertised, use the other CAN messages for actual power consumed and torque.


----------



## b0n3z

Looks like Tesla is changing the diagnostics connector at the back or FleetCarma is mistaken. I'm not sure why Tesla would change it. Maybe they are just getting confused by the Sumitomo 6098-5629 blue female connector found to also work. If anyone has a picture of this blue connector from Tesla - please take some pics and attach it here. I wish FleetCarma would have included a pic for both in the instructions (PDF):

Model 3 check fro blue cable


----------



## 96s46p

b0n3z said:


> Looks like Tesla is changing the diagnostics connector


Yes
https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-209033

But did those geniuses really post a 250mb PDF?


----------



## JWardell

Collin80 said:


> Here are some of the captures that Model3MadHacker was gracious enough to capture and allow to be shared (after the VIN number frames were erased).
> 
> www.savvycan.com/LargeModel3Captures.zip
> 
> Yes, that's 276 megabytes so it might take a while to download. This is not all of the logs but I didn't have time to try to process them all tonight. Still, in this one zip you get over 30 million CAN frames so it might keep people busy for a bit. They're all in CANalyzer Vector ASC format so they should load in the CANBus Analyzer tool too. But, I'm not in Windows and haven't been able to check for sure. And, I have no idea what happens if you load a 30 million frame ASC file into your software of choice. All I can say is SavvyCAN can do it. But, that's a lot of frames to load all at once!
> 
> I added output of CANalyzer ASC format to SavvyCAN (obviously) but there isn't likely to be a binary release for a bit as I add a few more things and fix more stuff. In the meantime it is checked into GIT (WIP branch) if anyone feels like compiling it. If you have a very recent version of QT installed (QT 5.11 or higher) you can compile it without any other dependency but you do need to know how to get a C++ compiler and QT installed first.





Roci said:


> @Model3MadHacker Kudos!
> 
> Likewise I am contributing a capture, of my AWD (non-P) full throttle run at 90% SOC, on software version 2018.50.6. Google Drive Link
> 
> Also I've found what I believe is the front motor power signals at ID 0x2E5, here are the front & rear power levels together during my two 0-60+ runs:
> 
> View attachment 23137
> 
> Peak numbers are 327 kW combined front and rear, which seems really high when compared to the rated specs on Wikipedia, although this peak is only reached for a brief moment. The raw torque got up to 331 NM, which seems low, so I'm thinking that is only measuring the rear motor?


Thanks for posting these! I've looked through them quickly for now, and I juts updated my spreadsheet with 0x2E5 duplicating 0x266 and updated notes for 0x336.

I am going to search for some other signals in there but hopefully some others can help, because 1000ms power data stinks. Need to figure out what other messages are new, and hopefully 10ms torque etc

Edit sorry it seems @amund7 's CANbusAnalyzer has an issue and can't read traces from Model3MadHacker/ @Collin80


----------



## JWardell

Found it!!

2e5 has a 7F offset from 266, so I'm looking for signals about that far off from rear inverter messages.

0x1D4 appears to have front torque, and decodes the same as Model S!


----------



## JWardell

Spreadsheet and DBC file have been updated with the two new front drive messages, but I'm sure there are more.


----------



## Roci

fast_like_electric said:


> Tires also 18" (assuming correct decode), so SOC is likely the biggest factor. A log at 100% SOC would be nice to have to compare.


Yes this is with 18" tires, in fact all of the values at 0x7FF are decoded correctly including drive train type, exterior color, autopilot options, etc. Pretty cool you guys figured that stuff out! I will try to get a run at 100% SOC next time I charge, but for now I have another one at 78%. I'm trying to investigate how and when the power and torque drops off due to low SOC, so I'd like to get captures at around 50% and 30% as well. This one at 78% seems to have produced almost the exact same torque as when I ran it at 90%, but the overall power achieved was 15 kW less, so I'm curious if the 0-60 time is any worse.
Capture of Full Throttle at 78% SOC

Also here are some short charging sessions. The first is a full supercharging session, but only 20 minutes and with a low obtained power of 20 kW due to being at 68% SOC when I started (I was mainly trying to warm up the battery for the 0-60 run!). One thing interesting though is that near the beginning the supercharging session failed and I had to restart, so may be something interesting in there. The second is charging from my home HPWC at 40 amps with a somewhat cold battery, it's only 4 minutes.
Capture of Supercharging Session
Capture of HPWC Charging


----------



## Collin80

JWardell said:


> Edit sorry it seems @amund7 's CANbusAnalyzer has an issue and can't read traces from Model3MadHacker/ @Collin80


It could be my fault. I tried to output in a format like what CANAnalyzer outputs and I can save then load and have it work but maybe i'm loading a bit more permissively than his program does. He'll have to tell me whether the problem is on my end or his. I can tweak the output format a bit if I'm doing something too out of spec for that file format.


----------



## Collin80

0x401 really does encode the cell voltages of all 96 series groups of cells. I made a DBC message with all the signals (actually, all 108 cell voltages though all of them past 96 are not used). Below is a link to the chunk of DBC that implements that. It could be inserted into your master DBC if you want.

DBC Chunk with Cell Voltages


----------



## fast_like_electric

Just received the 2019.5.15 with the supposed range update. Did a 0-60 MPH run just before the update as well. Summary below...

- No change in 0x352 nominal full pack energy or energy buffer: 76.1 kWh and 3.4 kWh respectively
- No change in 0x292 SOC numbers (had charged to 81% before and after update)
- No change in 0x336 drive inverter rating, 235kW (drive) / 60 kW (regen)
- No change in acceleration 0 to 60 MPH, measured 5.6 seconds at 81% SOC (LR RWD, 19" wheels/tires, 40 F, 2100 mi odo, climate off)

What did change is the displayed mileage on the car, phone app, and Tesla API parameters. Phone displayed 239 mi before update, and displayed 250 mi after. Car was unplugged during the update, which took 30 minutes.

So it is pretty clear that 5.15 does not dip into the battery more to get more range. Still unknown if some unnecessary load is being turned off for better efficiency, or if this is just a rescale of the displayed mileage estimate vs. % charge.

Also appears that 5.15 does not have the 5.1->5.0 sec performance update, or at least there is no improvement visible at 81% SOC. Perhaps others can try at higher SOC before and after, such as 90% or better.


----------



## Collin80

Here's the rest of Model3MadHacker's huge 90 million frame capture. 428MB compressed. If you put all three pieces together the file would be over 4GB.

Parts 2 and 3


----------



## 96s46p

Possibly relevant: https://teslaownersonline.com/threads/12v-now-always-on.11738/


----------



## JWardell

Collin80 said:


> 0x401 really does encode the cell voltages of all 96 series groups of cells. I made a DBC message with all the signals (actually, all 108 cell voltages though all of them past 96 are not used). Below is a link to the chunk of DBC that implements that. It could be inserted into your master DBC if you want.
> 
> DBC Chunk with Cell Voltages


Thank you! You'll notice 401 has been missing from mine, just because I have been putting off manually creating all of those items in the DBC 



fast_like_electric said:


> Just received the 2019.5.15 with the supposed range update. Did a 0-60 MPH run just before the update as well. Summary below...
> 
> - No change in 0x352 nominal full pack energy or energy buffer: 76.1 kWh and 3.4 kWh respectively
> - No change in 0x292 SOC numbers (had charged to 81% before and after update)
> - No change in 0x336 drive inverter rating, 235kW (drive) / 60 kW (regen)
> - No change in acceleration 0 to 60 MPH, measured 5.6 seconds at 81% SOC (LR RWD, 19" wheels/tires, 40 F, 2100 mi odo, climate off)
> 
> What did change is the displayed mileage on the car, phone app, and Tesla API parameters. Phone displayed 239 mi before update, and displayed 250 mi after. Car was unplugged during the update, which took 30 minutes.
> 
> So it is pretty clear that 5.15 does not dip into the battery more to get more range. Still unknown if some unnecessary load is being turned off for better efficiency, or if this is just a rescale of the displayed mileage estimate vs. % charge.
> 
> Also appears that 5.15 does not have the 5.1->5.0 sec performance update, or at least there is no improvement visible at 81% SOC. Perhaps others can try at higher SOC before and after, such as 90% or better.


Awesome, I was planning to do the same when/if I get the update. So clearly nothing is uncorked, they're just changing the estimate value, sadly.


----------



## Roci

Collin80 said:


> It could be my fault. I tried to output in a format like what CANAnalyzer outputs and I can save then load and have it work but maybe i'm loading a bit more permissively than his program does. He'll have to tell me whether the problem is on my end or his. I can tweak the output format a bit if I'm doing something too out of spec for that file format.


I was able to get one of your captures to work by tweaking the format to more closely resemble the other Vector captures we've seen. I reformatted the capture date/time slightly, shortened the timestamps and added the extra values at the end of the line. Length and BitCount I just copy/paste the same data, they don't seem to matter to CANBus Analyzer. The ID at the end of the line is the decimal version of the ID. Here's an example with the top & first frame of the P3D full throttle capture:


Code:


date Mon Mar 11 7:37:31.896 pm 2019
base hex  timestamps absolute
no internal event logging
// version 11.0.0
 671.92944 0  103             Rx   d 8 22 33 00 00 14 21 21 42  Length = 239925 BitCount = 124 ID = 259


----------



## Bokonon

Roci said:


> I was able to get one of your captures to work by tweaking the format to more closely resemble the other Vector captures we've seen. I reformatted the capture date/time slightly, shortened the timestamps and added the extra values at the end of the line. Length and BitCount I just copy/paste the same data, they don't seem to matter to CANBus Analyzer. The ID at the end of the line is the decimal version of the ID. Here's an example with the top & first frame of the P3D full throttle capture:
> 
> 
> Code:
> 
> 
> date Mon Mar 11 7:37:31.896 pm 2019
> base hex  timestamps absolute
> no internal event logging
> // version 11.0.0
> 671.92944 0  103             Rx   d 8 22 33 00 00 14 21 21 42  Length = 239925 BitCount = 124 ID = 259


Thanks for writing this up. I've been meaning to test the new AWD captures with CANBusAnalyzer and should finally have some time to do so tonight. If/when I run into the issue loading the ASC files, I'll see what I can do to fix it.


----------



## 96s46p

Hoping to see a Model 3 SR+ log soon, don't be shy new owners.


----------



## 0x6d33

I finally made some progress getting an Android app to display CAN bus information.










Here is an example of what it looks like. I'll post a video of it if people are interested.

There's still a lot of work to do in order to make this app usable.


----------



## bearbu

My Model 3 long range (China version) will be coming in end March. Will take to some photos of the diagnostic connector and see if there is any different.

Btw, Is there is any information of the control signals from steering wheel? Is it also going thru CAN? (It was Chasis CAN [CAN6] from Model S/X).

Thanks
BearBu


----------



## parc2407

I`ll get my SR+ on the 20th. Anyone in the Quebec city area who would want read a trace from my car. I`m really curious about the battery size 

Else if someone in Canada could send me a cable for a few days and whatever board they use, I`d send it back


----------



## Kayt183

bearbu said:


> My Model 3 long range (China version) will be coming in end March. Will take to some photos of the diagnostic connector and see if there is any different.
> 
> Btw, Is there is any information of the control signals from steering wheel? Is it also going thru CAN? (It was Chasis CAN [CAN6] from Model S/X).
> 
> Thanks
> BearBu


Steering wheel connected to the left body controller via Can and LIN buses. It's connected only to the Left Body Controller, this Can bus does not come out from the controller.


----------



## JWardell

0x6d33 said:


> I finally made some progress getting an Android app to display CAN bus information.
> 
> View attachment 23236
> 
> 
> Here is an example of what it looks like. I'll post a video of it if people are interested.
> 
> There's still a lot of work to do in order to make this app usable.


Awesome! How are you connecting it to the car?



bearbu said:


> My Model 3 long range (China version) will be coming in end March. Will take to some photos of the diagnostic connector and see if there is any different.
> 
> Btw, Is there is any information of the control signals from steering wheel? Is it also going thru CAN? (It was Chasis CAN [CAN6] from Model S/X).
> 
> Thanks
> BearBu


Yes, you can read all the steering buttons and inputs and wheel angle. VCleft spits out every switch it reads


----------



## 0x6d33

JWardell said:


> Awesome! How are you connecting it to the car?


I'm using a ESP32 with a CAN bus transceiver. It send the CAN bus data via Bluetooth to the phone.


----------



## rmn

b0n3z said:


> Looks like Tesla is changing the diagnostics connector at the back or FleetCarma is mistaken. I'm not sure why Tesla would change it. Maybe they are just getting confused by the Sumitomo 6098-5629 blue female connector found to also work. If anyone has a picture of this blue connector from Tesla - please take some pics and attach it here. I wish FleetCarma would have included a pic for both in the instructions (PDF):
> 
> Model 3 check fro blue cable


See attached some pictures from @amund7 I can make this cable as well, I have sent a few 20 pin wire harness with OBD connector to a few users to test, and will do the same with the 26 pin. Once we can confirm they work well, we can find a way to distribute them, any ideas?


----------



## JWardell

rmn said:


> See attached some pictures from @amund7 I can make this cable as well, I have sent a few 20 pin wire harness with OBD connector to a few users to test, and will do the same with the 26 pin. Once we can confirm they work well, we can find a way to distribute them, any ideas?
> 
> View attachment 23247
> 
> 
> View attachment 23248


I would hope that one of the existing aftermarket stores would be interesting in selling these, maybe EVTV ( @Jack Rickard or @Collin80 ) or @EVTuning

I would considering bundling them with a product, but with two connectors now that leans toward selling separately, and really I think building a open wireless solution is better

This harness plus the EVTV ESP32 module basically gets you there but it's somewhat expensive and bulky. 
I might work on (or more hopefully work with someone) to create a much smaller lower cost plug-in wireless module. But I'm getting well ahead of myself


----------



## 96s46p

0x6d33 said:


> I'm using a ESP32 with a CAN bus transceiver. It send the CAN bus data via Bluetooth to the phone.


Link to your github project?


----------



## 96s46p

bearbu said:


> My Model 3 long range (China version) will be coming in end March. Will take to some photos of the diagnostic connector and see if there is any different.
> 
> Btw, Is there is any information of the control signals from steering wheel? Is it also going thru CAN? (It was Chasis CAN [CAN6] from Model S/X).
> 
> Thanks
> BearBu


It will be interesting to see if it really has the OBD port and 1 or 2 can buses on it.


----------



## fast_like_electric

96s46p said:


> It will be interesting to see if it really has the OBD port and 1 or 2 can buses on it.


There is just one CAN bus at that OBDII connector - on the standard pins 6 and 14. It is a dedicated bus connected to the left body module, and there are some other signals as well. But this is not bringing out the Vehicle CAN bus. However, will be interesting to see what functionality is available though. Presumption is it only does OBDII things and not down the road messaging like is going on via the Vehicle CAN bus, but will need someone to verify.


----------



## 0x6d33

96s46p said:


> Link to your github project?


I want to fix somethings before I put it on Github.

It is largely based off amund7's Scan My Tesla but with support for DBC files.


----------



## 96s46p

0x6d33 said:


> I want to fix somethings before I put it on Github.
> 
> It is largely based off amund7's Scan My Tesla but with support for DBC files.


nice, what about the esp32 part?


----------



## Model3MadHacker

I had a chance to process the big log last night, it is 250megs compresses, about 1.5 gigs uncompressed. I put it into the raw format that CANBUS-Analyzer uses. CANBus Analyzer seems to have no problems with the big file. I had tried the file that Colin80 uploaded, but the software wouldn't play it like it does the raw file. It's really cool seeing the odometer running up and the batteries going down.

I'm not seeing any torque readings from the front motor, perhaps that's an issue with CANBus-analyzer. I'm still waiting for it to get to the first supercharger to watch the batteries fill back up.

Here is a link to the big file: https://www.dropbox.com/s/44hcit4jab3gokd/biglog.zip?dl=0


----------



## Model3MadHacker

I finally got to the supercharger session, and it's interesting that the odometer goes to 0 while supercharging. The supercharger session was at about 22000 kilometers on the odometer.


----------



## Jack Rickard

Got an interesting update from Tesla this week. The good news is you can now press the left steering wheel thumbwheel and cause fart noises to emit from the passenger seat. The wife will love that one.
The bad news is message 0x411 was removed from the vehicle bus. That's where we get individual cell voltages at the moment.

To confirm, I did a SavvyCAN file compare between a capture of my Model 3 driver that got the update, and a wreck in the shop that did not. We picked up a few and lost a few.


----------



## JWardell

0x6d33 said:


> I want to fix somethings before I put it on Github.
> 
> It is largely based off amund7's Scan My Tesla but with support for DBC files.


Will it work with EVTV's ESP32? I would be thrilled to test them together...



Jack Rickard said:


> Got an interesting update from Tesla this week. The good news is you can now press the left steering wheel thumbwheel and cause fart noises to emit from the passenger seat. The wife will love that one.
> The bad news is message 0x411 was removed from the vehicle bus. That's where we get individual cell voltages at the moment.
> 
> To confirm, I did a SavvyCAN file compare between a capture of my Model 3 driver that got the update, and a wreck in the shop that did not. We picked up a few and lost a few.


I noticed they were missing from my latest logs of 5.2 as well, I just thought maybe it was because of my short drive.
Perhaps they are being transmitted on a different bus or moved to a different ID
This is why I want to compare logs between versions easily


----------



## fast_like_electric

Jack Rickard said:


> Got an interesting update from Tesla this week. The good news is you can now press the left steering wheel thumbwheel and cause fart noises to emit from the passenger seat. The wife will love that one.
> The bad news is message 0x411 was removed from the vehicle bus. That's where we get individual cell voltages at the moment.
> 
> To confirm, I did a SavvyCAN file compare between a capture of my Model 3 driver that got the update, and a wreck in the shop that did not. We picked up a few and lost a few.


Confirmed on my end as well. 0x401 (battery cell group voltage) has been removed. 0x712 (some sort of cell area temperature) frames as well. Was is 2018.50.6, not in 2019.5.15.


----------



## fast_like_electric

JWardell said:


> I noticed they were missing from my latest logs of 5.2 as well, I just thought maybe it was because of my short drive.
> Perhaps they are being transmitted on a different bus or moved to a different ID
> This is why I want to compare logs between versions easily


They are probably still on the charge port bus (between the BMS and the charge port controller). When last checked, they were on that bus at a higher repetition rate, an indication that these were more for communication with the supercharger than for anything else on the car. Someone who logs traces on the chargeport bus may want to check with the lastest firmware.


----------



## fast_like_electric

JWardell said:


> Perhaps they are being transmitted on a different bus or moved to a different ID


Looks like those two IDs are just gone, and no new IDs.

So the question is, was it just that some debug finally got turned off, or is Telsa reacting negatively to that info being mentioned on this thread or elsewhere? I hope that is not the case. It doesn't seem like the trigger would be from Jack's comentary and program since 5.15 firmware was in the bag before that video was posted, unless there had been other side comms. But it does seem like an interesting coincidence that as soon as that capability was shown, it was immeadiately removed.

Not to mention the recent change of the 20->26 pin console junction connector, with no new functions. Were they not happy about what Fleet Carma (and now others) had done with that convenient tap-in point? Does make you wonder.


----------



## fast_like_electric

Model3MadHacker said:


> I finally got to the supercharger session, and it's interesting that the odometer goes to 0 while supercharging. The supercharger session was at about 22000 kilometers on the odometer.


It does that when the drive inverter is mainly offline and not needed for driving. If you take a look some of the other logs, you'll see similar behavior as the car becomes authorized to drive, and that message ID starts to come in. You will also will see this during AC charging. Nothing to do with Super Charging per say - just that the inverter isn't interested in sharing that info until authorized and online.


----------



## JWardell

fast_like_electric said:


> Looks like those two IDs are just gone, and no new IDs.
> 
> So the question is, was it just that some debug finally got turned off, or is Telsa reacting negatively to that info being mentioned on this thread or elsewhere? I hope that is not the case. It doesn't seem like the trigger would be from Jack's comentary and program since 5.15 firmware was in the bag before that video was posted, unless there had been other side comms. But it does seem like an interesting coincidence that as soon as that capability was shown, it was immeadiately removed.
> 
> Not to mention the recent change of the 20->26 pin console junction connector, with no new functions. Were they not happy about what Fleet Carma (and now others) had done with that convenient tap-in point? Does make you wonder.


I highly doubt it has anything to do with us. Especially considering I added 401 to my documents this week and this software is a month old. And I will chalk up the connector change to include additional wires for future vehicles, for all the unannounced features that will be added to the Y's console


----------



## fast_like_electric

JWardell said:


> I highly doubt it has anything to do with us. Especially considering I added 401 to my documents this week and this software is a month old. And I will chalk up the connector change to include additional wires for future vehicles, for all the unannounced features that will be added to the Y's console


The 0x401 (and 0x712) info has been mentioned in this thread for awhile (since the early decoding), so it could have been realized by someone that those battery debug messages shouldn't have been left there and they were gutted.

Just somewhat bizarre that Jack writes a program to display that 0x401 info with his setup, does a video that describes it in detail, and then the messages are removed from the Vehicle bus. Bad luck at least for sure. Too bad, as those were handy messages on that easy to access bus.


----------



## JWardell

There are plenty of other debug messages still there, and maybe there are many more eyes on Jack's video, but again, the software is a month old.
Plus the same message has always existed on model S, and several utilities are available to read it for years, and Tesla has not had an issue with it.
No need for all the paranoia, there are a dozen more sensible explanations.


----------



## fast_like_electric

JWardell said:


> There are plenty of other debug messages still there, and maybe there are many more eyes on Jack's video, but again, the software is a month old.
> Plus the same message has always existed on model S, and several utilities are available to read it for years, and Tesla has not had an issue with it.
> No need for all the paranoia, there are a dozen more sensible explanations.


I would like to think so to, but even @Jack Rickard thinks its fishy...

http://evtv.me/2019/03/teslappointment/

Read toward the end, he has a lot of other points in there about the Y reveal that I have to agree with too.


----------



## Collin80

fast_like_electric said:


> I would like to think so to, but even @Jack Rickard thinks its fishy...
> 
> http://evtv.me/2019/03/teslappointment/


It's hard to say but it was nearly worthless anyway. On the charge port that message comes in at 10ms interval. At that rate you can get the whole pack about 3 times per second. PERFECT. On the vehicle bus it was once every second which means you get a full pack update every 36 seconds! Believe me, watching this transpire on a full throttle run is heart wrenching. I can literally see as cells sag but the speed of update is so slow that if it starts at group 0 with full voltage you can watch the car accelerate and maybe by group 10 it has sagged a lot then by group 25 it has sprung back and by group 31 you're back essentially to rest voltage. If someone were using 0x401 to build up the state of the cells they'd get a very weird effect where some cell reading are from the full throttle run, some are during regen, and some are at rest. It makes the data really useless because even during charging you'd have some cells lagging 30 seconds behind the reading of other cells. This only works during no activity or very light charging. Otherwise you've got readings from entirely different points in time. They might have removed it out of embarrassment. Though, they could have done like the Model S and drop the time to 100ms which would give you a full pack reading every 3.6 seconds. That's better for sure; not perfect but pretty good.


----------



## 0x6d33

JWardell said:


> Will it work with EVTV's ESP32? I would be thrilled to test them together...


I don't have an EVTV ESP32 so my guess is it won't work. If someone could point me to some documentation on how EVTV's ESP32 bluetooth messages are formatted, I can likely make it work.

Currently, the app assumes the first 3 hex characters are the CAN ID and the rest are DATA. Each CAN message is separated by a new line.

EDIT: My code is now on Github: https://github.com/sbirss/ScanMyModel3


----------



## 96s46p

Collin80 said:


> This only works during no activity or very light charging. Otherwise you've got readings from entirely different points in time.


Valid, but still useful to keep an eye on cell group balancing and any large deviations.


----------



## Collin80

0x6d33 said:


> I don't have an EVTV ESP32 so my guess is it won't work. If someone could point me to some documentation on how EVTV's ESP32 bluetooth messages are formatted, I can likely make it work.
> 
> Currently, the app assumes the first 3 hex characters are the CAN ID and the rest are DATA. Each CAN message is separated by a new line.
> 
> EDIT: My code is now on Github: https://github.com/sbirss/ScanMyModel3


The EVTV ESP32 is basically a ESP32 WROOM placed onto an Arduino Due form factor board and with extra CAN hardware. It has the transceiver onboard so you can use the built-in CAN hardware on the ESP32 and it also has a MCP2517FD module so you get a second CAN bus that supports CAN-FD. I used the same dual serial port USB to serial chip as was used on some of the official dev boards. So, basically it works the same as the official ESP32 dev boards and you can program it as such.

And, hey, you even used my CAN library meant for the EVTV ESP32 so I think odds are pretty good your sketch would work on it. So, that's a bonus. Speaking of my CAN library. It has had some troubles at higher bus loads but I recently fixed up the built-in CAN code to work a lot better so if you update to the newest code on GITHub your CAN should work better. Before it would successfully get around 1900 frames per second but the Model 3 runs near 2400 frames per second. So, you'd be randomly missing 400-500 frames per second.


----------



## JWardell

Collin80 said:


> It's hard to say but it was nearly worthless anyway. On the charge port that message comes in at 10ms interval. At that rate you can get the whole pack about 3 times per second. PERFECT. On the vehicle bus it was once every second which means you get a full pack update every 36 seconds! Believe me, watching this transpire on a full throttle run is heart wrenching. I can literally see as cells sag but the speed of update is so slow that if it starts at group 0 with full voltage you can watch the car accelerate and maybe by group 10 it has sagged a lot then by group 25 it has sprung back and by group 31 you're back essentially to rest voltage. If someone were using 0x401 to build up the state of the cells they'd get a very weird effect where some cell reading are from the full throttle run, some are during regen, and some are at rest. It makes the data really useless because even during charging you'd have some cells lagging 30 seconds behind the reading of other cells. This only works during no activity or very light charging. Otherwise you've got readings from entirely different points in time. They might have removed it out of embarrassment. Though, they could have done like the Model S and drop the time to 100ms which would give you a full pack reading every 3.6 seconds. That's better for sure; not perfect but pretty good.


As you say, the message is basically useless. That's why it's removed. The network is already in dangerous utilization territory, and as they add features they will have to remove messages that are not useful.



Collin80 said:


> The EVTV ESP32 is basically a ESP32 WROOM placed onto an Arduino Due form factor board and with extra CAN hardware. It has the transceiver onboard so you can use the built-in CAN hardware on the ESP32 and it also has a MCP2517FD module so you get a second CAN bus that supports CAN-FD. I used the same dual serial port USB to serial chip as was used on some of the official dev boards. So, basically it works the same as the official ESP32 dev boards and you can program it as such.
> 
> And, hey, you even used my CAN library meant for the EVTV ESP32 so I think odds are pretty good your sketch would work on it. So, that's a bonus. Speaking of my CAN library. It has had some troubles at higher bus loads but I recently fixed up the built-in CAN code to work a lot better so if you update to the newest code on GITHub your CAN should work better. Before it would successfully get around 1900 frames per second but the Model 3 runs near 2400 frames per second. So, you'd be randomly missing 400-500 frames per second.


Do you mind compiling a release so I can try testing the ESP32 in the next few days? Already having some trouble getting comparison and graphic working with log files, not sure what the issue is, but would be helpful to have fixes in there


----------



## PNWmisty

Do any of you have any visibility as to how many possible positions the Throttle Position Sensor has? Also, can you see how many of them result in a "neutral" position, ie. between throttle and regen braking? I'm just curious how this is all mapped. It seems like the answer to my second question might be difficult to pin down since it probably varies for each use case, so no need to go out of your way to take logs specific to this, but I am curious how much resolution exists to begin with.


----------



## fast_like_electric

PNWmisty said:


> Do any of you have any visibility as to how many possible positions the Throttle Position Sensor has? Also, can you see how many of them result in a "neutral" position, ie. between throttle and regen braking? I'm just curious how this is all mapped. It seems like the answer to my second question might be difficult to pin down since it probably varies for each use case, so no need to go out of your way to take logs specific to this, but I am curious how much resolution exists to begin with.


After conversion from a voltage to a numeric value, accelerator pedal position is an 8 bit value, which results in 256 unique pedal positions, or 0.4% steps.

Regarding the neutral power/regen tipping point you mention, that's not really how it works. Pressing the accelerator pedal and holding it at a given position will result in the vehicle speeding up and settling at a particular speed based on incline and other loading factors. That accelerator position is what I believe you are referring to as a neutral position - push more and you draw more power and accelerate to a new speed, let go and you regen and slow. It is a very dynamic kind of thing based on lots of factors - there is no fixed point.


----------



## PNWmisty

fast_like_electric said:


> After conversion from a voltage to a numeric value, accelerator pedal position is an 8 bit value, which results in 256 unique pedal positions, or 0.4% steps.


Excellent, thank you!



> Regarding the neutral power/regen tipping point you mention, that's not really how it works. Pressing the accelerator pedal and holding it at a given position will result in the vehicle speeding up and settling at a particular speed based on incline and other loading factors. That accelerator position is what I believe you are referring to as a neutral position - push more and you draw more power and accelerate to a new speed, let go and you regen and slow. It is a very dynamic kind of thing based on lots of factors - there is no fixed point.


When I'm on a flat road and depress the accelerator a certain amount and hold it there, it will stabilize at a certain speed as you say. Then if I let off a tiny bit, it will stabilize at a slightly slower speed. Then if I let off a bit more it will start coasting down, the power graph in the upper left corner will show neither regen or power. That is the point I'm talking about. It sounds like, with only 256 values to play with, for both regen and acceleration, only one value would be designated as the "neutral" point and, yes, that point does move around. At higher speeds, that point appears to be closer to the floor.


----------



## mcv

bearbu said:


> My Model 3 long range (China version) will be coming in end March. Will take to some photos of the diagnostic connector and see if there is any different.
> 
> Btw, Is there is any information of the control signals from steering wheel? Is it also going thru CAN? (It was Chasis CAN [CAN6] from Model S/X).
> 
> Thanks
> BearBu


Taken from my long range dual motor China version model3


----------



## JWardell

mcv said:


> Taken from my long range dual motor China version model3
> View attachment 23443
> View attachment 23442


Great to see China gets OBD connectors, thanks for sharing! The real question is what signals are present there


----------



## fast_like_electric

JWardell said:


> Great to see China gets OBD connectors, thanks for sharing! The real question is what signals are present there


The signals/connections are known, just a special dedicated CAN OBD2 bus on the usual pins 6 and 14, and some other pins for power and LIN. That was detailed a many posts up I believe, and it is in the Tesla wiring info as well. What is unknown is what messaging is possible at that connector.

If someone in China had a ODB2 reader or other ODB2 accessory to plug in and check operation, that would confirm if standard J1979 messaging (speed, RPM, throttle position, etc) is present there. A CAN trace would be nice as well, but the educated guess it is that dedicated OBD2 bus is quiet until requests come in from a connected device. Need someone to verify though.


----------



## Collin80

JWardell said:


> Do you mind compiling a release so I can try testing the ESP32 in the next few days? Already having some trouble getting comparison and graphic working with log files, not sure what the issue is, but would be helpful to have fixes in there


Over at www.savvycan.com there are now new versions for each OS plus a new ESP32RET updater that you can use to update ESP32 devices to use the newer changes to the CAN library. It still isn't perfect but it will capture almost all frames at the full bus load on either CAN bus (if you have an EVTV board or just the built-in bus if you don't).

Edit: Oh, I think I fixed the CANAlyzer ASC output too. It should be correct now. I didn't add the extra stuff at the end of lines but I reformatted the date to be in the correct format and offset all the timestamps to no longer be at 1.5 billion seconds like it was. This should make the time stamps short enough now.


----------



## JWardell

Collin80 said:


> Over at www.savvycan.com there are now new versions for each OS plus a new ESP32RET updater that you can use to update ESP32 devices to use the newer changes to the CAN library. It still isn't perfect but it will capture almost all frames at the full bus load on either CAN bus (if you have an EVTV board or just the built-in bus if you don't).
> 
> Edit: Oh, I think I fixed the CANAlyzer ASC output too. It should be correct now. I didn't add the extra stuff at the end of lines but I reformatted the date to be in the correct format and offset all the timestamps to no longer be at 1.5 billion seconds like it was. This should make the time stamps short enough now.


I'll give it a try. I sent a big email to Jack a few hours ago about my tests and issues, I don't have your email so hopefully he will forward it to you.


----------



## Roci

JWardell said:


> I'll give it a try. I sent a big email to Jack a few hours ago about my tests and issues, I don't have your email so hopefully he will forward it to you.


Are you having trouble with the ESP32 doing can captures? I could share a very simple firmware that re-transmits all frames over tcp/ip via WiFi and then I use PuTTY on a laptop in the car to log it to a file. At that point I use scripts to convert those logs either to GVRET, ASC or decode the data into a CSV.


----------



## 0x6d33

Collin80 said:


> The EVTV ESP32 is basically a ESP32 WROOM placed onto an Arduino Due form factor board and with extra CAN hardware. It has the transceiver onboard so you can use the built-in CAN hardware on the ESP32 and it also has a MCP2517FD module so you get a second CAN bus that supports CAN-FD. I used the same dual serial port USB to serial chip as was used on some of the official dev boards. So, basically it works the same as the official ESP32 dev boards and you can program it as such.
> 
> And, hey, you even used my CAN library meant for the EVTV ESP32 so I think odds are pretty good your sketch would work on it. So, that's a bonus. Speaking of my CAN library. It has had some troubles at higher bus loads but I recently fixed up the built-in CAN code to work a lot better so if you update to the newest code on GITHub your CAN should work better. Before it would successfully get around 1900 frames per second but the Model 3 runs near 2400 frames per second. So, you'd be randomly missing 400-500 frames per second.


Thanks for your reply. I'm actually experiencing some of the CAN messages not showing up, or at least, taking awhile to show up. However, I suspect this is more likely an App issue.

I'll try you new library sometime this week and let you know how it goes. In addition, I'll explore supporting the EVTV ESP32 on the app.


----------



## mcv

fast_like_electric said:


> The signals/connections are known, just a special dedicated CAN OBD2 bus on the usual pins 6 and 14, and some other pins for power and LIN. That was detailed a many posts up I believe, and it is in the Tesla wiring info as well. What is unknown is what messaging is possible at that connector.
> 
> If someone in China had a ODB2 reader or other ODB2 accessory to plug in and check operation, that would confirm if standard J1979 messaging (speed, RPM, throttle position, etc) is present there. A CAN trace would be nice as well, but the educated guess it is that dedicated OBD2 bus is quiet until requests come in from a connected device. Need someone to verify though.


Unfortunately I do not have any OBD2 reader. I have tried connecting an OBD hud to the port, and it can not get any info.


----------



## fast_like_electric

mcv said:


> Unfortunately I do not have any OBD2 reader. I have tried connecting an OBD hud to the port, and it can not get any info.


Using the HUD was a good test, that would send similar J1979 PID requests as a scan tool.

It will probably take someone with the ability to do a CAN log during such communication to see what is going on with that port. Suppose it is possible that the firmware is not fully implemented in the vehicle yet to support the new connector.

There is some sort of legislation that says China vehicles must have this port, but I'm not clear what functionality must be provided to comply. But perhaps something other than US based SAE J1979, which is the OBD2 protocol.


----------



## JWardell

After 33 days of being stuck on a beta firmware, I finally got another update...to another beta.
Tesla might be smart here, because I'm obviously not releasing any logs or discussing details of things_ I_ find while on beta firmware. In case you're wondering why there haven't been captures in a while.

But that doesn't stop the rest of you. We had a couple of useful AWD captures a week or so ago but I do hope more of you start capturing short runs, and I will excitedly look through those logs for what's new.

I've also been working with @Collin80 who has made some awesome improvements to SavvyCAN. It is probably the best tool for folks to use to make captures. Let me know if anyone has questions on its use.

Now if you'll excuse me I have a lot of new features to test over the next few days...


----------



## fast_like_electric

I am waiting for the 2019.8.2 with the performance increase (roll-out appears slow), but I will immediately do another 0-60 MPH run to see if any measurable change in acceleration. I'll also look at the messages to see if there are changes in the peak power and torque output (expected), as well as check if the Drive Inverter and BMS limits have also been correspondingly increased (expected).

Some things that would be good to have from the group...

- 0-60 MPH runs at differing state of charge (under the same conditions).
- Any logs from the LEMR (limited edition Mid-Range)
- Any Logs from Standard
- Any Logs from the Standard Plus

I'm expecting the last two may only come from enterprising individuals, due to the recent connector change.


----------



## EVTuning

JWardell said:


> I would hope that one of the existing aftermarket stores would be interesting in selling these, maybe EVTV ( @Jack Rickard or @Collin80 ) or @EVTuning
> 
> I would considering bundling them with a product, but with two connectors now that leans toward selling separately, and really I think building a open wireless solution is better
> 
> This harness plus the EVTV ESP32 module basically gets you there but it's somewhat expensive and bulky.
> I might work on (or more hopefully work with someone) to create a much smaller lower cost plug-in wireless module. But I'm getting well ahead of myself


@JWardell and and @rmn if you guys want to collaborate together with EV Tuning. Josh is local to me he could do a demonstration video for Rich Rebuilds youtube channel and EV Tuning would be interested in carrying the products. This should get you infront of 430k sets of eyes and help the community as a whole. If you're interested send me an email [email protected]


----------



## 0x6d33

@Collin80 @JWardell

I spent most of yesterday trying to add bluetooth support to the EVTV ESP32. Unfortunately, I ran into a few problems. The first problem was adding the bluetooth libraries made the program size larger than the ROM size for app0. For some reason the Arduino IDE partitions the ROM for two apps (app0 and app1). This issue can be mitigated by removing app1 from the partition table (esp32/board.txt) and allocating all the space to app0.

At this point I was able to add the bluetooth libraries and transmit the CAN data via bluetooth. My next issue is approximately 10 to 20 secs after powering on the EPS32 and connecting to it via the mobile app, the ESP32 crashes with this error message "Guru Meditation Error: Core 0 panic'ed (LoadProhibited)." Quickly googling did not yield any solutions. My current theory is somehow instruction memory is getting overwritten thus causing the ESP32 to crash.

One possible alternative is to connecting to the ESP32 through WiFi instead of bluetooth. This gives several advantages. The first being WiFi has a significantly larger bandwidth than bluetooth. Lastly, iOS devices would likely be able to work. The major downside is the ESP32 would have to be setup as an AP. As a result, your phone would lose connection to the internet when connected to the ESP32.

I also tried @Collin80 updated CAN library and it seems to be working better. In addition, I've updated the mobile app to store the DBC file internally instead requiring the user to put it in the downloads folder.

https://github.com/sbirss/ScanMyModel3


----------



## JWardell

0x6d33 said:


> @Collin80 @JWardell
> 
> I spent most of yesterday trying to add bluetooth support to the EVTV ESP32. Unfortunately, I ran into a few problems. The first problem was adding the bluetooth libraries made the program size larger than the ROM size for app0. For some reason the Arduino IDE partitions the ROM for two apps (app0 and app1). This issue can be mitigated by removing app1 from the partition table (esp32/board.txt) and allocating all the space to app0.
> 
> At this point I was able to add the bluetooth libraries and transmit the CAN data via bluetooth. My next issue is approximately 10 to 20 secs after powering on the EPS32 and connecting to it via the mobile app, the ESP32 crashes with this error message "Guru Meditation Error: Core 0 panic'ed (LoadProhibited)." Quickly googling did not yield any solutions. My current theory is somehow instruction memory is getting overwritten thus causing the ESP32 to crash.
> 
> One possible alternative is to connecting to the ESP32 through WiFi instead of bluetooth. This gives several advantages. The first being WiFi has a significantly larger bandwidth than bluetooth. Lastly, iOS devices would likely be able to work. The major downside is the ESP32 would have to be setup as an AP. As a result, your phone would lose connection to the internet when connected to the ESP32.
> 
> I also tried @Collin80 updated CAN library and it seems to be working better. In addition, I've updated the mobile app to store the DBC file internally instead requiring the user to put it in the downloads folder.
> 
> https://github.com/sbirss/ScanMyModel3


Thanks for the help.
It will certainly need to create an ad hoc wifi network, and this is preferable for bandwidth and compatibility as you said.
Some phones can tell the wifi has no network and can continue to use cellular.
Of course it's just as easy to use a second phone or tablet if you really want to stay connected all the time. It would be nice to have a small tablet mounted near the display all the time showing lots of gauges and numbers.


----------



## Roci

JWardell said:


> Thanks for the help.
> It will certainly need to create an ad hoc wifi network, and this is preferable for bandwidth and compatibility as you said.
> Some phones can tell the wifi has no network and can continue to use cellular.
> Of course it's just as easy to use a second phone or tablet if you really want to stay connected all the time. It would be nice to have a small tablet mounted near the display all the time showing lots of gauges and numbers.


I have been working on a project where CAN data is available via both Bluetooth and WiFi, depending on how you choose to connect to the wireless module. With the ESP32 you can't use both at the exact same time because WiFi & BT share the same hardware radio, but you can switch between them during the same session. For example, you can use the Bluetooth connection to visualize data in real time with the custom Tesla-specific mobile apps or OBD2 diagnostic apps like Torque Pro. Then, if you want to dig deeper, you can fire up a laptop and connect to the WiFi access point and use SavvyCan or another tool to capture to disk or probe for CAN messages in real time. My thinking behind this is that it'd be great to have a semi-permanently installed board that can have multiple functions without having to re-flash firmware or re-wire things behind the center console.

What I'm not sure on right now is whether to release a version that does this in a standalone fashion, or to try to combine it with @Collin80 's ESP32RET or @0x6d33 's firmware. A single consolidated project for our community does sound quite appealing!


----------



## JWardell

Roci said:


> I have been working on a project where CAN data is available via both Bluetooth and WiFi, depending on how you choose to connect to the wireless module. With the ESP32 you can't use both at the exact same time because WiFi & BT share the same hardware radio, but you can switch between them during the same session. For example, you can use the Bluetooth connection to visualize data in real time with the custom Tesla-specific mobile apps or OBD2 diagnostic apps like Torque Pro. Then, if you want to dig deeper, you can fire up a laptop and connect to the WiFi access point and use SavvyCan or another tool to capture to disk or probe for CAN messages in real time. My thinking behind this is that it'd be great to have a semi-permanently installed board that can have multiple functions without having to re-flash firmware or re-wire things behind the center console.
> 
> What I'm not sure on right now is whether to release a version that does this in a standalone fashion, or to try to combine it with @Collin80 's ESP32RET or @0x6d33 's firmware. A single consolidated project for our community does sound quite appealing!


I love your idea. The best way to go about it is to remain flexible. Perhaps allow for anyone to add support for various products both on the input and output side. ESP32RET is available now, but over time we might be able to design something smaller and less expensive, or maybe someone can port some other existing can hardware. Likewise it would be great to use with multiple outputs, phone apps, laptop, or hardware display. The best way is whatever design that allows multiple people to work on different pieces as their time and talent allows for.


----------



## 0x6d33

Roci said:


> With the ESP32 you can't use both at the exact same time because WiFi & BT share the same hardware radio, but you can switch between them during the same session.


Perhaps this is why my program is crashing. When I was in school I made a project with an ESP32 that used both Bluetooth and WiFi. However, the major difference was the ESP32 was set up as a Bluetooth beacon which acts very differently than a Bluetooth serial port. I'll do some more experimenting to see if I can get it to work.



Roci said:


> A single consolidated project for our community does sound quite appealing!


Agreed!


----------



## 0x6d33

JWardell said:


> ESP32RET is available now, but over time we might be able to design something smaller and less expensive


Currently I am using an ESP32 dev board connected to a CAN transceiver (SN65HVD233). The dev board is about $10 and the SN65HVD233 breakout board was also around $10. However, the SN65HVD233 is significantly cheaper when bought in bulk. When put together, the total volume is about 1/3 to 1/4 the size of the EVTV ESP32.


----------



## Roci

0x6d33 said:


> Perhaps this is why my program is crashing. When I was in school I made a project with an ESP32 that used both Bluetooth and WiFi. However, the major difference was the ESP32 was set up as a Bluetooth beacon which acts very differently than a Bluetooth serial port. I'll do some more experimenting to see if I can get it to work.


Yes I recommend trying BLE, it is working well for me. The spec allows for a BLE message every 7.5 ms, each with a size of 120 bytes, so that's about 125 kbs, which should be enough for viewing data in real-time. To be safe I'm only sending packets every 20 ms right now though and there's no discernible lag from my iOS test app.


0x6d33 said:


> Currently I am using an ESP32 dev board connected to a CAN transceiver (SN65HVD233). The dev board is about $10 and the SN65HVD233 breakout board was also around $10. However, the SN65HVD233 is significantly cheaper when bought in bulk. When put together, the total volume is about 1/3 to 1/4 the size of the EVTV ESP32.


I found this interesting board today, I think it has everything we would need on one tiny board. CAN32 - An ESP32 dev. board with CAN-Bus (V2)


----------



## JWardell

0x6d33 said:


> Currently I am using an ESP32 dev board connected to a CAN transceiver (SN65HVD233). The dev board is about $10 and the SN65HVD233 breakout board was also around $10. However, the SN65HVD233 is significantly cheaper when bought in bulk. When put together, the total volume is about 1/3 to 1/4 the size of the EVTV ESP32.


You have an ESP32 board with hardware CAN? I thought most would need an SPI CAN controller like EVTV's.


----------



## fast_like_electric

JWardell said:


> You have an ESP32 board with hardware CAN? I thought most would need an SPI CAN controller like EVTV's.


The ESP32 has 1 native hardware CAN channel...

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/can.html

Most boards need the transceiver only.

The EVTV one also has a second CANFD interface over SPI.


----------



## 0x6d33

Roci said:


> The spec allows for a BLE message every 7.5 ms, each with a size of 120 bytes, so that's about 125 kbs


I didn't realize the BLE had that much bandwidth. Translating this into CAN messages per second. I am assuming each CAN message is sent as an ASCII string with each message containing 8 bytes of data. 3 chars for the ID 16 for the data and one for the new line yields 20 bytes per message. Therefore, you can send 800 messages per second ( (120 bytes/0.0075 sec)*(1 Message / 20 bytes) ).

This means we can only send a subset of the CAN messages via BLE as the Model 3 is capable of about 2400 message per second. I don't think most users care about seeing every CAN message live therefore, this doesn't seem like a big issue.

Do you plan on sharing your iPhone App? I'd love to give it a spin and even contribute to it. I've done some coding with swift back in school.


----------



## 96s46p

0x6d33 said:


> I didn't realize the BLE had that much bandwidth. Translating this into CAN messages per second. I am assuming each CAN message is sent as an ASCII string with each message containing 8 bytes of data. 3 chars for the ID 16 for the data and one for the new line yields 20 bytes per message. Therefore, you can send 800 messages per second ( (120 bytes/0.0075 sec)*(1 Message / 20 bytes) ).
> 
> This means we can only send a subset of the CAN messages via BLE as the Model 3 is capable of about 2400 message per second. I don't think most users care about seeing every CAN message live therefore, this doesn't seem like a big issue.
> 
> Do you plan on sharing your iPhone App? I'd love to give it a spin and even contribute to it. I've done some coding with swift back in school.


Why would you send it as ascii instead of binary? Also if you can list the message ids you are want and also cache them on esp32 and do not send duplicates you probably have enough bandwidth in most cases.


----------



## 0x6d33

96s46p said:


> Why would you send it as ascii instead of binary? Also if you can list the message ids you are want and also cache them on esp32 and do not send duplicates you probably have enough bandwidth in most cases.


My rationale for ASCII is it's easier to work with since you have comma characters such as a newline. Sending the messages in binary should double the bandwidth. In addition, my rough calculation assumes each message is sending the max amount of data per message.

I like to be pessimistic when it comes to bandwidth and speed calculation.


----------



## fast_like_electric

Roci said:


> Yes I recommend trying BLE, it is working well for me. The spec allows for a BLE message every 7.5 ms, each with a size of 120 bytes, so that's about 125 kbs, which should be enough for viewing data in real-time. To be safe I'm only sending packets every 20 ms right now though and there's no discernible lag from my iOS test app.





0x6d33 said:


> I didn't realize the BLE had that much bandwidth. Translating this into CAN messages per second. I am assuming each CAN message is sent as an ASCII string with each message containing 8 bytes of data. 3 chars for the ID 16 for the data and one for the new line yields 20 bytes per message. Therefore, you can send 800 messages per second ( (120 bytes/0.0075 sec)*(1 Message / 20 bytes) ).


For BLE 4.x, 128kbps is really a best case number, and actual will depend on what you are talking to. If you have control of the design at both BLE ends, you can go that fast. But if you are talking to phones and tablets running Android or IOS, you have limitations imposed based on the OS, and what range of devices you want to support.

Basically there are limits on the polling rate, and number of packets per poll. This page is a bit dated, but talks through some of the points well (for BLE 4.x).

https://punchthrough.com/pt-blog-post/maximizing-ble-throughput-on-ios-and-android/

BLE 5 also has different things to consider, and is generally faster as 255 bytes packets are allowed. But it is my understanding the the ESP32 is only BLE 4.2.

Streaming 500kps CAN (at relatively high bus utilization) without message loss over BLE is not possible without message filtering and/or delta-ing. Convert to ASCII and the math definately does not add up. Just consider the real world Model 3 Vehicle bus condition of about 2500 CAN frames per second (peak is much higher). Also consider that most messages are a full 8 byte frame, and that you need 2 more bytes for the CAN ID. So that gets you 2500 x (8 +2) = 25KB / s (or 200 kbps). The math just doesn't work, even for a best case BLE scenario with no additinal protocol overhead for message framing, etc.

Just some points to consider with a BLE solution. Can be done, but you have to work around the limitations, and understand the compromises.


----------



## JWardell

fast_like_electric said:


> The ESP32 has 1 native hardware CAN channel...
> 
> https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/peripherals/can.html
> 
> Most boards need the transceiver only.
> 
> The EVTV one also has a second CANFD interface over SPI.


Sorry, I always thought the Teensy was the only Arduino with native CAN. Hmm, never expected that of a wireless board! Well, maybe I'll be moving things over to ESP32 then.

As for Bandwidth discussion, I agree that while you might just be able to cram things into Bluetooth, it probably won't work in practice, and certainly not worth a ton of extra effort. I've always planned to have a processor at the connector filtering only the needed messages before transmitting (even if this is wifi). That leaves more cycles for the receiver to do fun things with displays as well.

I'll give a closer look to that board @Roci found. I still need things to be easily used with Arduino, and to live on a planet with 36 hours in the day.


----------



## All About Jake

JWardell said:


> I still need things to be easily used with Arduino


I was just about to post about the CAN32 only to find the last few posts discussing that very board. You shouldn't have any trouble using this with the Arduino IDE if you're comfortable with it. I'd recommend using the ArduinoOTA library to provide the ability to upload new firmware to the ESP32 over WiFi. You can close it all up in the console and never have to connect to it (unless something goes wrong and you need to unbrick it)

Also something like the WifiManager library will provide the ability to automatically connect to your local WiFi network, if available, or broadcast a network if your network is not available (or for initial configuration)

I've done quite a bit with these modules. My Christmas lights are individually addressable RGB LEDs all run off one of these modules. Happy to help.

Is there a supplier for a passthrough harness yet? Was looking at past posts (this thread has gotten pretty long) and it seems my 2018 would use white connectors that might be hard to get?


----------



## Roci

0x6d33 said:


> Do you plan on sharing your iPhone App? I'd love to give it a spin and even contribute to it. I've done some coding with swift back in school.


Well my current testing is simply using the Blynk app which is a free app for iOS & Android. It lets you add widgets to a dashboard and then communicate with them either through the cloud or over Bluetooth. I showed it a little bit in my first post: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-27#post-207282. It was basically a really quick way to get up and running at viewing data, and it does look nice and runs smoothly. The Blynk app has two limitations I do not like though, one being that the app only supports landscape mode, and the second being that the Bluetooth connection must be re-initialized every time you launch the app again.

Currently I am investigating the ELM327 protocol so that I can try to emulate a Bluetooth OBD2 adapter, that way any app such as Torque Pro, OBD Fusion, or DashCommand could be used for both viewing data and also logging data to the cloud over the mobile device's wireless connection.


----------



## rmn

0x6d33 said:


> The dev board is about $10 and the SN65HVD233 breakout board was also around $10. However, the SN65HVD233 is significantly cheaper when bought in bulk.


I actually think this would be a good price-point solution in between EVTV CAN Due board (which is quite expensive) and a protoboard project which requires wiring and soldering and its not compact enough to mount inside the car.

We can source ESP32 and CAN transceivers for a reasonable price since production of those modules is already in place. Then, we can produce this 'assembly' board where the ESP32 and CAN transceiver can be mounted. With a simple board like this and mass production modules like ESP32 and CAN transceivers it is possible to achieve a reasonable production price. The idea is that the board can power the ESP32 and CAN bus transceiver with the 12v and GND cables that come from the tapped wire harness. And also, the CAN_H and CAN_L tapped wires would connect to the CAN BUS transceiver.

Both power and CAN wires could be easily removed in case the wire harness with 20 pins needed to be replaced for the 26 pin. @JWardell @fast_like_electric what do you guys think?












EVTuning said:


> @JWardell and and @rmn if you guys want to collaborate together with EV Tuning.


 I think it would be good to bundle the wire harness with a product that offers the possibility of working with CAN messages. Maybe a sketch like the one above would work.


----------



## 0x6d33

rmn said:


> I actually think this would be a good price-point solution in between EVTV CAN Due board (which is quite expensive) and a protoboard project which requires wiring and soldering and its not compact enough to mount inside the car.
> 
> We can source ESP32 and CAN transceivers for a reasonable price since production of those modules is already in place. Then, we can produce this 'assembly' board where the ESP32 and CAN transceiver can be mounted. With a simple board like this and mass production modules like ESP32 and CAN transceivers it is possible to achieve a reasonable production price. The idea is that the board can power the ESP32 and CAN bus transceiver with the 12v and GND cables that come from the tapped wire harness. And also, the CAN_H and CAN_L tapped wires would connect to the CAN BUS transceiver.
> 
> Both power and CAN wires could be easily removed in case the wire harness with 20 pins needed to be replaced for the 26 pin. @JWardell @fast_like_electric what do you guys think?
> 
> View attachment 24005
> 
> 
> I think it would be good to bundle the wire harness with a product that offers the possibility of working with CAN messages. Maybe a sketch like the one above would work.


Doesn't the wire harness have a 5v wire?

If we are making our own board, it would make more sense to just put the SN65HVD233 directly on it since the breakout boards have a big markup.


----------



## amund7

I had a bit of an EUREKA moment this evening.
I've been struggling a bit with developing Scan My Tesla to support Model 3, I had issues with the response being very slow, and data coming in bursts, making it look horrible and jerky on screen, as well as graphs looking awful, many slower packet never showing in the logs etc.

I thought it was
- can crocodile (inductive sniffer) missing signals/too slow/interfernce/too weak signal
- my wiring being too shaky
- High end OBD2 adapter (OBDLink MX) beeing so overwhelmed by the traffic that everything slows to a bog

So I was thinking we need some exotic hardware like you guys are building. With all the implications that would follow.

I was about to break out my oscilloscope, but had one final crazy test to do first;
As a desperate measure, I tried the app on my girlfriend's phone, which is an older Lenovo running android 7.

Well guess what: It runs perfectly! The updates are so fast they look like a steady 60 fps for all gauges (the app has always been limited upwards to 60 fps per gauges as not to bog down the phone)
So everything is issues with Android 9, perhaps starting on Android 8. Not realizing this until now, as I sold my S and got a new phone in the meantime, so the 2 didn't overlap.

Not sure how to fix it yet, searches and reading migration guides tonight I found nothing. Any tips will be greatly appreciated. Not sure if it's bluetooth buffering, threading priorities or something xamarin/.net specific threading-wise

But that gives the conclusion:
- High-end OBD2 bluetooth hardware works excellently. 500 packets/second on my test today (not sure that can be correct, OBDLink mx says it will give 100 per sec). Probably lower-end OBD2 will also be good enough for on-screen display, and logs with less demand for speed
- Can Crocodile works nicely! No disconnecting of wires, just listening through the insulation. (A ready-made plug&play harness will probably be tidier and easier to install though)


----------



## JWardell

rmn said:


> I actually think this would be a good price-point solution in between EVTV CAN Due board (which is quite expensive) and a protoboard project which requires wiring and soldering and its not compact enough to mount inside the car.
> 
> We can source ESP32 and CAN transceivers for a reasonable price since production of those modules is already in place. Then, we can produce this 'assembly' board where the ESP32 and CAN transceiver can be mounted. With a simple board like this and mass production modules like ESP32 and CAN transceivers it is possible to achieve a reasonable production price. The idea is that the board can power the ESP32 and CAN bus transceiver with the 12v and GND cables that come from the tapped wire harness. And also, the CAN_H and CAN_L tapped wires would connect to the CAN BUS transceiver.
> 
> Both power and CAN wires could be easily removed in case the wire harness with 20 pins needed to be replaced for the 26 pin. @JWardell @fast_like_electric what do you guys think?
> 
> View attachment 24005
> 
> 
> I think it would be good to bundle the wire harness with a product that offers the possibility of working with CAN messages. Maybe a sketch like the one above would work.


We can certainly design a simple inexpensive board, but it would need to be much smaller than this, similar to the Czech example above. The smaller the board, the smaller the enclosure, and the more likely it can be fit inside the panel. I do plan to do that eventually.



amund7 said:


> I had a bit of an EUREKA moment this evening.
> I've been struggling a bit with developing Scan My Tesla to support Model 3, I had issues with the response being very slow, and data coming in bursts, making it look horrible and jerky on screen, as well as graphs looking awful, many slower packet never showing in the logs etc.
> 
> I thought it was
> - can crocodile (inductive sniffer) missing signals/too slow/interfernce/too weak signal
> - my wiring being too shaky
> - High end OBD2 adapter (OBDLink MX) beeing so overwhelmed by the traffic that everything slows to a bog
> 
> So I was thinking we need some exotic hardware like you guys are building. With all the implications that would follow.
> 
> I was about to break out my oscilloscope, but had one final crazy test to do first;
> As a desperate measure, I tried the app on my girlfriend's phone, which is an older Lenovo running android 7.
> 
> Well guess what: It runs perfectly! The updates are so fast they look like a steady 60 fps for all gauges (the app has always been limited upwards to 60 fps per gauges as not to bog down the phone)
> So everything is issues with Android 9, perhaps starting on Android 8. Not realizing this until now, as I sold my S and got a new phone in the meantime, so the 2 didn't overlap.
> 
> Not sure how to fix it yet, searches and reading migration guides tonight I found nothing. Any tips will be greatly appreciated. Not sure if it's bluetooth buffering, threading priorities or something xamarin/.net specific threading-wise
> 
> But that gives the conclusion:
> - High-end OBD2 bluetooth hardware works excellently. 500 packets/second on my test today (not sure that can be correct, OBDLink mx says it will give 100 per sec). Probably lower-end OBD2 will also be good enough for on-screen display, and logs with less demand for speed
> - Can Crocodile works nicely! No disconnecting of wires, just listening through the insulation. (A ready-made plug&play harness will probably be tidier and easier to install though)


Android 
j/k as we tried once before I am happy to test on my cheap Chinese android phone, and I plan to actually get a new cheap android soon, just to get on Google Fi, because my frequent international travel has really created a need for fast data. 
I thought you disappeared completely just because we hadn't seen any canbusanalzyer releases in a while. Glad you have shifted to ScanMyTesla 

I need to find time to get back to work on mine again as well, and I think first step is converting to ESP32.


----------



## 0x6d33

amund7 said:


> I had a bit of an EUREKA moment this evening.
> I've been struggling a bit with developing Scan My Tesla to support Model 3, I had issues with the response being very slow, and data coming in bursts, making it look horrible and jerky on screen, as well as graphs looking awful, many slower packet never showing in the logs etc.
> 
> I thought it was
> - can crocodile (inductive sniffer) missing signals/too slow/interfernce/too weak signal
> - my wiring being too shaky
> - High end OBD2 adapter (OBDLink MX) beeing so overwhelmed by the traffic that everything slows to a bog
> 
> So I was thinking we need some exotic hardware like you guys are building. With all the implications that would follow.
> 
> I was about to break out my oscilloscope, but had one final crazy test to do first;
> As a desperate measure, I tried the app on my girlfriend's phone, which is an older Lenovo running android 7.
> 
> Well guess what: It runs perfectly! The updates are so fast they look like a steady 60 fps for all gauges (the app has always been limited upwards to 60 fps per gauges as not to bog down the phone)
> So everything is issues with Android 9, perhaps starting on Android 8. Not realizing this until now, as I sold my S and got a new phone in the meantime, so the 2 didn't overlap.
> 
> Not sure how to fix it yet, searches and reading migration guides tonight I found nothing. Any tips will be greatly appreciated. Not sure if it's bluetooth buffering, threading priorities or something xamarin/.net specific threading-wise
> 
> But that gives the conclusion:
> - High-end OBD2 bluetooth hardware works excellently. 500 packets/second on my test today (not sure that can be correct, OBDLink mx says it will give 100 per sec). Probably lower-end OBD2 will also be good enough for on-screen display, and logs with less demand for speed
> - Can Crocodile works nicely! No disconnecting of wires, just listening through the insulation. (A ready-made plug&play harness will probably be tidier and easier to install though)


I've been messing around with ScanMyTesla code for a few week now. So far I've been able to add DBC support using your CANBUS-Analyzer code and communicate with my Model 3 via an ESP32. The performance seems to be very good on my Pixel 2 XL. The only real issue I have at the moment is tags don't seem to work so all the CAN messages are stuck in the all tab.

Would you consider adding DBC support in your official app?

https://github.com/sbirss/ScanMyModel3


----------



## amund7

0x6d33 said:


> I've been messing around with ScanMyTesla code for a few week now. So far I've been able to add DBC support using your CANBUS-Analyzer code and communicate with my Model 3 via an ESP32. The performance seems to be very good on my Pixel 2 XL. The only real issue I have at the moment is tags don't seem to work so all the CAN messages are stuck in the all tab.


Have you tried 'factory reset all tabs' + restart app, or delete all app data from settings? Android/visual studio has a strange way of uploading some old data and prefs for the app when you compile/deploy. Also, when you rename or add items, they will only show up in the tabs where they match the stored item name for each tab.



0x6d33 said:


> Would you consider adding DBC support in your official app?
> 
> https://github.com/sbirss/ScanMyModel3


Basically I asked @brianman to use his DBC code for Scan My Tesla 3 monts ago. He is still avoiding the question.

Canbus-Analyzer is also held up because of technical issues between @brianman 's repository and mine, and I need his help to fix it, but he hasn't responded for a month. I hope he's OK actually.


----------



## fast_like_electric

Finally got the 2019.8.3 update last night, which is listed as having the 5% (or so) power update. It is in wide rollout, so everyone should see it soon.

Nothing obvious regarding the max power rating CAN messaging when idle. ID 0x336 (drive inverter rating) didn't change - still reporting 235kW (drive) / 60 kW (regen) for my RWD. Lots of people reporting faster acceleration, will do a 0-60 run soon to compare with prior runs for the actual power numbers (which I imagine will be different).

One thing that did happen after the update is that Chill Mode became enabled, and my Creep Mode setting was also changed. Speed limit mode also got turned on. I'm not sure if is related to the firmware update, or the fact that I caved and bought FSD when it was available for $2K. Anyway, check your preferences after the update. My steering effort preferences were not changed - seems like only settings related to the drive inverter.


----------



## JWardell

fast_like_electric said:


> Finally got the 8.3.1 update last night, which is listed as having the 5% (or so) power update. It is in wide rollout, so everyone should see it soon.
> 
> Nothing obvious regarding the max power rating CAN messaging when idle. ID 0x336 (drive inverter rating) didn't change - still reporting 235kW (drive) / 60 kW (regen) for my RWD. Lots of people reporting faster acceleration, will do a 0-60 run soon to compare with prior runs for the actual power numbers (which I imagine will be different).
> 
> One thing that did happen after the update is that Chill Mode became enabled, and my Creep Mode setting was also changed. Speed limit mode also got turned on. I'm not sure if is related to the firmware update, or the fact that I caved and bought FSD when it was available for $2K. Anyway, check your preferences after the update. My steering effort preferences were not changed - seems like only settings related to the drive inverter.


Yes, I noticed that too, strange that 0x336 us unchanged at 60/235kW for me, but I saw peak power at 0x266 hit 256.5kW now (though I did record a 245 previously, so apparently that limit is not for the inverter). I saw peak torque for 0x108/0x154 increase from 426.7NM/406.3NM to 444.9/419.5 and that's still cold temps and snow tires. Still not sure which of those two torques are accurate, or maybe one is a correction after thermal losses or something. Anyway...4.,2% increase on the first try, also confirmed 0-60 of 4.999sec.


----------



## fast_like_electric

JWardell said:


> Yes, I noticed that too, strange that 0x336 us unchanged at 60/235kW for me, but I saw peak power at 0x266 hit 256.5kW now (though I did record a 245 previously, so apparently that limit is not for the inverter). I saw peak torque for 0x108/0x154 increase from 426.7NM/406.3NM to 444.9/419.5 and that's still cold temps and snow tires. Still not sure which of those two torques are accurate, or maybe one is a correction after thermal losses or something. Anyway...4.,2% increase on the first try, also confirmed 0-60 of 4.999sec.


I also concur regarding the prior max power (2018.50.6 and 2019.5.15) being about 245kW (my highest was 246kW and 81% SOC). So apparently the power ratings in 0x336 is not very meaningful regarding peak power limits, but those values are indeed different for RWD/AWD/Performance.


----------



## bearbu

mcv said:


> Taken from my long range dual motor China version model3
> View attachment 23443
> View attachment 23442


wow! wow! wow!!! I am getting fainted with the different between the Chinese version and the rest!

Btw, I am getting the car in next week and will have intensive work soon


----------



## Roci

I have a new capture from my LR AWD after updating to v2019.8.3. Compared to a capture taken while on v2018.50.6 at the same SOC of 90%, I am seeing a peak power increase of 2.9% as measured by the motors, and a 4.3% increase as measured by the battery. This is even with a slightly colder battery since the first capture was taken immediately after the car came off a 10kW charger.

Also comparing the 0-60 times on the best run of each capture, it has gone from 4.52 to 4.35. I'd say that's a pretty good result, especially considering the ground was wet when I did the new capture.

Another thing I noticed is that some of the 7FF messages seem to have changed. It is saying I have 19" wheels (when I only have 18") and that I have the 50 kWh battery (which previously was decoded as 74 kWh).

Capture_3-29-19_Full_Throttle_90pSOC_v2019.8.3_F.zip


----------



## Flarpl-Jr

rmn said:


> We have made the wire harness with the 20 pin connector and a standard OBD female cable. Following the pinout on the spreadsheet. If anyone is interested in testing it, I can send it, just PM me. @JWardell @b0n3z
> 
> About the 26 pin connector for 2019 models, does anyone know which connector is it?


Hi rmn, PMs appear disabled as well. Do you have an alternate method of contact, or are you on Freenode ##teslamotors?


----------



## Tmo6

0x6d33 said:


> Currently I am using an ESP32 dev board connected to a CAN transceiver (SN65HVD233). The dev board is about $10 and the SN65HVD233 breakout board was also around $10. However, the SN65HVD233 is significantly cheaper when bought in bulk. When put together, the total volume is about 1/3 to 1/4 the size of the EVTV ESP32.


Links for purchase @0x6d33 ? Thanks!


----------



## 0x6d33

Tmo6 said:


> Links for purchase @0x6d33 ? Thanks!


The CAN transceiver can be found here: 

ESP32: 

If you don't have any handy, gets some female to female wires.


----------



## 0x6d33

amund7 said:


> Have you tried 'factory reset all tabs' + restart app, or delete all app data from settings? Android/visual studio has a strange way of uploading some old data and prefs for the app when you compile/deploy. Also, when you rename or add items, they will only show up in the tabs where they match the stored item name for each tab.


I didn't realize you can just copy the message to the tab you want them in. This functionality is working flawlessly. Overall, the app is working really well. I just need to find a good mount for it.


----------



## JWardell

Before I go weeks or months developing my own ESP32 transmitter, does anyone else what to do the same? I'm not even sure it will be all that much different than @Collin80 's EVTV CANDdue board except one channel.

Here is what I want:
-Small and inexpensive module
-Aduino developed
-Published (and maybe crowd-developed) code for transmitter
-ESP32 to ESP32 adhoc wifi transmission of data
-Published data so many other receive projects can use it, hardware display, phone/tablet apps, etc.
-Go ahead and DIY parts and knockoff if you want but:
-Manufacture and sell a plug & play ready to go module for <$100 (actually hoping for ~$50)
-Maybe plugs into additional harness, or better yet pass-through plug integrated into the board itself (would need plastics genius for that part)
-9to18v input
-CAN hardware is hardware transmit disabled out of the box to instill confidence that you can plug and play and not screw anything up (easily hackable though...)

Software needs to figure out:
-ESP32 CAN code, maybe with configurable filters and configurable slower transmit rate
-ESP32 to ESP32 (or other) adhoc wifi with serial data stream
-Protocol to send data and receive some comms
Bonus:
-Allow for multiple transmitters and receivers! (One transmitter on each can bus in different spots, multiple wireless hardware displays, phone apps etc)

I will typically take my natural lead on hardware, but would love help with software.

This is what has been rattling in my brain for many months. But the more complex, the more likely I am to never complete a project. It is MUCH more likely to succeed if many of us work together, as we have proven with the data processing.



0x6d33 said:


> The CAN transceiver can be found here:
> 
> ESP32:
> 
> If you don't have any handy, gets some female to female wires.


I had just started doing my ESP32 research yesterday and was going to research and order boards this week... perfect timing, I just ordered these.

Yes, this does step on EVTV's toes a bit, but Jack has assured me he is good with it and does not want to deal with selling to folks who need support (I don't blame them). I want to target something plug and play and lower priced. Those smart enough to DIY are welcome to buy any solution but also have the info available to roll their own.

What to people think?
This will allow the handful of us to develop our own end use products, but all with a common data source


----------



## Tmo6

JWardell said:


> Before I go weeks or months developing my own ESP32 transmitter, does anyone else what to do the same? I'm not even sure it will be all that much different than @Collin80 's EVTV CANDdue board except one channel.
> 
> Here is what I want:
> -Small and inexpensive module
> -Aduino developed
> -Published (and maybe crowd-developed) code for transmitter
> -ESP32 to ESP32 adhoc wifi transmission of data
> -Published data so many other receive projects can use it, hardware display, phone/tablet apps, etc.
> -Go ahead and DIY parts and knockoff if you want but:
> -Manufacture and sell a plug & play ready to go module for <$100 (actually hoping for ~$50)
> -Maybe plugs into additional harness, or better yet pass-through plug integrated into the board itself (would need plastics genius for that part)
> -9to18v input
> -CAN hardware is hardware transmit disabled out of the box to instill confidence that you can plug and play and not screw anything up (easily hackable though...)
> 
> Software needs to figure out:
> -ESP32 CAN code, maybe with configurable filters and configurable slower transmit rate
> -ESP32 to ESP32 (or other) adhoc wifi with serial data stream
> -Protocol to send data and receive some comms
> Bonus:
> -Allow for multiple transmitters and receivers! (One transmitter on each can bus in different spots, multiple wireless hardware displays, phone apps etc)
> 
> I will typically take my natural lead on hardware, but would love help with software.
> 
> This is what has been rattling in my brain for many months. But the more complex, the more likely I am to never complete a project. It is MUCH more likely to succeed if many of us work together, as we have proven with the data processing.
> 
> I had just started doing my ESP32 research yesterday and was going to research and order boards this week... perfect timing, I just ordered these.
> 
> Yes, this does step on EVTV's toes a bit, but Jack has assured me he is good with it and does not want to deal with selling to folks who need support (I don't blame them). I want to target something plug and play and lower priced. Those smart enough to DIY are welcome to buy any solution but also have the info available to roll their own.
> 
> What to people think?
> This will allow the handful of us to develop our own end use products, but all with a common data source


I'm no developer, but you can count on me to buy whatever hardware and software you develop! 😉


----------



## 0x6d33

JWardell said:


> Before I go weeks or months developing my own ESP32 transmitter, does anyone else what to do the same? I'm not even sure it will be all that much different than @Collin80 's EVTV CANDdue board except one channel.
> 
> Here is what I want:
> -Small and inexpensive module
> -Aduino developed
> -Published (and maybe crowd-developed) code for transmitter
> -ESP32 to ESP32 adhoc wifi transmission of data
> -Published data so many other receive projects can use it, hardware display, phone/tablet apps, etc.
> -Go ahead and DIY parts and knockoff if you want but:
> -Manufacture and sell a plug & play ready to go module for <$100 (actually hoping for ~$50)
> -Maybe plugs into additional harness, or better yet pass-through plug integrated into the board itself (would need plastics genius for that part)
> -9to18v input
> -CAN hardware is hardware transmit disabled out of the box to instill confidence that you can plug and play and not screw anything up (easily hackable though...)
> 
> Software needs to figure out:
> -ESP32 CAN code, maybe with configurable filters and configurable slower transmit rate
> -ESP32 to ESP32 (or other) adhoc wifi with serial data stream
> -Protocol to send data and receive some comms
> Bonus:
> -Allow for multiple transmitters and receivers! (One transmitter on each can bus in different spots, multiple wireless hardware displays, phone apps etc)
> 
> I will typically take my natural lead on hardware, but would love help with software.
> 
> This is what has been rattling in my brain for many months. But the more complex, the more likely I am to never complete a project. It is MUCH more likely to succeed if many of us work together, as we have proven with the data processing.
> 
> I had just started doing my ESP32 research yesterday and was going to research and order boards this week... perfect timing, I just ordered these.
> 
> Yes, this does step on EVTV's toes a bit, but Jack has assured me he is good with it and does not want to deal with selling to folks who need support (I don't blame them). I want to target something plug and play and lower priced. Those smart enough to DIY are welcome to buy any solution but also have the info available to roll their own.
> 
> What to people think?
> This will allow the handful of us to develop our own end use products, but all with a common data source


I am more than willing to help you with this project. I am also more hardware focused but I have a good amount of experience programming microcontrollers. I'll add some more input tomorrow.


----------



## amund7

If you are designing the electronics from the ground up, how hard/expensive would it be to mimic the functionality of the Can Crocodile? An inductive sniffer that you clip on the wires, no unplugging, no need to get the correct plugs, and would theoretically work with any canbus car/tractor/bus/airplane/UFO in the universe.


----------



## JWardell

amund7 said:


> If you are designing the electronics from the ground up, how hard/expensive would it be to mimic the functionality of the Can Crocodile? An inductive sniffer that you clip on the wires, no unplugging, no need to get the correct plugs, and would theoretically work with any canbus car/tractor/bus/airplane/UFO in the universe.


Not sure...care to tear yours apart to see? 

But it's not as simple plug an play as a connector for a common end user. Of course it does bring other possibilities.


----------



## Diamond.g

This is probably a noob question, I got the ESP32 and am wondering if anyone else is using a 10.14 Mac with USB-C to talk to it. I ask because I have to disassemble the enclosure to reset the device before my Mac sees it.


----------



## aames_iop

fast_like_electric said:


> The signals/connections are known, just a special dedicated CAN OBD2 bus on the usual pins 6 and 14, and some other pins for power and LIN. That was detailed a many posts up I believe, and it is in the Tesla wiring info as well. What is unknown is what messaging is possible at that connector.
> 
> If someone in China had a ODB2 reader or other ODB2 accessory to plug in and check operation, that would confirm if standard J1979 messaging (speed, RPM, throttle position, etc) is present there. A CAN trace would be nice as well, but the educated guess it is that dedicated OBD2 bus is quiet until requests come in from a connected device. Need someone to verify though.


I asked a chinese model 3 owner and he said he has tried connected a reader to that port and cant get any data but VIN, maybe they are still encrypted.


----------



## 0x6d33

amund7 said:


> If you are designing the electronics from the ground up, how hard/expensive would it be to mimic the functionality of the Can Crocodile? An inductive sniffer that you clip on the wires, no unplugging, no need to get the correct plugs, and would theoretically work with any canbus car/tractor/bus/airplane/UFO in the universe.


Supporting Can Crocodile shouldn't be to hard. Trying to make our own would probably be challenging.


----------



## 0x6d33

rmn said:


> I actually think this would be a good price-point solution in between EVTV CAN Due board (which is quite expensive) and a protoboard project which requires wiring and soldering and its not compact enough to mount inside the car.
> 
> We can source ESP32 and CAN transceivers for a reasonable price since production of those modules is already in place. Then, we can produce this 'assembly' board where the ESP32 and CAN transceiver can be mounted. With a simple board like this and mass production modules like ESP32 and CAN transceivers it is possible to achieve a reasonable production price. The idea is that the board can power the ESP32 and CAN bus transceiver with the 12v and GND cables that come from the tapped wire harness. And also, the CAN_H and CAN_L tapped wires would connect to the CAN BUS transceiver.
> 
> Both power and CAN wires could be easily removed in case the wire harness with 20 pins needed to be replaced for the 26 pin. @JWardell @fast_like_electric what do you guys think?
> 
> View attachment 24005
> 
> 
> I think it would be good to bundle the wire harness with a product that offers the possibility of working with CAN messages. Maybe a sketch like the one above would work.


@JWardell,

I think @rmn is going in the right direction. By using a ESP32 dev board as a base we should be able to dramatically reduce the cost to build a board. I bet these dev boards only cost $5 to 6$ when bought in bulk. We could then just focus on adding a power supply, CAN transceiver and whatever else we need. My main complaint with @rmn initial design is it is way to big. We need it to be about a third the size so it could fit in the center console.

What do you guys think?


----------



## 96s46p

0x6d33 said:


> Supporting Can Crocodile shouldn't be to hard. Trying to make our own would probably be challenging.


It's not that hard, but there are patents.


----------



## JWardell

0x6d33 said:


> @JWardell,
> 
> I think @rmn is going in the right direction. By using a ESP32 dev board as a base we should be able to dramatically reduce the cost to build a board. I bet these dev boards only cost $5 to 6$ when bought in bulk. We could then just focus on adding a power supply, CAN transceiver and whatever else we need. My main complaint with @rmn initial design is it is way to big. We need it to be about a third the size so it could fit in the center console.
> 
> What do you guys think?


This is why I think the ultimate solution is a wifi module where the case IS the custom molded male and female connector. Can probably just use PCB header pins for contacts (I doubt Sumitomo makes board mount versions), and we have already seen folks can make decent 3D printed connectors.
That's ideal for lowest cost, smallest size, ease of installation...but obviously increased effort and dev time. First version can just be harness based.


----------



## rmn

JWardell said:


> This is why I think the ultimate solution is a wifi module where the case IS the custom molded male and female connector. Can probably just use PCB header pins for contacts (I doubt Sumitomo makes board mount versions), and we have already seen folks can make decent 3D printed connectors.
> That's ideal for lowest cost, smallest size, ease of installation...but obviously increased effort and dev time. First version can just be harness based.


That would be great if Sumitomo made board mount versions of the components.

But otherwise, molding this type of case would be really expensive. Plastic injection molds would be quite complex because of the Sumitomo connector design and would also require two different molds because of the 20 and 26 pin connectors.

I believe using the wire harness is still a good idea, considering that we have two different connectors. The housing design for the board can be made in a way that the wire harness doesn't take too much space.



0x6d33 said:


> @JWardell,
> 
> I think @rmn is going in the right direction. By using a ESP32 dev board as a base we should be able to dramatically reduce the cost to build a board. I bet these dev boards only cost $5 to 6$ when bought in bulk. We could then just focus on adding a power supply, CAN transceiver and whatever else we need. My main complaint with @rmn initial design is it is way to big. We need it to be about a third the size so it could fit in the center console.
> 
> What do you guys think?


That is what I am working on. I will start with a bigger board to develop the firmware using mounted modules for ESP32 and CAN transceiver. Despite being big, I will be able to stick it to the exterior side of the removable panel while its connected to the wire harness. It won't stay inside the center console, but It won't be left on the floor.


----------



## 0x6d33

rmn said:


> That would be great if Sumitomo made board mount versions of the components.
> 
> But otherwise, molding this type of case would be really expensive. Plastic injection molds would be quite complex because of the Sumitomo connector design and would also require two different molds because of the 20 and 26 pin connectors.
> 
> I believe using the wire harness is still a good idea, considering that we have two different connectors. The housing design for the board can be made in a way that the wire harness doesn't take too much space.
> 
> That is what I am working on. I will start with a bigger board to develop the firmware using mounted modules for ESP32 and CAN transceiver. Despite being big, I will be able to stick it to the exterior side of the removable panel while its connected to the wire harness. It won't stay inside the center console, but It won't be left on the floor.


Which CAN transceiver are you planning on using?


----------



## rmn

0x6d33 said:


> Which CAN transceiver are you planning on using?


I am currently testing this one.

https://detail.tmall.com/item.htm?s...848463&cm_id=140105335569ed55e27b&abbucket=13


----------



## Collin80

rmn said:


> I am currently testing this one.
> 
> https://detail.tmall.com/item.htm?s...848463&cm_id=140105335569ed55e27b&abbucket=13


While you can certainly use a board like that you don't need it all. The ESP32 has built-in CAN and you only need the transceiver. On that board that's the TJA1050. If you found a board with just the transceiver that would be sufficient. Something like this: https://www.waveshare.com/sn65hvd230-can-board.htm

But, there's no reason you couldn't use the MCP2515 on that board and just forget the on-board CAN on the ESP32. The CAN hardware on the ESP32 isn't that great anyway so it isn't any huge loss.


----------



## b0n3z

JWardell said:


> This is why I think the ultimate solution is a wifi module where the case IS the custom molded male and female connector. Can probably just use PCB header pins for contacts (I doubt Sumitomo makes board mount versions), and we have already seen folks can make decent 3D printed connectors.
> That's ideal for lowest cost, smallest size, ease of installation...but obviously increased effort and dev time. First version can just be harness based.


You would need a SLA 3D printer. I had one discord Tesla friend ( @Raider1284 ) try and print a connector via filament. It seemed to be quite difficult for them and in the end the internals still didn't print correctly after multiple attempts and adjusting the files. But thanks to @TickTock - this is possible:
https://www.thingiverse.com/thing:3379540

Modify this slightly and you would have a perfect plug-and-play case with a board inside.

So @JWardell - make us a parts list of what you would suggest to make a sudo standard for others to follow along here. We could have part list versions as we improve items along the way (such as connectors, case, etc) while trying to keep using the board and CAN receiver you suggest.

@0x6d33 suggested using the following ( https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-222090 ) - is this what you agree we should use?

I couldn't agree more with your comment "_This will allow the handful of us to develop our own end use products, but all with a common data source_".


----------



## JWardell

Collin80 said:


> The CAN hardware on the ESP32 isn't that great anyway so it isn't any huge loss.


What's wrong with it? Would be nice to know the details now before I find out through frustration 



b0n3z said:


> You would need a SLA 3D printer. I had one discord Tesla friend ( @Raider1284 ) try and print a connector via filament. It seemed to be quite difficult for them and in the end the internals still didn't print correctly after multiple attempts and adjusting the files. But thanks to @TickTock - this is possible:
> https://www.thingiverse.com/thing:3379540
> 
> Modify this slightly and you would have a perfect plug-and-play case with a board inside.
> 
> So @JWardell - make us a parts list of what you would suggest to make a sudo standard for others to follow along here. We could have part list versions as we improve items along the way (such as connectors, case, etc) while trying to keep using the board and CAN receiver you suggest.
> 
> @0x6d33 suggested using the following ( https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-222090 ) - is this what you agree we should use?
> 
> I couldn't agree more with your comment "_This will allow the handful of us to develop our own end use products, but all with a common data source_".


Just before we found the connectors to use, further up in this thread someone had 3D printed their own connector, and showed it did fit the plug. Makes me think it should be fairly possible. It doesn't have to be perfect, it just has to work. I've seen similar things with NO connector plastic, as the friction from the header pins was enough.

I will post parts as I get things working, or better yet layout a PCB and maybe make a few.


----------



## rmn

JWardell said:


> Just before we found the connectors to use, further up in this thread someone had 3D printed their own connector, and showed it did fit the plug. Makes me think it should be fairly possible. It doesn't have to be perfect, it just has to work. I've seen similar things with NO connector plastic, as the friction from the header pins was enough.
> 
> I will post parts as I get things working, or better yet layout a PCB and maybe make a few.


Yes, SLA offers great rigidity and perfect mechanical properties. We could easily do the same lock mechanism as the Sumitomo connectors. But it is really slow, as slow as an FDM printer and piece generally require curing and some 'postpro' to make them look good. But its an option.

Yes, @Collin80 what's wrong with the ESP32 CAN module, would be great to know


----------



## 96s46p

rmn said:


> Yes, SLA offers great rigidity and perfect mechanical properties. We could easily do the same lock mechanism as the Sumitomo connectors. But it is really slow, as slow as an FDM printer and piece generally require curing and some 'postpro' to make them look good. But its an option.
> 
> Yes, @Collin80 what's wrong with the ESP32 CAN module, would be great to know


There are software and hardware bugs, the latest official driver should be better but I am not sure all the hardware bugs can be bypassed. They might not be too relevant for this type of device anyway.


----------



## fast_like_electric

JWardell said:


> What's wrong with it? Would be nice to know the details now before I find out through frustration


Just an observation, but the CAN logs posted here using the ESP32 solution are dropping a ton of messages. A good example is a few posts up with 0-60 run with 2019.8.3, Capture_3-29-19_Full_Throttle_90pSOC_v2019.8.3_F.asc. Easy to see if you look at some of the muxed or counter/checksum messages, where part of the message is a sequential counter. Take id 0x257 for example (speed), which has a frame counter in the low nibble of the second byte. If you scan the trace, you'll see this skip around. Looks like about 50% message loss overall.

Not sure if this is a ESP32 hardware or software limitation (or both), but something is amiss. For gauges and instrumentation it isn't a big deal. If you want a full log, that may be of concern. Depends on the end goal of everyone's individual projects.


----------



## jbcmprdct

JWardell said:


> Raise the passenger seat to full height, then look underneath. There is a small black box with a few harnesses going into it, one of which is yellow. You can either disconnect the yellow connector, or squeeze the sides of the box to remove the box from the seat, then disconnect the connector. Be aware that at the moment I have not been able to get the box to clip back into the seat again.
> 
> The yellow connector has four wires, and the yellow and green wires on the end are the CAN wires. BUT the wire colors are reversed!
> This is an Amp connector so we can probably source this easily and make a harness.


Hey @JWardell, 
I was looking for the connector you talked about for the Chassis CAN bus and I am not sure that I found the correct one.
Is it this one?








By the way: For the newer Model 3, I figured out the 26-pin connector. It seems to be a Toyota connector (do not know which company originally produced it)
90980-12771
90980-12770


----------



## Roci

fast_like_electric said:


> Just an observation, but the CAN logs posted here using the ESP32 solution are dropping a ton of messages. A good example is a few posts up with 0-60 run with 2019.8.3, Capture_3-29-19_Full_Throttle_90pSOC_v2019.8.3_F.asc. Easy to see if you look at some of the muxed or counter/checksum messages, where part of the message is a sequential counter. Take id 0x257 for example (speed), which has a frame counter in the low nibble of the second byte. If you scan the trace, you'll see this skip around. Looks like about 50% message loss overall.
> 
> Not sure if this is a ESP32 hardware or software limitation (or both), but something is amiss. For gauges and instrumentation it isn't a big deal. If you want a full log, that may be of concern. Depends on the end goal of everyone's individual projects.


Holy cow, 50% loss is bad. I didn't realize that. I am using PuTTY to capture the TCP data and log it to a file, and I suspect that is the weak link. Others have gotten the ESP32 hardware to capture at full rate with other software, so I don't think it's a limitation with on the hardware side.


----------



## fast_like_electric

Roci said:


> Holy cow, 50% loss is bad. I didn't realize that. I am using PuTTY to capture the TCP data and log it to a file, and I suspect that is the weak link. Others have gotten the ESP32 hardware to capture at full rate with other software, so I don't think it's a limitation with on the hardware side.


Yes, I suspect the software chain is the biggest factor. Though I've not seen zero loss in any of the posted ESP32 logs, but yes some are better.

Nominal Model 3 Vehicle bus message rate is 2000-2500 frames per second, but it is bursty at 10,000 frames per second (as quick as 100us between messages - such as 2 back to back single frame messages). So the software architecture needs to deal with that worst case throughput if no messages are to be lost - if the user cares for their application.

I know Collin mentioned some improvement to the driver to improve this (though not fully). Not sure what are all the running tasks and capability of the ESP32 environment (IRQ priority, buffers, DMA, etc).


----------



## amund7

For real world applications I believe you will be hardware filtering out most of the traffic. Scan My Tesla always does this with ELM327 and STM1110 commands. Meaning, if you want to measure a 0-100 kph drag, you'd build a tab with torque, kw, and speed, perhaps a few other interesting items, and the adapter is set up to only let those messages through. Then most hardware should cope. I just can't think of a real world scenario where you need to log every packet, across all CAN ID's.


----------



## fast_like_electric

amund7 said:


> For real world applications I believe you will be hardware filtering out most of the traffic. Scan My Tesla always does this with ELM327 and STM1110 commands. Meaning, if you want to measure a 0-100 kph drag, you'd build a tab with torque, kw, and speed, perhaps a few other interesting items, and the adapter is set up to only let those messages through. Then most hardware should cope. I just can't think of a real world scenario where you need to log every packet, across all CAN ID's.


I agree about most end-product ideas (smart phone instrument displays, HUDs, etc). And sure, once you know what you are looking for you can filter for it. But for what this group is doing with logging and analyzing CAN messaging to find those of interest, a stable and consistent method to record all the CAN messaging would be highly benifical.


----------



## JWardell

fast_like_electric said:


> I agree about most end-product ideas (smart phone instrument displays, HUDs, etc). And sure, once you know what you are looking for you can filter for it. But for what this group is doing with logging and analyzing CAN messaging to find those of interest, a stable and consistent method to record all the CAN messaging would be highly benifical.





fast_like_electric said:


> I agree about most end-product ideas (smart phone instrument displays, HUDs, etc). And sure, once you know what you are looking for you can filter for it. But for what this group is doing with logging and analyzing CAN messaging to find those of interest, a stable and consistent method to record all the CAN messaging would be highly benifical.


I think it's most important to get a general inexpensive device out there for regular folks to use with end user devices, and hopefully some hardware or software filtering can be used to reduce demands on software and transmission. Most of the end user applications are fine with a fraction of the messages. Being Arduino based that means it's also open to future crowd optimization and improvements.
For the hard analysis it's fine that the more advanced users can continue to use pro can hardware and tools. But maybe if SavvyCAN and others added support for Peak and other pro adapters this could be mitigated.


----------



## Collin80

96s46p said:


> There are software and hardware bugs, the latest official driver should be better but I am not sure all the hardware bugs can be bypassed. They might not be too relevant for this type of device anyway.


Yes, also, the filtering is pretty bad. If I remember correctly you get something like 4 filters total and there are some restrictions on how you use them. Even the MCP2515 has more and better filtering than the ESP32. Additionally, one of the potential sources for dropped frames is the lack of hardware buffers. If you don't get a frame pulled from the hardware before more come in it's going to get overwritten pretty quickly. As far as I remember there is exactly one receive buffer and one transmit buffer. Most other hardware has multiple buffers so you don't have to immediately service the device or lose traffic. So, it's just not super high end by any means. But, it's cool that they tried at all. For most uses it's fine. Most of the time people are likely to be OK with only getting 2280 out of 2310 frames in a second. I think I got the ESP32 CAN driver I wrote to get up to about 95-99% capture. I'd rather it be 100% but I just haven't gotten that to work yet. For low to medium bus rates it seems fine. If your goal is to flash the firmware on an ECU then perhaps it isn't the thing to use. If you want to create a display for a few details it's fine. If you want to send a hundred frames per second, it's fine. You just can't overwork it too much because it's not meant for that. If super high end performance is a big deal then at least go to the ARM SAM3X if not something higher end from ST or something. ARM Cortex M7 processors can sometimes be found with CAN-FD built in. So can other processors. If you want good CAN performance a chip with built-in *good* CAN is a real bonus. The ESP32 has "well, let's slap this in there" CAN.

BTW, I wasn't even aware of any hardware bugs related to CAN. I just looked it up and you're right, there are certainly bugs. It doesn't look too dire but those bugs could cause some issues in rare circumstances.


----------



## Collin80

JWardell said:


> But maybe if SavvyCAN and others added support for Peak and other pro adapters this could be mitigated.


I tried. In theory PeakCAN devices should work with SavvyCAN. But, I don't have a PeakCAN device and I'm told that at least one person tried it and couldn't get it to work. So i'm not sure whether it works or not. I know the Kvaser Leaf Light adapters do work with SavvyCAN. Really, any socketcan device works. But, for those of you on Windows and OSX the choices are more limited. I added support (once again in theory) for any device that QT supports. That's PeakCAN, Sys Tec, socketcan, J2534 passthrough, TinyCAN, VectorCAN. It seems intrepid has not created a QT SerialBus driver for their hardware but lots of other devices are supported. Though, Vehicle Spy seems great so I'm not sure whether anyone with Intrepid hardware would really be interested in SavvyCAN anyway.


----------



## fast_like_electric

Collin80 said:


> Yes, also, the filtering is pretty bad. If I remember correctly you get something like 4 filters total and there are some restrictions on how you use them. Even the MCP2515 has more and better filtering than the ESP32. Additionally, one of the potential sources for dropped frames is the lack of hardware buffers. If you don't get a frame pulled from the hardware before more come in it's going to get overwritten pretty quickly. As far as I remember there is exactly one receive buffer and one transmit buffer. Most other hardware has multiple buffers so you don't have to immediately service the device or lose traffic. So, it's just not super high end by any means. But, it's cool that they tried at all. For most uses it's fine. Most of the time people are likely to be OK with only getting 2280 out of 2310 frames in a second. I think I got the ESP32 CAN driver I wrote to get up to about 95-99% capture. I'd rather it be 100% but I just haven't gotten that to work yet. For low to medium bus rates it seems fine. If your goal is to flash the firmware on an ECU then perhaps it isn't the thing to use. If you want to create a display for a few details it's fine. If you want to send a hundred frames per second, it's fine. You just can't overwork it too much because it's not meant for that. If super high end performance is a big deal then at least go to the ARM SAM3X if not something higher end from ST or something. ARM Cortex M7 processors can sometimes be found with CAN-FD built in. So can other processors. If you want good CAN performance a chip with built-in *good* CAN is a real bonus. The ESP32 has "well, let's slap this in there" CAN.
> 
> BTW, I wasn't even aware of any hardware bugs related to CAN. I just looked it up and you're right, there are certainly bugs. It doesn't look too dire but those bugs could cause some issues in rare circumstances.


After doing some research, I think the internal ESP32 hardware CAN controller is likely fine. It is SJA1000 compatible, which was the mainstream workhorse CAN controller chip for a long time. It's what the old Vector products use from that era, as well as most other CAN solutions before micros had internal CAN controllers. That core logic has been used in a lot of FPGA's for implementing CAN, so I'm sure that is the same logic block they implemented on the ESP32.

The SJA1000 (and associated ESP32 peripheral register set) has a 64 byte receive FIFO, so I doubt there should be any issue with receiving if configured correctly. The missing messages would likely be due to the software driver, or what else is going on with the ESP32 to take away cycles from servicing CAN.

Seems like the issue is a lack of good documentation, and no vendor supplied driver. I would think a good understanding of the SJA1000 and a clean-up of the ESP32 CAN driver would be the remedy for the missing messages and robustness issues.

I'm assuming you based your driver on this to start?
http://www.barth-dev.de/can-driver-esp32/
https://github.com/ThomasBarth/ESP32-CAN-Driver


----------



## Collin80

fast_like_electric said:


> I'm assuming you based your driver on this to start?
> http://www.barth-dev.de/can-driver-esp32/
> https://github.com/ThomasBarth/ESP32-CAN-Driver


Yes. In fact, at a low level it's still that same code with just a few modifications. It's very likely that software issues are a big problem here. I've never used an SJA1000 before and basically just copied over the driver Thomas made and built on that. I just don't know anything about the original SJA1000 that the CAN hardware was based off of. Perhaps I ought to go dig into that a bit better.


----------



## fast_like_electric

Collin80 said:


> Yes. In fact, at a low level it's still that same code with just a few modifications. It's very likely that software issues are a big problem here. I've never used an SJA1000 before and basically just copied over the driver Thomas made and built on that. I just don't know anything about the original SJA1000 that the CAN hardware was based off of. Perhaps I ought to go dig into that a bit better.


It may not be the driver itself - could simply be how it is being used. Some things I would think to check....

- When the CAN receive interrupt occurs, is the CAN controller's receive FIFO read until empty?
- Are the received messages stored in a big enough software FIFO to account for other tasks that will take away CPU cycles - before being read by the application code?
- Is the CAN interrupt the highest priority?

Those are just a few thoughts of areas to verify and optimize. I'm not an ESP32 (or Arduino) guy, but have a lot of CAN experience with a variety of micros and CAN controllers. The ESP32 does look like a nice platform for the task at hand.

I agree the hardware filter set of this CAN controller is not great. But the SJA1000 did serve the world for a long time in the standalone chip form, so unless the ESP guys goofed something up, it is fully capable of full message capture at high bus load. And the ESP is a much faster host than what the SJA1000 was typically married to 15 years ago.

Good luck!


----------



## pavankp

I have a noob question. I am able to capture the data but not able to figure out how to interpret it. I am reading the data from a Raspberry Pi connected over USB to the EVTV ESP32 CANDue board. I can see the bytes being read, but I can't figure out how to put them together to match the known CAN IDs. I tried using the first two bytes in each frame, shifting one and merging with the other. I combined them in two different ways, but neither gives me results that match the CAN IDs in the spreadsheet from the first post of this thread. I would really appreciate any help!


----------



## Needsdecaf

Hello all. Pop in this thread occasionally to see how cool it is, but admit that most of it's over my head. 

In any event, given Elon's recent tweets regarding the in-cabin camera, has anyone been able to see if this camera is live and streaming data? Or is it truly dead as Elon claims it is? 

Thanks all. Tried to search the thread but got nowhere, apologies if previously discussed.


----------



## 96s46p

fast_like_electric said:


> and no vendor supplied driver.


https://github.com/espressif/esp-idf/blob/master/components/driver/can.c
https://github.com/espressif/esp-idf/tree/master/examples/peripherals/can


----------



## 96s46p

Collin80 said:


> I tried. In theory PeakCAN devices should work with SavvyCAN. But, I don't have a PeakCAN device and I'm told that at least one person tried it and couldn't get it to work. So i'm not sure whether it works or not. I know the Kvaser Leaf Light adapters do work with SavvyCAN. Really, any socketcan device works. But, for those of you on Windows and OSX the choices are more limited. I added support (once again in theory) for any device that QT supports. That's PeakCAN, Sys Tec, socketcan, J2534 passthrough, TinyCAN, VectorCAN. It seems intrepid has not created a QT SerialBus driver for their hardware but lots of other devices are supported. Though, Vehicle Spy seems great so I'm not sure whether anyone with Intrepid hardware would really be interested in SavvyCAN anyway.


Lawicel?


----------



## Tmo6

Needsdecaf said:


> Hello all. Pop in this thread occasionally to see how cool it is, but admit that most of it's over my head.
> 
> In any event, given Elon's recent tweets regarding the in-cabin camera, has anyone been able to see if this camera is live and streaming data? Or is it truly dead as Elon claims it is?
> 
> Thanks all. Tried to search the thread but got nowhere, apologies if previously discussed.


Hello! This thread is focused on the powertrain data (temps, speed, battery data, charge, torque, etc) which does not transmit data from the cameras. Would be great to access that camera, though! I don't know of any public forums on accessing those feeds.


----------



## JWardell

I got an interesting tweet asking for emulating an OBDII Port:


__ https://twitter.com/i/web/status/1113900782158602241
I believe the CANDue already has some OBD code, right @Collin80 ? Sounds like this would be fairly easy to do, I just never realized there are commercial customers that could use this, but it certainly makes sense for fleets and things.


----------



## JWardell

pavankp said:


> I have a noob question. I am able to capture the data but not able to figure out how to interpret it. I am reading the data from a Raspberry Pi connected over USB to the EVTV ESP32 CANDue board. I can see the bytes being read, but I can't figure out how to put them together to match the known CAN IDs. I tried using the first two bytes in each frame, shifting one and merging with the other. I combined them in two different ways, but neither gives me results that match the CAN IDs in the spreadsheet from the first post of this thread. I would really appreciate any help!


Welcome! If you are able to post or link to some of the log files (hopefully nothing huge) we are happy to take a look and figure out what they are, and also help you through the process. What is running on the Pi doing the capturing? Technically I guess SavvyCAN might run on it.



Needsdecaf said:


> Hello all. Pop in this thread occasionally to see how cool it is, but admit that most of it's over my head.
> 
> In any event, given Elon's recent tweets regarding the in-cabin camera, has anyone been able to see if this camera is live and streaming data? Or is it truly dead as Elon claims it is?
> 
> Thanks all. Tried to search the thread but got nowhere, apologies if previously discussed.


The cameras are not on the CAN bus, they each have their direct connections to the autopilot computer board and nothing else. If you really don't trust Tesla's claims that it is not active, I guess you could unplug the cable (or even easier, just cover it with tape).


----------



## amund7

JWardell said:


> I got an interesting tweet asking for emulating an OBDII Port:
> 
> 
> __ https://twitter.com/i/web/status/1113900782158602241
> I believe the CANDue already has some OBD code, right @Collin80 ? Sounds like this would be fairly easy to do, I just never realized there are commercial customers that could use this, but it certainly makes sense for fleets and things.


I was also asked about this recently, but I suspect the people asking were missing some details, or perhaps I didn't understand the question, which was probably more like you ask here. If someone made a device that translates model 3 canbus into whatever the taxis want to read from the OBD2 port, then that would for sure be a sellable item. This would adapt lots of general accessories that rely on the OBD2 port. Add to that 'fleet', 'rentals', 'company car that needs to log the miles', you would have a potentially huge customer base world wide!


----------



## Needsdecaf

JWardell said:


> Welcome! If you are able to post or link to some of the log files (hopefully nothing huge) we are happy to take a look and figure out what they are, and also help you through the process. What is running on the Pi doing the capturing? Technically I guess SavvyCAN might run on it.
> 
> The cameras are not on the CAN bus, they each have their direct connections to the autopilot computer board and nothing else. If you really don't trust Tesla's claims that it is not active, I guess you could unplug the cable (or even easier, just cover it with tape).


Haha, already covered. I was just curious if we could catch Elon fibbing or not.


----------



## fast_like_electric

JWardell said:


> I got an interesting tweet asking for emulating an OBDII Port:
> 
> 
> __ https://twitter.com/i/web/status/1113900782158602241
> I believe the CANDue already has some OBD code, right @Collin80 ? Sounds like this would be fairly easy to do, I just never realized there are commercial customers that could use this, but it certainly makes sense for fleets and things.


The devil is in the details regarding which device is desired to be used and its function. OBDII is thrown around quite loosely meaning just something plugged into that port.

1) The official OBDII diagnostics (services, commands, PIDs, etc) are defined by the SAE J1979 standard. This allows any compliant device to pull things like vehicle speed / RPM / battery voltage. This is done by issuing these query commands to the appropriate diagnostic ID - typically the powertrain controller for emissions related info. Write-ups for ELM and other devices also detail this process. This is straight forward and easy to emulate - just need a device that has 2 CAN ports. This would allow you to support compliant devices such as generic HUDs. I have this working currently, but el-cheapo HUDs don't display much more than speed, rpm, temp, and voltage.

2) You also have OBD dongles (and test tools) which plug into the port and access non-emissions functions, alternate modules, and proprietary PIDs and functions. This is not publicly documented, and varies across manufacturer and vehicles. Advantages to things like this is that module faults can also be tracked in a fleet. There are also diagnostic services that can be used to automatically send periodic broadcasts of data of interest without requiring continual polling - minimizing the extra traffic imposed on the bus by the device.

3) There are also devices which just look at the down the road normal CAN messaging. The Fleet Carma dongle is an example of this, where is snags things like battery level and odometer transparently. Most insurance dongles do the same - but without EV centric functions. They plug into the OBDII port, but do nothing with OBDII messaging - just parse the CAN traffic like this group is doing. To support each car, the dongle is loaded with the appropriate firmware which understands a given car's CAN message database.

4) Lastly you have dongles which plug into that port that just use it for only 12V. They have internal radios for GPS and cell, and just enable vehicle tracking standalone without doing anything at all on the communication buses.

So, to support the taxi service inquiry, it would need to be understood what type of dongle is being used and how it operates. If it is using common J1979 PID queries - no problem to emulate that. But if it is working like most insurance dongles and asset trackers, that's actually not OBDII protocol. In that case the CAN messaging of whatever vehicles they do support would have to be understood and emulated.

Anything is possible to support. Just need to understand that generic OBDII may not be what is needed for a given device to actually perform its intended function.


----------



## amund7

https://play.google.com/store/apps/details?id=com.emon.canbus.tesla

Scan My Tesla with the first release supporting Model 3!

Credit goes to the people of this thread, especially JWardell for starting it and keep pushing.
Anyone participating is this thread is of course entitled to a free copy, PM me for that.
When someone has a webshop selling OBD2 harnesses, let me know, I would like to link to your store.


----------



## Perscitus

Purchased just to support you guys.
I've done a lot of CAN bus logging and PID reverse engineering, app beta and QA testing for Subarus (ECUs, TCUs, other xCUs), up to 30-40 concurrent PIDs writing away to a MicroSD csv file @ 40-100Hz. But my Oct build date Model 3 is a different animal... and this thread proves it. Can't wait for a way to use OBDLink LX, MX, Tactrix OPv2 or another interface to get at some basic data via this Android app.


----------



## JWardell

amund7 said:


> https://play.google.com/store/apps/details?id=com.emon.canbus.tesla
> 
> Scan My Tesla with the first release supporting Model 3!
> 
> Credit goes to the people of this thread, especially JWardell for starting it and keep pushing.
> Anyone participating is this thread is of course entitled to a free copy, PM me for that.
> When someone has a webshop selling OBD2 harnesses, let me know, I would like to link to your store.


Awesome! I was going to jump on Google Fi before a trip in a few months and get one of the cheap android phones, but this might move that decision up a few months...
I also need to grab an OBDlink, any reason not to just go with the LX?


----------



## amund7

No, just use the LX, the differences are just a special Ford bus AFAIK.


----------



## Mesprit87

amund7 said:


> https://play.google.com/store/apps/details?id=com.emon.canbus.tesla
> 
> Scan My Tesla with the first release supporting Model 3!
> 
> Credit goes to the people of this thread, especially JWardell for starting it and keep pushing.
> Anyone participating is this thread is of course entitled to a free copy, PM me for that.
> When someone has a webshop selling OBD2 harnesses, let me know, I would like to link to your store.


I'm not participating in any way in this thread but once you guys have the interface figured out, I'll be happy to pay for it and reward you for all the great work accomplished


----------



## pavankp

JWardell said:


> Welcome! If you are able to post or link to some of the log files (hopefully nothing huge) we are happy to take a look and figure out what they are, and also help you through the process. What is running on the Pi doing the capturing? Technically I guess SavvyCAN might run on it.


Thank you. Attached is a file I dumped a few days ago. I have a simple python script on the Pi that talks to the CANDue using pyserial. As I understand it, @Collin80's ESP32RET software is running on that board. So on the Pi, I just read a line of bytes and print it to produce the attached file. Each line is a series of bytes.

I tried combining the first two bytes of each line, to compare with the CAN IDs in your spreadsheet. I tried this in two ways: left-shift the first byte and merge it with the second, or left-shift the second byte and merge in the first byte. The results from neither method were within the hex ranges of CAN IDs in your spreadsheet.

Any idea what I am looking at and how to interpret it? Thanks for your help!

I looked into getting SavvyCAN to run on the Pi, but it looked way too difficult.

Edit 1: For example, the last line in the file is:


Code:


b'\x80\xab\x80\xe0&\x07\[email protected]\xa2"A\x00\[email protected]$\'\[email protected]\x00f\n'

 The spreadsheet doesn't list any of 0x080, 0x0AB, 0x80AB or 0xAB80 as valid CAN IDs.

Edit 2: The python byte string in test.txt is hard to read. Attached hexoutput.txt which shows each byte separately, delimited by - characters. In this file that I just captured, the first two bytes of the first few lines are: [0x0, 0x0], [0x3, 0xc], [0xc, 0xa7], [0x69, 0x0], [0x80, 0xa0], [0x80, 0xc0], [0x60, 0x2f]... I am not able to figure out a pattern here.


----------



## JWardell

pavankp said:


> Thank you. Attached is a file I dumped a few days ago. I have a simple python script on the Pi that talks to the CANDue using pyserial. As I understand it, @Collin80's ESP32RET software is running on that board. So on the Pi, I just read a line of bytes and print it to produce the attached file. Each line is a series of bytes.
> 
> I tried combining the first two bytes of each line, to compare with the CAN IDs in your spreadsheet. I tried this in two ways: left-shift the first byte and merge it with the second, or left-shift the second byte and merge in the first byte. The results from neither method were within the hex ranges of CAN IDs in your spreadsheet.
> 
> Any idea what I am looking at and how to interpret it? Thanks for your help!
> 
> I looked into getting SavvyCAN to run on the Pi, but it looked way too difficult.
> 
> Edit 1: For example, the last line in the file is:
> 
> 
> Code:
> 
> 
> b'\x80\xab\x80\xe0&\x07\[email protected]\xa2"A\x00\[email protected]$\'\[email protected]\x00f\n'
> 
> The spreadsheet doesn't list any of 0x080, 0x0AB, 0x80AB or 0xAB80 as valid CAN IDs.
> 
> Edit 2: The python byte string in test.txt is hard to read. Attached hexoutput.txt which shows each byte separately, delimited by - characters. In this file that I just captured, the first two bytes of the first few lines are: [0x0, 0x0], [0x3, 0xc], [0xc, 0xa7], [0x69, 0x0], [0x80, 0xa0], [0x80, 0xc0], [0x60, 0x2f]... I am not able to figure out a pattern here.


Hmm. Certainly doesn't look right, data lines are much too long. CAN IDs should only have three hex numbers (up to 0x7FF). Perhaps you are seeing the protocol that ESP32RET communicates to SavvyCAN with (GVRET?).


----------



## pavankp

JWardell said:


> Hmm. Certainly doesn't look right, data lines are much too long. CAN IDs should only have three hex numbers (up to 0x7FF). Perhaps you are seeing the protocol that ESP32RET communicates to SavvyCAN with (GVRET?).


Thanks, that would make sense. I now need to find any documentation about that data protocol. @Collin80 any pointers where I can look? I didn't see anything in the GitHub repository for GEVRET.


----------



## 0x6d33

I did a 0 to 60 mph run over the weekend after I got 2019.8.5 (dual motor). The delta between the first point over 60 MPH and the last point that was 0 MPH is 4.424 seconds.

As you can see from the plot, I eased up on the pedal before hitting 60 so my actual 0 to 60 is likely better than 4.4 seconds.


----------



## JWardell

0x6d33 said:


> I did a 0 to 60 mph run over the weekend after I got 2019.8.5 (dual motor). The delta between the first point over 60 MPH and the last point that was 0 MPH is 4.424 seconds.
> 
> As you can see from the plot, I eased up on the pedal before hitting 60 so my actual 0 to 60 is likely better than 4.4 seconds.
> 
> View attachment 24619


Nice. It seems like there are a LOT of dropouts in your data though. No pedal data between 4.3 and 4.6 to know when you eased off. Torque showing a dip around 4.5 where traction control might have kicked in. In other words, you know the car will be even faster than 4.4  Also make sure you are reading the signed velocity instead of the UI speed which transmits much more often, for more accurate 0-60 times.


----------



## Collin80

96s46p said:


> Lawicel?


Lawicel is a company that made a can adapter and then went to the effort to build up a text based protocol and a linux driver that took in the text output of that protocol and turned it into a socketcan interface in LINUX. Technically some other things support that same protocol and it can thus be used as a way to talk to the CAN bus adapter over a nice text based interface. If someone were to want to integrate with python in a cross platform way it might be a nice option.


----------



## Collin80

JWardell said:


> I got an interesting tweet asking for emulating an OBDII Port:
> 
> 
> __ https://twitter.com/i/web/status/1113900782158602241
> I believe the CANDue already has some OBD code, right @Collin80 ? Sounds like this would be fairly easy to do, I just never realized there are commercial customers that could use this, but it certainly makes sense for fleets and things.


Yeah, I have various bits of code laying about that support J1939 messaging. There's some in GVRET, M2RET, ESP32RET, GEVCU. It hasn't ever had the attention it should. I think it's all in a semi-working state. But, the general ideas are there and it probably wouldn't take a lot to get it running. It wouldn't be too difficult to put it all together and create an interface where one CAN bus is connected to the car and one to an ODB-II port such that the device (probably a CANDue or other dual CAN SAM3X design) would take in PID requests from the OBD-II port and get the relevant info from the main vehicle bus of the car. I do think there could be a market for an add-on OBDII port for the model 3.


----------



## Collin80

pavankp said:


> Thanks, that would make sense. I now need to find any documentation about that data protocol. @Collin80 any pointers where I can look? I didn't see anything in the GitHub repository for GEVRET.


https://github.com/collin80/M2RET/blob/master/CommProtocol.txt

But, your data appears odd. The GVRET protocol itself should have a 0xF1 every time a new command or frame is sent. I just don't see any F1 bytes. It seems like things are scrambled up.

For what it's worth, the GVRET sketch can talk a human readable format so if you didn't set anything special it should have been outputting in ascii and be readable. It only transmits in binary if you ask it to. SavvyCAN asks it to and if you connected SavvyCAN it might have gotten set to binary mode. You can use the serial console to turn that off. You only want binary mode to talk to SavvyCAN as there aren't too many other programs that try to talk in the binary format. GVRET has lawicel mode too if you wanted to get fancy and start slcan on the rPi and connect to GVRET that way. But, setting up serial to socketcan with slcan is a bit daunting the first time.


----------



## pavankp

Collin80 said:


> https://github.com/collin80/M2RET/blob/master/CommProtocol.txt
> 
> But, your data appears odd. The GVRET protocol itself should have a 0xF1 every time a new command or frame is sent. I just don't see any F1 bytes. It seems like things are scrambled up.
> 
> For what it's worth, the GVRET sketch can talk a human readable format so if you didn't set anything special it should have been outputting in ascii and be readable. It only transmits in binary if you ask it to. SavvyCAN asks it to and if you connected SavvyCAN it might have gotten set to binary mode. You can use the serial console to turn that off. You only want binary mode to talk to SavvyCAN as there aren't too many other programs that try to talk in the binary format. GVRET has lawicel mode too if you wanted to get fancy and start slcan on the rPi and connect to GVRET that way. But, setting up serial to socketcan with slcan is a bit daunting the first time.


Thank you! I did not connect SavvyCAN at all, so I don't know what I am doing wrong. The sketch running on the ESP32 should be your ESP32RET that it came with; I didn't upload anything to it. The python code I am using to read the data sent by the sketch is very simple:



Code:


#!/usr/bin/env python3

import serial

ser = serial.Serial("/dev/ttyUSB0", 500000)
while True:
    line = ser.readline()
    print(line)

The result from this is the test.txt file I attached earlier. Any idea what I am doing wrong?

I am totally new to CAN and I have forgotten most of the C and C++ I learned when I was young, so I was hoping to use python to build a GUI to show the CAN data, which is why I am trying to use the Pi as my in-car device.


----------



## 96s46p

Collin80 said:


> Lawicel is a company that made a can adapter and then went to the effort to build up a text based protocol and a linux driver that took in the text output of that protocol and turned it into a socketcan interface in LINUX. Technically some other things support that same protocol and it can thus be used as a way to talk to the CAN bus adapter over a nice text based interface. If someone were to want to integrate with python in a cross platform way it might be a nice option.


Yes what I meant was it would be nice to support native lawicel over com port in Windows since the open source clones are the cheapest usb-can devices.


----------



## fast_like_electric

96s46p said:


> Yes what I meant was it would be nice to support native lawicel over com port in Windows since the open source clones are the cheapest usb-can devices.


Convenient with no drivers, but lots of limitations. High bus load 500kbps CAN over serial with ASCII protocol? According to the manual...

"There are of course limitations of how many CAN frames the CAN232 can send & receive. Current version (V13nn) is tested with a throughput of sending 500 standard 11bit frames with 8 databytes at 125kbit CAN bitrate and 115,200 baudrate of the RS232. The bottle neck is of course the RS232 side and the microcontroller not being able to handle more frames per second. So the CAN232 is aimed for low speed CAN networks..."

Clearly not a good bus logger for Model 3, but ok if you know the limitations I guess. Also kinda hard to find a PC with COM port nowadays, so you'd also need a USB to serial converter with this type of device.


----------



## boatbuild

Looking to contribute here.. I have purchased M/F connectors and pins for an interposing cable for the rear of the center console Vehicle CAN. noob question, can i safely unplug the connector to add the interposer? Sorry if this has been discussed, i could not find it. Thanks for all the work on the spreadsheet


----------



## fast_like_electric

boatbuild said:


> Looking to contribute here.. I have purchased M/F connectors and pins for an interposing cable for the rear of the center console Vehicle CAN. noob question, can i safely unplug the connector to add the interposer? Sorry if this has been discussed, i could not find it. Thanks for all the work on the spreadsheet


Yes, no problem. You are momentarily powering down the security module by removing that connection, as well as 12V accessory and USB power in the console. So you'll loose that functionality during the disconnect period, but everything is unaffected and works fine when replugged in.

Most of us have done much worse things, like shorting the CAN bus, sending stray messages, or actively engaging a CAN sniffer at the wrong baud rate. That will make the big contactor clunk off and scare you a bit, but again no trouble once the fault scenario is removed.

Welcome to the group!


----------



## boatbuild

Thanks for the encouragement  I have a pi-based head-unit from another project that should serve as a decent CAN sniffer. I'll be back when i have something to offer.


----------



## amund7

fast_like_electric said:


> Yes, no problem. You are momentarily powering down the security module by removing that connection, as well as 12V accessory and USB power in the console. So you'll loose that functionality during the disconnect period, but everything is unaffected and works fine when replugged in.


Not sure if this needs mentioning, but I would power down the car from the screen and wait till all pumps and fans went asleep before unplugging anything.


----------



## JWardell

boatbuild said:


> Looking to contribute here.. I have purchased M/F connectors and pins for an interposing cable for the rear of the center console Vehicle CAN. noob question, can i safely unplug the connector to add the interposer? Sorry if this has been discussed, i could not find it. Thanks for all the work on the spreadsheet


I was terrified to do so for months, but I can confirm you can unplug the rear console connector WHEN NOT DRIVING without permanent issues.
I personally get in the back, close the door, and wait a few seconds for the display and everything to power back off before I do it.

If you short the CAN, you will immediately hear contractors open.
If there are any remaining issues with CAN connections afterwards, you will hear strange fan noises for a good minute before you start getting errors on the display. I really wanted to avoid learning that one.
If there are issues with connection to the various VSEC networks also in that connector, you probably won't be able to authenticate ignition and drive. Wish I avoided learning that the hard way too 

I've had that harness exposed and hanging out for months now with no issues, but I am always worried someone will kick it or something rolls into it. Really need to get a move on my small wireless module so I can cover it all back up.


----------



## fast_like_electric

amund7 said:


> Not sure if this needs mentioning, but I would power down the car from the screen and wait till all pumps and fans went asleep before unplugging anything.


The way that is supposed to work is that the car stays in that 'powered off' state until you step on the brake to cancel. I've never had that work, even when waiting several minutes, and after the 'clunk'. Opening the door resumes CAN activity, and the screen also pops right back on with no 'reboot' delay.

Anyway, you can certainly go to that extreme. This is somewhat difficult to do since opening the door undoes all that. To really stay in that power down state, you have to reach around and unplug and replug the connectors from the front seat, which is difficult to do from the front seat without exiting the vehicle.

Also worth noting that there is no mention of doing anything special in the Fleet Carma instructions, which is a similar concept of installing a 'T' harness at that location for the same purpose. Info here...

https://www.fleetcarma.com/docs/SCR_Tesla 3 Install Instructions_digital.pdf

No worries - just don't miswire the home built jumper harness if you can avoid it.


----------



## Collin80

pavankp said:


> Thank you! I did not connect SavvyCAN at all, so I don't know what I am doing wrong. The sketch running on the ESP32 should be your ESP32RET that it came with; I didn't upload anything to it. The python code I am using to read the data sent by the sketch is very simple:
> 
> 
> 
> Code:
> 
> 
> #!/usr/bin/env python3
> 
> import serial
> 
> ser = serial.Serial("/dev/ttyUSB0", 500000)
> while True:
> line = ser.readline()
> print(line)
> 
> The result from this is the test.txt file I attached earlier. Any idea what I am doing wrong?
> 
> I am totally new to CAN and I have forgotten most of the C and C++ I learned when I was young, so I was hoping to use python to build a GUI to show the CAN data, which is why I am trying to use the Pi as my in-car device.


You must set the serial rate to 1000000 that is, one million. The serial rate has nothing to do with the CAN bus rate. ESP32RET sends at 1Mb/s to get better performance. This differentiates the ESP32 from some of our other boards like the CANDue 2.0. That one uses an MCU with built-in USB and the USB stack always runs at 480Mbs. The processor can't actually achieve that but it does manage to push upward of a few megabytes per second and doesn't care what baud rate you ask for. The ESP32 board very much cares.

Otherwise, go to savvycan.com and download the ESP32RET installer. I don't know if the ESP32RET sketch is already on there or not. But, it looks like it's trying to send something so I'll bet the issue is the wrong bitrate.


----------



## fast_like_electric

Related to the recent talk about fitting the Model 3 with a real OBDII capable port, here's my first go at a Model 3 HUD...





































Off the shelf el-cheapo HUD (Amazon / ebay), interfacing with a secondary emulated J1979 CAN. Something like this would ultimately go more toward the left (and lower) on the windsheld - just placed it in the center dash for ease of photo-ing with main screen. Hard to get everything in focus, but the HUD is quite sharp looking even without the plastic film to project on. Quite visible in night and day as well.

Works good, but obviously limited to what the HUD itself can show and the messages it wants to pull. Proof of concept here is showing vehicle speed, motor RPM (bar graph), 12V voltage, and battery temp (in place of coolant temp).

Making a custom HUD would of course be better, but just wanted to share one concept.


----------



## JWardell

fast_like_electric said:


> Related to the recent talk about fitting the Model 3 with a real OBDII capable port, here's my first go at a Model 3 HUD...
> 
> View attachment 24694
> 
> 
> View attachment 24695
> 
> 
> View attachment 24696
> 
> 
> View attachment 24697
> 
> 
> Off the shelf el-cheapo HUD (Amazon / ebay), interfacing with a secondary emulated J1979 CAN. Something like this would ultimately go more toward the left (and lower) on the windsheld - just placed it in the center dash for ease of photo-ing with main screen. Hard to get everything in focus, but the HUD is quite sharp looking even without the plastic film to project on. Quite visible in night and day as well.
> 
> Works good, but obviously limited to what the HUD itself can show and the messages it wants to pull. Proof of concept here is showing vehicle speed, motor RPM (bar graph), 12V voltage, and battery temp (in place of coolant temp).
> 
> Making a custom HUD would of course be better, but just wanted to share one concept.


Awesome. This is why I bought a GPS HUD well before my Model 3 because I thought folks would want this. Never bothered to put it in though.
motor RPM will just be a graph of display, might be nicer to map torque or power to that.
So you already figured how to emulate OBDII for your display...


----------



## fast_like_electric

JWardell said:


> Awesome. This is why I bought a GPS HUD well before my Model 3 because I thought folks would want this. Never bothered to put it in though.
> motor RPM will just be a graph of display, might be nicer to map torque or power to that.
> So you already figured how to emulate OBDII for your display...


Yes, could display something other than RPM on the bar graph. My immeadiate thought was battery power or motor power as well, but that graph also has a few numbers and can't go negative - so something more custom will fit the bill better for that. This particular unit also has another 7 segment area for fuel consumption, but this is an odd calculated parameter based on vehicle speed and MAF data, so can't be used for generic display unfortunately. Also sending battery temperature in Fahrenheit numbers instead of Celsius, so the numbers line up with the coolant temp bar graph. That maps perfectly.

Yes, emulating J1979 PIDs is not bad. There isn't much EV pertinent info on those PIDs, so you do have to be creative based on what the particular HUD looks for. And then just feed those variables with scaled data from the Model 3 CAN message content. Using a PC with two CAN interfaces and some C code for quick debug, but easy to make this full embedded with a micro with two CAN controllers.

Given the issues with what off-the-shelf HUDs provide visually, OBDII messaging 'in-between' is probably not the best solution since a custom HUD will need a different display, so it might as well hook right up to the main CAN bus and use the native messages without conversion. At least that's my thought right now unless a nice OBDII HUD with what I want is hiding somewhere.

Can of course do this with a phone/tablet app too which would be more flexible, but would not be OBDII J1979 to get the EV data we'd want.


----------



## 96s46p

fast_like_electric said:


> Convenient with no drivers, but lots of limitations. High bus load 500kbps CAN over serial with ASCII protocol? According to the manual...
> 
> "There are of course limitations of how many CAN frames the CAN232 can send & receive. Current version (V13nn) is tested with a throughput of sending 500 standard 11bit frames with 8 databytes at 125kbit CAN bitrate and 115,200 baudrate of the RS232. The bottle neck is of course the RS232 side and the microcontroller not being able to handle more frames per second. So the CAN232 is aimed for low speed CAN networks..."
> 
> Clearly not a good bus logger for Model 3, but ok if you know the limitations I guess. Also kinda hard to find a PC with COM port nowadays, so you'd also need a USB to serial converter with this type of device.


Ah, no I mean the open source adapters and clones like cantact, canable, uccb that use usb-cdc.


----------



## fast_like_electric

96s46p said:


> Ah, no I mean the open source adapters and clones like cantact, canable, uccb that use usb-cdc.


Are the USB clones you mention the same as the Lawicel USB device? If so, that is a bit better, but there is a similar statement in the owners manual for the USB device as well. RS232 no longer the bottleneck, but they state that the micro and buffer size is.


----------



## pavankp

Collin80 said:


> You must set the serial rate to 1000000 that is, one million. The serial rate has nothing to do with the CAN bus rate. ESP32RET sends at 1Mb/s to get better performance. This differentiates the ESP32 from some of our other boards like the CANDue 2.0. That one uses an MCU with built-in USB and the USB stack always runs at 480Mbs. The processor can't actually achieve that but it does manage to push upward of a few megabytes per second and doesn't care what baud rate you ask for. The ESP32 board very much cares.
> 
> Otherwise, go to savvycan.com and download the ESP32RET installer. I don't know if the ESP32RET sketch is already on there or not. But, it looks like it's trying to send something so I'll bet the issue is the wrong bitrate.


Thank you, the baudrate fixed it! I am now getting the binary data with 0xf1 values so I am able to get to the CAN IDs and messages using your protocol description. Thanks for all your help.


----------



## pavankp

@fast_like_electric That looks great. I am trying to get a GUI on a Raspberry Pi to show the speed read from the CAN. I see that the third byte in messages with CAN ID 0x257 contains the UI speed. I can get to those messages on my Pi, and I see values in the range of 0x1c to 0x24 on a very short test drive where my speed was less than 5mph. How do those values convert to the displayed speed?


----------



## fast_like_electric

pavankp said:


> @fast_like_electric That looks great. I am trying to get a GUI on a Raspberry Pi to show the speed read from the CAN. I see that the third byte in messages with CAN ID 0x257 contains the UI speed. I can get to those messages on my Pi, and I see values in the range of 0x1c to 0x24 on a very short test drive where my speed was less than 5mph. How do those values convert to the displayed speed?


In message 0x257, the UI speed is in the 4th byte. 1 bit = 1 MPH or kph, depending on your display units.


----------



## JWardell

pavankp said:


> @fast_like_electric That looks great. I am trying to get a GUI on a Raspberry Pi to show the speed read from the CAN. I see that the third byte in messages with CAN ID 0x257 contains the UI speed. I can get to those messages on my Pi, and I see values in the range of 0x1c to 0x24 on a very short test drive where my speed was less than 5mph. How do those values convert to the displayed speed?


The third byte should literally be the same as the UI speed.
All decoding is detailed in the spreadsheet

Edit sorry the 4th byte. The preceding values are signed speed


----------



## pavankp

@fast_like_electric @JWardell Thank you both, it is working now with the 4th byte. Now I understand why the third byte starts off at 0x1f and goes down when in reverse.


----------



## 0x6d33

pavankp said:


> @fast_like_electric That looks great. I am trying to get a GUI on a Raspberry Pi to show the speed read from the CAN. I see that the third byte in messages with CAN ID 0x257 contains the UI speed. I can get to those messages on my Pi, and I see values in the range of 0x1c to 0x24 on a very short test drive where my speed was less than 5mph. How do those values convert to the displayed speed?


What are you planning on using for the GUI?


----------



## pavankp

0x6d33 said:


> What are you planning on using for the GUI?


I am using PyGtk. It is very easy to make a functional GUI with it.


----------



## 0x6d33

pavankp said:


> I am using PyGtk. It is very easy to make a functional GUI with it.


Thanks, I'll have to look into it.

My first stab into displaying the Model 3's CAN bus message was using a Pi directly connected to a MCP2515. I used python-can and SocketCan to communicate with the MCP2515.


----------



## 96s46p

fast_like_electric said:


> Are the USB clones you mention the same as the Lawicel USB device? If so, that is a bit better, but there is a similar statement in the owners manual for the USB device as well. RS232 no longer the bottleneck, but they state that the micro and buffer size is.


No they aren't really clones they just implement the protocol. They use stm32 native usb whereas lawicel usb uses ftdi I think.


----------



## thezim

Is anyone selling a pre-made patch cable yet for accessing the bus? I don't need any other hardware as I am using a Raspberry Pi with a Canable compatible adapter.

Thanks.


----------



## Tmo6

pavankp said:


> Thank you, the baudrate fixed it! I am now getting the binary data with 0xf1 values so I am able to get to the CAN IDs and messages using your protocol description. Thanks for all your help.


Can you share a link to the hardware you're using? Thanks! @pavankp


----------



## JWardell

thezim said:


> Is anyone selling a pre-made patch cable yet for accessing the bus? I don't need any other hardware as I am using a Raspberry Pi with a Canable compatible adapter.
> 
> Thanks.


I don't think any are sold just yet. @rvm made a few to test, and EVTV made a bunch which it might include with CanDue eventually. I think everyone is waiting to figure out the 2019 connectors


----------



## sconner

Does anyone have any recordings saved in SocketCan format that they would share? I would like to try my hand at decoding the powertrain (Vehicle CAN) bus.


----------



## Collin80

sconner said:


> Does anyone have any recordings saved in SocketCan format that they would share? I would like to try my hand at decoding the powertrain (Vehicle CAN) bus.


Back on page 31 I posted a bunch of logs that MadModel3Hacker let me post with the VIN removed. They used to be in socketcan format but I converted them to Vector ASC I think. So, I guess that still doesn't really help you a lot. Is your goal to play the log files back with socketcan utilities or what? Is there any hope that some other file format would work?

EDIT: Previously I said that there wasn't a converter between the files I posted on page 31 and the socketcan format. Actually SavvyCAN does support candump output which should then be directly possible to feed into the linux CAN utilities. It does, however, claim all frames came from vcan0. That's easy enough to change if you need it to point elsewhere. So, you can convert pretty much any of the logs posted so far into candump format using SavvyCAN if you need. Then you can use your preferred tools from there.


----------



## JWardell

Well folks, I just got what I think is another significant development working!
What's impressive here is that I am using all off-the-shelf parts here, or at least, nothing physically made by me, but by others here who have also been working hard in the background.
It took me a couple days of wrestling (at no fault of theirs), but I now have ScanMyTesla beautifully displaying data, and wirelessly to boot! See the video and photos below.

This involves:
1- a cheap Chinese Umi Android phone that had been collecting dust in my drawer
2- ScanMyTesla app which is thanks to a ton of hard work over the last few months by @amund7 
3- OBDLink LX OBD to bluetooth adapter
4- A beautifully made plug and play harness with OBD plug by @rmn - I hope you can join me in encouraging him to offer these to those who beg 
5- docked on my pre-existing phone mount

And yes...IT CAN LOG TOO!


----------



## 0x6d33

JWardell said:


> Well folks, I just got what I think is another significant development working!
> What's impressive here is that I am using all off-the-shelf parts here, or at least, nothing physically made by me, but by others here who have also been working hard in the background.
> It took me a couple days of wrestling (at no fault of theirs), but I now have ScanMyTesla beautifully displaying data, and wirelessly to boot! See the video and photos below.
> 
> This involves:
> 1- a cheap Chinese Umi Android phone that had been collecting dust in my drawer
> 2- ScanMyTesla app which is thanks to a ton of hard work over the last few months by @amund7
> 3- OBDLink LX OBD to bluetooth adapter
> 4- A beautifully made plug and play harness with OBD plug by @rmn - I hope you can join me in encouraging him to offer these to those who beg
> 5- docked on my pre-existing phone mount
> 
> And yes...IT CAN LOG TOO!
> 
> 
> View attachment 24855
> 
> View attachment 24856


Great job.

What kind of phone mount are you using?

How bad is the data lost with this setup, if any?


----------



## garsh

JWardell said:


> 4- A beautifully made plug and play harness with OBD plug by @rmn - I hope you can join me in encouraging him to offer these to those who beg


I'll join in the begging. 
Great job guys! @rmn, do you have plans to make the harness available? I'll take one.

@JWardell, is there anything special about the OBD-II bluetooth scanner? I have one of these old ELM327 ones that I used successfully with LeafSpy.


----------



## JWardell

0x6d33 said:


> Great job.
> 
> What kind of phone mount are you using?
> 
> How bad is the data lost with this setup, if any?


My own phone mount:
https://teslaownersonline.com/threads/my-diy-perfect-phone-mount.7877/

I will see how this does with captures. Probably better with a faster phone.



garsh said:


> I'll join in the begging.
> Great job guys! @rmn, do you have plans to make the harness available? I'll take one.
> 
> @JWardell, is there anything special about the OBD-II bluetooth scanner? I have one of these old ELM327 ones that I used successfully with LeafSpy.


It should work, however many of the cheap OBD adapters don't support the secondary high speed CAN bus, and nearly all of them are not fast enough to handle the data rates. We know the OBDlinks worked so I went with that. 
Even then I had to return the first one, and had a long fight with the second yesterday till I found an Android upgrade to install, then things went better.


----------



## Perscitus

With OBDLink LX and MX, its also important to:

a. apply the latest firmware updates (via the OBDLink companion app or Windows firmware updater app)
b. have a fairly recent (say >2017) hardware revision

CAN bus logging has improved exponentially on these over the past few years.

http://www.obdlink.com/support/lxbt/
http://www.obdlink.com/support/mxbt/

_"4- A beautifully made plug and play harness with OBD plug by @rmn 
- I hope you can join me in encouraging him to offer these to those who beg "_

@rmn - I'm officially begging. I think I sent you a ping a few months ago 
when you first developed the harness with the OBD connector. 
I've purchased ScanMyTesla and have both an OBDLink MX and LX and Tactrix OPv2 to test with.


----------



## pavankp

Tmo6 said:


> Can you share a link to the hardware you're using? Thanks! @pavankp


It is definitely overkill for use with a Pi, but this is what I am using.


----------



## sconner

Collin80 said:


> Back on page 31 I posted a bunch of logs that MadModel3Hacker let me post with the VIN removed. They used to be in socketcan format but I converted them to Vector ASC I think. So, I guess that still doesn't really help you a lot. Is your goal to play the log files back with socketcan utilities or what? Is there any hope that some other file format would work?
> 
> EDIT: Previously I said that there wasn't a converter between the files I posted on page 31 and the socketcan format. Actually SavvyCAN does support candump output which should then be directly possible to feed into the linux CAN utilities. It does, however, claim all frames came from vcan0. That's easy enough to change if you need it to point elsewhere. So, you can convert pretty much any of the logs posted so far into candump format using SavvyCAN if you need. Then you can use your preferred tools from there.


I standardized on using the SocketCAN file format about 6 years ago when I started writing CAN decoders for telematic systems. It is much more compact than the other formats and the Linux tools already support it. SavvyCAN is very useful as both a visualization tool and file converter. The latest version supports lots of format exports, so it looks like I am good to go.


----------



## rmn

JWardell said:


> 4- A beautifully made plug and play harness with OBD plug by @rmn - I hope you can join me in encouraging him to offer these to those who beg


There's no need to beg  I will work this weekend on a simple checkout page to place the order for the wire harness. We have both 20 and 26 pin cables with an OBD connector tapping CAN wires as well as 12v and GND.

Sorry If I haven't responded your messages, I am extremely busy and I try to dedicate as much time as I have to contribute to this thread.


----------



## JWardell

pavankp said:


> It is definitely overkill for use with a Pi, but this is what I am using.


I didn't realize @Jack Rickard added the CANDue with Model 3 cable to the EVTV store. Maybe no need to bug @rmn for the cable any more than. Just be aware that cable will not work with the 2019 connector.


----------



## Perscitus

Jake, how will above from Jack work with OBDLink and a 2017/2018 Model 3? Of course no luck for 2019s... for now.


----------



## JWardell

It looks like the EVTV cable is made to plug into their CANDue, in other words it ends in bare wire for CAN and power. You would need a the OBD plug wire it to.
RMN's cable is purpose-built, small cable with OBD plug built in ready to go.

I still would hope to make a small and cheap as possible easy to use transmitter, but that could be a while, one of these cables might suffice for the impatient nerds willing to figure them out.


----------



## pavankp

@JWardell I am trying to read the UI state-of-charge number from the CAN messages. Using your spreadsheet, I am reading 0x292 messages, with the first 10 bits multiplied by 0.1 as the UI SOC. But I am always getting values significantly higher than what the car screen or the Tesla app show. For example, I have my car charging now with the app showing 32%, but the data I am reading from the CAN messages shows 38.x%. Are you able to read this data in a way that matches your car screen display?

Edit: the number shown by the Tesla app and the value I am calculating from the CAN messages seem to move up by the same amounts as the car charges up, but they are off by around 6 percentage points.


----------



## JWardell

pavankp said:


> @JWardell I am trying to read the UI state-of-charge number from the CAN messages. Using your spreadsheet, I am reading 0x292 messages, with the first 10 bits multiplied by 0.1 as the UI SOC. But I am always getting values significantly higher than what the car screen or the Tesla app show. For example, I have my car charging now with the app showing 32%, but the data I am reading from the CAN messages shows 38.x%. Are you able to read this data in a way that matches your car screen display?
> 
> Edit: the number shown by the Tesla app and the value I am calculating from the CAN messages seem to move up by the same amounts as the car charges up, but they are off by around 6 percentage points.


No...the BMS SOCs are internally reduced by the display computer depending on temperature and unknown other factors. You will notice TeslaFi also doesn't read the same SOC as the display.


----------



## pavankp

JWardell said:


> No...the BMS SOCs are internally reduced by the display computer depending on temperature and unknown other factors. You will notice TeslaFi also doesn't read the same SOC as the display.


Thanks! I played with 0x352 messages and it looks like (remaining-buffer)/(full-buffer) is matching the car display. It is warm outside now, will check if it also matches late at night. It doesn't get very cold here though, so I can't really test in a wide range of temperatures.


----------



## pavankp

Here is my take on a HUD for the Model 3 using data from the CAN messages. It shows similar info to what is shown by the car display on the top left.










A closer look at the HUD:









And here is a short video of it in action. 

The things that I am most interested in adding to this are turn signals and navigation next step. I don't know how to get the data for either. Any suggestions are welcome!

I made this using a Raspberry Pi. If people are interested, I can put the code up on github.


----------



## 0x6d33

pavankp said:


> Here is my take on a HUD for the Model 3 using data from the CAN messages. It shows similar info to what is shown by the car display on the top left.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> A closer look at the HUD:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> And here is a short video of it in action.
> 
> The things that I am most interested in adding to this are turn signals and navigation next step. I don't know how to get the data for either. Any suggestions are welcome!
> 
> I made this using a Raspberry Pi. If people are interested, I can put the code up on github.


I'd love for you to put your code on github.

I'm also curious how you made the heads up display.

Keep up the great work!


----------



## JWardell

pavankp said:


> Here is my take on a HUD for the Model 3 using data from the CAN messages. It shows similar info to what is shown by the car display on the top left.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> A closer look at the HUD:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> And here is a short video of it in action.
> 
> The things that I am most interested in adding to this are turn signals and navigation next step. I don't know how to get the data for either. Any suggestions are welcome!
> 
> I made this using a Raspberry Pi. If people are interested, I can put the code up on github.


Love it! Are you just reflecting an LCD display for the PI?
Turn signals are buried in the light status, I can dig up that message for you. Not sure if I can find Nav instructions


----------



## pavankp

Here are some details on how I built this HUD.

I have a Raspberry Pi 3B+ connected over USB to the EVTV CAN monitor for the Model 3. The Pi reads messages over USB serial using Python 3, and extracts relevant data from a handful of CAN messages, and displays them in a GUI using PyGObject. The Pi has a sunlight-readable LCD monitor connected to it over HDMI. The Pi sits in the center console and the HDMI and monitor power cables run under the console side trim. I designed a custom mount for the monitor so it rests on the steering column without blocking anything. The display on the monitor is reversed so it looks normal in reflection. The reflection is through a beam-splitter mirror, for which I made a custom mount to get just the right viewing angle from the driver's seat.

@JWardell thanks, having turn signals show up would be fantastic! Please do let me know if you find a way to get to the Nav instructions. I am also interested in getting the current location (latitude and longitude) so I can determine day-vs-night and adjust the brightness of the LCD based on that. I tried listening for 0x04F messages but they are on the Chassis CAN and I don't know how to get them. Another wishlist item is to get the current cruise speed and whether cruise is enabled. Are those available in CAN messages?

You can find my code at this Github project. I have provided links there for my custom mounts as well as the other hardware I bought for this project.


----------



## pavankp

pavankp said:


> Thanks! I played with 0x352 messages and it looks like (remaining-buffer)/(full-buffer) is matching the car display. It is warm outside now, will check if it also matches late at night. It doesn't get very cold here though, so I can't really test in a wide range of temperatures.


I captured overnight SOC values reported by the Tesla API and they match exactly (when rounded to nearest integer) with the number I calculated from 0x352 messages with the formula above.


----------



## fast_like_electric

pavankp said:


> Here are some details on how I built this HUD.
> 
> I have a Raspberry Pi 3B+ connected over USB to the EVTV CAN monitor for the Model 3. The Pi reads messages over USB serial using Python 3, and extracts relevant data from a handful of CAN messages, and displays them in a GUI using PyGObject. The Pi has a sunlight-readable LCD monitor connected to it over HDMI. The Pi sits in the center console and the HDMI and monitor power cables run under the console side trim. I designed a custom mount for the monitor so it rests on the steering column without blocking anything. The display on the monitor is reversed so it looks normal in reflection. The reflection is through a beam-splitter mirror, for which I made a custom mount to get just the right viewing angle from the driver's seat.
> 
> @JWardell thanks, having turn signals show up would be fantastic! Please do let me know if you find a way to get to the Nav instructions. I am also interested in getting the current location (latitude and longitude) so I can determine day-vs-night and adjust the brightness of the LCD based on that. I tried listening for 0x04F messages but they are on the Chassis CAN and I don't know how to get them. Another wishlist item is to get the current cruise speed and whether cruise is enabled. Are those available in CAN messages?
> 
> You can find my code at this Github project. I have provided links there for my custom mounts as well as the other hardware I bought for this project.


GPS info is on the Chassis CAN bus. Cruise speed and status is on the Party CAN bus. Both of these (as well as the Vehicle bus) are on a common connector at the MCU behind the glove box. Personally I haven't got the courage to dig into that area of the car yet. But if you want that message content for your display, you'd need to tap those buses - and you'd need 3 CAN interfaces for your Pi.

And great job on the display setup. I'm sure all would be interested in the exact parts you chose for the mirror and beam splitter, as well as the code.


----------



## pavankp

fast_like_electric said:


> GPS info is on the Chassis CAN bus. Cruise speed and status is on the Party CAN bus. Both of these (as well as the Vehicle bus) are on a common connector at the MCU behind the glove box. Personally I haven't got the courage to dig into that area of the car yet. But if you want that message content for your display, you'd need to tap those buses - and you'd need 3 CAN interfaces for your Pi.
> 
> And great job on the display setup. I'm sure all would be interested in the exact parts you chose for the mirror and beam splitter, as well as the code.


Thanks. I will then wait on braver and smarter people to figure out how to access those buses. I guess the common connector behind the glove-box will be different from the one to the rear of the center console, so someone needs to figure that out as well. I can do 3D modeling for a connector, but don't know enough about wiring things to take a chance.

Here are all the parts I used:
* Raspberry Pi 3B+
* Sunlight-readable display, e.g. Newhaven Display NHD-7.0-HDMI-N-RSXN-CTU
* CAN harness for the Tesla Model 3 from EVTV
* Beamsplitter mirror 87mm x 157mm, thickness 1/8", transparency 30R/70T, rounded corners
* 3D printed mounts I designed to place the monitor and mirror in the driver's line-of-sight
* Car 12V power splitter to power the Pi and the monitor, while leaving a 12V socket open for other devices
* Compatible car power cable for the monitor, this works with the monitor above
* 5V, 2A car power cable for the Pi, preferably with a switch that you can position just below the center console lid so you can easily toggle the Pi on and off
* HDMI cable that is at least 6 feet long


----------



## amund7

Perscitus said:


> With OBDLink LX and MX, its also important to:
> 
> a. apply the latest firmware updates (via the OBDLink companion app or Windows firmware updater app)
> b. have a fairly recent (say >2017) hardware revision
> 
> CAN bus logging has improved exponentially on these over the past few years.


Can you elaborate on this / should I be concerned? My OBDLink MX has to be more than 10 years old if that's even possible, I have flashed the newest firmwares (for whichever hardware it has), but am I missing out on something important? Have you found any concrete changes to the hardware? I looked at the links you posted but couldn't find anything.


----------



## Perscitus

I think the MX is 'only' about 8-10 years old now. I forget.
I don't believe you have anything to worry about.
The type of CAN traffic we're after here is fairly vanilla, E-OBDII over CAN would be another story.

OBDSolutions recently removed all the good info and a historical log of release notes.
They've gone through a few revisions since your MX. All I can dig up is here:
https://www.scantool.net/downloads/updates/obdlink_mx/ (latest is v4.3.2 for both v1 and v2 hardware and all the subrevs in between)
https://www.scantool.net/scantool/downloads/archive/firmware-updates/

Concensus now is that both the MX and LX are somewhat deprecated. Even recent hardware revisions.
Firmware updates from now on will only introduce bug fixes but no new functionality or protocol, CAN bus messaging support
because of firmware image size limitations. They've solved this with the MX+ but not needed or practical for our use here.


----------



## amund7

Perscitus said:


> I think the MX is 'only' about 8-10 years old now. I forget.
> I don't believe you have anything to worry about.
> 
> Concensus now is that both the MX and LX are somewhat deprecated. Even recent hardware revisions.
> Firmware updates from now on will only introduce bug fixes but no new functionality or protocol, CAN bus messaging support
> because of firmware image size limitations. They've solved this with the MX+ but its wifi so not practical for our use here.


I found my original receit, I bought my MX in 2013. It's starting to pay itself off now 

MX+ is bluetooth, it doesn't have wifi at all.
They call it 'professional', but the only difference listed in their own comparison chart, compared to the original MX, is that it 'supports all IOS devices'... which probably means it also supports BLE in addition to 'old' Bluetooth ? And it has some kind of 'free OEM add-on', probably for their PC software ?
http://www.obdlink.com/mxp/ (click 'Compare')

And, as the diff between LX, MX and MX+ is some free software and GM and Ford protocols, for our use, LX should give us exactly the same performance at a much better price. They are all rated at ~100 PIDs a second, I find with Model 3 my MX gives me ~500 CAN packets a second! Which can then be multiplied by a bunch of signals per packet. Then we are talking quite a package for $50.


----------



## Perscitus

Agreed LX is more than enough for Tesla duty. Waiting on @rmn now to order the harness.


----------



## JWardell

amund7 said:


> I found my original receit, I bought my MX in 2013. It's starting to pay itself off now
> 
> MX+ is bluetooth, it doesn't have wifi at all.
> They call it 'professional', but the only difference listed in their own comparison chart, compared to the original MX, is that it 'supports all IOS devices'... which probably means it also supports BLE in addition to 'old' Bluetooth ? And it has some kind of 'free OEM add-on', probably for their PC software ?
> http://www.obdlink.com/mxp/ (click 'Compare')
> 
> And, as the diff between LX, MX and MX+ is some free software and GM and Ford protocols, for our use, LX should give us exactly the same performance at a much better price. They are all rated at ~100 PIDs a second, I find with Model 3 my MX gives me ~500 CAN packets a second! Which can then be multiplied by a bunch of signals per packet. Then we are talking quite a package for $50.


But it's "hacker-proof!" So apparently we're not allowed to use it


----------



## Perscitus

@rmn - im... patiently waiting for our beautifully made plug and play harnesses with OBD plug. Can't wait to start monitoring and logging using ScanMyTesla.


----------



## rmn

Perscitus said:


> @rmn - im... patiently waiting for our beautifully made plug and play harnesses with OBD plug. Can't wait to start monitoring and logging using ScanMyTesla.


We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


----------



## boatbuild

Waiting too


----------



## 0x6d33

Looks like the new HW3 computer is using two NXP TJA1043 CAN transceiver and four NXP TJA1059 Dual high-speed CAN transceiver.

I can't seem to locate the controller.

You can see a high resolution image of the board here: https://i.redd.it/bpu7endf0xt21.jpg


----------



## Frully

I'm looking forward to getting stuff like this going. Don't care much for the logging but I do want to add addressable LED strands here and there...and having enough data from the car to accurately animate 'going to plaid' is basically necessary.


----------



## JWardell

0x6d33 said:


> The CAN transceiver can be found here:
> 
> ESP32:
> 
> If you don't have any handy, gets some female to female wires.


Has anyone had luck uploading Arduino code to this HiLetgo ESP32 board? @Tmo6 @0x6d33 ? 
I know I'm connected as I see it continuously spitting out WiFi network scans in the serial monitor. Node32s board is selected in Arduino. When I program I just get
Connecting........_____....._____....._____....._____....._____....._____....._____

A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header


----------



## Roci

JWardell said:


> Has anyone had luck uploading Arduino code to this HiLetgo ESP32 board? @Tmo6 @0x6d33 ?
> I know I'm connected as I see it continuously spitting out WiFi network scans in the serial monitor. Node32s board is selected in Arduino. When I program I just get
> Connecting........_____....._____....._____....._____....._____....._____....._____
> 
> A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header


Pin GPIO 0 has to be connected to GND to enter programming mode. You can also press and hold the IO0 button on the board which does the same thing.


----------



## JWardell

Roci said:


> Pin GPIO 0 has to be connected to GND to enter programming mode. You can also press and hold the IO0 button on the board which does the same thing.


It works! Thank you!!
You think they would have documented that somewhere...
Could not pair with my iPhone but paired with cheap android phone and now communicating with bluetooth serial terminal! Sweet!
Now the much more difficult task of pairing with OBDlink.


----------



## Collin80

JWardell said:


> It works! Thank you!!
> You think they would have documented that somewhere...
> Could not pair with my iPhone but paired with cheap android phone and now communicating with bluetooth serial terminal! Sweet!
> Now the much more difficult task of pairing with OBDlink.


Apple, in their infinite wisdom, decided that things like standards and proper inter-operability over bluetooth are not something to aspire to. As such you really can't use generic bluetooth devices with an Apple device. Generic bluetooth serial just plain doesn't work. If you want to use an ESP32 to talk to an iPhone/iPad you'll want to use either BLE or WiFi. And, since BLE is slow you probably want to use WiFi.


----------



## JWardell

Collin80 said:


> Apple, in their infinite wisdom, decided that things like standards and proper inter-operability over bluetooth are not something to aspire to. As such you really can't use generic bluetooth devices with an Apple device. Generic bluetooth serial just plain doesn't work. If you want to use an ESP32 to talk to an iPhone/iPad you'll want to use either BLE or WiFi. And, since BLE is slow you probably want to use WiFi.


I knew that, yet was shocked to find the suggested bluetooth com app. Not sure what it can be used with.
But in my case it doesn't matter, I'm not looking to make phone apps.


----------



## Perscitus

rmn said:


> We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


Friday bump. Please take our money!


----------



## mishari

fast_like_electric said:


> If the objective is video substitution (or overlay) on the main screen, there are four points that could be used...
> 
> 1) Backup camera digital video serial feed
> 2) Digital video serial link between auto-pilot ECU to main computer
> 3) Digital video/data link between main computer and display interface board
> 4) Raw digital panel input between display interface board and LCD
> 
> Pros and cons with each. Option 1 probably easiest and most accessible, but likely only useful when used for the 'movies in park' sort of application. This due to the usage of the rear camera now for AP and blind spot detection - different or overlayed video will foul up that function when driving. Option 3 is difficult because the signalling is two way - video to the display, and touch to the main computer - all over the same coax, not a generic standard.
> 
> Option 2 or 4 likely the best, depending if you want to take over the whole screen area or just the back-up camera display area. But you'd be digging into the computer and/or display - not something for the faint of heart.


Has anyone attempted this? I'm interested in taking this on as a project. In the above comment, @fast_like_electric, you said option 3 is difficult. I haven't looked at the wiring diagram yet, but how hard is that harness to access? I'm considering option 3 because ideally I'd like to be able to read touch data as well as overlay video. That way it would be possible to interact with the overlay via the screen. Is it possible to separate the two signals, maybe by processing them before they reach the screen?

I'm new here, but you guys seem to be doing great work, so thank you!


----------



## fast_like_electric

mishari said:


> Has anyone attempted this? I'm interested in taking this on as a project. In the above comment, @fast_like_electric, you said option 3 is difficult. I haven't looked at the wiring diagram yet, but how hard is that harness to access? I'm considering option 3 because ideally I'd like to be able to read touch data as well as overlay video. That way it would be possible to interact with the overlay via the screen. Is it possible to separate the two signals, maybe by processing them before they reach the screen?
> 
> I'm new here, but you guys seem to be doing great work, so thank you!


I've not seen mention here of anyone tapping into the video feeds on this thread (yet). There was a Model S/X backup camera substitution product mentioned with some talk perhaps making a Model 3 version - not sure if there's been any progress there.

Going at it from the connection between the MCU and the screen assembly is challenging from a few levels. First you have to take apart the surround for either the MCU (by the glovebox) or the center display. Then when you access the connector (either end), you'll see it is quite an oddball, with a couple pairs of differential wiring as well as power and ground. You then need to decipher the LVDS signalling rates and data content on those lines, which is more involved given the two way comms (video out, touch sent back). And finally you'd need to have some sort of device which could output, switch, and/or overlay digital video over that interface - with the proper connectors.

Of course doable, but definitely some hurtles. The backup camera input being easiest physically and electrically, but with the drawback of not being a good idea to mess with while driving - given its usage for blind spot monitoring and other driver assistance. The old fashioned way of getting at the video directly at the LCD is probably the 2nd easiest, but you'd need to crack open the main UI for the car. I know I would be squeamish about doing that for this car - being the only control for everything in the car.


----------



## mishari

fast_like_electric said:


> I've not seen mention here of anyone tapping into the video feeds on this thread (yet). There was a Model S/X backup camera substitution product mentioned with some talk perhaps making a Model 3 version - not sure if there's been any progress there.
> 
> Going at it from the connection between the MCU and the screen assembly is challenging from a few levels. First you have to take apart the surround for either the MCU (by the glovebox) or the center display. Then when you access the connector (either end), you'll see it is quite an oddball, with a couple pairs of differential wiring as well as power and ground. You then need to decipher the LVDS signalling rates and data content on those lines, which is more involved given the two way comms (video out, touch sent back). And finally you'd need to have some sort of device which could output, switch, and/or overlay digital video over that interface - with the proper connectors.
> 
> Of course doable, but definitely some hurtles. The backup camera input being easiest physically and electrically, but with the drawback of not being a good idea to mess with while driving - given its usage for blind spot monitoring and other driver assistance. The old fashioned way of getting at the video directly at the LCD is probably the 2nd easiest, but you'd need to crack open the main UI for the car. I know I would be squeamish about doing that for this car - being the only control for everything in the car.


I definitely would not want to open up the screen, I'll most certainly mess something up haha. While getting to the connector may be somewhat of a challenge I think the main bottleneck is deciphering those signals. For the "middle man" device I'm thinking a raspberry pi has the appropriate ports (and GPIO pins) but might produce a laggy UI.

I have found multiple sources for converting LVDS to HDMI and vice versa. Not sure how that would work with the touch data though.


----------



## Collin80

mishari said:


> I definitely would not want to open up the screen, I'll most certainly mess something up haha. While getting to the connector may be somewhat of a challenge I think the main bottleneck is deciphering those signals. For the "middle man" device I'm thinking a raspberry pi has the appropriate ports (and GPIO pins) but might produce a laggy UI.
> 
> I have found multiple sources for converting LVDS to HDMI and vice versa. Not sure how that would work with the touch data though.


To get enough speed for such things usually the solution is to use an FPGA. I believe that's why at least the earlier Model S displays had FPGAs on them. They used them to splice backup camera video over the displayed screen. An FPGA can be plenty fast enough to do signal translation, editing, and re-encoding on the fly without causing any noticeable lag. But, they're a bit more complicated to set up and code for as well.


----------



## Jack Rickard

Video

Tesla Model3 Vehicle CAN bus adapter with ESP32 wifi and J1962 connecteor. This VIDEO shows a Android TORQUEPRO app. We're using SavvyCAN to playback Josh Wardell's AccelCAN.csv logfile to the device using WiFi TCP/IP.
The device acts as an AP itself. And the Android tablet links to the adapter via WiFi TCP/IP as well to get the J1979 PID data normally available on OBDII.

V


----------



## 0x6d33

Collin80 said:


> To get enough speed for such things usually the solution is to use an FPGA. I believe that's why at least the earlier Model S displays had FPGAs on them. They used them to splice backup camera video over the displayed screen. An FPGA can be plenty fast enough to do signal translation, editing, and re-encoding on the fly without causing any noticeable lag. But, they're a bit more complicated to set up and code for as well.


Speaking of FPGA, I've been working on a CAN reader implemented in an FPGA. It decodes the CAN data from the transceiver and sends the decode message in ASCII over a UART at 1 Mbit/sec. Since the UART is running at twice the speed of the CAN bus, there should be no data loss.

I've got it mostly working at this point. There just a few bugs I need to iron out. In addition, I need to add CRC checking.

My motivation is to accurately measure the amount of CAN message sent per second.


----------



## fast_like_electric

Jack Rickard said:


> Video
> 
> Tesla Model3 Vehicle CAN bus adapter with ESP32 wifi and J1962 connecteor. This VIDEO shows a Android TORQUEPRO app. We're using SavvyCAN to playback Josh Wardell's AccelCAN.csv logfile to the device using WiFi TCP/IP.
> The device acts as an AP itself. And the Android tablet links to the adapter via WiFi TCP/IP as well to get the J1979 PID data normally available on OBDII.


Nice.

One of the limitations with J1979 PIDs is that they are designed for non-EVs, and they don't support the full suite of EV parameters like kW Power or traction battery voltage. So to convey those, that information has to be sent on other re-purposed PIDs.

Based on your gauge display, it looks like you've chose to use something like the Evap. System Vapor Pressure (in Pa) PID for kW Power, and something else for traction battery voltage. For the re-purposed PIDs that the device is supplying, are the mappings detailed somewhere? That would be info that people need when marrying this device to OBDII apps such as Torque or otherwise.


----------



## Jack Rickard

Yes of course. We have a PDF on the web site with full details of all the PIDS we currently use. And rather a lot of other information about using SavvyCAN etc.

http://store.evtv.me/proddetail.php?prod=Model3OBDII

Jack Rickard


----------



## thezim

rmn said:


> We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


 I have a fist full of cash when you are ready.


----------



## JWardell

Jack Rickard said:


> Yes of course. We have a PDF on the web site with full details of all the PIDS we currently use. And rather a lot of other information about using SavvyCAN etc.
> 
> http://store.evtv.me/proddetail.php?prod=Model3OBDII
> 
> Jack Rickard


Thanks for documenting all of that (and extensive SavvyCAN documentation!)
You fake some PIDS with understandably related ICE vales, like HV Battery->Fuel pressure and kW->air pressure, but how are you getting the Android OBD app to display these with proper scale and V&kW labels?


----------



## Feathermerchant

I think in the torque app you can change the display units and use math.


----------



## Perscitus

rmn said:


> We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


@rmn -any updates?


----------



## Jack Rickard

JWardell said:


> Thanks for documenting all of that (and extensive SavvyCAN documentation!) displa
> You fake some PIDS with understandably related ICE vales, like HV Battery->Fuel pressure and kW->air pressure, but how are you getting the Android OBD app to display these with proper scale and V&kW labels?


Well I'm not exactly. You can change the scale on any display quite easily and often I'm changing the Title of the gage to be the proper units while generally failing to change the units. This is how you wind up with HORSEPOWER looking like it is in grams/second.

But actually, if you use the custom PID editor, you can even change that. If we could get 0x410 back we could do a whole set of custom PID extensions to show each cell voltage in theory.

Jack


----------



## JWardell

Uncle Rich gives us a nice tour of @Ingineer 's Tesla computer hacking operations!


----------



## hungyip84

Can anyone help me confirm if this 26 pin connector is wired correctly?


----------



## sigurdi

*JWardell*
You asked if someone have been working on their own PCB with WSP32 and CAN in a smaler form factor.
We have been moving over to the ESP32 and done testing for the last 7 months or so, the most work is to test different power supplies and filter to avoid noise to disturb to the CAN.
On our old PCB we have experienced error messages on Model S and X, and typical older models is more sensitive than newer and special on some CAN transceivers (MCB based)
(Never had any problems with TJA transceivers)

The prototype PCB is 5x5cm as this is the same form factor as our other boards. (Home and boat automation, 485 and some other devices.)
8-30v DC input and 3.3 and 5v power available at the board.
Use a RJ45 port to power display with a reset button, since the unit will be hidden away and display used for information while driving.
I only have one of the first prototypes at home for the moment, since the rest is out on the road to live testing and Aamund have one if he wanted to use it for Scan My Tesla.
(A typo on the PCB and the power supply was wrong way and then wires, but prototypes is prototypes.

So far it looks very stable and had no problems with error messages on any cars.
(No test on model 3 at the moment)
When the initial hardware testing is OK we will look at form factor used and shrink it accordingly before external production.
Have not deiced if it will be with a universal connector, pigtail that can be connected to the different diagnose plugs or dedicated connected to the different diagnose plugs.
As you can se the ESP testing here have both "internal" and external antenna support (testing range comparing, speed...)

Thanks to Colling for his library that we are using at the moment.


----------



## sigurdi

hungyip84 said:


> Can anyone help me confirm if this 26 pin connector is wired correctly?


For what I can see you have connected the following:

15 - Red - 12v Battery Input (USB Port Front) (Remember this is 2mm2 cable and can deliver some power Pin 1 is 12v to 12v power socket and also 2mm2))
18 - Blue - Vehicle Can + (High)
19 - Yellow - Vehicle Can - (low)
26 - Black - 12v Power Socket Ground Return (14 and 7 is also ground)

PS have you a name on the 26 pin connector.
(Have not found it in Sumitomo connector list)


----------



## Jack Rickard

hungyip84 said:


> Can anyone help me confirm if this 26 pin connector is wired correctly?
> 
> View attachment 25740
> View attachment 25741
> View attachment 25742


I keep seeing these and references to "working on" an adapter for the post January 2019 version of the x930 connector on the Model 3. But I never seem to see the part numbers or manufacturers of these connectors or the terminals in them. Why is that?

Jack Rickard


----------



## sigurdi

Jack Rickard said:


> I keep seeing these and references to "working on" an adapter for the post January 2019 version of the x930 connector on the Model 3. But I never seem to see the part numbers or manufacturers of these connectors or the terminals in them. Why is that?
> 
> Jack Rickard


It is a Sumitomo and looks like the same family as the 6098-5620 that is as diagnostic port on S, X and X930 on 3 until 09.01.19. 
This is a TS Hybrid series with 16+4 0,64 and 1.5mm2

The problem I see is that Tesla is using 22 + 4 and totally 26 pins connector that do not exist in Sumitomo parts lists in TS Hybrid series. 
1, 14, 15 and 26 is 2mm2 and the rest is less than 0.5mm2

The looks design.... is just like the ts series and I guess it is a new connector.

Tesla have not updated their Conector referance for the SOP3 and not possible to look it up.


----------



## JWardell

sigurdi said:


> *JWardell*
> You asked if someone have been working on their own PCB with WSP32 and CAN in a smaler form factor.
> We have been moving over to the ESP32 and done testing for the last 7 months or so, the most work is to test different power supplies and filter to avoid noise to disturb to the CAN.
> On our old PCB we have experienced error messages on Model S and X, and typical older models is more sensitive than newer and special on some CAN transceivers (MCB based)
> (Never had any problems with TJA transceivers)
> 
> The prototype PCB is 5x5cm as this is the same form factor as our other boards. (Home and boat automation, 485 and some other devices.)
> 8-30v DC input and 3.3 and 5v power available at the board.
> Use a RJ45 port to power display with a reset button, since the unit will be hidden away and display used for information while driving.
> I only have one of the first prototypes at home for the moment, since the rest is out on the road to live testing and Aamund have one if he wanted to use it for Scan My Tesla.
> (A typo on the PCB and the power supply was wrong way and then wires, but prototypes is prototypes.
> 
> So far it looks very stable and had no problems with error messages on any cars.
> (No test on model 3 at the moment)
> When the initial hardware testing is OK we will look at form factor used and shrink it accordingly before external production.
> Have not deiced if it will be with a universal connector, pigtail that can be connected to the different diagnose plugs or dedicated connected to the different diagnose plugs.
> As you can se the ESP testing here have both "internal" and external antenna support (testing range comparing, speed...)
> 
> Thanks to Colling for his library that we are using at the moment.


Very nice, it is already very small!
I'm still trying to connect ESP32 to a standard ODBII adapter if possible.


----------



## Perscitus

rmn said:


> We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


@rmn -any updates? Going twice.... its mid May already.


----------



## bearbu

Is there any sort of CAN signal required to power up the infotainment board and the Autopilot board by an external 12V power supply?

I had bought the ECU (actually it’s a combination of Infotainment board and Autopilot board) and I tried to power it up by external 12V supply (not from the car) but failed. The board couldn’t powered up , so I guess there are some sort of command/signals for power up sequence 


Sent from my iPhone using Tapatalk


----------



## JWardell

bearbu said:


> Is there any sort of CAN signal required to power up the infotainment board and the Autopilot board by an external 12V power supply?
> 
> I had bought the ECU (actually it's a combination of Infotainment board and Autopilot board) and I tried to power it up by external 12V supply (not from the car) but failed. The board couldn't powered up , so I guess there are some sort of command/signals for power up sequence
> 
> Sent from my iPhone using Tapatalk


That's something I think only @Ingineer could answer for sure as he is the only one that has had the MCU out on a table (or maybe @Jack Rickard ?)
But I would think the computer would power up if it had power, there is no reason to keep it unpowered until it has data, it is just a linux computer.
Is there any chance there is more than one power input, some other wire that also needs 12v?
Think of car stereos that needed both the battery connection and the ignition wire and will only turn on with both powered.


----------



## TomT

Also (kind of) patiently waiting...



rmn said:


> We have the checkout page ready, just waiting on a few assembly costs to determine final price. Should be ready this week


----------



## Bernd

Is there any news about an adaptor for the Blue Color (X930) console connectors for the 2019 Model 3 enabling access to the CANBus/ ODB2? Something similar to HRN-CT20T1?


----------



## Perscitus

Nein, nein gibt es nicht. Auch fur die alteren autos wird nichts am stecker benotigt.


----------



## Jack Rickard

As I noted. THere seems to be some "state secret" here in this forum about the post January 2019 x930 connector. Several have mentioned they are almost ready to release one,but seem to consider it proprietary information?

The Toyota connectors are of course made by Yazaki. I made you a little diagram with the Yazaki part numbers. Yazaki likes to sell 100,000 of something to OEMs so they are a little hard to source. But here's the stuff.

Collin has also made a pretty strong advance on the ESP32_CAN library in the past couple of days. Get the latest on github/collin80.


----------



## Jack Rickard

Latest Torque display.


----------



## juanmax

JWardell said:


> ​​Currently known CAN data spreadsheet​​Model 3 DBC file​​


​
Hi Wardell,

Nice work! Thanks a lot!

I found out two signals are wrong in the dbc. The correction is found here: (offset negative, signed value type). With this changes my model 3 performance shows currents up to (well, actually down to) -1200A. With the current dbc you linked, clipping occurs at 900A

I am still struggling to find wheel speeds on this bus. How can it be that there are nowhere to be found? Also tried chassis CAN.


----------



## JWardell

juanmax said:


> ​
> Hi Wardell,
> 
> Nice work! Thanks a lot!
> 
> I found out two signals are wrong in the dbc. The correction is found here: (offset negative, signed value type). With this changes my model 3 performance shows currents up to (well, actually down to) -1200A. With the current dbc you linked, clipping occurs at 900A
> 
> I am still struggling to find wheel speeds on this bus. How can it be that there are nowhere to be found? Also tried chassis CAN.
> 
> View attachment 26105


I'll have a look. What firmware rev do you have? There is a chance things have changed recently. Also if you're able to log some acceleration, I think we don't have that from a M3P


----------



## juanmax

JWardell said:


> I'll have a look. What firmware rev do you have? There is a chance things have changed recently. Also if you're able to log some acceleration, I think we don't have that from a M3P


12.1.2 in the Performance, an older one in the AWD. The offset, scaling and datatype that you have fits an AWD (since only goes up to 900A) however when I saw the measurement on the performance, clipping was occurring. I do not think this changed in the last versions, simply was wrong from the beginning (coincidence that worked out OK for non-performance value ranges). I have never seen a negative factor in a dbc signal scaling 

I have a acceleration log from my performance from 0-150-0. Do you want me to upload it somewhere or just post a diagram?


----------



## JWardell

juanmax said:


> 12.1.2 in the Performance, an older one in the AWD. The offset, scaling and datatype that you have fits an AWD (since only goes up to 900A) however when I saw the measurement on the performance, clipping was occurring. I do not think this changed in the last versions, simply was wrong from the beginning (coincidence that worked out OK for non-performance value ranges). I have never seen a negative factor in a dbc signal scaling
> 
> I have a acceleration log from my performance from 0-150-0. Do you want me to upload it somewhere or just post a diagram?


Sure, if you can find a way to compress and upload it somewhere and don't mind sharing.
I'm back on public firmware but waiting till I put my summer tires on before I do any new recordings and see if anything has changed since the winter.


----------



## energee

*Jack Rickard *What is that surface mount connector that matches the card reader from your video?


----------



## energee

BTW guys, I have access to all three CANs, are there any specific messages you are looking for?


----------



## juanmax

Hey energee, i am very interested in the Party and vehicle can. Specially all messages coming from the inverter. If you can not share publicily please send me a PM


----------



## juanmax

I will Post tomorrow the details about the wheel speeds. I found them in the Party CAN


----------



## JWardell

energee said:


> BTW guys, I have access to all three CANs, are there any specific messages you are looking for?


...all of them?  We have never seen a capture from party can, are you willing to upload a quick drive log with that? Or share where you found a good place to tap in?


----------



## 0x6d33

juanmax said:


> I will Post tomorrow the details about the wheel speeds. I found them in the Party CAN


Where is the Party CAN located?


----------



## juanmax

in the rear inverter connector


----------



## juanmax

This messages are in the party CAN, but also found in the chassis CAN.


----------



## energee

JWardell said:


> ...all of them?  We have never seen a capture from party can, are you willing to upload a quick drive log with that? Or share where you found a good place to tap in?


Yes, I tapped at the MCU, I can do a quick log for sure


----------



## Jack Rickard

energee said:


> *Jack Rickard *What is that surface mount connector that matches the card reader from your video?


I'm a little lost on the question. Which video? What surface mount connector? And what card reader?


----------



## juanmax

Hi,

as promised here some logs 
Model 3 AWD log with party(1) and vehicle(2) CAN
Model 3 Perf vehicle CAN (acceleration 0-150-0 in Track Mode)

I am struggling to find out which algorithm Tesla is using to calculate the CRC (Checksum). Does anybody here have an idea or hint? I tried different SAE Standards but no luck. For example here (0x108):


----------



## fast_like_electric

energee said:


> Yes, I tapped at the MCU, I can do a quick log for sure


We look forward to your logs.

MPU connector is the best place, as it has all three buses. Can you describe your particular approach to getting the bus connections? Made an adapter harness, spliced the wiring, took out the MCU and soldered to it, etc?

Any detail on how to easily get at that area of the car would be beneficial as well - photos, etc. Several of us have wanted to get at those buses over there, but are a bit gun shy since it it harder to get at vs. the easy access vehicle bus behind the console.


----------



## Jack Rickard

energee said:


> *Jack Rickard *What is that surface mount connector that matches the card reader from your video?


Finally figured out what you were asking about. The connectors to the security controller under the coffee cup.

TE Connectivity

Plug Pins NANOMQS 1-1703930-1

Plug Housing 12POS NANO MQS TL PLUG HOUSING 2177587-1

Header assembly for circuit board.
2POS,TAB 0.5X0.4,HEADER ASSY,CO 2177370-3


----------



## JWardell

juanmax said:


> ​
> Hi Wardell,
> 
> Nice work! Thanks a lot!
> 
> I found out two signals are wrong in the dbc. The correction is found here: (offset negative, signed value type). With this changes my model 3 performance shows currents up to (well, actually down to) -1200A. With the current dbc you linked, clipping occurs at 900A
> 
> I am still struggling to find wheel speeds on this bus. How can it be that there are nowhere to be found? Also tried chassis CAN.
> 
> View attachment 26105


If they are signed but with the offsets you mention, then there will be a 638A limit so I don't think that is right. But if I flip the factors and offset it all makes sense:









I suppose it is a matter of opinion but I consider positive current coming out of the battery and negative current when charging.


----------



## JWardell

juanmax said:


> This messages are in the party CAN, but also found in the chassis CAN.
> 
> View attachment 26161
> 
> View attachment 26162


I'm very curious how you determined these, and also what are the units?
I tried adding this and using my short chassis capture. I think the wheel speeds make sense, they are always positive even when driving in reverse. I assume they are in RPM?
Is wheel angle the angle of each wheel? I assumed that and converted 8 bit to 360 degrees. Not sure if that is right. I have not captured this signal (is it party CAN only?) so can't confirm. Does this look right?


----------



## amund7

juanmax said:


> 12.1.2 in the Performance, an older one in the AWD. The offset, scaling and datatype that you have fits an AWD (since only goes up to 900A) however when I saw the measurement on the performance, clipping was occurring. I do not think this changed in the last versions, simply was wrong from the beginning (coincidence that worked out OK for non-performance value ranges). I have never seen a negative factor in a dbc signal scaling
> 
> I have a acceleration log from my performance from 0-150-0. Do you want me to upload it somewhere or just post a diagram?


I've used the Model S formula (from WK057) since the beginning:



Code:


 1000 - ((Int16)((((bytes[3]) << 8) + bytes[2]))) / 10.0

That should give a range from -2276.7 to +4276.7 if I am thinking straight ? 
- is charge or regen, + is discharge (drive).
This formula is tried and true with Model S and X, never heard of wrapping even with P100D luda.

Same formula for S, X and 3 in Scan My Tesla and Canbus Analyzer.


----------



## fast_like_electric

JWardell said:


> I'm very curious how you determined these, and also what are the units?
> I tried adding this and using my short chassis capture. I think the wheel speeds make sense, they are always positive even when driving in reverse. I assume they are in RPM?
> Is wheel angle the angle of each wheel? I assumed that and converted 8 bit to 360 degrees. Not sure if that is right. I have not captured this signal (is it party CAN only?) so can't confirm. Does this look right?


0x155 (on the chassis bus) contains individual wheel rotation pulse counts. AKA, the magnetic tone sensor pickup as the wheels spin. They are 4 single byte rolling counters based on the wheel revolutions. You'll see these as uninitialized to 0xFF at the start of a drive, then right to zero, then count (and roll over) as you drive forward or back.


----------



## juanmax

Exactly


----------



## juanmax

amund7 said:


> I've used the Model S formula (from WK057) since the beginning:
> 
> 
> 
> Code:
> 
> 
> 1000 - ((Int16)((((bytes[3]) << 8) + bytes[2]))) / 10.0
> 
> That should give a range from -2276.7 to +4276.7 if I am thinking straight ?
> - is charge or regen, + is discharge (drive).
> This formula is tried and true with Model S and X, never heard of wrapping even with P100D luda.
> 
> Same formula for S, X and 3 in Scan My Tesla and Canbus Analyzer.


Well, I just played with the offset, gain and data type beacause the log from the performance acceleration was showing overrun in that signal. I do not have a sign convention preference, just wanted to fix the wrapping around.


----------



## juanmax

JWardell said:


> I'm very curious how you determined these, and also what are the units?


with the factor I posted, the units would be kph. Same format (and actually even message identifier) than in the model X.


----------



## JWardell

fast_like_electric said:


> 0x155 (on the chassis bus) contains individual wheel rotation pulse counts. AKA, the magnetic tone sensor pickup as the wheels spin. They are 4 single byte rolling counters based on the wheel revolutions. You'll see these as uninitialized to 0xFF at the start of a drive, then right to zero, then count (and roll over) as you drive forward or back.


I just realized I typed in 55 instead of 155 so that's why I didn't see them. Don't rush technical work at the end of a Friday...

If they are just counters and not angle then they really just represent raw speed then I guess.


----------



## fast_like_electric

JWardell said:


> I just realized I typed in 55 instead of 155 so that's why I didn't see them. Don't rush technical work at the end of a Friday...
> 
> If they are just counters and not angle then they really just represent raw speed then I guess.


In 0x155, the signals are not raw speed nor angle - they are only wheel rotation pulse counters. However, you can derive wheel speeds from the time between the last message, and the difference in the respective pulse count (for each wheel).

0x175 contains the wheel speeds, as was mentioned.


----------



## Jack Rickard

juanmax said:


> Hi,
> 
> as promised here some logs
> Model 3 AWD log with party(1) and vehicle(2) CAN
> Model 3 Perf vehicle CAN (acceleration 0-150-0 in Track Mode)
> 
> I am struggling to find out which algorithm Tesla is using to calculate the CRC (Checksum). Does anybody here have an idea or hint? I tried different SAE Standards but no luck. For example here (0x108):
> 
> View attachment 26166


Thankee, thankee, thankee.

We had a number of mistakes in our CAN decoding - mostly with sign extensions on 11 and 13 bit numbers. And we didn't really have any
way to test front wheel drive torque and power and horsepower and so forth for our CAN adapter and TorquePro setup.

Your "performance model" AWD rocked my world. I had no idea. This thing is showing -1200 amps, 800+ horsepower and just values of torque and kW I've never
seen in a Model3 with my own eyes. We got all the front drive unit stuff tested and it's showing very reasonable numbers.

Jack Rickard
http://evtv.me


----------



## Jack Rickard

JWardell said:


> If they are signed but with the offsets you mention, then there will be a 638A limit so I don't think that is right. But if I flip the factors and offset it all makes sense:
> View attachment 26174
> 
> 
> I suppose it is a matter of opinion but I consider positive current coming out of the battery and negative current when charging.


Well it certainly is arbitrary. And so I suppose I agree it's all about point of view. I view current DISCHARGE or negative values as power going OUT of the battery. Regenerative braking causes positive current values INTO the battery.
Tesla is doing that on the Model 3 and they have since the first Model S deliveries.

Conversely,. power and torque are generally treated as positive values while accelerating and negative during regenerative braking.

So Tesla shares my point of view which is basically the point of view of the battery. I'm always about the batteries and whatever they see is what I assume I see. Putting out current is a negative. Getting current in is a positive. If you're a battery. In any event,. my math doesn't have a problem with large values of negative current and the offset seems to favor them. On the performance model I'm seeing as much as 215A of positive regen and over -1200 amps clearly on acceleration. And close to 400kw of power holding at 325volts.


----------



## Jack Rickard

juanmax said:


> Well, I just played with the offset, gain and data type beacause the log from the performance acceleration was showing overrun in that signal. I do not have a sign convention preference, just wanted to fix the wrapping around.


I noticed the same thing in both our OBDII adapter and the SavvyCAN graphing function. Here's what we went to and seem to be getting smooth and rational values from your "performance" log now.

model3.hvBatteryCurrent=((int16_t)(msg.data.s1<<1))*0.05f-1000;

model3.hvBatteryCurrent is a standard 32 bit float variable. msg.data.s1 is bytes 3 and 4 of CAN message 0x132. We left shift the value to put the sign bit in position 16 of a signed 16-bit integer. Then we divide by 2 to get the value back to correct when we do the scaling at 0.05 instead of 0.1.

I'm now reading smooth readings from 215amps during max regen to about -1225 amps during max acceleration without that big ugly block we were seeing in the middle at something ridiculous like +2400 amps.


----------



## Jack Rickard

Jack Rickard said:


> I noticed the same thing in both our OBDII adapter and the SavvyCAN graphing function. Here's what we went to and seem to be getting smooth and rational values from your "performance" log now.
> 
> model3.hvBatteryCurrent=((int16_t)(msg.data.s1<<1))*0.05f-1000;
> 
> model3.hvBatteryCurrent is a standard 32 bit float variable. msg.data.s1 is bytes 3 and 4 of CAN message 0x132. We left shift the value to put the sign bit in position 16 of a signed 16-bit integer. Then we divide by 2 to get the value back to correct when we do the scaling at 0.05 instead of 0.1.
> 
> I'm now reading smooth readings from 215amps during max regen to about -1225 amps during max acceleration without that big ugly block we were seeing in the middle at something ridiculous like +2400 amps.


CORRECTION:

I guess msg.data.S1 is actually bytes 2 and 3 of CAN message 0x132. NOT 3 and 4.


----------



## juanmax

Jack Rickard said:


> Thankee, thankee, thankee.


I have to thank you Jack. I wrote you from my company email(GKN) asking for collaboration on model 3 hacking but you had other priorities which I respect. However I really have to thank you about the savvy hint and you motivated us to do it ourselves. Let's see wether we can find out the CRC algorithm, otherwise the project will not go further (which is a pity, since I am open to share with the community plenty of what we will find out, including winter testing in sweden )


----------



## Jack Rickard

juanmax said:


> I have to thank you Jack. I wrote you from my company email(GKN) asking for collaboration on model 3 hacking but you had other priorities which I respect. However I really have to thank you about the savvy hint and you motivated us to do it ourselves. Let's see wether we can find out the CRC algorithm, otherwise the project will not go further (which is a pity, since I am open to share with the community plenty of what we will find out, including winter testing in sweden )





juanmax said:


> I have to thank you Jack. I wrote you from my company email(GKN) asking for collaboration on model 3 hacking but you had other priorities which I respect. However I really have to thank you about the savvy hint and you motivated us to do it ourselves. Let's see wether we can find out the CRC algorithm, otherwise the project will not go further (which is a pity, since I am open to share with the community plenty of what we will find out, including winter testing in sweden )


Well I'm glad to see you are coming along with it. As to my participation in a CAN hacking project for Model 3, I am somewhat not a master of my own time and attention these days. It's reached the point where I deal with whatever fire is burning highest at the moment. We have more projects than we can say grace over now and I suffer a feeling of overwhelmed at each entry to the shop. The piles of things I really want to work on are just accusing. Then too, this is a beast of my own making. I have the attention span of a four-year-old. Ooohhh. Doughnuts....

Obviously you don't need to decode checksums to discern the meaning of incoming CAN bytes, so you must be trying to send some and want them to be valid. I just really don't know what that might be in the case of the Model 3. But on the Model S, we did occasionally have to do such to control the drive unit. I started by making tables of actual values in different situations. Tesla usually uses a counter somewhere in the 8 bytes, often just a four bit counter. Then it calculates the checksum using the values it is sending, plus the counter. So both the values change, but so does the counter with each message and you can use the counter and a polynomial checksum to ensure it is a valid message and that it is in order broadly.

Collin Kidder worked out the actual code for these messages as he's the "deep thought" end of EVTV when it comes to such things. If I give him a large enough table, he can usually work out the polynomial for the CRC.

Here's an example. But don't ask me much about it. It's from at least five or six years ago. I'm including it as an example of polynomial CRCs Tesla has used in the past. Your mileage may vary.

uint8_t seqTable[8] = {0xB2, 0x7F, 0x35, 0xF8, 0xA1, 0x6C, 0x26, 0xEB};
uint8_t gearTable[5] = {0x4C, 0x98, 0x2D, 0x5A, 0xB4};
uint8_t calc;
uint8_t seq;
calc = seqTable[seq & 7];
if (seq > 7) calc ^= 0x26;
for (int i = 0; i < 5; i++)
{
if (Gear & (1 << i)) calc ^= gearTable_;_
_ }_
_ gearFrame.data.bytes[3] = calc;_


----------



## juanmax

Yes we need the polynomial to generate the CRC based in different message contents. We plan to replace the inverter and the Car needs to be happy without it. So we have to send to the Car what ever the inverter was sending and is required. I counted more than 20 messages so it is wise to try to find out the real algoritmh instead of using tablet that work just for specific signal values. Thanks for the Code, will gibt it A look.


----------



## Jack Rickard

juanmax said:


> Yes we need the polynomial to generate the CRC based in different message contents. We plan to replace the inverter and the Car needs to be happy without it. So we have to send to the Car what ever the inverter was sending and is required. I counted more than 20 messages so it is wise to try to find out the real algoritmh instead of using tablet that work just for specific signal values. Thanks for the Code, will gibt it A look.


Well with enough combinations in a table you can actually get it to work. But more importantly in the process you will start to see the "pattern" leading to the proper polynomial.

Anyway they use this technique quite a lot. A 4 bit or 8 bit counter is the first thing to look for. Then the specific data that is information. And finally the CRC which is usually a series of additions xored with a polynomial.

Jack


----------



## 0x6d33

Would it make sense to add the DBC file to git instead of dropbox?


----------



## Jack Rickard

Jack Rickard said:


> Thankee, thankee, thankee.
> 
> We had a number of mistakes in our CAN decoding - mostly with sign extensions on 11 and 13 bit numbers. And we didn't really have any
> way to test front wheel drive torque and power and horsepower and so forth for our CAN adapter and TorquePro setup.
> 
> Your "performance model" AWD rocked my world. I had no idea. This thing is showing -1200 amps, 800+ horsepower and just values of torque and kW I've never
> seen in a Model3 with my own eyes. We got all the front drive unit stuff tested and it's showing very reasonable numbers.
> 
> Jack Rickard
> http://evtv.me
> View attachment 26203
> View attachment 26204
> View attachment 26203
> View attachment 26204
> View attachment 26203
> View attachment 26204


Here's a minimalist Torque designs for Heads-up Display


----------



## JWardell

0x6d33 said:


> Would it make sense to add the DBC file to git instead of dropbox?


Yeah, I've been thinking of doing that.


----------



## Collin80

juanmax said:


> Hi,
> 
> as promised here some logs
> Model 3 AWD log with party(1) and vehicle(2) CAN
> Model 3 Perf vehicle CAN (acceleration 0-150-0 in Track Mode)
> 
> I am struggling to find out which algorithm Tesla is using to calculate the CRC (Checksum). Does anybody here have an idea or hint? I tried different SAE Standards but no luck. For example here (0x108):


You're going to think this is really stupid but...

For that CRC byte do this:

Start with the number 9. Now, add all seven of the other bytes to that starting value of 9. At the end, take just the lower 8 bits of the result and that's your CRC. No, I'm not kidding.

As an example:

C9 25 7D A8 3D 32 07 00

So the result should be C9. Let's try it with my above approach:

9 + 25 + 7D + A8 + 3D + 32 + 07 + 00 = 1C9. 1C9 AND FF = C9 the proper result.

Now, you might wonder where the 9 comes from. I'm not entirely sure, it could be random. Or, the can ID is 0x108 and 9 is the sum of the digits in the ID. That could be a coincidence.


----------



## juanmax

Hi Collin, no its is not a coincidence!

Our engineers have found exactly this yesterday, the "offset" is the sum of the last two digits of the identifier plus the first one.
So if you have 0x108 to calculate the offset is, "1" + "08" so "09".
In case you would have a 0x7a0, then the offset is 7 + a0 = a7
In case you would have a 0x16, then the offset is 0 + 16 = 16

BUT, looks like in the message 0x129 the CRC is calculated somehow in another way. Do you have a hint?

Thanks !!


----------



## JWardell

0x6d33 said:


> Would it make sense to add the DBC file to git instead of dropbox?


I haven't hosted a project on GitHub before so I'm not sure I'm doing it right, but I placed it here. Let me know if I did something wrong, or if this is preferable to my dropbox link
https://github.com/joshwardell/model3dbc



juanmax said:


> Hi Collin, no its is not a coincidence!
> 
> Our engineers have found exactly this yesterday, the "offset" is the sum of the last two digits of the identifier plus the first one.
> So if you have 0x108 to calculate the offset is, "1" + "08" so "09".
> In case you would have a 0x7a0, then the offset is 7 + a0 = a7
> In case you would have a 0x16, then the offset is 0 + 16 = 16
> 
> BUT, looks like in the message 0x129 the CRC is calculated somehow in another way. Do you have a hint?
> 
> Thanks !!


So in other words treat the ID as data too and just sum all the bytes.


----------



## Collin80

juanmax said:


> Hi Collin, no its is not a coincidence!
> 
> BUT, looks like in the message 0x129 the CRC is calculated somehow in another way. Do you have a hint?
> 
> Thanks !!


Hmm... Byte 0 is most certainly a security/CRC byte. Byte 1 seems to be a 16 long counter from 0x20 to 0x2F repeating forever. Yes, it's a validation byte and it does not seem to be nearly as easy to reverse engineer as the other one (unfortunately). I can find discrete patterns in the data but it doesn't seem to come up as any CRC style calculation. However, there are correlations between data bytes and Byte 0 that are regular. But, at this point I'm not aware of the actual algorithm used to calculate it. What I can say is that my idea to use a table like I did for the Model S drive train command frame is close to a solution but not entirely. It appears they paid attention to my previous extracurricular activities and threw in a few more surprises this time. It's partially possible to find bit patterns that correspond strongly to changes in the bits of the data bytes but some expected patterns are not there. So, I must assume they've increased the algorithmic complexity a little bit more.

(Word of warning, the rest of this post is kind of nasty and technical and probably hard to follow. If you don't want to head down the rabbit hole you can ignore the rest of this)

But, as for a hint of how to figure it out: a general approach is to first categorize the data such that you find data that differs by only a single bit. Then, see what effect that had on the security byte. Below I've got several lines from the capture where only the counter byte changed. The actual data was static. This makes it easy to get single bit changes in the counter itself:

A8 20 FE 5F 00 20 FF 3F 
BF 21 FE 5F 00 20 FF 3F 
F6 22 FE 5F 00 20 FF 3F 
E1 23 FE 5F 00 20 FF 3F 
67 24 FE 5F 00 20 FF 3F 
70 25 FE 5F 00 20 FF 3F

You'll see why I picked those 6 lines in a second.

But, you can see that the last 6 bytes are all static and only the security byte and counter change. Ignoring the security byte itself, the first two lines differ by one bit. We go from 0x20 to 0x21, a single bit change. SO, what does that do to the security byte? It increased by 0x17 since we went from A8 to BF. But, that tells you what the value did on a high level.

What about the bit level? The "exclusive or" operator returns the difference between the binary representation of two values. Exclusive OR is a binary operation (and actually, final Jeopardy answer here - XOR is addition in the galois field gf(2) ) that is, you apply it bit by bit. For each bit from each byte if they're the same the XOR result is 0. If they're different the result is 1. This makes XOR excellent for detecting patterns. Back to what I said about the gf(2) field, XOR is addition and you throw the remainder away. That should make sense if you think about it. 0 + 0 = 0 so the result is 0. 1 + 1 would carry in binary and we throw away the carry'd bit so the result is 0. 0 + 1 = 1 and 1 + 0 = 1 so that's why XOR is really addition but in a number field of base 2.

Working out an example: What is 0x4F XOR 0xA3? 4F is 0100 1111 in binary. A3 is 1010 0011 in binary. I'm going to write them out vertically and do the gf(2) addition per line
(4F) (A3) (result)
0 1 0+1 = 1
1 0 1+0 = 1
0 1 0+1 = 1
0 0 0+0 = 0
1 0 1+0 = 1 
1 0 1+0 = 1
1 1 1+1 = 0 (bit was carried and lost)
1 1 1+1 = 0

Thus 4F xor A3 = 1110 1100 = 0xEC. You should be able to see how this value is really a listing of everywhere the bits were NOT the same. Anywhere there's a 1 the bits differed. Anywhere there's a 0 they did not. One last property of XOR - it is reversible. If you xor a value by another value twice you get the original value. That is 4F XOR A3 XOR A3 = 4F. This also means that you can take the result and XOR it by either of the original values to get the other value. That is, 4F XOR EC = A3 and A3 XOR EC = 4F. It's all reversible. This should make sense too as knowing which bits changed means you can reverse it by going through and changing those bits to get the other value.

When I talk about bits there are 8 bits in a byte. The bits are numbered from 0 to 7. Bit 0 has a value of either 0 or 1 depending on whether the bit is set or not (usually written as 1 if it is set). Bit 1 has a value of either 2 or 0, Bit 2 has a value of 4 or 0, etc. Each bit is twice the value of the one below it. So: 1, 2, 3, 4, 8, 16, 32, 64, 128 but written the other way since bits are numbered from right to left: 76543210. And, decimal is ugly in binary so we usually use hexadecimal. So, the bit values in proper order are 80, 40, 20, 10, 8, 4, 2, 1. Those are the hexadecimal values for each bit in order as in bit7, bit6, etc. So when someone writes 1100 0101 what that means is apply the bit value for each bit that has a 1 and don't add anything for the 0's (they are just place holders). So, that's 80 + 40 + 4 + 1 = C5 in hexadecimal or 192 in decimal.

So, back to the security bytes:

A8 XOR BF is also coincidentally 0x17 but that's actually a coincidence and not something you should normally expect. So, what about a different single bit difference? How about lines 1 and 3 this time? 0x20 and 0x22 are also only one bit different. This time the security byte increased by 0x4E and A8 XOR F6 = 5E. Now, a test would be to see whether this same pattern holds true of 0x23. It is two bits different from 0x20 but only one bit different from either 0x21 or 0x22. The security byte for 0x23 was E1 which is 0x39 higher than A8. But, more importantly, lets try XOR again. If we consider A8 to be a base since that was the value for the counter byte 0x20 then let's see what happens if we XOR that value by the values we found above? A8 XOR 17 = BF which is the answer for 0x21. So far, so good. A8 XOR 5E = F6 which is the value for 0x22. What if we apply both since 0x23 has both bits changed compared to 0x20? A8 XOR 17 XOR 5E = E1 just as we had hoped! So that shows a definite pattern. Each bit change really caused a discrete bit pattern change in the security byte. 0x24 is also a single bit change from 0x20 so getting that XOR (A8 XOR 67 = CF). Now we have XOR values for three different bits - bits 0, 1, 2 corresponding to a value increase of 1, 2, 4. Can we use that third XOR to try to calculate what 0x25 should have for a security byte? Let's try! A8 XOR 17 XOR CF (the xor values for bits 0 and 2, the two bits set for 0x25). That results in 70 like it should. So far, so good. But, the bad news is that the pattern is not holding above these 6. If you try the same thing for a counter byte of 0x26 it will fail.

AA 26 FE 5F 00 20 FF 3F

0x26 is 0x20 + 2 + 4. That's bits 1 and 2 set. A8 XOR 5E XOR CF = 39 which you might notice is not AA.

But, the general technique of using XOR to get bit differences is still valid. It thus also helps to look at the binary representation of all the numbers just to see if anything stands out. For instance, here are the three XOR values we got and their binary rep:

Bit 0 - 0x17 0001 0111
Bit 1 - 0x5E 0101 1110
Bit 2 - 0xCF 1100 1111

A question one might ask is, do these values have any pattern? Of course, one might try to XOR *these* values together to see how their bits changed.

17 xor 5E = 49 (0100 1001)
17 xor CF = D8 (1101 1000)
5E xor CF = 91 (1001 0001)

Personally, this doesn't do a lot for me. But, it helps to illustrate the pattern searching one must do. The XOR'ing of the XOR values doesn't seem to pan out but the values are interesting. The actual values for the bit xors (17, 5e, cf) might have some pattern. Consider 17 and 5e. 5E is 17 shifted upward 2 places to the left then 10 tacked on the end. That is, if you take 0001 0111 and rotate those bits to the left 2 places you get 0101 1100 which is 0x5C. 0x5E is formed by adding an extra 1 in there in the second bit. So, what if you did that for the next bit? What is 5E shifted up two places? It's 0x78 which doesn't really look like CF at all (78 is 0111 1000) So, obviously that pattern does not hold and that's more or less a dead end it seems. So, why did I mention it and work it through anyway? Because this technique will have you doing all that a lot to see if you can find patterns. 95% of the time those patterns either turn out to not exist or don't actually lead you anywhere. But, it pays to get in the mindset to look at bits and bytes critically and try to see if you can find patterns. Patterns are easiest to find if you take your time and carefully compare things that are as close to each other as possible. That normally means trying to find single bit differences. The whole XOR thing might not yield the actual algorithm but it can point you toward patterns that then pan out to yield a useful calculation you can do. As I showed above, there is some limited success in using XOR to generate the security byte based on bit differences so there is something going on there.

Sorry, I know that explanation was pretty quick given the subject. But, that all is my basic technique for investigating how a security byte works at the binary level. It has worked for me on multiple projects. If this subject is of interest to people I might be talked into making a more thorough write up that doesn't assume quite as much (or proceed so quickly) or maybe I could do a video. But, perhaps the subject is more boring than watching paint dry on a wet fall day and nobody wants a video like that unleashed upon the earth. That's OK too. I hope it made some sense.


----------



## Juggernaut

Hi Jack, 
the evtv solution isn't really comfortable in terms of 
permanent placement in the rear area of the car. We 
intend to create a solution similar to that one but with 
an external obd port available in the covering of the
canbus. 

BTW: Please update the date in the product ad' ... in 1919 nobody dreamed of an M3 ;-)

BR
/michael


----------



## BigTom91

hungyip84 said:


> Can anyone help me confirm if this 26 pin connector is wired correctly?


Hey,

am I right that you connected 15 to 16, 26 to 5 (or 4), 18 to 6 and 19 to 14, where the first number is the car connector and the second the OBD2?
Does it work on for you?

What do I have to consider? Do I have to shut down the car completely before installing the connectors?

@sigurdi maybe you can help me?


----------



## energee

JWardell if you or anyone else is interested, I have a couple extra Sumitomo connectors for in-between body controller and MCU which has VEH, CHASSIS, and PARTY can buses on it. Can PM me or reply here if interested .


----------



## JWardell

energee said:


> JWardell if you or anyone else is interested, I have a couple extra Sumitomo connectors for in-between body controller and MCU which has VEH, CHASSIS, and PARTY can buses on it. Can PM me or reply here if interested .


I might store them for you, but probably avoid fighting and frustration of building another connector again. Still would prefer professional harnesses
But that also makes me realize, do we know the pinouts of the computer connectors?


----------



## fast_like_electric

JWardell said:


> ... do we know the pinouts of the computer connectors?


Yes. The MCU connector is as follows...

1: CHASSIS-CAN-H
2: CHASSIS-CAN-L
3: PARTY-CAN-H
4: MAIN POWER
5: AUDIO POWER
6: <no connect>
7: VEHICLE-CAN-L
8: VEHICLE-CAN-H
9: PARTY-CAN-L
10: GROUND
11: GROUND
12: EMERGENCY-NOTIFICATION-SIGNAL


----------



## JWardell

fast_like_electric said:


> Yes. The MCU connector is as follows...
> 
> 1: CHASSIS-CAN-H
> 2: CHASSIS-CAN-L
> 3: PARTY-CAN-H
> 4: MAIN POWER
> 5: AUDIO POWER
> 6: <no connect>
> 7: VEHICLE-CAN-L
> 8: VEHICLE-CAN-H
> 9: PARTY-CAN-L
> 10: GROUND
> 11: GROUND
> 12: EMERGENCY-NOTIFICATION-SIGNAL


Thanks. Maybe I should give it a try as my can logger can do 4 busses simultaneously


----------



## 0x6d33

How easy is it to access the MCU connector?


----------



## energee

0x6d33 said:


> How easy is it to access the MCU connector?


To be honest, its kind of hard to unplug because its a tight space, but you only have to remove one panel under the dash with 4 pop tabs.


----------



## JWardell

The real question is, how bad is it to disconnect without the car fully shut down


----------



## energee

Its fine, its really just power cycling it.


----------



## fast_like_electric

JWardell said:


> The real question is, how bad is it to disconnect without the car fully shut down


How bad - don't know, but to minimize any issue, the best bet is to have it powered down I'm sure. Unplugging that connector will power down the main Linux computer (as well as the internal CAN gateway bridge, LTE cellular, etc) - it is not just a miscellaneous device like the security module in the center console. Doesn't seem like the best idea to strip power if it is doing something at the time.

I recently did a full 12V battery disconnect in an attempt to resolve my non-working LTE (been sporadic for months, then dead for a week after the 2019.16.2 update). That did work, and I learned the proper way to do this. Basically you do everything like a normal Safety and Security power off, but have the frunk open beforehand, and disconnect the negative 12V battery lead after the car goes to sleep. There is a Tesla procedure online which outlines this, as well as HV disconnect (which I did not do).

That said, I know there are some who have just unplugged and repluged the MCU connector live. I'd be reluctant to do that given the frequent writes to flash memory that Tesla is known for. Not the best idea to interrupt that process, and the car seems always awake to some level when the doors are open (such as to access the panel/connector easier).


----------



## energee

fast_like_electric said:


> How bad - don't know, but to minimize any issue, the best bet is to have it powered down I'm sure. Unplugging that connector will power down the main Linux computer (as well as the internal CAN gateway bridge, LTE cellular, etc) - it is not just a miscellaneous device like the security module in the center console. Doesn't seem like the best idea to strip power if it is doing something at the time.
> 
> I recently did a full 12V battery disconnect in an attempt to resolve my non-working LTE (been sporadic for months, then dead for a week after the 2019.16.2 update). That did work, and I learned the proper way to do this. Basically you do everything like a normal Safety and Security power off, but have the frunk open beforehand, and disconnect the negative 12V battery lead after the car goes to sleep. There is a Tesla procedure online which outlines this, as well as HV disconnect (which I did not do).
> 
> That said, I know there are some who have just unplugged and repluged the MCU connector live. I'd be reluctant to do that given the frequent writes to flash memory that Tesla is known for. Not the best idea to interrupt that process, and the car seems always awake to some level when the doors are open (such as to access the panel/connector easier).


Good point on eMMC writes, there isn't a simple way that I know of to power down all ECUs so pulling 12V will keep you on the safe side.


----------



## Jack Rickard

Juggernaut said:


> Hi Jack,
> the evtv solution isn't really comfortable in terms of
> permanent placement in the rear area of the car. We
> intend to create a solution similar to that one but with
> an external obd port available in the covering of the
> canbus.
> 
> BTW: Please update the date in the product ad' ... in 1919 nobody dreamed of an M3 ;-)
> 
> BR
> /michael


Actually, the EVTV solution doesn't reside in the rear of the car. I keep the box in the cubby in the console right in front of the cup holder.

You intend to put an OBDII port in the covering of the CANBUS??? The Model 3, even the 1919 version, doesn't have a CANBUS cover.


----------



## Juggernaut

I intend to create an easy accessable OBD access by using the covering of the rear CANBUS. With the availabilty of an spare covering you can easily have a permanent version for your own monitoring and a SeC one if you go for an inspection to tesla ....

the prototypes will be tested next weekend.


----------



## Perscitus

Finally! A few false starts earlier in this thread.... hope and wish you luck.


----------



## amund7

I recieved software version 2019.20.2.1 yesterday, it says it has the new 200 kw charge upgrade.
In this software, they changed the offset of the battery amps reading. It now reads 1000 amps at idle. (Probably means 0 offset instead of 1000)

I also have something strange going on with the Front Power reading, for a while now (2 months maybe?) Front Power reads as expected, until you are cruising calmly at highway speeds. Then Front Power shows, say about 10 kw, a number that follows the speed. And it does NOT follow throttle inputs, accelleration/regen or the Rear Power or Battery Power.


----------



## amund7

Suggestions how we can auto-detect the 1000-or-not offset in Scan My Tesla so the users don't need to worry about it would be very welcome... !


----------



## JWardell

This is why I wish we could find software version in the data somewhere. 

I will have to make some recordings and look into it more when I get back from traveling. I figure they will change scaling and offsets especially as they add power and speed to things. I bet they changed supercharging values to accommodate the faster v3 chargers as well.


----------



## Jack Rickard

amund7 said:


> I recieved software version 2019.20.2.1 yesterday, it says it has the new 200 kw charge upgrade.
> In this software, they changed the offset of the battery amps reading. It now reads 1000 amps at idle. (Probably means 0 offset instead of 1000)
> 
> I also have something strange going on with the Front Power reading, for a while now (2 months maybe?) Front Power reads as expected, until you are cruising calmly at highway speeds. Then Front Power shows, say about 10 kw, a number that follows the speed. And it does NOT follow throttle inputs, accelleration/regen or the Rear Power or Battery Power.


They sure did. For EVTV OBDII adapter owners

`1. Connect to USB port on adapter with ASCII terminal.
2. Make sure you have entered an SSID and password in CLIEntSSID and CLIENTWPA2KEY to match your Wifi AP.
3. Enter UPDATE

The program should retrieve the latest version over the air. After it downloads and reboots confirm build 113 by entering ?

This update should read both pre and post software versions correctly for current.


----------



## Mike

Off topic request:

With the technical operating information that is being successfully harvested, perhaps this geeky question can be answered with hard data:

When a trip odometer is being used to track Wh/km, does said trip odometer track energy used while at a dead stop (such as a stop light) as well as when in motion, or does the trip odometer only capture and display trip energy used while the wheels are actually moving?

Thanks.


----------



## amund7

Jack Rickard said:


> They sure did. For EVTV OBDII adapter owners
> 
> `1. Connect to USB port on adapter with ASCII terminal.
> 2. Make sure you have entered an SSID and password in CLIEntSSID and CLIENTWPA2KEY to match your Wifi AP.
> 3. Enter UPDATE
> 
> The program should retrieve the latest version over the air. After it downloads and reboots confirm build 113 by entering ?
> 
> This update should read both pre and post software versions correctly for current.


Wow, that was quick, well done!

How can your device tell if the car has the new or old way of telling the current? I am about to release a new version that tries to auto-detect the amp offset, but curious if you have found a simpler/more foolproof way of doing it?


----------



## Mike

Mike said:


> Off topic request:
> 
> With the technical operating information that is being successfully harvested, perhaps this geeky question can be answered with hard data:
> 
> When a trip odometer is being used to track Wh/km, does said trip odometer track energy used while at a dead stop (such as a stop light) as well as when in motion, or does the trip odometer only capture and display trip energy used while the wheels are actually moving?
> 
> Thanks.


Disregard this request.

As long as the car is in gear, energy used for that session is captured by the trip odometer.


----------



## JWardell

amund7 said:


> Wow, that was quick, well done!
> 
> How can your device tell if the car has the new or old way of telling the current? I am about to release a new version that tries to auto-detect the amp offset, but curious if you have found a simpler/more foolproof way of doing it?


Agreed, we still have tons of messages that were never decoded, and I'm hoping somewhere in there is the software version.

We do have versions of other pieces of the system though, so perhaps we could use those (perhaps create a chart)


----------



## JWardell

Just watched this video of @MountainPass driving the record lap at Leguna Seca...nice data display and graphics, Sasha


----------



## amund7

JWardell said:


> Agreed, we still have tons of messages that were never decoded, and I'm hoping somewhere in there is the software version.
> 
> We do have versions of other pieces of the system though, so perhaps we could use those (perhaps create a chart)


I was hoping for something more directly related to this problem though, like a '200 kw charge' flag or something. But I am probably dreaming.
Will be exciting to discover if all cars including classic Model S will recieve this change, or only the ones that are physically capable of 200 kw charging... I am guessing the first.

This will have a nasty impact on all our software and hardware tools, especially DBC files I guess, as there is no way to build an auto-detect logic, or even adjustable offset into those I suppose? All you guys'es dash gadgets will need firmware updates, and none of the DBC based tools will be able to detect the difference ?


----------



## Flarpl-Jr

amund7 said:


> I also have something strange going on with the Front Power reading, for a while now (2 months maybe?) Front Power reads as expected, until you are cruising calmly at highway speeds. Then Front Power shows, say about 10 kw, a number that follows the speed. And it does NOT follow throttle inputs, accelleration/regen or the Rear Power or Battery Power.


That sounds like Model S/X-style torque sleep on the front induction motor, to me.


----------



## Jack Rickard

What are you about to release a new version of? And how are you trying to auto-detect the amp offset? I'm not sure I understand the problem "auto-detecting it". -1000 amps is a rather large factor.


----------



## Jack Rickard

amund7 said:


> I was hoping for something more directly related to this problem though, like a '200 kw charge' flag or something. But I am probably dreaming.
> Will be exciting to discover if all cars including classic Model S will recieve this change, or only the ones that are physically capable of 200 kw charging... I am guessing the first.
> 
> This will have a nasty impact on all our software and hardware tools, especially DBC files I guess, as there is no way to build an auto-detect logic, or even adjustable offset into those I suppose? All you guys'es dash gadgets will need firmware updates, and none of the DBC based tools will be able to detect the difference ?


If you are talking about the -1000 amp offset, we already went through that on the Model S battery CAN. I don't recall which way it was off, but they did indeed change the offset over a year ago and we had to go through that then.


----------



## Jack Rickard

amund7 said:


> Wow, that was quick, well done!
> 
> How can your device tell if the car has the new or old way of telling the current? I am about to release a new version that tries to auto-detect the amp offset, but curious if you have found a simpler/more foolproof way of doing it?


Ok, now I see. You do ScanMyTesla? And you are asking how to tell if it is the new or old offset? Well it's nothing very elegant. In the software, I set a flag for newstyle. If it is set, I calculate using the new formula without the -1000 amp offset. If it is not set, I use the old formula. But if the result is <-1000 amps that's a lot of amps. A lot of power. So if the case arises where the current is <-1000 AND the torque is less than almost any arbitrary value, say below 100nm, I set the flag. Thereafter, it will use the new calculation for that session. So yes it was quick. It was like three lines of code and a global variable.

And of course, normally when you first start the program the vehicle is normally actually at rest. So on the new software version it will get set in about 50ms. I don't recall the value used, but I think if torque<50nm and current is <-1000 you kind of have an obvious problem going here. The basis is a 1000 amp error is pretty easy to spot very early.

That's in software. In a .DBC file you don't really have software. So I don't know how to fix that without examining something. Basically you are into versioning your .dbc file. Pre and post. I'm already into that mess with the CAN adapter harnesses. We hardly had it done before we had to do it again. January 2019 change. The exact same thing happened with the Model S diagnostic port in 2015. I guess it is endemic to the automotive industry, which I've never really been a part of, I would proudly note.

Indeed, we had this EXACT problem of the -1000 current offset occur on a battery CAN message on the Model S. That was over a year ago and I did a very similar fix there. But don't overthink it. If you have a current result of over 1000 amps, you are in a pretty extreme current situation. EVERYTHING should reflect it, battery voltage, temperature, power, torque, almost everything in the car. If it doesn't you have an anomaly. But we already know there are two cases. I guess this would be further complicated if they introduce ANOTHER offset of 500 amps or something. But two cases that extremely different are very easy to flag.

With the ESP32 this is all GOBS easier as it is wireless and we can do over the air updates - perhaps not as fancy as the car that uses GSM, but if you have a Wifi hub to access, the single UPDATE command will just go get our latest software from Amazon, download it, and reboot into it.

We also pass all OBDII via Wireless so Torque on Android works with ordinary J1979 PID requests. But you CAN also pass full CAN over both OBDII and Wifi. (A little performance hit if you do so - the Model 3 makes a LOT of traffic). But it letss me use Collin's SavvyCAN over Wifi without needing the USB cable.

So if your ScanMyTesla could do Wifi, you don't need an ELM Bluetooth Dongle ON TOP of an OBDII port. We don't support Bluetooth right now, and if we did, it would be BLE.


----------



## amund7

Thanks for sharing, Jack!
I made the same assumption, that the car is 'probably' at rest when the app starts, then deducting the max and min reasonable amps. A new version is out with this now, testing shows the auto-detect will fail on a classic model S with the throttle pushed 'half way' as the app starts. That could happen, we'll see if this is good enough. Otherwise looking at the torque is clever.

I had a theory that all cars would move to the new offset, because they did that the last time, and it was in WK057's original document from 2016, where he specifies both offsets, and by that time does not know which cars use which. Later all cars would get the 1000 offset through software updates, the only reason he saw 0 offset was due to an MCU he had on his bench from a crashed car, that had not been updated for years. Or so I believe.

But I already have reports from my main app tester that his car is on the 'old' 1000 offset, a Model S 90D, with the latest software build - same as my 3 - "2019.20.4.2 66625e9".
So we all need our softwares to support both offsets simultaneosly.

What I meant by my DBC 'and other software' comment is that our hardware or apps that lives real-time in a car, we can make assumptions, but with a software that chews old log files, we can't - usually a log file starts right at a drag race for instance. Then (-)1300 amps would be normal.


----------



## Jack Rickard

amund7 said:


> Thanks for sharing, Jack!
> 
> What I meant by my DBC 'and other software' comment is that our hardware or apps that lives real-time in a car, we can make assumptions, but with a software that chews old log files, we can't - usually a log file starts right at a drag race for instance. Then (-)1300 amps would be normal.


But it wouldn't be normal to draw -1300 with a low torque value. And it wouldn't be normal to do so for very long with a high torque value. Similarly wouldn't be normal to draw -1300 with a high battery voltage although it gets a little tricker to set a voltage to detect this because of the variation based on SOC. Ergo torque being the most direct choice.

Actually it is endless. Wheel rpm, speed, really everything changes at -1300 amps. I just think torque is the low hanging fruit.


----------



## dburkland

JWardell said:


> Just watched this video of @MountainPass driving the record lap at Leguna Seca...nice data display and graphics, Sasha


Is that just a raspberry Pi with a simple display? I saw that and want to do something similar.


----------



## ymilord

dburkland said:


> Is that just a raspberry Pi with a simple display? I saw that and want to do something similar.


Nope that's a Motec display. We use these on our race cars.


----------



## rootandy

Since @rmn seem to gave up on his idea to build a shop for the harnesses (April - July and still no updates) - My question is, if maybe @Jack Rickard may be able to sell the cables alone (w/o his box) - since i think most of us already have the hardware to read the can bus (e.g. obdlink). Is there a possibility for that?


----------



## dburkland

ymilord said:


> Nope that's a Motec display. We use these on our race cars.


Do you have it plugged into the EVTV adapter?


----------



## jackbauer

Just wondering if anyone has any information on the charge port can or ipc can system in the model 3? I've been given a PCS and hv controller and am working on an open source controller for the pcs. Some logs and info on Github:
https://github.com/damienmaguire/Tesla-Model-3-Charger


----------



## ymilord

dburkland said:


> Do you have it plugged into the EVTV adapter?


I am not sure how MountainPass is doing to get it to work with a model 3. As for me, Our team race Civic Type R's with Haltech ECUs. The Motec talks to it via CAN.


----------



## 0x6d33

I made some changes to the DBC file to fix the battery current values.

Old code:
SG_ RawBattCurrent132 : 32|[email protected]+ (-0.05,1000) [-2276.75|1000] "A" Vector__XXX
SG_ SmoothBattCurrent132 : 16|[email protected]+ (-0.1,1000) [-2276.7|1000] "A" Vector__XXX
New code:
SG_ Raw_Batt_Current132 : 32|[email protected] (-0.05,500) [-2276.75|1000] "A" Vector__XXX
SG_ Smooth_Batt_Current132 : 16|[email protected] (-0.1,0) [-2276.7|1000] "A" Vector__XXX

To double check the values I plugged it into the charge. I found the total power going into the battery was about 10% less than what was coming out of the charger. This makes sense since the AD/DC conversion is not 100 efficient plus the car is drawing power.

Charger: 244v at 24A
Car: 392 V at -13.3 A


----------



## Calibr8r

0x6d33 said:


> I made some changes to the DBC file to fix the battery current values.
> 
> Old code:
> SG_ RawBattCurrent132 : 32|[email protected]+ (-0.05,1000) [-2276.75|1000] "A" Vector__XXX
> SG_ SmoothBattCurrent132 : 16|[email protected]+ (-0.1,1000) [-2276.7|1000] "A" Vector__XXX
> New code:
> SG_ Raw_Batt_Current132 : 32|[email protected] (-0.05,500) [-2276.75|1000] "A" Vector__XXX
> SG_ Smooth_Batt_Current132 : 16|[email protected] (-0.1,0) [-2276.7|1000] "A" Vector__XXX
> 
> To double check the values I plugged it into the charge. I found the total power going into the battery was about 10% less than what was coming out of the charger. This makes sense since the AD/DC conversion is not 100 efficient plus the car is drawing power.
> 
> Charger: 244v at 24A
> Car: 392 V at -13.3 A


Sounds about right. I believe the converter typically consumes about 600-ish watts.


----------



## JWardell

jackbauer said:


> Just wondering if anyone has any information on the charge port can or ipc can system in the model 3? I've been given a PCS and hv controller and am working on an open source controller for the pcs. Some logs and info on Github:
> https://github.com/damienmaguire/Tesla-Model-3-Charger


I too am curious about charge port communications, if anything to figure out how to change charge current or add VIN validation to my home charging setup (an old idea I had). I believe it uses single wire CAN of some sort.

If you instead mean CAN messages on the vehicle bus when connected to supercharger, I already have most of that documented.


----------



## ymilord

JWardell said:


> ...figure out how to change charge current or add VIN validation to my home charging setup.


I have a RPI Zero W connected to the RS232 port on the HPWC (The Wall connector is set to a slave and the RPI is set to master, which then can command the HPWC what Amperage to set itself to and terminate the charging from the HPWC side vs. Vehicle side.). It controls the length depending on what the houses current usage is for the day. I also use a 60A 4 Pole Contactor (L1, L2, L3 & L4- But I only use L1, L2 & L3) connected to a zwave outlet. Which is connected to SmartThings. With-in SmartThings I added the cars WiFi MAC address to as a 'Presence Tag'. So if the car is home SmartThings sets the outlet to on, which then turns on the Contactor.

So the logic is when the car(s) come back, SmartThings turns on the HPWC, Then looks at the house usage for the day. (i.e. 16kW and it has a budget of 28kW). Then it sets a value of '12' which the RPi sees and then adjusts the current (if needed) and calculates the charge time that it can charge. The main reason is to keep the house daily avg somewhere between 20~24kW per day. Which keeps the power bill in check. This method has dropped our power bill and made it predictable. The secondary reason is to prep for Solar.


----------



## jackbauer

My plan is to make a controller to allow the PCS be used outside of a Model 3 such as in ev conversion projects. 
I'm slowly getting to grips with the IPC CAN. The PCS sends 5 ids:
0x76C,0x2C4,0x204,0x264,0x224.

Message 0x264 reports the AC voltage applied to the charger modules. Not worked out how but here is a capture doing a sweep from 0 to 240v and back to 0.
https://github.com/damienmaguire/Tesla- ... 0_240v.csv

0x224 and 0x204 bytes 6 and 7 respectively respond to the state of the PWM DCDC or PWM CHG enable lines. Going from 0 to 1 when 5v is applied.


----------



## jackbauer

I guess I should RTFM...or RTF spreadsheet
Looks like a few of the PCS messages are rebroadcast over vehicle can and have been worked out.

Next trick will be to use two laptops and two candues to play the hvcontroller messages back to the pcs and see which bring it to life.


----------



## GDN

ymilord said:


> I have a RPI Zero W connected to the RS232 port on the HPWC (The Wall connector is set to a slave and the RPI is set to master, which then can command the HPWC what Amperage to set itself to and terminate the charging from the HPWC side vs. Vehicle side.). It controls the length depending on what the houses current usage is for the day. I also use a 60A 4 Pole Contactor (L1, L2, L3 & L4- But I only use L1, L2 & L3) connected to a zwave outlet. Which is connected to SmartThings. With-in SmartThings I added the cars WiFi MAC address to as a 'Presence Tag'. So if the car is home SmartThings sets the outlet to on, which then turns on the Contactor.
> 
> So the logic is when the car(s) come back, SmartThings turns on the HPWC, Then looks at the house usage for the day. (i.e. 16kW and it has a budget of 28kW). Then it sets a value of '12' which the RPi sees and then adjusts the current (if needed) and calculates the charge time that it can charge. The main reason is to keep the house daily avg somewhere between 20~24kW per day. Which keeps the power bill in check. This method has dropped our power bill and made it predictable. The secondary reason is to prep for Solar.


----------



## ymilord

GDN said:


>


? Did what I said not make any sense?


----------



## Feathermerchant

I think his brain just went poof.
Pretty clever.
I pay a flat 9¢ per kWh which is cheaper than Supercharging so I can charge fully (80%) any time I want.


----------



## Jack Rickard

rootandy said:


> Since @rmn seem to gave up on his idea to build a shop for the harnesses (April - July and still no updates) - My question is, if maybe @Jack Rickard may be able to sell the cables alone (w/o his box) - since i think most of us already have the hardware to read the can bus (e.g. obdlink). Is there a possibility for that?


Sure, we could send the cable without the box. $295. But that's a lot to pay for a cable don't you think? You could probably use the box for something else if you don't need it.

Actually this has become quite difficult. The guy who did our first set of 50 has flaked out and disappeared AGAIN. I've used this guy over the years and he just kind of comes and goes. Very secretive. And then he's gone for awhile.

Fortunately, my Goddess of Cables has finally come through on this one as well and I just ordered another 200. The minimum order SHE can source these units is 200. It is a ****show. It took her three months to source these.

As you know, I've never met a connector I liked. This one is no exception.


----------



## jlquinn

Has anyone tried to see if the manual wiper button shows up in the data logs? My idea is to bypass the notoriously poor auto wipers on the Model 3. I'm thinking that we could put in a real rain sensor in the car with a box that detects the rain and issues a manual wiper command over the canbus.

What are your thoughts?
I'm posting in this thread since the folks who are doing data analysis are hanging out here.


----------



## Feathermerchant

My Model3 has great auto wipers. Have you coated your windshield with something? Are you using RainX additive or other in your washer fluid?


----------



## b0n3z

For those of you that are handy and have the tools to crimp correctly you can look up my posts and source these parts fine. It's not difficult once you know the correct information. For others looking to have these made for you - if you live in NY or certain areas check out https://www.fleetcarma.com/ (no, I don't work for them and I'm not affiliated with them in any way).


----------



## GDN

Please keep this thread focused on the technical details and sharing of data.


----------



## JWardell

jackbauer said:


> I guess I should RTFM...or RTF spreadsheet
> Looks like a few of the PCS messages are rebroadcast over vehicle can and have been worked out.
> 
> Next trick will be to use two laptops and two candues to play the hvcontroller messages back to the pcs and see which bring it to life.


Welcome! There are plenty more messages which we need to decode, and plenty that just need to be confirmed not necessarily in the spreadsheet. If you think of things for folks to look for, it often inspires us to do a little research and get a few more messages in there. I feel like we have most of the PCS/charging data, what else are you looking for?



Jack Rickard said:


> Sure, we could send the cable without the box. $295. But that's a lot to pay for a cable don't you think? You could probably use the box for something else if you don't need it.
> 
> Actually this has become quite difficult. The guy who did our first set of 50 has flaked out and disappeared AGAIN. I've used this guy over the years and he just kind of comes and goes. Very secretive. And then he's gone for awhile.
> 
> Fortunately, my Goddess of Cables has finally come through on this one as well and I just ordered another 200. The minimum order SHE can source these units is 200. It is a ****show. It took her three months to source these.
> 
> As you know, I've never met a connector I liked. This one is no exception.


Between bluetooth/arduino hangups and lack of cable sources I have totally slacked on development the last few months. If you are reliable getting both generations of cables, it might encourage me to get back to work, and if I do make some more finished product, could then possibly buy a chunk of then from you. In other words, if the cables can be used with a few different products, 200 won't be such an annoyingly large quantity anymore.



jlquinn said:


> Has anyone tried to see if the manual wiper button shows up in the data logs? My idea is to bypass the notoriously poor auto wipers on the Model 3. I'm thinking that we could put in a real rain sensor in the car with a box that detects the rain and issues a manual wiper command over the canbus.
> 
> What are your thoughts?
> I'm posting in this thread since the folks who are doing data analysis are hanging out here.


I will say autowipers are actively being develop and in my experience drastically improved...I saw them activate for just a mist for the first time the other day. Beware spending a ton of time and effort on hardware that Tesla is sure to obsolete.


----------



## amund7

JWardell said:


> Between bluetooth/arduino hangups and lack of cable sources I have totally slacked on development the last few months. If you are reliable getting both generations of cables, it might encourage me to get back to work, and if I do make some more finished product, could then possibly buy a chunk of then from you. In other words, if the cables can be used with a few different products, 200 won't be such an annoyingly large quantity anymore.


I also really need a reliable source for cables. I was contemplating doing it myself, but shipping from Norway will be so expensive nobody would be happy. (Also if I took on something like that, my development time would all be lost in shipping and packing cables) The best would be if the makers could ship directly from China. And there is money to be made from this, Scan My Tesla currently moves a tad below 100 copies a month, rising steadily, so far 850 copies in total. Most, if not all of these are Model S/X, surely because that's the only cables you can find in E-bay and other places. I don't think the sales potential of Model 3 has even started yet, because the cables are only available through obscure PM's in different forums...


----------



## 0x6d33

Like many dual motor owners, I believe the only difference between the performance and dual motor model is software. I would like to kick start an effort to unlocking the full performance of the dual motor model.

According to the EPA, the rear motor in the performance model and the RWD long range model are both rated 211 kW while the dual motor is rated at 188 kW. Both the dual motor and performance model front motor are rated at 147 kW. So it seems Tesla is only limiting the power on the rear motor.

Focusing on understand how the rear inverter communicates with the accelerator pedal and the rest of the car seems like a good first step. I know a few people in this thread have already start looking into some of the CAN messages being sent from the inverter.

According to the model 3 wiring diagram from the service manual, there some direct analog communication between the inverter and accelerator pedal. I think I'll have a look there first.

Source: https://www.fueleconomy.gov/feg/Find.do?action=sbs&id=41190&id=41191&id=41189


----------



## JWardell

You can probably do it by just flipping one config bit, but doing so requires root, and I from what I gather that can only be done with a physical computer hardware mod by @Ingineer


----------



## jackbauer

Worked back through the hv controller to find where the ipc can terminates. A real tour de force but it seems to end up in several places one of which is a qfp device with a weird part number. Decided to try something. Rigged up a 65HVD255 CAN transciever on a breadboard with Tx and Rx connected to the PCS and a short can line connecting it to the candue. Fired up the PCS and bingo. With the transciever handling the bus arbitration the pcs puts out messages from power on.
Log of pcs from powerup :
https://github.com/damienmaguire/Tesla- ... henoff.csv
Threw a CAN capture at it for laughs and found a message that controls the AC current limit of the charger section.

0X25D bit 4. When set reduces AC current limit from 48A (default) to 32A.

Log of 0x25D from a model 3 on charge :
https://github.com/damienmaguire/Tesla- ... wercmd.csv


----------



## Feathermerchant

That sounds like charging current limit. With a Gen1 UMC you can charge up to 40A (80%) on a 50A adapter. The Gen2 UMC is limited to 32A.


----------



## Perscitus

Signed up for fleetcarma and awaiting cable/dongle. 
I'll report back on how it works with OBDLink LX and MX and ScanMyTesla.

If someone sold these cables (for the pre- Jan-2019 and post Jan-2019 cars) - they should be no more than $20-30.
But given what we've seen in this and related threads, other forums over the past 2+ years, its unlikely they will ever be offered.


----------



## John

Jack Rickard said:


> The Toyota connectors are of course made by Yazaki. I made you a little diagram with the Yazaki part numbers. Yazaki likes to sell 100,000 of something to OEMs so they are a little hard to source. But here's the stuff.


If anybody needs help sourcing connectors, I'd be happy to help. With an exact model number, my company has access to just about anything.


----------



## b0n3z

John said:


> If anybody needs help sourcing connectors, I'd be happy to help. With an exact model number, my company has access to just about anything.


Can your company crimp and assemble the multiple connectors for a wire harness? Or do you have a resource your company uses (with their minimums)?


----------



## John

I could get quotes, if someone would work up a spec (connectors, wire gauge, lengths). We outsource cables.


----------



## scottf200

0x6d33 said:


> Like many dual motor owners, I believe the only difference between the performance and dual motor model is software. I would like to kick start an effort to unlocking the full performance of the dual motor model.
> 
> According to the EPA, the rear motor in the performance model and the RWD long range model are both rated 211 kW while the dual motor is rated at 188 kW. Both the dual motor and performance model front motor are rated at 147 kW. So it seems Tesla is only limiting the power on the rear motor.
> 
> Focusing on understand how the rear inverter communicates with the accelerator pedal and the rest of the car seems like a good first step. I know a few people in this thread have already start looking into some of the CAN messages being sent from the inverter.
> 
> According to the model 3 wiring diagram from the service manual, there some direct analog communication between the inverter and accelerator pedal. I think I'll have a look there first.
> 
> Source: https://www.fueleconomy.gov/feg/Find.do?action=sbs&id=41190&id=41191&id=41189


In InsideEVs update to their story on:
*Update From Tesla: No Tesla Model 3 Performance For Under $50K*
https://insideevs.com/news/360589/tesla-model-3-performance-49990-off-menu/

They still believe there is a unique inverter. See underlined below.
"
_*Update:* We reached out to Tesla for clarification since this information came from "sources familiar with the matter." Tesla says customers *can't order a new Model 3 Performance* from the online configurator *for $49,990*. If you select or request the 18-inch Aero wheels, *the price will remain at $54,990*. Also, the changes made Monday assure that every Model 3 Performance comes standard with the Performance Upgrades Package, and that *can't be* "unbundled" off-menu. So, you'll automatically get the performance features, including Track Mode. _

_It's additionally important to note that the Model 3 Performance continues to have more torque and more power than the regular Model 3 Long Range Dual Motor due to its unique inverter that carries more current from the battery to the motors._
"


----------



## scottf200

Maybe MaxWellTech is on here in another name (I did a search) but they look like they build S/X cables currently. Don't know if they had access to the parts if they'd build TM3 cables.
Just a thought. Sorry if this is repeated.

https://www.ebay.com/usr/maxwelltech?_trksid=p2047675.l2559


----------



## jackbauer

Message 0x22a on ipc can at 10ms intervals. Byte 1 , bit 2 is dcdc enable. set it to one and the dcdc wakes up. set it to 0 and it shutsdown. Released a first cut at a pcs controller on github. Just a modification to the existing gen3 charger controller. 
https://github.com/damienmaguire/Tesla-Model-3-Charger


----------



## Perscitus

Received the Fleetcarma pass-through cable and will finally take OBDLink LX and MX plus ScanMyTesla out for a spin. Zero intention of using the C2 dongle.


----------



## jackbauer

Need a little help on some can decoding. I had been looking for a message from the pcs with the 12v system voltage. None seemed to show itself. Then I observed message 0x424 pop up when the dcdc enable bit in 0x22a is sent. Here are a few samples of 0x424 with various 12v voltages applied. Anyone want to guess how the 12v is encoded here?

12v applied : 2b 80 2d 0d 01 00 00 a0
13v applied : 2b 80 4a 35 01 bc 0b a0
14v applies : 2b 80 65 5d 01 bc 0b a0
15v applied : 2b 80 7f 7d 01 bc 0b a0


----------



## JWardell

jackbauer said:


> Need a little help on some can decoding. I had been looking for a message from the pcs with the 12v system voltage. None seemed to show itself. Then I observed message 0x424 pop up when the dcdc enable bit in 0x22a is sent. Here are a few samples of 0x424 with various 12v voltages applied. Anyone want to guess how the 12v is encoded here?
> 
> 12v applied : 2b 80 2d 0d 01 00 00 a0
> 13v applied : 2b 80 4a 35 01 bc 0b a0
> 14v applies : 2b 80 65 5d 01 bc 0b a0
> 15v applied : 2b 80 7f 7d 01 bc 0b a0


I don't know of 12v in the PCS, I usually get it from the inverter or the VCfront/12v battery


----------



## Calibr8r

Has anyone played around with the ASAP2DEMO with the .dbc yet?


----------



## JWardell

Calibr8r said:


> Has anyone played around with the ASAP2DEMO with the .dbc yet?


what's that?


----------



## juanmax

I thought you may find interesting a plot of a quick charge session of my M3P. Interesting to see the temps of the battery going that high (and then stabilizing). In the first 5 min the car charges 19% SoC, this is impressive. I can not wait to have Superchargers V3 here in Europe! This Unity charger has a 500A max (350kW @ 700V) limit. Looks like the two times where the charge power went down is commanded from the charger itself, since I could see the charger setting a lower current limit on those two instances.

Your thoughts?










Regards,

Juanma


----------



## juanmax

Ok ok, my last post was off topic but look at this one:

I think I found what could be front axle motor torque request in the ID 0x136, first 12bits:

Anybody wants to double check?


----------



## JWardell

juanmax said:


> Ok ok, my last post was off topic but look at this one:
> 
> I think I found what could be front axle motor torque request in the ID 0x136, first 12bits:
> 
> Anybody wants to double check?
> 
> View attachment 28029


I don't think we have ever seen ID 136 before, where did you read it from?


----------



## juanmax

On the Party CAN. I can access now measurements from all party, veh and chas. CAN direclty on the connector from the MCU.

Also found just now another message containing steering wheel angle (maybe a second ECU for redundancy?) This one is only present on the chassis CAN


----------



## Calibr8r

juanmax said:


> I thought you may find interesting a plot of a quick charge session of my M3P. Interesting to see the temps of the battery going that high (and then stabilizing). In the first 5 min the car charges 19% SoC, this is impressive. I can not wait to have Superchargers V3 here in Europe! This Unity charger has a 500A max (350kW @ 700V) limit. Looks like the two times where the charge power went down is commanded from the charger itself, since I could see the charger setting a lower current limit on those two instances.
> 
> Your thoughts?
> 
> Regards,
> 
> Juanma


The first was probably from the A/C chiller activation command which happens around 47.5 to 48*C battery temps. The second may be from a battery temp limit at about 54*C (unconfirmed). I hit 148kW on the V2 150kW charger log from 6-85% SoC and the de-rate occurred at 47.5-48*C and the highest temp recorded was 53*c, hovering at around 52*C the majority of the time (started at 36*C).

/offtopic


----------



## amund7

I thought of something. Since the ethernet bus seems to have all the data, can we either connect, or sniff those wires? How cool would it be if there exists an inductive ethernet sniffer that anyone could clamp on a wire somewhere, and read ALL the info from ALL the can-buses. Or are there reasons this can't be done ? (Encryption comes to mind)


----------



## michi84

Does the EVTV OBD 2 adapter work with ScanMyTesla? I have a european Model 3 AWD, built in April or May. I do have an OBDLink MX from my previous car.


----------



## 0x6d33

amund7 said:


> I thought of something. Since the ethernet bus seems to have all the data, can we either connect, or sniff those wires? How cool would it be if there exists an inductive ethernet sniffer that anyone could clamp on a wire somewhere, and read ALL the info from ALL the can-buses. Or are there reasons this can't be done ? (Encryption comes to mind)


There seems to be 3 types of ethernet documented in the model 3. Diag, Radio and Auto Pilot. The diag ethernet is accessible via the driver side footwell however, no one seem to have figured out how to get this port to transmit data. Perhaps the Autopilot ethernet might have something interesting. It is a twisted pair of white and blue wires connected between the MCU and Autopilot ECU. It could be encrypted like you mentioned though.

The AP board has a 7 port ethernet switch (Marvell 88EA6321). There also a port on the AP board that looks like a USB port called DEBUG ETH.


----------



## TomT

I went to fleetcarma.com and could not find the cable... Do you have a specific link for it? I have a OBDLink and ScanMy Tesla and would love to be able to use it, but have had no luck in finding a cable for my 2019 Model 3... I don't want to spend $300 for the EVTV OBD 2...



Perscitus said:


> Received the Fleetcarma pass-through cable and will finally take OBDLink LX and MX plus ScanMyTesla out for a spin. Zero intention of using the C2 dongle.


----------



## Perscitus

Its not something you 'find'... instead, sign up for Fleetcarma (if operating in your state) and they ship you the hardware (including required cable) free of charge.

Make sure you stipulate a 2019, and hope they send a cable thats wired differently than the 2017/2018s.


----------



## David King

I'm new to CAN but am a young engineer that loves to learn and figure new things out. So after reading all 49 pages, I feel like it's possible to make a simple version MPP's Party Box by reading the wheel speed messages and immediately injecting my own wheel speed message. This could consist of reading say the driver rear wheel's speed and sending that as the other wheels' speeds, or sending the average wheel speed to all wheels. From line 42 in this .dbc file it looks like writing to the Chassis Bus will allow this. The Chassis bus is not located at the bottom rear of the center console but near the VCU correct? 
There's been a lot of talk about reading messages but not about writing them. Am I wrong in thinking that the hardest part of writing messages is figuring out the checksum? Are the checksums all the same so what is described on page 45 would apply to the wheel speed message? If I just want all the wheels to look like they're spinning together so that TC doesn't step in, all the new wheel speed messages would be identical except for the wheel ID. It seems kinda simple to figure out how to only change the wheel ID when copying one wheel speed to the others if you compare messages of the car rolling normally and then with some wheels slipping. I'm assuming messing with these wheel speeds would interfere with ABS so the fake messages could be disabled when the brake is sensed. This sounds kinda dangerous to be messing with such fundamental vehicle systems so please kill this dream of mine before I do something stupid. I just want to slide my AWD Model 3 on snowy parking lots like my old Subaru haha Thank you for your time!


----------



## JWardell

David King said:


> I'm new to CAN but am a young engineer that loves to learn and figure new things out. So after reading all 49 pages, I feel like it's possible to make a simple version MPP's Party Box by reading the wheel speed messages and immediately injecting my own wheel speed message. This could consist of reading say the driver rear wheel's speed and sending that as the other wheels' speeds, or sending the average wheel speed to all wheels. From line 42 in this .dbc file it looks like writing to the Chassis Bus will allow this. The Chassis bus is not located at the bottom rear of the center console but near the VCU correct?
> There's been a lot of talk about reading messages but not about writing them. Am I wrong in thinking that the hardest part of writing messages is figuring out the checksum? Are the checksums all the same so what is described on page 45 would apply to the wheel speed message? If I just want all the wheels to look like they're spinning together so that TC doesn't step in, all the new wheel speed messages would be identical except for the wheel ID. It seems kinda simple to figure out how to only change the wheel ID when copying one wheel speed to the others if you compare messages of the car rolling normally and then with some wheels slipping. I'm assuming messing with these wheel speeds would interfere with ABS so the fake messages could be disabled when the brake is sensed. This sounds kinda dangerous to be messing with such fundamental vehicle systems so please kill this dream of mine before I do something stupid. I just want to slide my AWD Model 3 on snowy parking lots like my old Subaru haha Thank you for your time!


Congrats on what is becoming quite an achievement reading this whole thread 

We know how to decode/recreate the checksums now, but the problem is the network is broadcast, so you will still have the real data mixed in with the fake data, plus many of the messages also have counters so everything has to be sequential. Tesla really did an impressive job over engineering an already robust network.

The known only way around it is a man-in-the-middle, which means literally cutting the sensors and splicing in a box to spit out modified signals.

There are always corners of software modes to be discovered though, like generating an ABS error or something to make the software ignore traction control or similar, that might be easier to do if they can be figured out.


----------



## Calibr8r

JWardell said:


> The known only way around it is a man-in-the-middle, which means literally cutting the sensors and splicing in a box to spit out modified signals.


I work with these 'tuning boxes' in my field. Its a basic arduino intercept and emulate scenario. The main unknown issue is how the system does plausibility checks and diagnosis of any sensors that are intercepted. Many boxes go into a sleep mode and if they are not awake when the system checks the sensors, they will get an open circuit fault. Its very doable if you can source the connectors to create the harnesses required (not always an easy feat).


----------



## JWardell

Calibr8r said:


> I work with these 'tuning boxes' in my field. Its a basic arduino intercept and emulate scenario. The main unknown issue is how the system does plausibility checks and diagnosis of any sensors that are intercepted. Many boxes go into a sleep mode and if they are not awake when the system checks the sensors, they will get an open circuit fault. Its very doable if you can source the connectors to create the harnesses required (not always an easy feat).


Oh yes certainly doable, just not a simple plug and play that can confidently be installed by any end user.
Especially if Tesla changes its comms in firmware updates.

Just look at the auto opening trunk hardware that is now available. They monitor CAN (which the end user must splice into manually), and they have already had to issue a firmware update as Tesla already changed the messages they were monitoring. Not the end of the world for something that just monitors, but with a man in the middle device that means suddenly that device does not work at all...now your ABS sensors don't work and you have a major safety issue.
This is much more simple with traditional brands without constant updates and innovations, that don't change their comms for generations.


----------



## amund7

I'd really like to see someone figure out a way to turn on Track Mode on a non-performance car... I'd buy that device in an instant!

But what happens if you unplug one ABS sensor, if those are easy/at all possible to get to?


----------



## JWardell

amund7 said:


> I'd really like to see someone figure out a way to turn on Track Mode on a non-performance car... I'd buy that device in an instant!
> 
> But what happens if you unplug one ABS sensor, if those are easy/at all possible to get to?


I would love track mode too, or whatever fun mode there could be for RWD.
You can unplug an ABS sensor from behind a wheel. It will disable traction control, yes, but it will also disable ABS brakes.


----------



## 0x6d33

You guys should check out @lewurm latest blog post. He's been poking around the Model 3's MCU. Really interesting stuff.

https://github.com/lewurm/blog/issues/4


----------



## JWardell

0x6d33 said:


> You guys should check out @lewurm latest blog post. He's been poking around the Model 3's MCU. Really interesting stuff.
> 
> https://github.com/lewurm/blog/issues/4


Yes, I've been following along..certainly a lot more hacking that I would be willing to do, removing massive BGAs and all


----------



## juanmax

Try sending on the can a wrong front motor rpm. You loose AP, ESC, TCS, and so on... ABS still works though.


----------



## vater

Hello!
My model 3 has some minor issues
I bought it at auction after an accident
the airbags worked, I replaced them but the car does not take charge and will not start
I know that everyone has a model 3 problem and can be solved
But I live in Armenia, no one can help me. And I never did a car repair
But I'm a software engineer, and I think I can solve this problem myself
I want to know this android application can help me?
Or do I need to use some kind of desktop application?

I will be happy with any useful information!


----------



## JWardell

vater said:


> View attachment 28475
> 
> Hello!
> My model 3 has some minor issues
> I bought it at auction after an accident
> the airbags worked, I replaced them but the car does not take charge and will not start
> I know that everyone has a model 3 problem and can be solved
> But I live in Armenia, no one can help me. And I never did a car repair
> But I'm a software engineer, and I think I can solve this problem myself
> I want to know this android application can help me?
> Or do I need to use some kind of desktop application?
> 
> I will be happy with any useful information!


I'm sure your pyro fuse blew as it is triggered with air bags and physically disconnects the battery. I think easy to replace under the rear seat but not sure if you will be able to buy one easily


----------



## amund7

A lot of changes in the recent 2019.28.3.1 software:

Front and rear torque is gone (CAN ID 0x1D4, 0x154), and front and rear power has gone crazy / garbage / not sure what's going on (CAN ID 0x2E5, 0x266)

Anyone looked into this yet?


----------



## gekoch

On the CAN bus, can wee see when Autopilot is activated?


----------



## energee

gekoch said:


> On the CAN bus, can wee see when Autopilot is activated?


Yes


----------



## gekoch

energee said:


> Yes


Nice, can you share the CAN ID since I didn't found the ID in the "Model 3 CAN bus IDs and data" spread sheet


----------



## amund7

amund7 said:


> A lot of changes in the recent 2019.28.3.1 software:
> 
> Front and rear torque is gone (CAN ID 0x1D4, 0x154), and front and rear power has gone crazy / garbage / not sure what's going on (CAN ID 0x2E5, 0x266)
> 
> Anyone looked into this yet?


1D5, 1E5 and 1D8 are new, and come in with the same frequency as 1D4 and 154 used to. I tried interpreting them with the old torque formulas, also 108, but none of them make sense directly.
108 still works though, I didn't implement it in SMT since it didn't have a companion for the front motor (that was known), tried looking for a brother packet (same frequency & formula), but no luck.


----------



## JWardell

amund7 said:


> A lot of changes in the recent 2019.28.3.1 software:
> 
> Front and rear torque is gone (CAN ID 0x1D4, 0x154), and front and rear power has gone crazy / garbage / not sure what's going on (CAN ID 0x2E5, 0x266)
> 
> Anyone looked into this yet?





amund7 said:


> 1D5, 1E5 and 1D8 are new, and come in with the same frequency as 1D4 and 154 used to. I tried interpreting them with the old torque formulas, also 108, but none of them make sense directly.
> 108 still works though, I didn't implement it in SMT since it didn't have a companion for the front motor (that was known), tried looking for a brother packet (same frequency & formula), but no luck.


I haven't looked at the small changes since the spring, and figured more are coming. Also because I've been on early access software since Feb. Now that we know v10 is coming in a few weeks (?) I am waiting for that before I make any new logs and start analyzing things.

But this makes it even more important to find a message identifying software version so that the decoder tools can intelligently choose which message set to use.


----------



## bwilson4web

Hi,

I watched Jack's YouTube video "Model 3 CAN Adapter and CAN Capture Techniques" and his basic battery, demo program, looks to be a good start for monitoring battery cell balance. I may buy one but wanted to ask:

Has anyone used Jack's system to document cell imbalance? For example, a distribution of cells at different voltage buckets, a histogram.

Has anyone used it to document cell balance methodology and timing? For example, is there a threshold voltage that triggers balancing the cells. Typically how long does it take to achieve some given, minimum uniformity?

Thanks,
Bob Wilson


----------



## JWardell

bwilson4web said:


> Hi,
> 
> I watched Jack's YouTube video "Model 3 CAN Adapter and CAN Capture Techniques" and his basic battery, demo program, looks to be a good start for monitoring battery cell balance. I may buy one but wanted to ask:
> 
> Has anyone used Jack's system to document cell imbalance? For example, a distribution of cells at different voltage buckets, a histogram.
> 
> Has anyone used it to document cell balance methodology and timing? For example, is there a threshold voltage that triggers balancing the cells. Typically how long does it take to achieve some given, minimum uniformity?
> 
> Thanks,
> Bob Wilson


I've seen outward indications of cell balancing for example when state of charge ticks up after sitting disconnected, and of course when charging to the top. I don't think anyone has looked at it with super fine detail.
Problem is the CAN message with cell voltages that Jack built that software and video around was removed by Tesla back in the spring. There may be some other message that helps find that data that we don't know about.


----------



## bwilson4web

JWardell said:


> Problem is the CAN message with cell voltages that Jack built that software and video around was removed by Tesla back in the spring.


AAAGGGGGHHHHHH!!!!

So we'd join an 'Enigma' hunt like _The Imitation Game_ . . . trying to decode the latest Tesla code.

Bob Wilson


----------



## Calibr8r

I figured I would start documenting the ID's that come & go on Vehicle CAN through the software updates and start a spreadsheet to see what comes & goes.

Here are items that are no longer available from the excel spreadsheet in the first post:

observed in 2019.28.3.1



Code:


0x154
0x1D4
0x214
0x215
0x217
0x244
0x26A
0x276
0x2B2
0x2E1
0x2E2
0x2E5
0x304
0x316
0x328
0x356
0x357
0x35A
0x35B
0x376
0x388
0x392
0x396
0x3B9
0x3D6
0x3D6
0x3D9
0x3D9
0x3E2
0x3E2
0x3FF
0x3FF
0x401
0x401
0x4E2
0x4E2
0x505
0x505
0x514
0x514
0x518
0x518
0x51E
0x51E
0x526
0x526
0x529
0x529
0x541
0x541
0x550
0x556
0x557
0x5F4
0x656
0x712
0x757

Here are the new ID's:



Code:


0x020
0x082
0x128
0x1D8
0x1E5
0x1FB
0x200
0x279
0x27D
0x29D
0x2BD
0x315
0x334
0x335
0x33A
0x367
0x36B
0x36E
0x385
0x395
0x398
0x3A5
0x3B5
0x3C5
0x3D5
0x3E5
0x3ED
0x400
0x5D5
0x5D7
0x6D4
0x77A
0x7D5


----------



## JWardell

Calibr8r said:


> I figured I would start documenting the ID's that come & go on Vehicle CAN through the software updates and start a spreadsheet to see what comes & goes.
> 
> Here are items that are no longer available from the excel spreadsheet in the first post:
> 
> observed in 2019.28.3.1
> 
> 
> 
> Code:
> 
> 
> 0x154
> 0x1D4
> 0x214
> 0x215
> 0x217
> 0x244
> 0x26A
> 0x276
> 0x2B2
> 0x2E1
> 0x2E2
> 0x2E5
> 0x304
> 0x316
> 0x328
> 0x356
> 0x357
> 0x35A
> 0x35B
> 0x376
> 0x388
> 0x392
> 0x396
> 0x3B9
> 0x3D6
> 0x3D6
> 0x3D9
> 0x3D9
> 0x3E2
> 0x3E2
> 0x3FF
> 0x3FF
> 0x401
> 0x401
> 0x4E2
> 0x4E2
> 0x505
> 0x505
> 0x514
> 0x514
> 0x518
> 0x518
> 0x51E
> 0x51E
> 0x526
> 0x526
> 0x529
> 0x529
> 0x541
> 0x541
> 0x550
> 0x556
> 0x557
> 0x5F4
> 0x656
> 0x712
> 0x757
> 
> Here are the new ID's:
> 
> 
> 
> Code:
> 
> 
> 0x020
> 0x082
> 0x128
> 0x1D8
> 0x1E5
> 0x1FB
> 0x200
> 0x279
> 0x27D
> 0x29D
> 0x2BD
> 0x315
> 0x334
> 0x335
> 0x33A
> 0x367
> 0x36B
> 0x36E
> 0x385
> 0x395
> 0x398
> 0x3A5
> 0x3B5
> 0x3C5
> 0x3D5
> 0x3E5
> 0x3ED
> 0x400
> 0x5D5
> 0x5D7
> 0x6D4
> 0x77A
> 0x7D5


Ouch, that is a lot. 
@amund7 we have some work to do!


----------



## amund7

Good news,

my German friends now has a website running, where they sell cables for most Teslas. They also sell a raspberry pi based web API statistics logger called 'Teslalogger'. (An open source project) Check it out:
https://www.e-mobility-driving-solutions.com/produkt-kategorie/cable/?lang=en


----------



## amund7

bwilson4web said:


> AAAGGGGGHHHHHH!!!!
> 
> So we'd join an 'Enigma' hunt like _The Imitation Game_ . . . trying to decode the latest Tesla code.
> 
> Bob Wilson


Scan My Tesla can decode the highest and lowest cell voltage, as well as temperatures. But not ALL of them simultaneously, as we still can with Model S/X. This means we can read the cell imbalance perfectly, just not a complete map of all the cells.

CAN ID 0x332

Here is my C# code from Canbus Analyzer (not yet released) and live in Scan My Tesla 1.8.0: (Will try to add it nicely to the Sheet later)


Code:


double? ExtractSignalFromBytes(byte[] bytes, int StartBit, int BitSize, bool signed, double ScaleFactor, double Offset)

      packets.Add(0x332, p = new Packet(0x332, this));
      p.AddValue("Cell temp max", "C", "cb", (bytes) => {
        if ((bytes[0] & 3) == 0)
          return cellTempMax = ExtractSignalFromBytes(bytes, 16, 8, false, 0.5, -40);
        else return null;
      });
      p.AddValue("Cell temp mid", "C", "cbmp", (bytes) => {
        if ((bytes[0] & 3) == 0)
          return (cellTempMax + cellTempMin) / 2.0;
        else return null;
      });
      p.AddValue("Cell temp min", "C", "cb", (bytes) => {
        if ((bytes[0] & 3) == 0)
          return cellTempMin = ExtractSignalFromBytes(bytes, 24, 8, false, 0.5, -40);
        else return null;
      });

      p.AddValue("Cell volt max", "V", "b", (bytes) => {
        if ((bytes[0] & 3) == 1)
          return cellVoltMax = ExtractSignalFromBytes(bytes, 2, 12, false, 0.002, 0);
        else return null;
      });
      p.AddValue("Cell volt mid", "V", "b", (bytes) => {
        if ((bytes[0] & 3) == 1)
          return (cellVoltMax + cellVoltMin) / 2.0;
        else return null;
      });
      p.AddValue("Cell volt min", "V", "b", (bytes) => {
        if ((bytes[0] & 3) == 1)
          return cellVoltMin = ExtractSignalFromBytes(bytes, 16, 12, false, 0.002, 0);
        else return null;
      });
      p.AddValue("Cell imbalance", "mV", "b", (bytes) => {
        if ((bytes[0] & 3) == 1)
          return (cellVoltMax - cellVoltMin) * 1000;
        else return null;
      });


----------



## scottf200

amund7 said:


> Good news,
> 
> my German friends now has a website running, where they sell cables for most Teslas. They also sell a raspberry pi based web API statistics logger called 'Teslalogger'. (An open source project) Check it out:
> https://www.e-mobility-driving-solutions.com/produkt-kategorie/cable/?lang=en


Newer (2019+) M3s


----------



## JWardell

scottf200 said:


> Newer (2019+) M3s
> 
> View attachment 28757


Seems to not have 2018 model 3 cables. 
Also seems our two cable sources here have dried up.
Lack of cables have contributed to my feet dragging...


----------



## michi84

Seems like he is focusing on Europe, where the first Model 3s arrived in 2019. I have ordered one for my Model 3 AWD which was built in late April 2019. Will test it with my OBDLink MX and ScanMyTesla.

I have also tried reaching out to geotab who make the cables for fleetcarma, but so far did not get any answer wether it is possible to buy the cable from them. They have one for 2018 model 3s (HRN-CT20T1, can be ordered from www.xtss.com for 28 USD, don't know if they are really in stock). The part number for 2019 model 3s seems to be HRN-CT20T11, but besides a photo on reddit i could not find any further reference to that, let alone a supplier to order it.


----------



## Roci

michi84 said:


> Seems like he is focusing on Europe, where the first Model 3s arrived in 2019. I have ordered one for my Model 3 AWD which was built in late April 2019. Will test it with my OBDLink MX and ScanMyTesla.
> 
> I have also tried reaching out to geotab who make the cables for fleetcarma, but so far did not get any answer wether it is possible to buy the cable from them. They have one for 2018 model 3s (HRN-CT20T1, can be ordered from www.xtss.com for 28 USD, don't know if they are really in stock). The part number for 2019 model 3s seems to be HRN-CT20T11, but besides a photo on reddit i could not find any further reference to that, let alone a supplier to order it.


Found an installation video for that cable, looks like a good deal too, $28 plus $12 shipping.


----------



## Calibr8r

I was logging the Battery Coolant Flow Rate during a supercharging session and the flow seemed to be inverse to what The temperature readings would suggest. Does anyone know if this scaling/offset is correct? (255-x)*0.1 seems in the ballpark but that's just a wild guess.


----------



## Ren001

scottf200 said:


> Newer (2019+) M3s


I ordered this cable yesterday. As I am located near Germany (like michi84), it will hopefully arrive within days and I am going to use it with Scan my Tesla and OBDLInk LX.

I am using Teslalogger since 3 month - its a very helpful tool to keep track of trips and power consumption.
In addition Teslalogger supplies a conversion of information received from the Tesla API to MQTT Topics, which I use to feed openhab2 without the need of the Tesla binding.


----------



## amund7

amund7 said:


> A lot of changes in the recent 2019.28.3.1 software:
> 
> and front and rear power has gone crazy / garbage / not sure what's going on (CAN ID 0x2E5, 0x266)


I found it, the power signal has moved from start bit 16 to start bit 0. Still the same offset and scaling.
'Heat power' is gone, as far as I can tell. There are 3 or 4 other byte values, which make little sense to me, some are the inverse of the power, while others top out flat.
Canbus Analyzer will get an update today that implements both versions of the packets.

Has anyone found out how to read the firmware version via canbus? It is known in Model S/X.


----------



## flo_muc

ID 0x1D8, s13 starting from bit 17 looks like front torque, but is not very smooth.

anybody got any further values figured out?


----------



## TomT

Got mine today and it works fine with my OBDLink LX on my late March 2019 M3. No VAT added to the U.S. of course...
Finally I can use the app!



scottf200 said:


> Newer (2019+) M3s
> View attachment 28757


----------



## JWardell

I'm still waiting (2 months now) for new firmware before I do a new capture.


----------



## Calibr8r

So I have found the formula that finally matches my displayed battery percentage:



Code:


(( [Remaining battery charge kWh] - [Energy Buffer kWh] )   /   ( [Full battery capacity kWh] - [Energy Buffer kWh] )) * 100

ROUND the result.


----------



## prensel

Hi all,

I've just received my EVTV Model 3 CAN monitor kit today and discovered they had the CAN LO and HI wiring swapped (green on HI...) on the ESP32 CANdue device.
After swapping the wiring (green on LO and white on HI) it works, spitting out CAN data.

Next step is to add a pair of DB9 connectors between the CANdue device and wiring for easy removal and/or replacement with other DB9 equiped CANbus devices like a Peak USB adapter or the Leonardo/Arduino CANbus.

I'm mainly/first interested in the individual cell voltages and temps to monitor battery behaviour.
Somewhere I have read that the EVTV sample program for monitoring the cell values doesnt work anymore.
Is there information available on what (new) CANid's contain the cell values ?

Paul


----------



## Calibr8r

prensel said:


> Hi all,
> 
> I've just received my EVTV Model 3 CAN monitor kit today and discovered they had the CAN LO and HI wiring swapped (green on HI...) on the ESP32 CANdue device.
> After swapping the wiring (green on LO and white on HI) it works, spitting out CAN data.


Mine came swapped incorrectly also. I let Jack know after I diagnosed they were in the wrong locations. I guess his existing inventory may not have been checked since I brought it to his attention. I think Jack does it as a 'right-of-passage' test lol.


----------



## JWardell

Calibr8r said:


> So I have found the formula that finally matches my displayed battery percentage:
> 
> 
> 
> Code:
> 
> 
> (( [Remaining battery charge kWh] - [Energy Buffer kWh] )   /   ( [Full battery capacity kWh] - [Energy Buffer kWh] )) * 100
> 
> ROUND the result.


I believe that is the equation we were using, but I believe there is a further temperature correction that shows only in the GUI (even Teslafi doesn't reflect the additional GUI adjustment). Its should remove a few more percent in cold temps especially below freezing.



Calibr8r said:


> Mine came swapped incorrectly also. I let Jack know after I diagnosed they were in the wrong locations. I guess his existing inventory may not have been checked since I brought it to his attention. I think Jack does it as a 'right-of-passage' test lol.


Sadly you may be more right than you think. Seeing his interaction today, he very much puts in extra effort to avoid effort supporting those who don't fully understand this very little understood technology.


----------



## Calibr8r

JWardell said:


> I believe that is the equation we were using, but I believe there is a further temperature correction that shows only in the GUI (even Teslafi doesn't reflect the additional GUI adjustment). Its should remove a few more percent in cold temps especially below freezing.


Ahh, I guess I missed where this formula was already displayed. Thanks for the additional info though 
Do you know where I could find that formula?

Jacks response to my email to him after purchasing his module was less than stellar also. At that point I decided that I wouldn't be using his products as a crutch for my laziness anymore.


----------



## prensel

Calibr8r said:


> Mine came swapped incorrectly also. I let Jack know after I diagnosed they were in the wrong locations. I guess his existing inventory may not have been checked since I brought it to his attention. I think Jack does it as a 'right-of-passage' test lol.


The first thing I did after receiving the kit was opening the box and then I noticed the green wire was (probably) on the wrong connection. 
After first use and getting no data it was obvious that was indeed the case. 
Probably a ****up from the guy on the assembly line.

Anyway i'm happy with the kit, works like a charm although i will make some additions like a sdcard adapter and LCD output.
Also will install 2 female DB9 connectors on the box for getting easier access to both CANbus ports.


----------



## prensel

amund7 said:


> Scan My Tesla can decode the highest and lowest cell voltage, as well as temperatures. But not ALL of them simultaneously, as we still can with Model S/X. This means we can read the cell imbalance perfectly, just not a complete map of all the cells.
> 
> CAN ID 0x332
> 
> Here is my C# code from Canbus Analyzer (not yet released) and live in Scan My Tesla 1.8.0: (Will try to add it nicely to the Sheet later)


I noticed there are two more temperature values in this message 0x332.
Although you name the first two values min and max i rather think they are just sensor values, not perse min or max values.
During a charge (from 90 - 95%) i noticed all four values are slightly rising within a degree from each other and at some point they where all equal


----------



## Perscitus

One of these things is not like the others... HRN-CT20T1 for the pre 2019 cars is now up to rev 3 vs the old Fleetcarma rev 1 loom.


----------



## prensel

Received update 2019.32.2.1 today and noticed there are some changes. 
Seems they skipped some addresses too hence the shorter list.


----------



## amund7

flo_muc said:


> ID 0x1D8, s13 starting from bit 17 looks like front torque, but is not very smooth.
> 
> anybody got any further values figured out?


Studied this one a bit today, can't find the correct start bit, it always seems to wrap around.

But at the same time I realized this is not front torque, but rear. See here graphed together with 108 which is the 'old' rear torque. Graph shows sb24, u16.
Front torque in 3 LR is rarely active, only with heavy throttle or slippery surfaces. Which is why I suggest this is rear torque, not front.
Let me know if you find another that could be front torque!


----------



## michi84

Got the cable from germany yesterday and installed it today. Works fine with Scan My Tesla.

@amund7: If you have a beta version which shows power output with current firmware 2019.28.3 or higher, i would be ready to test it with my AWD.

Your current version shows 385 kw rear power in idle.


----------



## amund7

michi84 said:


> Got the cable from germany yesterday and installed it today. Works fine with Scan My Tesla.
> 
> @amund7: If you have a beta version which shows power output with current firmware 2019.28.3 or higher, i would be ready to test it with my AWD.
> 
> Your current version shows 385 kw rear power in idle.


Have you updated to today's release v1.8.1? It contains the power you want


----------



## JWardell

Finally got a software update, so I will do a capture this week and start diving into changes as well.


----------



## michi84

amund7 said:


> Have you updated to today's release v1.8.1? It contains the power you want


Not yet. I checked yesterday evening for an update, and forgot to check again before my first test. Will update and try again tomorrow.


----------



## Juggernaut

JWardell said:


> Seems to not have 2018 model 3 cables.
> Also seems our two cable sources here have dried up.
> Lack of cables have contributed to my feet dragging...


Hi JWardell,
it's a wrong impression. I have the cables as well in stock and ship them on request worldwide.
That was the intentions of the website to provide barrier free access to the cables.
But there are many people around not aware, that there are differences.

I have supplied already some of the (M3<=12/2018) prototypes for testing purposes to Mr. TM-Spy, 
but never heard anything afterwards from him. So in case you need the cables they 
are available too, but i considerd it safer to start with the cables needed in europe.

One 24h M3 street world record team was using it over the whole run. Worked fine and showed 
as well really dangerous temps of over 60°C during their run while charging at ionity.

BR
/mkl


----------



## michi84

Front and rear power works fine, the front motor is only active during heavy acceleration. At 65% SOC, i get 300 kW combined power, in fact, it's a few kW more than battery power, which seems odd since this would mean more then 100% motor efficiency which of course is impossible.

An example during a 0-130 km/h run: Voltage 329.42, Amps 902, Battery Power 297.13 kW, front motor power 109 kW, rear motor power 191 kW -> combined motor power 300 kW. Speed was 72 km/h at that moment.

My best guess is that the reported motor power is electrical power, not mechanical power, which would explain why combined power and battery power are almost the same. The few kW between those values might be inaccuracies.

What you can also see is that the rear motor reaches its maximum power output of slightly more than 200 kW in the speed range 85-90 km/h (it fluctuates a little between 197 and 201 kW), and then begins to drop slightly from 95 km/h on. At the same time, front motor power increases from around 100 kW to a maximum of 124 kW at 126 km/h, at which point rear motor power is down to 174 kW, effectively making up the rear motor power loss. I will try to make a nice diagram of all this.

@amund7: How do i record a raw CAN log (for CANBUS Analyzer) with Scan My Tesla? I read in the instructions that this should be possible, but i could not find the option in the menu? Am i blind?


----------



## amund7

michi84 said:


> The few kW between those values might be inaccuracies.


Or lights, HVAC and computers... Yes, the motors report electrical power consumed.



michi84 said:


> @amund7: How do i record a raw CAN log (for CANBUS Analyzer) with Scan My Tesla? I read in the instructions that this should be possible, but i could not find the option in the menu? Am i blind?


Maybe  Long-press the recording button, select 'Can dump' (captures ALL data) or 'Raw log' (same format, but filters only the data on your current tab).


----------



## beachmiles

Can you post a direct link to the OBD adapter cable I need for the M3 in the OP? I clicked many links trying to find a cable for the M3 and it seems like there may be 2 options (which I now can't find) with 1 under the driver wheel and 1 at the bottom rear of the center console. The 1 under the driver wheel seems cleaner but looked like I had to buy another adapter that looked like a OBD Bluetooth adapter but it wasn't.


----------



## JWardell

beachmiles said:


> Can you post a direct link to the OBD adapter cable I need for the M3 in the OP? I clicked many links trying to find a cable for the M3 and it seems like there may be 2 options (which I now can't find) with 1 under the driver wheel and 1 at the bottom rear of the center console. The 1 under the driver wheel seems cleaner but looked like I had to buy another adapter that looked like a OBD Bluetooth adapter but it wasn't.


Good idea, I will add that now, although cables are still hard to come by.



Juggernaut said:


> Hi JWardell,
> it's a wrong impression. I have the cables as well in stock and ship them on request worldwide.
> That was the intentions of the website to provide barrier free access to the cables.
> But there are many people around not aware, that there are differences.
> 
> I have supplied already some of the (M3<=12/2018) prototypes for testing purposes to Mr. TM-Spy,
> but never heard anything afterwards from him. So in case you need the cables they
> are available too, but i considerd it safer to start with the cables needed in europe.
> 
> One 24h M3 street world record team was using it over the whole run. Worked fine and showed
> as well really dangerous temps of over 60°C during their run while charging at ionity.
> 
> BR
> /mkl


Let me know when you added to 2018 version and I will update the links


----------



## michi84

I have taken a look at the updated CAN spreadsheet and the inverter temps. If ScanMyTesla currently uses ID 376 to display inverter temperatures, then from my observations it seem that they are indeed the front motor inverter temps.

Reason: When the battery is still cold and passively heated, during regen braking the front motor shows 2-3 kW positive power (it stays at zero otherwise during regen). At the same time, the inverter capacitor temp (as labeled in SMT) rises quickly, and drops again when coming out of regen. After battery warmup, such sudden temperature rises only happen when i apply enough throttle to get the front motor into action.

If it ist helpful, i can provide a CAN dump recording from my AWD with SMT.


----------



## JWardell

michi84 said:


> I have taken a look at the updated CAN spreadsheet and the inverter temps. If ScanMyTesla currently uses ID 376 to display inverter temperatures, then from my observations it seem that they are indeed the front motor inverter temps.
> 
> Reason: When the battery is still cold and passively heated, during regen braking the front motor shows 2-3 kW positive power (it stays at zero otherwise during regen). At the same time, the inverter capacitor temp (as labeled in SMT) rises quickly, and drops again when coming out of regen. After battery warmup, such sudden temperature rises only happen when i apply enough throttle to get the front motor into action.
> 
> If it ist helpful, i can provide a CAN dump recording from my AWD with SMT.


It appears that 376 is now for the front inverter, and rear inverter temps have moved to 315. I no longer have 376 in my RWD. 
A short AWD log from recent firmware would be helpful to verify other messages for the front motor. 
It seems to me they are moving around motor and inverter messages, probably to make room for 3 & 4 motor vehicles (plaid & semi).


----------



## michi84

Here you go - two logs from my AWD. The shorter one is a deceleration to show rising inverter temps, the second one a quick acceleration, followed by full regen braking.


----------



## carleeno

First post here finally! Thanks for inviting me over JWardell.
I wanted to share some video and data from some of my autocross runs, if you think any of it would be helpful. I want to start helping in the effort to decode more signals (including some race data related signals such as inputs, gforce, gps). But for now, here's a video including some stuff you guys have already decoded 

Also, is it safe to post CANDumps, or do they contain VINs, etc?


----------



## JWardell

michi84 said:


> Here you go - two logs from my AWD. The shorter one is a deceleration to show rising inverter temps, the second one a quick acceleration, followed by full regen braking.


Thanks! I found known 2E5 and 376 with a quick look, which I don't have in RWD. I need more time to look for things we don't know about.



carleeno said:


> First post here finally! Thanks for inviting me over JWardell.
> I wanted to share some video and data from some of my autocross runs, if you think any of it would be helpful. I want to start helping in the effort to decode more signals (including some race data related signals such as inputs, gforce, gps). But for now, here's a video including some stuff you guys have already decoded
> 
> Also, is it safe to post CANDumps, or do they contain VINs, etc?


Awesome, how are you embedding the data in the video? Very cool! 
A can dump will contain your VIN, unless you delete 0x405 as I do. Up to you want you want to post publicly.


----------



## carleeno

JWardell said:


> Awesome, how are you embedding the data in the video? Very cool!
> A can dump will contain your VIN, unless you delete 0x405 as I do. Up to you want you want to post publicly.


I'm using DashWare (PC) to import the csv from Scan My Tesla. I ended up writing a vba script to fill in the blank data (since not every row is populated for every column) but after doing that, I'm not sure if it was necessary.

So I just searched my can dumps for 0x405, and realized that the can dumps were filtered since I was using a custom tab in SMT... so everything else is lost 

@amund7 is it possible to log an unfiltered candump while also logging a csv of a tab? I had both checked but I guess that caused the filters to apply.


----------



## carleeno

@JWardell 
Moving our reddit conversation over here...
the SMT can dump is a .txt, see attached (this one is filtered unfortunately).
I was trying to figure out how to open it in savvycan as well, no luck, but no experience with that program either.
I could probably write a script, can you send me a candump that is known to work in savvycan?

Maybe I should make something that can log from both CAN busses and save straight to csv (kind of like the candue, but you know how I feel about that company haha), and just use SMT for live viewing with it's pretty gauges 
What do you use to log?


----------



## Collin80

I was notified that SavvyCAN could not open the recently posted captures. Well, it can now but I haven't committed it yet because it's not really quite ready yet. But, here are the files converted to CANAlyzer ASC format which SavvyCAN (and obviously the Vector tools) can read. I did remove the 0x405 messages from these just in case.


----------



## JWardell

carleeno said:


> @JWardell
> Moving our reddit conversation over here...
> the SMT can dump is a .txt, see attached (this one is filtered unfortunately).
> I was trying to figure out how to open it in savvycan as well, no luck, but no experience with that program either.
> I could probably write a script, can you send me a candump that is known to work in savvycan?
> 
> Maybe I should make something that can log from both CAN busses and save straight to csv (kind of like the candue, but you know how I feel about that company haha), and just use SMT for live viewing with it's pretty gauges
> What do you use to log?


I think I've logged with 5 different things, mostly commercial though. I still think a Peak dongle is the best CAN to USB for those that are serious, and that's supported by a ton of software (Including Tesla's EDR tool...)
The problem with the OBD tool is it's not fast enough to grab and transmit all the data and there is a ton of dropouts. Not a problem for gauges but nasty for logged data.
I really need to join forces with some software folks because software hangups ultimately stop my hardware projects in their tracks, and I can think of so many more things to do with software. I pester the guys in here enough though 

Edit.. and while I was posting @Collin80 swoops in with a new version that solves things. This is why you guys are awesome


----------



## carleeno

Indeed, you guys are awesome.
I'm wondering if a RPi 4 would be able to log fast enough to not have dropouts, so I don't need to have a laptop in the car while autox-ing. And now that I know there is GPS (and potentially other useful stuff) on the other CANBus, I need to try to find a dongle that supports 2 busses preferably, so I don't need a hub and 2 dongles.

Do you know if there is accelerometer data on the Vehicle can, or is it probably on the chassis can too?


----------



## carleeno

Now that I'm looking at the candump from SMT, I notice there's no time references...
@amund7, Is there a fixed time interval for each line in the candump? If not, would it be possible to add accumulated time since start of log in each line (similar to the first column of the csv)?


----------



## JWardell

carleeno said:


> Indeed, you guys are awesome.
> I'm wondering if a RPi 4 would be able to log fast enough to not have dropouts, so I don't need to have a laptop in the car while autox-ing. And now that I know there is GPS (and potentially other useful stuff) on the other CANBus, I need to try to find a dongle that supports 2 busses preferably, so I don't need a hub and 2 dongles.
> 
> Do you know if there is accelerometer data on the Vehicle can, or is it probably on the chassis can too?


A Pi 2 is fast enough...we use them for all sorts of CAN stuff at work, typically with Peak dongles.
I've never come across accelerometer data, but then again we only have a small fraction of messages decoded.



carleeno said:


> Now that I'm looking at the candump from SMT, I notice there's no time references...
> @amund7, Is there a fixed time interval for each line in the candump? If not, would it be possible to add accumulated time since start of log in each line (similar to the first column of the csv)?


The SMT dump is just saving off serial data from the OBD-link as it comes in. None of that hardware is designed to timestamp things.
This is a big difference between this method and the more commercial hardware and software. Same goes for multiple simultaneous busses.
The harder part, though, is connecting to the other busses while still having a drivable car.


----------



## carleeno

JWardell said:


> ... Same goes for multiple simultaneous busses.
> The harder part, though, is connecting to the other busses while still having a drivable car.


So if I used 2 dongles to separately connect to 2 busses, that wouldn't cause any problems with the network, would it? I believe I saw a pintout of the connector under the center console showing that it had 3 busses plus vcsec, I need to find that again.


----------



## JWardell

Collin80 said:


> I was notified that SavvyCAN could not open the recently posted captures. Well, it can now but I haven't committed it yet because it's not really quite ready yet. But, here are the files converted to CANAlyzer ASC format which SavvyCAN (and obviously the Vector tools) can read. I did remove the 0x405 messages from these just in case.


It seems SavvyCAN still has issues with these converted files, there are CAN IDs that are not actually present, and in the log viewer window it also shows a number of extended CAN IDs (but with preceding zeros)

Anyway, here are the differences between these and my recent log, should be enough for me to pick through and look at what else is new:


----------



## amund7

carleeno said:


> I'm using DashWare (PC) to import the csv from Scan My Tesla. I ended up writing a vba script to fill in the blank data (since not every row is populated for every column) but after doing that, I'm not sure if it was necessary.
> 
> So I just searched my can dumps for 0x405, and realized that the can dumps were filtered since I was using a custom tab in SMT... so everything else is lost
> 
> @amund7 is it possible to log an unfiltered candump while also logging a csv of a tab? I had both checked but I guess that caused the filters to apply.


Very cool video!

CSV and Can dump should work simultaneously like you expect. Just make sure you selected can dump, not raw log - raw log is filtered, can dump is not.

You would probably have to check CSV and can dump, THEN press record, the record button clears the CAN filters as you press it. Let me know if that works out for you or not, will look into it if it doesn't.


----------



## amund7

carleeno said:


> Now that I'm looking at the candump from SMT, I notice there's no time references...
> @amund7, Is there a fixed time interval for each line in the candump? If not, would it be possible to add accumulated time since start of log in each line (similar to the first column of the csv)?


Those logs were just meant for debugging, to show me what the app was seeing on the other side of the world if people had issues. I never intended it to become full fledged logging and canbus analyzing tools built on top of it.. even if I built one of those tool myself.

I have thought to add time stamps in there many times, the problem is, then I'll break all the tools... suppose it just needs to be done, and the tools need to be updated.
Any thoughts on the timestamp format? CSV uses milliseconds since log start, but I'm not sure that is fast enough some times.


----------



## JWardell

I have a long-overdue updated DBC file, and moved it over to Github:

https://github.com/joshwardell/model3dbc

I've tried to address message IDs that have changed in firmware in the last few months, in my guess to make space for 3 & 4 drivetrains...

I need everyone's help to dial in the specifics of these messages, most importantly the scaling and what actual data each signal is.

New messages to look at are:

0x1D5 front torque
0x1D8 rear torque
0x2E5 front power
0x266 rear power
0x376 front inverter temperatures (this message has disappeared from RWD)
0x315 rear inverter temperatures (seems otherwise unchanged from 376)
0x395 (no idea, seems front-only)
0x396 (similar data format, all cars)
0x186 (front-only, not sure what is in here)

Also, first time I'm really using Github, please tell me if I'm doing something wrong.

The spreadsheet has also been updated with notes on all of this.



amund7 said:


> Those logs were just meant for debugging, to show me what the app was seeing on the other side of the world if people had issues. I never intended it to become full fledged logging and canbus analyzing tools built on top of it.. even if I built one of those tool myself.
> 
> I have thought to add time stamps in there many times, the problem is, then I'll break all the tools... suppose it just needs to be done, and the tools need to be updated.
> Any thoughts on the timestamp format? CSV uses milliseconds since log start, but I'm not sure that is fast enough some times.


I would encourage an already standardized and supported format...Vector CSV for example, or Peak?


----------



## carleeno

amund7 said:


> Very cool video!
> 
> CSV and Can dump should work simultaneously like you expect. Just make sure you selected can dump, not raw log - raw log is filtered, can dump is not.
> 
> You would probably have to check CSV and can dump, THEN press record, the record button clears the CAN filters as you press it. Let me know if that works out for you or not, will look into it if it doesn't.


Thanks! Can definitely attribute so much of it to you guys, so doubly thanks!

Regarding logging, I did check to verify, I had CSV and CAN Dump both checked (nothing else). I did that before going to autox. So there was likely an app close/relaunch from the time I enabled both to when I actually started logging.
Even during the event, there were several times I exited and relaunched the app (between runs) and started logging again. Both CSV and CAN Dump have remain checked.

I'm not sure which box I checked first, maybe it's possible I checked CAN Dump first, then enabled CSV next. Maybe the order in which you check them affects if filters are used or not. Tomorrow I'll experiment with this.

Also, I know it's a big change to do to multiple apps, but I agree with Wardell, if you go through the trouble to change the CAN Dump format, maybe instead create a 4th logging format in SMT that is the Vector CSV standard...then later you can add vector csv support to CBA.

Also, since SMT is a paid project, I'm not sure if it's open source, but I'd be glad to help in it's development if you wish. I'm trying to gain as much software experience as I can since I'm trying to transition my career 
I'd love to help add the ability for SMT to accept a DBC file, instead of manually adding it all to ...packets.cs (although I foresee this is not an easy task)


----------



## carleeno

Sorry guys I realized I started to hijack this thread last night with SMT bug troubleshooting. Using PM for that now.

@JWardell whats the typical packets per second you've seen logging unfiltered from the vehicle bus (while driving)? I want to get a feel for how much data I'm missing over bluetooth with the obdlink LX. Because I feel like phone hardware could keep up if a Pi 2 is fast enough, as long as the LX can keep up over bluetooth.


----------



## James W

Using a geotab harness and the info in the DBC file I was able to get my AiM SOLO 2 DL laptimer/datalogger to read and log from the CAN Bus. I only entered UI Speed and ABS Speed to test. 








(sorry for the bad pic)


----------



## JWardell

carleeno said:


> Thanks! Can definitely attribute so much of it to you guys, so doubly thanks!
> 
> Regarding logging, I did check to verify, I had CSV and CAN Dump both checked (nothing else). I did that before going to autox. So there was likely an app close/relaunch from the time I enabled both to when I actually started logging.
> Even during the event, there were several times I exited and relaunched the app (between runs) and started logging again. Both CSV and CAN Dump have remain checked.
> 
> I'm not sure which box I checked first, maybe it's possible I checked CAN Dump first, then enabled CSV next. Maybe the order in which you check them affects if filters are used or not. Tomorrow I'll experiment with this.
> 
> Also, I know it's a big change to do to multiple apps, but I agree with Wardell, if you go through the trouble to change the CAN Dump format, maybe instead create a 4th logging format in SMT that is the Vector CSV standard...then later you can add vector csv support to CBA.
> 
> Also, since SMT is a paid project, I'm not sure if it's open source, but I'd be glad to help in it's development if you wish. I'm trying to gain as much software experience as I can since I'm trying to transition my career
> I'd love to help add the ability for SMT to accept a DBC file, instead of manually adding it all to ...packets.cs (although I foresee this is not an easy task)





carleeno said:


> Sorry guys I realized I started to hijack this thread last night with SMT bug troubleshooting. Using PM for that now.
> 
> @JWardell whats the typical packets per second you've seen logging unfiltered from the vehicle bus (while driving)? I want to get a feel for how much data I'm missing over bluetooth with the obdlink LX. Because I feel like phone hardware could keep up if a Pi 2 is fast enough, as long as the LX can keep up over bluetooth.


I can try to answer these...
CBA already supports Vector CSV, thanks to @amund7 caving to my begging way back.
The code is all on GitHub, including libraries to read DBCs etc.
https://github.com/amund7/CANBUS-Analyzer

However, the amount of data is probably a major limitation, over 50% utilization of a 500kbps CAN network is fairly unheard of, and I'm not confident the OBDlink can even handle transmitting it all (see the buffer overruns in your dumps), let alone the incredible processing SMT would need to re format the data and save it into a new file format live.
Wired CAN USB to a Raspberry Pi should handle it like a champ though.


----------



## Vision

I have a obdii display device that auto powers on and off in my ice car. Would this be possible if I plug in the same device into the model 3 using the e-mobility cable or the evtv box? I assume the pid's would be off?


----------



## juanmax

carleeno said:


> First post here finally! ... But for now, here's a video including some stuff you guys have already decoded


What a first post!  congrats! Please more of those videos, next time in slow motion  so that we can better understand what is going on with the torque distribution front/rear


----------



## juanmax

JWardell said:


> I have a long-overdue updated DBC file, and moved it over to Github:
> 
> https://github.com/joshwardell/model3dbc


Very good! Here my 2cent: ID229 GearLever Command









PRND Values and meaning, half means only soft press, full means all the way. I couldn't come up with at better way to express this.








ParkButton is 0: not pressed 1: pressed, 2: undefined

Another question:
@JDWardell 0x175 in Chassis and Party bus is still missing in the excel, however it was already reported to be wheel speeds.


----------



## JWardell

juanmax said:


> Very good! Here my 2cent: ID229 GearLever Command
> 
> View attachment 29544
> 
> PRND Values and meaning, half means only soft press, full means all the way. I couldn't come up with at better way to express this.
> View attachment 29545
> 
> ParkButton is 0: not pressed 1: pressed, 2: undefined
> 
> Another question:
> @JDWardell 0x175 in Chassis and Party bus is still missing in the excel, however it was already reported to be wheel speeds.


Awesome find! I've added both wheel stalks to the DBC file, with a few changes after running them through the logs.
I also updated the spreadsheet with those and as you noted, some old missing updates to the Chassis bus. Wheel sensors were missing too. I don't think I gave that much attention because I only have one short log recording when I disconnected my seat.
Let me know what else you find.


----------



## carleeno

juanmax said:


> What a first post!  congrats! Please more of those videos, next time in slow motion  so that we can better understand what is going on with the torque distribution front/rear


Great idea! I could even slow down this current one and post it. I'm going back to autox on the 12th, so I'll have more data.
In fact, it's a bit hacky, but now I can log a full CAN dump on a pi while logging known values with SMT


----------



## carleeno

@juanmax Here you go


----------



## JWardell

carleeno said:


> Great idea! I could even slow down this current one and post it. I'm going back to autox on the 12th, so I'll have more data.
> In fact, it's a bit hacky, but now I can log a full CAN dump on a pi while logging known values with SMT
> View attachment 29600


Awesome! What are you using there to connect CAN to the Pi?


----------



## carleeno

JWardell said:


> Awesome! What are you using there to connect CAN to the Pi?


A PiCAN2 from copperhilltech.com, it has a built in SMPS as well so it can power it from the car's 12v 

I just made a python script that is logging a full can dump in GVRET_Log.csv format for savvycan!
I'm not sure what format would be best to use, but that's the one I started with.
Now I'm trying to familiarize myself with savvycan


----------



## JWardell

carleeno said:


> A PiCAN2 from copperhilltech.com, it has a built in SMPS as well so it can power it from the car's 12v
> 
> I just made a python script that is logging a full can dump in GVRET_Log.csv format for savvycan!
> I'm not sure what format would be best to use, but that's the one I started with.
> Now I'm trying to familiarize myself with savvycan


Nice, this one I assume:
https://copperhilltech.com/pican-2-can-bus-interface-for-raspberry-pi/

I didn't realize copper hill had so many can accessories.
And another for just 20 bucks:
https://copperhilltech.com/can-bus-plus-rs485-hat-for-raspberry-pi/

I've been meaning to teach myself PiQT to make CAN tools for the Pi as some others have been doing at work. Even more tempting when a $150 USB dongle isn't needed.

I'm very good at thinking of a ton of ideas for projects to do in my head, and very bad at carrying them through to fruition, and usually any kind of software stops me.

Still would love some help moving my stuff over to ESP32 and using its bluetooth to connect to OBD dongle instead of my current direct wire to Teensy setup. If anyone is interested


----------



## michi84

I have been playing around with the new DBC and the oil pump messages. Is it normal for the oil temp to always read 215? (255-40 offset)? The whole byte is always 1111111 in my recordings, and i am not sure if this is a bug / limitation of SMT CAN dumps or if the labeling is incorrect (e.g. OilPCBTemp and OilTemp reversed).

It looks like values from sensors which are not actually active default to the maximum, like powertrain messages during charging when the powertrain is not actually active. So it could also mean that although there is a provision in the message made for oil temp, it is not currently used or transmitted elsewhere.


----------



## carleeno

JWardell said:


> Nice, this one I assume:
> https://copperhilltech.com/pican-2-can-bus-interface-for-raspberry-pi/
> 
> I didn't realize copper hill had so many can accessories.
> And another for just 20 bucks:
> https://copperhilltech.com/can-bus-plus-rs485-hat-for-raspberry-pi/
> 
> I've been meaning to teach myself PiQT to make CAN tools for the Pi as some others have been doing at work. Even more tempting when a $150 USB dongle isn't needed.
> 
> I'm very good at thinking of a ton of ideas for projects to do in my head, and very bad at carrying them through to fruition, and usually any kind of software stops me.
> 
> Still would love some help moving my stuff over to ESP32 and using its bluetooth to connect to OBD dongle instead of my current direct wire to Teensy setup. If anyone is interested


Yea that one, but if you want the vehicle's 12v to power the pi, this one is better.
There is an existing project that I used for a jump start, it's done in python. However it's quite simple to read the can data using the python can library, just check out the user manual of the PiCAN2 on copperhill.


----------



## JWardell

michi84 said:


> I have been playing around with the new DBC and the oil pump messages. Is it normal for the oil temp to always read 215? (255-40 offset)? The whole byte is always 1111111 in my recordings, and i am not sure if this is a bug / limitation of SMT CAN dumps or if the labeling is incorrect (e.g. OilPCBTemp and OilTemp reversed).
> 
> It looks like values from sensors which are not actually active default to the maximum, like powertrain messages during charging when the powertrain is not actually active. So it could also mean that although there is a provision in the message made for oil temp, it is not currently used or transmitted elsewhere.


Yes, my old logs have reasonable oil temps, but recent logs are all at 215.


----------



## JWardell

It's been a while, but I finally have a *new DBC release and new CAN log* to share with everyone!
This covers many of the CAN changes in the past few months, but I still could use help finding a few more things.

Get the latest DBC here:
https://github.com/joshwardell/model3dbc

CAN log from 2019.32.11 v10
https://www.dropbox.com/s/vpz5b0c78qmqlt8/Model3Log2019-10-02v10.asc.zip?dl=0

Spreadsheet has had a lot of updates as well:

These appear to be the changes in v10 and recent versions of v9 from the last few months:
0x132 Battery V & A - Current offsets changed from 1000 to zero/500
(0x154 rear torques moved)
0x186 Front torque/RPM
(0x1D4 front torques moved)
0x1D5 Front torques
0x1D8 Rear torques
0x266 Rear power (kW) - signals have moved, need help determining some
0x2E5 Front power (kW) - signals have moved, need help determining some
0x315 Rear inverter temps
0x376 Front inverter temps (used to be rear)
0x395 Rear (?) oil pump
0x396 Front (?) oil pump - these seem to move around with different firmwares
0x5D5 looks like temperatures - any ideas?

There are a few more general messages and fixes to the DBC and spreadsheet as well.

As for the log, it has a little of everything for you to look at. Remember mine is a RWD so AWD logs are always welcome!

-Parked
-Plug in to charge
-Activate both steering stalks and buttons (these messages new to the DBC)
-Charging reaches 24A limit
-Turn off HVAC
-Charge for a bit
-Remove charger
-Reverse out of driveway
-Forward onto road, turn around, etc
-Stop then floor it onto highway.
-It's raining so you will see ton of traction control activation
-Reach 60-65 mph
-Regen off exit
-Turn and back on highway
-Activate autopilot quickly ~40mph
-exit highway
-Another stop and floor it just before the end

Sorry it's been so long, but I've been on Early Access firmware most of the year till now!
Also, I think a very significant new development is that instead of using mega expensive commercial CAN software as in the past, I've done all my sleuthing with free software - CANBUS-Analyzer from @amund7 and SavvyCAN from @Collin80 ! Huge thanks, sorry for my occasional nag for updates but as you can see these are super helpful! And as always lots of good help from @fast_like_electric as well.


----------



## michi84

Something changed with the oil pump states and voltage too. In Jwardells old log the oil pump state during driving is 1 (binary 00000001), in my case it is 9 (binary 00001001, Hex 09), taking into account the full first byte. In Can Bus Analyzer, because the DBC assumes only a 3 bit answer, the message is truncated and interpreted as 1. In a parked state, but with the car active (P button pressed) the response is 00000001.

Voltage is weird, in the old log it looks like 12V supply voltage, now it is much lower and varying. I suspect that the starting bits and message lenghts for these values might have changed-

0x5D5 B (starting bit 8) and C (starting bit 24) seem to be some rear motor or inverter temps: They rise and fall sharply with power demand, which means they rise and fall with current flow, and it must be something which does not have high heat capacity (e.g. no oil or coolant, rather some metal part in contact with a cooling medium) A is constant during two bursts of acceleration, so this must be something with high heat capacity, like oil or coolant.










In my AWD, there is another ID (0x556) which mirrors 0XD5, but only when my front motor is producing power. I tested this the following way: acceleration burst one with just enough throttle to keep the front motor (almost) off, but load the rear one enough to drive the temps up. The second one with full throttle.










Coolant temp at the battery inlet was 27°C, powertrain inlet 24,5°C. The temps follow the inverter heatsink temps, so they could be power electronic temps.

Rear heatsink:










Front heatsink:










The constant temp is close to the inverter PCB temp, but slightly higher. I will need more logs to study it. At that point it would be nice to have SMT with DBC capability, to monitor it live while driving.

@JWardell: In what range were your oil temps? Did they follow the OilPCB temp, or were the more like inverter temps? As 5D5A responds so slowly, but is higher than coolant temp, could it possibly be the oil temp which was for some reason removed from the oil messages?


----------



## JWardell

michi84 said:


> Something changed with the oil pump states and voltage too. In Jwardells old log the oil pump state during driving is 1 (binary 00000001), in my case it is 9 (binary 00001001, Hex 09), taking into account the full first byte. In Can Bus Analyzer, because the DBC assumes only a 3 bit answer, the message is truncated and interpreted as 1. In a parked state, but with the car active (P button pressed) the response is 00000001.
> 
> Voltage is weird, in the old log it looks like 12V supply voltage, now it is much lower and varying. I suspect that the starting bits and message lenghts for these values might have changed-
> 
> 0x5D5 B (starting bit 8) and C (starting bit 24) seem to be some rear motor or inverter temps: They rise and fall sharply with power demand, which means they rise and fall with current flow, and it must be something which does not have high heat capacity (e.g. no oil or coolant, rather some metal part in contact with a cooling medium) A is constant during two bursts of acceleration, so this must be something with high heat capacity, like oil or coolant.
> 
> View attachment 29642
> 
> 
> In my AWD, there is another ID (0x556) which mirrors 0XD5, but only when my front motor is producing power. I tested this the following way: acceleration burst one with just enough throttle to keep the front motor (almost) off, but load the rear one enough to drive the temps up. The second one with full throttle.
> 
> View attachment 29643
> 
> 
> Coolant temp at the battery inlet was 27°C, powertrain inlet 24,5°C. The temps follow the inverter heatsink temps, so they could be power electronic temps.
> 
> Rear heatsink:
> 
> View attachment 29644
> 
> 
> Front heatsink:
> 
> View attachment 29645
> 
> 
> The constant temp is close to the inverter PCB temp, but slightly higher. I will need more logs to study it. At that point it would be nice to have SMT with DBC capability, to monitor it live while driving.
> 
> @JWardell: In what range were your oil temps? Did they follow the OilPCB temp, or were the more like inverter temps? As 5D5A responds so slowly, but is higher than coolant temp, could it possibly be the oil temp which was for some reason removed from the oil messages?


Interesting, I am going to have to look through new and old logs to see how oil temps react. Don't forget though, this is not oil running through a hot IC engine and scraping pistons, just keeping some bearing lubricated, so I don't expect it would normally get much warmer than ambient.


----------



## JWardell

It's back!





My geek display spent a while in the basement, but I managed to update its firmware with the new v10 CAN messages, just in time for cold battery temps to start stealing regen.

I also looked back through my logs at regen temps (some people are thinking regen is reduced in v10...but I think it is just the cooler weather), and oil temps for @michi84 
I would say regen looks unchanged, and oil temps switched CAN IDs and values with v10 firmware. I don't have any logs between march and September.


----------



## carleeno

JWardell said:


> ...As for the log, it has a little of everything for you to look at. Remember mine is a RWD so AWD logs are always welcome!


Alright, here is an AWD log with 2019.32.11.1 firmware!
Involves a few minutes of driving, with a full acceleration, and lots of steep hills.
I had to split the file to 2 parts due to upload limit, just concat them.

I've updated my python logging script to output to the same ASC format you guys use, which means it can be opened with savvycan as well as canbus-analyzer

I was thinking I saw an accelerator pedal position in the dbc, but after searching, I can't find it...does anybody know if it was ever found? If not, I know what I'm going to be doing tonight


----------



## JWardell

carleeno said:


> Alright, here is an AWD log with 2019.32.11.1 firmware!
> Involves a few minutes of driving, with a full acceleration, and lots of steep hills.
> I had to split the file to 2 parts due to upload limit, just concat them.
> 
> I've updated my python logging script to output to the same ASC format you guys use, which means it can be opened with savvycan as well as canbus-analyzer
> 
> I was thinking I saw an accelerator pedal position in the dbc, but after searching, I can't find it...does anybody know if it was ever found? If not, I know what I'm going to be doing tonight


Awesome! Any chance you can publish that script? I have plenty of other can dumps from other folks that would be much more useful to me as ascii format.

Pedal position is in message 0x118 and in the DBC and spreadsheet.


----------



## Calibr8r

My own DIY logger display project was handy today to see what the “preconditioning battery for Supercharging” was doing with temps. Started with 31°c min battery temp and it was brought up to 36°c before I reached the supercharger in About 20 minutes. I’m not sure how high the preconditioning would have allowed the battery temps to get on a longer enroute trip. Battery inlet temp reached 41°c and battery inlet flow reached 9.4 LPM while preconditioning. 

I was very surprised 31°c Was still deemed low enough to require more preheating. Ambient was 27°c.


----------



## carleeno

JWardell said:


> Awesome! Any chance you can publish that script? I have plenty of other can dumps from other folks that would be much more useful to me as ascii format.
> 
> Pedal position is in message 0x118 and in the DBC and spreadsheet.


Oh! I had assumed that was brake pedal position...but checking the data, it seems that it's accelerator position. In that case, is there brake pedal %?

I think I will clean things up a bit and publish it with a write up on how/what to install (first I need to start over with a fresh install and document everything).
However that script would only work for people running a PiCAN2, I think, so would it be better to make a conversion script? That wouldn't be too hard if you can give me some examples of the other formats people send you.


----------



## carleeno

Calibr8r said:


> My own DIY logger display project was handy today to see what the "preconditioning battery for Supercharging" was doing with temps. Started with 31°c min battery temp and it was brought up to 36°c before I reached the supercharger in About 20 minutes. Battery inlet temp reached 41°c and battery inlet flow reached 9.4 LPM while preconditioning.
> 
> I was very surprised 31°c Was still deemed low enough to require more preheating. Ambient was 27°c.


It seems that the batteries like to be at human body temp to charge, haha.
I've been wondering where the heat comes from to precondition the batteries. In a tweet Musk said it would have negligible impact on range, so I wonder if it's taking heat from the motors, or using resistive heating, or even taking heat from the a/c (like a heat pump).
Do you notice if your motor temps started dropping as the battery was heating? Or a general increase in power consumption (maybe you were stopped at a light while conditioning, and can reference battery consumption)?


----------



## michi84

carleeno said:


> It seems that the batteries like to be at human body temp to charge, haha.
> I've been wondering where the heat comes from to precondition the batteries. In a tweet Musk said it would have negligible impact on range, so I wonder if it's taking heat from the motors, or using resistive heating, or even taking heat from the a/c (like a heat pump).
> Do you notice if your motor temps started dropping as the battery was heating? Or a general increase in power consumption (maybe you were stopped at a light while conditioning, and can reference battery consumption)?


The car seems to use two strategies to warm up the battery for supercharging - provided a supercharger is entered as destination in the nav system:

1) Passive heating via motor/inverter heat, using whatever waste heat is there during normal operation. This will probably include taking measures to avoid unnecessary heat loss, e.g. bypassing the radiator and using the battery as heatsink instead. This can and will start quite some time before you reach the supercharger.

2) Active heating by running motor/inverter inefficient: You get the preconditioning notification when that happens. In my dual motor, the front motor is then used with about 3.5 kW all the time, probably producing about that amount of heat and not contributing much to propulsion. At standstill, 4-7 kW are drawn from the battery. Inverter and stator temps rise significantly.

The target temp seems to be around 40°C, in normal operation, 30°C seems to be the target. When the cells go slightly above that, the powertrain an battery cooling loop are separated, this is notable with the powertrain inlet temp going suddenly up and above the battery inlet temp, which drops slighly below cell temp then.


----------



## JWardell

carleeno said:


> Oh! I had assumed that was brake pedal position...but checking the data, it seems that it's accelerator position. In that case, is there brake pedal %?
> 
> I think I will clean things up a bit and publish it with a write up on how/what to install (first I need to start over with a fresh install and document everything).
> However that script would only work for people running a PiCAN2, I think, so would it be better to make a conversion script? That wouldn't be too hard if you can give me some examples of the other formats people send you.


Brake pedal is also in 118, but it is a binary on or off. There might be some kind of brake pressure feedback from the ibooster but I haven't found that/maybe on a different bus.



carleeno said:


> It seems that the batteries like to be at human body temp to charge, haha.
> I've been wondering where the heat comes from to precondition the batteries. In a tweet Musk said it would have negligible impact on range, so I wonder if it's taking heat from the motors, or using resistive heating, or even taking heat from the a/c (like a heat pump).
> Do you notice if your motor temps started dropping as the battery was heating? Or a general increase in power consumption (maybe you were stopped at a light while conditioning, and can reference battery consumption)?


The inverters run the motors in a less efficient way-usually you are designing all your control algorithms and switching to be as efficient as possible-here they do the opposite. That generates extra heat (I bet we can see it in 375/376) which can then circulate into the battery.

Supercharging used to just charge at whatever the battery temp was, and any temp below 80F is a reduced charging rate. Of course the batteries heat as you charge, so it only took 5-15 min to get the battery up to temp, but this mode wastes a percent or two of range once you are 5-10 miles away from the supercharger, so the battery is warmer and can charge at a faster rate as soon as you plug in. It's trading a little bit of energy efficiency for time efficiency, which is probably more valuable.


----------



## Calibr8r

I just drove around today with my NAV set to my local supercharger destination just to see when the preconditioning notification would shut off or if the battery temp or coolant pump flow would level off. It reached 41°C and the pump flow was still churning. I’m starting to think they made the preconditioning system quite dumb and may not have an official shutoff threshold. Maybe it just stays on until you cancel your destination or arrive at the supercharger. These temps are far too warm to maximize the most ideal of charging sessions with minimal de-rate.

While supercharging I noticed that at about 48°C the charge rate begins to de-rate Long before it switching to constant-voltage charging, which I believe someone stated was the trigger point to turn on the AC chiller active cooling but I don’t know where this threshold was found. I have hit as high as 54°C but it seemed to level off at 52°C for the majority of the 150kw session

The typical 21700 Li-Ion cell datasheets show about 25°c is the point where high current charge rates are permitted and anything below that requires a much lower charge rate. They also show that the maximum permissible temp for charging is 45°C so clearly Tesla has more specific set points for their application.


----------



## michi84

I think i just found the battery target temperature in 0x212: starting bit 48, lenght 8 bit, no scaling and no offset. In Jwardells recent capture, during charging it is 54°C, during plugging in 46°C, and during driving 30°C. Does anyone have a supercharging CAN dump? 

I will try to record preconditioning next time i supercharge (coming weekend).


----------



## michi84

I also went through some old logs posted here regarding oil temp: oil temp and PCBOilTemp are practically the same. From that point it makes sense to drop one of the temps to make space for some other data. Now if it was oil temp or the PCB temp which was dropped we can only guess. To me, it would make more sense to monitor oil temp to detect possible problems in the drive unit. The PCB is possibly cooled by the oil, as long as oil temp is reasonable, there should be no problem. The new voltage varies with current, so i think it could be the actual drive voltage of the pump.

Also, as Jwardell noted, front and rear IDs have switched: 0X395 is now rear, 0x396 is front.


----------



## carleeno

michi84 said:


> ...
> 2) Active heating by running motor/inverter inefficient: You get the preconditioning notification when that happens. In my dual motor, the front motor is then used with about 3.5 kW all the time, probably producing about that amount of heat and not contributing much to propulsion. At standstill, 4-7 kW are drawn from the battery. Inverter and stator temps rise significantly.


Ahh I should have guessed, I noticed a couple of times before that the motor noise was noticeably louder and "different" when driving slow during preconditioning, sounding like it was coming from the front motor as well. That's brilliant, another case of a software solution to a hardware problem (turning the motor into a heater since there are no physical heating elements in the battery, or are there?)



JWardell said:


> Brake pedal is also in 118, but it is a binary on or off. There might be some kind of brake pressure feedback from the ibooster but I haven't found that/maybe on a different bus.


So last night I spent some time looking at every packet as an int with a short log of me pressing the brake pedal a few times, hoping to see a graph that matched my pattern...no luck finding a percentage, but is there a better way? Am I possibly missing some data because of this method (I'm a huge noob at this)?

I did however find a couple of packets that had more binary data related to braking:
3E2 and 3E3 contain data that relates to when the brake light is illuminated (whether regen, brake hold, or normal braking)
422 contains data that relates only to when the brake pedal is pressed, no regen or brake hold.
I wonder if these have anything to do with the ABS system? Seems strange to have duplicate to whats in 118.

Oh, I also found that 1A5 looks really interesting, and correlates with movement, for a second I thought it was longitudinal acceleration but it's not that. However it's only updating every 100ms, so doesn't have great resolution.

If anybody wants to give any pointers to how to find a pattern of an analog input (aside from setting all packets as ints in CBA) I'd greatly appreciate it!


----------



## Calibr8r

michi84 said:


> I think i just found the battery target temperature in 0x212: starting bit 48, lenght 8 bit, no scaling and no offset. In Jwardells recent capture, during charging it is 54°C, during plugging in 46°C, and during driving 30°C. Does anyone have a supercharging CAN dump?
> 
> I will try to record preconditioning next time i supercharge (coming weekend).


Thanks for that! So I just checked that address and these were my results:

46°C: unplugged, parked and not awake (didn't press brake pedal)
30°C: Unplugged, parked and awake (brake pedal depressed)
30°C: Driving
30°C: Preconditioning (we know preconditioning battery temps will ignore this limit)
38°C: Plugged-in but charger in fully 'off' state (can hear relay switch off)
54°C: Plugged-in not charging but maintaining power consumers (A/C etc...)
54°C: Plugged-in and charging

I will visit the supercharger on my way into work Tomorrow to see what values I get during DC-DC fast charging 👍🏻


----------



## JWardell

Calibr8r said:


> I just drove around today with my NAV set to my local supercharger destination just to see when the preconditioning notification would shut off or if the battery temp or coolant pump flow would level off. It reached 41°C and the pump flow was still churning. I'm starting to think they made the preconditioning system quite dumb and may not have an official shutoff threshold. Maybe it just stays on until you cancel your destination or arrive at the supercharger. These temps are far too warm to maximize the most ideal of charging sessions with minimal de-rate.
> 
> While supercharging I noticed that at about 48°C the charge rate begins to de-rate Long before it switching to constant-voltage charging, which I believe someone stated was the trigger point to turn on the AC chiller active cooling but I don't know where this threshold was found. I have hit as high as 54°C but it seemed to level off at 52°C for the majority of the 150kw session
> 
> The typical 21700 Li-Ion cell datasheets show about 25°c is the point where high current charge rates are permitted and anything below that requires a much lower charge rate. They also show that the maximum permissible temp for charging is 45°C so clearly Tesla has more specific set points for their application.


Don't forget there are endless different mixtures for lithium ion battery chemistry with varying properties and Tesla definitely has a soup that is best for them. You can't necessarily apply properties from another manufacturer.



michi84 said:


> I think i just found the battery target temperature in 0x212: starting bit 48, lenght 8 bit, no scaling and no offset. In Jwardells recent capture, during charging it is 54°C, during plugging in 46°C, and during driving 30°C. Does anyone have a supercharging CAN dump?
> 
> I will try to record preconditioning next time i supercharge (coming weekend).


Interesting. I don't think that was there before? Just some status bits. I will have to look back at older logs to see if this is something that changed.
I do have a supercharging log I posted a while ago.



carleeno said:


> Ahh I should have guessed, I noticed a couple of times before that the motor noise was noticeably louder and "different" when driving slow during preconditioning, sounding like it was coming from the front motor as well. That's brilliant, another case of a software solution to a hardware problem (turning the motor into a heater since there are no physical heating elements in the battery, or are there?)
> 
> So last night I spent some time looking at every packet as an int with a short log of me pressing the brake pedal a few times, hoping to see a graph that matched my pattern...no luck finding a percentage, but is there a better way? Am I possibly missing some data because of this method (I'm a huge noob at this)?
> 
> I did however find a couple of packets that had more binary data related to braking:
> 3E2 and 3E3 contain data that relates to when the brake light is illuminated (whether regen, brake hold, or normal braking)
> 422 contains data that relates only to when the brake pedal is pressed, no regen or brake hold.
> I wonder if these have anything to do with the ABS system? Seems strange to have duplicate to whats in 118.
> 
> Oh, I also found that 1A5 looks really interesting, and correlates with movement, for a second I thought it was longitudinal acceleration but it's not that. However it's only updating every 100ms, so doesn't have great resolution.
> 
> If anybody wants to give any pointers to how to find a pattern of an analog input (aside from setting all packets as ints in CBA) I'd greatly appreciate it!


0x3E2 and 0x3E3 are the light status message from VCLeft and VCright.
Unfortunately a large number of messages have data that is not byte by byte, its almost impossible to just stumble on data. I use the Flow View feature in SavvyCAN to literally stare at bits changing over time...it's like reading the Matrix.

Also, remember to cross reference both my DBC, and the ETH DBC where ~half the messages show up on CAN
https://brianman.visualstudio.com/D...th=/Samples/tesla_model3.dbc&version=GBmaster


----------



## Calibr8r

JWardell said:


> Don't forget there are endless different mixtures for lithium ion battery chemistry with varying properties and Tesla definitely has a soup that is best for them. You can't necessarily apply properties from another manufacturer.


Oh yes, I'm certainly aware. I've been bench testing the Tesla 2170 battery cells in-house and comparing them against others on the market for about 8 months now. The LG INR21700 M50T has had the closest properties that I have seen so far, in case anyone wants a good project battery to use lol. The best we can do is try and reverse engineer the thresholds that's Tesla is using and go from there.


----------



## michi84

Calibr8r said:


> I will visit the supercharger on my way into work Tomorrow to see what values I get during DC-DC fast charging 👍🏻


Check if the temp target changes when the preheating messages comes. If it does not, then there must be some other target which overules this one. From the video form ingeneerix where he shows the CAN viewer you get with root access to the car, there are active and passive targets for temperature control.


----------



## juanmax

JWardell said:


> Also, remember to cross reference both my DBC, and the ETH DBC where ~half the messages show up on CAN
> https://brianman.visualstudio.com/DBCTools/_git/DBCTools?path=/Samples/tesla_model3.dbc&version=GBmaster


Hi JWardell, since when do we have access to this ETH dbc? It is very useful. Do we know to which Software status corresponds or whether we can access older versions ?

Thanks!


----------



## Calibr8r

michi84 said:


> Check if the temp target changes when the preheating messages comes. If it does not, then there must be some other target which overules this one. From the video form ingeneerix where he shows the CAN viewer you get with root access to the car, there are active and passive targets for temperature control.


That's what I monitored when I did the test for ya. When the preconditioning message comes on it stays at the 30°C reading.

I had about 88% SoC on my car when I stopped at the Supercharger this morning for a test. I arrived with actual battery temps at 31.0°C. The target immediately jumped to 59°C when charging started for a moment and then dropped to 58°C for the remainder (stopped at 90% SoC). I will drain the battery down to 5-10% and visit the Supercharger again.


----------



## michi84

Calibr8r said:


> That's what I monitored when I did the test for ya. When the preconditioning message comes on it stays at the 30°C reading.
> 
> I had about 88% SoC on my car when I stopped at the Supercharger this morning for a test. I arrived with actual battery temps at 31.0°C. The target immediately jumped to 59°C when charging started for a moment and then dropped to 58°C for the remainder (stopped at 90% SoC). I will drain the battery down to 5-10% and visit the Supercharger again.


Then my theory seems right. What we see here is the passive heating/cooling target for the battery, which is overruled by the active heating/cooling target, provided the BMS wants to take active temperature control measures. I have (hopefully) managed to log an AC charging start with a cold (5°C) battery and active preheating. I had my phone with SMT in the car with Tasker set to start SMT one minute before with auto-logging enabled. I did not have time to check the log, but will report as soon as i can.


----------



## michi84

JWardell said:


> Also, remember to cross reference both my DBC, and the ETH DBC where ~half the messages show up on CAN
> https://brianman.visualstudio.com/D...th=/Samples/tesla_model3.dbc&version=GBmaster


That DBC is awesome, i am just starting to dive into it...

As for my charging log: Logging hung up after some minutes, but it was long enough to see some active battery heating. I have to analyze it further with some extra values from the DBC. Using the info from that treasure, it looks like w can now monitor some interesting data like coolant flow mode (series/parallel), coolant temp targets, a lot of VCFront and HVAC data and a ton more. The IDs match up with ours, the only thing we cannot be sure is if the decoding is correct in every case since there might have been changes. The DBC seems to be based on an older firmware, so use the info with caution and check the reported values for sanity.

I added some to my copy Jwardells DBC, only thing i did is add the CAN ID, change "eth" to "VehicleBus" and replace the X at the end of each line with "Receiver" (i did not yet bother to study the DBC structure, i just did what was neccessary to make it work).


----------



## Onyx

Hey guys. I just wanted to pop in to say that I've used the information you've all gathered to successfully tap into my Model 3 CANbus - so THANKS! I'm not gonna lie, I was terrified when I plugged it in. I was thinking "you're trusting the pin out of some Internet folks you've never met with your new 63k car!". Needless to say, I was relieved when nothing started burning and data started pouring in over the serial port. 

When I did this with my BMW, I had the full service manuals including all electricals, so it wasn't as scary.

At any rate, it's really awesome being able to see all the data. I'm going to do something with this for sure - just not quite sure yet. It'll likely involve getting all this lovely data on the main screen in a web app. Has anyone done something similar? (I like the idea of no wires and total integration with the stock "dashboard".)

(I can describe my setup if it's of interest, but I wasn't sure it wouldn't be off topic.)


----------



## JWardell

Onyx said:


> Hey guys. I just wanted to pop in to say that I've used the information you've all gathered to successfully tap into my Model 3 CANbus - so THANKS! I'm not gonna lie, I was terrified when I plugged it in. I was thinking "you're trusting the pin out of some Internet folks you've never met with your new 63k car!". Needless to say, I was relieved when nothing started burning and data started pouring in over the serial port.
> 
> When I did this with my BMW, I had the full service manuals including all electricals, so it wasn't as scary.
> 
> At any rate, it's really awesome being able to see all the data. I'm going to do something with this for sure - just not quite sure yet. It'll likely involve getting all this lovely data on the main screen in a web app. Has anyone done something similar? (I like the idea of no wires and total integration with the stock "dashboard".)
> 
> (I can describe my setup if it's of interest, but I wasn't sure it wouldn't be off topic.)


Welcome! I know some have thought about it before, but haven't seen much yet. I can imagine a Raspberry pi decoding and logging and generating a web web then served either by wifi or with its own cellular connection. With some latency no doubt but not a big deal for some data. A lot of work though so I don't think anyone has done it.



juanmax said:


> Hi JWardell, since when do we have access to this ETH dbc? It is very useful. Do we know to which Software status corresponds or whether we can access older versions ?
> 
> Thanks!


I think it's from January or February. And like I said, a lot isn't there (or maybe it is at another ID?), nor does it contain many other messages we do know about. I have only put data in my DBC that I have personally verified. Some programs let you load multiple DBCs at once so you shouldn't need to combine them.


----------



## juanmax

michi84 said:


> As for my charging log: Logging hung up after some minutes, but it was long enough to see some active battery heating. I have to analyze it further with some extra values from the DBC.


I have a log while doing a DC charging (20kW) session over more than 30 minutes long, in which the car did actively heat the battery even though I think it was not really needed. I could find this out since the charger was showing 20kW but the display in the car would show for very long (+15min) only 15kW or so. I reckoned the rest should be being pumped into the battery as heat, since ACC was off.

I can upload it if you want to have a look at it, it was from at least two months ago.


----------



## JWardell

juanmax said:


> I have a log while doing a DC charging (20kW) session over more than 30 minutes long, in which the car did actively heat the battery even though I think it was not really needed. I could find this out since the charger was showing 20kW but the display in the car would show for very long (+15min) only 15kW or so. I reckoned the rest should be being pumped into the battery as heat, since ACC was off.
> 
> I can upload it if you want to have a look at it, it was from at least two months ago.


Have a look through my supercharger log from much colder January:
https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-197034


----------



## michi84

@amund7: I have a problem with my CAN dumps - the adapter (OBDLink MX) seems to hang up after some time, sometimes minutes, sometimes even quicker. I have to unplug it and restart SMT to get it going again. Also, i sometimes get a message "adapter does not recognize STM after 6 attempts" during connecting to the car, however, it seems to work fine regardless for simply monitoring the gauges.


----------



## carleeno

michi84 said:


> @amund7: I have a problem with my CAN dumps - the adapter (OBDLink MX) seems to hang up after some time, sometimes minutes, sometimes even quicker. I have to unplug it and restart SMT to get it going again. Also, i sometimes get a message "adapter does not recognize STM after 6 attempts" during connecting to the car, however, it seems to work fine regardless for simply monitoring the gauges.


I might be able to help a bit here, For the error you get during startup about not recognizing STM after 6 attempts, tick the "ATMA before filters" option in the wrench menu, that should fix that.

I don't know if it'll help the hanging issue, it's possible it's bluetooth hanging up, have you tried disabling/enabling bluetooth on your phone instead of unplugging the obdlink?


----------



## michi84

I have ATMA before filters ticked, sometimes the error comes, sometimes not. The adapter is several years old. I have the newest firmware on it. Disabling and restarting bluetooth does not help, it is definitely the adapter hanging up.


----------



## Onyx

Well, I've got CAN traffic streaming to the main display. My setup is very rough and needs work before I can drive around, but it's a start (and a proof of concept of sorts.) I just have a log file display incoming traffic at this point. This was surprisingly tedious to get working, but I have to say that the v10 browser is very solid (it's a very recent version of Chrome with some extra Tesla goodies I wish I knew how to tap into).

Next step will be to build a signal explorer similar to the one Ingineerix showed in his video on the CAN signals. I'm thinking it'll be very nice to be able to drive around and mess with the signals from the main display.

Here's a quick video of what it looks like:


----------



## Calibr8r

michi84 said:


> Then my theory seems right. What we see here is the passive heating/cooling target for the battery, which is overruled by the active heating/cooling target, provided the BMS wants to take active temperature control measures. I have (hopefully) managed to log an AC charging start with a cold (5°C) battery and active preheating. I had my phone with SMT in the car with Tasker set to start SMT one minute before with auto-logging enabled. I did not have time to check the log, but will report as soon as i can.


Log the values JWardell shared in his spreadsheet for CAN ID 0x5D5 for active heating targets. These certainly get quite active during Supercharger Preconditioning, even while in my garage just sitting in Drive with Brake hold active and no motor RPM. Stator temps climb quite a bit. I'll try to get a road log on my way to work tomorrow.


----------



## JWardell

Onyx said:


> Well, I've got CAN traffic streaming to the main display. My setup is very rough and needs work before I can drive around, but it's a start (and a proof of concept of sorts.) I just have a log file display incoming traffic at this point. This was surprisingly tedious to get working, but I have to say that the v10 browser is very solid (it's a very recent version of Chrome with some extra Tesla goodies I wish I knew how to tap into).
> 
> Next step will be to build a signal explorer similar to the one Ingineerix showed in his video on the CAN signals. I'm thinking it'll be very nice to be able to drive around and mess with the signals from the main display.
> 
> Here's a quick video of what it looks like:


This is just downright badass


----------



## JWardell

I updated the DBC, first with some fleshed out signals for BMS 0x212 for @michi84 
But that has always been considered charge power available and retry count, not a target temp.

I have been looking at 5D5/556.

It appears that 0x556 is similar to 0x376 inverter temperatures, in that it was for the rear motor previously, and recently changed to 0x5D5 for rear motor, while 0x556 is now used for front motor.
I thought these contained 3 temperatures, but then I noticed these could be what was 0x557 temperature request message, but data is laid out slightly differently. Using that as a guide, I think the 3rd byte may actually be coolant flow rate LPM through the inverter/motor. Looking through logs it looks like this might be true, with values in the 6-14lpm range.
Today's DBC includes this assumption.
I looked at a few of my own logs plus some others' too verify. But hopefully some of you can also verify and share their opinion.

Separately it looks like @amund7 submitted a new release of CBA with some stuff from @carleeno . Nice.


----------



## Calibr8r

On my way home I set my NAV to a nearby Supercharger. Even though my battery temperature was already 40*C it still activated the 'Preconditioning for Supercharging' message, surprisingly. I watched the 0x5D5 temp values and the 'minimum battery temp' value. As JWardell mentioned, it does look like 0x5D5 is a target temp for the Rear Inverter. It targets 45*C, which is as high as the battery temp reached also. Even though the Preconditioning message shut off when battery temps reached about 43*C, the active heating still stayed active. I cancelled the Supercharger navigation at 1600 seconds in the attached log and the inverter and battery temps began falling immediately.

Definitely seems like the preconditioning targets a max battery heating temp of 45*C using the inverter as its heat source, which will certainly make your supercharging session hit thermal throttling VERY fast, which perplexes me.


----------



## JWardell

Calibr8r said:


> On my way home I set my NAV to a nearby Supercharger. Even though my battery temperature was already 40*C it still activated the 'Preconditioning for Supercharging' message, surprisingly. I watched the 0x5D5 temp values and the 'minimum battery temp' value. As JWardell mentioned, it does look like 0x5D5 is a target temp for the Rear Inverter. It targets 45*C, which is as high as the battery temp reached also. Even though the Preconditioning message shut off when battery temps reached about 43*C, the active heating still stayed active. I cancelled the Supercharger navigation at 1600 seconds in the attached log and the inverter and battery temps began falling immediately.
> 
> Definitely seems like the preconditioning targets a max of 45*C, which will certainly make your supercharging session hit thermal throttling VERY fast, which perplexes me.


Nice. My guess would be that 45 might be the max they are comfortable with running through the inverters and still keeping the drivetrain cool enough to perform. I doubt it will warm the battery as much as the battery heats when charging, but if it gets halfway there it's still going to speed things up. 
Tesla tracks heat in temperatures and dissipation in so many places, I can only imagine what they are doing with it all. They probably still have plenty things they haven't done yet too.


----------



## Calibr8r

JWardell said:


> Nice. My guess would be that 45 might be the max they are comfortable with running through the inverters and still keeping the drivetrain cool enough to perform. I doubt it will warm the battery as much as the battery heats when charging, but if it gets halfway there it's still going to speed things up.
> Tesla tracks heat in temperatures and dissipation in so many places, I can only imagine what they are doing with it all. They probably still have plenty things they haven't done yet too.


From my 150kW supercharger logs, thermal throttling started at around 48°C battery temps and even after the throttling the min battery temp peaked at 54°C and settled at about 52°C on a handful of logged sessions. As the weather cools I'll try to do some supercharger sessions to see the lowest the battery temps can be and still be permitted to accept maximum kw charging rates. My guess is about 25-30°C. Once I find that threshold I can see how much of a charge time improvement arriving at, say, 25°C would give versus the maximum preconditioned 45°C. For science...lol.


----------



## juanmax

Onyx said:


> Well, I've got CAN traffic streaming to the main display. My setup is very rough and needs work before I can drive around, but it's a start (and a proof of concept of sorts.) I just have a log file display incoming traffic at this point. This was surprisingly tedious to get working, but I have to say that the v10 browser is very solid (it's a very recent version of Chrome with some extra Tesla goodies I wish I knew how to tap into).
> 
> Next step will be to build a signal explorer similar to the one Ingineerix showed in his video on the CAN signals. I'm thinking it'll be very nice to be able to drive around and mess with the signals from the main display.
> 
> Here's a quick video of what it looks like:


how exactly have you done that ? If I tried building an WiFi access point in my mobile phone and pointing the tesla browser to my local web server the browser did not want to read the page. Not found. Have you installed a dns on a specific IP?


----------



## Juggernaut

Vision said:


> I have a obdii display device that auto powers on and off in my ice car. Would this be possible if I plug in the same device into the model 3 using the e-mobility cable or the evtv box? I assume the pid's would be off?


Can you send me the wiring schematics?
Than i will check them.


----------



## Juggernaut

JWardell said:


> Good idea, I will add that now, although cables are still hard to come by.
> 
> Let me know when you added to 2018 version and I will update the links


I have the 2018 version on request base. If i would present both in the store the
other M3 users will be confused with it like with facelift and pre-facelift in MS.
All clients ordering from the united states are receiving
automtically a confirmation mail with picture to ensure that the
right cable will be delivered to them.

BR
/mkl


----------



## Onyx

juanmax said:


> how exactly have you done that ? If I tried building an WiFi access point in my mobile phone and pointing the tesla browser to my local web server the browser did not want to read the page. Not found. Have you installed a dns on a specific IP?


I'm using an ngrok tunnel for now and web sockets, and I didn't bother trying to serve it from the phone. I thought about using WebRTC between the phone and main screen, but both are running symmetric NATs (when on cellular), so that won't work. I may eventually try WebRTC with a TURN server if having a UDP data channel turns out to be significantly less latency than the web sockets (but one thing at time lol).

My basic setup looks like this:
Macchina M2 > Serial to Xbee > BLE to Phone > WebSocket to server > WebSocket to Tesla browser

I haven't calculated latency yet. I was just starting to test my signal viewer in the car when my CAN transceiver burnt out, so I'm now stuck waiting for a replacement to come before I can continue. Here's a screenshot of what it looks like:


----------



## JWardell

Onyx said:


> I'm using an ngrok tunnel for now and web sockets, and I didn't bother trying to serve it from the phone. I thought about using WebRTC between the phone and main screen, but both are running symmetric NATs (when on cellular), so that won't work. I may eventually try WebRTC with a TURN server if having a UDP data channel turns out to be significantly less latency than the web sockets (but one thing at time lol).
> 
> My basic setup looks like this:
> Macchina M2 > Serial to Xbee > BLE to Phone > WebSocket to server > WebSocket to Tesla browser
> 
> I haven't calculated latency yet. I was just starting to test my signal viewer in the car when my CAN transceiver burnt out, so I'm now stuck waiting for a replacement to come before I can continue. Here's a screenshot of what it looks like:
> 
> View attachment 29869


I haven't head of that Maccina M2 before, how is it to work with? Is there an easy way to wirelessly connect to it via Arduino? I will have to research some more.
https://www.macchina.cc/m2-introduction


----------



## Onyx

The device works amazingly well, super easy to use and nice compact form factor - but like I said, I burnt it out. (It's quite possibly user error on my side, but you never know.) You can upload M2RET (a port of EVTV's GVRET) and it just works with SavvyCAN. I'm going to be writing my own firmware partly to customize what gets sent through the BLE card but also because I can! 

For wireless, I'm using https://www.dfrobot.com/product-1073.html now, but I've ordered Macchina's SuperB and am going to try that too. The DFRobot plugs-in and just works - mostly, it's not 100% BLE compliant, but since I'm writing my own phone app to interface with it, it's not a big problem. It's tricky to find XBee cards that work with the 3.3v only source though (apparently Macchina is working on a new board that'll support 5v so you'll be able to plug any XBee card in).

This is what it looks like mounted in the car (my camera is actually doing too good of a job with night sight on this shot, in real life, it's really hard to see at all):








(The LED is just for development, it'll be gone in the "final" version.)

What's really cool about this setup is that I can plug with the side mounted usb port to update the firmware, and the sd card that will log _everything_ can be accessed from the side too.


----------



## juanmax

One of my work colleagues also burnt a Macchina M2, so they are not that robust or failure tolerant. Thanks for the reply.

That means that the CAN stuff that your Macchina reads gets sent via Bluetooth to your phone, and from your phone into the internet, then the car connects to a website using LTE/3G right? I wanted a "local" solution based on a Wifi Accesspoint without having to get into internet.


----------



## JWardell

juanmax said:


> One of my work colleagues also burnt a Macchina M2, so they are not that robust or failure tolerant. Thanks for the reply.
> 
> That means that the CAN stuff that your Macchina reads gets sent via Bluetooth to your phone, and from your phone into the internet, then the car connects to a website using LTE/3G right? I wanted a "local" solution based on a Wifi Accesspoint without having to get into internet.


Are these getting "burnt" because they can't handle 15V on the power side, or is it something else? You could very easily add a regulator in front.


----------



## michi84

@Onyx: Your solution looks interesting. Do you know how much data traffic it causes? Can you use a DBC file for interpretating the data, or do you have to modify your source code to do so?

I am looking for a customizable solution, where i can experiment with displaying new CAN IDs. I tried to compile the ScanMyModel3 app with DBC support from Github ( https://github.com/sbirss/ScanMyModel3 ) with Visual Studio 2019, but did not manage to get a working .apk since a am a completed newby to programming. Also, i do not know if this modified version of ScanMyTesla would even work with my OBDLink MX since it was written for an ESP32 board as data source.

The source code of SMT was unfortunately removed from Github, i was planning to edit the packet.cs file to add what i want - not as convenient as just selecting a new DBC, but doable. I have a feeling that i might have a local copy somewhere, but i cannot find it now. I have however found some interesting stuff with the ETH CAN DBC, for example the coolant loop mode (series/parallel), AC compressor inlet and outlet pressure, HVAC data like evap temp, PTC current, chiller demand and so on which i would like to add.

My next step will be to document what appears to be working from the EHT CAN DBC especially from VCFRONT and HVAC (VRIGHT and VCLEFT).

Hardware wise, is it possible to use an OBD port splitter cable to connect both the OBDLink MX (for SMT) and another device like ESP32? Which hardware would currently be recommended to record long CAN dumps, i fpossible with time stamps? SMT and OBDLink MX are too unreliable for me to record CAN dumps longer than about 60-90 seconds.


----------



## Dick Blonov

JWardell said:


> Are these getting "burnt" because they can't handle 15V on the power side, or is it something else? You could very easily add a regulator in front.


From the schematic, looks pretty well protected (on the V-IN side anyway). Whatever happened must have been a case of miswiring the device.









Phil


----------



## Onyx

About the burning out: it's relatively easy to plug-in incorrectly and drive voltage where you shouldn't. I'm hoping that's what I did (although I find it unlikely). The interface board is purpose-built to survive ICE cars starting and whatnot, which causes much larger voltage and current issues than a Telsa would (from what I've read, I'm not at all an expert on this stuff). I'll 100% more careful with my new board, and hopefully it lives.

About the data rate: it's about 600 messages / sec, which means about 81 Kbps, and a little under 900 MB / day if running continuously and assuming all messages are the full 17 bytes (timestamp + id + length + 8 bytes of data). So obviously that won't work over a metered LTE connection. This is why I'm going to be writting my own firmware. I want the web app running in the Tesla browser to be able to signal to the M2 what data it wants "right now" and at what rate. This way, I'll be able to build "apps" that only cause a small amount of data to stream live.

To allow more "bulk logs" (for investigation and whatnot), I'll be dumping everything to the SD card and pulling it when I need to investigate something. I'll implement the same sort of "fill it up and then rotate" scheme the dash cam does, so I'll be able to just leave it in until I need it.

In terms of DBC support, I've written a small script that parses DBCs and spits out a JSON file that is then consummed by my service to allow "apps" to easily browse the data in a structured manner. So it's easy for me to make changes to the DBC (or integrate the community's finds) and re-deploy.

For splitting and using multiple CAN bus readers, I don't see why this would be a problem. It should just work, as that's kinda why CAN exists, i.e. adding new "modules". 

Getting a timestamp is a question I had too though. Is there a signal that carries the car's date/time? It would be very useful to me, and so far all I have is the uptime of my arduino.


----------



## michi84

Found some changes in the VCFRONT logging IDs (BO 705 and BO 897) between old and new firmware: The multiplex in 705 (10hz logging) went up to 5 in the old firmware (used an old CAN dump from the forum), and now only goes to 4 - that means that some values are now missing. However, the multiplex on 897 (1hz logging) now goes up to 6 instead of just 3. I suspect that some of the logging data might have been moved from 10hz to 1hz refresh rate. I will try adding the missing values at different multiplex selectors on 1hz, to see if the values make sense.

What i also see is that my OBDlink MX is not fast enough to capture all data, i have to use Jwardells recordings since mine see to miss out some data on those fast mulitplexed CAN IDs.

@Onyx You could try 0x318 (system time) or 0x528 (unix time) as per the Model 3 CAN spreadsheet for a timestamp. I have not yet tried these IDs since they are not in the DBC.


----------



## Onyx

michi84 said:


> @Onyx You could try 0x318 (system time) or 0x528 (unix time) as per the Model 3 CAN spreadsheet for a timestamp. I have not yet tried these IDs since they are not in the DBC.


Thanks, 0x318 worked. Might be worth adding that this is UTC. Also, the last 2 bytes danced around for me, but don't look like milliseconds as I first thought they must be: I got values of 1970, 4033, 956, 6616, 1991, and 6053 in this one log.


----------



## JWardell

Dick Blonov said:


> From the schematic, looks pretty well protected (on the V-IN side anyway). Whatever happened must have been a case of miswiring the device.
> View attachment 29880
> 
> 
> Phil


Well that is certainly a nice robust power circuit so I don't think that's what the problem is. I'm happy to try to troubleshoot (can you see any physically burned components?)



Onyx said:


> About the burning out: it's relatively easy to plug-in incorrectly and drive voltage where you shouldn't. I'm hoping that's what I did (although I find it unlikely). The interface board is purpose-built to survive ICE cars starting and whatnot, which causes much larger voltage and current issues than a Telsa would (from what I've read, I'm not at all an expert on this stuff). I'll 100% more careful with my new board, and hopefully it lives.
> 
> About the data rate: it's about 600 messages / sec, which means about 81 Kbps, and a little under 900 MB / day if running continuously and assuming all messages are the full 17 bytes (timestamp + id + length + 8 bytes of data). So obviously that won't work over a metered LTE connection. This is why I'm going to be writting my own firmware. I want the web app running in the Tesla browser to be able to signal to the M2 what data it wants "right now" and at what rate. This way, I'll be able to build "apps" that only cause a small amount of data to stream live.
> 
> To allow more "bulk logs" (for investigation and whatnot), I'll be dumping everything to the SD card and pulling it when I need to investigate something. I'll implement the same sort of "fill it up and then rotate" scheme the dash cam does, so I'll be able to just leave it in until I need it.
> 
> In terms of DBC support, I've written a small script that parses DBCs and spits out a JSON file that is then consummed by my service to allow "apps" to easily browse the data in a structured manner. So it's easy for me to make changes to the DBC (or integrate the community's finds) and re-deploy.
> 
> For splitting and using multiple CAN bus readers, I don't see why this would be a problem. It should just work, as that's kinda why CAN exists, i.e. adding new "modules".
> 
> Getting a timestamp is a question I had too though. Is there a signal that carries the car's date/time? It would be very useful to me, and so far all I have is the uptime of my arduino.


I looked more into the board, it certainly is a nice purpose made board, and I see it can be programmed with Arduino too. I might suggest programming either a circular buffer in the CAN dump to SD card, or better yet filtering messages to only log one from each ID every 250ms etc which would also save a ton of space. Or better yet, picking which data you want to save and the resolution...



michi84 said:


> Found some changes in the VCFRONT logging IDs (BO 705 and BO 897) between old and new firmware: The multiplex in 705 (10hz logging) went up to 5 in the old firmware (used an old CAN dump from the forum), and now only goes to 4 - that means that some values are now missing. However, the multiplex on 897 (1hz logging) now goes up to 6 instead of just 3. I suspect that some of the logging data might have been moved from 10hz to 1hz refresh rate. I will try adding the missing values at different multiplex selectors on 1hz, to see if the values make sense.
> 
> What i also see is that my OBDlink MX is not fast enough to capture all data, i have to use Jwardells recordings since mine see to miss out some data on those fast mulitplexed CAN IDs.
> 
> @Onyx You could try 0x318 (system time) or 0x528 (unix time) as per the Model 3 CAN spreadsheet for a timestamp. I have not yet tried these IDs since they are not in the DBC.


I have a look at those VCfront changes. It certainly makes sense. I guess we would have to look at old data on the old ID, and see if the new data on the new ID matches.
I don't have that stuff in the DBC because multiplex IDs are a giant pain to manually add in there. Although I can do more with a text editor these days than the kludgy DBC editor.
I never bothered with the time and date IDs, but perhaps I will add them. DBC only supports a few data types so things like ASCII can't be specified, but I think these are just straight integers.


----------



## Onyx

JWardell said:


> I never bothered with the time and date IDs, but perhaps I will add them. DBC only supports a few data types so things like ASCII can't be specified, but I think these are just straight integers.


Yeah, they are numbers. This worked for me:



Code:


BO_ 792 UTC_systemTime: 8 ETH
 SG_ UTC_year: 0|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_month: 8|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_seconds: 16|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_hour: 24|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_day: 32|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_minutes: 40|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_unknown1: 48|[email protected]+ (1,0) [0|0] "" X
 SG_ UTC_unknown2: 56|[email protected]+ (1,0) [0|0] "" X


----------



## fast_like_electric

Onyx said:


> Thanks, 0x318 worked. Might be worth adding that this is UTC. Also, the last 2 bytes danced around for me, but don't look like milliseconds as I first thought they must be: I got values of 1970, 4033, 956, 6616, 1991, and 6053 in this one log.


The last two bytes are not unknown - they are related to anti-replay and anti-substitution. Byte 7 has a 3 bit counter in this case, and byte 8 is the checksum. You see that sort of thing on all critical messages. The technique is mentioned here before. Time message format as well - which were some of the first decoded. But with 1000+ posts now, probably hard to navigate for answers.


----------



## juanmax

JWardell said:


> Are these getting "burnt" because they can't handle 15V on the power side, or is it something else? You could very easily add a regulator in front.


Wrong wire connection


----------



## JWardell

I've now added the time messages to the DBC (I'll upload it later). Not sure why I never bothered before, I think I didn't want to figure out encoding the unix time data, and now I see why...

0x528 Unix Time seems to break both SavvyCAN and CanBusAnalyzer who dont seem to like 32-bit or motorola ordered numbers.

SavvyCAN @Collin80 just looses some bits of resolution so you don't see the data or the graph with the bottom seconds increasing as they really do. When I split the message into two 16-bits it did work properly.

CBA @amund7 refuses to even decode the message with the 32-bit motorola. When split into two 16s it decodes the first word but the second doesn't show up. This may have something to do with startbit:

Adding to the confusion is the way Motorola-ordered signals are represented in the DBC; the start bit is where the MSB lies, yet it is represented differently even in Vector's DBC editor. As you can see here in the editor it indicates start bit 8, yet in the file it saves as startbit 7:










BO_ 1320 ID528UnixTime: 4 VehicleBus
SG_ UnixTimeTest528 : 7|[email protected]+ (1,0) [0|65535] "sec" Receiver
SG_ UnixTimeSeconds528 : 23|[email protected]+ (1,0) [0|65535] "sec" Receiver

The DBC is back to a proper 32-bit but be aware it won't be decoded correctly by these tools.

This is actually a very useful signal because it gives you a time reference for any graphs, especially since both of these tools graph over message count, not over time (Still begging for that!)



Onyx said:


> Yeah, they are numbers. This worked for me:
> 
> 
> 
> Code:
> 
> 
> BO_ 792 UTC_systemTime: 8 ETH
> SG_ UTC_year: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_month: 8|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_seconds: 16|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_hour: 24|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_day: 32|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_minutes: 40|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_unknown1: 48|[email protected]+ (1,0) [0|0] "" X
> SG_ UTC_unknown2: 56|[email protected]+ (1,0) [0|0] "" X


----------



## amund7

Ionity charger (350 kw claimed peak) - peaks at 190 kw on the 3:



















Notice how much fun battery inlet and powertrain inlet are having  (This is parallell/serial switching, plus a bit of A/C compressor cooling down one of them for active cooling of the battery)
This graph does not show that both drive units were heating the coolant like crazy in the beginning, then went offline, so I got a big ugly line through the whole plot.


----------



## LakeWorthB

Any place to buy the e-mobility adapter in the US, or is shipping from Germany the best way? I have a 6/2019 TM3.


----------



## amund7

michi84 said:


> I think i just found the battery target temperature in 0x212: starting bit 48, lenght 8 bit, no scaling and no offset. In Jwardells recent capture, during charging it is 54°C, during plugging in 46°C, and during driving 30°C. Does anyone have a supercharging CAN dump?


Try this format for that message (from the Brianman DBC):

BO_ 786 BMS_thermalStatus: 8 ETH
SG_ BMS_flowRequest: 10|[email protected]+ (0.3,0) [0|0] "LPM" X
SG_ BMS_inletActiveCoolTargetT: 17|[email protected]+ (0.25,10) [0|0] "DegC" X
SG_ BMS_inletActiveHeatTargetT: 33|[email protected]+ (0.25,-25) [0|0] "DegC" X
SG_ BMS_inletPassiveTargetT: 25|[email protected]+ (0.25,0) [0|0] "DegC" X
SG_ BMS_noFlowRequest: 63|[email protected]+ (1,0) [0|0] "" X
SG_ BMS_pcsNoFlowRequest: 62|[email protected]+ (1,0) [0|0] "" X
SG_ BMS_powerDissipation: 0|[email protected]+ (0.02,0) [0|0] "kW" X


----------



## michi84

amund7 said:


> ry this format for that message (from the Brianman DBC):
> 
> BO_ 786 BMS_thermalStatus: 8 ETH
> SG_ BMS_flowRequest: 10|[email protected]+ (0.3,0) [0|0] "LPM" X
> SG_ BMS_inletActiveCoolTargetT: 17|[email protected]+ (0.25,10) [0|0] "DegC" X
> SG_ BMS_inletActiveHeatTargetT: 33|[email protected]+ (0.25,-25) [0|0] "DegC" X
> SG_ BMS_inletPassiveTargetT: 25|[email protected]+ (0.25,0) [0|0] "DegC" X
> SG_ BMS_noFlowRequest: 63|[email protected]+ (1,0) [0|0] "" X
> SG_ BMS_pcsNoFlowRequest: 62|[email protected]+ (1,0) [0|0] "" X
> SG_ BMS_powerDissipation: 0|[email protected]+ (0.02,0) [0|0] "kW" X


Thanks, that works fine. Regarding your Ionity charging, i can confirm that 190 kW ist possible. I thit 191 kW at 40% SOC, after that is started reducing to 144 kW at 50%, then further similar to a supercharger. I could not log temperatures back then. I also got active heating at a 150 kW supercharger once, 3,5 kw on each inverter (total 7). Have to dig out that log.

@amund7: Will you add coolant loop status (parallel/series) to SMT? The message from Brianmans DBC works for decoding that, also the position of the 5-way-valve. Rad bypass does not change, i guess the signal moved, but i have as of now identified three different angles of the valve: around 130 degress is series, around 5 degrees is parallel, and during supercharging i got 45 degrees (mixing perhaps?).

BO_ 705 VCFRONT_logging10Hz: 8 ETH
SG_ VCFRONT_logging10HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_fiveWayValveMode m2: 3|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_fiveWayValveAngleActual m2: 6|[email protected]+ (0.25,-70) [0|0] "degrees" X
SG_ VCFRONT_fiveWayValveAngleTarget m2: 16|[email protected]+ (0.25,-10) [0|0] "degrees" X

VAL_ 705 VCFRONT_fiveWayValveMode 0 "SERIES" 1 "PARALLEL";

Chiller demand (on/off) can be taken from

BO_ 737 VCFRONT_status: 8 ETH
SG_ VCFRONT_statusIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_chillerDemandActive m3: 26|[email protected]+ (1,0) [0|0] "" X

1 is on, 0 is off, corresponds well to dropping battery inlet temps in my logs.


----------



## JWardell

amund7 said:


> Ionity charger (350 kw claimed peak) - peaks at 190 kw on the 3:
> 
> View attachment 29922
> 
> 
> View attachment 29923
> 
> 
> Notice how much fun battery inlet and powertrain inlet are having  (This is parallell/serial switching, plus a bit of A/C compressor cooling down one of them for active cooling of the battery)
> This graph does not show that both drive units were heating the coolant like crazy in the beginning, then went offline, so I got a big ugly line through the whole plot.


This is awesome. Very jealous that you not only have such high power chargers, but 3rd party HVDC chargers that work with Teslas commonplace over there.


----------



## amund7

JWardell said:


> This is awesome. Very jealous that you not only have such high power chargers, but 3rd party HVDC chargers that work with Teslas commonplace over there.


Ionity is really the only 3rd party that's fast, very few of them, I counted 8 charging sites throughout Norway now. But I'm sure they will start popping up more, now that the German EV's are starting to become visible on the roads.

Still, they (anyone but Tesla) always manage to make super clumsy systems. I spent at least 10 minutes getting the app, credit card, bank approvals, name, email, and charger to work. Then it didn't start, so I tried all of it again. So they charged my card twice.


----------



## amund7

michi84 said:


> Thanks, that works fine. Regarding your Ionity charging, i can confirm that 190 kW ist possible. I thit 191 kW at 40% SOC, after that is started reducing to 144 kW at 50%, then further similar to a supercharger. I could not log temperatures back then. I also got active heating at a 150 kW supercharger once, 3,5 kw on each inverter (total 7). Have to dig out that log.
> 
> @amund7: Will you add coolant loop status (parallel/series) to SMT? The message from Brianmans DBC works for decoding that, also the position of the 5-way-valve. Rad bypass does not change, i guess the signal moved, but i have as of now identified three different angles of the valve: around 130 degress is series, around 5 degrees is parallel, and during supercharging i got 45 degrees (mixing perhaps?).
> 
> BO_ 705 VCFRONT_logging10Hz: 8 ETH
> SG_ VCFRONT_logging10HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_fiveWayValveMode m2: 3|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_fiveWayValveAngleActual m2: 6|[email protected]+ (0.25,-70) [0|0] "degrees" X
> SG_ VCFRONT_fiveWayValveAngleTarget m2: 16|[email protected]+ (0.25,-10) [0|0] "degrees" X
> 
> VAL_ 705 VCFRONT_fiveWayValveMode 0 "SERIES" 1 "PARALLEL";
> 
> Chiller demand (on/off) can be taken from
> 
> BO_ 737 VCFRONT_status: 8 ETH
> SG_ VCFRONT_statusIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_chillerDemandActive m3: 26|[email protected]+ (1,0) [0|0] "" X
> 
> 1 is on, 0 is off, corresponds well to dropping battery inlet temps in my logs.


I have studied these before, trying to make sense of it, and concluded they completely changed the signal definitions for it early 2019 or late '18. Some of JWardells early logs it worked, but with my cars they gave crap. The current version of Canbus Analyzer contains some test messages for these, trying to find the radiator fan speed among other things, but the fiveWayValve stuff made zero sense. Will revisit with V10 logs.


----------



## Calibr8r

amund7 said:


> ...trying to find the radiator fan speed among other things, but the fiveWayValve stuff made zero sense. Will revisit with V10 logs.


I'd love to have the radiator fan speed and the front radiator shutter activation if anyone comes across those ❤


----------



## juanmax

Calibr8r said:


> I'd love to have the radiator fan speed and the front radiator shutter activation if anyone comes across those ❤


The radiator fan speed (target) on v9 looks right. This is from a 200kW DC Charge session


----------



## Calibr8r

juanmax said:


> The radiator fan speed (target) on v9 looks right. This is from a 200kW DC Charge session


Hmm, do you have the address and details for those fan related variables?


----------



## jsquared

Is it possible to issue canbus commands?


----------



## JWardell

I updated the DBC with messages to help @michi84 0x312 BMS thermals (I thought you were only looking at 212 earlier...) as well as what we can verify from VCFront 0x2C1 0x2E1 and 0x381


----------



## Vision

Guys, I have a 2019. Got the 'can' to obdii cable from fleetcarma. Came with the correct 26pin cable. There dongle works fine with the cable.

However when I connected my obd link mx+ bluetooth adapter the phone will connect to the adapter, but it tries all the different protocols in torque lite and says it can't connect to the ecu?. Any suggestions?


----------



## michi84

Torque Pro/Lite will not work with Teslas, except with the EVTV OBD Box which simulates an ELM 327 interface to query data by PIDs, which is what the Torque app does.

Teslas will not respond to those querys. You need an app like ScanMyTesla which passively sniffs the data from the CAN bus and interprets them.


----------



## Vision

michi84, thanks for the reply. I will buy it and see if that can display data for me.


----------



## JWardell

jsquared said:


> Is it possible to issue canbus commands?


If you want to roll the dice, and discover how the car handles imposter messages. I suppose we need to find out eventually...
Many of the messages have checksums and counters in them, so anything you transmit will not match the sequence and should be detected. Will it be ignored? Will the car error or phone home because the impostor message was detected? Not sure.

If you're asking from a more fundamental level, then yes, every can transceiver can also transmit data to the network. It's all broadcast so no way to know what device a message originates from.

But the reality is if you wanted to modify or issue new commands, you would have to cut out the device and put a man-in-the-middle device to receive the counted checksummed messages, modify their data, then re-transmit them.


----------



## Onyx

LakeWorthB said:


> Any place to buy the e-mobility adapter in the US, or is shipping from Germany the best way? I have a 6/2019 TM3.


For what it's worth, I have a 6/2019 TM3 too, and I ordered from e-mobility in Germany. They shipped quickly, and was cheaper to ship to Canada than most thing I have to source from the US - go figure (20 euros vs. 35 usd). The cable worked fine (even after my "modifications"), and seems well put together, so I'd recommend them easily.


----------



## Onyx

Alright, so, I got my new board from Macchina, and have been working on my firmware and mobile relay, and I now have a version of my "over the air can bus signal viewer" that works well enough to drive with.

I'm really, really, happy how this has turned out. It's super fast (no perceptible latency), uses very little cellular data, and is pretty stable. I'm really excited about building little "car apps" that use this thing to do useful and fun things.

I made a little video showing it in action.


----------



## michi84

Wow, that looks great! Do you plan to release your project on Github? I am really thinking about ordering an M2 Macchina. Would your project also work with a Raspberry Pi? I have one of these lying around, and i was thinking to add a PiCAN 2 and use it at least for recording CAN dumps. If this could be made to work with your code, that would be great.

@JWardell: I compared your first CAN dump with one of mine for VCFRONT Data. Some bytes which formerly contained data are now blank, others are now populated. The battery pump rpm for example works perfectly, powetrain which would be immediately after it not, there are values, but they do not make sense. There is something there, but it must be something else. Radiator fan RPM target appears to work, actual rpm not.

Does anyone know if registering for Tesla service access for one hour would give you the access code for the service menu? Then at least it would be possible to see the decoded values, and we could try to find them somewhere in the binary data. Or perhaps confirm if they moved form 10 to 1hz.

Also, how exactly do i read the binary values in Canbus Analyzer? The starting bits seem to be counted from right to left, in reverse from normal reading flow.

On the bright side, i can confirm reasonably sure that A/C refrigerant suction and discharge pressure are working fine: 0x2E1, 
SG_ VCFRONT_pressureRefrigSuction m3: 32|[email protected]+ (0.125,0) [0|0] "bar" X
SG_ VCFRONT_pressureRefrigDischarge m3: 40|[email protected]+ (0.125,0) [0|0] "bar" X

Also, on VCLEFT 0x282 we can see cabin blower rpm (actual and target), duty cycle an current:

BO_ 642 VCLEFT_hvacBlowerFeedback: 8 ETH
SG_ VCLEFT_blowerIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCLEFT_hvacBlowerEnabled m0: 2|[email protected]+ (1,0) [0|0] "" X
SG_ VCLEFT_hvacBlowerOutputDuty m0: 3|[email protected]+ (1,0) [0|0] "%" X
SG_ VCLEFT_hvacBlowerRPMTarget m0: 10|[email protected]+ (10,0) [0|0] "rpm" X
SG_ VCLEFT_hvacBlowerRPMActual m0: 20|[email protected]+ (10,0) [0|0] "rpm" X
SG_ VCLEFT_hvacBlowerIPhase0 m1: 10|[email protected]+ (0.2,0) [0|0] "A" X
SG_ VCLEFT_hvacBlowerIPhase1 m1: 18|[email protected]+ (0.2,0) [0|0] "A" X
SG_ VCLEFT_hvacBlowerIPhase2 m1: 26|[email protected]+ (0.2,0) [0|0] "A" X

With the blower at 2990 rpm (duty cycle 37%), i get roughly 16 amps on all three phases.

Moving to VCRIGHT 0x20C, we can see wether the HVAC evaporator is active, the evap target and actual temp, and the evap power demand in watts.

BO_ 524 VCRIGHT_hvacRequest: 6 ETH
SG_ VCRIGHT_conditioningRequest: 12|[email protected]+ (1,0) [0|0] "" X
SG_ VCRIGHT_demandEvapSkipRateLimit: 42|[email protected]+ (1,0) [0|0] "" X
SG_ VCRIGHT_evapPerformanceLow: 43|[email protected]+ (1,0) [0|0] "" X
SG_ VCRIGHT_hvacBlowerSpeedRPMReq: 32|[email protected]+ (5,0) [0|0] "RPM" X
SG_ VCRIGHT_hvacEvapEnabled: 11|[email protected]+ (1,0) [0|0] "" X
SG_ VCRIGHT_tempEvaporator: 13|[email protected]+ (0.1,-40) [0|0] "degC" X
SG_ VCRIGHT_tempEvaporatorTarget: 24|[email protected]+ (0.2,0) [0|0] "degC" X
SG_ VCRIGHT_wattsDemandEvap: 0|[email protected]+ (5,0) [0|0] "W" X

These all make sense, blower speed request matches data from VCLEFT, watts demand from evap seems to be actual cooling power, not electrical power draw from the compressor, since it is way higher than the total power draw of the car at the moment (about 1 kW total, evap request is 2635 watts (2,64 kW)).

On VCRIGHT logging 1hz 0x2B3, we get duct target and actual temp, evap load in recirc and fresh air intake (could be useful to decide which mode to use from an energy consumption standpoint), an PTC heater watts demand and actual. There is a lot more (see ETH DBC), but these are the ones i can confirm to make sense and which would be desireable to have displayed.

BO_ 691 VCRIGHT_logging1Hz: 8 ETH
SG_ VCRIGHT_logging1HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCRIGHT_tempDuctLeft m0: 4|[email protected]+ (0.3,-40) [0|0] "degC" X
SG_ VCRIGHT_tempDuctRight m0: 13|[email protected]+ (0.3,-40) [0|0] "degC" X
SG_ VCRIGHT_wattsHeaterLeftTotal m2: 28|[email protected]+ (5,0) [0|0] "W" X
SG_ VCRIGHT_wattsHeaterRightTotal m2: 38|[email protected]+ (5,0) [0|0] "W" X
SG_ VCRIGHT_ptcHeaterPwrDemandLeft m2: 48|[email protected]+ (20,0) [0|0] "W" X
SG_ VCRIGHT_ptcHeaterPwrDemandRight m2: 56|[email protected]+ (20,0) [0|0] "W" X
SG_ VCRIGHT_hvacDuctTargetLeft m5: 13|[email protected]+ (0.5,-40) [0|0] "degC" X
SG_ VCRIGHT_hvacDuctTargetRight m5: 21|[email protected]+ (0.5,-40) [0|0] "degC" X
SG_ VCRIGHT_evapLoadInFresh m5: 45|[email protected]+ (35,0) [0|0] "W" X
SG_ VCRIGHT_evapLoadInRecirc m5: 53|[email protected]+ (35,0) [0|0] "W" X


----------



## michi84

Here is a CAN dump i recorded today: I started the AC on full cold from outside with the app to observe the louvers - they did open when the AC ramped up, and closed after i shut it down. The second dump ist while driving, here the heating is on.


----------



## JWardell

Bjorn has finally discovered ScanMyTesla and how the data makes analyzing what's going on in your battery much easier.
@amund7 I assume you are seeing a spike in app purchases  and already some pressure to add more


----------



## Onyx

michi84 said:


> Wow, that looks great! Do you plan to release your project on Github? I am really thinking about ordering an M2 Macchina. Would your project also work with a Raspberry Pi? I have one of these lying around, and i was thinking to add a PiCAN 2 and use it at least for recording CAN dumps. If this could be made to work with your code, that would be great.


Thanks! I'll definitely post to GitHub once I get the various parts cleaned up a bit. This could work with a RPi I imagine, but most of the code running on the M2 would have to be rewritten, and possibly parts of the Bluetooth handling code running on the phone.


----------



## JWardell

michi84 said:


> Wow, that looks great! Do you plan to release your project on Github? I am really thinking about ordering an M2 Macchina. Would your project also work with a Raspberry Pi? I have one of these lying around, and i was thinking to add a PiCAN 2 and use it at least for recording CAN dumps. If this could be made to work with your code, that would be great.
> 
> @JWardell: I compared your first CAN dump with one of mine for VCFRONT Data. Some bytes which formerly contained data are now blank, others are now populated. The battery pump rpm for example works perfectly, powetrain which would be immediately after it not, there are values, but they do not make sense. There is something there, but it must be something else. Radiator fan RPM target appears to work, actual rpm not.
> 
> Does anyone know if registering for Tesla service access for one hour would give you the access code for the service menu? Then at least it would be possible to see the decoded values, and we could try to find them somewhere in the binary data. Or perhaps confirm if they moved form 10 to 1hz.
> 
> Also, how exactly do i read the binary values in Canbus Analyzer? The starting bits seem to be counted from right to left, in reverse from normal reading flow.
> 
> On the bright side, i can confirm reasonably sure that A/C refrigerant suction and discharge pressure are working fine: 0x2E1,
> SG_ VCFRONT_pressureRefrigSuction m3: 32|[email protected]+ (0.125,0) [0|0] "bar" X
> SG_ VCFRONT_pressureRefrigDischarge m3: 40|[email protected]+ (0.125,0) [0|0] "bar" X
> 
> Also, on VCLEFT 0x282 we can see cabin blower rpm (actual and target), duty cycle an current:
> 
> BO_ 642 VCLEFT_hvacBlowerFeedback: 8 ETH
> SG_ VCLEFT_blowerIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCLEFT_hvacBlowerEnabled m0: 2|[email protected]+ (1,0) [0|0] "" X
> SG_ VCLEFT_hvacBlowerOutputDuty m0: 3|[email protected]+ (1,0) [0|0] "%" X
> SG_ VCLEFT_hvacBlowerRPMTarget m0: 10|[email protected]+ (10,0) [0|0] "rpm" X
> SG_ VCLEFT_hvacBlowerRPMActual m0: 20|[email protected]+ (10,0) [0|0] "rpm" X
> SG_ VCLEFT_hvacBlowerIPhase0 m1: 10|[email protected]+ (0.2,0) [0|0] "A" X
> SG_ VCLEFT_hvacBlowerIPhase1 m1: 18|[email protected]+ (0.2,0) [0|0] "A" X
> SG_ VCLEFT_hvacBlowerIPhase2 m1: 26|[email protected]+ (0.2,0) [0|0] "A" X
> 
> With the blower at 2990 rpm (duty cycle 37%), i get roughly 16 amps on all three phases.
> 
> Moving to VCRIGHT 0x20C, we can see wether the HVAC evaporator is active, the evap target and actual temp, and the evap power demand in watts.
> 
> BO_ 524 VCRIGHT_hvacRequest: 6 ETH
> SG_ VCRIGHT_conditioningRequest: 12|[email protected]+ (1,0) [0|0] "" X
> SG_ VCRIGHT_demandEvapSkipRateLimit: 42|[email protected]+ (1,0) [0|0] "" X
> SG_ VCRIGHT_evapPerformanceLow: 43|[email protected]+ (1,0) [0|0] "" X
> SG_ VCRIGHT_hvacBlowerSpeedRPMReq: 32|[email protected]+ (5,0) [0|0] "RPM" X
> SG_ VCRIGHT_hvacEvapEnabled: 11|[email protected]+ (1,0) [0|0] "" X
> SG_ VCRIGHT_tempEvaporator: 13|[email protected]+ (0.1,-40) [0|0] "degC" X
> SG_ VCRIGHT_tempEvaporatorTarget: 24|[email protected]+ (0.2,0) [0|0] "degC" X
> SG_ VCRIGHT_wattsDemandEvap: 0|[email protected]+ (5,0) [0|0] "W" X
> 
> These all make sense, blower speed request matches data from VCLEFT, watts demand from evap seems to be actual cooling power, not electrical power draw from the compressor, since it is way higher than the total power draw of the car at the moment (about 1 kW total, evap request is 2635 watts (2,64 kW)).
> 
> On VCRIGHT logging 1hz 0x2B3, we get duct target and actual temp, evap load in recirc and fresh air intake (could be useful to decide which mode to use from an energy consumption standpoint), an PTC heater watts demand and actual. There is a lot more (see ETH DBC), but these are the ones i can confirm to make sense and which would be desireable to have displayed.
> 
> BO_ 691 VCRIGHT_logging1Hz: 8 ETH
> SG_ VCRIGHT_logging1HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCRIGHT_tempDuctLeft m0: 4|[email protected]+ (0.3,-40) [0|0] "degC" X
> SG_ VCRIGHT_tempDuctRight m0: 13|[email protected]+ (0.3,-40) [0|0] "degC" X
> SG_ VCRIGHT_wattsHeaterLeftTotal m2: 28|[email protected]+ (5,0) [0|0] "W" X
> SG_ VCRIGHT_wattsHeaterRightTotal m2: 38|[email protected]+ (5,0) [0|0] "W" X
> SG_ VCRIGHT_ptcHeaterPwrDemandLeft m2: 48|[email protected]+ (20,0) [0|0] "W" X
> SG_ VCRIGHT_ptcHeaterPwrDemandRight m2: 56|[email protected]+ (20,0) [0|0] "W" X
> SG_ VCRIGHT_hvacDuctTargetLeft m5: 13|[email protected]+ (0.5,-40) [0|0] "degC" X
> SG_ VCRIGHT_hvacDuctTargetRight m5: 21|[email protected]+ (0.5,-40) [0|0] "degC" X
> SG_ VCRIGHT_evapLoadInFresh m5: 45|[email protected]+ (35,0) [0|0] "W" X
> SG_ VCRIGHT_evapLoadInRecirc m5: 53|[email protected]+ (35,0) [0|0] "W" X


I think Tesla Service access only gets you access the parts database and drawings. It is helpful for wiring harnesses and finding where to tap. The only one I know who knows how to get into the service mode is @Ingineer who demonstrated it in his videos.

I suggest SavvyCAN for looking at random data. You can see the data from each can message in the log view, but what is nicest is the Flow view, where you can play back and watch bits change. I keep saying I will do a video soon showing how I do this now (very different than when I started back in December!)
You can do it in CBA, in that you can click decode as bytes and as words, then check the message box. Blindly, as the UI doesn't show anything happening, but next time you load the log it with graph bytes in that message. @amund7 never fixed that... Problem is that Tesla only rarely confirms data to even bytes. So then you have to add it to a DBC file, then reload. Savvy CAN a bit better for figuring out unknown stuff. CBA better for graphing known data.


----------



## TaccoBill

michi84 said:


> Torque Pro/Lite will not work with Teslas, except with the EVTV OBD Box which simulates an ELM 327 interface to query data by PIDs, which is what the Torque app does.
> 
> Teslas will not respond to those querys. You need an app like ScanMyTesla which passively sniffs the data from the CAN bus and interprets them.


I'm new to accessing data from my Model 3, but I've used the Torque app in previous cars. So I purchased the EVTV device. However the Torque PID file supplied by EVTV does not seem to include many of the parameters listed in the DBC. Is there a way to create custom PIDs for Torque from the DBC, or to translate the DBC parameters to Torque PIDs. Thanks.


----------



## JWardell

TaccoBill said:


> I'm new to accessing data from my Model 3, but I've used the Torque app in previous cars. So I purchased the EVTV device. However the Torque PID file supplied by EVTV does not seem to include many of the parameters listed in the DBC. Is there a way to create custom PIDs for Torque from the DBC, or to translate the DBC parameters to Torque PIDs. Thanks.


I'll tag @Collin80 since he would probably best be able to answer that for you.
I'm curious myself since I do like their super custom gauge interface.


----------



## Calibr8r

A friend and I tinkered with just emulating the the generic OBD2 PIDs with a generic OBD2 logger I had access to. I wasn't able to edit the naming on the device so I just tossed a few variables through it that were similar. A lot more work than it was worth lol


----------



## amund7

JWardell said:


> ...click decode as bytes and as words, then check the message box. Blindly, as the UI doesn't show anything happening, but next time you load the log it with graph bytes in that message. @amund7 never fixed that...


It is a stupid bug yes, but you just need to click another packet ID, then back, and they will show up. You don't have to reload the log.


----------



## CoolSilver

I've been lurking since I got my car last year. Good to see Juggernaut has some older cables that can be built and shipped. Yea I don't know why I waited so long but admit Bjorn reminded me.
The Macchina M2 looks to be a neat thing to have as well


----------



## dburkland

Just like @CoolSilver I've been lurking for a while however finally got the push I needed thanks to Bjorn's recent ScanMyTesla videos . With that said, my wife has an old iPhone 6 that she is no longer using that I want to leverage so I can display some key metrics like battery voltage, battery temp, various inlet temps, cell voltage, etc. Does ODB fusion know what the various metrics are out of the box or will I need to point it at the DBC file posted on page 1? Or would it just be easier to find a cheap Android phone and use ScanMyTesla?

Regardless if i go with an Android-based device or an iPhone, from a hardware perspective will I be safe going with the following?

1) OBDLink MX+
2) Geotab HRN-CT20T1 (I have a 2018 Model 3 Performance)

Thanks!

Dan


----------



## LakeWorthB

Onyx said:


> For what it's worth, I have a 6/2019 TM3 too, and I ordered from e-mobility in Germany. They shipped quickly, and was cheaper to ship to Canada than most thing I have to source from the US - go figure (20 euros vs. 35 usd). The cable worked fine (even after my "modifications"), and seems well put together, so I'd recommend them easily.


Thanks, so I just placed an order. Can't wait.


----------



## carleeno

dburkland said:


> Just like @CoolSilver I've been lurking for a while however finally got the push I needed thanks to Bjorn's recent ScanMyTesla videos . With that said, my wife has an old iPhone 6 that she is no longer using that I want to leverage so I can display some key metrics like battery voltage, battery temp, various inlet temps, cell voltage, etc. Does ODB fusion know what the various metrics are out of the box or will I need to point it at the DBC file posted on page 1? Or would it just be easier to find a cheap Android phone and use ScanMyTesla?
> 
> Regardless if i go with an Android-based device or an iPhone, from a hardware perspective will I be safe going with the following?
> 
> 1) OBDLink MX+
> 2) Geotab HRN-CT20T1 (I have a 2018 Model 3 Performance)
> 
> Thanks!
> 
> Dan


Yep that geotab harness is the one you want, and you can use even the OBDLink LX, I don't think you'll need any of the features that come with the MX(+).
I currently use the LX with Scan My Tesla on android.

Unfortunately I can't help you with OBD Fusion on iphone.


----------



## dburkland

carleeno said:


> Yep that geotab harness is the one you want, and you can use even the OBDLink LX, I don't think you'll need any of the features that come with the MX(+).
> I currently use the LX with Scan My Tesla on android.
> 
> Unfortunately I can't help you with OBD Fusion on iphone.


Thanks! I have not seen much mention of folks on here using OBD fusion so I'll be curious to see how much tinkering will be required.


----------



## JWardell

dburkland said:


> Just like @CoolSilver I've been lurking for a while however finally got the push I needed thanks to Bjorn's recent ScanMyTesla videos . With that said, my wife has an old iPhone 6 that she is no longer using that I want to leverage so I can display some key metrics like battery voltage, battery temp, various inlet temps, cell voltage, etc. Does ODB fusion know what the various metrics are out of the box or will I need to point it at the DBC file posted on page 1? Or would it just be easier to find a cheap Android phone and use ScanMyTesla?
> 
> Regardless if i go with an Android-based device or an iPhone, from a hardware perspective will I be safe going with the following?
> 
> 1) OBDLink MX+
> 2) Geotab HRN-CT20T1 (I have a 2018 Model 3 Performance)
> 
> Thanks!
> 
> Dan


Only Wifi ODB readers will work with iPhones, and then I doubt any apps supporting them will work with Tesla's custom CAN commands. Let me know if you find one that does.
This is why I have a cheap android device, so I have no problem using only for gauges and leaving it behind in the car...


----------



## Vision

If anyone needs a 2018 cable I have a extra, pm for price. Works great with scan my tesla to display all the data.


----------



## Onyx

So I've been lost in all this new found data, it's amazing! Is there a place (thread) to go to nerd out about what the data means and post observations? Or just post here? I don't want to pollute this thread...

Oh, and I've implemented multiplexed signals (I can't believe I glossed over that originally). And night mode! I can use *UI_isSunUp* to determine the theme if the display setting is on "auto", but I haven't found a signal that tells me the user's setting per se. Anyone know?


----------



## JWardell

Well now Björn has let all the cats out of the bag. I bet harness adapters will be out of stock instantly.
I still could use anyone's help coding the ESP32 to be host to the OBDlink, so I can make HUD modules.








Onyx said:


> So I've been lost in all this new found data, it's amazing! Is there a place (thread) to go to nerd out about what the data means and post observations? Or just post here? I don't want to pollute this thread...


This is the place


----------



## Ren001

I am using the same adapter and OBDLink LX as shown by Björn, but I am trying to get racechrono pro to show accelerator pedal and brake pedal data. I tried with the formula used by the torque app for Tesla M3, but this did not work out. Has anyone been successful in using the OBDII adapter cable with Racechrono pro 6.1?

In detail:
I am using this equation for the throttle position for example:
- Channel: "Accelerator position"
- PID: "0x0111" (It's in the 3rd column from the torque app csv file)
- OBD-II header: "0x7e0" (8th column)
- Equation: "(A*100.0) / 255.0" or "(bytesToUint(raw, 0, 1) * 100.0) / 255.0" (4th column)

According to the Model 3 CAN bus IDs and data.xlsx file the pid for 2019 M3 should be x0108 and the data item is data7 with a formula like "Pedal Position % u8 SB 32 scale 0.4" - but how to enter this in Racechrono Pro?

Any help appreciated...


----------



## amund7

JWardell said:


> Only Wifi ODB readers will work with iPhones, and then I doubt any apps supporting them will work with Tesla's custom CAN commands. Let me know if you find one that does.
> This is why I have a cheap android device, so I have no problem using only for gauges and leaving it behind in the car...


OBDLink claims MX+ (note the plus) is compatible with all IOS devices. I think I read somewhere that is supports both regular bluetooth (Android compatible, I use it myself) and BLE (Iphone).
TM Spy exists for Iphone, doesn't it? Not the overflow of information like Scan My Tesla, but it does give you the most important battery stats at least.
I plan to start work on an iphone version of Scan My Tesla, so OBDLink MX+ will be a good choice!


----------



## amund7

Ren001 said:


> I am using the same adapter and OBDLink LX as shown by Björn, but I am trying to get racechrono pro to show accelerator pedal and brake pedal data. I tried with the formula used by the torque app for Tesla M3, but this did not work out. Has anyone been successful in using the OBDII adapter cable with Racechrono pro 6.1?
> 
> In detail:
> I am using this equation for the throttle position for example:
> - Channel: "Accelerator position"
> - PID: "0x0111" (It's in the 3rd column from the torque app csv file)
> - OBD-II header: "0x7e0" (8th column)
> - Equation: "(A*100.0) / 255.0" or "(bytesToUint(raw, 0, 1) * 100.0) / 255.0" (4th column)
> 
> According to the Model 3 CAN bus IDs and data.xlsx file the pid for 2019 M3 should be x0108 and the data item is data7 with a formula like "Pedal Position % u8 SB 32 scale 0.4" - but how to enter this in Racechrono Pro?
> 
> Any help appreciated...


PIDs are OBD2 language commands to request certain data... Tesla does not speak it. We are just listening to whatever data passes by between the different modules. See if that thing can get out of OBD2 mode and has a CANBUS mode, then it might work?


----------



## dburkland

amund7 said:


> OBDLink claims MX+ (note the plus) is compatible with all IOS devices. I think I read somewhere that is supports both regular bluetooth (Android compatible) and BLE (Iphone).
> TM Spy exists for Iphone, doesn't it? Not the overflow of information like Scan My Tesla, but it does give you the most important battery stats at least.
> I plan to start work on an iphone version of Scan My Tesla, so OBDLink MX+ will be a good choice!


An iOS version of Scan My Tesla would be great, happy to be a beta tester for you if you need one


----------



## Casey_S

Does anybody have any code examples of processing CAN data for a UI? Showing live kW, voltage, etc. Just trying to educate myself.


----------



## amund7

Casey_S said:


> Does anybody have any code examples of processing CAN data for a UI? Showing live kW, voltage, etc. Just trying to educate myself.


Try this, even if it just reads files and not bluetooth. That 'middle' code is directly from Scan My Tesla, and new packets gets tested here first:
https://github.com/amund7/CANBUS-Analyzer


----------



## Ren001

amund7 said:


> Tesla does not speak it. We are just listening to whatever data passes by between the different modules. See if that thing can get out of OBD2 mode and has a CANBUS mode, then it might work?


Thank you, that was a good hint! Indeed Racechrono has a CAN Bus mode and I managed to establish connection to the Model 3 in this mode.
Now its about the PID. 
According to the "Model 3 CAN bus IDs and data" file the PID for "Accelerator position" is 0x0108 (2019 model). When I enter this PID it is translated to decimal 264 but I receive no raw data.
Any more hints?


----------



## JSGTA

I've found a place that currently sells the Geotab adapters for the Model 3, Model S, and Model X.

I've bought the adapter for the Model 3 from them and have had friends with the Model S and Model X buy the OBD2 adapters from them as well and they've been working great.

The Model S (2012-2015) uses the HRN-CT06A1
The Model S (2015+) and Model X use the HRN-CT06A11 and the HRN-CM24Y1 (if you need multiple connections)

If you have the 2015 Model S, if you VIN is greater than P7000, you have to use the HRN-CT06A11 adapter!

The Model 3 (2018+) uses the HRN-CT20T1


----------



## Needsdecaf

JWardell said:


> Well now Björn has let all the cats out of the bag. I bet harness adapters will be out of stock instantly.
> I still could use anyone's help coding the ESP32 to be host to the OBDlink, so I can make HUD modules.


Thanks for all you and the rest are doing on this front.

Yes, the cables are showing 2 week delivery time. I just ordered mine, will see how long it takes. Should give me plenty of time to source a used dedicated android phone to monitor.


----------



## Mr.K

Got this in the mail, guess I was to slow to order. 😂


> Valued customers,
> the appreciation of our work has over-exceeded all our expectations. Within 2 hours all of our prepared products were completely ordered. For an appropriate re-production, please allow us to initiate the required steps in an orderly manner. This has happened in the meantime, so today i can inform you here that from the calendar week 45, the shipment will be ordered continued.
> If you cancel your order in the meantime, we deeply regret that, but would also ask for your
> understanding of the following chronology.
> step 1 Thursday afternoon
> 1st contact of Bjorn to me
> step 2 Friday afternoon
> installation by Amund in bjorn's McHammer
> step 3 Saturday
> XXL recording Session by Bjorn
> step 4 sunday
> broadcast of the first ScanMyTesla clip
> ... the rest you know yourself.
> 
> We do our best to secure the shipment completition of the entire order backlog in calendar week 45
> and are asking here for your understanding.
> 
> Sincerely from Thuringia ... the middle of Germany
> / Michael Kluge


----------



## LakeWorthB

JSGTA said:


> I've found a place that currently sells the Geotab adapters for the Model 3, Model S, and Model X.
> 
> The Model 3 (2018+) uses the HRN-CT20T1


What does 2018+ mean, so is this a pre-2019 cable? Or does it have 2 connectors that work with 2018 and 2019 cars?


----------



## JSGTA

LakeWorthB said:


> What does 2018+ mean, so is this a pre-2019 cable? Or does it have 2 connectors that work with 2018 and 2019 cars?


2018 vehicles or newer


----------



## bexc

I recently got an ESP32 CANDue board to monitor the CAN traffic from the center console. But the case seems pretty wasteful in terms of space (it's higher and longer than needed), and I was wondering if anyone's designed a replacement?

If not, I'll proceed with learning about 3D printing and making my own


----------



## JWardell

LakeWorthB said:


> What does 2018+ mean, so is this a pre-2019 cable? Or does it have 2 connectors that work with 2018 and 2019 cars?


I believe they ask which one you need at check out. I agree 2018 and 2019 are different, not sure why they don't list two different parts.



Ren001 said:


> Thank you, that was a good hint! Indeed Racechrono has a CAN Bus mode and I managed to establish connection to the Model 3 in this mode.
> Now its about the PID.
> According to the "Model 3 CAN bus IDs and data" file the PID for "Accelerator position" is 0x0108 (2019 model). When I enter this PID it is translated to decimal 264 but I receive no raw data.
> Any more hints?


We are looking at CAN message IDs, 0x108.
J1939 PIDs used by ODBII is a different network and protocol, and not present in the model 3.


----------



## Casey_S

If anyone else is interested in learning about CAN hacking and doesn't want to buy hardware, I suggest trying ICsim. Generates CAN data over SocketCAN in Linux between a virtual controller and faux instrument cluster. Great for practicing how to sniff with no risks.


----------



## Onyx

Here's an update on my experiments with going directly to the TM3 display with can data. I built a Back to the Future themed nerd display. The data it's pulling is nothing new, but damn it's cool to have it display like this!


----------



## xilex

Onyx said:


> Here's an update on my experiments with going directly to the TM3 display with can data. I built a Back to the Future themed nerd display. The data it's pulling is nothing new, but damn it's cool to have it display like this!


Bro...what the ****. That's epic! You better come back with a guidebook for us.


----------



## JWardell

Onyx said:


> Here's an update on my experiments with going directly to the TM3 display with can data. I built a Back to the Future themed nerd display. The data it's pulling is nothing new, but damn it's cool to have it display like this!


Incredible! Love it!!

I'm guessing the car must be connected to the wifi from your board first. If that's the case, does the car then lose its internet to the rest of the world?
I'm wondering if this could instead be some sort of server app running on a phone with hotspot so both would work

Edit sorry, I think you already explained that this is transmitting your phone, so hopefully the latter is true. Looking forawrd to learning more...maybe I need to order one of those machinas. My pile of arduinos and raspberry pi's isn't high enough anyway


----------



## Onyx

My setup basically works like this:
- My car is connected through its LTE connection to the Internet (or my wifi when sitting in the garage)
- I point my car's browser to my web server "on the Internet" (I happen to be using an ngrok tunnel for development so technically the server is running on my PC)
- This web app opens a "client" web socket connection to the server to allow two-way, semi efficient binary communication
- My phone is connected through its own LTE connection to the Internet
- I'm developing an an app that's running on my phone, and acts as a relay between the Macchina M2 and the Internet
- My M2 device is connected to my car's can bus, and broadcasts the data it sees using an attached Xbee Bluetooth LE card (using firmware I'm developing).
- My phone app connects to the M2 when its scans pick it up, and then connects to a "device" web socket endpoint on my web server

So basically this setup allows me to stream can bus data to any connected web client, and also allows client to query and control the M2. If I weren't so cheap, I'd cut out the "middle man" (i.e the phone), and spring for an LTE Xbee card. This would require me to pay another monthly fee though, so yeah, not so cool. Also, I plan to eventually replace my Xbee card with the ESP32 based on Macchina makes that will allow dual bluetooth/wifi capability. I plan to use this functionality to dump the full logs I'll eventually be continuously gathering on the SD card, wirelessly to the cloud.

In practice, this is working very well (not perfect, I still have messages that glitch from time to time). I hop in the car and it "just works". I spent a ton of time working on automatic reconnects for the car, relay, and web app though. It really is a pain to have to manage the connectivity through a relay. But I really love the low-touch approach with no wires, visible electronic bits, or extra screens.

But, yeah, so much to do, so much to learn. 

And, yes, I'll be releasing all this on GitHub soon-ish.

EDIT: Oh, and yeah, the message framing has been and still is a nightmare!


----------



## raiello

I need about 9 harness to add vehicle tracking to my Tesla model 3's. I have 4ea 2018's and 5ea 2019's that I have to add ODB2 trackers to for our insurance company. They will be logging mileage and time from those devices. On ICE cars they also pull the vin on the device though I am not sure that info is available from the diagnostic port. If any one has these ready made I am sure I can have them sourced in china if you want to be able to get these made easily. Can anyone help with the cables I need?


----------



## Ren001

JWardell said:


> We are looking at CAN message IDs, 0x108.


Thanks JWardell, got it!
I am able now to select CAN message ID 0x118 and receive raw data in Racechrono Pro Beta 6.1.3 with a rate of 0,2 kbit/s.
Is 0x118 data 7 the percentage of the accelerator pedal? I.e. 100% = full throttle? And data 3, brake pedal info is only on/off (0/1)?
I am asking because when I track the car I was used to have a video with overlay of speed, accelerator and brake pedal position to study my laps - and I am trying to establish something similar with the Model 3.


----------



## Madmolecule

I just ordered an M2 and the SuperB. I did order the SuperB with the internal antenna. Let me know if the external antenna would've been a better choice. https://www.crowdsupply.com/


----------



## Madmolecule

I think I ordered the wrong radio, as I did not want get one with LTE. Is this the model you would recommend that would work with the M2? Digi LTE Modem


----------



## Onyx

Madmolecule said:


> I just ordered an M2 and the SuperB. I did order the SuperB with the internal antenna. Let me know if the external antenna would've been a better choice. https://www.crowdsupply.com/


I've been using a similar device with an internal trace antenna and the signal is really strong. I can even be working in my office and my phone picks up the M2's signal in the garage.



Madmolecule said:


> I think I ordered the wrong radio, as I did not want get one with LTE. Is this the model you would recommend that would work with the M2? Digi LTE Modem


I haven't tried it myself, but Macchina do have a tutorial on using this at https://docs.macchina.cc/m2-docs/detailed-reference/communication/cellular (which you probably saw). Let us know how it goes.


----------



## Onyx

Last update before I move on to other project ideas using this tech. Thanks to everyone that contacted me with suggestions!


----------



## dburkland

Tonight I installed the adapter cable and the OBDLink MX+ however I'm not having much luck with the OBD Link iOS app. It connects to the device via Bluetooth however barks about not being able to find a compatible protocol. The Model 3 is 500 baud correct? I have tried both of the 500 baud options along with automatic to no avail. A buddy of mine has a spare Android so I'll probably go the ScanMyTesla route but still wanted to give the iOS route a shot. 









One other question, any folks out there get SavvyCAN working with macOS Catalina + OBDLink MX+? For fun I wanted to see if I could at least see some basic CAN messages:

* Paired the OBLink MX+ to my MBP
* Added a device connection by specifying serial (tried both the cu.xxxx And tty.xxxx devices).
* Kept receiving permission denied or GVRET-related errors

I'm guessing I need a different OBD adapter like the EVTV one however since I'm new to all this I figured I'd ask the experts


----------



## prensel

I'm only using the raw CANbus data and not using an OBD2 adapter/converter. Also have the EVTV device which is good, it works like a remote gvret device with Savvycan.
But any device that sniffs the CANbus data and sends it to your reversing tool might work. I also have some Arduino based CANbus sniffers which plug directly on a 9pin subd connector that i have installed on the EVTV kit. This will also accept standard Peak devices.

Currently working on porting/adapting OVMS (OpenVehicleMonitoringSystem) for using it with Model3.


----------



## JWardell

Busy posting day to miss yesterday!



Onyx said:


> My setup basically works like this:
> - My car is connected through its LTE connection to the Internet (or my wifi when sitting in the garage)
> - I point my car's browser to my web server "on the Internet" (I happen to be using an ngrok tunnel for development so technically the server is running on my PC)
> - This web app opens a "client" web socket connection to the server to allow two-way, semi efficient binary communication
> - My phone is connected through its own LTE connection to the Internet
> - I'm developing an an app that's running on my phone, and acts as a relay between the Macchina M2 and the Internet
> - My M2 device is connected to my car's can bus, and broadcasts the data it sees using an attached Xbee Bluetooth LE card (using firmware I'm developing).
> - My phone app connects to the M2 when its scans pick it up, and then connects to a "device" web socket endpoint on my web server
> 
> So basically this setup allows me to stream can bus data to any connected web client, and also allows client to query and control the M2. If I weren't so cheap, I'd cut out the "middle man" (i.e the phone), and spring for an LTE Xbee card. This would require me to pay another monthly fee though, so yeah, not so cool. Also, I plan to eventually replace my Xbee card with the ESP32 based on Macchina makes that will allow dual bluetooth/wifi capability. I plan to use this functionality to dump the full logs I'll eventually be continuously gathering on the SD card, wirelessly to the cloud.
> 
> In practice, this is working very well (not perfect, I still have messages that glitch from time to time). I hop in the car and it "just works". I spent a ton of time working on automatic reconnects for the car, relay, and web app though. It really is a pain to have to manage the connectivity through a relay. But I really love the low-touch approach with no wires, visible electronic bits, or extra screens.
> 
> But, yeah, so much to do, so much to learn.
> 
> And, yes, I'll be releasing all this on GitHub soon-ish.
> 
> EDIT: Oh, and yeah, the message framing has been and still is a nightmare!


It really blows my mind you got all of that working! Also impressive is how low the latency is of everything.
Even if you can eventually filter out most of the data with 250ms updates on just the data you want, that would still use a lot of data up and back down.
Ultimately I'm curious if this could be moved to a Pi with a hotspot or run a hotspot on the Machina, to somehow inject data locally while passing everything else out over cellular.
I assume it would also be fairly easy to control start/stop of log dumps to the SD card with an on-screen button?



raiello said:


> I need about 9 harness to add vehicle tracking to my Tesla model 3's. I have 4ea 2018's and 5ea 2019's that I have to add ODB2 trackers to for our insurance company. They will be logging mileage and time from those devices. On ICE cars they also pull the vin on the device though I am not sure that info is available from the diagnostic port. If any one has these ready made I am sure I can have them sourced in china if you want to be able to get these made easily. Can anyone help with the cables I need?


If you are just looking to track milage and other items in the Tesla API, you could easily do this with TeslaFi or by running your own server, no need to install a thing.



Ren001 said:


> Thanks JWardell, got it!
> I am able now to select CAN message ID 0x118 and receive raw data in Racechrono Pro Beta 6.1.3 with a rate of 0,2 kbit/s.
> Is 0x118 data 7 the percentage of the accelerator pedal? I.e. 100% = full throttle? And data 3, brake pedal info is only on/off (0/1)?
> I am asking because when I track the car I was used to have a video with overlay of speed, accelerator and brake pedal position to study my laps - and I am trying to establish something similar with the Model 3.


That's correct, like most cars you have full accelerator pedal position but binary brake pedal. My guess is there is a value for brake pressure from the iBooster that we might eventually find to give an analog reading.



dburkland said:


> Tonight I installed the adapter cable and the OBDLink MX+ however I'm not having much luck with the OBD Link iOS app. It connects to the device via Bluetooth however barks about not being able to find a compatible protocol. The Model 3 is 500 baud correct? I have tried both of the 500 baud options along with automatic to no avail. A buddy of mine has a spare Android so I'll probably go the ScanMyTesla route but still wanted to give the iOS route a shot.
> View attachment 30173
> 
> 
> One other question, any folks out there get SavvyCAN working with macOS Catalina + OBDLink MX+? For fun I wanted to see if I could at least see some basic CAN messages:
> 
> * Paired the OBLink MX+ to my MBP
> * Added a device connection by specifying serial (tried both the cu.xxxx And tty.xxxx devices).
> * Kept receiving permission denied or GVRET-related errors
> 
> I'm guessing I need a different OBD adapter like the EVTV one however since I'm new to all this I figured I'd ask the experts


That is correct, the OBDlink app will only connect with the device, but there is no OBD data to find. Only ScanMyTesla can use it to read the CAN data.
SavvyCAN isn't made to talk to the OBDlink directly, only their own CAN device.

Yeah, you are starting to see that I have six completely different ways of connecting to the CAN, none of which work with each other


----------



## raiello

I have no choice but to install a proprietary OBD2 tracking device in all my vehicles. I need these cables no matter what. Does anyone have any ideas? I have 5ea 2019 model 3' s and 4ea 2018 model 3's. They all need this obd2 device.


----------



## prensel

Just noticed that 0x118 is missing from the latest 2019.32.12.2 58f3b76.
Before digging though the logs, anyone know where I can get the drive status from ?


----------



## Onyx

JWardell said:


> Even if you can eventually filter out most of the data with 250ms updates on just the data you want, that would still use a lot of data up and back down.


I'm doing that now. I throttle each message id to no more than 1 message per 250ms window, and the web app instructs the firmware to transmit only the messages it needs. So for the signal viewer, it's transmitting only the message you're currently viewing, and the BTTF display currently uses only 12 messages. I also now have a "pull mode", where apps can request the last value of a message, without having to have the message be broadcast continuously. For example, I can use this to poll solar data once a minute to see if I should turn the screen to night mode.

All time, my relay has consumed less than 40mb of data (including wifi used during development), and this includes the time before I had message filtering and throttling. So I'm not really worried about it for now. I do have an extra card up my sleeve though: I could easily add the ability for the firmware to package the signals an "applet" needs in a single data packet, which would further reduce bandwidth usage. So for example, the BTTF applet could have a signal processor on the M2 that extracts only PCS_dcdcLvBusVolt from PCS_logging, and send that along without all the other multiplexed data in PCS_logging, and likewise for the other messages it currently consumes.

If anything, I'd like to go in the other direction, and cut out the relay and have the M2 go straight to LTE. But this present its own set of issues.



JWardell said:


> Ultimately I'm curious if this could be moved to a Pi with a hotspot or run a hotspot on the Machina, to somehow inject data locally while passing everything else out over cellular.


I don't see how the car would be able to access this local network though. What am I missing?



JWardell said:


> I assume it would also be fairly easy to control start/stop of log dumps to the SD card with an on-screen button?


Yes, controlling it is trivial. I still haven't written the logging code yet though. I'm thinking I'll just log all the time, and pull the card when I need to review something. I have a 64GB card in it now. This is also one of the reasons I've left the M2 accessible. What I will do though is have a command to allows me to "save the current log", much like the dashcam does, so that specific data never gets overwritten with new data.


----------



## Onyx

prensel said:


> Just noticed that 0x118 is missing from the latest 2019.32.12.2 58f3b76.
> Before digging though the logs, anyone know where I can get the drive status from ?


I just checked and I'm still seeing valid signals on 280 (DI_systemStatus). DI_gear (21|[email protected]+ (1,0) [0|0] "" X) is still showing D/P/R, and DI_systemState (16|[email protected]+ (1,0) [0|0] "" X) is still showing STANDBY (2) when parked and ENABLE (5) when "in gear".

Are you sure the drive inverter is on? (That is, until you press the brake pedal, none of the DI messages are broadcast.)


----------



## LakeWorthB

LakeWorthB said:


> What does 2018+ mean, so is this a pre-2019 cable? Or does it have 2 connectors that work with 2018 and 2019 cars?


So I placed an order for one, but then got the call back and they said they just figured out that this actually only works on 2018 cars, and not 2019. The 2019 ones will be out soon. Doh.


----------



## JSGTA

JSGTA said:


> 2018 vehicles or newer


so this is my mistake. It's only for 2018 models. I called them up and they told me that the manufacturer is going to be coming out with the 2019 adapter shortly, so I will post here again when they have the 2019 model 3 adapter for sale


----------



## Mike

You 


Onyx said:


> Here's an update on my experiments with going directly to the TM3 display with can data. I built a Back to the Future themed nerd display. The data it's pulling is nothing new, but damn it's cool to have it display like this!


You know, next time some game like Cuphead is added to the OS of our cars, I'd love to see this added as well.....sometimes you just want to drive around with all this propulsion system raw data spinning away......makes things more fun......know what I mean, Elon ;-p

S


----------



## michi84

I think i have found the radiator bypass value. As i suspected, it seems to have been moved to VCFRONT Logging 1Hz, and replace the radiator fan FET temp. Using information found at https://www.teslarr.com/learn/thermal-management (Quote: "The radiator bypass valve is mounted to the right front outboard corner of the subframe. The THC commands the valve to the full radiator position if the system is in parallel mode, or if it is in series mode and either: The Battery inlet temperature is greater than the Battery active cooling target, or The powertrain inlet temperature is greater than the powertrain active cooling target"), the behaviour would make sense.

The value is 100% when in series mode, and 0% in parallel mode, and somewhere in between during transitioning.

BO_ 897 VCFRONT_logging1Hz: 8 ETH
SG_ VCFRONT_RadiatorBypass m2: 56|[email protected]+ (1,0) [0|0] "%" X

Does anyone have an old can dump from before the firmware change where he battery temperature went above 30°C, to compare the switching behaviour?


----------



## Onyx

Woah, I started playing with Macchina's SuperB, and the ESP32 on it is out of this world! My entire phone relay app can be eliminated with this thing. I can connect directly to wifi AND run a web socket server directly on the chip, insane! It's really too bad this will end up behind a symmetric NAT because it would be awesome for the Tesla browser to hit the M2 server directly. To be clear, this would work when parked in my garage, but not when running over LTE.

With this setup, I'd have two separate Arduino firmwares talking to each other over the Xbee UART. So cool! There go my next few evenings...


----------



## JWardell

Onyx said:


> I don't see how the car would be able to access this local network though. What am I missing?


This would have to be done with some sort of firewall-like app on the phone that redirects a particular address to the local server and lets everything else out through the internet, like they do in a hotel or plane. Way above my level


----------



## Calibr8r

michi84 said:


> I think i have found the radiator bypass value. As i suspected, it seems to have been moved to VCFRONT Logging 1Hz, and replace the radiator fan FET temp. Using information found at https://www.teslarr.com/learn/thermal-management (Quote: "The radiator bypass valve is mounted to the right front outboard corner of the subframe. The THC commands the valve to the full radiator position if the system is in parallel mode, or if it is in series mode and either: The Battery inlet temperature is greater than the Battery active cooling target, or The powertrain inlet temperature is greater than the powertrain active cooling target"), the behaviour would make sense.
> 
> The value is 100% when in series mode, and 0% in parallel mode, and somewhere in between during transitioning.
> 
> BO_ 897 VCFRONT_logging1Hz: 8 ETH
> SG_ VCFRONT_RadiatorBypass m2: 56|[email protected]+ (1,0) [0|0] "%" X
> 
> Does anyone have an old can dump from before the firmware change where he battery temperature went above 30°C, to compare the switching behaviour?


Here is some diagrams that may be helpful. The super Bottle has 5 ports but only 4 are in use at any one time, with one port being shared by paths #2 & #5 shown in the zoomed view below.


----------



## dburkland

Thanks for the reply @JWardell. Do you know (or anybody else know) if the EVTV device works with Scan My Tesla? I ask as it looks like for the cost you can get WiFi/bluetooth support along with the ability to view CAN traffic from apps like SavvyCAN.

Thanks again,

Dan


----------



## tomc603

dburkland said:


> Thanks for the reply @JWardell. Do you know (or anybody else know) if the EVTV device works with Scan My Tesla? I ask as it looks like for the cost you can get WiFi/bluetooth support along with the ability to view CAN traffic from apps like SavvyCAN.
> 
> Thanks again,
> 
> Dan


Dan, I have the EVTV device and it does not (directly) work with Scan My Tesla. My experimenting has it receiving 1-3 packets per second from the CAN bus, and the PIDs appear very slowly in the display. It also takes multiple attempts to connect properly.

I've been poring over the code slowly to see if it can be modified to add a mode for a more direct forwarding between the CAN ports, and how filters could be handled. This is probably something we'd need to talk to @Collin80 to get his thoughts on the matter.

I actually spoke with @amund7 on FB messenger, and he was surprised that the EVTV CAN device plus my OBD2 BT device worked at all with Scan My Tesla. It's possibly because I enabled every dangerous option on the EVTV CANDue, but again the behavior isn't correct, so while Scan My Tesla is receiving data, it's not working properly.

On a better note, I ordered a connector from https://www.xtss.com/ in the very early morning hours of Sunday and it has already shipped.


----------



## amund7

dburkland said:


> Thanks for the reply @JWardell. Do you know (or anybody else know) if the EVTV device works with Scan My Tesla? I ask as it looks like for the cost you can get WiFi/bluetooth support along with the ability to view CAN traffic from apps like SavvyCAN.
> 
> Thanks again,
> 
> Dan


I have 1 user using it, it works, barely, meaning suuuuper slowly. I suggested he talk to EVTV, and see if they can speed it up. They just need to pass through the raw canbus data (with the correct hex formatting) when I send ATMA. Bonus would be to support filters, but the app would still work witout filters.


----------



## Calibr8r

amund7 said:


> I have 1 user using it, it works, barely, meaning suuuuper slowly. I suggested he talk to EVTV, and see if they can speed it up. They just need to pass through the raw canbus data (with the correct hex formatting) when I send ATMA. Bonus would be to support filters, but the app would still work witout filters.


I decided not to bother with the EVTV arduino project and just wired a secondary OBD2 port to the EVTV terminal strip and is wired directly to the CAN HI/LO inputs to his box. That way I can still tinker with the arduino stuff simulataneously with ScanMyTesla. Works just fine


----------



## Ren001

@amund7 @JWardell
Just to give you feedback: Racechrono Pro 6.1.3 is now working with the cable from www.e-mobility-driving-solutions.com thanks to your famous spreadsheet! 
I took the car to track on sunday and had channels similar to the ones on my Chevrolet racecar - just less things to take care for (i.e. oil pressure, oil temp)

For interested users:
I got these instructions from the developer, applied them and got 2 channels - one for accelerator (0-100%), one for brake (0 or 100%)

CAN ID: "0x118": This is same as the PID in RaceChrono channel editor. Just enter 0x118 there.

Time period: "10 ms": This tells you how often this message is transmitted. 10 ms translates to 100 Hz, 100 times a second. You can ignore this column.

Bytes: "8": This tells you how many bites are in the messages. You can ignore this column.

Data 3: "Brake Pedal u2 SB 19 1-BrakePress": This is the third data value (channel) within the messages within PID 0x118. The u2 tells you it is unsigned integer that is 2 bits long. SB 19 tells you it starts at bit 19. "1-BrakePress" probably means you will get value 1 when it's pressed. No idea about the possible values 2 and 3, but 0 is probably not pressed.

As probably only values 0 and 1 are useful, I would use "bitsToUint(raw, 20, 1)" to get the value, instead of "bitsToUint(raw, 19, 2)". If you want to scale that to % to be used as "Brake position (%)" in RaceChrono, you can do "bitsToUint(raw, 20, 1) * 100.0". Then you will get 0% when pedal is not depressed, and 100% when depressed.

Data 7: "Pedal Position % u8 SB 32 scale 0.4". We decode just like above, except for the scale. Start with "bitsToUint(raw, 32, 8)". It will probably give you values 0 when not depressed, and 255 when fully depressed as this is 8-bit value with range of 0-255. The scale 0.4 is not really exact, but is roughly equivalent with dividing with 2.55. So equation of "bitsToUint(raw, 32, 8) / 2.55" should give 0-100%.


----------



## dburkland

amund7 said:


> I have 1 user using it, it works, barely, meaning suuuuper slowly. I suggested he talk to EVTV, and see if they can speed it up. They just need to pass through the raw canbus data (with the correct hex formatting) when I send ATMA. Bonus would be to support filters, but the app would still work witout filters.


@amund7 Another noob question, by sending ATMA to the OBDLink MX+ is it effectively just passing your app raw CAN messages which you are then decoding via the app?


----------



## prensel

Onyx said:


> I just checked and I'm still seeing valid signals on 280 (DI_systemStatus). DI_gear (21|[email protected]+ (1,0) [0|0] "" X) is still showing D/P/R, and DI_systemState (16|[email protected]+ (1,0) [0|0] "" X) is still showing STANDBY (2) when parked and ENABLE (5) when "in gear".
> 
> Are you sure the drive inverter is on? (That is, until you press the brake pedal, none of the DI messages are broadcast.)


You're right !

I have the M3 outside and using Savvycan remote over wifi to the EVTV box.
Had the M3 enabled into 'drive' from the app but somehow it wasnt working or enabled as it seems. 
After physically pressing the brake pedal the 'missing' packets started coming.


----------



## JSGTA

JSGTA said:


> so this is my mistake. It's only for 2018 models. I called them up and they told me that the manufacturer is going to be coming out with the 2019 adapter shortly, so I will post here again when they have the 2019 model 3 adapter for sale


The 2019 adapter is the HRN-CT20T11 and is now live on their website.


----------



## michi84

@Onyx: I like how you play around with the graphical interface for displaying the data. Will this be modifieable in your project without changing the fundamental code behind this, like using an HTML editor and a graphics program to design the layout, and then define which data to show?

What i would like to have is something similar to the thermal management screen in the rooted Model S, adapted to the screen aspect ratio of the model 3, preferably switchable between other similar views, e.g. HVAC display, performance display, thermal, energy and the "secret signals" screen to investigate specific signals.

For continuous recording, i would think that splitting the file after a few minutes capture would be better than one long continuous recording - at least as an option to avoid having one very large file which the tools find hard to digest. Also, is it possible to configure the M2 to automatically start recording when the car powers up with only M2RET installed, preferably with splitting, to be able to record proper CAN dumps in the meantime while this project continues?

My planned final setup would probably be a Y-cable with my OBDLink MX connected to SMT on my phone for displaying data when i need the main screen for navigation or where there is no cell connection, and the M2 running your project to serve the main screen and record can dumps for reverse engineering. Also, SMT can serve as secondary display to minimize the need for switching between different sets of data, e.g. thermal on main screen, voltages and BMS target temps on secondary.


----------



## amund7

dburkland said:


> @amund7 Another noob question, by sending ATMA to the OBDLink MX+ is it effectively just passing your app raw CAN messages which you are then decoding via the app?


Yes that is correct, only with some formatting settings (by default it does not sent the can ID), and filtering to only let through what the app wants to see in the current tab.


----------



## dburkland

amund7 said:


> Yes that is correct, only with some formatting settings (by default it does not sent the can ID), and filtering to only let through what the app wants to see in the current tab.


Awesome, thanks for confirming that!


----------



## Collin80

amund7 said:


> I have 1 user using it, it works, barely, meaning suuuuper slowly. I suggested he talk to EVTV, and see if they can speed it up. They just need to pass through the raw canbus data (with the correct hex formatting) when I send ATMA. Bonus would be to support filters, but the app would still work witout filters.


I think early on I did try to make the code work with SMT but I don't remember if I ever actually got it to work. Jack really was most interested in Torque support and it does do that properly. There isn't any really good reason why I couldn't support ATMA and get ScanMyTesla to work.

A long time ago people asked about doing custom PIDs with Torque. I think Torque might be able to read general CAN frames and decode them but if SMT isn't getting the raw traffic properly then probably Torque wouldn't either. So, maybe this is a general area for further improvement.


----------



## raiello

LakeWorthB said:


> So I placed an order for one, but then got the call back and they said they just figured out that this actually only works on 2018 cars, and not 2019. The 2019 ones will be out soon. Doh.


Where did you order it from? I need a 2018 cable


----------



## tomc603

I can confirm the XTSS cable for the 2018 Model 3 is in stock, shipping quickly, and works perfectly. My only input is that the protective sheath that the connector pass through wiring is in makes the pumper assembly stiff. A little bit of shoving and folding gets it all tucked in nicely, though.


----------



## Onyx

michi84 said:


> @Onyx: I like how you play around with the graphical interface for displaying the data. Will this be modifieable in your project without changing the fundamental code behind this, like using an HTML editor and a graphics program to design the layout, and then define which data to show?


It could be. I don't have any actual plans to do this myself at this time, but it'll all be open source, and it should be easy-ish to build this. I'll probably end up releasing this thing in components, tentative repos are:

onyx-m2-firmware: the M2 and SuperB firmwares you need to flash
onyx-m2-server: the Nodejs server you need to talk to the M2 through web sockets
onyx-m2-client: the Javascript libary that does the heavy lifting with the server

And the very last repo will be onyx-m2-ui, which will be the actual user interface you see in my videos. So with this segmentation, it should be really easy to take this thing is lots of cool directions. You wouldn't need to use my ui at all, you could build your own without having to worry about any of the underlying details (at least that's the theory). Let me know what you think.



michi84 said:


> What i would like to have is something similar to the thermal management screen in the rooted Model S, adapted to the screen aspect ratio of the model 3, preferably switchable between other similar views, e.g. HVAC display, performance display, thermal, energy and the "secret signals" screen to investigate specific signals.


Do you have a picture of what the rooted thermal screen looks like (or even better, a video)? I'd use it as inspiration. And yeah, I'll definitively be building more views moving forward.

My current backlog of ideas is:
1) A vbox like 0-100 chrono
2) A charge graph like you're charging
3) An animated view of how power is being used (I've been looking at the e-fuse data, and it's amazing how it shows precise energy use of every single electrical gizmo in the car).
4) A trip view that shows multiple things at once (including a trace on a map)
5) A "track view" with everything you'd want to see at the track (maybe taking some inspiration from the excellent Harry's GPS Laptimer)

So much fun ahead, if I can only get the connection/transmission/reliability foundations stuff out of the way. (Using the SuperB is going to be so good though - no more phone relay and super fast and reliable link.)



michi84 said:


> For continuous recording, i would think that splitting the file after a few minutes capture would be better than one long continuous recording - at least as an option to avoid having one very large file which the tools find hard to digest. Also, is it possible to configure the M2 to automatically start recording when the car powers up with only M2RET installed, preferably with splitting, to be able to record proper CAN dumps in the meantime while this project continues?


Indeed, that sounds reasonable. I'm not 100% sure what I'm going to be doing with this. One thing I really want is to have trips recorded and sync'ed when I park in my garage, but these could be separate files from the "pure can dumps" and managed differently. So much to do...


----------



## michi84

Onyx said:


> Do you have a picture of what the rooted thermal screen looks like (or even better, a video)? I'd use it as inspiration. And yeah, I'll definitively be building more views moving forward.


Here is a sample picture:


http://imgur.com/KijMR0n


Video: 




I guess the graphics would have to be modified for the browser window aspect ratio and adapted to model 3 components and terminology. The cooling system diagrams posted here can be a starting point. Waht i would like to have displayed is front and rear inverter, heatsink and stator temps, oil (pcb) temp, oil flow rate, coolant flow rates, battery/powetrain inlet temps, battery cell and target temps, and five way valve mode and angle. Also A/C refrigerant pressure and chiller on/off. Also, evaporator temp and power, and if space is there PTC power and temps.

I think font size should be a bit bigger than in the model S, even if this means simplyfing graphics.


----------



## dburkland

Onyx said:


> It could be. I don't have any actual plans to do this myself at this time, but it'll all be open source, and it should be easy-ish to build this. I'll probably end up releasing this thing in components, tentative repos are:
> 
> onyx-m2-firmware: the M2 and SuperB firmwares you need to flash
> onyx-m2-server: the Nodejs server you need to talk to the M2 through web sockets
> onyx-m2-client: the Javascript libary that does the heavy lifting with the server
> 
> And the very last repo will be onyx-m2-ui, which will be the actual user interface you see in my videos. So with this segmentation, it should be really easy to take this thing is lots of cool directions. You wouldn't need to use my ui at all, you could build your own without having to worry about any of the underlying details (at least that's the theory). Let me know what you think.
> 
> Do you have a picture of what the rooted thermal screen looks like (or even better, a video)? I'd use it as inspiration. And yeah, I'll definitively be building more views moving forward.
> 
> My current backlog of ideas is:
> 1) A vbox like 0-100 chrono
> 2) A charge graph like you're charging
> 3) An animated view of how power is being used (I've been looking at the e-fuse data, and it's amazing how it shows precise energy use of every single electrical gizmo in the car).
> 4) A trip view that shows multiple things at once (including a trace on a map)
> 5) A "track view" with everything you'd want to see at the track (maybe taking some inspiration from the excellent Harry's GPS Laptimer)
> 
> So much fun ahead, if I can only get the connection/transmission/reliability foundations stuff out of the way. (Using the SuperB is going to be so good though - no more phone relay and super fast and reliable link.)
> 
> Indeed, that sounds reasonable. I'm not 100% sure what I'm going to be doing with this. One thing I really want is to have trips recorded and sync'ed when I park in my garage, but these could be separate files from the "pure can dumps" and managed differently. So much to do...


With the SuperB thrown into the mix will it basically be creating a WiFi network that the car will join? Curious as to how that will fit into the solution. I'm thinking of buying the M2 (along with add-on components) here in the next week so if you need another person to test / create documentation for the repos let me know.


----------



## Plagued by Penguins

Great work JWardell and everyone here! most impressive...



Onyx said:


> It could be. I don't have any actual plans to do this myself at this time, but it'll all be open source, and it should be easy-ish to build this. I'll probably end up releasing this thing in components, tentative repos are:
> 
> onyx-m2-firmware: the M2 and SuperB firmwares you need to flash
> onyx-m2-server: the Nodejs server you need to talk to the M2 through web sockets
> onyx-m2-client: the Javascript libary that does the heavy lifting with the server
> 
> And the very last repo will be onyx-m2-ui, which will be the actual user interface you see in my videos. So with this segmentation, it should be really easy to take this thing is lots of cool directions. You wouldn't need to use my ui at all, you could build your own without having to worry about any of the underlying details (at least that's the theory). Let me know what you think.


sadly in Australia the web browser is grey'd out and doesn't work unless you're in Park. so looks like we're stuck with a "second screen" solution...

I was thinking a Macchina P1 (or similar) in the back harvesting CAN and running web server + wifi AP, and a phone up front running onyx-m2-ul in firefox. do you think that would work?
it's kinda indirect compared to running CAN wires up to the front and doing everything with a RPi and local HDMI screen + custom UI, but it would allow re-use of browser code, if that's the way y'all are trending.
that BTTF display mode is a must-have  ... 0-100 timer, and racetrack type things all sound great too.

speaking of track views, there should be an accelerometer and yaw rate sensor somewhere for the stability control (ESP?) to use. probably mounted somewhere central. hopefully those are on the chassis CAN bus.
but AFAICT from reading this thread there's no easy access way to look at the chassis bus? how do folks tap into it at the moment?

currently waiting for cable adapters to arrive... wondering if I should be looking for more whilst I'm waiting...


----------



## scottf200

JWardell said:


> I believe they ask which one you need at check out. I agree 2018 and 2019 are different, not sure why they don't list two different parts.





JSGTA said:


> so this is my mistake. It's only for 2018 models. I called them up and they told me that the manufacturer is going to be coming out with the 2019 adapter shortly, so I will post here again when they have the 2019 model 3 adapter for sale





raiello said:


> Where did you order it from? I need a 2018 cable


2018: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-59#post-260502
2019: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-61#post-261062 
TMC similar post: https://teslamotorsclub.com/tmc/posts/4163315/


----------



## Calibr8r

*EDIT* I corrected the diagram for an error 11/7/2019

I figured I'd share since this is a good group for the detailed topic that includes a lot of what we log with this data. If you haven't read the SAE J1634 document on BEV range testing, its a good read.

Here is a link to one of Tesla's SAE J1634 test results to the EPA:

https://iaspub.epa.gov/otaqpub/display_file.jsp?docid=46584&flag=1

I created a simplified simulink style of logic showing how the range calculation is most likely broken down, minus some compensations for temperature and other factors. I tossed in a few values from the link above. The buffer % is just an estimation from some long range data, as I have seen it reduce as the full pack capacity reduces also. My guess would be that this percentage may be locked to whatever a 15 mile buffer is, regardless of battery pack size. (none of this is to be used as gospel, just a conversation starter)


----------



## LakeWorthB

JSGTA said:


> The 2019 adapter is the HRN-CT20T11 and is now live on their website.


Just wanted to say, I got my 2019 cable last night, and also got an OBLink LX, and scan my tesla app, and it works.


----------



## cranialdr

Is there an aftermarket data retrieval cable that does not come in a $1200.00 kit from the pirates at crash data group?

does the USB to CAN adapter on amazon interface with the MODEL S?

thanks


----------



## scottf200

scottf200 said:


> 2018: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-59#post-260502
> 2019: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-61#post-261062
> TMC similar post: https://teslamotorsclub.com/tmc/posts/4163315/


2018 cables. Seem like high quality work:


----------



## joverdijk

I have ordered the wire-harnass from EV shop in Germany, and I have OBD2 MXwifi module.
Most likely ScanMyTesla app will work, but I want to capture lots of variables and put it in mysql database on my RaspbPI4 which is in the Tesla (model3).
I am trying to find good info sources on how to do this, but I'm not able to find anything that I can use so far.
Since the MX module is Wifi i suspect somehow I can get datastream on a TCP-port or something, or maybe some seriallink emulation is there to use.
Which software/scripts can i use on RPI4 to capture/decode canbus msgs, and are there any scripts i can reuse for this?
Anybody with some tips for me?


----------



## JWardell

cranialdr said:


> Is there an aftermarket data retrieval cable that does not come in a $1200.00 kit from the pirates at crash data group?
> 
> does the USB to CAN adapter on amazon interface with the MODEL S?
> 
> thanks


You can do it yourself with a Peak adapter, I detailed that here:

https://teslaownersonline.com/threads/tesla-event-data-recorder-access-by-can.6175/post-199280


----------



## scottf200

joverdijk said:


> I have ordered the wire-harnass from EV shop in Germany, and I have OBD2 MXwifi module.
> Most likely ScanMyTesla app will work, but I want to capture lots of variables and put it in mysql database on my RaspbPI4 which is in the Tesla (model3).
> I am trying to find good info sources on how to do this, but I'm not able to find anything that I can use so far.
> Since the MX module is Wifi i suspect somehow I can get datastream on a TCP-port or something, or maybe some seriallink emulation is there to use.
> Which software/scripts can i use on RPI4 to capture/decode canbus msgs, and are there any scripts i can reuse for this?
> Anybody with some tips for me?


Unclear what your use case is for capturing that data? With ScanMyTesla you can recorded and log, then the graphing tool in the below page. I also use DriveSync to automatically move that log file from my phone to my Google drive. All this is very handy and efficient.

https://sites.google.com/view/scanmytesla/reccommended-software


----------



## joverdijk

scottf200 said:


> Unclear what your use case is for capturing that data? With ScanMyTesla you can recorded and log, then the graphing tool in the below page. I also use DriveSync to automatically move that log file from my phone to my Google drive. All this is very handy and efficient.
> 
> https://sites.google.com/view/scanmytesla/reccommended-software


Hi Scott, my use-case is enriching the data I already collect via TeslaFI API. I have a home datacenter running Grafana and I'm a statistics freak.
With the CANdata I want to add a lot more parameters to the data I collect which are not available through the API.
From my RPI4 in the car (which runs already apache webserver, openvpn tunnel to home DC, lots of scripting for stats and teslaCAM (incl realtime webcam etc etc).
I think I might use only 1 minute samples, only from parameters that make sense and are fun to see, no need for capturing realtime all canbus data ofcourse 

I took a look at your link, but I am looking not for a way to analyse dumps/csv's after the fact, I want to make a connection realtime from my RPI to the OBD2 MX-Wifi and grab (with python scripts or something) particular parameters from the canbus data and extract values. So, I guess some 'realtime' extracting/calculating has to be done within this scripts?


----------



## JWardell

I finally got 2019.36.2.1 tonight and made some logs...

First, power bump is definitely there. As compared to 32:

















Max power output from my motor went from 254kW to 267kW (5%...) battery current from 740 to 780A.
(also dug up this old post when we were previously bumped from 245kW)

I also played around with new one pedal mode. Immediately apparent reversing out of my sloped driveway. It will apply a bit of power to hold the car in place, I think blend light brake, and after holding still for a second or two engage full brake pedal and display Hold. If anything I now notice I need to update my Hold state in 0x118 as it clearly means "foot is off the pedal so turn on the brake light even if we are barely slowing" not "stopped and engaging hold" as I previously thought. (I don't think that changed, I just hand't paid close enough attention.

Just some short bursts of forward and reverse in my driveway to watch the motor currents:


----------



## dgcaste

I see the OBDLink MX is the favorite around here, but is there any reason the MX+ might be a better tool?


----------



## JWardell

dgcaste said:


> I see the OBDLink MX is the favorite around here, but is there any reason the MX+ might be a better tool?


If anything the LX is the favorite as it has all you need to use with scan my Tesla and Android. The MX has no additional benefit. The new MX+ however does add iPhone bluetooth compatibility, in case some future iPhone apps come out.


----------



## dgcaste

JWardell said:


> If anything the LX is the favorite as it has all you need to use with scan my Tesla and Android. The MX has no additional benefit. The new MX+ however does add iPhone bluetooth compatibility, in case some future iPhone apps come out.


I am a registered iOS developer so maybe I should get that so I can pull the raw data and interpret it. Can't say I look forward to keeping a lookup table up to date but I also can't say I look forward to owning an Android


----------



## Needsdecaf

Did you notice if max regen changed? 

I swear that regen feels stronger at normal deceleration speeds...


----------



## michi84

I feel that too, although it could just be a more aggressive onset of regen braking, since the actual power (monitored with SMT) does not show more regen power than before, but with winter tires i seem to get a little less regen (the update gave me back some), and my battery was not warm enough to take full regen power (although the bar never touched the dots).

I will test acceleration and regen more thoroughly tomorrow with a full and warm battery, but even a quick test at about 60% SOC on a spot where i used to get 4,54 seconds from 0-100 km/h i got 4,47 today, on a wet road, with winter tires at 3°C and light rain. That AWD traction is amazing....and i can feel the improved acceleration.


----------



## Mesprit87

@JWardell, does the -74 compared to -66 on the same line that mentions full power would represent some increase of regen? Or was it just regen data from the specific record (or not regen at all for all the experience of reading numbers I have).


----------



## joverdijk

TorquePro has ability to post values via http-post to my webserver. I used this before on IONIQ EV.
If there a way to get the canbus messages via https://www.e-mobility-driving-solutions.com/produkt/kabelsatz-m3/?lang=en wireharness and a OBDLink MX Wifi plug into TorquePro instead of ScanMyTesla? Because ScanMyTesla does not support realtime online-exporting of data of some sort to my raspberrypi.

So looking to get TorquePro to work/interpret the CANBUS data from Model3, this might offer a sollution for me to get my data out.
Any tips ?


----------



## michi84

Power increase is noticable in CAN data: max battery discharge current has been increased from 1200 to 1340 amps in my AWD, rated drive power went up from 270 to 285 kW. I am getting around 330 kW battery power now. Regen is unchanged.

@joverdijk: TorquePro will not work with Tesla, except with the EVTV OBD box. To my knowledge, the convert some CAN IDs to regular OBD PIDs in there software running in the box, and emulate an ELM 327 adapter (so technically you would not need the OBDLink), but you would be limited to the data they implemented, unless i am mistaken here that you can edit them in the software.

For data export to a webserver, i would look at someting like onyx Macchina M2 solution.


----------



## JWardell

The DBC has been updated again, this time adding VCRight messages to assist in debugging HVAC as we are discussing in the turning off heat thread.
_Added VCRight messages ID 0x20C 0x243 and 0x2B3 to assist with debugging HVAC
Renamed Brake and Hold to clarify light from brake pedal or regen slowing_

Also, I can't look at iBooster messages that only exist on the other busses to debug regen to hold braking, but I did notice iBooster Debug mode which was always 1 is now 6 after 2019.36


----------



## amund7

joverdijk said:


> TorquePro has ability to post values via http-post to my webserver. I used this before on IONIQ EV.
> [...] Because ScanMyTesla does not support realtime online-exporting of data of some sort to my raspberrypi.


Work is underway to integrate real-time web pushing from Scan My Tesla to Teslalogger. It is not decided exactly what the format will look like, but I want to make it possible to use / customize for other targets than Teslalogger some time in the future. Have not looked into the Torque http setup, details and suggestions welcome (PM please, not to derail this thread).


----------



## Madmolecule

Onyx said:


> It could be. I don't have any actual plans to do this myself at this time, but it'll all be open source, and it should be easy-ish to build this. I'll probably end up releasing this thing in components, tentative repos are:
> 
> onyx-m2-firmware: the M2 and SuperB firmwares you need to flash
> onyx-m2-server: the Nodejs server you need to talk to the M2 through web sockets
> onyx-m2-client: the Javascript libary that does the heavy lifting with the server
> 
> And the very last repo will be onyx-m2-ui, which will be the actual user interface you see in my videos. So with this segmentation, it should be really easy to take this thing is lots of cool directions. You wouldn't need to use my ui at all, you could build your own without having to worry about any of the underlying details (at least that's the theory). Let me know what you think.
> 
> .


Have you decided to release any of these yet? I have the M2, SuperB and the Digi Xbee. I have the SIM card provisioned and can talk to the M2 through the SuperB. I have upgraded everything and been able to load the "blink" example sketch and now the Blue light is blinking.

I have installed the Data Port Cable in my 3 and just trying to figure out my next step. I am planning on trying to scan it with Savvycan but I don know if there is a more elegant way to proceed for a low skilled programmer.

One of my programmers is recommending Amazon's AWS for receiving the CANbus data and then using a bootstrap dashboard to display it.


----------



## Madmolecule

I found the following source online. Everything initializes correctly, but I don't see any data on the serial monitor. Any ideas? I wondering if I'm initializing on the wrong pins.

/*
MCP2515 CAN Interface Using SPI

Author: David Harding

Created: 11/08/2010
Modified: 6/26/12 by RechargeCar Inc.

For further information see:

http://ww1.microchip.com/downloads/en/DeviceDoc/21801e.pdf
http://en.wikipedia.org/wiki/CAN_bus

The MCP2515 Library files also contain important information.

This sketch is configured to work with the 'Macchina' Automotive Interface board 
manufactured by RechargeCar Inc. CS_PIN and INT_PIN are specific to this board.

This sketch shows the most basic of steps to send and receive CAN messages.

NOTE!!! If you use this sketch to test on a live system I suggest that you comment out the
send messages lines unless you are certain that they will have no detrimental effect!

This example code is in the public domain.

*/

#include <SPI.h>
#include <MCP2515_sw_can.h>

// Pin definitions specific to how the MCP2515 is wired up.
#ifdef MACCHINA_M2
#define CS_PIN SPI0_CS3
#define INT_PIN SWC_INT
#else
#define CS_PIN 34
#define INT_PIN 38
#endif

// Create CAN object with pins as defined
SWcan SCAN(CS_PIN, INT_PIN);

void CANHandler() {
SCAN.intHandler();
}

void setup() {
delay(5000);
SerialUSB.begin(115200);

SerialUSB.println("Initializing ...");

// Set up SPI Communication
// dataMode can be SPI_MODE0 or SPI_MODE3 only for MCP2515
SPI.setClockDivider(SPI_CLOCK_DIV2);
SPI.setDataMode(SPI_MODE0);
SPI.setBitOrder(MSBFIRST);
SPI.begin();

// Initialize MCP2515 CAN controller at the specified speed and clock frequency
// (Note: This is the oscillator attached to the MCP2515, not the Arduino oscillator)
//speed in KHz, clock in MHz
SCAN.setupSW(33);

attachInterrupt(INT_PIN, CANHandler, FALLING);
//SCAN.InitFilters(true);
SCAN.InitFilters(false);
SCAN.mode(3);

// NOTE! This speed might need to change. Usually 250 or 500
if(SCAN.Init(250,16))
{
SerialUSB.println("MCP2515 Init OK ...");
} else {
SerialUSB.println("MCP2515 Init Failed ...");
}

SerialUSB.println("Ready ...");
}

byte i=0;

// CAN message frame (actually just the parts that are exposed by the MCP2515 RX/TX buffers)
CAN_FRAME message;

void loop() {

//SerialUSB.print("ID: ");

if (SCAN.GetRXFrame(message)) {
// Print message
SerialUSB.print("ID: ");
SerialUSB.println(message.id,HEX);
SerialUSB.print("Extended: ");
if(message.extended) {
SerialUSB.println("Yes");
} else {
SerialUSB.println("No");
}
SerialUSB.print("Length: ");
SerialUSB.println(message.length,DEC);
for(i=0;i<message.length;i++) {
SerialUSB.print(message.data.byte_,HEX);
SerialUSB.print(" ");
}
SerialUSB.println();
SerialUSB.println();
}
}_


----------



## JWardell

It was a freezing 18F overnight so my battery got an early deep chill. I jumped on the opportunity to answer some old and new questions. I avoided preheating the car and made sure HVAC was disabled so I could be sure there would be no regen.

Most significantly, regen through the cabin heater is confirmed!
Also, there is no brake blending in hold mode with 2019.36. You will just coast.

I'll start with the last part of my log...With everything else off, I navigated to the nearest supercharger and battery preconditioning was activated. About 3kW is added to the motor, including when sitting stopped. You can hear coolant pumping higher than usual. Adds about 8A of battery current. Cancel and a few seconds later everything settles back down.
So that means if you want to spend some energy to get some regen back, just navigate to the closest supercharger!










Backing down the incline in my driveway, battery is -2C, heat is off, regen max is reading 3kW. Here I press the pedal a bit to reverse, then once I lift instead of regen everything flips and it actually adds forward torque and draws a bit of battery power to counteract the incline. With sound and HVAC off I notice the inverter whine sounds nastier than usual, and you can see in the capture below why, no doubt algorithms fighting as it compensates with forward torque while slowing in reverse down an incline. (cursor line is right where torque flips forward)










While driving, it is immediately clear there is no brake blending going on as lifting just coasts and I need to use friction brakes.
It looks like there is still 0.5-1kW of regen available, no doubt compensated by other systems loads. I drove a bit to see if power was being used similar to supercharger conditioning to warm the battery, but no. Normally, it will not waste energy to warm things out of the normal heat generated by systems.

Then I turn on the HVAC and I watch as system regen max rams up with the heater load to 8-9kW. The heater will only come on at its full 6700W for a short time unless you set the temp to HI (which I did once toward the end). The slow ramp up is hard to physically feel when turning on HVAC...but it is detectable when turning off. I had a few pedal off regen from 35mph and you can feel the slight regen release a tiny bit to a full coast.

Here is one deceleration with regen while turning off HVAC.
Green axle speed starts decelerating. Battery current is constant around 1A. Torque constant at -30NM, rear motor power at -5kW. Regen max reading 8kW. Battery at -1.5C. Heat drawing 5000W.
Then I turn off HVAC while still slowing... Heater ramps to zero. You see a quick -11A spike charge into the battery, then the clearly reactive system kicks in. Rear power falls to 1kW, rear torque falls to -6NM, regen max falls to 3kW, and axle speed goes more constant as your butt dyno feels the regen disappear.


----------



## Madmolecule

Finally got my M2 scanning the car with Savvycan. It took me forever to flash the MRET. I could never getting it working on OSX. It took a few tries with windows, but it finally flashed and then started communicating. Still mastering the Xbee and SuperB, but I am close on both.


----------



## joverdijk

Does anybody has good experience with CANable Pro Isolated USB to CAN Adapter from Protofusion labs? https://canable.io

They are sold out on their own webshop but on Ali there is stock:

https://www.aliexpress.com/item/329...1.0&pvid=5dd4213b-b6d0-4694-bec6-40094a2dfc26

Want to use this with the cable from the german guys (e-mobility-driving-solutions). Just connecting the CANhi CANlo wires, no ground, I suppose?
It looks like it's compatible with can-utils (candump) / socketcan etc

Its for in Model3. Anybody any comments on this, before I decide to buy this (or not?!)


----------



## TaccoBill

I now have both the HRN-CT20T11 adapter and the EVTV adapter, and want to use both the SMT and TorquePro apps to compare their data and capabilities. Is there any reason why I could not connect both of them to the canbus simultaneously by daisy-chaining them.


----------



## TaccoBill

TaccoBill said:


> I now have both the HRN-CT20T11 adapter and the EVTV adapter, and want to use both the SMT and TorquePro apps to compare their data and capabilities. Is there any reason why I could not connect both of them to the canbus simultaneously by daisy-chaining them.


Well I guess I'll answer my own question for anyone interested. I connected both adapters in series to the canbus connector, and then connected separate ODB readers to each adapter. I was able to run both Torque Pro and SMT, and view data by switching between the two apps.

My purpose in doing this was to verify the data output by each method, i.e. the canbus IDs interpreted by SMT with the ODB PIDs used by the EVTV adapter and Torque Pro. I do see that at least one PID is not being converted accurately by the EVTV device. Namely front torque for a dual motor M3. I do, however, prefer the user interface of Torque Pro over that of SMT, while SMT provides much more data. So now I can continue switching between them based on what I want to see.


----------



## JWardell

TaccoBill said:


> Well I guess I'll answer my own question for anyone interested. I connected both adapters in series to the canbus connector, and then connected separate ODB readers to each adapter. I was able to run both Torque Pro and SMT, and view data by switching between the two apps.
> 
> My purpose in doing this was to verify the data output by each method, i.e. the canbus IDs interpreted by SMT with the ODB PIDs used by the EVTV adapter and Torque Pro. I do see that at least one PID is not being converted accurately by the EVTV device. Namely front torque for a dual motor M3. I do, however, prefer the user interface of Torque Pro over that of SMT, while SMT provides much more data. So now I can continue switching between them based on what I want to see.


CAN is a broadcast bus where all devices are connected in parallel, so you can certainly connect multiple devices in parallel simultaneously.
That's one of the messages that changed over the summer, I'm guessing @Collin80 probably didn't update the code with the new changes yet


----------



## joverdijk

I am working on a project analysing CAN-bus logging from my Model3 using my onboard RaspberryPI4.
This to enrich my mysql-database with data that is not present in TeslaFI API.

I'm using JWardell's CANbus ID & Datasheet 
For now (OBDLink LX in order) I'm using cheap ELM327 bluetooth, serial connection on /dev/rfcomm0 and with some own written python-script I read-out the ATMA with some filters/masks

Some simple codes I understand perfectly well, like CAN-ID 318:


Code:


[email protected]:/storage# cat candump2.log | grep 318 | tail -3
318 13 0B 14 00 16 1B 03 81 
318 13 0B 2C 00 16 1B 0D A3 
318 13 0B 2E 00 16 1B 07 9F 
[email protected]:/storage#

1st field after index 318, 13 hex = 19 decimal = year, thats right!
2nd field after 318, 0B hex = 11 decimal = november, thats also right, etc etc

But, with the majority of the field I don't understand the calculations/notations in the sheets, and I cannot get values calculated that make sense and correspond with ScanMyTesla numbers in the app.



Code:


[email protected]:/storage# cat candump2.log | grep 321 | tail -3  
321 DF 65 A7 58 02 58 00 00 <DATA ERROR
321 E0 65 A7 58 02 58 00 00 <DATA ERROR
321 E0 65 A7 58 02 58 00 00 <DATA ERROR
[email protected]:/storage#

Like CoolantTempBatteryInlet, on Data1, in JWardells sheet: "CoolantTempBatteryInlet C u10 SB 0 scale 0.125 offset -40"

E0 hex is 224 dec. What does this "u10 SB0 scale 0.125 offset -40" mean ? 
U10 is unsigned-10 bit i suppose? but, that is just staying 224 then? -40 so its actually 224+40= 264 ? scale 0.125 is that 0.125*264 ? Because that gives 33 degrees? 
That does not seem right at all, both celcius and fahrenheit.

Can somebody explain, or point me to a howto/blog/site that explains calculations (and what it means) like for these 3 examples (the rest I can calculate from the explanation i hope 

-> u8 SB 16 scale 1 offset -100
-> 10 bit unsigned, startbit 10, scale 0.1
-> u14 SB 48 scale 0.128

How to calculate correct values like that from my output ?

Thanks for your time and effort!!


----------



## amund7

joverdijk said:


> E0 hex is 224 dec. What does this "u10 SB0 scale 0.125 offset -40" mean ?
> U10 is unsigned-10 bit i suppose? but, that is just staying 224 then? -40 so its actually 224+40= 264 ? scale 0.125 is that 0.125*264 ? Because that gives 33 degrees?
> That does not seem right at all, both celcius and fahrenheit.


I can give you lots of hints 
- E0 is only 8 bits, you need another 2
- There is also Big Endian and Little Endian, so the question is does the next 2 bits go before or after?
- In any case you need the 2 rightmost bits of 0x65
- offset is -40, so it's not +40, but -40
- I think you multiply scale first, THEN add the offset

As I mentioned to you in PM, maybe an easy start is to convert the whole packet into a string of binary, then do a string cut to get your 10 bits, just get them in the right order. I think the correct order would be byte1-bit76543210, byte0-bit76543210

Then after that, redo it with a 64-bit unsigned integer, and SHR + bitmask to get what you want, that should be pretty fast too!


----------



## joverdijk

amund7 said:


> I can give you lots of hints


I really appreciate the hints, but I'm kind of breaking my head on this... Other approach, I took the 12V battery voltage, because that is a relative stable number and I can check it with your ScanMytesla-app 

I see in my ScanMyTeslaApp that 12V voltage should read 13.9V, took candump right before starting the APP.

12v Batt Voltage V u12 SB 0 scale 0.005444

Candump line:
261 F8 19 DA 04 07 40 20 00 <DATA ERROR

So to get unsigned 12 bits, with startbit 0 
Byte0 is F8 (hex) = 8 bits , leaves me with a need to get another 4 bits out byte1 19 (hex)

byte0 is F8 hex is 11111000 in binary , byte 1 is 19 hex is 00011001 (added leading zeros)
now reverse order it (your quote: I think the correct order would be byte1-bit76543210, byte0-bit76543210)

byte0 11111000 in binary reversed 00011111
byte1 00011001 in binary reversed 10011000

Your quote from other example: "- In any case you need the 2 rightmost bits of 0x65"

so, byte1 reversed is 10011000 but only need the 2 mostrightbits of that, 00, and add byte0 to it in reverse order
that makes 0000011111, which is 31 decimal scale 0.005444 31 * 0,005444 = 0,168764 .... not 13,9 ;-(

Another approach, byte0 reversed 00011111 and 2 rightmostbits of byte1 '00' added to the end of that makes: 0001111100
This number is 124 decimal, scale 0.005444 gives me 124 * 0,005444 = 0,6751056 .... not 13,9 ;-(

I must be doing something wrong.


----------



## Long Ranger

joverdijk said:


> I really appreciate the hints, but I'm kind of breaking my head on this... Other approach, I took the 12V battery voltage, because that is a relative stable number and I can check it with your ScanMytesla-app
> 
> I see in my ScanMyTeslaApp that 12V voltage should read 13.9V, took candump right before starting the APP.
> 
> 12v Batt Voltage V u12 SB 0 scale 0.005444
> 
> Candump line:
> 261 F8 19 DA 04 07 40 20 00 <DATA ERROR
> 
> So to get unsigned 12 bits, with startbit 0
> Byte0 is F8 (hex) = 8 bits , leaves me with a need to get another 4 bits out byte1 19 (hex)
> 
> byte0 is F8 hex is 11111000 in binary , byte 1 is 19 hex is 00011001 (added leading zeros)
> now reverse order it (your quote: I think the correct order would be byte1-bit76543210, byte0-bit76543210)
> 
> byte0 11111000 in binary reversed 00011111
> byte1 00011001 in binary reversed 10011000
> 
> Your quote from other example: "- In any case you need the 2 rightmost bits of 0x65"
> 
> so, byte1 reversed is 10011000 but only need the 2 mostrightbits of that, 00, and add byte0 to it in reverse order
> that makes 0000011111, which is 31 decimal scale 0.005444 31 * 0,005444 = 0,168764 .... not 13,9 ;-(
> 
> Another approach, byte0 reversed 00011111 and 2 rightmostbits of byte1 '00' added to the end of that makes: 0001111100
> This number is 124 decimal, scale 0.005444 gives me 124 * 0,005444 = 0,6751056 .... not 13,9 ;-(
> 
> I must be doing something wrong.


I haven't yet looked into decoding this CAN data, so I'm not the best resource, but it looks to me like you're flipping the bit order when you shouldn't mess with that. Just treat it as a Little Endian byte order.
In your example the first three bytes would be 0xDA19F8. The lower 12 bits are 0x9F8. Multiply by the scaling factor and you get 13.9.


----------



## joverdijk

Long Ranger said:


> I haven't yet looked into decoding this CAN data, so I'm not the best resource, but it looks to me like you're flipping the bit order when you shouldn't mess with that. Just treat it as a Little Endian byte order.
> In your example the first three bytes would be 0xDA19F8. The lower 12 bits are 0x9F8. Multiply by the scaling factor and you get 13.9.


Yeah this seems to work. I was reversing the binary strings due to Amund's comment _" I think the correct order would be byte1-bit76543210, byte0-bit76543210"_

The method you mention seems to work because i want 12 bits, so exactly half of the second byte (4 bits) extra on the first byte (8 bits).
There is some can-data that is for example 10 bits, then this method won't work I suppose


----------



## Long Ranger

joverdijk said:


> Yeah this seems to work. I was reversing the binary strings due to Amund's comment _" I think the correct order would be byte1-bit76543210, byte0-bit76543210"_
> 
> The method you mention seems to work because i want 12 bits, so exactly half of the second byte (4 bits) extra on the first byte (8 bits).
> There is some can-data that is for example 10 bits, then this method won't work I suppose


It should still work for 10 bits, or any number of bits. I think you're just misunderstanding the bit76543210 comment. That implies the usual way a byte is specified, with the most significant bit first, no bit reversal necessary.

In your example, if it specified 10 bits instead of 12, again the first three bytes are 0xDA19F8 (binary 1101 1010 0001 1001 1111 1000), so then the lowest 10 bits would be 01 1111 1000 (0x1F8), as opposed to 1001 1111 1000 (0x9F8) for the lowest 12 bits.


----------



## joverdijk

And we have a winner ;-)










Thanks everybody who responded for all the help so far ;-)


----------



## JWardell

joverdijk said:


> I really appreciate the hints, but I'm kind of breaking my head on this...


This stuff can definitely break your brain!
And depending on what you're implementing it on, code can be completely different. The CanBusAnalyzer code on GitHub is a great example, but more for high-end computer C. Embedded/Arduino code is different because you are instead working with bytes. And doing this stuff in a spreadsheet or database is different again. And of course it all looks broken until you get it perfect.


----------



## joverdijk

JWardell said:


> This stuff can definitely break your brain!
> And depending on what you're implementing it on, code can be completely different. The CanBusAnalyzer code on GitHub is a great example, but more for high-end computer C. Embedded/Arduino code is different because you are instead working with bytes. And doing this stuff in a spreadsheet or database is different again. And of course it all looks broken until you get it perfect.


Yeah for now, I'm mostly interested in adding extra long-term data graphs to my grafana dashboards, to analyse and just for the fun of it.
My OBDLink LX arrives tomorrow, I'm still getting some stuff with cheapo ELM327 now but was already able to extract some battery stuff and plot if over a longer time-frame in nice readable view.










The data in the canbus seems to be all over the place. Not all packetids I see in your file (Jwardell) are present ,some data seems different, and from some other sources I get mixed results too.
As soon as my LX produces more reliable dumps, this most likely will get better and i can, when I get my ancient knowledge from lightyears ago back in action, maybe join 'the search' for the data ;-)


----------



## scottf200

Below is my post on TMC in the SMT thread. This is a poor mans graphing tool (*JWardell*'s above is very cool with addl features. What graphing software?) but I thought it was pretty simply once you learned to use it and added a column to your Excel/CSV with a new time format to your SMT log file. Just thought it may be useful to someone.



XGeek said:


> Thanks for validating that I am not the only one that is red dot-less. Also of note is that when I do start recording the tabs on the top all get grayed out so you can not switch between the different tabs for viewing. I quickly tried UPDLogger and had some performance issues so I have been trying Datplot (DatPlot - From raw data to report ready plots in under five minutes) which I have used before which is well documented, stable and very flexible for making strip charts





XGeek said:


> From what I can tell the time stamps are in milliseconds, not seconds, so you would need to convert the milliseconds to hh:mm:ss.fff which Datplot will understand. In Excel you can convert the milliseconds to the hh:mm:ss.fff format with the following formula: CONCATENATE(TEXT(INT(A2/1000)/86400,"hh:mm:ss"),".",A2-(INT(A2/1000)*1000)) where A2 is the cell that contains the millisecond time stamp. An example of the "how to" conversion can be found at: How to convert milliseconds to time in Excel?. I tried it on my file and it worked fine with Datplot. The thing I like about Datplot is the ability to easily zoom and pan in on the data and once you have things setup the way you like them you can use that template to easily swap new data files in and out with the view that you like. UDPLogger has some nice ease of use as well.


I've been playing more with this DatPlot tool and it is pretty cool and efficient. (Will be visiting my son and we may test to see how the new Hold Mode option looks via SMT and DatPlot data - My X is AP2.0 and no PM motor).

In Excel I do a '*Custom*' format using: '*hh:mm:ss.000*' as mask/template.
=CONCATENATE(TEXT(INT(B2/1000)/86400,"hh:mm:ss"),".",B2-(INT(B2/1000)*1000))*+TIMEVALUE("00:00:00")*

To add an offset and match up with TeslaFI.COM raw data download as needed I do '*+TIMEVALUE("00:00:00")*'. and adjust '*00:00:00*' to match TeslaFI.

As an example, below is to Pane (right click, add pane) and 3 plots on top (right click, add plot curve). Bottom graphic is how you tell DatPlot that you have a header line.










Red is the header line option of '1'. Green below is just the Excel formatted time that DatPlot likes. After import you signify this column will be used for X-axis in the top right corner drop down box.


----------



## All About Jake

Quick question. What's the proper method to install the ODB2 harness passthrough behind the console?

My plan was to open the doors and then shutdown the car from the screen. Then wait about 5 minutes without touching anything or sitting in the front seat. Then, after about 5 minutes to give it time to shutdown, disconnect connectors and install the OBD2 harness.

It isn't necessary to disconnect the 12v battery or anything like that, right?


----------



## JWardell

scottf200 said:


> Below is my post on TMC in the SMT thread. This is a poor mans graphing tool (*JWardell*'s above is very cool with addl features. What graphing software?) but I thought it was pretty simply once you learned to use it and added a column to your Excel/CSV with a new time format to your SMT log file. Just thought it may be useful to someone.
> 
> I've been playing more with this DatPlot tool and it is pretty cool and efficient. (Will be visiting my son and we may test to see how the new Hold Mode option looks via SMT and DatPlot data - My X is AP2.0 and no PM motor).
> 
> In Excel I do a '*Custom*' format using: '*hh:mm:ss.000*' as mask/template.
> =CONCATENATE(TEXT(INT(B2/1000)/86400,"hh:mm:ss"),".",B2-(INT(B2/1000)*1000))*+TIMEVALUE("00:00:00")*
> 
> To add an offset and match up with TeslaFI.COM raw data download as needed I do '*+TIMEVALUE("00:00:00")*'. and adjust '*00:00:00*' to match TeslaFI.
> 
> As an example, below is to Pane (right click, add pane) and 3 plots on top (right click, add plot curve). Bottom graphic is how you tell DatPlot that you have a header line.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Red is the header line option of '1'. Green below is just the Excel formatted time that DatPlot likes. After import you signify this column will be used for X-axis in the top right corner drop down box.


I started things off at the beginning with Excel. The problem is it is next to impossible to get to to decode numbers of various bit sizes and signs, and it very quickly comes to a screeching halt with this much data. Probably should have used something more powerful like Matlab. Not familiar with DatPlot.



All About Jake said:


> Quick question. What's the proper method to install the ODB2 harness passthrough behind the console?
> 
> My plan was to open the doors and then shutdown the car from the screen. Then wait about 5 minutes without touching anything or sitting in the front seat. Then, after about 5 minutes to give it time to shutdown, disconnect connectors and install the OBD2 harness.
> 
> It isn't necessary to disconnect the 12v battery or anything like that, right?


I was also super worried a cautious like this at the beginning as well. The good news is you don't have to be. Just be sure you are parked and not in drive when you plug and unplug things.


----------



## amund7

joverdijk said:


> Yeah this seems to work. I was reversing the binary strings due to Amund's comment _" I think the correct order would be byte1-bit76543210, byte0-bit76543210"_


Sorry if that was confusing. Bit 0, first bit, least significant bit... is to the right. The ordering of the bytes however are not always following the same logic. And this IS confusing.
I could have just pasted my code, but wanted to inspire you to write your own. Hope that worked as intended


----------



## Madmolecule

All About Jake said:


> Quick question. What's the proper method to install the ODB2 harness passthrough behind the console?
> 
> My plan was to open the doors and then shutdown the car from the screen. Then wait about 5 minutes without touching anything or sitting in the front seat. Then, after about 5 minutes to give it time to shutdown, disconnect connectors and install the OBD2 harness.
> 
> It isn't necessary to disconnect the 12v battery or anything like that, right?


I did not disconnect the battery. A very easy install, maybe 15 minutes.

Harness Install


----------



## cyntrex

Onyx said:


> It could be. I don't have any actual plans to do this myself at this time, but it'll all be open source, and it should be easy-ish to build this. I'll probably end up releasing this thing in components, tentative repos are:
> 
> onyx-m2-firmware: the M2 and SuperB firmwares you need to flash
> onyx-m2-server: the Nodejs server you need to talk to the M2 through web sockets
> onyx-m2-client: the Javascript libary that does the heavy lifting with the server
> 
> And the very last repo will be onyx-m2-ui, which will be the actual user interface you see in my videos. So with this segmentation, it should be really easy to take this thing is lots of cool directions. You wouldn't need to use my ui at all, you could build your own without having to worry about any of the underlying details (at least that's the theory). Let me know what you think.
> 
> Do you have a picture of what the rooted thermal screen looks like (or even better, a video)? I'd use it as inspiration. And yeah, I'll definitively be building more views moving forward.
> 
> My current backlog of ideas is:
> 1) A vbox like 0-100 chrono
> 2) A charge graph like you're charging
> 3) An animated view of how power is being used (I've been looking at the e-fuse data, and it's amazing how it shows precise energy use of every single electrical gizmo in the car).
> 4) A trip view that shows multiple things at once (including a trace on a map)
> 5) A "track view" with everything you'd want to see at the track (maybe taking some inspiration from the excellent Harry's GPS Laptimer)
> 
> So much fun ahead, if I can only get the connection/transmission/reliability foundations stuff out of the way. (Using the SuperB is going to be so good though - no more phone relay and super fast and reliable link.)
> 
> Indeed, that sounds reasonable. I'm not 100% sure what I'm going to be doing with this. One thing I really want is to have trips recorded and sync'ed when I park in my garage, but these could be separate files from the "pure can dumps" and managed differently. So much to do...


Hi, I've been lurking around here for a while now.
Right now I'm working on a websocket-based interfaced running on a Raspberry Pi, sending real-time data to the tesla browser, which is acting as the client.
Do you have any github repo you could add me to, or do you plan on releasing your repos anytime soon? Would really help me out seeing your approach.

Cheers,

cyntrex


----------



## joverdijk

My OBDLink LX has arrived, so I've re-written my code.
Now python and using ST cmdset filtering, no more buffer full ;-)


----------



## michi84

I think i have figured out some ways how we can calculate mechanical power from the know electrical inverter power and torque readings:

Let' start with the rear drive unit today, ID 0x266. Basis is a full throttle run from 0 to nearly 130 km/h at some 40% SOC (sorry, no big peak power figures here). The chosen datapoint is 85 km/h.

1) On ID 0x266, we get the following values:
Power: 185,5 kW
Dissipation: 25,6 kW (using the 0.125 scaling, -0.5 offset as per the DBC, but with starting bit 24 since there where some changes in the firmware (old SB was 8)
This would give us a mechanical power (electrical power - dissipation) of 159,9 kW, or 86,2% efficiency.

I believe dissipation would include both motor efficiency losses plus gearbox losses, so this power value would be the power going to the wheels / output shaft of the drive unit. At an earlier run (just SMT 0-100 with power data, no can dump) i get 224 kW peak output of the rear motor, which would then be 193 kW mech power. A look at the model 3 datasheet in the recent owners manual (30th October) says 180 kW peak power for the rear motor of the non performance AWD, so we are in the right ballpark. I am not sure if this already includes the 5% power update (would be 189 kW then). 

2) Another way would be to use axle torque and rpm, again for the rear motor (ID 0x108):
Rear axle rpm: 695,8 rpm
Rear axle torque: 2336 Nm
Power= (axle rpm x torque) / 9549 = 170,2 kW
The efficiency would be 91,76 % percent here. I assume this might be motor power without drivetrain losses.

3) Using the torque values from 0x1D8 seems not so straightforward, since we have no direct motor rpm readout. Since the data is recorded in serial fashion, data coming from different IDs will not be from the exact same time, so depending on the lag the calculations will be off.
Rear motor rpm (assuming 9:1 ratio): 6262,2 rpm
Rear torque: 247 Nm
Power: 161,98 kW
Efficiency: 87,3 %

Keep in mind, this is a single data point, i will look at more point tomorrow. What i can take from that is that method 1 gives the most conservative figure, method 2 seems to miss out drivetrain losses, and method 3 matches 1 closely, but might be troublesome because of lag between packets from different IDs. I would label method 1 as "drive unit mech power" and method 2 as "motor mech power".

I think i am also close to figuring out heat power with the new firmware.


----------



## scottf200

JWardell said:


> I started things off at the beginning with Excel. The problem is it is next to impossible to get to to decode numbers of various bit sizes and signs, and it very quickly comes to a screeching halt with this much data. Probably should have used something more powerful like Matlab. Not familiar with DatPlot.


Thanks. Is the below from Matlab? The 'State Tracker' is a very cool feature and you demonstrated it well.


----------



## JWardell

scottf200 said:


> Thanks. Is the below from Matlab? The 'State Tracker' is a very cool feature and you demonstrated it well.


No, it's CANoe.
And I agree, I would love CBA and SavvyCAN to graph states like that...


----------



## joverdijk

On my Model3 AWD, i do not seem to see any data on CanID 376 (STFAP 0376,07FF), looking for stator, invertor-temps etc.
I do have values on 372 and 379, but not 376, logging for days now. Has this been moved? Running 2019.36.2.1


----------



## michi84

Dissipation might need an offset: it is 5,75 kW at idle and low power, which seems to high. Best method to calculate power for now seems to be from axle torque and rpm, and since i read that tesla claims up to 93% efficiency for their model 3 drive unit, my 91% at full power to not seem so wrong after all.


----------



## Rush

@amund7 - WOW, I just put the MDS connector and OBD reader in new Standard +. Had a few problems, my tablet keep giving me 'read failed, socket might closed or timeout,read ret:-1' for about 10 min, I kept pushing retry... just the red led was lit AND finally the green blinking came on and all the info appeared. Massive amounts of data... and now I have to learn what are the parameters that I want to keep on one screen. I bought a 7" dragontouch tablet just to view the info and I'm afraid it might not be big enough. My use is just personal, to see how the numbers change, it is just so intense. I guess there is a tutorial on how to use the SMT.


----------



## JWardell

joverdijk said:


> On my Model3 AWD, i do not seem to see any data on CanID 376 (STFAP 0376,07FF), looking for stator, invertor-temps etc.
> I do have values on 372 and 379, but not 376, logging for days now. Has this been moved? Running 2019.36.2.1


376 is front motor temps, so it won't be present if you have RWD


----------



## joverdijk

JWardell said:


> 376 is front motor temps, so it won't be present if you have RWD


I have AWD .. But nevermind.. it only gives values when driving. (DOH!)


----------



## michi84

I think i have figured out heat power! Dissipation offset still not sure.

ID266 RearInverterPower:

SG_ RearPower266 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X 
SG_ RearHeatPower : 40|[email protected]+ (0.08,0) [0|255] "kW" X 
SG_ RearPowerDissipation : 24|[email protected]+ (0.125,-055) [0|255] "kW" X
SG_ RearHeatPowerOptimal : 56|[email protected]+ (0.08,0) [0|255] "kW" X
SG_ RearHeatPowerMax : 48|[email protected]+ (0.08,0) [0|255.5] "kW" X

ID2E5 FrontInverter Power:

SG_ FrontPower : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
SG_ FrontHeatPower : 40|[email protected]+ (0.08,0) [0|31875] "kW"
SG_ FrontPowerDissipation : 24|[email protected]+ (0.125,-0.5) [-0.5|31.375] "kW" X
SG_ FrontHeatPowerOptimal : 56|[email protected]+ (0.08,0) [0|31875] "kW" X
SG_ FrontHeatPowerMax : 48|[email protected]+ (0.08,0) [0|31875] "kW" X

Unless we know the offset for dissipation for sure, we should calculate mechanical power from axle torque and axle rpm, since this seems to be the most straightforward way to do it. We could then calculate electrical to mechanical power efficiency.


----------



## bwilson4web

Having a few problems installing the CAN-to-OBD kit:

*POWER OFF*

I tried this sitting in the rear seat with all windows up and doors closed:

Sentry mode off; mobile access off; and switch car 'Power Off'
Waited 8 minutes and never heard the relay CLAKKK
Since my goal is to insert the CAN-to-OBD adapter, I prefer having all power off. Have I missed something?

In the morning, I'll start with a double-******+brake reset. Then I'll try the POWER OFF button under security. But how do I exit the driver door and get in the back to handle the connectors without having that enabling POWER. IMHO, enabling POWER should only happen by pushing the brake, not opening a door.

*OPEN CONNECTORS*

Here is the connector and latch:








My instructions are to push the locking tab which I assume is the tab on the left and gently rock the male plug on the left from the female on the right. However, I'm not having a lot of luck. I'll try again in the morning using some needle nose, vice grips.

Personally, it looks like the small bar on the left should be raised up to allow the male connector to wiggle out. I'll take a closer look in the morning.

Any suggestions?

*ROUTING/MOUNTING OBD*

Looking at the access area, have folks left one side of the cover off so the OBD plug wires are outside of the access area?








There appears to be metal shell possibly space for the OBD but that could block the Bluetooth signal.

I'll try to make a video showing step-by-step what it takes. But I thought first to ask the community.

Bob Wilson


----------



## joverdijk

bwilson4web said:


> Having a few problems installing the CAN-to-OBD kit:
> 
> *POWER OFF*
> 
> I tried this sitting in the rear seat with all windows up and doors closed:
> 
> Sentry mode off; mobile access off; and switch car 'Power Off'
> Waited 8 minutes and never heard the relay CLAKKK
> Since my goal is to insert the CAN-to-OBD adapter, I prefer having all power off. Have I missed something?
> 
> Bob Wilson


Hi. I did not have much trouble with this. Disable all apps/services that can remotely access car (teslafi, teslaspy, apps/widgets on your phone (best to set flightmode) , then Sentry off, mobile access off, logout of the teslaaccount (asks password). Open all doors and then from standing NEXT to the car, reach in, rest your 1 hand on the steering-wheel and with other hand on screen to 'service' and select powerdown. If you sit/lean on the driver-chair it will notice you ;-)
Then wait indeed max 8 minutes but most likely the relay clakk will come within 2-3-4 minutes already... Dont sit in front, dont open any doors, just crawl in the back and disconnect the can-cable and put your wireharnass in between.
I think i remember pushing IN the little strip in the middle to pull-out connector from female side, not sure, did not give any problems.
As soon as you reconnect the cable with the wireharnass in between, the car will wake-up (WITH CLAKKK  .

detailed video here:
In 2019+ model the connectors are lightblue (in video below its still white).


----------



## amund7

Don't worry too much about the clack, or mobile access, apps etc. I have installed in several cars, never got a clack, but waited for pumps and fans to become quiet. Opened 1 or 2 rear doors first. If you open or close a door, the car wakes up immediately, that's why we open them first. No errors.


----------



## scottf200

scottf200 said:


> XGeek said:
> 
> 
> 
> ... In Excel you can convert the milliseconds to the hh:mm:ss.fff format with the following formula: CONCATENATE(TEXT(INT(A2/1000)/86400,"hh:mm:ss"),".",A2-(INT(A2/1000)*1000)) where A2 is the cell that contains the millisecond time stamp. ...
> 
> 
> 
> ...
> I've been playing more with this DatPlot tool and it is pretty cool and efficient. (Will be visiting my son and we may test to see how the new Hold Mode option looks via SMT and DatPlot data - My X is AP2.0 and no PM motor).
> 
> In Excel I do a '*Custom*' format using: '*hh:mm:ss.000*' as mask/template.
> =CONCATENATE(TEXT(INT(B2/1000)/86400,"hh:mm:ss"),".",B2-(INT(B2/1000)*1000))
Click to expand...

That formula had a flaw/bug where it was suppressing leading zeros. That made the graph line jump around. Use the blue rectangle as a substitute for isolating the milliseconds part. Red 0/zeros was just a comparison of Col B and Col C showing when it was wroong for my example below.


----------



## Rush

I'm having a problem with my OBDII, I get the error
read failed, socket might closed or timeout, read ret:-1
The red led keeps on blinking. When the green led comes on, which is very seldom, the same error message appears. I'm using a Dragontouch 7" tablet Y88X_PRO. I know the bluetooth works since I've been able to pair it with others, and in the settings it shows bluetooth paired with OBDII. It really only worked 2x and that was after lots of waiting for the connection to got thru. So I guess the Y88x and OBDII don't like each other.
So I got out my old Galaxy S4, charged it up and paired it with the OBDII, it works fine... but the screen is small so I just may have to get another tablet


----------



## Juggernaut

Rush said:


> I'm having a problem with my OBDII, I get the error
> read failed, socket might closed or timeout, read ret:-1
> The red led keeps on blinking. When the green led comes on, which is very seldom, the same error message appears. I'm using a Dragontouch 7" tablet Y88X_PRO. I know the bluetooth works since I've been able to pair it with others, and in the settings it shows bluetooth paired with OBDII. It really only worked 2x and that was after lots of waiting for the connection to got thru. So I guess the Y88x and OBDII don't like each other.
> So I got out my old Galaxy S4, charged it up and paired it with the OBDII, it works fine... but the screen is small so I just may have to get another tablet


That has definitely something to do with the bluetooth libraries installed on the android devices.
Which android OS is running on the device (an actual one?)

I have been working during the tests a the 24h race track on that connection failure as well.
we have purchased the HUAWEI P30 pro (many users had pairing difficulties with that device too) to make forensics
for that error situation on the smartphone
current solutions are looking like that ...

Disconnect are already paired BT devices.
Restart the tablet/phone.
Start the pairing with the handsfree of the tesla (that will force PIN confirmation for a successful pairing).
right after having paired the handsfree start another search of potential bluetooth devices (give it appr. 2 minutes
therefore)
than pick the OBDII as the device and it should bring up the dialog windows to type in the PIN code 1234.
that will lead to a successful pairing.
Than start SMT and select the right BT
device from the (quite short) list of devices.

That works in nearly 90% of the cases known to me.

If not we will replace the OBD towards another one we have for "prima ballerina behaving" android devices ;-).
Therefore i would recommend to contact us directly ...
we honestly don't have time to check the forum entries on daily basis.

BTW: we have tested the ecoGP HUD implementation of SMT inside the M3 on the OSCHERSLEBEN race track http://ecograndprix.com/.
Out of 6 drivers in our team only 3 had tesla driving experience ... the 3 others felt really better with having at night something
behind their steering wheel in the left area of window ;-) We ended up 2nd M3 ... winning team was driving/22kW charging a US-Model3
with Chademo ... more stable than the 6 others CCS charging european Model3s which had only 18kW charging speed.

a detailed Model3 pitlane diary will be shortly online at the SMT facebook page.

PS2: ... it is not a joke ... the million kilometres car drives in reality +500km/day


----------



## Rush

Juggernaut said:


> That has definitely something to do with the bluetooth libraries installed on the android devices.
> Which android OS is running on the device (an actual one?)


The Y88X has Android 9.0 Pie installed. It worked briefly 2 times and then nothing, except the error code. I tried about 20 times to pair it. In any case I've sent it back and will be getting a Samsung


----------



## JWardell

bwilson4web said:


> I am thinking we might want to have a separate thread for sharing data studies from this thread which has been more of a 'tool maker'.


Who are you calling a tool?? 

Honestly I would love all these windows tools on linux, if that's your thing. 
I still intend to master PyQT which might let me build all the stuff I can imagine. But I am very talented at procrastinating any high level coding.


----------



## bwilson4web

Just the obscure elements of big-endian vs little-endian is fascinating to some of us but not terribly useful about how to effectively use our Teslas. <grins>

BTW, I've always figured being a 'tool maker' an honorable profession unless they are making 'coal-rolling' tools.

Bob Wilson


----------



## Madmolecule

When I unplugged my Macchina-M2 a couple nights ago I received this error message. It did go away when I exited and reentered. Is there a proper way to disconnect.? I will need to do this many more times as I am still having trouble getting the data through wifi (superB) or cellular (Xbee) in Savvy Can. A turtle icon is pretty scary in a Tesla. I thought I was being punished for my aggressive driving.


----------



## JWardell

Madmolecule said:


> When I unplugged my Macchina-M2 a couple nights ago I received this error message. It did go away when I exited and reentered. Is there a proper way to disconnect.? I will need to do this many more times as I am still having trouble getting the data through wifi (superB) or cellular (Xbee) in Savvy Can. A turtle icon is pretty scary in a Tesla. I thought I was being punished for my aggressive driving.
> 
> View attachment 30947


I ran the gamut on this a year ago, first carefully tapping only when the car was off and slowly getting more courageous. I had my share of times where I shorted the Canbus as well.
For the most part there is no reason to do any turning off, just be sure you are parked when plugging and unplugging. Very rarely (but as you just discovered) there is a slight chance you get a can error, and it might pop an error up. It usually disappears when you shift into drive and everything is reinitialized. 
But I don't want to find out what happens if I do the same while driving. Which is why I rarely drive with my hardwired stuff there, and do not want to release anything to the public that sends the CAN around the cabin as I have.


----------



## bwilson4web

Just sharing with @amund7 and the community. My initial data recording resulted a pair of files per session:









Some of the CSV values were out of range and there were data gaps suggesting the Galaxy/OBD ran behind.
The TXT files have a lot of volume but it isn't clear how to use them. They are pretty large which on a small storage device might lead to other problems. Perhaps this might be documented and an option to disable these debug logs?
There were some problems with rogue data points (aka., below 0 C on a 5-8 C day) but Amund suggested using the "New" tab and populating with just the data points of interest as opposed to modification of the TEMP tab. Will give it a try.

I have a WiFi, OBD dongle for my BMW i3-REx. According to Samsung, the SM-T510 Bluetooth is "Bluetooth v5.0 (LE up to 2 Mbps)" and WiFi is a lot faster. This may avoid under-runs with the Bluetooth dongle. I'll give it a try.

I found trying to open the text log files didn't work on the Android. But unmounting and moving the SD card to my Macintosh gave me full access. So I've moved SCAN MY TESLA to the SD card and anticipate no further problems. Eventually I'll work on a virtual disk over WiFi between the Mac and Galaxy.

'Unlock at location', an Android security feature, is set for the house and driveway so I won't have to type in a password. I'll eventually enable it for my OBD adapter so no password will be needed in the car.

The App "AndrOpen Office" bricked itself into a black screen so it is gone. I don't anticipate doing much data analysis on the Galaxy since my Mac has all the tools, including Linux/Unix, needed.

Bob Wilson


----------



## pavankp

I have a DIY HUD in my car that I built early this year. It reads CAN messages with IDs 0x257, 0x118, 0x318, 0x292, 0x352 and 0x3F1, using EVTV's CAN monitor. At that time, this was the only easily available item I could buy to read CAN messages, so I spent $300 on it.

I convinced my wife to buy a Tesla Model 3 and she got her car a few weeks ago. Now she wants a HUD in her car, just like I have in mine. I saw that there are other, much cheaper options to get CAN data out of the car, for around $30. I got this one from GPS Tracking America. Unlike the EVTV box that has a USB type B connector that I directly plug into a Raspberry Pi, this one has an OBD2 connector. Now I have to figure out which OBD2-to-USB connector I should buy so I can read the CAN messages over USB. I looked at several ELM327 USB devices on Amazon, but I am unable to tell whether they will work for this use case. I want to read not just standard OBD2 data like speed, but also Tesla-specific data like drive state (e.g. "charging") and battery state-of-charge. Does anyone here have recommendations for which OBD2 adapters will work for this? Any hints on how to read the CAN data for specific IDs over USB from Raspberry Pi / Jetson Nano would be much appreciated!


----------



## Rush

You can use an app (that only works on Android) called Scan My Tesla (from Play Store)






This is an example of the info that can be displayed on an 8" tablet. The OBD you should get is OBDLink LX (Amazon - $30)


----------



## scottf200

pavankp said:


> I have a DIY HUD in my car that I built early this year. It reads CAN messages with IDs 0x257, 0x118, 0x318, 0x292, 0x352 and 0x3F1, using EVTV's CAN monitor. At that time, this was the only easily available item I could buy to read CAN messages, so I spent $300 on it.
> 
> I convinced my wife to buy a Tesla Model 3 and she got her car a few weeks ago. Now she wants a HUD in her car, just like I have in mine. I saw that there are other, much cheaper options to get CAN data out of the car, for around $30. I got this one from GPS Tracking America. Unlike the EVTV box that has a USB type B connector that I directly plug into a Raspberry Pi, this one has an OBD2 connector. Now I have to figure out which OBD2-to-USB connector I should buy so I can read the CAN messages over USB. I looked at several ELM327 USB devices on Amazon, but I am unable to tell whether they will work for this use case. I want to read not just standard OBD2 data like speed, but also Tesla-specific data like drive state (e.g. "charging") and battery state-of-charge. Does anyone here have recommendations for which OBD2 adapters will work for this? Any hints on how to read the CAN data for specific IDs over USB from Raspberry Pi / Jetson Nano would be much appreciated!





Rush said:


> You can use an app (that only works on Android) called Scan My Tesla (from Play Store) This is an example of the info that can be displayed on an 8" tablet. The OBD you should get is OBDLink LX (Amazon - $30)


Scan My Tesla also recently added a HUD menu option. Example in my post in this thread: https://teslaownersonline.com/threa...-discussion-feedback.14873/page-2#post-266465
However we tried it in my sons TM3 and the double vision display shows up as are in the bottom two from my display. I don't know how @pavankp got is looking good. Perhaps show some pictures please.

UPDATE: OK, I found his pictures here: HUD pictures -- he is not displaying on the windshield!


----------



## pavankp

@*scottf200 *Yes, I experimented with showing on the windshield, including with a reflective film, but didn't like the results. That is why I bought a beamsplitter mirror for my setup. With this, you don't see any double vision, neither in daylight nor at night.


----------



## JWardell

pavankp said:


> I have a DIY HUD in my car that I built early this year. It reads CAN messages with IDs 0x257, 0x118, 0x318, 0x292, 0x352 and 0x3F1, using EVTV's CAN monitor. At that time, this was the only easily available item I could buy to read CAN messages, so I spent $300 on it.
> 
> I convinced my wife to buy a Tesla Model 3 and she got her car a few weeks ago. Now she wants a HUD in her car, just like I have in mine. I saw that there are other, much cheaper options to get CAN data out of the car, for around $30. I got this one from GPS Tracking America. Unlike the EVTV box that has a USB type B connector that I directly plug into a Raspberry Pi, this one has an OBD2 connector. Now I have to figure out which OBD2-to-USB connector I should buy so I can read the CAN messages over USB. I looked at several ELM327 USB devices on Amazon, but I am unable to tell whether they will work for this use case. I want to read not just standard OBD2 data like speed, but also Tesla-specific data like drive state (e.g. "charging") and battery state-of-charge. Does anyone here have recommendations for which OBD2 adapters will work for this? Any hints on how to read the CAN data for specific IDs over USB from Raspberry Pi / Jetson Nano would be much appreciated!


Such an awesome project!!
You may not realize that the EVTV box is a embedded processor that is decoding the CAN and then processing it to a separate serial bus. I'm not sure there is another CAN-to-serial converter that you can drop in its place (I assume that supports GVRET). 
There are plenty of CAN to USB devices out there, but you probably have to then integrate whatever libraries they have into your code.
The OBD harnesses do not convert the data to OBD, they just provide an OBD connector with CAN on the CAN pins, but OBD pins are not populated. Only an OBD device that can read CAN will work. And that's how the scan my Tesla app works.
I do wish there was an easier way to talk to the OBD to bluetooth devices from something other than a smartphone. I certainly would prefer the wireless connection. Maybe possible with a Pi, but with Arduino I have only seen bluetooth libraries for slaves not masters. That's been the holdup for my own hardware.


----------



## amund7

JWardell said:


> .
> I do wish there was an easier way to talk to the OBD to bluetooth devices from something other than a smartphone. I certainly would prefer the wireless connection. Maybe possible with a Pi, but with Arduino I have only seen bluetooth libraries for slaves not masters. That's been the holdup for my own hardware.


Not sure if you realize that a Windows PC paired to for instance an Obdlink LX will get a COM port that you can read and write with a few lines of C# code, use PUTTY on, etc. I am sure it's just as easy with a Linux machine, or a Raspberry too. (Only trouble is the COM port number changes numbers every now and then when you reconnect) But maybe you meant Arduino, not sure how that would go.

Edit: Sorry, I didn't read that through properly. Have no experience with Arduino for Bluetooth in this way.


----------



## michi84

Anyone with 2019.40.2.1 here?

There is a report on a german forum that this update might have messed up some signals (HVAC, batt temp targets) in ScanMyTesla. Values are jumping and showing implausible data.


----------



## michi84

I think i just fixed the charger and DCDC temperature (PCS thermal status). I have observed that the temps for charger a and b seemed plausible, and charger C, DCDC and ambient (this means PCS ambient temp, not outside temp!) were jumping all over the place and made no sense. I then noticed that the first tow were exactly 11 bits apart, while the third started at bit 24, which seemed odd (why would there be a 2 bit gap?).

So i adjusted the starting bits and got plausible values with the following:

BO_ 676 PCS_thermalStatus: 8 ETH
SG_ PCS_ambientTemp: 44|[email protected] (0.1,40) [0|0] "C" X
SG_ PCS_chgPhATemp: 0|[email protected] (0.1,40) [0|0] "C" X
SG_ PCS_chgPhBTemp: 11|[email protected] (0.1,40) [0|0] "C" X
SG_ PCS_chgPhCTemp: 22|[email protected] (0.1,40) [0|0] "C" X
SG_ PCS_dcdcTemp: 33|[email protected] (0.1,40) [0|0] "C" X

I strongly suspect something similar is going on on VCFRONT where some values also jump around without making sense.

This is for firmware 2019.36 though. Update to 2019.40.2.1 is on hold for me, i have not got a notification yet and as a safety measure i have disabled the home network in the car. It will stay that way until i get my hands on a CAN dump from a car with 2019.40.2.1 to see for myself if anything important has changed in a not easily fixable way.


----------



## michi84

Just got a log. 

VCRIGHT logging 1hz seems messed up. Duct temps, PTC watts no longer make sense, some temp probes also. Looks a bit like what happened to VCFRONT in spring. I hate it when those multiplexed signals get mixed up, these are the hardest to get right again.


----------



## bernie

michi84 said:


> Anyone with 2019.40.2.1 here?
> 
> There is a report on a german forum that this update might have messed up some signals (HVAC, batt temp targets) in ScanMyTesla. Values are jumping and showing implausible data.


I've downloaded and installed 2019.40.2.1 SF California - it seems to be running fine for me. Wipers are much better now.


----------



## michi84

In the log from germany, batt target temps fluctuate between plausble values and some values that dont make sense. Can you check what you get for duct temp and PTC heater readings (try full heat).

Can you record a CAN dump with ScanMyTesla (car parked, heat on/off, A/C on/off, and a short drive)?


----------



## pavankp

JWardell said:


> Such an awesome project!!
> You may not realize that the EVTV box is a embedded processor that is decoding the CAN and then processing it to a separate serial bus. I'm not sure there is another CAN-to-serial converter that you can drop in its place (I assume that supports GVRET).
> There are plenty of CAN to USB devices out there, but you probably have to then integrate whatever libraries they have into your code.
> The OBD harnesses do not convert the data to OBD, they just provide an OBD connector with CAN on the CAN pins, but OBD pins are not populated. Only an OBD device that can read CAN will work. And that's how the scan my Tesla app works.
> I do wish there was an easier way to talk to the OBD to bluetooth devices from something other than a smartphone. I certainly would prefer the wireless connection. Maybe possible with a Pi, but with Arduino I have only seen bluetooth libraries for slaves not masters. That's been the holdup for my own hardware.


Thank you! I am completely new to OBD2. I never customized my previous cars, but got into it with Tesla.

Based on what you say, it sounds rather complicated to try to accomplish this with a OBD-to-USB connector. If I use an OBD-to-Bluetooth device, will the speed be a constraint? I want my HUD UI displayed speed to match the speed shown on the center screen, after processing the data coming in over Bluetooth to the Pi. If I go this route, I need to figure out how to read the data coming to the Pi over Bluetooth, something I haven't done before.


----------



## pavankp

amund7 said:


> Not sure if you realize that a Windows PC paired to for instance an Obdlink LX will get a COM port that you can read and write with a few lines of C# code, use PUTTY on, etc. I am sure it's just as easy with a Linux machine, or a Raspberry too. (Only trouble is the COM port number changes numbers every now and then when you reconnect)


So if I use OBDLink LX with a Pi, can I read the CAN data using that COM as a regular serial port? Do you know if Bluetooth speed may a constraint for data transfer compared to USB? Right now I read the CAN messages as they come in, parse them and store usable values, and then refresh the UI 20 times a second, so the speed displayed by my HUD UI matches the center console display. I can't figure out whether I will be able to manage that over Bluetooth.


----------



## JWardell

amund7 said:


> Not sure if you realize that a Windows PC paired to for instance an Obdlink LX will get a COM port that you can read and write with a few lines of C# code, use PUTTY on, etc. I am sure it's just as easy with a Linux machine, or a Raspberry too. (Only trouble is the COM port number changes numbers every now and then when you reconnect) But maybe you meant Arduino, not sure how that would go.
> 
> Edit: Sorry, I didn't read that through properly. Have no experience with Arduino for Bluetooth in this way.


Yeah windows is going the opposite direction for me 



michi84 said:


> I think i just fixed the charger and DCDC temperature (PCS thermal status). I have observed that the temps for charger a and b seemed plausible, and charger C, DCDC and ambient (this means PCS ambient temp, not outside temp!) were jumping all over the place and made no sense. I then noticed that the first tow were exactly 11 bits apart, while the third started at bit 24, which seemed odd (why would there be a 2 bit gap?).
> 
> So i adjusted the starting bits and got plausible values with the following:
> 
> BO_ 676 PCS_thermalStatus: 8 ETH
> SG_ PCS_ambientTemp: 44|[email protected] (0.1,40) [0|0] "C" X
> SG_ PCS_chgPhATemp: 0|[email protected] (0.1,40) [0|0] "C" X
> SG_ PCS_chgPhBTemp: 11|[email protected] (0.1,40) [0|0] "C" X
> SG_ PCS_chgPhCTemp: 22|[email protected] (0.1,40) [0|0] "C" X
> SG_ PCS_dcdcTemp: 33|[email protected] (0.1,40) [0|0] "C" X
> 
> I strongly suspect something similar is going on on VCFRONT where some values also jump around without making sense.
> 
> This is for firmware 2019.36 though. Update to 2019.40.2.1 is on hold for me, i have not got a notification yet and as a safety measure i have disabled the home network in the car. It will stay that way until i get my hands on a CAN dump from a car with 2019.40.2.1 to see for myself if anything important has changed in a not easily fixable way.


Nice work. To clarify this is the PCS charger under the back seat, not any connectors outside of the car. I will have to check these out when I get a chance.



pavankp said:


> Thank you! I am completely new to OBD2. I never customized my previous cars, but got into it with Tesla.
> 
> Based on what you say, it sounds rather complicated to try to accomplish this with a OBD-to-USB connector. If I use an OBD-to-Bluetooth device, will the speed be a constraint? I want my HUD UI displayed speed to match the speed shown on the center screen, after processing the data coming in over Bluetooth to the Pi. If I go this route, I need to figure out how to read the data coming to the Pi over Bluetooth, something I haven't done before.


Bluetooth probably doesn't have enough bandwidth to send ALL signals and data, but if you are only sending those that you are interested in, then it is plenty fast. You will get full response rate for speed, probably faster than the main display.


----------



## michi84

@JWardell 
Is there any CAN analysis software where you can highlight some bits (like in the flow view in SavvyCAN) and have the software display the resulting value in DEC, or, even better, with a formula applied?

Otherwise, i might try some kind manual brute force method for some signals on VCFRONT (shift starting bit in DBC one by one until i get a value that makes sense), perhaps there is a pattern to it.

In the log from germany, the position readings of the 5-way-valve seem odd (target 100 instead of 135, actual value 86 instead of 134,25). I have requested another recording with series/parallel shift to investigate further. I woudl ahte to loose this signal now, where i have got Onyx M2 software up and running, because that value will be instrumental for my planned thermal display like in the Model S to visualize the different cooling system configurations:

1) Valve 134/135°: series, 100% radiator bypass
2) Valve 95°: series, no radiator bypass
3) Valve 45°: parallel, 100% radiator bybass
4) Valve 5,25: parallel, no radiator bypass

On 2019.40.2.1, VCFRONT logging 1hz now has a 7th multiplexer index value, i suspect some further signales were moved over there.


----------



## michi84

2019.40.2.1 is all messed up on VCFRONT logging 10hz and 1hz. New multiplexers on 1hz, and some changes on 10hz. See attached files (not from me, they are from germany). Any help figuring this out would be appreciated.

Is disabling Wifi enough to prevent an unwanted update? Unless the valve position is solved, i am not eager to do any update since this woudl seriosly jeopardize my planned display. Also, any CAN dumps with new software and series/parallel shifting would be fine.


----------



## JWardell

michi84 said:


> @JWardell
> Is there any CAN analysis software where you can highlight some bits (like in the flow view in SavvyCAN) and have the software display the resulting value in DEC, or, even better, with a formula applied?
> 
> Otherwise, i might try some kind manual brute force method for some signals on VCFRONT (shift starting bit in DBC one by one until i get a value that makes sense), perhaps there is a pattern to it.
> 
> In the log from germany, the position readings of the 5-way-valve seem odd (target 100 instead of 135, actual value 86 instead of 134,25). I have requested another recording with series/parallel shift to investigate further. I woudl ahte to loose this signal now, where i have got Onyx M2 software up and running, because that value will be instrumental for my planned thermal display like in the Model S to visualize the different cooling system configurations:
> 
> 1) Valve 134/135°: series, 100% radiator bypass
> 2) Valve 95°: series, no radiator bypass
> 3) Valve 45°: parallel, 100% radiator bybass
> 4) Valve 5,25: parallel, no radiator bypass
> 
> On 2019.40.2.1, VCFRONT logging 1hz now has a 7th multiplexer index value, i suspect some further signales were moved over there.


Not really. The Savvycan flow view is great, previously I used to just scroll through a huge text file of just that signal and watch for changes. Either way it was up to my brain to see patterns in the matrix (which actually works fairly well...)
Other than that, it takes some coding in your choice platform, or stab and repeat with DBC signals until a graph looks like reality.
Honestly I've done this to nearly every signal, attempted to confirm each with reality.
I'm behind on a bunch of this, and still need to do a video of it all. Learning to fly has been sucking up all my free time the last two months


----------



## emanspeaks

JWardell said:


> Such an awesome project!!
> You may not realize that the EVTV box is a embedded processor that is decoding the CAN and then processing it to a separate serial bus. I'm not sure there is another CAN-to-serial converter that you can drop in its place (I assume that supports GVRET).
> There are plenty of CAN to USB devices out there, but you probably have to then integrate whatever libraries they have into your code.
> The OBD harnesses do not convert the data to OBD, they just provide an OBD connector with CAN on the CAN pins, but OBD pins are not populated. Only an OBD device that can read CAN will work. And that's how the scan my Tesla app works.
> I do wish there was an easier way to talk to the OBD to bluetooth devices from something other than a smartphone. I certainly would prefer the wireless connection. Maybe possible with a Pi, but with Arduino I have only seen bluetooth libraries for slaves not masters. That's been the holdup for my own hardware.


Hello all, long time lurker, first time poster. I've been following @pavankp's project for a while now, with the intent of creating my own HUD derived from their work. I also bought the EVTV box like them, and haven't really had much time to play with it since it arrived. However, after I had already bought the EVTV box, I had a colleague recently show me the Open Vehicle Monitoring System v3. It is similar to the EVTV hardware, but actually has support for three CAN buses (which piqued my interest, as I hope to eventually connect to all three of the Model 3 buses, perhaps through MCU?). Their software doesn't currently support the Model 3, but they stubbed it out in their code with the intent to add support later. I have not purchased one yet, but have been interested in switching to that box with a DB9-to-OBD cable I already own and then swapping to an OBD harness. Might require some mods to one of those cables to make it all work. In any case, that board also has a microUSB port that can be configured for a serial console, which would seem to replace the functionality of the EVTV box, though I am not sure it would be a drop-in replacement.

Curious if anyone has any thoughts on this. Hopefully I will get everything up and running soon at least with what I have and then I can join in the logging fun as well!


----------



## scottf200

emanspeaks said:


> Hello all, long time lurker, first time poster. I've been following @pavankp's project for a while now, with the intent of creating my own HUD derived from their work. I also bought the EVTV box like them, and haven't really had much time to play with it since it arrived. However, after I had already bought the EVTV box, I had a colleague recently show me the Open Vehicle Monitoring System v3. It is similar to the EVTV hardware, but actually has support for three CAN buses (which piqued my interest, as I hope to eventually connect to all three of the Model 3 buses, perhaps through MCU?). Their software doesn't currently support the Model 3, but they stubbed it out in their code with the intent to add support later. I have not purchased one yet, but have been interested in switching to that box with a DB9-to-OBD cable I already own and then swapping to an OBD harness. Might require some mods to one of those cables to make it all work. In any case, that board also has a microUSB port that can be configured for a serial console, which would seem to replace the functionality of the EVTV box, though I am not sure it would be a drop-in replacement.
> 
> Curious if anyone has any thoughts on this. Hopefully I will get everything up and running soon at least with what I have and then I can join in the logging fun as well!


The 'sources' tab here: show the three busses. It is unclear what data you want from all 3?
Module / Vehicle Bus / Chassis Bus / Party Bus
It is unclear to me which 'bus' is the one behind the console in the Model 3.


----------



## emanspeaks

scottf200 said:


> It is unclear to me which 'bus' is the one behind the console in the Model 3.


The Vehicle bus is the one behind the console.



scottf200 said:


> It is unclear what data you want from all 3?


The other two buses besides Vehicle have not really gotten much love yet, perhaps because they are hard to get access to. Once folks begin taking closer looks at data on those buses, it might become clear there is other useful information on them not repeated on the Vehicle bus. GPS data, for example, is only on the Chassis bus and would be great to have as a feature on a HUD without requiring additional hardware.


----------



## JWardell

emanspeaks said:


> The Vehicle bus is the one behind the console.
> 
> The other two buses besides Vehicle have not really gotten much love yet, perhaps because they are hard to get access to. Once folks begin taking closer looks at data on those buses, it might become clear there is other useful information on them not repeated on the Vehicle bus. GPS data, for example, is only on the Chassis bus and would be great to have as a feature on a HUD without requiring additional hardware.


Thats right.
I have two small captures from the chassis bus, taken from under the seat. I haven't seen a capture of the party bus.
I do have a few messages in the spreadsheet for chassis, and could certainly find more if there were some meaningful captures, but with out a simple point of access it won't matter much.

I think I remember someone at some point tapped in to all three at the computer inside the dash. I don't think most people want to go tearing about their dash and disconnecting the computers.

We still need to find better points of access of those other two busses.


----------



## amund7

pavankp said:


> So if I use OBDLink LX with a Pi, can I read the CAN data using that COM as a regular serial port? Do you know if Bluetooth speed may a constraint for data transfer compared to USB? Right now I read the CAN messages as they come in, parse them and store usable values, and then refresh the UI 20 times a second, so the speed displayed by my HUD UI matches the center console display. I can't figure out whether I will be able to manage that over Bluetooth.


The 'speed' packet is sent at 100 hz. Scan My Tesla can steadily get up to 750 packets per second with OBDLink bluetooth devices. When you set the filters in the adapter right, it sends you only that packet at the full 100 hz.


----------



## pavankp

emanspeaks said:


> The Vehicle bus is the one behind the console.
> 
> The other two buses besides Vehicle have not really gotten much love yet, perhaps because they are hard to get access to. Once folks begin taking closer looks at data on those buses, it might become clear there is other useful information on them not repeated on the Vehicle bus. GPS data, for example, is only on the Chassis bus and would be great to have as a feature on a HUD without requiring additional hardware.


It would be great to get the next navigation step, including info about lanes, that the computer sends for the MCU to display. That's pretty much the only thing I miss on my HUD.


----------



## bwilson4web

Thanks!


Calibr8r said:


> Thanks for that! So I just checked that address and these were my results:
> 
> 46°C: unplugged, parked and not awake (didn't press brake pedal)
> 30°C: Unplugged, parked and awake (brake pedal depressed)
> 30°C: Driving
> 30°C: Preconditioning (we know preconditioning battery temps will ignore this limit)
> 38°C: Plugged-in but charger in fully 'off' state (can hear relay switch off)
> 54°C: Plugged-in not charging but maintaining power consumers (A/C etc...)
> 54°C: Plugged-in and charging
> 
> I will visit the supercharger on my way into work Tomorrow to see what values I get during DC-DC fast charging 👍🏻


Recent data from a cold-soak, unplugged over night:









Prior to a Supercharger test, I ran the car down to 2-3 miles remaining:









Something went wrong with the logged data during the Supercharger session. However, I remember seeing 52-54 C.

Looking for something else, I found this paper on the 21700 cells: https://www.researchgate.net/public...arison_of_Commercial_18650_to_the_21700_Cells

Bob Wilson


----------



## Juggas

Anyone know id for high beam?


----------



## JWardell

Juggas said:


> Anyone know id for high beam?


0x3F1 VCFront lighting status 
VCFRONT_highBeamLeftStatus 32 33
VCFRONT_highBeamRightStatus 34 35
VCFRONT_highBeamSwitchActive 58 58


----------



## joverdijk

JWardell said:


> 0x3F1 VCFront lighting status
> VCFRONT_highBeamLeftStatus 32 33
> VCFRONT_highBeamRightStatus 34 35
> VCFRONT_highBeamSwitchActive 58 58


Cool  Seems like its not added in the google-docs can-sheet in opening post. Can you also add a 'last updated' date field in there?
I sometimes check to see if there are any updates, but it's hard to discover if something's been updated
Thanks!


----------



## AndK

Hi, in the CAN spreadsheets, what is "SB", Start bit?
Also: anyone found steering wheel torque yet ?


----------



## JWardell

joverdijk said:


> Cool  Seems like its not added in the google-docs can-sheet in opening post. Can you also add a 'last updated' date field in there?
> I sometimes check to see if there are any updates, but it's hard to discover if something's been updated
> Thanks!


I'll add a comment, but usually don't want to go through the trouble of typing out messages like that with dozens of entries
Google shows you the last updated date at the top of the spreadsheet, and if you click it will show you what was changed and when



AndK said:


> Hi, in the CAN spreadsheets, what is "SB", Start bit?
> Also: anyone found steering wheel torque yet ?


SB is start bit yes
We have wheel position and speed from the steering wheel. The wheel doesn't sense torque.
I suspect the steering rack might have motor torque of some type but that device isn't on the vehicle CAN and we haven't does much work on the other two busses.


----------



## AndK

JWardell said:


> I suspect the steering rack might have motor torque of some type but that device isn't on the vehicle CAN and we haven't does much work on the other two busses.


Seems to me like it is on the CAN C just like so much else ? : (from 2016.2 MS schematic)


----------



## joverdijk

JWardell said:


> I'll add a comment, but usually don't want to go through the trouble of typing out messages like that with dozens of entries
> Google shows you the last updated date at the top of the spreadsheet, and if you click it will show you what was changed and when


Ah cool i didn't know that.. thanks


----------



## JWardell

Time for some light reading!!


__ https://twitter.com/i/web/status/1210437926515023873

__ https://twitter.com/i/web/status/1210632138711863296


----------



## JWardell

So...we have 8 CAN buses according to this diagram... plus some ethernet to figure out.


----------



## Mike

"Batman and Robin" brick monitoring boards.


----------



## Collin80

Mike said:


> "Batman and Robin" brick monitoring boards.


Yeah, they really did name the BMS chips Batman and Robin. There are 9 of each in a Model 3. They're all actually labeled Batman and Robin too.


----------



## Eric_3y

Collin80 said:


> Yeah, they really did name the BMS chips Batman and Robin. There are 9 of each in a Model 3. They're all actually labeled Batman and Robin too.


Interesting to see there is a Private CAN network on the HVC PCB between the HVBMS and HVP chips. Any benefit to check this link, likely requires soldering so only a option for those testing on a torn apart battery pack. Also very interesting to see that Batman and Robin chips talk at two different frequencies using the same twisted two wires (impressive). If I read it correctly Batman talks at a high update rate but with a low frequency signal and Robin talks at a low update rate with a high frequency signal all on the same two wires daisy chained in a loop.

Collin, do you still believe this communication is LTC isoSPI? Steve (https://cabrioev.blogspot.com/2019/01/tesla-mode-3-battery-pack-bms-deeper.html) agrees with you and looks to have had some success with a LTC communication board/chip.

FYI: On the surface it looks possible that this BMS controller by Dilithium Design: (https://www.thunderstruck-ev.com/bms-controller.html) would talk to Model 3 BMBs given it is using LTC iso/SPI. Would of course need to try it on a removed battery module/pack. This is more then is needed to just talk to M3 BMBs but maybe they would depop the measurement portion.


----------



## Collin80

Eric_3y said:


> Interesting to see there is a Private CAN network on the HVC PCB between the HVBMS and HVP chips. Any benefit to check this link, likely requires soldering so only a option for those testing on a torn apart battery pack. Also very interesting to see that Batman and Robin chips talk at two different frequencies using the same twisted two wires (impressive). If I read it correctly Batman talks at a high update rate but with a low frequency signal and Robin talks at a low update rate with a high frequency signal all on the same two wires daisy chained in a loop.
> 
> Collin, do you still believe this communication is LTC isoSPI? Steve (https://cabrioev.blogspot.com/2019/01/tesla-mode-3-battery-pack-bms-deeper.html) agrees with you and looks to have had some success with a LTC communication board/chip.
> 
> FYI: On the surface it looks possible that this BMS controller by Dilithium Design: (https://www.thunderstruck-ev.com/bms-controller.html) would talk to Model 3 BMBs given it is using LTC iso/SPI. Would of course need to try it on a removed battery module/pack. This is more then is needed to just talk to M3 BMBs but maybe they would depop the measurement portion.


I'm not at liberty to fully discuss the deep inner workings of the Model 3 BMS. But, I can say this much - I no longer believe that it is an LTC isoSPI interface. It is natural to assume it is. Anyone who has seen pictures of the modules can plainly see "ISOSPI" labeled on the boards. I know Steve claims that such things worked for him but I could not replicate his results. And I have other reasons to believe it is not accurate, at least for the modules I have. For one thing, according to the leaked documents the BMS uses ASIC chips for batman and robin. ASIC = Application Specific Integrated Circuit. In other words, they built their own chips. You can do that when you're going to produce millions of chips. At 9 per car one gets to a million chips pretty quickly. To me they really do seem to be completely custom chips.


----------



## JWardell

Collin80 said:


> I'm not at liberty to fully discuss the deep inner workings of the Model 3 BMS. But, I can say this much - I no longer believe that it is an LTC isoSPI interface. It is natural to assume it is. Anyone who has seen pictures of the modules can plainly see "ISOSPI" labeled on the boards. I know Steve claims that such things worked for him but I could not replicate his results. And I have other reasons to believe it is not accurate, at least for the modules I have. For one thing, according to the leaked documents the BMS uses ASIC chips for batman and robin. ASIC = Application Specific Integrated Circuit. In other words, they built their own chips. You can do that when you're going to produce millions of chips. At 9 per car one gets to a million chips pretty quickly. To me they really do seem to be completely custom chips.


Yes, I think I remember reading things in the past that the BMS module communications are custom.
It's a tough thing to do in any HV battery pack, where you must pass data between modules that are hundreds of volts from each other, and guarantee the isolation.
Frankly I'm surprised we don't see more fiber optics for this kind of stuff, which would certainly simplify things.


----------



## asanyfuleno

Collin80 said:


> I'm not at liberty to fully discuss the deep inner workings of the Model 3 BMS. But, I can say this much - I no longer believe that it is an LTC isoSPI interface. It is natural to assume it is. Anyone who has seen pictures of the modules can plainly see "ISOSPI" labeled on the boards. I know Steve claims that such things worked for him but I could not replicate his results. And I have other reasons to believe it is not accurate, at least for the modules I have. For one thing, according to the leaked documents the BMS uses ASIC chips for batman and robin. ASIC = Application Specific Integrated Circuit. In other words, they built their own chips. You can do that when you're going to produce millions of chips. At 9 per car one gets to a million chips pretty quickly. To me they really do seem to be completely custom chips.


Does the interfacing difficulty stem form the communication to Batman and Robin or with the main Battery Management System?


----------



## TeslaKiller

Collin80 said:


> Yeah, they really did name the BMS chips Batman and Robin. There are 9 of each in a Model 3. They're all actually labeled Batman and Robin too.


I think this was mentioned in a couple of Jack Rickard's videos back in 2018 too.


----------



## scottf200

Does anyone have cell voltage ranges at different SOC %s on their Model 3? I did something crude like the below for the Chevrolet Volt a couple of years back.

Trying to help my son look at some things related to his TM3 and some unexpected sudden range changes that don't seem to be weather-related. He charges to 80% daily. He may charge to 90% for a week. Not sure if it is a myth or not related to good cell balancing to charge up to 90% several times. (?)

I was suggesting he look at data points vai ScanMyTesla. These are the ones I thought were relevant. 

Cell imbalance, 
Cell temp max, Cell temp mid, Cell temp min 
Cell volt max, Cell volt mid, Cell volt min ,
Battery voltage, 
SOC, SOC UI, SOC Min, SOC Max, SOC Avg
Outside temp


----------



## JWardell

The DBC file was update today with a few fixes found by someone at TMC.



scottf200 said:


> Does anyone have cell voltage ranges at different SOC %s on their Model 3? I did something crude like the below for the Chevrolet Volt a couple of years back.
> 
> Trying to help my son look at some things related to his TM3 and some unexpected sudden range changes that don't seem to be weather-related. He charges to 80% daily. He may charge to 90% for a week. Not sure if it is a myth or not related to good cell balancing to charge up to 90% several times. (?)
> 
> I was suggesting he look at data points vai ScanMyTesla. These are the ones I thought were relevant.
> 
> Cell imbalance,
> Cell temp max, Cell temp mid, Cell temp min
> Cell volt max, Cell volt mid, Cell volt min ,
> Battery voltage,
> SOC, SOC UI, SOC Min, SOC Max, SOC Avg
> Outside temp


It's difficult to look at voltage and compare to other times, unless you can remove almost all load from the battery. 
Cell balancing and voltage deviation will depend on how long its been since the car has performed balancing. Which could be at any time.
But certainly spend some time watching, graphing, and learning how it all relates.


----------



## scottf200

JWardell said:


> It's difficult to look at voltage and compare to other times, unless you can remove almost all load from the battery.
> Cell balancing and voltage deviation will depend on how long its been since the car has performed balancing. Which could be at any time.
> But certainly spend some time watching, graphing, and learning how it all relates.


Thanks for the response. Hard to know when cell balancing happens unless you go to 100% SOC until it stops drawing kW AFAIK.

I don't know if it always happen when you hit whatever set SOC you have. i.e. set it to 90% and you see that it hit 90% but then continues to draw kW for X number of minutes. Seems like that'd be a clue? Not sure if that has been fleshed out or not. TeslaFI.COM for example can take readings every minute so you can see when it hits the SOC limit you set. I'll have to watch for this.

amund7 did let me know that ScanMyTesla labels the report max and min voltages.
I found those data points in the 'All' tab output file in SMT that my son shared with me when we were testing his adapter cable.
'Max pack voltage': 402.83 / 96 = 4.196
'Min pack voltage': 241.31 / 96 = 2.513 

Maybe someday the Model 3 cell modules will be discovered like I have on my Model X. 
My X's 'Module 12' set of cells is regularly higher or lower than the rest.








.









TM-Spy where first graphic is not charging but sitting 'idle' at a stoplight. Cells/Models settle even during drives it seems.







.


----------



## garsh

scottf200 said:


> TM-Spy


Ha! I saw those pictures, and thought that it looked _very_ familiar.

Must be made by the same person who made Leaf Spy back in the day. 
I paid $17 for that app. I think it was the only app I ever paid money for.


----------



## CNDerek

Aha finally!
I am a new-comer of the TOO, glad to meet you guys.
I have tried these days,double check with SCAN MY TESLA and CANoe,VECTOR. and right now I will report something(questions and suggestions),FYI.
1.message 0x293,signal 'unit ' and 'suspensionlevel' have reversing of position? Because when I adjusted unit 'suspensionlevel' changed;
2.some signals DO NOT have clear definitions, listed as below,
0x396:
OilCurrentOffset ?

0x381:the meaning of 1Hz in the name of message?
modeTransitionID?
'count' in activeLouverMotorCounts、 fiveWayValveCountRange？
'mode' in modeTransitionID、 modeDesired？
targetPTActiveCool、 activeLouverOpenPosTarg、 targetPTPassive?

0x293:
trailermdoe/overtake ?

the difference of 'power' between 0x336 and 0x268 ?

0x243:
the value changed frequently? see "1-changed frequently.png "

the difference of 'torque' between 0x108 and 0x1d8 ? see "2-difference of torque.png "


----------



## CNDerek

On vehicle BUS, 
which includs FMCU/RMCU/Cabin PTC/Compressor/LBCM(LEPB,one node)/RBCM(REPB,one node)/security control/BMS/Autopilot/MCU(media)

any body knows the definition or layout for signals,such as
vehicle logic gear?
GPS info,latitude/longitude(elevation does exist)?


----------



## CNDerek

JWardell said:


> The DBC file was update today with a few fixes found by someone at TMC.
> 
> It's difficult to look at voltage and compare to other times, unless you can remove almost all load from the battery.
> Cell balancing and voltage deviation will depend on how long its been since the car has performed balancing. Which could be at any time.
> But certainly spend some time watching, graphing, and learning how it all relates.


there's something wrong with the latest DBC file when I tried to open it by CANdb++ , said,
"Line 6:syntax error"
see picture for detail.


----------



## JWardell

CNDerek said:


> there's something wrong with the latest DBC file when I tried to open it by CANdb++ , said,
> "Line 6:syntax error"
> see picture for detail.


I swear I wrote it out with CANdb++ but I will check again tomorrow.
As for your previous questions, GPS position is only on the Chassis bus, and is documented and in the DBC. Not on the vehicle bus.
As for all your questions about names, well those are what Tesla calls them and it's up to us to try and understand what exactly they mean.

Edit: I see nothing unusual with line 6, and no changes with a GitHub diff. Do you have an old version of Candb++?


----------



## CNDerek

JWardell said:


> I swear I wrote it out with CANdb++ but I will check again tomorrow.
> As for your previous questions, GPS position is only on the Chassis bus, and is documented and in the DBC. Not on the vehicle bus.
> As for all your questions about names, well those are what Tesla calls them and it's up to us to try and understand what exactly they mean.
> 
> Edit: I see nothing unusual with line 6, and no changes with a GitHub diff. Do you have an old version of Candb++?


yes I have the older one and it is normal.
According to your description I opened them with NOTEPAD, there's something different between them.
See the pictures in detail.

Maybe it went wrong during the download? or Upload?


----------



## CNDerek

JWardell said:


> I swear I wrote it out with CANdb++ but I will check again tomorrow.
> As for your previous questions, GPS position is only on the Chassis bus, and is documented and in the DBC. Not on the vehicle bus.
> As for all your questions about names, well those are what Tesla calls them and it's up to us to try and understand what exactly they mean.
> 
> Edit: I see nothing unusual with line 6, and no changes with a GitHub diff. Do you have an old version of Candb++?


Morning!
I compared the old version and the new version with Merge(a file-comparison-tool) and found changed content.
Maybe I could edit a new one in CANdb++ by myself.


----------



## JWardell

CNDerek said:


> yes I have the older one and it is normal.
> According to your description I opened them with NOTEPAD, there's something different between them.
> See the pictures in detail.
> 
> Maybe it went wrong during the download? or Upload?


Clearly the second one there is html/downloaded wrong. Be sure to download the raw text file from GitHub.
But your second message they look normal and yes you are seeing the proper changes I made, so I guess it is working now?
Do you also have the ETH.dbc?


----------



## CNDerek

JWardell said:


> Clearly the second one there is html/downloaded wrong. Be sure to download the raw text file from GitHub.


have tried for several times, all failed.



JWardell said:


> But your second message they look normal and yes you are seeing the proper changes I made, so I guess it is working now?


second picture shows the comparison of code from GitHub directly. It means the code is correct but there's something wrong with DBC file.Maybe you could download by yourself and check it?



JWardell said:


> Do you also have the ETH.dbc?


No, I was more familiar with CAN than Eth.


----------



## JWardell

It must be how your browser is saving it in html some how. Maybe try to right click the raw link and download.


----------



## CNDerek

JWardell said:


> It must be how your browser is saving it in html some how. Maybe try to right click the raw link and download.


this one did work.thanks.


----------



## JWardell

I added a new button...


----------



## David King

And I made an app...
Uses an Elm327


----------



## cyntrex

JWardell said:


> I added a new button...


We need to know details!


----------



## JWardell

David King said:


> And I made an app...
> Uses an Elm327


Nice! Can you transmit with an OBD adapter??


----------



## David King

Yeah @JWardell transmitting is pretty simple with the Bluetooth OBD adapters (use SP6 or you'll be transmitting at the wrong baud rate throwing an error in the car). You can just use a serial Bluetooth terminal app. Receiving is just as easy if you want raw frames. You can have the terminal log them too for analysis later.
Full Elm327 manual here.


----------



## JWardell

David King said:


> Yeah @JWardell transmitting is pretty simple with the Bluetooth OBD adapters (use SP6 or you'll be transmitting at the wrong baud rate throwing an error in the car). You can just use a serial Bluetooth terminal app. Receiving is just as easy if you want raw frames. You can have the terminal log them too for analysis later.
> Full Elm327 manual here.


I guess it makes sense considering they are made to reset errors etc. but considering the massive amount of bad data we see in capture logs from them, I would be very worried about it transmitting bad data on the bus and causing issues. (This is why you should be sure to program checksums on all packets...)


----------



## Collin80

JWardell said:


> I guess it makes sense considering they are made to reset errors etc. but considering the massive amount of bad data we see in capture logs from them, I would be very worried about it transmitting bad data on the bus and causing issues. (This is why you should be sure to program checksums on all packets...)


CAN intrinsically has checksum for all frames. So if it's a hardware issue it would get trapped by the hardware checksum. You could be referring to software side checksums which Tesla does have on many frames. Such a checksum could trap a software based glitch where the CAN is sent OK by hardware but the bytes got messed up before that, perhaps while transmitting over bluetooth. That could be an issue but really the BT layer should have it's own error detection and correction. So, it really comes down to the firmware running on the ELM327 dongle. It ought not output garbage frames but it might.


----------



## CNDerek

I did some job on merging two version of DBC file(@JWardell and @brianman), because in some case it is not enough for JWardell's version and I am looking forward to somebody to check all of the rest signals together with me.

Here is the DBC file named "Tesla Model 3 CANdbc_V0.4_20200116.dbc"(need to change extension to ".dbc")
UPDATE:It reminds me that "The uploaded file was not an image as expected. " even if I changed the externsion to ".npg" while upload, If somebody need it , PM.

Besides, there are some questions listed below, does anybody have an idea?
1.I couldn't log ID401:CellVoltages on my LR RWD, even though it has been difinited in the dbc?
2.Signal " PCS_dcdcLvOutputCurrent " kept as a value of zero"0" while it could not be zero?
3.signals request, such as 

front/rear inverter's voltage or current consumption
power of compressor
and so on


----------



## JWardell

Collin80 said:


> CAN intrinsically has checksum for all frames. So if it's a hardware issue it would get trapped by the hardware checksum. You could be referring to software side checksums which Tesla does have on many frames. Such a checksum could trap a software based glitch where the CAN is sent OK by hardware but the bytes got messed up before that, perhaps while transmitting over bluetooth. That could be an issue but really the BT layer should have it's own error detection and correction. So, it really comes down to the firmware running on the ELM327 dongle. It ought not output garbage frames but it might.


Yes of course CAN has low level checksum, but that isn't going to catch a bluetooth OBD dongle getting the wrong command or data. As we see from almost every log recorded with these adapters they very often have data dropouts and extra messages that aren't actually there.



CNDerek said:


> I did some job on merging two version of DBC file(@JWardell and @brianman), because in some case it is not enough for JWardell's version and I am looking forward to somebody to check all of the rest signals together with me.
> 
> Here is the DBC file named "Tesla Model 3 CANdbc_V0.4_20200116.dbc"(need to change extension to ".dbc")
> UPDATE:It reminds me that "The uploaded file was not an image as expected. " even if I changed the externsion to ".npg" while upload, If somebody need it , PM.
> 
> Besides, there are some questions listed below, does anybody have an idea?
> 1.I couldn't log ID401:CellVoltages on my LR RWD, even though it has been difinited in the dbc?
> 2.Signal " PCS_dcdcLvOutputCurrent " kept as a value of zero"0" while it could not be zero?
> 3.signals request, such as
> 
> front/rear inverter's voltage or current consumption
> power of compressor
> and so on


Remember that ETH DBC has many many messages that are not actually present on the network, and have changed, and others missing. That's why mine is handmade with verified data. You are also seeing missing messages that used to be there but removed in later firmware, which I also document. The ETH DBC if from firmware that is now a year old, and is documenting internal ethernet signals not CAN signals.
If you are using CANoe it's easier to just load in several DBC files on the same bus and it will decode everything.


----------



## CNDerek

JWardell said:


> Remember that ETH DBC has many many messages that are not actually present on the network, and have changed, and others missing. That's why mine is handmade with verified data. You are also seeing missing messages that used to be there but removed in later firmware, which I also document. The ETH DBC if from firmware that is now a year old, and is documenting internal ethernet signals not CAN signals.If you are using CANoe it's easier to just load in several DBC files on the same bus and it will decode everything.


yet I understood.
Actually what I have done is based on Brianman's version and fuse your version, during the comparison I chose to trust your definition as soon as seeking out differences. Thus Brianman's version provided references such as ID, signals coding-rule which are probably not changed in my opinion.

In this case, here are the questions which are the same to both versions.
1.I couldn't log ID401:CellVoltages on my LR RWD, even though it has been difinited in the dbc?
2.Signal " PCS_dcdcLvOutputCurrent " kept as a value of zero"0" while it could not be zero? 
3.Layout and len definition are different between ID266RearInverterPower and ID2E5FrontInverterPower, and I tend to that signal "heatpowermax" is 9 bits


----------



## mattiasclaesson

JWardell said:


> So...we have 8 CAN buses according to this diagram... plus some ethernet to figure out.


Hi,

I have connected to CAN at the rear center console in my model 3. Would that be the vehicle CAN bus in the diagram?

/Mattias


----------



## mattiasclaesson

scottf200 said:


> Maybe someday the Model 3 cell modules will be discovered like I have on my Model X.
> 
> .


I did get the impression from this code:
http://media3.ev-tv.me/Model3Battery102.zip
that it known information and working information.

But when I tried to write a own application, I did not get any of these frames. 
I also contacted the author of TM-Spy what told me that the cell voltages are on another bus.

/Mattias


----------



## JWardell

CNDerek said:


> yet I understood.
> Actually what I have done is based on Brianman's version and fuse your version, during the comparison I chose to trust your definition as soon as seeking out differences. Thus Brianman's version provided references such as ID, signals coding-rule which are probably not changed in my opinion.
> 
> In this case, here are the questions which are the same to both versions.
> 1.I couldn't log ID401:CellVoltages on my LR RWD, even though it has been difinited in the dbc?
> 2.Signal " PCS_dcdcLvOutputCurrent " kept as a value of zero"0" while it could not be zero?
> 3.Layout and len definition are different between ID266RearInverterPower and ID2E5FrontInverterPower, and I tend to that signal "heatpowermax" is 9 bits





mattiasclaesson said:


> I did get the impression from this code:
> http://media3.ev-tv.me/Model3Battery102.zip
> that it known information and working information.
> 
> But when I tried to write a own application, I did not get any of these frames.
> I also contacted the author of TM-Spy what told me that the cell voltages are on another bus.
> 
> /Mattias


Please remember that Tesla removed some messages, especially 0x401 cell voltages and cell temperatures, as highlighted in a following EVTV episode.
Yes, the rear console only has the vehicle CAN bus


----------



## michi84

PCS_dcdcLvOutputCurrent was removed in recent firmware. PCS current is however still present on VCFRONT:

BO_ 753 VCFRONT_eFuseDebugStatus: 8 ETH
SG_ VCFRONT_eFuseDebugStatusIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_PCSState m2: 8|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_PCSFault m2: 10|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pcsSelfTestResult m2: 11|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_PCSTemp m2: 15|[email protected]+ (0.125,-40) [0|0] "degC" X
SG_ VCFRONT_PCSVoltage m2: 31|[email protected]+ (0.1,0) [0|0] "V" X
SG_ VCFRONT_PCSCurrent m2: 47|[email protected] (0.1,0) [0|0] "A" X

Update rate about every 1-2 seconds with my Macchina M2. Voltage and Current could be used to calculate total 12V power.

For front and rear power, i use the following definitions:

BO_ 741 ID2E5FrontInverterPower: 8 ETH
SG_ FrontPowerDissipation2E5 : 24|[email protected]+ (0.125,-0.5) [-0.5|31.375] "kW" X
SG_ FrontPower2E5 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
SG_ FrontHeatPowerOptimal2E5 : 56|[email protected]+ (0.08,0) [0|31875] "kW" X
SG_ FrontHeatPowerMax2E5 : 48|[email protected]+ (0.08,0) [0|31875] "kW" X
SG_ FrontHeatPower2E5 : 40|[email protected]+ (0.08,0) [0|31875] "kW" X
SG_ Front12vInverter2E5 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X

BO_ 614 ID266RearInverterPower: 8 ETH
SG_ RearHeatPowerOptimal266 : 56|[email protected]+ (0.08,0) [0|255] "kW" X
SG_ RearHeatPowerMax266 : 48|[email protected]+ (0.08,0) [0|255.5] "kW" X
SG_ RearHeatPower266 : 40|[email protected]+ (0.08,0) [0|255] "kW" X
SG_ RearPowerDissipation266 : 24|[email protected]+ (0.125,-0.5) [0|255] "kW" X
SG_ RearPower266 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
SG_ Rear12vInverter266 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X

Dissipation-Offset does not yet appear right to me, values seem to high at low power and with the car standing still.


----------



## cyntrex

David King said:


> And I made an app...
> Uses an Elm327


Did you use the method juanmax described here with injecting the message to the front CAN bus?
I'd love to try out your app, got the hardware lying around for it, would be awesome if you could send me an apk if you have one.



juanmax said:


> Try sending on the can a wrong front motor rpm. You loose AP, ESC, TCS, and so on... ABS still works though.


----------



## CNDerek

michi84 said:


> PCS_dcdcLvOutputCurrent was removed in recent firmware. PCS current is however still present on VCFRONT:
> 
> BO_ 753 VCFRONT_eFuseDebugStatus: 8 ETH
> SG_ VCFRONT_eFuseDebugStatusIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSState m2: 8|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSFault m2: 10|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pcsSelfTestResult m2: 11|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSTemp m2: 15|[email protected]+ (0.125,-40) [0|0] "degC" X
> SG_ VCFRONT_PCSVoltage m2: 31|[email protected]+ (0.1,0) [0|0] "V" X
> SG_ VCFRONT_PCSCurrent m2: 47|[email protected] (0.1,0) [0|0] "A" X
> 
> Update rate about every 1-2 seconds with my Macchina M2. Voltage and Current could be used to calculate total 12V power.


That's right!



michi84 said:


> For front and rear power, i use the following definitions:
> 
> BO_ 741 ID2E5FrontInverterPower: 8 ETH
> SG_ FrontPowerDissipation2E5 : 24|[email protected]+ (0.125,-0.5) [-0.5|31.375] "kW" X
> SG_ FrontPower2E5 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
> SG_ FrontHeatPowerOptimal2E5 : 56|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ FrontHeatPowerMax2E5 : 48|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ FrontHeatPower2E5 : 40|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ Front12vInverter2E5 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X
> 
> BO_ 614 ID266RearInverterPower: 8 ETH
> SG_ RearHeatPowerOptimal266 : 56|[email protected]+ (0.08,0) [0|255] "kW" X
> SG_ RearHeatPowerMax266 : 48|[email protected]+ (0.08,0) [0|255.5] "kW" X
> SG_ RearHeatPower266 : 40|[email protected]+ (0.08,0) [0|255] "kW" X
> SG_ RearPowerDissipation266 : 24|[email protected]+ (0.125,-0.5) [0|255] "kW" X
> SG_ RearPower266 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
> SG_ Rear12vInverter266 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X
> 
> Dissipation-Offset does not yet appear right to me, values seem to high at low power and with the car standing still.


These should have to be checked.


----------



## JWardell

I've updated the DBC file with 0x224 and 0x2F1 after discussion above, it's especially tough to catch things that disappear with firmware changes. I'm sure it will be useful to see software fuse status as well. Thanks to @CNDerek and @michi84 for looking into these.

As for power messages 0x268 (system) 0x266 (rear) and 0x2E5 (front) thanks to changes we really don't know what the extra signals are and how their scales, offsets, etc have changed. These did change in recent updates when the messages moved around.
I never fully understood the meaning of all the heat and dissipation signals so that makes it more difficult to understand what data we should see here, and especially tough without a dual motor car.
It would be very helpful if you all could look into these with your own data and suggest how these signals should be defined. (Maybe @fast_like_electric too?)
Perhaps I will look at how these looked with year-old logs and then look at raw data for more recent logs. I'm betting some did add some extra bits and signals no double shuffled around within the message. There was a note in the DBC that I did not believe the offset, and I don't have the three of these matching. Hopefully we can figure this all out.



CNDerek said:


> yet I understood.
> Actually what I have done is based on Brianman's version and fuse your version, during the comparison I chose to trust your definition as soon as seeking out differences. Thus Brianman's version provided references such as ID, signals coding-rule which are probably not changed in my opinion.
> 
> In this case, here are the questions which are the same to both versions.
> 1.I couldn't log ID401:CellVoltages on my LR RWD, even though it has been difinited in the dbc?
> 2.Signal " PCS_dcdcLvOutputCurrent " kept as a value of zero"0" while it could not be zero?
> 3.Layout and len definition are different between ID266RearInverterPower and ID2E5FrontInverterPower, and I tend to that signal "heatpowermax" is 9 bits





michi84 said:


> PCS_dcdcLvOutputCurrent was removed in recent firmware. PCS current is however still present on VCFRONT:
> 
> BO_ 753 VCFRONT_eFuseDebugStatus: 8 ETH
> SG_ VCFRONT_eFuseDebugStatusIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSState m2: 8|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSFault m2: 10|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pcsSelfTestResult m2: 11|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_PCSTemp m2: 15|[email protected]+ (0.125,-40) [0|0] "degC" X
> SG_ VCFRONT_PCSVoltage m2: 31|[email protected]+ (0.1,0) [0|0] "V" X
> SG_ VCFRONT_PCSCurrent m2: 47|[email protected] (0.1,0) [0|0] "A" X
> 
> Update rate about every 1-2 seconds with my Macchina M2. Voltage and Current could be used to calculate total 12V power.
> 
> For front and rear power, i use the following definitions:
> 
> BO_ 741 ID2E5FrontInverterPower: 8 ETH
> SG_ FrontPowerDissipation2E5 : 24|[email protected]+ (0.125,-0.5) [-0.5|31.375] "kW" X
> SG_ FrontPower2E5 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
> SG_ FrontHeatPowerOptimal2E5 : 56|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ FrontHeatPowerMax2E5 : 48|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ FrontHeatPower2E5 : 40|[email protected]+ (0.08,0) [0|31875] "kW" X
> SG_ Front12vInverter2E5 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X
> 
> BO_ 614 ID266RearInverterPower: 8 ETH
> SG_ RearHeatPowerOptimal266 : 56|[email protected]+ (0.08,0) [0|255] "kW" X
> SG_ RearHeatPowerMax266 : 48|[email protected]+ (0.08,0) [0|255.5] "kW" X
> SG_ RearHeatPower266 : 40|[email protected]+ (0.08,0) [0|255] "kW" X
> SG_ RearPowerDissipation266 : 24|[email protected]+ (0.125,-0.5) [0|255] "kW" X
> SG_ RearPower266 : 0|[email protected] (0.5,0) [-512|511.5] "kW" X
> SG_ Rear12vInverter266 : 16|[email protected]+ (0.1,0) [0|25.5] "Volts" X
> 
> Dissipation-Offset does not yet appear right to me, values seem to high at low power and with the car standing still.


----------



## David King

Anyone who wants to try out the Android app, you can find it here. I haven't been able to test it in the snow yet, my main motivation for researching this, but it's happy to break the rear end loose on tight turns on wet pavement.

It's interesting to see how it changes the torque and power split shown in Scan My Tesla on my dual motor. It appears to constantly produce around half the power and torque in the front that it does from the rear motor and at any amount of torque, whereas before it seemed to only engage the front motor above a certain torque value, around 110 ft-lbs if I remember correctly. It made me think it may be faster to 60 in this mode so I did one 0-60 comparison on dry pavement and SMT reported it actually being slower than normal. I guess it gets a little conservative when the nannies are turned off.

EDIT: The app has been removed to ensure the sustainability of this and similar technology for our vehicles.


----------



## cyntrex

David King said:


> Anyone who wants to try out the Android app, you can find it here. It's called "Model 3 Unlocked" if you want to search for it. I haven't been able to test it in the snow yet, my main motivation for researching this, but it's happy to break the rear end loose on tight turns on wet pavement.
> 
> It's interesting to see how it changes the torque and power split shown in Scan My Tesla on my dual motor. It appears to constantly produce around half the power and torque in the front that it does from the rear motor and at any amount of torque, whereas before it seemed to only engage the front motor above a certain torque value, around 110 ft-lbs if I remember correctly. It made me think it may be faster to 60 in this mode so I did one 0-60 comparison on dry pavement and SMT reported it actually being slower than normal. I guess it gets a little conservative when the nannies are turned off.


Does this work with the rear console vehicle CAN bus?


----------



## David King

cyntrex said:


> Does this work with the rear console vehicle CAN bus?


Yes. Just like Scan My Tesla.


----------



## michigantesla

Just downloaded the Android version and tried it on my m3p.

We had a snowstorm Saturday and I was running around in track mode then. It would let the car slide some and sort of do donuts even. However was weird to have the car running the cooling fans when it was 20 degrees F outside and I seemed to be really chewing through some KWHs.

Anyway the app definitely worked!

Connected it my Obdlink mx and pressed the button and immediately got the warning messages on the display. Drove over to a hardpack (icy) road and tried it out. Definitely different driving with no regen.

On the icy road it would lite up front and rear tires with any significant throttle. However, I do think something was still limiting the amount of energy to the wheels. It was slippery enough that I should have been easily able to spin the wheels up to serious speed very quickly. The wheels would break traction (and the car would walk a little sideways while also accelerating) right away but no zing the speedo to 100mph like I would expect without any nanny. Probably a good thing but still not totally unrestricted it seems.

At an intersection (this is rural area no traffic) it would easily do donuts even though I have the AWD. It would in Track Mode also in the snow btw. But does seem a little more willing.









Overall this app seemed a lot better than track mode for snow and sliding the car around than track mode. And certainly less wasteful energy wise. Disabling regen in the snow is good I supposed but an option to leave it on would be welcome too.


----------



## JWardell

__ https://twitter.com/i/web/status/1219440781750128641


----------



## David King

michigantesla said:


> Just downloaded the Android version and tried it on my m3p.
> 
> We had a snowstorm Saturday and I was running around in track mode then. It would let the car slide some and sort of do donuts even. However was weird to have the car running the cooling fans when it was 20 degrees F outside and I seemed to be really chewing through some KWHs.
> 
> Anyway the app definitely worked!
> 
> Connected it my Obdlink mx and pressed the button and immediately got the warning messages on the display. Drove over to a hardpack (icy) road and tried it out. Definitely different driving with no regen.
> 
> On the icy road it would lite up front and rear tires with any significant throttle. However, I do think something was still limiting the amount of energy to the wheels. It was slippery enough that I should have been easily able to spin the wheels up to serious speed very quickly. The wheels would break traction (and the car would walk a little sideways while also accelerating) right away but no zing the speedo to 100mph like I would expect without any nanny. Probably a good thing but still not totally unrestricted it seems.
> 
> At an intersection (this is rural area no traffic) it would easily do donuts even though I have the AWD. It would in Track Mode also in the snow btw. But does seem a little more willing.
> 
> Overall this app seemed a lot better than track mode for snow and sliding the car around than track mode. And certainly less wasteful energy wise. Disabling regen in the snow is good I supposed but an option to leave it on would be welcome too.


Thanks for sharing your experience and I'm glad you enjoyed it. I'm definitely jealous you got to play in the snow as that's the whole reason I did this but for some reason this Ohio winter is mild and I haven't gotten the chance! The comparison with track mode is interesting to hear as my lack of track mode was another motivating factor. I guess I noticed similar reservations with the car when doing the 0-60 comparison. In your case, it seems totally feasible that the car could compare wheel speed with GPS speed to put reasonable limits on wheel speed even when the ESP system is "down". Or, they can just assume there's no full traction scenario where wheels accelerate that quickly and know to limit it in that case as well. Interesting stuff.


----------



## Kbecks

Just tried that app on my Performance and WHOA it works, didn't realize this car had so much power lol need to find a better place to play around. I'm also an engineer but don't know much about CAN and typically live in the hardware world, but my understanding is that this is basically slightly changing wheel speed values or did you use another method?

Based on these older posts: https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-49#post-248950

Love this thread and reading how this works so that i can better understand what i'm experiencing in the car, you guys are all absolute legends. Once i get Scan My Tesla data integrated into some track apps then i'm in heaven.


----------



## viperboy

David King said:


> And I made an app...
> Uses an Elm327


Really cool! Now I need to order the adapter and OBD2 bluetooth device, was quite underwhelmed with Track mode in a recent snow storm in my P3D, too many nannies still.

Can I ask how you did this? I'm a software engineer myself and would be interested in bringing this to iOS if it anything you'd like to partner on. Let me know!


----------



## michi84

Tried it in the snow yesterday, this is great for having a little fun on an empty parking lot. It feels like ABS is still working, so this would be like track mode, but without any stability control whatsoever to save you when you overdo it. I hope this does not get blocked by a software update,..


----------



## kornerz

Wake a Model 3 from deep sleep via CAN?

So I live in a country where there's no Tesla LTE coverage (yet), so there's no possibility to wake up the car remotely.
I do, however, have a Raspberry PI attached to vehicle CAN bus with a separate LTE connectivity (which also shares Wi-Fi with the car for maps to work).

The question is - have anybody seen a CAN message to be sent to vehicle CAN bus to wake a Model 3 from sleep?


----------



## fast_like_electric

kornerz said:


> Wake a Model 3 from deep sleep via CAN?
> 
> So I live in a country where there's no Tesla LTE coverage (yet), so there's no possibility to wake up the car remotely.
> I do, however, have a Raspberry PI attached to vehicle CAN bus with a separate LTE connectivity (which also shares Wi-Fi with the car for maps to work).
> 
> The question is - have anybody seen a CAN message to be sent to vehicle CAN bus to wake a Model 3 from sleep?


Basically any message sent on the bus will do it, as any module has that capability. It won't stay awake too long once it figures out that it doesn't have a reason to be awake. But if you then connect with the app via WiFi, you'll keep it awake and can do typical app control things - if that is what you are trying to accomplish.


----------



## kornerz

fast_like_electric said:


> Basically any message sent on the bus will do it, as any module has that capability. It won't stay awake too long once it figures out that it doesn't have a reason to be awake. But if you then connect with the app via WiFi, you'll keep it awake and can do typical app control things - if that is what you are trying to accomplish.


Thanks!
Yes, once it's awake I'll find a way to keep it so - that was the intent.
As for messages - is there some safe example? something like 0x336, power/regen rating one.


----------



## fast_like_electric

kornerz said:


> Thanks!
> Yes, once it's awake I'll find a way to keep it so - that was the intent.
> As for messages - is there some safe example? something like 0x336, power/regen rating one.


I don't believe the power-moding messages and logic are fully understood by the collective here. Ideally you'd want to send the message that the computer normally sends after LTE wake-up. Perhaps someone here can log that brief CAN transaction (car asleep with no traffic - then wake-up with app). Any message will work, but doing something close to 'normal' would be most ideal.

Alternately, you can put the car in a mode where it doesn't sleep - such as with Sentry mode active. At the expense of range, of course.


----------



## kornerz

OK, so I've tested it.
To wake a Model 3 from sleep via CAN, one can send message# 3FE (brake temps):

cansend can0 '3FE#3737373700'​​EDIT: cansend can0 '336#FAA000' , which is power limits message, wakes up the car as well.


----------



## Collin80

EVTV recently posted a video detailing reverse engineering work to get the Model 3 battery to work outside of the car (the whole battery, I'm working on the partial battery solution. It's close!): 




One interesting take away is that the battery pack only needs ID 0x221 to be able to close the contacts. So, this would suggest that 0x221 is a command to the battery pack. This doesn't get us a lot closer to knowing what the bitfield in there means but it does strongly hint at the purpose of the frame. It should be possible to play with the bit field in there to see what effect the bits have on the battery. Though, obviously that could be slightly inconvenient in a car.


----------



## Gtimart

David King said:


> Anyone who wants to try out the Android app, you can find it here. It's called "Model 3 Unlocked" if you want to search for it. I haven't been able to test it in the snow yet, my main motivation for researching this, but it's happy to break the rear end loose on tight turns on wet pavement.


Oh I would love to try this or learn how to do this on my awd. I've been finding the behaviour on snow less than perfect let's say. Unfortunately I don't see the application... Is it only published for the US? Thanks!

Edit: to be clear I'm looking for a way to reduce the traction control and stability to have some fun. Not sure I want to kill it all by sending a bad can message. Some of the posts I've read after my initial response made me nervous...


----------



## JWardell

Collin80 said:


> EVTV recently posted a video detailing reverse engineering work to get the Model 3 battery to work outside of the car (the whole battery, I'm working on the partial battery solution. It's close!):
> 
> 
> 
> 
> One interesting take away is that the battery pack only needs ID 0x221 to be able to close the contacts. So, this would suggest that 0x221 is a command to the battery pack. This doesn't get us a lot closer to knowing what the bitfield in there means but it does strongly hint at the purpose of the frame. It should be possible to play with the bit field in there to see what effect the bits have on the battery. Though, obviously that could be slightly inconvenient in a car.


Nice! Are you ne of the stars in the video?

Have you determined any of the signals in 0x221? It looks like it is muxed toggling with 40 and 41
Also did you figure out if the battery is running old firmware or ix 0x401 being suppressed?


----------



## Collin80

JWardell said:


> Nice! Are you ne of the stars in the video?
> 
> Have you determined any of the signals in 0x221? It looks like it is muxed toggling with 40 and 41
> Also did you figure out if the battery is running old firmware or ix 0x401 being suppressed?


No, I'm not in the video. I don't know if they tried to see if 0x401 is suppressed or not. I doubt that Tesla merely suppressed it with a message. The 0x401 message was extremely slow anyway so it would not have unduly affected the rest of the traffic. No, my bet is that they either just plain removed it or they now require a request from another node in order to get those messages.

I've looked at 0x221 a bit but I don't know what it encodes quite yet. Actually upon start up the first byte starts at 0 (alternating 0,1,0,1) then goes to 20,21,20,21 then later back to 0 then up to 40. So, I'm thinking there is some sort of bitfield in the upper nibble and the lower nibble alternates between 0 and 1. That alternation does appear to be a mux because basically all 0x40 messages look the same as do 0x41 messages. In fact, 0x21 messages are formatted like 0x41 messages, etc. So, it seems there are two separate types of message sent and which one is selected by that low nibble in the first byte. The last byte in the message is a simple checksum. Add the ID (0x221) and the first 7 bytes, add 2 to that, and chop it off to the lower 8 bits. You get the last byte in the message. So, that's how you'd fake 0x221 messages and get the battery to accept them.

But, what do the other 6 bytes mean? I'm not entirely sure at the moment. They change in ways that look suspiciously like bitfields. One guess might be a request for balancing. There are 96 series groups of cells (23 + 23 + 25 + 25) and if you assume the first and last bytes are spoken for you have 6 bytes in the middle. 6 * 2 * 8 is a suspicious value. However, looking at lots of logs seems to rule out this guess. The values don't really quite follow what you'd expect if they were actually balancing for each cell. Beside that, currently we're aware of no actual transmission of per cell voltages so it'd be pretty tough for the central computer to make commands if it doesn't even have the per-cell voltages. And, I'd think that the BMS would ordinarily make those decisions, not anything else on the bus. So, I don't really know what's in there except that they look like flags to me.


----------



## Otmar

Pure speculation here on the 0x221: 
Tesla has various states for standby, HVAC, Drive or some names that I forget. Could it be the gateway requesting the BMS to be in a certain mode with associated limits? 
Might be fun to check the set in various modes.


----------



## Collin80

That could be. I also just saw that there is a counter in there. The upper nibble in the 7th byte increments up from 0 through F over and over. It essentially ignores the mux from up in the fist byte. By that I mean, that counter increments with every message so while you get a flipflop of 0 and 1 in the first byte, this byte just keeps incrementing. So, it's just a counter that is added in there for some reason. Also, the bits in the middle 6 bytes seem to have things set usually every other bit which is why you see so many 0x55 values. Most of the time every other bit is never set. It's kind of a weird quirk that might not mean a whole lot.

Yeah, someone should try running through various modes to see if they show up in 0x221.


----------



## JWardell

Collin80 said:


> No, I'm not in the video. I don't know if they tried to see if 0x401 is suppressed or not. I doubt that Tesla merely suppressed it with a message. The 0x401 message was extremely slow anyway so it would not have unduly affected the rest of the traffic. No, my bet is that they either just plain removed it or they now require a request from another node in order to get those messages.
> 
> I've looked at 0x221 a bit but I don't know what it encodes quite yet. Actually upon start up the first byte starts at 0 (alternating 0,1,0,1) then goes to 20,21,20,21 then later back to 0 then up to 40. So, I'm thinking there is some sort of bitfield in the upper nibble and the lower nibble alternates between 0 and 1. That alternation does appear to be a mux because basically all 0x40 messages look the same as do 0x41 messages. In fact, 0x21 messages are formatted like 0x41 messages, etc. So, it seems there are two separate types of message sent and which one is selected by that low nibble in the first byte. The last byte in the message is a simple checksum. Add the ID (0x221) and the first 7 bytes, add 2 to that, and chop it off to the lower 8 bits. You get the last byte in the message. So, that's how you'd fake 0x221 messages and get the battery to accept them.
> 
> But, what do the other 6 bytes mean? I'm not entirely sure at the moment. They change in ways that look suspiciously like bitfields. One guess might be a request for balancing. There are 96 series groups of cells (23 + 23 + 25 + 25) and if you assume the first and last bytes are spoken for you have 6 bytes in the middle. 6 * 2 * 8 is a suspicious value. However, looking at lots of logs seems to rule out this guess. The values don't really quite follow what you'd expect if they were actually balancing for each cell. Beside that, currently we're aware of no actual transmission of per cell voltages so it'd be pretty tough for the central computer to make commands if it doesn't even have the per-cell voltages. And, I'd think that the BMS would ordinarily make those decisions, not anything else on the bus. So, I don't really know what's in there except that they look like flags to me.


Actually I think we already know from the eth dbc

BO_ 545 VCFRONT_LVPowerState: 8 GTW
SG_ VCFRONT_LVPowerStateChecksum : 56|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_LVPowerStateCounter : 52|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_LVPowerStateIndex M : 0|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_vehiclePowerState : 5|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_parkLVState m0: 8|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_espLVState m0: 10|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_radcLVState m0: 12|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_hvacCompLVState m0: 14|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_ptcLVRequest m0: 16|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_sccmLVRequest m0: 18|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_tpmsLVRequest m0: 20|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_rcmLVRequest m0: 22|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_iBoosterLVState m0: 24|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_tunerLVRequest m0: 26|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_amplifierLVRequest m0: 28|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_das1HighCurrentLVState m0: 30|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_das2HighCurrentLVState m0: 32|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_diLVRequest m0: 34|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_disLVState m0: 36|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_oilPumpFrontLVState m0: 38|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_oilPumpRearLVRequest m0: 40|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_ocsLVRequest m0: 42|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_vcleftHiCurrentLVState m0: 44|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_vcrightHiCurrentLVState m0: 46|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_uiHiCurrentLVState m0: 48|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_uiAudioLVState m0: 50|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_cpLVRequest m1: 8|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_epasLVState m1: 10|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_hvcLVRequest m1: 12|[email protected]+ (1,0) [0|0] "" ETH <----
SG_ VCFRONT_tasLVState m1: 14|[email protected]+ (1,0) [0|0] "" ETH
SG_ VCFRONT_pcsLVState m1: 16|[email protected]+ (1,0) [0|0] "" ETH

I'll add that to the next update.
I agree I doubt 401 is just suppressed, but Jack kept talking about verifying it with another battery or questioning the software rev, but never answered that.
I'm sure there are plenty more messages and things that can be requested. Still would love to figure out how to unlock the inverter debug message so we can see fun things like phase currents.

But really, it's most important to first figure out the signal order, bit lengths, scaling etc of the inverter power and torque messages, because those are by far of the most interest, and we have gone far too long not having confidence in them


----------



## Feathermerchant

If Jack would just take his test apparatus to HIS model 3 (that has up to date software) he could check to see if he can see individual cell voltages like he can on the salvaged battery.

On another subject I wonder why Jack didn't try plugging in a UMC to the charge port to see if it would charge the battery. It might require a message from the MCU or it might just remember the last setting for charge limit.


----------



## Collin80

Yes, you're right. It sure seems to match those entries in the eth file. I added them to the CAN DBC file and it looks pretty convincing.


----------



## JWardell

I'm beta testing an app that lets me view bitfields as I drive, and trying to concentrate on dialing 0x266 and 0x1D8 power and torque signals.

I think I have the signal locations and lengths correct (see layout at bottom) so what's left is scaling and offsets for what makes sense, as well as the middle signals in 266, which should have something to do with power (maybe mechanical vs electrical?) and dissipation. The three in the middle are definitely just bytes, and strangely just peg at 255 easily with no extra rollover, and no negative numbers (perhaps these have offsets?) The last signal is 12-bit and usually doesn't move from 202, but if you look below at the WOT 0-60 run graph, it clearly shows power limit and its back into the power curve. So maybe we can figure the scale for that one. The naming may be totally wrong.

Anyway, the video below is from the app, starting from park, then drive... I am just lightly tapping the pedal forward a few times, then reverse, and finally a harder accel and regen. You will note those three center 266 signals are very responsive to tiny torques, well before the first main power signal registers a single bit. Does that make sense to anyone?
(The graph below it is from an older 0-60 run)


----------



## michi84

Heat power should be: RearHeatPower266 : 40|[email protected]+ (0.08,0) [0|255] "kW" X

At least, i get very reasonable data with this, about 3.2 to 3.6 kW during battery preheating either with preconditioning with the car parked, during SUC preheating. Also, when battery temp is low, during regen i also get some heat power fro from about 1.6 to 3.xx kW, but mostly on the front motor at higher speeds, the rear motor kicks in at lower speed too. Without any active heating needed, value stays at zero.

Same on front motor. This is with firmware 2019.40.50.7, but has been so since months for me.


----------



## JWardell

michi84 said:


> Heat power should be: RearHeatPower266 : 40|[email protected]+ (0.08,0) [0|255] "kW" X
> 
> At least, i get very reasonable data with this, about 3.2 to 3.6 kW during battery preheating either with preconditioning with the car parked, during SUC preheating. Also, when battery temp is low, during regen i also get some heat power fro from about 1.6 to 3.xx kW, but mostly on the front motor at higher speeds, the rear motor kicks in at lower speed too. Without any active heating needed, value stays at zero.
> 
> Same on front motor. This is with firmware 2019.40.50.7, but has been so since months for me.


Yes, it appears I have heat power and heat power optimal swapped. I just noticed today while driving and watching byte 3 is more of a limit and represents the max value the other byte can reach. I don't know if that is heat power optimal or should be called heat power limit.

Also I have the final signal figured out, it is active electrical power limit and scale and offset I now have it matching power cutback on WOT. I updated the DBC earlier with that, but I will have to update again tomorrow with swaps and fixes to the three middle byte signals.

...and that means we may just have 266 fully figured out now! Stat tuned.


----------



## kornerz

Small correction to the DBC:
VAL_ 280 DriveState118 5 "Driving" 2 "Standby" 1 "Charging" 0 "Idle" ;

State "1" looks like "Conditioning", not "Charging":
It is active while battery is cold, climate on and rear drive unit is generating heat. And then deactivates (changes to 0 Idle) when MinBattTemp212 reaches 21C


----------



## JWardell

I think I finally have the new 0x266 and 0x2E5 power messages figured out!
Please grab the latest DBC.

First I have a scale and offset on that added last signal, which clearly seems to be a max power limit to me. It will kick in a few seconds after WOT and output power will reduce with that limit. I've tuned offset to match closely with many of my latest captures, but my big question is if it still holds true with dual motor and performance cars. It should set at the max power capability of the motor, but sometimes it is reduced by 20-30kW continuously (not sure why yet) and I will see WOT output only hit the reduced number as well.









Also thanks to being able to quickly view DBC changes live due to the new phone app, also thanks to @michi84 's comment and looking at the original signals and scales, I think I have the middle bytes figured out:










These all have to do with the power the inverter wastes to heat coolant in order to heat the battery. RearHeatPower shows the actual power. RearHeatPowerMax is the current limit for that power. RearHeatPowerOptimal usually is the same, but for example when navigating to a supercharger and battery preconditioning starts up, you can see power and max power go to ~3kW but optimal stays at zero because you wouldn't optimally need heat for driving at that moment.

I would love to hear thoughts from others!












kornerz said:


> Small correction to the DBC:
> VAL_ 280 DriveState118 5 "Driving" 2 "Standby" 1 "Charging" 0 "Idle" ;
> 
> State "1" looks like "Conditioning", not "Charging":
> It is active while battery is cold, climate on and rear drive unit is generating heat. And then deactivates (changes to 0 Idle) when MinBattTemp212 reaches 21C


The real definitions for these states are not clear with standby/idle/abort/fault etc....so early last year I looked very closely at this state and tried to assign more descriptive names. I always saw 1 while charging.
I confirmed today you are right, it is 1 when preconditioning (You couldn't precondition without charging until the end of 2019). So I've renamed it to ChargeHeat. But now I'm curious, is it 1 if it is charging but the inverter is not needed for heat? Well I guess it would be shut down and not transmitting the signal anyway. 
In other words I will monitor this state more closely and may rename it again soon.


----------



## Calibr8r

scottf200 said:


> Thanks for the response. Hard to know when cell balancing happens unless you go to 100% SOC until it stops drawing kW AFAIK.
> 
> I don't know if it always happen when you hit whatever set SOC you have. i.e. set it to 90% and you see that it hit 90% but then continues to draw kW for X number of minutes. Seems like that'd be a clue? Not sure if that has been fleshed out or not. TeslaFI.COM for example can take readings every minute so you can see when it hits the SOC limit you set. I'll have to watch for this.


I have seen my min-to-max cell imbalance value change from 7mV to only 2mV when I finished charging to 90%, which would suggest that balancing is possibly occurring below the typical 100% charging level some basic BMS' seem to do.


----------



## Chrism3c

@David King 
I'm new to this board so not able to message you directly but if you or anyone else could send me the TeslaTrac3 app I would like to give it a try.

Thanks


----------



## derotam

Calibr8r said:


> I have seen my min-to-max cell imbalance value change from 7mV to only 2mV when I finished charging to 90%, which would suggest that balancing is possibly occurring below the typical 100% charging level some basic BMS' seem to do.


I've seen it go from 12mv while driving to 6mv after plugging in, to 2mv after charging from 30% to 70%.


----------



## dsgerbc

Chrism3c said:


> @David King
> I'm new to this board so not able to message you directly but if you or anyone else could send me the TeslaTrac3 app I would like to give it a try.
> 
> Thanks


I'm sure he's being hammered with requests like this. Use the dyno mode instead for now.


----------



## David King

Chrism3c said:


> @David King
> I'm new to this board so not able to message you directly but if you or anyone else could send me the TeslaTrac3 app I would like to give it a try.


I'm not distributing it anymore for liability reasons and to protect similar devices but now that dyno mode is out, no one should really need it, although it is slightly different.


----------



## JWardell

Lots of updates to the DBC in the last few days, including updates to 0x7FF car config, 0x395 0x396 oil pumps, and finally have 0x126 0x1A5 motor V&A.
It looks like there are more can message changes in the last few months. The downside of constant over the air updates.


----------



## joverdijk

Are those updates also being implemented into Scanmytesla & the datapush towards Teslalogger?


----------



## Juggas

JWardell said:


> 0x3F1 VCFront lighting status
> VCFRONT_highBeamLeftStatus 32 33
> VCFRONT_highBeamRightStatus 34 35
> VCFRONT_highBeamSwitchActive 58 58


Hi,

I don´t get any data from 0x3F1 but I have tested 0x72A, 0x318 and get data.
Any ides?

0000072A0138303031415957 8001AYW
0000072A0054473131393132 TG11912
0000031814020A13041B1F8C Year=20 Month=02 Sec=11 Hour=19 Day=04 Min=27


----------



## kornerz

Juggas said:


> Hi,
> 
> I don´t get any data from 0x3F1 but I have tested 0x72A, 0x318 and get data.
> Any ides?
> 
> 0000072A0138303031415957 8001AYW
> 0000072A0054473131393132 TG11912
> 0000031814020A13041B1F8C Year=20 Month=02 Sec=11 Hour=19 Day=04 Min=27


It can be only active while driving, or while headlights are actually on.
On my Model 3, this message is also silent (while at park)


----------



## Juggas

kornerz said:


> It can be only active while driving, or while headlights are actually on.
> On my Model 3, this message is also silent (while at park)


I did not drive but I but it in drive and also turned on the headlights but no data.


----------



## JWardell

Juggas said:


> Hi,
> 
> I don´t get any data from 0x3F1 but I have tested 0x72A, 0x318 and get data.
> Any ides?
> 
> 0000072A0138303031415957 8001AYW
> 0000072A0054473131393132 TG11912
> 0000031814020A13041B1F8C Year=20 Month=02 Sec=11 Hour=19 Day=04 Min=27


It looks like Tesla removed 0x3F1 in recent firmware, my most recent log is missing it but it is in every log before it. Comparing them:

IDs found only in January log
0x00
0x01
0x02
0x025A
0x0276
0x02B4
0x0328
0x037A
0x0388
0x03D9
0x03F5
0x0518
0x0522
0x0527
0x0530
0x0550
0x055D
0x05F4
IDs found only October log
0x0254
0x03F1

They have to keep changing CAN and keep me on my toes...come on Tesla, can't you just send me new DBCs with each firmware change??


----------



## michi84

I have been playing around with VCFront logging 10hz (0x2C1), and got some values working again reasonably:

It looks like some redundant stuff was left out, e.g. for the pump rpms we now have only either target or actual rpm, same for 5-way-valve position.

Here are my suggested updates for the DBC:

BO_ 705 VCFRONT_logging10Hz: 8 ETH
SG_ VCFRONT_logging10HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpBatteryRPM m0: 3|[email protected]+ (10,0) [0|0] "rpm" X
SG_ VCFRONT_pumpPowertrainRPM m0: 13|[email protected]+ (10,0) [0|0] "rpm" X
SG_ VCFRONT_pumpBatteryOutVoltage m0: 23|[email protected]+ (0.1,0) [0|0] "V" X
SG_ VCFRONT_pumpPowertrainOutVoltage m0: 31|[email protected]+ (0.1,0) [0|0] "V" X
SG_ VCFRONT_pumpBatteryInitd m0: 39|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpPowertrainInitd m0: 40|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpBatteryEnabled m0: 41|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpPowertrainEnabled m0: 42|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpBatteryPowerOn m0: 43|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpPowertrainPowerOn m0: 44|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_pumpsWake m0: 45|[email protected]+ (1,0) [0|0] "" X

SG_ VCFRONT_radiatorFanOutVoltage m1: 8|[email protected]+ (0.2,0) [0|0] "V" X
SG_ VCFRONT_radiatorFanRPMTarget m1: 15|[email protected]+ (10,0) [0|0] "rpm" X
SG_ VCFRONT_radiatorFanInitd m1: 26|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_radiatorFanEnabled m1: 27|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_radiatorFanPowerOn m1: 28|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_radiatorFanPhaseCurrent m1: 32|[email protected]+ (0.5,-20) [0|0] "A" X

SG_ VCFRONT_fiveWayValveMode m2: 3|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_coolantTempBasedMode m2: 4|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_fiveWayValveModeWrong m2: 5|[email protected]+ (1,0) [0|0] "" X
SG_ VCFRONT_fiveWayValveAngleActual m2: 8|[email protected]+ (0.25,-100) [0|0] "degrees" X

5-way-valve 100% confirmed and working, also in SMT, radiator fan rpm looks like a target to me. If the voltages are scaled correctly is hard to tell, please have a look at the data yourself. The refrigerant temps are hard to get right,. since i do not know in which ballpark these temperatures should be, and even if i could find a scaling that makes sense at one point, it might still be worthless since the messages could be something else by now.


----------



## JWardell

michi84 said:


> I have been playing around with VCFront logging 10hz (0x2C1), and got some values working again reasonably:
> 
> It looks like some redundant stuff was left out, e.g. for the pump rpms we now have only either target or actual rpm, same for 5-way-valve position.
> 
> Here are my suggested updates for the DBC:
> 
> BO_ 705 VCFRONT_logging10Hz: 8 ETH
> SG_ VCFRONT_logging10HzIndex M: 0|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpBatteryRPM m0: 3|[email protected]+ (10,0) [0|0] "rpm" X
> SG_ VCFRONT_pumpPowertrainRPM m0: 13|[email protected]+ (10,0) [0|0] "rpm" X
> SG_ VCFRONT_pumpBatteryOutVoltage m0: 23|[email protected]+ (0.1,0) [0|0] "V" X
> SG_ VCFRONT_pumpPowertrainOutVoltage m0: 31|[email protected]+ (0.1,0) [0|0] "V" X
> SG_ VCFRONT_pumpBatteryInitd m0: 39|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpPowertrainInitd m0: 40|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpBatteryEnabled m0: 41|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpPowertrainEnabled m0: 42|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpBatteryPowerOn m0: 43|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpPowertrainPowerOn m0: 44|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_pumpsWake m0: 45|[email protected]+ (1,0) [0|0] "" X
> 
> SG_ VCFRONT_radiatorFanOutVoltage m1: 8|[email protected]+ (0.2,0) [0|0] "V" X
> SG_ VCFRONT_radiatorFanRPMTarget m1: 15|[email protected]+ (10,0) [0|0] "rpm" X
> SG_ VCFRONT_radiatorFanInitd m1: 26|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_radiatorFanEnabled m1: 27|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_radiatorFanPowerOn m1: 28|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_radiatorFanPhaseCurrent m1: 32|[email protected]+ (0.5,-20) [0|0] "A" X
> 
> SG_ VCFRONT_fiveWayValveMode m2: 3|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_coolantTempBasedMode m2: 4|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_fiveWayValveModeWrong m2: 5|[email protected]+ (1,0) [0|0] "" X
> SG_ VCFRONT_fiveWayValveAngleActual m2: 8|[email protected]+ (0.25,-100) [0|0] "degrees" X
> 
> 5-way-valve 100% confirmed and working, also in SMT, radiator fan rpm looks like a target to me. If the voltages are scaled correctly is hard to tell, please have a look at the data yourself. The refrigerant temps are hard to get right,. since i do not know in which ballpark these temperatures should be, and even if i could find a scaling that makes sense at one point, it might still be worthless since the messages could be something else by now.


I think VCFront10Hz has been moved over to 201. I have the decoding for that but it will take me a few days.


----------



## All About Jake

Hi Folks,

I have been working on an iOS CANBus visualization tool and I think its time to get some a few more willing test subjects to give it a try. You may have seen a preview of the app in @JWardell 's video a few posts back. The app is definitely a "1.0" release but it is already pretty capable. The app is called "tesLAX" and here's a bit of what the app can do:

1. Customizable "gauges" or widgets for various CANBus signals. A "binary matrix" widget for looking at the raw bits when reverse engineering.
2. Preconfigured database with Model 3, S, and X signals. (Though S/X can use some work as I don't own one for testing, and those guys don't have @JWardell to make a nice, maintained DBC)
3. Ability to interact with common CANbus formats: Ability to import DBC files and playback raw text logs or ASC files from iCloud drive. (no logging yet, I'll get there eventually)
4. Make your own custom scriptable signals using JavaScript. (Can do some pretty powerful stuff with this)
5. Presets for different cars (I'm calling a list of signals and a screen of widgets a "preset" and you can swap back and forth between cars or different sets.)
6. Ability to visualize LIVE CANBus data with an OBDLink MX+ dongle (yes, MX+ is required because of iOS restrictions, no other accessories are supported.)
7. Built using modern iOS development techniques (SwiftUI, Swift Combine) though some of these are very new from Apple and cause some instability at times. YMMV.
8. Gauges track min/max values and can use absolute ranges based on signal DBC definition or auto-range based on these limits.

If you have an OBDLink MX+ wired up into your CANBus and are interested in testing, send me a private message. I'd love some S/X testers if we have any lurking.

I'm working on the next build so I'm expecting to be ready for some testing next week.


----------



## JWardell

All About Jake said:


> Hi Folks,
> 
> I have been working on an iOS CANBus visualization tool and I think its time to get some a few more willing test subjects to give it a try. You may have seen a preview of the app in @JWardell 's video a few posts back. The app is definitely a "1.0" release but it is already pretty capable. The app is called "tesLAX" and here's a bit of what the app can do:
> 
> 1. Customizable "gauges" or widgets for various CANBus signals. A "binary matrix" widget for looking at the raw bits when reverse engineering.
> 2. Preconfigured database with Model 3, S, and X signals. (Though S/X can use some work as I don't own one for testing, and those guys don't have @JWardell to make a nice, maintained DBC)
> 3. Ability to interact with common CANbus formats: Ability to import DBC files and playback raw text logs or ASC files from iCloud drive. (no logging yet, I'll get there eventually)
> 4. Make your own custom scriptable signals using JavaScript. (Can do some pretty powerful stuff with this)
> 5. Presets for different cars (I'm calling a list of signals and a screen of widgets a "preset" and you can swap back and forth between cars or different sets.)
> 6. Ability to visualize LIVE CANBus data with an OBDLink MX+ dongle (yes, MX+ is required because of iOS restrictions, no other accessories are supported.)
> 7. Built using modern iOS development techniques (SwiftUI, Swift Combine) though some of these are very new from Apple and cause some instability at times. YMMV.
> 8. Gauges track min/max values and can use absolute ranges based on signal DBC definition or auto-range based on these limits.
> 
> If you have an OBDLink MX+ wired up into your CANBus and are interested in testing, send me a private message. I'd love some S/X testers if we have any lurking.
> 
> I'm working on the next build so I'm expecting to be ready for some testing next week.


I would be happy to curate a Model S DBC if someone wants to permanently donate a Model S to me 

Jake has been building an awesome app with impressive capabilities, and continuously updating as well. I highly recommend others put it to the test!


----------



## JWardell

Today I realized my latest log has some front inverter messages in them... as we saw with the oil temps, it looks like Tesla swapped front and rear message IDs with several of the inverter messages!
For example I thought the debug message had disappeared long ago, but it had just moved to the front debug ID! I also confirmed it still contained rear-only mux IDs.
This is why I put a lot of work into verifying messages and data and don't just blindly trust other files and generated code.

Also, *can someone please send me a log file from an AWD vehicle from 2020?* I realize the last one I have is from October and some messages have changed since then.

Included are 0x5D7 0x557 Thermal control and coolant messages which were also swapped. I also added back 0x5D5 0x556 which look nearly identical in signals, but the plotted data is different.
I would love others thoughts on what we think 5D5/556 temperatures are measuring. But they clearly come from the inverters.

Go grab the latest DBC, and keep an eye out for more updates this week!


----------



## livehybrid

@JWardell Logs from a M3P any good to you on 2020? What format do you want them in?


----------



## JWardell

livehybrid said:


> @JWardell Logs from a M3P any good to you on 2020? What format do you want them in?


Yes, actually I could really use a log of a quick drive with track mode enabled. Any format that Savvycan opens I can convert.
I will be recording a new log myself today.


----------



## michi84

I can make at recording with Savvycan tomorrow with my AWD on firmwaren 2020.4.1 with acceleration boost. Anything special you want? Full throttle acceleration / dyno mode?


----------



## JWardell

Just found something we have been searching for for a while: *0x33A UI SOC and milage range!!* Looks like it appeared almost a year ago.

UI Rated Range Mi u10 SB 0 scale 1
UI Ideal Range Mi u10 SB 16 scale 1
Rated WH/Mi u10 SB32 scale 1
UI SOE SOC % u7 SB 48 scale 1
UI unfiltered SOE % u7 SB 56 scale 1



michi84 said:


> I can make at recording with Savvycan tomorrow with my AWD on firmwaren 2020.4.1 with acceleration boost. Anything special you want? Full throttle acceleration / dyno mode?


Usually just a small/quick log, with full throttle and regen, is all I would need. Usually just need to verify which messages appear with AWD. Unless we are looking at something specific of course.


----------



## fast_like_electric

JWardell said:


> Just found something we have been searching for for a while: *0x33A UI SOC and milage range!!* Looks like it appeared almost a year ago.
> 
> UI Rated Range Mi u10 SB 0 scale 1
> UI Ideal Range Mi u10 SB 16 scale 1
> Rated WH/Mi u10 SB32 scale 1
> UI SOE SOC % u7 SB 48 scale 1
> UI unfiltered SOE % u7 SB 56 scale 1


Nice find. I would imagine the units (and value) for this change when you switch into metric mode. Probably a metric/english flag bit in there too, or it uses a global setting.

Nice to see confirmation of the 234 Wh / mi figure, at least on the RWD. Annoying that the rated line on the energy display has always been incorrectly high at 240 - you've always needed to be a bit below that line to get rated mileage. I wonder if this number changes based on the relatively new tire size setting, and/or model (AWD, Perf).

The search for estimated / predicted mileage (the number displayed on the right of the energy chart) still continues.


----------



## JWardell

fast_like_electric said:


> Nice find. I would imagine the units (and value) for this change when you switch into metric mode. Probably a metric/english flag bit in there too, or it uses a global setting.
> 
> Nice to see confirmation of the 234 Wh / mi figure, at least on the RWD. Annoying that the rated line on the energy display has always been incorrectly high at 240 - you've always needed to be a bit below that line to get rated mileage. I wonder if this number changes based on the relatively new tire size setting, and/or model (AWD, Perf).
> 
> The search for estimated / predicted mileage (the number displayed on the right of the energy chart) still continues.


I went back through all my logs, it was always at 234. I wish it changed, because I could never dream of getting that...384 is more realistic!


----------



## JWardell

I'm fighting with 0x312 BMS thermals, can a few people take a look at what makes sense? I have two different formats and not sure which is right. I see bits moving where they shouldn't be in both. One is 8 bit and one is 7. So I guess I should stick with the older 8 bit but the data still doesn't make sense. Here are the two options I have...would love if some others could make some sense of the data.

BO_ 786 BMS_thermalStatus: 8 GTW
SG_ BMS_flowRequest : 10|[email protected]+ (0.3,0) [0|0] "LPM" ETH
SG_ BMS_inletActiveCoolTargetT : 17|[email protected]+ (0.25,10) [0|0] "DegC" ETH
SG_ BMS_inletActiveHeatTargetT : 33|[email protected]+ (0.25,-25) [0|0] "DegC" ETH
SG_ BMS_inletPassiveTargetT : 25|[email protected]+ (0.25,0) [0|0] "DegC" ETH
SG_ BMS_noFlowRequest : 63|[email protected]+ (1,0) [0|0] "" ETH
SG_ BMS_pcsNoFlowRequest : 62|[email protected]+ (1,0) [0|0] "" ETH
SG_ BMS_powerDissipation : 0|[email protected]+ (0.02,0) [0|0] "kW" ETH

BO_ 786 BMS_thermalStatus: 7 VehicleBus
SG_ BMS_flowRequest : 16|[email protected]+ (0.3,0) [0|30] "LPM" Receiver
SG_ BMS_inletActiveCoolTargetT : 23|[email protected]+ (0.25,-25) [-25|100] "C" Receiver
SG_ BMS_inletActiveHeatTargetT : 41|[email protected]+ (0.25,-25) [-25|100] "C" Receiver
SG_ BMS_inletPassiveTargetT : 32|[email protected]+ (0.25,-25) [-25|100] "C" Receiver
SG_ BMS_noFlowRequest : 51|[email protected]+ (1,0) [0|1] "" Receiver
SG_ BMS_pcsNoFlowRequest : 50|[email protected]+ (1,0) [0|1] "" Receiver
SG_ BMS_powerDissipation : 0|[email protected]+ (0.02,0) [0|20] "kW" Receiver


----------



## JWardell

Lots of work on the DBC in today's update. Wanted to flesh out all the battery and charging related messages for Mike Edwards and @Collin80 who are troubleshooting battery packs. UI range and some others, also have the cabin heater message. I'm leaving 312 until others can look at it.

0x33A UI SOC and Range
0x333 UI charge status updated
0x334 UI drive settings
0x287 PTC Cabin heater
0x212 BMS Status updated
0x3B2 BMS log
0x320 BMS alerts
0x300 BMS info
0x2C4 PCS logging
0x21D Charge Port EVSE status
0x23D Charge Port status
0x75D Charge Port sensors
0x31C Charging status
0x31D Charging button
0x32C Charging logging
0x241 VCFront coolant updated


----------



## asanyfuleno

Is there a straight forward way to get the current firmware version from the battery pack?


----------



## JWardell

asanyfuleno said:


> Is there a straight forward way to get the current firmware version from the battery pack?


0x300 will give you the build version of the BMS firmware, but that is not the same as the "customer" firmware version of the car.


----------



## michi84

I made some recordings with SavvyCan on firmware 2020.4.1: https://www.dropbox.com/sh/ccr4h8e65701sc6/AABPvqr-az4q-nuEd7czqX8ta?dl=0

Content of the folder:

1) AC On Off.csv: Car in Drive, A/C on/off (for A/C and HVAC stuff decoding)

2) accel.csv: Full throttle acceleration from standstill to about 120 km/h, full regen braking afterwards, then a couple of hundred meters slow driving to standstill

3) Charging scheduled: Car in PARK, plugged in, charging scheduled for 13:00, amp limit set to 16A (three phase charging)

4) Charging start: Car in PARK, opening charge port with remote button on plug, plugging in, charging starts and stabilizes at 16A, three phase charging

5) Charging: a couple of seconds during charging process

6) Charging stopped: Stopping charging via button on screen, plug remains inserted. Afterwards, car is set up for scheduled charging

7) Heat max on off: Car in Drive, temperature set to LO, then to MAX, then back to LO

Remarks: SOC around 30%, so no new power records to be expected. Also, road was wet and cold, there might be slight traction control intervention during acceleration (although i did not see the indicator flashing). Battery was warm (>25°C cell temp).


----------



## JWardell

michi84 said:


> I made some recordings with SavvyCan on firmware 2020.4.1: https://www.dropbox.com/sh/ccr4h8e65701sc6/AABPvqr-az4q-nuEd7czqX8ta?dl=0
> 
> Content of the folder:
> 
> 1) AC On Off.csv: Car in Drive, A/C on/off (for A/C and HVAC stuff decoding)
> 
> 2) accel.csv: Full throttle acceleration from standstill to about 120 km/h, full regen braking afterwards, then a couple of hundred meters slow driving to standstill
> 
> 3) Charging scheduled: Car in PARK, plugged in, charging scheduled for 13:00, amp limit set to 16A (three phase charging)
> 
> 4) Charging start: Car in PARK, opening charge port with remote button on plug, plugging in, charging starts and stabilizes at 16A, three phase charging
> 
> 5) Charging: a couple of seconds during charging process
> 
> 6) Charging stopped: Stopping charging via button on screen, plug remains inserted. Afterwards, car is set up for scheduled charging
> 
> 7) Heat max on off: Car in Drive, temperature set to LO, then to MAX, then back to LO
> 
> Remarks: SOC around 30%, so no new power records to be expected. Also, road was wet and cold, there might be slight traction control intervention during acceleration (although i did not see the indicator flashing). Battery was warm (>25°C cell temp).


Awesome. Smart breaking up into several logs...why don't I do that? I end up with a 100MB+ log of trying to do everything, remembering what I did when, and then it takes 10 minutes for CBA to load it...

I have 312 figured out now, and some more messages on the way. The deeper I look, the more I find Tesla has changed in the last 6-9 months.


----------



## asanyfuleno

We have four 75 kWh battery packs in for testing, well, three 75 kWh and one 62 kWh despite ordering four 75 kWh packs.

Three of the packs are US sourced and one from Norway. All the US ones are RWD only and the Norwegian one AWD.

I believe that the US packs are from earlier cars than the Norwegian pack. Two packs have a rubber surround attached to the pack to seal against the car body whilst two have a gray foam surround that is just dropped over the top of the pack. All three US sourced packs have a white material attached to the top whilst the Norwegian one doesn't and is just black metal surface. 

Different packs appear to have different firmware as offer different information via CAN. We can't test 0x221 messages yet as the pyro fuses have blown but 0x401 works on two of them and not on the other pack we have tested.

Has anyone else noticed any physical changes to the packs or are most people still logging the data with the pack installed in the car?


----------



## livehybrid

JWardell said:


> Yes, actually I could really use a log of a quick drive with track mode enabled. Any format that Savvycan opens I can convert.
> I will be recording a new log myself today.


Sorry - been a hectic week but will pull some out over the next day or so. I see @michi84 has dumped some too.

On a quick side note - Do you know if theres a reliable code to look out for detecting start/end of a journey (Drive/Park I assume is best)?
Thanks


----------



## JWardell

livehybrid said:


> Sorry - been a hectic week but will pull some out over the next day or so. I see @michi84 has dumped some too.
> 
> On a quick side note - Do you know if theres a reliable code to look out for detecting start/end of a journey (Drive/Park I assume is best)?
> Thanks


Sure, that's how Teslafi IDs drives as well.


----------



## JWardell

The DBC is now updated with many signals with nice names in their comment.
Plus a few more messages too.

Original post:
It's getting more and more difficult to keep using my friendlier signal names in the DBC when updating and adding signals, especially when they can't have a space etc.
I'm thinking of adding a second friendly name for popular signals in the comment field, perhaps followed by a dash comma and then a further comment if needed.
So next to BMS_minPackTemperature we can have Min Batt Temp or even just Battery Temp
Then the apps like ScanMyTesla, CBA, SavvyCAN, etc can display those names on screen or in the graphs. Would be nice for new folks anyway.
I also plan to do some videos soon walking through some signals.
Thoughts? @amund7 @Collin80


----------



## Collin80

JWardell said:


> It's getting more and more difficult to keep using my friendlier signal names in the DBC when updating and adding signals, especially when they can't have a space etc.
> I'm thinking of adding a second friendly name for popular signals in the comment field, perhaps followed by a dash comma and then a further comment if needed.
> So next to BMS_minPackTemperature we can have Min Batt Temp or even just Battery Temp
> Then the apps like ScanMyTesla, CBA, SavvyCAN, etc can display those names on screen or in the graphs. Would be nice for new folks anyway.
> I also plan to do some videos soon walking through some signals.
> Thoughts? @amund7 @Collin80


Yeah, you could put better names in the comment field. Currently nothing is done with the comments but I could use them elsewhere. I assume you're aware that DBC items like nodes, files, signals can have attributes attached to them. I use some attributes in SavvyCAN to allow for setting the color for DBC signals so that you can color code different signals. I had some problems with that which are now corrected (things would come out black on black which is not very nice). You could create a custom attribute like FriendlyName and then attach it to nodes, messages, signals. This would be the "correct" way to do it probably but does suffer from the problem that most DBC readers will pretty much ignore attributes they don't understand. SavvyCAN has that problem. If you load a DBC file, edit it, and save it in SC you'll lose any info it didn't care enough about to interpret. So, I think the idea to put friendly names in the comment field is probably the safest and most likely to be read properly. But, even still, apps would have to be coded to pay attention to it so it isn't appreciably different from using attributes in that respect.


----------



## JWardell

Collin80 said:


> Yeah, you could put better names in the comment field. Currently nothing is done with the comments but I could use them elsewhere. I assume you're aware that DBC items like nodes, files, signals can have attributes attached to them. I use some attributes in SavvyCAN to allow for setting the color for DBC signals so that you can color code different signals. I had some problems with that which are now corrected (things would come out black on black which is not very nice). You could create a custom attribute like FriendlyName and then attach it to nodes, messages, signals. This would be the "correct" way to do it probably but does suffer from the problem that most DBC readers will pretty much ignore attributes they don't understand. SavvyCAN has that problem. If you load a DBC file, edit it, and save it in SC you'll lose any info it didn't care enough about to interpret. So, I think the idea to put friendly names in the comment field is probably the safest and most likely to be read properly. But, even still, apps would have to be coded to pay attention to it so it isn't appreciably different from using attributes in that respect.


Yes, that's the idea. Forgot about attributes. Laughable that even Vector uses attributes for a ton of things like cycle time, but DBC editor has no knowledge of what they are or let you edit half of it. Clearly they just slapped on features over time. And that's right, I'm always worried about things being compatible and surviving. 
I've seen other commercial DBCs with English names in the comment for each signal, so I thought was the best idea. Useful even if you are just reading through the editor. But as I said if a few apps start making use of it, then all the better.
That and I'm still bugging both of you for the ability to easily view states over time...


----------



## Evasiv3

So I've been working on a little personal project here at work this year to better understand hardware and CAN processing. First goal was to communicate with 4 different screens on 2 different communication buses effectively, then start adding functionality by consuming CAN data. It's still a work in progress with a lot left to tidy up, but it's been a lot of fun thus far and I really appreciate all the time and dedication everyone here has contributed to this thread. I'll be making a custom PCB and 3d printing a steering wheel mount in the next few months to make it more usable in the car. Right now I've got it tucked in between the wireless charger and the console.

It currently works as a live display and a datalogger (red button). This is all powered by a Teensy 3.6 and Arduino. The screens are SSD1306 0.91" White OLED, and SSD1351 1.5" RGB OLED. Will be adding in the diode and trace cut on the Teensy shortly so it can run fully on OBD power with the LM2596 buck converter (mid-right in picture).


----------



## JWardell

Evasiv3 said:


> So I've been working on a little personal project here at work this year to better understand hardware and CAN processing. First goal was to communicate with 4 different screens on 2 different communication buses effectively, then start adding functionality by consuming CAN data. It's still a work in progress with a lot left to tidy up, but it's been a lot of fun thus far and I really appreciate all the time and dedication everyone here has contributed to this thread. I'll be making a custom PCB and 3d printing a steering wheel mount in the next few months to make it more usable in the car. Right now I've got it tucked in between the wireless charger and the console.
> 
> It currently works as a live display and a datalogger (red button). This is all powered by a Teensy 3.6 and Arduino. The screens are SSD1306 0.91" White OLED, and SSD1351 1.5" RGB OLED. Will be adding in the diode and trace cut on the Teensy shortly so it can run fully on OBD power with the LM2596 buck converter (mid-right in picture).
> 
> View attachment 32311


Love it! So many great little OLED displays out there to have fun with now. Love that joystick too.
One of these days I'll actually finish one of my projects instead of just starting new ones


----------



## kornerz

As we're talking about personal setups, here's a sneak peek of my own dashboard.

Hardware is Raspberry Pi 3 B+ and $2 MCP2515 CAN interface module.
Frontend is displayed in a simple WebSockets-driven html page, which (to my surprise) is capable of rendering more than 600 item value changes per second,
making the dashboard fast and fluid, with latency measured in milliseconds.

Once software is a bit more polished, I'll be making a separate post with full details on how to it works.





Edit: added how the device itself looks.


----------



## All About Jake

kornerz said:


> Frontend is displayed in a simple WebSockets-driven html page


Very nice. I wish there was a way to get a device on the M3's local network so you didn't have to bounce off a hotspot or cellular link.


----------



## kornerz

All About Jake said:


> Very nice. I wish there was a way to get a device on the M3's local network so you didn't have to bounce off a hotspot or cellular link.


It is not bounced.
Yes, Tesla browser is blocked from accessing private networks (192.168.x.x, 10.x.x.x etc).
However, in my case Raspberry Pi is acting as Wi-Fi AP with a small not widely used public IP subnet (so Raspberry is at 75.101.xx.1 address, and clients get 75.101.xx.20-100 addresses).
So as a result Tesla browser is happy to access local page with "non-private" IP address.

As for the hotspot - I need it anyway, because there is no Tesla LTE coverage in our country yet.


----------



## All About Jake

TIL... cool. I'll have to try that.


----------



## JWardell

kornerz said:


> As we're talking about personal setups, here's a sneak peek of my own dashboard.
> 
> Hardware is Raspberry Pi 3 B+ and $2 MCP2515 CAN interface module.
> Frontend is displayed in a simple WebSockets-driven html page, which (to my surprise) is capable of rendering more than 600 item value changes per second,
> making the dashboard fast and fluid, with latency measured in milliseconds.
> 
> Once software is a bit more polished, I'll be making a separate post with full details on how to it works.
> 
> 
> 
> 
> 
> Edit: added how the device itself looks.


Still so impressive! Totally worth a bit of data usage if you had to use your own data plan, could just pop a free google fi data sim in there.

You guys are really giving me a run here, I need to break through the software barriers that are keeping me from finishing my projects. That's plural


----------



## michi84

Does anyone get signals on IDs 31C (CC_chgStatus ), 31D (CC_chgStatus2) and 32C (CC_logData)? I get nothing here on my EU Model 3 AWD, not during charging or in Drive or Park.

Also, for some reason

CP_pinTemperature2 m1 : 16|[email protected]+ (0.8039215686,-55) [-55|149.99] "C" Receiver

on ID 75D gives me very low values, around -40 something.

However, changing the offset to zero seems to bring this value in line with the two other pins. I need to to some more verification during charging. Also, i am planning to try if i can find out which pin is which be warming them up or colling them separately while watching the live data.

Also, does anyone get reasonable A/C compressor rpms on VCFront logging 1hz? Mine always shows 1800 rpm even with the compressor off.


----------



## JWardell

michi84 said:


> Does anyone get signals on IDs 31C (CC_chgStatus ), 31D (CC_chgStatus2) and 32C (CC_logData)? I get nothing here on my EU Model 3 AWD, not during charging or in Drive or Park.
> 
> Also, for some reason
> 
> CP_pinTemperature2 m1 : 16|[email protected]+ (0.8039215686,-55) [-55|149.99] "C" Receiver
> 
> on ID 75D gives me very low values, around -40 something.
> 
> However, changing the offset to zero seems to bring this value in line with the two other pins. I need to to some more verification during charging. Also, i am planning to try if i can find out which pin is which be warming them up or colling them separately while watching the live data.
> 
> Also, does anyone get reasonable A/C compressor rpms on VCFront logging 1hz? Mine always shows 1800 rpm even with the compressor off.


Yes, I get those when charging at home with the mobile connector. Maybe they aren't there if you are using a different charger?
I only put signals in my DBC if I confirm I get the message and get good data.
So many other messages I wish we saw, or are just filled with zeros.


----------



## michi84

I use a goEcharger wallbox, will try the UMC next time to see if that is the reason. Could be, since there shoud be some extra CAN communication with the tesla charger. I have actually never used the UMC, i dont even know if it works, since i use my three phase wallbox from day one.


----------



## Evasiv3

I'm not sure if this has been discussed or shown already, but has anyone found a way to display the instantaneous Wh/mi from the bus. I don't see it directly available in the DBC, so I'd imagine it's a basic calculation of kW used over a sample of mileage from the odometer? If anyone has this I'd love to add it to my display at a much more frequent rate than what the car shows.

Thanks!


----------



## kornerz

Evasiv3 said:


> I'm not sure if this has been discussed or shown already, but has anyone found a way to display the instantaneous Wh/mi from the bus. I don't see it directly available in the DBC, so I'd imagine it's a basic calculation of kW used over a sample of mileage from the odometer? If anyone has this I'd love to add it to my display at a much more frequent rate than what the car shows.
> 
> Thanks!


I've tried that, it's too jumpy as an instant stat - either too high when you press accelerator, or negative when you release it.

As for actual formula - you can get battery power by multiplying voltage and current in message #132.
Also you can get current speed from #257.

And when you divide power (Watts) by speed (mi/hour) you will literally get Watt * Hour / Mile, or efficiency.


----------



## JWardell

Well I'm tired of waiting around and keeping this awesome app from @All About Jake to myself...check out his new iPhone app:






Not in the App Store just yet but I bet he would love some more help testing it!


----------



## michi84

Would this run with an IOS emulator on android? No iPhone or iPad in the house (yet).


----------



## dodan2

First of all, I really appreciate all the information posted/shared on this thread. Really helpful for my small project to build HUD with RPi.
I wonder if anybody has found CAN msg for the blind-spot warning while changing lane (regardless of auto-pilot/FSD)
I'm trying to display blind-spot warning on HUD and flasing LED near side-mirror.

Thanks!


----------



## JWardell

dodan2 said:


> First of all, I really appreciate all the information posted/shared on this thread. Really helpful for my small project to build HUD with RPi.
> I wonder if anybody has found CAN msg for the blind-spot warning while changing lane (regardless of auto-pilot/FSD)
> I'm trying to display blind-spot warning on HUD and flasing LED near side-mirror.
> 
> Thanks!


I love the idea. Chances are it's all done internally in the autopilot computer though. There are some UI messages that are defined for various AP UI elements but I have never found them transmitted. Then again, we still don't know what half the can messages are.


----------



## dodan2

JWardell said:


> I love the idea. Chances are it's all done internally in the autopilot computer though. There are some UI messages that are defined for various AP UI elements but I have never found them transmitted. Then again, we still don't know what half the can messages are.


Right. if it is handled internally by autopilot computer, they might not send any msg on the bus.
Hope they add blind-spot warning LED later (on new model?) and send the corresponding msg on the CAN bus.

Thanks!


----------



## MartinP

Wow, it was really fun to read the thread and seeing the explorer stuff, waiting on harnesses, analyzing the CAN bus.....
So I ordered the MX+, a harness for my 2019 M3 (blue connectors) and am now waiting for them.....
In the meantime, some questions arise...

1. When going to a service centre with the car, does one completely remove the harness and OBD or only the OBD tool, like for me the MX+?
2. Looking at code, I like the CANBUS Analyzer, however, the download from github seems to not have the DBCLib.csproj and related files. Do I need to get them from somewhere else? Searching this thread for DBCLib does not find anything. I did find https://github.com/jacobtonder/DBCLib but that does not work with the latest version of CANBUS Analyzer.

My goal is to filter odometer (0x3B6) and feed it to my application (C#) to calculate the current average speed since start. We drive a kind of hobby rally where 42km needs to be the average speed at a number of checkpoints. Using the Odometer and time from the PC I am able to calculate that (accounting for driving wrong, correcting the M3 odometer against the organization delivered distances).


----------



## kornerz

MartinP said:


> My goal is to filter odometer (0x3B6) and feed it to my application (C#) to calculate the current average speed since start.


If odometer is the only value you need - Tesla Owner API provides odometer as fractional miles (e.g. [odometer] => 35960.160312 ), updated every minute.
See https://tesla-api.timdorr.com/vehicle/state/data for more details


----------



## mattiasclaesson

All About Jake said:


> Hi Folks,
> 6. Ability to visualize LIVE CANBus data with an OBDLink MX+ dongle (yes, MX+ is required because of iOS restrictions, no other accessories are supported.)
> 
> If you have an OBDLink MX+ wired up into your CANBus and are interested in testing, send me a private message. I'd love some S/X testers if we have any lurking.


Hi,

Are you sure that a OBD LELink^2 would not be able to work? I can test if you want.
That adapter is working just fine with TM-Spy on iOS and our model 3.
Do you have it on TestFlight?

/Mattias


----------



## JWardell

MartinP said:


> Wow, it was really fun to read the thread and seeing the explorer stuff, waiting on harnesses, analyzing the CAN bus.....
> So I ordered the MX+, a harness for my 2019 M3 (blue connectors) and am now waiting for them.....
> In the meantime, some questions arise...
> 
> 1. When going to a service centre with the car, does one completely remove the harness and OBD or only the OBD tool, like for me the MX+?
> 2. Looking at code, I like the CANBUS Analyzer, however, the download from github seems to not have the DBCLib.csproj and related files. Do I need to get them from somewhere else? Searching this thread for DBCLib does not find anything. I did find https://github.com/jacobtonder/DBCLib but that does not work with the latest version of CANBUS Analyzer.
> 
> My goal is to filter odometer (0x3B6) and feed it to my application (C#) to calculate the current average speed since start. We drive a kind of hobby rally where 42km needs to be the average speed at a number of checkpoints. Using the Odometer and time from the PC I am able to calculate that (accounting for driving wrong, correcting the M3 odometer against the organization delivered distances).


I believe it needs DBCtools from BrianMan https://brianman.visualstudio.com/DBCTools/_git/DBCTools
@amund7 would have to answer for sure



mattiasclaesson said:


> Hi,
> 
> Are you sure that a OBD LELink^2 would not be able to work? I can test if you want.
> That adapter is working just fine with TM-Spy on iOS and our model 3.
> Do you have it on TestFlight?
> 
> /Mattias


If it works with iOS than it will probably work. Ask @All About Jake to invite you on TestFlight


----------



## All About Jake

JWardell said:


> If it works with iOS than it will probably work. Ask @All About Jake to invite you on TestFlight


Right now, I'm focused on the MX+. BLE dongles maybe in the future. I have many other things I'm interested in completing first. Does anyone make a STN1100 chipset with BLE?


----------



## MartinP

kornerz said:


> If odometer is the only value you need - Tesla Owner API provides odometer as fractional miles (e.g. [odometer] => 35960.160312 ), updated every minute.
> See https://tesla-api.timdorr.com/vehicle/state/data for more details


Hi Kornerz, thanks for the reply! Yes, I tried that. Last years rally I used the API to continuously get the odometer that way. A few things did not work out though. I need the data every second or so because we never know where the checkpoints are. That did not work, especially in the Ardennes area (the rally goes through The Netherlands, Germany, Belgium and Luxembourg), in two ways.

First, the car could not connect to Tesla in that area so my odometer kilometers received through the API gave the same value for sometimes even 15 minutes. 
Realizing that the car did not connect I switched to WiFi with my phone as a hotspot for the car. But even my phone was not able to be connected continuously as well, although a bit better compared to the car's connectivity, so we ended up without any information on our average speed for quite some time. And of course, as luck would have it, we encountered a few checkpoints during that period with no idea what would be the right time to hit the checkpoint.

So directly after that weekend (it lasts two days) I went looking for another way of registering the odometer. At that time there was little to no info on what we have today, so I looked into adding my own sensor somewhere in the car to capture distance. However, I could not find an offering where such a sensor is connected to my PC and the necessary software/drivers, preferably in C#, so that I could get those values.

In my ICE car we drove this rally for more than 20 years where my car's sensor on the rear axle output was fed into a small circuit board taken from a video recorder that controlled jitter which was modified by a friend of mine to give 5V block output. That was fed into the LPT1 port of a very old laptop running DOS where my COBOL program counted the paper out switches as a way to calculate distance and based on that the average speed. We succeeded once to place first! Those times are gone.....


----------



## MartinP

JWardell said:


> I believe it needs DBCtools from BrianMan https://brianman.visualstudio.com/DBCTools/_git/DBCTools
> @amund7 would have to answer for sure


JWardell, thanks, that did the trick, the main window opens now of the CANBUS analyzer, great! One more step done......... 
I loaded one of the asc files from your opening post and saw one 0x3B6 packet in there (CAN log from 2019.32.11 v10 ).


----------



## mattiasclaesson

All About Jake said:


> Right now, I'm focused on the MX+. BLE dongles maybe in the future. I have many other things I'm interested in completing first. Does anyone make a STN1100 chipset with BLE?


Ok! 
I do have a usb connected OBDLink SX, that one also have the STN1100 chipset.
But I am sure that iOS unfortunately does not support USB OTG. 
Also it would require some changes to the code (I think).

/M


----------



## JWardell

Forgot to post my first signals video explaining power, torque, and voltage signals. More to come soon!


----------



## dburkland

JWardell said:


> Forgot to post my first signals video explaining power, torque, and voltage signals. More to come soon!


This looks really cool, nice work! Do you need any beta testers for the app?


----------



## JWardell

Here's another video showing how the car preconditions and heats up the battery:






You'll notice lots of awesome upgrades to the gauges in TesLax, despite still waiting for App Store approval @All About Jake has been cranking out tons of great new features!


----------



## Feathermerchant

Very informative video. Thanks.
Is that App only Apple or just not available yet?


----------



## MartinP

So my OBDLINK MX+ is attached, ScanMyTesla is spewing out logs, now for the next stage, getting 3B6 (odometer) myself in my c# code. Still looking around, did not find any usable code examples yet for filtering only the 3B6 messages.
There is an app that comes with the OBDLINK (for my Android phone) which I cannot get to connect to the car. It connects to the device, but car, no.
Anyone else any experience with that? Or does that app just don't like my Model 3?


----------



## Redox

Hi,
First of all thanks for your interesting work here !

I'm trying to build a logger on a RPi Zero W, using this simple script : https://redox.fr/highlight.php?file=obdtesla.py
Every 30s it saves the file and another script upload data files in /tmp to my server that interprets the raw data.

When driving, the STM command finishes by the "BUFFER FULL" messages, ending with ~500kB of log per 30s, I suppose that it's because of the 115200 baudrate.

So I've tried using an higher baudrate (2500000) by setting the port to this rate and sending STSBR 2500000 command, that is accepted.
But I still get ~500k logs per 30s.
I've checked the baudrate with stty shell command, it was the one requested.

I've also tried obdii_blue script included with can4eve to redirect CAN traffic to IP, I get the same result.

Do you have an idea or a better solution to suggest me ?

Edit : I forgot, it's an OBDLink LX... It was in 4.51 fw version, I updated it to the latest (4.6.1), the result is the same. Also, it seems that sometimes it crashes, even when there isn't any BUFFER FULL error... I need to unplug/replug it to get it back !


----------



## cyntrex

Someone on here was talking about a racing hud display, for taking your car on the track and having all the vehicle data on screen. Tesla just added this to the newest update along with laptimers. I heard the name Trackmode v2. I have a M3 Performance, is anyone interested in a demo video?


----------



## cyntrex

cyntrex said:


> Someone on here was talking about a racing hud display, for taking your car on the track and having all the vehicle data on screen. Tesla just added this to the newest update along with laptimers. I heard the name Trackmode v2. I have a M3 Performance, is anyone interested in a demo video?


Ok, so I did a quick test run of Trackmode v2 this morning and it seems it saves a video of every lap as a single file, given you have a folder named 'TeslaTrackMode" at the root of your USB-Drive, enabled the recording feature in the new Trackmode settings menu and also set up a Start-Finish-Line using your Display.

Sadly, we don't get any automatically overlayed data to the saved lap files, we just get a .csv file with all the data logged since the activation of the current Trackmode session.
I was in the process of creating a nice tool in python to easily load and visualize the data, but got stuck in the process. If I find time, I'll see if I can release some working tool.

Heres a list of all the data that is currently logged and written to the .csv:

Lap
Elapsed Time (ms)
Speed (MPH)
Latitude (decimal)
Longitude (decimal)
Lateral Acceleration (m/s^2)
Longitudinal Acceleration (m/s^2)
Throttle Position (%)
Brake Pressure (bar)
Steering Angle (deg)
Steering Angle Rate (deg/s)
Yaw Rate (rad/s)
Power Level (KW)
State of Charge (%)
Tire Pressure Front Left (bar)
Tire Pressure Front Right (bar)
Tire Pressure Rear Left (bar)
Tire Pressure Rear Right (bar)
Brake Temperature Front Left (% est.)
Brake Temperature Front Right (% est.)
Brake Temperature Rear Left (% est.)
Brake Temperature Rear Right (% est.)
Front Inverter Temp (%)
Rear Inverter Temp (%)
Battery Temp (%)
Tire Slip Front Left (% est.)
Tire Slip Front Right (% est.)
Tire Slip Rear Left (% est.)
Tire Slip Rear Right (% est.)

New Trackmode v2 interface:
[IMG='width:983px;']https://www.teslarati.com/wp-content/uploads/2020/03/tesla-track-mode-tire-temp-scaled.jpg[/IMG]

Some data I captured, graphed ugly:


----------



## MartinP

Redox said:


> Hi,
> First of all thanks for your interesting work here !
> 
> I'm trying to build a logger on a RPi Zero W, using this simple script : https://redox.fr/highlight.php?file=obdtesla.py
> Every 30s it saves the file and another script upload data files in /tmp to my server that interprets the raw data.
> 
> Do you have an idea or a better solution to suggest me ?
> 
> Edit : I forgot, it's an OBDLink LX... It was in 4.51 fw version, I updated it to the latest (4.6.1), the result is the same. Also, it seems that sometimes it crashes, even when there isn't any BUFFER FULL error... I need to unplug/replug it to get it back !


You could try to limit the filters set in the python script, maybe even down to one to see what happens. If that works slowly build it up to more filters, until....
Just got my first filtered messages today, so noob here.....


----------



## JWardell

MartinP said:


> So my OBDLINK MX+ is attached, ScanMyTesla is spewing out logs, now for the next stage, getting 3B6 (odometer) myself in my c# code. Still looking around, did not find any usable code examples yet for filtering only the 3B6 messages.
> There is an app that comes with the OBDLINK (for my Android phone) which I cannot get to connect to the car. It connects to the device, but car, no.
> Anyone else any experience with that? Or does that app just don't like my Model 3?


There is no OBD data in the Model 3, only CAN, so most OBDlink apps won't communicate with it. As far as I know, only scanmytesla or Torque. But if you are doing your own code the OBDlink commands are fairly easy to set up a filtered message.



cyntrex said:


> Ok, so I did a quick test run of Trackmode v2 this morning and it seems it saves a video of every lap as a single file, given you have a folder named 'TeslaTrackMode" at the root of your USB-Drive, enabled the recording feature in the new Trackmode settings menu and also set up a Start-Finish-Line using your Display.
> 
> Sadly, we don't get any automatically overlayed data to the saved lap files, we just get a .csv file with all the data logged since the activation of the current Trackmode session.
> I was in the process of creating a nice tool in python to easily load and visualize the data, but got stuck in the process. If I find time, I'll see if I can release some working tool.
> 
> Heres a list of all the data that is currently logged and written to the .csv:
> 
> Lap
> Elapsed Time (ms)
> Speed (MPH)
> Latitude (decimal)
> Longitude (decimal)
> Lateral Acceleration (m/s^2)
> Longitudinal Acceleration (m/s^2)
> Throttle Position (%)
> Brake Pressure (bar)
> Steering Angle (deg)
> Steering Angle Rate (deg/s)
> Yaw Rate (rad/s)
> Power Level (KW)
> State of Charge (%)
> Tire Pressure Front Left (bar)
> Tire Pressure Front Right (bar)
> Tire Pressure Rear Left (bar)
> Tire Pressure Rear Right (bar)
> Brake Temperature Front Left (% est.)
> Brake Temperature Front Right (% est.)
> Brake Temperature Rear Left (% est.)
> Brake Temperature Rear Right (% est.)
> Front Inverter Temp (%)
> Rear Inverter Temp (%)
> Battery Temp (%)
> Tire Slip Front Left (% est.)
> Tire Slip Front Right (% est.)
> Tire Slip Rear Left (% est.)
> Tire Slip Rear Right (% est.)
> 
> New Trackmode v2 interface:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Some data I captured, graphed ugly:
> View attachment 32649


It's so awesome that Tesla did this. I assume there will be plenty of apps out soon enough to overlay the data over the video.


----------



## nem3

Hi all, I've been working on an iOS app for the Model S/X for the last few months and am getting around now to adding Model 3 support. Have stumbled across an issue I'm hoping some can help with. From what I'm reading 0x401 was removed completely? Is this still the case or is there now a replacement that's similar to 0x6F2 on the S/X?. I use this to retrieve cell voltage, compute balance and display cell temps. See bottom row in attached pic.


----------



## MartinP

nem3 said:


> Hi all, I've been working on an iOS app for the Model S/X for the last few months and am getting around now to adding Model 3 support. Have stumbled across an issue I'm hoping some can help with. From what I'm reading 0x401 was removed completely? Is this still the case or is there now a replacement that's similar to 0x6F2 on the S/X?. I use this to retrieve cell voltage, compute balance and display cell temps. See bottom row in attached pic.


This is a part of a 13 minute raw dump from ScanMyTesla with 2020.4.1 from my Model 3 LR AWD. I took some data before and after the 401. I saw it in those 13 minutes only once without data. Don't know if it is a real CAN message or just noise.
Let me know if you need something else.

2E5000004320200DD 
2E5000004320200DD00
2C138E82014943F0000
2660400052305003D01
118550285181D800000
1D521E87F010000E03F
1327B99C 
AFFA426FF0F 
1D821E3025C000080BB
129672E63657920FF3F
2E5000004320200DD00
2660400062305003D01
118560385181D800000
2579DEA260A2A000000
1D521E87F000000005E
1327C99C7FF8E26FF0F
1D821DB02580000A0CF
129D72F6A657A20FF3F
2E500 
2E5000004320200DD00
2C10100001428006400
2660300052305003D01
118570485181D800000
261C51A4A04BF7F6 
401 
1D521E87F000000207E
1327F99C8FF9626FF0F
1D821D402540000C0E4
129842071657D20FF3F
2E5000004320200DD00
3812AFFBFFDFDBF2400
2660200052205003D01
20C00A0400A000000 
118580585181D800000
2579EEB260A2A000000
1D521E87F000000409E
1328299C9FFA326FF0F
1D821CD024E0000E0F7
1297F2178657F20FF3F
2E5000004320200DD00
2C102AB835100650100
396013232333D19227D
186A95CFFA9FF1C0300
2660200042205003D01
118590685181D800000
1D521E87FFD1F0060DA
1328799CAFFAE26FF0F
1D821C8024B0000000F
129CE227F658320FF3F
2E5000004320200DD00
2660200042204003D01
118 
1185A0785181D800000


----------



## MartinP

JWardell said:


> There is no OBD data in the Model 3, only CAN, so most OBDlink apps won't communicate with it. As far as I know, only scanmytesla or Torque. But if you are doing your own code the OBDlink commands are fairly easy to set up a filtered message.


Thanks, it feels like I am slowly learning this. However, I could do that in just a few weeks, it feels I am but a dwarf standing on the shoulders of giants . Because of you and all the other giants in this thread!
I used a terminal program to connect to the OBDLINK and was able to filter the messages that I want!


----------



## kornerz

nem3 said:


> From what I'm reading 0x401 was removed completely?


Can confirm, 0x401 is no longer present in CAN data.
The closest I have to it is 0x332 BattCellMinMax, which lists max and min cell temperature and voltage:


Code:


ID332BMS_bmbMinMax(
    BMS_bmbMinMaxMultiplexer: 'BMB_VOLT_MUX1',
    BMS_brickVoltageMax: 3.794 V,
    BMS_brickVoltageMin: 3.79 V,
    BMS_brickNumVoltageMax: 19,
    BMS_brickNumVoltageMin: 3
)
  can0  332   [6]  0C 06 86 85 00 00 ::
ID332BMS_bmbMinMax(
    BMS_bmbMinMaxMultiplexer: 'BMB_THERM_MUX0',
    BMS_thermistorNumTMax: 3,
    BMS_thermistorNumTMin: 6,
    BMS_thermistorTMax: 27.0 DegC,
    BMS_thermistorTMin: 26.5 DegC
)


----------



## MartinP

These 332's are in my logs. Out of order because of sort...
332
332
3320100DD00
332011FB9073025
3320120FE07301A
3320120FF073223
332052000081523
332052000085E1A
332092001085C23
3320920FF07301A
3320D200108301A
3320D2002083217
332112003081523
332140
33214006
33214006F6
33214006F6
33214006F6D
33214006F6D
33214006F6D000
33214006F6D0000
33214006F6D0000
33214006F6D0000

I also have some log files with CAN data and readable ScanMyTesla csv logging, let me know if you want that.


----------



## nem3

@MartinP @kornerz Fantastic, thank you. This does help with most of what I need.


----------



## amund7

cyntrex said:


> Trackmode v2
> 
> Heres a list of all the data that is currently logged and written to the .csv:
> 
> Speed (MPH)
> Throttle Position (%)
> Steering Angle (deg)
> Steering Angle Rate (deg/s)
> Power Level (KW)
> State of Charge (%)
> Brake Temperature Front Left (% est.)
> Brake Temperature Front Right (% est.)
> Brake Temperature Rear Left (% est.)
> Brake Temperature Rear Right (% est.)
> Front Inverter Temp (%)
> Rear Inverter Temp (%)
> Battery Temp (%)


Seems like they are learning from us


----------



## Redox

MartinP said:


> You could try to limit the filters set in the python script, maybe even down to one to see what happens. If that works slowly build it up to more filters, until....


Yep I've removed every 100Hz filters, keeping only 1Hz, 10Hz and 50Hz (speed) and it's working fine ! Thanks ! 

Also, I'm trying to log GPS coordinates (STFAP 04F,7FF) and tire pressures/temp (STFAP 31F,7FF) but I get no result, am I filtering the wrong IDs ?


----------



## fast_like_electric

Redox said:


> Also, I'm trying to log GPS coordinates (STFAP 04F,7FF) and tire pressures/temp (STFAP 31F,7FF) but I get no result, am I filtering the wrong IDs ?


Those are unfortunately only on the chassis CAN bus, not the vehicle CAN bus.


----------



## All About Jake

Hi folks. tesLAX, the CANBus visualizer you've seen in @JWardell 's videos, is now available on the AppStore.

https://apps.apple.com/us/app/teslax-canbus-explorer/id1495403139

I've also created an issue tracker for folks to provide feedback here: https://github.com/tesLAXApp/tesLAX/issues

I have much more planned, but the app is really just for my own learning and development fun... Real life takes precedence. No promises, warranties, or guarantees. . Hope people enjoy using it as much as I've enjoyed making it.


----------



## Mr.K

Great, can finally get rid of my spare android phone. But it looks like the OBDLink MX+ adapters are sold out.


----------



## JWardell

Mr.K said:


> Great, can finally get rid of my spare android phone. But it looks like the OBDLink MX+ adapters are sold out.


Check on scantool.net as well as eBay. I paid $30 less for mine on eBay as "factory serviced" and it came good as new from scan tool in two days


----------



## Redox

fast_like_electric said:


> Those are unfortunately only on the chassis CAN bus, not the vehicle CAN bus.


Ok ! Thanks ! Fun that the elevation is on the vehicle bus and not the lat/long although everything comes from the GPS...
I will use the GPS data from the API with the timestamp it provides to keep the data in sync.


----------



## fast_like_electric

Redox said:


> Ok ! Thanks ! Fun that the elevation is on the vehicle bus and not the lat/long although everything comes from the GPS...


The CAN message / bus allocations have to do with what modules need the information - a producer / consumer model. What Tesla calls the 'vehicle' CAN bus is what is traditionally known as the powertrain bus. For proper operation, those related powertrain systems don't care where you are on globe, so GPS coordinates would not be relevant for that bus. However, something like elevation may be important for any drivetrain / cooling system where variations in atmospheric pressure are important.

As these buses are very busy and bandwidth and performance is critical, messages that have no consumer would not be transmitted on a given bus. At least that is how things start out in the design of such a system, and is continually evaluated as new messages are added. You can get pretty involved with message id allocation and message rates to have very predictable timing behavior on these CAN systems. We are only observers, a lot goes into the messaging architecture design.


----------



## MartinP

Redox said:


> I will use the GPS data from the API with the timestamp it provides to keep the data in sync.


Beware that the API suffers from 2 flaws, connectivity from the car to Tesla, and from Tesla to you. Going through the Ardennes made that clear for us. If you have good connectivity for both you are ok.


----------



## bexc

I saw some messages much earlier in this discussion about creating a board that would be small enough to fit inside the panel where the CAN bus is. Specifically, the messages I saw suggested using something like an Adafruit HUZZAH32 Feather.
I was wondering if anyone ever went ahead with that idea? The EVTV CANDue board is nice, but just a little too big to fit into the panel (with all of the casing removed), and my soldering skills are atrocious so I've failed to build a board myself. I was hoping somebody would have boards they could sell, or instructions for buying one?


----------



## JWardell

bexc said:


> I saw some messages much earlier in this discussion about creating a board that would be small enough to fit inside the panel where the CAN bus is. Specifically, the messages I saw suggested using something like an Adafruit HUZZAH32 Feather.
> I was wondering if anyone ever went ahead with that idea? The EVTV CANDue board is nice, but just a little too big to fit into the panel (with all of the casing removed), and my soldering skills are atrocious so I've failed to build a board myself. I was hoping somebody would have boards they could sell, or instructions for buying one?


I will have an ESP32 mounted in an OBD connector (any day now, I swear), which should fit, and my older traction control injector fit an Arduino pro into an even smaller one.
I do very much plan to make more of these in at least small numbers once I design a PCB, but I could always hand make a few first


__ https://twitter.com/i/web/status/1219440781750128641


----------



## jackbauer

If its any benefit to anyone here are can captures from a 2019 M3 rear inverter on the bench on its own with no motor:
https://github.com/damienmaguire/Tesla-Model-3-Drive-Unit/tree/master/CAN_Logs


----------



## asanyfuleno

After obtaining a few Model 3 battery packs recently we've been struggling to get them to function as expected. You may recall an earlier post about how they were all RWD 75 kWh which makes them early models.

We noticed on all of them that the AC charge port, next to the DC charge point just had a blank cover and no port. Today we hired a brand new 2020 Model 3 and found that there is an AC charge port on these models.

Just to complicate matters, the software that has consistently failed to switch the contactors on our other packs managed to switch the pack in the car with no problems at all, even though it was based on one of the early log files.

So we have three packs that we can't get to switch and have no idea why not. Two packs do absolutely nothing and the third appears to be trying to switch, you can see the current increase and then drop again when it fails, but at least it is trying to do something.

Any ideas what might be going wrong or what could possibly be broken do please let me know.


----------



## JWardell

asanyfuleno said:


> After obtaining a few Model 3 battery packs recently we've been struggling to get them to function as expected. You may recall an earlier post about how they were all RWD 75 kWh which makes them early models.
> 
> We noticed on all of them that the AC charge port, next to the DC charge point just had a blank cover and no port. Today we hired a brand new 2020 Model 3 and found that there is an AC charge port on these models.
> 
> Just to complicate matters, the software that has consistently failed to switch the contactors on our other packs managed to switch the pack in the car with no problems at all, even though it was based on one of the early log files.
> 
> So we have three packs that we can't get to switch and have no idea why not. Two packs do absolutely nothing and the third appears to be trying to switch, you can see the current increase and then drop again when it fails, but at least it is trying to do something.
> 
> Any ideas what might be going wrong or what could possibly be broken do please let me know.


Jack has discussed that in a few of his latest videos and it seems they figured it out, maybe you can ask him or @Collin80


----------



## asanyfuleno

JWardell said:


> Jack has discussed that in a few of his latest videos and it seems they figured it out, maybe you can ask him or @Collin80


I did message @Collin80 but not heard back yet.


----------



## Juggas

Any new info where VCfront lighting status have moved?


----------



## Quantum

Any leads on the CAN device for the nag?


----------



## vildron

Hi to all. I hope this info will be interesting for you. I am author of can2sky.com free CAN bus cloud decoder.
You can upload raw log CAN bus files and see data in readable format, and built plots of known and unknown parameters for analysis.

Service uses DBC-files as source for CAN bus parsing. You can load new DBC or edit existing parsers with built-in editor.

Some screenshots attached.

There are some different raw can log formats are supported, including candump linux utility format.
More info in manual

Now Im adding some features for collaboration analysys and CAN log sharing.

English is not my native, sorry


----------



## JWardell

It' alive!

*



*


----------



## All About Jake

Ooh that’s really nice!


----------



## GDN

JWardell said:


> It' alive!
> 
> *
> 
> 
> 
> *


Oh - that's sweet and quite fun.


----------



## Juggernaut

JWardell said:


> It' alive!
> 
> *
> 
> 
> 
> *


Immediately i would order one from you ... problem is to get hands on a m3 during contact bann here in germany


----------



## Perscitus

JWardell said:


> It' alive!


We think its epic, especially because wireless and stealthy and signal configurable.


----------



## scottf200

Scan My Tesla in the Model Y















Blue and Green TM3










FYI, Re: 72 on TM3 vs 77 TMY
from TMC:


amund7 said:


> Both my 3s were also 77 point something Nominal on the first few days. It's the same battery.


----------



## JWardell

scottf200 said:


> Scan My Tesla in the Model Y
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Blue and Green TM3


Nice, I had been meaning to ask someone in here to confirm if the connector was present in the Model Y and wondering if CAN signals have changed.

But I will ask if anyone does have one and can submit some CAN logs, it would be very helpful! With some logs I can publish DBC changes needed for the Model Y if necessary.


----------



## scottf200

FYI, TMC post:


amund7 said:


> Both my 3s were also 77 point something Nominal on the first few days. It's the same battery.


----------



## JWardell

scottf200 said:


> FYI, TMC post:


Yes, as was mine.


----------



## JWardell

Chassis bus finally conveniently tapped and logged! Hundreds new signals to pour through!
Mini speedometer display functioning!
Teslax testing logging from my phone!
ScanMyTesla now testing on iOS!

I have A LOT going on in the evenings! 
I hope I'm entertaining my neighbors who have nothing else to do but watch me tooling around in the driveway


----------



## JWardell

I got a Model Y CAN log from someone, here's a graph of torques. If anything it proves that my scaling in 1D8 is wrong, at least for request. Will need to compare to model 3 performance.
GTW config chassis type is 3 and wheel type is 17...both undefined, so I'll have to update that too


----------



## JWardell

They're multiplying


----------



## onessela

Hi all, I registered myself a few minutes ago. I own an M3 (2020) since a month, and I would like to design my own "second display". My company builds and sells displays programmable in C with can bus interface, so I'll try to connect one "by wire" to my car and develop some firmware. I already bought an extension to the 26-pole connector, now I must find where +/- 12V, CAN+ and CAN- are connected.
Perhaps one of you would be so kind as to send me an image/link to 26 pole connector pinout ?
Thank you


----------



## scottf200

onessela said:


> Hi all, I registered myself a few minutes ago. I own an M3 (2020) since a month, and I would like to design my own "second display". My company builds and sells displays programmable in C with can bus interface, so I'll try to connect one "by wire" to my car and develop some firmware. I already bought an extension to the 26-pole connector, now I must find where +/- 12V, CAN+ and CAN- are connected.
> Perhaps one of you would be so kind as to send me an image/link to 26 pole connector pinout ?
> Thank you


Pin connector tabs (bottom) here:


----------



## JWardell

onessela said:


> Hi all, I registered myself a few minutes ago. I own an M3 (2020) since a month, and I would like to design my own "second display". My company builds and sells displays programmable in C with can bus interface, so I'll try to connect one "by wire" to my car and develop some firmware. I already bought an extension to the 26-pole connector, now I must find where +/- 12V, CAN+ and CAN- are connected.
> Perhaps one of you would be so kind as to send me an image/link to 26 pole connector pinout ?
> Thank you


Welcome! Scott posted the pinout above. I'm curious where you found an extension harness that doesn't have an OBD connector on it.
Also curious about your company's can displays, sounds useful!


----------



## Mr.K

Adress is in the picture, but I only see model s/x connectors. 
https://cnhonha.en.alibaba.com/search/product?SearchText=Tesla


----------



## onessela

Hi and thank you for infos ! Aliexpress link for extension harness is https://it.aliexpress.com/item/4000324035057.html?spm=a2g0s.9042311.0.0.24a04c4dgK74qJ
I will start connecting CanBus to a Raspberry zero-based device (has RS485, CanBus, Ethernet) and doing some experiments with it.


----------



## nem3

Curious if anyone would be willing to run a few beta tests for me. Have a couple of testers for Model 3 already, but they haven't been very active recently. Very anxious to get this update out and confirmation of Model 3 signals is what's holding me up.


----------



## JWardell

nem3 said:


> Curious if anyone would be willing to run a few beta tests for me. Have a couple of testers for Model 3 already, but they haven't been very active recently. Very anxious to get this update out and confirmation of Model 3 signals is what's holding me up.


Beta test of what? I love beta testing things 
Oh, looks like you are making an app. Yes, definitely sign me up


----------



## nem3

Looks like there was a change made to 0x102 for the S/X with 2020.12.5, anyone confirm? Did a quick comparison vs 0x132 from the 3/Y, looks like it's changed to that format.


----------



## adam m

I've been tinkering with sniffing the can bus for a certain CANID on my model 3 and can't find it. I'm looking to find an ID that only triggers when sentry mode triggered and flashes the blinkers/puts up the image on the screen.


----------



## onessela

My experiments are going well. Now I can read data and show them on a 7" display with a Qt application. Basically I wish to build an auxiliary display to place behind the steering wheel.

Yesterday I've been able to decode GUI speed (0x257, byte3). Next steps needed/msgs to decode:

- Real time power and regen (0x252 ? 0x268?) as shown on main display *<------- please help*
- Gear (N, P, R, D) (0x118, third byte >> 5 ?)
- Date/Time (0x318 ?)
- Indicator lights (low beam, high beam, front/rear fog, parking brake, seat belt)*<------- please help*
- Total estimated driving distance (or energy) available*<------- please help*
- Rated Range*<------- please help*








I enclose a snapshot of my GUI (version 0.0)

Right now I am reading page 25 of this thread....keep going...


----------



## x-cimo

onessela said:


> My experiments are going well. Now I can read data and show them on a 7" display with a Qt application. Basically I wish to build an auxiliary display to place behind the steering wheel.
> 
> Yesterday I've been able to decode GUI speed (0x257, byte3). Next steps needed/msgs to decode:
> 
> - Real time power and regen (0x252 ? 0x268?) as shown on main display *<------- please help*
> - Gear (N, P, R, D) (0x118, third byte >> 5 ?)
> - Date/Time (0x318 ?)
> - Indicator lights (low beam, high beam, front/rear fog, parking brake, seat belt)*<------- please help*
> - Total estimated driving distance (or energy) available*<------- please help*
> - Rated Range*<------- please help*
> View attachment 33355
> 
> I enclose a snapshot of my GUI (version 0.0)
> 
> Right now I am reading page 25 of this thread....keep going...


What do you use to drive the display? A Pi with hdmi? Very interesting


----------



## JWardell

adam m said:


> I've been tinkering with sniffing the can bus for a certain CANID on my model 3 and can't find it. I'm looking to find an ID that only triggers when sentry mode triggered and flashes the blinkers/puts up the image on the screen.


I don't think there will be any new messages when in Sentry, as the hardware isn't doing anything it isn't always doing. The references I can find are states in ID284 and ID3B3, although not sure those are transmitted anymore.



onessela said:


> My experiments are going well. Now I can read data and show them on a 7" display with a Qt application. Basically I wish to build an auxiliary display to place behind the steering wheel.
> 
> Yesterday I've been able to decode GUI speed (0x257, byte3). Next steps needed/msgs to decode:
> 
> - Real time power and regen (0x252 ? 0x268?) as shown on main display *<------- please help*
> - Gear (N, P, R, D) (0x118, third byte >> 5 ?)
> - Date/Time (0x318 ?)
> - Indicator lights (low beam, high beam, front/rear fog, parking brake, seat belt)*<------- please help*
> - Total estimated driving distance (or energy) available*<------- please help*
> - Rated Range*<------- please help*
> View attachment 33355
> 
> I enclose a snapshot of my GUI (version 0.0)
> 
> Right now I am reading page 25 of this thread....keep going...


Those are all in my DBC file. Torques are in 108 & 186, motor power in 266 & 2E5. Battery power you multiply current and voltage in 132.
Most of the lights are in 3F5.
Range is 33A


----------



## onessela

JWardell said:


> I don't think there will be any new messages when in Sentry, as the hardware isn't doing anything it isn't always doing. The references I can find are states in ID284 and ID3B3, although not sure those are transmitted anymore.
> 
> Those are all in my DBC file. Torques are in 108 & 186, motor power in 266 & 2E5. Battery power you multiply current and voltage in 132.
> Most of the lights are in 3F5.
> Range is 33A


Thank you very much, I will implement these nexts days and give feedback. I wish to show same power/regen values shown in M3 instant energy graph (same as model S<. kW 0-60 on the regen side (green) and 0-320 on the use side (orange), I guess)


----------



## adam m

JWardell said:


> I don't think there will be any new messages when in Sentry, as the hardware isn't doing anything it isn't always doing. The references I can find are states in ID284 and ID3B3, although not sure those are transmitted anymore.


Should I be looking for a message going to VCFront to flash the blinkers when sentry mode is triggered or VCLeft and Right? DO you guys have a GitHub for the Teensy Code you've been using?


----------



## onessela

Update: Range and gear OK. I still have problem with power/regen. I am using early 2019 sheet.
Message ID 0x268 always contains 60KW and 335KW (maximum power i guess).
Message ID 0x252 always contains 150KW and 338KW (maximum power i guess).
*Message ID 0x266 contains weird numbers* in SB16 - data[2], data[3]. For example 0x0B 0x15. Processing with function
ExtractSignalFromBytes(data, 16, 11, true, 0.5, 0) taken from CANBUS-Analyzer/Parser.cs
gives me back -378KW (?!?)
I guess this 11-bit value should go circa from -60 (max regen) to +300 (max accel)
Perhaps some bug into function or wrong endianness ?
Maybe I misunderstand meaning of "Rear Power kW signed 11-bit SB 16, scale 0.5", I did conversion by hand and got -765 (/2 = -378) again.

Keep experimenting....


----------



## kornerz

onessela said:


> *Message ID 0x266 contains weird numbers* in SB16 - data[2], data[3]. For example 0x0B 0x15. Processing with function
> ExtractSignalFromBytes(data, 16, 11, true, 0.5, 0) taken from CANBUS-Analyzer/Parser.cs
> gives me back -378KW (?!?)
> I guess this 11-bit value should go circa from -60 (max regen) to +300 (max accel)
> Perhaps some bug into function or wrong endianness ?
> Maybe I misunderstand meaning of "Rear Power kW signed 11-bit SB 16, scale 0.5", I did conversion by hand and got -765 (/2 = -378) again.
> 
> Keep experimenting....


It's 11-bit signed, but starting from bit 0 (not 16)


----------



## Mr.K

It starts to show up cars with OBD-II ports in Sweden, looks like most of them are Model 3 SR+. Anyone know whats signals is available in that port? One forum user has tested with Scan my tesla and Torque without any success.
Can it be cars designated to the chinese market that has be reallocated to europe?


----------



## onessela

kornerz said:


> It's 11-bit signed, but starting from bit 0 (not 16)


Yes ! Thank you for this info. Maybe I was using an outdated spreadsheet.
I simply add front power and rear power and show it, but perhaps I need some more sophisticated algorythm.
I am now experimenting some glitches, for example, if I put my car from park into drive mode (keeping brake pedal pushed), sometimes power goes >>0 and then <<0, and then returns to 0. While driving I see some delays and glitches too. I don't think it's a CanBus issue (speed is perfect...)
Will investigate more.

"Most of the lights are in 3F5." ..... not documented ? I will log these messages....


----------



## kornerz

onessela said:


> Yes ! Thank you for this info. Maybe I was using an outdated spreadsheet.
> I simply add front power and rear power and show it, but perhaps I need some more sophisticated algorythm.
> I am now experimenting some glitches, for example, if I put my car from park into drive mode (keeping brake pedal pushed), sometimes power goes >>0 and then <<0, and then returns to 0. While driving I see some delays and glitches too. I don't think it's a CanBus issue (speed is perfect...)
> Will investigate more.
> 
> "Most of the lights are in 3F5." ..... not documented ? I will log these messages....


You may want to check the DBC file at https://github.com/joshwardell/model3dbc
It contains more recent data than the spreadsheet, however in not so user-friendly format.


----------



## JWardell

onessela said:


> Update: Range and gear OK. I still have problem with power/regen. I am using early 2019 sheet.
> Message ID 0x268 always contains 60KW and 335KW (maximum power i guess).
> Message ID 0x252 always contains 150KW and 338KW (maximum power i guess).
> *Message ID 0x266 contains weird numbers* in SB16 - data[2], data[3]. For example 0x0B 0x15. Processing with function
> ExtractSignalFromBytes(data, 16, 11, true, 0.5, 0) taken from CANBUS-Analyzer/Parser.cs
> gives me back -378KW (?!?)
> I guess this 11-bit value should go circa from -60 (max regen) to +300 (max accel)
> Perhaps some bug into function or wrong endianness ?
> Maybe I misunderstand meaning of "Rear Power kW signed 11-bit SB 16, scale 0.5", I did conversion by hand and got -765 (/2 = -378) again.
> 
> Keep experimenting....


The spreadsheets are not up to date, 252 and 268 are maximums, you need 266 and 2E5 as I mentioned for instantaneous power (if that is what you are looking for?)
If you look at the DBC, you see:
SG_ RearPower266 : 0|[email protected] (0.5,0) [-500|500] "kW" Receiver
So rear motor power is an 11-bit signed number starting at bit zero, then scaled by 0.5 (divide by two). The hard min/max is -/+ 500kW I think -100 to 450 is a more realistic range.

Spreadsheet updating is too tedious now, I'm hoping to find some way to export DBC to spreadsheet, though at this point I've spent enough time in the DBC to read it as english 



Mr.K said:


> It starts to show up cars with OBD-II ports in Sweden, looks like most of them are Model 3 SR+. Anyone know whats signals is available in that port? One forum user has tested with Scan my tesla and Torque without any success.
> Can it be cars designated to the chinese market that has be reallocated to europe?


Interesting, I remember hearing they were added somewhere to chinese model 3s. Are there pictures?


----------



## Mr.K

JWardell said:


> Interesting, I remember hearing they were added somewhere to chinese model 3s. Are there pictures?


In the driver side footwell, pics only from the outside. 
https://teslaclubsweden.se/forum/viewtopic.php?f=51&t=15257&hilit=Obd&start=20#p424749


----------



## onessela

kornerz said:


> You may want to check the DBC file at https://github.com/joshwardell/model3dbc
> It contains more recent data than the spreadsheet, however in not so user-friendly format.


MUCH better...with SavvyCAN I can check every signal ! Thanks


----------



## JWardell

Mr.K said:


> In the driver side footwell, pics only from the outside.
> https://teslaclubsweden.se/forum/viewtopic.php?f=51&t=15257&hilit=Obd&start=20#p424749


Nice so next question is if anyone has removed that panel and figured out where it plugs in? I assume up to the computer?


----------



## Mr.K

Not that i have seen, I've recommended them to have a look at this thread.


----------



## onessela

Update: thanks to SavvyCAN + DBC file work is faster and more fun.
Lights are OK (left/right turn, headlights, fog lights), power and speed are OK, Now I am trying to make "Seat belts" and "Hold Brake" icons work. *Somebody knows where to find these bits ?*








Tomorrow will add date/time, temperature. I would like also to add two more gauges, one foe rpm and another for torque...


----------



## JWardell

Mr.K said:


> Not that i have seen, I've recommended them to have a look at this thread.


It has a harness to VCleft with a unique CAN bus. I may probe to see if it is active everywhere



onessela said:


> Update: thanks to SavvyCAN + DBC file work is faster and more fun.
> Lights are OK (left/right turn, headlights, fog lights), power and speed are OK, Now I am trying to make "Seat belts" and "Hold Brake" icons work. *Somebody knows where to find these bits ?*
> View attachment 33415
> 
> Tomorrow will add date/time, temperature. I would like also to add two more gauges, one foe rpm and another for torque...


I will look for seatbelts this weekend, I think it's an alert message I don't have in there.
See brakestate118 I forget if that is regen brake or hold.
The UI Hold is in 2B6 but that might not be on that can bus


----------



## onessela

You are right, BrakeState is in bit 26 of 0x118. Only *seatbelts *missing at the moment*.*
I am working on date/time, I discovered I need also timezone info.....I will get it from my Raspberry.
Temperature shows OK too.
Update: I added reading of rear axle rpm and torque, now I should convert them in rear motor rpm (multiply by 9.73 ?) and show it on display on 2 more gauges.
I choose 0..600Nm and 0..14000 RPM, seem reasonable/adequate ?









I would also like to add this triangle marker, I guess it's actual speed limit but I don't know where I could get the value








Update (Saturday). Added Torque gauge (rear + front axle), RPM Gauge (up to 15000). Everything working OK.
Next step: find a high luminosity/high resolution LCD and design some complimentary electronics circuits (e.g. ambient light sensor for dimming, optoisolated CANBUS, power supply)


----------



## twinbee

I don't want to spend hours going through this gigantic thread, so I'll ask outright. Is there anyone with an example of raw data from the CANbus/OBD-II port when driving the Model 3? Preferably when flooring it from 0-60. I'll have all the columns it provides, but in particular I'm looking for:

- Time in milliseconds (it can be the time since flooring it, or the actual time, doesn't matter).

- Pedal position (say 0-100%)

- Car distance traveled (millimetre or centimetre accuracy needed)...... OR .......mph/kph (tenths of a mph or kph needed really)...... OR .......wheel RPM.

Does anyone here have a spreadsheet of such data? So down the left hand column would be time, and the top row titles would be the other variables.

The reason for doing this is I want to precisely measure the time between pressing the acceleration pedal and when the car starts to move even a millimetre. So far, from tests I've done with my 60fps video camera, I'm measuring around 120 milliseconds of lag on my M3P, but I want another way to back this up to make it a bit more conclusive, hence going the CANbus route. I could go and research and buy the CANbus/OBD-II converter, and software, but it may be that I'd be disappointed in the end if it doesn't have the accuracy needed (or even one of the variables), so if someone has a spreadsheet like this to offer, I would be immensely grateful.


----------



## Krash

twinbee said:


> ...Is there anyone with an example of raw data from the CANbus/OBD-II port when driving the Model 3?...


I am gathering this data for an update to the Performance Metrics thread on TMC. The data isn't mine (I have an S) but I have permission to share it or have gathered it from public data from the generous TOO crowd. I have one remaining bug processing CANBus in Excel for the battery current, but all the fields you asked for are available.

Do you want AWD non P data? From before or after the latest boost? If you are pulling CANBus data, would you be willing to share yours? Or are you you just looking at the CANBus data for comparison?

We are calculating distance from speed. As far as I know, nobody is pulling GPS data at the same time since it is on a different bus.

The files are big.


----------



## JWardell

twinbee said:


> I don't want to spend hours going through this gigantic thread, so I'll ask outright. Is there anyone with an example of raw data from the CANbus/OBD-II port when driving the Model 3? Preferably when flooring it from 0-60. I'll have all the columns it provides, but in particular I'm looking for:
> 
> - Time in milliseconds (it can be the time since flooring it, or the actual time, doesn't matter).
> 
> - Pedal position (say 0-100%)
> 
> - Car distance traveled (millimetre or centimetre accuracy needed)...... OR .......mph/kph (tenths of a mph or kph needed really)...... OR .......wheel RPM.
> 
> Does anyone here have a spreadsheet of such data? So down the left hand column would be time, and the top row titles would be the other variables.
> 
> The reason for doing this is I want to precisely measure the time between pressing the acceleration pedal and when the car starts to move even a millimetre. So far, from tests I've done with my 60fps video camera, I'm measuring around 120 milliseconds of lag on my M3P, but I want another way to back this up to make it a bit more conclusive, hence going the CANbus route. I could go and research and buy the CANbus/OBD-II converter, and software, but it may be that I'd be disappointed in the end if it doesn't have the accuracy needed (or even one of the variables), so if someone has a spreadsheet like this to offer, I would be immensely grateful.


The first post has spreadsheets and (older) logs and stuff. You can read your wheel ticks, axle speed, or vehicle speed to measure. I do the same to determine 0-60, last I did I measured 4.9sec 0-60. 
You can record GPS (and there is a GPS speed message too) but that's less accurate. The data is all there.


----------



## twinbee

Krash said:


> I have one remaining bug processing CANBus in Excel for the battery current, but all the fields you asked for are available.


Oh are you the creator of the software which records the data?



Krash said:


> but all the fields you asked for are available.


Fantastic.



Krash said:


> Do you want AWD non P data? From before or after the latest boost?


Non-P is okay, but preferably P if possible (as that's what I use, so a comparison is more apples to apples).



Krash said:


> From before or after the latest boost?


I assume you're referring to where the 0-60 changed from around 3.2s to 3.0s. Yes, preferably after as I have the boost too.



Krash said:


> We are calculating distance from speed.


I assume there's no wheel RPM measurement or any other way to track distance indirectly.



Krash said:


> The files are big.


Great  Can always zip/rar 'em.

Thanks a ton, I really look forward to seeing the data!


----------



## twinbee

JWardell said:


> The first post has spreadsheets and (older) logs and stuff. You can read your wheel ticks, axle speed, or vehicle speed to measure. I do the same to determine 0-60, last I did I measured 4.9sec 0-60.


Is the data a Performance 3 flooring it from 0-60? Can you give the specific link with the data? There are a lot of links, and from a brief look, I couldn't see much.


----------



## Krash

twinbee said:


> Oh are you the creator of the software which records the data?
> ...
> Great  Can always zip/rar 'em.
> ...


No, I am not the software creator. I haven't coded in a very long time. I just organize the data.

I haven't had any luck attaching excel, txt or zip files on TOO. They always get blocked.

The data is jumpy. But it should have the boost. I didn't interpolate the missing data, although it has torque, and power in between the missing speeds so if you did, you could get pretty close.

​


----------



## JWardell

twinbee said:


> Is the data a Performance 3 flooring it from 0-60? Can you give the specific link with the data? There are a lot of links, and from a brief look, I couldn't see much.


Not unless you give me a M3P, then i'll gladly post a log of it


----------



## twinbee

Krash said:


> No, I am not the software creator. I haven't coded in a very long time. I just organize the data.
> 
> I haven't had any luck attaching excel, txt or zip files on TOO. They always get blocked. So attached is the data in word.
> 
> The data is jumpy. But it should have the boost. I didn't interpolate the missing data, although it has torque, and power in between the missing speeds so if you did, you could get pretty close:


Thank you. That's good, but unfortunately it's missing pedal position (0-100%), so I can't match up the the moment you press the accel pedal with when the car starts to move. If you do it again, make sure all numbers (speed, distance, pedal position etc.) start at zero. Also if you have any other stat columns (such as torque, power, or RPM), it'd be nice to see those too.

Finally, the time jumps (accuracy) are around 100 milliseconds. Can you make them more like 10 milliseconds between each recording? The spreadsheet will be much bigger, but much more accurate.


----------



## twinbee

JWardell said:


> Not unless you give me a M3P, then i'll gladly post a log of it


Lol, I've just popped one in the post. Don't expect to see it for a couple of weeks because of the Corona-virus causing delays though.

Seriously, I'd be very interested to see data from you for non-P too. Acceleration is slower than P, but that shouldn't affect pedal to movement latency! If you do try, maybe take two tests though - one with nannies on, and another with them off (such as obstacle aware acceleration, Automatic emergency braking etc. off).


----------



## JWardell

I just placed an order for a bunch of PCBs and dropped a LOT of money on parts...very exited that I am very close to having something fun available in a few weeks!

But one thing I can offer much sooner is a *chassis bus tap* for those nerdy enough to want a CAN or ODB connection. I could hand build a few in the next few days vs waiting weeks.

So my question is, who *would be interested*? And do you think it should have and OBD connector or a DB9 connector?

This would be a small box that plugs in below the seat.


----------



## onessela

Hi all, work is going well, I only miss seat belt signal but I'll find it out. RPM and speed indicators objectively show very similar data, perhaps I could replace RPM with something more useful. Now I will start to design a proper support, which should be aesthetically pleasing. Here is my progress (sorry video was private):


----------



## JWardell

Battery Day is here! Well, not from Elon.


----------



## GDN

JWardell said:


> Battery Day is here! Well, not from Elon.


Thanks - great information. I've heard little bits and pieces about the battery, it's nice to hear it all put together from someone that understands it.


----------



## garsh

JWardell said:


> Battery Day is here! Well, not from Elon.


Very informative video. Thanks for taking the time to record that.
Here are just some informative nugget highlights I got from it.

Great explanation of how the 12v battery must first supply 400v DC before closing the contactors.
Great explanation of how SOC is calculated by the BMS. Everybody should watch this to better understand just how much that value is an art and a "guess".
Don't worry about "balancing the battery" so much. Let it happen naturally.
Battery's favorite operating temperature is 50° C / 120° F


----------



## JWardell

If anyone with 2020.12.x can get me a 1-2 minute CAN log, especially a model Y, it would be appreciated. My car is still refusing to update from .8


----------



## bwilson4web

JWardell said:


> If anyone with 2020.12.x can get me a 1-2 minute CAN log, especially a model Y, it would be appreciated. My car is still refusing to update from .8


You want "All" in a CAN log?

I have a 2019 Std Rng Plus Model 3 running 2020.12.6. Would this help?

We have a rain front moving through the area but I could get it later on my Samsung Tab A. It will probably be pretty large. Let me know and we'll work out a transfer method.

Bob Wilson


----------



## JWardell

bwilson4web said:


> You want "All" in a CAN log?
> 
> I have a 2019 Std Rng Plus Model 3 running 2020.12.6. Would this help?
> 
> We have a rain front moving through the area but I could get it later on my Samsung Tab A. It will probably be pretty large. Let me know and we'll work out a transfer method.
> 
> Bob Wilson


Let's see if I can get a Model Y log so I can verify heat pump compressor.
Not sure if I have a SR log, probably not for a while, might be useful under full accel to see limits, but don't try that in the rain


----------



## amund7

FW 2020.12.11.2 - ID 0x381, multiplex counter went from 4 to 5 bits (pure guesswork on my side, but my logic seems to work) - this probably means there are some new pages in this message.


----------



## JWardell

amund7 said:


> FW 2020.12.11.2 - ID 0x381, multiplex counter went from 4 to 5 bits (pure guesswork on my side, but my logic seems to work) - this probably means there are some new pages in this message.


Yes. Some DBC updates due...


----------



## JWardell

I spent many hours tonight cranking out a DBC update. The DBC now should have signals for both Model 3 and Model Y, and current for all 2020.12.x firmware. It was quite a daunting task.
Hopefully they cool it a bit on changing around signals now.


----------



## JWardell

My boards arrived and first articles are soldered up! Now I really have no excuse to complete the software that I've been procrastinating on!
No one seemed to show intrest on the chassis can adapter so I'll probably offer the ESP32 CAN server next, or hopefully have a few whole wireless display systems ready soon. 
I will need help polishing the software, and cases aren't my thing...hopefully some nerds will take an interest and help improve things.
What I will need to figure out soon is if I just put up some online store, or have a survey with preferences and take preorders, and build to order. (there will be a lot of options)


----------



## JWardell

I'm kind of surprised to see such significant changes in VCLeft...probably in 2020 Model 3s as well as Y. Several connectors have changed. Spade connectors to accessory, trailer, air suspension are gone. This all means wire harnesses have changed as well. Must be a nightmare for someone at tesla to keep track of all of that stuff for parts and service.


----------



## dance.parrot

Was anyone able to configure Torque Pro when used with a CAN connector cable (e-mobility or GPSTA) with the DBC info decoded on this forum, how ScanMyTesla works?


----------



## Perscitus

Torque Pro is extermely slow, even when running in wired CAN mode with decent hardware on either end and sampling E-OBDII PIDs.

60-100 PIDs @ 60-120Hz+ or don't bother, especially for ICE.


----------



## michi84

Torque Pro will not work, since it only supports OBD-compliant communication protocols. What Torque Pro does is to send a request for a certain PID (parameter ID, in HEX) to the cars ECU. The ECU then responds with a corresponding message which contains the ID and the data bytes. There are standard PIDs and manufacturer specific PIDs, but the answer-request structure is always the same. 

For example, if you want to know vehicle speed as registered by the ECU, you send the request 01 0D. You will get a response like 41 01 3C (for 60 km/h or mph, response is always requested mode number+40 (in this case, we use OBD Mode 01 and get back 41 correspondingly)), with the first byte being the mode ID, the second the PID and the third the data (3C in Hex = 60 in decimal). Responses can of course contain several bytes.

Custom, non-standard PIDs use a different mode ID, e.g. 22 for Fiat/Alfa vehicles. I reverse engineered several of them for my former car (Alfa Guilietta) by sniffing serial communcation while using a third party scan app with extended PIDs for Alfa. You had to figure out the scaling für yourself or trying standard formulas, but knowing the correct value from the scantool helped a lot.

For Tesla, the situation is completely different. There is no standardized OBD-communication protocol implemented, and no OBD port (only in China, dont know if this works and which kind of data you get). Sending a PID request on the CAN bus will get you nowhere, the app wont even connect, since it will not find a valid communication protocol. In the best case, nothing will happen except a failure to establish a connection, in the worst case, you could cause some kind of error or glitch in the system. You will not even get to the point to try some custom PID request, because for that to work, you need to establish a connection to the ECU first.

Scan my Tesla and similar apps work differently. They read the messages on the CAN bus, and convert them to readable data in the way specified in the DBC. In principle, it is doing the work the ECU would do in a standard OBD-system. Take a raw can message and convert it into a standardized, readable way for a standardized or manufacturer specific scantool. By sending your PID request, you basically order the ECU to take the corresponding CAN message and present its data to you in a way you (if you can do the hex to dec conversion an scaling in your head) or your scan software can read. Scan my Tesla does not request anything, it just reads what is there and converts this into readable data.

So in short: Unless the developer of Torque Pro adds a way to switch to "CAN listen mode" and enter custom CAN message definitions (or load DBCs), there is no way to make Torque Pro with Teslas. You need to use Scan My Tesla (Android and IOS) or Teslax (IOS, especially useful if you want to add new messages via DBC yourself).


----------



## bwilson4web

These are my lessons learned using current versions of ScanMyTesla8 [1.9.1]/Android [V9] and tesLAX [1.1(29)]/iPhone [13.4.1]. Although I have ScanMyTesla on iPhone, it is too soon to cover it:

OBD Modules - early experience suggests there is a low-power, sleep mode that requires a 'wake-up'. It may require the car to be in a READY mode.
"Mini OBDII" - came with the ScanMyTesla wiring harness. Initially it worked fine but after a couple of months, it stopped working and required being disconnected and reconnected. When it fails, the Power light does not come on.
"OBDLink MX+ 16406" - when not responding to the app, it can be awakened by using the iPhone "Settings" by touching the "Not Connected +i". At least one time, I also had to wake up the Model 3. I have not tested it with ScanMyTesla/Android.

Android tablet and iPhone
Samsung Tab A - with plenty of memory and storage, it needs a data export app to share with my Macintosh. Furthermore, there seems to be some some random, undiagnosed overruns on the Mini OBDII that requires data filtering on the Macintosh (i.e. some temperature records.) I have not tested it with the new OBDLink MX+ (hummm, sounds like a good excuse for a trip.)
iPhone - if the screen saver comes on, typically 5 minutes, many applications end including tesLAX so set the iPhone display to never sleep or set the app to override screen sleep when running. The screen video recording is the only way to playback the data for later analysis.

ScanMyTesla and tesLAX
Configuring ScanMyTesla, a set of capture signals, must be done in the car with data streaming from the OBD. Once configured, the different data capture configurations are saved. It does save the data in a CSV format that is spreadsheet friendly.
The tesLAX, capture signals can be configured in the house. There are multiple formats but no CSV collection and export. To playback the data, the iPhone screen video must be viewed and any data graphs require manual entry in a spreadsheet. Worse, once the app ends either by being stopped or the screen lock, the capture signals have to be re-entered including deleting the "Front" motor metrics in my rear-drive only Std Rng Plus Model 3. There is an option to inhibit screen sleep.

PET PEIVES

CSV engineering units recording - when doing a test, the operator should not also be the data recorder. Making a video of the device screen does not put it in a spreadsheet for a detailed analysis. For this, ScanMyTesla/Android is ahead.
Test configurations - it takes time to configure what sets of data to capture. The tesLAX/iPhone can be configured away from the car versus ScanMyTesla/Android that can only be done in the car in READY. However, ScanMyTesla/Android preserves the test measurement setup, a good thing!
Firehose data - sometimes you need everything as seen. But more practical would be a variable time interval, 0-n milliseconds, averaged with optional high/low/counts in CSV format. This significantly reduces the volume of data and makes it more spreadsheet compatible.
Both developers (@All About Jake and @amund7) are working hard and I appreciate and paid for their work. These are suggestions on how they can maximize the payoff for this user who is really interested in the car.

Bob Wilson

UPDATE:
Hands down, OBDLink MX+ is much better than Mini OBDII because it captures data at a faster rate. With the Mini OBDII, typical data samples are 2-5 milliseconds apart but the OBDLink MX+ has multiple data points within the same millisecond time-stamp. With the older Mini OBDII, I would expect to see at least one temperature value change with a sign change or jump to impossible values. In contrast, OBDLink MX+ all temperature values were well behaved moving smoothly between values.

I did have to clear and then re-pair the OBDLink MX+ with the ScanMyTesla/Android. This could have been due to earlier experiments with tesLAX/iPhone. Regardless, I didn't have to power-cycle the OBDLink MX+ but just clear and re-pair.


----------



## JWardell

bwilson4web said:


> These are my lessons learned using current versions of ScanMyTesla8 [1.9.1]/Android [V9] and tesLAX [1.1(29)]/iPhone [13.4.1]. Although I have ScanMyTesla on iPhone, it is too soon to cover it:
> 
> OBD Modules - early experience suggests there is a low-power, sleep mode that requires a 'wake-up'. It may require the car to be in a READY mode.
> "Mini OBDII" - came with the ScanMyTesla wiring harness. Initially it worked fine but after a couple of months, it stopped working and required being disconnected and reconnected. When it fails, the Power light does not come on.
> "OBDLink MX+ 16406" - when not responding to the app, it can be awakened by using the iPhone "Settings" by touching the "Not Connected +i". At least one time, I also had to wake up the Model 3. I have not tested it with ScanMyTesla/Android.
> 
> Android tablet and iPhone
> Samsung Tab A - with plenty of memory and storage, it needs a data export app to share with my Macintosh. Furthermore, there seems to be some some random, undiagnosed overruns on the Mini OBDII that requires data filtering on the Macintosh (i.e. some temperature records.) I have not tested it with the new OBDLink MX+ (hummm, sounds like a good excuse for a trip.)
> iPhone - if the screen saver comes on, typically 5 minutes, many applications end including tesLAX so set the iPhone display to never sleep or set the app to override screen sleep when running. The screen video recording is the only way to playback the data for later analysis.
> 
> ScanMyTesla and tesLAX
> Configuring ScanMyTesla, a set of capture signals, must be done in the car with data streaming from the OBD. Once configured, the different data capture configurations are saved. It does save the data in a CSV format that is spreadsheet friendly.
> The tesLAX, capture signals can be configured in the house. There are multiple formats but no CSV collection and export. To playback the data, the iPhone screen video must be viewed and any data graphs require manual entry in a spreadsheet. Worse, once the app ends either by being stopped or the screen lock, the capture signals have to be re-entered including deleting the "Front" motor metrics in my rear-drive only Std Rng Plus Model 3. There is an option to inhibit screen sleep.
> 
> PET PEIVES
> 
> CSV engineering units recording - when doing a test, the operator should not also be the data recorder. Making a video of the device screen does not put it in a spreadsheet for a detailed analysis. For this, ScanMyTesla/Android is ahead.
> Test configurations - it takes time to configure what sets of data to capture. The tesLAX/iPhone can be configured away from the car versus ScanMyTesla/Android that can only be done in the car in READY. However, ScanMyTesla/Android preserves the test measurement setup, a good thing!
> Firehose data - sometimes you need everything as seen. But more practical would be a variable time interval, 0-n milliseconds, averaged with optional high/low/counts in CSV format. This significantly reduces the volume of data and makes it more spreadsheet compatible.
> Both developers are working hard and I appreciate and paid for their work. These are suggestions on how they can maximize the payoff for this user who is really interested in the car.
> 
> Bob Wilson


That's some valuable feedback, and I hope @All About Jake and @amund7 give it a good read.

I will say that both ScanMyTesla (android) and TesLax do record data to log files, and it does work well outside of slow or bad data coming from the OBDLink. But those files are not really intended to be human-readable or fed into excel which will quickly bog down with all the data. They are intended to be used with CAN analysis software, and again my favorites are made right here... CANbusAnalyzer by @amund7 and SavvyCAN by @Collin80 . You can then load my DBC file into both of them and quickly look at human-readable data and graphs. In fact savvy can has super powerful import/export capabilities, so you can take of these logs and export them to CSV if that's what you wish.

When writing software there are a lot of different considerations for data format. ASC is most widely supported by CAN software. Can dump is the simplest and has the least processor overhead and smallest files. BLF is the most powerful but rare support etc. It's great to just be able to convert between them.


----------



## All About Jake

bwilson4web said:


> when not responding to the app, it can be awakened by using the iPhone "Settings" by touching the "Not Connected


Yes, I've seen this behavior. iOS rules do not give app developers much control over this process and unfortunately it involves a visit to the Settings.app. I've also seen the MX+ get into a state where you need to power cycle, which involves an unplug and replug. Later versions of tesLAX try to disconnect cleanly so this hopefully will happen less frequently.



bwilson4web said:


> if the screen saver comes on, typically 5 minutes, many applications end including tesLAX


tesLAX does background, but it is also a high-power use application. iOS may indiscriminately kill it at any time. I'm working to improve power utilization when I can.



bwilson4web said:


> The screen video recording is the only way to playback the data for later analysis.


In 1.1 you can record a log in TXT or ASC and play it back in the app. Just use "open file..." to open a previously recorded log. I recommend ASC because it saves timing information as well for more accurate playback.



bwilson4web said:


> Worse, once the app ends either by being stopped or the screen lock, the capture signals have to be re-entered including deleting the "Front" motor metrics in my rear-drive only Std Rng Plus Model 3. ........ ScanMyTesla/Android preserves the test measurement setup, a good thing!


Yeah, you found a bug. Thanks for reporting it on GitHub. I'm waiting for Apple to approve a TestFight with the bugfixes for this issue. There are two bugs -- deletes aren't persisted. The second bug relates to blank values. So if you fill in, say a gauge subtype that was previously blank, it may not save.  You can try to save a change to a non-blank setting to trigger the save.... but the real fix is coming in 1.1.1



bwilson4web said:


> CSV engineering units recording - when doing a test, the operator should not also be the data recorder.


CSV is on my list but I haven't decided how I want to do it in the app yet. As @JWardell mentioned for now you can probably use a different tool along with an ASC log and his DBC to analyze a log.

Thanks for the feedback.


----------



## bwilson4web

All About Jake said:


> Yeah, you found a bug. Thanks for reporting it on GitHub. I'm waiting for Apple to approve a TestFight with the bugfixes for this issue. There are two bugs -- deletes aren't persisted. The second bug relates to blank values. So if you fill in, say a gauge subtype that was previously blank, it may not save. You can try to save a change to a non-blank setting to trigger the save.... but the real fix is coming in 1.1.1


The persistent 'Presets' work which makes tesLAX much more usable.

THANKS!

I have no doubt the other issues are on your 'to do list' and I look forward to seeing them. But I have a question about some of the metrics:









The longitude and latitude did not show values. How should we handle this?

Bob Wilson


----------



## All About Jake

bwilson4web said:


> The longitude and latitude did not show values. How should we handle this?


@JWardell may be able to tell you more. Not all signals in the database are available. Tesla has removed some (like individual cell brick voltages) and are there for historical purposes. Some are on other busses. I haven't played with the GPS coordinates specifically, but my guess is Tesla is just not transmitting them on the bus.


----------



## JWardell

bwilson4web said:


> The persistent 'Presets' work which makes tesLAX much more usable.
> 
> THANKS!
> 
> I have no doubt the other issues are on your 'to do list' and I look forward to seeing them. But I have a question about some of the metrics:
> View attachment 34057
> 
> 
> The longitude and latitude did not show values. How should we handle this?
> 
> Bob Wilson


GPS information is on the chassis bus. You would need to plug into that instead. (and more fun stuff like accelerometer, autopilot, etc)


----------



## bwilson4web

JWardell said:


> GPS information is on the chassis bus. You would need to plug into that instead. (and more fun stuff like accelerometer, autopilot, etc)


I would be nice if the OBDLink MX+ could monitor either one of the CANbus. I don't look forward to having two wiring harnesses or a harness with a manual switch.

Bob Wilson


----------



## JWardell

bwilson4web said:


> I would be nice if the OBDLink MX+ could monitor either one of the CANbus. I don't look forward to having two wiring harnesses or a harness with a manual switch.
> 
> Bob Wilson


As far as I know, I have the only solution in existence to plug into the chassis bus 
With a fair amount of software help, it is possible for these apps to talk to it and read from both busses simultaneously.


----------



## JWardell

👀

__ https://twitter.com/i/web/status/1263666021463986176


----------



## Frank 11223

JWardell said:


> As far as I know, I have the only solution in existence to plug into the chassis bus
> With a fair amount of software help, it is possible for these apps to talk to it and read from both busses simultaneously.


But where you get the chassis bus on the car?


----------



## Frank 11223

JWardell said:


> I just placed an order for a bunch of PCBs and dropped a LOT of money on parts...very exited that I am very close to having something fun available in a few weeks!
> 
> But one thing I can offer much sooner is a *chassis bus tap* for those nerdy enough to want a CAN or ODB connection. I could hand build a few in the next few days vs waiting weeks.
> 
> So my question is, who *would be interested*? And do you think it should have and OBD connector or a DB9 connector?
> 
> This would be a small box that plugs in below the seat.


I am interesting in that ,The chassis can,Do you have picture to show where it is? Thank you in advanced.


----------



## JWardell

Frank 11223 said:


> But where you get the chassis bus on the car?


The easiest spot is a connector under the seat. My board plugs in and passes it on. If folks want I can add ODB and/or DB9 connectors as well.


----------



## Frank 11223

@JWardell ，Thank you for you feed back ,i found this box under the passenger seat as below.i fond the there was a CAN bus IC on the board .but there are no wires connect with the yellow connector ,just a cable with the black connector , even the box is not powered on .i don't know what's going on with it.


----------



## Frank 11223




----------



## Frank 11223

Frank 11223 said:


> you can see from the picture below
> View attachment 34092


----------



## Eric_3y

From some bench testing of a Standalone Tesla RCM aka: Restraint Control module (Bosch 0 285 014 176 P/N 1095757-00-C S/N 2 A 2 0132830 AA 18-11-2018)
No airbags or sensors just the RCM with wires for: Power, Ign, Drive input, Gnd, Chassis CAN, Party CAN.
I was able to confirm the following msg IDs on each BUS are from the RCM;
Party Bus:
0x11, onetime msg if in drive mode and I really thrash the RCM around I get a one-time msg maybe a crash message or a WTF is happening, not sure. 
0x101, 10ms This does look to be the IMU data as is already in the CAN DBC
0x111, 10ms Lots of changing bytes like 0x101, not sure what this is. Maybe more IMU channels
0x121, intermittent, Showed up when I tilted the RCM. It seems to be an extreme tilt message. Tilting the RCM left causes one msg to send then stops, Tilting right cause the message to be sent again then stop. 
0x211, 5ms Only bytes 0 and 1 are changing, others are static. Even if I switch to drive input, So fast looks like maybe a status/fault message/heartbeat from RCM
no other msgs seen

Chassis Bus:
0x11: Same as noted on party bus. 
0x101: 20ms, all 0's except bytes 6 & 7. If IMU channels it must need something to enable it. 
0x111: 20ms, all 0's except bytes 6 & 7. If IMU channels it must need something to enable it.
0x121: same behavior as on Party Bus
0x211: 100ms Same behavior as on Party bus. 
0x351: 2s rate
0x371: 1s rate
0x511: Once, Sent only when ignition transitions to off
0x5F1: Once, Sent on first Key on never again. likely a serial number or part number, etc.
0x717: 1s rate

If it would be of use I could try to mess with the inputs to see if the state msg changes. I am guessing this is 0x211 msg on either bus.


----------



## JWardell

Frank 11223 said:


> @JWardell ，Thank you for you feed back ,i found this box under the passenger seat as below.i fond the there was a CAN bus IC on the board .but there are no wires connect with the yellow connector ,just a cable with the black connector , even the box is not powered on .i don't know what's going on with it.
> 
> View attachment 34091


The CAN and power are on the yellow connector. If it is disconnected and you go into drive, you will get restraint errors.
But I've sourced the connectors and that's where my stuff plugs in


----------



## Frank 11223

@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.


----------



## Frank 11223

@JWardell , Hope i can get some suggestion from you,Thank you in advance.


----------



## JWardell

Frank 11223 said:


> @JWardell , Hope i can get some suggestion from you,Thank you in advance.
> View attachment 34098


What are you looking for exactly? I have only verified the messages, not the exact data within. It could be getting it from another message.


----------



## Frank 11223

JWardell said:


> What are you looking for exactly? I have only verified the messages, not the exact data within. It could be getting it from another message.


Hi JWardell ，I want to get the navigation data showing on the screen.
1.Navigation status ,type of Next branch ,distance of Next branch ,surplus distance ,surplus time ， the time on destination and map speedlimit .Just the red box as below:
I hope I made that clear.


----------



## JWardell

I see. Not something I've looked into. Although I would expect that all to exist within the computer itself, no need to send it across the canbus.


----------



## Frank 11223

JWardell said:


> I see. Not something I've looked into. Although I would expect that all to exist within the computer itself, no need to send it across the canbus.


Bad news for me ,But thanks for your info.


----------



## Frank 11223

JWardell said:


> I see. Not something I've looked into. Although I would expect that all to exist within the computer itself, no need to send it across the canbus.


you mean the map data showing on the screen sent by the MCU directly though optical fiber or coaxial-cable. not exist on the canbus right?


----------



## JWardell

Sent where? The map is already in the MCU as is the navigation.

It looks like time to destination is in 08B, though I haven't confirmed that message:

BO_ 139 UI_tripPlanning2: 6
SG_ UI_maxSpeedToReachDestination : 0|[email protected]+ (0.01,0) [0|655.34] "m/s"
SG_ UI_remainingWeightedRMSSpeed : 16|[email protected]+ (0.01,0) [0|655.34] "m/s"
SG_ UI_timeToDestination : 32|[email protected]+ (1,0) [0|65534] "s"


----------



## Frank 11223

JWardell said:


> Sent where? The map is already in the MCU as is the navigation.
> 
> It looks like time to destination is in 08B, though I haven't confirmed that message:
> 
> BO_ 139 UI_tripPlanning2: 6
> SG_ UI_maxSpeedToReachDestination : 0|[email protected]+ (0.01,0) [0|655.34] "m/s"
> SG_ UI_remainingWeightedRMSSpeed : 16|[email protected]+ (0.01,0) [0|655.34] "m/s"
> SG_ UI_timeToDestination : 32|[email protected]+ (1,0) [0|65534] "s"


You mean the map data is in the MUC of the screen ,so it do not need to send the map data to the can bus ,right ?

the ID08B and ID139 you got if for which can bus,vechile can OR chassis can?


----------



## JWardell

JWardell said:


> 👀
> 
> __ https://twitter.com/i/web/status/1263666021463986176


It seems most people missed the hidden site in that video...
Finally had some progress tonight after being sidetracked for a week.
More very soon.


----------



## Frank 11223

onessela said:


> You are right, BrakeState is in bit 26 of 0x118. Only *seatbelts *missing at the moment*.*
> I am working on date/time, I discovered I need also timezone info.....I will get it from my Raspberry.
> Temperature shows OK too.
> Update: I added reading of rear axle rpm and torque, now I should convert them in rear motor rpm (multiply by 9.73 ?) and show it on display on 2 more gauges.
> I choose 0..600Nm and 0..14000 RPM, seem reasonable/adequate ?
> View attachment 33435
> 
> 
> I would also like to add this triangle marker, I guess it's actual speed limit but I don't know where I could get the value
> View attachment 33432
> 
> Update (Saturday). Added Torque gauge (rear + front axle), RPM Gauge (up to 15000). Everything working OK.
> Next step: find a high luminosity/high resolution LCD and design some complimentary electronics circuits (e.g. ambient light sensor for dimming, optoisolated CANBUS, power supply)


Hi onessela ,This dashboard is so cool ,when can you complete it .Please inform me if you done ,I'd like to buy one if you can sell.
BTW Have you got the timezone, I would be flatted if you can share this info.
Thank you ！


----------



## Rush

96s46p said:


> Would also appreciate any details and photos or diagrams on bus and power harness and connector locations, pinouts, body controllers locations, etc...


Hi all - I was just looking thru the "Model 3 Event Data Recorder Retrieval Guide" (https://edr.tesla.com/) and see that there is also a Can bus connector in the right hand base of the B-pillar. I haven't read thru this whole thread so if I'm already posting old info, my apologies.
And I don't know if it fits the adapters that JWardell posted at the beginning of the thread.

Best, stay safe, wear a mask in public -


----------



## JWardell

Rush said:


> Hi all - I was just looking thru the "Model 3 Event Data Recorder Retrieval Guide" (https://edr.tesla.com/) and see that there is also a Can bus connector in the right hand base of the B-pillar. I haven't read thru this whole thread so if I'm already posting old info, my apologies.
> And I don't know if it fits the adapters that JWardell posted at the beginning of the thread.
> 
> Best, stay safe, wear a mask in public -
> View attachment 34212


Yes, I believe the EDR kit comes with a cable that plugs into what goes to the seat harness. It's really in the floor strip at the bottom of the door opening. I plugged in further down the line under the seat and was able to run the EDR software. That's another thing that's now possible with my can server box on the chassis bus.


----------



## iChris93

JWardell said:


> I'm hoping to find some way to export DBC to spreadsheet, though at this point I've spent enough time in the DBC to read it as english


I want to contribute here and I think that I can create a MATLAB script to do this. Can you give me an idea of what you want the columns in the table to be so that I can get an idea of how to format the table and populate it?


----------



## JWardell

iChris93 said:


> I want to contribute here and I think that I can create a MATLAB script to do this. Can you give me an idea of what you want the columns in the table to be so that I can get an idea of how to format the table and populate it?


Well the first sheet has the old decoding of messages, but gets very tedious with a number of signals. A better answer would be something that can not only be placed into a spreadsheet, but easily imported into code as well...so for example the line for the message you want can be copied and transmitted to an arduino you want to decode it.
The biggest issue with MATLAB is the 20 grand you need to run it


----------



## iChris93

JWardell said:


> The biggest issue with MATLAB is the 20 grand you need to run it


Yeah, maybe not worth developing on MATLAB then.


----------



## JWardell

This is why I hope to get canserver into a number of smart folks' hands, because I can only imagine all the neat things that can be done with it. Continuously recording CAN data, filtered to once a second or whatever, and auto uploading to a server when you get home, can see dozens of times more interesting signals than Teslafi! It's not just for silly dash displays


----------



## amund7

Just learned from one of my users that 2020.20.5 breaks Nominal remaining, expected remaining and buffer. Anyone looked into this yet? (I haven't recieved that update yet, so I'm running blind)

I found out recently that Model S had a change on this packet, the signals didn't move offset, but went from previously 16 bit to 10 bit. Could be the same happened to model 3, probably, but I don't know until I get the update myself (or get a log from someone with that software)


----------



## JWardell

amund7 said:


> Just learned from one of my users that 2020.20.5 breaks Nominal remaining, expected remaining and buffer. Anyone looked into this yet? (I haven't recieved that update yet, so I'm running blind)
> 
> I found out recently that Model S had a change on this packet, the signals didn't move offset, but went from previously 16 bit to 10 bit. Could be the same happened to model 3, probably, but I don't know until I get the update myself (or get a log from someone with that software)


I have .16 and haven't even had the chance to log and look at it yet. I certainly will when .20 comes around.


----------



## bedoig

amund7 said:


> Just learned from one of my users that 2020.20.5 breaks Nominal remaining, expected remaining and buffer. Anyone looked into this yet? (I haven't recieved that update yet, so I'm running blind)
> 
> I found out recently that Model S had a change on this packet, the signals didn't move offset, but went from previously 16 bit to 10 bit. Could be the same happened to model 3, probably, but I don't know until I get the update myself (or get a log from someone with that software)


For what it's worth, wk057 has had some interesting posts related to those signals over at TMC recently, saying they're basically legacy code artifacts that aren't actually representative of what the BMS and car report. They do seem representative of the changes I see in rated miles on my own car, but what do I know. Pages 64 & 65:

https://teslamotorsclub.com/tmc/thr...81-kwh-with-up-to-77-kwh-usable.61896/page-64


----------



## JWardell

bedoig said:


> For what it's worth, wk057 has had some interesting posts related to those signals over at TMC recently, saying they're basically legacy code artifacts that aren't actually representative of what the BMS and car report. They do seem representative of the changes I see in rated miles on my own car, but what do I know. Pages 64 & 65:
> 
> https://teslamotorsclub.com/tmc/thr...81-kwh-with-up-to-77-kwh-usable.61896/page-64


Thanks for pointing that out, I don't have the time or patience to deal with TMC. His actual post is here

He is saying that tesla now balances at any SOC and any time. That can certainly be true. I've been looking deeper into what gives a real indicator that brick balancing is active, have some ideas, but have had zero time to investigate. I'm behind on DBC updates too. My spare time has been completely consumed with initial product shipments and a new puppy.


----------



## cyntrex

So appearantly Electrified Garage is now offering a mod for dual motor M3s to increase acceleration beyond Performance Model 3 levels. 
It seems like it is being manufactured by a company called Ingenext (?) and plugs into the CAN bus on the passenger side (?)

Stage 1

0-60 in 3.8 seconds
Access to Tesla Firmware Updates
Web app to configure settings
$1,100
Stage 2

0-60 in 3.2 seconds
NO access to Tesla firmware updates, must go back to EG to upgarde
Limited based on motor code, rear motor must have code 112980
$2,250

https://shop.electrifiedgarage.com/products/eg-stage-2
https://ingenext.ca/products/boost-50


----------



## msjulie

cyntrex said:


> Limited based on motor code, rear motor must have code 112980


Well that would back up the often-suggested 980 vs 990 motor theories


----------



## JWardell

cyntrex said:


> So appearantly Electrified Garage is now offering a mod for dual motor M3s to increase acceleration beyond Performance Model 3 levels.
> It seems like it is being manufactured by a company called Ingenext (?) and plugs into the CAN bus on the passenger side (?)
> 
> Stage 1
> 
> 0-60 in 3.8 seconds
> Access to Tesla Firmware Updates
> Web app to configure settings
> $1,100
> Stage 2
> 
> 0-60 in 3.2 seconds
> NO access to Tesla firmware updates, must go back to EG to upgarde
> Limited based on motor code, rear motor must have code 112980
> $2,250
> 
> https://shop.electrifiedgarage.com/products/eg-stage-2
> https://ingenext.ca/products/boost-50


Yes. I would be weary of both. Igenext's photo shows a man-in-the-middle CAN device, which probably spoofs messages to make the car think it has a performance rear motor or something.
Problem is Tesla changes CAN signals all the time, so after a software update you might find your car won't drive (or worse). I guess you could then yank it out.
The stage 2 is way more invasive and they are probably changing config of the actual motor, hopefully it has enough fets populated to support it. They readily admit software can't be updated with that one.

Tesla is usually pretty reasonable dealing with the hacking but these seem to have real possibility to kill the car or hurt someone, so I expect they will make chages that will make things tougher for all of us playing around with things.

You'll notice I am always concentrating on _monitoring_ signals, never modifying or transmitting things.
Remember we did figure out how to turn off traction control, but the car turns into a mustang and quickly darts for the sidewalks. Much as I wanted to, I chose not to make that available. Dynomode came out anyway. I don't want someone getting injured or wrecking their car on account of my product.


----------



## amund7

The other thing that is a dilemma with this, is that (if I understand correctly) stage 1 = $2000 accelleration upgrade. They are basically stealing this from Tesla. On one side, you have ICE cars that can be tuned with aftermarket parts, instead of you buying the more expensive version of the car with more horsepower. On the other hand, if I started a company selling cracks of Windows 10 licenses to people... I don't want to be that guy when the Microsoft lawyers (or probably FBI) come knocking. But all of this is new, no car has existed that had this possibility, at least not where the manufacturer sells the same software upgrade as a paid option. We will see how this plays out... but I'm afraid those guys won't be able to do this for long. At least not publicly.

The tuning a Performance car to be even faster, something Tesla is not offering, is different, and more in line with other aftermarket tuners, and a super cool option.

Now the cat is out of the box... more companys will pop up doing this, and more people will figure out how to do it themselves. If nothing else, Tesla might have to compete with the 'hackers', and offer the same performance from factory, lower the prices for the upgrades, or offer more options, which will be great for us owners!


----------



## JWardell

This kind of thing exists for a lot of cars. "chip" tunes that plug into the OBD and reconfigure some settings. Manufactures can't do much except break future models.
But Tesla can very easily circumvent by changing its comms, as it already does in small amount with each updates, and apply to every existing car.
These guys are in for a cat and mouse game. Mountainpass already did somethign similar in a different way, but their party box has been kept fairly quiet. This thing shot for immediate mass media in a day, so I would expect action.
That action is changing can signals...which precisely falls in my lap as I'm the one scrambling to identify changes with updates.
Or maybe, if I'm lucky, they just do some secure firmware handshake at power up and don't change all the comms, that would be less work for all of us.
All we can do is grab the popcorn...


----------



## All About Jake

JWardell said:


> These guys are in for a cat and mouse game.


I specifically worry about this the cat-and-mouse game. DirecTV went after H-Card hackers in the late 90's, culminating in the bricking hardware of those who engaged in signal piracy. While I doubt Tesla would go so far, I could see us passive-monitoring type people aren't caught in the crossfire. Any security implemented to prevent this sort of man-in-the-middle attack could also obfuscate signals for the rest of us. At best, we're in for regular shifting around of messages and signals to get around the man-in-the-middle. At worst, we're going to see some sort of cryptography brought to bear.


----------



## bwilson4web

GREAT NEWS!

*LIVE DATA DISPLAY*

This real-time display adds data not found in today's Tesla displays. For example, you can get both tire pressure and temperature if you're planning to toss the car around a track:









*MANAGE DATA RECORDING*

Recording data can quickly fill up the iPhone file system so you can toggle whether or not to record a data segment. For example, 100 seconds of data generated 2 MB of data:









*CONVERSION AFTER THE TEST*

Fiddling with converting the .ASC file to a proper CSV (Comma Separated Value) file should be done while parked and not distracted. It is fast, less than 10 seconds:








Accumulating the data into a longer interval substantially reduces the volume of data. Some things that do not change rapidly like battery temperatures are best looked at longer interval.

*SUBSTANTIAL SPACE SAVINGS*

Going from 2 MB to 326 KB is nearly a 10 fold reduction in space. The original file remains in case of an OOPS! Regardless, these large, raw, .ASC files can easily eat up the file system space:








Labeling the files with the data and time system works great for correlation.

*EASTER EGG - DATA GROUP RECORDED*

Unexpected, the .ASC file included the associated data metrics in the log file. The live data display works best with just the data metrics of interest. But when recording, there are obscure metrics we would not know are important too:








This is especially useful because we don't have to guess and run separate tests to find every significant metric. Sure, you get a wealth of data but when recording for engineering analysis, this saves a lot of benchmark time and offers new insights.

A 'nit', it would be great if we optionally had the units in the column header BUT _data value inspection is good enough for me_! The units only help those who don't recognize the difference between Celcius vs Farenheit. . . . Hummmmm, how much hand-holding do we need in our tools <GRINS>. That is why I call it a 'nit'.

*CONCLUSION*

Jake has done a superior job in data recording: (1) efficient; (2) post test CSV reduction, and; (3) data group (an unexpected feature.) In my testing, I was interested in what is going on with our 12 V lead-acid battery in an Alabama summer day and now I know.


----------



## amund7

amund7 said:


> Just learned from one of my users that 2020.20.5 breaks Nominal remaining, expected remaining and buffer. Anyone looked into this yet? (I haven't recieved that update yet, so I'm running blind)
> 
> I found out recently that Model S had a change on this packet, the signals didn't move offset, but went from previously 16 bit to 10 bit


Must correct myself, these were always 10 bit. I was cross-eyed at that moment I think, I was thinking of the 'range' packet in Model S.

I think I cracked it. All signals went from 10 to 11 bit, except Buffer, which went from 8 to 9 bits.

With that I will say, bigger batteries are coming! These signals would previously max out at 102.4 kWh. Now it's double, and they can go to 204.8. Same change in Model S and X I believe.


----------



## bwilson4web

"What is the kWh at any given speed?"

In the past, I would run three, bi-directional benchmarks, ~10 miles, or 6 total runs. Then I would average the results of two runs at the same speed and voila, three data points at three different speeds. Using a quadratic equation solver, I could then graph an approximate "MPH vs kWh". But this is a lot of time, typically 1-2 hours, at a given temperature, typically midnight-to-dawn. Using teaLAX, we have a faster, new method:









Record elevation, speed, and kW (Std Rng Plus Model 3 has rear motor only)
By inspection, find data where there is no appreciable change in elevation
note descending has a greater impact than a gentle up-slope

Trim out the unusable data and average
This will give faster results so changes in tires and other aspects can give a quick feedback. But I'm also finding metrics I'd never seen before:

ChargeHoursRemaining132 - so far, constant at 4095. Is this the reported maximum charge hours before the battery will throttle down SuperCharging?


----------



## JWardell

amund7 said:


> Must correct myself, these were always 10 bit. I was cross-eyed at that moment I think, I was thinking of the 'range' packet in Model S.
> 
> I think I cracked it. All signals went from 10 to 11 bit, except Buffer, which went from 8 to 9 bits.
> 
> With that I will say, bigger batteries are coming! These signals would previously max out at 102.4 kWh. Now it's double, and they can go to 204.8. Same change in Model S and X I believe.


I'm still on .16 but I will watch this closely whenever I get an update.



bwilson4web said:


> ChargeHoursRemaining132 - so far, constant at 4095. Is this the reported maximum charge hours before the battery will throttle down SuperCharging?


That's just the time till your battery charging will be complete as shown in your display. I don't think supercharger throttling is a thing in Model 3.


----------



## bwilson4web

JWardell said:


> bwilson4web said:
> 
> 
> 
> ChargeHoursRemaining132 - so far, constant at 4095. Is this the reported maximum charge hours before the battery will throttle down SuperCharging?
> 
> 
> 
> That's just the time till your battery charging will be complete as shown in your display. I don't think supercharger throttling is a thing in Model 3.
Click to expand...

I'm still curious what units as "4095 hours" would be way too slow. The actual units should be a function of the charge rate so seeing a constant value regardless of SOC has me scratching my head. But if that is a 'place holder' when not charging (i.e., OxFFF,) it would make sense.

I'll take some samples when on either my L1 or L2 EVSE after running some errands. Hour seems a little coarse.

Bob Wilson


----------



## iChris93

bwilson4web said:


> I'm still curious what units as "4095 hours" would be way too slow. The actual units should be a function of the charge rate so seeing a constant value regardless of SOC has me scratching my head. But if that is a 'place holder' when not charging (i.e., OxFFF,) it would make sense. I take a sample when on my L2 charger after running some errands.
> 
> Bob Wilson


That's exactly it. It's the highest decimal integer you can store in 12 bits, 0b111111111111.


----------



## bwilson4web

Good news! It appears to be minutes, not hours:









Bob Wilson


----------



## JWardell

Yes. I think I made it minutes in my DBC (it goes way back). And 4095 is saying not valid/ignore.


----------



## bwilson4web

JSGTA said:


> I've found a place that currently sells the Geotab adapters for the Model 3, Model S, and Model X.
> 
> I've bought the adapter for the Model 3 from them and have had friends with the Model S and Model X buy the OBD2 adapters from them as well and they've been working great.
> 
> The Model S (2012-2015) uses the HRN-CT06A1
> The Model S (2015+) and Model X use the HRN-CT06A11 and the HRN-CM24Y1 (if you need multiple connections)
> 
> If you have the 2015 Model S, if you VIN is greater than P7000, you have to use the HRN-CT06A11 adapter!
> 
> The Model 3 (2018+) uses the HRN-CT20T1


Sorry to be late to the party. Did the wiring harness I got from "ScanMyTesla" come from the parent company, https://www.geotab.com/blog/ev-battery-health/?

Thanks,
Bob Wilson


----------



## Redox

Hi,

I've build a script on a raspberry to log and upload CAN data to my server in near real time.
In order to avoid "BUFFER FULL" message from the OBDLink LX, I'm gonna try to use a CAN HAT (https://www.amazon.fr/gp/product/B07DNPFMRW/) for the raspberry, so I will plug directly on the can bus.

I suppose the Waveshare hat is enough ?
I should only wire CAN H / CAN L (pin 6 / 14) to the HAT, that's right ?
Do you know if I can put 2 CAN HAT on the same pi, so I will be able to log chassis bus also ?



JWardell said:


> No one seemed to show intrest on the chassis can adapter so I'll probably offer the ESP32 CAN server next


If you have an Y cable available with CAN H / CAN L, I will be interested...


----------



## bwilson4web

Testing "tesLAX", I recorded this data during a brief charging session at a SuperCharger:








The car was in a little shade with three dogs and climate set to 'Dog Mode". What surprised me was seeing the stator in 'heater mode' reaching nearly 97 C. There was a constant power load of 3.4 kW to the rear motor. My SuperCharger fee, $3.52 (with tax) for 16 kWh over +12 minutes. The peak charge rate, 80 kW, was reasonable for the initial SOC, ~54%, on a 150 kW SuperCharger.

I had expected the battery temperature to reach ~50 C and hold constant. During charging:

BMSmaxPackTemperature: 33.0 to 53.75 C
BMSminPackTemperature: 30.5 to 45.5 C
I'm working with the developer, @All About Jake, who has been very helpful. There are some rough edges which could be part of the IOS-OBD interface but I'm impressed with his progress. For example, the 39.8 MB .ASC log file reduced to 1.1 MB as a CSV file. This was easily reduced to by the converter to 1 second samples and e-mailed for loading into a spreadsheet with 2.269 rows of 1 second per row data. I did not have to use complex spreadsheet techniques to make a usable sheet like I have to do with the data flood from 'ScanMyTesla.' Having 'ScanMyTesla' is better than no data at all.

Bob Wilson


----------



## JWardell

bwilson4web said:


> Testing "tesLAX", I recorded this data during a brief charging session at a SuperCharger:
> View attachment 34408
> 
> The car was in a little shade with three dogs and climate set to 'Dog Mode". What surprised me was seeing the stator in 'heater mode' reaching nearly 97 C. There was a constant power load of 3.4 kW to the rear motor. My SuperCharger fee, $3.52 (with tax) for 16 kWh over +12 minutes. The peak charge rate, 80 kW, was reasonable for the initial SOC, ~54%, on a 150 kW SuperCharger.
> 
> I had expected the battery temperature to reach ~50 C and hold constant. During charging:
> 
> BMSmaxPackTemperature: 33.0 to 53.75 C
> BMSminPackTemperature: 30.5 to 45.5 C
> I'm working with the developer, @JWardell, who has been very helpful. There are some rough edges which could be part of the IOS-OBD interface but I'm impressed with his progress. For example, the 39.8 MB .ASC log file reduced to 1.1 MB as a CSV file. This was easily reduced to by the converter to 1 second samples and e-mailed for loading into a spreadsheet with 2.269 rows of 1 second per row data. I did not have to use complex spreadsheet techniques to make a usable sheet like I have to do with the data flood from 'ScanMyTesla.' Having 'ScanMyTesla' is better than no data at all.
> 
> Bob Wilson


Yes, the car wants the batteries quite hot for most efficient/fastest supercharging, so it often uses the motor for heating while charging.
@All About Jake is the developer of TesLAX, not me...I'm just a very thrilled user


----------



## Paul Hindle

Can anyone help me diagnosis an odd reading with scanmytesla? I'm at 67,000 miles on my LR RWD. The Nominal Full Pack is showing only 67.5kWh (11% Degradation) but the really strange indication is Energy Buffer 19.2 kWh (normally around 3kWh).

Anyone have any idea what's going on?


----------



## JWardell

Paul Hindle said:


> Can anyone help me diagnosis an odd reading with scanmytesla? I'm at 67,000 miles on my LR RWD. The Nominal Full Pack is showing only 67.5kWh (11% Degradation) but the really strange indication is Energy Buffer 19.2 kWh (normally around 3kWh).
> 
> Anyone have any idea what's going on?


Are you on 2020.20? I think tesla changed the data for this (can't confirm myself yet). I think he just released an update addressing that.


----------



## Paul Hindle

JWardell said:


> Are you on 2020.20? I think tesla changed the data for this (can't confirm myself yet). I think he just released an update addressing that.


I'm on 2020.20.12, the scanmytesla app thinks it's up to date but I'll try re-installing just in case.


----------



## Redox

Paul Hindle said:


> I'm on 2020.20.12, the scanmytesla app thinks it's up to date but I'll try re-installing just in case.


I'm on 2020.20.12 also and I still read this (using the dbc file) :
BfullKWhNom352 : 73.4kWh (Batt Full kWh)
BbufferKWh352 : 3.4kWh (Battery Buffer kWh)


----------



## Paul Hindle

Redox said:


> I'm on 2020.20.12 also and I still read this (using the dbc file) :
> BfullKWhNom352 : 73.4kWh (Batt Full kWh)
> BbufferKWh352 : 3.4kWh (Battery Buffer kWh)


Those are much more normal numbers. I just checked an earlier data file from April at 102,000km Nominal Full 70.0 (7% degradation), Buffer 3.1


----------



## Redox

It seems there are some signals that were on the chassis that are now on the vehicle bus : 
39D : 25.000 - IBST_status - Chassis
2D3 : 1.800 - UI_solarData - Chassis
04F : 1.000 - GPSLatLong - Chassis
399 : 1.000 - DAS_status - Chassis
24A : 1.000 - DAS_visualDebug - Chassis

But... according to 399 signal, even when I was under AP, I read : DAS_autopilotState : 0 = DISABLED, that seems strange... or is there another one to look at, to check if I'm under AP ?


----------



## Mike

Paul Hindle said:


> Can anyone help me diagnosis an odd reading with scanmytesla? I'm at 67,000 miles on my LR RWD. The Nominal Full Pack is showing only 67.5kWh (11% Degradation) but the really strange indication is Energy Buffer 19.2 kWh (normally around 3kWh).
> 
> Anyone have any idea what's going on?


Thanks for this independent data point.

I just did two trips, each involving an indicated use of 50% of the available SOC.

The first refill, the UI showed an uplift of 33 kWh (implied usable capacity between 66 and 68 kWh).

The second refill, the UI showed an uplift of 34 kWh (implied usable capacity between 67 and 69 kWh).

So my usable capacity seems to be about 67ish kWh as well (25 months old, just shy of 50,000 km).

Edit: all based on raw data, I have no third party software or hardware in my vehicle.


----------



## JWardell

Redox said:


> It seems there are some signals that were on the chassis that are now on the vehicle bus :
> 39D : 25.000 - IBST_status - Chassis
> 2D3 : 1.800 - UI_solarData - Chassis
> 04F : 1.000 - GPSLatLong - Chassis
> 399 : 1.000 - DAS_status - Chassis
> 24A : 1.000 - DAS_visualDebug - Chassis
> 
> But... according to 399 signal, even when I was under AP, I read : DAS_autopilotState : 0 = DISABLED, that seems strange... or is there another one to look at, to check if I'm under AP ?


What version are you running that you saw those on vehicle?
Yeah, autpilot state has always been zero. Just because messages exist doesn't mean they are used. There are a bunch that are just all zeros.


----------



## iChris93

Redox said:


> I'm on 2020.20.12 also and I still read this (using the dbc file) :
> BfullKWhNom352 : 73.4kWh (Batt Full kWh)
> BbufferKWh352 : 3.4kWh (Battery Buffer kWh)


I am also showing 
Full: 73.60
Buffer: 3.20


----------



## Redox

JWardell said:


> What version are you running that you saw those on vehicle?
> Yeah, autpilot state has always been zero. Just because messages exist doesn't mean they are used. There are a bunch that are just all zeros.


I'm still on 2020.20.12.
Oh ok... that's sad ! I want to get some stats of my AP usage :sweatsmile:


----------



## amund7

Paul Hindle said:


> I'm on 2020.20.12, the scanmytesla app thinks it's up to date but I'll try re-installing just in case.


Scan My Tesla 1.9.2 fixes this, but it is just a few days old and I did a gradual rollout, so not sure it has reached everyone yet. 
Also Scan My Tesla Beta for Android version 2.0.7
Also Scan My Tesla for IOS version 2.0.5
(I've been pretty busy


----------



## amund7

bwilson4web said:


> Sorry to be late to the party. Did the wiring harness I got from "ScanMyTesla" come from the parent company, https://www.geotab.com/blog/ev-battery-health/?
> 
> Thanks,
> Bob Wilson


Hi Bob, I am not affiliated with Geotab, but with E-Mobility Driving Solutions in Germany, you might have ordered a bundle with cable harness + OBD adapter + Scan My Tesla from them.


----------



## Paul Hindle

amund7 said:


> Scan My Tesla 1.9.2 fixes this, but it is just a few days old and I did a gradual rollout, so not sure it has reached everyone yet.
> Also Scan My Tesla Beta for Android version 2.0.7
> Also Scan My Tesla for IOS version 2.0.5
> (I've been pretty busy


That fixed it, thanks.

I noticed that the new Full Pack When New showed 77.8 kWh, I was expecting to see 75 or so. I was also surprised to see 12.7% (67.9kWh Nominal Full) battery degradation which is very unlikely - I live in a colder climate, usually charge to 80% using slow charging. I'm at 108,000km but that's very unusual for a Tesla.


----------



## Paul Hindle

Paul Hindle said:


> That fixed it, thanks.
> 
> I noticed that the new Full Pack When New showed 77.8 kWh, I was expecting to see 75 or so. I was also surprised to see 12.7% (67.9kWh Nominal Full) battery degradation which is very unlikely - I live in a colder climate, usually charge to 80% using slow charging. I'm at 108,000km but that's very unusual for a Tesla.


It seems that the range drop that occurred with software version 10 has happened again with 2020.20.12, maybe it will come back.


----------



## bwilson4web

Does using the wiring harness from 'ScanMyTesla' and an improved OBD interface with 'tesLAX' risk my warranty?

Rich 'Rebuilds' Benoit demonstrated that Tesla will turn off SuperCharger access to a salvage title, Model X. My Model 3 does not have a salvage title but I've noticed an abnormal charging profile:
https://teslaownersonline.com/threads/curious-150-kw-supercharger-behavior.16452/
Plausible deniability, I can report the charge profile came from a video recording.

I want to share the new charge profile with Tesla to find out if this is the new 'normal' or an 'opps'.

It is a problem because the battery heating happened during the charge session, not enroute to the SuperCharger. The profile suggests about 5 kW of heating started during the charge. In previous video recordings, there was a quick rise to the local peak followed by a gradual decline. This stepped profile is different.

UPDATE:
I can benchmark charging with a video record driving to the Tupelo and then the Athens Supercharger. In parallel, I'll use 'tesLAX' to make a technical record. Then I'll open the case with Tesla about charging.

Thanks,
Bob Wilson


----------



## iChris93

Does anyone know of a signal on the vehicle bus that will tell me whether or not the power at the chassis bus under the passenger seat is on or off? 

I was going to monitor the displayOn message, but the chassis bus power under the passenger seat turns off before the display does when there is a "charge complete" message on the screen.


----------



## JWardell

In a Vector UDS webinar yesterday, they talked about a DoIP standard ISO 13400 for sending diagnostics over ethernet, and I started thinking, I wonder if that is the mystical communications in the ethernet diagnostic port under the Model 3 steering wheel that no one's figured out. Any thoughts?


----------



## JWardell

bwilson4web said:


> Does using the wiring harness from 'ScanMyTesla' and an improved OBD interface with 'tesLAX' risk my warranty?
> 
> Rich 'Rebuilds' Benoit demonstrated that Tesla will turn off SuperCharger access to a salvage title, Model X. My Model 3 does not have a salvage title but I've noticed an abnormal charging profile:
> https://teslaownersonline.com/threads/curious-150-kw-supercharger-behavior.16452/
> Plausible deniability, I can report the charge profile came from a video recording.
> 
> I want to share the new charge profile with Tesla to find out if this is the new 'normal' or an 'opps'.
> 
> It is a problem because the battery heating happened during the charge session, not enroute to the SuperCharger. The profile suggests about 5 kW of heating started during the charge. In previous video recordings, there was a quick rise to the local peak followed by a gradual decline. This stepped profile is different.
> 
> UPDATE:
> I can benchmark charging with a video record driving to the Tupelo and then the Athens Supercharger. In parallel, I'll use 'tesLAX' to make a technical record. Then I'll open the case with Tesla about charging.
> 
> Thanks,
> Bob Wilson


Well I know it is not doing anything to affect your charge profile, neither of those apps transmit anything.
However the OBDlink does have transmission capability, so it is theoretically possible to screw things.

This is why I designed my CANserver in hardware to prevent transmission, for piece of mind, not to mention liability.

But regardless, if you were ever to get your car serviced, it is ALWAYS a good idea to remove any installed accessories, because Tesla is no doubt any better than the dealers at pointing fingers at anything. Never give anyone a reason to offload blame for their issues.



iChris93 said:


> Does anyone know of a signal on the vehicle bus that will tell me whether or not the power at the chassis bus under the passenger seat is on or off?
> 
> I was going to monitor the displayOn message, but the chassis bus power under the passenger seat turns off before the display does when there is a "charge complete" message on the screen.


I assumed it stayed powered with everything else when the car is awake. I will have to look more closely. I guess I can now watch from my couch when the server wifi network disappears.


----------



## iChris93

JWardell said:


> I assumed it stayed powered with everything else when the car is awake. I will have to look more closely. I guess I can now watch from my couch when the server wifi network disappears.


It powers off instantly after I close the door and charging is complete while the USB ports and vehicle bus stay awake.


----------



## iChris93

I have questions on a few signals.
1) 0x252 BMS_maxRegenPower. Reading this signal I get a value of ~85, that seems wrong for kW, is it scaled by 10?
2) 0x252 BMS_maxDischargePower. Reading this signal I get a value of ~20, this doesn't make sense considering the maxRegen value. 
3) 0x352 BremainingKWhNom352. Reading this signal I get a value of ~73 with a SOC of ~48%, so that value doesn't make any sense when my available storage is about 73.3 kWh. It does change, however, at ~55% its ~83.


----------



## kornerz

iChris93 said:


> I have questions on a few signals.
> 1) 0x252 BMS_maxRegenPower. Reading this signal I get a value of ~85, that seems wrong for kW, is it scaled by 10?
> 2) 0x252 BMS_maxDischargePower. Reading this signal I get a value of ~20, this doesn't make sense considering the maxRegen value.
> 3) 0x352 BremainingKWhNom352. Reading this signal I get a value of ~73 with a SOC of ~48%, so that value doesn't make any sense when my available storage is about 73.3 kWh. It does change, however, at ~55% its ~83.


0x252 is correct, it will scale down from 85kW if battery is cold or regen is limited by other means.
Max discharge power is also only updated when car is in drive, otherwise it will have some small value.
0x352 has been updated in 2020.20.x, and now values are 11-bit each, starting at 0, 11, 22, 33, 44 and 55 (for 8-bit Buffer value) respectively)


----------



## iChris93

kornerz said:


> 0x252 is correct, it will scale down from 85kW if battery is cold or regen is limited by other means.
> Max discharge power is also only updated when car is in drive, otherwise it will have some small value.
> 0x352 has been updated in 2020.20.x, and now values are 11-bit each, starting at 0, 11, 22, 33, 44 and 55 (for 8-bit Buffer value) respectively)


Very helpful! Thank you!

So 85 kW is the maximum regen power for the rear motor?

Looking back at my data for the max discharge, you're right! I can see it is about 380 while in drive, is that reasonable?

Ah! I am only looking for 10 bit signal lengths for 0x352, I will have to update that tomorrow. How do you decode the changes? I am only working off of the DBC that @JWardell maintains.


----------



## kornerz

iChris93 said:


> How do you decode the changes? I am only working off of the DBC that @JWardell maintains.


Using the same DBC, but edited as follows (note 11,22,33 start addresses instead of 10,20,30):

BO_ 850 ID352BMSenergy: 8 VehicleBus
SG_ BfullKWhNom352 : 0|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ BremainingKWhNom352 : 11|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ BexpectedremainKWh352 : 22|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ BidealremainKWh352 : 33|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ BtochargecompleteKWh352 : 44|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ BbufferKWh352 : 55|[email protected]+ (0.1,0) [0|25.5] "kWh" Receiver


----------



## iChris93

kornerz said:


> Using the same DBC, but edited as follows (note 11,22,33 start addresses instead of 10,20,30):
> 
> BO_ 850 ID352BMSenergy: 8 VehicleBus
> SG_ BfullKWhNom352 : 0|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
> SG_ BremainingKWhNom352 : 11|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
> SG_ BexpectedremainKWh352 : 22|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
> SG_ BidealremainKWh352 : 33|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
> SG_ BtochargecompleteKWh352 : 44|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
> SG_ BbufferKWh352 : 55|[email protected]+ (0.1,0) [0|25.5] "kWh" Receiver


Right, but how do you find out what changes need to be made to the DBC?


----------



## kornerz

iChris93 said:


> Right, but how do you find out what changes need to be made to the DBC?


It has been mentioned couple of pages back in this thread, that signals are up from 10 to 11 bit: https://teslaownersonline.com/goto/post?id=286291
Also, DBC format is well described and can be edited by hand.


----------



## JWardell

iChris93 said:


> I have questions on a few signals.
> 1) 0x252 BMS_maxRegenPower. Reading this signal I get a value of ~85, that seems wrong for kW, is it scaled by 10?
> 2) 0x252 BMS_maxDischargePower. Reading this signal I get a value of ~20, this doesn't make sense considering the maxRegen value.
> 3) 0x352 BremainingKWhNom352. Reading this signal I get a value of ~73 with a SOC of ~48%, so that value doesn't make any sense when my available storage is about 73.3 kWh. It does change, however, at ~55% its ~83.


Yes, full regen is 85kW I believe.
Max discharge sometimes reads something low when not driving, so maybe 20kW when parked is correct.
Or as mentioned, these values all just changed in .20 or .24, and I need some time to grow on trees to investigate and do DBC updates


----------



## iChris93

iChris93 said:


> It powers off instantly after I close the door and charging is complete while the USB ports and vehicle bus stay awake.


I'm monitoring the passenger seatbelt for now. Goes to NSA shortly after the chassis bus power is turned off under the seat.


----------



## JWardell

iChris93 said:


> I'm monitoring the passenger seatbelt for now. Goes to NSA shortly after the chassis bus power is turned off under the seat.


So then it sounds like I should add a timeout to the display firmware to go black after a few minutes of no server connection, for those only on this connection


----------



## codingoverdrive

Hi all... newcomer here...

It's taken a while to get up to date on this thread, but it's been worth it. What a treasure trove!

I have been decoding @JWardell ASC log file from Oct 19 - thanks for posting it (as I don't yet have my M3)

One thing I cannot see in the log file is the headlamp information, specifically O_ 1013 ID3F5VCFRONT_lighting which is marked as being on the Vehicle bus. Is the high beam and light information available on another MID, or have I missed something?

Thanks


----------



## Scubastevo80

For you guys running Teslax, is there a signal to pull "max power"? I have both front motor and rear motor power signals running fine, but I wasn't sure if there was a separate signal to pull this, or if you all were downloading data and then adding up the front + rear at various speeds to get a "total" number. I'm asking because I'm soon to upgrade to Boost/AWD+ and wanted to compare a before (133.5kW front / 228.0kW rear) and after (?).


----------



## bwilson4web

Just use the battery power for both. The vehicle overhead is not important at high power loads.

Bob Wilson


----------



## kornerz

madmaxim said:


> One thing I cannot see in the log file is the headlamp information, specifically O_ 1013 ID3F5VCFRONT_lighting which is marked as being on the Vehicle bus. Is the high beam and light information available on another MID, or have I missed something?
> 
> Thanks


I see ID3F5 in logs for my Model 3, and looks like it contains actual data (high/low beams, DRLs, fog lights, etc)


----------



## JWardell

In case you missed it...
microDisplay and CANserver announcement video was posted this week, and the store is open!
Still required ability to progam with Arduino at the moment, still need to make configuration easy, but I've waited too long


----------



## Tmo6

JWardell said:


> In case you missed it...
> microDisplay and CANserver announcement video was posted this week, and the store is open!
> Still required ability to progam with Arduino at the moment, still need to make configuration easy, but I've waited too long


Amazing, Josh! You are the man!


----------



## codingoverdrive

kornerz said:


> I see ID3F5 in logs for my Model 3, and looks like it contains actual data (high/low beams, DRLs, fog lights, etc)


Thanks - it seems to be missing from the .asc log file @JWardell made available from Oct 19.

Maybe it was introduced with a recent firmware upgrade?

Does anyone have a more recent log file (ideally .asc format) that I could look at?


----------



## Onyx

Hey guys, it's been a while! For those that remember, I was (and have now returned to) working on a project to have the CAN bus signals available in a web app on the M3's main screen. 

I'll try to post some updates soon - I've been failing pretty hard at that - just no time! 

But in the meantime, I've seen all this chatter about the chassis vs. vehicle bus. My setup taps the connector in the rear console, and is currently hooked up to the vehicle bus. Have we discovered how to get the CAN_H and CAN_L signals for the chassis bus from that same connector? My board actually has a dual CAN, so I could read from both, which would be awesome! Or are people now tapping from somewhere else that has better access to both buses?

Any hints? Thanks!


----------



## JWardell

Onyx said:


> Hey guys, it's been a while! For those that remember, I was (and have now returned to) working on a project to have the CAN bus signals available in a web app on the M3's main screen.
> 
> I'll try to post some updates soon - I've been failing pretty hard at that - just no time!
> 
> But in the meantime, I've seen all this chatter about the chassis vs. vehicle bus. My setup taps the connector in the rear console, and is currently hooked up to the vehicle bus. Have we discovered how to get the CAN_H and CAN_L signals for the chassis bus from that same connector? My board actually has a dual CAN, so I could read from both, which would be awesome! Or are people now tapping from somewhere else that has better access to both buses?
> 
> Any hints? Thanks!


No, two different places, though under the seat isn't far away from the center console.


----------



## Onyx

JWardell said:


> No, two different places, though under the seat isn't far away from the center console.


Thanks! I found your post from April:



JWardell said:


> But one thing I can offer much sooner is a *chassis bus tap* for those nerdy enough to want a CAN or ODB connection. I could hand build a few in the next few days vs waiting weeks.
> 
> So my question is, who *would be interested*? And do you think it should have and OBD connector or a DB9 connector?


Did you end up making these? I'd be interested: what I really would like is the pass-through, and I'd solder on my own harness and have it run to the M2 behind the center console, as you suggest. This would be "cleaner" than directly tapping the wires.


----------



## JWardell

Onyx said:


> Thanks! I found your post from April:
> 
> Did you end up making these? I'd be interested: what I really would like is the pass-through, and I'd solder on my own harness and have it run to the M2 behind the center console, as you suggest. This would be "cleaner" than directly tapping the wires.


I ended up adding a 3rd connection to the canserver for an additional wire harness, because I had the same need as well.


----------



## bwilson4web

SUGGESTION: owner 'black box' recorder

It occurred to me that if these CANbus data recorders had a 'round robin' file recording mechanism, it could be an owner's "black box." So the owner could have it record data in 2-5 minute files and automatically delete the oldest of 2-5 recorded files to avoid filling up the smart phone. This would provide 4-25 minutes of the latest data. In event something bad happens, the owner could find the independently recorded data on the smart phone or flash memory. Alternatively, record to flash memory in a fire resistant case. Regardless, this reduces the dependency on Tesla or any other forensic analysis.

I could imagine recording absolute time, GPS coordinates, speed, and driver inputs. Of course I would add a few engineering inputs such as motor, battery power, and critical temperatures. If G-forces are detectable, preserve the data file for a longer interval, say 2-3 days.

Bob Wilson


----------



## garsh

bwilson4web said:


> SUGGESTION: owner 'black box' recorder
> 
> It occurred to me that if these CANbus data recorders had a 'round robin' file recording mechanism, it could be an owner's "black box." So the owner could have it record data in 2-5 minute files and automatically delete the oldest of 2-5 recorded files to avoid filling up the smart phone. This would provide 4-25 minutes of the latest data. In event something bad happens, the owner could find the independently recorded data on the smart phone or flash memory. Alternatively, record to flash memory in a fire resistant case. Regardless, this reduces the dependency on Tesla or any other forensic analysis.
> 
> I could imagine recording absolute time, GPS coordinates, speed, and driver inputs. Of course I would add a few engineering inputs such as motor, battery power, and critical temperatures. If G-forces are detectable, preserve the data file for a longer interval, say 2-3 days.
> 
> Bob Wilson


It would be even nicer if you could integrate this with functionality similar to Roadie, to also keep extended camera recordings as well.
tryroadie.com


----------



## Onyx

Hey everyone, so I've been trying to figure out what type of connector the chassis bus access under the passenger seat is using. I want to build a Y-cable to tap it. I'm not an electronics guy, so I don't know if this thing has a name, but I've looked through the AMP connectors, and countless other connectors to visually find a match. If anyone could give me any hints, I'd appreciate it greatly! (I know @JWardell knows, because he sourced them, but... I don't think the parts numbers were disclosed in this thread, so maybe it's a secret? I don't know TBH, I hope straight up asking isn't a no-no, or something.)

Here are the male and female connectors I'm trying to figure out:

















Thanks!


----------



## JWardell

bwilson4web said:


> SUGGESTION: owner 'black box' recorder
> 
> It occurred to me that if these CANbus data recorders had a 'round robin' file recording mechanism, it could be an owner's "black box." So the owner could have it record data in 2-5 minute files and automatically delete the oldest of 2-5 recorded files to avoid filling up the smart phone. This would provide 4-25 minutes of the latest data. In event something bad happens, the owner could find the independently recorded data on the smart phone or flash memory. Alternatively, record to flash memory in a fire resistant case. Regardless, this reduces the dependency on Tesla or any other forensic analysis.
> 
> I could imagine recording absolute time, GPS coordinates, speed, and driver inputs. Of course I would add a few engineering inputs such as motor, battery power, and critical temperatures. If G-forces are detectable, preserve the data file for a longer interval, say 2-3 days.
> 
> Bob Wilson


that's one of the goals of the CANserver as it has an SD card to log to. rolling full speed buffer, plus long term slow filtered data, can be integrated easily with cloud servers for something like TeslaFi on steroids!



Onyx said:


> Hey everyone, so I've been trying to figure out what type of connector the chassis bus access under the passenger seat is using. I want to build a Y-cable to tap it. I'm not an electronics guy, so I don't know if this thing has a name, but I've looked through the AMP connectors, and countless other connectors to visually find a match. If anyone could give me any hints, I'd appreciate it greatly! (I know @JWardell knows, because he sourced them, but... I don't think the parts numbers were disclosed in this thread, so maybe it's a secret? I don't know TBH, I hope straight up asking isn't a no-no, or something.)
> 
> Here are the male and female connectors I'm trying to figure out:
> View attachment 34792
> 
> View attachment 34793
> 
> 
> Thanks!


Yes they are MQS and what I use to plug the can server in. Thats also why it has a third can connection for those of us that would like to use it as a splitter for other devices as well. I've wired an OBD connector output so I could plug the OBD link alongside the server and run live with teslax etc. it's how my recordings are recording both busses simultaneously


----------



## ArchGryphon9362

Might seem like a bit of a noob question... but why are there 2 busses, a VehicleBus and a ChassisBus and is there any way to send signals to the ChassisBus using the connector under the rear AC of the car? And if not, how would I go about connecting to the ChassisBus *(I am currently connecting to it using a custom made Arduino shield)*

*Edit: *I meant to which busses can I send signals to using that connector?


----------



## Mr.K

ArchGryphon9362 said:


> *Edit: *I meant to which busses can I send signals to using that connector?


Pin out from earlier post on this thread. (The old connector i think)
https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/page-28#post-207680


----------



## JWardell

ArchGryphon9362 said:


> Might seem like a bit of a noob question... but why are there 2 busses, a VehicleBus and a ChassisBus and is there any way to send signals to the ChassisBus using the connector under the rear AC of the car? And if not, how would I go about connecting to the ChassisBus *(I am currently connecting to it using a custom made Arduino shield)*
> 
> *Edit: *I meant to which busses can I send signals to using that connector?


There are even more than those two busses on the Model 3: Vehicle, Chassis, and Party busses are the main can busses that route around the car. There are a few more local can buses like within the HV module, between the computer and autopilot, and the radar and the computer. But...the Vehicle and Chassis are the two we can get reasonably easy access to in the cabin without taking parts of the car apart or splicing into things.

If you are tapped on to a bus, well then there is nothing to stop you from transmitting TO it, however that would be extremely dangerous as you could instantly take important things like your motor or battery offline. This is why unlike other products out there I have the transmit disabled in the canserver hardware.


----------



## ArchGryphon9362

JWardell said:


> There are even more than those two busses on the Model 3: Vehicle, Chassis, and Party busses are the main can busses that route around the car. There are a few more local can buses like within the HV module, between the computer and autopilot, and the radar and the computer. But...the Vehicle and Chassis are the two we can get reasonably easy access to in the cabin without taking parts of the car apart or splicing into things.
> 
> If you are tapped on to a bus, well then there is nothing to stop you from transmitting TO it, however that would be extremely dangerous as you could instantly take important things like your motor or battery offline. This is why unlike other products out there I have the transmit disabled in the canserver hardware.


Ok, good to know. I only send signals to stuff like glovebox or lighting but nothing even close to critical. I'm not scared sending stuff to the glovebox for example because it's not that bad if that won't open, but I do not send signals to stuff like the battery because I could easily damage something and the car wouldn't even go.

Anyways thx for the info! Cheers 😁


----------



## Onyx

RE: making a y-connector for the chassis bus access under the passenger seat

Thanks @JWardell! With your information, I was able to find the parts and have ordered them. Disappointingly , it cost me about what you charge for the can server (have to order in quantity). But, I promised myself I wouldn't do any wonky mods on my 3: the car's engineering is spectacular, and I don't want to "diminish it".  This will keep everything reversible and removable.


----------



## JWardell

ArchGryphon9362 said:


> Ok, good to know. I only send signals to stuff like glovebox or lighting but nothing even close to critical. I'm not scared sending stuff to the glovebox for example because it's not that bad if that won't open, but I do not send signals to stuff like the battery because I could easily damage something and the car wouldn't even go.
> 
> Anyways thx for the info! Cheers 😁


If you know what you are doing and sending messages safely, then you might also be smart enough to figure out how to re-enable transmit on the board, for for everyone's safety I'm not documenting that nor allowing it in the public software. But of course you can do whatever you want with the board and software...



Onyx said:


> RE: making a y-connector for the chassis bus access under the passenger seat
> 
> Thanks @JWardell! With your information, I was able to find the parts and have ordered them. Disappointingly , it cost me about what you charge for the can server (have to order in quantity). But, I promised myself I wouldn't do any wonky mods on my 3: the car's engineering is spectacular, and I don't want to "diminish it".  This will keep everything reversible and removable.


Yeah, the connectors aren't exactly cheap, but well worth it for simple plug and play. You can get away with .100" SIP connectors and pins, but I worry about it falling out. My hope is folks will grab a canserver and use it for their own breakout purposes and projects, and maybe add more capabilities to the software while they're at it.


----------



## Onyx

JWardell said:


> You can get away with .100" SIP connectors and pins, but I worry about it falling out


Yeah, I went with the "official" ones - that was the most expensive part of my order because the smallest quantity I could find was 100 units of each. I don't know enough about electronics to improvise. Even figuring out what to order for "the straightforward way" has been a challenge. It's a whole crazy new world to me once you go beyond the common connectors.

I also wondered if I'd be able to crimp these things with my "normal" crimping tool. TE wanted ~400$ for their crimper!


----------



## JWardell

Onyx said:


> Yeah, I went with the "official" ones - that was the most expensive part of my order because the smallest quantity I could find was 100 units of each. I don't know enough about electronics to improvise. Even figuring out what to order for "the straightforward way" has been a challenge. It's a whole crazy new world to me once you go beyond the common connectors.
> 
> I also wondered if I'd be able to crimp these things with my "normal" crimping tool. TE wanted ~400$ for their crimper!


Yeah, tell me about it, now you know why I've invested thousands of dollars (not to mention hours of time), but happy I can now can make these available to everyone, at least at the DIY-er level right now. Hope to eventually make everything polished enough for simple use by anyone. Also why I wanted to target sub-$100


----------



## REGuy

amund7 said:


> There are quite a few: https://play.google.com/store/apps/details?id=com.emon.canbus.tesla
> But you soon realize that making a good looking and fast display for an any of these is very hard.


Check out Kivy for Android. Supposedly you can deploy IOS apps with it too, but I've never done it.

Kivy has been used for some automotive dash GUIs.

https://kivy.org/#home


----------



## REGuy

Collin80 said:


> I also found that SerialBus is not supported on OSX though I have no idea why. On Windows and Linux you can use devices like Peak CAN devices with SavvyCAN (and anything socketcan on linux) but on OSX for some reason there isn't any QT SerialBus support so only the *RET devices will work.


I'm not an OSX guy but I think that QTSerialBus needs direct access to /dev/bus/usb and OSX doesn't allow that. Or something like that. It isn't as simple as /dev/ttyUSB0.


----------



## REGuy

fast_like_electric said:


> The 0x401 (and 0x712) info has been mentioned in this thread for awhile (since the early decoding), so it could have been realized by someone that those battery debug messages shouldn't have been left there and they were gutted.
> 
> Just somewhat bizarre that Jack writes a program to display that 0x401 info with his setup, does a video that describes it in detail, and then the messages are removed from the Vehicle bus. Bad luck at least for sure. Too bad, as those were handy messages on that easy to access bus.


That CAN bus seems pretty busy with messages. Not every device needs to broadcast its data all the time. After all, what other device in the car needs to know cell voltages that frequently ? I'm guessing that data will still be available, but probably only after being polled.

Not sure if Tesla abides by this rule or not, but if it were me, I would not reuse a PID immediately after changing it. Because the chance of misuse is too high. If that is the case, you guys can easily find what has changed between versions by comparing the PID list from version to version.


----------



## REGuy

0x6d33 said:


> @Collin80 @JWardell
> 
> I spent most of yesterday trying to add bluetooth support to the EVTV ESP32. Unfortunately, I ran into a few problems. The first problem was adding the bluetooth libraries made the program size larger than the ROM size for app0. For some reason the Arduino IDE partitions the ROM for two apps (app0 and app1). This issue can be mitigated by removing app1 from the partition table (esp32/board.txt) and allocating all the space to app0.


The variant of ESP32 you are using actually has 2 processor cores. Thus you are given 2 application memory spaces, one for each core. One of the spaces is supposed to be used for code that runs on the core that services the network interface (Bluetooth in this instance). The other memory space is supposed to be for the core that runs "the program", ie the main task.

Did the code have a HAL or #define to set things up ?


----------



## REGuy

amund7 said:


> If you are designing the electronics from the ground up, how hard/expensive would it be to mimic the functionality of the Can Crocodile? An inductive sniffer that you clip on the wires, no unplugging, no need to get the correct plugs, and would theoretically work with any canbus car/tractor/bus/airplane/UFO in the universe.


Not a good idea to try to inductively couple a transducer/sensor to read CAN messages at 1Mbit/sec, as some are. Note that, at the very minimum, this requires untwisting some of the twisted pair.

If you get desperate, pin probes and heat shrink tape or clear nail polish work.


----------



## REGuy

0x6d33 said:


> Speaking of FPGA, I've been working on a CAN reader implemented in an FPGA. It decodes the CAN data from the transceiver and sends the decode message in ASCII over a UART at 1 Mbit/sec. Since the UART is running at twice the speed of the CAN bus, there should be no data loss.
> 
> I've got it mostly working at this point. There just a few bugs I need to iron out. In addition, I need to add CRC checking.
> 
> My motivation is to accurately measure the amount of CAN message sent per second.


Just count the number of valid CAN message headers you get. Am I missing something ?

I suspect the reason the ESP32 isn't keeping up is because the code servicing the network interface is running on the same core as the code servicing the CAN interface. They need to run on separate cores. And DMA should be used between the two. The processors should be doing very little.


----------



## REGuy

juanmax said:


> *I found out two signals are wrong in the dbc. *The correction is found here: (offset negative, signed value type). With this changes my model 3 performance shows currents up to (well, actually down to) -1200A. With the current dbc you linked, clipping occurs at 900A
> 
> I am still struggling to find wheel speeds on this bus. How can it be that there are nowhere to be found? Also tried chassis CAN.
> 
> View attachment 26105


I don't want to pick on anyone, but signals and messages are different.

Signals are generally voltage (or current) waveforms sent on a wire. Messages are pieces of data in a computer.

If you tell me a signal is wrong, I get out an oscilloscope and look at a schematic.

If you tell me a message is wrong, I pull out a debugger and start looking at source code.

Just saying...


----------



## REGuy

amund7 said:


> I thought of something. Since the ethernet bus seems to have all the data, can we either connect, or sniff those wires? How cool would it be if there exists an inductive ethernet sniffer that anyone could clamp on a wire somewhere, and read ALL the info from ALL the can-buses. Or are there reasons this can't be done ? (Encryption comes to mind)


What makes you think an Ethernet "bus" would have "all the data" ?

The reason vehicles use CAN Bus is because of the low overhead and low latency. And low number of wires and differential signalling. And simple network interfaces.

TCP/IP stacks have tons of overhead and latency. Ethernet interfaces are complicated. Ethernet needs way more than a twisted pair as a backbone.

Data only gets sent around a vehicle on a need to know basis. I think the chances of finding a lot of this low level data on an Ethernet network is very low, unless something higher up a) needs to know it and b) isn't connected to the 3 CAN Buses in the vehicle.


----------



## JWardell

REGuy said:


> I don't want to pick on anyone, but signals and messages are different.
> 
> Signals are generally voltage (or current) waveforms sent on a wire. Messages are pieces of data in a computer.
> 
> If you tell me a signal is wrong, I get out an oscilloscope and look at a schematic.
> 
> If you tell me a message is wrong, I pull out a debugger and start looking at source code.
> 
> Just saying...


You do realize you are replying to messages that are many many months old?

Juanmax is correct, signals refer to the pieces of data in the database, and messages are the CAN messages that contain those signals in a particular Message ID.

You may be confusing CAN with J1939, as I saw you mention PIDs earlier, which are 1939 not CAN.


----------



## JWardell

REGuy said:


> What makes you think an Ethernet "bus" would have "all the data" ?
> 
> The reason vehicles use CAN Bus is because of the low overhead and low latency. And low number of wires and differential signalling. And simple network interfaces.
> 
> TCP/IP stacks have tons of overhead and latency. Ethernet interfaces are complicated. Ethernet needs way more than a twisted pair as a backbone.
> 
> Data only gets sent around a vehicle on a need to know basis. I think the chances of finding a lot of this low level data on an Ethernet network is very low, unless something higher up a) needs to know it and b) isn't connected to the 3 CAN Buses in the vehicle.


Again, you are incorrect, as I think you are generalizing and do not have specific knowledge of Tesla's design. All the data is on ethernet busses, within the computer. In fact the computer has no knowledge of CAN, it thinks these are all ethernet busses. There is an ethernet gateway that controls access, filters, rebroadcasts, and even relocates data between the ouside can busses and the computer, as well as the diagnostic ethernet port, and the autopilot computer.
In fact, many modern cars are leaning this direction with an ethernet backbone along with multiple CAN busses. Ethernet, and the computers running it, is much much faster than any CAN network and simple microcontrollers that are connected at the nodes.


----------



## REGuy

JWardell said:


> Seems to not have 2018 model 3 cables.
> Also seems our two cable sources here have dried up.
> Lack of cables have contributed to my feet dragging...


Getting access to OEM connectors is always a pain.

There are a couple ways to address this without cutting wires.

1) You can get really small pin ends for wires. Slide them alongside the outside of a wire until they penetrate and touch the conductor. Tape them in place. When you are done, slide out the pins. It leaves only a pinhole, depending on the insulation on the wire.

2) All cables are made by crimping pins (or sockets) onto wires and then inserting pins (or sockets) into connectors. This means that those pins (or sockets) are removeable from the connector body.

Usually the removal tool looks like a small tube that is just larger than the pin itself. If you can find the right sized tube, pushing the tube over the pin/socket will collapse the "wings" that holds it into the connector and you can remove the pins you need without damaging them.

Then find similar pins (or sockets) and create a replacement pigtail for the pins/sockets removed and crimp a butt connector onto the true pins/sockets to make a connection to it. Or solder wires to the pin/connect where the wire is crimped onto the pin/connector. When you are done the project, unsolder the wires and reinsert your pins into the connector and it looks as if nothing was ever done.

3) Find sockets and pins that fit the connector. Make socket/pin pairs by soldering sockets to pins, end to end. Push a socket/pin pair onto every pin on one connector and then onto every pin on the other connector. If you want to get fancy, put a breakout board between the sockets and pins. Or make socket to pin connectors with lengths of wires.

There are lots of ways to skin this cat.


----------



## REGuy

JWardell said:


> Juanmax is correct, signals refer to the pieces of data in the database, and messages are the CAN messages that contain those signals in a particular Message ID.


Yes, messages travel on a CAN bus, via signals. Signals are like 0 to 5V, 4 to 20 ma, sawtooth, PWM, etc. Messages are bit streams, which are signals. Nobody says they saw a PWM message on a wire. The right terminology is a CAN message bit stream.

CAN messages are encoded as "non-return-to-zero (NRZ) coding" as the signal. "The signal level can remain constant over a longer period of time if the transmitted bits have the same logical value."



> You may be confusing CAN with J1939, as I saw you mention PIDs earlier, which are 1939 not CAN.


 I was too many of Jack's posts and thinking of ELM324s.


----------



## JWardell

REGuy said:


> Yes, messages travel on a CAN bus, via signals. Signals are like 0 to 5V, 4 to 20 ma, sawtooth, PWM, etc. Messages are bit streams, which are signals. Nobody says they saw a PWM message on a wire. The right terminology is a CAN message bit stream.
> 
> CAN messages are encoded as "non-return-to-zero (NRZ) coding" as the signal. "The signal level can remain constant over a longer period of time if the transmitted bits have the same logical value."
> 
> I was too many of Jack's posts and thinking of ELM324s.


The terminoligy for DBC files is Messages and Signals. This is what we are referring to, specifically as he was speaking about the DBC file.



REGuy said:


> Getting access to OEM connectors is always a pain.
> 
> There are a couple ways to address this without cutting wires.
> 
> 1) You can get really small pin ends for wires. Slide them alongside the outside of a wire until they penetrate and touch the conductor. Tape them in place. When you are done, slide out the pins. It leaves only a pinhole, depending on the insulation on the wire.
> 
> 2) All cables are made by crimping pins (or sockets) onto wires and then inserting pins (or sockets) into connectors. This means that those pins (or sockets) are removeable from the connector body.
> 
> Usually the removal tool looks like a small tube that is just larger than the pin itself. If you can find the right sized tube, pushing the tube over the pin/socket will collapse the "wings" that holds it into the connector and you can remove the pins you need without damaging them.
> 
> Then find similar pins (or sockets) and create a replacement pigtail for the pins/sockets removed and crimp a butt connector onto the true pins/sockets to make a connection to it. Or solder wires to the pin/connect where the wire is crimped onto the pin/connector. When you are done the project, unsolder the wires and reinsert your pins into the connector and it looks as if nothing was ever done.
> 
> 3) Find sockets and pins that fit the connector. Make socket/pin pairs by soldering sockets to pins, end to end. Push a socket/pin pair onto every pin on one connector and then onto every pin on the other connector. If you want to get fancy, put a breakout board between the sockets and pins. Or make socket to pin connectors with lengths of wires.
> 
> There are lots of ways to skin this cat.


Again, this is ancient. There are plenty of posts showing my initial pins-on-wires techniques, and then we got the real connectors, and now harnesses are very commonly available for purchase by anyone.

Please, Please first go through the thread before posting dozens of replies to old posts. There has been a lot of progress in this thread over the years.


----------



## REGuy

JWardell said:


> Again, you are incorrect, as I think you are generalizing and do not have specific knowledge of Tesla's design. All the data is on ethernet busses, within the computer. In fact the computer has no knowledge of CAN, it thinks these are all ethernet busses. There is an ethernet gateway that controls access, filters, rebroadcasts, and even relocates data between the ouside can busses and the computer, as well as the diagnostic ethernet port, and the autopilot computer.
> In fact, many modern cars are leaning this direction with an ethernet backbone along with multiple CAN busses. Ethernet, and the computers running it, is much much faster than any CAN network and simple microcontrollers that are connected at the nodes.


We really disagree here.

The Ethernet network between the MCU, AP, etc. may share some of the CANBus data, but it surely doesn't share all of it, it doesn't share it as fast and the data it shares certainly isn't real time. Think about it... the vehicle CAN bus is nearly full at 1Mb/sec using a super light network protocol/message stack. Do you know how much bandwidth it would take to duplicate that level of communication on a TCP/IP stack ? It would be insane. To say nothing of the lack of noise immunity on the Ethernet backbone or the network latency between messages.

If Ethernet was a realistic method of real time communication between the vehicle modules, why didn't Tesla use it ? Ethernet was never designed as a real time network. CANBus is.

The "computer" (MCU ?) absolutely knows about the CAN bus because it talks to it and it certainly doesn't use the TCP/IP stack to do so.

BTW, when Tesla does a firmware update, the vehicle modules receive their firmware updates over their CANBus. That is how the modules know how to respond to or transmit messages with a new ID.


----------



## JWardell

REGuy said:


> We really disagree here.
> 
> The Ethernet network between the MCU, AP, etc. may share some of the CANBus data, but it surely doesn't share all of it, it doesn't share it as fast and the data it shares certainly isn't real time. Think about it... the vehicle CAN bus is nearly full at 1Mb/sec using a super light network protocol/message stack. Do you know how much bandwidth it would take to duplicate that level of communication on a TCP/IP stack ? It would be insane. To say nothing of the lack of noise immunity on the Ethernet backbone or the network latency between messages.
> 
> If Ethernet was a realistic method of real time communication between the vehicle modules, why didn't Tesla use it ? Ethernet was never designed as a real time network. CANBus is.
> 
> The "computer" (MCU ?) absolutely knows about the CAN bus because it talks to it and it certainly doesn't use the TCP/IP stack to do so.
> 
> BTW, when Tesla does a firmware update, the vehicle modules receive their firmware updates over their CANBus. That is how the modules know how to respond to or transmit messages with a new ID.


You know, Ethernet and TCP/IP are two different things. You don't need TCP/IP for ethernet. There are tons of other protocols that can use ethernet. In fact many can ride on it simultaneously. Afterall you are comparing a 500kbps CAN network to a gigabit ethernet network. There is plenty of overhead for real time signals.
And again, this is not opinion, this is fact, I was telling you how it Tesla implemented it.


----------



## REGuy

JWardell said:


> You know, Ethernet and TCP/IP are two different things. You don't need TCP/IP for ethernet. There are tons of other protocols that can use ethernet. In fact many can ride on it simultaneously. Afterall you are comparing a 500kbps CAN network to a gigabit ethernet network. There is plenty of overhead for real time signals.
> And again, this is not opinion, this is fact, I was telling you how it Tesla implemented it.


Several people have put a plain switch on the Ethernet network on the Model S/X. And connected to the MCU on that network with SSH from a plain computer via the switch. So what protocol is it running ? Is the Model 3 different from the Model S/X ?

As far as I know, SSH only runs on a TCP/IP stack. https://www.seqrite.com/blog/wp-content/uploads/2019/08/02.jpg


----------



## REGuy

"Some reverse engineering of this service showed that the Tesla Model S does NOT seem to send raw CAN frames from the infotainment system to the vehicle. Instead, there is a Vehicle API (VAPI) whereby the CID asks the gateway to perform any one of an "allowed" set of actions.

The existence of a gateway that operates in this manner is very good for the resilience of the car, for it means that even if the infotainment network is compromised, that does not grant an attacker the ability to inject raw CAN frames into the vehicle network. They can only send "legitimate" VAPI requests."

https://blog.lookout.com/hacking-a-tesla

Tesla is not using Time Sensitive Networking (TSN, 802.1) and even if it was, it can't co exist with TCP/IP. As far as I know the Model 3 and Model S Ethernet networks use TCP/IP.

https://www.embedded-computing.com/...e-ethernet-a-crossroads-for-the-connected-car

https://elinux.org/images/5/56/ELC-2018-USA-TSNonLinux.pdf

https://www.kontron.com/products/io...tsn/pcie-0400-tsn-network-interface-card.html

As far as I know "Ethernet" means 802.3, which means CSMA/CD, which is a non deterministic messaging system. Doesn't matter what protocol you run on it. 802.1 TSN is deterministic, but requires nodes to keep strict timing. Totally different than 802.3.

This diagram of Model 3 communications labels the network between the MCU and ECU as "Ethernet". https://teslaownersonline.com/threa...ccess.7502/page-66#lg=attachment31447&slide=0

I'm here to learn. Correct me if I'm wrong.


----------



## Garlan Garner

REGuy said:


> "Some reverse engineering of this service showed that the Tesla Model S does NOT seem to send raw CAN frames from the infotainment system to the vehicle. Instead, there is a Vehicle API (VAPI) whereby the CID asks the gateway to perform any one of an "allowed" set of actions.
> 
> The existence of a gateway that operates in this manner is very good for the resilience of the car, for it means that even if the infotainment network is compromised, that does not grant an attacker the ability to inject raw CAN frames into the vehicle network. They can only send "legitimate" VAPI requests."
> 
> https://blog.lookout.com/hacking-a-tesla
> 
> Tesla is not using Time Sensitive Networking (TSN, 802.1) and even if it was, it can't co exist with TCP/IP. As far as I know the Model 3 and Model S Ethernet networks use TCP/IP.
> 
> https://www.embedded-computing.com/...e-ethernet-a-crossroads-for-the-connected-car
> 
> https://elinux.org/images/5/56/ELC-2018-USA-TSNonLinux.pdf
> 
> https://www.kontron.com/products/io...tsn/pcie-0400-tsn-network-interface-card.html
> 
> As far as I know "Ethernet" means 802.3, which means CSMA/CD, which is a non deterministic messaging system. Doesn't matter what protocol you run on it. 802.1 TSN is deterministic, but requires nodes to keep strict timing. Totally different than 802.3.
> 
> This diagram of Model 3 communications labels the network between the MCU and ECU as "Ethernet". https://teslaownersonline.com/threa...ccess.7502/page-66#lg=attachment31447&slide=0
> 
> I'm here to learn. Correct me if I'm wrong.


He's trying to correct you.


----------



## fast_like_electric

REGuy said:


> Yes, messages travel on a CAN bus, via signals. Signals are like 0 to 5V, 4 to 20 ma, sawtooth, PWM, etc. Messages are bit streams, which are signals. Nobody says they saw a PWM message on a wire. The right terminology is a CAN message bit stream.


Within an automotive CAN system, the term 'signals' and 'messages' are what the industry leaders use to define the system. Messages are the CAN frames, 'signals' are the data packed into the frame. Signals can vary in bits and bytes in length, scaling, and format. Originally meant to encode something like a analog temperature value or voltage reading for example, but extended to represent things like states as well. Vector is the main company in automotive CAN in the US, and they define the vehicle layout in the .dbc file format that we are using here. As such, signals are the terminology used - albiet different from what you would think for an electrical signal on a wire in electronics.


----------



## juanmax

JWardell said:


> The terminoligy for DBC files is Messages and Signals. This is what we are referring to, specifically as he was speaking about the DBC file.
> 
> .


Exactly


----------



## WhiteModel3

I'm not sure if i missed this in the latest dbc, but I'm looking for the maximum torque (both motoring and regen) as a function of motor speed.
I'm trying to get a full understanding of the pedal map.


----------



## JWardell

WhiteModel3 said:


> I'm not sure if i missed this in the latest dbc, but I'm looking for the maximum torque (both motoring and regen) as a function of motor speed.
> I'm trying to get a full understanding of the pedal map.


I've always meant to do a study of the pedal map, very curious if it is simple or complicated. Should simply be pedal position vs torque request. The question is if the zero point where it flips to regen is always in the same spot or changes by speed or situation


----------



## iChris93

JWardell said:


> I've always meant to do a study of the pedal map, very curious if it is simple or complicated. Should simply be pedal position vs torque request. The question is if the zero point where it flips to regen is always in the same spot or changes by speed or situation


Depending on where traction control and other stability programs come in, it may not be that simple.


----------



## WhiteModel3

@JWardell Based on your latest log, Model3Log2019-10-02v10, I basically just look at when the torque request = 0, what were the speed and pedal values.
So this is what I have come up so far.









Also, I believe you were in "Sport" mode here, so it'll be more interesting to see how the mapping changes in different modes.
So, if there are any one here who has more logs of each driving mode, I would be happy to look at them. The longer the logs, the better.


----------



## JWardell

WhiteModel3 said:


> @JWardell Based on your latest log, Model3Log2019-10-02v10, I basically just look at when the torque request = 0, what were the speed and pedal values.
> So this is what I have come up so far.
> 
> View attachment 34914
> 
> Also, I believe you were in "Sport" mode here, so it'll be more interesting to see how the mapping changes in different modes.
> So, if there are any one here who has more logs of each driving mode, I would be happy to look at them. The longer the logs, the better.


I think internally Chill mode used to be referred to as half pedal map, I bet you it's just a simple linear division function.
So I think you're saying the faster you're going the further pressed the zero torque point on the pedal is? I guess that makes sense.


----------



## Feathermerchant

If the pedal was just mapped to torque, it would be really hard to keep a constant speed. It only takes about 25 kW for my Model 3 to maintain a constant 75 mph.
If mapped only speed, then if you pushed down half way on my car, it would jump to about 80 mph. Just a guess but is may mimic the speed/torque relationship an air throttle produces on an ICE because that's what we are used to.


----------



## Onyx

Alright, one chassis can bus cable made and successfully tested (on my wife, didn't tell her she was driving with an experimental hardness - oops!). And I know I'm not an electronics guy, but my goodness that was harder than I thought it would be. Those connectors don't allow for much crimping play. I also overdid it on the wires, I used 20 AWG instead of 22 AWG, which is within tolerances, but maybe that's why it was so hard to fit the pins? At any rate, I'll probably try to make another one with some 22 AWG and see if that's better.










Next step, I'll splice into the blue and white signal wires and route those to my Macchina M2 that is tacked onto the back of the center console. I've already got all the software ready to go, so I should have dual-can access this week. Hopefully.


----------



## JWardell

Onyx said:


> Alright, one chassis can bus cable made and successfully tested (on my wife, didn't tell her she was driving with an experimental hardness - oops!). And I know I'm not an electronics guy, but my goodness that was harder than I thought it would be. Those connectors don't allow for much crimping play. I also overdid it on the wires, I used 20 AWG instead of 22 AWG, which is within tolerances, but maybe that's why it was so hard to fit the pins? At any rate, I'll probably try to make another one with some 22 AWG and see if that's better.
> 
> View attachment 34930
> 
> 
> Next step, I'll splice into the blue and white signal wires and route those to my Macchina M2 that is tacked onto the back of the center console. I've already got all the software ready to go, so I should have dual-can access this week. Hopefully.


Don't cut the red wire!! 

Now you know some of the crimping fun I have each week


----------



## WhiteModel3

JWardell said:


> I think internally Chill mode used to be referred to as half pedal map, I bet you it's just a simple linear division function.
> So I think you're saying the faster you're going the further pressed the zero torque point on the pedal is? I guess that makes sense.


Oh Yeah? Chill Mode is Half?

Does this mean at Full Pedal, the "Chill Mode" request is 50% or some factor of the "Sport Mode"?

I haven't really tried this mode and compares..


----------



## Onyx

It's Alive! Chassis bus tap works under the passenger seat works!










Sort of.

As soon as I put the car in gear, the messages stop coming in. Do you guys think it's a software problem on my side, or is there a known issue with that tap location?


----------



## JWardell

WhiteModel3 said:


> Oh Yeah? Chill Mode is Half?
> 
> Does this mean at Full Pedal, the "Chill Mode" request is 50% or some factor of the "Sport Mode"?


I saw that somewhere some time...Never confirmed it. Never made any logs in chill mode, it's not worth the minute of torture 



Onyx said:


> It's Alive! Chassis bus tap works under the passenger seat works!
> 
> View attachment 34938
> 
> 
> Sort of.
> 
> As soon as I put the car in gear, the messages stop coming in. Do you guys think it's a software problem on my side, or is there a known issue with that tap location?


It turns off when the car goes to sleep, but certainly not when driving. I've been logging from there for months now. Either a wire is loose or you have a strange software bug.
(And if the wiring was loose, you would get restraint system errors once you go into drive)


----------



## WhiteModel3

Feathermerchant said:


> If the pedal was just mapped to torque, it would be really hard to keep a constant speed. It only takes about 25 kW for my Model 3 to maintain a constant 75 mph.
> If mapped only speed, then if you pushed down half way on my car, it would jump to about 80 mph. Just a guess but is may mimic the speed/torque relationship an air throttle produces on an ICE because that's what we are used to.


I didn't really explained much why i created a "map" for Pedal and Speed. It's about Torque Request (as a percentage of max available toque) being dependent to Pedal and Speed. I thought about percentage because max torque decreases as speed increases.

100% Torque request in low speed is different from high speed (in terms of Nm). -100% means Full Regen.









I know this sounds simple and I'm sure there are other factors missing like ramp rates, filters, etc. But using this table is a good start to understand. And again, this is just the "Request" portion before applying Traction Control and such.


----------



## WhiteModel3

JWardell said:


> I saw that somewhere some time...Never confirmed it. Never made any logs in chill mode, it's not worth the minute


I have access to a NeoVI data logger. Do I just buy/install the splitter, connect the logger in, and call it a day?


----------



## Onyx

JWardell said:


> It turns off when the car goes to sleep, but certainly not when driving. I've been logging from there for months now. Either a wire is loose or you have a strange software bug.


Yeah, false alarm - just a software bug on my side. Works beautifully now! Amazing to see all the new chassis signals!


----------



## JWardell

WhiteModel3 said:


> I have access to a NeoVI data logger. Do I just buy/install the splitter, connect the logger in, and call it a day?


That's basically what I have always done.
That's why the CANserver has a 3rd CAN connection, for the few of us that would like to add additional can hardware easily.
Though I think we are fairly close to having logging capability to the SDcard directly on the canserver. Then no need for expensive hardware and messy cables!


----------



## codingoverdrive

I'm building a CANBUS network to simulate a Tesla Model 3 by replaying CAN log files as I work on my display unit project.

I'm using two raspberry pi's and a USB->CANBUS board from Inno-Maker. These work well and I can transmit and receive can messages easily.

When I connect my scope to analyse messages (running the bus at 500kbps), I see that the wave form is quite dirty; even with the probe set to 10X.

Should I expect a cleaner signal on the scope?


----------



## codingoverdrive

Basic schoolboy error... forgot to connect the earth line between the two can bus transceivers...










Better now at especially with probe set to 1x

Edit: removed incorrect image


----------



## Mr.K

Any signal indicating preconditioning for supercharging?
'UI_requestActiveBatteryHeating' in 0x082 seems to turn to 1 when selecting navigate to supercharger, but it doesn't turn back to 0 when it stops or even if i get out of the car.


----------



## 3ngineer

Has anyone used the ports highlighted in the video in the edited OP for write access to the CID in any way? Or is this read only/write to CANBUS only?


----------



## Mike

3ngineer said:


> Has anyone used the ports highlighted in the video in the edited OP for write access to the CID in any way? Or is this read only/write to CANBUS only?


Unfortunately I can't answer your question because this discussion is way over my head, but I wanted to say welcome to the forum and I love your avatar. Very cool!


----------



## JWardell

Mr.K said:


> Any signal indicating preconditioning for supercharging?
> 'UI_requestActiveBatteryHeating' in 0x082 seems to turn to 1 when selecting navigate to supercharger, but it doesn't turn back to 0 when it stops or even if i get out of the car.


You can see the waste heat generated by each motor or the system as a whole. When you navigate to a supercharger, you can see them all jump up. Or when you precondition in the cold:







3ngineer said:


> Has anyone used the ports highlighted in the video in the edited OP for write access to the CID in any way? Or is this read only/write to CANBUS only?


Not quite sure what you mean by write to the CID, but transmitting on the can bus is definitely not recommended, you can certainly screw things up or at least alert the mothership


----------



## marcus_54

Hello,

I am French (sorry for my English) and I have a Model3

I looked through the forum pages and found some interesting information.

I am using RaceChrono pro and the busCAN.

Using the Excel Model 3 CAN bus IDs and data.xlsx file I found the data, but I did not get the right results.

Can you tell me why ?
Thank you

0x3FE 1000 5
FL brake temp C u10 SB 0 scale 1 offset -40
FR brake temp C u10 SB 10 scale 1 offset -40
RL brake temp C u10 SB 20 scale 1 offset -40
RR brake temp C u10 SB 30 scale 1 offset -40

*FL : bitsToUint (raw, 0, 10)-40
RL : bitsToUint (raw, 20, 10)-40*

0x321 1000 8
CoolantTempBatteryInlet C u10 SB 0 scale 0.125 offset -40
CoolantTempPowertrainInlet C u10 SB 10 scale 0.125 offset -40
Ambient Temp Raw C u8 SB 24 scale 0.5 offset -40
Ambient Temp Filtered C u8 SB 40 scale 0.5 offset -40

*(bitsToUint (raw, 0, 10)/8)-40*

0x33A 8
UI Rated Range Mi u10 SB 0 scale 1
UI Ideal Range Mi u10 SB 16 scale 1
Rated WH/Mi u10 SB32 scale 1
UI SOE SOC % u7 SB 48 scale 1
UI unfiltered SOE % u7 SB 56 scale 1

*bitsToUint (raw, 48, 7)*


----------



## Mr.K

marcus_54 said:


> Hello,
> 
> I am French (sorry for my English) and I have a Model3
> 
> I looked through the forum pages and found some interesting information.
> 
> I am using RaceChrono pro and the busCAN.
> 
> Using the Excel Model 3 CAN bus IDs and data.xlsx file I found the data, but I did not get the right results.
> 
> Can you tell me why ?
> Thank you
> 
> 0x3FE 1000 5
> FL brake temp C u10 SB 0 scale 1 offset -40
> FR brake temp C u10 SB 10 scale 1 offset -40
> RL brake temp C u10 SB 20 scale 1 offset -40
> RR brake temp C u10 SB 30 scale 1 offset -40
> 
> *FL : bitsToUint (raw, 0, 10)-40
> RL : bitsToUint (raw, 20, 10)-40*
> 
> 0x321 1000 8
> CoolantTempBatteryInlet C u10 SB 0 scale 0.125 offset -40
> CoolantTempPowertrainInlet C u10 SB 10 scale 0.125 offset -40
> Ambient Temp Raw C u8 SB 24 scale 0.5 offset -40
> Ambient Temp Filtered C u8 SB 40 scale 0.5 offset -40
> 
> *(bitsToUint (raw, 0, 10)/8)-40*
> 
> 0x33A 8
> UI Rated Range Mi u10 SB 0 scale 1
> UI Ideal Range Mi u10 SB 16 scale 1
> Rated WH/Mi u10 SB32 scale 1
> UI SOE SOC % u7 SB 48 scale 1
> UI unfiltered SOE % u7 SB 56 scale 1
> 
> *bitsToUint (raw, 48, 7)*


https://racechrono.com/support/equations
bitsToUint(source, bitOffset, bitLength)
Returns unsigned integer value, extracted from the source value. Bit offset 0 is the bit with highest significance (big-endian).

I think the problem might be the bit order, big-endian in racechrono and little-endian in Tesla.

Edit: after reading it again, i think i misunderstood it. Changed my mind.  Lets get an expert in here!


----------



## Onyx

marcus_54 said:


> Hello,
> 
> 0x3FE 1000 5
> FL brake temp C u10 SB 0 scale 1 offset -40
> FR brake temp C u10 SB 10 scale 1 offset -40
> RL brake temp C u10 SB 20 scale 1 offset -40
> RR brake temp C u10 SB 30 scale 1 offset -40
> 
> *FL : bitsToUint (raw, 0, 10)-40
> RL : bitsToUint (raw, 20, 10)-40*


These look correct. Are you sure the drive inverter is on? Most DI signals stop broadcasting when the DI is offline, but brake temps continue to broadcast, but with nonesense values. (I get 40,-24,-40,-40 when DI is off - all works nicely when on though.) You need to press the brake pedal to "turn on the DI", by the way, if you didn't know that.



> 0x321 1000 8
> CoolantTempBatteryInlet C u10 SB 0 scale 0.125 offset -40
> CoolantTempPowertrainInlet C u10 SB 10 scale 0.125 offset -40
> Ambient Temp Raw C u8 SB 24 scale 0.5 offset -40
> Ambient Temp Filtered C u8 SB 40 scale 0.5 offset -40
> 
> *(bitsToUint (raw, 0, 10)/8)-40*


Not sure why this one doesn't work - I'm getting good data on this signal.



> 0x33A 8
> UI Rated Range Mi u10 SB 0 scale 1
> UI Ideal Range Mi u10 SB 16 scale 1
> Rated WH/Mi u10 SB32 scale 1
> UI SOE SOC % u7 SB 48 scale 1
> UI unfiltered SOE % u7 SB 56 scale 1
> 
> *bitsToUint (raw, 48, 7)*


I'm not sure what message is on 0x33A (I don't have it.) For SOC, I'd use 668 (BMS_socStatus) on signal BMS_socUI (10|10 0.1).


----------



## marcus_54

Nothing works except the position of the accelerator pedal
PID 280 or 0x118 bitsToUint (raw, 32, 8) / 2.5
All other codes give false values


----------



## codingoverdrive

If you post the specific frame data and the ID you are having an issue, then it might be easier to help you.

eg

DBC
-----
BO_ 658 ID292BMS_SOC: 8 VehicleBus
SG_ BattBeginningOfLifeEnergy292 : 40|[email protected]+ (0.1,0) [0|102.3] "kWh" Receiver
SG_ SOCmax292 : 20|[email protected]+ (0.1,0) [0|102.3] "%" Receiver
SG_ SOCave292 : 30|[email protected]+ (0.1,0) [0|102.3] "%" Receiver
SG_ SOCUI292 : 10|[email protected]+ (0.1,0) [0|102.3] "%" Receiver
SG_ SOCmin292 : 0|[email protected]+ (0.1,0) [0|102.3] "%" Receiver
SG_ BMS_battTempPct : 50|[email protected]+ (0.4,0) [0|100] "%" Receiver

Sample Data
-----------------
MID: 0x292 Data: 0x11 0x03 0x7C 0x71 0xC5 0x0A 0x03 0x00


----------



## JWardell

Excel is terrible especially when dealing with hex and non-8 bit data. Can you use something else to do the decoding?


----------



## marcus_54

My car's SOC is 17%

ID 0x292
bitsToUint (raw, 0, 10) * 0.1 = 91% 
bitsToUint (raw, 10, 10) * 0.1 = 52% 

ID0x333
bitsToUint (raw, 10, 10) * 0.1 = 27% 

ID 0x29C (668)
bitsToUint (raw, 10, 10) * 0.1 = nothing 



JWardell said:


> Excel is terrible especially when dealing with hex and non-8 bit data. Can you use something else to do the decoding?


What do you suggest me?

thank you


----------



## iChris93

marcus_54 said:


> My car's SOC is 17%
> 
> ID 0x292
> bitsToUint (raw, 0, 10) * 0.1 = 91%
> bitsToUint (raw, 10, 10) * 0.1 = 52%
> 
> ID0x333
> bitsToUint (raw, 10, 10) * 0.1 = 27%
> 
> ID 0x29C (668)
> bitsToUint (raw, 10, 10) * 0.1 = nothing
> 
> What do you suggest me?
> 
> thank you


Try ID 0x352.



kornerz said:


> 0x352 has been updated in 2020.20.x, and now values are 11-bit each, starting at 0, 11, 22, 33, 44 and 55 (for 8-bit Buffer value) respectively)


----------



## marcus_54

ID 0x352.
bitsToUint (raw, 0, 11) * 0.1 = 179 % 
bitsToUint (raw, 11, 11) * 0.1 = 70 %


----------



## iChris93

marcus_54 said:


> ID 0x352.
> bitsToUint (raw, 0, 11) * 0.1 = 179 %
> bitsToUint (raw, 11, 11) * 0.1 = 70 %


Send the raw bits.


----------



## kornerz

marcus_54 said:


> ID 0x352.
> bitsToUint (raw, 0, 11) * 0.1 = 179 %
> bitsToUint (raw, 11, 11) * 0.1 = 70 %


0x352 contains kWh capacities, not percentages.
The issue also might be in signal endianness.

For example, the message "EB 39 C6 31 8E 51 0D 0B" shall be decoded to the following:
BMS_nominalFullPackEnergy: 49.1 KWh,
BMS_nominalEnergyRemaining: 19.9 KWh,
BMS_expectedEnergyRemaining: 19.9 KWh,
BMS_idealEnergyRemaining: 19.9 KWh,
BMS_energyToChargeComplete: 21.3 KWh,
BMS_energyBuffer: 2.2 KWh


----------



## iChris93

kornerz said:


> 0x352 contains kWh capacities, not percentages.


Oops, yes. Should have mentioned that.


----------



## JWardell

marcus_54 said:


> My car's SOC is 17%
> 
> ID 0x292
> bitsToUint (raw, 0, 10) * 0.1 = 91%
> bitsToUint (raw, 10, 10) * 0.1 = 52%
> 
> ID0x333
> bitsToUint (raw, 10, 10) * 0.1 = 27%
> 
> ID 0x29C (668)
> bitsToUint (raw, 10, 10) * 0.1 = nothing
> 
> What do you suggest me?
> 
> thank you


If you want State of Charge, that's in 0x33A:

BO_ 826 ID33AUI_rangeSOC: 8 VehicleBus
SG_ UI_idealRange : 16|[email protected]+ (1,0) [0|1023] "mi" Receiver
SG_ UI_Range : 0|[email protected]+ (1,0) [0|1023] "mi" Receiver
SG_ UI_SOC : 48|[email protected]+ (1,0) [0|127] "%" Receiver
SG_ UI_uSOE : 56|[email protected]+ (1,0) [0|127] "%" Receiver
SG_ UI_ratedWHpM : 32|[email protected]+ (1,0) [0|1023] "WHpM" Receiver


----------



## marcus_54

ID 0x33A
my SOC is 47
bits number 48
lenght 7 bits
bitsToUint (raw, 48, 7) = 23 
if i do 48+1
bitsToUint (raw, 49, 7) = 47 

hazərd ?


----------



## kornerz

marcus_54 said:


> ID 0x33A
> my SOC is 47
> bits number 48
> lenght 7 bits
> bitsToUint (raw, 48, 7) = 23
> if i do 48+1
> bitsToUint (raw, 49, 7) = 47
> 
> hazərd ?


You can try to get the data manually.
- Get the raw 64-bit value.
- Enter it into Windows Calculator in "programmer" mode in HEX.
- switch to bits tab:


http://imgur.com/r7uwlNh

- manually pick the 7 bits you need
- convert them to the number you need by switching calculator to binary mode and then to decimal
- Check if the you've received expected value.


----------



## Onyx

Does anyone know what's up with 789 (DI_temperature) with 2020.24.x? It's cycling between valid looking temperatures and garbage data. It used to be 100% reliable, and now I can't tell what it's doing.


----------



## codingoverdrive

Don't know if this is interesting, but it's how I'm developing my Tesla display project without access to a car (yet).


----------



## marcus_54

Pedal Position OK
bitsToUint (raw, 32, 8) / 2.5

UI SOE SOC % OK
bitsToUint (raw, 49, 7)

Battery Voltage V u16 SB 0 scale 0.01 NOK
bitsToInt (raw, 1, 16) *0.01 = 440V and move

I just thought I have an oscilloscope which decodes the CAN bus


----------



## Onyx

Onyx said:


> Does anyone know what's up with 789 (DI_temperature) with 2020.24.x? It's cycling between valid looking temperatures and garbage data. It used to be 100% reliable, and now I can't tell what it's doing.


Okay, so the issue is that I'm reading from both the chassis and vehicle buses now, and it turns out that the chassis bus is carrying a 789 message that isn't DI_temperature but some other unknown set of signals. I guess the lesson here is that the DBC is not all inclusive, and you must filter messages by source bus before attempting to decode. I had naively thought that message ids would be unique over the entire car.

Please correct me if any of this is incorrect.


----------



## iChris93

Onyx said:


> Okay, so the issue is that I'm reading from both the chassis and vehicle buses now, and it turns out that the chassis bus is carrying a 789 message that isn't DI_temperature but some other unknown set of signals. I guess the lesson here is that the DBC is not all inclusive, and you must filter messages by source bus before attempting to decode. I had naively thought that message ids would be unique over the entire car.
> 
> Please correct me if any of this is incorrect.


You're right here. The message ID that is for the blind spot monitoring on the chassis bus recently started appearing on the vehicle bus but was carrying a different signal.


----------



## codingoverdrive

Just wondering if anyone else think it could be useful for @JWardell to (git) tag commits on the https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc file with the firmware version that the DBC file relates to.

Otherwise it's difficult to know if the DBC file and CAN signals from a Model 3/Y are in sync based on the car's firmware version.

This could be useful for anyone with older cars that stumble across the repo but can't figure out why their signals differ.

Just my 2c


----------



## JWardell

Onyx said:


> Okay, so the issue is that I'm reading from both the chassis and vehicle buses now, and it turns out that the chassis bus is carrying a 789 message that isn't DI_temperature but some other unknown set of signals. I guess the lesson here is that the DBC is not all inclusive, and you must filter messages by source bus before attempting to decode. I had naively thought that message ids would be unique over the entire car.
> 
> Please correct me if any of this is incorrect.


I realize I am seeing this a lot too often, as I have switched to dual bus logs. I don't think any of the free utilities pay attention to the bus number in the logged data and differentiate them. @Collin80 @amund7

Easier to split the logs or save to separate logs



madmaxim said:


> Just wondering if anyone else think it could be useful for @JWardell to (git) tag commits on the https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc file with the firmware version that the DBC file relates to.
> 
> Otherwise it's difficult to know if the DBC file and CAN signals from a Model 3/Y are in sync based on the car's firmware version.
> 
> This could be useful for anyone with older cars that stumble across the repo but can't figure out why their signals differ.
> 
> Just my 2c


I almost always put the firmware version the update is for in the check-in notes


----------



## codingoverdrive

JWardell said:


> I almost always put the firmware version the update is for in the check-in notes


I checked the latest commit, https://github.com/joshwardell/model3dbc/commit/c61be330c24e252ec5e422d050394a1345f5e181 and wasn't able to see any firmware information.

Can you let me know which notes you're referring to?

Thanks


----------



## JWardell

madmaxim said:


> I checked the latest commit, https://github.com/joshwardell/model3dbc/commit/c61be330c24e252ec5e422d050394a1345f5e181 and wasn't able to see any firmware information.
> 
> Can you let me know which notes you're referring to?
> 
> Thanks


The last commit was a quick update to add a few things to the previous (and recent) commit, which does state 20.24. 
I similarly commented in the commit before that too.

In general the DBC is kept as up to date as I can, but I leave in as much as possible for abandoned signals. It shouldn't be anything to worry or think about to anyone who is using it with their current car at any time. It's only an issue if you're analyzing old logs from far in the past...in which case, grab the version nearest that date.
A LOT of work goes into comparing and verifying signals, from numerous sources none of which are accurate. I do the best I can.


----------



## Onyx

JWardell said:


> I realize I am seeing this a lot too often, as I have switched to dual bus logs. I don't think any of the free utilities pay attention to the bus number in the logged data and differentiate them. @Collin80 @amund7


I've updated my firmware (https://github.com/onyx-m2/onyx-m2-firmware) to track buses independently. The server component that interfaces with the device now reads the bus from the DBC file and reacts appropriately. The rest of my software is ignorant of this, which is nice. All messages seem to work well now and have stable values.


----------



## iChris93

Onyx said:


> The server component that interfaces with the device now reads the bus from the DBC file and reacts appropriately.


This approach might not always work. 


JWardell said:


> The DBC labels everthing as vehicle unless it only appears on chassis [on the day I add the signal].


----------



## codingoverdrive

JWardell said:


> The last commit was a quick update to add a few things to the previous (and recent) commit, which does state 20.24.
> I similarly commented in the commit before that too.


Thanks @JWardell - I missed the firmware information from the previous commit messages. Apologies that was my mistake.



JWardell said:


> In general the DBC is kept as up to date as I can, but I leave in as much as possible for abandoned signals. It shouldn't be anything to worry or think about to anyone who is using it with their current car at any time. It's only an issue if you're analyzing old logs from far in the past...in which case, grab the version nearest that date.
> A LOT of work goes into comparing and verifying signals, from numerous sources none of which are accurate. I do the best I can.


I think we all really appreciate the effort that you make with the DBC files. Without the information you've gathered and shared, I doubt that I would even have embarked on my project. So I and I'm sure others are really grateful for your sterling work.

Many thanks


----------



## codingoverdrive

JWardell said:


> It's only an issue if you're analyzing old logs from far in the past...in which case, grab the version nearest that date.
> A LOT of work goes into comparing and verifying signals, from numerous sources none of which are accurate. I do the best I can.


For anyone in this situation... tagging commits with the firmware version would help a lot, I think.

It would allow you to pull down two different tagged versions of the DBC file and use a tool like diff to see what changed.

I think you were tagging versions in the past, https://github.com/joshwardell/model3dbc/tags but I'm not sure what the tags 100, 110 and 111 mean.

If you are able to tag future commits with the firmware version, it would make it simpler to process a historical file or to compare one version to another without trawling through the commit history.

This is only a suggestion, but since you are creating an amazing "source of truth" - I'm sure future visitors to your repo would find it useful.


----------



## Onyx

Do we know how reliable APP_environment (603) is? It showing APP_environmentRainy=1 right now, and the sky couldn't be bluer. Just curious how/if this message works.


----------



## Onyx

iChris93 said:


> This approach might not always work.


Thanks for the tip. I'm actually writing a tool to validate everything I can in the dbc, so it should be easy to spot incorrect bus assignments and dead messages. I'll let everyone know if I find any discrepancies with JWardell's dbc file.


----------



## gleb

Hi
Is there information whether DC charging is enabled accessible through CAN?


----------



## kornerz

gleb said:


> Hi
> Is there information whether DC charging is enabled accessible through CAN?


"is DC charging session currently active" - yes, in ID29DCP_dcChargeStatus 
"Has Tesla blocked my salvaged + restored car from DC charging and superchargers" - I doubt it.


----------



## Onyx

Onyx said:


> Thanks for the tip. I'm actually writing a tool to validate everything I can in the dbc, so it should be easy to spot incorrect bus assignments and dead messages. I'll let everyone know if I find any discrepancies with JWardell's dbc file.


Alright, tool written, data obtained - and you were correct @iChris93, there were many errors in the bus info. I'm happy to say that now almost everything works with my filtering by bus.

Here is a spreadsheet of a snapshot I took of the latest values on all messages that were emitted during a ~40m drive today that shows the errors (they are the lines in red, bus 0 = VEH, and bus 1 = CH). 
This also confirmed that there are quite a few messages that use the same id on each bus and that are obviously not carrying the same data. Some are easy to spot because they are different lengths, some harder to be sure whether they are the same one. There are also a ton of messages we don't have on our dbc.

I use my own dbc, that favours the Tesla nomenclature but obviously uses a lot of the info @JWardell publishes in his. You can find the change set for the buses in https://github.com/onyx-m2/onyx-m2-server/commit/fa13e529ea8bb5661400a2fc7485d5b88d2b2163.

I hope this is useful to others.


----------



## codingoverdrive

If you are using a unix platform and are looking for a tool to replay can bus messages from a *.asc (Vector format) log file, then you might find this project useful

https://github.com/codingoverdrive/vehicle-canbus-simulator

It replicates the functionality of can-utils/canplayer but unlike that project works with Vector's .ASC files

Note that it doesn't actually do any decoding. It transmits what's in the log file honouring the timestamp information.


----------



## JWardell

OOoh, I missed lots of great posts!



madmaxim said:


> For anyone in this situation... tagging commits with the firmware version would help a lot, I think.
> 
> It would allow you to pull down two different tagged versions of the DBC file and use a tool like diff to see what changed.
> 
> I think you were tagging versions in the past, https://github.com/joshwardell/model3dbc/tags but I'm not sure what the tags 100, 110 and 111 mean.
> 
> If you are able to tag future commits with the firmware version, it would make it simpler to process a historical file or to compare one version to another without trawling through the commit history.
> 
> This is only a suggestion, but since you are creating an amazing "source of truth" - I'm sure future visitors to your repo would find it useful.


I don't really know what I'm doing with github, and I think I was incorrectly trained years back that tags in SVN were separate code forks or something. It a github tag more like a label in the traditional sense of the word tag? Can I go back and add tags to past commits?
Furthermore I only published a release once in a while when I thought the DBC was "solid" but now it seems it needs to change every month. I should do another I guess.



Onyx said:


> Do we know how reliable APP_environment (603) is? It showing APP_environmentRainy=1 right now, and the sky couldn't be bluer. Just curious how/if this message works.


In general, I find a lot of the AutoPilot and DAS messages don't do what you expect, or sometimes do nothing. Never know if they are left from older software. Always must test, log, and verify.



gleb said:


> Hi
> Is there information whether DC charging is enabled accessible through CAN?





kornerz said:


> "is DC charging session currently active" - yes, in ID29DCP_dcChargeStatus
> "Has Tesla blocked my salvaged + restored car from DC charging and superchargers" - I doubt it.


DC charge status, CP status, etc are only useful while actively plugged into a charger.
Always look at message 0x7FF for how a car is configured.
I couldn't tell without testing, but most likely you need to look at GTW_superchargingAccess
When talking to Rich, he said no Model 3s have been blocked, only salvaged S&X



Onyx said:


> Alright, tool written, data obtained - and you were correct @iChris93, there were many errors in the bus info. I'm happy to say that now almost everything works with my filtering by bus.
> 
> Here is a spreadsheet of a snapshot I took of the latest values on all messages that were emitted during a ~40m drive today that shows the errors (they are the lines in red, bus 0 = VEH, and bus 1 = CH).
> This also confirmed that there are quite a few messages that use the same id on each bus and that are obviously not carrying the same data. Some are easy to spot because they are different lengths, some harder to be sure whether they are the same one. There are also a ton of messages we don't have on our dbc.
> 
> I use my own dbc, that favours the Tesla nomenclature but obviously uses a lot of the info @JWardell publishes in his. You can find the change set for the buses in https://github.com/onyx-m2/onyx-m2-server/commit/fa13e529ea8bb5661400a2fc7485d5b88d2b2163.
> 
> I hope this is useful to others.


Very cool, I will have to look through all that. I am long overdue for analyzing and documenting what signals of interest are on which bus, so folks can choose which Server to buy. Then Tesla goes and switches them up with a firmware update anyway. It's necessitating me to add dual bus capabiliies. Coming in the next revision!


----------



## codingoverdrive

JWardell said:


> I don't really know what I'm doing with github, and I think I was incorrectly trained years back that tags in SVN were separate code forks or something. It a github tag more like a label in the traditional sense of the word tag? Can I go back and add tags to past commits?
> Furthermore I only published a release once in a while when I thought the DBC was "solid" but now it seems it needs to change every month. I should do another I guess.


Yes, you can tag specific commits after the event. There are two kinds of tags; annotated and lightweight.

Since our focus is on a single DBC file, the use of a lightweight tag would be fine.

More info here: https://git-scm.com/book/en/v2/Git-Basics-Tagging

You basically apply tags to your local git copy, and then push the tags to GitHub using

`git push --tags`

If you make a mistake you can delete a tag from local or remote, and add/remove them easily after the event.

If you are able to do this, I think it could be really helpful. Many thanks


----------



## Eugenius

Hi,

my ESM327 OBD-Dongle died :/
So I started ESP32-CAN development.







It looks on the photo weird, I know, but it works.
I managed to get up to 200 packets per second. But at least 50 per second are always there.








I will test some days, but it looks great and performance is way better then ELM327 dongle.
Then I will share my code on github.
My goal is to logging the data to SD-Card and then synchronize it with TeslaLogger (https://github.com/bassmaster187/TeslaLogger ).
TeslaLogger can already save and display CAN-data, but only via ScnaMyTesla app and (until now) only live-data...


----------



## codingoverdrive

Eugenius said:


> So I started ESP32-CAN development.


What CAN transceiver are you using with the ESP 32?

I'm guess that CAN TX/RX board is directly connect to the two CAN pins of the ESP 32?

Did you also consider or try a CAN TX/RX board with SPI? At least for the second can bus channel if you intend to support two


----------



## Eugenius

madmaxim said:


> What CAN transceiver are you using with the ESP 32?
> 
> I'm guess that CAN TX/RX board is directly connect to the two CAN pins of the ESP 32?
> 
> Did you also consider or try a CAN TX/RX board with SPI? At least for the second can bus channel if you intend to support two


I'm using SN65, e.g. https://www.aliexpress.com/item/32375462280.html (without termination resitors)
RX/TX are connected to GPIO16/17
I have no use case (yet) for second CAN, so I'dint tried SPI ICs yet.
Why you will the second CAN? Which one, chassis? Where can I get adapter/harness for it?


----------



## codingoverdrive

Looks like you're using a board with the SN65HVD23x chipset. This can run at 3.3V which makes it perfect for the ESP32

Sorry, our messages overlapped! 

yes, I would use the 2nd CANBUS channel to enable logging of both Vehicle and Chassis buses


----------



## codingoverdrive

Eugenius said:


> Why you will the second CAN? Which one, chassis? Where can I get adapter/harness for it?


Best to ask @JWardell if he would consider offering a Y-harness for the chassis bus. Otherwise you can create your own with the right MQS plug/socket


----------



## codingoverdrive

What are the power options for a display unit on the dashboard? I'm looking for a "switched" power supply that goes off with the centre console and back on when the console comes back on

1. ODB plug
2. 5V USB in console
3. Other???

I think @JWardell mentioned that there is a CAN msg that indicates that the M3 centre console screen is going to power off. Perfect for shutting down a device.

I need the power to go from off -> on to power the device back up


----------



## JWardell

Eugenius said:


> Hi,
> 
> my ESM327 OBD-Dongle died :/
> So I started ESP32-CAN development.
> View attachment 35055
> 
> It looks on the photo weird, I know, but it works.
> I managed to get up to 200 packets per second. But at least 50 per second are always there.
> View attachment 35056
> 
> 
> I will test some days, but it looks great and performance is way better then ELM327 dongle.
> Then I will share my code on github.
> My goal is to logging the data to SD-Card and then synchronize it with TeslaLogger (https://github.com/bassmaster187/TeslaLogger ).
> TeslaLogger can already save and display CAN-data, but only via ScnaMyTesla app and (until now) only live-data...


If you don't feel like reinventing the wheel, this is what we have already accomplished, with ESP32, and logging to SD card. Also already connects to apps and your home wifi.


----------



## Onyx

So, I've been experimenting with a data logger on my M2 project, and it's working very well - but I'm suspicious. I'm sustaining sampling at 1.8k+ messages per second, which seems very high. Does anyone else have a frame of reference of what rate I should be getting if I'm successfully reading all traffic?

(This is running both VEH and CH buses through my logger, btw. VEH is logging 1070 msg/sec and CH is at 807 msg/sec.)

Some high frequency messages are logging faster than their name would imply. For example, VCFRONT_logging10Hz and VCFRONT_logging10Hz2 are logging every 14ms (median), but shouldn't it be every 100ms based on the name? The most verbose messages are BMS_hvBusStatus, CP_chargeStatus, and SCCM_steeringAngleSensor - each logging every 10ms - does that match the community's experience? 

All and all, I'm pretty pleased with the performance I'm getting. (On the M2 - Google Sheets performance SUCKS on large files!)


----------



## JWardell

Onyx said:


> So, I've been experimenting with a data logger on my M2 project, and it's working very well - but I'm suspicious. I'm sustaining sampling at 1.8k+ messages per second, which seems very high. Does anyone else have a frame of reference of what rate I should be getting if I'm successfully reading all traffic?
> 
> (This is running both VEH and CH buses through my logger, btw. VEH is logging 1070 msg/sec and CH is at 807 msg/sec.)
> 
> Some high frequency messages are logging faster than their name would imply. For example, VCFRONT_logging10Hz and VCFRONT_logging10Hz2 are logging every 14ms (median), but shouldn't it be every 100ms based on the name? The most verbose messages are BMS_hvBusStatus, CP_chargeStatus, and SCCM_steeringAngleSensor - each logging every 10ms - does that match the community's experience?
> 
> All and all, I'm pretty pleased with the performance I'm getting. (On the M2 - Google Sheets performance SUCKS on large files!)


Sounds about right to me. Those names were never right


----------



## JWardell

Onyx said:


> All and all, I'm pretty pleased with the performance I'm getting. (On the M2 - Google Sheets performance SUCKS on large files!)


We have a growing need for better analysis apps (or better yet cloud apps). I think we will have a lot more people pulling a lot more data very soon. CanbusAnalyzer is simple but missing a few features and data support. SavvyCAN super powerful but not easy to quickly look at graphs. The author of Teslogger expressed integration interest but hasn't appeared yet. If anyone has ability to set up fast cloud graphing of log files, we could use it.
We could very easily blow TeslaFi out of the water.


----------



## Eugenius

JWardell said:


> If you don't feel like reinventing the wheel, this is what we have already accomplished, with ESP32, and logging to SD card. Also already connects to apps and your home wifi.


Hi @JWardell ,
I know about your project. It's very cool 
But you focusing on your hardware, I'm on TeslaLogger and ScanMyTesla integration.
For Example you decode some some values, like speed or voltage for your displays. I will need for TeslaLogger other values, more battery relevant, like cell imbalance or cell voltage.
ScanMyTesla working already, maybe it's interesting for you (I will share my code next days).
Some things a very similar in our projects, some different.
...and wanted to know how it works, learning by doing 

ahh... other question: can anybody provide part numbers for chassis bus plug/socket?


----------



## codingoverdrive

JWardell said:


> If you don't feel like reinventing the wheel, this is what we have already accomplished, with ESP32, and logging to SD card. Also already connects to apps and your home wifi.





Eugenius said:


> For Example you decode some some values, like speed or voltage for your displays. I will need for TeslaLogger other values, more battery relevant, like cell imbalance or cell voltage.


I agree that @JWardell's CanServer project is very cool.

What would be great is to have an open source hardware reference platform (like the Panda) that has the following (hardware) features:

1) Dual can bus support
2) On board 12-30V -> 5 and/or 3.3V regulation (without the separate buck)
3) Opto-isolation to enhance protection to the "can sniffer" device
4) SD card support
5) Standardised small (cheap/available) connectors on the board, and source of plugs to make up our own leads
6) SMALL form factor
7) cased

If such a thing existed I would create boards based on it. Since I'm in Europe and don't want the hassle/cost of purchasing from the US. I would be very happy to contribute to the hardware design and testing.

In terms of software, my needs are also different to Josh's.

I want access to all messages transmitted over UDP with the client specifying the messages to receive from the server. The server doesn't need to process the messages beyond interleaving messages from both buses and filtering to avoid sending messages that the client doesn't want to receive.

Again I would be happy to collaborate on the software that meets this requirement.


----------



## Eugenius

madmaxim said:


> 1) Dual can bus support
> 2) On board 12-30V -> 5 and/or 3.3V regulation (without the separate buck)
> 3) Opto-isolation to enhance protection to the "can sniffer" device
> 4) SD card support
> 5) Standardised small (cheap/available) connectors on the board, and source of plugs to make up our own leads
> 6) SMALL form factor
> 7) cased


1) It is necessary only for Chassis bus (the only interesting data for me it GPS position to make fully offline logger, without Tesla API)
2) agree
3) Why? I see no use case for it
4) agree
5) I would make it like comma.ai white panda OBD-II
6) agree
7) agree

All this can comma.ai white panda OBDII... but it is not available in Germany :/

do you have "connections" to assembly company?
To design and produce PCB ist easy and cheap, but assembly is pretty expensive.


----------



## Onyx

Eugenius said:


> ahh... other question: can anybody provide part numbers for chassis bus plug/socket?


I sourced mine from Mouser. I made a pass-through cable, then tapped the CAN+/CAN- signals and sent them to the center console location where I get power and VEH signals.

571-936121-1
936121-1
TE Connectivity Automotive Connectors
US HTS:8538906000 ECCN:EAR99 COO:KR552

571-1-936119-1
1-936119-1
TE Connectivity Automotive Connectors
US HTS:8538906000 ECCN:EAR99 COO:KR553

571-963716-1-CT
963716-1 (Cut Strip)
TE Connectivity Automotive Connectors
US HTS:8538908140 ECCN:EAR99 COO:US1001004

571-928999-1-CT
928999-1 (Cut Strip)
TE Connectivity Automotive Connectors
US HTS:8536698000 ECCN:EAR99 COO:US


----------



## Onyx

madmaxim said:


> What would be great is to have an open source hardware reference platform (like the Panda) that has the following (hardware) features:
> 
> 1) Dual can bus support
> 2) On board 12-30V -> 5 and/or 3.3V regulation (without the separate buck)
> 3) Opto-isolation to enhance protection to the "can sniffer" device
> 4) SD card support
> 5) Standardised small (cheap/available) connectors on the board, and source of plugs to make up our own leads
> 6) SMALL form factor
> 7) cased


The Macchina M2 does all of this out of the box. I've been using these for a couple of years, and they're great. Well, not the connectors, of course. I've been working on firmware for it for the Model 3, which does a lot of what you're talking about (not ready for prime time yet, but you can check out the general idea at https://github.com/onyx-m2/onyx-m2-firmware).


----------



## JWardell

madmaxim said:


> I agree that @JWardell's CanServer project is very cool.
> 
> What would be great is to have an open source hardware reference platform (like the Panda) that has the following (hardware) features:
> 
> 1) Dual can bus support
> 2) On board 12-30V -> 5 and/or 3.3V regulation (without the separate buck)
> 3) Opto-isolation to enhance protection to the "can sniffer" device
> 4) SD card support
> 5) Standardised small (cheap/available) connectors on the board, and source of plugs to make up our own leads
> 6) SMALL form factor
> 7) cased
> 
> If such a thing existed I would create boards based on it. Since I'm in Europe and don't want the hassle/cost of purchasing from the US. I would be very happy to contribute to the hardware design and testing.
> 
> In terms of software, my needs are also different to Josh's.
> 
> I want access to all messages transmitted over UDP with the client specifying the messages to receive from the server. The server doesn't need to process the messages beyond interleaving messages from both buses and filtering to avoid sending messages that the client doesn't want to receive.
> 
> Again I would be happy to collaborate on the software that meets this requirement.


The CANserver basically checks all of those boxes. Especially when the Dual Bus version arrives... 
There should be no need for opto isolators. CAN tranceivers are already very robust, and the high voltage comonents already have isolation. Here you are only plugging into wires from VCleft/right.
Already logs to SD cards, already emulates CommaAI Panda data communications. Solid 9-30v to 5v supply. In a relatively small case. And easily customizable.


----------



## Eugenius

JWardell said:


> The CANserver basically checks all of those boxes. Especially when the Dual Bus version arrives...
> There should be no need for opto isolators. CAN tranceivers are already very robust, and the high voltage comonents already have isolation. Here you are only plugging into wires from VCleft/right.
> Already logs to SD cards, already emulates CommaAI Panda data communications. Solid 9-30v to 5v supply. In a relatively small case. And easily customizable.


Will it be available in Germany?


----------



## codingoverdrive

JWardell said:


> Already logs to SD cards, already emulates CommaAI Panda data communications.


Good to know, but I don't see these features in your CANSERVER repo on GitHub. Is this on another branch?



JWardell said:


> Solid 9-30v to 5v supply. In a relatively small case. And easily customizable.


Have you considered switching from an ESP32 dev board to a smaller discrete ESP32-WROOM device? That would help reduce the size even more.


----------



## JWardell

madmaxim said:


> Good to know, but I don't see these features in your CANSERVER repo on GitHub. Is this on another branch?
> 
> Have you considered switching from an ESP32 dev board to a smaller discrete ESP32-WROOM device? That would help reduce the size even more.


Sure, eventually in the future if volume takes off. But that would have prevented me from ever finishing it to begin with, with a lot more components to layout and solder myself, and I would probably have to sell it for triple.
The new software should be merged in this week.


----------



## Onyx

Some more mildly interesting info on logging to an SD card. Using my binary format, and logging at full resolution (1.8k+ msgs/sec), I'm able to store 1 hour of car usage in a little under 100 MB. The SD card is 32 GB, which is the largest size supported by HSMCI (High Speed MultiMedia Card Interface) on the M2. 

This means I can realistically be logging everything for months without having to empty the card, which is pretty cool. Even an extreme road trip, where you might be driving 10 hours a day, you'd be able to go a month without having to empty the card. If you were camping in the car with camp mode on, you'd probably burn an extra ~60MB/hour of storage space when parked.

I'm pretty happy about this. I'm thinking about eventually implementing a system similar to the dash cam that recycles files unless you save them. I could even make it so the same controls (i.e. honking the horn) saves the current log forever. This still represents extremes amount of data, so I'm not sure that sending to the cloud automatically makes sense from a performance and cost perspective... For now, I'm personally just going to store full captures locally. The cloud will get a curated view of "interesting data".


----------



## codingoverdrive

Onyx said:


> Some more mildly interesting info on logging to an SD card. Using my binary format, and logging at full resolution (1.8k+ msgs/sec), I'm able to store 1 hour of car usage in a little under 100 MB. The SD card is 32 GB, which is the largest size supported by HSMCI (High Speed MultiMedia Card Interface) on the M2.


Are you keeping the messages from each bus separate, or do you identify which bus the message originates from?

Someone mentioned that Tesla might be re-using the same ID in different buses and possibly with different signals depending on the bus it is from


----------



## codingoverdrive

Onyx said:


> The Macchina M2 does all of this out of the box. I've been using these for a couple of years, and they're great. Well, not the connectors, of course. I've been working on firmware for it for the Model 3, which does a lot of what you're talking about (not ready for prime time yet, but you can check out the general idea at https://github.com/onyx-m2/onyx-m2-firmware).


Had a look at the M2 which looks great but is more expensive compared to a custom ESP32 based device with dual CAN which can be created for < $20 pretty simply. Although cost shouldn't really be a factor if you're considering your own or one or two vehicles tbh.

I suspect that I'll end up creating my own CanTransmitter/Logger just for the experience of designing and manufacturing a device. It's not my intention to sell such a device standalone - I'll leave that to @JWardell - he deserves a great deal of recognition and reward for his openness and willingness to share and help others.

I also took a look at the code for the M2 in your repo and am impressed. You certainly seem to covering lots of technical details and things are very clear and well structured.

At the moment I'm investigating using the Arduino Framework vs ESP-IDF on FreeRTOS. I suspect that I will go down the ESP-IDF route because I want to implement true multitasking to get as much performance from the dual processors as possible. Again this is all part of the learning experience. It's 100% likely that my own code would run on Josh's single or dual CANServers.


----------



## Onyx

madmaxim said:


> Are you keeping the messages from each bus separate, or do you identify which bus the message originates from?


Every message is saved with its origin bus, yes, but all messages are saved in the same location in the order they are read from the CAN mailboxes. It look something like this:

TS BUS ID LEN VALUES 
3,114 1 792 8 14 8 39 10 5 19 1D BB
3,142 0 579 8 FC 7F FF 1F 9A 42 2 49
3,142 1 297 8 0 25 0E 20 0 20 FF 3F
3,142 0 832 8 1 0 0 0 2 0 0 0
3,142 1 737 8 10 21 4 4E 60 8A 6 4
3,142 0 306 8 A0 99 F9 FF 4 27 FF 0F
3,142 0 930 8 7 4 0 0 0 0 0 0
3,142 1 552 2 90 BA 
3,142 0 705 8 1 0 0 14 28 0 64 0
3,142 1 297 8 0F 23 0D 20 1 20 FF 3F
3,142 0 1058 6 F2 6 0 2 0 0 

Having the precise timestamp is for each message is also super useful.



madmaxim said:


> Someone mentioned that Tesla might be re-using the same ID in different buses and possibly with different signals depending on the bus it is from


Yes, they most definitely do. This is easy to spot because some have different length (i.e. a given id will be 8 bytes long on VEH and 6 byte long on CH). There are a lot of duplicates too (i.e. same message, same values, at the same time, on both buses).


----------



## Onyx

madmaxim said:


> Had a look at the M2 which looks great but is more expensive compared to a custom ESP32 based device with dual CAN which can be created for < $20 pretty simply. Although cost shouldn't really be a factor if you're considering your own or one or two vehicles tbh.


This is exactly my thinking. I'm doing this for fun, to learn and explore, and have no ambitions whatsoever to make a commercial grade product out of this. This "project car" territory for me - next gen style. So cost and ease of mass producing is not at all a goal here. That said, I've spent way more on the cabling that the electronics.



madmaxim said:


> @JWardell - he deserves a great deal of recognition and reward for his openness and willingness to share and help others.


1000!!! We'd be nowhere without him!



madmaxim said:


> I also took a look at the code for the M2 in your repo and am impressed. You certainly seem to covering lots of technical details and things are very clear and well structured.


Thanks!

Even though this is just a for fun project, I'm still trying to do it right. It's also partly a test bed for me to experiment with different software technologies. For example, the front-end I rewrote in React because I wanted something to test what they call "hooks" on. I implemented a CMS to easily modify the screens, but I did it this way mostly because I needed to know more about headless CMSs for work. And so. (All the software will eventually land in https://github.com/onyx-m2, by the way. Most is there already, I just need to clean up the phone app and release it. And make some kind of video that explains a little better what all this does and how it fits together.)



madmaxim said:


> At the moment I'm investigating using the Arduino Framework vs ESP-IDF on FreeRTOS. I suspect that I will go down the ESP-IDF route because I want to implement true multitasking to get as much performance from the dual processors as possible. Again this is all part of the learning experience. It's 100% likely that my own code would run on Josh's single or dual CANServers.


I've personally developed a love-hate relationship with ESP32. On paper, it's amazing. In practice, I've had much more trouble getting it to behave than the Arduino Due (Atmel SAM3X). It's closer to a very small computer than a micro-controller - very dependent on huge software libraries to do anything, and slow. It cannot sustain high transfer rates on either BLE or Wifi, and it can barely handle TLS (I disabled it, it was just too slow, and made everything lag randomly). It runs crazy hot too - though this might be something I'm doing wrong.


----------



## codingoverdrive

Onyx said:


> I've personally developed a love-hate relationship with ESP32. On paper, it's amazing. In practice, I've had much more trouble getting it to behave than the Arduino Due (Atmel SAM3X). It's closer to a very small computer than a micro-controller - very dependent on huge software libraries to do anything, and slow. It cannot sustain high transfer rates on either BLE or Wifi, and it can barely handle TLS (I disabled it, it was just too slow, and made everything lag randomly). It runs crazy hot too - though this might be something I'm doing wrong.


Interesting. The data transfer over wifi will probably be the first thing I start testing then.


----------



## codingoverdrive

Knocked up my prototype Can transmitter... (I don't want to call it a CanServer to avoid confusion although it should do a similar job)










Need to confirm I'm using the right pins and then hope to make a start on the software.


----------



## garsh

madmaxim said:


> Knocked up my prototype Can transmitter...


Knocked up means something very different in the states.


----------



## JWardell

Onyx said:


> Every message is saved with its origin bus, yes, but all messages are saved in the same location in the order they are read from the CAN mailboxes. It look something like this:
> 
> TS BUS ID LEN VALUES
> 3,114 1 792 8 14 8 39 10 5 19 1D BB
> 3,142 0 579 8 FC 7F FF 1F 9A 42 2 49
> 3,142 1 297 8 0 25 0E 20 0 20 FF 3F
> 3,142 0 832 8 1 0 0 0 2 0 0 0
> 3,142 1 737 8 10 21 4 4E 60 8A 6 4
> 3,142 0 306 8 A0 99 F9 FF 4 27 FF 0F
> 3,142 0 930 8 7 4 0 0 0 0 0 0
> 3,142 1 552 2 90 BA
> 3,142 0 705 8 1 0 0 14 28 0 64 0
> 3,142 1 297 8 0F 23 0D 20 1 20 FF 3F
> 3,142 0 1058 6 F2 6 0 2 0 0
> 
> Having the precise timestamp is for each message is also super useful.
> 
> Yes, they most definitely do. This is easy to spot because some have different length (i.e. a given id will be 8 bytes long on VEH and 6 byte long on CH). There are a lot of duplicates too (i.e. same message, same values, at the same time, on both buses).


Yes...certainly pays dividends for your processor cycles and SD card bandwidth to write one file with as close to a data dump as possible.
Alternately, it is nice to have a standardized format that can be read by existing utilities.
Labeling the busses is important. I will probably need to start expanding my DBC to differentiate signals from both busses (and that might actually need two DBCs) because there are a few messages that are different IDs on different busses, and then there are completely different messages that have matching IDs on both busses. Yet another reason my head spins when I research changes and updates. CANbusAnalyzer has no knowledge of bus numbers so the data seems to alternate randomly in these cases. I really need it to be updated to remain useful, or someone else make a fast efficient data plotting tool.

Because, if we start getting CANservers in a LOT of people's hands, then there will suddenly a LOT of logs available to analyze! Which of course is a great thing.
Sure wish I had an S/X to curate a DBC for as well. (Or better yet someone to help do so)

I have five *more* PCBs arriving this weekend, and I already have updates needed for one of them. The ideas and improvements keep flowing! There's just so much potential for this stuff. Once I got over the hump of doing some slightly polished hardware for myself, and the reward of duplicating it for a few others, the excitement to do more is nonstop.

I think I said this a year ago, and nearly two years ago too....but stay tuned for more!


----------



## codingoverdrive

Short clip of the display unit I'm working on.

Both displays are running from the same CANBUS data transmitter which is sending data over WiFi and what you see is real-time at 40fps. One if configured for the US and the other for EU; both show the same CANBUS data.






There are signals missing that I still want to add, and I have more work to do on the hardware side. Making progress though... so much to learn!


----------



## JWardell

madmaxim said:


> Short clip of the display unit I'm working on.
> 
> Both displays are running from the same CANBUS data transmitter which is sending data over WiFi and what you see is real-time at 40fps. One if configured for the US and the other for EU; both show the same CANBUS data.
> 
> 
> 
> 
> 
> 
> There are signals missing that I still want to add, and I have more work to do on the hardware side. Making progress though... so much to learn!


I commented on your video that someone sent me not knowing it was you 

It looks spectacular!


----------



## codingoverdrive

JWardell said:


> I commented on your video that someone sent me not knowing it was you


LOL

In answer to your video comment, I think what is likely is that the display unit can run with any ESP32 based (or even other chipset) CANBUS data transmitter provided the software on the sending device honours the "data/integration contract" with the display unit.

It's 99% likely that my ESP32 transmitter code will run on your CanServer without any changes which would allow someone to run a CanServer and their own display unit (see below)

One optimisation that the display unit makes is to "tell" the transmitter which message IDs it wants to receive - this massively cuts down on the volume of data between the devices. It also transmits/receives over UDP because the odd lost packet doesn't really matter in the scheme of things. The transmitter is effectively quite dumb as it only filters messages and blindly forwards those messages asked for by the display unit.

My current transmitter is not running on an ESP32 and that is my next task. Quite a lot to learn as I've never programmed one before...



JWardell said:


> It looks spectacular!


Thank you. It's been a labour of love and is closely modelled on the S/X instrument cluster.

In the video you see two units; the one on the left is running on a pi zero W (single core processor) while the one on right is a 64 bit quad core processor.










The display unit is tiny (and thin) but needs an additional board to provide stabilised power and circuitry to dim the display when it's dark. At the moment the brightness is overwhelming in the dark.

The UI is written in GTK3 and is designed/sized for any 800x480 pixel display. The Raspbian OS I'm using needs some customisation and I have further work to lighten it, and overclock the pi zero a little. There are a lot of pre-installed services that I just don't need to have running which will improve the startup time a lot.

One concern I have (among many) is how to handle the fact that Tesla are changing messages and signals with firmware upgrades. I have some ideas of how to manage this but want to make the process completely automatic for users.

Until I complete the software, I could make either application binaries available for anyone that wants to try it out with a CanServer... once I have compatible transmitter software available to run on your CanServer... or to publish the integration contract so people can implement their own.

I don't want to put myself under additional pressure, but I will try and make stuff available when I'm ready and happy with the quality.


----------



## JWardell

So it looks like Tesla has recently made some large changes to harnessing, and I am suspecting they eliminated the under-seat occupancy modules and integrated into VCleft/VCright, which means my simple connection to the chassis bus might be gone. As just discovered by @Ren001 
https://teslaownersonline.com/threa...n-gauges-for-your-dash-q-a.16615/#post-290552

And confirmed someone else already with their north american 2020 3.

I'm trying to investigate as best I can, but if anyone with a car built halfway through 2019 or later can please take a peek under their seat and help determine if hey are missing the module with the yellow connector as highlighted in the canserver install video it would be helpful


----------



## Onyx

JWardell said:


> if anyone with a car built halfway through 2019 or later can please take a peek under their seat and help determine if hey are missing the module with the yellow connector as highlighted in the canserver install video it would be helpful


4/19 here and it's present


----------



## iChris93

JWardell said:


> So it looks like Tesla has recently made some large changes to harnessing, and I am suspecting they eliminated the under-seat occupancy modules and integrated into VCleft/VCright, which means my simple connection to the chassis bus might be gone. As just discovered by @Ren001
> https://teslaownersonline.com/threa...n-gauges-for-your-dash-q-a.16615/#post-290552
> 
> And confirmed someone else already with their north american 2020 3.
> 
> I'm trying to investigate as best I can, but if anyone with a car built halfway through 2019 or later can please take a peek under their seat and help determine if hey are missing the module with the yellow connector as highlighted in the canserver install video it would be helpful


Not present in a Model Y I test drove today.


----------



## codingoverdrive

iChris93 said:


> Not present in a Model Y I test drove today


Was the Tesla salesperson a little surprised to see you crawling around the footwell looking under the seat?


----------



## iChris93

madmaxim said:


> Was the Tesla salesperson a little surprised to see you crawling around the footwell looking under the seat?


Thankfully, touchless and without the salesperson. I even snapped a photo.


----------



## JWardell

iChris93 said:


> Thankfully, touchless and without the salesperson. I even snapped a photo.
> View attachment 35140


Unlike the others your Y has that flat black cable coming out of the rectangle...question is if the other end does go to the box somewhere else, or feed into the harness.


----------



## JWardell

As it turns out, I don't have a module in the same spot under the driver's seat. So I need to better understand where these things are...but needless to say please check under BOTH seats as it may be under the other one


----------



## Gtimart

2020 M3 here, delivered December 2019, and I DO have the box under the passenger seat. I do not have one on the drivers side. LR AWD model if that makes a difference. Edit: NA (Canada) model.


----------



## JWardell

So I now better understand that the OCSP module (occupant classification system-passenger) is reading the seat weight pads and some capacitance sensors, and is used to disable the passenger airbag (and probably to intelligently change its firing strength). It only exists in the passenger seat.
Tesla service diagrams show it in the passenger seat of both the 3 and the Y. Unfortunately, Tesla has not updated those diagrams since 2019 (yes, even for Y).

But I've easily knocked mine off and it's difficult to get it clipped back under there. So there is some chance that it IS there just moved somewhere more secure. 
So if anyone is missing the box from their passenger seat but does see a black cable coming out of the center rectangle that @iChris93 posted here, perhaps you could follow where the other end of that cable goes.


----------



## iChris93

JWardell said:


> So if anyone is missing the box from their passenger seat but does see a black cable coming out of the center rectangle that @iChris93 posted here, perhaps you could follow where the other end of that cable goes.


I wonder if it is just behind the black plastic at the top of my photo.


----------



## Onyx

iChris93 said:


> I wonder if it is just behind the black plastic at the top of my photo.


I think it's extremely unlikely that the OCSP is just gone. Here's my guess on the wire loom mapping (using @iChris93's photo and comparing to under my car seat)










The 3 labeled looms look suspiciously similar. 1 has blue and yellow shielding you can see, 2 comes out of a similar looking cutout, and 3 has the thicker felt tape with the white label - all in the same order and similar spacing.

I think your theory of the OCSP being secured above the plastic lip make the most sense.


----------



## iChris93

Onyx said:


> I think it's extremely unlikely that the OCSP is just gone.


Crisis adverted.


----------



## codingoverdrive

Development setup... when you don't have a Model 3 to hand or want to work disconnected from your M3 or Y










One of the Pi's is sending (pre-recorded) Model 3 CANBUS frames over the two wire network. The other Pi forms the other node in the network and I'm using candump running on it to confirm the messages are being sent/received correctly.










The CANBUS transmitter is working and intercepting (and logging) the messages correctly. My next task is to get it to transmit the CANBUS data over the WiFi to drive the display unit. The Transmitter code is pretty rough at the moment but I actually found setting up the development environment (Visual Studio Code + Platformio) harder than copying sample code and flashing the ESP32!

This stuff looks super daunting when you start out, but it does start to make more sense as you progress.


----------



## Onyx

codingoverdrive said:


> I actually found setting up the development environment (Visual Studio Code + Platformio) harder than copying sample code and flashing the ESP32!


Yeah, setting up vscode for this I found to be pretty finicky too (I'm using the Arduino bindings though), but well worth in the end. It's so much faster to develop, debug, and navigate around your own code as well as all the libraries you'll end up using (probably).


----------



## Onyx

iChris93 said:


> Crisis adverted.


Ah! Yeah, I guess that did come across as pretty arrogant - sorry about that.


----------



## iChris93

Onyx said:


> Ah! Yeah, I guess that did come across as pretty arrogant - sorry about that.


Oh no, I did not mean it that way. Your post was great, clear, and detailed.

If that box was removed and the chassis bus had to be sourced somewhere else, it would have been a headache (crisis) for @JWardell. It's great that it seems to be there still!


----------



## JWardell

iChris93 said:


> Crisis adverted.


Well not quite, I'm hoping more folks can confirm since we had one report that it definitely wasn't there


----------



## mdrobnak

Hi there. I am attempting to recreate some of the data on the bus for use with the Charge Port ECU. It seems some of the data has a checksum counter (Bosch / Siemens called it an alive counter) and a corresponding checksum calculation. For some of it, it's easy enough to fake it by looking for patterns (like 0x221) because it doesn't change much, but for others like 0x545 on the HV ECU side, the data moves a bit too much for me to figure it out.
Also knowing that it's not necessarily a simple addition of bytes (or perhaps it _is_ - just _which_ bytes), I figured I'd ask here if anyone has some specifications on how to compute the checksum.

Thanks for any help.

-Matt


----------



## JWardell

mdrobnak said:


> Hi there. I am attempting to recreate some of the data on the bus for use with the Charge Port ECU. It seems some of the data has a checksum counter (Bosch / Siemens called it an alive counter) and a corresponding checksum calculation. For some of it, it's easy enough to fake it by looking for patterns (like 0x221) because it doesn't change much, but for others like 0x545 on the HV ECU side, the data moves a bit too much for me to figure it out.
> Also knowing that it's not necessarily a simple addition of bytes (or perhaps it _is_ - just _which_ bytes), I figured I'd ask here if anyone has some specifications on how to compute the checksum.
> 
> Thanks for any help.
> 
> -Matt


We figured it out in here somewhere buried in this thread a while ago. It is just sum of bytes plus another byte if I remember correctly. Not sure if it is the same for all messages. Does anyone remember?
Of course especially with 2020.32 now detecting CAN hacks and disabling the car, there's a good chance Tesla will be changing things more significantly. I knew those Boost upgrades going public and being sold would just result in more work for us.


----------



## bwilson4web

JWardell said:


> Of course especially with 2020.32 now detecting CAN hacks and disabling the car, there's a good chance Tesla will be changing things more significantly.


Are there more technical details?

Bob Wilson


----------



## Onyx

JWardell said:


> We figured it out in here somewhere buried in this thread a while ago. It is just sum of bytes plus another byte if I remember correctly. Not sure if it is the same for all messages. Does anyone remember?


I've recently tested using my data logs, and all the messages I've checked used the same checksum: sum all bytes in the message and low and high bytes of the message id and clamp to 0xFF.

So basically: ((id << 8) + (id & 0xff) + sum(values)) % 0xff

(This is for messages on the vehicle and chassis bus.)


----------



## Onyx

bwilson4web said:


> Are there more technical details?


It was (in my opinion) extremely naive to think you'd be able to spoof motor power limits and not have have it show in any of the derivative data. There is so much data, on many busses, you'd have to fudge to make it impossible to detect. For example, you'd have to hijack the RCM (seatbelt module) and change the longitudinal values from the accelerometer, which can easily confirm you're accelerating faster than your spec says you should. And obviously, spoofing this would be disastrous for your safety. This is one example, there probably hundreds of such messages flying around that would out you.



JWardell said:


> I knew those Boost upgrades going public and being sold would just result in more work for us.


Yeah, this is gonna suck. I also wonder if Tesla now have to test their changes against this device to make sure a change in message format/mappings doesn't make these cars smash into walls, as they can't actually disable the devices directly. Either way, this thing sucks for everyone.

Edit: I suppose the company making these things could turn themselves off on a change of version, until they confirm the new version works, and push an update that re-enables them. This would be the responsible thing to do. (They may already do this, I don't know.)


----------



## iChris93

Onyx said:


> I suppose the company making these things could turn themselves off on a change of version, until they confirm the new version works, and push an update that re-enables them. This would be the responsible thing to do. (They may already do this, I don't know.)


I don't think they are currently doing this since the car is detecting the modification.


----------



## bwilson4web

Onyx said:


> ... spoof motor power limits ...


So this is just a problem for those who are trying write data via the canBUS and/or other modifications to the car. This is way beyond where I'm headed in my read-only, investigations.

BTW, it looks like the 19" performance, aero covers may work on our 7-spoke rims. I've ordered a salvage hubcap and will see what might work.

Bob Wilson


----------



## garsh

bwilson4web said:


> So this is just a problem for those who are trying write data via the canBUS and/or other modifications to the car.


If Tesla changes up the messages, then it will also become a problem for those just trying to read as well.


----------



## codingoverdrive

Finally got my ESP32 "driving" my display unit by sending CAN messages over wifi. It works but it's a bit jerky.

Because I'm using the ESP-IDF framework I was unable to use Collin Kidder's Arduino library and had to switch to a fork of Thomas Barthe's CAN library, https://github.com/ESP32DE/ESP32-CAN-Driver.

As my code currently stands, one thing I'm finding is that there is almost no way I can get the ESP32 to transmit all messages received on the canbus in real-time without using message filters - this is because the volume of work the ESP32 needs to do seems to cause it to struggle.

I can see optimisation opportunities in my code (removal of one task and one event queue) but before I start down that road, I wondered if anyone else 
has any idea of how many messages per sec the ESP32 should be able to process from the (onboard) CANBUS and transmit over BLE/Wifi or write to the SDCard?


----------



## JWardell

codingoverdrive said:


> Finally got my ESP32 "driving" my display unit by sending CAN messages over wifi. It works but it's a bit jerky.
> 
> Because I'm using the ESP-IDF framework I was unable to use Collin Kidder's Arduino library and had to switch to a fork of Thomas Barthe's CAN library, https://github.com/ESP32DE/ESP32-CAN-Driver.
> 
> As my code currently stands, one thing I'm finding is that there is almost no way I can get the ESP32 to transmit all messages received on the canbus in real-time without using message filters - this is because the volume of work the ESP32 needs to do seems to cause it to struggle.
> 
> I can see optimisation opportunities in my code (removal of one task and one event queue) but before I start down that road, I wondered if anyone else
> has any idea of how many messages per sec the ESP32 should be able to process from the (onboard) CANBUS and transmit over BLE/Wifi or write to the SDCard?


I'm pretty sure @pyjamasam has investigated each of these...


----------



## codingoverdrive

I read through @pyjamasam's messages but wasn't able to find any specific performance information on the ESP32.

@JWardell I see that your CanServer has an SD card holder. Have you tried logging all messages on the bus to the SD Card? And if so, do you see any dropped messages?


----------



## kornerz

codingoverdrive said:


> I wondered if anyone else
> has any idea of how many messages per sec the ESP32 should be able to process from the (onboard) CANBUS and transmit over BLE/Wifi or write to the SDCard?


Wi-Fi has sufficient throughput in bytes per second, but is absolutely horrible if you need high packet count per second, and busy Tesla CAN bus is exactly that - a source of thousands small packets each second.

So it should work if "realtime transmission over wi-fi" requirement is slightly relaxed and some buffering is used before sending data over Wi-Fi. For example, accumulating CAN messages over 0.1sec and sending all of them in a single message over Wi-Fi.


----------



## codingoverdrive

kornerz said:


> Wi-Fi has sufficient throughput in bytes per second, but is absolutely horrible if you need high packet count per second, and busy Tesla CAN bus is exactly that - a source of thousands small packets each second.
> 
> So it should work if "realtime transmission over wi-fi" requirement is slightly relaxed and some buffering is used before sending data over Wi-Fi. For example, accumulating CAN messages over 0.1sec and sending all of them in a single message over Wi-Fi.


That's a great suggestion, thank you.

I'll give that a try and experiment with different buffer sizes vs delays in getting the data to the receiving device.


----------



## JWardell

codingoverdrive said:


> I read through @pyjamasam's messages but wasn't able to find any specific performance information on the ESP32.
> 
> @JWardell I see that your CanServer has an SD card holder. Have you tried logging all messages on the bus to the SD Card? And if so, do you see any dropped messages?


No here, but he performed a number of tests to see how the canserver can handle high data rates from two 500k busses. His conclusion was to make it even more efficient.
I haven't had trouble logging to SD card nor transmitting to TesLax, but I think we will have even better performance soon.


----------



## mdrobnak

Onyx said:


> I've recently tested using my data logs, and all the messages I've checked used the same checksum: sum all bytes in the message and low and high bytes of the message id and clamp to 0xFF.
> 
> So basically: ((id << 8) + (id & 0xff) + sum(values)) % 0xff
> 
> (This is for messages on the vehicle and chassis bus.)


Ah, the id << 8...Totally didn't think of that part. I'll give this a shot.

In other (related) news - there were definite changes to the Charge Port ECU data at some point - I've got a controller off Ebay that _does not_ react the same way as the one in my car.

I can replay a log and have the port go into the Blue LED state for a scheduled charge, for instance, but the Ebay ecu just sits with the Red LED.

Anyone have any Charge Port logs they are willing to share? Full disclosure: in the short term I'm probably going to keep this to myself / sell it. I'll definitely help people with whatever I know, but I'm not implementing code for them.  In the long term I'll release the code as open source.

-Matt


----------



## Eugenius

Onyx said:


> ((id << 8) + (id & 0xff) + sum(values)) % 0xff


Du you or somebody else have an (arduino) example for it?


----------



## Onyx

Eugenius said:


> Du you or somebody else have an (arduino) example for it?


I don't, I didn't write code for this, I just proved it using a speadsheet. It should be trivial though - is something specific tripping you up?


----------



## Eugenius

Onyx said:


> I don't, I didn't write code for this, I just proved it using a speadsheet. It should be trivial though - is something specific tripping you up?


If I understand correctly, I have to compare result of ((id << 8) + (id & 0xff) + sum(values)) % 0xff with CRC byte? But which one is CRC?
I'm using the lib from collin80: https://github.com/collin80/can_common/blob/master/src/can_common.cpp#L3-L13 
id an data is clear for me but how can I get if CRC is OK or not.

If I'm testing with this sketch: https://github.com/collin80/esp32_c...TestESP32_BuiltIn/CANTestESP32_BuiltIn.ino#L3 
i get something like that:
132 S 86F 84 F6 FF FD 26 FF F
132 is ID, 
S is not relevant
8 is data length
6F 84 F6 FF FD 26 FF 0F is data.

(id << 8) => 0x13200
(id & 0xff) => 0x32
sum(values) = 6F + 84 + F6 + FF + FD + 26 + FF + 0F = 0x512

(0x13200 + 0x32 + 0x512) % 0xFF = 0x13744 % 0xFF = 0x7C

What is 0x7C?


----------



## Onyx

Eugenius said:


> 6F 84 F6 FF FD 26 FF 0F is data.
> 
> (id << 8) => 0x13200
> (id & 0xff) => 0x32
> sum(values) = 6F + 84 + F6 + FF + FD + 26 + FF + 0F = 0x512
> 
> (0x13200 + 0x32 + 0x512) % 0xFF = 0x13744 % 0xFF = 0x7C
> 
> What is 0x7C?


Ah, I see, yes sorry - I derped with my equation. What you're trying to do is sum up the bytes of data, with the id split between its 2 bytes. Also, don't sum the checksum (in your case, I'm presuming the last byte? But this could vary based on the specific message, at least in theory).

So, for your example, it would be:

0x01 (high byte of id) + 0x32 (low byte of id) + 6F + 84 + F6 + FF + FD + 26 + FF (data excluding checksum) = 0x53D % 0xFF = 0x42

And this is not equal to your presumed checksum byte (0x0F), so something is off. Are you sure about the signals in your message?


----------



## Eugenius

Some other examples (Dumps from Vehicle Bus)
132 S 8 48 8B F8 FF FF 26 FF 0F => (01 + 32 + 48 8B F8 FF FF 26 FF ) % FF = 26 but not 0F
129 S 8 B9 2E A9 1F FF 1F FF 3F => (01 + 32 + B9 2E A9 1F FF 1F FF) % FF = 3FF % FF = 0x3 but not 3F...
334 S 8 1F 3F FF C8 00 00 A0 FC => (03 + 34 + 1F 3F FF C8 00 00 A0) % FF = 3F8 % FF = FB but not FC...

I'm sure about data, but not about CRC algorithm :/

if check ID132 definition: https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L3235
in my example:
01 32 - 48 8B - F8 FF - FF 26 - FF 0F
bytes 0&1 (16bit) BattVoltage132 => 48 8B
bytes 2&3 (16bit) SmoothBattCurrent132 => F8 FF
bytes 4&5 (16bit) RawBattCurrent132 => FF 26
bytes 6&7 (12bit) ChargeHoursRemaining132 => FF 0F & 0xFFF0 (first 12 bits, right?)
In this case we can't use F0 as CRC... only last 4 bits may be... => b1111


----------



## Onyx

Eugenius said:


> if check ID132 definition: https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L3235


This message doesn't use a checksum. If you want to look at the simplest one that does, look at the AP watchdog messages on the chassis bus. For example, with APB_status, you see that the checksum and counter are part of the message. Or look at UTC_systemTime on the vehicle bus. I've manually checked both of these and they work as I've described.

I'm sorry, when you said "message 132", I thought you meant something you were getting from a different bus in the charge port.

Just in case, if you are thinking of the CAN protocol checksum, that's handled in hardware (or in the lower level CAN libs), and you don't need to worry about it.


----------



## Onyx

Has anyone looked at 2020.32.x yet? Are there many message/signal changes? I'm hesitant to upgrade...


----------



## JWardell

I just got it, haven't logged or noticed changes yet


----------



## kornerz

Onyx said:


> Has anyone looked at 2020.32.x yet? Are there many message/signal changes? I'm hesitant to upgrade...


No changes in the signals I use in 2020.32.3


----------



## mdrobnak

I also had a slightly different way of calculating things... (also maybe typo? or comprehension test?) 
You said:
(id << 8)
which to me should actually be:
(id >> 8) - Right shift to get the upper part of the id.

and you're modulus against 0xFF, whereas I've done & 0xFF and that has worked.

In other news, I've made some progress on it so far:

__
http://instagr.am/p/CEjycVpnZ8J/

Two issues:
My eBay CP ECU doesn't react as nicely.  I can get it to go to blue but only for a moment before it turns red again. Seems like a message is no longer being sent, or something else changed. Note that its angry even with a playback of all IDs (except the CP ones themselves) so it's not a bad data generation thing. It's a missing data thing.
Power on is hairy. Need to time it right to open the door, then it is OK. I've noted this may be related to one of the messages I'm sending may be saying the doors are locked. I'm not 100% certain. A lot of the CP / HV bus unique stuff seems to be yet-to-be-decoded.

I've figured out how to make the UMC turn power on, but filming that is not a good idea without stable probes.. It also seems to have a safety cutoff.

I appreciate that while there's a lot of multiplexed data, at least most of it so far seems to be 16 bit boundaries. Darn kids and their 32 bit or 64 bit CPUs :-D 0x12A and 0x14A seem to be voltages or temperatures? What initially looked like a gibberish data stream actually had quite a bit of pattern to it when slowed way down. 

-Matt


----------



## Onyx

mdrobnak said:


> I also had a slightly different way of calculating things... (also maybe typo? or comprehension test?)
> You said:
> (id << 8)
> which to me should actually be:
> (id >> 8) - Right shift to get the upper part of the id.
> 
> and you're modulus against 0xFF, whereas I've done & 0xFF and that has worked.


Yes, I meant shift right of course. I also made a mistake with the mod, I meant to have 256 (which is what I have in my actual calcs - somehow I incorrectly converted that to hex as 0xFF). So I have mod(sum(lo(id), hi(id), data_without_checksum), 256) - which is mathematically the equivalent to your bitand(0xFF) because this is unsigned data.

This is a long winded way to say we came to the same conclusion on the algorithm, but I can't type my equations out without making multiple mistakes.


----------



## michi84

Onyx said:


> Has anyone looked at 2020.32.x yet? Are there many message/signal changes? I'm hesitant to upgrade...


Only thing i noticed is BO_ 946 ID3B2BMS_log2: The multiplexer now runs up to 30 or 31, some values appear to have changed (capacity imbalance now alsways zero, some other values seem different, CAC values however are unchanged).

Everything else i use looks normal. I have to compare logs however to make sure, but my car is in the body shop for a warranty repair until friday. Driving a Model S P85+ loaner at the moment.


----------



## JWardell

I'm very sad to report that Jack Rickard of EVTV passed this week. 
He was battling lung cancer, but still making longwinded Tesla videos to the end.
I'm told Collin and Richard will continue the business.

Here's a quick local article:
https://www.semissourian.com/story/2831878.html

Here's his last video, the first minute ironic in hindsight.


----------



## abraha2d

codingoverdrive said:


> Short clip of the display unit I'm working on.
> 
> Both displays are running from the same CANBUS data transmitter which is sending data over WiFi and what you see is real-time at 40fps. One if configured for the US and the other for EU; both show the same CANBUS data.
> 
> 
> 
> 
> 
> 
> There are signals missing that I still want to add, and I have more work to do on the hardware side. Making progress though... so much to learn!


Fun stuff. I'm also getting started on making my own instrument cluster to put behind the wheel. Spent the last few days reading through this thread, so much good information to soak up. A big thank you to everyone contributing to this effort, and @JWardell for spearheading it.

Anyways, I figured I'd share some mockups I put together for my display. (heavily) inspired by the model S cluster.

Park. Headlights and fog lights on, all doors open. Power/regen gauge totally not ripped off a low-res screenshot of the model S cluster .








Drive. Headlights and fog lights on, and brake being pressed. Blue route line is just something I threw on there for fun, I don't think it can be implemented with just CAN bus data.








All indicator lights on (to show placement).








Daytime mode, with seatbelt unbuckled and right turn signal on.








Car color would change based on the config CAN message. Blind spot monitor warnings integrated, if possible.
I'm also thinking of adding some sort of mechanism to change what's showing on the left (map) and right (power gauge) areas. Stuff like odometer/trip and TPMS readings would be useful.


----------



## Mike

Thread lurker here with NO computer skills whatsoever with a sidebar question.

With all the 12 volt battery issues going on with TM3s that are more than 24 months old, has anyone here been able to monitor the 12 volt battery activity/health?

I added this to my wife's Kona EV, based on the input from that community, and it works like a charm...I want to add the same to my TM3 but my mobile tech says it will simply screw up the resident Tesla software data that monitors the 12 volt battery state of health:










From a transparent data monitoring point of view, any thoughts? Thanks.


----------



## JunyeobKim

JWardell said:


> It's been a while, but I finally have a *new DBC release and new CAN log* to share with everyone!
> This covers many of the CAN changes in the past few months, but I still could use help finding a few more things.
> 
> Get the latest DBC here:
> https://github.com/joshwardell/model3dbc
> 
> CAN log from 2019.32.11 v10
> https://www.dropbox.com/s/vpz5b0c78qmqlt8/Model3Log2019-10-02v10.asc.zip?dl=0
> 
> Spreadsheet has had a lot of updates as well:
> 
> These appear to be the changes in v10 and recent versions of v9 from the last few months:
> 0x132 Battery V & A - Current offsets changed from 1000 to zero/500
> (0x154 rear torques moved)
> 0x186 Front torque/RPM
> (0x1D4 front torques moved)
> 0x1D5 Front torques
> 0x1D8 Rear torques
> 0x266 Rear power (kW) - signals have moved, need help determining some
> 0x2E5 Front power (kW) - signals have moved, need help determining some
> 0x315 Rear inverter temps
> 0x376 Front inverter temps (used to be rear)
> 0x395 Rear (?) oil pump
> 0x396 Front (?) oil pump - these seem to move around with different firmwares
> 0x5D5 looks like temperatures - any ideas?
> 
> There are a few more general messages and fixes to the DBC and spreadsheet as well.
> 
> As for the log, it has a little of everything for you to look at. Remember mine is a RWD so AWD logs are always welcome!
> 
> -Parked
> -Plug in to charge
> -Activate both steering stalks and buttons (these messages new to the DBC)
> -Charging reaches 24A limit
> -Turn off HVAC
> -Charge for a bit
> -Remove charger
> -Reverse out of driveway
> -Forward onto road, turn around, etc
> -Stop then floor it onto highway.
> -It's raining so you will see ton of traction control activation
> -Reach 60-65 mph
> -Regen off exit
> -Turn and back on highway
> -Activate autopilot quickly ~40mph
> -exit highway
> -Another stop and floor it just before the end
> 
> Sorry it's been so long, but I've been on Early Access firmware most of the year till now!
> Also, I think a very significant new development is that instead of using mega expensive commercial CAN software as in the past, I've done all my sleuthing with free software - CANBUS-Analyzer from @amund7 and SavvyCAN from @Collin80 ! Huge thanks, sorry for my occasional nag for updates but as you can see these are super helpful! And as always lots of good help from @fast_like_electric as well.


Is there any way to find cell voltage(ID 0X401) in S/W ver V10?


----------



## JWardell

abraha2d said:


> Fun stuff. I'm also getting started on making my own instrument cluster to put behind the wheel. Spent the last few days reading through this thread, so much good information to soak up. A big thank you to everyone contributing to this effort, and @JWardell for spearheading it.
> 
> Anyways, I figured I'd share some mockups I put together for my display. (heavily) inspired by the model S cluster.
> 
> Park. Headlights and fog lights on, all doors open. Power/regen gauge totally not ripped off a low-res screenshot of the model S cluster .
> View attachment 35398
> 
> 
> Drive. Headlights and fog lights on, and brake being pressed. Blue route line is just something I threw on there for fun, I don't think it can be implemented with just CAN bus data.
> View attachment 35399
> 
> 
> All indicator lights on (to show placement).
> View attachment 35400
> 
> 
> Daytime mode, with seatbelt unbuckled and right turn signal on.
> View attachment 35401
> 
> 
> Car color would change based on the config CAN message. Blind spot monitor warnings integrated, if possible.
> I'm also thinking of adding some sort of mechanism to change what's showing on the left (map) and right (power gauge) areas. Stuff like odometer/trip and TPMS readings would be useful.


Wow those look awesome! What hardware are you using to do this?



Mike said:


> Thread lurker here with NO computer skills whatsoever with a sidebar question.
> 
> With all the 12 volt battery issues going on with TM3s that are more than 24 months old, has anyone here been able to monitor the 12 volt battery activity/health?
> 
> I added this to my wife's Kona EV, based on the input from that community, and it works like a charm...I want to add the same to my TM3 but my mobile tech says it will simply screw up the resident Tesla software data that monitors the 12 volt battery state of health:
> 
> View attachment 35402
> 
> 
> From a transparent data monitoring point of view, any thoughts? Thanks.


I kind of laughed but I guess depending on where and how it was installed, and how much power is draws from the battery, there is a slight chance the car might complain. If it really is 1mA like it says than there should be no issue installing it on any always-on 12v location.
If you are using this to log your battery voltage long-term, than that's fine.
But if you are just looking to see what the voltage is whenever you are using the car, well any 12v meter will work, and likewise we have several 12v measurements on the can bus which can be logged and displayed as well.

Matter of fact up until last week my miswired OBD harness kept all of my stuff permanently powered, and that certainly draws way more than 1ma. Even sleeping for days the car never complained nor have I had any 12v battery issues. I really think it's only a problem for higher draw loads like amps that are never turned off.

All of that said, I too was very concerned with 12v battery after reading all the reports in the forums, and bought some tiny 12v displays to put in the dash to watch it, but it never ended being an issue. My much better solution was to keep a charged jump starter battery in the trunk. So many issues I've read in the forums and (And watching Bjorn repeatedly stranding himself) would all be non-issues if they has a jump starter.



JunyeobKim said:


> Is there any way to find cell voltage(ID 0X401) in S/W ver V10?


Tesla removed 0x401 and all the cell information over a year ago. The BMS does still transmit the min and max cell voltages which is all most need to determine imbalance.


----------



## Mike

JWardell said:


> I kind of laughed but I guess depending on where and how it was installed, and how much power is draws from the battery, there is a slight chance the car might complain. If it really is 1mA like it says than there should be no issue installing it on any always-on 12v location.
> If you are using this to log your battery voltage long-term, than that's fine.
> But if you are just looking to see what the voltage is whenever you are using the car, well any 12v meter will work, and likewise we have several 12v measurements on the can bus which can be logged and displayed as well.
> 
> Matter of fact up until last week my miswired OBD harness kept all of my stuff permanently powered, and that certainly draws way more than 1ma. Even sleeping for days the car never complained nor have I had any 12v battery issues. I really think it's only a problem for higher draw loads like amps that are never turned off.
> 
> All of that said, I too was very concerned with 12v battery after reading all the reports in the forums, and bought some tiny 12v displays to put in the dash to watch it, but it never ended being an issue. My much better solution was to keep a charged jump starter battery in the trunk. So many issues I've read in the forums and (And watching Bjorn repeatedly stranding himself) would all be non-issues if they has a jump starter.


Thanks!

I'm still on the fence about adding this voltage logger/tracker or not...


----------



## iChris93

Mike said:


> Thanks!
> 
> I'm still on the fence about adding this voltage logger/tracker or not...


Most (all?) of the 12V battery issues we have seen have been in hotter climates so I am trying not to worry about it. I'm past 24 months and 44k miles.


----------



## Mike

I'd like to think it is tied to the hotter climates, but...we sure could use a small 12 volt tracker added to the app...


----------



## JunyeobKim

JWardell said:


> Wow those look awesome! What hardware are you using to doT this?
> 
> I kind of laughed but I guess depending on where and how it was installed, and how much power is draws from the battery, there is a slight chance the car might complain. If it really is 1mA like it says than there should be no issue installing it on any always-on 12v location.
> If you are using this to log your battery voltage long-term, than that's fine.
> But if you are just looking to see what the voltage is whenever you are using the car, well any 12v meter will work, and likewise we have several 12v measurements on the can bus which can be logged and displayed as well.
> 
> Matter of fact up until last week my miswired OBD harness kept all of my stuff permanently powered, and that certainly draws way more than 1ma. Even sleeping for days the car never complained nor have I had any 12v battery issues. I really think it's only a problem for higher draw loads like amps that are never turned off.
> 
> All of that said, I too was very concerned with 12v battery after reading all the reports in the forums, and bought some tiny 12v displays to put in the dash to watch it, but it never ended being an issue. My much better solution was to keep a charged jump starter battery in the trunk. So many issues I've read in the forums and (And watching Bjorn repeatedly stranding himself) would all be non-issues if they has a jump starter.
> 
> Tesla removed 0x401 and all the cell information over a year ago. The BMS does still transmit the min and max cell voltages which is all most need to determine imbalance.


Thank you very much


----------



## mdrobnak

FYI 0x401 is still very much alive on the CP / HV CAN.

Anyone know where the vehicle lock status is? I can see where the mirrors are folding in, but have missed the 'vehicle is locked' bit somewhere clearly...

-Matt


----------



## JWardell

mdrobnak said:


> FYI 0x401 is still very much alive on the CP / HV CAN.
> 
> Anyone know where the vehicle lock status is? I can see where the mirrors are folding in, but have missed the 'vehicle is locked' bit somewhere clearly...
> 
> -Matt


Well of course the communication and data is there within the BMS, but HV can exists only within the penthouse to link the BMS and HV controller. It used to be sent along to the rest of the car on the Vehicle bus.


----------



## mdrobnak

JWardell said:


> Well of course the communication and data is there within the BMS, but HV can exists only within the penthouse to link the BMS and HV controller. It used to be sent along to the rest of the car on the Vehicle bus.


 Fair enough. I was simply pointing out that if you _really_ wanted it, you can still get it with more work. You'd basically have to tap it at the Charge Port, which good luck finding the suitable plug for. TE lists it but nobody has it (https://www.te.com/usa-en/product-1452349-1.html ).

-Matt


----------



## michi84

I just recorded some logs with 2020.32.5, and it looks like the cell voltages are back! On ID 0x401!

Using Jwardells latest DBC, i get meaningfull values from cell 0 to cell 95, and the values change slightly with load, although refresh rate is low.

Further changes: ID 0x3B2 (BMS_log2) appears to have changed, also 0x7AA (HVp debug), some values dont make sense or are missing.

See for yourself: https://www.dropbox.com/sh/7ofk374rj6lnvuh/AAAk8gjyCdvn-3R3SQarPTJua?dl=0


----------



## JWardell

michi84 said:


> I just recorded some logs with 2020.32.5, and it looks like the cell voltages are back! On ID 0x401!
> 
> Using Jwardells latest DBC, i get meaningfull values from cell 0 to cell 95, and the values change slightly with load, although refresh rate is low.
> 
> Further changes: ID 0x3B2 (BMS_log2) appears to have changed, also 0x7AA (HVp debug), some values dont make sense or are missing.
> 
> See for yourself: https://www.dropbox.com/sh/7ofk374rj6lnvuh/AAAk8gjyCdvn-3R3SQarPTJua?dl=0
> View attachment 35444


_Checks log from a few weeks ago..._

By gosh you are right!
Welcome back, brick voltages!

I will have to change the signal names from cell to brick as I've learned since then.

Well see, this is why I leave old no-longer-used IDs in the DBC 

Maybe they did this just to appease Jack Rickard...


----------



## JWardell

I missed this last week, Wugz did something I meant to do for years, and that is log and determine the pedal map to motor torque:











__
https://www.reddit.com/r/teslamotors/comments/inzuhz


----------



## Mike

JWardell said:


> I missed this last week, Wugz did something I meant to do for years, and that is log and determine the pedal map to motor torque:
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> __
> https://www.reddit.com/r/teslamotors/comments/inzuhz


For the past year or so, if I "floor it" to pass someone (on a two lane highway) and then once I've pulled back into the correct lane I completely remove my foot from the accelerator...

...with the expectation that a maximum regen situation will ensue until I apply pressure on the accelerator...

...the maximum regen situation will disappear and an acceleration (black horizontal line) event will occur for about one second.

The first time that happened, it sure scared me and I wrote a nice long, detailed email to Tesla....never did hear back from them.

Now I expect it and thus don't take my foot off the accelerator with the expectation of a pure, undisturbed regen situation.


----------



## Randy Spencer

abraha2d said:


> Fun stuff. I'm also getting started on making my own instrument cluster to put behind the wheel.
> View attachment 35398
> View attachment 35399
> View attachment 35400
> View attachment 35401


Reminds me of the new one from HansShow

https://www.hautopart.com/product/model-3-y-steering-wheel-center-console-screen/


----------



## JWardell

Randy Spencer said:


> Reminds me of the new one from HansShow
> 
> https://www.hautopart.com/product/model-3-y-steering-wheel-center-console-screen/
> 
> View attachment 35699


The Hanshow display is pretty impressive! Waiting to see some solid video reviews and experiences. Also waiting to see how all these HUDs streaming out of china handle Tesla's constantly changing data


----------



## bwilson4web

JWardell said:


> Tesla's constantly changing data


Is it just the CANbus or serious format changes?

The reason I ask is I really want the tire pressure management data with both pressure and temperature.

Bob Wilson


----------



## JWardell

bwilson4web said:


> Is it just the CANbus or serious format changes?
> 
> The reason I ask is I really want the tire pressure management data with both pressure and temperature.
> 
> Bob Wilson


TPMS on the CAN has definitely changed a few times, then again they also completely changed out the TPMS system in new vehicles from traditional to bluetooth.


----------



## kornerz

CAN bus message 32C (https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L1336) contains 4 charge connector temperature readings, CC_temperature1 to CC_temperature4.

Does anyone know what parts of the charge connector these temperatures correspond to? 
From temperature values I can guess CC_temperature1 can be the connector temperature, and CC_temperature3 looks like an ambient temperature.


----------



## JWardell

kornerz said:


> CAN bus message 32C (https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L1336) contains 4 charge connector temperature readings, CC_temperature1 to CC_temperature4.
> 
> Does anyone know what parts of the charge connector these temperatures correspond to?
> From temperature values I can guess CC_temperature1 can be the connector temperature, and CC_temperature3 looks like an ambient temperature.


There are temperatures in the plug adapter, temperatures within the mobile charger, temperatures in the handle...we would have to perhaps log while heating one part at a time with a hair dryer etc.


----------



## codingoverdrive

JWardell said:


> The Hanshow display is pretty impressive! Waiting to see some solid video reviews and experiences. Also waiting to see how all these HUDs streaming out of china handle Tesla's constantly changing data


Watching the video is really interesting.

It shows two thicker wires entering the vent and then being routed down the RHS of the vehicle to the Voltage Controller (??). I'm guessing that the two wires actually contain (at least) two individual wires internally for 12V, Gnd, Can H, Can L (for the Vehicle Bus?).

Although you have to pull the dash apart, it doesn't look like a difficult job, and the connector on the VC looks similar to the one that is being used at the rear centre console.

Can anyone confirm what that connector is and what buses it has available on it?

If the VC has both the Vehicle and Chassis Canbuses available, then this might be a better solution that transmitting data over wifi/BT from the rear of the car or under the seat to a display (Head) unit. Especially if you want to create a more complex UI that displays multiple signals from the two buses.

Think I'm going to modify my design to eliminate the ESP32 transmitter, direct wire to the VC (as per the video), use an SPI Canbus chip which will be directly supported by the Pi that is driving the display.

Although the installation will be trickier, the parts count and software complexity should be reduced.

Time to get a breadboard out to host the MCP2515... (edit, got the part number wrong before!)


----------



## JWardell

codingoverdrive said:


> Watching the video is really interesting.
> 
> It shows two thicker wires entering the vent and then being routed down the RHS of the vehicle to the Voltage Controller (??). I'm guessing that the two wires actually contain (at least) two individual wires internally for 12V, Gnd, Can H, Can L (for the Vehicle Bus?).
> 
> Although you have to pull the dash apart, it doesn't look like a difficult job, and the connector on the VC looks similar to the one that is being used at the rear centre console.
> 
> Can anyone confirm what that connector is and what buses it has available on it?
> 
> If the VC has both the Vehicle and Chassis Canbuses available, then this might be a better solution that transmitting data over wifi/BT from the rear of the car or under the seat to a display (Head) unit. Especially if you want to create a more complex UI that displays multiple signals from the two buses.
> 
> Think I'm going to modify my design to eliminate the ESP32 transmitter, direct wire to the VC (as per the video), use an SPI Canbus chip which will be directly supported by the Pi that is driving the display.
> 
> Although the installation will be trickier, the parts count and software complexity should be reduced.
> 
> Time to get a breadboard out to host the MCP2515... (edit, got the part number wrong before!)


They are connecting right at the ICE computer where all three CAN busses come in, and they made a nice T harness for it. A little potentially dangerous if something goes wrong, but I sure would like a harness like that. I also didn't realize pulling the wood strip is an ideal place to run and hide wires as well.
I'm hoping to have dual bus/2515 support for the Canserver very soon, it be even nicer to optionally install the server in that spot.


----------



## abraha2d

JWardell said:


> Wow those look awesome! What hardware are you using to do this?


I'm using an RPi 2B with a PCAN-USB dongle attached, all packed into a cereal box enclosure with a 7" touchscreen.









Backend is written in Node.js, and frontend utilizes React.js. All open source, available here: https://github.com/abraha2d/ipm3.

Here's a video of it playing back data from one of @michi84's captures on Dropbox (2020-09-09 07.28.08 PM.asc i think): https://photos.app.goo.gl/KdVHtPJHpth4KtFw5
The data seems to be missing some of the time messages, which is why the clock is skipping seconds. When hooked up to an actual car, it ticks like a normal clock.
Here's another video of it re-configuring after receiving live data: https://photos.app.goo.gl/a6g6XWbAmb6rTds89

My current problem is trying to power the Pi + screen from the car. When I hook them up to the power pins from the OBD-II harness installed behind the center console, it seems to trip the e-fuse for the security controller. Symptoms include no longer being able to lock / unlock car (using the key card or the button on-screen) or being able to open the frunk. Also, since it can't detect the key card, I can't put the car in gear either. I then have to completely power off the car to get the e-fuse to reset.

Is there anywhere else where I can draw power without the potential of tripping a critical fuse?


----------



## JWardell

abraha2d said:


> I'm using an RPi 2B with a PCAN-USB dongle attached, all packed into a cereal box enclosure with a 7" touchscreen.
> 
> View attachment 35814
> 
> 
> Backend is written in Node.js, and frontend utilizes React.js. All open source, available here: https://github.com/abraha2d/ipm3.
> 
> Here's a video of it playing back data from one of @michi84's captures on Dropbox (2020-09-09 07.28.08 PM.asc i think): https://photos.app.goo.gl/KdVHtPJHpth4KtFw5
> The data seems to be missing some of the time messages, which is why the clock is skipping seconds. When hooked up to an actual car, it ticks like a normal clock.
> Here's another video of it re-configuring after receiving live data: https://photos.app.goo.gl/a6g6XWbAmb6rTds89
> 
> My current problem is trying to power the Pi + screen from the car. When I hook them up to the power pins from the OBD-II harness installed behind the center console, it seems to trip the e-fuse for the security controller. Symptoms include no longer being able to lock / unlock car (using the key card or the button on-screen) or being able to open the frunk. Also, since it can't detect the key card, I can't put the car in gear either. I then have to completely power off the car to get the e-fuse to reset.
> 
> Is there anywhere else where I can draw power without the potential of tripping a critical fuse?


For some reason some of the OBD harnesses incorrectly tap VSEC's 12v supply instead of the obvious large lighter socket wire as they should (and also will never power down). I literally cut mine and moved it over. I always recommend powering accessories from that as it's the only circuit the car will always be OK with unpredictable loads. Aside from the socket itself, it can be tapped behind the socket in the console, in the rear console connector, as well as by your feet in the bottom of the A pillar. That last spot is great for powering accessories in or on your dash.


----------



## abraha2d

JWardell said:


> For some reason some of the OBD harnesses incorrectly tap VSEC's 12v supply instead of the obvious large lighter socket wire as they should (and also will never power down). I literally cut mine and moved it over. I always recommend powering accessories from that as it's the only circuit the car will always be OK with unpredictable loads. Aside from the socket itself, it can be tapped behind the socket in the console, in the rear console connector, as well as by your feet in the bottom of the A pillar. That last spot is great for powering accessories in or on your dash.


Ah, that makes sense. Maybe they do that because the OBD-II 12V pin is always-on in ICE vehicles (straight from the battery)? At least that's how it is in mine.

I'll probably tap from behind the console, since I already have an ethernet cable running from there to the dash (for the CAN data). Thanks for the tip!

EDIT: There's 2 pairs of thick wires on that connector (blue + black, and yellow + black). There's 12V on both pairs. Is there a difference between the two, or are they the same feed?

EDIT 2: Picked the yellow + black pair.


----------



## abraha2d

Now that the power issue is resolved, it works! Video here: https://photos.app.goo.gl/1gWU3TaoiuMhPmh18
If you look closely you can see the Pi struggling to keep up with the incoming CAN data. There's about a full second of latency... I guess that's what I get for writing everything in javascript. 
The lag is much more apparent when animations come into play: https://photos.app.goo.gl/P9RviHmwxqpLmFn29. For comparison, here is the same thing, but on a laptop instead of the Pi: https://photos.app.goo.gl/XaqSMNVHZcCJpmQH7.


----------



## JWardell

abraha2d said:


> Now that the power issue is resolved, it works! Video here: https://photos.app.goo.gl/1gWU3TaoiuMhPmh18
> If you look closely you can see the Pi struggling to keep up with the incoming CAN data. There's about a full second of latency... I guess that's what I get for writing everything in javascript.
> The lag is much more apparent when animations come into play: https://photos.app.goo.gl/P9RviHmwxqpLmFn29. For comparison, here is the same thing, but on a laptop instead of the Pi: https://photos.app.goo.gl/XaqSMNVHZcCJpmQH7.


I'm amazed javascript can handle the massive amount of data 
Very cool.


----------



## JWardell

If you all haven't noticed, 2020.40.x breaks a bunch of CAN messages, and I am trying to figure out changes.
I know 00C UI status message has disappeared, but if anyone else has noticed other things, please let me know so I can target them


----------



## kornerz

JWardell said:


> If you all haven't noticed, 2020.40.x breaks a bunch of CAN messages, and I am trying to figure out changes.
> I know 00C UI status message has disappeared, but if anyone else has noticed other things, please let me know so I can target them


As a data point, the messages I use are intact:
118 132 20C 312 21D 241 243 252 257 261 264 266 268 282 287 2B4 2D2 2F2 315 321 32C 332 336 33A 352 3A1 3B6 3D2 3D8 3F2 3F5 3FE 473 541


----------



## JunyeobKim

Your DBC is very powerful. I'm really appreicate. 

So now I can see some various diagnostic flag signals about isolation resistance in Model3 DBC.
But I can't explain each signals means exactly.
Could you please give me detail information about each signals? 
How can I separate each signals and What is the difference?

-BMS_a034_SW_Passive Isolation 
-BMS_a035_SW_Isolation
-BMS_a123_SW_Internal_Isolation
-BMS_a151_SW_external_Isolation
-BMS_a155_SW_Weak_short_impedence

Thank you.


----------



## joverdijk

Until now, I've had a Raspberry PI4 with bluetooth to my OBDLINK LX and the german's wireharnass for my Model3.
Today i've received canshield with MCP2515 CAN controller and MCP2551 CAN transceiver, to hardwire canH/L via OBD -> db9 to canbus shield.
I am curious about starting dump/selecting signals .. with OBDLINK you could talk ST-commandset.
Anybody any documentation or github stuff to get me going?
Reason behind this is that I want to to more speedy capturing of data, the LX craps out with BUFFER FULL quite soon (and i want to monitor several highspeed signals).
Anyone can point me in any direction? (maybe via DM) Thanks!


----------



## JWardell

JunyeobKim said:


> Your DBC is very powerful. I'm really appreicate.
> 
> So now I can see some various diagnostic flag signals about isolation resistance in Model3 DBC.
> But I can't explain each signals means exactly.
> Could you please give me detail information about each signals?
> How can I separate each signals and What is the difference?
> 
> -BMS_a034_SW_Passive Isolation
> -BMS_a035_SW_Isolation
> -BMS_a123_SW_Internal_Isolation
> -BMS_a151_SW_external_Isolation
> -BMS_a155_SW_Weak_short_impedence
> 
> Thank you.


Those are not signals, but alerts, and usually coincide with a different error message on the screen or log. Perhaps they have various isolation tests, and external is probably triggered by the supercharger's isolation data.



joverdijk said:


> Until now, I've had a Raspberry PI4 with bluetooth to my OBDLINK LX and the german's wireharnass for my Model3.
> Today i've received canshield with MCP2515 CAN controller and MCP2551 CAN transceiver, to hardwire canH/L via OBD -> db9 to canbus shield.
> I am curious about starting dump/selecting signals .. with OBDLINK you could talk ST-commandset.
> Anybody any documentation or github stuff to get me going?
> Reason behind this is that I want to to more speedy capturing of data, the LX craps out with BUFFER FULL quite soon (and i want to monitor several highspeed signals).
> Anyone can point me in any direction? (maybe via DM) Thanks!


That will depend on the particular 2515 shield you purchased, which hopefully has some documentation on how to read from it...the common 2515 boards out there are SPI and still need a microcontroller and software to work with them.


----------



## joverdijk

JWardell said:


> That will depend on the particular 2515 shield you purchased, which hopefully has some documentation on how to read from it...the common 2515 boards out there are SPI and still need a microcontroller and software to work with them.


Its CAN-BUS shield and looks exactly like this:

https://www.fasttech.com/product/6479701-can-bus-shield-v1-2-expansion-board-module

I understand i'll be needing an arduino R3 / uno together with it? I have those laying around.

Wondering if this is something that would be compatible:
https://github.com/Seeed-Studio/CAN_BUS_Shield

Tips and hints are welcome


----------



## JWardell

joverdijk said:


> Its CAN-BUS shield and looks exactly like this:
> 
> https://www.fasttech.com/product/6479701-can-bus-shield-v1-2-expansion-board-module
> 
> I understand i'll be needing an arduino R3 / uno together with it? I have those laying around.
> 
> Wondering if this is something that would be compatible:
> https://github.com/Seeed-Studio/CAN_BUS_Shield
> 
> Tips and hints are welcome


Yes, it's a shield, so it's designed to connect to a microcontroller that you then program. Not the same as a CAN to RS232 serial. (I would recommend Canable for that)
But that github link looks like it has the documentation you need.


----------



## lopflop

Hello JWawrdell and everyone. I'm wondering if there is anywhere a list of specification of DID's. For example if I send 22 F0 14 on vehicle can at CanIDs 602 & 612, I'm given a part number of my main battery. I've been searching a lot, but could not find anything about any DID. Could you help me on this one or give me a hint where to search? I'm really curious what some DID's represents.

Sorry if this is a wrong thread.


----------



## JWardell

lopflop said:


> Hello JWawrdell and everyone. I'm wondering if there is anywhere a list of specification of DID's. For example if I send 22 F0 14 on vehicle can at CanIDs 602 & 612, I'm given a part number of my main battery. I've been searching a lot, but could not find anything about any DID. Could you help me on this one or give me a hint where to search? I'm really curious what some DID's represents.
> 
> Sorry if this is a wrong thread.


I assume DID=Device ID but that's not part of CAN, so I'm not quite sure what you are looking for. You certainly do not want to be transmitting anything on your can bus, or Tesla will no doubt notice it. You can find some BMS info by reading ID 0x300


----------



## kornerz

JWardell said:


> I assume DID=Device ID but that's not part of CAN, so I'm not quite sure what you are looking for. You certainly do not want to be transmitting anything on your can bus, or Tesla will no doubt notice it. You can find some BMS info by reading ID 0x300


There is another level of communication on top of CAN bus, which was mentioned in some of Tesla hacking videos. Short requests are sent over CAN bus and large 64-bit data blobs are returned in a single message, which need to be decoded then. I think that is called "UDS - ISO 14229", and there are confirmations that it is used by Tesla (here, for example: https://www.blackhat.com/docs/us-17...Hacking-Tesla-From-Wireless-To-CAN-Bus-wp.pdf )


----------



## JWardell

Oh yes, well there are numerous UDS commands that can be sent to every device, and that is what is used to flash new firmware updates as well. But I would be worried that Tesla might be monitoring unexpected UDS messages


----------



## Onyx

Hey all! I finally accepted that running gauges on the center screen is not really what I want. So I'm still keeping my system for heavier data screens (and of course the signal browser), but I'm also developing a gauge cluster that sits behind the steering wheel. It turns out I kinda missed that without knowing it. I guess 100 years of car design isn't 100% wrong.  I'll post more some info of this cluster soon. Here's a preview of what it looks like right now.










(Don't judge me on the tire pressure, it's cold and the sun's been beating down on the right side of car all day!  )

Here what it looks like in the car. I'm just using my phone for now - but wow, a high-res AMOLED is an awesome screen for an instrument cluster, especially at night! It makes me sad that the main screen isn't that good. Visibility is great, and my hands fit on either side of my field of view during normal 10-2 driving. I'll eventually be building a "real" display so I don't need to use my phone, assuming I like this setup and want to make it more permanent.










For mounting, I whipped up a quick and dirty stand in cad and 3d printed it. I fastened it to the steering column top shroud with double sided tape. It seems be holding up fine for now, and doesn't wobble. Eventually I'll clean up the mount and make it look nicer. Maybe I'll fasten it to the steering column directly someday, but that'll involve some drilling into the shroud, so I want to make sure before proceeding.

Here's what it looks like without the phone in it.










The groove fits my case perfectly, so inserting and removing the phone is fast and easy, and the rubber in the case lets it "glide" somewhat (as apposed to scrapping).

I was able to use my system to quickly whip this up and test it in the car. It is already super usable. Pretty nice prototyping tool, and I'm also pretty happy with the result, especially considering it represents less that 2 weekends of work all in.

---

Oh, a couple questions too: It looks like UI_status (12) doesn't work anymore. Has anyone found where it moved to? I was going to use the UI_displayOn signal to turn off the cluster with the main display. And also, what are people using for the turn indicators? I'm currently using
VCLEFT_turnSignalStatus and VCRIGHT_turnSignalStatus, which work nicely for blinking, but when the brake light is on, both those signals transmit "ON", which isn't the normal behaviour for a turn indicator.


----------



## JWardell

Onyx said:


> Hey all! I finally accepted that running gauges on the center screen is not really what I want. So I'm still keeping my system for heavier data screens (and of course the signal browser), but I'm also developing a gauge cluster that sits behind the steering wheel. It turns out I kinda missed that without knowing it. I guess 100 years of car design isn't 100% wrong.  I'll post more some info of this cluster soon. Here's a preview of what it looks like right now.
> 
> View attachment 35954
> 
> 
> (Don't judge me on the tire pressure, it's cold and the sun's been beating down on the right side of car all day!  )
> 
> Here what it looks like in the car. I'm just using my phone for now - but wow, a high-res AMOLED is an awesome screen for an instrument cluster, especially at night! It makes me sad that the main screen isn't that good. Visibility is great, and my hands fit on either side of my field of view during normal 10-2 driving. I'll eventually be building a "real" display so I don't need to use my phone, assuming I like this setup and want to make it more permanent.
> 
> View attachment 35956
> 
> 
> For mounting, I whipped up a quick and dirty stand in cad and 3d printed it. I fastened it to the steering column top shroud with double sided tape. It seems be holding up fine for now, and doesn't wobble. Eventually I'll clean up the mount and make it look nicer. Maybe I'll fasten it to the steering column directly someday, but that'll involve some drilling into the shroud, so I want to make sure before proceeding.
> 
> Here's what it looks like without the phone in it.
> 
> View attachment 35957
> 
> 
> The groove fits my case perfectly, so inserting and removing the phone is fast and easy, and the rubber in the case lets it "glide" somewhat (as apposed to scrapping).
> 
> I was able to use my system to quickly whip this up and test it in the car. It is already super usable. Pretty nice prototyping tool, and I'm also pretty happy with the result, especially considering it represents less that 2 weekends of work all in.
> 
> ---
> 
> Oh, a couple questions too: It looks like UI_status (12) doesn't work anymore. Has anyone found where it moved to? I was going to use the UI_displayOn signal to turn off the cluster with the main display. And also, what are people using for the turn indicators? I'm currently using
> VCLEFT_turnSignalStatus and VCRIGHT_turnSignalStatus, which work nicely for blinking, but when the brake light is on, both those signals transmit "ON", which isn't the normal behaviour for a turn indicator.


That looks spectacular! I was immediately wondering what nice big OLED screen did you find to use there...then I realized it was a phone.  Which is a great idea, perfect size, and I have a growing collection of useless android phones collecting dust that I really should repurpose. Too bad I can't run TesLax on them with its pretty gauges.
I also like the simple 3D print mount. I can also imagine running other apps like Waze or JBV1

Also: 0x00C has moved to 0x353


----------



## Onyx

JWardell said:


> Also: 0x00C has moved to 0x353


Thanks, that worked. Out of curiosity, what's your approach to figure this out? Do have a way to quickly identify when things move based on bit patterns or something? Or more a manual process of pouring over logs?


----------



## JWardell

Onyx said:


> Thanks, that worked. Out of curiosity, what's your approach to figure this out? Do have a way to quickly identify when things move based on bit patterns or something? Or more a manual process of pouring over logs?


Quick? More like a week of frantically looking through the matrix  Well mostly because I get updates on the later side, and I had a handful of folks whose displays stopped working (they turn off when displayOn=0) with 2020.40.x. But because I now have hardware always connectected that make logging super simple, I take a log with every firmware update, and then I can use SavvyCan to compare logs and see what new messages appear.

And then by somewhat luck/coincidence I looked at raw data for that message and you realize it doesn't change much...so I searched the new log for the same string and found it  Then create a new DBC and verify the data still matches up because of course there is a good chance signals changed. But thankfully they didn't seem to here.

I think the explanation is the old ID 0x00C is super low/high priority, and isn't important enough (should be crash messages and such down there) so someone smart moved it higher around where all the other UI data is.


----------



## kornerz

A small data request for owners of 2020 SR+ Model 3.
I'm trying to find out how my (2019 SR+) battery pack compares to recent ones.

Can someone with 2020 SR+ and CAN bus access post here the following signals data?
- 33A (UI displayed range and "default" efficiency)
- 352 (Battery capacity)
- 292 (beginningOfLifePackEnergy value)

I have 52.4 kWh for beginningOfLifePackEnergy and UI_whpm = 219 wh/mi (or 136.8 wh/km) which gives me 366.9km (230mi) of available range after deducting 2.2kWh of buffer capacity.


----------



## jackbauer

Folks, I'm wondering if anyone would have such a thing as a log of the hv can bus in a Euro Model 3 with CCS? I'm working on a project to build a stand alone M3 charge port controller. any help much appreciated
https://openinverter.org/forum/viewtopic.php?f=17&t=1040


----------



## JWardell

4hm4dr3 said:


> Hi Mr. Wardell and good evening folks,
> 
> I'm relatively new to this topic (CANBus access, read data from Tesla), but I am stucking on one point, where I am developing a Flutter app (Google's new cross-platform framework for mobile), which should access the OBD2 Data from Tesla Model 3/Y and S/X (like Teslax or scan my tesla). Disclaimer: There's no problem with the mobile framework or bluetooth access. I can handle every bluetooth connection I want.
> 
> 1. I've collected a lot of data through the internet and got several CANDump's for Model 3/Y and S/X but I don't know how to use them.
> 2. I've tried to send commands through BLE-characteristics and getting something like: "*? >*" or "*3513515341 51543551345 >*", but I don't know what to do with these info's. I am sending in ascii encoded: "*132\r*" for getting the battery voltage. after getting a response, I am decoding it, but best case will be something like *317 V* for the calculation (got it from CANBUS-Analyzer in Model3Packets):
> *var voltage = (bytes[0] + (bytes[1] << 8)) / 100.0;*
> 
> 3. But before I am getting 317 V I have to play around with the command (I am actually sending ONLY "*132\r*"). I'm sure I have to do an initialization phase, but I really don't know how
> 
> What are the first steps and how can I initialize the adapter so I can send the command for the battery voltage for example?
> 
> Thanks a lot  (My first post ever here ^^)


It sounds like you are trying to send ELM327 commands to a bluetooth OBD adapter. Hopefully there is documentation for you adapter. Here are the docs for OBDLinks:
https://www.scantool.net/downloads/98/stn1100-frpm.pdf


----------



## 4hm4dr3

JWardell said:


> It sounds like you are trying to send ELM327 commands to a bluetooth OBD adapter. Hopefully there is documentation for you adapter. Here are the docs for OBDLinks:
> https://www.scantool.net/downloads/98/stn1100-frpm.pdf


Thanks, I'll study that


----------



## JWardell

2021 Model 3 (and Y?) packs bumped to 82kWh, though are software limited (for now?) to 325mi range.
https://electrek.co/2020/11/10/tesla-model-3-82-kwh-battery-pack-new-cells/

I would love to take a peek at a quick CAN log from a 2021 car if anyone can provide one!


----------



## Eugenius

JWardell said:


> 2021 Model 3 (and Y?) packs bumped to 82kWh, though are software limited (for now?) to 325mi range.
> https://electrek.co/2020/11/10/tesla-model-3-82-kwh-battery-pack-new-cells/
> 
> I would love to take a peek at a quick CAN log from a 2021 car if anyone can provide one!


The 2019 (my EU Version) and 2020 version has 79 kWh in this document... 
If you will, I can take a foto from my document.
I will share the data from 2021 EU Model 3 in next weeks (my friend bought one, but doesn't picked up yet)


----------



## dimitar.ns

JWardell said:


> The Hanshow display is pretty impressive! Waiting to see some solid video reviews and experiences. Also waiting to see how all these HUDs streaming out of china handle Tesla's constantly changing data


They don't! My HUD stopped working few weeks ago with one of the updates. Now it's showing always "P" and is useless.
I will dig deeper to see what messages changed and why this happened.

The HUD doesn't have FOTA so there is no way to recover it and the Chinese guys said they will send me new HW...it's funny more like HardwareOverTheAir


----------



## JWardell

dimitar.ns said:


> They don't! My HUD stopped working few weeks ago with one of the updates. Now it's showing always "P" and is useless.
> I will dig deeper to see what messages changed and why this happened.
> 
> The HUD doesn't have FOTA so there is no way to recover it and the Chinese guys said they will send me new HW...it's funny more like HardwareOverTheAir
> 
> View attachment 36068


I saw someone on TMC also was told by hansshow they would send a replacement, I can't believe they didn't plan for updates and wondering if there is a hardware issue they are also addressing.
I did describe here how I found and fixed the changed message so I'm sure they could have done that. But drive mode hasn't changed so I'm not sure what's going on with their displays.


----------



## kornerz

kornerz said:


> CAN bus message 32C (https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L1336) contains 4 charge connector temperature readings, CC_temperature1 to CC_temperature4.
> 
> Does anyone know what parts of the charge connector these temperatures correspond to?
> From temperature values I can guess CC_temperature1 can be the connector temperature, and CC_temperature3 looks like an ambient temperature.


Answering my own question after a couple of weeks of observation, temperatures in 32C most probably mean the following:

CC_temperature1: Wall side plug temperature.
*If this reaches 63 °C, MC will throttle charging by reducing the current *
CC_temperature2: Mobile Connector internal (PCB) temperature
This one remains at 30-40 °C while MC is plugged in, even if charge is stopped.
CC_temperature3: Ambient air temperature near the MC
CC_temperature4: Car side plug temperature (or possibly, some other part of PCB - not sure at this one)


----------



## Onyx

I think one of things I like the most about looking at this CAN data, is seeing how much attention to detail Tesla has put into everything. In this case, monitoring 4 different temperatures in the charge port to make sure charging is always safe.


----------



## dimitar.ns

JWardell said:


> I saw someone on TMC also was told by hansshow they would send a replacement, I can't believe they didn't plan for updates and wondering if there is a hardware issue they are also addressing.
> I did describe here how I found and fixed the changed message so I'm sure they could have done that. But drive mode hasn't changed so I'm not sure what's going on with their displays.


I made a simple ESP32 which re-sends the data from 0x353 with ID 0x00C and I can confirm the HUD is WORKING AGAIN! @JWardell, thank you for the hint.
Maybe the HUD SW is using this message as a IGN switch (Ready state) and don't interpret the other signals if doesn't receive it with correct state - not a good idea.


----------



## JWardell

Onyx said:


> I think one of things I like the most about looking at this CAN data, is seeing how much attention to detail Tesla has put into everything. In this case, monitoring 4 different temperatures in the charge port to make sure charging is always safe.


Yes, that's been my point for a long long time. There are hundreds of temperature sensors in the car, littered with all sorts of sensors, many of which they might not even use but leave for potential future use. It gives them so much flexibility to make things smarter and smarter in future software.



dimitar.ns said:


> I made a simple ESP32 which re-sends the data from 0x353 with ID 0x00C and I can confirm the HUD is WORKING AGAIN! @JWardell, thank you for the hint.
> Maybe the HUD SW is using this message as a IGN switch (Ready state) and don't interpret the other signals if doesn't receive it with correct state - not a good idea.


Haha, what a brilliantly simple idea, love it!


----------



## Eugenius

dimitar.ns said:


> I made a simple ESP32 which re-sends the data from 0x353 with ID 0x00C and I can confirm the HUD is WORKING AGAIN! @JWardell, thank you for the hint.
> Maybe the HUD SW is using this message as a IGN switch (Ready state) and don't interpret the other signals if doesn't receive it with correct state - not a good idea.


Hi, can you share your SW for ESP32? thx!


----------



## dimitar.ns

Eugenius said:


> Hi, can you share your SW for ESP32? thx!


Sure, why not, there is nothing special in it. Of course there might be more code, checks etc but for this purpose its enough.
EDIT: Uploaded it here - https://github.com/dimitarns/UI_status_fix


----------



## Onyx

dimitar.ns said:


> Maybe the HUD SW is using this message as a IGN switch (Ready state) and don't interpret the other signals if doesn't receive it with correct state - not a good idea.


It wouldn't be totally crazy to wait for UI_readyForDrive (one of the signals carried by this message) before "starting to listen for other signals". The car is known to spew bad data when things are "not applicable". Not having OTA updates is crazy though, obviously.


----------



## Eugenius

dimitar.ns said:


> Sure, why not, there is nothing special in it. Of course there might be more code, checks etc but for this purpose its enough.
> EDIT: Uploaded it here - https://github.com/dimitarns/UI_status_fix


The only thing I don't like in your code: you send messages directly to Vehicle Bus... with wrong information (from car perspective)... 
it might be ok today, but tomorrow (e.g. next update) it can be dangerous...


----------



## dimitar.ns

Eugenius said:


> The only thing I don't like in your code: you send messages directly to Vehicle Bus... with wrong information (from car perspective)...
> it might be ok today, but tomorrow (e.g. next update) it can be dangerous...


Yes, it's not perfect but it's a workaround for now. The best fix will be with a 2 CAN module (like the one @JWardell is making) which acts as a bridge between the HUD and the car and duplicates the message only in the HUD CAN bus part. Maybe in the future if I got a 2 CAN module I can give it a try.


----------



## kornerz

dimitar.ns said:


> Yes, it's not perfect but it's a workaround for now. The best fix will be with a 2 CAN module (like the one @JWardell is making) which acts as a bridge between the HUD and the car and duplicates the message only in the HUD CAN bus part. Maybe in the future if I got a 2 CAN module I can give it a try.


Re-sending data under old ID can be harmful only in case if Tesla decides to reuse ID 0x00C for some new data.

A possible workaround without a second CAN bus: Listen for first ~1000 messages on the bus after boot, and start main activity (relaying 0x353 to ID 0x00C ) only if no traffic on 0x00C detected.


----------



## Eugenius

I've just released ESP32 firmware for ScanMyTesla adapter:
https://github.com/Adminius/ESP32-ScanMyTesla

It simulates ST1110 OBII Stick, but uses ESP32 for it (costs until 10$ for all parts on Ali).


----------



## JWardell

kornerz said:


> Re-sending data under old ID can be harmful only in case if Tesla decides to reuse ID 0x00C for some new data.
> 
> A possible workaround without a second CAN bus: Listen for first ~1000 messages on the bus after boot, and start main activity (relaying 0x353 to ID 0x00C ) only if no traffic on 0x00C detected.


A better option would be for them to just update their display firmware


----------



## Onyx

kornerz said:


> Re-sending data under old ID can be harmful only in case if Tesla decides to reuse ID 0x00C for some new data.
> 
> A possible workaround without a second CAN bus: Listen for first ~1000 messages on the bus after boot, and start main activity (relaying 0x353 to ID 0x00C ) only if no traffic on 0x00C detected.


And start the count only once the brake pedal has been pressed and the car is "fully on". (Lots of messages aren't sent until the "fully on" state. It's not foolproof though, lots of messages are only sent when plugged in, or supercharging.)


----------



## Eugenius

Is an estimated range after 10km/25km/50km (Energy Monitor, 5/15/30 Miles) on CanBus available?


----------



## kornerz

Interesting new data: Tesla service manuals and Toolbox access:

__ https://twitter.com/i/web/status/1334564079264993281
Web toolbox tries to connect to car ethernet port and has correct auth keys for that:
(not tried in car yet, but request is definitely sent):


----------



## JWardell

Yes, everyone is abuzz but much too busy of a day for me to try...doesn't help that I have my first service appointment in a few days too so I don't want to screw with anything right now. But I'm sure a lot of new data may float up soon


----------



## Eugenius

Is it somehow possible (CAN message?!) to wake up a car from a sleep?
I have no cell service in my underground parking lot but WiFi.
That means I can't start preconditioning via tesla app until car wakes up by it self and connects to WiFi.
Any ideas?


----------



## kornerz

Eugenius said:


> Is it somehow possible (CAN message?!) to wake up a car from a sleep?
> I have no cell service in my underground parking lot but WiFi.
> That means I can't start preconditioning via tesla app until car wakes up by it self and connects to WiFi.
> Any ideas?


Any CAN message will wake the car.
I use message 1F9 with payload of "00" for the last ~8 months, with no adverse effects so far.
Actual command on a RPi with CAN adapter:
> cansend can0 1F9#00


----------



## kornerz

Looks like 2020.48.10 changed some of CAN messages.

What I've found is that RawBattCurrent132 in ID132, which was a signed 16-bit value with multiplier of 0.05 and offset of 500:


> SG_ RawBattCurrent132 : 32|[email protected] (-0.05,500) [-1138.35|2138.4] "A" Receiver


now apparently is a *14-bit* wide signed value with the same multiplier, but *offset of something between 2 and 3*:


> SG_ RawBattCurrent132 : 32|[email protected] (-0.05,2) [-1138.35|2138.4] "A" Receiver


Can somebody else on 2020.48 with CAN bus access verify that?
Couple of values from my CAN dump on #132:


Code:


  can0  132   [8]  53 96 FC FF 31 40 FF 0F
  can0  132   [8]  58 96 FC FF 31 40 FF 0F
  can0  132   [8]  55 96 FD FF 32 40 FF 0F
  can0  132   [8]  59 96 FC FF 33 40 FF 0F
  can0  132   [8]  58 96 FC FF 2E 40 FF 0F
  can0  132   [8]  63 96 FB FF 32 40 FF 0F
  can0  132   [8]  67 96 FC FF 31 40 FF 0F
  can0  132   [8]  67 96 FD FF 31 40 FF 0F
  can0  132   [8]  69 96 FC FF 32 40 FF 0F


----------



## pyjamasam

Ya I noticed this the other day when I saw that Raw Batt Current was showing up as a large negative number.



Code:


(1607966410.257917) vcan0 132#4398ACFFB13FFF0F
(1607966410.267917) vcan0 132#3F98A6FFA03FFF0F
(1607966410.277917) vcan0 132#3F98A7FF803FFF0F
(1607966410.287917) vcan0 132#4498AAFFA73FFF0F
(1607966410.297917) vcan0 132#3E98A2FF963FFF0F
(1607966410.307917) vcan0 132#4398A8FF963FFF0F
(1607966410.317917) vcan0 132#3F98ADFFA83FFF0F
(1607966410.327917) vcan0 132#3E98A5FF933FFF0F
(1607966410.337917) vcan0 132#4198ACFFA63FFF0F

I am not sure of the relationship between raw and smooth, but an offset of 3 gets my numbers close.

chris.


----------



## JWardell

I've heard of some other changes to 48 as well.
Been slammed with work this past week. I did take a log but no time to dive in.
Plus I need to get whip up a bunch of dual bus servers, becuase Chris has some incredible firmware for them now


----------



## kornerz

OK, so I've collected 550k of ID132 messages and averaged "RawBattCurrent132 - SmoothBattCurrent132" value over these 550k samples.
And it appears that correct value of the offset is *2.8 *(raw average was 2.804463):


Code:


SG_ RawBattCurrent132 : 32|[email protected] (-0.05,2.8) [-1138.35|2138.4] "A" Receiver


----------



## pyjamasam

SO I am seeing an offset of 821.9 (could be rounded to 822) with the original 16bit width. This gives me a difference between smooth and raw as an average of 0.095 over 486301 frames. If I use 821.99 as the offset it ends up being a difference of 0.005 over those same frames. Though I suspect that thats just me "fitting" the values to make the data work...

The question is why shorten the field by 2 bits. What could they stuff in there that would be useful. I mean I could see the offset changing. I don't know. It's curious. Any way, just presenting my findings.

@kornerz can you check with my assumptions?
I tried your 2.8 offset on 14 bits but I end up with an error of -3.57 over the range of the same frames. And there are some times it jumps up as high as 7.

I don't know how the smoothing vs raw relationship is though. Using 14 bits and an offset of 2.8 makes the rawcurrent more "spiky" though so it seems to be more in line with that that relationship should be.

<shrug>. All that to say, I am not really sure. hahaha.

chris.


----------



## JWardell

I can confirm, raw batt current simply changed offset to 822.
But you really sould be using the smooth/averaged batt current. I think the raw is there in case something wants to detect a high spike. Smooth is not much of an average, more like oversampled more accurate data.


----------



## kornerz

Re-checked, and 16-bit width + offset of 822 also works well.
So this must be a math coincidence of some kind, that decoding the same value in two ways gives the same result.


----------



## Eugenius

JWardell said:


> I can confirm, raw batt current simply changed offset to 822.
> But you really sould be using the smooth/averaged batt current. I think the raw is there in case something wants to detect a high spike. Smooth is not much of an average, more like oversampled more accurate data.


Will you update DBC file on github?


----------



## Eugenius

Eugenius said:


> The 2019 (my EU Version) and 2020 version has 79 kWh in this document...
> If you will, I can take a foto from my document.
> I will share the data from 2021 EU Model 3 in next weeks (my friend bought one, but doesn't picked up yet)


Now I've data from 1 week and 600 km old Model 3 Long Range 2021 with 82kWh battery.


----------



## Dave EV

Just got my adapter installed on my 2018 Model 3 and have an ELM327 plugged in that's working, packet rate seems to vary between 10-40 packets per second at the most.

It seems that the OBDlink adapters should be much faster - what's the difference between the $50 OBDlink LX and the $100 OBDlink MX+ ? Is there any difference when using scan my tesla?

Edit: Found my answer - for scan my tesla use, it appears that the LX and MX+ are no different, so save $50 and go with the LX.


----------



## pyjamasam

Dave EV said:


> Just got my adapter installed on my 2018 Model 3 and have an ELM327 plugged in that's working, packet rate seems to vary between 10-40 packets per second at the most.


The actual rate on the Vehicle bus (the one I am guessing you connected to - behind the armrest) is around 2400-2600 CAN frames/s when in drive. There is a LOT of data flowing through that bus. I am not totally sure how ScanMyTesla and the OBDLink manages filters, but a rate of 10-40 seems _super _low. Then again it might be the norm. Not sure. I'd need some more experience with that hardware/software. <shrug>. I'd be curious to know what other people see with that hardware/software combo. Just as a datapoint for reference.



Dave EV said:


> It seems that the OBDlink adapters should be much faster - what's the difference between the $50 OBDlink LX and the $100 OBDlink MX+ ? Is there any difference when using scan my tesla?


The MX+ is the only one thats certified for using with iOS. So if you're using Android then the LX is prob fine.

chris.


----------



## Eugenius

pyjamasam said:


> I am not totally sure how ScanMyTesla and the OBDLink manages filters


ST1110 protocol (witch OBDLink is using) allows to set ID filters. That means, only relevant message IDs (SMT sets those) will be forwarded via BT to SMT.
I use the "same trick" on my ESP32 implementation -> today I could get up to 750 packets/second:
https://github.com/Adminius/ESP32-ScanMyTesla


----------



## pyjamasam

Not to toot our own horn (but just to provide some additional info - well, and you know, maybe a little tooting as well  ), @JWardell and I have his new dual bus CANServer running at just shy of 6000 frames/second. Now thats the rate from the car, but over a WIFI link tesLAX can consume those frames really well. (Also a modified version of SavvyCAN can ingest them real time over the network as well)

But thats wifi, using a binary protocol. The ST/ELM ascii based protocol has a lot more overhead, and Bluetooth unfortunately has rather limited bandwidth compared to wifi.

The tesLAX developer and I are also working on adding some filtering to that network connection, just mostly to reduce load a little and make stuff a little easier to process. I'd likewise love to work with @amund7 to get CANServer support added to ScanMyTesla at those kind of high data rates as well.

chris.


----------



## JWardell

pyjamasam said:


> Not to toot our own horn (but just to provide some additional info - well, and you know, maybe a little tooting as well  ), @JWardell and I have his new dual bus CANServer running at just shy of 6000 frames/second. Now thats the rate from the car, but over a WIFI link tesLAX can consume those frames really well. (Also a modified version of SavvyCAN can ingest them real time over the network as well)
> 
> But thats wifi, using a binary protocol. The ST/ELM ascii based protocol has a lot more overhead, and Bluetooth unfortunately has rather limited bandwidth compared to wifi.
> 
> The tesLAX developer and I are also working on adding some filtering to that network connection, just mostly to reduce load a little and make stuff a little easier to process. I'd likewise love to work with @amund7 to get CANServer support added to ScanMyTesla at those kind of high data rates as well.
> 
> chris.


YES. I honestly meant to do a video about v2 Server, v2 software, and two busses two weeks ago (lots of twos there)...plus working on S&X support. I hope to do that during the break this week. But you might notice they have been available in the store.

It's not a big deal for people just looking for displays, but for CAN data nerds, it's kind of now my dream product, very much thanks to @pyjamasam 's massive software efforts. Full speed RAW CAN logging from both busses into a compact file. Live transmission of that data to TesLax or even to my computer running SavvyCAN. And even using your home network from the comfort of your couch! Also the beginnings of data log auto transfer, hoping for support from Teslogger etc to have the potential of Teslafi with thousands of times more data.



Eugenius said:


> Will you update DBC file on github?


I didn't realize before that you were making a CAN to bluetooth ESP32 adapter...probably much better than the existing OBD dongles aside from bandwidth limits.
DBC hasn't been updated in a long time, for a long list of reasons. I'll try to get something updated soon.


----------



## Eugenius

kornerz said:


> Any CAN message will wake the car.
> I use message 1F9 with payload of "00" for the last ~8 months, with no adverse effects so far.
> Actual command on a RPi with CAN adapter:
> > cansend can0 1F9#00


hm... I need help :/
I powered ESP32 with powerbank (my OBD cable doesn't provide 12V if car is sleeping).
ESP32 connected to WiFi and MQTT server.
ESP32 reacts to MQTT inputs, that is not a problem, but if I send ID 1F9 with data "00" nothing happens... Car stays asleep.
I also tried with ID016 and "01" it also doesn't work.

CAN_FRAME txFrame;
txFrame.rtr = 0;
txFrame.id = 0x1F9;
txFrame.extended = false;
txFrame.length = 1;
txFrame.data.uint8[0] = 0x00;
CAN0.sendFrame(txFrame);

To be sure: we are talking about vehicle bus. Car is sleeping (HV contactors are off. car's WIFI ist not connected)
I'm not really sure if 1F9#00 really was send to can bus (I should try with a second OBD dongle in parallel to check it) or if car doesn't react to it...
Car's FW: 2020.48.26


----------



## kornerz

Eugenius said:


> To be sure: we are talking about vehicle bus. Car is sleeping (HV contactors are off. car's WIFI ist not connected)
> I'm not really sure if 1F9#00 really was send to can bus (I should try with a second OBD dongle in parallel to check it) or if car doesn't react to it...
> Car's FW: 2020.48.26


Yes, exactly. Vehicle bus, car is sleeping, sending 1F9#00 should wake it.

I would also check if ESP32 really sends the message.


----------



## Roci

Since you're using an ESP32, you must be using a separate CAN transceiver and some of those have a pin that must be pulled high or low to configure the transmission mode. For instance I'm using the SN65HVD230 and I specifically wired it to be in low power mode, which causes it to only to listen in on the bus. I hear the CANserver board is wired the same way.


----------



## JWardell

Roci said:


> Since you're using an ESP32, you must be using a separate CAN transceiver and some of those have a pin that must be pulled high or low to configure the transmission mode. For instance I'm using the SN65HVD230 and I specifically wired it to be in low power mode, which causes it to only to listen in on the bus. I hear the CANserver board is wired the same way.


That's correct. Intentionally disables transmit for peace of mind.


----------



## Eugenius

Roci said:


> Since you're using an ESP32, you must be using a separate CAN transceiver and some of those have a pin that must be pulled high or low to configure the transmission mode. For instance I'm using the SN65HVD230 and I specifically wired it to be in low power mode, which causes it to only to listen in on the bus. I hear the CANserver board is wired the same way.


good point. Yes, I'm using SN65HVD230 breakout board, with 10k to ground on Rs pin:
https://os.mbed.com/media/uploads/kaspars/sn65hvd230-can-module.png
But I desoldered 120 ohm termination resistor.
According to datasheet it is slope control. For stand-By/read only Rs should be pulled high.
I created another ESP32 with another SN65 breakout board -> it sends nothing (at least my car doesn't reacts to it).
I think, I will connect this two boards with each other (with termination resistor on both "sides") and create test can bus to see if I can send and receive messages...


----------



## JWardell

Do you have an oscilliscope that can prove if your circuit is transmitting, or at least a USB CAN dongle?
Be very careful with CAN transmits, Tesla has become a lot smarter and detects AND logs errors and unexpected transmissions.


----------



## Eugenius

thank you guys for you help! now it's working. But don't ask me what was wrong with it  (I think it was bad soldered 10k pull down resistor on SN65 board, because it also didn't work with two ESPs as "private can bus" on my work desk without a car...)

@JWardell , yes, I know about logging. But I do not send fake IDs or fake data. Actually only 0x1F9 with '00' as data at sleep.
But I have a next question  Is is it possible to change AC charging current via CAN? It's not possible via App, only Tesla-screen... 
I tried to change some bits ID333UI_chargeRequest on, but it doesn't work (or may be similar problem as before?)
ID333UI_chargeRequest changes if I change the current on tesla screen. So I tried to catch data (it comes alot of times/second), change bits to target current and resend it, but no result...)
This AC current change should not be "unexpected transmissions" also.


----------



## amund7

Has anyone found any signals regarding the octovalve and heat pump?


----------



## JWardell

amund7 said:


> Has anyone found any signals regarding the octovalve and heat pump?


The compressor is in ID227 or 2A8, that data was beefed up for heat pump compressor when the Y came out.
The Octovale and older 5-way valve are controlled by VCFront so if you search for coolantValve you will see signals for mode, valve angle, etc.


----------



## michi84

JWardell said:


> The compressor is in ID227 or 2A8, that data was beefed up for heat pump compressor when the Y came out.
> The Octovale and older 5-way valve are controlled by VCFront so if you search for coolantValve you will see signals for mode, valve angle, etc.


Do you have signal definitions for ID227? ID2A8 does not seem to do anything meaningful for Model 3 without heat pump, there is however ID281 (VCFRRONT_CMPREQUEST) from your DBC which shows compressor duty in % and compressor power limit in watts. You could caclulate compressor power by multiplying duty cycle with power, maximum is around 70% with a max power of 8191 W, so about almost 5,8 kW power. I dont know ift this is electrical/mechanical power or cooling power. I would need to cross reference this with evap power and battery power with as little other consumers as possible.


----------



## Eugenius

Does anybody knows if ID31CCC_chgStatus is still available on VehicleBus? 
I didn't received any messages on this ID while charging on AC charger... 
Or maybe it on ChargePortCanBus only? If so, than DBC file is wrong on GitHub :/

I need AC voltage and number of phases... this ID would be perfect...


----------



## jya

Apologies if this information has been provided before; I browsed this thread a bit without success.

Is there another place than the armrest access to plug an ODB2 adapter?
One that doesn't require you to cut wires obviously.

TIA


----------



## JWardell

Eugenius said:


> Does anybody knows if ID31CCC_chgStatus is still available on VehicleBus?
> I didn't received any messages on this ID while charging on AC charger...
> Or maybe it on ChargePortCanBus only? If so, than DBC file is wrong on GitHub :/
> 
> I need AC voltage and number of phases... this ID would be perfect...


I still see 31C on vehicle, hmm. Wonder if it's a europe thing.



jya said:


> Apologies if this information has been provided before; I browsed this thread a bit without success.
> 
> Is there another place than the armrest access to plug an ODB2 adapter?
> One that doesn't require you to cut wires obviously.
> 
> TIA


Well there is no where to access anything without "cutting" wires, but inline harnesses are readily available for the center console so you don't have to, and it's easy to access.
The next best spot is the connection to the computer where all busses come into one connector. That's where some of the displays connect. Still haven't found a harness for that though.
China-built cars apparently have an actual OBD port, but I have no idea what data is available there.


----------



## kornerz

JWardell said:


> I still see 31C on vehicle, hmm. Wonder if it's a europe thing.


I see ID31C on a EU vehicle as well, as of today.
Sample message (240V 32A single-phase plugged in):
can0 31C [8] 40 04 F0 78 FE FF 07 00


----------



## Eugenius

kornerz said:


> I see ID31C on a EU vehicle as well, as of today.
> Sample message (240V 32A single-phase plugged in):
> can0 31C [8] 40 04 F0 78 FE FF 07 00


Ok, thanks, then I will test it one more time. I had single phase 16A charger plugged in... I'm on 2020.48.26, I hope it doesn't matter.


----------



## kornerz

Eugenius said:


> Ok, thanks, then I will test it one more time. I had single phase 16A charger plugged in... I'm on 2020.48.26, I hope it doesn't matter.


One more idea: Do you use official Tesla Mobile Connector plugged into some wall socket, or something third-party?
My results are with Tesla UMC.
Also, you may check ID264 - it does not have phase count, but has input voltage, current and current limit.


----------



## Eugenius

kornerz said:


> One more idea: Do you use official Tesla Mobile Connector plugged into some wall socket, or something third-party?
> My results are with Tesla UMC.
> Also, you may check ID264 - it does not have phase count, but has input voltage, current and current limit.


good point. It was third party mobile adapter. I will check it with original UMC. But now CC_numVehCharging makes sense for me: load sharing between Tesla WallConectors...

ID264 should be enough for me. I can calculate phases from power, current and voltage  Somehow I didn't founded it yesterday...

Thank you!


----------



## onessela

Hi all, my 7" custom display project is doing well, now I would like to use brightness of main (15") display (in order to track it with my display's backlight) and I'd like to know when main display switches off (in order to shut off my Linux machine after a while). Any hint ? Thank you !


----------



## kornerz

onessela said:


> Hi all, my 7" custom display project is doing well, now I would like to use brightness of main (15") display (in order to track it with my display's backlight) and I'd like to know when main display switches off (in order to shut off my Linux machine after a while). Any hint ? Thank you !


I doubt main display brightness is present on Vehicle CAN bus.

As for "main display switches off" - I am using VCFRONT_driverPresent signal from "ID3A1VCFRONT_vehicleStatus" message to check for driver presence, which implies that main display is on (see https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L610 )


----------



## pyjamasam

onessela said:


> Hi all, my 7" custom display project is doing well, now I would like to use brightness of main (15") display (in order to track it with my display's backlight) and I'd like to know when main display switches off (in order to shut off my Linux machine after a while). Any hint ? Thank you !


On my Model 3, 0x273 on VEH seems to have UI_displayBrightnessLevel : 32|[email protected]+ (0.5,0) [0|127]
From some recent logs (well not that recent, back on Dec 23rd) I have data that looks like it could match up to that.









chris.


----------



## JWardell

Yes, it's all there. I use UI_displayOn in 0x353 to turn off my displays with the center display and that works well. I had always planned to use UI_displayBrightnessLevel to adjust brightness as well


----------



## Xxtreme

JWardell said:


> I added a new button...


how did you do it, is an ESP32 and a SN65HVD230 CAN bus transceiver enough? can you please tell me how to do this, I'm a beginner but learning fast.
Or maybe it works with your CANserver.


----------



## Xxtreme

JWardell said:


> __ https://twitter.com/i/web/status/1219440781750128641


that's exactly what I want to build, could you write me a little tutorial and the program, hardware and bottles are no problem for me. Or sell me a finished one?


----------



## onessela

JWardell said:


> Yes, it's all there. I use UI_displayOn in 0x353 to turn off my displays with the center display and that works well. I had always planned to use UI_displayBrightnessLevel to adjust brightness as well


Great news ! Right now I am using ID3A1VCFRONT_vehicleStatus, but I will switch immediately to 0x353. 
I enclose a photo of my finished prototype


----------



## JWardell

Xxtreme said:


> how did you do it, is an ESP32 and a SN65HVD230 CAN bus transceiver enough? can you please tell me how to do this, I'm a beginner but learning fast.
> Or maybe it works with your CANserver.


The original LED geek gauges were made with a Teensy and CAN wires strung all the way up to the breadboard, ready to fall out and short at any time!
I still intend to make/sell alphanumeric LED gagues which attach to my microdisplay to duplicate this...just never got around to making the large board needed to mount them above the display. Most because I haven't seen interest other than my own.
As for the traction disable button, when I first made it I thought it would very much make a good product. It's an arduino pro micro and a can board. Then dynomode leaked out a few weeks later and allowed anyone to do it. I later realized how completely deadly it can be as you lose traction and go for the crowds on the sidewalk very quickly, so will not release details on it. Frankly I think Tesla now has a lot more CAN monitoring in place and logs anything unexpected, so I would worry about it voiding warranty too.
I settled on my current ESP32-based CANserver because I can design it to be safe for the user, with hardware transmit disabled, and keeping everything close to the existing CAN wiring, sending data via wifi instead, not to mention the powerful capabilities of the processor at a reasonable price.


----------



## Xxtreme

JWardell said:


> The original LED geek gauges were made with a Teensy and CAN wires strung all the way up to the breadboard, ready to fall out and short at any time!
> I still intend to make/sell alphanumeric LED gagues which attach to my microdisplay to duplicate this...just never got around to making the large board needed to mount them above the display. Most because I haven't seen interest other than my own.
> As for the traction disable button, when I first made it I thought it would very much make a good product. It's an arduino pro micro and a can board. Then dynomode leaked out a few weeks later and allowed anyone to do it. I later realized how completely deadly it can be as you lose traction and go for the crowds on the sidewalk very quickly, so will not release details on it. Frankly I think Tesla now has a lot more CAN monitoring in place and logs anything unexpected, so I would worry about it voiding warranty too.
> I settled on my current ESP32-based CANserver because I can design it to be safe for the user, with hardware transmit disabled, and keeping everything close to the existing CAN wiring, sending data via wifi instead, not to mention the powerful capabilities of the processor at a reasonable price.


ok I can understand that, so with the CANserver I can also not execute commands like open door without pulling the lever? because he may not send anything?


----------



## kornerz

Xxtreme said:


> ok I can understand that, so with the CANserver I can also not execute commands like open door without pulling the lever? because he may not send anything?


Yes, it would be fairly easy to mess with the car that way - and nobody wants the users to blame him "your CANServer device damaged my car and it's not on warranty now"


----------



## Xxtreme

kornerz said:


> Yes, it would be fairly easy to mess with the car that way - and nobody wants the users to blame him "your CANServer device damaged my car and it's not on warranty now"


Well, if I install something like that, it's my own fault if something gets damaged. My decision, moreover, can also manipulate the firmware of me in the CANserver.


----------



## pyjamasam

Xxtreme said:


> Well, if I install something like that, it's my own fault if something gets damaged. My decision, moreover, can also manipulate the firmware of me in the CANserver.


Yes of course if you break your own car its your own problem... BUT we don't want there to be any reason that the CANServer breaks your car.

If you take it and modify it and do things we never intended with it there isn't much we can do to prevent that. But out of the box and used within the intended purpose the hope is that nothing bad happens. It is still a DIY device, and there are risks with connecting anything to your expensive toy. But we are trying to minimize those risks as much as possible for the vast majority of users who just want to get data and see it in TesLAX or SMT, or do some advanced logging and analysis as to how their car performs.

In the end we are trying to keep the CANServer "read-only" with respect to the car. It was @JWardell's original intention and I don't suspect we'll ever stray from that ideal.

chris.


----------



## JWardell

Xxtreme said:


> Well, if I install something like that, it's my own fault if something gets damaged. My decision, moreover, can also manipulate the firmware of me in the CANserver.


That sense of accountability you are fortunate to have is rare around here, if you haven't noticed.
It's a simple development platform though, folks with a little smarts can do whatever they want with it


----------



## kornerz

A general question. Who is using what signal to get "maximum available power" displayed?

Options which I've found so far:
- ID252 BMS_powerAvailable with BMS_maxDischargePower and BMS_maxRegenPower 
- ID268 SystemPower with DI_sysDrivePowerMax and DI_sysRegenPowerMax

I am using ID252, and looking at the sources of CANServer, @JWardell is also using that one.
However, recently with low-ish battery charge this signal displayed 148kW available power on my SR+, and I was able to get more than that (205kW, almost the maximum for SR+) power used.


----------



## jya

JWardell said:


> Well there is no where to access anything without "cutting" wires, but inline harnesses are readily available for the center console so you don't have to, and it's easy to access.
> The next best spot is the connection to the computer where all busses come into one connector. That's where some of the displays connect. Still haven't found a harness for that though.
> China-built cars apparently have an actual OBD port, but I have no idea what data is available there.


Thanks for your answer.

I had hoped to have the ODB2 adapter to be permanently installed and out of the way. In the centre console doesn't achieve that. My kids sitting at the back would always end up kicking it or play with it no doubt.


----------



## iChris93

jya said:


> In the centre console doesn't achieve that. My kids sitting at the back would always end up kicking it or play with it no doubt.


There's a little hole in there that you can actually fit a lot into. I have a CANServer and the adapter tucked into mine.


----------



## Xxtreme

JWardell said:


> That sense of accountability you are fortunate to have is rare around here, if you haven't noticed.
> It's a simple development platform though, folks with a little smarts can do whatever they want with it


very cool, can I use the CanServer for other things like the connection to "scan my Tesla".

Do you also ship to Germany?


----------



## JWardell

kornerz said:


> A general question. Who is using what signal to get "maximum available power" displayed?
> 
> Options which I've found so far:
> - ID252 BMS_powerAvailable with BMS_maxDischargePower and BMS_maxRegenPower
> - ID268 SystemPower with DI_sysDrivePowerMax and DI_sysRegenPowerMax
> 
> I am using ID252, and looking at the sources of CANServer, @JWardell is also using that one.
> However, recently with low-ish battery charge this signal displayed 148kW available power on my SR+, and I was able to get more than that (205kW, almost the maximum for SR+) power used.


It's a good question. Logically the BMS should be in control of that limit more so than the inverter. Really it would take some logging and detailed analysis of both in several situations. Although keep in mind power goes to more than just the drive inverter. So for example if you have zero regen from the BMS, but your heat is on, the inverter can regen the 7kW used by the heater.


----------



## kornerz

JWardell said:


> It's a good question. Logically the BMS should be in control of that limit more so than the inverter. Really it would take some logging and detailed analysis of both in several situations. Although keep in mind power goes to more than just the drive inverter. So for example if you have zero regen from the BMS, but your heat is on, the inverter can regen the 7kW used by the heater.


Thanks for the suggestion. So I've added both values to my dashboard (BMS | SYS) and will check how they behave.
So far ID268 limit (SYS) looks closer to what I need.


----------



## dimitar.ns

Hello guys, do you know how this "Mikey Mouse display" is able to detect the Steering Wheel buttons? I looked at all 3 CAN buses but I was not able to find out the ID which sends the buttons. I'm interested also in the Left side ones (media buttons) so any hint will be very helpful.


----------



## JWardell

dimitar.ns said:


> Hello guys, do you know how this "Mikey Mouse display" is able to detect the Steering Wheel buttons? I looked at all 3 CAN buses but I was not able to find out the ID which sends the buttons. I'm interested also in the Left side ones (media buttons) so any hint will be very helpful.


ID 3C2 from VCleft has the wheel buttons in it...

SG_ VCLEFT_swcLeftDoublePress m1 : 41|[email protected]+ (1,0) [0|1] "" Receiver
SG_ VCLEFT_swcLeftPressed m1 : 5|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCLEFT_swcLeftScrollTicks m1 : 16|[email protected] (1,0) [-32|31] "" Receiver
SG_ VCLEFT_swcLeftTiltLeft m1 : 14|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCLEFT_swcLeftTiltRight m1 : 3|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCLEFT_swcRightDoublePress m1 : 42|[email protected]+ (1,0) [0|1] "" Receiver
SG_ VCLEFT_swcRightPressed m1 : 12|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCLEFT_swcRightScrollTicks m1 : 24|[email protected] (1,0) [-32|31] "" Receiver
SG_ VCLEFT_swcRightTiltLeft m1 : 8|[email protected]+ (1,0) [0|3] "" Receiver
SG_ VCLEFT_swcRightTiltRight m1 : 10|[email protected]+ (1,0) [0|3] "" Receiver


----------



## Krishell

Is there a list with LIN ID etc? From different units?


----------



## fw19876311

Hello guys, do you know which ID is the seat belt working on? I looked for a socket in the middle of the host with three sets of CAN and didn't find any useful information，can you help me?thanks...


----------



## JWardell

Krishell said:


> Is there a list with LIN ID etc? From different units?


You would need LDF files that describe the communications of each component. And it's usually point to point, so only useful if you were accessing the part directly. What are you trying to do?



fw19876311 said:


> Hello guys, do you know which ID is the seat belt working on? I looked for a socket in the middle of the host with three sets of CAN and didn't find any useful information，can you help me?thanks...
> View attachment 36845


Not sure what the picture is of...doesn't seem to be seat belt? There a number of components to the restraint system.


----------



## TeslaM3Tweaker

Hi all, I am new to this Forum so I apologize if this isn't the right way to ask a question. I have a Tesla Model 3 (manufactured in September 2020) and I am trying to learn about CAN. I used the database file mentioned in this forum (which was last updated 6 months ago, before my car was manufactured) along with a Vector CANalyzer (VN1630A) to look at the signals. When I connect the CANalyzer to the CAN bus and attach this dbc file to it, I see many signals (like doors, steering angle, Charging status, etc.) but I am not able to get the message for Speed, RPM, Gear, Torque, etc. from the file. I have confirmed using a ODB II reader and an EVTV OBD II adapter that the CAN bus I am tapping on has the speed and RPM signals on it. My speculation is that even though the database file is relatively new, I think that it might need an update? What do you guys think? Does any of you was able to read speed, RPM using the dbc file? If yes then I would be glad if you could help me out here. 

Thanks in advance


----------



## kornerz

TeslaM3Tweaker said:


> Hi all, I am new to this Forum so I apologize if this isn't the right way to ask a question. I have a Tesla Model 3 (manufactured in September 2020) and I am trying to learn about CAN. I used the database file mentioned in this forum (which was last updated 6 months ago, before my car was manufactured) along with a Vector CANalyzer (VN1630A) to look at the signals. When I connect the CANalyzer to the CAN bus and attach this dbc file to it, I see many signals (like doors, steering angle, Charging status, etc.) but I am not able to get the message for Speed, RPM, Gear, Torque, etc. from the file. I have confirmed using a ODB II reader and an EVTV OBD II adapter that the CAN bus I am tapping on has the speed and RPM signals on it. My speculation is that even though the database file is relatively new, I think that it might need an update? What do you guys think? Does any of you was able to read speed, RPM using the dbc file? If yes then I would be glad if you could help me out here.
> 
> Thanks in advance


There is more than one CAN bus in a Model 3 with different set of signals on each, where are you connecting to?


----------



## JWardell

TeslaM3Tweaker said:


> Hi all, I am new to this Forum so I apologize if this isn't the right way to ask a question. I have a Tesla Model 3 (manufactured in September 2020) and I am trying to learn about CAN. I used the database file mentioned in this forum (which was last updated 6 months ago, before my car was manufactured) along with a Vector CANalyzer (VN1630A) to look at the signals. When I connect the CANalyzer to the CAN bus and attach this dbc file to it, I see many signals (like doors, steering angle, Charging status, etc.) but I am not able to get the message for Speed, RPM, Gear, Torque, etc. from the file. I have confirmed using a ODB II reader and an EVTV OBD II adapter that the CAN bus I am tapping on has the speed and RPM signals on it. My speculation is that even though the database file is relatively new, I think that it might need an update? What do you guys think? Does any of you was able to read speed, RPM using the dbc file? If yes then I would be glad if you could help me out here.
> 
> Thanks in advance


Yes, I am overdue to update it but have have been short on time lately. However Speed, RPM, Gear, and Torque haven't changed in a while, they should all work. You might not be looking at the right signals, or maybe you aren't plugged into the powertrain can bus. 
Where are you plugging in? Share a screenshot or two from Vector and I can see if I can figure out what's missing.
For example, you should be viewing the DI_uiSpeed signal.


----------



## All About Jake

Hi folks. I just released tesLAX v1.5 to the AppStore with many improvements and support for (some?) WiFi based OBD-2 dongles. I use the "vLinker MC WiFi" as it supports the ST-command set with filtering to prevent too much data from flooding the line. It should also work with WiFi-based ELM327 dongles, but the performance is terrible and you'll see lots of buffer overruns and dropped packets. -- good enough for casual viewing. (I've tested the "vGate iCar Pro" in this regard) Anything that supports AT- or ST- over a TCP connection should work

Since I can't test with every possible WiFi dongle on the market, let me know how it works for you. Send me a DM or find me on Discord.

This version has support for the new protocol extensions used by Josh's CANServer which now supports filtering.

Also I'm planning support for BLE-based dongles in a future update. If you have one of those, and are interested in beta testing, also reach out. (Note iOS only supports "Classic" bluetooth for certified accessories, meaning, the OBDLink MX+ is the only game in town. However, for "Bluetooth Low Energy" there is more freedom and more options. tesLAX will continue to only support the MX+ for traditional bluetooth, but in the next update hopes to work with "BLE" or "4.0" compatible dognles.... however I expect the performance to be poorer as the low-energy nature of BLE means its not good for high bandwidth stuff.)


----------



## TeslaM3Tweaker

kornerz said:


> There is more than one CAN bus in a Model 3 with different set of signals on each, where are you connecting to?


@kornerz, thanks for the reply. Yes, you are right there are multiple CAN buses (4 in total) where we have the data. I have a Bluetooth OBDLink adapter using which I was able t verify that the CAN bus I have tapped into has the Speed and RPM signals.


----------



## TeslaM3Tweaker

JWardell said:


> Yes, I am overdue to update it but have have been short on time lately. However Speed, RPM, Gear, and Torque haven't changed in a while, they should all work. You might not be looking at the right signals, or maybe you aren't plugged into the powertrain can bus.
> Where are you plugging in? Share a screenshot or two from Vector and I can see if I can figure out what's missing.
> For example, you should be viewing the DI_uiSpeed signal.


@JWardell, thanks for the reply. I can confirm that I am on the right bus. For speed, I am looking for 'ID3D9UI_gpsVehicleSpeed' signal. 'DI-uiSpeed' is not in the dbc file. And I apologize, right not I don't have the car with me so I won't be able to get the screenshots. But if there is anything you want me to elaborate on, I can do that.

Thanks again for your reply guys, I really appreciate it.


----------



## JWardell

TeslaM3Tweaker said:


> @JWardell, thanks for the reply. I can confirm that I am on the right bus. For speed, I am looking for 'ID3D9UI_gpsVehicleSpeed' signal. 'DI-uiSpeed' is not in the dbc file. And I apologize, right not I don't have the car with me so I won't be able to get the screenshots. But if there is anything you want me to elaborate on, I can do that.
> 
> Thanks again for your reply guys, I really appreciate it.


You are looking for the UIspeed signals in 0x257 message. GPS speed is not always present.


----------



## TeslaM3Tweaker

JWardell said:


> You are looking for the UIspeed signals in 0x257 message. GPS speed is not always present.


Hmm I see, I think I couldn't get even that. But I will have to check. Is there any message that you will recommend for RPM (ID186DIF_torque, ID108DIR_torque), Gear (ID118DriveSystemStatus), Torque (ID186DIF_torque, ID108DIR_torque), and Accelerator Pedal Position (ID118DriveSystemStatus)? Messages in the parentheses are the ones I am looking for but couldn't find.


----------



## pyjamasam

TeslaM3Tweaker said:


> Hmm I see, I think I couldn't get even that. But I will have to check. Is there any message that you will recommend for RPM (ID186DIF_torque, ID108DIR_torque), Gear (ID118DriveSystemStatus), Torque (ID186DIF_torque, ID108DIR_torque), and Accelerator Pedal Position (ID118DriveSystemStatus)? Messages in the parentheses are the ones I am looking for but couldn't find.


In a recent log file from my model 3 I see 0x186 on both chassis and vehicle busses, as well 0x108 and 0x118 are also on both busses. 0x257 is also on both busses.

chris.


----------



## JWardell

TeslaM3Tweaker said:


> Hmm I see, I think I couldn't get even that. But I will have to check. Is there any message that you will recommend for RPM (ID186DIF_torque, ID108DIR_torque), Gear (ID118DriveSystemStatus), Torque (ID186DIF_torque, ID108DIR_torque), and Accelerator Pedal Position (ID118DriveSystemStatus)? Messages in the parentheses are the ones I am looking for but couldn't find.


Yeah something is wierd as you are looking for fairly common and well established messages. How and where are you connecting?


----------



## TeslaM3Tweaker

JWardell said:


> Yeah something is wierd as you are looking for fairly common and well established messages. How and where are you connecting?


I directly connect to the CAN bus (under the rear of the center console) then use a db9 connector cable to connect it with my Vector CANalyzer hardware. I also have an EVTV OBD II adapter which I have connected to the CAN bus. I used the OBD II outlet of the EVTV adapter to put my third-party Bluetooth dongle which reads RPM, Speed, etc. to confirm that the signal is on that bus.


----------



## TeslaM3Tweaker

pyjamasam said:


> In a recent log file from my model 3 I see 0x186 on both chassis and vehicle busses, as well 0x108 and 0x118 are also on both busses. 0x257 is also on both busses.
> 
> chris.


Hi Chris, thanks for the reply. How old is your Model 3 if I may ask. I looked for 0x118, 0x108, and 0x186 but could not find them. I will check again today, but it is doubtful that I missed all 3 of them.


----------



## Madmolecule

while using the canserver I have had to choose buss 1, (instead of any buss) for speedlimit and other signals to get them to function properly. (otherwise they were flashing on the screen). I don't know if these signal are on both busses also. I have an older 88K VIN 3 with upgraded computer


----------



## pyjamasam

TeslaM3Tweaker said:


> Hi Chris, thanks for the reply. How old is your Model 3 if I may ask. I looked for 0x118, 0x108, and 0x186 but could not find them. I will check again today, but it is doubtful that I missed all 3 of them.


Hmm.. My 3 is from March 2020, and running 2020.48.35.5. 0x118 is a fairly important message based on its contents. Something seems really strange if it is missing.

chris.


----------



## JWardell

TeslaM3Tweaker said:


> I directly connect to the CAN bus (under the rear of the center console) then use a db9 connector cable to connect it with my Vector CANalyzer hardware. I also have an EVTV OBD II adapter which I have connected to the CAN bus. I used the OBD II outlet of the EVTV adapter to put my third-party Bluetooth dongle which reads RPM, Speed, etc. to confirm that the signal is on that bus.


The EVTV adapter has two separate busses, so it echos some limited data to the OBD bus, which may be the issue.
Vector directly into the rear console can will definitely work, that's how I got my data for the first year.
Can you take a quick log, or look at a trace to see if the data is actually there?


----------



## FrenchieEAP

Sorry if this is a bit off topic but I'm part of the FSD Beta testers and I'm trying to see if there is an "easy" way to record the car screen on a Model 3. I'm not a tech guy so not sure if it would require to mirror the screen or other solution. Thanks!


----------



## JWardell

FrenchieEAP said:


> Sorry if this is a bit off topic but I'm part of the FSD Beta testers and I'm trying to see if there is an "easy" way to record the car screen on a Model 3. I'm not a tech guy so not sure if it would require to mirror the screen or other solution. Thanks!


None that I know of. Only folks who have hacked and rooted their whole system, and managed to install a VNC server.


----------



## phil_ger

Hi folks, I'm sorry that I just ask here, but I haven't found a more suitable thread. My father's 2021 Model 3 was delivered today and we wanted to read out the battery stats. I bent a PIN with the obd adapter cable (https://www.gpstrackingamerica.com/shop/hrn-ct20t11/) and now I can no longer get the vehicle connector on it. Does anyone have any advice on how I can best get the pin straight back without breaking it completely? The vehicle is currently not lockable! Thank you for every tip on the name of the connector to check whether I can pull out the defective pin individually, for example.





















Thank you!!!
Regards Phil


----------



## JWardell

phil_ger said:


> Hi folks, I'm sorry that I just ask here, but I haven't found a more suitable thread. My father's 2021 Model 3 was delivered today and we wanted to read out the battery stats. I bent a PIN with the obd adapter cable (https://www.gpstrackingamerica.com/shop/hrn-ct20t11/) and now I can no longer get the vehicle connector on it. Does anyone have any advice on how I can best get the pin straight back without breaking it completely? The vehicle is currently not lockable! Thank you for every tip on the name of the connector to check whether I can pull out the defective pin individually, for example.
> 
> View attachment 37114
> View attachment 37115
> View attachment 37113
> 
> 
> Thank you!!!
> Regards Phil


Looks like you should be able to squeeze and straighten it with some needle nose pliars?


----------



## phil_ger

Hi Josh, thanks for your reply!
Just want to give you an update and hope I can finally fix it this evening. I hope it wouldnt break 
I only managed removing the connector from the center console in my lunch break... that was challenging!
This evening I try to bend back the pin. wasnt able to that with a small pointed tweezers. maybe with a piece of the blade of a cutter knife, then with a needle nose pliar as you recommended.
Please let me know if thats out of the threads scope. Otherwise the pics possibly helps others.





















Regards, Phil


----------



## Mike

phil_ger said:


> Hi Josh, thanks for your reply!
> Just want to give you an update and hope I can finally fix it this evening. I hope it wouldnt break
> I only managed removing the connector from the center console in my lunch break... that was challenging!
> This evening I try to bend back the pin. wasnt able to that with a small pointed tweezers. maybe with a piece of the blade of a cutter knife, then with a needle nose pliar as you recommended.
> Please let me know if thats out of the threads scope. Otherwise the pics possibly helps others.
> 
> View attachment 37120
> View attachment 37121
> View attachment 37122
> 
> 
> Regards, Phil


I am not familiar with the specifics of repairing these Tesla connectors.

However, my experience with Ford connectors from the 1970s and 1980s as well as Toyota from the 2000s tells me there must be a release tang that will allow one to remove an individual male ended wire from that connector (i.e. release the locking tang from the wire input side, then pull the wire (and it's male end) out from the backside of the connector).


----------



## JWardell

phil_ger said:


> Hi Josh, thanks for your reply!
> Just want to give you an update and hope I can finally fix it this evening. I hope it wouldnt break
> I only managed removing the connector from the center console in my lunch break... that was challenging!
> This evening I try to bend back the pin. wasnt able to that with a small pointed tweezers. maybe with a piece of the blade of a cutter knife, then with a needle nose pliar as you recommended.
> Please let me know if thats out of the threads scope. Otherwise the pics possibly helps others.
> 
> View attachment 37120
> View attachment 37121
> View attachment 37122
> 
> 
> Regards, Phil


We spent a good deal of time early on in this thread discussing these connectors and how to tap into them.
Actually I am looking closely at the wiring I have on the 26 pin connector sheet of my spreadsheet... it looks to me like that bent pin should be unused, but strangely the pin next to it hat you have missing should be used. I'm surprised to see so many pins missing in your connector, all the connectors I see have all pins and pas through all signals.

Still it looks like you should be able to get in there and straighten it. If not I have links to some other sources


----------



## phil_ger

Mike said:


> I am not familiar with the specifics of repairing these Tesla connectors.
> 
> However, my experience with Ford connectors from the 1970s and 1980s as well as Toyota from the 2000s tells me there must be a release tang that will allow one to remove an individual male ended wire from that connector (i.e. release the locking tang from the wire input side, then pull the wire (and it's male end) out from the backside of the connector).


Thank you!
Already tried with the obd adapter cable. same connectors but I wasnt able to pull those wires out because I have no tool fine enough to stick into the connector to release the pin. I saw several videos how to do that (like you described) but it seems to need a hard jerk to pull them out even with the right tool.

http://prd.sws.co.jp/components/en/detail.php?number_s=60985613http://prd.sws.co.jp/components/en/detail.php?number_s=81003622
Nevertheless many thanks!



JWardell said:


> We spent a good deal of time early on in this thread discussing these connectors and how to tap into them.
> Actually I am looking closely at the wiring I have on the 26 pin connector sheet of my spreadsheet... it looks to me like that bent pin should be unused, but strangely the pin next to it hat you have missing should be used. I'm surprised to see so many pins missing in your connector, all the connectors I see have all pins and pas through all signals.
> 
> Still it looks like you should be able to get in there and straighten it. If not I have links to some other sources


Thanks again!
A friend of mine received a Model 3 perf. just a week before us.
He made a picture for me and it looks like the same:









good news!
looks not perfect but I wanted to bent just as much as I should...
I checked the other side of the obd adapter cable and I have contact between the two pins with the adapter cable in between.
My thoughts was better the adapter cable instead of the other side (car) damaged if something goes wrong with the pin...
thanks for participation


----------



## kornerz

Does anyone know the updated definition of ID3F2, BMSCounters?
I've noticed that on recent firmware the index (BMSCountersIndex3F2) is now 4-bit wide instead of 3, and overall there are 12 values in this message instead of 4 described in the DBC here: https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L2898

Values sample:



Code:


 (1613970959.816149)  can0  3F2   [8]  00 8A 42 40 00 00 00 00 ::
ID3F2BMSCounters(
    BMSCountersIndex3F2: 0,
    BMStotalACcharge3F2: 4211.338 KWh
)
(1613970960.816584)  can0  3F2   [8]  01 0D D0 01 00 00 00 00 ::
ID3F2BMSCounters(
    BMSCountersIndex3F2: 1,
    BMStotalDCcharge3F2: 118.797 KWh
)
(1613970961.816518)  can0  3F2   [8]  02 54 B0 12 00 00 00 00 ::
ID3F2BMSCounters(
    BMSCountersIndex3F2: 2,
    BMStotalRegenCharge3F2: 1224.788 KWh
)
(1613970962.816044)  can0  3F2   [8]  03 36 61 40 00 00 00 00 ::
ID3F2BMSCounters(
    BMSCountersIndex3F2: 3,
    BMStotalDriveDischarge3F2: 4219.19 KWh
)
(1613970963.815376)  can0  3F2   [8]  04 DA 87 14 D0 11 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 4
(1613970964.816724)  can0  3F2   [8]  05 F4 10 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 5
(1613970965.814835)  can0  3F2   [8]  06 C7 87 14 20 18 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 6
(1613970966.814765)  can0  3F2   [8]  07 47 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 7
(1613970967.814462)  can0  3F2   [8]  08 F5 87 14 90 15 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 8
(1613970968.814413)  can0  3F2   [8]  09 26 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 9
(1613970969.814359)  can0  3F2   [8]  0A D7 87 14 10 16 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 10
(1613970970.814391)  can0  3F2   [8]  0B 2C 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 11


----------



## JWardell

kornerz said:


> Does anyone know the updated definition of ID3F2, BMSCounters?
> I've noticed that on recent firmware the index (BMSCountersIndex3F2) is now 4-bit wide instead of 3, and overall there are 12 values in this message instead of 4 described in the DBC here: https://github.com/joshwardell/model3dbc/blob/master/Model3CAN.dbc#L2898
> 
> Values sample:
> 
> 
> 
> Code:
> 
> 
> (1613970959.816149)  can0  3F2   [8]  00 8A 42 40 00 00 00 00 ::
> ID3F2BMSCounters(
> BMSCountersIndex3F2: 0,
> BMStotalACcharge3F2: 4211.338 KWh
> )
> (1613970960.816584)  can0  3F2   [8]  01 0D D0 01 00 00 00 00 ::
> ID3F2BMSCounters(
> BMSCountersIndex3F2: 1,
> BMStotalDCcharge3F2: 118.797 KWh
> )
> (1613970961.816518)  can0  3F2   [8]  02 54 B0 12 00 00 00 00 ::
> ID3F2BMSCounters(
> BMSCountersIndex3F2: 2,
> BMStotalRegenCharge3F2: 1224.788 KWh
> )
> (1613970962.816044)  can0  3F2   [8]  03 36 61 40 00 00 00 00 ::
> ID3F2BMSCounters(
> BMSCountersIndex3F2: 3,
> BMStotalDriveDischarge3F2: 4219.19 KWh
> )
> (1613970963.815376)  can0  3F2   [8]  04 DA 87 14 D0 11 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 4
> (1613970964.816724)  can0  3F2   [8]  05 F4 10 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 5
> (1613970965.814835)  can0  3F2   [8]  06 C7 87 14 20 18 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 6
> (1613970966.814765)  can0  3F2   [8]  07 47 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 7
> (1613970967.814462)  can0  3F2   [8]  08 F5 87 14 90 15 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 8
> (1613970968.814413)  can0  3F2   [8]  09 26 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 9
> (1613970969.814359)  can0  3F2   [8]  0A D7 87 14 10 16 53 01 :: expected multiplexer id 0, 1, 2 or 3, but got 10
> (1613970970.814391)  can0  3F2   [8]  0B 2C 11 10 30 40 07 00 :: expected multiplexer id 0, 1, 2 or 3, but got 11


Not sure this is entirely up to date:

BO_ 1010 ID3F2BMSCounters: 8 VehicleBus
SG_ BMS_kwhCounter_Id M : 0|[email protected]+ (1,0) [0|0] "" Receiver
SG_ BMS_kwhDcChargeTotalModule3 m9 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhChargeTotalModule2 m6 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDcChargeTotalModule2 m7 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhChargeTotalModule4 m10 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDcChargeTotalModule4 m11 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDcChargeTotalModule1 m5 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhChargeTotalModule1 m4 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhChargeTotalModule3 m8 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhAcChargeTotalModule3 m9 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDischargeTotalModule2 m6 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhAcChargeTotalModule2 m7 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDischargeTotalModule4 m10 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhAcChargeTotalModule4 m11 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhAcChargeTotalModule1 m5 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDriveDischargeTotal m3 : 8|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_dcChargerKwhTotal m1 : 8|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDischargeTotalModule1 m4 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_acChargerKwhTotal m0 : 8|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhRegenChargeTotal m2 : 8|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
SG_ BMS_kwhDischargeTotalModule3 m8 : 8|[email protected] (0.001,0) [0|0] "KWh" Receiver


----------



## kornerz

JWardell said:


> Not sure this is entirely up to date:
> 
> BO_ 1010 ID3F2BMSCounters: 8 VehicleBus
> SG_ BMS_kwhCounter_Id M : 0|[email protected]+ (1,0) [0|0] "" Receiver
> SG_ BMS_kwhDcChargeTotalModule3 m9 : 36|[email protected]+ (0.001,0) [0|0] "KWh" Receiver
> ...


Thanks, looks up to date for me at 48.3.5

Edit: that split of charge stats into 4 module details look like a preparation for the Semi, where 4 modules are charged separately and it will make sense to track each


----------



## JWardell

kornerz said:


> Thanks, looks up to date for me at 48.3.5
> 
> Edit: that split of charge stats into 4 module details look like a preparation for the Semi, where 4 modules are charged separately and it will make sense to track each


Oh, good point. And two for the roadster perhaps. They should send me one for development purposes  Maybe we can use Trev's extra...


----------



## kornerz

JWardell said:


> Oh, good point. And two for the roadster perhaps. They should send me one for development purposes  Maybe we can use Trev's extra...


"Anyone has CAN message IDs for cold gas thrusters?"


----------



## Madmolecule

I’ll bit off topic as usual but has anyone tried to split the display cable to run two displays? I don’t really see any safety concerns as it would be impossible to enter something on both screens simultaneously. Karaoke would be a lot better with the rear display.


----------



## Madmolecule

I have added a second instrument cluster display. The set up is done by using various different finger combinations on the main display. Is this finger information available on the can server? It could be usefull to change display modes on the micro display

example from the setup

2 UI styles. Hold down the central touchscreen with four fingers to change the display from current style to another style.
Hold down the central touchscreen with five fingers to reset the trip.
Instead of total estimated driving distance available, you can hold down the central touchscreen with six fingers to display the percentage of battery energy remaining.
Hold down the central touchscreen with seven fingers to change the language. (English or Simplified Chinese)
Brightness sync with the central touchscreen


----------



## pyjamasam

Madmolecule said:


> I have added a second instrument cluster display. The set up is done by using various different finger combinations on the main display. Is this finger information available on the can server? It could be usefull to change display modes on the micro display
> 
> example from the setup
> 
> 2 UI styles. Hold down the central touchscreen with four fingers to change the display from current style to another style.
> Hold down the central touchscreen with five fingers to reset the trip.
> Instead of total estimated driving distance available, you can hold down the central touchscreen with six fingers to display the percentage of battery energy remaining.
> Hold down the central touchscreen with seven fingers to change the language. (English or Simplified Chinese)
> Brightness sync with the central touchscreen


UI_FalseTouchCounter in ID00CUI_status is the touch count. Combine that with some timers and you should be able to mimic the behaviour you specified.

UI_displayBrightnessLevel in ID273UI_vehicleControl would be the brightness level of the display.

chris.


----------



## Madmolecule

Created a quick bezel for the micro displays and they mount pretty nice on the base of my Chinese display. I have not been able to find some right angle power connectors that would work properly and be more discrete. It still looks pretty good. Once I added the swivel to the screen it lowered it, so it made more sense to move in on top of the main display. I like the look there also.


----------



## dimitar.ns

Hello guys, do you know if the trip data is calculated in the UI or it's somewhere in the CAN messages? (info like distance, time and consumption since X and since last charge)

And is anybody interested in a cable with all 3 CAN buses from the MCU for example on 3 DB9 connectors? We can produce and distribute such cables if there is demand, just let me know. DB9 can be also some other type of connector if it makes sense.


----------



## JWardell

dimitar.ns said:


> Hello guys, do you know if the trip data is calculated in the UI or it's somewhere in the CAN messages? (info like distance, time and consumption since X and since last charge)
> 
> And is anybody interested in a cable with all 3 CAN buses from the MCU for example on 3 DB9 connectors? We can produce and distribute such cables if there is demand, just let me know. DB9 can be also some other type of connector if it makes sense.


A single plug and play harness would be great. But my problem is, harnesses are laborious and expensive, and require a significant upfront investment, especially for the unusual connectors that tesla uses. And then it all goes out the window when Tesla choses to change the connector. As it is there are two different diagnostic connectors for S&X, and two different rear console connectors for 3&Y. So as much as I hate the giant OBDII connector, that's the one standard that harnesses are already available and made for off the shelf.

The other standard is DB9, which is standard for CAN prototyping but never production given that it is bulky and in no way secure.

My CANserver does support the standard Vector 2-bus DB9 connector. So if you were to make a harness that plugs powertrain and chassis into that one DB9, it would plug and play. That certainly would be nice.


----------



## All About Jake

For those interested, I just released "tes•LAX v1.6" with some slightly revised branding. Of specific interest, support for BLE OBD-2 dongles like the OBDLink CX, and vLinker MC+, etc.

It should work with most serial ELM237 dongles over BLE... but BLE has a system of service UUIDs and characteristic UUIDs and I might not have every obscure dongle accounted for. Advanced users can add their own BLE ID's in the settings if they have something that doesn't work out of the box.

I have to say I'm impressed with the OBDLink CX, as it has good performance at its price point. The vLinker MC+ with BLE is nice too because it also has the ST-command set. But with all of these BLE dongles, keep in mind a malicious user can connect to an unpaired dongle... a pretty big security problem. (Some WiFi dongles also have this problem if they cannot be secured with a password)

Also there's a Mazda 3 profile in there from @pyjamasam, showing how you can configure tes•LAX for any vehicle with a CAN bus. If you create anything neat for another vehicle (using public-domain information), let me know and maybe I can include it in the default library of presets.


----------



## All About Jake

All About Jake said:


> For those interested, I just released "tes•LAX v1.6" with some slightly revised branding. Of specific interest, support for BLE OBD-2 dongles like the OBDLink CX, and vLinker MC+, etc.


Sad to report there is a minor bug in tesLAX 1.6 that prevents the "Extra Strength" unlock from working properly for some users. I've submitted a fix to Apple and are waiting for them to approve. I apologize for the interruption in features for some users.


----------



## kornerz

Looks like in 2021.4.11 they've updated (or moved somewhere) ID261, 12v battery status.
Now it has a multiplexer and consists of 3 messages:


Code:


  can0  261   [8]  00 10 FE 00 99 40 50 F8
  can0  261   [8]  31 48 02 01 A4 4A 62 8D
  can0  261   [8]  F6 FE 4F 04 46 42 70 00
  can0  261   [8]  00 10 FE 00 99 40 80 28
  can0  261   [8]  31 48 0D 01 A4 4A 92 C8
  can0  261   [8]  F6 FE 4F 04 46 42 A0 30
  can0  261   [8]  00 10 FE 00 99 40 B0 58
  can0  261   [8]  31 48 0D 01 A4 4A C2 F8
  can0  261   [8]  F6 FE 4F 04 46 42 D0 60
  can0  261   [8]  00 10 FE 00 99 40 E0 88
  can0  261   [8]  31 48 CC 00 9F 4A F2 E1
  can0  261   [8]  F6 FE 4F 04 46 42 00 90


----------



## tyuo9980

Does anyone know if you can write to the canbus with the obdlink mx+?


----------



## JWardell

tyuo9980 said:


> Does anyone know if you can write to the canbus with the obdlink mx+?


Yes you can, with the right commands. I wouldn't recommend it, because your Tesla will most likely detect the unexpected data.


----------



## jj92

Hello all,

I am still quite new here and have but directly a question regarding a Model Y.
I'm looking for some info on where to find the can bus in the Model Y. 
I have already notebook with can interface to record what is on the bus.

Would be great if someone knows, maybe even with a photo or where I can get more info.

Greetings


----------



## JWardell

jj92 said:


> Hello all,
> 
> I am still quite new here and have but directly a question regarding a Model Y.
> I'm looking for some info on where to find the can bus in the Model Y.
> I have already notebook with can interface to record what is on the bus.
> 
> Would be great if someone knows, maybe even with a photo or where I can get more info.
> 
> Greetings


(Are there Model Ys in Germany??)
The Y is the same and the 3, so the best place to access CAN is in the back of the center console, with an OBD harness.


----------



## jj92

JWardell said:


> (Are there Model Ys in Germany??)
> The Y is the same and the 3, so the best place to access CAN is in the back of the center console, with an OBD harness.


No, but I have access to a us version of model y.
Have you ever tried to connect directly to the wire of the can?


----------



## likandoo

Hello,

I am hoping to get help on this Forum I am trying to get the OBDLink MX+ to work in my Model 3 connected to a MacBook Pro.
I bought the OBDLink MX+ because everyone said its the best with the best compatibility. But now I found out that apparently it does not officially support MacOS is that right?

Because I have the problem that I cannot get it connected to my Macbook via Bluetooth.

The Dongle is connected and has Power and also shows up in MacOS with the right name. When I click connect it takes 2 seconds and then it says "Connected" however on the Dongle the Bluetooth indication LED is still flashing blue instead of constant blue. And after about 5-10 seconds it says disconnected again in the MacOS Bluetooth Panel.

What am I doing wrong as it connects flawlessly on my iPhone and also on a Android Device.

But I need it to connect to MacOS Bluetooth as it is my development environment there.

I hope someone ran into the same problem here and found a solution.

(btw tried it on two different MacBooks with Catalina and BigSur)


----------



## likandoo

Is there someone with Javascript and OBD Knowledge that could help out?

This is a Node.js app that reads from the OBDLINK Mx+
https://github.com/ProtoPie/protopie-connect-bridge-apps/tree/master/node-bridge-obd

This script is written for normal OBD Ports from combustion engines cars.

Could someone help out how this Script would have to be changed to work with the Tesla OBD / Can Format?

I would guess the answer lies in the obd-pids.json file and in the index.js where it filters for the PIDS right?

Edit:

Here are some first pictures, I want to create a Instrument Cluster that fits from proportions and design to the Model 3 Head Unit design.
Also the plan is different Version (Like super NERD Mode with all data / super simple mode) etc.

But for this I need the help with the Javascript up there.


----------



## onessela

Hi, I am trying to get left/right steering wheel knobs (swc) data. Infos should be in 0x3C2 VCLEFT, "swcLeftTiltLeft", "swcLeftTiltRight", and so on. They are multiplexed so I checked also SwitchStatusIndex (Multiplexor), but data is inconsistent and wrong. I am using file 072020. Perhaps some update available ? Thanks


----------



## kornerz

onessela said:


> Hi, I am trying to get left/right steering wheel knobs (swc) data. Infos should be in 0x3C2 VCLEFT, "swcLeftTiltLeft", "swcLeftTiltRight", and so on. They are multiplexed so I checked also SwitchStatusIndex (Multiplexor), but data is inconsistent and wrong. I am using file 072020. Perhaps some update available ? Thanks


0x3C2 data looks pretty much the same for me in 2021.4.18 as in some of older dumps I have from mid-2020.
Don't have a sample with wheel knobs tilted, but here is "idle state":


> (1621489580.181087) can0 3C2 [8] 29 55 00 00 00 00 00 00
> (1621489580.231342) can0 3C2 [8] 00 55 55 55 00 00 55 05
> (1621489580.281074) can0 3C2 [8] 29 55 00 00 00 00 00 00
> (1621489580.331900) can0 3C2 [8] 00 55 55 55 00 00 55 05
> (1621489580.430847) can0 3C2 [8] 00 55 55 55 00 00 55 05
> (1621489580.481465) can0 3C2 [8] 29 55 00 00 00 00 00 00


----------



## onessela

Thanks for helping. I check data when Multiplexor (data[0], bit [0-1]) is 1 (all messaged ending with 05). In these messages


kornerz said:


> 0x3C2 data looks pretty much the same for me in 2021.4.18 as in some of older dumps I have from mid-2020.
> Don't have a sample with wheel knobs tilted, but here is "idle state":


OK thank you now tilt wheels seem to work, now I'll try to get wheel ticks. Thank you again


----------



## onessela

My custom display shows instantaneous car power as sum of 
0x2E5: Front Power kW signed 11-bit SB 0, scale 0.5 and 
0x266: Rear Power kW signed 11-bit SB 0, scale 0.5

When power is low ([email protected]) data is correct and matches with power level shown on display.
When I make a drag race, this sum never exceeds 160kW but real power is surely greater (ScanMyTesla goes up to 300kW and also graph on display).

Is there some other component that needs do be added to (Front Power kW + Rear Power kW) ?


----------



## JWardell

Usually we read power from the BMS 0x132 by multiplying voltage and current. Power goes to more places than just the two motors.


----------



## CleanEV

@JWardell - canpico is release and available as of today. Does this help in minimizing number of wires, dongles or similar contraptions to get all the data from Tesla's?
https://www.cnx-software.com/2021/05/26/canpico-open-source-board-adds-can-bus-to-raspberry-pi-pico/


----------



## onessela

JWardell said:


> Usually we read power from the BMS 0x132 by multiplying voltage and current. Power goes to more places than just the two motors.


Hi, I tried this way. Readings are slightly different (greater, max. reading now is 200KW), which is reasonable, but very far from 300-350KW showed in display / menu Energy. Hmmmmm....


----------



## kornerz

onessela said:


> Hi, I tried this way. Readings are slightly different (greater, max. reading now is 200KW), which is reasonable, but very far from 300-350KW showed in display / menu Energy. Hmmmmm....


That is strange.
Using this method, even my RWD SR+ pulls 225kW when flooring.


----------



## JWardell

A general shout-out to anyone with a Plaid or 2021 Model S (or anyone who knows anyone) that is willing to take and share a short CAN log, we would love to investigate, we could quickly find answers to a lot of questions like battery configuration and pack voltage!


----------



## JWardell

Ask and you shall anonymously receive...info is preliminary and LOTS of CAN sleuthing is required, but plenty of good nerdy data discovered for plaid from a stationary log:

Pack energy 100kWh
Pack usable 97kWh
Max voltage 462V
Chassis type Model S 
Performance package BASE 
Max discharge power 791kW
Max charge power 118 kW
max discharge current 2300A
Drive max power 770kW
Drive max regen 90kW
System power limit 640kW
System torque limit 10300Nm (ok that doesn't seem right..)
110 battery bricks (110 cells in series) instead of the usual 96!


----------



## garsh

JWardell said:


> System torque limit 10300Nm (ok that doesn't seem right..)


Apparently, it's a "wheel torque" measurement rather than at the motor.

https://www.motorauthority.com/news...pound-feet-of-torque-and-whats-its-horsepower


----------



## jomega

Hi, 
Does anyone know which message is sent to the BMS to request open/close contactor? This is for the Tesla model 3 battery.


----------



## JWardell

Updated the post above with some corrected data. SavvyCAN decoding bug.


----------



## JWardell

I've found all three plaid motors in the matrix!! Stay tuned...


----------



## JWardell

Well folks have asked for years for a video walking through some of the can log analysis and data sleuthing I've done, so here is the opportunity!


----------



## dimitar.ns

JWardell said:


> Well folks have asked for years for a video walking through some of the can log analysis and data sleuthing I've done, so here is the opportunity!


Great video! Thanks for sharing your workflow with us.

Is there any chance we can also get the logs to play with them ourselves a little? I'm thinking to make a comparison table with model 3 messages and share it here in the thread.


----------



## JWardell

dimitar.ns said:


> Great video! Thanks for sharing your workflow with us.
> 
> Is there any chance we can also get the logs to play with them ourselves a little? I'm thinking to make a comparison table with model 3 messages and share it here in the thread.


I can't share their logs but I'm sure more will be along soon.
I did run a compare in savvycan and there were hundreds of differences. It's using Model 3 messages for most subsystems, but most everything from the motors/inverters are elsewhere, and there are dozens of unknown things. Hopefully we can identify more with time, especially once Model 3 catches up to the same software updates as the plaid.


----------



## Redox

I'd like to read if ACC is enabled and the speed that the driver asks ACC to reach.
Currently, to read if ACC is enabled, I read DAS_accSpeedLimit if its value is 1023 (204.6km/h), I consider ACC is enabled. Is it the good way or is there another signal ?
DAS_setSpeed seems to be the speed that ACC itself asks the car to reach, is it right ?
I've checked every signal containing "speed" but can't find the speed that the driver can set... Have I missed it ?

Edit : my assumption about DAS_accSpeedLimit seems to be wrong as it doesn't stay at 1023 when AP is enabled...

I have another question, do we know how to use DAS_virtualLaneC0 to C3, to get a visual representation of the lane ?


----------



## JWardell

*1.21 GigaMegawatts.*
Plaid launch power. That can't just be a coincidence!


----------



## JWardell

So 2021.12.whatever arrived today and I noticed my torque bargraph was wonky. Uh-oh, Tesla changed some CAN messaging!

I forgot that I use 0x1D8 on my Server and Displays, which was purely reversed engineered in this thread back in the day, and seemed to present real torque. It changed only once with v9. But I believe .12 is the first mix with Plaid software so it's a good reason to change it again.
It seems to go from a 13-bit signed to a 10-bit side, and multiplier from .25 to maybe .5... but we never really know what that should be.
(So if you have wonky bargraphs, if you change those values on your server, it will be good again)

But I really need to kind of validate this with a full throttle on a dyno or find max ratings and scale appropriately.

Meanwhile the "software" torque is at 0x108 so we know that decoding, but that has always presented insane values of 7000Nm or whatever. That still seems to be working, at least on my 3. I think we argued in here if we should leave that or enter in some divider, but never found a sensible one.

I think this also explains why I couldn't find good torque messages for plaid. I'll have to investigate some more.


----------



## JWardell

Ok *NOW* I have the motor torque changes with 2020.12 figured out...they stay 13 bit and just move. This are the secret-ish 0x1D5 and 0x1D8 motor torques, not the 0x108 etc axle torques.

BO_ 472 ID1D8RearTorque: 8 VehicleBus
SG_ Checksum1D8 : 56|[email protected]+ (1,0) [0|255] "" Receiver
SG_ Counter1D8 : 53|[email protected]+ (1,0) [0|7] "" Receiver
SG_ RearTorqueRequest1D8 : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ RearTorque1D8 : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ TorqueFlags1D8 : 0|[email protected]+ (1,0) [0|255] "" Receiver

Still searching for both torque types in the plaid log haystack.


----------



## JWardell

I just made quite a big discovery, and I need help from anyone with a 2021 Model 3/Y!

Apparently Tesla has hidden a dedicated Model S-style CAN diagnostic connectors in Model 3 since Oct 2020!
It should be hidden behind the passenger footwell. I noticed the change in the EDR cable guide at https://edr.tesla.com/help

And, by coincidence, this "CAN Connector" has the same new pinout as we noticed changes in the new 2021 Model S/plaid

So we might FINALLY have a single, easy to access connector, with mutiple canbusses, common across all 2021 Teslas!

I need help with anyone with a 2021 to help confirm it exists, and we get good data.

I also need help begging Maxwell to update the Model S cables to make the pin swaps needed for 2021 Model S, and apparently now 3 as well.


----------



## karasta

JWardell said:


> I just made quite a big discovery, and I need help from anyone with a 2021 Model 3/Y!
> 
> Apparently Tesla has hidden a dedicated Model S-style CAN diagnostic connectors in Model 3 since Oct 2020!
> It should be hidden behind the passenger footwell. I noticed the change in the EDR cable guide at https://edr.tesla.com/help
> 
> And, by coincidence, this "CAN Connector" has the same new pinout as we noticed changes in the new 2021 Model S/plaid
> 
> So we might FINALLY have a single, easy to access connector, with mutiple canbusses, common across all 2021 Teslas!
> 
> I need help with anyone with a 2021 to help confirm it exists, and we get good data.
> 
> I also need help begging Maxwell to update the Model S cables to make the pin swaps needed for 2021 Model S, and apparently now 3 as well.
> 
> View attachment 39540


I found EDR CAN bus connector for my 2021 Model 3 SR+ RH(JPN) behind the carpet on the "driver's side."
This is a 20-pin connector with seven wires connected to it.
It was about 30mm wide and had Sumitomo's mark on.
The model number is probably 6098-5613.

I hope you have some information on the pinout.


----------



## JWardell

karasta said:


> I found EDR CAN bus connector for my 2021 Model 3 SR+ RH(JPN) behind the carpet on the "driver's side."
> This is a 20-pin connector with seven wires connected to it.
> It was about 30mm wide and had Sumitomo's mark on.
> The model number is probably 6098-5613.
> 
> I hope you have some information on the pinout.
> 
> View attachment 39641


Yes, the pinout and build instructions are here:
https://teslamotorsclub.com/tmc/threads/diagnostic-port-index.98663/page-9#post-5840129
Unfortunately it seems 3/Y do not have 12v power in their connector


----------



## Madmolecule

idea for canserver. Wireless trailer interface. A wireless module that mounts on the trailer that you only have to provide 12 V to. It will then get its lights, brake and turn signals. From the canbus. The Tesla is just such an expensive car to install trailer lights on. Of course you would have to add some party light mode for camping etc.


----------



## JWardell

Madmolecule said:


> idea for canserver. Wireless trailer interface. A wireless module that mounts on the trailer that you only have to provide 12 V to. It will then get its lights, brake and turn signals. From the canbus. The Tesla is just such an expensive car to install trailer lights on. Of course you would have to add some party light mode for camping etc.


Interesting idea. Nothing needed for the canserver really, that can be done now, it's really a client module like my microdisplay that has outputs for all the lights.
I don't have a trailer or hitch so I don't know any better, does it just need four outputs for running lights, brake lights, and two blinkers? How much power does each need, are they usually 50 watt bulbs?


----------



## kornerz

If anyone need that data, I've managed to partially decode ID261, VCFRONT_12VBatteryStatus with 12v battery voltage, current, temperature and capacity.
They've changed it at around 2020.4 to an indexed value with 4 pages, however only first 3 appear usable:



Code:


BO_ 609 ID261VCFRONT_12VBatteryStatus: 8 VehicleBus
 SG_ VCFRONT_12VBatteryIndex M : 0|[email protected]+ (1,0) [0|4] ""  Receiver
 SG_ VCFRONT_IBSCurrent m0 : 16|[email protected] (0.005,0) [-163.84|163.835] "A"  Receiver
 SG_ VCFRONT_IBSCurrentRaw m1 : 16|[email protected] (0.005,0) [-163.84|163.835] "A"  Receiver
 SG_ VCFRONT_IBSVoltage m1 : 32|[email protected]+ (0.005443676098,0) [0|22.29185362131] "V"  Receiver
 SG_ VCFRONT_IBSAmpHours m2 : 2|[email protected] (0.01,0) [-81.92|81.91] "Ah"  Receiver
 SG_ VCFRONT_IBSTemperature m2 : 8|[email protected] (0.1,0) [-327.68|327.66] "degC"  Receiver


----------



## JWardell

kornerz said:


> If anyone need that data, I've managed to partially decode ID261, VCFRONT_12VBatteryStatus with 12v battery voltage, current, temperature and capacity.
> They've changed it at around 2020.4 to an indexed value with 4 pages, however only first 3 appear usable:
> 
> 
> 
> Code:
> 
> 
> BO_ 609 ID261VCFRONT_12VBatteryStatus: 8 VehicleBus
> SG_ VCFRONT_12VBatteryIndex M : 0|[email protected]+ (1,0) [0|4] ""  Receiver
> SG_ VCFRONT_IBSCurrent m0 : 16|[email protected] (0.005,0) [-163.84|163.835] "A"  Receiver
> SG_ VCFRONT_IBSCurrentRaw m1 : 16|[email protected] (0.005,0) [-163.84|163.835] "A"  Receiver
> SG_ VCFRONT_IBSVoltage m1 : 32|[email protected]+ (0.005443676098,0) [0|22.29185362131] "V"  Receiver
> SG_ VCFRONT_IBSAmpHours m2 : 2|[email protected] (0.01,0) [-81.92|81.91] "Ah"  Receiver
> SG_ VCFRONT_IBSTemperature m2 : 8|[email protected] (0.1,0) [-327.68|327.66] "degC"  Receiver


Thanks, this is helpful. I didn't realize this changed, I will have a closer look. I need to make some plaid updates to the DBC anyway


----------



## scottf200

Re: cross-referencing information displayed in the car to what you see in the CANBus.

FYI, others are reporting in a TMC Model Y 82 kWh pack thread that this is working to get into the diagnostic screens. -- TMC Post: Model Y 82kW Battery Pack

I could do it in my 2017 X 100D but my kid could *not *in his 2018 TM3 AWD LR *until *he did the reddit mentioned steps below. He was able to then see the diagnostic screens










Trouble getting in? Brake to turn 'on'.

From the reddit thread.










I'm sure Tesla will correct this oversight soon. In anticipation, I did a 'Forget' of my wifi for the time being so it doesn't download and prompt me every time I turn get in the car.


----------



## michi84

The Inverter temp messages BO_ 886 ID376FrontInverterTemps and BO_ 789 ID315RearInverterTemps: 8 VehicleBus seem to have changed with 2021.24.4: What was formerly stator temp, now appears to be Inverter Temp, Inverter Heat Sink and Inverter Temp (old) are jumping between 40°C and some other value. Did not have time to look at the binary view yet, but it looks like signal order and start bits / length have changed. Or the message is multiplexed now like 12V Battery. See attached logs.


----------



## michi84

Looks very much like multiplexed signal now, with a multiplexer changing between 0 and 1. Values fluctuate with multiplexer change. First recording is with car parked, the other two while driving. In parked condition inverter temp and heatsink temp are normaly within 1°C of powertrain inlet coolant temp, so the correct value could be checked against this reading. While driving, inverter heatsink temp reacts quickly to load changes (increases a few degrees under acceleration, more under heavy acceleration), inverter temp changes slowly and is mostly close to powertrain coolant temp or slightly above. Stator temp usually goes up continuosly during driving, primarily for the rear motor, and runds around 40-60 degress under current weather. Front is colder. Capbank temp was useless, always fixed at 40°C.


----------



## Eugenius

since Diagnostic Menu was discovered, we know, that there a signal for Time Zone available with an offset of -14400 for -4h
https://i.redd.it/hqxnlgb2qqk71.jpg
Did somebody already found it?


----------



## pyjamasam

Eugenius said:


> since Diagnostic Menu was discovered, we know, that there a signal for Time Zone available with an offset of -14400 for -4h
> https://i.redd.it/hqxnlgb2qqk71.jpg
> Did somebody already found it?


That Data screen isn't all CAN info. I suspect its stuff that the computer knows about (some of it is CAN based, but not all) - which makes sense cause the main computer would know the timezone for display purposes, but the rest of the car all operates in UTC. I don't think we have ever come across the timezone or offset in the CAN data.

chris.


----------



## karasta

I made a cable to connect the CANserver to the 2021 Tesla Model 3 with new diagnostic port, so I'll share it with you.
The CANserver box was installed in the center console and gets power from USB. I used an Ethernet cable for these connection. It's a twist-pair.
There are several types of Ethernet jacks. The punch down type (B.) is cheaper, but screw type (C.) is easier.

Below is the parts list. Aliexpress is cheap, but takes a long time to deliver.

A. 20 pin female Sumitomo Automobile cable Connector 6098-5622 with wire, $7
https://www.aliexpress.com/item/4000366756514.htmlB. RJ45 Punch Down Keystone Jack, $2
https://ja.aliexpress.com/item/1005002081657901.htmlC. RJ45 Ethernet Female to 8 Pin Screw Terminal Connector, $6
https://www.aliexpress.com/item/1005001804036555.htmlD. JST XH 2.54mm Pitch Terminal Kit, $3
https://www.aliexpress.com/item/4000126563819.html


----------



## JWardell

karasta said:


> View attachment 39853
> 
> I made a cable to connect the CANserver to the 2021 Tesla Model 3 with new diagnostic port, so I'll share it with you.
> The CANserver box was installed in the center console and gets power from USB. I used an Ethernet cable for these connection. It's a twist-pair.
> There are several types of Ethernet jacks. The punch down type (B.) is cheaper, but screw type (C.) is easier.
> 
> Below is the parts list. Aliexpress is cheap, but takes a long time to deliver.
> 
> A. 20 pin female Sumitomo Automobile cable Connector 6098-5622 with wire, $7
> https://www.aliexpress.com/item/4000366756514.htmlB. RJ45 Punch Down Keystone Jack, $2
> https://ja.aliexpress.com/item/1005002081657901.htmlC. RJ45 Ethernet Female to 8 Pin Screw Terminal Connector, $6
> https://www.aliexpress.com/item/1005001804036555.htmlD. JST XH 2.54mm Pitch Terminal Kit, $3
> https://www.aliexpress.com/item/4000126563819.html


I'm still waiting for someone to sell the updated the connector, I thought Maxwell would have one by now. Great idea getting a pre-crimped connector off of aliexpress!
Quite a few folks do the same and build their own ethernet cables to locate the server elsewhere.
It's too bad Tesla doesn't also put power on that connector (on 3/Y)


----------



## kornerz

Updated to 2021.32.10, and it looks like ID3A1 (VCFRONT_vehicleStatus ) is multiplexed now, with the first bit ( 0|[email protected]+ (1,0)) being the index, and old data available at index 0.
Sample messages:
can0 3A1 [8] 08 62 00 98 00 20 82 17
can0 3A1 [8] C3 FF FF 01 00 00 90 C5


----------



## michi84

I can confirm this is also the case on 2021.24.4 - the same version also changed the inverter temp messages.


----------



## karasta

In GPSLongitude04F of ID04FGPSLatLong of Model3CAN.dbc, I got the correct value with unsigned (28|[email protected]+) instead of signed(28|[email protected]).
I've only tested this in my location (Lng 138.xx), so it may have a negative effect in other locations. I'm still trying to understand how it works.


----------



## JWardell

We finally have software version! Something we have been searching for years for.
The first four bytes of 0x558 coincide with the GitHash of the firmware version (you can get them from teslafi firmware page etc)

BO_ 1368 SoftwareVersion: 8 VehicleBus
SG_ SWVersionGitHash : 0|[email protected]+ (1,0) [0|1] "" Receiver

Huge props go to @Redox for this one!


----------



## JWardell

karasta said:


> In GPSLongitude04F of ID04FGPSLatLong of Model3CAN.dbc, I got the correct value with unsigned (28|[email protected]+) instead of signed(28|[email protected]).
> I've only tested this in my location (Lng 138.xx), so it may have a negative effect in other locations. I'm still trying to understand how it works.


This is strange, because the old decoding in my DBC still works correctly for me, but I have seen new decoding that does NOT work right.
Try this, but if it works I have to figure out why there is a difference:

UI_longitude : 28|[email protected]+ (1e-06,0) 
UI_latitude : 0|[email protected]+ (1e-06,0)


----------



## El0ngated

On Plaid found a possible signal related to torque request: ID1CFCombined Torque Request? : 8|[email protected] (.02442,0) Maybe %?


----------



## El0ngated

JWardell said:


> We finally have software version! Something we have been searching for years for.
> The first four bytes of 0x558 coincide with the GitHash of the firmware version (you can get them from teslafi firmware page etc)
> 
> BO_ 1368 SoftwareVersion: 8 VehicleBus
> SG_ SWVersionGitHash : 0|[email protected]+ (1,0) [0|1] "" Receiver
> 
> Huge props go to @Redox for this one!


On Plaid it looks to be the first 6 bytes. The hex corelates with the software code found on the center display under the software menu. Maybe someone can check if this is the case with 3 and Y.


----------



## Redox

El0ngated said:


> On Plaid it looks to be the first 6 bytes. The hex corelates with the software code found on the center display under the software menu. Maybe someone can check if this is the case with 3 and Y.


You're right, I've just checked all my logs, and I've seen for example on teslascope.com that they have the 6 bytes githash for every version.
So the easiest way to find the githash extracted from 0x558 is to search on google : "site:teslascope.com <githash>" as teslafi doesn't have always the 6 bytes githash.


----------



## Argent_S

Hi everyone.
For a long time, I try to found any information about how to change the region. I bought M3 at the auction in the USA and brought the car to the EU. I will happy if somebody shares any information about it with me. Thanks a lot.


----------



## kornerz

Argent_S said:


> Hi everyone.
> For a long time, I try to found any information about how to change the region. I bought M3 at the auction in the USA and brought the car to the EU. I will happy if somebody shares any information about it with me. Thanks a lot.


That is usually done by gaining root access ("jailbreaking") the car - and we don't discuss such modifications here.

Anyway, even if you do change the region with help of some local Tesla hackers - current EU maps are useless in Belarus.


----------



## JWardell

I'm not sure it's even that easy. THere are a LOT of hardware differences between North American and Euorpean Teslas, that can't be changed by flipping some bits (and those bits, BTW need to be changed both in the computer and on the cloud side). The largest of these is the totally different charge port, charge connector, and onboard charger.


----------



## kornerz

JWardell said:


> I'm not sure it's even that easy. THere are a LOT of hardware differences between North American and Euorpean Teslas, that can't be changed by flipping some bits (and those bits, BTW need to be changed both in the computer and on the cloud side). The largest of these is the totally different charge port, charge connector, and onboard charger.


I've seen these conversions, it's almost 100% in software.
NA vehicle in Europe gets a blank map and no LTE connectivity.
So the changes usually are:
- Upload local maps to the vehicle, flip some bits so it thinks maps are good
- Install local SIM card
- Sometimes, replace taillights with red turn signals with amber ones.

Charging port stays the same as well as all charging circuitry - owners of US salvaged Tesla are fine with using some adapters to charge.


----------



## osunick

Hi all,

Got my CANServer installed a few days ago and roped my wife into hacking an Android app that I plan to use as an instrument cluster. Think a dock built into the steering column trim that you slot your phone into and it just turns into a gauge cluster that matches the look and feel of the Tesla UI. Nothing too complicated, but we're making good progress (if anyone has good ideas on swapping little endian integers into big endian so Java/Kotlin is happier other than just string manipulation with a cast at the end, please share). 

My question is whether or not one can determine if the display is in 'dark' mode from CAN. I can pull headlight status and brightness but haven't found a signal that corresponds to dark mode.

Also, if there is interest we can put our project up on github and throw up a discord if people want to hack. My goal is to contribute, and the most I'd ever do is coffeeware without any ads or paid features. Thanks!


----------



## JWardell

osunick said:


> Hi all,
> 
> Got my CANServer installed a few days ago and roped my wife into hacking an Android app that I plan to use as an instrument cluster. Think a dock built into the steering column trim that you slot your phone into and it just turns into a gauge cluster that matches the look and feel of the Tesla UI. Nothing too complicated, but we're making good progress (if anyone has good ideas on swapping little endian integers into big endian so Java/Kotlin is happier other than just string manipulation with a cast at the end, please share).
> 
> My question is whether or not one can determine if the display is in 'dark' mode from CAN. I can pull headlight status and brightness but haven't found a signal that corresponds to dark mode.
> 
> Also, if there is interest we can put our project up on github and throw up a discord if people want to hack. My goal is to contribute, and the most I'd ever do is coffeeware without any ads or paid features. Thanks!


Sounds great, would love to see a photo when you're done!

The only message that I can find, and not sure is actually transmitted, has these values for display:

SG_ UIS_centerDisplayState m80 : 32|[email protected]+ (1,0) [0|4.29497e+9] ""
VAL_ 1056 UIS_centerDisplayState 0 "OFF" 1 "DIM" 2 "ACCESSORY" 3 "ON" 4 "DRIVING" 5 "CHARGING" 6 "LOCK" 7 "SENTRY" 8 "DOG" 9 "ENTERTAINMENT" ;

Otherwise it might need to just be based on sunrise/sunset times


----------



## osunick

JWardell said:


> Sounds great, would love to see a photo when you're done!
> 
> The only message that I can find, and not sure is actually transmitted, has these values for display:
> 
> SG_ UIS_centerDisplayState m80 : 32|[email protected]+ (1,0) [0|4.29497e+9] ""
> VAL_ 1056 UIS_centerDisplayState 0 "OFF" 1 "DIM" 2 "ACCESSORY" 3 "ON" 4 "DRIVING" 5 "CHARGING" 6 "LOCK" 7 "SENTRY" 8 "DOG" 9 "ENTERTAINMENT" ;
> 
> Otherwise it might need to just be based on sunrise/sunset times


Oh is that how the display triggers night/day based on some almanac data? Also, are you planning on deprecating Panda any time soon? Since websockets aren't available we're using your "v2" API to pull filtered data. Java/kotlin really does not like little endian numbers, so that's been a bit of a pain but we're pulling data and it's mostly looking good now. I've also ordered a spare piece of steering column trim that I hope to scan with my 3D scanner so I can make a fairly decent charging mount on the steering column and I hope to have STEP up on thingiverse so people can design their custom mounts. We're targeting Android 6 so that folks can use cheap hardware or their own phones. I'm planning on using a Sony Xperia Z3 Compact because it has a hardware charging port on the side, so I can do something invisible when the phone is in landscape.


----------



## JWardell

osunick said:


> Oh is that how the display triggers night/day based on some almanac data? Also, are you planning on deprecating Panda any time soon? Since websockets aren't available we're using your "v2" API to pull filtered data. Java/kotlin really does not like little endian numbers, so that's been a bit of a pain but we're pulling data and it's mostly looking good now. I've also ordered a spare piece of steering column trim that I hope to scan with my 3D scanner so I can make a fairly decent charging mount on the steering column and I hope to have STEP up on thingiverse so people can design their custom mounts. We're targeting Android 6 so that folks can use cheap hardware or their own phones. I'm planning on using a Sony Xperia Z3 Compact because it has a hardware charging port on the side, so I can do something invisible when the phone is in landscape.


NOt sure if it dim display is based on time, but the car does calculate the actual position of the sun, so it trigger when it actually drops below the horizon based on your position and elevation.
Panda will stay, but @pyjamasam may add another method as well


----------



## osunick

This is our prototype Sony Xperia X3 Compact in a 3d printed charging mount on the steering column. The key is that it works!

We got basic functionality working in the car today (along with a basic cluster with turn signal and speed) and it's pretty solid, lots to do in terms of polish and wiring up more UI but the CANServer was very, very useful in keeping us productive. Big thanks to my wife who did most of the heavy lifting and learned a lot about Panda and CAN, two things that are utterly irrelevant to her work.










Next steps are to make it a little less fragile and remove the navbar , and wire up more signals to UI while making it look more Tesla.


















intent is to open source this once we get it in better shape. It would be cool if people did motorsport views or even theming like a Cyberpunk one. Still not letting us get ahead of ourselves but it feels good to have something work. What is the refresh rate of the Panda data? It seems quite fast- it was a relief that we didn't have to figure out how to manually sync turn signal indicators.


----------



## osunick

JWardell said:


> Sounds great, would love to see a photo when you're done!
> 
> The only message that I can find, and not sure is actually transmitted, has these values for display:
> 
> SG_ UIS_centerDisplayState m80 : 32|[email protected]+ (1,0) [0|4.29497e+9] ""
> VAL_ 1056 UIS_centerDisplayState 0 "OFF" 1 "DIM" 2 "ACCESSORY" 3 "ON" 4 "DRIVING" 5 "CHARGING" 6 "LOCK" 7 "SENTRY" 8 "DOG" 9 "ENTERTAINMENT" ;
> 
> Otherwise it might need to just be based on sunrise/sunset times


This looks like the ticket:

BO_ 723 ID2D3UI_solarData: 8 ChassisBus 
SG_ UI_isSunUp : 25|[email protected]+ (1,0) [0|3] "" Receiver


----------



## JWardell

I found Plaid torque messages!!

After my last video, I spent several days searching through EACH CAN ID looking for data that matched or was similar to existing torque CAN messages, but could never find any...and with to per motor, it was frustrating that six messages should be easy to find, and I got nowhere.

Really thanks to Ryan for hacking around his plaid and breaking things, we discovered there is an unknown CAN bus, containing high speed drivetrain data, and all the missing torque signals were there! (well after more deep searching)

So here's a video explaining it all:






And for reference, the plaid torque messages:

BO_ 264 ID108DIR_torque: 8 VehicleBus
SG_ DIR_axleSpeed : 40|[email protected] (0.1,0) [-2750|2750] "RPM" Receiver
SG_ DIR_slavePedalPos : 56|[email protected]+ (0.4,0) [0|100] "%" Receiver
SG_ DIR_torqueActual : 27|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIR_torqueChecksum : 0|[email protected]+ (1,0) [0|255] "" Receiver
SG_ DIR_torqueCommand : 12|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIR_torqueCounter : 8|[email protected]+ (1,0) [0|15] "" Receiver
SG_ DIR_axleSpeedQF : 25|[email protected]+ (1,0) [0|1] "" Receiver

BO_ 390 ID186DIF_torque: 8 VehicleBus
SG_ DIF_axleSpeed : 40|[email protected] (0.1,0) [-2750|2750] "RPM" Receiver
SG_ DIF_slavePedalPos : 56|[email protected]+ (0.4,0) [0|100] "%" Receiver
SG_ DIF_torqueActual : 27|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIF_torqueChecksum : 0|[email protected]+ (1,0) [0|255] "" Receiver
SG_ DIF_torqueCommand : 12|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIF_torqueCounter : 8|[email protected]+ (1,0) [0|15] "" Receiver
SG_ DIF_axleSpeedQF : 25|[email protected]+ (1,0) [0|1] "" Receiver

BO_ 266 ID10ADIRL_torque: 8 VehicleBus
SG_ DIRL_axleSpeed : 40|[email protected] (0.1,0) [-2750|2750] "RPM" Receiver
SG_ DIRL_slavePedalPos : 56|[email protected]+ (0.4,0) [0|100] "%" Receiver
SG_ DIRL_torqueActual : 27|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIRL_torqueChecksum : 0|[email protected]+ (1,0) [0|255] "" Receiver
SG_ DIRL_torqueCommand : 12|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIRL_torqueCounter : 8|[email protected]+ (1,0) [0|15] "" Receiver
SG_ DIRL_axleSpeedQF : 25|[email protected]+ (1,0) [0|1] "" Receiver

BO_ 392 ID188DIRR_torque: 8 VehicleBus
SG_ DIRR_axleSpeed : 40|[email protected] (0.1,0) [-2750|2750] "RPM" Receiver
SG_ DIRR_slavePedalPos : 56|[email protected]+ (0.4,0) [0|100] "%" Receiver
SG_ DIRR_torqueActual : 27|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIRR_torqueChecksum : 0|[email protected]+ (1,0) [0|255] "" Receiver
SG_ DIRR_torqueCommand : 12|[email protected] (2,0) [-7500|7500] "Nm" Receiver
SG_ DIRR_torqueCounter : 8|[email protected]+ (1,0) [0|15] "" Receiver
SG_ DIRR_axleSpeedQF : 25|[email protected]+ (1,0) [0|1] "" Receiver

BO_ 472 ID1D8RearTorque: 8 VehicleBus
SG_ Checksum1D8 : 56|[email protected]+ (1,0) [0|255] "" Receiver
SG_ Counter1D8 : 53|[email protected]+ (1,0) [0|7] "" Receiver
SG_ RearTorqueRequest1D8 : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ RearTorque1D8 : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ TorqueFlags1D8 : 0|[email protected]+ (1,0) [0|255] "" Receiver

BO_ 469 ID1D5FrontTorque: 8 VehicleBus
SG_ FrontTorqueRequest1D5 : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ FrontTorque1D5 : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver

BO_ 477 ID1DDRearLeftTorque: 8 VehicleBus
SG_ RearLeftTorqueRequest : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ RearLeftTorque : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver

BO_ 792 ID318PlaidFrontTorque: 8 VehicleBus
SG_ PlaidFrontTorqueRequest1D5 : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ PlaidFrontTorque1D5 : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver

BO_ 793 ID319RearRightTorque: 8 VehicleBus
SG_ RearRightTorqueRequest : 8|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver
SG_ RearRightTorque : 21|[email protected] (0.222,0) [-909.312|909.09] "NM" Receiver


----------



## Argent_S

Hi.

I have a little problem with steering. I need to adapt steering with toolbox? I hope anybody can help me and clerify how it works.

Thanks.


----------



## osunick

Cross posting here as I think it's probably a better place-

Background, I'm writing an Android powered dashboard, you can see my progress here with live data, and it's powered by a CANServer reading panda frames over UDP.






I'm running into problems understanding and processing multiplexed frames, and I need to be able to so I can pull frunk status:

Here is the signal I want:
SG_ VCFRONT_frunkLatchStatus m0 : 3|[email protected]+ (1,0) [0|8] "" Receiver

and here is the definition for this frame:
BO_ 737 ID2E1VCFRONT_status: 8 VehicleBus
SG_ VCFRONT_statusIndex M : 0|[email protected]+ (1,0) [0|6] "" Receiver

When I extract raw data from Panda, in the payload I expect the first three digits to be the mux value from 0-6 in binary. This is an example of what I'm getting:

2021-11-04 09:41:44.593 8017-8044/tesladashboard D/PandaServiceImpl: frunkState mux startbit:3 bitlength:4 serviceIndex:3
2021-11-04 09:41:44.593 8017-8044/tesladashboard D/PandaFrame: muxValue: 0 GVSMUXPayload: 0000010100100110000000000000000000000000000000000000000000000000 unparsedMux000result 0
2021-11-04 09:41:44.610 8017-8044/tesladashboard D/PandaServiceImpl: frunkState mux startbit:3 bitlength:4 serviceIndex:3
2021-11-04 09:41:44.610 8017-8044/tesladashboard D/PandaFrame: muxValue: 0 GVSMUXPayload: 0000100000100001000001000010000010100010100011110010001000001000 unparsedMux000result 1

so my understanding here is that since both frames start with 000 they are the correct frame to process, but now I"m seeing cycling between two values. (when I look at other frames returned with this frameid, i will see payloads starting with 111 (7) which should be invalid as the highest valid value for statusIndex is 6.

I am new to all of this so my assumption is I'm making a basic mistake but I'm not sure what is going on here. Any help? Once I get these things ironed out to a decent state we can open source it and you all can take a look (and contribute, if you'd like).

Thanks!

-n.


----------



## osunick

I get it now. I have to read the first byte and then pull the last 3 digits.


----------



## osunick

Anyone happen to know which CAN signal has the cruise control set speed? I've looked at a variety of signals and none of them seem quite right. Thanks!


----------



## scott99

Hello, I'am looking ID for lock all doors in 2020 model3? It is?


----------



## JWardell

scott99 said:


> Hello, I'am looking ID for lock all doors in 2020 model3? It is?


There is a lockRequest in ID273, I'm not sure if that is a status or command, it's in the DBC.


----------



## scott99

JWardell said:


> There is a lockRequest in ID273, I'm not sure if that is a status or command, it's in the DBC.


I try ID273 already, but it's not.


----------



## JWardell

scott99 said:


> I try ID273 already, but it's not.


There might not be any CAN command for lock, since it just an imaginary software state in the computer. There are no actual locks, the computer just ignores the door buttons.


----------



## capture

Dear TeslaOwners!

I am currently struggling with a friends Model S. Tesla upgraded the MCU to MCU2 and it seems like they also updated the cars firmware. Before the upgrade we could read out the SoC on the CAN with ID0x302 but now I am struggling to find the SoC on the bus. I made some analysis on different states of charge and tried to apply the previous formula on the new data but without success. I did not find a solution by using the search function either so I hope someone can help me finding the correct identifier.

Kind regards from Switzerland

Mac


----------



## scott99

JWardell said:


> There might not be any CAN command for lock, since it just an imaginary software state in the computer. There are no actual locks, the computer just ignores the door buttons.


OK，Thank you.


----------



## JWardell

capture said:


> Dear TeslaOwners!
> 
> I am currently struggling with a friends Model S. Tesla upgraded the MCU to MCU2 and it seems like they also updated the cars firmware. Before the upgrade we could read out the SoC on the CAN with ID0x302 but now I am struggling to find the SoC on the bus. I made some analysis on different states of charge and tried to apply the previous formula on the new data but without success. I did not find a solution by using the search function either so I hope someone can help me finding the correct identifier.
> 
> Kind regards from Switzerland
> 
> Mac


I don't have an S to confirm, but I believe it is at 302, startbit 10, 10 bits, .1 scale.


----------



## powertrain.ing

Hey,

found this threat via google, when I was searching for CAN information of the Model3.

I don´t own Model3 yet, but I started allready some investigation on network, E/E architecture and CAN-communication, just to "know" about the car, when I will look for one during the next year.

Great work done sofare !!
A *BIG* respect to this

I am used to re-search on CAN busses, does it on several cars yet, but not for Tesla.

I collect allready a lot information and differend kind of DBC-file for Model3 form here and other sides on net. So I started allready working on my own re-search

Don´t know if you allready found this Model3 DBC too ?
It includes more information, but seem to decribe an older software.

May murching both files will be a step forwart.

May I ask about some items to the DBC-files themselves ?
There are a few things, that are not quite correct defined, but at the end, the file works of cause:

- Controler should discribe the CUs communicating on the CAN. In your file you discribe the CAN-busses awailible in the car. But this not correct at all. Eatch DBC-file discribes only *one* CAN-bus, not all of the car.

- same to network knobs, with are simular to controler

- insert known controller and assign signals to him as transmitter.
e.g. assign all DI-signal to controller DriveInverter, all BMS signals to controller BatteryManagementSystem etc.

- same, as you know a reciver of a signal

At the end you can build a communication matrix based on this.

- as I unterstand you change* THE* DBC-file, if a software update chance CAN communication. 
May I suggest to have one DBC-file to every software update, if there are chance and rename it to software revision. So there will be some kind of revision history based on vheicle software and you will not missmatch the DBC-file, if the CAN sniff is form older software.

As I unterstand, you mostly sniff the VehicleCAN, but not PartyCAN or ChassisCAN..
Anyone got CAN-sniffs from PartyCAN ?

For my own re-engieering of the CAN bus, may I ask someone to post a CAN-bus sniff like @michi84 did in this threat ? (I use them allready for my search).
Following maneuvers are usefull:

- acceleration from standstill up to 60miles (or higher if possible), with 50%, 75% and 100% pedal
- if possible, a powerup from sleep or awaike to drive-ready
- powerdown from drive to "off" (sleep will take too long AFAIK).
- just a drive on a curvy road

Thanks you advice
Jochen

btw.:

I mostly use Vector Tools for re-search ans well as a CAN re-engineering tool called "SmartCAN", witch was devellop by my company and works quite simular to SavvyCAN


----------



## powertrain.ing

What I allready chanced to your DBC:

VIN should be displayed in a differend way, so you have complete VIN displayed if you use ASCII as formal:

BO_ 1029 VIN_info: 8 VEH
SG_ VIN_infoIndex M : 0|[email protected]+ (1,0) [0|255] "" X
SG_ VIN_buffer m16 : 8|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_1 m16 : 40|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_2 m16 : 48|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_3 m16 : 56|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_4 m17 : 8|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_5 m17 : 16|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_6 m17 : 24|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_7 m17 : 32|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_8 m17 : 40|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_9 m17 : 48|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_10 m17 : 56|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_11 m18 : 8|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_12 m18 : 16|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_13 m18 : 24|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_14 m18 : 32|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_15 m18 : 40|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_16 m18 : 48|[email protected]+ (1,0) [0|255] "" Vector__XXX
SG_ VIN_17 m18 : 56|[email protected]+ (1,0) [0|255] "" Vector__XXX

Best regards 
Jochen


----------



## capture

JWardell said:


> I don't have an S to confirm, but I believe it is at 302, startbit 10, 10 bits, .1 scale.


Thank you for your reply. You are right, the soc was on 302 - but just until the upgrade to mcu2. It does not occur anymore. I will give it another try by searching through the can dump and hopefully find the soc anyway. I will let you know if I was successful.

Regards


----------



## JWardell

powertrain.ing said:


> Hey,
> 
> found this threat via google, when I was searching for CAN information of the Model3.
> 
> I don´t own Model3 yet, but I started allready some investigation on network, E/E architecture and CAN-communication, just to "know" about the car, when I will look for one during the next year.
> 
> Great work done sofare !!
> A *BIG* respect to this
> 
> I am used to re-search on CAN busses, does it on several cars yet, but not for Tesla.
> 
> I collect allready a lot information and differend kind of DBC-file for Model3 form here and other sides on net. So I started allready working on my own re-search
> 
> Don´t know if you allready found this Model3 DBC too ?
> It includes more information, but seem to decribe an older software.
> 
> May murching both files will be a step forwart.
> 
> May I ask about some items to the DBC-files themselves ?
> There are a few things, that are not quite correct defined, but at the end, the file works of cause:
> 
> - Controler should discribe the CUs communicating on the CAN. In your file you discribe the CAN-busses awailible in the car. But this not correct at all. Eatch DBC-file discribes only *one* CAN-bus, not all of the car.
> 
> - same to network knobs, with are simular to controler
> 
> - insert known controller and assign signals to him as transmitter.
> e.g. assign all DI-signal to controller DriveInverter, all BMS signals to controller BatteryManagementSystem etc.
> 
> - same, as you know a reciver of a signal
> 
> At the end you can build a communication matrix based on this.
> 
> - as I unterstand you change* THE* DBC-file, if a software update chance CAN communication.
> May I suggest to have one DBC-file to every software update, if there are chance and rename it to software revision. So there will be some kind of revision history based on vheicle software and you will not missmatch the DBC-file, if the CAN sniff is form older software.
> 
> As I unterstand, you mostly sniff the VehicleCAN, but not PartyCAN or ChassisCAN..
> Anyone got CAN-sniffs from PartyCAN ?
> 
> For my own re-engieering of the CAN bus, may I ask someone to post a CAN-bus sniff like @michi84 did in this threat ? (I use them allready for my search).
> Following maneuvers are usefull:
> 
> - acceleration from standstill up to 60miles (or higher if possible), with 50%, 75% and 100% pedal
> - if possible, a powerup from sleep or awaike to drive-ready
> - powerdown from drive to "off" (sleep will take too long AFAIK).
> - just a drive on a curvy road
> 
> Thanks you advice
> Jochen
> 
> btw.:
> 
> I mostly use Vector Tools for re-search ans well as a CAN re-engineering tool called "SmartCAN", witch was devellop by my company and works quite simular to SavvyCAN


Yes, that DBC is well outdated by now but was very useful at the time for insight into unknown signals.

Can you give us a link to your SmartCAN software so we can try it out?


----------



## iChris93

Are GPS coordinates available on the vehicle bus?


----------



## JWardell

iChris93 said:


> Are GPS coordinates available on the vehicle bus?


Historically no, but they make an appearance from time to time. Just confirmed chassis only in my latest log.


----------



## iChris93

JWardell said:


> Historically no, but they make an appearance from time to time. Just confirmed chassis only in my latest log.


Bummer. I just updated my CANServer firmware to V2. When I was on my own previous builds, I had chassis info sent to the vehicle bus using web sockets so I could log the GPS info with vehicle info for plotting as a function of position.

I also had it set up where filtered logging could be logged using an interval, just noticed filtered logging is logged every time the signal is received.


----------



## pyjamasam

iChris93 said:


> Bummer. I just updated my CANServer firmware to V2. When I was on my own previous builds, I had chassis info sent to the vehicle bus using web sockets so I could log the GPS info with vehicle info for plotting as a function of position.
> 
> I also had it set up where filtered logging could be logged using an interval, just noticed filtered logging is logged every time the signal is received.


I just saw your issue on github. I should be able to add that in.

chris.


----------



## gearcruncher

Thanks for this amazing thread, work, and knowledge.
I've read a lot, but before I read all 100 pages, does this thread include data on how to control the car via CAN, not just read data?

My use case: I want to be able to quickly change track mode settings while moving. Not put it into track mode, but change settings once already in track mode by either direct manipulation of the settings, or switching between profiles. I do actually track my car, and I think I might be able to be faster if I can adjust settings on course, this is not to be an idiot on the street.

I see the S3XY buttons have functions close to this, but I have a different use case and like to do things myself. I've built custom CAN displays for some ICE cars. I already have an ESP32 hooked to the bus and SavvyCAN, and I can see everything. But I'm interested how much work has been done in sending data. Are there examples in here for even simple stuff like rolling down a window or turning on the interior lights that I can use to learn more? I am well aware of the security risks when doing this- my ultimate goal is a fully hardwired system with no RF access.

Thanks for any pointers!


----------



## JWardell

Not a whole lot of experimentation has been made in transmitting data. The sexy buttons are the nicest example so far, but their short list of capabilities is about it. Really, folks need to experiment to answer what can be done, and I think most folks are not willing to take that risk. There are messages with counters and checksums that you know are not going to work out of sequence, but there are plenty of others that do not. The UI_ messages are perfect candidates, and sexy buttons prove they work (sometimes?)


----------



## gearcruncher

@JWardell - Thanks for the information. I'm attempting to hit a UI_ message, so maybe there is some hope. At the same time, the UI_powertrainControl messages do have a counter/checksum, so maybe I'm stuck. They appear to be ones the sexy buttons can hit too though...

For items without a checksum (say UI_vehicleControl), do we even know how to send these? They often have more than one signal- do you have to cache the last signal and only change what you want and transmit it all back, or is there a way to indicate null for the signals you don't want to touch? Do you just transmit the exact UI_ message you saw on the bus?


----------



## gearcruncher

Confirmed that for some things, you can make them happen by just re-sending the received message with the bit modification.
For instance 0x273, bit 61. If you set it high, the horn honks for a moment. Set bit 5 high and the frunk opens.
Now to go try more interesting things...


----------



## michi84

Are there any significant message changes with the holiday update? At the moment, i am holding back the update, since one in autumn broke the inverter temp messages (i might slowly be getting there to sort out was has changed (it a multiplexed signal now), but need some spare time). A log to look over it would be nice, hust to check wether this update is "safe" in this regard.


----------



## kornerz

michi84 said:


> Are there any significant message changes with the holiday update? At the moment, i am holding back the update, since one in autumn broke the inverter temp messages (i might slowly be getting there to sort out was has changed (it a multiplexed signal now), but need some spare time). A log to look over it would be nice, hust to check wether this update is "safe" in this regard.


Looks safe, with all messages still in place.
At least at Vehicle Bus.


----------



## michi84

That sounds good. Can you make a recording with the holiday update software for me to check?


----------



## onessela

Hello everybody, and happy New Year. Does anyone know if it is possible to send commands via Canbus? I would like to simulate the double click on the right lever to activate autopilot...
Alternatively, does anyone know how to intercept the up / down signals of the right lever? with a couple of relays they could be remotely controlled...


----------



## asanyfuleno

Bit of a random question but I've seen a thread talking about using V_ess and V_bat on the Model S to show the voltage either side of the contactors where they have to be very similar before it will allow the contactors to close. Is there anything similar on the Model 3 as I'm struggling with a contractor switching issue on my battery pack?


----------



## onessela

asanyfuleno said:


> Bit of a random question but I've seen a thread talking about using V_ess and V_bat on the Model S to show the voltage either side of the contactors where they have to be very similar before it will allow the contactors to close. Is there anything similar on the Model 3 as I'm struggling with a contractor switching issue on my battery pack?


Thank you, I'll check, meanwhile I found a video on how to directly intercept the analog voltage associated with position of levers switches, I could make a man-in-the middle interface and generate these analog levels with a DAC


----------



## onessela

Hello, does anybody know if it's possible to know when Autospeed/Autosteering is ON from Vehicle bus ? I don't have access to Chassis Bus. Just need to know when autospeed and/or autosteering is activated/deactivated from driver...
Edit: no luck until now. I tested 
ID247DAS_autopilotDebug: DAS_alcInternalState
ID247DAS_autopilotDebug: DAS_behaviorReport
ID3B3UI_vehicleControl2: UI_autopilotPowerStateRequest


----------



## Sporty

gearcruncher said:


> Confirmed that for some things, you can make them happen by just re-sending the received message with the bit modification.
> For instance 0x273, bit 61. If you set it high, the horn honks for a moment. Set bit 5 high and the frunk opens.
> Now to go try more interesting things...


Could you check if bits 6 & 7 will control the wipers?


----------



## asanyfuleno

Are there any significant differences compared to the Model Y?


----------



## kornerz

It looks like 2021.44.30.7 brought some changes to CAN bus behavior in Model 3.
Now the vehicle bus is brought down in deep sleep mode - so it is no longer possible to wake up the car by sending a small message over it.

I've spent quite some time debugging my hardware, but the bus is indeed being disabled from car side now.
And it looks like now I need to at least check if chassis bus is the same - or find another way of waking up the car.


----------



## Mike

kornerz said:


> It looks like 2021.44.30.7 brought some changes to CAN bus behavior in Model 3.
> Now the vehicle bus is brought down in deep sleep mode - so it is no longer possible to wake up the car by sending a small message over it.
> 
> I've spent quite some time debugging my hardware, but the bus is indeed being disabled from car side now.
> And it looks like now I need to at least check if chassis bus is the same - or find another way of waking up the car.


OT: perhaps this explains why I suddenly cannot wake my car up via the app today (?) (44.30.8)


----------



## onessela

Hi all, I am trying to attach my Raspberry to chassis bus. Unfortunately my (EU) car does not have yellow connector under passenger seat. Anyone knows where I can find this bus in EU Model 3's without too much disassembling ? Thanks a lot.


----------



## kornerz

kornerz said:


> It looks like 2021.44.30.7 brought some changes to CAN bus behavior in Model 3.
> Now the vehicle bus is brought down in deep sleep mode - so it is no longer possible to wake up the car by sending a small message over it.
> 
> I've spent quite some time debugging my hardware, but the bus is indeed being disabled from car side now.
> And it looks like now I need to at least check if chassis bus is the same - or find another way of waking up the car.


"Definitely not my hardware issue" was, in fact, my hardware issue (bad CAN bus connector wire).
So there are no changes to CAN bus behavior in sleep, all works as intended.


----------



## Onyx

Hey folks - wondering if anyone else has been playing with the connector in the passenger footwell on the newer model 3s? I build a connector using info from https://teslaownersonline.com/threads/diagnostic-port-and-data-access.7502/post-318649 (thanks @karasta !). I've got it hooked up to both vehicle and chassis buses, and most things check out - however, I'm not seeing any BMS messages at all on the vehicle bus. Is this known? Have they somehow filtered out some messages from getting to this access port? Or should I be looking elsewhere for issues?


----------



## Onyx

Ok, crisis averted. I think your pinout is incorrect @karasta (or I just read it wrong). By wiring my cable to the pins as shown this picture of my actual connection, I get good values on both buses. (The top of the picture is towards the cabin.)


----------



## onessela

Onyx said:


> Ok, crisis averted. I think your pinout is incorrect @karasta (or I just read it wrong). By wiring my cable to the pins as shown this picture of my actual connection, I get good values on both buses. (The top of the picture is towards the cabin.)
> 
> View attachment 41141


Hi, I have a 03/2020 EU Model 3 LR...Is the chassis bus connected to this connector on my model as well, or was it only done from October 2020 onwards?


----------



## sapkra

Hey, thank you for the amazing research. I need some help with getting some data from my Model 3. I created a dump while I was pushing the door handle in but I don't get any data in which angle the door handle is. None of the doorStatus messages (ID: 102, 122, 103) are changing somehow.

btw. I'm currently working on a helpful open source project for the community which I will announce in near future.


----------



## jabloomf1230

Has anyone with a recent FSD beta firmware created a dbc file for their vehicle?


----------



## bwilson4web

jabloomf1230 said:


> Has anyone with a recent FSD beta firmware created a dbc file for their vehicle?


Huh? What is a "dbc" file?

Bob Wilson


----------



## makemoney35

would you be able to read the color from the "car colorizer" using this? the color you select is available via the API since it shows up in the tesla app.

I was going to try to wire up interior RGB lights and use the car colorizer to select which color to use, but im not sure if thats something i could read with CAN data


----------



## kornerz

makemoney35 said:


> would you be able to read the color from the "car colorizer" using this? the color you select is available via the API since it shows up in the tesla app.
> 
> I was going to try to wire up interior RGB lights and use the car colorizer to select which color to use, but im not sure if thats something i could read with CAN data


Doubt it will be available on CAN bus (what the purpose would be for that?).
But it is definitely available on the Tesla Web API - in the same way Tesla app gets the color.


----------



## Salvesen

Hi all,

I am new to OBD2 usage, but I just bought a kit to my car and want to start creating some applications. I have just started to create a test program using c#. I am using the InTheHand.Net.Bluetooth lib to talk to the OBD adapter.

But I am facing a problem. I am using this guide: https://burakalakusen.wordpress.com/2011/07/27/to-get-obd2-data-via-elm327-c/

So I am sending ATSP1-5 and then sending 0100 to test comms. When sending ATSP1-2 I get NO DATA as a response, when I use 3 - 5 I get BUS INIT: ERROR. So, all 5 fails. And If i try an bus ID it just returns the ID with no data.

Anyone with experience that can guide me in the right direction here? Thanks!


----------



## kornerz

Salvesen said:


> Hi all,
> 
> I am new to OBD2 usage, but I just bought a kit to my car and want to start creating some applications. I have just started to create a test program using c#. I am using the InTheHand.Net.Bluetooth lib to talk to the OBD adapter.
> 
> But I am facing a problem. I am using this guide: https://burakalakusen.wordpress.com/2011/07/27/to-get-obd2-data-via-elm327-c/
> 
> So I am sending ATSP1-5 and then sending 0100 to test comms. When sending ATSP1-2 I get NO DATA as a response, when I use 3 - 5 I get BUS INIT: ERROR. So, all 5 fails. And If i try an bus ID it just returns the ID with no data.
> 
> Anyone with experience that can guide me in the right direction here? Thanks!


The guide you used is for conventional ICE cars and OBD protocol.
Tesla does not implement OBD protocol with "OBD request / response", etc - Tesla cars just have CAN bus connection where ELM327 adapter can be connected to read data.
You can try to use some known Tesla-specific OBD app ("Scan my Tesla", etc) to validate that hardware is working.


----------



## Salvesen

kornerz said:


> The guide you used is for conventional ICE cars and OBD protocol.
> Tesla does not implement OBD protocol with "OBD request / response", etc - Tesla cars just have CAN bus connection where ELM327 adapter can be connected to read data.
> You can try to use some known Tesla-specific OBD app ("Scan my Tesla", etc) to validate that hardware is working.


Hi,

I have verified it with scanmytesla.

Ok, so basically tesla only has a stream of data that I open then. Is that how I should be tackling it? Also, what about sending data to it? I know those buttons can turn of different things trough can etc?


----------



## ee1100

Does anyone know of any OBDII adapters that are compatible with a 2022 Model 3?


----------



## MakoShark3

ee1100 said:


> Does anyone know of any OBDII adapters that are compatible with a 2022 Model 3?


OBDLink LX works fine.

Is the DBC file up to date for the latest 2022.8.2?


----------



## ee1100

MakoShark3 said:


> OBDLink LX works fine.
> 
> Is the DBC file up to date for the latest 2022.8.2?


I mean the cord that plugs into the Tesla itself.


----------



## jonTmodY

Hi, if I'm using an OBD2 reader on a Model Y what message do I need to send to the car to unlock all of the codes shown in the DBC file?


----------



## iChris93

jonTmodY said:


> Hi, if I'm using an OBD2 reader on a Model Y what message do I need to send to the car to unlock all of the codes shown in the DBC file?


You don't need to send anything.


----------



## dimitar.ns

Is there someone that have logs from 2022.12.1? It looks like there are bigger changes in the signals with this version.
If you have but don't want to share them publicly here, please DM me.


----------



## tks_007

Hey Guys i'm searching for some logs of 2018 M S or a current DBC file?


----------



## Eugenius

karasta said:


> View attachment 39853


Did somebody found uninterrupted +12V near diagnostic port? (or at least interrupted +12V?)


----------



## Sydneyg

Thanks for everyone that has shared their work on here - especially Josh! It's been super usefull. Thought I should give something back if I am able. Doesn't seem to be any logs of all 3 can buses (Vehicle/Chassis/Party) so I've added a file from my AWD model 3 Performance. Hasn't updated for a while (no longer updating) so it is still on version 2021.4.3
Find here: https://github.com/sydneyg007/Tesla-Model-3-Logs


----------



## andyschroder

Hello,

I wanted to share an update on the Distributed Charge project. Board A0 has been released which allows connection to the SWCAN on the charge port: http://andyschroder.com/DistributedCharge/BoardA0/Overview/ . Board A0 mounts to the TOFU, which then gives you a full on board computer with cellular to interact with the car's CAN buses. In addition to the special CAN bus that is used for the charge port SWCAN, there is a second CAN bus on Board A0 that can be used to connect to the normal CAN buses on the car. I've also produced a rough schematic showing how Distributed Charge works with Board A0: http://andyschroder.com/DistributedCharge/EV/HowItWorks/ .


----------



## mgerczuk

I received 2022.12 yesterday and took a chance to compare the changed CAN frames 315 and 376:

old:
 (1588178450.689316) can0 315 [8] 3A 3A 3A 50 3A 95 7D 03
(1588178452.620446) can0 376 [8] 39 3A 39 50 3A 8A 7D 03

new:
 (544.697169) can0 315 [8] 0C 37 36 36 50 37 A0 7D
(544.697792) can0 315 [8] 01 36 37 00 38 37 00 00
(544.698275) can0 315 [8] 02 00 00 00 00 00 00 00
(545.665189) can0 376 [8] 0C 37 36 37 50 38 84 7D
(545.665675) can0 376 [8] 01 38 38 00 38 FF 00 00
(545.666389) can0 376 [8] 02 FF FF FF FF 00 00 00

It looks like both changed to a multiplexed frame, the first 7 bytes moved "one up" and the two bits signal of the last byte of the old frame moved to bit positions 2 and 3 of the first byte in the new frame.

I have no idea what the frames 1 and 2 may contain. It looks like more temperature values since it was about 15°C when the log was taken.


----------



## mathias_c

Hello,

Do you have more information on the meaning of these parameters on a Model 3 ? (Target Active Cool, Target Passive, Target Active Heat)

Thank you


----------



## kornerz

mathias_c said:


> Hello,
> 
> Do you have more information on the meaning of these parameters on a Model 3 ? (Target Active Cool, Target Passive, Target Active Heat)
> 
> Thank you


Wording implies it's cooling system targets to keep Powertrain (PT) and Battery temperatures below these values.
I've tried to log them a while ago, but no significant changes were observed.
Also, these battery cooling targets are way above of healthy battery temperature - so I would assume this message is a leftover of something not implemented or removed.


----------



## mexu

Hello,

I'm having difficulty analyzing the CAN signals of my Model 3 with a Raspberry Pi 4B.

As soon as I connected the 18th yellow pin and the 19th white pin of the 26-pin connector (referring to the spreadsheet) to the CAN-H and CAN-L pin of a Raspberry Pi CAN BUS module, my Model 3 turned off air conditioning and seemed to have stopped working. I guess my model 3 stops working when there is any continuity between the 18th pin and the 19th pin.

Is my Model 3 working correctly and could you give me any advice or help?

Thank you.


----------



## mexu

mexu said:


> Hello,
> 
> I'm having difficulty analyzing the CAN signals of my Model 3 with a Raspberry Pi 4B.
> 
> As soon as I connected the 18th yellow pin and the 19th white pin of the 26-pin connector (referring to the spreadsheet) to the CAN-H and CAN-L pin of a Raspberry Pi CAN BUS module, my Model 3 turned off air conditioning and seemed to have stopped working. I guess my model 3 stops working when there is any continuity between the 18th pin and the 19th pin.
> 
> Is my Model 3 working correctly and could you give me any advice or help?
> 
> Thank you.


Aw it worked well by setting the CAN interface listen-only. Thank you!


----------



## mexu

May I ask another question?

I'm sorry if I missed the information, but is it correct that the chassis CAN bus cannot be accessed via this blue 26-pin port behind the cover in the center console? Is there no way to get vehicle speed or something via this port?

Thank you.


----------



## mrt06

Hey guys!

I've tried to analyze the CAN bus of a Model 3 and a Model Y. On the Model 3 I was able to find a set of message that are listed on the following page: GitHub - joshwardell/model3dbc: DBC file for Tesla Model 3 CAN messages

But the messages on the Model Y look way different?! Where can I find a DBC file for the Model Y?

Thanks in advance
BR
T


----------



## elektronik87

Hello

Does anyone know the number of the male 22 pin EDR plug for Tesla 3?


----------



## grga

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.


----------



## kornerz

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


----------



## sapkra

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.









GitHub - tesberry/tesberry: A Tesla CAN bus utility for Raspberry Pi (WIP)


A Tesla CAN bus utility for Raspberry Pi (WIP). Contribute to tesberry/tesberry development by creating an account on GitHub.




github.com


----------



## onessela

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


----------



## kornerz

onessela said:


> 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.


----------



## MP3_NBG

.


----------



## dcop63

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 !


----------



## kenanluo

Does autopilotTrial indicate whether the auto driving is on? I decoded my own .asc files and this UI_autopilotTrial returns None always.


----------



## dcop63

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


----------



## ozaibaq

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.


----------



## chunkulator

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?


----------



## ozaibaq

ozaibaq said:


> 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).


----------



## ozaibaq

I noticed that I can read most of the data on the VehicleBus (in the dbc file), but I couldn't read any of the data on the ChassisBus. Any idea how to do that? Is there another bus I need to connect to?

Edit:
Sorry for the duplicate. I found an answer on this thread.
@JWardell How can I get the cable/connector?


----------



## ozaibaq

Frank 11223 said:


> @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?


----------



## ozaibaq

ozaibaq said:


> 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).


----------



## MrDIY

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!!!










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.


----------



## sapkra

@MrDIY Have you tried using ID2D3UI_solarData?


----------



## MrDIY

sapkra said:


> @MrDIY Have you tried using ID2D3UI_solarData?


I think this is it - thank you!!

My gateway only connects to VehicleBus  ... mabe I should look into adding ChassisBus as well.


----------



## sapkra

You're welcome. But before you hook into the ChassisBus, please have a look if this message isn't also available in the VehicleBus, because some of these messages defined in the DBC file are available in both.


----------



## MrDIY

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.


----------

