Turn a PC mouse into a Speedo

noxorc · Post by **noxorc** » Thu Jul 03, 2003 8:19 pm

now I'm getting bogus results.
big motors are showing shorting distances. slow motors longer.

I think the mouse decoder isn't that fast at reading, so it's skipping.

-nox

ph2t · Post by **ph2t** » Thu Jul 03, 2003 9:56 pm

Yeah nox that's what I found with my tests. Moving the mouse across the screen at a "slow" rate gave me value X. Moving the mouse across the screen at a "fast" rate gave me value Y. The distance moved each time was approx equal (give or take 1/2 an inch). Y was less than X.

I will do some more testing this weekend mate.

Oh yeah, this was done on an older version of the sw. The new version reports FAULT if I try this method which I guess makes sense given that the encoding wheel is changing direction....

ph2t.

noxorc · Post by **noxorc** » Sat Jul 05, 2003 9:06 pm

ph2t wrote:Yeah nox that's what I found with my tests. Moving the mouse across the screen at a "slow" rate gave me value X. Moving the mouse across the screen at a "fast" rate gave me value Y. The distance moved each time was approx equal (give or take 1/2 an inch). Y was less than X.

I will do some more testing this weekend mate.

Oh yeah, this was done on an older version of the sw. The new version reports FAULT if I try this method which I guess makes sense given that the encoding wheel is changing direction....
ph2t.

I don't know about older versions of Windows, but XP lets me change the sample rate. But at best it's 200 per second.
Which ain't enough.

This project might not be based on current mousez (or atleast based on MS's driver inbetween us). (the big bastard).
(lucky, I can write ass to.)

ph2t · Post by **ph2t** » Sun Jul 06, 2003 5:35 am

Maybe we need to put a gearing reduction set in between the car and the mouse encoder wheel so that even the fastest motor doesn't cause the sampling to drop out. You could then mod your program with the correct maths to account for the ratios from the reduction gearing.

noxorc · Post by **noxorc** » Sun Jul 06, 2003 8:23 am

ph2t wrote:Maybe we need to put a gearing reduction set in between the car and the mouse encoder wheel so that even the fastest motor doesn't cause the sampling to drop out. You could then mod your program with the correct maths to account for the ratios from the reduction gearing.

been there...thought of that...

Problem is, I'm not a watch repair expert.
I've tried to put a couple of idle gears together, without luck, slipage.
the motors really crank. I'm thinking more on the lines of MODing a old style wind clock.
Or atleast get the motor in the gears working. Then even with a stop watch.
record how long it takes to move the big hand some distance.

Would like to stay electronic...but have to investigate some more.

-NoX

ph2t · Post by **ph2t** » Sun Jul 06, 2003 9:38 am

noxorc wrote:Would like to stay electronic...but have to investigate some more.
-NoX

That's some serious can of worms, I'll investigate and see what I can come up with. If this was to happen what port on the PC would you prefer your "speedo software" to read? The Serial? Parallel? PS2?
Which one offers the best sample rates?

ph2t.

noxorc · Post by **noxorc** » Sun Jul 06, 2003 12:31 pm

I guess I would say parallel, cause I could steal my own software from NoxBox.

I'm sure the sample rate is much greater, since it's not a human interface device.

hogjowlz · Post by **hogjowlz** » Sun Jul 06, 2003 2:22 pm

what about usb?

ph2t · Post by **ph2t** » Sun Jul 06, 2003 6:04 pm

hogjowlz wrote:what about usb?

A USB mouse does offer a faster sample rate, definately more than PS2 & serial, but I think the issue that Nox is stating is that the sampling rate is limited by the driver software used by the OS for the mouse interface.

Again, *I think*

. Nox will correct me I'm sure.

ph2t.

noxorc · Post by **noxorc** » Sun Jul 06, 2003 9:09 pm

that is correct...that is my point.

thanks Ph2t.

-nox

ph2t · Post by **ph2t** » Sun Jul 06, 2003 11:11 pm

Nox, I'm investigating some opto-sensor based circuits that count a value based on LED/Sensor pair. When the beam is broken the count is registered. This can be fed though a series of Divide-by-10 counters to get the sample rate down to the printer port limit (whatever that is).

This is still at the concept/functional stage, gotta do more research over the next few days.........

ph2t.

ph2t · Post by **ph2t** » Mon Jul 07, 2003 7:08 am

Just with quick update. I ripped open a mouse and put the rear tyre up against the encoder wheel and then ran the programs I've linked in my first post in this thread. The programs dropped all values and didn't read anything. Only when I removed the spinning tyre from the encoder wheel did the software start to register values, as the encoder wheel slowed down......

Big Scary wrote....
This project might not be based on current mousez (or atleast based on MS's driver inbetween us). (the big bastard).
(lucky, I can write ass to.)

Could you write a driver that had a higher sample rate?

ph2t.

noxorc · Post by **noxorc** » Tue Jul 08, 2003 6:41 am

don't know, but I think so.

I don't know the hardware logic for the standard parallel port.

but having a program monitor the pins, is done.
now, how fast can you flip the state (0 or 1) and back and notice.
I don't know.
but considering it's the parallel port and handshaking between two
computers. I'm sure it's fast. (faster than humans)
but question is slower/faster than a R/C motor @ 40,000 rpms.

if you can drive the pin on a parallel port, say pin 2.
On/Off based on the decoder wheel of the new device.
then we are in good shape.

-nox

ph2t · Post by **ph2t** » Wed Jul 09, 2003 9:56 pm

So pin 2 is DATA 0 on the parallel port. As long as I can flip it's state
you can capture the data, cool. Did some investigation but couldn't find
anything about sampling rate.
Found
this handy site.

I was investigatibg using a Hall effect sensor like this one
HERE. I was still going to use the encoder wheels on the mouse, actully the whole base is still being used but I've rip the pcb out of the mouse. All that's left is the bottom half of shell with the 2 encoder wheels stuck in place.

Gotta do some more work on the design.

ph2t.

ph2t · Post by **ph2t** » Wed Jul 09, 2003 9:58 pm

Another idea is to remove the encoder disk from it's axle and attach it to the other side of the other encoder disk/axle. This way you can have both rears tyres in contact.

ph2t.