|At a glance|
|Product||Google NLS-1304-25 (Wifi) [Website]|
|Summary||Mesh Wi-Fi system with AC1200 class mesh points.|
|Pros||• Least expensive mesh Wi-Fi product
• Mesh networks can include AC1900 class OnHubs
• Built-in ZigBee radio
• App shows internet connection, client connection and mesh connection performance
|Cons||• Does not support access point mode for mesh configurations
• ZigBee radio supports only Philips Hue bulbs
Updated 1/12/17 – Assorted updates
Google caused a stir in the emerging mesh Wi-Fi universe when it announced in October it too was getting into the game with Google Wifi. Google’s first attempt — OnHub — didn’t put much of a dent in the incumbent consumer Wi-Fi makers’ market share. But since GWifi’s key competition, eero and Luma, are much smaller fish, GWifi wouldn’t have to do much to create some serious potholes in their road to long-term viability.
Google Wifi (yes, that’s how Google spells it) takes an approach similar to Luma and eero in form and features. All three aim at the consumer who wants easy setup, as in plug-it-in-and-it-works. All come in small off-white plastic packages (Google refers to theirs as "Wifi points"), as shown in the group photo below, designed for high WAF.
Luma, eero, Google Wifi – front
All three also come with two Gigabit Ethernet ports and have AC1200 class radios. But GWifi doesn’t have the (currently) non-functional USB 2.0 port that eero and Luma sport. Instead, it has a USB C connector that right now serves only to bring power in.
Luma, eero, Google Wifi – rear
Google has priced GWifi aggressively at $129 for one and $299 for a three-pack. Luma apparently noticed and lowered its three-pack to $299 from $399, but kept its single-unit price at $149. eero has chosen to keep its premium prices of $499 for three and $199 for one, although you can buy a two-pack for $349. Although GWiFi is shipping, Google sold out its initial production run. So you’ll have to join a waitlist until it comes back into stock, which should be in the next week or two, according to Google.
Shortage has been resolved. Order away!
GWifi’s FCC documents are under wraps for now. So when testing was done, I opened one up for photos and component identification. The photo below shows the view after removing the bottom cover. It’s a solid design, with the main board screwed onto a cast metal shell that serves as a heatsink and imparts a feeling of substance. The two Gigabit Ethernet and USB C connectors are on a small board that connects to the main board via what looks like a PCI-e connector.
Google Wifi inside
Most components are on the other side of the board, shown below with RF can tops removed. The GWifi’s heart is a Qualcomm IPQ4019, basically the same device as the IPQ4018 that powers Luma. It’s a simultaneous dual-band AC1200 radio that also supports MU-MIMO, which neither Luma nor GWifi have chosen to support in their products.
Google Wifi board
The upper left RF can holds a surprise – a Silicon Labs EM3581 ZigBee / Thread SoC and Skyworks ZigBee front end. This is the same combo found in the TP-Link and ASUS OnHubs, but it’s not mentioned in any Google Wifi documentation, per se. But OnHub has supported ZigBee-based Philips Hue bulbs since August and since GWifi also supports Philips Hue bulbs, Google Wifi’s ZigBee radio is also functional. The device with a Qualcomm logo in the right side RF can is most likely the Bluetooth radio, but I couldn’t find any reference to the part number marked on it.
The other surprise is the STM32F072 32 bit ARM Cortex-M0 microcontroller and Infineon STM9615 Trusted Platform Module. Neither of these were found in either OnHub.
Google reports that OnHub does have a Trusted Platform Module.
For comparison, here’s Luma’s board…
…and eero’s. It’s pretty obvious why eero needs to keep its price high compared to Luma and Wifi.
But eero continues to be the only three-pack mesh product with two 5 GHz radios.
eero’s second 5 GHz radio was a shared 2.4 / 5 GHz. This Reddit post describes that the 5 GHz components on the shared radio have been removed, along with the band-limiting filter on the separate 5 GHz radio. This makes eero the same as most other "three-pack" mesh Wi-Fi systems, with 2.4 and 5 GHz radios that are used for both backhaul and client connection. eero confirmed that the change was made "late spring, early summer" of 2016. Sources tell me that eero’s superior performance (to Luma and Amplifi at least) is due to higher transmit power.
The component summary below shows the key components of Wifi, Luma and eero.
|CPU||– Qualcomm IPQ4019 Wave2 2×2 a/b/g/n/ac SoC
– STM32F072 32 bit ARM Cortex-M0
– Infineon STM9615 Trusted Platform Module
|Qualcomm IPQ4018 2×2 a/b/g/n/ac SoC||Qualcomm dual-core IPQ8062 @ 1 GHz|
|Switch||QCA8075||QCA8075||Qualcomm Atheros QCA8337|
|RAM||512 MB||256 MB||512 MB|
|Flash||– 4 GB eMMC (IF5055?)
-4 MB Winbond 25Q64FV
|128 MB GigaDevice 5F1GQ4UCYIG
2 MB GigaDevice serial flash 25Q16CS1G
|4 GB / 8 MB|
|2.4 GHz Radio||– In IPQ4019
– Skyworks SKY8530 2.4 GHz front end (x2)
|– In IPQ4018
-Skyworks RFX8425 2.4 GHz RF front end (x2)
|– QCA9982 2×2 MU-MIMO 802.11abgnac radio
– RFMD RFFM4204 2.4 GHz Front End (x2)
|5 GHz radio||– In IPQ4019
– Skyworks SKY85717-11 5 GHz front end (x2)
|– In IPQ4018
– Skyworks SKY85716-11 5 GHz RF front end (x2)
|– QCA9982 2×2 MU-MIMO 802.11abgnac radio
– RFMD RFPA5522 5 GHz power amp (x4)
|Bluetooth||Qualcomm 3003-CL3D (CSR102x?)||CSR8510 Bluetooth 4.0 SoC||Atheros AR3012 Bluetooth 4.0 SoC|
|ZigBee||– Silicon Labs EM3581 ZigBee / Thread SoC
– Skyworks SKY66109-11 2.4 GHz ZigBee front end
Table 1: Component summary and comparison
Note the dedicated monitor radio found in OnHub is not part of GWiFi. The gallery below has some more inside photos and commentary.
View with bottom cover removed.
Same side of board, with Ethernet / power board and RF can tops removed. Small RF can at top of board has Skyworks 5 GHz front ends.
Other side of board has most of the components, The ZigBee radio is at upper left.
This large cast piece thermally couples to a few devices and serves as the heatsink.
The antenna assembly sits at the top. Left antenna is one of two 5 GHz; right is for ZigBee.
Left antenna is second 5 GHz; right is one of two 2.4 GHz. The other 2.4 GHz is on the other side and is vertically polarized. The Bluetooth radio shares this 2.4 GHz antenna.
Other reviewers have covered GWifi’s easy installation and there is this nice installation video, so I won’t be spending much time on setup. The only things I’ll point out are that the app provides easy-to-use guidance for initially placing Wifi points and also for moving them.
Instead, let’s focus on GWifi’s features, or lack thereof. Like other "three-pack" mesh products, GWifi’s feature set skews toward the basics that their target non-techie buyer needs. Setup is done via iOS or Android app (pictured below), which was easy to use. The three top-level screens are shown below. If you’re a tweaker, you’ll probably spend most of your time in the second and third tabs and their sub-screens.
Google Wifi app – Top Level Screens
First, let’s cover the feature set, most of which are found under Network Settings > Advanced Networking. The screenshot below shows most of what you can do.
- Automatic (default). Uses Google’s DNS, but falls back to your ISP’s in the unlikely event Google’s fails
- ISP’s DNS
- DHCP (default)
- DHCP reservations
- Port forwarding (static single and port ranges, no triggered ports)
- UPnP disable (default enabled)
- Priority device (prioritizes uplink traffic for one device)
- Guest network
- Home control (Philips Hue bulbs only, requires Hue bridge)
- Family Wi-Fi Pause (suspend internet access for device and device groups)
Google Wifi app – Feature Screens
Key things not supported:
- Outbound and inbound service and website blocking and other parental controls
- DMZ host
- Access Point mode
- Ability to set LAN IP (fixed to 192.168.86) and DHCP range
- Wi-Fi Protected Setup (due to security risk, according to Google)
The most significant missing feature is the ability to operate multiple GWifis (or OnHubs) in mesh mode as access points, i.e. with no routing features and bridged to your router’s LAN. I was initially as confused as you may be by the Bridge option in the Network Mode screen. It took a few emails and eventually a phone call to nail down that only a single GWifi can be operated as an AP. If you want to add Wifi points to your network, you have to use NAT mode.
Google has made this choice because they feel their target buyer is neither interested nor prepared to deal with the complexity of running a router for routing features and a mesh network for Wi-Fi. They also point out that, as with any router operated in AP mode, you lose most of the nifty features of the product.
On a more positive note, the list of features above doesn’t include the fact that ASUS and TP-Link OnHubs can now be configured as Wifi points either with or without Google Wifi. So this makes Google the only option if you want to create a mesh network using AC1900 class (3×3) mesh nodes vs. AC1200. Google has posted simple instructions in its support forum and this short article.
One of the common complaints about mesh systems is the lack of visibility into how well the mesh itself is working. Sure, it’s nice to have a quick way to check your internet up and downlink throughput, but what about the connections between mesh nodes and the actual devices? This is where GWiFi shines and is way ahead of any of its competition. The app shows connection quality for each of the Wifi points and lets you run the test on demand.
Google Wifi app – Mesh test
While the result is neither actual signal level nor throughput, it’s better than what competing systems provide (nothing). It’s also turns out to be a good indication of actual performance, as I found during mesh performance testing. You also get the usual internet speed test, but can also check the connection quality of the device the app is running on.
Google Wifi app – Other tests
Finally, for those who like to keep track of bandwidth use, Google has you covered too. You can select the timeframe, get an overview of bandwidth use by device and also drill down to individual devices. The little screen icon at the lower left of the middle and right screens below is used to set the Priority device. This function the same as in OnHub and prioritizes uplink bandwidth for the selected device for either 1, 2 or 4 hours.
Google Wifi app – Bandwidth use
Because GWifi continues to operate without an internet connection, I was able to run our Version 4 router performance tests on it with 8872.40.9 firmware. Table 2 summarizes routing test results; this Excel test summary contains all functional and performance test results.
The app let me forward the two static ports required for the test suite, but didn’t support setting up triggered ports or setting the DHCP server range. So the lower functional score reflects this.
Table 2 summarizes the performance test results and includes Luma. eero isn’t in this table because it drops its connections five minutes after losing internet connection. So it can’t be tested with the Version 4 process, which requires devices be disconnected from the internet.
GWifi’s lower Simultaneous TCP throughput appears to be due to a larger number of total retries vs. Luma (36,726 vs. 12,625). Similarly, GWifi’s lower simultaneous UDP throughput is due to higher packet loss of about 10% in each direction vs. Luma 0.1%.
|Test Description||Google Wifi||Luma|
|WAN – LAN TCP (Mbps)||941||941|
|LAN – WAN TCP (Mbps)||941||941|
|Total Simultaneous TCP (Mbps)||1539||1764|
|WAN – LAN UDP (Mbps)||950||960|
|LAN – WAN UDP (Mbps)||950||950|
|Total Simultaneous UDP (Mbps)||1710||1898|
Table 2: Routing performance comparison
Luma has no functional score because none of the settings required for the test could be configured.
Google Wifi is not Wi-Fi Certified and does not support Wi-Fi Protected Setup (WPS). So any client you connect to it must be able to have its Wi-Fi network password entered. It supports WPA2/AES PSK wireless encryption only. Google also provided the following information about GWifi:
- Band steering is supported
- Devices are not load balanced among Wifi points
- 802.11v, k and r are currently not supported. RSSI based roaming assistance is used
- DFS channels are not supported
Google was very cooperative in accommodating our V9 test process requirements. In addition to a standard three-pack, they provided one Wifi point with 8872.40.9 firmware and the 2.4 GHz radio set to 20 MHz bandwidth for our throughput vs. attenuation test and one set to 40 MHz for maximum throughput testing. Both had the 2.4 GHz channel set to 6 and 5 GHz set to 40. Throughput vs. range testing was performed on the 20 MHz bandwidth sample.
GWifi was centered on the test chamber turntable in normal operating position, as shown in the photo below. The 0° position for had the connectors facing away from the chamber antennas as shown.
Google Wifi in test chamber
Although eero and Luma have been retested using the V9 wireless process, they are still marked with a "Special" test method because they could not run the latest Router test process. This is why you won’t find either as AC1200 class products in either the Router Ranker or Charts. So I had to create the comparison plots below of the three plus NETGEAR’s Orbi using Excel.
The 2.4 GHz downlink profile shows a stark difference in both throughput and range between eero and Luma and Orbi and GWifi. Given the design similarity, this is puzzling.
2.4 GHz Downlink Throughput vs. Attenuation
A similar pattern holds for 2.4 GHz uplink.
2.4 GHz Uplink Throughput vs. Attenuation
The performance stratification continues for 5 GHz downlink. Orbi continues its pattern of remaining slightly above GWifi throughout much of the tested attenuation range.
5 GHz Downlink Throughput vs. Attenuation
5 GHz uplink is the one test that mixed things up. eero suddenly jumps ahead of everything else for throughput, but still has shorter range, disconnecting after the 30 dB attenuation test. GWifi starts out stronger than Orbi until the 15 dB test, then the two track very closely for the rest of the run.
5 GHz Uplink Throughput vs. Attenuation
The second part of wireless testing used the open air mesh test process I’ve been using with all mesh products. For these tests, I’ve chosen to compare only the three "three-pack" mesh products, i.e. eero, Luma and GWifi. As an added bonus, however, I’ve included test results for eero with its Version 2.0 firmware.
The first chart shows downlink performance with the middle node in the hallway location. This spot is a tougher test in that it has higher attenuation than the living room location. As a reminder, the Kitch-Reconnect test location represents two-hop results, with connection confirmed by BSSID. I should also note that the GWifi app flagged the Hallway location as having poor mesh performance and suggested moving the node.
GWifi does better than Luma in all except the best-case Office location. Comparison to eero is mixed, with GWifi doing about the same or better depending on location and eero firmware version. Luma and GWifi connected on 5 GHz for all tests shown, which seems to be the preferred band for the NETGEAR A6200 USB client I use. eero also used 5 GHz with the old firmware, but roamed to 2.4 GHz in the Living Room and Kitchen locations with the middle node in both the Hallway and Kitchen locations. That may account for the lower eerov2 throughput in those locations.
Mesh throughput summary w/ Hallway node – downlink
Hallway location uplink shows GWifi tracking lower than eero in most cases.
Mesh throughput summary w/ Hallway node – uplink
Moving the center mesh node to the Living Room location, which the GWifi app had no objection to, moves GWifi above eerov2 in most cases. But eerov2 connected on 2.4 GHz for the Living Room and Kitchen tests, moving to 5 GHz only with the forced re-association in the Kitchen-Reconnect test. But GWifi still had higher throughput for the last test.
Mesh throughput summary w/ Living Room node – downlink
Uplink results again show eero with generally higher throughput than GWifi.
Mesh throughput summary w/ Living Room node – uplink
Finally, I also ran a quick tests with a TP-Link OnHub configured as the root node, to see if an AC1900 class 3×3 radio would make a significant difference. It didn’t. As you might expect, performance was limited by the GWifi’s AC1200 class 2×2 radio. To get a performance boost, you’ll need to build your mesh entirely with OnHubs.
Some folks will want to connect Ethernet devices to mesh nodes, using them as wireless bridges in addition to their Wi-Fi duties. All three products automatically support this, simply by plugging an Ethernet device into either port.
For the test, each product is set up with the root node in my office on the lower level of one end of my home and another node in the hallway and living room locations, one floor up. (See the first Mesh Mashup review for location details.) As with the previous tests, I just turned products on and let them link up. I used the same Lenovo x220i laptop for testing, but connected it via Ethernet to one of each product’s Ethernet ports.
The downlink chart below shows performance by location. The Living Room spot has higher throughput than the Hallway location for all products, with the GWifi having the biggest jump, from 88 to 210 Mbps!
Wireless bridge performance – downlink
Uplink results again show improved throughput in the Living Room location. Luma wins the prize here for most improvement, increasing to 92 Mbps from 14.
Wireless bridge performance – uplink
These results are important because a mesh node can, at best, pass on only the throughput it receives via its backhaul link. This is one of the reasons Orbi, witih its dedicated 4×4 AC backhaul link, beats the pants off all the shared 2×2 based solutions. For reference, Orbi’s results were 335 and 528 Mbps for downlink and 284 and 413 Mbps uplink for Hallway and Living Room locations, respectively.
Given its brand, Google could afford to take its time to enter the Wi-Fi mesh market. But name gets you only so far, you also need advantage in price, performance or features to move market share your way. Google definitely has the edge on price for now, although Luma has reduced its three-pack, but not its single point, price to match Google’s. Given the similarity of its design to Google Wifi’s, Luma is in a much better position than eero to do this and still stand a chance of making money. But given Google’s deep pockets and probable volume advantage, it’s questionable whether price matching is a viable long term strategy for Luma.
eero appears to have the edge on Google Wifi for performance, either with or without eero’s new V2.0 firmware. Backhaul performance, as measured by the wireless bridge tests, did improve, but didn’t consistently provide the 2X performance boost eero claimed in its briefing call.
For routing features, Luma, eero and GWifi are about equal, with GWifi’s main disadvantage being is inability to work as access points in a mesh configuration, which is sorta the reason you buy it, eh? On the plus side, Google Wifi is definitely the one you’ll want if you like to measure performance of something other than your internet connection. And its bandwidth monitoring reports are a nice plus, too.
The bottom line depends on your situation.
- Already have an eero, or have bought and returned it and are still desperately seeking mesh Wi-Fi – There’s no good reason to try Google Wifi. Get a NETGEAR Orbi.
- Have Luma, but aren’t happy with its performance and want to minimize your additional cost – Give Google Wi-Fi a try.
- Are looking to see what this whole mesh Wi-Fi thing is about, but are on a budget – Give Google Wi-Fi a try.