Blaizzen | # 1 | 2010-11-12, 00:43 | Report

Hi!
Not sure if this is a bug relating to Qt mobility or Maemo 5

With reading sensor values through mobility and values through "/sys/class/i2c-adapter/i2c-3/3-001d/coord" I've found the Y and Z values to be inverse (apart from other things). Lying the phone face up, it gives me

Through Qt Mobility: 0.35, 0.35, 9.5
through reading file: 36, -36, -954

Would this be a maemo bug since according to this page, face up should give a positive z value (http://doc.qt.nokia.com/qtmobility-1.0/sensors-api.html).

Additionally why are the values all have different ranges. Qt Mobility on the simulator has -50 to +50, on maemo -10 to +10 while reading the values from that file gives -1000 to +1000. Would other phone models behave similarly (eg would the N8 or N9 have the same ranges as maemo or closer to the simulator)?


I've attached the project i used to test it.

Attached Files

test.zip (4.2 KB, 74 views)

---

Last edited by Blaizzen; 2010-11-12 at 00:45.

tswindell | # 2 | 2010-11-12, 00:52 | Report

Qt is an abstraction layer between the hardware and you app, the file is basically the raw data. So you'd expect them to be different. Qt Mobility is supposed to provide you with a unified interface to the accel data no matter what platform (symbian, maemo, etc). The ranges are as they are, becuase sysfs is generally full of integers, I'm guessing those are 100th/s of a G, where as Qt mobility is probably scaling it to a real value with a bit more friendly meaning for app devs (which should be unified across platforms).

---

Last edited by tswindell; 2010-11-12 at 00:59.

anwar71839 | # 3 | 2010-11-12, 01:00 | Report

This thing is definitely a bug. My accelerometer is acting weird after updating to PR 1.3. Anyway to solve this issue?

tswindell | # 4 | 2010-11-12, 01:03 | Report

How do you mean weird? And he's not reporting a bug, he was enquiring over why the values differ and what he can expect from Qt Mobility APIs across platform. If you have a problem with the accel, can you file a bug report.

Blaizzen | # 5 | 2010-11-12, 01:04 | Report

Makes sense. I just would have assumed it would try to make it more uniform across platforms to ease in development. Guess to port to another platform you'd have to change the maths slightly.

I guess it also answers why the values are inverse, as Qt would probably try to make all phones face up have positive Z values no matter how their accelerometer is placed inside.

thanks

tswindell | # 6 | 2010-11-12, 01:07 | Report

Well, this is the whole reason of Qt Mobility Sensors API, it means you don't have to worry about talking to the hardware directly and can write code once that will work the same on all platforms/devices.

Blaizzen | # 7 | 2010-11-12, 01:11 | Report

So it might still be a bug, only if other devices behave differently.

Also I guess the simulator would need to have the limits changed.

tswindell | # 8 | 2010-11-12, 01:13 | Report

All you need to worry about is the values matching those in the qt docs when using the qt apis, stop thinking about the sysfs interface. :P

The simulator is fine, I'm sure it's possible that some accels can measure 5G

Blaizzen | # 9 | 2010-11-12, 01:20 | Report

lol, fair enough. Thanks for your help.