Please pardon me if someone has already address this question - could not find a closely related response for sure.
Does anyone know if the Nexus One is using any other devices for ALS (ambient light sense) and Proximity detection - other than the Capella CM_3602?
In looking at the android 2.2 source, the driver code seems to set up the Prox (by assigning pin direction and IRQ association) but didn't seem to do much with the ALS.
Is ALS being done in some other area?
It would seem that ALS would require some computation to return proper Lux values.
At first I was under the impression that such a device would require initialization of various registers for configuring the device (via I2C ?), but according to the cm3602 data sheet, there is no I2C!
Configured a kernel to use I2C/dev (to look for any other light sensor devices) and only bus i2c-0 seems to be present. Is that correct - only 1 I2C bus in use?
Is there somewhere else I should be looking?
Thank you for your kind attention.
jbrenner said:
Please pardon me if someone has already address this question - could not find a closely related response for sure.
Does anyone know if the Nexus One is using any other devices for ALS (ambient light sense) and Proximity detection - other than the Capella CM_3602?
In looking at the android 2.2 source, the driver code seems to set up the Prox (by assigning pin direction and IRQ association) but didn't seem to do much with the ALS.
Is ALS being done in some other area?
It would seem that ALS would require some computation to return proper Lux values.
At first I was under the impression that such a device would require initialization of various registers for configuring the device (via I2C ?), but according to the cm3602 data sheet, there is no I2C!
Configured a kernel to use I2C/dev (to look for any other light sensor devices) and only bus i2c-0 seems to be present. Is that correct - only 1 I2C bus in use?
Is there somewhere else I should be looking?
Thank you for your kind attention.
Click to expand...
Click to collapse
AFAIK the nexus only uses that one capella cm3602 sensor as both a light sensor and proximity sensor....
I don't know too much about the driver side code, but there is only the one sensor and it is on the i2c bus.... the light sensor code might be called from another area... but again I'm not sure....
Good question, but I'm not quite sure if this is the right location to be posting it.... what were you looking to do with the light sensors?
Sent from my Nexus One
ALS and Prox sensor
Wow - thank you for your quick response and again I am sorry if this isn't the correct place to post the question. Please tell me is there is a more appropriate location and where that would be. I don’t want to ruffle any feathers.
I am looking to see if there is a way to find the cause and correct the issues others (including myself) have been experiencing (such as unexpected / annoying changes in display brightness, etc.). Also suspicious of dropped calls being related to prox – although probably the carrier.
Mostly though, I would like to help / contribute to the overall improvement and enjoyment for users of the Nexus One.
Without schematics and limited information (data brief vs. data sheets), it is a challenge.
You have mentioned there is only one sensor and it's on the I2C bus. Is it then the cm3602? And if so, I would guess that some of the pins on the device double as SCL and SDA - is that correct? Do you know which ones?
Any help would be appreciated!
Thank you again.
OK [Question answered] - the Capella cm_3602 device DOES NOT HAVE i2c capability.
The ALS data is a prop. voltage fed out of a pin. It's sensitivity is determined by a fixed resistor.
The analog out is provided/controlled internal to the device.
The Proximity is fixed and an interrupt is provided via another /pin.
Thus there isn't much one can do to improve the prox detection range and the user must simply live with the ALS.
It would have been nice if a 'programable' device had been used, thus it would have been capable of being calibrated.
Related
Hi all, Im a noob here and this is my very first post.
Just got a samsung galaxy s (Irish version, i9000) after upgrading from a htc legend. Amazing phone and very impressed with it.
My question is does it have a gyroscope and what apps are there to use it?
I want to map an underground carpark that has no gps or data signal so the phone would have to log the path it takes by using the accelerometer and gyro (if it has one). If the app could output the data to a log file that would be amazing but I think im asking too much!
It has magnetic compass, and x,y,z accelerometers. Best thing to do is give it a proper try (some people commented that the compass in some older firmwares was a bit off though).
I don't believe there are any gyro's but Gyro's probably need recalibration every so often anyway (internal or otherwise). If you hold the phone a constant way (flat), I'd imagine there should be sufficient information to be accurate (because you know that Z axis is always 9.8m/s, and any changes in Z from are height
All you can do is test it though..
First: the keyword is inertial navigation (search on wikipedia).
Sorry, but I have to disappoint you:
It is theoretically possible to do what you want to do by using data from the accelerometer and compass sensors.
However the accuracy of the integrated accelerometer is way too low for this purpose (integration drift).
I would expect about 100m drift after 1min of measurement.
If you still want to try this, i'd recommend to run/drive as fast as you can
Hey guys. I have looked around and can find no info on some of the tabs sensors. From what i understand the chipset is straight out of the galaxy s phones, which is the reason i see the existence of a proximity sensor but dont see any data from it.
Anyone have a clue whether it actually exists?
chipset and sensors are different things....even if the chipset supports a certain type of sensor doesn't mean it should be there if there is no need to be there.
galaxy tab doesn't need a proxy sensor cause you are not going to put it beside your face when calling...
triplex76 said:
chipset and sensors are different things....even if the chipset supports a certain type of sensor doesn't mean it should be there if there is no need to be there.
galaxy tab doesn't need a proxy sensor cause you are not going to put it beside your face when calling...
Click to expand...
Click to collapse
Doesn't need and doesn't have are different things. Point is, if it was stated that the tab has a proximity sensor, where is it?
I'm pretty sure it has one, in the unofficial CM build Technomancer says he fakes i at 10CM
There is no proximity sensor in Galaxy Tab.
My CM7 sensors driver pretends there is one and reports 10CM distance so the Phone app behaves better.
Thanks mate, that's what you said in the last thread back in October, but why do all the sensor pingers see it? Are they checking code rather than hardware?
Also, is there a working, sensitive light meter anywhere for the tabs ambient light sensor? The couple I've tried refuse to work...
There is working light sensor in the Tab. Both my CM7 and Samsung ROMs support it just fine. It has range from 0 to 6000 Lux snapped to one of several levels in the kernel driver. You can actually read it from sys interface.
The proximity sensor in my CM7 sensors driver is just software reporting constant 10cm to the system. The sensors test apps in my CM7 (I uses Sensor Test and Plot http://www.appbrain.com/app/sensor-test-and-plot/com.golborne.android.SensorTest) just reports 10cm from my fake sensor.
I think there is some leftover code in Samsungs sensors driver that may report presence of proximity sensor.
Yep, i use it as well, but my issue is with the three avaliable states the driver seems to report.
I get 5, 22 and 75. Are there only three levels then? And no way to modify them outside the kernel?
I can get up to 6000lux using strong LED flashlight directly on the sensor.
There is another sys device that can read unprocessed data that has values not snapped to 5,22,75 etc... but Samsung's driver uses the snapped device (and so is mine).
This is very annoying... im trying to make an app that needs a proximity sensor to work as intended so the light sensor as well as the sleep mode implementation are really no substitute.
In any case, im sure it will be quite usefull for all tablet owners running 2.2 and up and using a case. I will have a closed beta for xda members by the end of the day, so people can test it over the weekend.
Would you like a shot, mancer?
I don't know what would you do but if I understand why not to use the g-sensor ... just like in samsung omnia...put backwards enable silent courtesy mode.
the proximity sensor will be useful if you use the leather case to close the screen when touches the screen , like ipad 2 and galaxy tab 10.1 V they have proximity sensors , but i noticed that the sensor exists using sensor applications they see it exists but not giving readings
Hi - there is no sensor, the sensor list showing it is just a glitch from the galaxy s motherboards. And the functionality youre describing is already available in my app Killswitch - you can get both the lite and full version from my signature...
ftgg99 said:
Hi - there is no sensor, the sensor list showing it is just a glitch from the galaxy s motherboards. And the functionality youre describing is already available in my app Killswitch - you can get both the lite and full version from my signature...
Click to expand...
Click to collapse
Thanks I already bought it from market and it's great
Sent from my GT-P1000 using XDA App
Great! Im working on an update that will help improve the accuracy of the light sensor functions... been getting some flack for not updating it
Watch this space!
Good afternoon everyone. I do hope I am posting this in the correct forum. I am going to cheat and copy/paste my original G+ post because:
1 - I'm lazy
2 - It has all the information (I believe).
Anyone else have the HTC One (M7) and having an issue with the orientation sensor?
More specifically.... anyone have the HTC One with CM11 and having issues with the orientation sensor?
I use GPS Status and Toolbox on a regular basis. It used to work just fine, but since the 4.4.2 update (assumed timeframe), the compass doesn't work nor does the pitch/roll indicator.
I installed Elixir 2 and it is showing the orientation sensor as being present and functional, but it's not getting any data. Nor is it getting data from:
• Gravity Sensor
• Linear Acceleration Sensor
• Magnetic Field Sensor
• Rotation Vector Sensor
Again, they are all showing as present. I get green bar showing active, but no graph data (which tells me it's not receiving information for those sensors).
Any help would be greatly appreciated.
HTC One
CM11 (currently on a nightly, though I am awaiting a "stable build" update)
4.4.2
I "fixed" the issue.
It was an issue with the CM build. I just went back to a 12/26/13 nightly and it's working.
PS: Off-topic... this 5 minutes between postings for us newbs is ridiculous. I understand the purpose... but 5 minutes is extreme.
Hi!
Our hammerhead currently lacks full support for ambient display in Android L. One+1 has the kernel changes we need already merged(https://github.com/CyanogenMod/andr...mmit/735f665d2f5dd350b92cffae26517ed494760b5f). I checked this patch before - it's not a match to our source, it needs some more merges in video drivers. I was just wondering if anyone on XDA tried to get this working and wanted to share progress and experiences with doze mode on 3.4 msm kernel?
Mike
mikegapinski said:
Hi!
Our hammerhead currently lacks full support for ambient display in Android L. One+1 has the kernel changes we need already merged(https://github.com/CyanogenMod/andr...mmit/735f665d2f5dd350b92cffae26517ed494760b5f). I checked this patch before - it's not a match to our source, it needs some more merges in video drivers. I was just wondering if anyone on XDA tried to get this working and wanted to share progress and experiences with doze mode on 3.4 msm kernel?
Mike
Click to expand...
Click to collapse
but does our panel really supports that mode?, i remember people thinkering with the digitizer to get the double tap to wake like on the g2 (Without bat drain) and they got nowhere
The panel itself works fine, we are missing one feature only - enabling ambient display afer device is picked up, it needs to be ported to our kernel and sensors hal I guess.
We have a IPS LCD display, using Ambient display will suck a lot of battery juice :/
DJBhardwaj said:
We have a IPS LCD display, using Ambient display will suck a lot of battery juice :/
Click to expand...
Click to collapse
IPS doesn't mean its gonna suck battery. Nokia did it on IPS before.
http://allaboutwindowsphone.com/features/item/18191_Nokia_works_a_LCD_miracle-Glan.php
The topic to be discussed here anyway isn't the screen type or its flaws. It is to get sensors to be able to wake the device with ambient display enabled.
akash3656 said:
IPS doesn't mean its gonna suck battery. Nokia did it on IPS before.
http://allaboutwindowsphone.com/features/item/18191_Nokia_works_a_LCD_miracle-Glan.php
The topic to be discussed here anyway isn't the screen type or its flaws. It is to get sensors to be able to wake the device with ambient display enabled.
Click to expand...
Click to collapse
Everyone's got their choice. I had my opinion laid.
how about applying the patch to cm kernel instead of stock, since it uses updated video drivers and such? is a no-go still?
opssemnik said:
how about applying the patch to cm kernel instead of stock, since it uses updated video drivers and such? is a no-go still?
Click to expand...
Click to collapse
It's included in CM12-CAF build, however we still don't have support for waking the screen after the device is picked up.
mikegapinski said:
It's included in CM12-CAF build, however we still don't have support for waking the screen after the device is picked up.
Click to expand...
Click to collapse
If I recall we had the option on some custom roms (4.4.4) to wake the screen when the device was picked up. I think it used the proximity sensor to detect when the device was picked up.
edit- I apologize, I just realized that this was for developers only.
@mikegapinski Any progress on this or is it abandoned? I'm really looking forward to using full ambient display on hammerhead if it's even possible.
Thanks!
You'd need over 750 patches in the graphics subsystem of the kernel before you can start applying relevant doze patches. Plus updated gpu kernel drivers etc etc
We'll have this on an additional nightly CM12 build eventually and it works pretty good. The only drawbacks at the moment are the situation where sometimes the pick-up sensor is triggered and enables the short wake-up effect; this is because we use a sensor blob from bacon. Then, in order to have a reliable pick-up, that always works, I abused the tilt sensor with some fixed parameters, which is wakeup capable. This however leads to a tad too long timespan from actual pick-up to showing the message on the display.
Whatever, take it or leave it.
myfluxi said:
You'd need over 750 patches in the graphics subsystem of the kernel before you can start applying relevant doze patches. Plus updated gpu kernel drivers etc etc
We'll have this on an additional nightly CM12 build eventually and it works pretty good. The only drawbacks at the moment are the situation where sometimes the pick-up sensor is triggered and enables the short wake-up effect; this is because we use a sensor blob from bacon. Then, in order to have a reliable pick-up, that always works, I abused the tilt sensor with some fixed parameters, which is wakeup capable. This however leads to a tad too long timespan from actual pick-up to showing the message on the display.
Whatever, take it or leave it.
Click to expand...
Click to collapse
Is this available fully implemented in any build?
Sent from my Nexus 5 using Tapatalk
akash3656 said:
IPS doesn't mean its gonna suck battery. Nokia did it on IPS before.
http://allaboutwindowsphone.com/features/item/18191_Nokia_works_a_LCD_miracle-Glan.php
The topic to be discussed here anyway isn't the screen type or its flaws. It is to get sensors to be able to wake the device with ambient display enabled.
Click to expand...
Click to collapse
Sorry for reviving this thread, but it IS about the display type. Not the AMOLED vs. LCD part, but if the display module actually incorporates Display Memory - which is a key in low-power Ambient Display options.
What Nokia/MS did is basically using DM with a simple script that moves the content around. It is low power, and as the phone does not need to be awake, power drainage is lowered even further.
Updates are ran by a background service that collects relevant notifications (the 6 lock screen notifications, the big lock screen info + current date/time), and on the exact minute, updates the DM. It results in a less than 1000ms wakelock, and does not keep the device awake.
I highly doubt that many Android phones would come with Display Memory enabled displays - it is simply not worth it financially, and would be mainly useless. So we cannot really reach the whole Nokia-level low power usage, though we can try.
MemoryController said:
Is this available fully implemented in any build?
Click to expand...
Click to collapse
CM 12.x hammerheadcaf
I currently make an XDA application where I need to access the proximity sensor. I need help with information on which methods and data Android uses to access the sensor.
I know values in the SensorManager class show the proximity sensor readout but I am not sure whether this is what Android uses or there are other as well as I am not sure whether I can override these values to be visible to the whole system and to make sure there is no any app, such as the Phone app, which reads data from anywhere else, for example, directly from a hardware register.
Please, be kind to respond with what Android and the Phone app use to read the sensor.
Thanks.
I never played with Proximity Sensors but your post made me curious. Did you see this example?
ttp://androidbite.blogspot.com/2013/05/android-proximity-sensor-example.html
I have seen http://androidbite.blogspot.com/2013/05/android-proximity-sensor-example.html. This is a standard application which uses the proximity sensor as per the OS. I have tried standard ways to access the proximity sensor. They all work fine EXCEPT the most important thing : they cannot disable the proximity sensor when call is made or received. The phone application is very strong and does not seem to play by the standard rules. This is why I have to do something with Xposed. I am not happy to use Xposed also because people are not happy to install Xposed nor do they care to root their phones. However, there is no other way.
This is why I ask for information on data and methods used to access the information of the proximity sensor. Obviously, the lowest the level, the better, I. e. the closer to the HAL and hardware the better but any information is appreciated.