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.

lolachampcar

Well-Known Member
Nov 26, 2012
6,469
9,368
WPB Florida
I started this thread to put the hardware logging and graphical analysis stuff in one place. I will update the thread with drop box links to data as I collect it and welcome those that want to test and/or develop utilities to learn from collected data.

Special thanks to WK for providing CAN bus message decoding such that data loggers can be built.

I'll start with some data from a 0_60 using launch mode starting in the rain with traction events :) Here is a small excerpt showing just how much torque is loaded up against the brakes before launch :)
Dropbox - PerfWetLaunchMode0_60_1_28_16.txt

Time......TPS....Speed.....R_Tq...F_Tq....BatV.....BatI.....Pwr
6126.98 000.0 +000.00 -002.2 +000.0 373.16 -0005.8 002.1
6127.00 000.0 +000.00 -002.0 +000.0 373.06 -0005.2 001.9
6127.02 000.0 +000.00 -001.8 +000.0 373.42 -0004.8 001.7
6127.04 000.0 +000.00 -001.6 +000.0 373.41 -0005.3 001.9
6127.06 031.6 +000.00 -001.2 +000.0 373.03 -0007.0 002.6
6127.08 090.8 +000.00 +033.9 -005.1 371.67 -0029.7 011.0
6127.10 100.0 +000.00 +108.2 -049.4 371.54 -0035.0 013.0
6127.12 100.0 +000.00 +097.5 -057.1 372.05 -0027.7 010.3
6127.14 100.0 +000.00 +095.3 -008.1 372.17 -0023.9 008.8
6127.16 100.0 +000.00 +094.4 +030.4 372.30 -0022.1 008.2
6127.18 100.0 +000.00 +089.4 +043.8 372.17 -0022.9 008.5
6127.20 100.0 +000.00 +085.3 +046.0 372.17 -0024.4 009.0
6127.22 100.0 +000.00 +083.1 +049.9 371.67 -0023.9 008.8
6127.24 100.0 +000.00 +088.5 +055.5 372.17 -0025.4 009.4
6127.26 100.0 +000.00 +106.7 +061.4 371.68 -0029.8 011.0
6127.28 100.0 +000.00 +123.7 +066.5 371.30 -0035.0 012.9
6127.30 100.0 +000.00 +133.6 +071.5 371.41 -0036.8 013.6
6127.32 100.0 +000.00 +143.8 +076.3 370.79 -0039.1 014.4
6127.34 100.0 +000.00 +153.9 +080.9 370.91 -0040.6 015.0
6127.36 100.0 +000.00 +164.4 +085.7 371.05 -0043.2 016.0
6127.38 100.0 +000.00 +178.3 +090.5 370.79 -0044.2 016.3
6127.40 100.0 +000.00 +190.1 +095.1 370.40 -0048.9 018.1
6127.42 100.0 +000.00 +196.5 +100.1 370.40 -0055.2 020.4
6127.44 100.0 +000.00 +203.3 +105.8 369.50 -0059.9 022.1
6127.46 100.0 +000.00 +226.9 +111.1 369.77 -0063.9 023.6
6127.48 100.0 +000.00 +240.8 +117.4 369.27 -0070.0 025.8
6127.50 100.0 +000.00 +255.0 +123.5 369.27 -0072.6 026.8
6127.52 100.0 +000.00 +267.3 +128.3 368.90 -0073.6 027.1
6127.54 100.0 +000.00 +280.8 +133.8 368.77 -0076.9 028.3
6127.56 100.0 +000.00 +292.2 +138.4 368.27 -0080.4 029.6
6127.58 100.0 +000.00 +296.8 +142.9 367.89 -0087.9 032.3
6127.60 100.0 +000.00 +312.1 +147.8 367.64 -0092.5 034.0
6127.62 100.0 +000.00 +321.9 +153.7 367.39 -0100.6 036.9
6127.64 100.0 +000.00 +333.3 +159.6 366.74 -0109.5 040.1
6127.66 100.0 +000.00 +343.5 +165.0 366.50 -0112.0 041.0
6127.68 100.0 +000.00 +351.6 +170.7 367.39 -0102.1 037.5
6127.70 100.0 +000.00 +354.2 +176.0 367.40 -0097.5 035.8
6127.72 100.0 +000.00 +350.8 +174.8 367.39 -0099.0 036.3
6127.74 100.0 +000.00 +349.0 +172.7 367.03 -0097.1 035.6
6127.76 100.0 +000.00 +348.3 +163.0 367.42 -0097.1 035.6
6127.78 100.0 +000.00 +347.3 +167.9 367.53 -0098.8 036.3
6127.80 100.0 +000.00 +347.5 +165.9 367.28 -0099.4 036.5
6127.82 100.0 +000.00 +339.6 +173.5 367.16 -0097.7 035.8
6127.84 100.0 +000.00 +335.5 +176.0 367.40 -0098.1 036.0
6127.86 100.0 +000.00 +348.4 +174.0 367.39 -0099.7 036.6
6127.88 100.0 +000.00 +352.3 +172.0 366.74 -0099.0 036.3
SoC 074.6 BatT 30.32 BatOdo 015316

- - - Updated - - -

I took one of my OBDii tools (reflasher, data logger, scan tool, etc.) and repurposed it to do the Model S Chassis Bus CAN logging. The cable was purchased from FastTech and I simply added a DB-9 connector wired onto my board to connect +12V, Ground, CAN+ and CAN-. I'm not sure how I'm going to package this in a more robust way for others to use. I'll figure out something.

Only one of the 4 Mbyte flash parts is populated which normally turns out to be more than enough for logging data.
 

Attachments

  • IMG_1434.jpg
    IMG_1434.jpg
    1.5 MB · Views: 430
  • Cables.jpg
    Cables.jpg
    1.7 MB · Views: 320
There is some other published CAN bus stuff that I've got bookmarked at home as well as someone from the forum who has posted presentations from TMC Connect on the subject (maybe the same guy). I've also been doing some of my own very weak research on the subject. It might make sense to establish a wiki somewhere so that anyone can add their observations and we can open source this effort a bit. If no one else steps up, I could probably manage something. My current area of research interest is to try to figure out what in the heck happens during that last section of charging when we think they are balancing the pack. I've also promised to share some 0-60 performance data captures post ludicrous update with lola and wk, and I think the ground is just about dry enough to give that shot soon.
 
I found one of the sources I've seen. O'Brien28 posted about it on the forum as Exploring the Model S CAN Bus. If you read his instructable, it appears that he has a number of irons in the fire. Of particular interest are his mappings for CAN-2 and CAN-3.

We should probably post a link to wk057's PDF and I'll try to find the PowerPoint from TMC Connect. Looking at the Instructable, I'm pretty sure that it was also from O'Brien28. It's pretty clear that there are least three (probably four) different groups decoding messages, none of whom appear to share their information with each other. I can see some valid reasons to keep some stuff private, but by and large I think sharing information like I've seen on other CAN explorations with other cars would make more sense, unless you intend to make a commercial product.
 
Standing on the shoulders of giants somewhat, I've built a little on the work lola has done and knocked up a first pass at a UI for reading the log outputs from this device, and providing some visualization of the output:

LoggingApp.png


Nothing earth shattering TBH just a couple of hours in C# (most of which was dusting off some of the old mental cobwebs using built in Microsoft chart stuff. ) but it gives a feel.

Happy to stick source up the source in GitHub/CodePlex / wherever. (Embarrassingly admits this is his first open source project :redface: ) In the meantime: Dropbox - TeslaGraph

My bigger plans were to make this hosted so you could just upload a file and not install anything client side.. my aim is to make sure the code is written in such a way I can push it over onto ASP.NET without much trouble, and give both options.
 
LGF,

Here are two records from the battery health version of my logger....

3.344 3.345 3.346 3.345 3.344 3.345 3.346 3.346 3.346 3.346 3.346 3.346 3.345 3.343 3.345 3.345 3.345 3.345 3.344 3.345 3.345 3.343 3.344 3.344 3.348 3.346 3.347 3.346 3.346 3.348 3.345 3.346 3.346 3.345 3.346 3.346 3.347 3.346 3.345 3.346 3.346 3.346 3.345 3.343 3.345 3.345 3.345 3.346 3.345 3.345 3.346 3.346 3.344 3.346 3.344 3.343 3.345 3.343 3.344 3.344 3.345 3.346 3.345 3.345 3.346 3.345 3.346 3.346 3.345 3.345 3.345 3.346 3.346 3.346 3.346 3.346 3.344 3.346 3.340 3.342 3.342 3.342 3.342 3.341 3.345 3.345 3.345 3.346 3.344 3.345 3.342 3.345 3.343 3.343 3.344 3.344 17.88 18.32 18.07 18.25 18.14 18.36 17.98 18.46 18.03 18.23 17.88 18.30 17.83 18.11 17.69 18.03 18.06 17.60 17.76 18.16 17.95 18.22 17.91 18.20 18.00 18.45 17.89 18.30 18.09 18.62 18.10 18.50
3.343 3.345 3.345 3.343 3.345 3.344 3.347 3.346 3.346 3.346 3.346 3.348 3.345 3.345 3.345 3.343 3.345 3.344 3.344 3.346 3.345 3.345 3.344 3.344 3.348 3.346 3.346 3.347 3.346 3.346 3.346 3.346 3.346 3.343 3.346 3.345 3.347 3.346 3.346 3.346 3.346 3.346 3.345 3.343 3.345 3.343 3.345 3.345 3.346 3.345 3.346 3.345 3.344 3.346 3.345 3.345 3.345 3.345 3.345 3.343 3.345 3.343 3.345 3.346 3.346 3.345 3.345 3.345 3.345 3.345 3.345 3.346 3.345 3.345 3.346 3.345 3.344 3.346 3.338 3.341 3.343 3.341 3.342 3.342 3.344 3.346 3.345 3.345 3.345 3.345 3.343 3.345 3.343 3.343 3.343 3.343 17.88 18.32 18.08 18.24 18.16 18.36 18.00 18.45 18.06 18.23 17.90 18.29 17.86 18.11 17.72 18.02 18.09 17.59 17.78 18.15 17.98 18.22 17.92 18.19 18.01 18.44 17.90 18.29 18.10 18.62 18.11 18.51

You get every cell module voltage along with the temperature of each pack and voltage and current (not shown on the above example). My plan is to stop by the super charger within the next few days and log a SC session. I'll post a drop box link to the data. I've never believed in messing with stuff while driving so have always built me tools to perform autonomously. You plug the logger in, it is powered by the car and simply does its thing. When you are done driving, you download the data and analyze.

As for the 12V, my logger can either be powered by the USB cable when connected to a PC to download the data or via 12V from the car when being used to log.

I currently have two versions of the performance logger. One uses a Throttle Position Sensor threshold (TPSThreshold) above which logging starts. When you fall below this threshold, the logger captures another five seconds of data then switches over to capture end of run State of Charge, Battery Temperature and Battery Odometer (not the same as car odometer). I picked TPS as a starting trigger but it could just as easily be tied to Current, or Front or Rear Motor Torque.

The switch version logs when you pop the switch on then, when you turn it off, the logger captures the above mentioned five seconds of data plus status info. The other version of firmware I have does the battery health stuff which takes three seconds to report the whole set battery health data. I log this as quickly as it is available along with current and voltage of the pack as a whole.

I also plan on adding switch functionality so that the user can switch between performance with TPS Threshold and Battery Health logging modes. Using the switch based performance logger will still require a firmware change. I did confirm my old drag and drop field firmware update. You literally drag the firmware file off your PC and onto the logger then unplug and replug the logger USB (or just plug it into the car) and the firmware will update automatically. This allows users to change the device's personality in the field along with allowing me to continue to develop even after sending out devices.

Many thanks to smac for the viewer. We can now look at the same very detailed high speed data that Tesla has had access to.

apache,

The board is my own and uses 12 volts as described above. If you are familiar with ICs, here is what is on the board-
The large chip is a FreeScale (NXP) JM128 micro controller with internal hardware CAN module
The two small 8 pin chips near the OBDii connector are CAN bus and ISO 9141-2 K-LINE line interface parts (the board also does legacy K-Line)
The one small 8 pin on the top part of the board is a 4 mbyte Atmel serial flash part for storage. The three empty foot prints adjacent to it are for additional flash parts but have never been used.
The rest is just power supply (lower right) to regulate the car's 12V in, a crystal for the micro (low central) and some diodes and logic switching around the USB connector on the left
 
Last edited:
rns,

That is why I posted the snippet of the log above :)

6127.80 100.0 +000.00 +347.5 +165.9 367.28 -0099.4 036.5

Throttle is the 100% when you have launch enabled and are now preparing to launch.
Speed is 0.0 because you still have your foot hard on the brake as well as the throttle.
+347.5 ft-lbs of Rear Motor Torque
+165.9 ft-lbs of Front Motor Torque
367.28 volts on the main pack
99.4 amps of power draw (- is draw down while + is regen)
36.5 KWatts of power consumption just sitting there ready to go
 
I found one of the sources I've seen. O'Brien28 posted about it on the forum as Exploring the Model S CAN Bus. If you read his instructable, it appears that he has a number of irons in the fire. Of particular interest are his mappings for CAN-2 and CAN-3.

We should probably post a link to wk057's PDF and I'll try to find the PowerPoint from TMC Connect. Looking at the Instructable, I'm pretty sure that it was also from O'Brien28. It's pretty clear that there are least three (probably four) different groups decoding messages, none of whom appear to share their information with each other. I can see some valid reasons to keep some stuff private, but by and large I think sharing information like I've seen on other CAN explorations with other cars would make more sense, unless you intend to make a commercial product.

@LetsGoFast
Actually, I started out with the MS CAN decoding long before anyone got on the scene (save for perhaps Otmar and a select few, though nobody was sharing things publicly then), wk057 has recently started working on decoding things the easy way ;-) because he has a CID and IC sitting on his bench, basically a very big decoder ring for the CAN messages. I currently have a gdocs spreadsheet with quite a lot of information in it and while I would love to share all of it for free, I feel that some members who run a certain webshow about electric cars might take unfair commercial advantage of what has been an awful lot of work on the part of me and several other engineers/owners, so for now I am keeping it invite only (likely to change in the future), if you are interested in joining and can keep a secret, just PM me a google email address and I'll be in touch.

The TMC connect presentation is actually from another member (@snooprob) who contacted me for some additional details (for the presentation) after he read my Instructables posting.
 
@lola - Pardon my ignorance, but why reinvent the wheel? Why not base your logger off of a Beaglebone, Arduino, etc. with appropriate connections?

Also, why the need for the switchable mode? Why can't it handle both streams at the same time? Sorry, not an electronics guy but curious nonetheless.
 
Apache,

there re was no reinventing. I'd did my board five plus years ago as a re flash device for ice tuners. It also logged data to aid in tuning. I still have a good number laying around and needed to exercise my brain. WK provided the decoding and I know my hardware has proper automotive hardware based CAN support thus can handle full speed CAN traffic. I'm also a bit of a snob and prefer to work with proper quality hardware rather than the audrino stuff (too many compromises).

My goal was ASCII text output directly from a small vehicle powered device. I'm almost there. I'll provide devices to other forum members that want to test, learn and share data. I have no interest in selling anything (learned my lesson with the fob I did) and zero interest in helping EVTV :)

I enjoy my peeps here and want to contribute. None of that precludes anyone from doing the exact or similar thing with an audrino or other design.

lastly, battery health data at 3 seconds per sample is not comparable with performance data at 100 samples per second. In addition, I do not want to deal with the two vastly different data sets being mixed together. Simply reaching down and selecting battery health when at the supper charger to capture a charge session then flipping the switch when I leave the SC so I can record full hot bat performance data just seemed like the smart solution. I did not want to deal with a PC or having to reconfigure the device firmware (or switch devices for that matter).
 
Last edited:
Gotcha, makes sense. Regarding the two modes. I understand that the data streams in at vastly different rates, by why not simply log battery health to one file and performance data to another? I guess I just don't understand the need for the switch.
 
@LetsGoFast
Actually, I started out with the MS CAN decoding long before anyone got on the scene (save for perhaps Otmar and a select few, though nobody was sharing things publicly then), wk057 has recently started working on decoding things the easy way :wink: because he has a CID and IC sitting on his bench, basically a very big decoder ring for the CAN messages. I currently have a gdocs spreadsheet with quite a lot of information in it and while I would love to share all of it for free, I feel that some members who run a certain webshow about electric cars might take unfair commercial advantage of what has been an awful lot of work on the part of me and several other engineers/owners, so for now I am keeping it invite only (likely to change in the future), if you are interested in joining and can keep a secret, just PM me a google email address and I'll be in touch.

The TMC connect presentation is actually from another member (@snooprob) who contacted me for some additional details (for the presentation) after he read my Instructables posting.

Thanks for clarifying. Your work does appear to be the earliest published stuff, if you don't count the Roadster stuff.

Standing on the shoulders of giants somewhat, I've built a little on the work lola has done and knocked up a first pass at a UI for reading the log outputs from this device, and providing some visualization of the output:

Nice stuff! I'd love to see this as a web service.

You get every cell module voltage along with the temperature of each pack and voltage and current (not shown on the above example). My plan is to stop by the super charger within the next few days and log a SC session. I'll post a drop box link to the data.

Awesome.
 
Nice stuff! I'd love to see this as a web service.

Certainly on the radar. Right now though it would get almost zero hits per day as AFAIK Lola has the only device required to generate that file format ;) WPF was simply quicker way to get to proof of concept.

I'm waiting on a straight forward CAN logger box to arrive from the US, so my next little project will be to replicate the aggregation work Lola has done "on device" in C#. Then I will be able to take a raw dump of the CAN messages and convert those into this (or similar) summary data structures ready for graphing.

So I see a couple of options for a future website, upload the data in raw format, do the processing there and make it nice and ubiquitous (and therefore open it up to a wider community, which lets face it is pretty small as it is), or to pre-process the messages somehow, either in a smarter logger, or in a easy to use desktop tool prior to upload. The latter has some appeal as I believe there may be some sensitive data in the CAN logs, that people would feel uncomfortable uploading to the web.

One of the reasons I took up the challenge was I wanted to have a play with .NET core, unfortunately lack of UI tools has stopped that in it's tracks, but it wouldn't be an issue for doing a small standalone aggregation generation tool, that run cross platform with minimal install and setup. So that's still on the cards.

One thing I'd like to do if I do go for a web site, is to offer a compare function. Not only could we compare cars against each other to see the difference variants have, but it would provide a virtual drag strip we could race on ;) :redface:
 
There are some interesting visualization problems with even the limited messages that are already decoded. The battery charge stuff is so number dense that it would be much better to have a graphic. I'm thinking using color gradients with a visual map of the battery pack would be the best way to represent it. You could pretty much represent each cell that way. It would also be nice to be able to replicate or improve on some of the diagnostic screens.

I'm sure you saw wk's original graph where he used multiple Y axes (same plural for ax, axe and axis, weird) so that you could more readily see speed against the power values. Might be interesting to provide alternative templates for some of the more obvious power graphs.

It is certainly a very small niche and I'd assume anyone who goes to the trouble of collecting CAN data would be reasonably technically competent. As a Unix/Linux/Mac guy, I've never installed .NET stuff at home, but I understand they have done a lot with the cross platform stuff in the past year. Depending on the tool, you can usually filter out just a subset of messages that you want to export or display to alleviate privacy concerns (although many people seem fine sharing data or even credentials from their car to other websites that would make me uncomfortable).
 
@GoFast.

For sure, putting different axes on and using a different scaling would be a definite improvement.

Saying that it got a bit crazy as I was trying to graph multiple measures all with wildly different units. It's more by luck than judgement they broadly fit within a comparable range of dimensionless values. (Well partial luck, I intentionally scaled down "CalculatedPower" from Watts to Kilowatts)

One thing that isn't clear from the screen shot is you can click the legend area, and "pulll out" each of the measurements individually into the bottom graph.

In terms of graphing improvements of this data set. I'd like to:
a) scale speed up, it is a little low compared in absolute numbers to the other measures. I could cheat and convert it into furlongs per hour ;) but a second axis would help.
b) convert front and rear torque into stacked bar charts. (Working on the theory total torque is actually a little more telling, but it's still nice to see the split)
c) allow two measures of different units to be pulled out into the bottom graph. So the top graph is a "helicopter view", and the bottom is a better way to do comparisons of say speed vs. power.

I've not even begun to think about graphing the battery stuff. But I like the idea of a info-graphic of the car. Slight caveat, it depends on the goal I guess, if you wanted to plot say temperatures vs charge rate vs time, then it might still need to end up as a traditional line graph.

As for tech choices, I guess I could do something in Java for broadest platform compatibility. I really do hope Microsoft can get some traction with .NET core, I've been working with Web stuff for decades now, and I still find it a infuriating for writing rich apps.

<rant>Silverlight / Air / Java plug-in are all on life support, and seemingly nothing to fill the void. So we carry on with spotty revolving interpretations of umpteen layers of different "standards", requiring working knowledge of at least 4 different languages of differing paradigms and syntax, with fashion of the month libraries to debug/de-foible , all dumped on top of a system originally designed to serve out academic papers being pushed way beyond it's limits to deliver rich applications.... I just put up with it as it pays the bills ;)</rant>
 
LGF and Apache,
smac picking up the ball and helping on the visualization side is exactly why I am doing this. A few people with differing views and needs can combine a modest effort to produce a very useful process.

smac,
I'm more than happy to add a total torque column to my data set if it would help. I spend most of my time waiting for CAN frames to arrive. It's a 32 bit core so another add and conversion to ASCii is dead simple.

apache,
Logging battery health and performance data at the same time just does not make sense. When I'm charging, I want to see battery health. When I'm beating on it (thus the TPS Threshold log start), I want to see high speed performance data. Too many CPU cycles to do both at the same time but, more importantly, way too much data to sift through.

Lastly, the whole reason for a stand alone bit is to remove the need for post processing for those that simply want some data to test with. Having the community having access to both full blown loggers and scaled down versions that readily provide data in engineering units will provide a full spectrum capability.
 
Last edited:
@lolacarchamp

It's super easy to just use the deserialisation in the app. For example I've added a "CalculatedPower" where I simply multiplied BattV and BattI as I streamed through the serialisation.

Effectively it looks like this:
var entry = new LogEntry()
....
entry.BatteryVolts = double.Parse(parts[5]),
entry.BatteryCurrent = -double.Parse(parts[6]),
......
entry.CalculatedPower = (entry.BatteryVolts * entry.BatteryCurrent) /1000;

Doing similar to create a total torque would be super easy. Personally I'm not a fan of storing values that can be inferred anyway. (Well not in data sets this size).




Really a question for all is determining what we want to get out of this. Like ever the hardest part is trying to vision what the final outcome we are looking to get to is.

For me it seems the goal is to allow the largest group of people, some who are less technically inclined, to be able to easily dig in to a limited subset of the logging aspects of the car. Performance and batteries being obvious low hanging fruit.
 
Last edited:
rns,

That is why I posted the snippet of the log above :)

6127.80 100.0 +000.00 +347.5 +165.9 367.28 -0099.4 036.5

Throttle is the 100% when you have launch enabled and are now preparing to launch.
Speed is 0.0 because you still have your foot hard on the brake as well as the throttle.
+347.5 ft-lbs of Rear Motor Torque
+165.9 ft-lbs of Front Motor Torque
367.28 volts on the main pack
99.4 amps of power draw (- is draw down while + is regen)
36.5 KWatts of power consumption just sitting there ready to go


:) Thank you very much for spelling it out for me, I see it now

This is very cool - that is the kind of information Tesla should use the 17" screen to display in true GT-R style - who needs to know what the radio is playing when you have this kind of information just behind the screen

That is some serious torque building up