As I stated in the start, this project is a bit crazy for the cost and amount of effort it took. It really started with a phone-based CAN bus analyzer I designed. This got bogged down as the off-the-shelf CAN bus products I tried couldn’t keep up with the massive amount of data Tesla produces on a single CAN bus, let alone the 4 busses I wanted to monitor. It works well when you limit the data (which is done at the hardware level), but I wanted it all.
I shifted gears to designing my own low-level hardware and writing my own code for the microcontroller. This connected to the phone via USB. Bluetooth would never work for this, as it is way too slow. I then found the phone itself was also unable to process the massive amount of data coming in, store it and display the data in different ways in real-time. This was not going the way I wanted! During this time, a few other owners introduced products with limited CAN bus recording with off-line processing. I may revisit that project as the phones/tablets gain more power. I only need that Intel i9 18 core extreme CPU that lasts longer than a few seconds on a cell phone battery!
I got the idea for Tshow when the refresh Model S came out, as it had the perfect display area behind the front T-badge. I could reuse some of the hardware and software work I’d previously done as Tshow is far less demanding. Meanwhile, a new microcontroller with dual CAN bus hardware appeared late last year, which was perfect for this project. I didn’t need all four CAN buses, but I did need two (CAN 2 and CAN 3) for monitoring data.
With some of the prior work I’d done and more analysis of CAN bus traffic, I identified critical ids to track for the various features. Here are the IDs I track for Tshow:
|2||0x209||2||6||Left Blinker On|
|2||0x20A||2||6||Right Blinker On|
|3||0x00E||0 & 1||Steering Position|
|3||0x222||0 & 4||Charging State|
|3||0x302||1 & 2||State of Charge|
This CAN data was on a refreshed Model S. It’s likely to be the same on all versions of the Model S and Model X. It may even be the same on the Model 3.
To include day/night brightness and holiday features, I needed an accurate date and time. Unfortunately, I was only able to find the date/time broadcast on CAN bus 6. Since I didn’t want to add a third CAN bus to the project, so I used the processor’s built-in RTC along with battery backup. I wrote the code so the time and date are automatically set when the app connects to the processor.
I built the prototype on a breadboard, which makes it easy to try out different processors and design ideas while creating the companion Android app.
As the project rolled along, I concluded PCBs would be necessary to ensure reliability and compactness. That meant learning the latest schematic and PCB software. Of course, I made a few mistakes and had to re-run new boards. This is no different than most engineering projects (although costly for a one-off project).
Version 2 still had a couple of minor errors, and the remote control’s NeoPixels data was unreliable on longer cables. I added a second differential bus transceiver and fixed the errors on the version 2 board. The version 3 schematic covers all these changes.
A few sharp engineers may notice I used some modules rather than surface mount ICs. Surface mount parts are difficult to solder for a one-off project and these specific parts are only available in surface mount. Luckily, there are modules available with the surface mount ICs, that is only slightly more expensive than the IC itself. They do take up a little more PCB board space, but not enough to matter.
The NeoPixels use a single serial data line. This becomes unstable for longer runs, typically over 12″. By using differential transceivers, the signal is not affected by wire length. The processor module connects to the receiver and remote via a differential connection, which in turn connects to NeoPixels.
The receiver needs mounting on the T-badge assembly very close to the NeoPixel input. I found the desired mounting on the passenger’s side physically interfered with the radar module, so in a last-minute decision, mounted it on the driver’s side and flipped the NeoPixels so the start (i.e. pixel 1) was on the driver’s side to keep the wire run as short as possible between the receiver and the NeoPixels data input. This required a fairly significant software change to “flip” the visual direction in various display modes.
Along the way, I couldn’t find a suitable plastic box to house the remote unit. I got the brilliant idea to make a 3D box for it – having never done so before! This required learning a new CAD system – Tinkercad. It took 3 tries to get it right, but the design improved dramatically with each iteration. With that under my belt, I had planned to use a stock plastic box for the receiver, but a 3D box would be so much better. I got a good box design after two tries. For those who have never done 3D design, the tools today are quite impressive. Once the design is complete, I used an online service to choose a fabricator to make it, often in 2-3 days. Printing each box in ABS costs under $20. In the last iteration, I combined both boxes into a single print.
My one regret is not making a 3D box for the processor unit. This would have been a bit more complex design and costly. It would have saved quite a bit of rework on the stock plastic box. If this is ever made into a production product, a 3D processor box would be great.
I wrote the microcontroller software using the Arduino IDE, in C++ code. While the Teensy 3.6 processor can run at up to 192 MHz, I run it at 120 MHz as more speed is unnecessary and it reduces the power consumption slightly. I wrote the Android software in Java using Android Studio. As such, it may not be easy to port to Apple iOS. Not something I’ve investigated. Android devices such as a 5″ quad-core phone with Android 6.0 and Bluetooth 4.0 can be had for as little as $50 and will work great with this project if you don’t already have an Android phone or tablet