Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register
  • Want to remove ads? Register an account and login to see fewer ads, and become a Supporting Member to remove almost all ads.
  • Tesla's Supercharger Team was recently laid off. We discuss what this means for the company on today's TMC Podcast streaming live at 1PM PDT. You can watch on X or on YouTube where you can participate in the live chat.

Chassis CAN Logging To ASCII Text Plus Graphing

This site may earn commission on affiliate links.
#301
kennybobby said:
Here are some charts from Bill's slip start testing at ~80%SOC of post #287. Run 1 is normal ff launch and runs2-3 are using slip start.

<snip graph 1 and 2>


View attachment 112961

snip

In the zoomed shot of run 2 you can see how the tiny fluctuation in current results in a large perturbation of the rear torque--this is seen in every run by all the cars. In addition i put some arrow lines to illustrate how the current ramp changes slope--obviously a steeper slope is more current in less time, and would result in more torque faster. The 450 ft-lb torque limit is reached very early on with only ~200 Amps.
Click to expand...

I just put graphs up in "LolaChampCar - 02-26-16 - Slip Start.xlsx" in the LolaChampCar sub-directory on the google drive share (side note Kenny, PM me your email address and I'll give you editing rights so you can upload to here). First run definitely has tires slipping, that's amazing to see the level of responsiveness to this.

This second run, and pretty much all runs, with the steeper initial slope for torque is interesting. Initially I was thinking this could be slipping, though I believe this may be just the initial loading of the tires to initiate movement.

Here's a zoom in of the first 1/4 second, and assuming valid correlation, that first 1/10th of a second has most of the interesting behavior.
LolaChampCar - 02-26-16 - Slip Start Run2 (Zoomed).png
 
#302
That looks a lot like pre-determined programatic kicking or winding up of tire side wall flex to me. Start fast and hard to put energy into a zero energy system then back off to let the kick settle in before ramping up until the car starts moving. Tesla put a lot of time and energy into the launch on this car.

Anybody know any top fuel clutch guys? I would love to hear a professional's take on this.
 
#306
wk057 said:
I've checked quite a bit. There doesn't seem to be any RPM value coming from the front motor. Definitely weird. Tesla's developer mode CAN debugger also does not have any RPM value for the front motor. If it's there, I can't find it.
Click to expand...

I think that real engine revolutions will not be because the front motor does not revs sensor. If you find it, they can come only the calculation of the frequency inverter ( no real revs ).
Only big rear engine has revs sensor (A/B encoder X253). So, only front revs msg will be revs from front wheels. R/L wheel revs for ESP ( but it is probably different CAN bus ).
 
Last edited:
#308
kennybobby said:
Good observation, do you know the line count or resolution of the encoder, e.g. pulses per rev, number of teeth on gear, etc.
Click to expand...

Unfortunately I don't know for now
I'm trying to get a car wreck for help wk057 with hecking. Here in Eastern Europe it is difficult to buy a car for a good price and from the USA it is too much complicated.
... and I must not disassembly my P85D :wink: my wife would kill me quickly.
 
#309
Speed controllers work with an intimate knowledge of RPM (without positional knowledge, they can not lead the field and generate torque) so RPM is a known even if generated from reverse EMF and not a physical encoder. It just appears as though Tesla is not putting it on the CAN bus.

It looks like we may be joined by a P90D shortly. I'm looking forward to seeing 90 data on the same graph as similar 85 data ala the work that has been done with P85D and DL data. All we need to do now is find an X to participate and we will have representative data for all the performance models.

I've concentrated on the ability to get the data. Many thanks to all that have, and continue to, arrange available data in graphical form in addition to those that are helping to expand the data pool to all available models. It is certainly helping my level of understanding.
 
#310
lolachampcar said:
It looks like we may be joined by a P90D shortly. I'm looking forward to seeing 90 data on the same graph as similar 85 data ala the work that has been done with P85D and DL data. All we need to do now is find an X to participate and we will have representative data for all the performance models.
Click to expand...

am i supposed to be building my own cable or would one be sent?
 
#311
i'll throw out another look at the initial launch sequence, here is a time-step integration of the Rrpm to calculate distance travelled assuming 24" diameter tires.

It looks to me like maybe the whole point of that current-torque-rpm oscillation is to produce a linear 1-foot rollout response.

i wouldn't be surprised if there was a subroutine in the controller with that name: the 0-60 with rollout came to 3.19 sec, so they were going to make damn sure to deliver on the 3.2 advertised.

1foot_rollout_lccrun2.png
 
  • Like
Reactions: benjiejr
#312
lolachampcar said:
Brian,
I bought ten diag cables with the idea of having ten loggers in circulation. I suspected that most would want to collect and understand data from their car then really have no long term need for a logger. That person could then ship it to the next interested owner to enable evaluating their car. If you like, I can get one to you for your testing; it would just be a loaner and not a long term thing.
Click to expand...

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.

MikeBur,
I'd like to have a folder on your Google Drive share to make data available to the community. Can you help ? (Sorry for the public request, when I attempted to PM you I got this message:
  • MikeBur has exceeded their stored private messages quota and cannot accept further messages until they clear some space.)

yak-55
 
#313
It might be nice to post one of your 0-60 runs to see how they line up with mine and others. Not sure there is anything to learn but is anyone interested in seeing three or four P85D 0-60 runs laid on top of each other? Perhaps current or torque initiation aligned. I'd be willing to be they are incredibly similar even with different vehicle/battery milage providing they were near the same SoC.
 
#314
kennybobby said:
i'll throw out another look at the initial launch sequence, here is a time-step integration of the Rrpm to calculate distance travelled assuming 24" diameter tires.

It looks to me like maybe the whole point of that current-torque-rpm oscillation is to produce a linear 1-foot rollout response.

i wouldn't be surprised if there was a subroutine in the controller with that name: the 0-60 with rollout came to 3.19 sec, so they were going to make damn sure to deliver on the 3.2 advertised.

View attachment 113097
Click to expand...

Looks nice. Like the time-step integration KennyBobby. How are you doing it?

I'm not convinced this is the 1ft rollout response for all as we are getting (by eye) many variations for 0-60 based on SoC, batt temp, etc. if this existed as a specific routine to guarantee 3.2 timings, then would we not be seeing very different slopes for power use as the routine would need to compensate?
 
#315
For my runs I calculate distance using delta-T and MPH line by line. Probably not perfect, but works out pretty well. In spreadsheet form it's basically just:

(ABS(current_line_time_seconds - previous_line_time_seconds)/3600)*(MPH)*5280 .... gives distance in feet traveled for that line. Example from my google doc: =(ABS(A39-A38)/3600)*(C39)*5280

Then for total distance traveled just sum up the output for relevant lines, or make a running sum like SUM($A$2:A35) or whatever, locking in the starting row's cell.
 
#316
yak-55 said:
MikeBur,
I'd like to have a folder on your Google Drive share to make data available to the community. Can you help ? (Sorry for the public request, when I attempted to PM you I got this message:
  • MikeBur has exceeded their stored private messages quota and cannot accept further messages until they clear some space.)

yak-55
Click to expand...
Fixed. Didn't realize how many PMs I got ... Lol, apologies. PM me your email and any preferred name for folder. Also if you want help using the templates I put up, let me and will help. Nit now takes me about 30 secs to go from raw data to graph per run, which is pretty good - though often spend a lot longer on tweaking scales, axis, sub-axis criteria, etc so anyone can compare easier on the screen grabs..

second Bill's ask I supplying data. Also, be sure to say what tires, etc you're running on. I'm about, well actually in another week, swap back to summer perf from SottoZeros and will be comparing like for like.

additionally, experience has shown that there are some things you should try your utmost to do, for consistency between comparisons:
0) Always be safe, for yourself and doubly so for others. No data capture is worth putting anyone at risk.
1) try to use same stretch of road
2) wherever possible use same SoC and battery temp. Either just finish a charging session, or use max battery. Max battery takes a while to warm the battery and consumes a lot of battery energy. It appears to work best for me if I start max battery session and then plug car in.
3) remember 0-60 timing on public roads may be considered "street racing", so be safe and legal.
4) note the outside temperature and weather conditions
5) use TACC for steady speed testing, eg. Range mode
6) with Bill's logger I blip the throttle quickly to start the data tracking before the event of interest. The capture lasts ~20 seconds and you can get 8-10 before memory is full. Keeping a laptop in car to take data off helps.

- - - Updated - - -

wk057 said:
For my runs I calculate distance using delta-T and MPH line by line. Probably not perfect, but works out pretty well. In spreadsheet form it's basically just:

(ABS(current_line_time_seconds - previous_line_time_seconds)/3600)*(MPH)*5280 .... gives distance in feet traveled for that line. Example from my google doc: =(ABS(A39-A38)/3600)*(C39)*5280

Then for total distance traveled just sum up the output for relevant lines, or make a running sum like SUM($A$2:A35) or whatever, locking in the starting row's cell.
Click to expand...

thanks. Hungover brain struggling on the 5280 number...? Is this one of those inches/feet things? Oh, for longing for a metric system ;-)
 
#319
Hey guys...
Let me know if we want to adjust post threshold logging times.
As it stands now-
Logging starts when throttle exceeds TPS Threshold
Logging continues until the throttle drops below TPS Threshold
Loggong continues for (I think - need to check) about twelve seconds after throttle falls below TPS Threshold (for the first time - going back above TPS Threshold does not affect timing at this point in the game)

If you simply want to blip the throttle as your "start" signal then log for a set time, we can do that. It kinda works that way now but, unless you are doing 1/4 runs, we log a bunch of crap at the end. It would be simple to do variants that capture for a fixed lesser period of time to enabling capturing more runs between laptop downloads.
 
#320
lolachampcar said:
Hey guys...
Let me know if we want to adjust post threshold logging times.
As it stands now-
Logging starts when throttle exceeds TPS Threshold
Logging continues until the throttle drops below TPS Threshold
Loggong continues for (I think - need to check) about twelve seconds after throttle falls below TPS Threshold (for the first time - going back above TPS Threshold does not affect timing at this point in the game)

If you simply want to blip the throttle as your "start" signal then log for a set time, we can do that. It kinda works that way now but, unless you are doing 1/4 runs, we log a bunch of crap at the end. It would be simple to do variants that capture for a fixed lesser period of time to enabling capturing more runs between laptop downloads.
Click to expand...

Would be ideal if we could find an (otherwise insignificant) CAN message to trigger the recording period. In my Subaru days we used the switch for the rear defroster to trigger logging. Maybe something like that is available ? (Seat heater, fog lamps, ??) This would allow arbitrary logging periods enabled by user input.

Also, I don't know if its feasible at these data rates, but realtime export via USB to a laptop would ease the storage limitation.

yak-55
 
You must log in or register to reply here.
Top
Back
Blog
New
Forum list
Marketplace
Menu