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-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.
06-15-2019 09:41 AM
TranquilTempest
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.
06-15-2019 09:16 AM
gipetto 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.
06-15-2019 03:46 AM
TranquilTempest 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 0x00001011(11 in decimal) becomes 0x00101100(44 in decimal)
		EncoderState += DebounceEncoderA >> 6 & 0x00000010; //second to last bit becomes new value of encoder A. (if DebounceEncoderA is 128 or greater, add 2 to EncoderState)
		EncoderState += DebounceEncoderB >> 7 & 0x00000001; //last bit becomes new value of encoder B (if DebounceEncoderB is 128 or greater, add 1 to EncoderState)
		EncoderState = EncoderState & 0x00001111;// 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.
06-07-2019 09:50 AM
gipetto I got the hybrid wheel pcb in yesterday. feels good, very close to an alps scroll wheel, although a little harder. the tips of the cog teeth are flat, so ideally they would be pointed so that the wheel doesn't get stuck in between clicks. It does snap back into position when moved a little though. I used same width spokes, not sure if that was a bright idea as gray codes are tapered. I can see it being a success as even at this stage there is no axle play like there would be on an ec10. I wouldn't scale up to 16 tooth without making the wheel larger. I'm still thinking about how to mount it in the io1.1.
06-05-2019 07:53 AM
gipetto I got in some cheaper level converters today from aliexpress which I shouldn't have bought, due to the chance of being clones. I tried soldering them, hard to see if they were successful, even with the free magnifying glass that came with the pcb. some of them took a few tries, i may have killed them with heat.
06-05-2019 07:23 AM
TranquilTempest Ah, I'm using Hakko tips with a cheap clone station. The clone tips I've noticed are too loose, they don't get good contact with the heating element. With conical tips I've had better luck bending them into an elbow shape, but sometimes that damages the plating.
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