Progress on a fully custom mouse. - Page 12 - Overclock.net - An Overclocking Community

Forum Jump: 

Progress on a fully custom mouse.

Reply
 
Thread Tools
post #111 of 130 (permalink) Old 06-15-2019, 03:46 AM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,685
Rep: 78 (Unique: 63)
Looks interesting, curious how it will feel when installed in the mouse.

On my end I'm slowly making progress on the firmware. Currently writing the scroll wheel and setup functionality. I think I'm not going to use the DPI buttons behind scroll wheel, but a third thumb button in combination with the scroll wheel.

To handle quadrature decoding I'm using a lookup table instead of conditional logic:
Code:
	int8_t EncoderLUT[] = (0, 0, 1, 0, 0, 0, 0, -1, -1, 0, 0, 0, 0, 1, 0, 0); //create table by counting from 0 to 15 in binary, and moving in the appropiate direction when A changes but B doesn't.
...
		EncoderState = EncoderState << 2; //shift left 2 0b00001011(11 in decimal) becomes 0b00101100(44 in decimal)
		EncoderState += DebounceEncoderA >> 6 & 0b00000010; //second to last bit becomes new value of encoder A. (if DebounceEncoderA is 128 or greater, add 2 to EncoderState)
		EncoderState += DebounceEncoderB >> 7 & 0b00000001; //last bit becomes new value of encoder B (if DebounceEncoderB is 128 or greater, add 1 to EncoderState)
		EncoderState = EncoderState & 0b00001111;// clear all except last four bits, which results in a number between 0 and 15.
		Scroll += EncoderLUT[EncoderState]; use that number to look up the corresponding entry in the table

it should work, but I haven't tested it yet.


Last edited by TranquilTempest; 07-15-2019 at 10:24 PM.
TranquilTempest is offline  
Sponsored Links
Advertisement
 
post #112 of 130 (permalink) Old 06-15-2019, 09:16 AM
New to Overclock.net
 
gipetto's Avatar
 
Join Date: Jun 2017
Posts: 493
Rep: 9 (Unique: 7)
It could use some comments so other people( like me) could understand it. I like how the encoder code is symmetrical, shows a natural design. qsxcv' s code although efficient is unintuitive. if i was to rework the code for my wheel I would like if one channel failed, the wheel would rotate in one direction only, if the other channel failed it would rotate also in one direction. currently that failsafe mode only works on one channel as I understand it.

I am delayed again because I have to re-order atmega32u4 chips with a bootloader. I had escaped until now without having to learn what one was.
gipetto is offline  
post #113 of 130 (permalink) Old 06-15-2019, 09:41 AM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,685
Rep: 78 (Unique: 63)
Quote: Originally Posted by gipetto View Post
It could use some comments so other people( like me) could understand it. I like how the encoder code is symmetrical, shows a natural design. qsxcv' s code although efficient is unintuitive. if i was to rework the code for my wheel I would like if one channel failed, the wheel would rotate in one direction only, if the other channel failed it would rotate also in one direction. currently that failsafe mode only works on one channel as I understand it.

I am delayed again because I have to re-order atmega32u4 chips with a bootloader. I had escaped until now without having to learn what one was.
Added some comments, as for failure of A vs B, if A fails completely the wheel will stop scrolling completely. If B fails the wheel will scroll back and forth one step. This is because steps are only counted for A, as B isn't in a known value when the scroll wheel is in a resting state(A changes at the peak of the detent, B changes in the valley of the detent). Not sure how you could tell the difference between one channel failing, and the user just fidgeting with the wheel.


Last edited by TranquilTempest; 06-15-2019 at 10:07 AM.
TranquilTempest is offline  
Sponsored Links
Advertisement
 
post #114 of 130 (permalink) Old 06-15-2019, 11:46 AM
New to Overclock.net
 
gipetto's Avatar
 
Join Date: Jun 2017
Posts: 493
Rep: 9 (Unique: 7)
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.
gipetto is offline  
post #115 of 130 (permalink) Old 06-16-2019, 03:08 PM
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,202
Rep: 363 (Unique: 150)
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

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #116 of 130 (permalink) Old 06-16-2019, 03:30 PM
New to Overclock.net
 
gipetto's Avatar
 
Join Date: Jun 2017
Posts: 493
Rep: 9 (Unique: 7)
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.

Last edited by gipetto; 06-16-2019 at 03:47 PM.
gipetto is offline  
post #117 of 130 (permalink) Old 06-16-2019, 04:11 PM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,685
Rep: 78 (Unique: 63)
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.

TranquilTempest is offline  
post #118 of 130 (permalink) Old 06-16-2019, 10:13 PM
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,202
Rep: 363 (Unique: 150)
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

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #119 of 130 (permalink) Old 06-16-2019, 11:43 PM - Thread Starter
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,685
Rep: 78 (Unique: 63)
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

TranquilTempest is offline  
post #120 of 130 (permalink) Old 06-16-2019, 11:53 PM
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,202
Rep: 363 (Unique: 150)
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

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
Reply

Tags
custom , modding , mouse , pcb , shell

Quick Reply
Message:
Options

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



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

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
Trackbacks are Off
Pingbacks are Off
Refbacks are Off