Overclock.net - An Overclocking Community - Reply to Topic

Thread: Progress on a fully custom mouse. Reply to Thread
Title:
Message:

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in


  Additional Options
Miscellaneous Options

  Topic Review (Newest First)
06-24-2019 12:28 PM
gipetto I seriesed a 100k pot with the 10k resistor and it is more responsive. It turns out the keyboard backlight was swamping the detector. The advice was helpful, thanks.
06-24-2019 11:43 AM
TranquilTempest If you're not using an opamp, you'll want a higher value resistor. If your meter has a microamps range, measure the light vs dark current with the 10k resistor in place, then select your new resistor to give the appropriate voltages at those currents.

If your meter doesn't have that range, try ~470k, and go up or down from there.
06-24-2019 11:29 AM
gipetto I got the photoreflectors in the mail today, and followed the example 10k pullup circuit for the detector(emitter to ground). I can only get one tenth of a volt of a swing from 4.7v down to 4.6v or so. I tried reversing polarity of the detector but that seemed to completely cook it, even after reverting the polarity there was no voltage swing.
06-16-2019 11:53 PM
qsxcv that's interesting. in that case that would be what you want to do.

i had in mind kailh encoders (e.g. pg 4 of http://www.kailh.com/pdf/CEN989012R20-1.pdf) where both A and B edges are near the middle between two detents
06-16-2019 11:43 PM
TranquilTempest I was doing my debouncing separately, the most significant bit of DebounceA and DebounceB is the output of that. With the encoder I'm using, B is undefined at the bottom of the detent so I don't want to scroll on changes in B, just use it to determine direction (bottom left of first page): https://www.mouser.com/datasheet/2/15/EC10E-1370735.pdf
06-16-2019 10:13 PM
qsxcv oh thats a nice way

but you'd want something like this
0100: 1
0111: -1
1011: 1
1000: -1
to have some hysteresis for debouncing
06-16-2019 04:11 PM
TranquilTempest I think I can explain my code a bit better.
Start by counting 0 to 15 in binary

You have four bits in this order: OldA OldB NewA NewB
When A and only A changes, output the appropriate value by looking at the encoder diagram (you can use B but you'd be able to scroll a line without moving encoder to next notch) If A is changing to match B scroll one direction, if A is changing to be different than B scroll the other.

0010: 1
0111: -1
1000: -1
1101: 1

Fill in the rest of the values as 0, and that's where the look up table comes from.
If you want to reverse the direction just subtract it from your scroll variable instead of adding it, or change the signs.

So basically it does the same thing as any other quadrature decoder. The difference in performance is probably negligible. In principle I'm trying to make the loop time as consistent as possible, so that I can delay sensor and switch reads to immediately before the USB ISR. So instead of conditional code I try to use fixed code with conditional effects.
06-16-2019 03:30 PM
gipetto I shouldn't be putting my foot in it, as I barely understand the code, which gets harder as I age. Yours is a well documented method I have seen explained on different sites though, you're just checking whether the second channel lags the first or vice versa.
I brought up the subject of wheel code because I made a homebrew s/r latch wheel encoder which didn't develop bounce, therefore it would be possible to try out alternative code methods to extend mouse life. There is a picture of it back the thread, although the optical part is not completed yet.
It's not necessary for most games and many small GUI menus to use both directions of wheel rotation, merely to iterate along them. csgo for instance only uses I think 3 items on the wheel so there's little difference which way you rotate it. I wouldn't have bothered except as a way to add redundancy.
06-16-2019 03:08 PM
qsxcv i haven't read in detail what you guys are doing, but for quadrature outputs (which is what all mechanical encoders do afaik), you realize that if one of the outputs fail, there's absolutely no way to distinguish up and down

Quote: Originally Posted by gipetto View Post
qsxcv' s code although efficient is unintuitive.
uhm, thanks? lololol
the way i do it (in e.g. https://github.com/qsxcv/avr_wireles...r/mouse/main.c), if one of the pins gets stuck, no scrolling will ever happen. actually this is the only correct way to do things, since to the mcu this situation simply looks like bouncing near one of the transitions, which of course should be ignored

and my wheel code does not look symmetric (in the sense that the variable whl_a appears more often) but it is functionally symmetric
similar to how
if x == y:
z = x
does not look "symmetric"
but does exactly the same thing as
if x == y:
z = (x+y)/2
06-15-2019 11:46 AM
gipetto Indeed. I would agree with you except I have seen it happen when one channel burned out using the optical ball mouse photodetector, you could toggle the wheel and the page would scroll continuously. not sure what was going on there, because the code was unmodified from bst_public. The code itself could be symmetrical in theory, as it is equivalent to swapping the pins to reverse the wheel, even if the wheel mechanism itself is not symmetrical. I guess it is a compromise between fail safe and fail secure. can't have both without changing the code.
This thread has more than 10 replies. Click here to review the whole thread.

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off