Odd y mouse measurement

[MoretonBayKiting]

I'm using the wrapper to measuring line length in a control application - that is, a line (string) is moved past a mouse and that measures distance moved. I've used the strategy previously quite successfully with a PS2 mouse but now need to use USB mice. The example (USB_Test) detects the mouse I'm using and reports (my_USB_PrintCB) 5 bytes in hex format. I understand (from HID spec) that bytes 1 and 2 (of 0:4) are x and y. The y byte is almost invariably a multiple of 16 (as though movement is only triggering the upper 4 bits) whereas the x byte is a small integer (when cast to int8_1 it is between -4 and 4). x values look quite plausible. But I'm confused by the data reported for y (when it is moved at about the same rate as x). Has anyone seen something similar? Any suggestions?

[tobozo]

relative mouse moves are usually described as int8_t so there should be two values between -128 and 127 in every mouse report, plus the button states, it's not very precise to measure distance when the reported values are subject to accelerations

a device descriptor using absolute positioning (e.g. touchpad) is much more appropriate for precision, absolute coordinates can be described as uint16_t

some HID devices can send both absolute and relative positions until configured by an OS driver, some are restricted, your mileage may vary

[MoretonBayKiting]

Thanks. I understand that the mouse provides measurement of relative movement. If I accumulate y, the error on returning to a start position is tolerable and can be easily removed/accounted for. For example, after moving back and forth a few times over order 300mm the error is order 1mm (that testing was with the ps2 mouse which I have setup with lines controlled by winches). My very rough bench testing of a USB mouse seems also to return tolerably to zero. But I'm confused that, with similar movement speed, for x values I get raw values of 0x0n whereas for y I get 0xnF with, in each case, n a small integer. I can work with the y values as they are with appropriate calibration. But it seems very odd.

Absolute position measurement would not work for my purposes. The control lines (several) will be released "manually" (ie by RC to the winches) - this could be up to 60m. At a length determined by the operator, which will vary with conditions and various other factors, the system will be switched to autopilot. The relative movement of the different lines is needed for that mode.