Welcome to Tesla Motors Club
Discuss Tesla's Model S, Model 3, Model X, Model Y, Cybertruck, Roadster and More.
Register

New headlights retrofit

This site may earn commission on affiliate links.
So based on that, the headlamp ECU firmware is updated according to the matrix headlight internal config, but then this fails a check in the gateway because the headlamp ECU firmware no longer matches the vehicle config. This is kind of enlightening in the update process, in that the components seem to be independently updated but checked by the main computer.

Does this mean the main OS can be fooled into supporting the headlamps if the ECU CAN firmware value is intercepted and changed to the old firmware value? That will probably mean you can't do a light show with matrix headlamps but you could use them as normal.

EDIT: This is an old but good resource for understanding what is happening.
 
Last edited:
  • Helpful
  • Like
Reactions: Bull and WhiteM3P-
Without insight to the firmware code it's impossible to know whether there is code even there to interface between body controllers running one version of firmware, and lights and other modules running firmware that is designed to work with different hardware on newer cars.

To use my heated steering wheel as an example. I found out that the left body controller on my car had been revised (twice) since I got the car. It turned out the harnesses in that part of the car had changed, so even though the physical connectors and wiring connecting the wheel to the steering column was the same other stuff in the pathway wasn't.

Further investigation from Tesla suggested that the older left body controller may have never been designed to handle a heated steering wheel (e.g. undersized MOSFETs). It might be able to handle it - people have hacked ways of doing it - but obviously Tesla are not going to write and install code to provide backwards compatibility without a financial incentive. So in that scenario even if the car could support a heated steering wheel on older cars, using the older left body controller, it wouldn't simply because the firmware for that version has never been written to support it. It's not expecting to "see" the heated steering wheel on that revision, so it doesn't run code to support it.

It could be the case that this is similar with the matrix headlights.

If "level 3" techs can't change this stuff, then short of getting hold of the software team to work out what in the pathway between headlights and controllers is incompatible, there is a good chance it can't get progressed. Definitely frustrating, but not a lot you can do.
 
Without insight to the firmware code it's impossible to know whether there is code even there to interface between body controllers running one version of firmware, and lights and other modules running firmware that is designed to work with different hardware on newer cars.

To use my heated steering wheel as an example. I found out that the left body controller on my car had been revised (twice) since I got the car. It turned out the harnesses in that part of the car had changed, so even though the physical connectors and wiring connecting the wheel to the steering column was the same other stuff in the pathway wasn't.

Further investigation from Tesla suggested that the older left body controller may have never been designed to handle a heated steering wheel (e.g. undersized MOSFETs). It might be able to handle it - people have hacked ways of doing it - but obviously Tesla are not going to write and install code to provide backwards compatibility without a financial incentive. So in that scenario even if the car could support a heated steering wheel on older cars, using the older left body controller, it wouldn't simply because the firmware for that version has never been written to support it. It's not expecting to "see" the heated steering wheel on that revision, so it doesn't run code to support it.

It could be the case that this is similar with the matrix headlights.

If "level 3" techs can't change this stuff, then short of getting hold of the software team to work out what in the pathway between headlights and controllers is incompatible, there is a good chance it can't get progressed. Definitely frustrating, but not a lot you can do.
Heated steering wheel config.. is not the best example to the Matrix confi..
Matrix as it stands today is 100% software configurable with new lights installed.

And as to your hardware point, some cars are capable of heated steering wheel yet didn't from factory..that's a fact.
 
  • Like
Reactions: goRt and ph0ton
So based on that, the headlamp ECU firmware is updated according to the matrix headlight internal config, but then this fails a check in the gateway because the headlamp ECU firmware no longer matches the vehicle config. This is kind of enlightening in the update process, in that the components seem to be independently updated but checked by the main computer.

Does this mean the main OS can be fooled into supporting the headlamps if the ECU CAN firmware value is intercepted and changed to the old firmware value? That will probably mean you can't do a light show with matrix headlamps but you could use them as normal.

EDIT: This is an old but good resource for understanding what is happening.
So originally I was told that the car was unable to detect the headlights that were installed and that it would only send the lin signals it was configured for at the gateway. We now know this isn't true. There is two way comm between the headlight and front body controller to the MCU. So in theory a couple lines in future code could auto update headlights for the appropriate hardware installed.
 
  • Like
Reactions: eesmjus and ph0ton
Cars have always been in the domain of aftermarket modifications, and Tesla is not expected to support matrix headlights any more than GM is expected to support superchargers installed by the owner.

People keep talking about gateway configurations like it's the landscape of Android phones but it's not the same at all IMO. Everything in a car is "mission critical" and I don't think we should give Tesla a pass for locking down a trivial aspect of our cars which have been modifiable for decades. The gateway configuration is literally just a text file read by the OS; the implementation of said features are done discretely within components, communicated over CAN. Everything is highly standardized, modularized, and there is absolutely no risk of an OTA update hitting a bad config with factory parts as it currently stands.

That obviously won't last forever but within comparable versions, this will hold true. But in the larger picture, manufacturers will continue advancing this draconian logic, forcing us into obsolescence, if we don't present some friction in these practices.

I think stopcrazypp is right in that the average person should just take the easy route and get a newer car if it matters so much to them. A select few of us who care about the rights of modifying or repairing our property will keep on trying to force the issue, and everyone else will benefit from it. If it's a fight worth picking then good, and if not, then that's also good. :)

Either way, it's nothing to get too upset over. As others have said, the matrix headlights are a marginal improvement at best, and some of the best capabilities (selective dimming, adaptive response to curves, etc) aren't event on the table now. For me it's an exercise in unlocking my car and helping others to do so too by understanding the electronic infrastructure. (it's also really cool)
I think you are over-trivializing this. It may "just" be a simple "text" comparison, but from the linked error, they are comparing the firmware versions and making sure they aren't installing firmware that doesn't match the configuration. That's the bare minimum I think most security researchers would expect Tesla needs to do to support a robust OTA process.

What other automakers are doing is not comparable at all, as they use dealers to do their critical updates, so they have a service tech which minimizes the chance of error. OTAs on mission critical parts (not just infotainment) are a whole different ball game. Those of us used to Tesla seem to take a matter of fact that OTAs are easy to do, but you can see the teething problems other automakers have had:
Lucid Air briefly "bricked" after failed over-the-air software update
Volkswagen 'Over The Air' Software Upgrade May Require A Dealer Visit
https://www.macheforum.com/site/threads/ota-1-7-1-stuck-anyone-else-have-issue-updating.10071/
This article has a decent summary of the status of OTAs for automakers, you can see that for practically all of them, they are either infotainment only updates, or more minor patches (still requires owner to take car to dealer for more major updates). There's still a long road ahead for them to make it so everything can be updated via OTA, and they may end up having to do similar firmware version checks.
Over-the-air updates: How does each EV automaker compare?
 
I think you are over-trivializing this. It may "just" be a simple "text" comparison, but from the linked error, they are comparing the firmware versions and making sure they aren't installing firmware that doesn't match the configuration. That's the bare minimum I think most security researchers would expect Tesla needs to do to support a robust OTA process.

What other automakers are doing is not comparable at all, as they use dealers to do their critical updates, so they have a service tech which minimizes the chance of error. OTAs on mission critical parts (not just infotainment) are a whole different ball game. Those of us used to Tesla seem to take a matter of fact that OTAs are easy to do, but you can see the teething problems other automakers have had:
Lucid Air briefly "bricked" after failed over-the-air software update
Volkswagen 'Over The Air' Software Upgrade May Require A Dealer Visit
https://www.macheforum.com/site/threads/ota-1-7-1-stuck-anyone-else-have-issue-updating.10071/
This article has a decent summary of the status of OTAs for automakers, you can see that for practically all of them, they are either infotainment only updates, or more minor patches (still requires owner to take car to dealer for more major updates). There's still a long road ahead for them to make it so everything can be updated via OTA, and they may end up having to do similar firmware version checks.
Over-the-air updates: How does each EV automaker compare?
I'm only talking of regulations and caution for the sake of such when I compare traditional manufacturers. As for the OTA implementation, it's necessarily simple because it must be. It's unpacking the module firmware in the image and deploying it on update. That's it. As long as the module chain is valid, then the firmware is valid, and it must work with the car. As the protocols advance and infrastructure changes, this won't apply so I think similar teething problems will occur with legacy vehicles as the software advances. So far, Tesla's response is simply not to deploy software on legacy vehicles. The firmware incompatibility with the headlamps is only an issue because of the factory configuration, not because of an innate difference in the hardware chain.

OTA is complicated because network infrastructure isn't trivial as well as version control over an entire fleet. Tesla had a software-company mindset from the beginning so they knew how to deploy it properly. This will be much more difficult when the deployment is as fractured and heterogeneous as the landscape of vehicles from traditional manufacturers (in a decade imo). I think your sentiment will ring true then, but right now Tesla is doing this for financial reasons (demand of new vehicles, limited demand on retrofitting old ones) rather than technical reasons.
 
Fairly new to Tesla but have been part of the BMW “coding” scene for a while. What are the chances we could install the new physical headlight units and have them work? Would the car simply throw errors or would it adjust? In the BMWs you can retrofit parts and then with a laptop and “coding” software you can flash the car to work with the new parts.
I asked a mobile ranger about headlight swap DIY and he said they are not coded (at least on the 2016's)
 
Just a thought.. let's say someone were to get the matrix working and was using the headlights. Tesla decides it wasn't the regular config for the car and reverts back. Do you think the customer can hold tesla liable for damages if an accident occurs.. this occurred to me as I am planning on driving to a tesla approved body shop today. I will see if their toolbox can do it.
 
Just a thought.. let's say someone were to get the matrix working and was using the headlights. Tesla decides it wasn't the regular config for the car and reverts back.
Tesla does have a "bot", called Teleforce, that enforces settings on cars remotely every few minutes. I don't know if headlight configuration is currently one of the parameters it enforces or not, but it certainly could be added in the future if it isn't already.
 
Unfortunately as connected as these cars are, I don't see Tesla allowing any aftermarket upgrades like this. I'd love to add the premium audio from the LR into my SR+ to keep it all factory but from what I have read this isn't an option.
 
Just a thought.. let's say someone were to get the matrix working and was using the headlights. Tesla decides it wasn't the regular config for the car and reverts back. Do you think the customer can hold tesla liable for damages if an accident occurs.. this occurred to me as I am planning on driving to a tesla approved body shop today. I will see if their toolbox can do it.
Actually, liability likely is why Tesla has to (or already has) clamp down on this harder and make it abundantly clear they don't support this if they don't intend to do so. So if they do any software updates and something screws up because it's a part that doesn't match factory configuration, it's all on you when they have made that clear. It's a different case if they decide to officially offer retrofits, but obviously they have no plans to do so at this point.
 
Last edited:
Actually, liability likely is why Tesla has to (or already has) clamp down on this harder and make it abundantly clear they don't support this if they don't intend to do so. So if they do any software updates and something screws up because it's a part that doesn't match factory configuration, it's all on you when they have made that clear. It's a different case if they decide to officially offer retrofits, but obviously they have no plans to do so at this point.
I'll sign a waiver if they get this moving.
 
  • Like
Reactions: Danny Brown