USB speed selection

[tveenker]

Hi,

I'm creating a Teensy 3.1 based device for scientific usage. For synchronizing clocks I'm doing a round trip from PC to Teensy and back to PC again and then process the results. I'm working under Linux (Mint 13, kernel 3.2.0-23).

The odd thing is that the round trip takes more time when the Teensy's USB cable is directly plugged in my PC compared to plugged in via an active 5m USB extender. When connected via the extender the round trip duration is about 80us..200us, whereas it is about 200us..1000us when plugged in directly.

Looking at the logs (attached) I noticed that in the slower/direct case the system uses uhci_hcd. In the faster/extender case the system uses ehci_hcd. Since communication works fine with the ehci_hcd driver I wonder why does the system decide it needs to use the uchi_hcd driver for the Teensy. Or better, can I do something on the Teensy side to tell the system that the plugged in device is a high speed device rather than a full speed device?

Theo

 

[steckdenis]

Hi,

I once had a similar problem with an external hard drive that was detected as being USB 1.1 instead of USB 2.0, even though both the external drive and the computer were USB 2.0-compliant. The external drive had an on-off button that allowed me to plug the drive without having it start to spin. I've discovered that, if I connected the drive while it was on the "off" position, and then powering it on, an USB 2.0 connection was used.

After a bit of research, I discovered that the USB 1.1 vs USB 2.0 selection is based (among others) on the voltage drop that happens when a device is plugged in. In the case of my external hard drive, having it start as soon as it was plugged in resulted in a big drop of voltage at the USB port, and made the device identified as USB 1.1. When I plugged it while still being in the "off" position, the disk did not try to start too early and no voltage drop was observed by the computer.

This seems a bit strange, but maybe your Teensy-based device consumes a lot of current when plugged-in (capacitors are charged, for instance). Your active extender may be able to provide more current to your device, or does not measure the voltage drop and always considers your device as an USB 2.0 one. Verify that you don't charge big capacitors when the Teensy is connected. Note also that I've read somewhere that if you have soldered a capacitor under the Teensy board (to make it an USB host), you cannot use it as an USB device anymore (because the capacitance is too big for an USB device).

(if you want a fast connection between the computer and the device, PJRC recommends to use the USB CDC (Serial) device type, not USB HID)

 

[Frank B]

Did you try a short high-quality usb-cable ?

 

[tveenker]

After a bit of research, I discovered that the USB 1.1 vs USB 2.0 selection is based (among others) on the voltage drop that happens when a device is plugged in. In the case of my external hard drive, having it start as soon as it was plugged in resulted in a big drop of voltage at the USB port, and made the device identified as USB 1.1. When I plugged it while still being in the "off" position, the disk did not try to start too early and no voltage drop was observed by the computer.

Interesting, didn't know that. What an odd way of differentiating between full/high speed mode.

This seems a bit strange, but maybe your Teensy-based device consumes a lot of current when plugged-in (capacitors are charged, for instance). Your active extender may be able to provide more current to your device, or does not measure the voltage drop and always considers your device as an USB 2.0 one. Verify that you don't charge big capacitors when the Teensy is connected. Note also that I've read somewhere that if you have soldered a capacitor under the Teensy board (to make it an USB host), you cannot use it as an USB device anymore (because the capacitance is too big for an USB device).

I'm not using it in host mode. I just tried a Teensy 3.0 alone on a breadboard. Same thing, full speed, not high speed. My device has an external power option, but using that also doesn't make a difference. When restarting the Teensy in software, which is supposedly the same as pulling out the USB connector end reinserting it (but any capacitors would remain charged) it is still recognized as a full speed device.

(if you want a fast connection between the computer and the device, PJRC recommends to use the USB CDC (Serial) device type, not USB HID)

I'm using Serial indeed (well, also Serial1 (RS232) for longer distance communication).

 

[tveenker]

About cables. I tried a bunch of cables, short, long, quality, crap. The results are consistent. When going via the extender I get high speed, without it I get full speed. Hmm.

 

[tveenker]

Plugging the Teensy to a USB-3 port the system still recognizes it as a full speed device, but it is then using xhci_hcd and it gives me the desired short round trip latency. Apparently when the system decides to use echi_hcd communication is slow(er), when echi_hcd or xhci_hdc are used things are fine. I suspect in all speeds the teensy operates at 12Mbit/s which is quite OK, but maybe there is some overhead involved when the system thinks it is talking to a USB-1 device? Does that make sense?

 

[PaulStoffregen]

Since communication works fine with the ehci_hcd driver I wonder why does the system decide it needs to use the uchi_hcd driver for the Teensy.

The answer is on your PC. Somehow Linux believe it's a different USB controller.

Maybe that extender cable has some electronics inside? Maybe some type of USB hub?

Or better, can I do something on the Teensy side to tell the system that the plugged in device is a high speed device rather than a full speed device?

No, not really. USB devices don't get to control such things.

I suspect in all speeds the teensy operates at 12Mbit/s which is quite OK

Yes, Teensy 3.1's USB always works at 12 Mbit/sec. It does not support any other speed, not even the slower 1.5 Mbit/sec rate.

, but maybe there is some overhead involved when the system thinks it is talking to a USB-1 device? Does that make sense?

No, not really.

My guess is there's a hub at play, where the "transaction translator" in the hub matters, versus the "root hub".

This is really a Linux question. I'm not sure where you'd have any chance of getting a good answer... but maybe there's a Linux mail list or forum somewhere where you could ask?

 

[tveenker]

Yes the extender reports as a four port hub (although it has only one output).

I'll see if I can blacklist the uhci_hcd driver. I don't mind tweaking my own system if it improves IO performance. But I'd rather not force my clients to do this. Well, maybe I should first check a few other systems to see what gives.

Thanks.