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

map updates!

This site may earn commission on affiliate links.
Last time I checked, haven't yet received the update. The current nav map is confused when we turn onto the street near our house. It believes it takes 5 minutes to drive the first few feet on the block. So we'll be able to determine pretty quickly if they've fixed that problem with the new maps.

[Assuming we ever get the update...]
 
I got a maps update last night. This after exchanging emails with servicehelpna@ a couple weeks ago and them insisting that I had the latest maps and calling into question the reliability of report(er)s here in TMC of new map updates. They said that maps were always distributed along with firmware updates, which is known to be false. (My map update came without a firmware update for the record.)

Hope this helps the one or two places where I know the old maps were definitely broken (one was CA-99 in the central San Joaquin Valley where the maps didn't properly track a freeway realignment).

Here's a picture of the pop-up dialog, not sure if I've seen it posted here to TMC before but a bunch of people have asked what it looks like. Apologies for the picture quality. :p

IMG_8287.jpg


Aw heck, one more picture. This is the output from my Cacti installation at home, which showed a traffic "spike" last night of around 10Mbps for a little less than two hours. If the transfer were exactly two hours long, that'd be 2*3600*10/8/1024=8.8GB, so if you figure it was a little shorter and maybe with a slightly lower traffic volume, that'd be in the ballpark of the 5GB that was quoted upthread. The assumption of course was that this was the dominant traffic source at that time of the night, and that the traffic spike did indeed correspond to the map update. I don't have any more detailed statistics than that (maybe I need to re-set up NetFlow exports on my firewall or get the car onto its own SSID / VLAN).

Screen Shot 2016-02-21 at 4.23.16 PM.png
 
Last edited:
I got a maps update last night. This after exchanging emails with servicehelpna@ a couple weeks ago and them insisting that I had the latest maps and calling into question the reliability of report(er)s here in TMC of new map updates. They said that maps were always distributed along with firmware updates, which is known to be false. (My map update came without a firmware update for the record.)

Aw heck, one more picture. This is the output from my Cacti installation at home, which showed a traffic "spike" last night of around 10Mbps for a little less than two hours. If the transfer were exactly two hours long, that'd be 2*3600*10/8/1024=8.8GB, so if you figure it was a little shorter and maybe with a slightly lower traffic volume, that'd be in the ballpark of the 5GB that was quoted upthread. The assumption of course was that this was the dominant traffic source at that time of the night, and that the traffic spike did indeed correspond to the map update. I don't have any more detailed statistics than that (maybe I need to re-set up NetFlow exports on my firewall or get the car onto its own SSID / VLAN).

View attachment 112172

I am running netflow. I was trying to figure out why my garage was pushing more traffic than usual this evening. I found that there is a lot of action on port 22 from an amazon compute instance. For the life of me I don't know why they would be pushing a map update through an ssh port but I can't think of another reason why my car would receive so many GBs otherwise. This is much more than a patch and way more than I would expect for typical firmware/os updates.

Sadly I think I disrupted the download as I was mucking about with the AP :-(. Coming over port 22 makes me fear a relatively fragile, human oriented, maps update process. I really hope they are using rsync or some variant to resume downloads. I would hate to see the BW bill to update thousands of cars repeatedly.

Here it is in cacti to compare with yours (pretty far upstream from the car).

Capture.PNG


And from my netflow collector (this graph only monitors the car)

Capture.PNG


The amazon port 22 massive download is what drove that blue spike (the 60Mbps is an artifact of the flow graphing and not truly the download speed). A normal Tesla day looks more like the below.

Capture.PNG
 
I am running netflow. I was trying to figure out why my garage was pushing more traffic than usual this evening. I found that there is a lot of action on port 22 from an amazon compute instance. For the life of me I don't know why they would be pushing a map update through an ssh port but I can't think of another reason why my car would receive so many GBs otherwise. This is much more than a patch and way more than I would expect for typical firmware/os updates.

That's pretty interesting. So just to confirm, not through the VPN?

Sadly I think I disrupted the download as I was mucking about with the AP :-(. Coming over port 22 makes me fear a relatively fragile, human oriented, maps update process. I really hope they are using rsync or some variant to resume downloads. I would hate to see the BW bill to update thousands of cars repeatedly.

Here it is in cacti to compare with yours (pretty far upstream from the car).

View attachment 112218

And from my netflow collector (this graph only monitors the car)

View attachment 112219
Cool! What NetFlow collector are you using?

OK now this is kind of weird (or stupid or both). The Cacti graph I posted before was from the wired port of one of my wireless access points, and showed a more-or-less constant stream of about 10Mbps. Here's the WAN port from my firewall:

Screen Shot 2016-02-21 at 9.09.37 PM.png


The plateau on the left is the supposed maps download. Same timeframe but the reported throughput is roughly half of what the access point measured. I'm unable to account for this difference. (Same measurement intervals for both, as far as I know.) Unfortunately Cacti polling of my firewall's interfaces is inexplicably broken so I can't compare against say a Cacti graph of the firewall's WAN interface. Guess I have some other debugging to do. But anyway if you believe my firewall's version of events, it'd be roughly half of what you get from the access point's numbers. (The firewall is running pfSense based on FreeBSD, the access point is an old Apple Airport Extreme, at this point I'm inclined to believe the firewall but there's no real evidence in either direction.)
 
That's pretty interesting. So just to confirm, not through the VPN?


Cool! What NetFlow collector are you using?

OK now this is kind of weird (or stupid or both). The Cacti graph I posted before was from the wired port of one of my wireless access points, and showed a more-or-less constant stream of about 10Mbps. Here's the WAN port from my firewall:

View attachment 112221

The plateau on the left is the supposed maps download. Same timeframe but the reported throughput is roughly half of what the access point measured. I'm unable to account for this difference. (Same measurement intervals for both, as far as I know.) Unfortunately Cacti polling of my firewall's interfaces is inexplicably broken so I can't compare against say a Cacti graph of the firewall's WAN interface. Guess I have some other debugging to do. But anyway if you believe my firewall's version of events, it'd be roughly half of what you get from the access point's numbers. (The firewall is running pfSense based on FreeBSD, the access point is an old Apple Airport Extreme, at this point I'm inclined to believe the firewall but there's no real evidence in either direction.)



  • They appear to be using a pretty vanilla openvpn and I can see it as a pretty active set of sessions over UDP. This is definitely port 22 for a big download to the car. It could be "a" VPN but not what I typically experience as "the" VPN for Tesla.
  • I use nfsen as the collector.

There are lies, damn lies, and interface statistics :). In your case the first lie is likely that they are both reporting at an equivalent packet depth. Some systems will include mac headers and some won't. There are probably a number of other differences but I don't poll apple or pfsense so I don't have any particular experience. If I really wanted to know I would grab iperf and run some tests. Don't get me started on 32bit vs. 64 bit counters.
 
Once again I whine ...

Tesla needs to add a polling icon to check for updates (either firmware or maps).

Very great idea, I have my Oppo DVR set up to check the mothership once per week on a Monday...
it would be nice to have such a Tesla App that also shows what it has checked and what your current version is... a simple
checkmarks shows you are up to date and if you click on MORE INFO it can show you the version and last date of update.
Could be added to the T screen on the 17" display, it shows the firmware version you are running there.
 
Here is what I saw on an older log where they are indeed using rsync to fetch the map updates:

{"url":"rsync://filesync.vn.teslamotors.com/mapdata/NA-Q413-5942e0a4/","target_version":"NA-Q413-5942e0a4","size":3627361703,"max_wifi_kbps":10000,"max_cell_kbps":0}

As you can see this also explains the 10 meg bandwidth.
 
Here is what I saw on an older log where they are indeed using rsync to fetch the map updates:

{"url":"rsync://filesync.vn.teslamotors.com/mapdata/NA-Q413-5942e0a4/","target_version":"NA-Q413-5942e0a4","size":3627361703,"max_wifi_kbps":10000,"max_cell_kbps":0}

As you can see this also explains the 10 meg bandwidth.

Hey, that is really cool. Thanks Ingineer.

I don't see the partial command in there :-/. If it is a bunch of small files then it is probably okay without partial. It will be interesting to see if I get a resume or a brand new download. It will be blindingly obvious if the download is completely new. Avoiding ATT bills is only one half of the BW cost equation :).
 
There are lies, damn lies, and interface statistics :). In your case the first lie is likely that they are both reporting at an equivalent packet depth. Some systems will include mac headers and some won't. There are probably a number of other differences but I don't poll apple or pfsense so I don't have any particular experience. If I really wanted to know I would grab iperf and run some tests. Don't get me started on 32bit vs. 64 bit counters.

Haha, I didn't know the part about MAC-layer headers.

iperf has some other weirdness in that it only knows how to compute bandwidth and throughput at the application layer, not taking into account TCP, UDP, or IP header overheads. (I "maintain" iperf3 as part of my day job, for small values of "maintain", and people sometimes forget things like this when trying to correlate iperf3 data with interface counters.)

To get marginally back on topic: My turn-by-turn arrows are blue now after the update, but I thought they'd always been blue. One of those crazy things where you stare at a screen and just thinking about it causes you to question your recollection of what it was like before. :confused:
 
Low and behold! Surprise, surprise! I got a map update this afternoon....

I was parked for an hour and a half in a public lot with no access to wifi - only LTE (a 2 bar signal), went into my meeting and came out to the screen announcing "Navigation Map Updates" " Congratulations your navigation system is now using the latest maps".

Feel like I just won the lottery :smile:

Have not had a chance to test the navigation maps accuracy in my area yet.
 
Haha, I didn't know the part about MAC-layer headers.

iperf has some other weirdness in that it only knows how to compute bandwidth and throughput at the application layer, not taking into account TCP, UDP, or IP header overheads. (I "maintain" iperf3 as part of my day job, for small values of "maintain", and people sometimes forget things like this when trying to correlate iperf3 data with interface counters.)

To get marginally back on topic: My turn-by-turn arrows are blue now after the update, but I thought they'd always been blue. One of those crazy things where you stare at a screen and just thinking about it causes you to question your recollection of what it was like before. :confused:

I just use iperf to stress things so I can see what they look like under duress :).

Regarding the blue-arrows. You know, I would swear that all sorts of stuff keeps changing on the car (with or without updates). It makes life interesting but sometimes confusing. It definitely causes the occasional challenge when I want to demo a function and it works "differently."