Overclock.net banner

A wireless mouse faster than Logitech's wired ones? Oh yes!

30K views 90 replies 42 participants last post by  qsxcv 
#1 ·


mouse:

parts: torq x5l shell, top part of torq x5l pcb, d2f-f-3-7's, pmw3366 board from a g502, adafruit fpc stick, nrf24l01+ mini module, teensy2.0, adafruit 150mah lipo battery and switch, lots of wire and kapton tape, superglue and sugru in various places

receiver:

small protoboard from fry's, teensy2.0, nrf24l01+ module

weight: 84.5g

i removed all side buttons and also other various parts of the shell.

button latency:
wireless vs my modded g100s (wired):

g100s_teensy_r_vs_x5l_teensy_l.txt 4k .txt file

avg: 0.342ms slower

wireless vs g303:

g303_r_vs_x5l_teensy_l.txt 4k .txt file

avg 4.98ms faster

motion latency:
well i don't have logitech's rig, and mousecomparator/tester is only precise/repeatable to around 1ms or so. but i can directly measure the timing between the sensor communications and the usb stuff on the oscilloscope.
my wireless thing:

g303:


synchronization to usb frames:
Quote:
Originally Posted by CPate View Post

It's theoretically possible make a nicer-looking plot by doing things differently, but this has the consequence of a drastic decrease in battery life. So that's not what we did.
Quote:
Originally Posted by CPate View Post

can't you just have the wireless receiver send a packet every 50 usb frames or so to keep the main loop of the mouse firmware in sync? something like a phase-locked loop
i don't see how that affects battery life significantly
well idk if logitech has tried this yet, but i did and got it within ~1us
tongue.gif

https://vid.me/vjiD
here, the oscilloscope is triggered by sensor communication in the main loop. the yellow trace is the usb D+ line from the receiver. i can explain in greater detail how it works but it's not very interesting.
and of course it's perfectly stable in mousetester
mj7zIK7.png


battery life:
unknown right now. probably around 3-4hrs. i haven't optimized for power consumption yet. after doing that i'd expect the current draw to be ~25mA when the sensor is tracking, so around 6 hours of continuous use with the 150mAh battery. adding in idle modes should make it good enough that i would only need to charge it overnight.

once i do that and clean things up a bit more, i'll post the firmware (pm me if you want what i currently have)

wireless performance:
well... i can't really test it but
1. in usual circumstances where the receiver is only a few feet away, it never drops packets. (or at least i don't see any from a 30s interval plot in mousetester)
2. the mouse sends absolute coordinates to the receiver, so even a packet is dropped, there is no drift. if you were to do logitech's circular motion test on this with lots of background 2.4ghz stuff going on, the only issue would be that the circles might show some flat sides due to the dropped packets, but it won't show jumps like the mamba 2015 (http://www.pcper.com/news/General-Tech/Just-Delivered-Logitech-G900-Chaos-Spectrum-Wireless-Ambidextrous-Mouse)
3. the channel it uses is hard-coded, whereas i'd expect the g900 to be more robust and automatically select the best channel or something.
 

Attachments

See less See more
9
#9 ·
Quote:
Originally Posted by Melan View Post

Neat. +rep

Now if someone would employ him to make mice (looking at you Logitech), or at least help him build an actual pcb without this wired mess and jury rigging along with some shell.
None of the companies want to release the best mouse possible.

They want to release something that is slightly better than last years model, and continue iterating on that for the next 5 years until they finally arrive on what they already know is their end goal for that series. Gives them plenty of time to think of "the next big thing" to market and stretch out over another 5 years.

If they jumped straight to the best now, it would:

A) Be very expensive and not many people would buy it.
B) They would have to actually compete against each other on durability rather than looks, as nothing significantly better would come out for a while, and longevity would suddenly become a much more relevant aspect of mice.
C) The result of B would be a lot less mice sold over the next several years due to current one not breaking down.

Great for consumers, sure, but awful for manufacturers.
 
#14 ·
Quote:
Originally Posted by SmashTV View Post

Quote:
Originally Posted by qsxcv View Post

what's stock?
Quote:
Originally Posted by trism View Post

Probably means the Logitech's 750 mAh.
This.
see estimates in op, multiply by 5.
after optimizing the firmware for power it should be similar to g900, because the bottleneck is the 3366 consuming ~20mA
 
#16 ·
Quote:
Originally Posted by Zero4549 View Post

None of the companies want to release the best mouse possible.
This is true for a lot of things especially cell phones

Like the Nexus 6p is jam packed with features.. But oh hey no battery removal and no micro SD card because people don't want that heh..

But uh I'll be honest using the g900 the only thing the mouse has that I consider not great is the mouse feet unless I got a defect cause just 3 weeks in and my feet are all spotty/rough/ worn looking. Like in terms of quality and features I don't feel anything was taken away. Battery life is long, tracking is great, build feels great, software works good.. It's the best all around I've used since the beginning.

Great job as though this is super impressive. Maybe you'll get to the point where you can make your own mouse and begin selling it
 
#17 ·
Quote:
Originally Posted by ncck View Post

Maybe you'll get to the point where you can make your own mouse and begin selling it
obviously he is skilled enough to take care of (at least) one aspect of a mouse, but:
Quote:
Originally Posted by qsxcv View Post

idk... i can't see myself actually doing this stuff for a living
tongue.gif
and imo, it would barely be worth it if the rest of the mouse wasn't of the same high quality as whatever qsxcv himself could provide.
think CAD, tooling, materials, components, PCB..

suppose he'd be interested in making such a mouse - it would probably need to get funded by pre-orders or by getting some company involved. getting another company involved would most likely mean a loss in quality and a gain in useless features. (and an ugly logo on your mouse.)
funding by pre-orders might work (probably not), but in that case i think marketing would be pretty hard, and i can imagine that prototyping would't exactly cheap.

neither option sounds realistic to me. there's probably a reason why even the known companies outsource almost everything and cheap out on almost everything.
 
#20 ·
Nice Oscope. I hope to upgrade to a quad-channel RIGOL some day...

How is switch bounce accounted for, both in the test setup and the software? It looks like a super clean signal on the scope, and my amateur implementations at button debounces usually take a few ms to complete proper, so I'm wondering if the mouse S/W handles it? Also, do you plan on releasing the code for the micro-controller?

Now I'm all curious; as if I have time to start another project! Good work!
 
#21 ·
Quote:
Originally Posted by steezebe View Post

How is switch bounce accounted for, both in the test setup and the software? It looks like a super clean signal on the scope, and my amateur implementations at button debounces usually take a few ms to complete proper, so I'm wondering if the mouse S/W handles it? Also, do you plan on releasing the code for the micro-controller?
yes i'll release the code later after cleaning it up and optimizing for power.

the scope pictures are the signal on a debug pin, not the switches.

for debouncing, in words, how it works is:
1. if button is pressed, register it immediately.
2. if button is released, only register a release if it remains in the released state for X ms.
so there's absolutely no debounce related latency for presses, and X added latency for releases.
 
#22 ·
Quote:
Originally Posted by qsxcv View Post

yes i'll release the code later after cleaning it up and optimizing for power.

the scope pictures are the signal on a debug pin, not the switches.

for debouncing, in words, how it works is:
1. if button is pressed, register it immediately.
2. if button is released, only register a release if it remains in the released state for X ms.
so there's absolutely no debounce related latency for presses, and X added latency for releases.
That's cool. So if someone is spam clicking it'll never register the release until they haven't clicked for say 400ms?

Is there any problems or does that work perfectly?
 
#23 ·
yes except i use X=16ms

old logitech (like g100s) does this with X=20ms
new logitech (g502/402/302/303/900) does something similar, i think it's like only register a click if it's been down for 4ms, only register a release if it's been released for 20ms

and of course the most common method is to use the same number for both clicks and releases.
 
#24 ·
wouldn't it be possible to have software + on-board memory to set the debounce time? i wondered why i've never seen a mouse that offers this possibility, i imagined it wouldn't be hard to have a slider or a numeric input field to set it.
it seemed like an easy way to fix potential debounce issues to me - anyone experiencing clicking issues could just be suggested to increase the debounce time a bit.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top