Space Navigator PE Driver Development Thread

[sama]

PROGRESS: We've now decoded the data that comes back from the HID device, and pending some development to make it do something useful. This is no longer a Girder defition file, it'll be a multiplatform stand-alone app

Following some developments in this thread, a Girder definition is now under development for the 3DConnexion SpaceNavigator PE. This is a device that has 6 axis of motion, and two buttons.

So far, thanks to cherrybomb, it has been found that the latest version of Girder does not work with the HID plugin, as the previous verison did (4.0.1). Having downloaded this and configured the HID plugin, the values being read shown:

00 00 00 00 00 00

pressing buttons 1 or 2, give definitive values (first two digits change only), but things move way too fast to be able to determine how the different axis affect the numbers. I just about see that moving along some axis, sets some pair to FF, and others start playing.

Also, to add to the spice, i think the pan motion, is in fact a combination of two motions. Since this device is like a hat on a stick, then the stick moving forward AND the hat being tilt backwards equates to a panning action.

Anyway, I think a seperate development thread is in order for this, rather than a price drop one! So here it is... I'll post any updates here


Let's start with the simple bit shall we:

Button Left: 01 00 00 00 00 00
Button Right: 02 00 00 00 00 00
Both BUttons: 03 00 00 00 00 00

[turbocad6]

subscribed

[sama]

UPDATE:

Girder is proving to be a bit of a pain to learn, so to deocode the output of this device, cherrybomb and I have been working together. He's written a nice little app that gets HID output in .net, and he's sending it down a network port to a little java server that I wrote.

Now that we are both well within our elements, we should have this device sussed soon.

[turbocad6]

that's all I need to hear, I'm ordering one now

[sama]

lol! good on ya! now I feel we have a responsibility to get this working

we've got a couple of apps that shows progress bars of the 7 two-word bytes that come back from the HID input.

the device is very touchy-feely and spews shedloads of data when you barely touch it. I'm trying to be very precise with the movements, and to corrolate the movements that map to particular bars. Only bars 1-6 count, as the first figure is always 1, 2 or 3.

You'd expect that since there are 6 axis, and 6 values, each axis would map to a value. But that's not the case. I think they are combined to acheive a higher level of precision. So it's now a trial and error to decode it.

I've noticed, when data comes in, the whole line has starts either with a 1 or a 2. Creating a seperate set of bars for each, and displaying all of them, seems to show that there may in fact be 14 lots of data.

next step I will try to combine the numbers from the two lines to create a 16bit number, and then stick a sign (+/-) on it. I've got a good feeling about this strategy and depending on how sleepy I get now, I may jut try it


PS. I'm thinking out loud, so if cherrybomb sees this, he can know what I've been up to, and of course anyone else can follow

[inh]

very cool! at least your gettin somewhere man. i cant wait to get mine. too many speeding tickets to pay first.. :-/

[sama]

I FIGURED IT ALL OUT!!!!


I've seperated each axis... shoudln't be too hard now

[inh]

post details! i love technical crap

[sama]

ok, say you get two lines back that look like this:

Code:

1 8 0 161 255 251 255 
2 245 255 0 0 238 255

you organise this as follows:

Code:

[0] [1] [2] [3] [4] [5] [6]
 1   8   0  161 255 251 255 

[0] [1] [2] [3] [4] [5] [6]
 2  245 255  0   0  238 255

and this by using the table below, you can determine the stick's position.

Code:

pan left/right axis
value from 1[1]
right: 2[1] = 0
left : 2[1] = 255

pan fwd/back axis
value from 3[1]
back : 4[1] = 0
fwd  : 4[1] = 255

push/pull axis
value from 5[1]
push : 6[1] = 0
pull : 6[1] = 255

tilt fwd/back axis
value from 1[2]
back : 2[2] = 0
fwd  : 2[2] = 255

tilt left/right axis
value from 3[2]
left : 4[2] = 0
right: 4[2] = 255

twist axis
value from 5[2]
right: 6[2] = 0
left : 6[2] = 255

And finally, buttons are on lines that start with a 3, and they are:

Quote:

3 1 0 0 0 0 0 Left Button
3 2 0 0 0 0 0 Right Buton
3 3 0 0 0 0 0 Both Buttons

Just need to tidy the code now so each axis value ranges from -255 to +255, with a 2 bit modifier to indicate button state (0=none, 1 = left, 2 = right, 3 = both).


Damn, I need to sleep. I have to wake up in 5 hours!

[scott_fx]

damn you guys...you just spent another $65 of my money!

[sama]

hehe. I really think you won't be sorry. If you use google earth, it's worth it for that alone. And soon you'll also be able to use it for volume, track control, switching between different screens, and that's three axis out of 6.

This is a great device with lots of potential.

[liquid_smoke]

sounds good, cant wait to test this out.

[sama]

proof tha it works!

video codec: xvid mpeg 4

[cherrybomb]

Brilliant!

Good work sama!

Seems to make sense. Can't wait to get my device so I can actually test it.

Suppose I should tweak my test app, or I guess we're really ready to start developing something useful now that you've cracked the code?

[sama]

definiltely.

I've tried to create a girder scipt with this knowledge, but strangely it's only returning 6 bytes. I took off all the splitting code and did a simple string.length on the incoming data directly, it's 6 bytes for sure. Which means it's impossible to distinguish between interleaved lines. If the Poximis guys can sort that out, then I'm sure we can get a girder script to work also.

I have some ideas on how we can use this device:

I think we should ignore a small range at the begning of every axis otherwise there will be noise and overlap betwen functions.

In the configuration of the software, any axis can have different modes of operation.

MODE 1:
after a certain threshold, a thread starts a "pulsing" event. This would be slow with low values (little pressure), and as the pressure is increased, the pulse would get quicker. This will give a use for the analogue proerties of the device, and makes it possible to control the speed of for forwarding songs, cycling through playlists, volume change etc. The pulse/range mapping can easily be defined using a couple of arrays that can be defined in the config.

MODE 2:
just "presses" a single event per axis direction. pressure is not taken itno account. This is useful for switchign between different screens for example (GPS/Media/etc.)


I can think of antoher mode but I'm not sure what for!:

MODE 3:
segement the range to "press" a single event (not pulsing) at different threshholds.


I've also found that combining axis (like pan and tilt) you can create more quick-functions. Like holding the hat and tilting left but panning right. These quick presses are easy to model and diffrentiate.


I guess the best starting pont is getting this to work with RoadRunner, sending it simple messages, and then we can incorporate all these modes based on usage etc.

If anyone has any ideas, please post away.


Thanks for all the help cherry, coudln't have done anythign at all without your magic app!