Not really a project progress thread, but it fits in this section better than anywhere else. The concept is also not Tesla-specific, but it happens to be built for one. I'm posting it here because it's interesting and I'm hoping it'll spark ideas and discussion.
This is a project of a friend of mine - he has a Model 3 and wanted some display in front of the driver. So he built a display that reads the information off the CAN bus and displays it graphically on a small screen he's mounted in front of the driver. He started off with a clear goal of what he wanted to see and has added a few things just because they're neat, like the amount of torque being delivered or regenerated via the front and rear axles.
Regardless of how people feel about glass cockpits and a center-mounted instrument stack, I think it's a good example of what you can do with modern tools and the data coursing around inside a car. It's read-only so there's no chance of borking something. It's really not that different than my analog race dash project but has less hardware screwing around.
This is different than a scangauge-type unit that's just querying the OBD-II interface. It's much faster and has access to all the data. The downside is that it's manufacturer-specific, you need to know the content of the messages so they can be decoded. The Tesla is a good platform for this because there is a ridiculous amount of information being sent around the car. GM publishes their data format so it would be easy to build something like this.
It would be possible to have something external react to some of these messages. For example, you could have some aftermarket exterior lights turn on and off with the high beams, or undercar lighting that turns on when the door is open. Or undercar lighting that changes color depending on if you're accelerating or regenerating. Or undercar lighting that moves down the road tied to road speed so it looks like the lights are static - okay, I'll stop with the undercar lighting. How about an active wing that trims itself based on speed, steering angle and braking? Or an onboard camera that looks where the wheels are pointing? I think this is where some of the really fun applications potentially lie.
In my case, I used those messages to move some motors that happened to be attached to needles on gauges.
Now, trying to control something by injecting messages is a different matter. To emulate a simple button push, that's easy. So if you wanted to replace the on-screen button in a Tesla for "turn on left rear seat heater" with a physical button, you'd just send the appropriate message and the body control module would react by turning on the heater and changing the status of that heater in the data. Overriding a continuous stream is a lot more difficult. You can spam the network with your version and hope to overwhelm the stock message, which is done by some developers. It obviously means you will get occasional failures where the stock message "wins" and you can saturate the network and make it stop working. It's the lazy and easy method.
A better solution is to block the message and send your own, but this requires physically inserting a device (a gateway) into the appropriate wires and the small delay added can cause problems with other systems. For example, we do use this technique in our ND V8 cars and if the gateway is in the wrong part of the bus, the stability control system notices the very slight lag in the messages being passed through and interprets it as a failure.
Holy rambling, batman. TLDR: neat project, what can we do with this stuff?
