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.
Is the data file size not large enough to just save all the data once you enable perf mode instead of trying to capture something before it happens? When you want perf data you already know what you are going to be doing.

If you want a pre-trigger so you can catch TPS from 0, could you use some other CAN id (e.g. the turn blinker or the high-beam toggle) as the high-rate trigger? Like an interrupt where you just monitor CAN for the headlight blink which turns on the fast recorder--then stomp it...
 
Ah, there are now three modes of operation-
Launch Mode
Fast Foot
Floppy Foot
:)

Heh, I did try hiding it the first time, though full transparency shows errs as well as unexpected data. Talking of that, here's one from today that shows either a weird capture issue - the current draw for each of the anomalous reading was > 6000 Amps - so, whilst I trust the data overall I don't know what to do with those 2 data points...
2-21-16 0-105 launch mode.PNG



Is the data file size not large enough to just save all the data once you enable perf mode instead of trying to capture something before it happens? When you want perf data you already know what you are going to be doing.

If you want a pre-trigger so you can catch TPS from 0, could you use some other CAN id (e.g. the turn blinker or the high-beam toggle) as the high-rate trigger? Like an interrupt where you just monitor CAN for the headlight blink which turns on the fast recorder--then stomp it...

Trick I'm using so far is either using launch mode or punching accelerator (causing start of recording) and then doing actual maneuver to be captured. And, for the wannabe mothers out there, the speeds beyond road limits are on a private road a friend owns - the astute could likely figure out where, though it's flat to slightly downhill primarily straight, single road, and did I mention private? If the local strip was open this early in the season, I'd be doing it there, though beggars can't be choosers ;-)

Also, there's a bunch more data and differing runs - incl. 30-50, 50-70, etc. etc in the raw excel files on the share. More going up later.

Upgrade on Monday and then comparisons can begin :)
 
  • Like
Reactions: benjiejr
...
the data overall I don't know what to do with those 2 data points...

Upgrade on Monday and then comparisons can begin :)

That run looks more like it, with the squat torques 175 F and 350 R, and the current drops back around 82 mph, etc. Maybe we can back out the motor rpm at that speed and determine if that is the motor's current limit due to back emf.

For the out of family data points in the current, i would replace them with the average of the data points on either side--add them together and divide by 2 should smooth out those spikes. Signal noise or data drop out, obviously 6000 amps would put you into warp drive...

Exciting news on the upgrade!
 
That is the first time I've seen spikes like that. Definitely toss them.

Rear motor RPM coming with the next release. I've found a way to open up the filters to add that CAN ID. No one has found a front motor rpm message yet.

I do have a switch activated Performance Logger version of firmware. As the name implies, the switch turns logging on/off.
 
Yep, killing those spikes makes sense. It was either data hiccup, warp drive engage, or batteries exploding in a supernova. Easy enough to to address, though raw data first.

Batteries seem ok, though don't know if anyone saw the module temps earlier. Concerns me a little. I thought anything beyond 50C was bad for the battery cells?
As I haven't seen much difference currently in power delivery when max battery ready vs just on, and warming, for launches I'm not inclined to use it anymore.

This run was otherwise pretty good - 0-60 in 3.33 (no rollout ;-)), 0-100 in ~9. I know o should only be comparing like for like, due to temp, tires, road conditions, etc, though is anyone else posting data on these high-level data points for p85dL yet?

Thanks for the continuing efforts on the FW updates Bill. It truly is a nice logger and I love that it captures quickly and minimizes the runtime processing. In terms of pre-buffer, looking at launch mode data vs fast foot (from graph 2 here) it looks like it takes 0.2 seconds for throttle movement from 0-100% to be captured, plus 1.5 seconds for that torque ramp up above and we likely will be able to service most requests with 2 seconds worth of data.
 
Ok, this is interesting. Two very similar runs, first slightly down hill, and second slightly up hill (the return). First with fixed anomalous data. The power knee is looking like it is time, *NOT* speed or battery related:

2-21-16 0-105 launch mode.PNG


2-21-16 0-105 launch slight uphill.PNG


Investigating a little more:

First run dataset around 6 second mark, followed by second. Formatting is gradient between Red at 1290, and Green at 1300 - note speeds are different. Numbers further along in time are solid red (ie. < 1290)
2-21-16 0-105 launch mode 6 second power falloff.PNG


2-21-16 0-105 launch mode slight uphill 6 second power falloff.PNG
 
Maybe 1300 Amps for 6 seconds is eating into the I2t margin of the main pack fuse--have to go back and dig that up later.

Interesting high-frequency limit-cycle in the R Tq during the squat on the uphill run.

Ask them if you can get a picture of the new fuse or write down the Bussmann part #, etc. so we can look up the curve for the new fuse.

Old fuse curve (630 Amp)
old_fuse_curve.png
 
Last edited:
I saw that high frequency waveform on one of my runs when the brake disks allowed some wheel movement when the rear of the car loaded up.

Mike,
Sounds like you are going to beat me to the L upgrade. I'm looking forward to your data. I'd like to see exactly what L offers and how it permits increased access to the battery.
 
Last edited:
A few data passes with updated firmware-
Dropbox - HartP85D_0_60_2_22_16.TXT

Looking at some steady state speed where rear motor rpm and wheel speed should be static I get 118 (118.1742..) rpm per MPH. Using this ratio, Rear Motor RPM would indicate 2.93 mph before wheel speed moves off zero. 0.16 seconds elapses from initial rear RPM reporting until the car reports wheel speed. I am curious to learn if this is drive line wind up or a lag in the wheel speed reporting. Graphical analysis may provide clues with power consumption. Another way to look at it is the average Rear Motor RPM is 346 rpm/2 or 173 rpm. Multiply this by 0.16 seconds * 1 min/60 seconds and you get 0.46 wheel revolutions before wheel speed presents. This could be the sum of drive line wind up and the lag necessary for a few wheel speed interrupts to occur before wheel speed can be calculated and presented on the bus.

Looks like I got a 3.37 second 0-60 without roll out as well (as MikeB).

Change log
Added extra CAN message filtering to allow for capture of Rear Motor RPM
Replaced calculated Power with Rear Motor RPM
Provided header for SoC BatT and BatODO followed by the data on the next line to aid with Excel integration

Time TPS Speed R_Tq F_Tq BatV BatI R_RPM AWD
0111.48 085.6 +000.00 +039.4 +012.9 383.07 -0029.2 +00000
0111.49 100.0 +000.00 +089.0 +034.8 381.81 -0055.9 +00003
0111.50 100.0 +000.00 +150.6 +058.8 381.31 -0066.0 +00052
0111.51 100.0 +000.00 +206.3 +079.1 380.54 -0076.4 +00155
0111.52 100.0 +000.00 +238.6 +099.2 380.79 -0076.2 +00255
0111.53 100.0 +000.00 +235.8 +115.6 381.04 -0070.7 +00331
0111.54 100.0 +000.00 +199.6 +125.7 380.78 -0070.5 +00362
0111.55 100.0 +000.00 +170.5 +129.9 380.15 -0079.0 +00360
0111.56 100.0 +000.00 +155.4 +134.4 379.28 -0092.0 +00347
0111.57 100.0 +000.00 +178.8 +142.3 377.91 -0112.8 +00331
0111.58 100.0 +000.00 +230.1 +156.9 376.81 -0132.1 +00317
0111.59 100.0 +000.00 +270.6 +175.5 375.94 -0147.0 +00311
0111.60 100.0 +000.00 +300.0 +192.3 375.18 -0158.4 +00313
0111.61 100.0 +000.00 +316.0 +206.8 374.44 -0171.6 +00326
0111.62 100.0 +000.00 +335.4 +217.7 373.56 -0185.5 +00342
0111.63 100.0 +000.00 +354.3 +225.3 373.05 -0193.1 +00347
0111.64 100.0 +000.00 +372.2 +229.5 372.67 -0202.0 +00347
0111.65 100.0 +000.25 +387.5 +233.9 372.17 -0209.8 +00346
0111.66 100.0 +000.45 +398.4 +236.9 371.77 -0217.2 +00355

0114.97 100.0 +059.50 +185.1 +160.4 295.85 -1305.9 +07168
0114.98 100.0 +059.60 +186.0 +160.6 295.86 -1290.5 +07179
0114.99 100.0 +059.70 +186.0 +160.6 295.35 -1305.1 +07191
0115.00 100.0 +059.80 +185.1 +160.0 295.34 -1293.1 +07196
0115.01 100.0 +059.95 +183.8 +159.6 295.22 -1308.7 +07212
0115.02 100.0 +060.05 +183.8 +159.4 295.72 -1289.1 +07227
0115.03 100.0 +060.15 +183.2 +159.4 296.34 -1298.3 +07250
0115.04 100.0 +060.25 +183.2 +159.3 296.10 -1291.6 +07255
0115.05 100.0 +060.35 +182.5 +159.1 295.84 -1296.1 +07259
0115.06 100.0 +060.45 +181.4 +158.9 294.47 -1300.8 +07268
0115.07 100.0 +060.60 +179.5 +158.3 295.48 -1308.5 +07293
0115.08 100.0 +060.70 +178.8 +158.0 294.73 -1312.6 +07313
SoC BatT BatOdo
085.0 28.22 016115
 
A few data passes with updated firmware-
Dropbox - HartP85D_0_60_2_22_16.TXT

Looking at some steady state speed where rear motor rpm and wheel speed should be static I get 118 (118.1742..) rpm per MPH. Using this ratio, Rear Motor RPM would indicate 2.93 mph before wheel speed moves off zero. 0.16 seconds elapses from initial rear RPM reporting until the car reports wheel speed. I am curious to learn if this is drive line wind up or a lag in the wheel speed reporting. Graphical analysis may provide clues with power consumption. Another way to look at it is the average Rear Motor RPM is 346 rpm/2 or 173 rpm. Multiply this by 0.16 seconds * 1 min/60 seconds and you get 0.46 wheel revolutions before wheel speed presents. This could be the sum of drive line wind up and the lag necessary for a few wheel speed interrupts to occur before wheel speed can be calculated and presented on the bus.

Looks like I got a 3.37 second 0-60 without roll out as well (as MikeB).

Change log
Added extra CAN message filtering to allow for capture of Rear Motor RPM
Replaced calculated Power with Rear Motor RPM
Provided header for SoC BatT and BatODO followed by the data on the next line to aid with Excel integration

Time TPS Speed R_Tq F_Tq BatV BatI R_RPM AWD
0111.48 085.6 +000.00 +039.4 +012.9 383.07 -0029.2 +00000
0111.49 100.0 +000.00 +089.0 +034.8 381.81 -0055.9 +00003
0111.50 100.0 +000.00 +150.6 +058.8 381.31 -0066.0 +00052
0111.51 100.0 +000.00 +206.3 +079.1 380.54 -0076.4 +00155
0111.52 100.0 +000.00 +238.6 +099.2 380.79 -0076.2 +00255
0111.53 100.0 +000.00 +235.8 +115.6 381.04 -0070.7 +00331
0111.54 100.0 +000.00 +199.6 +125.7 380.78 -0070.5 +00362
0111.55 100.0 +000.00 +170.5 +129.9 380.15 -0079.0 +00360
0111.56 100.0 +000.00 +155.4 +134.4 379.28 -0092.0 +00347
0111.57 100.0 +000.00 +178.8 +142.3 377.91 -0112.8 +00331
0111.58 100.0 +000.00 +230.1 +156.9 376.81 -0132.1 +00317
0111.59 100.0 +000.00 +270.6 +175.5 375.94 -0147.0 +00311
0111.60 100.0 +000.00 +300.0 +192.3 375.18 -0158.4 +00313
0111.61 100.0 +000.00 +316.0 +206.8 374.44 -0171.6 +00326
0111.62 100.0 +000.00 +335.4 +217.7 373.56 -0185.5 +00342
0111.63 100.0 +000.00 +354.3 +225.3 373.05 -0193.1 +00347
0111.64 100.0 +000.00 +372.2 +229.5 372.67 -0202.0 +00347
0111.65 100.0 +000.25 +387.5 +233.9 372.17 -0209.8 +00346
0111.66 100.0 +000.45 +398.4 +236.9 371.77 -0217.2 +00355

0114.97 100.0 +059.50 +185.1 +160.4 295.85 -1305.9 +07168
0114.98 100.0 +059.60 +186.0 +160.6 295.86 -1290.5 +07179
0114.99 100.0 +059.70 +186.0 +160.6 295.35 -1305.1 +07191
0115.00 100.0 +059.80 +185.1 +160.0 295.34 -1293.1 +07196
0115.01 100.0 +059.95 +183.8 +159.6 295.22 -1308.7 +07212
0115.02 100.0 +060.05 +183.8 +159.4 295.72 -1289.1 +07227
0115.03 100.0 +060.15 +183.2 +159.4 296.34 -1298.3 +07250
0115.04 100.0 +060.25 +183.2 +159.3 296.10 -1291.6 +07255
0115.05 100.0 +060.35 +182.5 +159.1 295.84 -1296.1 +07259
0115.06 100.0 +060.45 +181.4 +158.9 294.47 -1300.8 +07268
0115.07 100.0 +060.60 +179.5 +158.3 295.48 -1308.5 +07293
0115.08 100.0 +060.70 +178.8 +158.0 294.73 -1312.6 +07313
SoC BatT BatOdo
085.0 28.22 016115

Charts

This set of data does look interesting when you add the motor rpm into the equation:
LCC-02-22-16-Run3.PNG


And a zoom in on the first second of data - note RPM only on secondary (right) axis now, everything else on left
LCC-02-22-16-Run3 (Zoom in).PNG
 
Last edited:
So... what graphing library/software/etc are you guys using to make these nice graphs? I have mountains of CAN data (including some new P85D data), but its a PITA to make nice graphs...
 
Excel, though smac is working on an automagic way to import data. I find Excel strangely therapeutic - and I add more variables on the sheets to allow tweaking "easily".. yes, pita and likely some excel pivottable junkie could do this a lot more efficiently. Until then, feel free to steal / edit template from my google drive: https://drive.google.com/open?id=0BzwKZAn3p2LTVGRsdU9SMHpzUlk - this one is in LCC's directory, HartP85D.xlsx.

Whilst wasting BW, here's a better chart of that zoomed in data - both axis now aligned on zero, reinforcing Bill's earlier statements easier.

LCC-02-22-16-Run3 (Zoom in).PNG
 
Last edited:
  • Like
Reactions: benjiejr
Excel, though smac is working on an automagic way to import data. I find Excel strangely therapeutic - and I add more variables on the sheets to allow tweaking "easily".. yes, pita and likely some excel pivottable junkie could do this a lot more efficiently. Until then, feel free to steal / edit template from my google drive: https://drive.google.com/open?id=0BzwKZAn3p2LTVGRsdU9SMHpzUlk - this one is in LCC's directory, HartP85D.xlsx.


Ah Excel the swiss army knife of the IT world :)

Personally I'm using the built in .NET graphing functionality. I keep meaning to put some time in to port it to ASP.NET so I can get it publicly hosted . I think I have some unclaimed corporate Azure credits somewhere.

(Though as Kenny hinted at, I've recently bought myself a plasma cutter and a welder, so non IT projects and a break from my day job are getting a bit more focus right now :redface:)
 
Ah Excel the swiss army knife of the IT world :)

Personally I'm using the built in .NET graphing functionality. I keep meaning to put some time in to port it to ASP.NET so I can get it publicly hosted . I think I have some unclaimed corporate Azure credits somewhere.

(Though as Kenny hinted at, I've recently bought myself a plasma cutter and a welder, so non IT projects and a break from my day job are getting a bit more focus right now :redface:)

It's pretty simple graphing, so both of these are likely overkill - was thinking of finding some quality time, VS and imGUI, though that would have to be for realtime visualization. Already have a seriously over powered compute stick itching to get involved here, though until I see a way to easily display this data on the 17" I'm content with offline visualization :)


I do love the Zen nature of your new toys, btw. I fully expect the forthcoming title: "Zen and the Art of Cutting and Welding" - I'd buy that for a quid / dollar ;-)
 
Maybe 1300 Amps for 6 seconds is eating into the I2t margin of the main pack fuse--have to go back and dig that up later.

Interesting high-frequency limit-cycle in the R Tq during the squat on the uphill run.

Ask them if you can get a picture of the new fuse or write down the Bussmann part #, etc. so we can look up the curve for the new fuse.

Old fuse curve (630 Amp)
View attachment 112243

Car is done. I pick it up tomorrow morning. Was interesting to see some of the testing, via TeslaLog, that 0-60 on 23% of battery was showing some interesting battery draw ability though times were pretty slow (I guess I shouldn't complain about the technicians respecting my car - they're a great bunch :)), and they did manage to pull 350Wh at ~23% SoC pretty easily. If I'd been able I could have picked the car up today, so that would have been same day. Pretty impressive.
I'll see if they will tell me tomorrow about the fuse, though thought this was a special fuse and electronically triggered? (maybe my brain is even more addled here than usual? :))
 
Mike,
Fantastic graphs...
I'm doubling down on my theory that there is an initial programmed wind up of the system whereby Tesla slams the car with a bunch of torque to get the rear started then backs off. Either that or my choice of tires has such different slip characteristics that there is an initial jerk that the launch/traction control system is compelled to control.

Love the Motor RPM shining a huge flashlight on the traction event that follows :)

Sure would love to lure some X90D, DL and P90D, DL folks to this thread. I've got a few more loggers and would love to see some data for X to S comparison.

The traction control period appears to be about 0.08 seconds which is phenomenally fast and explains that "skitter" noise I here on traction events.
 
Did you ever post how much you and the car weigh? i just go to one of the local truck scales to get a reading for $10, accurate within 10 lbs.

From the zoom chart the initial current ramps up to a peak which leads the Rtorque by about 10-15 msec, which then leads the Rrpm by 20-25 ms. There is a little pull-back in current just 20 ms later and the Rt and Rrpm follow with a little more lag time. Intuitively this is what you would expect and it is a fast and tight control loop.

The first motion detected in speed occurs at a combined F+Rtorque of ~600 ft-lbs x 9.7 = 5820 ft-lbs. The tires are about 1 ft radius so i'm calling it 5820 lbs launch force.

The acceleration in the first time step is 36.6 ft/sec^2, or 1.136 g. So i'll guess that you and the car weighs 5123 lbs.

Also amazing is how it makes peak torque early on with only ~200 amps and 75kW.
 
Last edited: