Rival 700 Support

[Aigis]

Is it possible to add Rival 700 support to rivalcfg? Not sure how similar/different the hardware is, but I'd greatly appreciate it if I could configure at least my sensitivity on my Arch install, the rumble and oled screen would be nice to have, but I could take them or leave them. Please let me know if there's anything I can do to help add and troubleshoot support for the Rival 700!

[flozz]

Hello,

It should be possible to add support for the Rival 700... but as I do no have this mouse, I cannot do the reverse engineering that is required to implement its support in rivalcfg.

I am searching for alternative solution to study the mouse, but currently without success.

[antoinnneee]

Hi flozz

If you tel me how to reverse engineering the rival 700, i can help you, I actually have this mouse.

[flozz]

Hello,

I wrote an article on my blog about it:

• http://blog.flozz.fr/2016-03-27/steelseries-rival-100-reverse-engineering-peripherique-usb/

It is in french, but I think that google translate can help.

Don't hesitate if you have questions :)

[antoinnneee]

Haha je suis français, c'est parfait ;) je lirais sa un peut plus tard merci

[RibalGZ]

Hi,

I'll probably buy the Rival 700 this week, so I'll also be able to help you with the reversing :)

[LinuxdevelopersOrg]

Hi, this I reckon is still an outstanding request - I got my 700 today so I've just started looking into it (using an usb sniffer on Windows).

I'll let you know how it goes :)

Edit: The dumps I get from the USB logger will be stored at https://drive.google.com/open?id=0B-D4jp_mLMTaYVFyb19rNEVjelE

Can't get much to work, but then again I only had a quick look at it. Note: I have the latest firmware on the mouse.

[LinuxdevelopersOrg]

So, I got the tactile stuff to work. Can't do more on this tonight, though. I've added rival700.py to the above gdrive location with all the tactile variants from the SS utility (with the same names).

Next up, the OLED (yeah, I'll do the fun parts first :))

(Edit: I haven't touched any of the other functions in the file, so they won't work with the 700 yet.)

[flozz]

Hello,

Nice see someone working on this mouse! I will take a look to your work when I have some free time. :)

[LinuxdevelopersOrg]

I've made a few other things in "beta", will upload them eventually. I must've missed something in the OLED part.

Interesting license you've digged up, hadn't seen that before. A bit special... :)

[flozz]

Hello,

I am looking at you oled_upload_picture.csv file, Have you uploaded a completely black (or white?) image? What is the resolution of the OLED screen?

Edit: I looked at the SteelSeries website. The screen seems to be 128×36px. So for a monochrome screen, we need at least 576 Bytes to transfer an image (if there is no compression at all). → so I think there is some frame missing in your dump :)

[LinuxdevelopersOrg]

Yes, the OLED handling is illogical as it stands. USBlyzer have always worked for me in the past (doing Arduinostuff) so I dunno. Looking at setting_of_pixel.csv it seemingly do some stuff at the very end.

Got the sensitivity to work (at least it differs in real life tests, don't know how to really check the setting in Linux), but all the color stuff won't "stick" when I set them.

I'll rerun the stuff in Windows using another USB logger and see if it differs.

Edit: Got it. I'll fix the OLED-support tonight. I've never before used the Export to CSV option of USBlyzer (since I never before needed to export it out of its native format) and lo and behold, it drops anything but the first bytes. Weird development choice that but now I can fix it at least.

[LinuxdevelopersOrg]

Tried a few other USB loggers but couldn't get it to work. I've been very busy (renovating my house), but I've setup a virtual machine - maybe the 300's solution from the other thread also can be of help to me.

I will get this to work :)

[HughPH]

Anyone still working on this? If not I might give it a go.

Just thought I would point out that the OLED will show animations at 10FPS, and can have animated GIFs uploaded to it by the SteelSeries software. That might go some way to explaining the "stuff at the very end".

It would be cool to run a daemon for this mouse, so that other software can invoke tactile functions or push images directly. Would also be interesting to see if images can be pushed faster than 10FPS - seems that way since you can keep hammering the Invert button in the SteelSeries software and it flickers pretty quick. Could have some nice fractal or random anims running on it, or a ticker of some sort. Maybe system load. Should be able to get 16x4 chars on it, or 16x6 with a smaller font.

[flozz]

Hello,

As far as I know, nobody is working on the Rival 700.

It would be cool to run a daemon for this mouse, so that other software can invoke tactile functions or push images directly.

rivalcfg must stay a simple CLI program and a library (maybe a GUI will be also implemented one day as a separated project). So it cannot be a daemon, but a daemon that uses rivalcfg as a library can by implemented separately (we keep all the logic to communicate with the mouse in rivalcfg and we implement a daemon that uses it).

[leijendary]

It would be really nice to have this work like the actual SteelSeries engine (even without the GUI for now) for my Rival 700. The lack of support in Linux is the only thing keeping me from using Linux. Also, i don't think that SteelSeries themselves will release a Linux version of the engine

[HughPH]

Thanks @flozz

I wouldn't consider trying to daemonise the python CLI. In fact it might be more profitable for me to do a new one from scratch. It all looks pretty straightforward.

@Lejendary if I can get this figured out, I'm thinking about making a daemon that sits on dbus. Then someone could create a QT and/or GTK gui.

I did a little playing with WireShark this evening and determined the following...

time is in 10ms increments and little-endian, presumably for the chip in the mouse

li = lamp index: 00 = logo, 01 = wheel
mode: 08 = trigger, 01 = steady, 00 = shift
ramp: ?! Somehow describes the delta between colours
00 -> ff -> 00 is 10 / f0 <- these are signed bytes!! So 10 is -112 and f0 is +112
ff -> 00 -> ff is f0 / 10 Are they therefore inverted as well??
ix: index of ramp, 00 means no more ramps. Max 14 control points in SteelSeries engine, room for 16 Ramps in the data packet.

Each command seems to elicit a response and then require an 08 00 00 00 ... before it's "committed."
Haven't decoded responses yet.

Trigger:
| cmd | li | colour 1 | colour 2 | time1 | ?? | mode |
| 05 00 | 01 | ff 00 00 | e3 30 ff | 64 00 | 01 | 08 | 00 00 00 ... 578 bytes
(response)
08 00 ... 32 bytes

Steady:
| cmd | li | colour 1 | ignore | ignor | ?? | mode |
| 05 00 | 01 | ff 52 00 | e3 30 ff | e7 03 | 01 | 01 | 00 00 00 ... 578 bytes
(response)
| 08 00 | ... 32 bytes

ColourShift:
| cmd | li | ignore | ignore | ignor | ?? | mode | [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | time |
| 05 00 | 01 | ff 52 00 | e3 30 ff | e7 03 | 01 | 00 | 06 fc 00 00 ff 00 01 00 fa 04 00 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a0 02 20 04 a0 0f ff 00 dc 05 8a 02 00 00 00 00 01 00 02 00 | fe 01 |
| 05 00 | 01 | ff 52 00 e3 30 ff e7 03 01 00 03 03 fc 00 de 03 01 00 fc 00 04 00 de 03 02 00 00 fd 00 00 fc 03 00 00

Multi Colour Breathe: Same as ColourShift
| cmd | li | ignore | ignore | ignor | ?? | mode | [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? | time |
| 05 00 | 01 | ff 52 00 e3 30 ff e7 03 01 00 ee 00 00 00 d8 00 01 00 12 08 00 00 d8 00 02 00 ee f8 00 00 d8 00 03 00 12 0b 00 00 d8 00 04 00 ef f6 00 00 e5 00 05 00 11 00 00 00 e5 00 00 00 00 00 00 00

Disable:
| cmd | li | black | ignore | ignor | ?? | mode | [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix ?? [ ramp ] ?? [tme] ix
| 05 00 | 01 | 00 00 00 | e3 30 ff | 64 00 | 01 | 01 |

[HughPH]

So I've done a bit more tinkering and I have a (very very quick & dirty) .net core command line app which makes the tactile buzzes work. I've also mapped out the colour commands and the bitmap command but need to test all that. Bitmap seems very simple. Command is little endian 0x0159 (bytes [0x59, 0x01]) followed by 576 bits where MSB is left-most and LSB is right-most and they read left to right.

It turns out SteelSeries Engine on Windows does 10FPS animations by sending the images to the mouse, so faster than that should be easy, and custom text & computed graphics should be super-simple too.

[HughPH]

The most exciting thing here is that there seemed to have been a huge number of gaps in the tactile stuff, and actually, it seems to be possible to fill them in. Here's what I've got so far, but the perception of some of them will be very subjective. I'm wondering if there's some meaning behind these numbers. They're all 6 bits, is that 3 pairs of 2-bit numbers? Or 6 distinct flags? Or a mixture? Setting the 7th bit seems to have an effect, but it's not clear what's going on just yet. Even with 6 bits, though, we have 64 potential patterns.

    Strong = 0b000001,
    Soft = 0b000010,
    Sharp = 0b000100,
    Ping = 0b001000,                
    Bump = 0b000111,
    Double = 0b001010,
    QuickDouble = 0b011011,
    QuickDoubleSoft = 0b100000,
    QuickTriple = 0b001100,
    Buzz = 0b101111,
    LongBuzz = 0b001111,
    Ring = 0b010000,
    LongButLight=0b111111,
    LightBuzz=0b110011,
    Tick = 0b011000,
    Pulse = 0b110101,
    StrongPulse = 0b110100,

[HughPH]

So it looks like setting the image isn't going to work yet because the URB wValue must be 0x0300 for that request, and if we just push data to /dev/hidraw_x_ it will have wValue 0x0251. Actually I don't know what the 08 00 00 00 00 [...] message is for yet, maybe it's a little ping to keep the screen on, but that has wValue 0x0200 when SteelSeries Engine does it. It might be just lucky that we have tactile stuff working.

Now working on a C++ app to get a bit more low-level...

[HughPH]

Woo! I got an image onto the mouse! However, I got the image by saving it as a .bmp and then stealing the bytes from it, and I forgot BMP is bottom-up...

[HughPH]

So I also have it playing video at about 60FPS, although ImageMagick seems to have some problem writing 1-bit files, so I need to write my own converter. 10 FPS lol that's cute steelSeries

[HughPH]

Interestingly, pictures seem to work OK when either the first or last pixel is white but somehow get corrupted if there's some other combination of bits... Going to re-"encode" this with a tweak to set first or last pixels or both and see if I can make it all line up.

I know it's hard to believe, so...
https://youtu.be/mJs-ZQe0qB4

[HughPH]

So I just got back to this and found a picture that was screwed up when I put it on the mouse but not when it came from SteelSeries Engine. There's definitely a difference between them (the one that works is longer!!), but I'm going to have to turn it into a stream of 1s and 0s to get a feel for how they're encoding these images.

[HughPH]

faceplam
After having a look through, the one on the right has some "spurious" extra bytes. Which are all 0x20 and 0x0a. Which are the character codes for space and newline. THEY EXIST IN THE FILES - so somehow, somewhere, the code is stripping these out. Although I'm reading the file as binary. And I'm pretty sure even if it was text, I'd still want the spaces and newlines...

[HughPH]

So yeah, that works a bit better
https://www.youtube.com/watch?v=meQ2gJfKdo8

[flozz]

@HughPH wow you made a great work with the reverse engineering of the oled part of the Rival 700. Pretty cool to be able to watch Big Buck Bunny on the mouse :)

[HughPH]

Yeah, could get the whole thing to play but it was never released in 32:9 so it would be badly cropped :)

The other fun thing I thought about was actually playing a little game like pong or defender using the side buttons or scroll wheel.

Anyway, I'll create a GitHub project soon and post my ropey C++ source. It would be nice to describe the mouse in configuration, then look at implementing support for other SteelSeries peripherals, maybe even other manufacturers devices, then sync them all together and provide a common interface.

BTW it looks like SteelSeries Engine can't deal with 2 SteelSeries mice at the same time!!

[flozz]

@HughPH maybe you will be interested by libratbag that tries to support as many mice as possible through a d-bus interface :)

[nixtux]

Colorshift and Multi color breath command (the only part missing is how the color change is worked out)

bytes (ind)	exp	values	summary
1-2	command	05 00
3	led id	00 or 01	logo or wheel
4-11	unknown	1d 01 02 31 51 ff c8 00	seems static
12-124	stages		(index, 00, color 3 bytes ?? but not rgb, 00, 2 bytes time in ms)
125-129	start rgb	f0 0f a0 00 a0 00	rgb color but every other byte ???? eg start color ffa0a0
130-132	unknown	ff 00 dc 05 8a 02 00 00 00 00 01 00	seems static
133-134	cycle time	ms little endian

SSE only lets yot set up to 14 stages for color shift and only 4 stages for multi color breath

stages

index	00	color not rgb	00	time in ms from last stage or start little endian
00	00	00 00 00	00	7f 00 -- 127
01	00	f0 fa fa	00	ff 00 -- 255
02	00	20 0c 0c	00	7f 00 -- 127
				509 --> 1fd --> cycle duration

color
f0 fa fa --> fa is 244 not 160 -- f0 is 250 not 160
20 0c 0c --> 20 is 42 not 61 -- 0c is 12 not 61

1 color set at at 25% 255/10/10 hex ffa0a0
2 color at 75% 61/61/61 hex 3d3d3d

0000 80 fa fc d1 60 94 ff ff 53 02 00 0a 01 00 00 00 ....`...S.......
0010 69 b8 ce 5e 00 00 00 00 eb ae 06 00 8d ff ff ff i..^............
0020 42 02 00 00 42 02 00 00 21 09 00 03 00 00 42 02 B...B...!.....B.
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 05 00 00 1d 01 02 31 51 ff c8 00 00 00 00 00 00 ......1Q........
0050 00 7f 00 01 00 f0 fa fa 00 ff 00 02 00 20 0c 0c ............. ..
0060 00 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 0f 00 ................
00d0 0a 00 0a ff 00 dc 05 8a 02 00 00 00 00 01 00 03 ................
00e0 00 fd 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0280 00 00 ..

[HughPH]

@nixtux Please confirm if this is correct:

125-129 | start rgb | f0 0f a0 00 a0 00 | rgb color but every other byte ???? eg start color ffa0a0

because it disagrees with this:

00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 f0 0f 00 ................
00d0 0a 00 0a ff 00 dc 05 8a 02 00 00 00 00 01 00 03 ................
00e0 00 fd 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

You also say you have a colour set at 255/10/10 (0a) but then talk about 160 (a0)

What I find most notable about the hex dump is that f0 | 0f = ff, and 00 | 0a = 0a so it looks like maybe the high & low nibbles have been extracted for some reason.

To go back and 'decode' my earlier ramblings...
4..11 are configuration for triggered colour/time, so you have Colour 1 (idle) = 1d0102, Colour 2 (triggered) = 3151ff, Trigger fade time = 0x00c8 (if we assume little-endian int16)

In your byte 12 you have 00, I have 01, I never worked out what it was but I don't think it's index.

Byte 13 = 00, you also have 00 here but you thought it might be index 00. If we change that same value to 08 in our request, we will get the Trigger colours as defined earlier in the message. On that basis, I'm quite sure it's Mode. I also wrote code on that basis, and it holds water.

I think the structure might then be:
Colour (24-bit)
?? (8-bit)
Time (16-bit)
Index (16-bit)

So to read yours on that basis I would get about the same:

colour	??	time	index
00 00 00	00	7f00	0100
f0 fa fa	00	ff00	0200
20 0c 0c	00	7f00	0000

We might be wrong, it might be big-endian data with a null termination:

colour	time	index	term
00 00 00	007f	0001	00
f0 fa fa	00ff	0002	00
20 0c 0c	007f	0000	00

I agree it seems a bit mad for the last one to have an index of 0, but for my hex dump, I would have had two with the index 0001

Here's my original dump more clearly formatted...

cmd	li	ignore	ignore	ignore	??	mode	ramp	??	time	index	ramp	??	time	index	ramp	??	time	index	ramp	??	time	index	ramp	??	time	index	ramp	??	time	index	...etc
05 00	01	ff 52 00	e3 30 ff	e7 03	01	00	ee 00 00	00	d8 00	01 00	12 08 00	00	d8 00	02 00	ee f8 00	00	d8 00	03 00	12 0b 00	00	d8 00	04 00	ef f6 00	00	e5 00	05 00	11 00 00	00	e5 00	00 00	00 00 00 00

Unfortunately it was ages ago that I did that, and I can't remember what colours I picked. They were probably pretty random.

The reason I called it "ramp" is that I suspect it's a delta of some kind, with a reset to the start value that might be in what I think is split nibbles later in your capture.

[HughPH]

Apparently I released this under the wrong kind of license so you can't copy & paste it into your own project. TBH that's not really what I intended anyway - it's not developed with anyone else's code in mind, it's just a hastily thrown together monolithic thing with no architectural design that does some stuff to prove what's possible. Be inspired by it, or something: https://github.com/HughPH/SteelSeriesControl

[nixtux]

yeah sorry make a mistake in that table entry, but yeah every dump i've produced has starting color in that format, will double check table and add another example.

[nixtux]

on a side note to getting colorshift to work https://www.dropbox.com/s/uwheh85b2zp2xsp/rival700snakes.m4v?dl=0

[HughPH]

What we think is "index" might be "next"

Nice work on the snake game :) Unfortunately I destroyed my OLED screen (probably just the cable) when I took the mouse apart to give it a clean (wheel button was double-clicking or not-clicking randomly) and SteelSeries won't send me a replacement. (Obviously they just want me to buy a 710!)

[nixtux]

So after some more testing to workout how color is defined in stages i noticed small change in color values didn't effect the command sent, interesting and look what the result leads to

2 stages selected in sse
start color for this command is is b0 03 10 0d f0 0f ff -- 3bd1ff or 59/209/255
2 stage stage is 8c00ff or 140/00/255

first stage 05 f3 00 let extract the nibbles
first nibbles 0 f 0
last nibbles 5 3 0

lets start with the red channel starting color is 3b or 59 in this stage we have 0 or 5 nibble lets take the last one and do (516)+59=139 so does the low nibble mean add?
next byte last nibble so we have a high first nibble does that mean subtract lets try we started at d1 or 209 sub value of last nibble (316) so 209-140=161
third byte last nibble so we start at ff- its 00 so nothing is done here

second stage fb 0d 00
nibbles b d 0
first byte last nibble so we have fb so its sub b or 11 (1115)=144 we had 139 from the last stage its in 12 bit color so now we are back to start color
second byte last nibble so we start at 0d low first byte so we add d is 1316 is 208 and again back to start color
third byte last nibble so we start 00 so nothing is done here

0000 00 86 cb c4 96 8e ff ff 53 02 00 0a 01 00 00 00 ........S.......
0010 e4 60 d1 5e 00 00 00 00 58 07 05 00 8d ff ff ff .`.^....X.......
0020 42 02 00 00 42 02 00 00 21 09 00 03 00 00 42 02 B...B...!.....B.
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 05 00 00 1d 01 02 31 51 ff c8 00 00 00 05 f3 00 ......1Q........
0050 00 ff 00 01 00 fb 0d 00 00 ff 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 03 10 ................
00d0 0d f0 0f ff 00 dc 05 8a 02 00 00 00 00 01 00 02 ................
00e0 00 fe 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0270 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0280 00 00 ..

[nixtux]

I still need to do more testing to confirm the high low bit values but it does seem to select every color for stages in 12bit

[HughPH]

It's a good thought. It would make sense if the colour doesn't need to be exact, and it might be that the mouse's MCU doesn't support floating point which would cause complications with calculating shift amount per cycle.

[nixtux]

Yeah it was a good thought just the wrong one, but i have found out that each byte is just a signed byte depicting the rate of increase per tick.

[HughPH]

That's pretty much what I expected.