Re: Understanding accelerometer data

2009-11-01 Thread Nelson Castillo
I would recommend the python script for easy testing: http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval It's certainly possible that I've just written my program wrong.  So yes, I'll try that script too. Here I print a direction vector (ignoring Z). It goes from 0 to 100 (instead of

Re: Understanding accelerometer data

2009-11-01 Thread Neil Jerram
2009/11/1 Nelson Castillo arhu...@freaks-unidos.net: Here I print a direction vector (ignoring Z). It goes from 0 to 100 (instead of 0.0 to 1.0) to avoid floating point. It updates rather fast. http://svn.arhuaco.org/svn/src/openmoko/accelerometers/dir.c If I only care about this vector I

Re: Understanding accelerometer data

2009-11-01 Thread Nelson Castillo
On Sun, Nov 1, 2009 at 3:27 AM, Neil Jerram neiljer...@googlemail.com wrote: 2009/11/1 Nelson Castillo arhu...@freaks-unidos.net: Here I print a direction vector (ignoring Z). It goes from 0 to 100 (instead of 0.0 to 1.0) to avoid floating point. It updates rather fast.

Re: Understanding accelerometer data

2009-11-01 Thread Nelson Castillo
I remember that some time ago I wrote a module to check this and Python attempted a read of 32K in my PC! No matter how many bytes I was trying to read. This could be the cause if you are already experienced this. In this weblog post I just read that we have to use non-blocking I/O to avoid

Re: Understanding accelerometer data

2009-10-30 Thread Neil Jerram
2009/10/30 Neil Jerram neiljer...@googlemail.com: OK, I understand what was wrong with my program now.  It was reopening the /dev/input/event[2,3] file before every read. [...] FWIW, I've now added my corrected program (in Guile Scheme) to

Understanding accelerometer data

2009-10-29 Thread Neil Jerram
I'm struggling to understand my accelerometer data. Here's what I see, opening and reading the /dev/input/event[2,3] files every 4 seconds, when my FR is flat on its back on the table. (event2 -36 54 198)(event3 -72 108 234) (event2 -36 54 198)(event3 -72 90 234) (event2 -36 54 198)(event3 -72

Re: Understanding accelerometer data

2009-10-29 Thread Robin Paulson
2009/10/30 Neil Jerram neiljer...@googlemail.com: I'd expect the x and y values to be much smaller than the z values (compared to the ratios here) because of the z value including gravity.  Am I misunderstanding what the data is telling me? yes. acceleration is change of velocity. if there is

Re: Understanding accelerometer data

2009-10-29 Thread Michael Tansella
Am Donnerstag, 29. Oktober 2009 23:16:53 schrieb Robin Paulson: 2009/10/30 Neil Jerram neiljer...@googlemail.com: I'd expect the x and y values to be much smaller than the z values (compared to the ratios here) because of the z value including gravity. Am I misunderstanding what the data

Re: Understanding accelerometer data

2009-10-29 Thread rixed
yes. acceleration is change of velocity. if there is no change in velocity, there will be no acceleration. hence, if the phone is still, all acc values should be zero. gravity or not, there is no net acc on the phone. i don't know the format the accelerometers output data in, but i'd take a

Re: Understanding accelerometer data

2009-10-29 Thread Neil Jerram
2009/10/29 Michael Tansella michael-tanse...@gmx.de: If the Freerunner is not moving (x^2+y^2+z^2)^(1/2) must be g. The values of the freerunner are in mg so it must be 1000. Your values are really strange. Do the x values never change? Not never, but they do seem reluctant to change. For

Re: Understanding accelerometer data

2009-10-29 Thread Neil Jerram
2009/10/29 Neil Jerram neiljer...@googlemail.com: It's certainly possible that I've just written my program wrong.  So yes, I'll try that script too. OK, I understand what was wrong with my program now. It was reopening the /dev/input/event[2,3] file before every read. It appears that the