Hi there.
I own a Spacepilot device but i don't use any 3D modeling software, no software that is supported or was supported by you (3DConnexion).
It has nice buttons a cool LCD Display but other than that with the current drivers and software it is purely useless.
Since I am a programmer (in my free time) I've said to myself "Hey this device has a SDK" but when looked a little at your SDK in order to make something usefull from this device I quickly realised that it was in vain.
Later I've found on this forum the RBC9 driver that could allow to do some usefull stuff but unlucky for me it doesnt work.
I dont want to go as such low level as RBC9 did (kernel driver) since i do not poses the necesary knowledge but what the heck I am not supposed to know such low level stuff if there is a well written API/SDK which on our case it doesnt exist.
So what are my options?
To throw in a recycle bin this ~400$ device or ....insert other option here...?
Spacepilot - to recycle it or not - this is the question
Moderator: Moderators
Hi jwick.
For starters one idea could be a process monitor / uptime / clock / network load / memory & disk monitor / a winamp visualisation plugin (i doubt about that since i've observed that the LCD has high latency, but i may be wrong) .... you name it.. anything usefull that can be displayed on that LCD. If you want to make an ideea about what i am talking look at the Lcdproc http://lcdproc.omnipotent.net/ as an example.
Now my problem shouldnt and it isnt the data aquisition but the display of that data on that LCD since i really do not know how to do it and no examples involving the LCD exist in the sdk or a documentation explaining the protocol used.
Ok ok, please dont get me wrong, your product does his job very well with all those application listed as supported but i want to do a little more with it (since i dont use any of that apps). This device has a lot of potential in doing a lot of things other than improving the productivity as 3d modeler and I'm almost sure that you agree with me.
Probably i will scratch my head a lot and give some serious head hits into some walls
) till i'll be able to make what i have in my mind but any help it will be quite nice to have.
For starters one idea could be a process monitor / uptime / clock / network load / memory & disk monitor / a winamp visualisation plugin (i doubt about that since i've observed that the LCD has high latency, but i may be wrong) .... you name it.. anything usefull that can be displayed on that LCD. If you want to make an ideea about what i am talking look at the Lcdproc http://lcdproc.omnipotent.net/ as an example.
Now my problem shouldnt and it isnt the data aquisition but the display of that data on that LCD since i really do not know how to do it and no examples involving the LCD exist in the sdk or a documentation explaining the protocol used.
Ok ok, please dont get me wrong, your product does his job very well with all those application listed as supported but i want to do a little more with it (since i dont use any of that apps). This device has a lot of potential in doing a lot of things other than improving the productivity as 3d modeler and I'm almost sure that you agree with me.
Probably i will scratch my head a lot and give some serious head hits into some walls
) till i'll be able to make what i have in my mind but any help it will be quite nice to have.Hi darvaru,
OK. I get ya.
You are more interested in using the LCD for innovative things than the motion controller. There are a lot of very cool things that could be done with it. You could even mix the motion controller in. Imagine controlling winamp with the motion controller with output to a high speed color LCD. That would be slick.
I did do an example controller for iTunes a while back. It showed the upcoming songs, current song, volume, etc. on the LCD. It used the motion controller to scrub through songs.
You are right about the LCD--it is too slow to do any realtime updates. It actually isn't the LCD that is the problem; the problem is the low speed USB connection to the machine. This is one reason why we don't expose access to the LCD via the COM SDK.
I did explain to someone on the forum how he can access the LCD. I suspect it was a bit too overwhelming for him since I never heard from him again <GG>.
Thanks for the input. Such innovative suggestions get our product marketing folks thinking...
Jim
3Dx Software Development
OK. I get ya.
You are more interested in using the LCD for innovative things than the motion controller. There are a lot of very cool things that could be done with it. You could even mix the motion controller in. Imagine controlling winamp with the motion controller with output to a high speed color LCD. That would be slick.
I did do an example controller for iTunes a while back. It showed the upcoming songs, current song, volume, etc. on the LCD. It used the motion controller to scrub through songs.
You are right about the LCD--it is too slow to do any realtime updates. It actually isn't the LCD that is the problem; the problem is the low speed USB connection to the machine. This is one reason why we don't expose access to the LCD via the COM SDK.
I did explain to someone on the forum how he can access the LCD. I suspect it was a bit too overwhelming for him since I never heard from him again <GG>.
Thanks for the input. Such innovative suggestions get our product marketing folks thinking...
Jim
3Dx Software Development
Thanks for your understanding and quick response.
I belive that you are reffering to this post viewtopic.php?t=1095
Ok, i've understood the display layout and the commands and data to be sent, but I'm still in the proverbial "fog" since I do not see what API should I use to send those commands (I never played with any USB device before). I guess using HID interface would be a good idea, I'll give it a try when I'll be at home using HIDRezero example as a base.
Anyway, can you give me a hint about how many fps can be achieved on that display when you fill it completly or how many seconds does it takes to be filled completly
? Or better, how many commands(data)/second does it accept.
Well, from what you said I'm a little surprised about the low speed of the interface. Almost all PC's from this generation supports USB 2.0 which is more than enough for what this device does but anyway I'm not here to judge your design.
PS: I appologize for any grammar and spelling mistakes done in this and previous posts, im not a native english speaker nor do i plan to be
I belive that you are reffering to this post viewtopic.php?t=1095
Ok, i've understood the display layout and the commands and data to be sent, but I'm still in the proverbial "fog" since I do not see what API should I use to send those commands (I never played with any USB device before). I guess using HID interface would be a good idea, I'll give it a try when I'll be at home using HIDRezero example as a base.
Anyway, can you give me a hint about how many fps can be achieved on that display when you fill it completly or how many seconds does it takes to be filled completly
? Or better, how many commands(data)/second does it accept.Well, from what you said I'm a little surprised about the low speed of the interface. Almost all PC's from this generation supports USB 2.0 which is more than enough for what this device does but anyway I'm not here to judge your design.
PS: I appologize for any grammar and spelling mistakes done in this and previous posts, im not a native english speaker nor do i plan to be
Yes that's the one.I belive that you are reffering to this post viewtopic.php?t=1095
You can just WriteFile to it.Ok, i've understood the display layout and the commands and data to be sent, but I'm still in the proverbial "fog" since I do not see what API should I use to send those commands (I never played with any USB device before). I guess using HID interface would be a good idea, I'll give it a try when I'll be at home using HIDRezero example as a base.
It's pretty slow. The key (and the difficulty) is to only update the part of the LCD that you change. You can set the start position for drawing to limit the amount of the LCD that you draw. I spent a lot of time optimizing the code for the static layout of the buttons display on the LCD. If you change the whole thing it will take a couple of seconds. I don't remember the exact data rate.Anyway, can you give me a hint about how many fps can be achieved on that display when you fill it completly or how many seconds does it takes to be filled completly ? Or better, how many commands(data)/second does it accept.
It's not the interface in the PC, it's the interface on the USB chip inside the device. These hardware decisions get made WAY in advance when a chip gets picked and the firmware gets written.Well, from what you said I'm a little surprised about the low speed of the interface. Almost all PC's from this generation supports USB 2.0 which is more than enough for what this device does but anyway I'm not here to judge your design.
I'll give it a try now that I'm home.jwick wrote: You can just WriteFile to it.
[qoute]It's pretty slow. The key (and the difficulty) is to only update the part of the LCD that you change. You can set the start position for drawing to limit the amount of the LCD that you draw. I spent a lot of time optimizing the code for the static layout of the buttons display on the LCD. If you change the whole thing it will take a couple of seconds. I don't remember the exact data rate.
[/qoute]
Well, it seems that the LCD (the physical device) have by its design high latency (it takes lot of time until a pixel is fully white or black) it is like an ancient CRT or LCD with a poor refresh rate (trails) so even having high write speed on it, it will not do any good since it's a "very lazy" LCD.
However the drawing optimisation is quite simple from my point of view, keeping in memory two 64x240 black & white bitmaps one with the current image displayed on the LCD and one with the new image that should be displayed on the LCD and having the drawing function updateing only the difference between those bitmaps. It doesnt require too much memory and the update function can be fairly fast enough not to be a CPU hog since the data to be processed isnt so big.
Well, having such a "lazy" LCD it really doesnt justify the usage of a high speed controller for accessing it (in case of Spacepilot), anyway it seems that you, as a software developers, are constrained by the hardware limitations of the used parts.It's not the interface in the PC, it's the interface on the USB chip inside the device. These hardware decisions get made WAY in advance when a chip gets picked and the firmware gets written.
Maybe in the future (for new products) the hardware designers from 3dconnexion should use a low responsive LCDs (maybe even color LCDs) since they are pretty cheap. This will give you a lot of freedom as software developers and new oportunities to make a complete and a 24/7 useful device.
I hope that you got my ideas, having a device that it is still useful even when you are not using it for what it was designed could be an acomplishment towards the end user. It's like saying "Hey, this device its really useful even if i dont have my hand on it or using it in my favorite 'insert random 3D app', it earned the rightful place to be on my left side of keyboard, permanently"
I belive i can call it a success
I've used portions of HIDRezero for detecting the Spacepilot and getting the device path & handle.
Now im implementing the display function which is pretty easy knowing what to do.
As a funny thing the leds are 4 grouped as 2 and can be litten individually (the groups) ,each group being controlled by a bit , first bit ->first group , second bit -> second group ,third bit -> third group , forth bit -> forth group... and combinations; Also as a funny thing the Spacepilot have a internal uptime clock that can be accessed using feature 0x10( if I remember correctly).
For now I'm planning to use in memory monochrome bitmaps so I can use the GDI for drawing pixels/lines/text. After -> device drawing optimisations.
I've used portions of HIDRezero for detecting the Spacepilot and getting the device path & handle.
Now im implementing the display function which is pretty easy knowing what to do.
As a funny thing the leds are 4 grouped as 2 and can be litten individually (the groups)
,each group being controlled by a bit , first bit ->first group , second bit -> second group ,third bit -> third group , forth bit -> forth group... and combinations; Also as a funny thing the Spacepilot have a internal uptime clock that can be accessed using feature 0x10( if I remember correctly).For now I'm planning to use in memory monochrome bitmaps so I can use the GDI for drawing pixels/lines/text. After -> device drawing optimisations.