> It also said the microphone was originally included in the Nest Guard for the possibility of adding new security features down the line, like the ability to detect broken glass.
Detecting broken glass with a microphone? Does the device even have enough CPU power (and RAM) to add advanced advanced audio processing features? Or was this going to upload the audio to Google's servers to do the work? If it's the latter, that would necessarily[1] require uploading audio without a wake-word trigger.
Either they just admitted to wanting always on microphones in the home, or they are blatantly ling about why the microphone hardware was included. Designing hardware for a large market usually involves a lot of value engineering to reduce the number of parts or replace a feature that requires expensive parts with a functionally similar design that is cheaper. Saving $0.01 (or less) by removing an optional resistor doesn't sound like a lot, but it adds up if you're selling >100k units. A microphone is much more expensive[2]. A part that costs $0.366 (or more[3]?) needs a good reason to be included, and "for the possibility of new features" isn't good enough. So what was the real intended use that justified including a moderatly expensive part?
[1] The robber about to break your window isn't going to call out "Ok, Google" first so the Nest Guard knows it can upload an audio clip.
You don't need "advanced audio processing" to detect a glass window breaking because it is loud, and has a distinctive spectrogram. It's a lot easier to detect glass breaking than a wake word, and you can buy standalone acoustic glass break sensors for under $30.
Ok, so it could at least plausibly have been local processing. I haven't been able to find out what kind of CPU/etc is in the device, and most of the features would have been easy to implement on the almost any hardware. It would have been even stranger to also include a powerful (expensive) CPU to do a bunch of audio processing, but if there are techniques that work on $30 devices, that opens up a much broader range of cheaper hardware.
(I still think it's insane that the bean counters and value engineers let them include a microphone that wasn't needed.)
> I still think it's insane that the bean counters and value engineers let them include a microphone that wasn't needed.
Having worked on hardware products, the features planned sometimes (even often!) change after the hardware has been prototyped and an initial production order has been placed. It is cheaper to simply not ship the feature than it is to change the board.
Many in this comment section do not really seem to have much experience with hardware. It is fairly common for products to ship with unused hardware and it much more believable than malicious intent, especially given how disorganized Google is internally.
Broken glass alarms based on sound are really really common, and are effectively just a slightly modified The Clapper (that maybe cares more about specific frequencies) attached to an alarm that calls the police. My house had one when I was growing up (though it didn't call the police: we turned that part off as it went off every time my father belched ;P).
> Or was this going to upload the audio to Google's servers to do the work? If it's the latter, that would necessarily[1] require uploading audio without a wake-word trigger.
Couldn’t it run a local model to detect possible incidents, and when a local confidence threshold was exceeded, upload to Google to run a more intense model? I’m pretty sure this is how things like “Hey Siri” and “okay Google” are implemented.
>Detecting broken glass with a microphone? Does the device even have enough CPU power (and RAM) to add advanced advanced audio processing features?
Remember the time google lied about performance impact of adblockers in chrome so they wanted to remove function that lets adblockers work? They changed their position after being pointed out that's a huge lie. It was last week.
Detecting broken glass with a microphone? Does the device even have enough CPU power (and RAM) to add advanced advanced audio processing features? Or was this going to upload the audio to Google's servers to do the work? If it's the latter, that would necessarily[1] require uploading audio without a wake-word trigger.
Either they just admitted to wanting always on microphones in the home, or they are blatantly ling about why the microphone hardware was included. Designing hardware for a large market usually involves a lot of value engineering to reduce the number of parts or replace a feature that requires expensive parts with a functionally similar design that is cheaper. Saving $0.01 (or less) by removing an optional resistor doesn't sound like a lot, but it adds up if you're selling >100k units. A microphone is much more expensive[2]. A part that costs $0.366 (or more[3]?) needs a good reason to be included, and "for the possibility of new features" isn't good enough. So what was the real intended use that justified including a moderatly expensive part?
[1] The robber about to break your window isn't going to call out "Ok, Google" first so the Nest Guard knows it can upload an audio clip.
[2] https://www.mouser.com/Electromechanical/Audio-Devices/Micro...
[3] $0.366 when buying >10,000. Up to $0.75 in lower quantities. (prices from a random example: https://www.mouser.com/ProductDetail/DB-Unlimited/MO064402-4... )