Hello Mayeul, list,
On Mon, Mar 19, 2012 at 23:40, Mayeul Kauffmann
mayeul.kauffm...@free.fr wrote:
Hi,
Great, that was fast! Looking forward to see the results of the test
and, hopefully, get something to test integration!
Two requests:
- Please, don't top-post (don't put your reply at the
2012 07:43:55 +0100
To: List for communicating with real GTA04 owners gta04-ow...@goldelico.com
Cc: List for Openmoko community discussion community@lists.openmoko.org
Subject: Re: [Gta04-owner] Advance OpenStreetMap surveying with GTA04? /
accelerometer patch
Hello Mayeul, list,
On Mon, Mar 19
the BMA180 accelerometer.
It should apply to the 3.2-gta04 tree. I have not tested it lately, so
it may just fail. When my flat battery is recharged I can test it too.
The LSM303DLH combines both 3D compass and accelerometer, so is the
HMC5883L usefull for this application?
We planned to use
--- On Sat, 12/25/10, Timo Juhani Lindfors timo.lindf...@iki.fi wrote:
W. B. Kranendonk wankelwan...@yahoo.com writes:
I found it after searching for accelerometer-dump, but (the FR)
Just capture the data on FR but run it on your PC. Like
li...@sauna$ ssh neo cat /dev/accelerometer-top
W. B. Kranendonk wankelwan...@yahoo.com writes:
See attachment.
li...@ginger:~$ accelerometer-dump event4.log | head | cut -d ';' -f2-|tr ';'
' '
x y z
108 36 900
144 36 900
126 36 900
126 36 882
144 36 900
126 36 900
126 18 900
126 36 900
126 36 882
li...@ginger:~$ accelerometer-dump /dev
--- On Sat, 12/25/10, Timo Juhani Lindfors timo.lindf...@iki.fi wrote:
li...@ginger:~$ accelerometer-dump event4.log | head |
cut -d ';' -f2-|tr ';' ' '
x y z
108 36 900
144 36 900
126 36 900
li...@ginger:~$ accelerometer-dump
/dev/accelerometer-top | head | cut -d ';' -f2-|tr ';' ' '
x
W. B. Kranendonk wankelwan...@yahoo.com writes:
Would that mean that (one of) the meter(s) is connected at an angle?
Are they not calibrated in software?
top and bottom accelerometers are oriented differently anyway.
Is the accelerometer-dump standalone, and do you have a binary version
I did a lot of work with my FR on the accelerometers. The output from
the chip is quite noisy. There is a script I wrote in TCL on the
SourceForge web site under the fltkwish project page. It may give you
some ideas about that can be done. In my experience, the results vary
depending on which of
anyway.
Yes, now you say it I recall reading about it. I actually meant: could it be
that it is installed at an incorrect angle, i.e. not perpendicular or paralell
to the case, but slanted.
Is the accelerometer-dump standalone, and do you have
a binary version available?
http://iki.fi/lindi
W. B. Kranendonk wankelwan...@yahoo.com writes:
I found it after searching for accelerometer-dump, but (the FR)
didn't have gcc installed and don't know yet which packages to
install to make it useful. At least a reason now to dive into
figuring that out :-)
Just capture the data on FR
--- On Sat, 12/25/10, Iain B. Findleton ifindle...@videotron.ca wrote:
The output from
the chip is quite noisy.
The problem is not that the signal is not reliable: it is. It is just that it
is off by a few degrees.
There is a script I wrote in TCL
on the
SourceForge web site under the
Le 23 déc. 2010 10:11, Timo Juhani Lindfors timo.lindf...@iki.fi
a écrit :
W. B. Kranendonk writes:
One of my FRs is dizzy: the accelerometers are off.
Can you send a sample of the accelerometer data? (Preferably in
the binary format that you can read from /dev/input/)
On Thu, 12
W. B. Kranendonk wankelwan...@yahoo.com writes:
Is that useful? This is while the FR is lying flat on its back. I
haven't compared it to output from the other FR yet.
Raw binary output would be a lot easier to parse.
___
Openmoko community mailing
--- On Sat, 12/25/10, Timo Juhani Lindfors timo.lindf...@iki.fi wrote:
W. B. Kranendonk wankelwan...@yahoo.com
writes:
Is that useful?
Raw binary output would be a lot easier to parse.
Lying on its back again, cat /dev/input/event4 event4.log
See attachment.
¤ÃMÃ
running of by lifting the right side by 15 deg and the
top by about 5 deg.
On the wiki there is sparse mention of accelerometer calibration; is it
possible at all or does it have a different name?
Best regards,
Boudewijn
___
Openmoko
W. B. Kranendonk wankelwan...@yahoo.com writes:
One of my FRs is dizzy: the accelerometers are off.
Can you send a sample of the accelerometer data? (Preferably in the
binary format that you can read from /dev/input/)
___
Openmoko community
elerometers are off.
Can you send a sample of the accelerometer data? (Preferably in the
binary format that you can read from /dev/input/)
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman
and the lis302dl spec sheet, an open
on the device
file should send the calibration data from the device. Can you confirm
that I am reading the correct driver source?
I have now confirmed that indeed the proper sequence of data is flowing
from the accelerometer
interface using /dev/input/event2
Many tests appear to indicate that a complete report set read from
/dev/input/event2 or event3 is a relative rarity. Looking at the code
from the lis302dl driver in git.openmoko.org it appears to me that this
should not be true, and if I recall correctly, proper output was couming
out under
Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton:
Many tests appear to indicate that a complete report set read from
/dev/input/event2 or event3 is a relative rarity. Looking at the code
from the lis302dl driver in git.openmoko.org it appears to me that this
should not be
Michael 'Mickey' Lauer wrote:
Am Donnerstag, den 17.12.2009, 11:59 -0500 schrieb Iain B. Findleton:
Many tests appear to indicate that a complete report set read from
/dev/input/event2 or event3 is a relative rarity. Looking at the code
from the lis302dl driver in git.openmoko.org it
On Thu, 17 Dec 2009 12:32:46 -0500
Iain B. Findleton ifindle...@videotron.ca wrote:
Let me remind you that the driver has changed wrt. RELATIVE and
ABSOLUTE. These days, upon opening the device, only the first report is
a full report. Subsequent reports only contain changed axes.
I
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
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
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.
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
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
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
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
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
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
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
out of date data, because of the
kernel buffering unread data in the open file object. To avoid that,
I decided to open, read and close on every iteration of reading the
accelerometer.
But I saw while googling that the buffer for these files only holds 64
sets of data - hence if the sample period
you mail me the code.
What software have you used on the PC to make a graph??
Use OpenGl with some commands to read the serial port data. (see MSDN
documentation if on windows).See wiki for accelerometer code.
___
Openmoko community mailing list
Hi ranjan, I would like to have a look at your source code and try to figure
out what needs to be done to Increase the performance. Can you tell me where
can I look for the code, or can you mail me the code.
What software have you used on the PC to make a graph??
On Thu, Oct 1, 2009 at 7:04 PM,
to read the serial port data. (see MSDN
documentation if on windows).See wiki for accelerometer code.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
What are the accelerometers used in the FR (company and model number)?I
think it might be Freescale's MMA7260.If it is it has selectable
sensitivities in the range of +/- 1.5 g to 6 g what has been selected in
the free runner.What I observed is that the Free runner is able to
detect shocks as
On Thu, Oct 01, 2009 at 10:19:00AM +0530, RANJAN wrote:
Hi,
What are the accelerometers used in the FR (company and model number)?I
think it might be Freescale's MMA7260.
I have no idea why you think they might be Freescale MMA7260. The wiki[1]
clearly says that they are LIS302DL from ST
the
sample rate be changed?And what is the fastest way to read the accelerometer
values.Also is 38400 bps the max baud rate of the bluetooth on FR?
Sriranjan
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman
Freerunner uses the LIS302DL accelerometers from ST [1]. They can be
switched between +-2g and +-8g range and have a resolution of 8 bit per
axis. The sample rate can be selected between 100Hz and 400Hz. And they
inherit some nice functions like double click detection and zero-g
filtering.
Hi,
I have been testing the accelerometers on the free runner via bluetooth at
38400 bps.Here is my test video:
http://www.youtube.com/watch?v=Bdads8XAYcE
I think at 38400 it is not pretty real time.What could be the maximum
refresh rate of the accelerometers?And what is the best way to read
I have been testing the accelerometers on the free runner via bluetooth at
38400 bps.Here is my test video:
http://www.youtube.com/watch?v=Bdads8XAYcEhttp://www.youtube.com/watch?v=Bdads8XAYcE
I think at 38400 it is not pretty real time.What could be the maximum
refresh rate of the
After many experiments with the accelerometers, I notice that there is,
on my FR, a considerable difference between the readings from the 2
devices. Aside from the noise issue, the difference between the measured
gravity between the 2 devices is of the order of 1m/s**2, device 0 being
lower than
So, the fact that when idle the accelerometers report a positive Z value
implies that the Z axe is actually upward.
Agree ?
Yes I think that's right. If you hold the Freerunner that any arrow of an axis
points to the earth middlepoint then the sown value must be negative.
Michael
Michael Tansella michael-tanse...@gmx.de writes:
So, the fact that when idle the accelerometers report a positive Z value
implies that the Z axe is actually upward.
Agree ?
Yes I think that's right. If you hold the Freerunner that any arrow of an
axis
points to the earth middlepoint then
Please have a look at the accelerometer data retrieval wiki page at
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval .
It is said that the Z axis is pointing from the display downwards to to the
back of the openmoko. In my opinion this is false and all other axes
my be inverted as well
Paul Fertser fercer...@gmail.com writes:
? Michael Tansella michael-tanse...@gmx.de writes:
So, the fact that when idle the accelerometers report a positive Z value
implies that the Z axe is actually upward.
Agree ?
Yes I think that's right. If you hold the Freerunner that any arrow of an
?
The wiki tells that a positive acceleration is downward (Z axe pointing down).
This is not true, in my opinion.
When standing still, the accelerometer must report an acceleration directed in
the
_oposite_ direction the the gravitational force. As it is reporting a positive
acceleration
that a positive acceleration is downward (Z axe pointing down).
This is not true, in my opinion.
When standing still, the accelerometer must report an acceleration directed
in the
_oposite_ direction the the gravitational force. As it is reporting a positive
acceleration, then the Z axe goes up.
And I
a (a_tot=a+g).
Well, some confusion here.
OK, let's imagine a _perfect_ accelerometer.
This device would report only acceleration. So, when the phone lies on the
table, it would report 0 (neglecting the rotation of earth here :-)).
Then, to take your phone up to your ear, you first accelerate
direction) that is the sum of gravity acceleration g and your imposed
acceleration a (a_tot=a+g).
Well, some confusion here.
OK, let's imagine a _perfect_ accelerometer.
This device would report only acceleration. So, when the phone lies on the
table, it would report 0 (neglecting the rotation
Le 14342ième jour après Epoch,
ri...@happyleptic.org écrivait:
Well, some confusion here.
Yes, probably because of mixing gravity, force, acceleration, inertia,
etc... :)
OK, let's imagine a _perfect_ accelerometer.
This device would report only acceleration. So, when the phone lies
Thank you very much for the sample code. I've just read that Andy has left
Openmoko, so I wonder what will happen to the Andy-tracking Kernel. I hope
that the changes to the ABS sync events will go into the stable Kernel. When
that happens I'll add your Code to the Wiki if you agree.
All the
are an improvement for
the accelerometer data, but the report times, while not negative any
more, appear somewhat erratic. The type codes appear to be unchanged in
this build, with the driver reporting EV_REL and EV_SYN.
The time codes should be very reliable, and should be spaced at 10ms
On Sun, Mar 22, 2009 at 07:39:13PM -0700, Charles-Henri Gros wrote:
Iain B. Findleton wrote:
I have been playing a bit with the accelerometers on the FR appear to
observe the following:
1) The time stamp on events appears to be unreliable, in the sense
that the time difference
In the latest andy-tracking it reports the more correct 'ABS' events.
So now it does report zeros. However it doesn't report an axis if there
has been no change.
Is it correct that there are now two changes for developers. The first one is
that the EVENT type has changed from EV_REL (0x02)
Okay, it looks like the 2.6.28 kernel and modules are an improvement for
the accelerometer data, but the report times, while not negative any
more, appear somewhat erratic. The type codes appear to be unchanged in
this build, with the driver reporting EV_REL and EV_SYN.
Thanks for the various
Charles-Henri Gros wrote:
A known issue in 2008.12.
http://docs.openmoko.org/trac/ticket//2145
Workaround:
echo 10 /sys/devices/platform/lis302dl.1/threshold
ls /sys/devices/platform:
drwxr-xr-x 21 root root0 Mar 23 12:40 .
drwxr-xr-x4 root root
On Monday March 23, michael-tanse...@gmx.de wrote:
In the latest andy-tracking it reports the more correct 'ABS' events.
So now it does report zeros. However it doesn't report an axis if there
has been no change.
Is it correct that there are now two changes for developers. The first one
On Monday March 23, ifindle...@videotron.ca wrote:
Okay, it looks like the 2.6.28 kernel and modules are an improvement for
the accelerometer data, but the report times, while not negative any
more, appear somewhat erratic. The type codes appear to be unchanged in
this build
On Monday March 23, ifindle...@videotron.ca wrote:
Charles-Henri Gros wrote:
A known issue in 2008.12.
http://docs.openmoko.org/trac/ticket//2145
Workaround:
echo 10 /sys/devices/platform/lis302dl.1/threshold
ls /sys/devices/platform:
They seem to move around a
On Monday 23 March 2009, Neil Brown wrote:
So look under /sys/bus/spi/devices/spi3.x
I wonder what 'spi' means...
Serial Peripheral Interface, a common bus for connecting microprocessors to
accelerometers and suchlike
___
Openmoko community mailing
On Tue, Mar 24, 2009 at 09:24:09AM +1100, Neil Brown wrote:
if type == 3:
if code == 0:
x = value
if code == 1:
y = value
if code == 2:
z = value
Or
if type == 2 or type == 3:
...
then it would work on both old
I have been playing a bit with the accelerometers on the FR appear to
observe the following:
1) The time stamp on events appears to be unreliable, in the sense
that the time difference
between sequential events is frequently negative, and appears
also to be have erratically
by
Hi,
Iain B. Findleton ifindle...@videotron.ca writes:
I have been playing a bit with the accelerometers on the FR appear to
observe the following:
...
1) Is this a common situation with the FR (OM2008.12)
Unmaintained distro using old kernel? No wonder. There was plenty of
accelerometer
Hi,
With the following Kernel the Accs work great for me.
http://downloads.openmoko.org/distro/unstable/NeoFreerunner/uImage-2.6.28-
stable+gitr0+f19f259d3c1afde8eae53983fd19f61831927413-r2-om-gta02.bin
greets
Michael
___
Openmoko community mailing
Iain B. Findleton wrote:
I have been playing a bit with the accelerometers on the FR appear to
observe the following:
1) The time stamp on events appears to be unreliable, in the sense
that the time difference
between sequential events is frequently negative, and appears
also to
On Sunday March 22, charles-henri.gros+openm...@m4x.org wrote:
Iain B. Findleton wrote:
I have been playing a bit with the accelerometers on the FR appear to
observe the following:
1) The time stamp on events appears to be unreliable, in the sense
that the time difference
r...@om-gta02:~# opkg install perpendicular
http://downloads.openmoko.org/repository/unstable/armv4t/libsdl-1.2-0_1.2.11-r7_armv4t.ipk
http://downloads.openmoko.org/repository/unstable/armv4t/libsdl-ttf_2.0.3-r1_armv4t.ipk
http://downloads.openmoko.o
community@lists.openmoko.org
Gesendet: Dienstag, den 3. März 2009, 23:06:12 Uhr
Betreff: Re: AW: New accelerometer application, that draws the current
perpendicular line and angle
Just install them from openmoko repositories, then it works.
http://downloads.openmoko.org/repository/unstable
Just install them from openmoko repositories, then it works.
http://downloads.openmoko.org/repository/unstable/armv4t/ or
experimental one.
Btw. this app is really nice, I thought about some similar one -
instead of line, rolling ball. Maybe in some free time..
On Tue, Mar 3, 2009 at 8:56 PM, The
Hi Community,
I
have recently written a little utility, that draws the perpendicular
line using the accelerometers. It is based upon SDL and SDL_ttf (for
drawing the angle). I hope you can enjoy it, I will soon release a
binary package.
Here the source code:
On Mon, Mar 2, 2009 at 6:03 PM, hab keen oh ne baba_mel...@yahoo.de wrote:
Hi Community,
I have recently written a little utility, that draws the perpendicular line
using the accelerometers. It is based upon SDL and SDL_ttf (for drawing the
angle). I hope you can enjoy it, I will soon release
Hi,
I would like to know much syncrhonizing is possible
between audio input and accelerometer input.
How much can it be improved with kernel modifications?
For example setting a timestamp in the sound input?
Greetings
Andreas Kemnade
signature.asc
Description: PGP signature
Hi,
On Thu, 5 Feb 2009 11:18:15 +0100
Christ van Willegen cvwille...@gmail.com wrote:
I would like to know much syncrhonizing is possible
between audio input and accelerometer input.
How much can it be improved with kernel modifications?
For example setting a timestamp in the sound input
I would like to know much syncrhonizing is possible
between audio input and accelerometer input.
How much can it be improved with kernel modifications?
For example setting a timestamp in the sound input?
What would also be nice is a good way to synchronize accel data and
GPS data, so that, ie
Hi All,
if I've understood correctly, on Om2008.12 the Accelerometer does not get
correctly recognized out of the box:
it sends useless data
and that's a kernel issue.
It seems that there aren't any kernel package that fixes it, please correct me
if I'm wrong.
That said, I guess
Charles-Henri Gros charles-henri.gros+openm...@m4x.org writes:
Any ideas why this may be happening / how to fix it?
Sounds like http://docs.openmoko.org/trac/ticket//2145
___
Openmoko community mailing list
community@lists.openmoko.org
When trying to read the accelerometers, it looks like no data is
received if there's a big change in acceleration.
e.g. if I hexdump /dev/input/event2, and start shaking the phone, output
stops.
Any ideas why this may be happening / how to fix it?
Thanks,
--
Charles-Henri
Then maybe gestures daemon can be extended to be more robust. The biggest
problem with the acc.meters is that they go unresponsive and block read
attempts.
On Mon, Nov 10, 2008 at 2:51 PM, Michael 'Mickey' Lauer [EMAIL PROTECTED]
wrote:
Am Monday 10 November 2008 14:14:45 schrieb Atilla Filiz:
Mickey,
I've talked with Daniel recently and told him that I was working on
recognizing contexts.
For that I'm using self-organizing maps (Nokia is using these for
gesture recognition) and I'll try to recognize walking, running,
walking up/down stairs etc.
Just wanted you to know that I'm
I don't know if there is any work towards this anyway, i think having an acc
daemon like gpsd would be nice. The daemon can check for blocking in
acc.meters and reset the hardware if necessary, and serve multiple
clients(which is not very likely actually). This way maybe we can have more
quality
Hi
the potentiel of these accelerometer is great, but I need some help to
really understand what can be done with them.
I mean for now i know openmoocow, gestures
What can I do with theses recognized gestures ? Load a command, call my
mother ? I don't wnat to sound against their use
Hi Paul,
Here is an interesting reference for you on recognizing contexts from mobile
phone data (can send you the PDF as PM upon request):
Modular Bayesian Network for Uncertainty Handling on Mobile Device
Keum-Sung Hwang, Sung-Bae Cho.
Mobile devices can now handle a great deal of
I think its quite likely to need multiple clients:
openmoocow/gestures/accel-rotate are on my phone now. When it starts
being a reliable phone I would also like to try the orientation based
profiles so there will often be two or more applications running at the
same time.
BillK
On Mon,
ok, thanks folks!
jni it is then...
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I guess that this is the way when using jni.
Timo Juhani Lindfors schrieb:
Bernd Prünster [EMAIL PROTECTED] writes:
my question is: how do i read our data from the accelerometers in java?
You open the file[1] and read data[2].
[1]
wiki.openmoko.org, execute it and read the output, but that's not a
desirable way!
so i'm asking to give me a hint how to directly read the accelerometer
output. (it's gotta be possible without jni and the like...
..but if not, what's the best way to do it?)
thx in advance
Sudharshan S [EMAIL PROTECTED] writes:
I think, there are DBus bindings for java. So you could probably take a look
at the services offered by FSO for reading accelerometers output.
Wouldn't that cause huge overhead? Reading 100 (or 400) events per
second from two accelometers can not be
Bernd Prünster [EMAIL PROTECTED] writes:
my question is: how do i read our data from the accelerometers in java?
You open the file[1] and read data[2].
[1] /dev/input/event{2,3}
[2] data is a steady flow of
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32
On Saturday 08 November 2008 19:58:29 Bernd Prünster wrote:
so i'm asking to give me a hint how to directly read the accelerometer
output. (it's gotta be possible without jni and the like...
..but if not, what's the best way to do it?)
I think, there are DBus bindings for java. So you could
- New Energy for Java - Domain Driven Development.
On Tue, Oct 14, 2008 at 9:06 PM, Paul V. Borza [EMAIL PROTECTED] wrote:
Hi everyone,
A couple of people asked me whether I will or won't continue my
project on accelerometer-based gestures.
My answer was always yes, and to make
like to remind you of a
couple of details that may turn out to be important in the long run.
One thing I would like to see come true is the implementation of an
accelerometer framework that is flexible enough to accommodate all
kinds of usage, not just gestures, and you are basically sitting
is the implementation of an
accelerometer framework that is flexible enough to accommodate all
kinds of usage, not just gestures, and you are basically sitting on it
(horay!!!). :)
Examples:
1 - human gestures;
2 - seismic vibrations (distributed earth quake detection), see [1];
3 - travel dead
of an
accelerometer framework that is flexible enough to accommodate all
kinds of usage, not just gestures, and you are basically sitting on it
(horay!!!). :)
Examples:
1 - human gestures;
2 - seismic vibrations (distributed earth quake detection), see [1];
3 - travel dead reckoning, whether of humans
.
http://www.qi4j.org- New Energy for Java - Domain Driven Development.
On Tue, Oct 14, 2008 at 9:06 PM, Paul V. Borza [EMAIL PROTECTED] wrote:
Hi everyone,
A couple of people asked me whether I will or won't continue my
project on accelerometer-based gestures.
My answer was always
Hi everyone,
A couple of people asked me whether I will or won't continue my
project on accelerometer-based gestures.
My answer was always yes, and to make that clear, I've bought
accelsense.com, and accelsense.org.
The code has moved from http://code.google.com/p/accelges/ into a GIT
repository
On Wednesday 15 October 2008 06:06:40 Paul V. Borza wrote:
Hi everyone,
A couple of people asked me whether I will or won't continue my
project on accelerometer-based gestures.
My answer was always yes, and to make that clear, I've bought
accelsense.com, and accelsense.org.
The code has
On Sun, 12 Oct 2008 09:47:13 +0530
Nishit Dave [EMAIL PROTECTED] wrote:
*groan* I am on qtextended, I charged the phone fully before going to
sleep, but when I woke up this morning, it was switched off. I had
switched off the alarm too. After putting it to charge, apm told me
battery level
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Fox Mulder wrote:
How can i test if it really goes into suspend or any other suspend-like
mode?
After i press the putton zhone says that it goes into suspend and
nothing anymore reacts for input. Only when i press the power button
again it
1 - 100 of 338 matches
Mail list logo
