Jumpy readings from Space Navigator using DI8 (Direct Input)

Post questions, comments and feedback to our 3Dconnexion Windows Development Team.

Moderator: Moderators

timcoolman
Posts: 7
Joined: Mon Apr 11, 2011 10:04 am

Re: Jumpy readings from Space Navigator using DI8 (Direct In

Post by timcoolman »

Thanks to your help I now have smooth movement with the Space Navigator.

I ended up going the route of polling at a faster rate (~90 Hz) and ignoring all zeros until they had repeated for more than 0.02 seconds. Since you say the device should run at 60 Hz, that should be enough time to be certain that device isn't simply between polls. To ensure the 90 Hz polling rate I placed the polling code on a separate thread; unexpected frame rate lapses in my main program loop shouldn't cause inconsistencies this way.

I can't be certain this was a necessary change, because in the process of implementing this I had to work out multiple bugs to eliminate choppy behavior, but I also ended up separating out my "all-zero tracking" into two parts. One for translation (lX, lY, lZ) and one for rotation (lRx, lRy, lRz), much like was done in the event-handling sample you referenced. Again, I am not 100% positive about this, but it SEEMED that with the fast polling, I was getting each set of three values from different Poll() calls. So if I were to accept ALL values from the JoyState when just one of the values was non-zero, then I was likely getting all zeros for the other set of three values (I hope I'm making sense here). By evaluating the triplets separately, I was able to only update the legitimate values and still use a timer to know when zeros had persisted long enough to accept as real values.

Thanks again for all your help!
ngomes
Moderator
Moderator
Posts: 3321
Joined: Mon Nov 27, 2006 7:22 am
Contact:

Re: Jumpy readings from Space Navigator using DI8 (Direct In

Post by ngomes »

Good stuff, timcoolman. Glad to see that you sorted out the issues (and kept your dependencies to a minimum).
ignoring all zeros until they had repeated for more than 0.02 seconds.
20 ms is on the short side. That's basically a one or two packet period (depending on device). You should up that to 100ms. Users won't be able to tell and you will also filter out the odd zero event that can be triggered if the user moves the cap along a direction that intersects the device "rest" position.
Post Reply