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

My visit to the beta in Florida today (small new piece of info)

This site may earn commission on affiliate links.
Went to the Florida store today. It was the same Beta as was in Detroit. The salesperson told me that it got "used and abused" in Detroit, and they had to really clean it up. I didn't really learn much new while I was there (thanks to this forum). A friend of mine came along and managed to break the web browser, by going to a page with a javascript pop-up that required a text entry. There seemed to be no way to gain focus into the text field, and he couldn't dismiss it. From that point on, all of the screens (including navigation, climate control, etc.) had the javascript pop-up window. So there's a bug there.

For the other computer geeks out there, I visited a web page for which I have control, so that I could get some info on what sort of browser they are actually using. Here is the data from the logfile:

166.147.112.181 - - [29/Jan/2012:12:17:49 -0500] "GET /ronnie HTTP/1.1" 404 283 "-" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Chrome/7.0.517.44 Safari/534.7"

Here's what I can tell from that:

- The 3G is through Cingular (AT&T)
- They are using a very old version of the Chrome web browser
- The web browser is running on Linux, through X-Windows
- The CPU is an i686

I don't think I've seen this info posted before.

I do think I've seen people mention that the map is "laggy". It was incredibly laggy; enough that I find it unusable. I'm sure that will be fixed for production. It's still around here for a few more days, if anyone wants me to try anything else.
 
In a car like the S I feel like the browser should be sandboxed away from the other bits in the car. Seems like its ALL running in a shared environment?

Well, the same operating system. But the javascript bug is likely just a bug from the really old version of Chrome. I imagine that the pop-up window is just sitting above the other stuff, which is running on native X-Windows, outside the browser. If this is true, if the browser crashes, it should not affect the other functions of the vehicle.
 
I'd hate to get rickrolled with one of those that spawn popups and bounce around and not be able to control my sunroof, climate etc because of it. It's something that they're hopefully considering. Luckily, the S is designed for OTA software updates, so if it becomes a problem, they should be able to quickly rectify it.

Thanks for geeking out on the browser :smile:
 
I'd hate to get rickrolled with one of those that spawn popups and bounce around and not be able to control my sunroof, climate etc because of it. It's something that they're hopefully considering. Luckily, the S is designed for OTA software updates, so if it becomes a problem, they should be able to quickly rectify it.

Thanks for geeking out on the browser :smile:

I was proud of myself for thinking about it on the spot... :)

Anyway, I'm sure they'll upgrade the browser. chrome is currently up to major version 16, while the car is at version 7. The dev release is at 18. Version 7 is from 10/21/2010.
 
That doesn't seem right--

The processors in the Model S are supposed to be NVIDIA Tegras, which are ARM Cortex A9s, not X86es.

I'm certain I read somewhere that Linux was the host OS, and WebKit was used for page rendering (this would be true of Chrome).

- If the i686 is true, then we haven't seen the "final" processor chip in the dash. I doubt this, because the NVIDIA people were in the booth at CES showing off the Model S's touchscreen as having Tegra processors.
- If the i686 is false, then you may have the wrong log entry from your web server?
- Or, the browser is lying. Browsers often lie about who they are.

When I played with the map it seemed to update slowly, but it was clearly pulling satellite image tiles over the 3G. I would run it in map mode (I have no desire to see the satellite view), and I expect that we'll be storing local area maps onboard, no 3G connection needed.

/Mitch.
 
That doesn't seem right--

The processors in the Model S are supposed to be NVIDIA Tegras, which are ARM Cortex A9s, not X86es.

I'm certain I read somewhere that Linux was the host OS, and WebKit was used for page rendering (this would be true of Chrome).

- If the i686 is true, then we haven't seen the "final" processor chip in the dash. I doubt this, because the NVIDIA people were in the booth at CES showing off the Model S's touchscreen as having Tegra processors.
- If the i686 is false, then you may have the wrong log entry from your web server?
- Or, the browser is lying. Browsers often lie about who they are.

Yes, the browser *could* be lying. I've not looked at the Chrome source. Maybe I will. I would bet that the browser info query string is generated by the Makefile or config file, which wouldn't have to know about the processor if it's not using any processor-specific "asm" code.

I am sure that I have the correct line in the logfile. That's why I did the "/ronnie" (my name). There isn't really a webpage with that name, so I did it so that I could search the logfile quickly.
 
Yes, the browser *could* be lying. I've not looked at the Chrome source. Maybe I will. I would bet that the browser info query string is generated by the Makefile or config file, which wouldn't have to know about the processor if it's not using any processor-specific "asm" code.
The config file, while writing the browser query string, ought to know what CPU architecture it's being compiled for. But that doesn't mean that the Makefile is written right. (I've done a lot of config / Makefile work, and most people write shoddy Makefiles.) It also may be deliberately lying because some websites, for no good reason, mistreat browsers whose response strings are "too weird" for them.

It is totally possible that the beta touchscreen is running on an i686, but it would indicate that the electronics development is behind what we expect it to be.
 
Well, I did a quick browse of the source, and it seems like at least the default for the user_agent query string is actually generated dynamically by using the uname() system call. But I believe there may be a hack to change it once it's installed. If they haven't hacked it, the OS definitely thinks it is a 686.

Code:
  struct utsname unixinfo;
  uname(&unixinfo);

  std::string cputype;
  // special case for biarch systems
  if (strcmp(unixinfo.machine, "x86_64") == 0 &&
      sizeof(void*) == sizeof(int32)) {  // NOLINT
    cputype.assign("i686 (x86_64)");
  } else {
    cputype.assign(unixinfo.machine);
  }

(From user_agent.cc)
 
That's just weird.

If I was on the hardware team, I wouldn't have designed in an X86. They're just poor choices for this sort of embedded platform. It'd actually be MORE work to use one in my opinion.

I seriously doubt they just bolted a PC in the dash, with the number of things that the touch screen needs to communicate with, they'd have to fashion custom interface hardware. If they build custom hardware, they'll choose something reasonable for the CPU.


I think that they just hacked the code to provide that string. A few reasons come to mind:

- Certain web sites / servers might behave differently if presented the "truth". A website might think it's a tablet or some other portable device.
- Maybe they're trying to be stealthy and not reveal any specifics about the hardware platform that could be used by competitors or fan web sites.
- Some internal test servers may be rigged to know things -- they almost certainly did early development of the UI on regular PCs (before the hardware was real), so they might have just hacked things to make the real car look like their test rig.


I dunno, I personally doubt that any of the betas have X86es as their touchscreen CPUs.

/Mitch.
 
That's just weird.

If I was on the hardware team, I wouldn't have designed in an X86. They're just poor choices for this sort of embedded platform. It'd actually be MORE work to use one in my opinion.

I seriously doubt they just bolted a PC in the dash, with the number of things that the touch screen needs to communicate with, they'd have to fashion custom interface hardware. If they build custom hardware, they'll choose something reasonable for the CPU.


I think that they just hacked the code to provide that string. A few reasons come to mind:

- Certain web sites / servers might behave differently if presented the "truth". A website might think it's a tablet or some other portable device.
- Maybe they're trying to be stealthy and not reveal any specifics about the hardware platform that could be used by competitors or fan web sites.
- Some internal test servers may be rigged to know things -- they almost certainly did early development of the UI on regular PCs (before the hardware was real), so they might have just hacked things to make the real car look like their test rig.


I dunno, I personally doubt that any of the betas have X86es as their touchscreen CPUs.

/Mitch.

Yes. The more I think about it, you're probably right. It's likely that in testing they saw that web pages were discriminating against it, and they wanted the full browser experience. Maybe they went to the nearest full browser on a Linux box, copied the user agent string and pasted it in, to override. If that's the case, none of my observations (other than Cingular) are reliable.
 
I went to the Florida showroom on January 2 and put down a deposit. The one thing I heard that bothered me was that Tesla was going to cripple the nav system while the car was underway. The European cars I drive don't do this; is this an American legal thing, I wonder. I hate this "We know better than you Big-Daddy crap" they pull.