Do you have an issue with Galaxy Nexus volume changing automatically? (Updated 01.12)

NEW IN THIS THREAD?
PLEASE READ THE FOLLOWING BEFORE REPLYING

PLEASE NOTE THAT THE PROBLEM HAS BEEN FIXED WITH AN OVER-THE-AIR UPDATE BY GOOGLE. IF YOU SUFFER FROM THIS PROBLEM THEN YOU SHOULD WAIT FOR THE UPDATE TO ARRIVE ON YOUR DEVICE.

Full details:

What the problem is

• The device has an issue of volume acting strangely. Most often the volume mutes very quickly. Sometimes the volume starts 'jumping' between muted and loud very quickly.
• This volume issue happens often during phone calls, using internet or receiving SMS text messages.
• Some users are also reporting that when calling, they can hear 'radio interference' sounds.
• The device is often unresponsive while the problem happens. Power button not working for the brief time has been reported.

How it happens

• The problem happens while the device uses GSM 900 network, that is when the device is in 2G.
• Your phone is on 2G when it uses E (Edge) and G (GPRS) connections, both data and mobile. If data is used, a small letter near signal indicator points out what you are connected to.
• The problem happens while another device that is on GSM 900 is nearby and is transmitting in 2G network. This happens even if Nexus itself is not using any networks at the time (such as when radios are off and the device is in Airplane mode).
• The problem is more evident when user is in low-signal area and more 2G information is transmitted.
• The problem also happens in bootloader and is not the fault of Android 4.0 itself.
• Please remember that the problem does not happen for all 2G networks, some 2G networks (especially outside Europe) do not use GSM 900.

How many users are affected

• Every Samsung Galaxy Nexus handset seems to be affected by this problem. Majority of users however are not encountering the problem due to not using GSM 900 2G networks.
• 2G networks working on GSM 900 are majority of Europe, Africa, Australia, Middle East and large part of Asia.
• In UK, the GSM 900 is used by O2, Vodafone, giffgaff, Tesco Mobile.

What Samsung and Google are saying

• No official statements from Samsung other than asking people to send details of the problems on their customer support e-mail (uk.technical@samsung.com).
• Samsung did post a quote on their Samsung UK Facebook wall that says 'We are aware of the volume issue and have developed a fix. We will update devices as soon as possible.' This quote is said to be originating from Google according to Samsung, Clove, androidpolice.com and The Verge.
• Google employee has confirmed in an Android developer chatroom that Google is developing or has developed a software fix for the problem.
• Another Google employee, Dan Morrill, shared a post by Lee Johnson on his wall and said that he is very accurate in his estimation about how software can fix this hardware flaw.
• Google has replied to a customer support thread that there is a fix and it will be rolled out in the coming week. It is possible that the 'coming week' refers to week starting 5th of December.

What sellers are saying

• Handtec and Clove conducted additional testing on the devices and both found the volume bug to exist on their devices.
• Handtec stopped the shipments after the problem became widely known. Samsung Distribution also stopped shipments for sellers few days later, delaying shipments of the device for a week.
• Clove stated that according to what they heard from Google, that a software fix is being worked upon. Clove stated that according to their sources the problem is in software and not hardware. Clove has not gotten this information from Google or Samsung directly however and refers to their inside research about information found online and their own sources.
• While it was originally believed that the shipment delays are because of Samsung flashing the devices with updated software that will fix the bug, the new devices shipped on 29.11 also carry the bug according to Clove. It seems Samsung held the shipments to give Google additional testing time with the fix and held back possible refunds and replacement handsets would have gotten had the shipments not been held back.

Is it hardware or software problem?

• All the tests conducted by many users so far indicate that the problem is in hardware and that the device receives signals from 2G that it should not receive due to not being protected from radio interference. This is also shown while the device runs in bootloader.
• Many engineers here and in other forums and social networks say that a cheap hardware shielding would fix the problem easily, however Samsung and Google intend to fix the problem with possibly as valid means through software.
• If the software fix manages to patch the problem, then it really does not matter if the problem was in software or hardware, as long as the device works properly and there are no after-effects, since some users fear that the software fix of a hardware might cause additional battery drain or unresponsiveness problems. But this is merely an opinion, we will know more once the patch is out.
• The flaw is confirmed to be a hardware flaw by engineers, as well as a Google employee (referred to above). But both state that it is common for this type of hardware flaw to be patched with software and it is likely that many devices you already own have such patches in place without you knowing it.

What you can do

• Wait for the update to arrive on your Galaxy Nexus. Google is slowly rolling out a fix to all handsets right now. Make sure you have internet or data connection for the update and have your phone in a charger just in case while updating.

Hope people don't forget to credit me for enabling to prove this once for all.

CanaganD said:

Lets be clear:

I'm a professional software developer (as a lot of us are), but I am also versed in eletronics and radio equipment (Industry Canada issued callsign: V**CMY). I can definitely say right now, that from the symptoms presented, it IS a hardware design flaw. No one worth their salt in eletronics engineering or software development for that matter would dispute this.

Issues like this happen often with lesser manufacturers (Chinese based designs for instance) due to their inexperience with RF sheilding and avoidance of using RF conductive paths. For instance, the length of a wire can determine which frequency it can be susceptable to... ex: a wire at 1/8, 1/4, 1/2 the wave length of the target freqency, is a wire that is able to pick up more noise on that frequency. Which is why, if you measure the antenna on your FRS radio and multiply it by 4 or 2, you get approximately the wavlength of the 460MHz spectrum

Since it's CLEAR that this is a hardware problem. The software fix will always be a bandaid solution and nothing more. The software fix may be so clever or so efficient that the hardware faults will never be noticed again, but I'm highly skeptical that this would completely disappear.

The only reason a software fix is occuring instead of a PROPER hardware fix is cost. Samsung is a ruthless company that squeezes margins and conducting a launch of this magnitude then to retrofit a recall to all phones AND new phones is significant. Just look at Apple, they released a $3 bumper and that was already far less costly than total recall (heh heh... total recall...)


As I posted 20 entries back in this thread, the software fix would be to manage symptoms by tracking the 'stale' volume level, whether or not the phone is operating on 2g 900MHz, duration of the volume press (symptoms indicate very short down press interval) and if the volumedown button is being rapidly pressed beyond human capability.



Due to the requirement of the OS to know when it is in 2G and also in 900MHz mode, and to handle volume events at the source, a change to the kernel is necessary (which is why Google in involved, as they know the Kernel inside and out).

If in some strange way this issue is software related, Samsung would only need to update their drivers or OS/Hardware interfacing code. But no, instead the Kernel needs modification so that Samsung knows some mitigation parameters from the phone so that it can 'bandaid' it.

This is my PROFESSIONAL opinion. And if you ask another software dev, I'm sure he'll agree 90%.

Click to expand...

Click to collapse

Let's get the qualification bit out of the way: I am pursuing a PhD in Electrical Engineering. While you're right that this problem has its roots in hardware, and one possible fix would be a change to RF shielding, I encourage you to explain why a fix in firmware is so terribly inferior.

First of all, the problem has been exhibited in the bootloader, so the patch cannot be applied in the kernel as you have suggested, since the kernel isn't even in play in bootloader mode. If you're claiming that the fix will *only* fix the bug within Android, and the bootloader will remain borked, that's a very bold and easily verifiable claim now that the fix has been released.

Secondly, claims abound that there's something wrong with a software fix, as if this sort of thing isn't common. As pointed out by Google engineer Dan Morrill (google 'Dan Morrill Nexus Volume), and, as I can confirm from my undergraduate degree, whenever you have a button, you need to debounce ( wikipedia 'debounce' ) the signal from the switch or else you will get spurious multiple presses whenever the button is pressed. So the idea of using logic circuitry/software to inhibit event generation soon after a button press is the absolutely dead-standard solution used by everyone, from hobbyists to global giants. Adapting that to testing if a button press is consistent and long, and not spurious noise is an absolutely trivial modification.

OK, so this means that the problem can probably be completely solved in software. That is, perfectly solved, you will never ever see a spurious button press due to radio interference. The only concern that remains is whether or not the CPU is 'overwhelmed with interrupts'; spending all of its time handling spurious interrupts only to find that the interrupts should be ignored to implement debouncing. Again, there is a far better solution: *disable* the volume button interrupt for a certain amount of time. That is, disable the volume button interrupt, and set a hardware timer going to fire x milliseconds later. When the hardware timer fires, re-enable the volume button interrupt, and see what's up. During the x ms, the processor is left in complete peace to do whatever processing is necessary.

When implemented on a slow (strictly compared to a Cortex A8) Atmel AVR microcontroller, this sort of strategy can transform a situation where the microcontroller is completely stalled, running at 100% CPU, just continually handling spurious button press interrupts, to < 1% CPU utilisation with no apparent overhead whatsoever.

Now, a hypothetical question: When *any* smartphone company, with the tight profit margins endemic to such a competitive marketplace, is presented with the option to a) implement proper RF shielding, which costs 2 cents per phone or b) do it in software for zero cents in such a way that it has an absolutely immeasurably negligble bearing on software performance or battery life, what would they choose? The only difference here is that Samsung made a bit of a mistake in not testing it in all markets, and are now putting out the software that they would have always put out if they were on a more relaxed timeline.

I cannot stress this enough: it is almost completely irrelevant how nasty the signal on the volume button line is, and how badly it makes the *current* software lag out. Software has control over the nature of the interrupts that it REQUESTS (the R in IRQ), so a complete, perfect fix for the lagging comes inherently with the fix of the spurious presses. And it's a fix shared not just by all smartphones in the market (admittedly, perhaps, only to implement debouncing), but just about any modern device that has a button on it.

Now I've already made my point at this stage, but I'm going to keep on going just to cover all the bases.

A smartphone is a bloody complicated thing; it's much closer to a PC than an Arduino board with an Atmel AVR on it. Imagine this problem happened on your PC: a 2G phone nearby caused your keyboard to type random characters. Everyone seems to be reacting under an apparent assumption here that this 'bandaid fix' is like a terrible hack in Windows that just uses some complicated heuristic to guess which key presses are fake and discard them. So what would you prefer? The keyboard is broken, so you would want to fix that instead, right? How would you do that? By updating the software on the keyboard. So why didn't Samsung do that... oh, wait. They probably did.

While the firmware inside a keyboard is probably not updateable over USB, there's in a micro hiding in there. Even in a tightly integrated device like a smartphone, the volume button probably isn't directly wired to a pin on the CPU. Just like the keyboard in a PC goes via the southbridge, then the northbridge, and then finally to the CPU. (Yes, I know the northbridge and southbridge have been merged in recent PCs, this is beside point.) Even though space is at a premium in a smartphone, I seriously doubt they would send each volume button and power button (and touch screen inputs) into their own pins on the smartphone CPU. It'll go into some other intermediary chip that handles all of the above, handles debouncing etc, and multiplexes all the data onto some kind of standard bus from the CPU that handles everything else like speakers, microphone, SD card, etc.

If this isn't the case, and the volume buttons are indeed directly wired to the CPU, i've already covered that case above. But otherwise, read on.

That random intermediary chip is probably vaguely related to a microcontroller itself, and guess what, that microcontroller runs software ('firmware'). Update that software, and the problem is completely and utterly fixed, at no cost to performance or anyone's pockets. An utterly perfect solution, that no-one has any valid reason to complain about.

attu90 said:

Ive just recieved the update and installed it but im stuck at the green android with the red triangle, its been like that for about 10 mins ...is this normal ?
im tempted to pull the battery but will that brick my phone ?

Click to expand...

Click to collapse

you should see an android with a spinning hexagon ball ("Buckminsterfullerene" anyone??) and a progress bar at the bottom of the screen
this stage took me about 2 minutes then the phone will restart and you will see "android is upgrading" and another progress bar optimising all your apps.

---------- Post added at 12:09 AM ---------- Previous post was at 12:01 AM ----------




Post-OTA CPU Usage Test (and Bootloader test)

http://www.youtube.com/watch?v=h3T4my6Eyf8

So from this not-so-scientific test this patch (ITL41F) does seem to address the volume bug without significant impact on CPU or system responsiveness.

Like someone mentioned earlier this patch was applied to the Android OS but not the lower level (such as firmware) so the volume bug can still be triggered in boot loader mode.

I've also tried pressing the volume button on GN while another phone was emitting 900MHz GSM signal, and there was no problem controlling the volume of my Galaxy Nexus. (GN responded to human input without erratic behaviour)

A CPU doesn't really process any hardware on its own. Things like key or button presses generate what are known as "interrupts". When the CPU is interrupted, it halts instruction execution and looks for an "interrupt handler" which is a piece of code (software) normally installed by the OS at boot. After the interrupt handler has executed, the CPU returns to executing where it left off before the interrupt. If there is no handler, or interrupts are disabled, nothing happens.

In the case of a PS/2 keyboard, the PS/2 controller on the motherboard talks to the keyboard using the PS/2 protocol which is completely separate from any of this. The controller on the motherboard generates an interrupt when a key is pressed. The CPU halts and executes the interrupt handler, which reads the key from the keyboard buffer (by executing a memory read software instruction, reading from the buffer's location in the address space) and passes it to the OS to handle later.

Buttons on a phone would generate an interrupt. Even the bootloader (which is a piece of software) would have to install an interrupt handler in order to know about them. This is all done through CPU instructions... ie. software.

However, oscillik is not wrong, as what he is really talking about is the interrupts at the hardware level, which is most definitely direct to the CPU. In summary: the 900 MHz interference is probably causing spurious interrupts to be generated. This is very common when RF shielding is inadequate.