Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

Let the hacking begin... (Model S parts on the bench)

This site may earn commission on affiliate links.
I'm curious on what you guys use to log / play with the can busses. I've played a bit with them on my previous ride (Volvo S60) but I had the official diagnostic tool and it was super easy to trigger a dump of the CAN logs to a SD card housed on the Volvo DiCE (the tool).

I've seen that EVTV sells an arduino based device, is that a good deal? I already own a few arduinos + raspberry pi so I don't mind getting my hands dirty a bit to help the cause here ;)

I remember reading that Tesla's bus is at very high speed... so the regular CAN stuff might not work...
 
@llavalle

Partly due to the MS speed and bus load not a lot of devices can handle it, and those that can tend to be subject to any minor adjustments to either software or drivers, reading from a CAN transceivers SPI bus just a little too slowly (or having a poorly written driver) can mean the difference between constant error messages or successful logging. If you are interested in do some work in this area, another Canadian owner and I have been writing some software (GUI and console based) for logging and displaying messages using the CANtact, a low cost ($60) board available here, lots of progress on our front and more to come. The biggest advantage that the CANdue (from EVTV) has is being compatible with Collin Kidders SavvyCAN software, which enables logging and analyzing of the bus, the issue is the rather highly priced Arduino Due board, yes it's cheaper than a new Kvaser or Vector device but at over $100 shipped (more so to Canada) it doesn’t promise to be such a great deal (I got some Kvaser stuff of eBay for maybe $70 more than the CANdue shipped), plus I have written python software to reformat the output of the CANtact to a file format that SavvyCAN can read (so no logging but analysis features).

There are a lot of options out there depending on your comfort or skill level (plus what you already have laying around), send me a PM if you are interested in learning more, I'd be happy to help get you jumpstarted.
 
Wow, so how many folks are working on CAN loggers at this point? Seems like several by my count. Way to go!

Small suggestion, if I may: If you are piecing together a device that captures and parses CAN data, can it come with Wifi? Reason being is that I would find it extremely useful to have an auto upload feature to my home server. Basically this would simply entail a script that runs whenever I'm in range of my home wifi and it would sync up the logs.
 
That's pretty interesting. Without knowing the details around the situation I don't know how I'd handle that. Your car physically shipped with two chargers, but Tesla remotely disabled one? That's pretty messed up. I'd have raised hell.


Jason, It's a UK thing. Background:

The preferred charging option suggested by Tesla was to use a government scheme for installing a 32A single phase Type-2 point at your home. The glitch/oversight was chargers in an EU Model S cannot however charge at more than 16A @ 240V per phase. (In fact true single charger cars in EU are limited to 3kW when using public type 2 charging posts which did kick up a separate issue, but I'm digressing..)

In mainland Europe this wasn't a major problem because they could use the UMC with a "Commando" style 32A socket. In the UMC adapter for this style socket the input pin is simply bridged onto two of the phases inputs that go into the UMC itself.

However these sockets were up until recently not compliant with our electrical codes, as they do not have shutters. And at launch no 13A British style 3 pin adapter was available, so the UMC was not exactly living up to the "U" in it's title :D

So for UK cars the only play was to ship the cars all with physical dual chargers.

Now this is where it gets messy. Tesla software team were obviously not aware that that Tesla engineering team had taken this approach and Tesla sales team had still offered it as a hardware priced upgrade. So the early firmware as shipped to launch cars simply saw physically two chargers were installed, and on a 3 phase 32A supply we got the full benefit of dual chargers.

People posted up the results saying how pleased they were they'd got it FOC, and those that had paid for it kicked up hell. I would say for the early launch cars, the number of dual charger equipped cars was the majority, so offering refunds would have been very costly.

So Tesla OTA flashed cars with a new version that had a new software setting, not just reliant on the presence of the hardware. (Of course being Tesla they cocked this up, and flashed some people that had paid for it back to single chargers :) )

Now of course this pales into insignificance compared to the launch cars being superseded with in a month with AP, which was IMHO rushed through to get Euro NCAP 5 stars. Effectively none of the launch cars are 5 star rated as they don't have emergency brake assist which is mandatory to get that result, but that's another issue, and one which Tesla UK faced immensely more flak for.

It's still a mess here. Recent changes mean that if you have an interlocked 32A commando socket it now complies to code for installation in a domestic property for the use of EV charging. As soon as this happened UK team changed the guidance and pushed the UMC along with a voucher scheme competing with the government one which only allows Type-2 (rightly IMHO), often citing Elon had demanded it for user experience reasons. I suspect more likely the reason is that a UMC is cheaper than a second on board charger.

However all has not gone to plan, and there has been some kickback, the UMC solution is electrically less safe and given the way the UMC bridges phases even though the end is physically a Type-2 connector, electrically it isn't. Plug one into a car expecting true phases on the pins and magic smoke escapes from that car. So some people are still insisting on Type-2.


ANYWAY...

The analogy that comes to mind was if I'd bought a regular ICE, picked it up and discovered I'd got say a full size alloy wheel instead of a space saver. Then Tesla snuck into my garage and replaced it one night.

A simple email saying it was going to happen, or an offer of some mats as a sorry, or well anything.. It's colored my view of Tesla for sure.

Will I kick up hell, tbh life's too short.

Besides, I've had my revenge. I got shipped some firmware that has caused my car to lock down to lower charging rates on 3 phase, so I knew _EXACTLY_ what was going on. However I played dumb and let the service center replace both the physical chargers, before they realized and downgraded my firmware :redface:


All of that said... with root I could re-enabled it. Just like I could change a 40 to a 60, enable autopilot on cars that don't have it enabled, etc. Will I do any of that? No, I will not.

TBH was tongue in cheek. If I had root would I switch stuff on I didn't pay for, well dual chargers yes given the background... but it's moot. I won't keep the car outside 3 years, and then it will get traded in, so I have no intention of doing anything that voids the warranty.

"The right to repair" vs "right to enable latent features" is going to be an interesting debate on out of warranty cars at some point though, especially the low spec ones where more gains are to be had.
 
In regards to the CAN speeds, they are different depending on which bus you are on. For Example, CAN1 is at a standard speed while CAN6 is a high speed bus and CAN4 is also different. (No, I will not tell you which bus is on which pins. *insert ethical hacking post here*) Some also have different redundancy factors.

CAN is not my interest, BUT there is something else on/in the MCU (CID) that IS of interest to me. Anyway, skins are cool and I think that IF I have time I could whip one up after a bit of tinkering.

BTW DEFCON in Las Vegas might be interesting to people from here. (hint. hint.)
 
My goal is a small piece of hardware that looks like a mass storage class device when plugged into a USB port (memory stick) and will log certain data sets when plugged into the MS diag port just below the center display. I'm currently working on bat cell voltages and temps (that massive battery health screen you've seen posted) and plan on doing a burst performance data set after that (logs interesting stuff when power exceeds XYZ for doing vehicle performance analysis - there is some high rate stuff floating around so it should be one of the best 0-60 etc tools going). The pain in the butt for me is storing data in ASCII so that it can be viewed without post processing. In the past, I've used binary for space reasons and simply post processed to view. That is not going to fly here so I've got to do binary to ASCII with conversion to engineering units on the fly in micro controller land on large data sets (something like 128 values per set) which, basically, sucks. It also chews up a lot of clock cycles so I may be doing it on USB initiation... Not sure yet.

There are a lot of CAN things out there. I've got no interest in re-creating PC based professional CAN logging tools nor post process/analysis tools like SavvyCAN. My target is a simple tool for fellow forum members with tons of thanks to WK for getting me off my butt to do something :)
 
image.jpeg
 
Let's see... what other goodies...

Can enable Spotify from the diagnostic screen. It replaces Slacker, which sucks. And the quality is terrible compared to Slacker. Terrible. I'm not one for being picky on sound quality, but, they definitely have Spotify set to a much lower bitrate. I didn't keep it enabled. I like Slacker better still. It should probably be an option, though, even for us USA folks. The Spotify search interface is certainly way cooler:
.
Some people are reporting better sound/dynamic from spotify after the latest update (2.7.172) - could you check again (I can't remember if you have blocked for updates)
 
Dash display isn't capped at 60, but it's not linear, so beyond 60 the change is very small. Edit: Plus in v7.x in an autopilot car the power graph on the dash is completely useless anyway.

It is indeed non-linear, but the next two tick marks on the power meter would ostensibly be 75KW (darker mark) and then 90KW (lighter mark).

PowerMeter.PNG


I've NEVER seen my power meter even hit the 75KW mark, much less the 90KW+ that the values you posted above would imply. And I've tried. :wink:

So, as Ingineer has subsequently posted, if those are the limits the BMS the DI is being held to by the BMS, then it would be necessary to find a way to tell the DI it's OK to reach for those limits...

Looks like we'd need a way to build a "High" regen CAN msg to send to the DI, in addition to the Low and Standard settings the CID sends...
 
@llavalle

Partly due to the MS speed and bus load not a lot of devices can handle it, and those that can tend to be subject to any minor adjustments to either software or drivers, reading from a CAN transceivers SPI bus just a little too slowly (or having a poorly written driver) can mean the difference between constant error messages or successful logging. If you are interested in do some work in this area, another Canadian owner and I have been writing some software (GUI and console based) for logging and displaying messages using the CANtact, a low cost ($60) board available here, lots of progress on our front and more to come. The biggest advantage that the CANdue (from EVTV) has is being compatible with Collin Kidders SavvyCAN software, which enables logging and analyzing of the bus, the issue is the rather highly priced Arduino Due board, yes it's cheaper than a new Kvaser or Vector device but at over $100 shipped (more so to Canada) it doesn’t promise to be such a great deal (I got some Kvaser stuff of eBay for maybe $70 more than the CANdue shipped), plus I have written python software to reformat the output of the CANtact to a file format that SavvyCAN can read (so no logging but analysis features).

There are a lot of options out there depending on your comfort or skill level (plus what you already have laying around), send me a PM if you are interested in learning more, I'd be happy to help get you jumpstarted.

Personally I'm a fan of the CANDue 2.0 boards because they've got more features than most anything. Yes, they are expensive. You can most certainly find cheaper canbus adapters than $150. But, my hope is that it still seems worth it to some people for the following reasons: it has two CAN buses so you can log two buses at once, both are isolated (which seems to be a rarity), the firmware is open source so you can do whatever you want with it, it has a microSD slot and the default firmware is capable of automatically writing to the card with auto incrementing filenames (no need for a PC).

But, there are plenty of options out there. You mentioned the CANTact. It's a decent board. It's half the price. It isn't isolated, it doesn't have two buses, it has no SDCard slot. But, it's also open source and Eric seems like a very capable guy. So, my opinion is that it's a fine device but targeted at a somewhat different demographic. That's actually very nice. I'm a fan of options and I know one size does not fit all. One thing I would suggest against would be the use of really low end (read: less than $50) hardware. It's very unlikely to be reliable enough. But, sure, a cantact is fine. I have a Kvaser leaf light and that's a great device if you can find one reasonably priced. There are lots of options that will work fine.

On the software side, it seems like a lot of people like to write their own. That's why I wrote SavvyCAN - I didn't like the other options out there and they didn't do what I wanted them to do. So, I contributed to the large number of PC based CAN programs. But, frankly I wasn't impressed with the existing options. They were usually very limited or very expensive. One notable exception is BusMaster. It's a very large, very capable program. It has many similarities to Vector's programs (CANAlyzer, etc) but instead is free and open source. Unfortunately it is windows only and somewhat complicated and irritating to use. But, it's capable and I do use it sometimes. Eric Evenchick, who made the CANTact, also wrote python programs that run on the PC and interface with his hardware. So, those can be used as a stepping stone too.

So, yeah, lots of options. I helped make some of them. If you don't use my stuff I promise I won't mop around for too long or anything.
 
It is indeed non-linear, but the next two tick marks on the power meter would ostensibly be 75KW (darker mark) and then 90KW (lighter mark).

I wonder if it's worth it on RWD cars. the continuous rating of the motor/inverter is only 69kW. I have no idea how long before that limit kicks in, but I wonder if Tesla have set it below the continuous rating on purpose to prevent any possibility for it to cause issues. My thinking is it's possible to exceed this coming down a long steep hill.
 
@W.Petefish

Not to be condescending, but unlike Tesla I don't need to be cloak and dagger about the details of how the CAN bus works. I document what connectors you need and what buses are on what pins over at my instructable page (posted a year ago now) showing anybody whose interested how they can access a car they bought and paid for.

Based on my research the bus speeds are as follow:
Powertrain (CAN3) = 500kbps
Chassis (CAN6) = 500kbps
Body Fault Tolerant (CAN4) = 125kbps
Body (CAN2) = 125kbps

Now that I think of it, I should probably update my article to include that...
 
Plug one into a car expecting true phases on the pins and magic smoke escapes from that car. So some people are still insisting on Type-2.

This shouldn't be true. Plugging one of these into a car expecting three different phases will result in 0V differential between phases; it shouldn't let out the smoke, but rather things will just not work if they have electronics that use L-L instead of L-N. Is there anywhere I can read about why they let out magic smoke?

- - - Updated - - -

AC? I've never seen over 118 kW DC at a SpC.

Same here.
 
@apacheguy @lolachampcar

I am flirting with two different options (I may end up doing both), one is using the Particle Electron (I backed it on KS so I should be getting one in a month or so) to make a completely wireless data logger that could transmit back to dropbox/custom server or the website Teslalogs (which I'm co-developer on) possibly all of the above, the nice part is that you don't have to remember to keep the car on when you bring it back to your home and make sure you have WIFI coverage where you park the car. The second option is an in car data logger with display that mimics Tesla's thermal and battery diagnostics screens (not all of us want to open our dash like wk057), this hardware stack is based on the Beaglebone Black with a 7" LCD touchscreen, below is a beta version of the python app that me and another owner have built, still lots of work to do, not enough hours in the day.

IMG_0967.jpeg
IMG_0971.jpeg
 
Hi.. Awesome thread! I'd like to interface CAN3 with a Raspberry Pi. Is there a somewhat inexpensive off-the-shelf board/hat/device that I can buy with existing drivers? It seems like Kvaser Leaf would work, but it is a bit expensive for what I want to do.
 
obrien,
That looks nice... I'm on the far other end with a super small dedicated logger and a requirement for something that can open the txt log file treating the logger as a thumb drive. I'm looking at it purely for diagnostics (the battery stuff) and car related performance data (TC slip, power to motors, power from battery and the like plus wheel speed(s)) at a 100 Hz and logging in burst mode to capture just the events of interest. It is a very narrowly focused effort.

I'm also terribly ole fashioned in that I prefer working in C and using FreeScale's micros.
 
@zdre

I haven't tried it out yet (don't like the pi for a couple reasons), but this (CAN-pi) project on Hack-a-day seems like a nice option if you are handy with a soldering iron.

Here are some links to tutorials on setting things up
CAN Bus Module Tutorial for Arduino, Raspberry Pi and Intel Galileo
CANned Pi: (Part1) - CowFish Studios
I looked into this one, but I'm not sure it will work since it uses MCP2515 chip which someone mentioned did not work so well for Tesla's bus. Thanks for your instructable by the way.. Lots of useful info
 
@zdre

As I mentioned before, the MS is very sensitive to software and driver quality, I have seen the MCP chip work exceptionally well on some devices (like the CANtact) while fail miserably on others (CANbus Triple, TowerTech BB CAN cape). That said even with poor drivers single ID or less than a dozen ID logging should work regardless based on my experience.
 
Personally I'm a fan of the CANDue 2.0 boards because they've got more features than most anything. Yes, they are expensive. You can most certainly find cheaper canbus adapters than $150. But, my hope is that it still seems worth it to some people for the following reasons: it has two CAN buses so you can log two buses at once, both are isolated (which seems to be a rarity), the firmware is open source so you can do whatever you want with it, it has a microSD slot and the default firmware is capable of automatically writing to the card with auto incrementing filenames (no need for a PC).
Collin, the CANDue 2.0 sounds interesting. Are there any schematics?

I think we should all team up and roll a Model-S specific board with logging, MITM, etc. No need to make it Arduino "shield" compatible. 2 CAN busses, one on the PT bus, with jumpers to select which bus the 2nd CAN xceiver is on. Micro SD slot. Maybe even a WiFi module on the back so it can be accessed remotely without opening the dash.

It could even be constructed so as to fit right into the connector as a little "dongle", thus making it cheap and compact. Here's my quick 'n dirty mock-up:
cantesla.jpg

(Please excuse the crudity of this model. I didn't have time to build it to scale or paint it, but you get the idea.)

Thoughts? Who is interested in such a thing?