h a l f b a k e r yThis product is not intended to diagnose, treat, cure or prevent any disease.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
This pointing device consists of an X-axis and a Y-axis vertical slider, either along the side and top of a slanted screen or horizontally arranged, for instance in a T-square like arrangement. Both sliders are identical. Each consists of twelve parallel conductive tracks, painted over at intervals
with an insulator, so that each has a twelve-bit binary pattern corresponding to an unsigned binary integer, arranged in sequence from all bits clear to all bits set. The thing which is actually slid consists of twelve conductive contacts running along the tracks. Where the insulator is absent, a circuit is closed. This presents a twelve-bit number indicating the position of the slider, which is interfaced to a computer via a twenty-six bit parallel interface. The extra two bits are set or cleared by pressing buttons corresponding to left and right mouse buttons. Operating the X and Y sliders moves a cursor on along the X and Y axes of a display in order to place it in any one of around sixteen million positions in a grid on the display, like a mouse.
This is a straightforward way to achieve a binary representation of the position of a cursor, like a mouse or other pointing device. Possible improvements could include two transparent sticks crossing at the position corresponding to the cursor which can be moved in order to move the cursor.
An alternative would involve a series of black and white strips on a transparent surface, illuminated from below and detected by a row of twelve photocells on the movable part of the device.
Also wondering if Gray code is useful here.
A further alternative would be to roll the whole slider up and put it on a rotary encoder-style device, enabling a genuine mouse to be constructed, but it would be very fiddly.
Another issue with this is that i'm pretty sure PS/2, USB and serial interfaces don't read a twenty-six bit code indicating the position of the mouse.
Quadrature Decoder
http://www.fpga4fun...dratureDecoder.html
How mice do it [Wrongfellow, Jun 27 2011]
[link]
|
| |
//Also wondering if Gray code is useful here.// |
|
| |
Yes, a Gray code will be perfect for this device. |
|
| |
//Another issue with this is that i'm pretty sure PS/2, USB and serial interfaces don't read a twenty-six bit code indicating the position of the mouse.// |
|
| |
That's not a major problem - converting your 26 bit code to something the computer will understand is relatively simple - it's certainly trivial compared to implementing the rest of the USB stack. |
|
| |
In that case, i think this'll be a PS/2 or RS232 device. |
|
| |
some kind of countinuouoss dampening /
capacitor circuit, addedd to the sideline of such a
yield, will lessen digital requirements, and
increasing direct measure control. |
|
| |
I, personally, did some quality insurance /
assurance , calculations, of a digital counter /
rotational encoder, for a power / torque
measurer', based around a regular 1 Mega Cycle
CMD=64 Commodore, in the years of my Student's
Hat' / Engineering college' day's, and as I got it
from these calculations, a More Than 32.000 lines /
per 360 degrees',, rotation angle encoder
(incremental, one diemension (forward, round),
was to be required, in order to have absolute
quality of say plus minus 2-5 percent. |
|
| |
This was based on an assumbtion, that One Pulse,
from the encoder, going to the Counter' (not The
Bar,, :-) or The Caffeteria')), Port, would 'slip' or
'enter', into the counter. |
|
| |
I don't know the specifics of Digital Counter's,
even today, all that they are accumulating, in
interger numbers. The thing was then, that a
read, from the bus, would somehow, interfere, or
cancel, Just One Pulse, from the Encoder,
connected to the Rotating Lines' spread,. |
|
| |
The economics, of it then, was reduced to a
choice of building a entire engine stand, and
additionally, aquiring' a 3.200,- kroner danish / like
5-600 USD'ollar's,. ,, Hellicopter encoder, found
somehow in a catalogue, of sorts, from a Local
Representative. |
|
| |
This was ballanced out, as to just 'buy' 'rulle-felt'
time, that is, the now wide spread auto wheel-to-
roll's of mass inertia/speed shops, instead to have
an entire assembled car, as opposed to the 'naked'
engine,. |
|
| |
BIT - To - BIT exchanges, are very simply solved in
cables, I think. |
|
| |
Not that it's required for this site, but why? What's
the advantage over a traditional mouse? |
|
| |
the 102nd use for chopsticks ? |
|
| |
[Sirau], admirably detailed response from which i
will withhold comment until i have the time to
give you the attention you deserve. |
|
| |
[MechE], as usual my motivations are that i want
control while minimising expense and arcane
resources and maximising user-serviceability.
From taking mice to bits, they often seem to rely
on cogwheels interrupting an LED to count the
movement of the mouse ball, though how they do
the direction is another concern. The advantage
over other pointing devices is that to me, this
makes sense and resembles something i could
actually make myself. I'm not sure how closely
because it would seem to involve very precise
painting of insulator or opaque medium - two
thousand odd evenly spaced blobs of paint would
take a very steady hand. |
|
| |
Also, i have a distaste for rotation. |
|
| |
I like the directness of encoding every single bit in hardware like this, but it could be simplified to 2 tracks per axis, arranged as follows (vertical axis): |
|
| |
repeating as often as needed, where · = non-conducting, | = conducting (effectively, a 2 bit Gray code). |
|
| |
A counter circuit would keep track of the actual position. You would still need to calibrate it for zero, but that could be done by providing an extra contact that resets the counter to zero when the slider is moved to the extreme left / top position. The encoder would then need to be powered, which might be a deal-breaker for your purposes. |
|
| |
If you want, you could still realise the bits as hardware switches (relays), but you would only have to do it once, rather than 4096 times. |
|
| |
It's possible that [sirau] said the same thing, but I can't quite tell. |
|
| |
Woah, brain processing intensity requirement right
now! Thanks. |
|
| |
OK, an advantage of a rotational version is that
there can be fewer codes per sensor (if that's the
word). It can just keep cycling through them as
the mouse or trackball is slid about. The counter
circuit is what scares me. I can visualise, just
about, what that would be in terms of logic gates
and then i come to wonder of what i'm supposed
to build the gates. Relays maybe? Thermionic
valves are right out because a vacuum pump is a
rather difficult machine to make. There is no
precision engineering here. I can maybe solder
and do the kind of fine work a watchmaker or a
jeweller could, but the likes of making a vacuum
pump is probably beyond me, so the options are
fluidic or relay-based logic gates, and a counter
circuit made of those would be big and subject to
failure. |
|
| |
//From taking mice to bits, they often seem to rely on cogwheels interrupting an LED to count the movement of the mouse ball, though how they do the direction is another concern.// |
|
| |
As if by magic, a link appeared! |
|
| |
//OK, an advantage of a rotational version is that there can be fewer codes per sensor (if that's the word).// |
|
| |
Usually four. The link explains all! |
|
| |
To be honest i did think about a potentiometer,
which has the advantage of being readily available
and salvageable from an old radio or hi-fi, but i was
also expecting analogue to digital conversion to be a
bit of a tall order without integrated circuits. |
|
| |
Try not to get mired in those little details, you can buy an off-shelf microcontroller that accepts the x-y inputs and has built-in USB communication. Easy peasy. |
|
| |
More worthwhile of discussion in my opinion are the practical applications this would have compared to a mouse. And would it have force feedback? |
|
| |
Well for a start, whereas there are of course digitisers and light pens, attempting to draw with a mouse is like drawing with a boulder. It's easier to be precise with this than with a mouse, it could be used better as a seeker on video and audio files, as a volume control and for scrolling through a large document such as a book quickly. It also somewhat resembles an Etch-A-Sketch. Another example: if you were using this with Google Earth or Celestia, it could be used to spin a globe in a way which is closer to spinning an actual globe (though not so much as a trackball would be). In fact, any occasion on which a slider control is used in a GUI, this would be a direct analogue. I suspect that happens less often with a mouse. |
|
| |