Official Tesla Model 3 thread

My Nissan Leaf Forum

Help Support My Nissan Leaf Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
Title: We Re-Test Our Tesla Model 3's Braking Performance | Talking Cars #153
Consumer Reports
Published on May 30, 2018
Tesla sent an over-the-air software update to all Model 3's this past weekend, which included a fix for the long stopping distances we experienced during our initial testing. We discuss our new test results, and what role over-the-air updates will play in the future of automobiles.
http://www.youtube.com/watch?v=EOEivi7kgwk
 
EVDRIVER said:
lorenfb said:
lpickup said:
Oh dear...looks like Loren might have to eat his words:



Emphasis mine

Hardly! As has been indicated before, there're different levels of firmware updates, e.g. minor functional changes - rate of change of wheel
velocity before lockup, that can be made versus changes to the overall stability control system algorithm that only the ABS supplier
has access to. Allowing a vehicle manufacturer small tweaks to an ABS system while still in beta production, i.e. which the M3 is now in,
would be common today in the automotive industry. Please re-read the bolden text in the quote of the original post.

You are wrong. They can flash anything at any level even third party firmware. Want to make a wager on that? Not a pizza. What do you think they are doing when they increase braking distance? Specifically.

Since you appear to be "in" at Tesla, send the source code/file size, etc., i.e. C++ or C (microcontroller based), of the OTA flash. Then define
how the complied file, e.g. a possible ZIP, would transfer from the MCU's radio receiver to the ABS ECU, i.e. if not just an OTA for the MCU's
interface with traction control (ABS ECU). Or does the MCU output the firmware file thru a central gateway bus to the ABS ECU's bus,
and then to ABS ECU's boot loader for re-flashing? Not a difficult request from someone that's "obviously" technically knowledgeable
about MS/MX/M3 vehicle system electronics, right? Please explain.
 
lorenfb said:
EVDRIVER said:
lorenfb said:
Hardly! As has been indicated before, there're different levels of firmware updates, e.g. minor functional changes - rate of change of wheel
velocity before lockup, that can be made versus changes to the overall stability control system algorithm that only the ABS supplier
has access to. Allowing a vehicle manufacturer small tweaks to an ABS system while still in beta production, i.e. which the M3 is now in,
would be common today in the automotive industry. Please re-read the bolden text in the quote of the original post.

You are wrong. They can flash anything at any level even third party firmware. Want to make a wager on that? Not a pizza. What do you think they are doing when they increase braking distance? Specifically.

Since you appear to be "in" at Tesla, send the source code/file size, etc., i.e. C++ or C (microcontroller based), of the OTA flash. Then define
how the complied file, e.g. a possible ZIP, would transfer from the MCU's radio receiver to the ABS ECU, i.e. if not just an OTA for the MCU's
interface with traction control (ABS ECU). Or does the MCU output the firmware file thru a central gateway bus to the ABS ECU's bus,
and then to ABS ECU's boot loader for re-flashing? Not a difficult request from someone that's "obviously" technically knowledgeable
about MS/MX/M3 vehicle system electronics, right? Please explain.

Not to take away evdriver's thunder, but the process goes like this:
- MCU downloads the firmware (encrypted and code-signed) into a staging area.
- A management process then pulls in the update file and verifies the integrity of the update (that the package is intact and did indeed come from Tesla) and then flashes the drivetrain ECU.
- firmware updates are pulled in, not pushed.

I don't recall how many subprocesses were involved, since it's been awhile since I read it, but this was all detailed by Jason Hughes (aka wk057) on his site (https://skie.net/skynet/projects) or on TMC. I forgot which, so can't send a direct link.

You're welcome. :)
 
Oils4AsphaultOnly said:
lorenfb said:
EVDRIVER said:
You are wrong. They can flash anything at any level even third party firmware. Want to make a wager on that? Not a pizza. What do you think they are doing when they increase braking distance? Specifically.

Since you appear to be "in" at Tesla, send the source code/file size, etc., i.e. C++ or C (microcontroller based), of the OTA flash. Then define
how the complied file, e.g. a possible ZIP, would transfer from the MCU's radio receiver to the ABS ECU, i.e. if not just an OTA for the MCU's
interface with traction control (ABS ECU). Or does the MCU output the firmware file thru a central gateway bus to the ABS ECU's bus,
and then to ABS ECU's boot loader for re-flashing? Not a difficult request from someone that's "obviously" technically knowledgeable
about MS/MX/M3 vehicle system electronics, right? Please explain.

Not to take away evdriver's thunder, but the process goes like this:
- MCU downloads the firmware (encrypted and code-signed) into a staging area.
- A management process then pulls in the update file and verifies the integrity of the update (that the package is intact and did indeed come from Tesla) and then flashes the drivetrain ECU.
- firmware updates are pulled in, not pushed.

I don't recall how many subprocesses were involved, since it's been awhile since I read it, but this was all detailed by Jason Hughes (aka wk057) on his site (https://skie.net/skynet/projects) or on TMC. I forgot which, so can't send a direct link.

You're welcome. :)

The traction control system (ABS system) is not typically considered part of the "drivetrain". Yes, most OEMs can easily re-flash their drivetrain
ECUs, e.g. an engine controller or EV motor controller (inverter). Those ECUs are typically designed in-house where the OEM has control of the
source code. What is really needed is the actual re-flashing process as it totally relates to the ABS system AND the extend of the re-flash,
e.g. just minor setting of parametric values - max rate of change of wheel velocity, or a complete revision of the total controller's firmware.
 
lorenfb said:
EVDRIVER said:
lorenfb said:
Hardly! As has been indicated before, there're different levels of firmware updates, e.g. minor functional changes - rate of change of wheel
velocity before lockup, that can be made versus changes to the overall stability control system algorithm that only the ABS supplier
has access to. Allowing a vehicle manufacturer small tweaks to an ABS system while still in beta production, i.e. which the M3 is now in,
would be common today in the automotive industry. Please re-read the bolden text in the quote of the original post.

You are wrong. They can flash anything at any level even third party firmware. Want to make a wager on that? Not a pizza. What do you think they are doing when they increase braking distance? Specifically.

Since you appear to be "in" at Tesla, send the source code/file size, etc., i.e. C++ or C (microcontroller based), of the OTA flash. Then define
how the complied file, e.g. a possible ZIP, would transfer from the MCU's radio receiver to the ABS ECU, i.e. if not just an OTA for the MCU's
interface with traction control (ABS ECU). Or does the MCU output the firmware file thru a central gateway bus to the ABS ECU's bus,
and then to ABS ECU's boot loader for re-flashing? Not a difficult request from someone that's "obviously" technically knowledgeable
about MS/MX/M3 vehicle system electronics, right? Please explain.


As usual you ignored the post request.
 
https://www.teslarati.com/tesla-model-3-profit-german-teardown-company/

Big auto makers have reason not to use third party evaluations of the 3 which is why they all have bought a Model 3.
 
EVDRIVER said:
https://www.teslarati.com/tesla-model-3-profit-german-teardown-company/

Big auto makers have reason not to use third party evaluations of the 3 which is why they all have bought a Model 3.
Interesting ! Thanks for sharing.
 
Model 3 totaled after being hit by a Camero and and BMW racing in i90...
https://teslamotorsclub.com/tmc/threads/my-model-3-got-wrecked-today.116495/

Description from a witness:
https://teslamotorsclub.com/tmc/threads/my-model-3-got-wrecked-today.116495/page-2#post-2771736


Very interesting that the 3 has airbags in the footwells.
 
jlv said:
Very interesting that the 3 has airbags in the footwells.
I've thought for a while that the most damaged parts of human bodies in severe but not fatal collisions are the knees and neck.
Tesla is ahead of the curve on knees, but I'm not sure that headrests should remain immobile.
 
lorenfb said:
The traction control system (ABS system) is not typically considered part of the "drivetrain". Yes, most OEMs can easily re-flash their drivetrain
ECUs, e.g. an engine controller or EV motor controller (inverter). Those ECUs are typically designed in-house where the OEM has control of the
source code. What is really needed is the actual re-flashing process as it totally relates to the ABS system AND the extend of the re-flash,
e.g. just minor setting of parametric values - max rate of change of wheel velocity, or a complete revision of the total controller's firmware.

Why? We don't need to know how they do it to conclude that they can make enough changes to fix the ABS behaviour on subsequent emergency stops (CR did get 130+ feet on their first test, it was the follow-up ones that failed miserably). You've said that you didn't think an ABS supplier would permit Tesla (the customer) access to overwrite their firmware, and now they've proven otherwise. You can't have it both ways. Either the ABS Supplier permitted it, or Tesla did their own ABS implementation and thus own their own code. You have to concede one of those positions.
 
Re: Best analysis of Model 3 to date (German) - per Elon M tweet so that would lead one to believe it is reasonably accurate.

https://twitter.com/elonmusk/status/1002270980755013632

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fwww.wiwo.de%2Ftechnologie%2Fmobilitaet%2Felektroauto-zerlegt-tesla-model-3-kann-gewinn-abwerfen%2F22625806.html&edit-text=&act=url

ELECTRIC CAR DISASSEMBLEDTesla Model 3 can throw off profits

EXCLUSIVE
by Stefan Hajek
May 31, 2018
It is the big question in Tesla's hopes: Can the Californians build Model 3 profitably? A German engineering service provider has disassembled a Model 3 and comes to a clear conclusion in the analysis.

Tesla's Model 3 can make a profit. This is the result of a German engineering service provider, who has a Model 3 decomposed to the last screw . The material and delivery costs of the $ 35,000- $ 78,000 car are only around $ 18,000; In addition, according to the calculations of the burglars, who are the WirtschaftsWoche, about $ 10,000 in production costs per car. "If Tesla manages to build the planned 10,000 pieces a week, the Model 3 will deliver a significant positive contribution to earnings," says a test engineer.

The WirtschaftsWoche are minutes of some engineering service providers who have worried and dismantled a Tesla Model 3 from the USA on behalf of German auto companies on the gray market. The sellers are ex-Tesla employees who were able to order a Model 3 early and now sell it at a high profit. The prices on the gray market are at 100,000 to 130,000 dollars.

A total of four Tesla Model 3 have been transferred to information from the WirtschaftsWoche in recent weeks to Germany and disassembled here in the works of competitors. The German Tesla competitors did not just want to investigate some hitherto unclear technical solutions of the expected first over 500,000 pre-orders electric cars for the mass market on the object; they were also interested in revealing its economic calculations.

Another result of the analyzes: Tesla has achieved a breakthrough with scarce battery raw materials. Tesla has obviously succeeded in significantly reducing the share of the notoriously scarce metal cobalt in the batteries of his new Model 3. This is the result of laboratory analyzes exclusively available to WirtschaftsWoche. Cobalt is needed in the cathode of lithium-ion cells; It is considered irreplaceable there. More than 60 percent of the global cobalt deposits are in the civil-war-torn Democratic Republic of the Congo, where the cobalt is partly funded by child labor and used to finance warlords.

In the world market, the price of cobalt last tripled within 18 months. Due to the flood of new e-models of numerous car companies, which should come on the market from 2020, the demand for the scarce metal will multiply again. Individual corporations like VW had recently tried to conclude direct delivery contracts with mine operators, but without success.

Battery manufacturers and their suppliers are therefore working hard to develop new cathode materials that use less cobalt. Tesla and his partner Panasonic appear to be ahead of the competition, as previously known: According to the laboratory analyzes leaked to WirtschaftsWoche, the cathodes of the Panasonic cells used in the new Tesla Model 3 consist of only 2.8 percent cobalt. The current state of the art is currently eight percent cobalt. "That would be a significant competitive advantage for Tesla, Kobalt is currently very difficult to get on the world market," says Sven Bauer, head of Germany's largest independent battery producer BMZ.
 
Oils4AsphaultOnly said:
lorenfb said:
The traction control system (ABS system) is not typically considered part of the "drivetrain". Yes, most OEMs can easily re-flash their drivetrain
ECUs, e.g. an engine controller or EV motor controller (inverter). Those ECUs are typically designed in-house where the OEM has control of the
source code. What is really needed is the actual re-flashing process as it totally relates to the ABS system AND the extend of the re-flash,
e.g. just minor setting of parametric values - max rate of change of wheel velocity, or a complete revision of the total controller's firmware.

Why? We don't need to know how they do it to conclude that they can make enough changes to fix the ABS behaviour on subsequent emergency stops (CR did get 130+ feet on their first test, it was the follow-up ones that failed miserably).

Yes, of course that's needed for a full understanding of the extent of the firmware re-flash. You are aware the some ECUs that are produced
in high volume may have just a small section of re-flashable memory, where the main firmware is contained in a mask ROM (not changeable).
Most likely the re-flashable section is just used for changing characteristics of the ABS function, e.g. stopping distance.

Oils4AsphaultOnly said:
You've said that you didn't think an ABS supplier would permit Tesla (the customer) access to overwrite their firmware, and now they've proven otherwise.

Your logic is lacking, Watson! Where's the proof of this? Re-read my previous statement.

Oils4AsphaultOnly said:
Either the ABS Supplier permitted it, or Tesla did their own ABS implementation and thus own their own code. You have to concede one of those positions.

As I have stated numerous times, most ECU suppliers provide end-users a small section of the ECU with re-flashable memory for tweaks
to the ECU's functionality. That's just like with the MCU ECU that's supplied by Nvidia, i.e. Nvidia DOES NOT supply the full source code
of the MCU to Tesla. Nvidia basically provides access for Tesla to change UI features of the MCU.

Furthermore, one can most likely conclude that Tesla didn't waste engineering resources developing their own ABS ECU, since the design
of the ABS (traction control) functionality is over 30 years old with well established algorithms. Besides there're many off-the-shelf sources
for that ECU. As was stated up-thread, an ECU supplier doesn't want the liability for system failures, e.g. deaths, because Tesla was
allowed access to the full source code of an ECU.

Avoid further guessing about the extent of the OTA firmware updates that Tesla provides without accurate information!
 
lorenfb said:
Oils4AsphaultOnly said:
lorenfb said:
The traction control system (ABS system) is not typically considered part of the "drivetrain". Yes, most OEMs can easily re-flash their drivetrain
ECUs, e.g. an engine controller or EV motor controller (inverter). Those ECUs are typically designed in-house where the OEM has control of the
source code. What is really needed is the actual re-flashing process as it totally relates to the ABS system AND the extend of the re-flash,
e.g. just minor setting of parametric values - max rate of change of wheel velocity, or a complete revision of the total controller's firmware.

Why? We don't need to know how they do it to conclude that they can make enough changes to fix the ABS behaviour on subsequent emergency stops (CR did get 130+ feet on their first test, it was the follow-up ones that failed miserably).

Yes, of course that's needed for a full understanding of the extent of the firmware re-flash. You are aware the some ECUs that are produced
in high volume may have just a small section of re-flashable memory, where the main firmware is contained in a mask ROM (not changeable).
Most likely the re-flashable section is just used for changing characteristics of the ABS function, e.g. stopping distance

....

Furthermore, one can most likely conclude that Tesla didn't waste engineering resources developing their own ABS ECU, since the design
of the ABS (traction control) functionality is over 30 years old with well established algorithms. Besides there're many off-the-shelf sources
for that ECU. As was stated up-thread, an ECU supplier doesn't want the liability for system failures, e.g. deaths, because Tesla was
allowed access to the full source code of an ECU.

Do you mind if I laugh at your serious attempt to justify the shaky ground you stand upon, Sherlocke?

"Why yes GM, stopping distance is indeed a parameter that you can tweak! Would you like to stop in 130ft like everyone else, or stretch it out to 150ft just to excite your customers?!"

Last I checked, EVERYONE wants to stop in as short of a distance as possible! That's why it's even measured!
 
Oils4AsphaultOnly said:
lorenfb said:
Oils4AsphaultOnly said:
Why? We don't need to know how they do it to conclude that they can make enough changes to fix the ABS behaviour on subsequent emergency stops (CR did get 130+ feet on their first test, it was the follow-up ones that failed miserably).

Yes, of course that's needed for a full understanding of the extent of the firmware re-flash. You are aware the some ECUs that are produced
in high volume may have just a small section of re-flashable memory, where the main firmware is contained in a mask ROM (not changeable).
Most likely the re-flashable section is just used for changing characteristics of the ABS function, e.g. stopping distance

....

Furthermore, one can most likely conclude that Tesla didn't waste engineering resources developing their own ABS ECU, since the design
of the ABS (traction control) functionality is over 30 years old with well established algorithms. Besides there're many off-the-shelf sources
for that ECU. As was stated up-thread, an ECU supplier doesn't want the liability for system failures, e.g. deaths, because Tesla was
allowed access to the full source code of an ECU.

Do you mind if I laugh at your serious attempt to justify the shaky ground you stand upon, Sherlocke?

"Why yes GM, stopping distance is indeed a parameter that you can tweak! Would you like to stop in 130ft like everyone else, or stretch it out to 150ft just to excite your customers?!"

Last I checked, EVERYONE wants to stop in as short of a distance as possible! That's why it's even measured!

You're obfuscating the issue, i.e. Does Tesla have the ability to OTA a full re-flash (all firmware) of any ECU within its vehicles from outside
vendors as some believe?. Yes, some ECU vendors may provide Tesla some re-flashable firmware/memory area within its ECUs to tweak
some parameters. This is typically what most all OEM automotive producers have the capability to do.

Still waiting for detailed info about Tesla's OTA firmware re-flash capabilities as it relates to outside sourced ECUs.
Probably a total waste of time to expect any real detailed info anyway, i.e. this is a total waste of time as are many threads
related to Tesla here on MNL.
 
InsideEVs has the Model 3 deliveries estimated at 6,250 for May 2018.

Incidentally the Leaf now appears to be outselling the Bolt EV in the same estimate.

*GM and Tesla only report deliveries quarterly but InsideEVs has historically been very accurate in their estimations.

https://insideevs.com/monthly-plug-in-sales-scorecard/
 
lorenfb said:
Oils4AsphaultOnly said:
lorenfb said:
Yes, of course that's needed for a full understanding of the extent of the firmware re-flash. You are aware the some ECUs that are produced
in high volume may have just a small section of re-flashable memory, where the main firmware is contained in a mask ROM (not changeable).
Most likely the re-flashable section is just used for changing characteristics of the ABS function, e.g. stopping distance

....

Furthermore, one can most likely conclude that Tesla didn't waste engineering resources developing their own ABS ECU, since the design
of the ABS (traction control) functionality is over 30 years old with well established algorithms. Besides there're many off-the-shelf sources
for that ECU. As was stated up-thread, an ECU supplier doesn't want the liability for system failures, e.g. deaths, because Tesla was
allowed access to the full source code of an ECU.

Do you mind if I laugh at your serious attempt to justify the shaky ground you stand upon, Sherlocke?

"Why yes GM, stopping distance is indeed a parameter that you can tweak! Would you like to stop in 130ft like everyone else, or stretch it out to 150ft just to excite your customers?!"

Last I checked, EVERYONE wants to stop in as short of a distance as possible! That's why it's even measured!

You're obfuscating the issue, i.e. Does Tesla have the ability to OTA a full re-flash (all firmware) of any ECU within its vehicles from outside
vendors as some believe?. Yes, some ECU vendors may provide Tesla some re-flashable firmware/memory area within its ECUs to tweak
some parameters. This is typically what most all OEM automotive producers have the capability to do.

Still waiting for detailed info about Tesla's OTA firmware re-flash capabilities as it relates to outside sourced ECUs.
Probably a total waste of time to expect any real detailed info anyway, i.e. this is a total waste of time as are many threads
related to Tesla here on MNL.

No one is going to post detailed sensitive info even though you have already been disproved by default. You assume that Tesla does not have different agreements with suppliers and you assume all supplier agreements are the same. More than one person hacked into the Tesla system and you can see all that Tesla updates, what files come from their servers and all the various access levels to components. Because other companies do not do this does not mean it is not possible. In fact there are people in the general public that have access to more information than the Tesla techs can see with their tools. The level of detail and depth of information access on Tesla products is unlike anything any dealership has access to or auto maker ships today.

You speak of liability, how to you think Tesla tweaks ABS to work with regen? You don't think that is liability issue? Where do the level of adjustments end? Where does firmware flashing begin end end? You really don't think they have deep access? Any supplier can grant access and changes if they choose to do so or if it makes sense for both parties. Educate yourself on the basics of the car before you start diving into the deeper technology. Start with riding in one because as of this moment you won't even admit if you have driven one which makes your credibilitysuspect. If you are going to come on a Tesla thread and post about technology you should at least drive one.

I'll ask you this one last time because you so often ask people specifics about things and ignore questions from others. Have you ever driven a Tesla? What is your direct experience with the car? Answer that please, it's not a personal question and It's all I want to know really. In fact If you answer I will never reply to another post of yours except that one.


Or- Let's say they can't do what your say, what are we left with? You arguing about the most upgradable car ever built, one that can have braking parameters changed OTA, one you have likely never driven.
 
Regardless of who has access to what code, etc, am I the only one surprised that an issue with the operation of the brakes could be identified, updated and sent out to the field in 1 week? That just seems like it wouldn't leave much time for testing and all that stuff....
 
goldbrick said:
Regardless of who has access to what code, etc, am I the only one surprised that an issue with the operation of the brakes could be identified, updated and sent out to the field in 1 week? That just seems like it wouldn't leave much time for testing and all that stuff....

It depends. It may have been done already and Tesla rolls updates in waves, monitors them and then continues on. The update may have been pretty much done and the pushed it to that car after it was identified. Tesla owners know that not everyone gets the same update or updates at the same time. Some updates can be very staggered and also targeted. I get updated pushed to my car and it is even possible to revert back to an older update if you have the ability. When visiting service they push any updates to your car you may not have received based on the schedule. Regardless it's not surprising. The deep OTA update feature has many benefits to consumers accompanied by drawbacks as an auto maker can release products before they are fully refined. So far Tesla owners seem to be ok with the trade offs and it gives Tesla haters something to latch onto and gripe about of course.
 
Back
Top