WiFi Performance

On most tablets, WiFi performance is perhaps one of the most crucial parts of the experience as WiFi is often the primary method of connectivity. Without working WiFi, a tablet is basically useless as the only alternative is either cellular (which is quite rare on most tablets) or Ethernet over USB-OTG, which destroys most of the value of a mobile device.

In the case of the Nexus 9, we see that HTC has fitted this device with a BCM4354 WiFi module to enable two spatial stream 802.11ac. Interestingly, there is some evidence to suggest that HTC has also adopted Cypress Semiconductor’s CapSense controller to enable antenna tuning for the WiFi antennas. However, it’s probable that this solution is only for HTC devices without a Qualcomm Gobi modem as we’ve seen the use of the QFE15xx antenna tuner in previous HTC products. In order to test how the Nexus 9’s WiFi solution performs, we turn to iperf on Android to test throughput across the network, and utilize Asus’ RT-AC68U router to ensure that the device under test will be able to reach maximum performance.

WiFi Performance - UDP

The Nexus 9's WiFi solution performs about as well as one might expect from a BCM4354 solution. For the most part I haven't noticed any reception issues, even when touching/detuning the WiFi antennas.

GNSS

While most of the GNSS solutions that we’ve looked at this year use Qualcomm’s GPSOne/IZat due to the presence of a Qualcomm Gobi Modem, the same isn’t true for the Nexus 9. Instead, Broadcom’s BCM4752 is used here. While this shouldn’t have a massive impact on the speed with which first lock is acquired, in practice Qualcomm’s solution is noticeably faster here as the modem can often provide data to make for a hot fix. At any rate, the Nexus 9 does perform acceptably in this regard. I don’t see any major issues with location performance, although it does seem that the GPS tends to report lower accuracy levels than the Qualcomm solutions that I'm used to. Other than this, the GNSS solution is quite usable.

Misc

While we don't have a proper audio quality test yet, it's clear that the audio codec used is the same Realtek RT5677 codec that we saw in the SHIELD Tablet. Outside of the code, we also see an RT5506 2.55V amp on the 3.5mm jack, along with two NXP TFA9895 amps on the speakers, which are quite good due to their front-facing placement. In practice I don't really see much issue with loudness or quality here, as the speakers can get even louder than the M8 in some situations. We also see a Broadcom BCM2079x NFC chip, which means HCE is fully supported out of the box. Interestingly, the VCM controller is exposed to the OS and is said to be a Texas Instruments DRV201 chip.

 

Camera Final Words
Comments Locked

169 Comments

View All Comments

  • lucam - Thursday, February 5, 2015 - link

    Next time you will write the article for Anand.
  • tuxRoller - Thursday, February 5, 2015 - link

    Just tested on my N7 2013. Results were far higher than shown in the chart.
    SR:64.2->76.1
    SW:18.4->30.1
    RR:11.2->13.4
    RW:0.7->3.1
  • mpokwsths - Thursday, February 5, 2015 - link

    Well, your results are far far more improved than 10% Andrei says.
    3 devices by 2 different users, all showed vast improvements (10-500%).
    Only they refuse to acknowledge it.
    Who knows, it seems Anandtech guys are on Apple's payroll...
  • eiriklf - Thursday, February 5, 2015 - link

    Just wanted to note that on the NAND performance front, I believe the android devices which beat the nexus 9 in sequential speed use emmc 5.0 while the nexus uses a high quality emmc 4.5. I think this is because the tegra K1 SoC does not support emmc 5.0.
  • tviceman - Wednesday, February 4, 2015 - link

    Better late than never, although being this late is indeed a big letdown.

    Onto the hardware, looks like Denver is an interesting first custom SoC from Nvidia. Solid in some respects, lacking in others. I think it's a solid building block from which to work on and improve. I hope Nvidia continues the custom ARM core path and gets more design wins (if warranted) moving forward.
  • kepstin - Wednesday, February 4, 2015 - link

    The Denver chip design is pretty interesting, but it reminds me very strongly of another mobile-targeted chip that didn't do well in the marketplace; the Transmeta Crusoe.

    Both are VLIW designs with in-order execution, both rely on software code translation that runs on the CPU itself. Both even used a partitioned section of system ram as a translated ops cache.

    The most significant difference that I see between them is the addition of a native ARM decoder to the Denver CPU; the Crusoe didn't have a native X86 decoder and relied on the dynamic translation for all code that it executed.

    I had a Crusoe for a while in a Sony Vaio; it was used in some of the very small/lightweight ultraportable laptops by Japanese manufacturers for a while.
  • phoenix_rizzen - Wednesday, February 4, 2015 - link

    Didn't a large group of Transmeta devs get hired by Nvidia?
  • ABR - Thursday, February 5, 2015 - link

    Crusoe lost because Transmeta woke the sleeping giant Intel to the value of low-power, and then a group of 100 people couldn't keep up the resulting engineering race. The x86 world would be a pretty different place today if that hadn't occurred. But I'd say the jury is still out on the overall capability of the VLIW + morphing approach.
  • frenchy_2001 - Thursday, February 5, 2015 - link

    I would second that. A quick search returned a licensing agreement where nvidia licensed Transmeta's technology.
    This could be a good part of Denver.

    About in order execution, the biggest experiment was from intel: itanium.
  • kgh00007 - Wednesday, February 4, 2015 - link

    It's 3 months late, the nexus 9 was released on the 3rd of November!!

    No excuses, but it's just too late to help people make an informed decision!! Just like dog years, one year for a tablet is like 7 technology(dog) years!!

Log in

Don't have an account? Sign up now