- What Is A Usb Devices
- Kinds Of Usb Devices
- Drivers Tiptel USB Devices
- Drivers Tiptel Usb Devices Dongle
TipTEL TIP-234 GSM wireless phone based on GSM 900MHz/ 1800MHz -enabled mobile access device. This equipment UIM, only need to insert a SIM card, you can dial local telephone, domestic and international long distance, mobile and IP network telephone; The machine has received strong signal, call quality is good, stable performance and long working hours and other characteristics.-->
Innovation, quality and know-how – Tiptel with more than 45 years of experience For more than 45 years Tiptel.com GmbH Business Solutions has been a leading provider of telecommunication solutions. Innovation, quality and the high expectations in functionality and design lead to the high reputation of the Ratingen based company group. Oct 23, 2020 The 18.104.22.168 version of Tiptel 2/8 USB is available as a free download on our software library. The tool can also be called 'Tiptel 28 USB'. The most popular version of the Tiptel 2/8 USB 1.4. The size of the latest installation package available is 951 KB. The program lies within System Utilities, more precisely Device Assistants. The combination Tiptel 112 USB phone + Latitude E5510 results in a 'Device not recognized' from Vista (Enterprise SP2). Change the T112 by any other model OR the E5510 by any other model and it works. Extensive search have revealed that the problem arises very early, during the USB-high speed negotiation. The 22.214.171.124 version of Tiptel 2/8 USB is available as a free download on our software library. The tool can also be called 'Tiptel 28 USB'. The most popular version of the Tiptel 2/8 USB 1.4. The size of the latest installation package available is 951 KB. The program lies within System Utilities, more precisely Device Assistants.
- Opening the device and obtaining WinUSB handle.
- Getting information about the device, configuration, and interface settings of all interfaces, and their endpoints.
- Reading and writing data to bulk and interrupt endpoints.
This topic includes a detailed walkthrough of how to use WinUSB Functions to communicate with a USB device that is using Winusb.sys as its function driver.
If you are using Microsoft Visual Studio 2013, create your skeleton app by using the WinUSB template. In that case, skip steps 1 through 3 and proceed from step 4 in this topic. The template opens a file handle to the device and obtains the WinUSB handle required for subsequent operations. That handle is stored in the app-defined DEVICE_DATA structure in device.h.
For more information about the template, see Write a Windows desktop app based on the WinUSB template.
Note WinUSB functions require Windows XP or later. You can use these functions in your C/C++ application to communicate with your USB device. Microsoft does not provide a managed API for WinUSB.
What Is A Usb Devices
The following items apply to this walkthrough:
- This information applies to Windows 8.1, Windows 8, Windows 7, Windows Server 2008, Windows Vista versions of Windows.
- You have installed Winusb.sys as the device's function driver. For more information about this process, see WinUSB (Winusb.sys) Installation.
- The examples in this topic are based on the OSR USB FX2 Learning Kit device. You can use these examples to extend the procedures to other USB devices.
Step 1: Create a skeleton app based on the WinUSB template
To access a USB device, start by creating a skeleton app based on the WinUSB template included in the integrated environment of Windows Driver Kit (WDK) (with Debugging Tools for Windows) and Microsoft Visual Studio.You can use the template as a starting point.
For information about the template code, how to create, build, deploy, and debug the skeleton app, see Write a Windows desktop app based on the WinUSB template.
The template enumerates devices by using SetupAPI routines, opens a file handle for the device, and creates a WinUSB interface handle required for subsequent tasks. For example code that gets the device handle and opens the device, see Template code discussion.
Step 2: Query the Device for USB Descriptors
Next, query the device for USB-specific information such as device speed, interface descriptors, related endpoints, and their pipes. The procedure is similar to the one that USB device drivers use. However, the application completes device queries by calling WinUsb_GetDescriptor.
The following list shows the WinUSB functions that you can call to get USB-specific information:
Additional device information.
Call WinUsb_QueryDeviceInformation to request information from the device descriptors for the device. To get the device's speed, set DEVICE_SPEED (0x01) in the InformationType parameter. The function returns LowSpeed (0x01) or HighSpeed (0x03).
Call WinUsb_QueryInterfaceSettings and pass the device's interface handles to obtain the corresponding interface descriptors. The WinUSB interface handle corresponds to the first interface. Some USB devices, such as the OSR Fx2 device, support only one interface without any alternative setting. Therefore, for these devices the AlternateSettingNumber parameter is set to zero and the function is called only one time. WinUsb_QueryInterfaceSettings fills the caller-allocated USB_INTERFACE_DESCRIPTOR structure (passed in the UsbAltInterfaceDescriptor parameter) with information about the interface. For example, the number of endpoints in the interface is set in the bNumEndpoints member of USB_INTERFACE_DESCRIPTOR.
For devices that support multiple interfaces, call WinUsb_GetAssociatedInterface to obtain interface handles for associated interfaces by specifying the alternative settings in the AssociatedInterfaceIndex parameter.
Call WinUsb_QueryPipe to obtain information about each endpoint on each interface. WinUsb_QueryPipe populates the caller-allocated WINUSB_PIPE_INFORMATION structure with information about the specified endpoint's pipe. The endpoints' pipes are identified by a zero-based index, and must be less than the value in the bNumEndpoints member of the interface descriptor that is retrieved in the previous call to WinUsb_QueryInterfaceSettings. The OSR Fx2 device has one interface that has three endpoints. For this device, the function's AlternateInterfaceNumber parameter is set to 0, and the value of the PipeIndex parameter varies from 0 to 2.
To determine the pipe type, examine the WINUSB_PIPE_INFORMATION structure's PipeInfo member. This member is set to one of the USBD_PIPE_TYPE enumeration values: UsbdPipeTypeControl, UsbdPipeTypeIsochronous, UsbdPipeTypeBulk, or UsbdPipeTypeInterrupt. The OSR USB FX2 device supports an interrupt pipe, a bulk-in pipe, and a bulk-out pipe, so PipeInfo is set to either UsbdPipeTypeInterrupt or UsbdPipeTypeBulk. The UsbdPipeTypeBulk value identifies bulk pipes, but does not provide the pipe's direction. The direction information is encoded in the high bit of the pipe address, which is stored in the WINUSB_PIPE_INFORMATION structure's PipeId member. The simplest way to determine the direction of the pipe is to pass the PipeId value to one of the following macros from Usb100.h:
USB_ENDPOINT_DIRECTION_IN (PipeId)macro returns TRUE if the direction is in.
USB_ENDPOINT_DIRECTION_OUT(PipeId)macro returns TRUE if the direction is out.
The application uses the PipeId value to identify which pipe to use for data transfer in calls to WinUSB functions, such as WinUsb_ReadPipe (described in the 'Issue I/O Requests' section of this topic), so the example stores all three PipeId values for later use.
The following example code gets the speed of the device that is specified by the WinUSB interface handle.
The following example code queries the various descriptors for the USB device that is specified by the WinUSB interface handle. The example function retrieves the types of supported endpoints and their pipe identifiers. The example stores all three PipeId values for later use.
Step 3: Send Control Transfer to the Default Endpoint
Next, communicate with the device by issuing control request to the default endpoint.
All USB devices have a default endpoint in addition to the endpoints that are associated with interfaces. The primary purpose of the default endpoint is to provide the host with information that it can use to configure the device. However, devices can also use the default endpoint for device-specific purposes. For example, the OSR USB FX2 device uses the default endpoint to control the light bar and seven-segment digital display.
Control commands consist of an 8-byte setup packet, which includes a request code that specifies the particular request, and an optional data buffer. The request codes and buffer formats are vendor defined. In this example, the application sends data to the device to control the light bar. The code to set the light bar is 0xD8, which is defined for convenience as SET_BARGRAPH_DISPLAY. For this request, the device requires a 1-byte data buffer that specifies which elements should be lit by setting the appropriate bits.
The application can set this through the user interface (UI), such as by providing a set of eight check box controls to specify which elements of the light bar should be lit. The specified elements correspond to the appropriate bits in the buffer. To avoid UI code, the example code in this section sets the bits so that alternate lights get lit up.
Use the following steps to issue a control request.
Allocate a 1-byte data buffer and load the data into the buffer that specifies the elements that should be lit by setting the appropriate bits.
Construct a setup packet in a caller-allocated WINUSB_SETUP_PACKET structure. Initialize the members to represent the request type and data as follows:
- The RequestType member specifies request direction. It is set to 0, which indicates host-to-device data transfer. For device-to-host transfers, set RequestType to 1.
- The Request member is set to the vendor-defined code for this request, 0xD8. It is defined for convenience as SET_BARGRAPH_DISPLAY.
- The Length member is set to the size of the data buffer.
- The Index and Value members are not required for this request, so they are set to zero.
Call WinUsb_ControlTransfer to transmit the request to the default endpoint by passing the device's WinUSB interface handle, the setup packet, and the data buffer. The function receives the number of bytes that were transferred to the device in the LengthTransferred parameter.
The following code example sends a control request to the specified USB device to control the lights on the light bar.
Step 4: Issue I/O Requests
Next, send data to the device's bulk-in and bulk-out endpoints that can be used for read and write requests, respectively. On the OSR USB FX2 device, these two endpoints are configured for loopback, so the device moves data from the bulk-in endpoint to the bulk-out endpoint. It does not change the value of the data or add any new data. For loopback configuration, a read request reads the data that was sent by the most recent write request. WinUSB provides the following functions for sending write and read requests:
To send a write request
- Allocate a buffer and fill it with the data that you want to write to the device. There is no limitation on the buffer size if the application does not set RAW_IO as the pipe's policy type. WinUSB divides the buffer into appropriately sized chunks, if necessary. If RAW_IO is set, the size of the buffer is limited by the maximum transfer size supported by WinUSB.
- Call WinUsb_WritePipe to write the buffer to the device. Pass the WinUSB interface handle for the device, the pipe identifier for the bulk-out pipe (as described in the Query the Device for USB Descriptors section of this topic), and the buffer. The function returns the number of bytes that are actually written to the device in the bytesWritten parameter. The Overlapped parameter is set to NULL to request a synchronous operation. To perform an asynchronous write request, set Overlapped to a pointer to an OVERLAPPED structure.
Write requests that contain zero-length data are forwarded down the USB stack. If the transfer length is greater than a maximum transfer length, WinUSB divides the request into smaller requests of maximum transfer length and submits them serially.The following code example allocates a string and sends it to the bulk-out endpoint of the device.
To send a read request
- Call WinUsb_ReadPipe to read data from the bulk-in endpoint of the device. Pass the WinUSB interface handle of the device, the pipe identifier for the bulk-in endpoint, and an appropriately sized empty buffer. When the function returns, the buffer contains the data that was read from the device. The number of bytes that were read is returned in the function's bytesRead parameter. For read requests, the buffer must be a multiple of the maximum packet size.
Zero-length read requests complete immediately with success and are not sent down the stack. If the transfer length is greater than a maximum transfer length, WinUSB divides the request into smaller requests of maximum transfer length and submits them serially. If the transfer length is not a multiple of the endpoint's MaxPacketSize, WinUSB increases the size of the transfer to the next multiple of MaxPacketSize. If a device returns more data than was requested, WinUSB saves the excess data. If data remains from a previous read request, WinUSB copies it to the beginning of the next read request and completes the request, if necessary.The following code example reads data from the bulk-in endpoint of the device.
Step 5: Release the Device Handles
After you have completed all the required calls to the device, release the file handle and the WinUSB interface handle for the device. For this, call the following functions:
- CloseHandle to release the handle that was created by CreateFile, as described in the step 1.
- WinUsb_Free to release the WinUSB interface handle for the device, which is returned by WinUsb_Initialize.
Step 6: Implement Main
The following code example shows the main function of your console application.
If your device supports isochronous endpoints, you can use WinUSB Functions to send transfers. This feature is only supported in Windows 8.1.
For more information, see Send USB isochronous transfers from a WinUSB desktop app.
WinUSB Architecture and Modules
WinUSB (Winusb.sys) Installation
WinUSB Functions for Pipe Policy Modification
WinUSB Power Management
Write a Windows desktop app based on the WinUSB template
Anyone who has fiddled a bit with USB devices recognizes the infamous Windows pop up message 'This device can perform faster'. This message is a result of two USB communication speeds, known as USB1.1 and USB2.0. Great! But heck, it pops up on two UBS2.0 DELL latitude D610 laptops and one USB2.0 workstation. On top of that on a LINUX UBUNTU installation in a different format. Time for a bit of digging where 'This device can perform faster' Windows message comes from.
One USB 2.0 Hi-Speed card reader produced the 'This device can perform faster' pop up message from day 1. A quick test with various other USB 2.0 mass storage devices (USB stick, USB hard drive) and USB printers DO NOT produce 'This device can perform faster' pop up message. So the USB drivers and USB hardware seem to be very much OK.
| This device can perform faster - USB 2.0 Hell|
The USB2.0 Hi-Speed detection mechanism is not rocket science, it's a matter of writing decent driver software. So why do these misleading messages pop-up?
In a hurry?Go directly to USB 2.0 Hi-Speed findings
Next a Tiptel 150 USB connected VOIP phone caused the same Windows XP behavior, right from start. Although the consequence here is less, the phone works ok, the slower USB1.1 speed is enough for calling over the internet. The USB 2.0 card reader however operates very slow, copying 2Gb memory cards took ages.
Now what is wrong here? The Dell Latitude D610 has USB 2.0 ports as the other mass storage devices already indicate. The generic USB 2.0 capable drivers from windows XP pro operate as they should. It seems like there's an incompatibility problem between USB devices on a lower level than USB driver software. So at this stage installing different USB drivers doesn't seem to make any sense.
|Cheap All-in-One Cardreader advertised as USB2.0||Tiptel 150 USB VOIP phone|
The D610 Latitude is equipped with a Intel 82801 FB/FBM USB2 Enhanced Host Controller. Very common USB controller hardware found in many laptops and desktops. Through 'Properties' of 'My Computer' the 'Manage' menu item shows if a Windows system has USB2.0 Hi-Speed capabilities:
The 'Enhanced' part in the name indicated USB 2.0 specifications.
Opening the USB 2.0 Hi-Speed card reader reveals a single chip - the AU6371 USB 2.0 Single LUN Multiple Flash Card Reader Controller from Alcor Micro Corporation located in Taiwan. Surprisingly the controller chip range is mentioned at the website, however the AU6371 is not available anymore. The newer AU6372 - the 9-in-1 USB flash card reader chip - now has the spotlight and is released in October 2003. The AU6371 most likely is released before 2003. Also the Intel 82801 USB2 Enhanced Host Controller stems from this era. The USB 2.0 Hi-Speed card reader is bought in Dubai in 2008, so the AU6371 is still in stock and sold as recent USB hardware.
The Alcor Micro website doesn't host any drivers for the USB controller chip so generic Windows XP drivers should do the job. But it doesn't, the card reader operates at slow USB 1.1 speeds.
Opening the Tiptel 150 VOIP phone reveals another brainy controller chip. The CY7C64713 is a EZ-USB FX1™ USB Microcontroller Full-speed USB Peripheral Controller made by Cypress Semiconductor Corporation. A quick glance through the chip specification results in an interesting statement: 'FX1 operates at one of the three rates defined in the USB Specification Revision 2.0, dated April 27, 2000: Full speed, with a signaling bit rate of 12 Mbps'. Well that's basically USB 1.1 speed! That's one problem solved - the VOIP phone is not designed for USB 2.0 Hi-Speed use. The Windows pop-up message 'This device can perform faster'is therefor wrong and misleading; The Tiptel 150 USB VOIP phone can not operate at high USB speeds.
Kinds Of Usb Devices
Now with the Tiptel 150 VOIP phone, clearly identified as USB 1.1 because it's USB controller (CY7C64713) can't go any faster, let's plug it into a USB 1.1 port on an ole DELL Optiplex with Windows XP Pro (SP1). Heck! The USB1.1 VOIP phone is AGAIN classified as High Speed USB2.0. At least Windows XP gets the controller right, it's a non-Hi-Speed USB Hub - know as the Intel 82371 AB/EB PCI to USB universal host controller. What a mess - no wonder the USB driver (re-)installation orgy found on the Internet!
Note: SP1 has no USB2.0 support by default. USB 2.0 Hi-Speed drivers have to be installed manually, starting with the USB host controller.
Now for the USB 2.0 Hi-Speed card reader - somehow USB 2.0 High Speed - capability identification goes sour between the Intel 82801 USB2 Enhanced Host Controller and the AU6371 USB 2.0 Controller chip. The Intel 82801 already proved it can operate at USB 2.0 speeds, so what about the AU6371 Controller chip? A quick test in a Pentium 4 - USB2.0 workstation with Windows XP Home produces the same message, the USB 2.0 Hi-Speed card reader is detected as a USB1.1 device. The Pentium 4 work station has the same chipset, the Intel 82801 USB2 Enhanced Host Controller.
At the same time a different 6 in 1 USB 2.0 card reader connects without a problem. This card reader has a Integrated Circuit Solution, Inc. (ICSI) IC1110 USB 2.0 Flash Card Reader controller inside. (ICSI is also known as Integrated Silicon Solutions, Inc - ISSI)
With these strange findings, let's see how a LINUX install copes with the USB 2.0 Hi-Speed card reader on a DELL Latitude D610 laptop.
The UBUNTU website serves a neat LINUX install resulting in a bootable UBUNTU 9.04 CD within 2,5 hours using NERO Burning ROM. This free LINUX version is installed as a multi-boot partition next to a Windows XP SP3 install - all straight out of the UBUNTU box. With UBUNTU up and running, the USB 2.0 test with the USB 2.0 Hi-Speed card reader can commence. And it connects smoothly, silently popping up as a USB disk device. UNBUNTU doesnt show if it's USB2.0 directly. So a 256 Mb Memory Card from a Sony T1 is installed for a quick copy test. 71 Mb of pictures are copied at a speed of approximatly 1012 KByte/sec. Hmmmm, sounds like that's USB 1.1 again. To know for sure, /var/log/messages was opened and it contained the following log entries:
- usb 4-1 new full speed USB device using uhci_hcd and address 3
- usb 4-1 not running at top speed; connect to a high speed usb
Looks similar to the Windows XP Pro USB mess. The log entries with 'uhci_hcd' and 'full speed' is similar to USB 1.1. It should mention 'ehci-hcd' and 'high speed'. So with a totally different OS on the same hardware, the USB 2.0 Hi-Speed card reader still connects as a slow USB1.1 device.
Connecting a LaCie 160 Gb USB2.0 disk with UBUNTU 9.04 running on a DELL D610 Latitude laptop immediately results in a Hi-Speed USB2.0 link. No need for manual 'sudo modprobe ehci_hcd' commands because UBUNTU 9.04 automatically loads the right USB module. Now /var/log/messages looks like this;
- USB 1-5 new high speed USB device using ehci_hcd and address 3
- USB 1-5 configuration #1 chosen from 1 choice
- scsi 3 : SCSI emulation for USB Mass Storage devices
- scsi 3:0:0:0: Direct-Access FUJITSU MHW2160BH PQ: 0 ANSI: 2 CCS
NOTE:: Trying to manually load the ehci_hcd module using modprobe results in 'FATAL: module ehci_hcd not found'. With the above results, this seems to be normal.
Chances are bleak that the USB 2.0 Hi-Speed Memory Card Reader will ever perform at High USB Speeds.
So far it seems to be a hardware issue with the Memory Card Reader where Windows XP Pro adds even more confusion.
Now back to Windows XP Pro again. A much repeated remedy to get USB 2.0 devices operate at USB High speed is to uninstall all USB devices in the Windows Device Manager and restart. The reasoning behind it is; Service Pack 1 has no USB 2.0 support. So for all those who migrated their XP installation from SP1 to SP2, already registered USB 2.0 devices continue to operate on USB 1.1 speeds. Sound legit. So lets give that one a try with SP3 installed. So open the Computer Management console (My Computer - right click - Manage), select the device manager and start uninstalling all USB host controllers. Pretty simple - they're gone in a few minutes. Restart and Windows XP Pro detects the USB hardware right away.
Now it got really really really weird with re-installed USB device drivers. Windows XP Pro SP3 reports the USB 2.0 Hi-Speed card reader as a High Speed USB 2.0 device and the Host controller as USB 1.1. With SP2 it was the other way around. So what's the verdict with the USB 1.1 VOIP phone? Wow!! it's also reported as a USB2.0 device. What a total mess - SP3 should be an improvement?
The list is long of devices that do work at High Speed WITHOUT re-installing USB drivers. Too give a few examples of much used USB Hi-Speed devices:
- LaCie 160 Gb USB disk (Design By Porsche) with JM20339 USB2.0 to SATA Bridge
- NoName 120 Gb USB disk with M110B USB 2.0 To IDE Bridge (PATA)
- HP Deskjet F300 series with USB2.0 interface with unknown USB controller
And those USB 2.0 devices work flawlessly from day 1 on USB 2.0 speeds with:
- DELL Latitude D610 with XP Pro SP2
- DELL Latitude D610 with XP Pro SP3
- DELL Optiplex Gx110 with Xp Pro SP1
- NoName P4 with XP Home
- DELL Latitude D610 with UBUNTU 9.04 (Linux variant)
All have been tested with the above mentioned USB2.0 memory card reader and all OS configurations switch to USB1.1. Only Windows XP add's more confusion to the already hard to diagnose USB 2.0 Hi-Speed mess. The correct USB message here would be: 'USB non-Hi-Speed device connected to USB Hi-Speed Hub'.
Looking closer at the USB 2.0 High Speed - capability identification shows a rather simple mechanism and is known in the USB industry as 'chirping'. At connect the USB device receives 'USB RESET' command from the host controller. If the USB device has high speed capabilities it answers the USB RESET by raising one of the communication lines (D-) to +5Volts. In turn the host controller 'chirps' (raising D- and D+ lines alternating) indicating it's own USB 2.0 High speed capabilities. From here communication continues at USB 2.0 speeds.
Now for the USB 2.0 Hi-speed card reader, where does the USB Hi-speed identification go sour? A few possibilities, assuming the host controller initiates the USB reset;
- The USB device doesn't respond according to USB specification, because;
- The USB reset is not received correctly (voltage & timing)
- The USB reset response is incorrect (voltage & timing)
- The USB device does respond within USB specifications, but
- the host controller doesn't interpret the response as correct (timing) and stays at USB1.1.
- the USB device doesn't see the 'chirping' correctly and stays at USB1.1 speed.
Most likely - in this case, it's scenario 1b where the timing of the D- signal is off mark and the USB host controller continues at USB 1.1 (Full speed iso Hi-Speed).
In this case changing Windows driver software doesn't help for one bit. The problem lies at chip level, not at the Windows driver level. For those with USB devices with on-board firmware in (flash) memory, there is a chance changing USB device driver software might help. Controller chip dependent USB2.0 detection software, following signal and timing specification in the graph above, requires good programming usually implemented on small real-time OS kernels. This is specialist embedded software programming where timing is crucial. For PC based host controllers the right driver does the trick. And as shown in this case, compatible USB 2.0 controller chipsets can make a big difference.
Not surprisingly, there's USB2.0 High Speed certification. Those USB integrators / manufacturers who pass the USB-IF Compliance Testing Program may carry the USB Hi-speed certificate on their products. The cheap USB2.0 card reader mentioned above did not have the USB Hi-speed certificate - at least not on the product package. But as usual, logo's can be copied easily and can appear on products not certified at all. For those USB devices where high speed communication is crucial, such as a memory card reader, it might safe a bit of time and frustration to have a device with a USB 2.0 compliant USB controller inside.
Now, just for the heck of it, did the AU6371 chip from Alcor Micro Corporation pass the USB-IF Compliance Testing Program? Yes it did, the AU6371 chip is listed in the the USB Hi-Speed compliance database, however with revision number A41. The USB Hi-Speed compliance entry is created at 6 august 2006. According to the Alcor website, the AU6371 is released in October 2003. It could be that early releases of the AU6371 controller didn't function properly and are still available in the 'wild'.
The UBUNTU linux installation lists the Memory Card Reader with serial number Multi_Flash_Reader_058F001111B1-0;0 with firmware version 1.0. The latter version sounds very virgin...
With SP3, it's possible to get rid of the infamous USB messages. Apparently some-one at Microsoft agreed the slow USB speed reminders are not always so much fun to look at.
Don't try to find this 'feature' in Windows XP versions prior to SP3.
Based on the findings above, the USB 2.0 Hi-Speed stuff that really sticks out;
|1) Not all USB 2.0 devices are really USB2.0 compliant, |
in this case the AU6371.
2) Windows USB messages are misleading, specially
in the case of 1)
3) Windows SP1, SP2 and SP3 have different USB
Hi-Speed messaging behaviors
4) UBUNTU 9.04 on the same hardware also
logs misleading USB info in case of 1).
|High Power WIFI adapter - USB connected|
Drivers Tiptel USB Devices
No wonder the USB driver (re)-installation orgy found on the internet. When USB messages can not be trusted in combination with the absence of decent USB error reporting it takes a lot of cross-PC / OS testing to make any sense of this USB 2.0 Hi-Speed Hell.
To get your system communicating at USB2.0 hi-speed the following can be done:
|- Check USB 2.0 hardware in your computer|
- Check USB 2.0 drivers for your OS (Windows, Linux)
- Check USB2.0 device if it communicate at USB2.0 Hi-speed
- Check USB2.0 certification of the USB2.0 device
As in the above example, USB devices branded as USB2.0 can fail to communicate at USB2.0.
This is decided within 10 ms (mili-seconds) using the USB 2.0 detection mechanism.
Drivers Tiptel Usb Devices Dongle
In 2010 USB 3.0 will make a debut, read how to use USB 3.0 with your laptop or notebook.