• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 531
  • Last Modified:

How to do manual acceleration of custom USB mouse in embedded code / Windows XP?

I am using a miniature trackball TBWB2A00 (datasheet attached) for one of my console designs. I am using PIC18F4450 which takes the raw switch inputs from this trackball and sends it to the PC as an USB optical mouse.

The issue is the trackball has a click-click action as it is actually internally mechanical switches. So the user to browse a 1024 X 768 display would mean a huge amount of time and clicks making it cumbersome to use. So we thought of providing acceleration as in Windows XP - that is, when the user moves fast the cursor should also move fast.

But unfortunately I have not been able to do this. Following things I have tried out:

1) I have tried to sense the time interval between successive movements to get the acceleration but because the time interval is huge, I am unable to get any effect out of this.

2) I have tried to use WIndows acceleration adjustments (through registry) but this also has not helped.

Is there a good logic for implementing this through embedded code or through Windows XP?
  • 4
  • 3
1 Solution
The usual method is increase the step size by a factor k every N steps, as long as
the steps are going in the same direction.

You might set  k=sqrt(2) and N=3.  

If you're using a PIC, you might do better with a lookup table for step size:

 1  1  1  2  2  2  4  4  4  6  6  6  10  10  10  14  14  14  ...

If the ball changes direction, or sits for too long, you reset the step size to 1.
You may want different tables for each axis.

Figure out how many moves you want to take to cover your range, and adjust the
table accordingly.  You might also want to make the initial acceleration slower to
let you zero in on a point.

snavneethAuthor Commented:
Okay, thanks ........ I have been trying it but somehow not able to do it ....... The same direction thing I am able to implement (variable step size) ...... but the sitting too long (no movement) I am not able to sense ....... it always takes as no movement whatever count value I am trying to provide ....... any good method to sense no movement you can suggest would be very helpful ............
Presumably the outputs of the trackball are quadrature encoded:
i.e. two square waves/switches 90 degrees out of phase for each axis.

You have to process/debounce the signals in the PIC.
Do you know how to handle quadrature signals?

How fast can you move the trackball?  
Something like 1/3 to 1/2 of the circumference in a second?
How many switch clicks does that give you?
Certainly less than 1000/second.

The PIC should have no trouble with timing in the ms regime.
And it certainly shouldn't have trouble figuring out  if the ball hasn't
moved for 10 seconds.
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

snavneethAuthor Commented:
The signal handling part is working fine ....... it moves the cursor on the screen one pixel in each direction as per the movement .......

The trackball can be moved approx 1/3 of the circumference in one shot (fastest motion from one end to the other) ...... this would be approx 4 clicks i.e., 4 pixel movement ....... in other words around 4 clicks / second at the maximum. The issue is not too high but too low. And the other part is after the 4 click movement, there would certainly be a pause as the user to come back to the initial position to start rotating again.

Should I initiate another timer to sense the time between clicks? How much should I keep the timer interval?
That is a pretty small ball, and also a pretty small number of clicks per swipe.
So I guess you have to do this with a single finger, not the palm of your hand.

So maybe try doubling the step size every swipe/4 clicks.

1  1  1  1
2  2  2  2
4  4  4  4
64  64  64  64         <== Set some reasonable max speed.

For this arrangement, you would need 9 full swipes to get 1000 pixels:

   4 + 8 +16 + 32 + 64 +128 + 256 + 256 +256

That doesn't sound too bad.

I would expect you can get 2-3 swipes per second.  So the reset time
if the ball doesn't move should be on the order of 1 second.

The PIC should be able to buffer the ball motion, and send out single steps at a max rate of 1 kHz.
Reading over my comments, I see I could have done a better job.

The analysis and techniques I provided are appropriate.
Some psuedo code would have been helpful.

But I did stay with the questioner for three rounds of comments,
and it may have been enough for him to find a solution.
snavneethAuthor Commented:
Dear d-glitch,
Your comments were all fine and okay. I have just gone into PIC programiming and not an expert, some code from your side could have been helpful. I mean it was a bit impractical for me to implement as it started behaving very funnily by trying to implement the acceleration thing and the users felt very uncomfortable.

Anyways thanks for all the help provided and hope you would give comments when I post some other doubt on PIC. Thanks.

Featured Post

New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now