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

Chassis CAN Logging To ASCII Text Plus Graphing

This site may earn commission on affiliate links.
I'd be happy to lend a hand here. I'm fluent in C# and Java and I've done some hardcore high performance stuff (yep, in a compiled to bytecode language!).
The joys of modern processors :)

I also had the idea to use usb-otg on Android. That could make a very useful platform for live data and storage.

I like the sound of that. I know it isn't the aim of lola's device, but a simple CAN to USB gateway straight into an android device via otg and we could easily move this into a
real time thing which would be very cool!
 
Guys, a question.... These CAN bus messages... Is there a component on the CAN bus that stores them in a file structure? If so, is the so called "LOG FILE" that Tesla can upload from your model S essentially a dump of this file structure data?

Also, how many subsystems create or originate these CAN bus messages? Is there a mapping of transaction type to source or originator system?

For instance, is the Air Suspension subsystem on the CAN bus?
 
Guys, a question.... These CAN bus messages... Is there a component on the CAN bus that stores them in a file structure? If so, is the so called "LOG FILE" that Tesla can upload from your model S essentially a dump of this file structure data?

Also, how many subsystems create or originate these CAN bus messages? Is there a mapping of transaction type to source or originator system?

For instance, is the Air Suspension subsystem on the CAN bus?

I haven't got my logger yet, but I very much doubt Tesla is capturing all messages. By all accounts it is a very busy network, and would soon fill up a log file.

There are is also more than one bus. The one we are logging here is used by the motor and batteries. There are at least 2 other CAN busses for other stuff, and I'm not sure which one air suspension sits on.
 
Can we get a count off of all the folks who are working on a logger? Platform, capabilities, etc.? I may end up borrowing one of Lola's, but ultimately I'd like a permanent setup.

I should start working on something within the next 2 weeks or so. Still waiting for some hardware to arrive here and I'll be out of the country next week (work related).

I'll be using the "CANtact" device. It is open source (board & all) so I like that. Once I have something working I'll share.
 
I like the sound of that. I know it isn't the aim of lola's device, but a simple CAN to USB gateway straight into an android device via otg and we could easily move this into a
real time thing which would be very cool!

And then onto the 17" display next?


Some progress on Android Auto integration. Right now it's in a state where I can see it running on Tesla: AndroidAuto - YouTube

Yep. I'm planning to run it on the central console, probably in place of the browser.
 
Guys, a question.... These CAN bus messages... Is there a component on the CAN bus that stores them in a file structure? If so, is the so called "LOG FILE" that Tesla can upload from your model S essentially a dump of this file structure data?

No, there is way too much data. Likely one or more controllers would log certain values and serious errors, but there is way they can store and transmit every single message from all the CAN buses.

Also, how many subsystems create or originate these CAN bus messages? Is there a mapping of transaction type to source or originator system?

No one has publicly claimed to know for certain every message and its mapping. There are multiple groups attempting to decode the mapping and source and originators. I think we collectively likely know most of the devices that are talking, but not the meaning of all the data bytes. It is likely to be a rapidly moving target, especially since wk057 has the capability to both look at code and play back can messages to diagnostic mode on his bench.

For instance, is the Air Suspension subsystem on the CAN bus?

Yep. On CAN-6 (chassis bus)
 
@lola - Thanks for the responses.

Can we get a count off of all the folks who are working on a logger? Platform, capabilities, etc.? I may end up borrowing one of Lola's, but ultimately I'd like a permanent setup.

Lots of people like Eric Evenchick's CANtact hardware along with possibly the CANard software. The CANtact is open source as is CANard. CANard is a set of python scripts and so is very cross platform. CANtact supports socketcan via the lawicel protocol so you can use pretty much any linux canbus utility with it. You will require a connection to a computer of some sort as this board has no storage. Thus, logging will be done with a PC but it can be running pretty well any operating system.

I wrote the software for the EVTVDue, CANDue 2.0, and GEVCU boards. I don't think that all of the designs for those are all that easy to find but there are probably some versions of the board files to be found somewhere, I don't know. I didn't really build the hardware, just the software. And, the software most certainly is open source.

The EVTVDue is pretty comparable to the CANtact with a few differences: it is really an Arduino Due with added transceiver (and a USB-B plug) so you can add more shields to it if you want. Also, the EVTVDue uses the same processor as the Arduino Due which is something like twice the speed of the STM32 processor on the CANtact. That probably doesn't make a lot of difference.

The GEVCU is really an ECU and not meant for this sort of thing (it just can be used for logging and reverse engineering if you need an ECU eventually and don't want to buy two tools).

So, that leaves the CANDue 2.0 of which I am the most proud to be associated with. It is a shield that is placed onto an Arduino Due. This shield has several advantages over most any other project you could find in the sub-$200 range. It has two CAN buses so you can log on two buses at once. Both buses are isolated so nasty noise on the CAN lines will not mess up the microprocessor or your computer. It also has a microSD card slot and the ability to log to the card given nothing but power and CAN. So, it can be used as a dedicated data logger that is installed in the car all of the time. Thus, I'd say it is very feature complete. All of the boards run the same firmware which supports connection to the open source savvycan program I wrote. SavvyCAN is QT based and available for windows, OSX, and linux. So, it's pretty cross platform. Also, the firmware that runs on the hardware is capable of LAWICEL / SocketCAN mode just like the CANtact so you can use it with linux can utilities.

Technically you can easily use the GVRET firmware I wrote with a wide range of Arduino Due based canbus devices. Basically all you need is a Due compatible board and some canbus transceivers. Then the firmware can be pretty easily retrofitted to work.

So, there's some options.
.

- - - Updated - - -

I haven't got my logger yet, but I very much doubt Tesla is capturing all messages. By all accounts it is a very busy network, and would soon fill up a log file.

There are is also more than one bus. The one we are logging here is used by the motor and batteries. There are at least 2 other CAN busses for other stuff, and I'm not sure which one air suspension sits on.

Yeah, CAN6 (drivetrain) has something like 1500 to 2000 messages per second. Each message could be stored with a 32 bit ID that includes length in the upper three bits (can is 11 or 29 bits), and 8 data bytes. That's 9 bytes per message at a bare minimum. That's something like an average of 15.8 kilobytes per second for that one bus. That's 54MB per hour. If you figure that the total traffic in the car is around three times the amount of the drivetrain bus then you could figure something like 150MB per hour total. That's a lot to capture and store.
 
I've found a couple piles of raw boards and have quite a bit of the BoM with most the passives on reels. I've no interest in assembling and selling but if others want to kick in with the work side of it, I'll donate what I have to the cause and perhaps we can generate a boards for the community. The board ran about $50 in 100 piece quantities hand assembled and without the plastic housing and OBDii connector. Given I already have the boards, processors, and passives there will likely be little else remaining to be bought.

The tasks would be-
Purchase the remainder of the BoM
Assemble
Pre-program and test (I've got this one as I am set up to both program and have a loop back test fixture)
Purchase diag cables from Fast Tech

If there are others willing to pick up some of the balls, I'll toss everything I've got into the pot. The parts were all purchased a long time ago for other projects so I do not need to get anything out of them. It would seem wise to assemble in the US instead of shipping across the pond for assembly then back to the US for programming and a majority of the distribution.
 
Logged a SuperCharger session with the Battery Health profile. Here is where it ended up at charge termination-




BatOdo 015417
3133.21 099.9 402.38 +0013.5 005.4 4.194 4.196 4.196 4.197 4.196 4.195 4.189 4.190 4.190 4.190 4.188 4.189 4.191 4.192 4.191 4.191 4.191 4.190 4.189 4.191 4.190 4.191 4.190 4.189 4.193 4.195 4.195 4.195 4.195 4.192 4.194 4.195 4.194 4.195 4.193 4.193 4.195 4.196 4.196 4.196 4.195 4.194 4.191 4.192 4.193 4.193 4.192 4.191 4.192 4.194 4.194 4.195 4.190 4.193 4.183 4.185 4.185 4.185 4.184 4.183 4.183 4.185 4.185 4.185 4.184 4.182 4.191 4.191 4.192 4.192 4.190 4.190 4.194 4.194 4.194 4.194 4.194 4.192 4.194 4.197 4.196 4.197 4.197 4.196 4.191 4.192 4.192 4.193 4.192 4.192 4.192 4.193 4.192 4.192 4.192 4.191 31.64 32.35 31.85 32.27 31.96 32.47 31.76 32.57 32.00 32.44 31.86 32.63 32.05 32.58 32.26 32.66 32.74 32.57 31.93 32.35 32.02 32.20 31.85 32.13 31.93 32.42 31.82 32.31 32.00 32.63 31.88 32.37
3136.41 100.0 402.53 +0013.6 005.4 4.195 4.196 4.197 4.196 4.196 4.195 4.188 4.190 4.190 4.190 4.189 4.189 4.191 4.192 4.191 4.191 4.191 4.190 4.189 4.192 4.189 4.191 4.189 4.189 4.193 4.195 4.194 4.195 4.194 4.192 4.193 4.195 4.194 4.194 4.194 4.193 4.194 4.196 4.197 4.196 4.195 4.194 4.191 4.192 4.193 4.193 4.192 4.191 4.192 4.195 4.194 4.195 4.191 4.193 4.183 4.185 4.185 4.185 4.184 4.184 4.183 4.185 4.184 4.184 4.184 4.182 4.191 4.191 4.191 4.191 4.190 4.190 4.194 4.195 4.194 4.194 4.194 4.193 4.194 4.197 4.196 4.197 4.196 4.196 4.191 4.192 4.192 4.192 4.192 4.191 4.192 4.193 4.193 4.192 4.192 4.191 31.64 32.35 31.85 32.27 31.96 32.47 31.75 32.57 32.00 32.43 31.86 32.63 32.05 32.58 32.25 32.66 32.74 32.55 31.93 32.35 32.02 32.20 31.85 32.13 31.93 32.42 31.82 32.31 32.00 32.63 31.88 32.37

The BatOdo is at the top of every session to document miles on the battery at time of recording.
I've only included two records where it ticked over to 100% SoC.
The first value (3136.41) is time in seconds. The car puts out one complete set of CAN messages for battery health about every three seconds.
The second number (100.0) is State of Charge.
The third is pack voltage, the fourth pack current and the fifth is the product of the two or power in KW.
The remainder are each cell sheet's voltage followed by the module temperatures in DegC.

By the looks of the above, I need to knock recording down by three to something like one complete record per ten seconds. I recorded a meg of data with just this session and I was nowhere near empty.

Any thoughts?

DropBox link for the file
Dropbox - SC1_31_16.TXT
 
Here's what the Cell Sheet or Brick voltages looked like at 114kW on the supercharger. Interesting pattern.

SC_session.png



And at the end.

SC_end.png
 
Last edited:
  • Like
Reactions: PhysicsGuy
for those more intimately familiar with LiOn cells, what are normal or acceptable cell differentials in a well balanced series pack?

You just did a range charge so you triggered the balancing. One of the interesting things to examine is what happens to the voltage of each brick after the range charge. How balanced will they get after 3 / 6 / 12 / 24 hours?
 
  • Like
Reactions: PhysicsGuy
You just did a range charge so you triggered the balancing. One of the interesting things to examine is what happens to the voltage of each brick after the range charge. How balanced will they get after 3 / 6 / 12 / 24 hours?

I thought the balancing was what caused the range charge to indicate some minutes to go, while taking perhaps 30 to an hour more. Is that not the case? Is a balance still taking place after the "Charge Complete" message, or are you trying to say the "Charge Complete" message can be delayed up to 12+ hours? Confused.
 
The first record is last night with the second this morning without the car being moved since coming home from the SC about four yesterday afternoon-

0047.45 097.9 396.97 -0000.7 000.2 4.137 4.135 4.136 4.135 4.137 4.136 4.135 4.135 4.135 4.135 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.135 4.137 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.137 4.137 4.136 4.137 4.136 4.136 4.136 4.137 4.136 4.137 4.136 4.136 4.136 4.137 4.136 4.136 4.136 4.136 4.135 4.136 4.136 4.137 4.135 4.136 4.134 4.134 4.133 4.133 4.133 4.133 4.134 4.134 4.134 4.134 4.134 4.133 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.136 4.134 4.135 4.135 4.135 4.135 4.135 4.135 4.135 4.135 4.135 4.135 4.136 4.136 4.136 4.136 4.136 4.136 4.136 27.52 27.74 27.69 27.65 27.76 27.83 27.55 27.89 27.71 27.69 27.64 28.00 27.56 27.81 27.69 27.75 28.17 28.03 27.41 27.45 27.70 27.58 27.55 27.48 27.61 27.71 27.54 27.60 27.78 28.02 27.52 27.71
BatOdo 015423
0016.62 097.4 396.29 -0001.2 000.4 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.129 4.128 4.128 4.128 4.128 4.129 4.128 4.129 4.129 4.129 4.129 4.129 4.128 4.129 4.128 4.129 4.129 4.128 4.128 4.128 4.129 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.129 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.129 4.129 4.128 4.128 4.128 4.128 4.128 4.128 4.126 4.126 4.127 4.126 4.126 4.126 4.126 4.126 4.126 4.126 4.126 4.125 4.129 4.128 4.129 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.129 4.126 4.127 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.128 4.129 4.128 4.129 4.128 4.128 4.128 23.81 23.98 24.05 24.01 24.14 24.16 23.95 24.27 24.08 24.05 23.98 24.20 24.04 24.11 23.92 24.00 24.08 23.99 23.89 24.10 24.01 24.05 23.89 23.92 23.97 24.17 23.83 23.98 24.09 24.39 23.97 24.20




There is also a dry 0-60 higher SoC run in the data set (this was the switch version of the code that lets you choose between Battery Health and Performance Logging)
0923.47 100.0 +000.00 +389.6 +241.5 378.58 -0203.6 077.0
0923.48 100.0 +000.25 +399.2 +241.7 377.95 -0211.5 079.9

0926.84 012.4 +058.00 +179.5 +163.9 293.60 -1301.1 382.0 oops, lifted too soon. Still significantly faster than wet runs with lower SoC. Looks like it would have been a 3.5 second run without roll out. Next will be back to back full SoC with and without launch mode on the same piece of pavement.
SoC 094.9 BatT 26.64 BatOdo 015429

Dropbox - BatLeveland0_60dryHighSoC.TXT