Letter To Elon Musk Regarding P85D Horsepower – Discussion Thread

[JohnSnowNW]

I think the more interesting question is, why is Tesla using the correct method for 70, 70D, 85 and 85D models but not for P85D? On the order page they don't show motor power anymore except P85D. Other models only show actual achieved hp but not motor power. P85D shows only motor power* but not actual hp. Because this is a recent change, it shows they are aware it was misleading and they are try improve. They fixed the problem for other models but not for P85D. Why not? Because those other models already had the lower number as well. P85D didn't. Somehow 550 hp was forgotten from the beginning.

* motor power = Horsepower the motor is capable of producing by design in a lab environment when attached to a perfect power source. For example S70 and S85 share the same motor that could theoretically produce 382 hp. However with the 70 kWh battery it produces 315 hp and with the 85 kWh battery it produces 373 hp. These numbers (382 hp, 315 hp, 373 hp) are shown on the Model S page on Tesla website.

As I have already stated several posts back, the explanation is that performance vehicles are marketed differently. Manufacturers try to differentiate their performance models from their base models to make them seem more appealing. The metrics I showed for the Chevy Camaro are a good example.

In Tesla's case, they are simply using metrics employed by other manufacturers they are competing against. If, say, Dodge is using "BHP" for the Hellcat (they are) but Tesla uses the equivalent of "WHP" then the Hellcat is going to look more desirable from a performance perspective.

Advertising is aimed at the lowest common denominator, and frankly most consumers are quite ignorant. Tesla has to compete in this industry, and that means they have to use similar metrics of vehicles they are competing against.

Anyway, hopefully the letter gives Tesla a chance to respond...I'm not sure it does, but it would be nice to put this issue to bed. Not that I don't expect people to find something else to nit-pick down the road.

 

[omarsultan]

This is the kW number reported via the "power" field in the REST API. I personally haven't seen 415kW but I have seen 414kW. Pete just pulled 456 kW from his P90DL. It's about 9% more than the power reported at the wheels by a vbox showing the incredible efficiency of the Tesla D car vs a typical AWD ICE car which loses more like 20%. There have been very detailed discussions on this in the other threads.

So streaming telemetry is something I know a thing or two about. Like any number this needs to have context, in this case, its important to understand what is being instrumented and at what resolution--in this case, the resolution is likely the important piece. For example, if the car is reporting 1-second resolution, a transient sub-second spike is likely not going to be properly captured--depending on the telemetry policy and the capabilities on the instrumentation, you may get the average across the sampling interval, you might get a max/min during the sampling interval (rare as it creates messy data) or you might get a single point right at the sampling interval.

You generally don't see super high-resolution sampling in most applications unless there is a specific requirement as instrumentation the is more expensive, it burns resources on the system (car) like CPU and memory, and it generates an immense amount of data that must then be moved off the device and sifted through. Typically, you use coarse resolution to identify patterns and then only spend resources investigating the interesting stuff.

The other thing worth noting is that the is an undocumented API, there is no guarantee that it is working/working well/working consistently, etc.

 

[sorka]

So streaming telemetry is something I know a thing or two about. Like any number this needs to have context, in this case, its important to understand what is being instrumented and at what resolution--in this case, the resolution is likely the important piece. For example, if the car is reporting 1-second resolution, a transient sub-second spike is likely not going to be properly captured--depending on the telemetry policy and the capabilities on the instrumentation, you may get the average across the sampling interval, you might get a max/min during the sampling interval (rare as it creates messy data) or you might get a single point right at the sampling interval.

You generally don't see super high-resolution sampling in most applications unless there is a specific requirement as instrumentation the is more expensive, it burns resources on the system (car) like CPU and memory, and it generates an immense amount of data that must then be moved off the device and sifted through. Typically, you use coarse resolution to identify patterns and then only spend resources investigating the interesting stuff.

The other thing worth noting is that the is an undocumented API, there is no guarantee that it is working/working well/working consistently, etc.

There's been tons of discussion on this in other threads including the REST API thread in the user interface forum. The sampling is 4 hz but if the servers are busy it can drop off but I've never seen that happen myself. I've logged and graphed thousands of samples and if there were any sudden sub 100 ms spikes, you'd eventually catch them. I've also overlayed the kW data with the the vbox hp channel data which is 20 hz and tracks perfectly with that and only shows about a 9 or 10% loss. This is assuming the power is being reported at the battery. If it's being reported further downstream like power at the inverter output before going into the motor, then it would mean it's a little less efficient because that 10% would not include inverter conversion losses. For the sake of discussion, I think some have even been willing to accept the possibility that the 414KW(550 hp) might even be their calculated motor output. If that were the case, then the drivetrain loss would be 10% from the motor to the wheels rather than from the battery to the wheels. I think most are assuming this is the power at the battery itself.

 

[stopcrazypp]

I think the more interesting question is, why is Tesla using the correct method for 70, 70D, 85 and 85D models but not for P85D? On the order page they don't show motor power anymore except P85D. Other models only show actual achieved hp but not motor power. P85D shows only motor power* but not actual hp. Because this is a recent change, it shows they are aware it was misleading and they are try improve. They fixed the problem for other models but not for P85D. Why not? Because those other models already had the lower number as well. P85D didn't. Somehow 550 hp was forgotten from the beginning.

* motor power = Horsepower the motor is capable of producing by design in a lab environment when attached to a perfect power source. For example S70 and S85 share the same motor that could theoretically produce 382 hp. However with the 70 kWh battery it produces 315 hp and with the 85 kWh battery it produces 373 hp. These numbers (382 hp, 315 hp, 373 hp) are shown on the Model S page on Tesla website.

See my response to you for an explanation:

The time-line is October 2014, when Tesla launched their dual motor models, Tesla changed all models to "motor power". Then in March 2015 the thread about 691 hp "motor power" for P85D being misleading was posted. In May 2015, Tesla finally removed the 691hp "motor power" number as well as the rest of the motor power numbers. Recently they added "motor power" numbers. If Tesla adds a 556hp number for the P85D, they pretty much know from the thread at the time, that there would be backlash. The situation is different from if Tesla advertised only the P85D with "motor power" and the others differently from the start.

The specs page shows "motor power" numbers for the other models also, it just doesn't on the design page because they only use one line (and P85D they don't list official system power number):
http://www.teslamotors.com/models#battery-options

 

[DanKeen]

Dan just for you... what I bought instead of upgrading my 60 to a P85D (which was a lucky escape. given it would have been obsolete even before delivery!!!)

Totally jealous!

And yeah, sorka, I know that the Tesla will drop faster than the Exige. But it wasn't built for the track - the Exige was. Just poorly

 

[ERP]

My Lotus Exige will drop some 60+hp (which is major when it starts with 260…) when the intercooler heat soaks. At Thunderhill I'll lose 15+mph on the front straight.

The stock intercooler setup has terrible air flow. There are a few ways to improve it, but the best fix is to get the BOE Rev kit.

You're talking track duty. The P85D will drop a 100+ horsepower under the same conditions in just a few minutes.

At the Lotus owners gathering last week my wife took our P85D onto the autocross. It was only a 60 sec course but during the 4th run it had a temporary decrease in power. It didn't last long but was noticeable. This was with 5-8 minutes between runs.

 

[smac]

The stock intercooler setup has terrible air flow. There are a few ways to improve it, but the best fix is to get the BOE Rev kit.

+1 the OEM Intercooler was rubbish (I had a stock 220 a few years back.)

Plenty of after market cooling options for the S220/240/260's though charge cooling is probably the real, if expensive fix

And trying to not turn this into a Lotus thread... in someways Lotus implementation of the SC felt a bit like where we are in Tesla-land right now. e.g. Hit some impressive numbers on paper, but not really worry about the implications too much in practice. (History doesn't repeat but it does sometimes rhyme)

At the Lotus owners gathering last week my wife took our P85D onto the autocross. It was only a 60 sec course but during the 4th run it had a temporary decrease in power. It didn't last long but was noticeable. This was with 5-8 minutes between runs.

Interesting result. Personally I think the effort Tesla are putting in to 0-60 right now are doing no favors for Tesla. It is an extremely quickly accelerating and comfortable saloon. It isn't nor ever has been a track car, however the headline numbers seem to make people think it is. (Of course this is a UK biased view, and the 1/4 mile is a tiny niche here, track days are v. popular).

Personally I'd happily substitute some 0-60 in the Tesla for it being even more upmarket interior wise, however I appreciate this may not sell them as many cars, as a two car garage isn't always an option


BTW If either you or Dan are in the UK, please feel free to PM me, I'd happily show you/take you out in the V6. In OEM terms it is the best Lotus ever, and I really wish you guys could get one stateside. Truly a different league to the old 4 cylinder cars (well as they left the factory. )

 

[rns-e]

Personally I'd happily substitute some 0-60 in the Tesla for it being even more upmarket interior wise, however I appreciate this may not sell them as many cars, as a two car garage isn't always an option

I know what you are saying, but both Insane and Ludicrous are byproducts of other focus areas. Insane is the byproduct of better traction and better range and Ludicrous is the byproduct of making the power train able to last a million miles - or at least that is what Mr. Musk has said, and then the little boys within the grown engineers took over the show and went for speed of the line

 

[smac]

I know what you are saying, but both Insane and Ludicrous are byproducts of other focus areas. Insane is the byproduct of better traction and better range and Ludicrous is the byproduct of making the power train able to last a million miles - or at least that is what Mr. Musk has said, and then the little boys within the grown engineers took over the show and went for speed of the line

The little boys in engineering, or those in marketing?

 

[Auzie]

The little boys in engineering, or those in marketing?

I'd be surprised if Tesla employed any marketing people.

 

[smac]

I'd be surprised if Tesla employed any marketing people.

Of course Tesla employ marketing staff! OK they may not do TV or print adverts (unless we include China), but they certainly issue press releases, organise events, do research into what the market wants, how to best present the features of the car etc. etc.

It may be "rebranded" into another job title, but marketing != making adverts.

(BTW I don't work in marketing, but do employ some!! Great bunch and integral to a successful business, but on occasion need reigning in by the product guys )

 

[Auzie]

Of course Tesla employ marketing staff! OK they may not do TV or print adverts (unless we include China), but they certainly issue press releases, organise events, do research into what the market wants, how to best present the features of the car etc. etc.

It may be "rebranded" into another job title, but marketing != making adverts.

(BTW I don't work in marketing, but do employ some!! Great bunch and integral to a successful business, but on occasion need reigning in by the product guys )

smac you made me do the work

I had to google it and LinkedIn it to check who's right

You win big time

Tesla has pure marketing types in Florida, Fremont, Pacific Northwest, Midwest, Atlanta, etc

 

[smac]

You win big time

A bit like the Ashes

(Sorry couldn't resist)

 

[Auzie]

A bit like the Ashes

(Sorry couldn't resist)

No need to apologise

Though you made me work again

Had to google Ashes

 

[omarsultan]

The sampling is 4 hz but if the servers are busy it can drop off but I've never seen that happen myself.

That is only telling you the rate you can poll the API, and that might be policy controlled. The actual chain likely looks something like this:

Controller (samples analog signal) ---> onboard process to collect analyze and store data ---> onboard process to transmit data ---> Tesla HQ process to collect data ---> API to access stored data

Any off the points after the first one could be aggregating the data that is passed along. Does Tesla really care to collect the current flow at 12:00:00.01 and again at 12:00:00.02 -- the vehicle management systems might but is it worth transmitting and storing that data? I dunno. However, my point was that without API docs, its just a best guess as to what the data point actually represents. As far as the VBOX data, that is still HP at the wheel not HP at the crank. Typical drop-off from crank to wheels is 15%-20%. Your observed data is at the high edge of this range. I would expect it to be on the lower end of the range because of the simpler transmission, but there are lots of factors that affect wheel HP, so its hard to say.

Anyway, as I said to Andy, curious to see how this plays out.

 

[sorka]

That is only telling you the rate you can poll the API, and that might be policy controlled. The actual chain likely looks something like this:

Controller (samples analog signal) ---> onboard process to collect analyze and store data ---> onboard process to transmit data ---> Tesla HQ process to collect data ---> API to access stored data

Any off the points after the first one could be aggregating the data that is passed along. Does Tesla really care to collect the current flow at 12:00:00.01 and again at 12:00:00.02 -- the vehicle management systems might but is it worth transmitting and storing that data? I dunno. However, my point was that without API docs, its just a best guess as to what the data point actually represents. As far as the VBOX data, that is still HP at the wheel not HP at the crank. Typical drop-off from crank to wheels is 15%-20%. Your observed data is at the high edge of this range. I would expect it to be on the lower end of the range because of the simpler transmission, but there are lots of factors that affect wheel HP, so its hard to say.

Anyway, as I said to Andy, curious to see how this plays out.

You've obviously misunderstood my previous posts. The drop off from the API data to wheels(which I already said the vbox data was at the wheels) is ONLY 9 to 10% which would make it the most efficient drivetrain of all time as most AWD ICE systems lose 20% from the flywheel to the wheels.

I'm not really sure what your beef is with the API. Are the readings instant samples at that time or is each sample an average of some higher internal sampling rate since the last sample was retrieved through the API? Does it really matter? The API data matches the power at the wheel data exactly at lower speeds and starts to diverge at higher speeds and increases as the speed increases but the shape of the divergence exactly characterized air resistance. I'm dynoing my P85D on Tuesday and will do the same thing. In that case I expect it to be even close with the only divergence being attributed to motor efficiency and non linear increase in resistance from the reduction gear oil and differential oil but those should be very small factors. Air resistance won't be a factor at all except the air the wheels have to scrub against as the spin.

 

[omarsultan]

I have no beef with the API, all I am saying is without documentation about what the value means, how it is measured, or if its even functioning correctly, some assumptions are being made and its good to call those out. When someone says the API says X so the car cannot be doing Y, there are some inherent caveats in that and it seems to be getting lost in the conversation.

 

[sorka]

I have no beef with the API, all I am saying is without documentation about what the value means, how it is measured, or if its even functioning correctly, some assumptions are being made and its good to call those out. When someone says the API says X so the car cannot be doing Y, there are some inherent caveats in that and it seems to be getting lost in the conversation.

When I log 15 minutes of a drive from end of charge and integrate the samples over that time, the area under that graph is within 1% of the cumulative energy use since last charge. If the car is parked, with the AC on, the energy usage for the AC is shown in the streaming API. If I turn the AC off, it goes to zero. There are quite a few conclusions you can draw from this.

There are a lot more detailed discussion on this in other threads. You're late to the party. That's fine, but this thread is probably beyond the scope debating this particular issue. There are other threads for that already.

 

[wk057]

I have no beef with the API, all I am saying is without documentation about what the value means, how it is measured, or if its even functioning correctly, some assumptions are being made and its good to call those out. When someone says the API says X so the car cannot be doing Y, there are some inherent caveats in that and it seems to be getting lost in the conversation.

When I log 15 minutes of a drive from end of charge and integrate the samples over that time, the area under that graph is within 1% of the cumulative energy use since last charge. If the car is parked, with the AC on, the energy usage for the AC is shown in the streaming API. If I turn the AC off, it goes to zero. There are quite a few conclusions you can draw from this.

There are a lot more detailed discussion on this in other threads. You're late to the party. That's fine, but this thread is probably beyond the scope debating this particular issue. There are other threads for that already.

I'll just chime in here and +1 sorka's post to point out that the API behavior is pretty well known.

Trying to say the API data is not valid for this discussion is just ridiculous and I'd highly suggest some research in the area before assuming so.

I'd happily give the power values from the API a +/- 2% margin for error... and that's being pessimistic. As far as I can tell the power values are based on data from the current shunt and voltage readings inside the battery pack. It's not going to get much more accurate than this.

 

[Andyw2100]

Trying to say the API data is not valid for this discussion is just ridiculous and I'd highly suggest some research in the area before assuming so.

I'd happily give the power values from the API a +/- 2% margin for error... and that's being pessimistic. As far as I can tell the power values are based on data from the current shunt and voltage readings inside the battery pack. It's not going to get much more accurate than this.

To be fair, though, I don't think omarsultan ever actually suggested the API data --WASN'T-- valid for certain. He just questioned whether or not it would be. He's probably just a lot less familiar with the REST threads, etc., than you guys are, and was just trying to suggest one possible area where an incorrect assumption on our part could have led to a potentially incorrect conclusion.

I think omarsultan has been one of the more open-minded people who has questioned the main assertion in the letter, and that he, more so than some of the other critics, is really interested in finding out what the real situation is.

That being said, I trust, omarsultan, that if you did research the REST threads, as wk057 and Sorka have, that you'd reach the same conclusions that they have about the validity of the numbers being spit out.