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.
Dropbox - UPDATE_C0000A9.EBL
Dropbox - UPDATE_C0000B9.EBL
Dropbox - UPDATE_C0000C9.EBL
Dropbox - UPDATE_C0000D9.EBL

A 75% TPS Threshold for logging
B 50%
C 25%
D is switch triggered logging

Changes for version 9
Data file increased from 1 meg to 3 megs. I was mistaken on erasure time. I was already doing a complete chip erase so the larger data file does not increase erasure time.
Added switch on for logging. As usual, switch away from LED side of plastic case parting line is "Off". Plug the logger in with the switch in the down or off position. You will see the RGB LED Post sequence followed by one or two red blinks indicating the number of motors in the car. Turn the switch on to log and off to stop. When switched off, the logger's LED will go from Green to Red while it waits for a battery health temperature message (up to 3 seconds) so that it can write the end of log SoC, BatT and BatOdO values. The logger is available for the next log set after the Red LED extinguishes.

This version is not as throughly tested as the last so let me know if you find anything.

Lastly, one person asked for a logger and it fell completely off my radar. Sorry and I will remedy that today.

- - - Updated - - -

KB,

Care to take a stab at overlaying P85DL and P90DL torques, current and battery voltage? My initial take was that the only advantage the P90DL had was slightly less voltage droop under load. I suspect the torques and current profiles will overlay perfectly on compatible good traction launches while the 90's battery V will be slightly better.
 
  • Like
Reactions: benjiejr
haha, we want to see pictures or it didn't happen...plus don't you owe us a story about the hardware store--something you mentioned after the story about the little cakes.
At the risk of derailing the thread:

Ready To test.jpg

Glowing.jpg



Anyway... now the desire to be able to forge steel using my garden furniture is out of my system, I shall resume the far less dangerous job of wiring up some web pages.

As for the hardware store story. If you go to your local place and ask for:
"A long weight", "Tartan paint" , "Roadster 3.0 Aero upgrade package"

I'm sure you can come back with one to entertain us yourself ;)

- - - Updated - - -

I think Tesla is well aware that no customer car will do 10.9. See above.

One thing WK mentioned earlier did peak my interest. That is one of long term battery degradation, and it's impact on performance due to peak voltage.

Extrapolating a little: Given the shape of the battery life curve, (and admittedly scraping the barrel here in Tesla's defense), but I wonder if a brand new straight off the line, fresher than fresh pack could manage it.

(Of course coupled with losing the 100's of lbs of extras most customer P cars will be spec'd with. If things truly are torque capped by the motor not traction limited, I'd expect the weight savings to be slightly more important.) Maybe, just maybe add these together and you can get a 10.9 in brand new poverty spec P90D ?
 
  • Like
Reactions: benjiejr
I'd be willing to bet that the preset front and rear motor torque for the first second are functions apart from traction control proper. Sure, they are put in there to keep from over powering the tires but I think they are hard coded torque limits (funny, that is the term used in ICE calibration files; Torque Limits) without closed loop feedback from traction.
 
I'd be willing to bet that the preset front and rear motor torque for the first second are functions apart from traction control proper. Sure, they are put in there to keep from over powering the tires but I think they are hard coded torque limits (funny, that is the term used in ICE calibration files; Torque Limits) without closed loop feedback from traction.

Maybe. Before my tires are replaced next time I'll try some stuff. :)
 
  • Funny
Reactions: benjiejr
Maybe. Before my tires are replaced next time I'll try some stuff. :)

The implication in the statement above is that you are going to wait until --just-- before you replace your tires the next time, obviously because of the potential for damage to the existing tires.

Having come to know you at least a bit through your postings, etc., I'm going to go out on a limb and predict that while you will, in fact, be trying your stuff before your tires are replaced, it winds up happening weeks or months before. :)
 
I'd be willing to bet that the preset front and rear motor torque for the first second are functions apart from traction control proper. Sure, they are put in there to keep from over powering the tires but I think they are hard coded torque limits (funny, that is the term used in ICE calibration files; Torque Limits) without closed loop feedback from traction.
Looking at logger plots from launches under various traction conditions, I believe the dips in rear torque during the first second after launch are from closed loop feedback, where the torque is reduced based on rate of increase of rear motor RPM, so in effect that creates a hard-coded "Acceleration Limit". Once that acceleration limit is realized, better tires or a sticky track don't help.

Hard coded torque limits in the first second after launch would result in run-away wheel spin if the tires broke loose. This is the problem with fuel dragster slider clutches. They effectively have a hard-coded "Torque Limit" at launch. All is well if the crew chief guesses correctly setting the clutch so the torque is just below the force that slips the tires, but if it is just above that force, they get run-away wheel spin. As track conditions change, they scramble to re-set the clutches (no closed loop feedback is allowed).

The dips in Tesla's front torque during the first second are more mysterious to me. It seems to follow the rear torque, but not exactly. The MPH readings are much smoother than the rear RPM readings and have no upwards spikes that precede torque dips like the rear does.
 
  • Informative
Reactions: benjiejr
CAN based system "Wheel Speed" is typically a smoothed value generated by the ABS module from all four discrete wheel speed sensors.

Nice catch on the rear RPM ramp angle driving torque reduction. That perfectly explains that first flatish portion of the launch.
 
CAN based system "Wheel Speed" is typically a smoothed value generated by the ABS module from all four discrete wheel speed sensors.

Nice catch on the rear RPM ramp angle driving torque reduction. That perfectly explains that first flatish portion of the launch.
Are these 4-wheel smoothed "Wheel Speed" values the numbers reported as "MPH" by your CAN logger SW? If so, are values from the four discrete wheel speed sensors also available on the CAN? How about front motor RPM?
 
Are these 4-wheel smoothed "Wheel Speed" values the numbers reported as "MPH" by your CAN logger SW? If so, are values from the four discrete wheel speed sensors also available on the CAN? How about front motor RPM?

The wheel position sensors are on the chassis CAN I believe. There is no speed per wheel, and I'm not 100% sure the relative units for these values. But lolachampcar's logger won't see this anyway since it's on another bus entirely.
 
The wheel position sensors are on the chassis CAN I believe. There is no speed per wheel, and I'm not 100% sure the relative units for these values. But lolachampcar's logger won't see this anyway since it's on another bus entirely.
So... Which sensor is the source of the LolaLog "MPH" data? (Is it from the front motor RPM?) The MPH data is smooth with only slight peaks during launch, but maybe that's because the torque applied to the front wheels is only half the rear torque making the front tires far from slipping.
 
So... Which sensor is the source of the LolaLog "MPH" data? (Is it from the front motor RPM?) The MPH data is smooth with only slight peaks during launch, but maybe that's because the torque applied to the front wheels is only half the rear torque making the front tires far from slipping.

The MPH being used is being reported directly by the rear drive unit. What it uses to calculate it, I don't know for sure. I do know there is a message on the power train bus that specifies the calculated tire diameter, and it somehow accounts for wear too supposedly. So it probably uses this info as well.
 
The MPH being used is being reported directly by the rear drive unit. What it uses to calculate it, I don't know for sure. I do know there is a message on the power train bus that specifies the calculated tire diameter, and it somehow accounts for wear too supposedly. So it probably uses this info as well.

Interesting.

Do you know if this is the same MPH that we see reported on the instrument cluster?

If it is, and if the adjustment for tire wear is also taken into account when calculating distance traveled, that would make all the old discussions about inaccurate odometers overstating distance traveled even more interesting.
 
Interesting.

Do you know if this is the same MPH that we see reported on the instrument cluster?

If it is, and if the adjustment for tire wear is also taken into account when calculating distance traveled, that would make all the old discussions about inaccurate odometers overstating distance traveled even more interesting.

There is a message specifically for the number displayed on the IC, and it's not the same message, and it only has 1 MPH or 1 KPH resolution, depending on the preference. I'm pretty sure the car uses the more precise MPH reading (the one we've been logging) for the odometers, otherwise there would be huge errors in distance traveled calculations.
 
OK, so I'm feeling a little guilty here .... Bill has been kind enough to share one of his devices with me for data collection, and I haven't been able to contribute much (props to MikeBur and KennyBobby for their excellent work). It seems much of what I have been collecting has already been nicely reported/explored ... in particular pack balancing, 0-60 characteristics -especially current torque limits and traction control, and the mysterious torque sleep. Anyone with interesting P85D (not L) data request feel free to PM me (note, I don't have easy access to non-public roads, so please keep requests *close* to conventional legal limits).

By way of contribution, I will say that although I essentially never charge beyond 60% (I have a short daily commute - frustratingly short since I got the Model S!) my brick voltages are *remarkably* balanced. Far better than I would expect from other LiPo battery experience if only top balancing (above 93% SOC as reported) is in play. Perhaps Tesla is *very* good at initial cell selection for balance, but I suspect the BMS is doing more than we (at least I) know.

yak-55

OK, some data posted to MikeBur's Google drive in the folder "yak-55". I believe you can find it here ... Meet Google Drive – One place for all your files

I haven't done much of any analysis, but there are several 0-XX runs and a couple of "Torque Sleep" at various speeds logs there. I did "borrow" KennyBobby's (?) spreadsheet for graphing
a 0-60 run shown below ... just to show my P85D is just as boringly consistent as the next.:smile: Feel free to browse for anything of interest.

Untitled.png