Last weekend (as I write these words), I even added a third mesh hub to the mix, for my wife’s office downstairs, in addition to the router in the downstairs furnace room (the networking nexus) and mesh hubs in the upstairs living room and master bedroom. Alas, as I’d long dread-suspected, Google’s dropping OnHub support at the end of this year; while an existing OnHub-based network will continue to function, no further configuration of it will be possible, including replacement of failing units in the mesh (a not-exactly-easy process even now…and since that video was shot, the original Google Wifi app has been deprecated in favor of the Google Home successor, engendering further complications…and two OnHubs have died on me so far…).
In that November 2017 piece, I mentioned that I’d also acquired a three-unit Google Wifi set (no, I don’t know why the company’s brand name is spelled that way, either), which I’d then decided to return for full refund (on sale for $244.99 plus tax, versus a $299.99 MSRP, at the time), among other reasons because its 802.11ac capabilities were “only” AC1200 2×2:2 MU-MIMO, versus the AC1900 3×3:3 (albeit no MU-MIMO) facilities of OnHub devices.
Well, in mid-2020, after hearing initial rumor rumbles of OnHub’s looming demise, I reversed course and picked up another three-device Google Wifi set, this time refurbished from Woot for $174.99 plus tax. Turns out I still won’t be migrating to them once my OnHub mesh networking romance ends, however; Google’s successor Nest Wifi system is AC2200 4×4:4 MU-MIMO (for the router, at least; Nest Wifi hubs are Google Wifi-reminiscent in their specs and also drop the wired backhaul interface option, which is why I’d instead assemble an all-router-based mesh):
And I’ve also firmware-hacked a bunch of T-Mobile TM-AC1900 routers to transform them into mesh-capable ASUS RT-AC68U units, if I decide to drop the Google-centric ecosystem approach:
That said, however, I still have a compelling use for at least one of the Google Wifi units…as a teardown victim, of course. To date, Google’s actually made three different versions of the Google Wifi device; the second-generation model AC-1304 (FCC ID A4RAC-1304) is absent the Zigbee facilities embedded (but, as with its OnHub precursor, never robustly supported) in the original model NLS-1304-25 (FCC ID A4RNLS-1304-25). And more recently, the company quietly released a lower-priced third-generation design, whose only notable evolution (at least on the outside) is the migration from a USB-C connector-based to a barrel connector-based power supply. Two of the three units in my refurbished set were second-generation AC-1304 models, but the third was a first-generation NLS-1304-25, which I’ll be dissecting today. I may also do a second-generation model teardown in the future, although as we’ll soon see, FCC documentation will likely suffice to discern the differences (albeit not necessarily their causes).
The three-unit set showed up in a Google logo-branded but otherwise plain cardboard box:
The model NLS-1304-25 device was in the center, with AC-1304s straddling it on either side—NLS-1304-25 to the left, AC-1304 to the right:
Same model ordering, this time showing the units’ undersides from two different perspectives:
By the way, before continuing, I should show you what else is in the box. Since (I’m assuming) these were refurbs, they included only one single-sided piece of documentation, with amusing instructions (if initial configuration fails; step 1: factory reset and try again, step 2: email us!):
And underneath the three units are accompanying “goodie” boxes, one per:
Each contained a power adapter and solitary Ethernet cable (OnHubs had included two):
Let’s now focus on the star of the show, the NLS-1304-25, as-usual accompanied by a 0.75″ (19.1 mm) diameter U.S. penny for size comparison purposes (the Google Wifi device is 4.1 in/106.1 mm in diameter, 2.7 in/68.7 mm in height, and weighs 12 oz/340 g):
Here’s an underside closeup, notating (among other things) the locations of the wired WAN, LAN and power inputs:
That solitary screw you see is the only meaningful barrier to getting inside. Once removed, insert a flat-head screwdriver with tab-proximity discernment, and twist, and you’re inside:
One of the first things you’ll likely notice is that the LAN, WAN and power connectors are located on a separate daughter card, although the Ethernet switch is on the main board. My hypothesis is that this approach conceptually allowed for Google to optionally support LAN-only wired connectivity for a mesh hub built on the same base platform, much as Nest Wifi does. Regardless, my initial attempts to separate it from the main board were thwarted by close-proximity vertical “knobs” in the aluminum chassis that precluded sufficient horizontal PCB movement (along with, it turns out, other impediments that will soon be apparent):
So, I turned my attention to first extracting the entire two-PCB “sandwich,” beginning by detaching the five antenna connectors, along with a separate two-wire connector, and removing six additional screws (one of which was intentionally-or-not different than the other six, along with the prior two):
We have lift-off:
Here’s our first glimpse at the underside of the main board; match up ICs with the thermal tape seen in the previous photo (which transfers heat to the aluminum chassis acting as a sink) to figure out which chips run particularly hot:
Flip it over, and the two-PCB “sandwich” reappears, unobstructed by any chassis distractions:
But the daughter card still won’t detach. Waaa? Ahhh, it’s still attached by a couple of plastic pins:
A sharp pair of scissors snipped away those remaining impediments:
Let’s take a closer gander at the comparatively unmemorable daughter board first:
With it out of the way, the main board gets even more interesting than it was before:
At the bottom, to the left of the daughter card connector, is a Texas Instruments LP55231 nine-channel RGB/white LED driver. Above and to the right of it is the aforementioned wired Ethernet switch, a Qualcomm QCA8075 five-port Ethernet PHY (WikiDevi’s notes mention that some units substituted a two-port QCA8072 instead). Over on the fire right edge is a Winbond W25Q64FVZPIG 64 Mbit SPI serial flash memory. And then there’s that mysterious Faraday cage up top… Once it’s removed:
As keen-eyed readers have already guessed from the close-proximity antenna connectors around it, there’s RF stuff inside: specifically, two Skyworks SKY85717 front-end modules, one for each 5 GHz Wi-Fi antenna. Before turning the PCB over, by the way, take a gander at the roughly rectangular, nearly closed, copper-and-solder chain structure that extends out of the Faraday cage and around the PCB, roughly encircling digital circuitry on the other side. I’m guessing it’s for RF shielding, but I welcome feedback from those more “in the know.”
And with that, we turn the PCB back over:
Smack dab in the middle is the primary “brains” of the system, a Qualcomm IPQ4019 single-chip Wave-2 802.11ac SoC. Below it is another flash memory, this a Samsung KLM4G1FEPD-B031 4 GByte eMMC module. At the very bottom is the system LED. In the lower left corner is a Nanya NT5CC256M16DP-DI 4 Gbit DDR3-1600 SDRAM. In the lower right corner are two curious chips: a STMicroelectronics STM32F072CB Arm-based SoC and an Infineon SLB9615 Trusted Platform Module (TPM), also found in the OnHub and present for unknown-to-me purposes. And last but not least…in the upper right and left corners, two more Faraday cages!
Unsurprisingly, again, they contain RF circuitry. The larger one in the upper right is focused on 2.4 GHz Wi-Fi and Bluetooth LE (the latter used for initial communication with a mobile device and app-controlled configuration); specifically, CSR’s (now Qualcomm’s) CSR1021 BLE SoC and two Skyworks SKY85309-11 2.4 GHz WLAN front-end modules. The other is the more intriguing combo: a Silicon Labs EM3581 Zigbee mesh networking SoC and a Skyworks SKY66109-11 2.4 GHz Zigbee front-end module. Why intriguing (aside from being there at all)? Hold that thought.
Are we done? Heck no, we haven’t found the antenna yet! Follow the earlier-seen wires to their sources and we’ll find them, I suspect. The first step is to remove four more particularly stubborn screws from the aluminum chassis:
Release three plastic tabs, and the two halves cleanly separate:
Hey, where’d that earlier-glimpsed red-and-black two-wire harness go? Whenever I see one, I automatically suspect it goes to either a speaker or a switch. And since there’s no speaker here:
Onward; two of the antennae are already peeking out:
Four more screws to go, and…voila:
Let’s turn it over for a clearer look at the antenna array:
In correlating the wires feeding the antenna to their sources on the PCBs, I’m going to hazard a guess than the yellow and blue ones correspond to 2.4 GHz Wi-Fi antennae:
With the green and black ones handling 5 GHz Wi-Fi duties (note the 90° rotation orientations of one versus the other, presumably for maximum vertical-and-horizontal coverage):
This last one, fed by the light grey wire, is the baffler:
For one thing, this antenna looks totally different than the others, both structurally and by virtue of the fact that all the “metal” is pointing inward, versus outward. Its PCB connector proximity leads me to suspect that it’s there for Zigbee, and conversely that the PCB-resident copper-and-solder chain I mentioned earlier is the Bluetooth LE antenna. But…
Those of you who’ve already peeked at the FCC certification documentation for the AC-1304 have probably already noticed what I’m about to point out. The two designs are seemingly identical save for the absence of the Zigbee-intended Silicon Labs EM3581 mesh networking SoC and Skyworks SKY66109-11 2.4 GHz front-end module on the second-generation model. The ICs’ PCB pads are still there, they’re just not populated. But the atypical antenna and its light grey wire harness remain in the second-generation design. So, either that particular antenna does double-duty for Zigbee and Bluetooth LE in the first-generation model, or Google just didn’t bother removing it from the bill of materials in the cost-reduced product variant.
I’m betting on the latter. How about you? Let me know in the comments.
—Brian Dipert is Editor-in-Chief of the Edge AI and Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company’s online newsletter.