I have to test how a High speed USB device behaves when it runs at Full speed.

As High speed runs at 480 MHz and Full speed at 12 MHz I thought this would be easy with a "low pass filter" that does not allow the high frequencies to pass and so the host would automatically negociate a slower speed with the device.

I opened a USB cable and soldered a capacitor between Data+ and Data- like that: enter image description here

But although I tried several values for the capacitor it did not work.

When I connect 3.3pF, 6.8pF or 12pF the device will work with High speed. How did I prove that? I connect a USB stick and transfer a big file. The transfer speed is 20 Megabyte/s which is too fast for Full speed.

When I increase the capacitor to 15pF or more I suddenly see the device working with Low speed (1.5MHz) or even failing completely (device enumeration failed)

I tried this on two different computers. The mainboard has USB2.0 hubs and USB3.0 hubs. No difference in bahaviour. I tried on Windows XP and Windows 7.

There is no way get Full speed. Either High speed or Low speed or nothing.

Can anybody explain me that? How do I force the device to run at Full speed?

UPDATE: 9 month after asking this question (and being more expert in USB stuff), I know today that USB does not have a fall-back mechanism. If a high speed device does not respond as expected the device enumeration will simply fail. The computer does not try to communicate with a high speed device in full speed after a high speed negociation has failed and neither does the device fall back to full speed mode. The only way to force full speed is to use a full speed hub (USB 1.1), which are very difficult to find nowadays.

  • 6
    \$\begingroup\$ Software. Just tell your USB host controller to only provide full speed. It's just a driver setting. \$\endgroup\$ – Marcus Müller Jun 17 '17 at 20:02
  • 3
    \$\begingroup\$ Plug the device into a USB 2.0 hub that only supports Full Speed and Low Speed modes (not High Speed). \$\endgroup\$ – MarkU Jun 17 '17 at 20:03
  • 3
    \$\begingroup\$ Speed in not determined by cable bandwidth, it is negotiated. usbmadesimple.co.uk/ums_6.htm \$\endgroup\$ – Bruce Abbott Jun 17 '17 at 20:06
  • 4
    \$\begingroup\$ BTW: USB HS runs at 480 Mbps, not 480 MHz, and FS likewise is 12 Mbps, not 12 MHz. Due to the encoding scheme (NRZI) there may be long runs of up to 6 bits of the same value, meaning the frequency spectrum is distributed, with components well below 480 MHz/12 MHz, and above, due to the edge rates. Hence, you cannot consider either as a single frequency. \$\endgroup\$ – uint128_t Jun 18 '17 at 6:04
  • \$\begingroup\$ @Marcus: I have read on Stackoverflow that Microsoft does not provide any way to configure the driver to run at Full Speed. If you have any detailed information how to do that and if you have tested that this really works (not just theory) let me know how to configure that. stackoverflow.com/questions/19945124/… \$\endgroup\$ – Elmue Jun 19 '17 at 17:14

The issue is that the FS mode is negotiated during attach/port reset event. Any HS device signals the connect event by pulling up D+ data line just as a FS device would do. The host, seeing the connect, initiates "USB_RESET" state, dragging both D+ and D- to ground with 45-Ohm driver. Then, if a device is HS, it pulls "Chirp-K" signal on D- wire. A HS device must always do this, you can't avoid this signal phase.

The host does recognize the Chirp-K, and after a special chirping sequence, both Host ans Device recognize the HS mode. You can find more details HERE.

The problem in your case is that suppressing signal quality at HS mode doesn't remove the chirping sequencing. Since the chirping comes at much lower switching rate (~ 10MHz), you can't suppress it without harming the FS data signaling mode. That's why a simple impeding of HS data rate doesn't work.

There are three options to validate a HS device ability to run on FS mode:

  1. Have a USB 1.1 hub, as suggested by duskwuff;
  2. Get a USB host that supports only USB 1.1 (Arduino flavours, Cypress, whatever)
  3. Get a normal (older) PC that is built around Intel EHCI controller, and disable the EHCI part of it in Device Manager. The remaining UHCI controller (or OHCI in AMD line) will provide the FS functionality.

CORRECTION: The chirp sequence J-K-J-K-... is specified to have pulses between 40us and 60us, see Section of USB 2.0 specifications. All designs have it in the center, 50 us. Which makes the chipring frequency at 10 kHz, not 10 MHz, my bad. This frequency disparity makes it impossible to suppress chirps by filtering given the FS signaling rate is 6 MHz.

  • \$\begingroup\$ That's interesting. I supposed that the Chirp is at 480MHz. Where did you read that it is only at 10 MHz? \$\endgroup\$ – Elmue Jun 19 '17 at 17:21
  • \$\begingroup\$ @Elmue Read specifications. The initial chirp-K is about 1-2 ms, and subsequent J-K alternations are coming in 50 uS pulses. \$\endgroup\$ – Ale..chenski Jun 19 '17 at 17:27

Attach the device to a USB 1.1 hub. They're still commercially available.

  • \$\begingroup\$ Actually, USB 1.1 hubs are not easy to find these days. But you can find an evaluation board for HS hub configured as FS-hub only, specifically for USB-IF Golden Tree interoperability tests. See digikey.com/product-detail/en/microchip-technology/… \$\endgroup\$ – Ale..chenski Jun 20 '17 at 18:37
  • \$\begingroup\$ It is extremely difficult to buy one today. I finally found a Belkin 7 port hub F5U027 on eBay. It is full speed from 2001. Very good quality. It comes with a 4 A power supply and lifetime warranty! But very expensive ($79). \$\endgroup\$ – Elmue Oct 13 '17 at 0:50

@duskwuff has a good solution. The reason your approach didn't work is that the USB autonegotiation is based on the advertised capabilities of the host, device and any hubs - no attempt is made to characterize the cable loss.

  • \$\begingroup\$ If this is true, I think that the USB protocol is misdesigned. If High speed does not work because the cable is of bad quality or because the cable is too long, why does the USB protocol not provide a way to use that same cable with full speed instead? That would be better than failing completely. \$\endgroup\$ – Elmue Jun 19 '17 at 17:22
  • \$\begingroup\$ Take it up with the USB IF, but I'm sure it was a conscious decision. Could be for a few reasons - cost of additional hardware needed to support link training, or the desire to present a consistent experience to the user (either it works as intended or it doesn't work at all) \$\endgroup\$ – pericynthion Jun 19 '17 at 17:44
  • \$\begingroup\$ Well, the USB spec provices an "Other Speed" descriptor for all high speed devices which is intended to be used when the high speed device runs at full speed. So the majority of high speed devices has been designed to work also at full speed. For a camera this may not be usefull, but for any device that just transfers files it would just work slower. \$\endgroup\$ – Elmue Jun 19 '17 at 17:55
  • 1
    \$\begingroup\$ @Elmue, it is not the "majority of HS devices", every HS device MUST work in FS environment. The FS framework has reduced capabilities, shorter max packet length, etc, and thus requires another, FS-tailored set of descriptors, for the "other speed". If a device is HS, and a host is HS, there is no excuse to have a bad non-compliant cable. For marginal cables the USB has a mechanism of silent re-tries, so the link will sort-of work, sometimes to a confusion of users. It takes an additional engineering effort to detect and eliminate this marginal condition. \$\endgroup\$ – Ale..chenski Jun 20 '17 at 1:54
  • 1
    \$\begingroup\$ @Elmue , actually, nobody prevents a designer to make a "smart HS" device that would fall back to FS-only mode if several sequential attempts to communicate at initial high-speed were not successful. When such a device encounters this, it just blocks the HS set of descriptors, disconnects, and re-connects as FS only (not starting the Chirp-K handshake). The host will then proceed in FS mode. It is doable, but USB doesn't mandate this behavior. This behavior will just hide the root cause of the problem (signal integrity), which doesn't help at system level. \$\endgroup\$ – Ale..chenski Jun 20 '17 at 2:08

There are also usb isolators out there that will block the inital hand shake. You can find them here.

Also adafruit sells breakout boards here

  • 1
    \$\begingroup\$ Could you clarify the basis of your claim that these "will block the initial hand shake"? It's been explained here already that analog signal degradation isn't really enough to do that well - if you are claiming this implements a protocol-level block of switching to high speed mode, can you site specific evidence for that? \$\endgroup\$ – Chris Stratton Mar 14 '18 at 22:46
  • \$\begingroup\$ Sounding like this was nothing but a guess - specifically, an incorrect guess. \$\endgroup\$ – Chris Stratton Mar 15 '18 at 16:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.