yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] mnexusaud:
I believe it is only when YOUR phone is running on 2G since it is a hardware issue with the phone itself; other sources probably wont have more than the usual affect on it.

Running in 3G you will last about 10-14 hours of battery life with average use. Read my above post regarding battery life expectancy; I could be wrong depending on how efficient the Nexus is, but going by normal NextG with a GS2 it will be hard to keep the phone online, even without using the internet at all.

Having 2G enabled is extremely helpful to conserve battery life and use when travelling around.

As this has been labelled a hardware issue, wouldn't the hardware need replacing to correct the problem? I didn't think software could fix it, but then again I'm no tech expert. Could someone put my mind at ease with this? I have the phone coming from the UK as we speak, don't want to have to send it back immediately.
[Samsung Galaxy Nexus] agormog:
As I understand it is NOT only when your phone is using the 900MHz band.

You can see this in the bootloader example. The phone likely isn't using ANY radio there but it is affected.

So if someone is using 900MHz near you, you've got a problem.
[Samsung Galaxy Nexus] escrivel:
So anybody received a GN from a new batch this morning? Any reports regarding the bug?
[Samsung Galaxy Nexus] mnexusaud:
Does anyone know how long it would take to release a software update to correct this problem based on how Samsung/Google attend to problems in the past?

Also I've just purchased the phone from Handtek and it is on its way expect to arrive next week. Would I have to return it immediately after I receive it or can this kind of hardware problem be corrected with a software update?

Call me silly but I don't understand how hardware failures can be solved with software updates - I really dont want to send it back due to the fact that I'd rather not fork out extra shipping costs + I actually need the phone.
[Samsung Galaxy Nexus] atomic_dude:
Yeah, if that someone is your gf that is rubbing her phone against your GN while being on the phone with you while doing 'it' or something like that. Come on now! You really think that a GNwould be affected by your neighbour'sVodafail $56.49 dumb phone?!

I have been running my Defy in 3G mode for the last few days and did not notice a significant shortage in battery life. Defy's are notorious for short charges, so don't think the GN will be any worst than this.
[Samsung Galaxy Nexus] andygw:
And here's the exact reason I've been so confused, 2 polar opposite responses back to back haha. The latter is the impression I had gotten though, that other devices nearby running on 900MHz will trigger the problem, even if your own Nexus is on a different frequency. If it was only on your phone, I wouldn't be too concerned by it personally, as I'd very rarely (if ever) have to deal with the issue. However if other devices affect it, then yeah that's gonna cause problems.

I can understand that, however I've been using an iPhone running on 3G for the last 2 years so I'm more than used to crappy battery life, haha. Sometimes I'll take 3G off to give it longer life, but not often.

And as it's likely a hardware issue, that's my concern as well. I can't imagine a software fix would do anything other than mask and slightly reduce the problem, whereas a hardware fix is what would be really needed. And that's just gonna vastly increase wait-time on our orders...

I'm very seriously considering just getting the GSII instead and getting ICS when it's released for that phone. I've already sent a ticket in to Handtec with advice on what to do if I wish to cancel my Nexus order and get the SII instead.
[Samsung Galaxy Nexus] dg1qkt:
What about this second tinfoil aproach mentioned some pages earlier (upper side of battery near volumne buttons) did anybody try that?
[Samsung Galaxy Nexus] andrew.k:
http://xdaforums.com/showthread.php?t=1359286 a couple of positive answers already there. Which probably means the whole batch is infected.
[Samsung Galaxy Nexus] Evostance:
`

Yup me. Didnt work
[Samsung Galaxy Nexus] Royan:
OT:

OT:

2G=900/1800MHz, 3G=2100Mhz

brgds

Royan
[Samsung Galaxy Nexus] sim_jim:
Google: Galaxy Nexus Volume Bug Is Not Hardware Related - Software Fix Already On The Way

Source
[Samsung Galaxy Nexus] Evostance:
Rubbish. If it was a software issue it wouldn't happen in the bootloader, but it does
[Samsung Galaxy Nexus] Robboftw:
Cheers! :)
[Samsung Galaxy Nexus] sim_jim:
Hopefully its a software issue only .. what we have to do is only wait for the fix i think today only we will get response from samsung .. or google because the shipments on hold i don't think they will keep it for one or two more days on hold.. they will lose a lot of costumers
[Samsung Galaxy Nexus] sim_jim:
im not putting anything my friend i just copied what i saw so everybody knows ..
[Samsung Galaxy Nexus] FISKER_Q:
They did not say it is a fix that will "likely mask the problem", you are putting words in their mouth :rolleyes:
[Samsung Galaxy Nexus] Rubu:
Not true. Everybody keeps saying that it's a hardware fault, but we simply don't know that. Simply looking at the issues at hand here, a hardware fault seems the most likely option. However, we don't know that. There are situations possible where a software bug makes this also occur in the bootloader; it's not definite proof of a hardware bug.

Also, Samsung being experienced at building phones, I find it hard to believe that an error of this magnitude would really slip through their (hopefully extensive) testing.
[Samsung Galaxy Nexus] noobdeagle:
dont phones also go through RF testing ?, i find it hard to believe they wouldnt stumble across it during this kind of testing however im probably wrong and lets face it while companies are still run by humans errors are bound to happen

solution ? KILL ALL HUMANS!
[Samsung Galaxy Nexus] Duddyroar:
I find it very hard to believe as well, especially given the evidence we've unearthed in this thread. If the volume rocker is triggered by external 900MHz signals, how can they solve this issue save for disabling the volume rocker entirely?

I feel sorry for Google a little bit, they're having to deal with an issue that Samsung has created and Samsung remain totally silent. No doubt we'll hear absolutely nothing back from them now, they'll just leave it for Google to sort out.
[Samsung Galaxy Nexus] appelflap:
I think the whole hardware / software related discussion is obsolete. The boundary isn't that clear cut. With new technologies software can't be set up to listen to a exactly defined subset of hardware. The relation is probably more "coherentistic" and not "foundationalistic". Its a many to many relation that needs to be coherent. Classical deductive logic can't be used anymore for these complex systems. So if the fix is hardware related or software related isn't important. Important is that the whole system functions coherently.
[Samsung Galaxy Nexus] davej777:
Unfortunately, there aren't really any good software fixes for this.

You can try and filter the button presses - you could then end up with situations where you hit the button quickly and it thinks it is just interference, or where the interference just happens to closely imitate a real button press and the volume goes down. Either way, the constant interrupts may prevent the phone from correctly sleeping and could cause poor battery life.

The alternative is to completely disable the input pins, resulting in dead volume buttons. No battery life issues, but you would need to use a widget or app to change the volume.

A hardware fix could be as simple as changing (or installing) a resistor or capacitor. Unfortunately, any hardware changes could take quite some time (and be a massive inconvenience).

So who would prefer possibly-temperamental volume buttons over non-functional volume buttons?
[Samsung Galaxy Nexus] pienut:
I ordered from Handtec...

I am afraid though to allow them to ship my phone since my provider in Belgium (Proximus) uses 900Mhz for 2G and also has 900Mhz (+1800Mhz) on 3G ...

I'm afraid I would be properly f*cked because of the 900mhz usage on 3G networks as well here :-)

And I'm also a little skeptical about a software fix for this issue...

Unless it could be fixed firmware/radio wise...

I'm no Samsung Engineer, can't conclude how they (or Google) messed up and are going to solve it :-)

Seeing Samsung & Google are 2 big companies (A company's primary goal is to make profit), they will just "patch" up things and hope everybody will remain silent about this "feature" afterwards.
[Samsung Galaxy Nexus] StuMcBill:
Correct me if I am wrong, but once this fix has been applied, we will still be able to look at the logs to see if the "ghost" button presses are being registered by the device, but just being ignored unless the rocker is held down for +/- 100ms as a coolbho3000 said?
[Samsung Galaxy Nexus] davej777:
This sounds a lot like software debouncing.

The problem is that the button is not bouncing - a "bouncing" button eventually enters a steady state (usually within 20ms). The interference in this case is continuous - it can happen continuously for several seconds. 100ms is not long enough - it is entirely possible that the button will randomly happen to be "down" at this instant.
[Samsung Galaxy Nexus] coolbho3000:
If you fix it on the lowest level possible in the kernel and do it efficiently, nothing should log to logcat, and there should be just the tiniest minimal performance impact. If you fix it on the firmware level, it would be completely transparent to the user.

I mention that. It's very similar to software debouncing.

But... We listen for the volume down released interrupt, too. The on/off oscillations seem to be happening at a much greater frequency than 10Hz.

If we get a volume down pressed interrupt and 100 milliseconds later the volume down button is still held, then register it BUT if we get a volume down released interrupt in the meantime, then we know it's from interference. Yes, it could be held at both instants and happen to randomly be down 100ms later - but if there was no volume down released interrupt between our two measurements, then we are sure the button was held down between them.
[Samsung Galaxy Nexus] Alexander T.:
Yes, that's exactly what I was thinking over. Samsung engineers might have just accidentally misconfigured the port parameters, e.g. forgotten the pullups.
[Samsung Galaxy Nexus] sethyx:
What if the user presses the button "in the meantime"?

How can the driver detect a user-press, when it is bouncing because of the RF interference?
[Samsung Galaxy Nexus] coolbho3000:
Every time we get a volume down pressed interrupt, we repeat this process. So if the user presses the volume down switch in the meantime, we ignore the original volume down pressed signal, and start calculating from the last volume down pressed signal (actuated by the user).

But, you say, wouldn't we continue to get interrupts from interference as the 900MHz signal continues while the user is holding the button? I don't think so.

When the volume down button is held by the user, the switch is constantly at an "on" position and interference cannot change that (rapidly inducting an "on" signal in a switch when it's already on results in the switch continuing to be on), so we get no further interrupts in the kernel other than the original pressed and released interrupts. If this interval is >= 100ms, then we register the keypress because we assume it's from the user (the signal doesn't seem to be capable of holding down the switch for that long). Otherwise, we do not.
[Samsung Galaxy Nexus] tamcy:
There is no relationship between "It's a hardware flaw" and "It can be fixed with software". A software/firmware fixable issue does not imply the issue is not due to a hardware flaw, so I am sorry to say that the title of Android Police is misleading.

OK I know there is no definite answer from Google/Samsung about whether this is a hardware/software issue. But let's ASSUME that the volume bug is really caused by hardware, i.e. due to insufficient shielding. Can Google issue a fix? Definitely. As some member had said, Google can fix it by detecting and ignoring the unreasonably frequent "button pressing" triggers because an ordinary man can't press a button so many times in a second.

But is it a "fix" to the issue? It depends on how you look at it. For a normal user , it is definitely "fixed" if it no longer bothers the user by some mysterious volume change alerts. But in a design perspective you can say no because the cause (insufficient shielding) is still there and they are just hiding the problem. Key presses are still registered and passed to the CPU. The implication is that it lowers the performance (CPU cycles wasted to process those wrongly triggered key presses) and affects battery life (CPU cycle = battery).

Yes we still don't know (or Google/Samsung still didn't acknowledge) the cause. But I personally would say it a "software issue" if the fix from Google stops the sensor from generating any incorrect button pressing trigger. If Google just hides the problem, I would say it is still a hardware issue, but workaround by some software trick.

Personally I still hope that it is a pure software issue because I want to get the phone as early as possible. But is "hardware issue hidden via software workaround" unacceptable? Well it again depends on your view. Just think CPU. AFAIK every new generation of Intel CPU has a list of design flaw (or errata) that can impact performance and may need software workaround. Some of those errata are fixed at the hardware side with new stepping. Can you say that Intel should not retail those early stepping CPUs? I think not. Of course the Galaxy Nexus case is a bit different, but still I personally accept software workaround, provided that the impact on battery/performance is now drastic.
[Samsung Galaxy Nexus] davej777:
Unfortunately the testing may be modular.

Chipset manufacturers probably test the radio in isolation. If radio proves to be producing the correct emissions and functioning properly (on every band), then it passes.

Once the radio is installed in a device, it is (generally) no longer necessary to test it on every band.

If you very carefully time every event, it might be possible. It would be nice if someone could produce a log of all the interrupt events during an "episode" in order to assess the feasibility of this. This may require a custom driver to be loaded which replaces the default interrupt handler.

That would be wonderful if that turned out to be the issue. With a rooted device it may be fairly easy to adjust the pin configuration and see what happens.
[Samsung Galaxy Nexus] Alexander T.:
Are you sure the drivers are not in binary format? Is there anybody with rooted Nexus to try this? Just curious if this theory works out.:)

I tend to think its just a silly lost pullup problem, since the engineering version didn't have this bug, and the latter was the one which has taken each and every test from crash to RF-proof and found OK. But the mass-production device is checked against defects in declared functionality only.

I do believe that the pre-released and mass production devices differ only in terms of SW, but not HW. So, the mass version could have a newer version driver with the misconfigured port. My 5 cents...
[Samsung Galaxy Nexus] coolbho3000:
Yes, that would be easy. I would try it and even try to write a fix, but unfortunately, I don't have anything in my house that could possibly generate a 900MHz signal.

I think my "pseudo-debouncing" solution wouldn't even require careful timing. (Google's engineers are smarter than I am and have probably come up with an even better solution)
[Samsung Galaxy Nexus] eXtremeXJ:
There is no way Samsung are going to recall devices to ship out fixed units, no time and expense, they will just either rely on the "software fix" or make changes to the current manufacturing process silently and a proper solution will filter out.

This phone is going to cost me 800+ over its contract term, i expect it to be at least usable for voice calls.
[Samsung Galaxy Nexus] sethyx:
I agree on that.

But I'm talking about the opposite version. Interference is present, it keeps the interrupt for itself for 50ms, which means if the user presses the button in that 50ms, it won't recognize the press.

As we can see from the logs and the videos, the button gets the interrupts really frequently, so it can happen.

(Not trolling, just want to clearly understand your idea.)
[Samsung Galaxy Nexus] inoplanet:
Guys,

I'm looking forward to my GN,i hope they release it soon in Germany.

But this volume issue it seems will have a fix,this i great.It's no use to argue before the fix if it's sw or hw...we'll see after the fix is released if it still affects the phone in bootloader mode then your phone is just patched,not fixed.

If the phone isn't affected in bootloader then from my point of view it's 100% fixed and will probably not affect me or bother me.It will be like nothing ever happened(that's because right now i dont even have it).
[Samsung Galaxy Nexus] davej777:
It does make one wonder - how many hardware problems in consumer electronics are "hidden" by last-minute patches?
[Samsung Galaxy Nexus] oscillik:
For all those people who are saying that you can force the phone into

3G only mode

- I have some news for you -

It doesn't stick.

Try it yourself.

1. Go to the phone application

2. Hit *#*#4636#*#*

3. Select Phone Information

4. Scroll down until you find Set preferred network type

5. Change it to WDCDMA only (or indeed anything other than GSM/CDMA Auto PRL)

6.

Now reboot your phone

It doesn't stay persistent.

As to all the blog sites and tech news sites that are running with the notion that this isn't a hardware related issue, that is extremely disingenuous - All that Google have said is the following:

Google have said nothing to contradict reports and claims that this is a hardware defect, yet the tech sites/blogs are still putting 1 and 1 together and getting 15
[Samsung Galaxy Nexus] :
@oscillik

notwithstanding the overall issue, the CDMA only actually sticks on my GN even after 10 reboots.

Just make sure you "exit" the Phone information display prior to rebooting, that "forces" it.
[Samsung Galaxy Nexus] coolbho3000:
Okay, let's go through a scenario.

Say interference causes an interrupt for "volume down pressed" to register and "volume up pressed" to register every 50 milliseconds (just as an example - it probably oscillates much faster than this).

Scenario 1:

We get a fake "volume down pressed" at t = 0 ms from the 900MHz interference.

At t = 40 ms, the user presses the volume down key.

At t = 50 ms, the 900MHz interference "lets go" of the key. However, the kernel sees no interrupt since the switch has been on this whole time.

At t = 100ms, the press is registered, 60 ms after the user presses the key.

Scenario 2:

We get a fake "volume down pressed" at t = 0 ms from the 900MHz interference.

At t = 50 ms, the 900MHz interference lets go of the key.

At t = 60 ms, the user presses the volume down key.

At t = 100 ms, the 900MHz interference "presses" the key again. However, the kernel sees no interrupt since the switch has been on this whole time.

At t = 160 ms, the press is registered, 100 ms after the user presses the key.
[Samsung Galaxy Nexus] oscillik:
I have already produced a log of the events that happen, at least twice in this thread now.

Here it is, again, for your convenience

At line 28 I put the phone into 2G mode, and immediately after that you can see multiple buffer overruns.
[Samsung Galaxy Nexus] OJBizzle:
I bought my galaxy nexus sim-free from Phones4U last Saturday. I've not experienced this issue (yet). I just switched my phone into 2G mode and borrowed a colleague's phone which only gets a 2G signal at work and put them next to each other, made a call etc and received no volume switching issue.

I'm no expert in this, so is there any other way I can test whether this affects my particular device or not?
[Samsung Galaxy Nexus] coolbho3000:
Thanks for that log - I actually built my solution on it. :)

From that log, as I gathered before, the period between overflows is in the order of fractions of a second. That means the period between interrupts must be much smaller than that.

No human could do that, so there is a software way to ignore unintended keypresses.

I'm probably going to wait for Google to release something instead of attempt a fix myself, since there's no way for me to test.
[Samsung Galaxy Nexus] bleets:
a huge amount

but then most are actually software/firmware issues.

like with laptops could be driver specific or related to BIOS

although with my Dell laptop at home the BIOS update to fix an issue was blatent do it and hope for the best (nvidia chipset overheats and dies, Dell solution was to release a new BIOS that runs the fan more!)

but anyways, in all devices theres always firmware flashes to fix issues. it's the nature of electronics in general.
[Samsung Galaxy Nexus] appelflap:
Hey, so this actually fixes it for now? Don't have the time to read the whole thread.

Great job if that's true.
[Samsung Galaxy Nexus] sethyx:
Makes sense, thanks pressed! :)
[Samsung Galaxy Nexus] oscillik:
Can you please tell me how one can 'exit' the phone information display? I have exitied the Phone Information display by doing the following:

1. Pressing the home screen from within Phone Information

2. Pressing the multitasking button and swiping the Phone Information screen from the list

I can see no other way of exiting the Phone Information section.
[Samsung Galaxy Nexus] :
I press the back key, that seems to work (for me)
[Samsung Galaxy Nexus] oscillik:
I have already done that.

It does not stay persistent.
[Samsung Galaxy Nexus] :
Weird. Works for me though, just checked (again). I can easily configure and have the settings stick by using the back key to "confirm" the settings.
[Samsung Galaxy Nexus] gregounech:
Change carrier to three, you'll have no issue this way :rolleyes: :D.
[Samsung Galaxy Nexus] oscillik:
Hmmm. I doubt that it is my SIM card that is forcing my phone back into GSM/CDMA Auto PRL since:

1. How does the SIM card even interface with Android to be able to change settings by itself?

2. I have in the past been able to set my Nexus One to WCDMA Preferred, while using this very SIM card.

I'm not understanding why you are able to have the setting stay persistent, whereas I am not.
[Samsung Galaxy Nexus] Duddyroar:
I know someone with a rooted GN. I've sent them a link to this post and will let you know what they say.
[Samsung Galaxy Nexus] davej777:
That is a log of reported phone events - not a log of the actual timings of the individual interrupts. There is not a 1:1 relationship between interrupts and buffer overruns.

What is needed is precise timing (below the millisecond level) of the individual "press" and "release" events (which presumably each trigger an interrupt).

That gives you information like "how long is an interference event vs a real user event?"
[Samsung Galaxy Nexus] oscillik:
Sorry for misunderstanding what you were referring to. As I understand it, not many on this forum would have the equipment necessary to perform such event logging as what you are requesting seems to be extremely low-level and would appear to require specialist equipment that possibly only the manufacturer and handset team at Google would have access to :(
[Samsung Galaxy Nexus] HUNZwiebel:
http://android.hdblog.it/2011/11/23...o-software-lupdate-4-0-2-risolve-il-problema/

They write that Google confirmated the problem, and they will solve this with the 4.0.2. :D
[Samsung Galaxy Nexus] :
can you guys please refrain from quoting some random sites to do with android? there is NO NEWS other than google will issue an OTA patch. Nothing more, nothing less other than what android police wrote.

EDIT: acutally they make assumptions calling it 4.0.2. Nothing confirmed to that matter, might well be 4.0.1.1 or whatever.
[Samsung Galaxy Nexus] kisumx5:
seems like they have fixed the problem.....

androidpolice.com/2011/11/23/google-galaxy-nexus-volume-bug-is-not-hardware-related-software-fix-already-on-the-way