razer viper ultimate internal pics/technical info

i looked through some of TheFiend's posts on reddit:

https://www.reddit.com/r/MouseReview...m_medium=web2x
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
https://www.reddit.com/r/MouseReview...m_medium=web2x
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.

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.

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

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)

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.

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

 

 

 

Attached Files

File Type: txt

3399mousetester.txt (12.7 KB, 18 views)

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?

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.

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.