Google Home Mini teardown, comparison to Echo Dot, and giving technology a voice

Justin Alvey
14 min readOct 25, 2017

--

Google just announced some new products — one of which was the Google Home Mini, a smaller, cheaper version of their voice assistant, which just started shipping.

I was drawn to Google’s new design direction, that’s come a far way from their serif, primary-colored type-logo, notably the expressive colors, creative use of materials, the nod to Olivetti and Italian design, and lastly I couldn’t help but be wooed by the playful association to a donut, towards which I have a soft spot.

As a disclaimer, I am a big fan of the Echo Dot and what Amazon’s hardware team is doing to help spread their technology products outside of Silicon Valley and into everyone’s homes. And I also think having a name to address like ‘Alexa’ (or ‘Cortana’ or ‘Siri’) goes a long way to making an ephemeral assistant more approachable, whereas Google have not (yet?) embodied their voice in a named persona — so uttering “Ok, Google” does make me cringe a little. But Google has, in my opinion, a one-up on the design here. While the new Echo line has a fabric exterior, it does feel more like an afterthought than part of the original design intent. And so despite not being able to whisper ‘Alexa’ anywhere in my house without triggering a blue and green light-show, I naturally had to get hold of a Google Home Mini and take a peek behind the scenes.

Besides being intrigued by the fabric design, there were a few other questions about the new Google Home Mini that I sought to answer in the following teardown:

  • How does it stack up to Amazon’s Echo Dot as a remarkably similiar product at the same price point?
  • What changed from the regular Google Home, to get this to less than half the price of the regular Google Home?
  • How is a single speaker used to create uniform omnidirectional sound, from behind the LED dots and touch controls all while embedded under the fabric?
  • And lastly, what could have gone wrong with the tap control to cause the quickly-resolved bug (and PR close-shave) resulting in some devices listening to everything being said?

So read on, and all will be revealed!

Interestingly, the folks at Android Police just released a software teardown of the Google app update, which revealed some clues about a new Google Home with a screen. Well here’s the hardware equivalent of the teardown, lets see what can be learned…

Unboxing and setup

The box that arrived on my doorstep looked suprisingly willing to be stolen, with Google as the ship-from address. The packaging is obviously intended for retail, given the hang tab, is well designed and cost effective, with a neat perforated tear-tab, and white pulp trays cradling the product.

The plastic hang-tab was awkwardly crushed in the box

Setting up was easy, and the product’s aesthetic and charm did not disappoint in real life. But I quickly ran into my biggest gripe: for what would mostly be used as a music playing assistant, there is no way to directly connect external “dumb” or even Bluetooth speakers, or support of audio over USB-C, as in the Pixel 2. Instead the solution to connect to external speakers here is to buy a $35 Chromecast audio to connect to them over Wifi.

Fun hack: If the Mini had Bluetooth speaker support, one would have been able to use the Echo Dot as a $49 ‘Bluetooth-to-audio jack adapter’, while also having the redundancy of two voice assistants through the same speakers. I’m not sure either company would have wanted this though, nor realistically would I…

Not playing as nice as I hoped…

Anyway, no time to waste, lets get to the teardown… 🔨

Disassembling

Ah, the pretty, soft-touch, and expressively-colored base-plate.

It seemed obvious there were some screws hiding beneath this, but seeming really difficult to pry off, I attempted to find some snaps holding together the fabric shell and plastic base, that I could pry apart instead.

Nope, none here. I’d have to work on softening the adhesive glue on the base to reveal the screws. One could use a specialized custom heat-pack for this. I needed a quick hack to apply a controlled temperature to the surface, so as not to melt the cover or damage the components, while still allowing enough time for the glue to soften. The solution — a pot within a water bath, similiar to how one would prepare a poached egg or sauces, would limit the pot’s temperature to the boiling point of water. Gastronomy has it’s applications…

Donut try this at home 🍩

About 5 minutes later, the base had softened and could be peeled right off, revealing the once stubborn double-sided adhesive that was similarily used in the original Google Home to attach the touchscreen.

Here is one I prepared earlier 👨‍🍳

Removing the adhesive and the torx screws now allows the two halves of the product to easily come apart, revealing a ribbon cable that needs to be unplugged before completely seperating. This reveals what looks like a custom speaker enclosure attached with another 4 torx screws to the fabric shell.

The flex cable connects to a small interfacing PCB, with a USB header, a toggle switch (for disabling the microphone), and a reset button on the reverse, intended to be pressable through the baseplate. (Note the plastic flexure translating a general push on the area into specific button actuation). No other components here besides a decoupling capacitor for the 5V power supply.

USB micro B — so 2000's, but it’s not like they planned on passing audio through here anyway

Removing the black enclosure, we can see it is indeed an impressively sized custom speaker enclosure, and we get a hint at the solution to providing omnidirectional sound from the metal shape below.

Removing the hopefully final set of 4 torx screws, we set free the interesting metal/plastic part, and finally reveal the main PCB.

Lets have a closer look at this metal/plastic part, and see how it contributes to the design.

Childhood jigsaw puzzles jump to mind

The metal looks like it was molded, and then sections of it overmolded with plastic, achieving a tight fit and perfect tolerances. Why the plastic and why not all metal? If you take a look at the two large black areas, you’ll see they correspond to where the Bluetooth and Wifi antenna’s on the PCB are. Not having metal in this area is critical for good RF performance. The plastic is also used to electrically isolate two stainless steel “touch sensors” from the metal frame. These are used for sensing side-taps for volume control.

You may also ask, why not make the whole part plastic? Using metal would primarily be for thermal relief, i.e. dissipating the heat generated by a powerful processor (note the blue thermal pad which makes contact with the shield of the main processor on the PCB). But the metal could also add strength and tight tolerances to what is the main structural component holding everything else together, while also adding a bit of weight, helping the little Google Home Mini feel more solid and sit better on a table-top.

Now onto that cone-shaped protrusion on the metal. You can see that this together with the support arms provide a precisely designed air spacing for the speaker to most optimally broadcast sound. No doubt a lot of acoustic engineering went into this…

The speaker setup 🔊🎼 — helping keep the donut imagery consistent

The PCB and electronics

Removing the PCB you can finally see where most of the magic happens.

Main PCB, and underneath the donut’s frosting, showing LED light pipes, capacitive sensor plates, and some mic holes

The arguably most important feature is provided by two humble microphones, placed on opposite ends of the PCB. This allows noise cancellation and beam-forming i.e. figuring out the location of the sound, similiar to how two ears on opposite sides of one’s head does.

MEMS microphones are ideal for this, as they have tight sensitivity matching (i.e. there is low variation in how sensitive manufactured components are to different frequencies ) which makes them great for these beam-forming and noise-cancellation algorithms. And as with most MEMS microphones used today, the port is on the bottom, requiring a hole through the PCB, as can be seen below.

A bottom-port microphone viewed from both sides. Note the sealing paste used for isolation against the exterior shell

Interesting note: A “pick-and-place” assembly machine uses a vacuum to pick up the tiny electronic components from a reel and then place them onto the PCB. Creating a vacuum over the microphone port would damage the MEMS microphone, so this is one less thing to worry about with microphones with a bottom-port. The other trade-off’s with having a bottom-port relate to cost and frequency response.

To get to the brains of the PCB, we’ll need to remove the metal shielding in 3 places. These typically consist of a “fence” that is soldered onto the board, and covers that can pop-off (and be placed back on) easily thanks to the little bumps along their perimeter. These little shields are very cheaply made from stamped sheet metal.

Note the thermal pad which helps conduct heat from the main processor, through the shield and to the metal “heat-sink”/speaker bracket. The fences still have large surfaces (providing a surface for the vacuum pick-up assembly method we discussed earlier) that we’ll need to cut away to identify all the chips. No long term harm here, as the shield covers will still protect from any noise once replaced.

The brains

We can see some familiar chips from the previous and originial Google Home. This would obviously save a lot of development time, and so there would be little sense in making significant changes. Working from the top left we have:

  • Marvell 88DE3006-BTK2 — (unchanged) This is the multimedia processor SoC, an ARMADA 1500 Mini Plus with a Dual-Core ARM Cortex A7, supporting 1080p HD content.
  • Toshiba TC58NVG1S3HBA16 —(unchanged) 256 MB NAND flash
  • Texas Instruments TAS5720 — (unchanged) The audio amplifier
  • Marvell Avastar 88W8887 WLAN/BT/NFC SoC — (changed from the 88W8897 used in the Google Home) The main difference with this SoC is that instead of a 2x2 wifi radio (meaning it can send and receive on two antennas simultaneously and do wifi beamforming), it only has a “1x1”. This is most likely a cost reduction, also requiring less thermal dissipation and hence a smaller, cheaper design, for a product that may not need the extra bandwidth and antenna strength.
  • SK hynix H5TC4G63CFR-PBA — This is 4Gb DDR3L SDRAM (changed from the Samsung K4B4G16 512MB DDR3 SDRAM used in the Google Home)

There are also now only 4 RGB status LEDs, compared to the 12 in the original Google Home, and so they also got away with using only one LED driver, the NXP PCA9956BTW, instead of two. A relatively minor cost reduction.

Also included is some Marvell switched-mode power supplies. Nothing superhero here though.

Peeling back some adhesive foam, you can see a flex cable soldered directly to the board — marginally cheaper but significantly tougher than the ZIF connector used on the other end of the cable. I’m open to learn about how this compares in terms of time and cost on the assembly line.

The tap controls and the “Always Listening” bug

With most of the PCB components covered, we can move our attention to the source of an unfortunate bug, that caused some early devices to continuously listen to audio. The feature-turned-bug was a touch sensor that could be used trigger the device to start listening without having to say the magic “Ok Google” wake command.

Below you can see the capacitive touch sensor consisted of stamped sheet metal adhered onto the inside of the plastic shell, surrounding the LED light pipes. A small, gold tipped spring contact was used to connect to the PCB.

What could have caused the stray change in capacitance that made the sensor think a finger was hovering above it, triggering recording?

Some guesses say it could have been moisture, or something to do with the adhesive on the sheet-metal. Or related to the heat-generating Dual-Core ARM Cortex A7 directly beneath the contact.

But I’m suspicious of the placement of the contact on the PCB. You can see it was squeezed in quite close inbetween a foam gasket meant to reduce LED light spillover — which was resultingly trimmed shorter to make space, and the shield of the SDRAM — which one would not want to accidentally contact. Also, some adhesive conductive mesh (think sticky steel wool) was stuck over the gold-plated contact. This could be an attempted fix of a potential bad connection of the sheet metal to the PCB in the case of some tolerance misalignment or spring fatigue. Or it could be a source of the problem, with the adhesive altering conductivity at different temperatures, or causing stray connections to the nearby ground shield.

Having experienced these type of edge cases in manufacturing, I’m sure there’s an explanation that became apparent in the field. It was probably painful to the design team to lose that feature, but lucky it could have been easily killed with a firmware update instead of requiring a recall or resulting in a PR nightmare.

Now lets take a look at the capacitive-touch volume controls, which did seem to be behaving.

One can see the gold-plated tip of the stainless-steel is to connect with the golden contacts visible on the PCB. The rest of the stainless-steel part is sprung against the metal frame with foam adhesive, ensuring a tight press against the fabric shell, while still preventing electrical contact with the metal part. The fabric shell has corresponding insulating and padded Kapton tape, to ensure a snug fit, and probably to prevent direct moisture or contaminants from glitching out the capacitive sensing.

On initially hearing that the controls required tapping, I thought this might have been done by an accelerometer, which we can see it wasn’t. If cheap enough, this may have actually helped provide the redundancy necessary to eliminate false positives on the capacitive touch sensors, but hindsight is 20/20.

Molded parts and manufacturing dates

Interestingly, across most of the molded parts, you can see dates of manufacturer. These changeable imprints are built into the tools so that one can easily and reliably track parts that are made. Note the overmolded metal part has a resolution of down to the day (day 2 & 3 of week 33) corresponding to what I believe is the 14 & 15th August. The plastic overmolding however indicates the 13th August. Is there something I am missing, or did tight production schedules require time travel? (I would not put it past Google) It also looks like the white plastic base was manufactured a month later, in September, likely due to the stricter cosmetic requirement meaning it was iterated on during validation runs more than internal parts.

Manufacturing dates imprinted into the injection-molded product parts 🕵️

Comparing to the Echo Dot…

While the Google Home Mini and Amazon Echo Dot were given birth by two feuding giants, and they look very different on the outside, what’s on the inside does not appear too different. (Aww… )

Below you can see a line-up of their most significant internals. Most notably, you can see if you look closely that the Dot has 7 microphones instead of the two on the Google Home Mini, but Google’s software here has still done a great job of being able to hear above noise and music, and identify different voices, using just these two. There have been a lot of teardowns of the Dot done so be sure to check them out if you’d like to learn more of the details.

Google Home Mini (top) and Amazon Echo Dot, 2nd gen (bottom). Lineup from left to right: PCBs, custom speakers, and… paperweights (?)

Giving technology a voice

In summary, the Google Home Mini is a beautifully designed product. And the internals show some serious thought went into making this compact, affordable as well as being easy to re-assemble, which I appreciate. Looking at the single main PCB of the Mini, and that of the Dot, one can see how simple it has become to make a voice assistant, and can assume this will start to become commodified, leaving the innovation to either the AI and Natural Language Processing itself, or the integration of this hardware into other products rather than being just a standalone device.

I ultimately believe that hardware is that magical, physical touchpoint or gateway for powerful software applications to reach human beings, so any effort put into making this interaction more seamless, beautiful and fun can go a long way and has my support. And so I believe we need more people understanding and building this type of technology, to make the chances higher that the future we build will be one that we all want.

Her (2013)

There are already devboards, hobbyist kits, and cheap Raspberry Pi plugins to integrate Alexa, Google Voice or other assistants into your own projects, so be sure to check them out. Hopefully this inspires some of you to start building, so we can see less Black Mirrors on our devices, more creative ways that voice can be integrated into our lives, and hopefully the virtue of the $100 laptop for education can be replaced by a <$10 voice tutor.

I hope you enjoyed this teardown and took something away from it — if you did, please clap away at the button below. If you have any questions, feedback or insights I missed, feel free to comment below or e-mail me at j@justinalvey.com

Also, follow me on Twitter at @justlv, or check out my other teardowns here:
Nest Thermostat E
Google Pixel Buds

--

--

Justin Alvey
Justin Alvey

Written by Justin Alvey

Hardware, design, science & the future

Responses (22)