Vala DataInputStream.read_int32 in accelerometer message

3 messages Options
Embed this post
Permalink
MicVM

Vala DataInputStream.read_int32 in accelerometer message

Reply Threaded More More options
Print post
Permalink
I am trying to build a vala library to access the accelerometers of the freerunner. I am using vala just to give it a try but I am experiencing strange problems and wanted to ask if some of you can give me some hints. When i read from the input interface of an accelerometer i get the following bytestream:

b 3 d1 4a 42 ea d 0 0 0 0 0 0 0 0 0
1b 3 d1 4a 79 f e 0 3 0 1 0 6c 0 0 0
1b 3 d1 4a d7 f e 0 3 0 2 0 26 4 0 0

that looks quite good to me. However, when I try to read the values in the message as integers i have a problem when reding the "value" field, i.e. the last 32 bit signed integer of the message. I get strange values around +300 instead of +1062 for the Z value as in the last line of the above example. Also for X and Y the values are wrong. I read the stream with the following code snippet in vala (using GIO libs):

var data_stream=new DataInputStream(file_stream);
data_stream.set_byte_order(DataStreamByteOrder.LITTLE_ENDIAN);

//Skip time field, 8 bytes
data_stream.skip(8,null);

//Read eventtype
eventtype=data_stream.read_uint16(null);
while(eventtype!=0)
{
        if((eventtype==3)||(eventtype==2))
        {
                code=data_stream.read_uint16(null);
                if(code==0)
                {
                        x_value=data_stream.read_int32(null);
                                       
                }
                if(code==1)
                {
                        y_value=data_stream.read_int32(null);
                }
                if(code==2)
                {
                        z_value=data_stream.read_int32(null);
                }
                       
....

I think somewhere I am doing a major mistake because the decoding of the int32 is a basic functionality that does not work in my case. The funny thing is that decoding of uint16 is done correctly such that eventtype and code are read correctly. Any help is appreciate :)
RANJAN-3

Re: Vala DataInputStream.read_int32 in accelerometer message

Reply Threaded More More options
Print post
Permalink


On Sun, Oct 11, 2009 at 1:38 AM, MicVM <[hidden email]> wrote:

I am trying to build a vala library to access the accelerometers of the
freerunner. I am using vala just to give it a try but I am experiencing
strange problems and wanted to ask if some of you can give me some hints.
When i read from the input interface of an accelerometer i get the following
bytestream:

b 3 d1 4a 42 ea d 0 0 0 0 0 0 0 0 0
1b 3 d1 4a 79 f e 0 3 0 1 0 6c 0 0 0
1b 3 d1 4a d7 f e 0 3 0 2 0 26 4 0 0

that looks quite good to me. However, when I try to read the values in the
message as integers i have a problem when reding the "value" field, i.e. the
last 32 bit signed integer of the message. I get strange values around +300
instead of +1062 for the Z value as in the last line of the above example.
Also for X and Y the values are wrong. I read the stream with the following
code snippet in vala (using GIO libs):

var data_stream=new DataInputStream(file_stream);
data_stream.set_byte_order(DataStreamByteOrder.LITTLE_ENDIAN);

//Skip time field, 8 bytes
data_stream.skip(8,null);

//Read eventtype
eventtype=data_stream.read_uint16(null);
while(eventtype!=0)
{
       if((eventtype==3)||(eventtype==2))
       {
               code=data_stream.read_uint16(null);
               if(code==0)
               {
                       x_value=data_stream.read_int32(null);

               }
               if(code==1)
               {
                       y_value=data_stream.read_int32(null);
               }
               if(code==2)
               {
                       z_value=data_stream.read_int32(null);
               }

....

I think somewhere I am doing a major mistake because the decoding of the
int32 is a basic functionality that does not work in my case. The funny
thing is that decoding of uint16 is done correctly such that eventtype and
code are read correctly. Any help is appreciate :)
--
View this message in context: http://n2.nabble.com/Vala-DataInputStream-read-int32-in-accelerometer-message-tp3801000p3801000.html
Sent from the Openmoko Devel mailing list archive at Nabble.com.

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel

What is the maximum frequency at which you are able to read the accelerometer values?
Are you able to sample the values properly?
Are the reading in X and Y changing smoothly?

Here is a test that I conducted:
http://www.youtube.com/watch?v=Bdads8XAYcE&feature=fvsr

Sriranjan

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel
MicVM

Re: Vala DataInputStream.read_int32 in accelerometer message

Reply Threaded More More options
Print post
Permalink
On 10/11/09, RANJAN <[hidden email]> wrote:

> On Sun, Oct 11, 2009 at 1:38 AM, MicVM <[hidden email]> wrote:
>
>>
>> I am trying to build a vala library to access the accelerometers of the
>> freerunner. I am using vala just to give it a try but I am experiencing
>> strange problems and wanted to ask if some of you can give me some hints.
>> When i read from the input interface of an accelerometer i get the
>> following
>> bytestream:
>>
>> b 3 d1 4a 42 ea d 0 0 0 0 0 0 0 0 0
>> 1b 3 d1 4a 79 f e 0 3 0 1 0 6c 0 0 0
>> 1b 3 d1 4a d7 f e 0 3 0 2 0 26 4 0 0
>>
>> that looks quite good to me. However, when I try to read the values in the
>> message as integers i have a problem when reding the "value" field, i.e.
>> the
>> last 32 bit signed integer of the message. I get strange values around
>> +300
>> instead of +1062 for the Z value as in the last line of the above example.
>> Also for X and Y the values are wrong. I read the stream with the
>> following
>> code snippet in vala (using GIO libs):
>>
>> var data_stream=new DataInputStream(file_stream);
>> data_stream.set_byte_order(DataStreamByteOrder.LITTLE_ENDIAN);
>>
>> //Skip time field, 8 bytes
>> data_stream.skip(8,null);
>>
>> //Read eventtype
>> eventtype=data_stream.read_uint16(null);
>> while(eventtype!=0)
>> {
>>        if((eventtype==3)||(eventtype==2))
>>        {
>>                code=data_stream.read_uint16(null);
>>                if(code==0)
>>                {
>>                        x_value=data_stream.read_int32(null);
>>
>>                }
>>                if(code==1)
>>                {
>>                        y_value=data_stream.read_int32(null);
>>                }
>>                if(code==2)
>>                {
>>                        z_value=data_stream.read_int32(null);
>>                }
>>
>> ....
>>
>> I think somewhere I am doing a major mistake because the decoding of the
>> int32 is a basic functionality that does not work in my case. The funny
>> thing is that decoding of uint16 is done correctly such that eventtype and
>> code are read correctly. Any help is appreciate :)
>> --
>> View this message in context:
>> http://n2.nabble.com/Vala-DataInputStream-read-int32-in-accelerometer-message-tp3801000p3801000.html
>> Sent from the Openmoko Devel mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> devel mailing list
>> [hidden email]
>> https://lists.openmoko.org/mailman/listinfo/devel
>>
>
> What is the maximum frequency at which you are able to read the
> accelerometer values?
> Are you able to sample the values properly?
> Are the reading in X and Y changing smoothly?
>
> Here is a test that I conducted:
> http://www.youtube.com/watch?v=Bdads8XAYcE&feature=fvsr
>
> Sriranjan
>
Hi, i provide here hopefully the answers to your questions:

I tried to measure the time passed when reading the messages as in the
code snippet above and when reading a 16-bytes stream (uint8 field)
for each message. In both examples the freerunner was laying on the
table with the touchscreen on the top. Indeed there is something
strange there:

16ByteStream Method (data_stream.read(buffer,16,null)):

59 fe d1 4a 5b 55 1 0 0 0 0 0 0 0 0 0
uSec: 22
59 fe d1 4a 1c 7a 1 0 3 0 0 0 48 0 0 0
uSec: 8751
59 fe d1 4a 92 7a 1 0 3 0 2 0 2 4 0 0
uSec: 23
59 fe d1 4a b2 7a 1 0 0 0 0 0 0 0 0 0
uSec: 21
59 fe d1 4a 71 9f 1 0 3 0 1 0 90 0 0 0
uSec: 9125
59 fe d1 4a ce 9f 1 0 3 0 2 0 de 3 0 0
uSec: 23
59 fe d1 4a ef 9f 1 0 0 0 0 0 0 0 0 0


Snippet method:

X Message arrived
uSec: 462
Y Message arrived
uSec: 8501
Z Message arrived
uSec: 363
SYN: 0 0 0
uSec: 16
X: -72, Y: 54, Z: 306
X Message arrived
uSec: 464
Y Message arrived
uSec: 402
Z Message arrived
uSec: 370
SYN: 0 0 0
uSec: 16
X: -54, Y: 72, Z: 306
X Message arrived
uSec: 466
Y Message arrived
uSec: 27613
Z Message arrived
uSec: 402
SYN: 0 0 0
uSec: 16
X: -72, Y: 54, Z: 306
X Message arrived
uSec: 2038
Y Message arrived
uSec: 384
Z Message arrived
uSec: 361
SYN: 0 0 0
uSec: 15

Regarding the smoothness of changes, when i decode "manually" the 16
byte stream the changes are rather smooth (e.g. for Z=1000 in the
current position, then 980, then 956 then 880, etcc.). When i decode
it by the code snippet the changes are also "smooth" BUT the ranges
for X, Y and Z are totally asymmetric and not in the same range. E.g.
when I put the freerunner on the X axis I get the value -32 (with -X i
get -90) while when i put it on the Z axis +306 (-Z gives -162 as
result).

About the sampling, I am not sure what u mean. I use:

data_stream.skip(8,null); //for time
eventtype=data_stream.read_uint16(null);  //is decoded correctly as 0, 2 or 3
code=data_stream.read_uint16(null); //is decoded correctly as 0,1,2
x_value=data_stream.read_int32(null); // strange behaviour IMHO

which should correspond to the decoding described in:
http://wiki.openmoko.org/wiki/Accelerometer_data_retrieval

_______________________________________________
devel mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/devel