WiFi

The Galaxy Nexus uses Broadcom’s BCM4330, which is starting to pick up steam and become just as ubiquitous as the BCM4329 it replaced. The Galaxy Nexus’ BCM4330 includes both 2.4 and 5 GHz WLAN connectivity, just like the SGS2 in fact. What’s particularly notable is that Android 4.0.x now includes the proper prioritization for each WiFi band, and also includes the ability to set preference for one band for the other. By default, when faced with the same SSID on both 2.4 and 5 GHz, the Galaxy Nexus correctly chooses the 5 GHz AP if the signal is favorable, then falls over to 2.4 GHz when its link quality on that band would be better. Other than this notable change, the remainder of the WiFi settings panes are unchanged. The WiFi sleep preferences and the main scan and connect page does get a minor facelift and change, however.

 

The Galaxy Nexus latched onto my 802.11n APs on both 2.4 and 5 GHz and used 20 MHz long guard interval rates at 65 Mbps the same as other BCM4330 based devices. Throughput is unsurprisingly very good on the Galaxy Nexus in our WiFi test, which consists of downloading a 100 MB PDF hosted locally over WiFi. Of course, since we can now control and choose which band the device uses, I tested on both 2.4 GHz and 5 GHz, both with a negotiated link rate of 65 Mbps.

WiFi Performance

WiFi range on the Galaxy Nexus is good as well, I can make it to the same place before hopping off my network as other devices. I have gotten a few emails and read reports about power-save mode incompatibility with some APs that causes it to drop off when on standby mode. Since we've seen BCM4330 work just fine on other devices, I have no doubt this is a software issue which will be fixed soon. 

Speakerphone

As usual I also measured speakerphone volume on both variants of the Galaxy Nexus using a sound datalogger. There is apparently a difference between the two models, possibly from different acoustical chambers in the vibration unit and antenna. Also there’s possibly still a difference as a result of the different voice coders in use, and the different dynamic range.

Speakerphone Volume - 3 Away

Either way, the two test differently, and subjectively my experience backs those measurements up. I found the GSM/UMTS Galaxy Nexus a bit too quiet while using Google Navigation, and the CDMA/LTE Galaxy Nexus on the quieter side but totally useable for Navigation.

GPS

Just like the SGS2, the Galaxy Nexus uses a SiRFStarIV GSD4t for GPS. Subjectively the Galaxy Nexus GPS doesn’t lock quite as fast as some of the other GNSS solutions that are integrated into the cellular basebands in phones, but it does get the job done pretty fast. I see a time to first fix of between 4-7 seconds depending on visible sky swath presented to the handset.

I did receive a few emails from readers with reports of some Galaxy Nexuses shipping with GPS issues or taking too long to lock. One of my friends with a CDMA/LTE Galaxy Nexus also reported that he couldn’t get a GPS lock at all for Google Navigation. I’m not entirely sure what the deal is here since I never was able to encounter this behavior, although manually downloading the A-GPS data (ephemeris) using a tool like GPS Status seems to in general helps mitigate those problems when they do happen. This just manually re-downloads the xtra.bin file from http://xtra1.gpsonextra.net/xtra.bin as configured in gps.conf. I have to admit that I didn’t encounter any GPS issues in my time with the Google Nexus (CDMA/LTE or GSM/UMTS version) so far.

Audio

We’re going to do a more in-depth audio analysis with the Galaxy Nexus when we have our testing suite more fleshed out, and possibly bring you Francois Simond’s thoughts once more. For now however, we have some RMAA runs I talked about a while ago in another review, and my own impressions with Galaxy Nexus sound after using the device for a while now as my primary music player with some Shure SE535s.

 

First off, the Galaxy Nexus out of the box is pretty decent subjectively. The Galaxy Nexus uses TI’s TWL6040 low power audio codec for its DAC and other audio responsibilities, alongside the vibrator actuator. We’ve seen some other TI audio codecs (like AIC3254 in the HTC Sensation) but this our first time seeing TWL6040. Almost immediately I noticed that there isn’t any constant high frequency whine present like I’ve heard on so many phones lately (Bionic, SGS2, others), and it’s hard to hear any noise when the DAC turns on and off after music stops playing. Even plugged into USB power, the device also doesn’t pick up any more noise or change at all. There’s also almost no CPU noise, though if you listen very carefully you can indeed hear some state changes, but it’s very minimal and very difficult to pick out.

Though the frequency response isn’t entirely flat as shown, the Galaxy Nexus doesn’t sound bad subjectively. Our testing here is just a RMAA run from line out on the devices to line in on an ASUS Xonar Xense sound card. In addition, testing is done at 44100/16 bit on the devices - Android will downsample anything more than this.

https://images.anandtech.com/reviews/gadgets/Motorola/RAZR/Three/fr.png
From 20 Hz to 20 kHz: +0.10, -0.62 (dB)

Noise on the Galaxy Nexus also isn’t bad, definitely better than the RAZR we tested earlier.

Noise Level
Noise Level: -96.2 (dB, A weight)

Dynamic range shows the difference in level between the maximum output and minimum output on the smartphone. This is limited by voltage swing and system noise. Galaxy Nexus again here looks pretty good, minus a few spikes.

Dynamic Range
Dynamic range: 96.0 (dB, A weight)

The two total harmonic distortion charts are next, which are the summation of integer multiples of the test frequency and expressed as a ratio of the input signal (in this case at 1 kHz). THD+Noise gives all frequencies except the input signal. The Galaxy Nexus is pretty good here, but still has some spikes at a few noteworthy integer multiples, plus some odd spikes at high frequencies.

THD + Noise
THD %: 0.0088

Intermodulation distortion is similar to total harmonic distortion, however it applies two input signals and then measures the signal at all frequencies except the two inputs. In this case, the two signals are on opposite sides of the spectrum. Galaxy Nexus ends up not looking too bad here although there are disconcerting spikes above 1 kHz that I can’t explain.

IMD
IMD + Noise %: 0.013

Finally stereo crosstalk is pretty flat on the Galaxy Nexus.

Stereo Crosstalk
Stereo Crosstalk: -87.4 dB

Again, this isn’t meant to be a totally comprehensive analysis of the Galaxy Nexus’ sound characteristics, just some educated impressions. Subjectively the Galaxy Nexus sounds nice and clean, and is absent of the annoyingly audible background noise and whine that’s present on some of the other noteworthy phones we’ve tried as of late. Francois (supercurio) has expressed a few times that the Galaxy Nexus has good audio potential, and that alone should tell you something.

Cellular Performance and Call Quality on Galaxy Nexus Battery Life Analysis
Comments Locked

185 Comments

View All Comments

  • CoryS - Thursday, January 19, 2012 - link

    Guys, this is a NEXUS it is a dev device. That primary reason I got it was because of this...better hardware will be right around the corner...but we won't see another Nexus..especially on Verizon for some time.

    It is refreshing to have a community to fix issues OEMS ignore (yes even Apple) for a change. This is my first unlocked device, and i can't see myself ever going back to anything else.
  • medi01 - Friday, January 20, 2012 - link

    Wake up, Smartphone market (worldwide):
    1. Samsung 24%
    2. Apple 18%

    Android vs Apple = 3 vs 1 and gap is raising.

    Most people turn to apple due to FUD, like this article. Google "steppit out of the shade of its competitor" having three times Apple's market share and much more usable interface (try to quickly access settings like wlan/bluetooth/gps on ios)
  • steven75 - Friday, February 10, 2012 - link

    LOL dont you get it? You don't *need* to fiddle with those settings on iOS necause the battery life is so dramatically better.

    Also, funny reading this comment after Apple's Q4 report where they dominated.
  • Omid.M - Wednesday, January 18, 2012 - link

    I hope Samsung puts out this phone based on GN aesthetics but Exynos 5250 (plus MDM9xxx multi-mode/LTE modem) and blows away the competition.

    @moids
  • Chumster - Wednesday, January 18, 2012 - link

    Could someone clarify on what GPU/CPU he was talking about coming in Q2 devices? Cray? Crate? It was hard to pick up on my headphones.
  • mmp121 - Wednesday, January 18, 2012 - link

    Krait

    Read below:

    http://www.anandtech.com/show/4170/qualcomms-annou...

    Enjoy!
  • Conficio - Wednesday, January 18, 2012 - link

    Really, Google can't survive once Walled Garden platforms like iOS gain traction.

    While it is nice to control the OS (Chrome OS) on PC like devices and nice to stick it to Microsoft, it is essential in the world of smart phones. Google clearly saw that Apple did the unthinkable, wrestle control of the phone's apps away from the networks. That is an existential thread for Google. If there is a billion PC users world wide, there is a multitude of smart phone users, sooner or later.

    If a hardware manufacturer and OS provider like Apple (or Microsoft) controls the apps that can be provided to the phone and features, move from browser to apps on phones, then this is the end of (a profitable) google sooner or later.

    From anther point of view, Google is a huge data center that provides you with data services on their computing power (and you pay for it with advertisement somehow). Apple is a hardware manufacturer that sees it necessary to control the software to deliver a good user experience. Sure, two different approaches to a smart phone OS.
  • hackbod - Tuesday, January 24, 2012 - link

    "Google clearly saw that Apple did the unthinkable, wrestle control of the phone's apps away from the networks."

    There is this weird thing I see expressed a lot, as if Android is a reaction to the iPhone.

    It is not.

    In this particular case, it is obvious: Android's SDK was made available a few months after the original iPhone was on sale, well before there was *any* native SDK for the iPhone. At that time Apple's very clear official policy was that web-based apps was the One True Way to create applications for their phone. There was no concept of an App Store, no phone apps except what Apple shipped built in to the iPhone, nothing wrestled away from the networks in that department.

    If Android was a reaction to anything, it was to the current situation on desktop PCs, with one company controlling that platform, and being able to quite strongly dictate and control its ecosystem and thus large parts of the computer industry.

    One of the goals of Android was to try to keep that from happening in the upcoming mobile industry, by creating an open platform so that everybody in the industry can compete as equally as possible.

    (And an aside -- this also makes it funny to see the recent stuff going around about Google "losing control" of Android. Android was very much set up so that no one company, not even Google, could have anything like the control that Microsoft does over Windows. This should be pretty obvious to anyone who wants to actually write thoughtful articles on the topic and not just link bait.)
  • bjacobson - Wednesday, January 18, 2012 - link

    Can you talk more about this? From Diane Hackborne's post here (https://plus.google.com/u/0/105051985738280261832/... it sounds like the "limitation" is memory bandwidth in that hardwares that are "laggy" are laggy because they can't render to the entire screen 2 and 3x per frame for all the overlays. Which wouldn't seem like so much of a Tegra2 limitation in my opinion considering it has the power to play games like Quake 3 at 1600x1200 @ 60fps (I think...right?). What are your thoughts?
  • hackbod - Tuesday, January 24, 2012 - link

    I don't know about the performance of Tegra 2 playing Quake, but you need to be very careful when comparing the traditional 3d workload that GPUs are highly optimized to support (as exemplified by Quake) vs. the performance rendering 2d graphics.

    Traditional 3d games tend to rely, for example, on triangle rendering as much if not more than raw pixel fill rate, and GPUs are designed to be able to do that fast. When drawing 2d scenes, there are very few triangles but those triangles cover very large parts of the screen and are rendered as overlapping layers.

    On all of the hardware I have seen, for 2d rendering raw memory bandwidth (determining the number of times every pixel can be touched per frame) is the #1 impact on performance.

    Look back at that post -- for a typical scroll of all apps in launcher, without using overlay tricks (which aren't available on Tegra when the screen is rotated), you are looking at touching every pixels about 4 times to render all the layers and composite them to the screen. This is just not a typical 3D game workload.

Log in

Don't have an account? Sign up now