razer viper ultimate internal pics/technical info - Page 2 - Overclock.net - An Overclocking Community

Forum Jump: 

razer viper ultimate internal pics/technical info

Reply
 
Thread Tools
post #11 of 55 (permalink) Old 10-23-2019, 03:03 PM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,286
Rep: 370 (Unique: 153)
i looked through some of TheFiend's posts on reddit:

https://www.reddit.com/r/MouseReview...m_medium=web2x
Quote:
Sensor's variable framerate is "independent" of the motion-sync implementation and does not need to be in multiples of 1000... The only thing affected is read timing i.e. which frame is being fetched and sent to the PC . The SPI clock and the PC's polling tick are sync'd to within 1% timing, so the frame data fetched from the sensor is always in sync with PC's polling ticks.
so here the claim is that motionsync is synchronization of SPI and the USB polling.
i don't understand the "hardware implementation" whatever from the previous post. this is something to do with timing of the firmware of the mouse mcu.

in any case, with my mouse running whatever test firmware it is running, "motionsync" whatever it is, is not synchonizing SPI and USB in wireless mode. it appears that the mouse is running it's own 1000Hz loop, which is not synchronized with the USB polls of the receiver, and hence the tolerances in crystal oscillators (some parts per million) lead to the drift as seen in the video.

https://www.reddit.com/r/MouseReview...m_medium=web2x
Quote:
The framerate of the mouse is already several times higher than the polling rate and it doesn't slow down. Just the "input frame selection" is optimized (by syncing it to the polling tick).
https://www.reddit.com/r/MouseReview...m_medium=web2x
Quote:
No smoothing all the way from 100-20000 dpi, variable frame rate, mad responsiveness thanks to motionsync which ensures that your mouse mcu and PC polling ticks are in-sync and the PC gets the latest frame before the tick, and not some arbitrary frame in the last millisecond (or averages).
see, this all makes sense if the SPI and USB are synchronized. in that case, you could make sure that every time you read from the sensor, you do so right before a USB poll arrives. this means that the input lag due to the gap between when you read from the sensor and when a usb poll arrives can be stable and minimized (to the time it takes for wireless signal to be transmitted and processed, plus a few tens of us of overhead). this is exactly what TheFiend means in these two posts.

but in wireless mode, as shown in my video, SPI and USB are not synchronized and there is some slow drift. given this, the best case scenario is that the input lag of this gap now fluctuates slowly between x and x + 1ms, where x is (the time it takes for wireless signal to be transmitted and processed plus a few tens of us of overhead).

tldr: if the goal of motionsync is to ensure that when a usb poll arrives, the most recent (or as much as possible) data from the sensor is what is transmitted, this is NOT currently done by the viper ultimate in wireless mode.


anyway, at least it seems they understand the importance of this synchronization so hopefully they will fix this in a firmware update.
and just for the record, this doesn't really matter in practice and logitech's wireless mice have the same issues. it's more about achieving exact parity with wired mice


edit: TheFiend mentioned in an email that motionsync is something done by the sensor. i cannot make any sense of this unless the 3399 is doing something quite different from other pixart sensors. so i'll wait for him to clarify

in any case, since data from the sensor has to go through the mouse mcu via SPI before reaching the receiver, my point about input lag fluctuating between x and 1+x still stands.

too busy to check forums as regularly
pm me if i forget to respond

Last edited by qsxcv; 10-23-2019 at 03:26 PM.
qsxcv is offline  
Sponsored Links
Advertisement
 
post #12 of 55 (permalink) Old 10-23-2019, 03:27 PM
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,722
Rep: 78 (Unique: 63)
Maybe he's talking about synchronizing the motion processing within the sensor itself with the SPI reads? What are older sensors doing then?

TranquilTempest is offline  
post #13 of 55 (permalink) Old 10-23-2019, 03:31 PM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,286
Rep: 370 (Unique: 153)
Quote: Originally Posted by TranquilTempest View Post
Maybe he's talking about synchronizing the motion processing within the sensor itself with the SPI reads? What are older sensors doing then?
i checked with one probe on the spi clock and one probe on the sensor led cathode. like all other sensors, they run independently.

maybe they lock together in higher framerate modes once the mouse is in motion? not sure. (this would be a possible explanation for why the mousetester xcounts tends to be quite smooth)

but yes it would be a very cool thing if the sensor used the timing of SPI reads to determine the timing of frames. this solves the synchronization between sensor frames and SPI, but has no absolutely no bearing on the synchronization between SPI and USB polls.

too busy to check forums as regularly
pm me if i forget to respond

Last edited by qsxcv; 10-23-2019 at 03:34 PM.
qsxcv is offline  
Sponsored Links
Advertisement
 
post #14 of 55 (permalink) Old 10-23-2019, 04:59 PM
New to Overclock.net
 
NDUS's Avatar
 
Join Date: Feb 2017
Posts: 41
Rep: 1 (Unique: 1)
Quote:
in a wireless mouse, there are 4 things that have (potentially) independent timing:
1. sensor frames
2. sensor <-> mouse mcu communication (via SPI)
3. mouse mcu <-> receiver mcu communication (via the wireless)
4. receiver mcu <-> pc communication (via USB)
couldn't a manufacturer make synchronization of the third data handoff more practical by using a lower-latency wireless protocol than 2.4ghz? (like wigig/60ghz)
i thought wigig was invented for exactly this use case

Last edited by NDUS; 10-23-2019 at 05:08 PM.
NDUS is offline  
post #15 of 55 (permalink) Old 10-23-2019, 05:29 PM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,286
Rep: 370 (Unique: 153)
that's not a bottleneck in any case. in my diy thing, it the overhead is only 200us (see motion latency section of https://www.overclock.net/forum/375-...topics/1598978)

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #16 of 55 (permalink) Old 10-23-2019, 05:30 PM
New to Overclock.net
 
SmashTV's Avatar
 
Join Date: Sep 2014
Location: Innovation
Posts: 1,681
Rep: 55 (Unique: 43)
Quote: Originally Posted by qsxcv View Post
ideally the timings of all of these are synchronized. no one has achieved this yet (if you do, you would get plots like https://www.overclock.net/forum/375-...lots-ever.html)
I've only ever seen graphs that smooth when the gyro kicks in on the G402.

May your Raindrop last forever and ever. You provide a wealth of info and a nice look into how things are working, and I for one thoroughly enjoy reading it even if I don't completely grasp all of it.

MX518 Legendary
Logitech G603 (91g)
Allsop Raindrop XL
SmashTV is offline  
post #17 of 55 (permalink) Old 10-23-2019, 06:48 PM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,286
Rep: 370 (Unique: 153)
lol thanks
yes raindrop goat mousepad

so frame periods (inverse of frame rate) are approximately
500us, 450us, 400us, 350us, 300us, 250us, 200us, 150us, 100us, 50us

seems deliberate that they are all multiples of 50us.

idea/speculation:
in most sensors, when spi reads data, the output of the sensor is simply the sum of the counts from the frames since the previous spi read
the 3399 is doing something different. i think it is upsampling the data to 50us intervals

also i highly suspect there is what i call "mcu smoothing" at some part in the pipeline.

honestly it's really confusing. mousetester shows ratios between dots of apparently 40/39. maybe they upsample to 25us intervals?
k guess i'll read the spi data by oscilloscope and see how it compares to the reported counts in mousetester.
Attached Thumbnails
Click image for larger version

Name:	DS1Z_QuickPrint5.png
Views:	15
Size:	73.5 KB
ID:	302114  

Click image for larger version

Name:	DS1Z_QuickPrint6.png
Views:	12
Size:	45.5 KB
ID:	302116  

Click image for larger version

Name:	33399.png
Views:	10
Size:	45.0 KB
ID:	302118  

Attached Files
File Type: txt 3399mousetester.txt (12.7 KB, 18 views)

too busy to check forums as regularly
pm me if i forget to respond

Last edited by qsxcv; 10-24-2019 at 12:20 AM.
qsxcv is offline  
post #18 of 55 (permalink) Old 10-24-2019, 12:16 AM
New to Overclock.net
 
hotrodkungfury's Avatar
 
Join Date: Nov 2017
Posts: 75
Rep: 1 (Unique: 1)
Quote: Originally Posted by qsxcv View Post
lol thanks
yes raindrop goat mousepad

so frame periods (inverse of frame rate) are approximately
500us, 450us, 400us, 350us, 300us, 250us, 200us, 150us, 100us, 50us

seems deliberate that they are all multiples of 50us.

idea/speculation:
in most sensors, when spi reads data, the output of the sensor is simply the sum of the counts from the frames since the previous spi read
the 3399 is doing something different. i think it is upsampling the data to 50us intervals

also i highly suspect there is what i call "mcu smoothing" at some part in the pipeline.

honestly it's really confusing. mousetester shows ratios between dots of apparently 40/39. maybe they upsample to 25us intervals?
Can you ELI5 some of this information for those of who are fully capable of reading all of your posts but are unable to comprehend any of it?
hotrodkungfury is offline  
post #19 of 55 (permalink) Old 10-24-2019, 12:33 AM - Thread Starter
lololol
 
qsxcv's Avatar
 
Join Date: Feb 2014
Posts: 4,286
Rep: 370 (Unique: 153)
these posts are mostly just a live stream of my current thoughts

once i think i have a good understanding of everything, i'll update the op with everything written in a a more digestable format

in the meantime, if you write down what you don't understand or specific questions, that will help me determine how much eli5 i need to be in the OP.

too busy to check forums as regularly
pm me if i forget to respond
qsxcv is offline  
post #20 of 55 (permalink) Old 10-24-2019, 12:44 AM
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,722
Rep: 78 (Unique: 63)
Instead of upsampling, I think the sensor has a 20khz native framerate(50us interval), but some samples are simply discarded or skipped to get the variable framerate. So technically it would be downsampling. But that clock is still running at 20khz so your frame intervals are multiples of 50us.

This will keep exposure times the same, and let you get more of a difference between comparison images when the mouse is moving very slowly.


Last edited by TranquilTempest; 10-24-2019 at 12:47 AM.
TranquilTempest is offline  
Reply

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