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

Introducing tripography.com - Track your Road Trips and Daily Drives

This site may earn commission on affiliate links.

PureAmps

Model S P85 (#2817)
Oct 22, 2012
359
7
SF Bay Area
Greetings fellow TMC members,

For a couple of months now, I've been working on a website to track various vehicle stats for the Model S. That website is called tripography.com, and this week I've started opening it up to a limited number of Model S owners. You can find my public vehicle stats at PureAmps on Tripography. I'm looking for a few additional Model S owners who are interested in being beta testers for the site.

Background

I, like many others on this site, have been experimenting with the vehicle's telemetry data since the Tesla mobile app was released earlier this year. I have done a few things for fun with that data like have my car send out automated tweets via @PureAmps. I also provided real-time telemetry data for the Tesla Road Trip drivers who recreated Broder's infamous drive. I realized after the Broder incident and the Telsa Road Trip team's recreation of that event how powerful data can be in shedding a light on the fear, uncertainty and doubt that currently surrounds electric vehicles. That event was the impetus for creating this site.

What is Tripography

Tripography is intended to be a community resource for Tesla owners (and future owners), and the EV community in general. It is somewhat inspired by Volt Stats, a website created by a Chevy Volt owner for tracking Chevy Volt statistics. Volt Stats is currently tracking ~1800 Chevy Volts and has recorded over 16M EV miles. I'm hoping we can do a little better (over time).

Tripography is a website that gathers information about your driving and charging behavior directly from your vehicle. That data is made available to you for your own personal use. But more importantly, that data is aggregated across all tripography users by geographic region, vehicle type, etc. for use as a community resource for all Tesla owners (current and future).

  • Want to know how much to charge your car each night for your typical daily drives? Tripography can tell you that.
  • Want to know if there is a difference in driving behavior between 60 kWh vs 85 kWh owners? Tripography can tell you that.
  • Want to know how long it takes for a typical road trip from SF to LA in a Tesla Model S? Tripography can tell you that.
  • Want to know the on-peak/off-peak supercharger times? Tripography can tell you that.
Actually, tripography can only theoretically tell you some of those things. What tripography needs to tell you those things is your vehicle's data. Without your (collective) data, tripography is only a mildly interesting vehicle stats tracking site.

The site is still in its infancy, has only been live for a few weeks, and is currently only tracking daily driving distance for a few vehicles. For example, here's my daily driving for the past few weeks:

Screen Shot 2013-06-07 at 5.42.26 PM.png


Looking at this graph, I remember that great trip I took up to Sonoma over Memorial Day. No problem in my Model S. ;)

Here's the distribution of my daily driving over that same period:

Screen Shot 2013-06-07 at 5.42.34 PM.png

With only a few weeks of data, I can already tell from looking at the graph that most my Model S daily driving seems to be in the 40-70 mile range per day.

Beta Testers Needed

Interested? Great! Here's what you can do to help.

Go to tripography.com and request an invitation by submitting your email address on the home page. I'm giving priority access to TMC members, so if you would really like to have an invitation sooner rather than later, please send me a PM with your email address, your vehicle type and general geographic region. In particular I'm looking for:

  • A 60 kWh Model S owner
  • A Canadian owner (I need to do some metric testing!)
  • Owners in the Mountain and Central timezones
I will only be adding a limited number of vehicles per week. During tripography's beta period, access will be limited to 100 vehicles total, so that I can better understand the performance issues surrounding the website and the impact it may have on Tesla's telemetry servers. I hope to launch the site and open it to all owners at the end of the Summer.

Security and Privacy

Security and privacy are a top priority to me in operating this website as they should be for you. I'm currently finalizing the site's official Privacy Policy. But the goal of Tripography is to share some limited data about your vehicle with the community at large. So if you have severe qualms about that, this is not the website for you.

So what type of data will be shared and aggregated?
  • Daily Driving distances (aggregated to the country/state/county/city levels)
  • Daily Charging habits (time/duration/soc) (aggregated by location to a specific charger if it is a public charger (e.g. a supercharger).
What may be optionally shared?
  • Road Trips (start city/destination city and all stops in between, including charge times/locations (if public))
What is never shared?
  • Your car's exact GPS location
  • Your VIN
  • Any other personally identifiable info (your name, your email, etc.)
Tripography requires your Tesla Motors login information to access your vehicle's telemetry data. By using tripography to track your vehicle, you are giving permission to periodically obtain telemetry data from your vehicle and granting permission to share, aggregate, and publish that data under the terms of the site's Privacy Policy (as roughly outlined above). Your Tesla Motors password is used only once to request a security token (cookie) from Tesla Motors' telemetry servers. The security token is encrypted and securely stored and periodically used to request data from your vehicle. Under no circumstances are your Tesla Motors credentials used to access the "My Tesla" section of teslamotors.com nor is your Tesla Motors password ever stored on our site. You will be required to periodically renew your security token as it expires every 90 days. The website is hosted in the cloud and is designed and architected using industry-standard best practices that are commonly used for running e-commerce sites that store and process consumer credit card data.

About Me

My name is George Scott, I live in the San Francisco Bay Area, and I have owned a Telsa Model S P85 (VIN #2817) since December 2012. I'm a software/technology entrepreneur who has founded several companies in the Bay Area. I'm currently a private investor and always at work on "the next big thing". Hint: tripography.com is probably not it. ;)

Tripography.com is owned and operated by RumbleWare Inc., a corporation I own and use to launch websites and apps from time to time. The site's official terms of service and privacy policy are currently being finalized, and will be made publicly available soon, but will largely be in line with the thoughts expressed in this post and standard industry practices.
 
Last edited:
Threw my name in the ring under the category of "horrible to non-existant 3G coverage through AT&T at home", meaning that getting telemetrics on my car when it is in the garage is nigh impossible, but having put 13k miles on the car since mid-November, I'd definitely generate plenty of stats in other categories for the currently SC deprived Atlantic coast.
 
This is cool, but as I'm sure you have considered, it would be great to have a way to avoid disclosing the password. A proxy service that each person ran on their own system, that reflects the calls to the webservice (hiding the password), but it would take too much technical expertise and people might not have a system at home running. Or some way to give an oauth token that only allows reading the car location but not logging into the website.
 
Threw my name in the ring under the category of "horrible to non-existant 3G coverage through AT&T at home", meaning that getting telemetrics on my car when it is in the garage is nigh impossible, but having put 13k miles on the car since mid-November, I'd definitely generate plenty of stats in other categories for the currently SC deprived Atlantic coast.

That is a great test case! I may have to add you to the list, just for the challenge. :)

This is cool, but as I'm sure you have considered, it would be great to have a way to avoid disclosing the password. A proxy service that each person ran on their own system, that reflects the calls to the webservice (hiding the password), but it would take too much technical expertise and people might not have a system at home running. Or some way to give an oauth token that only allows reading the car location but not logging into the website.

Yes, I agree 100%. I would prefer not to deal with passwords and instead have Tesla support a proper 3rd party authentication/authorization system like OAuth that is commonly used by sites like Facebook, Twitter, etc. In my conversations with Tesla, a 3rd party API is on their roadmap, but does not seem imminent. I have considered many ideas including a proxy service or relay of some type. Unfortunately, as you point out, they require some technical expertise to install and configure, and would have a large technical support burden that I cannot reasonably support.

I have debated launching this site for some time now because of this issue. I decided to launch the site after a few recent conversations with new owners that have never taken road trips because they consider it too "risky". These are people who have "almost" bought into the EV revolution, but just won't take that final step and drive down the I-5 from the Bay Area to LA using superchargers because they think they will run out of juice or it will take too long. I told them I've done it. But I can tell they are not quite buying it, and I'm just one data point to them. Well, what if I showed them several hundred data points....
 
Here's the distribution of my daily driving over that same period:

View attachment 23341
With only a few weeks of data, I can already tell from looking at the graph that most my Model S daily driving seems to be in the 40-70 mile range per day.
Great idea. I've been using Volt Stats! Tracking real world usage of Chevy Volts in the wild... since pretty much the inception.
Along the lines of your graph above with aggregate data you can see the the overall drivers.

Agg: Voltstats DailyTab: http://www.voltstats.net/#dailyTab

18C7s.jpeg



Lot of graph possibilities for the individual owners as well.
Individual example : http://www.voltstats.net/Stats/Details/11

18C8b.jpeg
 
All -

George reached out to me recently to be a part of this great endeavor and I jumped on in a heart beat. Ever since the @TeslaRoadTrip and the great tweeting his code did, I knew he would do something like this eventually! Looking forward to seeing good data for my own records as well as contributing my 25,000+ miles a year to the community and showing what the Model S can really do!

My Stats Page:

https://tripography.com/AaronGS

Aaron
 
This is cool, but as I'm sure you have considered, it would be great to have a way to avoid disclosing the password. A proxy service that each person ran on their own system, that reflects the calls to the webservice (hiding the password), but it would take too much technical expertise and people might not have a system at home running. Or some way to give an oauth token that only allows reading the car location but not logging into the website.

That's what I was thinking. Can I generate my own token and provide it?
 
I wanted to give a quick update based on all of the messages I have received over the past 36 hours. First, thanks for the overwhelming interest in the site. Response has been much better than I expected. I've received dozens of PMs (sorry, I still haven't gotten back to all of you), over 30 signup requests on the website in the first 24 hours, and increasing by the hour (currently ~40 signups). I had expected it to take 6-8 weeks to get 100 people interested, seems like it may happen in the first week! I also now have plenty of 60 kWh vehicles, all North American timezones and Canada covered.

This week I will be adding just a few new vehicles so that I can continue testing some edge cases that are not covered by vehicles currently being monitored. I'm also on vacation at the end of June, so there may be a pause in the vehicle expansion until I return. So please be patient in the interim. I will try to get you all online as soon as possible.

I also wanted to clarify that this site is currently just an experiment. I'm running it as an owner for other owners. I'm doing this as a hobby/side-project, so please keep that in mind. I'm striving for the site to be reliable and maintenance free, but if it goes down at 3am, I'm not going to be getting up to fix it. :eek:

Finally, based on some of the comments I've received, I wanted to give some more insight into how the site works and how some of the features will work. But, I will do that in a followup post later today or tomorrow, when I have a little more time.
 
Tripography Update

TMC, thanks again for the interest in tripography. Tripography is currently gathering data from a dozen different vehicles and I've just sent the final batch of invites out for the week. I'm trying to keep it under 20 vehicles for the next couple of weeks, since I'll be traveling at the end of June. I have a huge backlog of invite requests to go through and I will get to you all as soon as I get back from vacation. I think I'll hit my self imposed 100 vehicle limit much quicker than I expected. :scared:

I've had a lot of great feedback and suggestions on tripography. I wanted to explain a few of the challenges in implementing this site so you may better understand why I've chosen to implement features a certain way and why there will be a slow roll out of the site.

Tripography is using the same Tesla servers that power the Tesla mobile app. These server APIs were not designed for 3rd party applications and only provided limited access to the car's data. From my email exchanges with Tesla, it is clear they are committed to a formal 3rd party application ecosystem, but it may be a while before it is available. In the meantime, they are currently "neutral" on the use of the mobile APIs for other purposes as long there is not excessive load on their servers or use of network bandwidth. Which is a nice way of saying Tesla will tolerate our use of these APIs as long as we don't become a huge pain in the ass and cause a service disruption to the mobile app.

So the biggest challenge in designing Tripography is to avoid putting excessive load on Tesla's servers, while still designing a service that could support monitoring hundreds and eventually thousands of vehicles. Tesla's current server API is designed to support the mobile app, so it is geared towards occasional use and real-time querying of the car's current state (drive, charge, climate, etc.). It is not designed for an analytics application like tripography.

In a perfect world, after you've parked your car at the end of the night, tripography would talk to your car and ask "what did you do today?" and your car would say: "I drove from A to B in 34 mins, covering a distance of 24 miles, and used 7.2 kWh of energy, then I charged for 2.5 hours @ 40 amps and added 24.3 kWh of energy, then I drove from B to C, etc..., now I'm home and will charge at 12:30am to 80% soc, I'll give you a ring when I'm done.". Unfortunately, that is not how the system currently works. Instead, tripography has to constantly ask your car "What are you doing?", and then try to piece together a picture of what happened over some period of time. The more frequently tripography asks your car "What are you doing?", the more accurate that picture becomes.

In designing tripography's features, I've tried to strike a balance between the data I'm trying to get out of the vehicle and the burden placed on Tesla's infrastructure, so that tripography doesn't become a major annoyance to Tesla (or owners trying to use the Tesla mobile app).

Because of these constraints tripography has two very different behaviors for daily driving versus road trips.

For daily driving, tripography calculates your daily mileage by reading your odometer each night. Since this is only done once a day, there is minimal load on Tesla's infrastructure. The other assumption for daily driving is that you are using "slow" charging (not superchargers), so there is less of a need to poll the vehicle frequently to see if it is currently charging. I'm expecting typical charge times will be at least one hour or more. I'm still playing with the algorithm to query the charge state for daily driving, but I do not expect a significant burden on Tesla's servers to track charging behavior for typical daily driving scenarios.

Now let's talk about road trips. This is the feature I most wanted to implement after my experience with tweeting the TeslaRoadTrip team's recreation of the Broder drive. For this feature, I want to capture all legs of your road trip, including super-charging stops. This requires querying your vehicle at a very frequent rate. This undoubtedly places a higher load on Tesla's servers than they had intended. It is the equivalent of you checking your car's status on the mobile app every 5 minutes, all day long. I think there is huge value in this data, and I don't think Tesla will mind too much, as long as this feature is used in a limited manner. :) So the way the road trip feature will work on tripography, is that you will have to log in and turn on "Road Trip" mode for your car. When you do, telemetry data will be queried at a much higher rate for a period of time (basically, until your car is parked for an extended period of time). This data is accumulated into a Road Trip Log, which you can then later publish on your profile. Data about trip legs will be aggregated across vehicles, so it will be possible to estimate average trip times between major cities for example. Pretty, cool eh?

The other variable at my disposal is the number of vehicles being monitored, which is why this site will be invitation only for a while as I control the expansion and corresponding load on Tesla's servers.

Well, that is my update for the moment. Thanks again for the continued interest.
 
Here's the data tripography has collected on my driving habits: tripography.com/wraithnot

My daily commute is 51 miles- it's really interesting to see how much mileage errands and other side trips add. I've already had two 100+ mile days and haven't done any actual road trips yet (I'm planning a road trip to Vegas and another to San Diego in July). Given my driving habits, it's definitely good that I didn't buy the 40 kWh version that I originally planned to get.
 
While a very cool idea - there is a huge problem with the concept. Each time you connect to the car via iPhone app or REST API, it "wakes up" the entire car. The 12V starts draining, the MS battery kicks on to start charging up the 12V battery, then the heating/coolant system kicks on the keep the MS battery temps stable. Result: huge vampire loss. Thus repeated usage is incredibly bad for battery (more cycles over time). This was told to me directly by a lead Tesla service tech. Biggest contributor to vampire loss and unnecessary cycles through draining of the battery->constantly checking the phone app and waking up the car by accessing it from the REST API.
 
While a very cool idea - there is a huge problem with the concept. Each time you connect to the car via iPhone app or REST API, it "wakes up" the entire car. The 12V starts draining, the MS battery kicks on to start charging up the 12V battery, then the heating/coolant system kicks on the keep the MS battery temps stable. Result: huge vampire loss. Thus repeated usage is incredibly bad for battery (more cycles over time). This was told to me directly by a lead Tesla service tech. Biggest contributor to vampire loss and unnecessary cycles through draining of the battery->constantly checking the phone app and waking up the car by accessing it from the REST API.
Wouldn't it be nice if we had access to that car logs without having to use the 3G and a Tesla server.
 
While a very cool idea - there is a huge problem with the concept. Each time you connect to the car via iPhone app or REST API, it "wakes up" the entire car. The 12V starts draining, the MS battery kicks on to start charging up the 12V battery, then the heating/coolant system kicks on the keep the MS battery temps stable. Result: huge vampire loss. Thus repeated usage is incredibly bad for battery (more cycles over time). This was told to me directly by a lead Tesla service tech. Biggest contributor to vampire loss and unnecessary cycles through draining of the battery->constantly checking the phone app and waking up the car by accessing it from the REST API.

Yes some vampire losses are possible, but I would not say they are "huge". This is why I've designed the site's features to avoid frequently querying the car. For example, to measure daily driving distances requires querying the car only once per day. Currently between 12-1am (in the car's timezone). Other features like the road trip feature are designed for when you are driving your car on a road trip, the car is already "awake", so the overhead is negligible.

I suspect the tech has overstated the issue. If the Tesla mobile app is having such a huge impact on the car's energy load, then they have a serious design flaw in their system architecture. I personally have not observed the traction battery engaging to charge the 12V battery when using the mobile app. Possibly this was more of an issue with the bad batch of 12V batteries?

Wouldn't it be nice if we had access to that car logs without having to use the 3G and a Tesla server.

Yes it would. Ideally one could install an "app" in the car to gather this data and then upload it somewhere as needed. That is the design I would prefer.
 
While a very cool idea - there is a huge problem with the concept. Each time you connect to the car via iPhone app or REST API, it "wakes up" the entire car. The 12V starts draining, the MS battery kicks on to start charging up the 12V battery, then the heating/coolant system kicks on the keep the MS battery temps stable. Result: huge vampire loss. Thus repeated usage is incredibly bad for battery (more cycles over time). This was told to me directly by a lead Tesla service tech. Biggest contributor to vampire loss and unnecessary cycles through draining of the battery->constantly checking the phone app and waking up the car by accessing it from the REST API.

I just don't think this is true. I have logged data from my car for months and I don't see any more vampire loss than I did before I started doing the logging. Accessing the API definitely does not turn on the heating or cooling.

Here is my data from 12 hours of continuous polling every 120 seconds on the streaming API. I see at most 1% loss in SOC loss between 11:45 - 5:30 when the car was sitting in the parking lot at work.

Screen Shot 2013-06-21 at 7.52.26 PM.png
 
Last edited:
I'm back home after a nice relaxing vacation in Hawaii. :)

While I was gone, tripography has amassed 70+ invite requests, so I have quite a backlog to work through over the next couple of weeks. I'm hoping to hit 100 vehicles before TESLIVE, so there are probably only 15 or so slots still available. So please request an invite if you are interested.

While I was away a few vehicles had occasional or recurring errors attempting to obtain data from the vehicle. So if your vehicle is missing data, that is most likely the cause. I still need to investigate the causes further, but Tesla's servers seem to get overwhelmed at certain times of the day. I may have to adjust my reading schedule and error handling accordingly to accommodate.

I'll be doing a few minor site updates over the next couple of days and then the next batch of invites should start going out shortly thereafter.

Thanks for your patience.