Start a new topic

communicating with 3D embeded..


I'm building an artistic installation using GHI EMX board and YEI 3D sensor.

It's a small VR device with simple horisontal pan.

I managed to connect the sensor using SPI and can get data from it using

C# code (.NET MF). However I recieve 12 byte[] arrays, which represent 3 floats.

And since there is no BitConverter, it looks like I need to write my own

IEEE754 converter in order to get actual values. Or is there a workaround ?

I saw that I can communicate with sensor in ASCII mode. I wonder if it's much

slower, than binary ?

Also regarding speed - is it better to put sensor in streaming mode or request

data manually ? Basically I need to get as low latency as possible, since it's a

real-time visual application.

Thanks in advance,


Hi Gerald,

Our data-logging sensor can be set to begin a recording session immediately after being turned on. Please refer to section 3.5.3 in the 3-Space user's manual for more information on the settings available with the 3-Space data-logger: You can learn more about the data-logger at the following link: Let me know if you have any more questions!

HI - another question related to this though just for a generic 3space sensor. Is it possible to prepare the sensor so it is always in streaming mode?  ie. so I don't need to send any instructions - just turn it on and know that data will be generated...

Thanks Gerald


Ok! Thank you very much for your help! It works now as I wanted....
Amazing :)


Hi Mikhail,

Since you are mounting the sensor vertically on your forehead, I would recommend using the offset orientation in order to compensate for mounting the sensor in this orientation. You can find instructions on how to set this up in section 3.1.8 of our user's manual: As you said, the problem you are experiencing now is likely due to gimbal lock. Using the offset orientation will let the sensor give readings as if it were mounted horizontally, even though it is vertical.

The Suite does not do anything special to retrieve rotation data from the sensor -- the data chart prints the data to the screen exactly as it is received. Let us know if you have any more questions!


I switched to serial mode and it seems to be working fine. I can also convert floats without problem.
However it seems that I'm having another problem.

For my application I need to  to capture horizontal pan movement (as if somebody is turning their head left and right) and with sensor attached flat to their forehead. So my sensor is mounted vertically and I need to capture rotation around Y axis (in world coordinates).

When sensor is lying flat on the table I can sort of get this data, however when I mount it vertically, I can't get any data which corresponds to this "head turning" rotation.

I issue "0x60" Tare with current orientation command.

Then I request Euler Angles (0x01) and take one of the axis.
But none of them are consistent with my movement.

After some reading I wonder if my problem is due to gimbal lock, since
my sensor is in vertical position. But at the same time when sensor is
flat on the table, it seems to be doing the job.

I tried to use quaternions to get roll,pitch, yaw data..  but when I monitor
the values, I still can't get this rotation data that I need.

Strangely enough in 3-Space-Suite in graph view I get good rotation data on Z
axis ... but when I try to recover data it from my code, it's not good. So it seems
that there are some more operations that needs to be done to get clean rotation data ?
Or am I missing something fundamental in my approach ?

Thank you,


Hi Mikhail,

Yes, if you are able to establish a serial connection rather than SPI you will then be able to use streaming mode.

Let us know if you have any more questions!

Hello Tricia. 

Thank you for your answer. The reason I can't use BitConverter is because I use version 4.2 of MF and I'm a bit reluctant to upgrade. 

Now regarding SPI - so maybe that not the best way to communicate with the sensor ? 

I can use serial (asynch) communication. 

Would that be any better than SPI ? 

Especially since there is a steaming mode available ? 

Thanks, M

Hi Mikhail,

Is there a reason that you cannot use the BitConverter that is built into C#? If you cannot use this, then yes, it will be necessary to write your own converter. We do not recommend ASCII mode as it is significantly slower than binary (more data needs to be sent), and it is also incompatible with SPI. Streaming mode is faster than the call and response protocol, but this is also not available over SPI.

Let us know if you have any more questions!

Login or Signup to post a comment