yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy Nexus] mike freegan:
I'm on Three UK. I can tell you that if someone walks by close enough on O2 making a phone call, my phone goes onto silent.

It will be going back this week.
[Samsung Galaxy Nexus] gambiting:
"So the volume bug was fixed and will be out soon..but wtf are people doing using the nexus in a 2g area? Bug doesn't manifest unless in 2g area..so u can all relax."

And I come from a country with a 900MHz UMTS network, but I'm in the UK at the moment, I'll be going home for christmas at the earliest.
[Samsung Galaxy Nexus] Evostance:
He sounds like a complete ****
[Samsung Galaxy Nexus] nyyankees3511:
I quote P3Droid "So the volume bug was fixed and will be out soon..but wtf are people doing using the nexus in a 2g area? Bug doesn't manifest unless in 2g area..so u can all relax."

im not here to judge, hes been on point many, many times.
[Samsung Galaxy Nexus] oscillik:
because I'm sick of repeating myself because people aren't reading this thread and following the information that has been proven thus far.

there are no drivers involved, the problem is literally a matter of physics. electromagnetic interference caused by the 900MHz frequency band that is interfering with the volume rocker switches. this occurs even in bootloader mode where there are no drivers present.

---------- Post added at 12:30 AM ---------- Previous post was at 12:27 AM ----------

if he's been 'on point' many many times, why can he not grasp the simple notion that in the UK many people have to use their Galaxy Nexus in a 2G area by proxy of the fact that not all of the UK has great 3G coverage?

he is wrong. plain and simple.
[Samsung Galaxy Nexus] ShiroEd:
"So the volume bug was fixed and will be out soon..but wtf are people doing using the nexus in a 2g area? Bug doesn'tmanifest unless in 2g area..so u can all relax."

This has got to be the single most stupid thing ive read on the internet in ages!!!
[Samsung Galaxy Nexus] her0n:
I had that one too once upon a time! Used to (ab)use it with my PDA.. bluetooth modem brought internet to my PDA on college break times :)
[Samsung Galaxy Nexus] gambiting:
Oscillik yes, I understand that perfectly. But the 900 GSM standard specifies at least a dozen channels, and this issue might/might not be specific to one of them. 900MHz might be interfering with the volume rocker electronics,but 901MHz might not. And the radio driver always has to choose which channel to use - if they block it from using the one causing the problem - it won't happen again, at least not from the phone's own signal. Does this make sense to you?
[Samsung Galaxy Nexus] oscillik:
it makes perfect sense, but you're simply barking up the wrong tree

changing the internal cellular radio on the Galaxy Nexus to use a different integer of the frequency band (in your example 901MHz instead of 900MHz) will not stop the phone from exhibiting symptoms of RF interference when it comes into close proximity of another phone (or multiple phones in a concentrated area) that happens to be running on straight 900MHz.

get my point?

this phone needs a recall.
[Samsung Galaxy Nexus] juicytuna:
There may not be any radio drivers loaded up but there is certainly software present. How else would it register volume up and down presses?

Anyway, people should post build dates! You can check yours by going into odin mode (volume down and power).
[Samsung Galaxy Nexus] oscillik:
hardware clock, low level hardware access. that's how.
[Samsung Galaxy Nexus] paul_one:
I'm with oscillik here..

People will use the galaxy nexus in any area they see fit/have to use. It's the hardware at fault and not the people who want to use the phone!

gambiting, does it make sense to you to only use your phone on the corner of the street? How about only using it if a traffic light is red?

Now how about using it only if it's not coming into contact with a 900mhz signal (internal or external).

there is NO software fix.
[Samsung Galaxy Nexus] juicytuna:
Yes, in other words firmware which is still software.
[Samsung Galaxy Nexus] gambiting:
I agree completely. But look at it this way - right as it is now, the phone cannot be used in a GSM 900 zone, not at all, it's just broken. But if they update the firmware as I explained, it would have this issue only when in proximity of another phone, and if that phone was placing a call or sending data. So the issue would still exist, but the probability of it occurring would be much lower,and it would save Samsung loads of money. And because of the inverted square power loss of signal, I honestly doubt that any phone that is more than 10cm from the Nexus would interfere, as you can actually see on the video - the phone goes crazy only when the Nexus One is like 1-3cm from it, not any further.
[Samsung Galaxy Nexus] nyyankees3511:
Why dont you relax and let the real engineers figure it out.. this isnt samsungs first phone they manufactured so lets stop guessing and see what they come up with.
[Samsung Galaxy Nexus] gambiting:
Not necessarily, if the pooling method is built into the CPU then it cannot be changed. But it still might be executed differently, so there is some hope.
[Samsung Galaxy Nexus] oscillik:
I have started a new thread to collect Odin data from people who are experiencing the issue

Post your hardware details from Odin Mode if you suffer from SAV
[Samsung Galaxy Nexus] noobdeagle:
exactly this even tho an os is not running there are still basic low level software at play in order for the functions to work even in the bootloader.

also does anyone else think its strange that it only triggers volume down ?
[Samsung Galaxy Nexus] oscillik:
that is not firmware. you are wrong.

---------- Post added at 12:47 AM ---------- Previous post was at 12:46 AM ----------

do you even understand what low-level means? it means "interacting directly with the CPU"

there is not software in play in the bootloader.
[Samsung Galaxy Nexus] Chrono_Tata:
Actually if you do the method by introducing interference from another phone, both buttons are affected. I guess it usually only happens to the down button because the internal interference is happening near there.
[Samsung Galaxy Nexus] jaketurbo:
That IS firmware.
[Samsung Galaxy Nexus] paul_one:
what about the law of wave superposition? many waves combining to amplify the signal?

Given that all things will be moving, its highly likely that you will encounter this happening by walking down the street.

There has been someone post here already saying it has happened to them whilst walking down the street, while they're on a network of 2100mhz.
[Samsung Galaxy Nexus] oscillik:
you are WRONG.
[Samsung Galaxy Nexus] jaketurbo:
Seriously...

A bootloader is a program... written in code.... stored in rom.
[Samsung Galaxy Nexus] juicytuna:
That's wrong. Of course there is 'software' (as in lines of code) in the bootloader. You think the graphical interface we see is all hardwired into the cpu? "Low level" can mean Assembler or another low level language like C has been used to access the hardware directly.

I'm not saying that this isn't a hardware issue or that it can be fixed using software, just correcting you on the fact that there is software in the bootloader. Let's not rule anything out at this stage.
[Samsung Galaxy Nexus] jaketurbo:
What is a bootloader?
[Samsung Galaxy Nexus] gambiting:
I honestly doubt that anything that is further away than few centimeters from the phone can generate enough electricity in the volume rocker's circuits to be registered as a button press. And I agree, there is no software fix, but there MIGHT be a software workaround that will make this completely not noticeable(and there is absolutely no way that you can prove otherwise, as we don't have access to engineering sheets of the Nexus' internals,so we don't know what are the internal mechanisms of the phone's radio). Why do I think this way? Because company like Samsung will go any length to avoid recalls, it's just very very bad for the company's image.
[Samsung Galaxy Nexus] jaketurbo:
Nm... not worth my time.
[Samsung Galaxy Nexus] oscillik:
ok, it's really quite simple - the volume rocker and the power button are akin to a PS/2 keyboard in the sense that the PS/2 keyboards keys are interpreted directly by the CPU with no intermediary software
[Samsung Galaxy Nexus] gambiting:
I disagree. Event like this is very unlikely. Pressing a button creates a short burst of electricity in the circuit, a burst which is too strong to be induced by an electromagnetic field from a several centimeters away and further. When the antenna is so close to the circuits like we have seen and tried - then yes, it is quite possible, and that's what's happening with the Nexus. But the power of the signal diminishes so quickly with the distance that it is close to impossible to happen while just walking down the street. And that was a single person reporting that issue - I am not saying that it's not true,but his/her phone "might" have switched to a 2G network, for a second or two, so they didn't notice that. Unless we get more reports of that it is an unconfirmed event.
[Samsung Galaxy Nexus] mike freegan:
Happened to me before when my mum walked past on the phone, and I'm on the Three network.

I can't help but think that (dare I say it) if this were an Apple handset, we'd have had a PR statement by now to save their reputation, we'd be given a date for a fix (if possible) and they'd be cracking the whip to make sure someone was working on this around the clock to ensure they honour that promise.

Samsung have just stuck their head in the dirt.
[Samsung Galaxy Nexus] jaketurbo:
Other than onboard firmware in the controller, usb bus, a controller etc
[Samsung Galaxy Nexus] oscillik:
PS/2 keyboards do not use the USB bus, nor a controller, nor RAM.

you've just proved that you have no clue what you're talking about.
[Samsung Galaxy Nexus] rodrigojavier:
"You're holding it wrong"
[Samsung Galaxy Nexus] jaketurbo:
For some reason i missed ps2 when reading that.

Bed time...
[Samsung Galaxy Nexus] paul_one:
we've already discussed any 'fix' and the outcome of that.

You'll be lucky if you can get a working phone half the time and both the battery and performance of the phone would greatly deteriorate. also users pressing the volume keys would get ignored.

I can also prove through statistical probability that 'completely not noticable' is an impossibility. something will get noticed from a fault with hardware being influenced by external forces.

for samsung this is *already* very bad. little to none customer feedback, no announcement or acknowledgement, and proof that at least some qa testing hasn't been performed.

it would be far better for samsung to come out saying 'if you have this fault, call us directly, we'll replace your products with our sincere apologies. Then, with the returns, they can re-fit them and refurbish them, gaining that money back... instead of this uncertainty about their product and ddeteriation in their name.
[Samsung Galaxy Nexus] jaketurbo:
:confused:

I read it as ps2 (playstation2) for some reason..

Have fun.
[Samsung Galaxy Nexus] paul_one:
hahaha, I've just been thinking this over in my head all day.
[Samsung Galaxy Nexus] gambiting:
I'm very sorry to prove you wrong, but PS/2 keyboards do have microcontrolers. They convert the key presses into clock signals that go through the cable. It also governs LEDs for the lock keys and accepts the commands from the computer.
[Samsung Galaxy Nexus] oscillik:
ok...so it has a microcontroller. still hardware.

and my point in referencing the PS/2 keyboard was to highlight that the data from the volume rocker and power key is interpreted directly by the CPU.
[Samsung Galaxy Nexus] paul_one:
clock signals? do you mean ascii signals?

its these signals he's talking about. these 'bits' get sent and are interpreted by the cpu/hardware directly. then passed to the 'firmware' (bios/bootloader/os).
[Samsung Galaxy Nexus] gambiting:
Clock as in analogue signals, which are interpreted by their length and pooled at a specific interval, therefore it is said that the microntroler generates a clock signal. And these microcontrolers do have some software on it. Very basic, very low level assembler, but they still run code. Not that it helps with our specific case, as this code is so low-level that it cannot be changed, but I just wanted to prove a point.
[Samsung Galaxy Nexus] paul_one:
oh wow, I didn't know that the keyboard used a clock before. its just like a mini IDE cable!

I would argue its not software. its how the chips work. the actual construction of the chips, the gates, etc, force it to act a certain way. software/firmware is not this. it is a series of bits/bytes which are commands interpreted on a programmabkl chip.
[Samsung Galaxy Nexus] JonyEpsilon:
Hmmmmmmm :-)
[Samsung Galaxy Nexus] gambiting:
http://www.computer-engineering.org/ps2protocol/

Do I still need to explain what the Clock Line is for and what the Clock Signal is? Just read the spec.
[Samsung Galaxy Nexus] phazerorg:
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.
[Samsung Galaxy Nexus] oscillik:
thank you for expanding upon, and corroborating my point. muchly appreciated. (i'd give thanks but i've hit my limit today :( )
[Samsung Galaxy Nexus] MikeyMike01:
If this is in fact a hardware problem and leads to a recall or is just ignored, then this is much worse than antennagate.

Wow.
[Samsung Galaxy Nexus] atomic_dude:
So could we stop dribbling now and stay on topic, please? I could always wiki on the low level programming subject... Every time there's a new post here I hope to read there's a cure for the bloody volume bug... Please don't play with our emotions like that :-)
[Samsung Galaxy Nexus] oscillik:
if you've been following this thread, then you would know by now that the only cure for this volume 'bug' is to get a replacement handset that is a different hardware revision that does not suffer from this hardware defect
[Samsung Galaxy Nexus] paul_one:
I read the spec.. I'm missing the part which is aimed at my response (which acknowledges the clock, but argues hardware function over the word 'software').

I would also like to thank you on expanding that very clearly (I've also run out).
[Samsung Galaxy Nexus] nyyankees3511:
Could it be the rfi shield was simply not installed at the factory? I remember when i took apart a G2x the shield was simply snapped on and off.
[Samsung Galaxy Nexus] Chirality:
How does a CPU know what to do with a volume rocker input?

All the CPU knows about are IO buses and memory buses. A signal from the volume rocker triggers a CPU interrupt on the IO bus. The CPU then looks up a table in memory for the appropriate OS routine to handle this interrupt. In bootloader mode, the OS routine is a small program loaded from the bootloader ROM into main memory. The CPU then executes a jump instruction to that memory address, and starts executing the OS routine for handling volume rocker input.

The CPU has no idea how to deal with various IO events. It handles them by jumping to the appropriate instruction in memory. The instructions in memory are, by definition, software. The software can be from various sources. Normally it's kernel code loaded up from the system ROM. In bootloader mode it's code loaded from the bootloader firmware ROM.
[Samsung Galaxy Nexus] oscillik:
exactly my point - all it knows is that the button is being 'pressed'

except in this case, the button isn't really being pressed, but is being interfered with by the RF interference.

so as far as the CPU is concerned, the volume buttons are being pressed in rapid succession.
[Samsung Galaxy Nexus] blunden:
Apart from the IMEI number and serial number, what numbers are listed behind the battery? The N1 had a batch number there. It was of interest back in the early days of release when some devices had problems with the adhesive used to glue the glass for the screen on. Maybe we can compare those on the ones with the problem to the ones from the new shipment. :)

EDIT: Too bad we don't have a teardown to look at yet.
[Samsung Galaxy Nexus] Chirality:
All the CPU knows is that something is generating a lot of hardware interrupts.

This can't be fixed with software but can be ameliorated by software. Rapidly generating hardware interrupts might slow down the system a bit, but if the handler for the interrupt takes no action, it's possibly invisible to the user. So you can imagine that the issue can be mostly hidden from the user if the interrupt handler for this particular event just does nothing. But what if the user actually wants to use the volume rocker? Well, depending on how the button controllers are implemented this could be resolved too. If the button controller is sending additional information along with each IO event, for example duration of the event, then the event handler can look at the duration, filter out low duration events that are likely triggered by the hardware fault, and only execute volume control code for long duration events which are likely triggered by the user. Assuming all this can be done, then this problem can largely be addressed by software. This obviously doesn't address the underlying issue at all. But what it's doing is using software to compensate for underlying hardware imperfections, which is not uncommon. In fact there are probably other places in this phone where hardware behavior is imperfect and software routines are used to filter out noise, deal with crosstalk, or use various heuristics to determine correct action, etc. So don't just assume that this can only be fixed by adding EMI shielding etc. It's quite possible that Samsung will try to address it with software compensation.
[Samsung Galaxy Nexus] oscillik:
ahhh it's finally clicked, what you've been trying to get across now.

Wouldn't that cause extra battery drain and cause slowdown of the phone though? The point is - the phone shouldn't have been released in this state in the first place.
[Samsung Galaxy Nexus] Chirality:
Yes, this isn't ideal, the phone would have better performance if it the hardware were built better. But the thing is...if Samsung had shipped the phone with firmware that already does this sort of thing, we might have never known that there was a problem with the EMI shielding, and just take its performance as it is. We would never know that the phone could perform better if they build the hardware better. Who knows what else is going on in the phone that we don't know about that are being compensated for at the firmware level...
[Samsung Galaxy Nexus] oscillik:
then it definitely shouldn't be referred to as a 'fix' then, as it is more like papering over the cracks...
[Samsung Galaxy Nexus] Chirality:
Yep. But even in fully working devices, there's likely a lot of "papering over the cracks" anyhow. Just the reality of engineering stuff so intricate and complex. For example RAM bits would sometimes randomly flip due to exposure to radiation, and you have to use various algorithms to detect when a bit has flipped. It works most of the time, but when it doesn't...bad stuff happens.
[Samsung Galaxy Nexus] paul_one:
the cost to performance would be a lot, seeing as it would have to constantly jump out of current calculations, store its registers, jump over to the interrupt handler, do the logic there, then load back in the old registers before continuing. ordering of instructions is half the reason software is as fast as it is. so time isn't wasted swapping data in and out of registers waste fully.

plus I'd prefer not to have a 4hr battery (constant 1.2ghz) and what would effectively be an over priced hand warmer... although it is the weather for it.
[Samsung Galaxy Nexus] Chirality:
Having two cores helps a bit, if you can keep the other core idle and doing nothing but the OS routine for handling volume changes, haha.

Too bad ARM doesn't have HyperThreading...

(I jest, I jest...)
[Samsung Galaxy Nexus] paul_one:
hahaha, when will arm learn?

:-)

*edit*

I'm off to bed. just wanna congratulate all those who've participated here so far (esp those I've clicked thanks to).

Its good that you've narrowed it down this far, and no matter what we speculate, we have to now wait, possibly gathering as much as we can to try and tell the hardware batches apart.

night all.
[Samsung Galaxy Nexus] dnlsmy:
Apparently the problem has been "fixed" by Google and Samsung with an update.

P3Droid reports it has been fixed and he's supposedly running the new version, 4.0.2.

And now I'm one of very few people who is running Android 4.0.2.....Can't wait to see how this runs

EDIT: It seems the 4.0.2 update is for the LTE Nexus not the GSM version. He still states it HAS been fixed via software though.

So the volume bug was fixed and will be out soon..but wtf are people doing using the nexus in a 2g area? Bu… (cont) http://t.co/0qnXHqxW
[Samsung Galaxy Nexus] Tom Servo:
Eh. I hope we can track interrupt rates in rooted phones. I don't trust this yet, and it could simply be filtering based on event frequency.
[Samsung Galaxy Nexus] samizad:
Can you provide a link please?

The issue can not be "fixed" by an updated version of Android because this is not an Android issue. At the very least, it requires a firmware update - not an Android update.

In any case, it's hard to believe that Samsung have learned of the bug, built a new firmware version and had it loaded onto all their unshipped stock in 3 days, all without making a single comment of acknowledgement about the issue.
[Samsung Galaxy Nexus] dnlsmy:
Please re-read the above post, I've edited it.

Post: http://xdaforums.com/showpost.php?p=19580549&postcount=573
[Samsung Galaxy Nexus] shehriih:
Samsung is busy marketing for the Note !!!

i ordered one from clove and i hope it wont have this problem.
[Samsung Galaxy Nexus] escrivel:
Sorry...but once again: Is there now a hotfix out there from google?
[Samsung Galaxy Nexus] malliktajmahal:
Does the bug fixed

Hi I want to order it from India. Can you please confirm once you receive ur GS whether the bug is fixed or not. Thank you.
[Samsung Galaxy Nexus] Duddyroar:
Got mine from the local Three store. I'm the guy who posted the video that was linked to earlier.

Issue post on Google Android board: http://code.google.com/p/android/issues/detail?id=22021
[Samsung Galaxy Nexus] chrisjaffe:
Got mine in Norwich and having this issue. I was on the train going in and out of 3g when it was happening.
[Samsung Galaxy Nexus] budda:
Volume mute fault with handset from O2 Widnes

Got the Galaxy NExus today from the O2 Widnes branch. Noticed the problem as soon as I got back home and was browsing the Android market and installing apps.

Assumed i was griping handset wrongly but this thread has assured me otherwise.

The 3G/2G radio signal sounds plausible as the network coverage is patchy in my house.

I've cast my vote in the poll too.