Verified PCIe to USB3


I’m looking for a USB3 PCIe card that’s known to work very reliably with the TX2, provides the full 5Gbps throughput, and fits on the dev board.
Could someone please recommend one?


Er, what’s wrong with the USB already on the TX2?

I’m running into the same reliability issues already mentioned on the forums using my Realsense cameras.
Based on what I could gather, other high throughput devices are affected too, so is the TX1 with recent Jetpack versions, but not older ones.

I don’t have the time to debug a Kernel USB driver bug at the moment, so I’m hoping using a different USB chipset will allow me to circumvent it.
It’s a pain having to physically unplug and replug my devices every few minutes.

Hi JeremyHX,

May I know what’s the issue you met?

And, this is the transcend USB3 PCIe device we have, we checked the functionality by connecting Seagate USB 3.0 HDD to this USB3 PCIe card


Thanks, I’ll try it if I can find it in stock somewhere.

In short - lots of LIBUSB_ERROR_IOs when I reopen the camera feed after closing it, or when I change cameras parameters, and sometimes after a long time just having the feed open. They more often than not leave the camera in an unstable state, and I have to physically unplug it to get it back to work properly.
I’ve tried three different powered USB3 hubs, and three different 3D cameras (Realsense ZR300, Realsense SR300, Kinect2). I run into that same issue with all of them.
I have no such issue when using an Intel Atom board.

FYI - the card works but it didn’t solve my issue.
I guess the bug is higher up the stack. Maybe video4linux or libusb.
Oh well… Was worth a try.

I doubt the bug would be in user space (libusb) if you get LIBUSB_ERROR_IO.
Perhaps the card you plugged in uses the same driver as the onboard USB? In general, most USB controllers are compatible with the *HCI standards and thus use the same driver.

I am curious if these changes (they’re temporarily till reboot) alter the error (try a fresh boot, alter these values, then check camera behavior in comparison to what normally happens):

# These double defaults:
sudo echo "40" > /proc/sys/vm/dirty_ratio
sudo echo "20" > /proc/sys/vm/dirty_background_ratio

Didn’t help. Thanks though. I’ll investigate a bit more and open a separate thread on this question later.