MP3Car.com - View Single Post - Space Navigator PE Driver Development Thread

cherrybomb · 01-11-2007, 01:05 PM

Quote: Originally Posted by sama

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've been posting a lot of my findings and such on the Promixis message board, and evidently Girder 5 is going to have much more robust support for HID. I've been offered to join the beta, which I think I will, and use developing for this device to test.

Quote: Originally Posted by sama

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.

*nod* the first two were pretty much the ones I'd expected to have for this device. I agree that there should be some threshold that it ignores to allow for it to be useful.

Quote: Originally Posted by sama

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.

Yes, gestures. :-) It'd be cool to have some gestures that take you to specific places, or do specific things. Like a left tilt and zoom takes you to GPS, but a right title and zoom takes you to your media player etc. :-)

Quote: Originally Posted by sama

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

Can't really take a ton of credit for it, most of it was already written, I just massaged it to conform to our application. Glad it helped. :-)

01-11-2007, 01:05 PM	#16
cherrybomb Variable Bitrate Join Date: Apr 2005 Location: Southern Califorina Posts: 228	Quote: Originally Posted by sama 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've been posting a lot of my findings and such on the Promixis message board, and evidently Girder 5 is going to have much more robust support for HID. I've been offered to join the beta, which I think I will, and use developing for this device to test. Quote: Originally Posted by sama 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. nod the first two were pretty much the ones I'd expected to have for this device. I agree that there should be some threshold that it ignores to allow for it to be useful. Quote: Originally Posted by sama 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. Yes, gestures. :-) It'd be cool to have some gestures that take you to specific places, or do specific things. Like a left tilt and zoom takes you to GPS, but a right title and zoom takes you to your media player etc. :-) Quote: Originally Posted by sama Thanks for all the help cherry, coudln't have done anythign at all without your magic app! Can't really take a ton of credit for it, most of it was already written, I just massaged it to conform to our application. Glad it helped. :-) __________________ '99 Ford Explorer Eddie Bauer CarPC Progress ~= 97%. Everything is installed, and operational. Still need to tweak and tune, and do some "finish" fabrication. CarPC Project Web Site SpaceNavigatorDriver SourceForge Project Check out my blog.