The "scan my tesla" cable and bluetooth OBD connector arrived about 3-4 weeks ago. An executive summary, here are the problems and solutions I chose:
I. Android device
Google and forum searches, I soon found Android has a lot of variants often sold as new that often have older Android versions. For example, my wife's Android cell phone is at version 7 and only T-Mobile provides updates. Version 7 appears to have memory leaks that require maintenance at least weekly or it stops taking calls ... along with other faults.
Fortunately, Costco had a special on a $199, Samsung, Galaxy Tab A, 128 GB, 10.1" running Android 9. With only WiFi and V5 Bluetooth V5 (2 mbs), it is large but very capable. When recording data, I use the text 'gauges' since I'm interested in the CSV data file and not looking at cabin gauges.
II. Installation
The instructions are a little 'light' but in a collaborative effort, the 'Owners' group helped figure it out. Power down the car requires leaving the doors open and the power relay KLACK was the reward. Changing connectors with power ON is risky.
The final installation is a work in progress as there is not a lot of space behind the Tesla cover and no provisions for the OBD interface. In my case, only one side of the cover is clipped providing space for the wiring assembly and running the OBD cable external to the cover. The signal strength -61 db appears to be enough
III. Operational Scenario
Initial data captures showed 'noise' suggesting the Galaxy/OBD was under running the data stream. Restricting the log to the CSV format and using the simple text 'gauge' reduced these problems. There are still occasional data errors that can be easily handled in the spreadsheet.
A MacOS user, I found the Android interface inconsistent and transferring data via SD card was awkward. This was solved by "AirDroid", $25/yr subscription, that makes a web interface on the Android device supporting efficient file navigation and download to the MacOS.
IV. Initial Study
One of my interests is efficiency, OUTPUT / INPUT, expressed as an efficiency %. So I went to a favorite benchmark road, Brindley Mountain, a 1.1 mi (1.76 km), ~500 ft (~160 m), ~8% grade, South of Tennessee River, Route 231. Waiting for traffic to pass, pull onto the road and stop. Then floor the accelerator to climb the hill; turn around at the top, and; descend on cruise control.
CHILL MODE
Less 'frantic' driving, it still reaches the speed limit before anyone else at a light. So this is the first run:
- Initially the car has reduced power to avoid spinning the tires. But around 60 kph (~37 mph) the full power is not available. Then the full power kicks in, ~140 kW (~188 hp).
- Full power, climbing efficiency approaches ~98%.
- To avoid a scary curve at the top, 180 kph (112 mph).
- On the descent, the ~103% has a slight, ~1%, decrease in efficiency.
STANDARD MODE
Not used except for benchmarks, included here:
- Peak power ~220 kW (~295 hp)
- Peak velocity ~180 kph (112 mph) is also limited by the low banked curve at the top
- Efficiency ~102% does not make sense unless there is a battery or traction motor power data problem
- Descending efficiency, ~103% is about 1% less efficient than climbing suggesting the power efficiency is similar to chill mode
Bob Wilson