Anyone with an example of raw data from the CANbus/OBD-II port when driving the Model 3?

[dspwhite]

Preferably when flooring it from 0-60. I'll have all the columns it provides, but in particular I'm looking for:

- Time in milliseconds (it can be the time since flooring it, or the actual time, doesn't matter).

- Pedal position (say 0-100%)

- Car distance traveled (millimetre or centimetre accuracy needed)...... OR .......mph/kph (tenths of a mph or kph needed really)...... OR .......wheel RPM.

Does anyone here have a spreadsheet of such data? So down the left hand column would be time, and the top row titles would be the other variables.

The reason for doing this is I want to precisely measure the time between pressing the acceleration pedal and when the car starts to move even a millimetre. So far, from tests I've done with my 60fps video camera, I'm measuring around 120 milliseconds of lag on my M3P, but I want another way to back this up to make it a bit more conclusive, hence going the CANbus route. I could go and research and buy the CANbus/OBD-II converter, and software, but it may be that I'd be disappointed in the end if it doesn't have the accuracy needed (or even one of the variables), so if someone has a spreadsheet like this to offer, I would be immensely grateful.

 

[Knightshade]

Seems like this thread might have some info that'd help you

Diagnostic Port and Data Access - Tesla Owners Online

 

[dspwhite]

Thanks, saw that, but as far as I can see, there's no real data presented in a raw table with time going down the first column and the other variables (speed, RPM, pedal position etc.) going across the top row (each acting as columns of data).

I suppose I could try adding to the thread there...

 

[P3Orion]

I have a csv file with the data you want, but can't get it to upload. So I will summarize. This is from a 0-60 run I did in my M3P.

Time (ms) Accelerator position (%) Speed (mph)
11743 0 0
11754 0.4 0
11959 100 0
12064 100 0.34
15371 100 59.9

So it takes 200ms from when I start to push the accelerator until it is fully depressed.
It takes 105ms until a positive speed is logged. Due to canbus timings for these parameters, that may be a lower number, since the first speed logged is 0.34mph.
It hits 60 in about 3.4 sec, which is consistent with my other runs that day.

Edit: I guess the file did attach. It is a zipped csv. Scroll down to time of 11743.

Hope this helps.

 

[dspwhite]

I have a csv file with the data you want, but can't get it to upload. So I will summarize. This is from a 0-60 run I did in my M3P.

Time (ms) Accelerator position (%) Speed (mph)
11743 0 0
11754 0.4 0
11959 100 0
12064 100 0.34
15371 100 59.9

So it takes 200ms from when I start to push the accelerator until it is fully depressed.
It takes 105ms until a positive speed is logged. Due to canbus timings for these parameters, that may be a lower number, since the first speed logged is 0.34mph.
It hits 60 in about 3.4 sec, which is consistent with my other runs that day.

Edit: I guess the file did attach. It is a zipped csv. Scroll down to time of 11743.

Hope this helps.

Thank you! That's amazing info.

In theory, the car should start to move even at 0.4% pedal depressed (where with your data, we see an overall pedal to movement latency of 289 milliseconds), and especially at around 20% pedal depressed (where the pedal to movement latency is still quite a relatively slow 195 milliseconds). I wonder what's causing the discrepancy between that and my tests where I've found it's more like 120 milliseconds of latency with my 60fps camera trick.

I notice in your spreadsheet you have torque and power stats too. If we go from 0.4% pedal depressed to the first F torque reading, we get 62 milliseconds.

Perhaps more interestingly, I noticed the "R RPM" stat. Is this the RPM of the motor or the wheel do you know? In either case, we're looking at 112 milliseconds (from 0.4% pedal depressed), which DOES match up more with what I'm seeing. The "F RPM" stat is missing from your spreadsheet. That's maybe a shame since the F torque starts counting earlier than the R torque.

Finally, did you try with the nannies removed such as Obstacle aware acceleration off (found in the autopilot settings)? (nearby, you can also turn off Forward collision warning, Lane departure avoidance, Lane emergency departure avoidance, and Automatic emergency braking). If the car has to check if it's going to collide into something when you accelerate, that may add on a good few more milliseconds.

I'll do some 60fps video camera tests in the mean time.

 

[Mash]

I would assume track mode decreases intended latency somewhat. Without latency car is too dangerous for daily use.

 

[P3Orion]

I would highly recommend that you get the canbus adapter and the Scan My Tesla software, if you want to do this analysis. It will be much more accurate than video.

I looked a bit more at the data and found some other interesting things. I'm not an engineer, but I am a physicist, so I would guess that there is some latency between the accelerator being depressed, the motors starting to spin, the 10:1 reduction gearbox, and the tires starting to rotate enough to overcome friction and begin to move the car.

Perhaps the most amazing fact (to me anyway) is that the motors reach maximum torque (477 lb-ft) in just 182 ms after full throttle. Peak HP can be calculated as 595 at about 47mph. That is for SOC of 77%.

I don't know exactly what the R RPM parameter is. I think it is probably motor rpm after the gearbox. I didn't happen to choose the Front RPM to log.

The Scan My Tesla app is really good if you're interested in these kinds of stats. You can log many things about the car. Check out that thread over on teslaownersonline.

 

[Knightshade]

I would assume track mode decreases intended latency somewhat. Without latency car is too dangerous for daily use.

Not sure it does since nobody has found it improves 0-60 or 1/4 mile times at all

 

[Mash]

Not sure it does since nobody has found it improves 0-60 or 1/4 mile times at all

Why would it improve? You measure time since start of movement and not since you press a pedal.

 

[dspwhite]

I would highly recommend that you get the canbus adapter and the Scan My Tesla software, if you want to do this analysis. It will be much more accurate than video.

I guess my concern with the CANbus/log approach is that even ignoring the fineness of the polling rate, some of the hardware sensors in the data themselves may have a bit of lag, perhaps due to the fact that the sensors will be in different locations in the car, so distance and transmission protocols would be required for communication, adding potentially misleading milliseconds to the time for some variables (and less or more so for other variables).

With my approach, the camera "never lies" so to speak, so what you see is what you get. My foot, the pedal, and the outside of the car are all in shot, so in theory, you get to witness the true latency. Although perhaps it is arguably also prone to weakness (such as a jolt being perceived as wheel movement, or missing out on the very initial tiniest wheel movement if the video resolution isn't high enough).

I looked a bit more at the data and found some other interesting things. I'm not an engineer, but I am a physicist, so I would guess that there is some latency between the accelerator being depressed, the motors starting to spin, the 10:1 reduction gearbox, and the tires starting to rotate enough to overcome friction and begin to move the car.

All very good points, and definitely needs to be considered. I wonder how much of the latency is due to software, and how much is due to the raw hardware physics as you suggest.

I don't know exactly what the R RPM parameter is. I think it is probably motor rpm after the gearbox.

I think you're right that it's after (not before) the 10:1 gear reduction takes place. The maths works out as you'd expect: 26 inch diameter wheels (20" rims + 6" both tire sidewalls height) = around 80 inches circumference. And 800 RPM * 80 inches * 60 (for minutes to hour conversion) = 3,840,000 inches/hour = 60.6 miles/hour or thereabouts.

The Scan My Tesla app is really good if you're interested in these kinds of stats. You can log many things about the car.

I am tempted definitely. If I could be cheeky and ask for one last test, it would be with standard nannies removed such as Obstacle Aware Acceleration and recording both the R RPM and F RPM parameters along with the others you did. Don't worry about track mode or getting 60mph though. Even just 0-20mph would be fine.

Otherwise, are all CANbus adaptors as good in functionality? For example, I see this one for $30, this one for $42, this one for $104 and this one for a whopping $295. Not sure if some poll faster than others.

Thanks again for your input. Latency is always something I've cared a lot about in software, comms, electronics, games/controllers, displays, touchscreens and hardware generally, so I've been very curious how the Model 3 fared.

 

[Mash]

Latencies on the bus are below 1ms. Roughly 10x worse than your camera.

 

[MXLRplus]

I'm posting in the thread for reference so I can find it later. Thanks.

 

[dspwhite]

Latencies on the bus are below 1ms. Roughly 10x worse than your camera.

1ms sounds good. Can you elaborate?

I'd have thought the various sensors (pedal sensor, motor sensor etc.) could themselves potentially have some latency in producing the millisecond figures, unfortunately.

To support that idea and having a second look at P3Orion's spreadsheet data, it seems most odd that the R RPM positive figures start coming in around 177-198 milliseconds sooner (time position 11866ms), than the first Speed measurement (0.34mph at time position 12064ms), despite a decent polling frequency of around 15-30ms for the Speed stats. I would have thought there would be a very tight and instant physical connection between the motor (post gear reduction), and the wheels, and certainly not as much as 180ms worth. This is in part why I think there seems to be something skewed going on in the data. Unless I'm mistaken somehow.

 

[Uncle Paul]

In Tesla launch mode, micro latency is also reduced, as the motors generate a bit of torque to take up all the slack in the driveline. Motors are tensed, gears are torque meshed, tires are engaged slightly forward, even the lug bolts are pushed forward in their circles. Everything is pre-stressed and engaged before the pedal is slapped to the floor.

For human perception, however, the forward thrust can seem immediate.

Comparing EV drive systems to gassers, the difference is probably going to be significant. Need to wait for throttles to open, gas to spray and atomize, computers to sync, turbos to spool up, multispeed transmissions to sort out launch gear and automatics to build up fluid pressures. Dragsters need to pre engage clutches while holding brakes. On launch they need to roll on more throttle while letting off the brake and apply exactly enough torque to move the car rapidly forward without spinning the tires into smoke.

 

[dspwhite]

Motors are tensed, gears are torque meshed, tires are engaged slightly forward, even the lug bolts are pushed forward in their circles. Everything is pre-stressed and engaged before the pedal is slapped to the floor.

Interesting. I'd love to know how many milliseconds are spent pushing physical stuff around like this before the rubber of the tires engage with the road. I'd have thought less than 50ms (and that the software spends most of the remaining latency time), but I can't be sure.

Be nice for Tesla to implement an optional "low-latency mode" on the screen, even if it's at the cost of energy or noise etc. The instant "brain-car live connection" would feel even more profound than currently, since 200ms or even 100ms is quite a lot of lag.

 

[Uncle Paul]

Maybe a lot of lag for a microchip, but amazingly little lag for a 4,000 lb electro-mechanical machine with lots of moving parts and tolerances.

 

[dspwhite]

Maybe a lot of lag for a microchip, but amazingly little lag for a 4,000 lb electro-mechanical machine with lots of moving parts and tolerances.

Oh I agree. Relatively speaking, it's amazing, but I was thinking in terms of the perception of the lag, at least for many people.

On this forum and elsewhere, people have even complimented the original Tesla Roadster in regards to how responsive it is, in comparison to later Tesla vehicles (even if the Model 3/S/X are faster to 60mph).

 

[MagnusMako]

I think prevention of torque ripple from the PMSR motor is probably responsible for the perceived lag (in G forces) because the car holds back full torque in the first few mph if I recall correctly. The guy on the Engineering Explained YT channel elaborated on it when he got his P3D a while back.

 

[dspwhite]

The guy on the Engineering Explained YT channel elaborated on it when he got his P3D a while back.

I saw that yeah. IIRC, he did say however that the P3D felt much more responsive than the single motor 3 in that regard, and much more like what he was hoping for. I think he was referring to the acceleration or jerk (rate of change of acceleration) in the lower end, which is also very important, but a different topic. To be clear, throughout this thread, I'm trying to discover the time gap between pressing the pedal and the wheels moving even a tiny millimetre.

 

[Mash]

1ms sounds good. Can you elaborate?

I'd have thought the various sensors (pedal sensor, motor sensor etc.) could themselves potentially have some latency in producing the millisecond figures, unfortunately.

To support that idea and having a second look at P3Orion's spreadsheet data, it seems most odd that the R RPM positive figures start coming in around 177-198 milliseconds sooner (time position 11866ms), than the first Speed measurement (0.34mph at time position 12064ms), despite a decent polling frequency of around 15-30ms for the Speed stats. I would have thought there would be a very tight and instant physical connection between the motor (post gear reduction), and the wheels, and certainly not as much as 180ms worth. This is in part why I think there seems to be something skewed going on in the data. Unless I'm mistaken somehow.

I meant to say better, not worse. Lag there is intentional - it's an input filter to make it safer. From my experience with high power servo motors - low latency is not a big deal, but it's dangerous. Accidental slam on power and you lose control of half megawatt motors connected to the ground.