TurboTwist Hi-Low Spinner Backspin problem. XP 64 Poll rate, Works Now!

[2600]

This would make sense, to a point.  However, seeing that the system is obviously capable of the higher speeds, it is, IMHO, a bonehead decision to not offer users the option of setting that speed to whatever they wish through a simple registry entry modification.  Still no need to constantly monitor or shift gears, so if that was their primary concern, this approach would have been infinitely better.

RandyT

I'm not sure that first statement is totally accurate.  Can it be capable, yes.  Always, no.  The low speed spec was specifically designed to help allow super cheap products without a critical need in speed.  For example, the cable does not have to be as robust as the default cable you provide.  When you start attaching or daisy chaining a lot of devices shielding starts playing a much bigger role.  Also, when the spec was written motherboards had one or two host controllers unlike today where one EHCI controller which has multiple USB 1.1 controllers built in.  When you start loading the bus down, you don't want the priority going to a mouse or keyboard.

The fact is if a device needs a faster poll rate the designer is suppose to choose full speed over low speed.  With full speed the designer has the option of polling as fast as 1ms, but can be polled slower if the designer chooses.  For HID devices, the device does not need to respond immediately to a poll if the designer chose a faster speed then needed.


Granted, I do like the ability to modify things through the registry, but you have to use what's given to you.

[RandyT]

I'm not sure that first statement is totally accurate.  Can it be capable, yes.  Always, no.  The low speed spec was specifically designed to help allow super cheap products without a critical need in speed.  For example, the cable does not have to be as robust as the default cable you provide.  When you start attaching or daisy chaining a lot of devices shielding starts playing a much bigger role.  Also, when the spec was written motherboards had one or two host controllers unlike today where one EHCI controller which has multiple USB 1.1 controllers built in.  When you start loading the bus down, you don't want the priority going to a mouse or keyboard.

This is kind of getting into another discussion, but I've yet to see a situation where the system was not capable of higher poll rates than the newer MS operating systems default to.  If you have, I'd appreciate an example to investigate.  We are also talking primarily about the capabilities of the host, not the device.  It is true that there are "super-cheap" mouse devices out there that are incapable of operating properly when the poll rates are hiked.  The processor used in the GGG optical devices, however, is not one of these devices.  It is, in fact, using the same 12 million cycle per second core as our other encoder products, which is more than capable of sustaining higher poll rates.  The difficulty doesn't come from the host, as the bus is the bus.  If it can go "Full-Speed", then it can operate properly at higher poll rates at "Low-Speed".  Also, we aren't talking about bulk transfers, rather very small amounts of data at a higher frequency.  "Full-Speed" devices are usually things like card readers and mass storage devices (at least under 1.1) where large amounts of data need to be transmitted as fast as possible.

Again, the intent of the "Low-Speed" specification was to benefit the device, not the host.  The host is simply more flexible as a result. 

RandyT

[2600]

Yeah, sorry for the sidetrack on thread discussion.

One thing, I wasn't trying to imply that the GGG is a super cheap device in fact I was saying the opposite.  What I was more trying to imply is that you can't hold all low speed devices to your GGG standard.  If you increase the low speed poll rate in the OS for one device, you are increasing it for all devices.

I'm not quite sure I understand the rest of your argument.  If you want low speed devices with full speed device characteristics, why not make it a full speed device.  Why would the creators of the spec who are probably much more knowledgeable about it then us, although I do loathe USB, create 2 different speeds if they weren't trying to imply a difference?

I don't have a specific example about poll rates, but I imagine if you start increasing the bus length and increasing the number of devices as well as traffic on the bus you will start seeing that situation.  It may not be blatantly apparent, but if you put an analyzer on the bus you may start seeing errors or devices that would not enumerate correctly.

[RandyT]

Yeah, sorry for the sidetrack on thread discussion.

One thing, I wasn't trying to imply that the GGG is a super cheap device in fact I was saying the opposite.  What I was more trying to imply is that you can't hold all low speed devices to your GGG standard.  If you increase the low speed poll rate in the OS for one device, you are increasing it for all devices.

Apparently, this is not the case for one of the better solutions out there.  You can actually assign the device you want to increase the poll rate with so it only affects that particular device...at least if what I have been hearing is true.

I'm not quite sure I understand the rest of your argument.  If you want low speed devices with full speed device characteristics, why not make it a full speed device.  Why would the creators of the spec who are probably much more knowledgeable about it then us, although I do loathe USB, create 2 different speeds if they weren't trying to imply a difference?

Well, it isn't really a "Full-Speed" characteristic.  The spec allows for whatever poll rate one wants to request, but only requires the host to honor 10ms.  One should view that as a minimum for compliance, which MS did seeing as they upped it to 8ms, but not as a definition for what constitutes the capability of a "Low-Speed" device.   As for the difference, it's as was stated before.  It's merely an accommodation of less capable devices, that for the most part is a subset of the full capabilities of the host.  So one cannot technically state that MS is not complying with the spec, because they are.  But one can state that they are of the opinion that not allowing the user (or the devices) the ability to do better is a "bonehead decision", as doing so does not in any way violate the specifications for a USB "Low-Speed" device.

And finally, in the practical world of USB, it seems that the host implementation reigns supreme, not the specification.  I have a great little, inexpensive 16-input USB device here capable of kicking out standard keyboard data very quickly, and it works fantastically for gaming under 98SE, XP and Vista.  But under Win2K, it can't seem to get out of it's own way.  It works fine under Win2K for an application like a kiosk or museum display (or a keyboard), but just doesn't have the throughput under Win2K for what folks here would use it for.  So my point is, referring to the spec doesn't always give you a solid indicator of what to expect from the performance of any particular device when coupled with any particular host.  What has been exhibited, over and over again, is that the hosts in the context of this discussion, set to higher polling of "Low-Speed" mouse devices, work just fine.

On the subject of host performance, one has to keep in mind that the host does not need to poll at 500hz reliably for this application.  It is overkill, as half that would likely be sufficient.  So the host can vary it's poll rate wildly without the user ever seeing an issue, so long as it is able to sustain a rate higher than that which would cause an overflow condition.  In other words, we don't care if there isn't a "dead nuts 500hz reliability"  because it just doesn't matter here.

RandyT

[TPB]

Good to know about Arkanoid. It's one of my favorites.

Rest easy.

The TT2 was MADE for Arkanoid (and its sequel DOH).

It remains the only hi-res spinner with steering wheel options, and a high-low version.

Of course, there is now another hi-res compact spinner in the market, which is giving the TT2 some stiff competition.  It was developed with the assistance of a design sharing and collaboration agreement, the fruits of which shall soon see another product come to market, a revolutionary new joystick called the G360 GroovyStik.   

[Todd H]

Just tested the TT2 with Arkanoid. Perfection. And Tempest at a setting of 6 feels exactly as I remembered. Great product Randy!  

[robertsig]

OK, I have to reply to this because I'm having the same problem.

I have a TT2 master and slave (X & Y axis on mouse).  My MAME machine is running XP 32-bit SP3.  I have the USB interface.  I set Tempest's analog down to 6, as well as trying a bunch of other settings.

Standard polling rate of 125 on usbport.sys.  I also upped to to 250 and 500 for testing.

In all three cases, I still get backspin, or at least that is what I think it is called.  The "claw" jitters back and forth instead of spinning if I move the spinner fast.  What do I do next?  Out of the hundreds of games I have, Tempest was my #1 reason for building this thing.

[MonMotha]

The USB spec restricts low speed (1.5Mbps) devices to 100Hz polling rate.  They are not permitted, per the words of the spec, to ask for anything higher, though there's nothing technically stopping them from doing so.  For HID devices, Windows "upgrades" them to 125Hz, since 100Hz is lacking in many uses such as gaming, regardless of what they ask for.  Linux seems to do something similar.

What these hacks do is cause Windows to "upgrade" things even more for low speed devices.  Some poorly done versions of the hack also apply themselves to full speed devices which can actually cause such devices to be slowed down!

The USB specification does not restrict full speed (12Mbps) devices.  They are permitted to request any polling rate that is an integer divisor of 1000Hz (they actually specify the polling PERIOD in milliseconds) in their descriptor.  Windows seems to respect the devices wishes.  I've asked for 1000Hz before, and Windows complies.  Modern Linux kernels also comply fully, but some older ones max out at 500Hz or sometimes some weird number like 800Hz.

Usually, 250Hz is more than sufficient even for the most picky of gamers.  Most games only poll button and joystick inputs once per (60Hz) frame, anyway.  However, on device that report relative movement, such as mice and trackballs, one has to worry about the relative motion counter overflowing (which causes backspin).  To counter this overflow, one can do two things: increase the polling rate (resetting the counter more frequently so it doesn't have a chance to overflow) or making the counter bigger (so that it takes longer to overflow)

Note that both low speed and full speed are part of the USB 1.1 specification.  A USB 2.0 device can also be low speed or full speed.  "Full speed" always refers to 12Mbps, NEVER to the 480Mbps "high speed" introduced in USB 2.0, even if a device is USB 2.0 compliant.

High speed (480Mbps) devices, which must be USB 2.0, can request much faster polling rates as they request their polling rates in units of 125microseconds.  Very very few HID devices are high speed.  Usually only composite devices with some other function (such as a mouse with integrated flash storage or something similarly weird) in addition to the HID would be high speed.  I'm not aware of any commercially available "arcade IO" devices on the market that are high speed, and it's generally unnecessary.

Note that high speed devices are supposed to degrade gracefully to full speed if at all possible.  Most do (e.g. storage devices get slower, cameras use lower framerates, etc.).
Also note that high speed is faster than full speed.  Put another way, full speed is slower than high speed.  Yes, it's totally unintuitive, but welcome to the world of a hardware standard written by Microsoft and a software standard written by Intel...all while doing who knows what drug(s).

[robertsig]

Ugh. I was changing the wrong value.  I changed sensitivity down the 6% and it works fine.

[MonMotha]

FYI, since what I said above is not obvious if you read certain parts of the USB spec, e.g. the description of the "endpoint descriptor" would lead you to believe that both full and low speed devices can ask for anything between 1-255ms polling periods, see page 51 of the USB 2.0 specification:

A full-speed endpoint can specify a desired period from 1 ms to 255 ms. Low-speed endpoints are limited to specifying only 10 ms to 255 ms.