Bugzilla – Bug 9104
Ambient light sensor hw variance
Last modified: 2009-09-08 09:14:32 UTC
I did a ambient light sensor comparison on three of my PQP3 boards (actually they read MPQ). It looks like there is some variance in the hardware. It also looks like the board I am using for development (the one with jtag connector) returns the highest values of the three boards. Firmware 26 contains the formula from the datasheet but the constants are multiplied by 100. Integration time is 408ms and gain is 16x. In a fairly lit room the three boards read the following values: 4800, 4500, 4100 Closed room, no sunlight, one 100W light bulb: 2700 (122) 2300 (115), 2900 (90) Closed dark room, two LCD monitors: 41 (14), 8 (0), 11 (0) Closed dark room, one LCD: 15 (0), 0 (0), 0 (0) The values in brackets are with the dyed dark lens. I also played a bit with longer integration times, but the result was that the one board with jtag gave higher values than before (which is what I expected), but on the other two boards even integrating for about 5 seconds still resulted in 0 (which I guess isn't too surprising as if there is nothing, counting that for a longer time still gets you nothing). Another thing I realized is the fact that the light sensor is very directional, i.e. tilting the board a bit to the left/right or up/down can change the resulting number quite a bit. And to make things worse the lens seems to reflect the display light into the light sensor too. And I think you are right, at the lower levels the formula from the datasheet doesn't work very well, especially with our dark lens. Do you think the variance I am seeing is just what we have to expect from the light sensor or do you think we are using it wrong or that it got somehow damaged during manufacturing on some of the boards? Did you do a test with more than one board? If yes, are you also seeing significantly different values for the same condition? Did you have a chance to analyze the two raw channel values?
Response from Caleb: I have not done any meaningful comparative testing from board to board. I would expect that they would be closer than what you're seeing. I would expect some variance, but not as much as you're seeing. I have some new untouched MPQ units that I can give it a try with.f I have not done any analysis of the raw 2 channel data yet. Perhaps we can get Rico on this project. It's mr. light calibration dude now.
I think it would be good if you or Rico could also do some comparison with different boards to see if you're findings match mine or not.
I'd be happy to take a look at this once I know where to find the sensed lux values. As I recall in older firmwares it was available either under current settings or in the FCC test menu but I don't see it there anymore..
Found it under factory test. duh. Quick note without even disassembling this boom: The value will range anywhere from 850 to 1900 by simply spinning it around on the desk in my cube.
The ambient light sensor has two channels, one measuring visible and infrared light and the other measuring infrared light only. A formula, taken from the datasheet, combines the two values to the value you see in the factory test - ambient light menu. The formula is taken as it is, but the constants are multiplied by 100 to get a better reading. Please talk to Caleb, he can tell you how to retrieve the two raw channel values. I also see the effect you are describing when tilting the units, the values can change quite a bit as the ambient light sensor is very directional. My main concern however is to find a good formula in low light situations that works across different units. BTW: Make sure you are using Booms that are using the newer of the two Taos ambient light sensors (TSL2569) which is more sensitive. You see that in the factory test - ambient light menu. The first value is the PARTNO and should read 'b'. If it reads '1' you got the older less sensitive sensor (TSL2561). Also, even though the formula says 'lux', the values are not calibrated at all. You find the datasheet in here: https://svn.slimdevices.com/repos/player/trunk/hardware
I've finished getting data from some MPQ booms and here are my very unscientific results: Overhead fluorescent on: lux_boom1: ~1050 lux_boom2: ~ 975 lux_boom3: ~1200 ch0_boom1: ~2050 ch0_boom2: ~2000 ch0_boom3: ~2350 ch1_boom1: ~ 480 ch1_boom2: ~ 545 ch1_boom3: ~ 595 Overhead lights off, door open: lux_boom1: 86 lux_boom2: 50 lux_boom3: 61 ch0_boom1: 124 ch0_boom2: 112 ch0_boom3: 124 ch1_boom1: 8 ch1_boom2: 34 ch1_boom3: 32 Lights off, door closed, very dark: lux_boom1: 3 lux_boom2: 0 lux_boom3: 5 ch0_boom1: 5 ch0_boom2: 1 ch0_boom3: 7 ch1_boom1: 0 ch1_boom2: 2 ch1_boom3: 0 Cell phone pointed towards front panel: lux_boom1: 13 lux_boom2: 6 lux_boom3: 13 ch0_boom1: 18 ch0_boom2: 17 ch0_boom3: 19 ch1_boom1: 0 ch1_boom2: 6 ch1_boom3: 1 So there is some variance, hard to say whether it is due to difference in the sensor/lens or the spot on the table the boom was sitting, or ? It seems to me we can simply adjust the sensitivity of display response in a low light environment. I poked around for where the cutoffs are for the five different brightness levels but it wasn't obvious to me where these settings are.
Check out app/drivers/vfd_16032.c - vfd2_brightness() (near the bottom of the file). The display brightness and gray scales are composed of five parameters: vfd_filament_voltage, vfd_filament_power, bk_time, gcp1_time and gcp2_time. In the second part of the function you'll see a switch/case statement where the regular (non ambient light sensor) brightness levels are composed. In the first part of the function you'll find how the five parameters are calculated from the ambient light sensor value b. b is first converted into bk_time and the other four values are then calculated from bk_time. To become more familiar with the display brightness and gray scales and these parameters (and how they influence each other), you probably want to try the vfd tester that can be built using a define (BUILD_VFD_TESTER) in app/squeeze.h. Caleb has put up a wiki page describing how to use a regular remote to change the five parameters.
They are about to start reworking the pop units in the back. Perhaps of we are very careful, we could use some of those to get a very good sample of unit to unit variation.
Created attachment 3814 [details] light sensor data from 15 booms Factory fresh POP booms, brightness fixed to max, protective lens film _not_ peeled off. Sheet3 has the results. Yellow :overhead fluorescents on Light gray:lights off, door open to hallway with fluorescents Dark gray :lights off, door closed (very dark) Light blue:lights off, bright white cell phone lcd
QA to verify it LOOKS good under these conditions.
Ping QA!
I did some tests and came up with similar results to Rico. The screen was visible in all brightnesses, although it was too dim at the lower end of the scale. Dean's direction is that it should not 'illuminate the room' i.e. overpower the ambient light. I tested three MP units, one PB3 (mpq) and one PB1 (just to see) One of the MP units, though, had an odd problem. It first showed up as an anomalously high number in 0 light. (anywhere between 32 and 106) I turned the brightness back up and the number returned to the normal range. As I slowly reduced the incandescent brightness the number decreased to 24, then began rising again (as high as 106, in pitch blackness (according to my eyes)). It seems possible there was a bright infrared source in the room that I wasn't able to see, but it only affected one unit from my testing. I will send this unit to Felix per Dean's instructions.
Chris: I've added some description about what the various numbers in the ambient light sensor test mean to bug 9287. When you say it's still too dark at the lower end I would need to know if in that condition the light sensor value 'nnn' is still zero or already above zero. If it is still zero then only increasing the offset would help, you could try that by pressing '2' on an old remote. If it is above zero then either increasing the offset helps, or dependent on the lightsensor value you could decrease the divisor (button '7'). We could then use your findings, i.e. good values for the divisor and offset and change that in SC/SN.
I've looked at the unit Chris sent me and found exactly what Chris has found that the value the light sensor reports is very different (much higher) in a complete dark room than the Boom I used to calibrate the formula currently in firmware. Comparing the two sensors in the two Booms without lens in a complete dark room it takes about 4 layers of black tape (on top of the sensor) to get one sensor to report '0', whereas the other (also with 4 layers of black tape) still reports around '100'. (Actually I was not able to get the value to '0' at all by adding more layers.) I removed the lens to rule out reflections from the display via lens to the sensor. There might still be a direct influence from the display to the sensor, but I'd expect that would be the same on both units. My current guess is that there might be an issue how the sensors get initialized, causing them not to operate in the mode we expect or an that the sensor hardware actually differs that much in low light conditions.
We should get this unit to TAOS for failure analysis. It could be a bad part from the vendor, or it could have been damaged during SMT or some other part of the process. Felix, you're in MV this week, right?
I've included a fix (rev 4874, either for SC 7.2.1 or 7.3) for some 'if' conditions in the ALS formula to make them the same as in the datasheet formula. (I initially omitted some 'if' conditions to save space, but it turned out to be inaccurate in some corner conditions.) This should help reducing the issue where different values are seen on different units in low light conditions (i.e. bug 9353 display to bright for bedside use). However Caleb and myself have seen cases (in MV's dark room) where the ALS value would not go down to '0' (even with this fix) because of the display feeding back into the ALS either direct or indirect via lens. I still believe we need a better formula / lookup table to make the ALS work better in all conditions and to compensate for unwanted feedback from the display.
I didn't test it by taking the lens off to see if it still had high readings. That would likely indicate if the spurious reading was due to reflected light from the VFD. I'm searching for another such unit but i haven't found one yet.
Felix, is this in the latest 7.2.1 or 7.3 firmwares? There's a large message board thread about Boom being too bright in dark rooms. Should we suggest some of those users test the new fw? Or are there other changes you're working on as well?
The code changes are checked into fw trunk, ready for SC 7.2.1 and/or 7.3, but no new fw has been released since I've checked them in. So, no, it's not in the latest fw. The code changes only correct the implementation of the formula from the datasheet in fw which might help the issue somewhat. But as stated before, Caleb and myself saw cases where the display still wouldn't go all the way down to '0' in a dark room due to (self-)feedback and/or reflections from the display. It has been decided that as soon as Caleb gets the proper measurement tools he would further look into the ALS / display brightness issue. I am currently not working on it. BTW: The unit you've sent to me (see comment #12) is now in Caleb's hands. Well, not the complete unit, but the main board. (MAC: 1E:46:AD)
But these changes should be in the FW QA is currently testing for 7.2.1?
yes, they are
We'll leave 9353 open to continue the discussion of how bright is too bright.
Verified with SqueezeCenter Version: 7.2.1 - 23502
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.