According to the kernel drivers Nexus S has a "k3g" gyroscope and "kr3dm" accelerometer both of which is produced by ST.
However, I could not find any sensor with the corresponding names in the ST's website. I believe ST just labels its sensors produced for Samsung with different names?
Does anyone know the ST designated real model/part number of these sensors? I need the spec sheets of these sensors.
Try here
Related
Adam accelerometer values Test
I and many other have noticed that the Adams accelerometer is not working as it should. So I ran an app on it called "Accelerometer values" which plots the devices X,Y AND Z values on a panel of graphs. I also ran this on my Droid X with exact same settings, and in the same orientaion.
Using the Droid as a control, of which I know the values are set correctly. I compared to the two. And this is what I found.
Settings in portriate orientation
1."Relative to the control", the adams X & Y axis are swaped. (x is y, y is x)
2. "^", The Y axis on Adam(X on Droid) displays the same numeric value as the control when tilted in the same direction. example Adam 5.0, control 5.0
3. "^", The X axis on Adam(Y on Droid) displays opposite numeric values as the control
when tilted in the same direction. example Adam -5.0, control 5.0
4. "^", The Z axis are the same on both.
Results with settings in landscape orientation are the same.
Hopefully a dev can fix this, but this confirms that the Adams accelerometer is not set properly.
Yes, i meet the same problem when i play any games with accelerometer... hope someone can help to fix it.
Hopefully there will be a way to relay this info to NI.
Perhaps a repost to TINA on NIA or RISHI on NIH
-CC
EDIT: In talking about this in IRC, it was mentioned that it seems the apps are using the values incorrectly, and some apps have been fixed.. So it may not be a Adam issue.
labyrinth Games prooves your points. Adams is using wrong values. Someone please fix this issue.
My point is that weither the device in question is set to run in portrait(phone) or landscape( most tablets) shouldnt nessesitate a change in the way the accelerometer works. Seeing as most apps for android work in portrait and landscape perfectly fine on phones, then why the HELL would one change the accelerometer settings on tablets. Even the Xoom aparently is having this kind of problem, and most other large android tablets.
There has got to be a way to port/change these settings. Maybe isolating what we need from another rom. Unless this is a hardware issue and accelerometer itself is positioned differently or something stupid like that.
the ony way to fix is by settiny ur calibration to the settings u want try diif position and calibrate , see if it works
Sky maps worked wonderfully when I first got my tablet a few months ago. However, flashing custom roms seems to have royally screwed up the tilt sensors (I have tried multiple different roms, nothing seems to address it). Compass is okay, but X and Y axes are reversed (i.e. it pitches when it should roll, and vice versa). This happens in both landscape and portrait.
Anyone run into this before, or have any idea how to proceed?
playing SpeedX 3d the tilt sensors worth great, playing table labyrinth where you have to roll the ball through the maze to reach the other side is totally FUBAR, the sensors are opposite of each other which makes it impossible to plays.
So with my finding it works fine with some games and terrible with others.
I noticed the same issue on the a100.
SoHaunted said:
playing SpeedX 3d the tilt sensors worth great, playing table labyrinth where you have to roll the ball through the maze to reach the other side is totally FUBAR, the sensors are opposite of each other which makes it impossible to plays.
So with my finding it works fine with some games and terrible with others.
Click to expand...
Click to collapse
Admittedly, I haven't tried it with too many other apps, but those that I have are problematic (sky maps and several sensor-reading apps). It's frustrating because it used to work just fine with sky maps.
Which version of HC are y'all using, 3.1 or 3.2.
On 3.2 I'm having no problems at all.
Just wondering?
Check out "GPS Status" app on the market, it has an option to calibrate the pitch and roll sensors, maybe you just need a calibration..
It will also show the actual pitch/roll values which may help.
kiwi_mat said:
Check out "GPS Status" app on the market, it has an option to calibrate the pitch and roll sensors, maybe you just need a calibration..
It will also show the actual pitch/roll values which may help.
Click to expand...
Click to collapse
"A Tilt Labrynth" also has a built in calibration tool as well
If I'm not mistaken, those calibration utilities only affect the program that they're part of - they don't have any effect on global settings.
[Edit: I'm using 3.2 (Taboonay 2.1b), though the problem was also present on several other 3.1 and 3.2 roms]
I'm running Skeye and Mobile Observatory on my A500 and havent noticed any problems at all with the x/y axis' being off. Honestly, I haven't paid that much attention since I also have both programs installed on my phone and mostly use it instead since I can mount it to my scope for push-to guidance. But just locating Polaris and other well known objects seem to be spot-on. May want to try another program and see if that fixes the issue.
fasteddy86 said:
If I'm not mistaken, those calibration utilities only affect the program that they're part of - they don't have any effect on global settings.
[Edit: I'm using 3.2 (Taboonay 2.1b), though the problem was also present on several other 3.1 and 3.2 roms]
Click to expand...
Click to collapse
as that maybe true it would help people figure out of the calibration is off on the tablet. if the calibration is off then we can look into why its happening in stead of what apps are having the issues
Timelord83 said:
as that maybe true it would help people figure out of the calibration is off on the tablet. if the calibration is off then we can look into why its happening in stead of what apps are having the issues
Click to expand...
Click to collapse
Well there's no question that my sensors are off. The only apps that work are those that come bundled with a calibration function. There's a long-standing defect logged with elgoog about the fact that there's no easy way to calibrate, but they've not addressed it yet.
I know some phones come with a calibration function, and others at least have files where one can change the values...
Whenever I search for camera improvements in AOSP, I only find camera apps like lenovo super cam, HTC m9 cam, etc apps. But the thing is that camera apps alone can't improve the image and video quality. Camera apps can just be used to tweek some settings like ISO, contrast, brightness, HDR, and improve user experience. I don't find a noticible improvement between images taken on aosp stock camera app, lenovo, htc, and other AOSP camera mods.
The actual camera improvement lies in Camera HAL and drivers right?
But it is very difficult to write, edit, and test camera drivers.
There are devices with same camera sensor as g2 like
lg g3 (extra: laser auto focus and dual flash)
Moto x 2nd gen (extra: dual flash)
My question is that if the camera quality on those devices are better than our g2,
1. Is it possible to use the camera drivers and hal from those devices while compiling AOSP based roms?
2. Will the camera work as normal or other problems will encounter?
Devs: please take time to answer.
Others: Discussion is encouraged.
If I understand well the problem is that lg camera drivers are closed sources, so it is impossible to use the advanced functions of the sensor.
_____________________________________Read more write less and be smart
siggey said:
If I understand well the problem is that lg camera drivers are closed sources, so it is impossible to use the advanced functions of the sensor.
_____________________________________Read more write less and be smart
Click to expand...
Click to collapse
My question is about including camera drivers from other device sources which have same camera sensor/module while compiling the ROM.
I already asked this question, but didn't get any reply.
Is it possible to import LG framework into AOSP framework?
I'm asking, because I think there is no other way to get high camera image/video quality without LG stock camera app, but without LG framework the app won't work.
I'll introduce myself, I'm working for 2 years as HW and Realtime-Embedded SW engineer. I've designed (board design) Intel, Freescale and communication systems, made HDL design for FPGA with softcore (flexible custom built) micro-controller and I've written some custom cores for controller's interconnect (main inner bus). Of course for my custom cores I've written HAL drivers.
I've introduced myself, because I don't know anything about ROM building, but I'm pretty experienced in a low-level programming. I really want to help to resolve the problem with poor camera functioning.
I assume that the main problem with a camera and not only the camera of AOSP roms, is a very generic/basic framework. HAL drivers are only for the SOC itself. Camera module is not part of the SOC, it's connected to the SOC with I2C bus (control and status read) and LVDS transmitter (RAW sensor's data), so the only drivers needed are I2C and LVDS-IO. The drivers are part of the kernel, and the kernel doesn't know what is a camera, IR blaster and etc., the kernel takes care of CPU, GPU, AXI bus, UART, USB, I2C, LVDS transceivers and etc. The framework takes care of a camera - it includes the functions to control the camera. For example: to read supported resolutions of camera module:
char* camera_read_supported_res()
{
static char resolution_string[256];
if (i2c_write(CAMERA_ADDRESS, REG_ADDRESS, DATA) != 0) throw_exception();
if (i2c_read(CAMERA_ADDRESS, REG_ADDRESS, resolution_string) != 0) throw_exception();
return resolution_string;
}
Each camera module should have some (hundreds) essential registers with the same addresses and functionality, but nobody limits the manufacturers to add more registers to extend the functionality. And that's where the AAA manufacturers do monumental work to make additional features so great, like fast focusing, good low-light image quality and etc. Those manufacturers add additional hardware that require more control registers, and to manipulate them, they add additional functions to the framework. Those functions are just additional I2C_read/write set of function calls with some device specific registers (addresses). Stock camera apps make use of those additional functions, and if they don't exist in the framework, the should crash.
If each android mobile phone has sources of the stock ROM, is there anyway to add their framework to an AOSP framework?
Forgive me if some of my assumptions are incorrect, I've written them by basing on my work experience.
Click to expand...
Click to collapse
vitalik.t said:
I already asked this question, but didn't get any reply.
Click to expand...
Click to collapse
Your post has a lot of difficult things to understand. I'm studying engineering and I have Embedded systems as one of my subjects. I have heard lot of terms u used in the post in ES but still I was guessing a lot of things while reading.
Thanks for replying. You seem to have researched more than I did on the issue.
My question is a lot simpler.
I've checked the sources of the kernel that is published by LG. I was right about the drivers, there are no drivers for external modules. Need to use the camera? Use I2C and Rapid-IO drivers. But LG didn't publish the sources of the framework. And it looks like that Google also not publishing the sources, they do provide you an API.
We need somebody to decompile the framework.
Try the new snapdragon camera in apps and theme selection.
Hi,
Does someone knows what is the path to get readings from this sensors?
I've been looking in /sys but can not seem to find any
best regards
Finger print sensor path would be good as well. Maybe we can port the pixel notification scrolling
Perhaps if you do an strace on the native calibration binary it will tell you what paths the sensors are located on. See for details:
http://forum.xda-developers.com/nexus-6p/help/formatted-nexus-6p-persist-partition-t3453035
http://elinux.org/Android_Tools#strace
"Sensor readout" on the google play store recognizes the 6P sensors, but doesn't show any path information in the app. Dev probably could help with that, or for that matter decompling the app source code if not obfuscated.
Got the phone today, and after setting everything up I did some google cardboard viewing. Not sure if it was bad settings from the QRcode of that particular cardboard, but I kept getting double vision.
After searching on google I came across a post on oneplus one forums, on the oneplus.net website, and scanning that QRcode fixed it for me.
Link is: forums.oneplus.net/threads/fix-oneplus-one-google-cardboard-no-more-double-images
Thanks for sharing. What do you mean double images?
The way google cardboard (and all other aftermarket vr headsets) works, is by splitting your screen in half and then rounding each half into circular shapes to appear like you have full view.
Unfortunately each screen is a different width. Our eyes are at different distances apart and the glass in the headsets are all at different fields of view. This means that if you have the wrong setup, then the vr apps can place the images on the phone too far apart, too close together, or at the wrong angle (circular shape) to match your eyes and headset glass. So, for example, if the two images are too far apart or close together, your eyes can't twist enough and your brain can't combine the images into one. Think of it like crossing your eyes while still seeing distant objects as one. So thus you get double vision.
The provided qr code is nice to have. But depending on your headset, may not work. The best option is to use the link to the vr setup utility and use a computer to adjust the view until you have perfect vision with no eye strain (muscle tension)
Has anyone tried disabling NFC and using a Daydream as Cardboard?
I tried with a cheap eBay vr glasses and it works just fine. No problem at all