Main > Main Forum
turbotwist 2 choice - USB vs PS/2
<< < (2/11) > >>
AndyWarne:
Does it actually have a 300 PPR encoder? Most of the minature ones such as the Avago HEDR series are 200 PPR.
A standard 10ms poll rate would be a limiting factor at this resolution.
RandyT:

--- Quote from: AndyWarne on February 02, 2007, 01:08:07 pm ---Does it actually have a 300 PPR encoder? Most of the minature ones such as the Avago HEDR series are 200 PPR.

--- End quote ---

Yes, it actually does have 300, for 1200 actual transitions per revolution.  We are talking perfect DOH with enough left over to fix the feel of a larger than original sized knob.


--- Quote ---There is not really a "default" poll rate for the USB device, it's whatever is specified in the descriptor.

--- End quote ---

I'm surprised that you don't already know this, but your statement is only half true.  "Low Speed" USB HID devices are throttled by a number of OS's, either intentionally, or due to marginal USB implementations.  There are hacks to up that speed on some OS's, or as used with expensive gaming mice, one can create custom drivers at the expense of standard HID compatibility.  There are also practical limitations imposed by the "work to be done" at the hardware level.


--- Quote --- I would think that this resolution would need a 5ms poll rate otherwise the math indicates the maximum speed would be limited.

--- End quote ---

There is always a max speed limitation for any devices like these.  Please show your math so we can better discuss how you achieved that number and maybe we can relate that to "rotations per second" at a specific report rate, which is the real number of interest.

To anyone watching this discussion and not understanding what's being said:

This thread probably stopped being important to your gaming interests about 4 posts ago.  The current discussion is "academic" in nature, so feel free to tune out whenever you get bored.  My apologies to the OP.

RandyT
2600:
"default" may be a poor word choice.  Per the USB Spec, 100Hz is the fastest poll rate low-speed devices can request.  where as the fastest full-speed devices can request is 1000Hz.  The Host can choose to poll faster, which Windows does and default's to polling at 125Hz for low-speed mice.

Usually, the backspin is caused because the poll rate is too slow and the buffer fills up.  There are 2 ways to alleviate this type of backspin.  I've never seen it caused by the Host not being able to process the packets.

1. Faster poll rate - Which can be accomplished two ways.
A. Patch Windows default Poll Rate, there are few software apps that do this and most low-speed mice don't have a problem with it.
B. Use USB full-speed, to get a faster poll rate from the Host.  Although, 1000 Hz would be insane and cause a lot of traffic to have to be processed by the host.  4 or 5ms would be a better choice to put in the descriptor for full-speed devices.

2. Larger output buffer.  Mice typically use an 8 bit buffer per axis, but I've heard of at least one low-speed mouse that uses a 16 bit buffer.  I haven't tested this so am unsure of the trade offs.


EDIT: Randy got in, before me.  You two type too fast for me to keep up.
AndyWarne:
Too fast for me too. I edited my post but Randy got the pre-edit version quoted!
Absolutely correct of course. I was forgetting that I am dealing with full-speed devices right now (ie the Mouse portion of the Ultrastik 360) in which I can set the poll rate to whatever I want (but of course being sensible about the resulting overhead).

Andy
RandyT:

--- Quote from: 2600 on February 02, 2007, 01:47:06 pm ---The Host can choose to poll faster, which Windows does and default's to polling at 125Hz for low-speed mice.

--- End quote ---

This is the 2K / XP default.  As I understand it, other Windows versions are different.


--- Quote ---Usually, the backspin is caused because the poll rate is too slow and the buffer fills up.  There are 2 ways to alleviate this type of backspin.  I've never seen it caused by the Host not being able to process the packets.

--- End quote ---

I was relating processing to USB overhead internal to the hardware as well as the polling.  The host can't process the packets if they aren't being sent.


--- Quote ---1. Faster poll rate - Which can be accomplished two ways.
A. Patch Windows default Poll Rate, there are few software apps that do this and most low-speed mice don't have a problem with it.

--- End quote ---

This works, as long as a faster poll rate is specified in firmware.  But if the user's system is not patched, or the device is used on a different OS, that faster rate causes problems.  Not a great choice, IMHO.


--- Quote ---B. Use USB full-speed, to get a faster poll rate from the Host.  Although, 1000 Hz would be insane and cause a lot of traffic to have to be processed by the host.  4 or 5ms would be a better choice to put in the descriptor for full-speed devices.

--- End quote ---

Agreed, were it actually necessary for proper operation of the device in question.


--- Quote ---2. Larger input buffer.  Mice typically use an 8 bit buffer per axis, but I've heard of at least one low-speed mouse that uses a 16 bit buffer.  I haven't tested this so am unsure of the trade offs.

--- End quote ---

Larger buffers can store more data, but going to 16 bit buffers means quite a few more processing cycles at every transition.  I haven't tried this either, but my first impressions are that it could actually slow things down at the very important "data collection" phase.  Better to overflow the buffer in extremely unlikely circumstances than to miss transitions all the time.

RandyT

Navigation
Message Index
Next page
Previous page

Go to full version