[JOM]

Greetings,

http://jouni.miettunen.googlepages.com/sensoranalyzer

Version History

* 1.1 2008-05-08 Visualize raw sensor data. Bars idea based on Aapo Rista modified verlet.py
* 1.0 2008-05-07 Based on Sensor Sample + debug code to see raw sensor data

Tested with pyS60 1.4.3 in N82.

Sample Code

* Not worth much as sample code, but a quick and dirty tool to help figuring out what the raw Sensor API data means. Now I know
* Debug code is included, but beware: it generates a HUGE file on your phone. By default I turn debugging off before uploading the file.
* This is 1/3 of the "final" application, but just wanted to get it out right now. It's already pretty useful as is. Final version should be even better!

Sensor Analyzer

See what kind of raw data Sensor API gives you, when you move the device.

First bar is data_1 (RED), second bar is data_2 (GREEN) and third bar is data_3 (BLUE). At top you see max value for each data and at bottom min value. Bottom row shows current value for each.

The bars scale automatically, which might be confusing, but keeps all data on-screen and everything comparable between each others. Scaling is shown at left side somehow. The numbers are all-time max/min values, but scaling is actually based on absolute max value, to keep data on-screen.

You can reset the max/min limits by pressing select key.

Uses cases:

* Try to document Sensor API
* Experiment with movement related algorithms
* Search for limits

Usage - Keyboard shortcuts:

1 - Toggle data channel 1 on/off
2 - Toggle data channel 2 on/off
3 - Toggle data channel 3 on/off
Enter - Reset collected data, start again
# - Save a screen snapshot on disk

Enjoy,

--jouni on lunchbreak

[aaaaapo]

Originally Posted by JOM

http://jouni.miettunen.googlepages.com/sensoranalyzer
Sensor Analyzer

See what kind of raw data Sensor API gives you, when you move the device.

First bar is data_1 (RED), second bar is data_2 (GREEN) and third bar is data_3 (BLUE). At top you see max value for each data and at bottom min value. Bottom row shows current value for each.

One suggestion: change the bar orientation so that they show the tilt direction. E.g.

• if the phone is laying on the table, bar 1 and 2 both have zero value
• if you tilt the phone to the left (lift up the right edge), bar 2 grows to the left also
• if you lift up the phones top, bar 1 grows to the bottom of the screen

Bar 3 is a bit different, so I think it's better to take the 1st bar and think about bar 3 a bit more... Perhaps some kind of growing and shrinking square?

[JOM]

Originally Posted by aaaaapo

One suggestion: change the bar orientation so that they show the tilt direction. E.g.

I'm thinking about displaying some vectors, that should do it.. Just have to figure out a 3D -> 2D conversion first.

Originally Posted by aaaaapo

• if the phone is laying on the table, bar 1 and 2 both have zero value
• if you tilt the phone to the left (lift up the right edge), bar 2 grows to the left also
• if you lift up the phones top, bar 1 grows to the bottom of the screen

Bar 3 is a bit different, so I think it's better to take the 1st bar and think about bar 3 a bit more... Perhaps some kind of growing and shrinking square?

Hmph, that analyzer just presents RAW DATA as it comes from Sensor API. No modifucations, no calculations, nothing at all. I believe you're now few steps ahead of me and thinking about actual gesture detection!

This is the meaning of bars, which nicely identifies the sensor positioning:

• Bar 1: Phone is standing vertically on table, red bar goes down (negative data_1 values). Turn upsidedown, red bar goes up (positive data_1 values). Values are close to zero, when device is lying on it's side or on it's back.
• Bar 2: Phone is lying horizontally on table on right side, green bar goes down (negative data_2 values). Turn on left side, green bar goes up (positive data_2 values). Values are close to zero, when device is standing vertically or lying on it's back.
• Bar 3: Phone is lying horizontally on table on back, blue bar goes down (negative data_3 values). Turn face downwards, blue bar goes up (positive data_3 values). Values are close to zero, when device is standing vertically or lying on it's side.

Btw the values nicely tell that earth gravity is about value 300. There seems to be some bug in the script, which now block the max/min values exactly at 680. Last night the best values were at about 1200 == maybe I was waving my hand at 4G force, but that's just a guess. I have no idea whether sensor data is linear or not!

Cheers,

--jouni

[JOM]

Greetings,

http://jouni.miettunen.googlepages.com/sensoranalyzer

Version 1.2:
- View sensor data as bars
- View sensor data as vectors
- View sensor data as dot graph
- Zoom the scale between 120 - 1200
- Change view with left and right arrow keys
- Reset collected data with zero number key (0)

Press 1, 2 and 3 to disable/enable related data channels.

Enjoy,

--jouni

[aaaaapo]

Originally Posted by JOM

Version 1.2:
- View sensor data as bars
- View sensor data as vectors
- View sensor data as dot graph
- Zoom the scale between 120 - 1200
- Change view with left and right arrow keys
- Reset collected data with zero number key (0)

Hey cool! Vector mode is quite concrete.

Feature requests for 1.3 :-)

- G-sense meter (I still don't know how to convert those xyz-values to G-sense value)
- "weightless" timer: tells how many seconds the phone was in free fall, e.g. thrown up (and then caught, of course :-)

[JOM]

Originally Posted by aaaaapo

Feature requests for 1.3 :-)

...actually I was thinking about to look at LBS next. There is a "Forum Nokia Code Camp: Location-Based Services, May 27, Barcelona, Spain", which I'm planning to visit. Have to generate some ideas and questions before that

Originally Posted by aaaaapo

• G-sense meter (I still don't know how to convert those xyz-values to G-sense value)
• "weightless" timer: tells how many seconds the phone was in free fall, e.g. thrown up (and then caught, of course :-)

G-metering should be easy: if 1G is about 300 then 2G would be 600 I'll try to add that to next version somehow.

Free-fall is something I won't be testing! 200 km/h going towards hard ground doesn't sound like healthy! Anyway the technical problem here is sensor noise level, would have to investigate that a bit.

Cheers,

--jouni

[aaaaapo]

Originally Posted by JOM

Anyway the technical problem here is sensor noise level, would have to investigate that a bit.

How about using the average of e.g. 5 last measurements?

I got yesterday Nokia 5500 sport for testing and it has even more noise in sensor data than in my N82.

BTW: the screen size in 5500 is 208x208 so sensor analyzer GUI doesn't fit that very well. Actually none of my own GUIs don't either...

PS. I'd like to have a cup of coffee and exchange thoughts of location based services, pys60 etc. with you some day.

--
Aapo Rista

[JOM]

Originally Posted by aaaaapo

How about using the average of e.g. 5 last measurements?

Argh, now my head is full of ideas how to improve the analyzer! Guess I'll have to make one more big upgrade, both UI and features. Some day.

Originally Posted by aaaaapo

I got yesterday Nokia 5500 sport for testing and it has even more noise in sensor data than in my N82.

That's got Tapping sensor!!! Would you please test my Sensor Sample to verify that tapping code actually works! It's never tested, should work.

Originally Posted by aaaaapo

BTW: the screen size in 5500 is 208x208 so sensor analyzer GUI doesn't fit that very well. Actually none of my own GUIs don't either...

Uh, I was waiting for this and hoping nobody would notice Some parts are hardcoded for 240x320, some parts are automatically scaling. Added on todo list...

Originally Posted by aaaaapo

PS. I'd like to have a cup of coffee and exchange thoughts of location based services, pys60 etc. with you some day.

Your profile says you don't accept emails... Well, I come to Helsinki occasionally for Mobile Monday or Arctic Startup event. We could try those?

Btw you have really nice photo LBS websites. Also found your pys60 GPS, could use a little UI update

Cheers,

--jouni

[aaaaapo]

Originally Posted by JOM

Your profile says you don't accept emails...

Yours too. :-) Mine should accept email from now on.

Originally Posted by JOM

Well, I come to Helsinki occasionally for Mobile Monday or Arctic Startup event. We could try those?

Okay, Mobile Monday Helsinki, June 2 at 18. I'll try to find you and I won't, I'll call/send sms.

[michaelangel0]

hi

a g-sense meter is just a norm: square root the sum of axis value squares: sqrt(x.x+y.y+z.z)

i'm interested in a sensor summary table: which phones have which sensors?
also i'm not sure the rotation sensor is what it says it is... isn't it rather a rotation acceleration sensor?
as in: axis value=0 when constant sped or still about that axis, and !=0 if rotation speed changes.

can you help with these issues?

thanks

[JOM]

Originally Posted by michaelangel0

i'm interested in a sensor summary table: which phones have which sensors?

This is more or less uptodate:
http://wiki.forum.nokia.com/index.php/Nokia_Sensor_APIs

Originally Posted by michaelangel0

also i'm not sure the rotation sensor is what it says it is... isn't it rather a rotation acceleration sensor?
as in: axis value=0 when constant sped or still about that axis, and !=0 if rotation speed changes.

Well, as far as I understood it really was telling when rotation happens. Turn the device around enough and then API tells you that device orientation is now something. Speed had nothing to do with it, if I recall right. I believe it's using internal filter to check real-time sensor data.

Anyway, the good thing is that the APIs are public! Anyone can use them and check out what happens

Cheers,

--jouni

[apacheking]

jouni bro does it works for 5800