|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|
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|
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|
oh thats a nice way
but you'd want something like this
to have some hysteresis for debouncing
|06-16-2019 04:11 PM|
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.
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|
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|
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
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.|