Shared publicly  - 
 
Let's talk about the Google Nexus "volumegate" issue.

Today Google said that they have fixed the problem in software, and that a fix is coming.
I see many people saying this is a bunch of BS, but in reality they just have no idea how complex electronic circuits and software interact.


I'm a Systems Engineer and also a Developer. I deal with things like this every day.

What we have here is indeed a hardware issue, in that the radio interference is coming in through the radio hardware.
However things like this can be fix fairly easily in software. It's called debounce.
When you monitor an electronic input like the buttons on a phone there is always noise and flutter even when you just press the button. If testing by Google has shown that they just need to turn up the debounce time (the time which an input must exceed for it to be determined to be a genuine press) then it will more than likely just work and no one will ever see ti again.

Like I said I deal with this kind of thing every day, it's not a big deal as long as your debounce time is not excessive. But noise happens down on the order of 1 to 40 ms, real inputs when you press a button last from 100 or 200ms if you tap the button, up to seconds if you hold it down.

This is nothing like Apple and the iPhone 4 antennae problems that could not be fixed in software. I'm sure everyone will see in due time, the problem will be fixed, and the dust will blow over.

And people will be saying "wow, I was wrong, Google rocks!"

Cheers,

Lee.
113
90
Alex Fischer's profile photoShrinivas Patil's profile photoDavid Lawerteh's profile photoCraig Butterfield's profile photo
45 comments
 
It should also be noted that this is not and never was an issue on the US bound LTE version. This is because not only does it have different radio circuits, but there are no 900MHZ GSM signals in the USA.
 
It's also not an issue with the Canadian phones, probably b/c of lack of 900 MHz.
 
Excellent explanation. I hope more people see this
 
I'll probably add to this with some diagrams tonight as well, I can really show with a diagram what happens in a situation like this.
 
Thx for sharing this.. Guess what,I am going to bed by learning a new thing today. Thx to you :)
 
Electrical noise can be a bitch... I've had to fly to Texas, California and England numerous times (and other places) just to deal with such things...
 
Great explanation. Especially for those of us that know nothing of the inner workings. Ha
 
Thanks for a well thought out professional answer to a hot topic.
 
This is an excellent explanation .. thank you!
 
Great explanation. Thanks.
Is this debounce time calculation done by the CPU, or it happens somewhere else before the input signal reaches the CPU?
 
Improperly debouncing the volume buttons is a rookie mistake! While it might be easily fixable, it sure makes the developers look bad if the problem really is that simple....
 
thanks! i was considering cancelling my order.. its a quite expensive phone! so in your opinion, the fix will be completely legit, with no adverse side effects e.g. hidden cpu usage/battery?
 
Is debouncing a hardware function, e.g. the GPIO that shows up in the log files, and if so, can you specify the time? Or does the OS have to deal with all the interrupts caused by this?
 
But what's strange is why this occurs only with vol down key? I tend to think, there is a wrong pullup or pulldown value set in the driver for that particular port assigned to the vol down button. This also explains, why the pre-mass handset doesn't have this bug. IMHO, the latter could have the driver version with correct configuration. Most probably the mass-production handset has the updated buggy driver, and the handset itself was not tested to RF-proof again, as it could already be done at pre-release stage. Lee, your comments are welcome.
 
+Lee Johnston I was commenting on a reshare of your post so I'll comment again here.
Thanks for explanations, but there is one more thing which I would like to know before buying my next Nexus: Is the phone going to be waken up by a "button press" and it will say: "naah, too short to be a real one, must be interference, let's go back to sleep" only to be waken up again and again? This cannot be a restful sleep and in "the morning" the likely outcome is that the battery will have taken a hit...

Please explain, I don't know how this things works... so, is this a fix or a workaround?
 
Hi, will this problem decrease the overall performances or damage the smartphone itself? I mean, if rocker is influenced by Radio signals, can the motherboard itself be damaged?
 
I never said Google didn't rock. Google, unlike Samsung, are willing to do something about it. Evn though it is not their problem to fix.
 
+Lee Johnston Out of curiosity, what exactly will be targetted by the upcoming OTA to make that kind of change, and where does it "live"? My initials laymans guess would be the kernel, but what's throwing me off is that the bootloader loads and responds to keypresses before that's even loaded. Not quite being able to grok this is actually bothering me more than the bug itself. ;) An explanation would be much appreciated.
 
the kernel is useless without the software on top to tell it what to do. while the kernel may be responsible for android being able to "see" the keypress as such, i'd imagine it's android itself that decides what to do with it. my take of this is that all that is happening here in terms of this "fix" is that the response to the keypress (ie chaging to volume) is being increased from, say, 40 milliseconds, to 90 milliseconds. while that may sound crude, you'd be surprised how often delays are used in real life. in my job as a fire alarm engineer, intelligent fire alarm systems are subject to constant interferance from their surroundings, so everything has a built in delay (we're talking seconds, not minutes, but the delays are still there). it's impossible to completely shield any piece of electronic equipment from interference without limiting what it comes into contact with, so this software fix is a perfectly logical defence against it. so really, the keypress itsekf will still be being detected and processed, it'll just be that the response time before the phone actually does anything will be increased from one incomprehensibly small time to a slightly longer incomprehensibly short time, either way i doubt anyone who can't slow down time will notice a difference. although i'm no software engineer so this is just my opinion based on what i've read.
 
+Lee Johnston We don't have the 900MHZ GSM signal here in the states but I know people that still use 900MHZ cordless landline phones (mom). I'm sure other devices still use that frequency as well. Would these types of devices have caused the same kind of problems here in the states? Could this be why Verizon has not released the phones here yet?
 
+William Martin That can't be the whole story, as there are videos showing the interference happening in the bootloader, which is before the Android system is loaded.
 
Hey guys, really busy today getting ready for a show down in Orlando next week, but basically this sort of thing is pretty low down in the system, in the firmware.
I'll add some more info later today when I have time, but for now let's just relax and let the good guys at Mountain View do their thing.

Peace.
 
+David Lawerteh the firmware in question is a level above the physical hardware, but below any running software. The Bootloader is still a piece of running software that is running on top of the low level firmware and hardware. Hope that helps :)
 
+David Lawerteh i don't mean the problem is effecting the Android software - the interference is effecting the phone hardware, making it believe that the button has been pressed when actually it hasn't. It's the solution that lies in the software - it's sometimes not possible to prevent interference, so the best way to counteract it is to stop it actually doing anything. I can half understand why people think this is something to worry about, but believe me, probably every electrical item you come into contact with on a daily basis is dealing with signals by ignoring them
 
There's only one problem people have forgotten in this whole thing, and that's how people turn in to melodramatic drama queens (and armchair experts) on the internets lol.
 
+Lee Johnston It does, thanks. I take that it's possible for the Bootloader to interface with and modify this low level firmware, so updating it is just a matter of sending the right instructions down?

+William Martin I think we both misunderstood each other, and we actually agree. From the way you phrased it I thought you meant the fix would be handled purely on the OS level, so my response was to say that such a fix still wouldn't help the bootloader (which would be tragic for a Nexus phone).
 
+David Lawerteh sorry, i must have completely misread your post, i didn't even realise your point that this issue is causing the bootloader to start when the phone is powered up, in which case the fix will obviously need to take place before Android even begins to load (and thus before the kernel even comes into play I'd assume). If it's a firmware fix, it's still technically software, but i have no idea if each hardware controller has its own little piece of flash memory for its firmware, or it's all stored on the phone memory.
 
At least a comment that makes sense on what is only a minor bug !
All this flame war around something so insignificant is really pathetic.
 
+Lee Johnston, after all this, let me clarify, that the term bouncing refers to the situation, where the button is physically pressed (or released), and it takes some time until it develops good close (or open) contact. What we are dealing with here is NOT the case of bouncing! It has to do something with high input state, so-called hi-z or floating, which may be a result of wrong pullup/down value chosen for the port. It can also be an insufficient filtering issues, if they use an ADC as the button interface. So, if the root cause is the wrong pullup/down value, then it is a pure sw issue, and in case ADC is used, then again, it might be solved with sw patch, but this time we can't be sure, if its hw filter issues or just a sw engineer's mistake.
 
At least they didn't tell you guys you're holding the phone incorrectly or some blatant excuse.
 
I have Google Nexus, and I have not encountered this problem yet. Well, I bought it 3 or 4 days ago, and everything seems fine.
The OS is a major improvement, it's very very different with all the new functionalities. I'm very happy about it. Cool
 
If this wasn't a Nexus phone, people would be waiting 6-10 months for a promised fix, that would never be delivered because by then the device would be "Old" and not worth the expense of a big OTA rollout.
 
+Alvin Brinson that is very true. People should be happy that this was even acknowledged by both Samsung and Google. And as quickly as it was.

I also hear from "friends" that the fix is already int eh hands of beta testers and that it cures the problem. I'm sure Google will roll out the fix to everyone within a few weeks. It comes with version 4.0.2 from what I am told.
 
I hate to go back to "Searchgate" on the Nexus S. But the software fixes never 100% resolved the issue, and at it's worst it would initiate long-touch regularly on the search button.
 
When I set mine up last night, I was a bit disappointed to have similar issues, but it seems weird since I'm in the US and all the claims here have been that there's an issue with the 900 MHz band, not the 850 Mhz band. It seemed to happen when my old iPhone or my flatmate's new iPhone were a meter or two away. I didn't want to flash the device the day I got it, but in the end, I found out that I had the Samsung-supported variant and they had yet to release the OTA update. After flashing, it was fine. Just slightly frustrating to buy a Nexus and find out updates aren't coming from Google.
Add a comment...