- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
we know that the specs says that we need a 3.0 port but I have an old machiine just with 2.0 ports and when I connect the cam, the so recognices it and install the drivers but the green led doesn't turn. Does somebody have tried to use it well in those conditions? If not, could exist some hardware/software solution?
Thank you
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Probably some parts of the cam will work, such as the initialization, and listing on the hub, etc, but the actual camera needs a proper USB 3.0 connection. You can't really use it if you don't have one. Sorry.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a thread on the limitations of 4th generation processors, Windows operating system and USB ports. In this thread, nobody has reported any success with a USB 2 port.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SDK and camera are designed to use USB3 on Haswell CPU running Windows 8.1. I suspect that the SDK and camera may well be capable of working with USB2, Ivy Bridge and Windows 7 however the SDK and camera driver will check for SuperSpeed, Haswell and Windows 8.1 so Intel have a more controlled environment to support.
David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think the main bottleneck is the bandwidth.
USB2 has a bandwidth of 480 Mbit/s, whereas USB3 has roughly 10 times that.
In order to be able to stream color at 1920x1080@30Hz, depth and IR at 640x480@60Hz, you would need a lot of bandwidth:
- PIXEL_FORMAT_RGB32 Color (BGRA with 8 bits each channel): 1920x1080x30x8x4 = 1,990,656,000 bits/sec = 1898.4375 Mbit/s (this is almost 4 times more than USB2 bandwitdh)
- PIXEL_FORMAT_DEPTH_F32 Depth (One 32 bit floating point channel): 640x480x60x32 = 589,824,000 bits/sec = 562.5 Mbit/s (this is more than USB2)
- PIXEL_FORMAT_Y16 IR (One 16 bit unsigned int channel): 640x480x60x16 = 294,912,000 bits/sec = 281.25 Mbit/s (about half USB2 bandwith)
So, if you are streaming all those 3 channels, you end up with 2742.1875 Mbit/s, which is almost 6 times the bandwith of USB2, but still less than the bandwith you have in USB3, which is about 10 times USB2.
Therefore, there is no way you could run this camera at these specs on a USB2 port.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would like to reiterate this question and hopefully get someone from Intel to provide clarification.
While USB 2.0 does not provide sufficient bandwidth to stream multiple streams in high resolutions, the bandwidth is indeed sufficient for simultaneous color and depth streams in lowest resolutions.
I gave it a try using the R200 camera with SDK on Windows and with librealsense on Linux and in both cases it did not appear to work. The connection was through a USB 2.0 cable to a USB 3.0 port, so I believe power requirements were met,
I would appreciate clarification on the compatibility with USB 2.0. With the recently-released Linux driver it would be great to have opportunity to use RealSense in embedded systems, which mostly lack support for USB 3.0.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The requirement is and always has been for USB 3.0 - due to power and bandwidth. Many people on this forum already know that even weak USB 3.0 does not meet the requirements. USB 2.0 is not supported. There is already a tremendous amount of validation required just within the given specs, pushing on other setups is outside the scope of this forum.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page