Two major issues with the Nexus 5 ambient light sensor

Search This thread

Palmadores

Member
Mar 10, 2013
31
39
London
1. The sensor reading often jumps to 30000lx momentarily, (measured using Lux Dash in Debug mode), and so the phone blinds you for while. This happens in a repeatable fashion when you hold the phone at certain angles. Try it yourself.

2. The N5 reads zero lux even in moderate/dim light, while my old N4 still reads around 10 lux. The N4 was much better as you could make a distinction between the dim light and no light at all.
On the new N5 you have to set the zero lux level so it's bright enought for moderate light, which means it's far too bright at night.

Why is the N5 sensor so poor? Or is the kernel? Really, this is pretty basic stuff. Come on Google, we want the autobrightness to work fine without having to download apps to try and fix the most basic settings.

(As per other threads, the N5 stock autobrightness is almost unusable!)
 

t2002

Member
Nov 6, 2013
28
0
Same here. Only occurs in the kitchen under the spotlights. I've had 2 phones and the same has happened on both using lux.

Sent from my Nexus 5 using Tapatalk
 

heliostatic

New member
Nov 23, 2013
1
0
I had some dead pixels on my first N5, so I got a replacement. The replacement is now exhibiting this weird sensor issue (also spiking up to 30,000lux based on device orientation).
 

Kusie

Senior Member
Aug 25, 2011
235
41
I have the same issue on my N5, sudden freak peaks of 15000 lux or more, then suddenly back to normal values of 50-80. Same behavior on stock kernel and Francos Kernel.
Hoping for a quick fix by Google.
Kusie
 

Aria807

Senior Member
Dec 31, 2010
648
93
Dallas
I'm having the same issue too, but it appears to be under certain lightbulbs that I have this issue. For example in 2 different situations, one I was in a restaurant and another while I was in my bathroom, and my phone would constantly pick up either 0 lux or 30000 lux (depending on the angle of the phone under the light). This is under halogen lighting.

When I get out of the restaurant and under regular lighting and when I'm in my bedroom (LED/CCFL lights), the light sensor would behave normally.

Anyone else have these issues?
 

coolguy949

Senior Member
Nov 4, 2008
294
51
Orange County, CA
Can the sensor be calibrated or is it just bad hardware? This is a real annoyance. My S4 doesn't read 0 lux unless there is absolutely zero and it never jumps around. Even it's own screen reflecting on my face will cause it to read 1-10. That level of sensitivity is great for setting up lux to go subzero. Maybe the kernel is translating the sensor voltage output incorrectly?


Sent from my Nexus 5 using xda app-developers app
 

Aerowinder

Senior Member
Aug 11, 2012
3,322
1,329
Yes, and it's not really reproduceable for me but it's very annoying and sometimes painful. This screen can get very bright and it's blinded me in the dark when this happens.

Is it the light sensor? Is it LUX? Does this happen without lux installed?

Lux is a measurement of brightness.
 

Aria807

Senior Member
Dec 31, 2010
648
93
Dallas
I thought it was Lux causing it, but I have tried full wipe + reflashing a new rom, and my sensors still go a lil whack. This is flashing new rom + immediately downloading a sensor tool and checking the readings before installing Lux or any other apps.

However, Lux came out with a new version a week or so ago and it seems to have been waiving those spiked readings, so my phone atm isn't acting up super dim to super bright and back.
 
  • Like
Reactions: Aerowinder

Kusie

Senior Member
Aug 25, 2011
235
41
I still have this issue on 4.2.2.,very annoying. Is this a software issue or bad sensors?
Starts to piss me off so badly I think about sending my N5 back to google.

Happens both on stock auto brightness and yaab.

Help please?
Kusie
 

exorz

Member
Nov 26, 2008
34
2
I have this same problem too. Using the Lux app debug mode I rotated the phone while in a room lit with incandescent bulbs and one lit with daylight. When rotating the phone I sometimes see a spike of 30000 lx but more importantly the sensor drops to 0 even though there is plenty of ambient light. During daylight I don't see the 30000 lx spikes but I still see the sensor dropping to 0 when there's plenty of ambient light.

I feel like the sensor is too far recessed into the phone and causing a tunnel effect. If the phone is looking at a dark shirt or surface that's a foot away from it, it will register 0 even though there's plenty of ambient light. This seems like a design flaw or a flaw in android's API.

Using the full version of Lux app might be able to fix it since it allows you to use the camera for ambient light detection but I haven't purchased the full app yet so I don't know.

Really wish android would have a solution for this because it's quite irritating.
 

exorz

Member
Nov 26, 2008
34
2
Are you guys using the Lux app? I haven't had this problem with stock auto brightness.

With the stock auto brightness it was too bright in most cases and also in some cases the brightness would spike. Downloaded the free version of lux app in order to try to fix the problem and while it can adjust the brightness to be lower, the problem is that the light sensor gives low readings straight from the api.
 

Xharos

Senior Member
Dec 27, 2010
251
31
Canary Islands
I just installed Lux and I can't reproduce it on my Nexus. Mine always behaves correctly in automatic brightness, so I guess it's a hardware problem that only affects some devices?
 

n3ocort3x

Senior Member
May 10, 2012
5,862
10,822
Vienna
I jump now in here as i have the same problem unfortunatley. I have no clue if its hardware related or software, but on my HTC One with kitkat running the same rom i dont have such issues s i guess its a HW fault. If anyone finds a solution or something that fixes this mess, would highly appreciate if wwe could keep this thread alive :)
 

coolguy949

Senior Member
Nov 4, 2008
294
51
Orange County, CA
I hope it's just a kernel issue where it's not translating the sensor output to the OS granularly enough. On my S4, it has to be truly zero light for it to see 0lx. Even in low low light, it's registering a value between 1 and 100. It makes it very easy to distinguish between no light (laying in bed) and low light (driving in the car, movie theater, etc). I hope they fix it because it's rather annoying that we're having this issue.
 

n3ocort3x

Senior Member
May 10, 2012
5,862
10,822
Vienna
I hope it's just a kernel issue where it's not translating the sensor output to the OS granularly enough. On my S4, it has to be truly zero light for it to see 0lx. Even in low low light, it's registering a value between 1 and 100. It makes it very easy to distinguish between no light (laying in bed) and low light (driving in the car, movie theater, etc). I hope they fix it because it's rather annoying that we're having this issue.

The next interesting thing is that it happens only in 1 out of 6 rooms at home. I hope I'm not totally crazy but could it be a bad combination between a sort of light bulb and the sensor?? I know this sounds totally stupid but I only can reproduce it with one light bulb. Or it is because that one light bulb is really low dimmed. I have to test that further tomorrow. Only have one dimmable light bulb atm to test so I will dim the others tomorrow that working atm.

noNeedforAsig
 

coolguy949

Senior Member
Nov 4, 2008
294
51
Orange County, CA
The next interesting thing is that it happens only in 1 out of 6 rooms at home. I hope I'm not totally crazy but could it be a bad combination between a sort of light bulb and the sensor?? I know this sounds totally stupid but I only can reproduce it with one light bulb. Or it is because that one light bulb is really low dimmed. I have to test that further tomorrow. Only have one dimmable light bulb atm to test so I will dim the others tomorrow that working atm.

noNeedforAsig

I remember reading something weeks ago that the sensor doesn't work well with certain bulbs. I can't seem to locate the thread though.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 5
    Is there anyone who has an experience of debugging native android services and reverse-engineering ARM binaries?

    I finally gave up trying to debug native code with no sources available and switched to a more high level workaround.

    What I've basically done is a filter at a point where native HAL communicates to android framework. It intercepts all sensor readings and replaces abnormal 30k lux (and 0 lux following 30k) with an averaged value from a sliding window. This affects any process that use android sensors interface including system_process, so that default android auto-brightness now works fine too.

    Code:
    04-03 23:17:48.436: V/LightSensorFilter(871): fixup bogus high: 19.685715lux
    04-03 23:17:49.036: V/LightSensorFilter(871): fixup bogus high: 24.08449lux
    04-03 23:17:50.136: V/LightSensorFilter(871): fixup bogus low:  15.469254lux
    04-03 23:17:57.286: V/LightSensorFilter(871): fixup bogus high: 28.414286lux

    Working proof-of-concept is implemented using Xposed framework and available on my github: https://github.com/abusalimov/XposedHammerheadLightSensorFix.

    I run stock Android with a custom kernel, so I didn't try to apply this fix directly to ROM, though some parts of code would be a bit more straight-forward in that case. In fact I got my very first android phone just few weeks ago, so I didn't research popular custom ROMs yet. Probably one day I'll choose one and switch to it so that I could pull my changes there and try them without using Xposed hacks.
    http://forum.xda-developers.com/showpost.php?p=51694977&postcount=8
    3
    This should be the sensor driver, even though I'm not 100% sure:
    /kernel/lge/hammerhead/drivers/misc/apds993x.c
    https://android.googlesource.com/ke...hammerhead-3.4-kk-fr2/drivers/misc/apds993x.c
    https://github.com/android/kernel_m...erhead-3.4-kitkat-mr1/drivers/misc/apds993x.c

    1. The sensor reading often jumps to 30000lx momentarily, (measured using Lux Dash in Debug mode), and so the phone blinds you for while. This happens in a repeatable fashion when you hold the phone at certain angles. Try it yourself.
    Code:
    	if (ch0data >= apds993x_als_res_tb[data->als_atime_index] ||
    	    ch1data >= apds993x_als_res_tb[data->als_atime_index]) {
    		luxValue = 30*1000;
    		return luxValue;
    	}

    30*1000 ==> 30k !

    2. The N5 reads zero lux even in moderate/dim light, while my old N4 still reads around 10 lux. The N4 was much better as you could make a distinction between the dim light and no light at all.
    On the new N5 you have to set the zero lux level so it's bright enought for moderate light, which means it's far too bright at night.

    this issue is really bad.

    The whole calculation method is this:
    Code:
    static int LuxCalculation(struct i2c_client *client, int ch0data, int ch1data)
    {
    	struct apds993x_data *data = i2c_get_clientdata(client);
    	int luxValue=0;
    	int IAC1=0;
    	int IAC2=0;
    	int IAC=0;
    
    	if (ch0data >= apds993x_als_res_tb[data->als_atime_index] ||
    	    ch1data >= apds993x_als_res_tb[data->als_atime_index]) {
    		luxValue = 30*1000;
    		return luxValue;
    	}
    
    	/* re-adjust COE_B to avoid 2 decimal point */
    	IAC1 = (ch0data - (apds993x_coe_b * ch1data) / 100);
    	/* re-adjust COE_C and COE_D to void 2 decimal point */
    	IAC2 = ((apds993x_coe_c * ch0data) / 100 -
    			(apds993x_coe_d * ch1data) / 100);
    
    	if (IAC1 > IAC2)
    		IAC = IAC1;
    	else if (IAC1 <= IAC2)
    		IAC = IAC2;
    	else
    		IAC = 0;
    
    	if (IAC1 < 0 && IAC2 < 0) {
    		IAC = 0;	/* cdata and irdata saturated */
    		return -1; 	/* don't report first, change gain may help */
    	}
    
    	if (data->als_reduce) {
    		luxValue = ((IAC * apds993x_ga * APDS993X_DF) / 100) * 65 / 10 /
    			((apds993x_als_integration_tb[data->als_atime_index] /
    			  100) * apds993x_als_again_tb[data->als_again_index]);
    	} else {
    		luxValue = ((IAC * apds993x_ga * APDS993X_DF) /100) /
    			((apds993x_als_integration_tb[data->als_atime_index] /
    			  100) * apds993x_als_again_tb[data->als_again_index]);
    	}
    
    	return luxValue;
    }

    I hope some of the custom kernel dev should fix this bad behavior if not fixed by google.
    2
    1. The sensor reading often jumps to 30000lx momentarily, (measured using Lux Dash in Debug mode), and so the phone blinds you for while. This happens in a repeatable fashion when you hold the phone at certain angles. Try it yourself.

    2. The N5 reads zero lux even in moderate/dim light, while my old N4 still reads around 10 lux. The N4 was much better as you could make a distinction between the dim light and no light at all.
    On the new N5 you have to set the zero lux level so it's bright enought for moderate light, which means it's far too bright at night.

    Why is the N5 sensor so poor? Or is the kernel? Really, this is pretty basic stuff. Come on Google, we want the autobrightness to work fine without having to download apps to try and fix the most basic settings.

    (As per other threads, the N5 stock autobrightness is almost unusable!)
    2
    This should be the sensor driver, even though I'm not 100% sure:
    /kernel/lge/hammerhead/drivers/misc/apds993x.c
    ...
    I hope some of the custom kernel dev should fix this bad behavior if not fixed by google.

    Unfortunately it seems that this kernel driver was superseded by proprietary libraries in user space (probably sensors.qcom and friends from vendor_qcom_hammerhead) few month before release. I tried just to enable the driver in configs and device-tree, but then kernel simply refuses to start (reboots after few seconds after showing "google" splash). However I didn't try to revert rest of the kernel to the moment when the driver used to be enabled. Most likely one would have to revert HAL too in this case, so I'm rather pessimistic about this idea.

    I also tried to attach to a running sensors.qcom (it is registered as a service in init.hammerhead.rc) using gdb (gdserver on the device + adb tcp forwarding), but with no success. For some reasons it always suspends on the same instruction and refuses to step over/out. In fact, I'm not sure that is the right binary at all, because all sensors remain working even when the process is suspended. The problem is that no source nor debug symbols are available for the binary. However, arm-eabi-strings reveals some plausible messages inside the binary (I2C communication, ALS lux conversion, proximity change events, etc.). Maybe I have some misunderstanding on how android services work.

    Hope this will help to more lucky and experienced hackers. =)

    P.S. I'm not allowed to post links, here is some related info.

    Commits switching to qcom driver:
    • device/lge/hammerhead/+/4e858dde1463a7cbdb4e2489cfa9f7002cb73dc2 on android.googlesource dot com
    • android/kernel_msm/commit/50ee8cb3b8a29cf20514f8606439fa4e2893383d on github
    Vendor binaries:
    • jamesonwilliams/vendor_qcom_hammerhead on github
    2
    Recently I installed Gravitybox and adjusted the brightness levels. Before that I experienced the jumps in brightness as well. Since the adjustments no more strange behavior.

    Even my battery lasts longer due to lower brightness!

    Sent from my Nexus 5 using xda app-developers app

    I can edit the brightness curve on my ROM but... the issue here is that a total darkness is 0lux on the N5 sensor... and a 50-70lux (real) is still 0lux on N5 light sensor! So you can change the brightness at 0lux, but this can't fix the brightness behavior because the light sensor doesn't change its value while the light vary from 0 to 50-70lux.

    :eek:

    anyone can compare the N5 lux reading values with other smartphone models?

    for example:
    DesireS 5lux <==> N5 0lux

    or
    DesireS 72lux <==> N5 5lux


    It seems google is taking a lot of time to fix this issue.
Our Apps
Get our official app!
The best way to access XDA on your phone
Nav Gestures
Add swipe gestures to any Android
One Handed Mode
Eases uses one hand with your phone