How well the SR300 would function with your machine likely depends on whether its Xeon 1607 processor is the V3 or V4 model. If it's V3, it's probably a 4th generation Haswell chip architecture. This works with the SR300's predecessor the F200 camera. The SR300's official minimum requirement is a 6th generation Skylake architecture processor though.
However, although that is the official spec, it is not as absolute as that. The V4 Xeon is 5th generation Broadwell, and these have been shown to function sometimes with the SR300, even though it's a generation behind the minimum spec. It's a lucky dip really whether a particular V4 Xeon machine works with the SR300 or not.
The fact that you can stream depth suggests that the camera has at least some of the functionality that it is supposed to when it is used with your Xeon, otherwise I would only expect you to be able to get a basic RGB image like an ordinary webcam. The processor type would certainly help explain why you may get better performance from the camera on another machine, if that machine has a 6th gen Skylake or 7th gen Kaby Lake processor.
Your mention of the hand and cursor modes not working though makes me ask whether you are using the '2016 R3'. RealSense SDK. Unlike previous SDKs, the new R3 SDK is split into a core 'Essentials' module and a series of optional feature modules such as hands, face, cursor and 3D scan that have to be downloaded and installed separately. Are you using the R3 SDK?
Hello MartyG, and thanks for your fast and detailed answer.
I am aware of the CPU requirements, and I see I forgot to mention in my first post that it works successfully (cursor + hand) with an HP Z440, that runs a Xeon E5 v3 as well. The only difference I see is that on the Dell 5810 the Xeon is a 1607 whereas on the HP it is a 1620. They both run the same windows 10 1607 version.
I am though a little bit worried when you say "it works sometimes with the Xeon". Does the fact that the Dell uses a 1607 and not not a 1620 like the HP can explain why it does not work with the Dell?
Regarding the SDK, indeed I am still using the old 2016 R2 version. However, when I saw it was not working, I uninstalled it to try with the 2016 R3, and it failed as well.
Looking up the capabilities of Xeon processors is always difficult because Intel tends to use the same processor code number for different generations, distinguishing them only with a V (e.g V3 or V4). That's why it's important to know the V number of the chip when evaluating possible compatibility with RealSense.
For example, E5-1607 V4 is Broadwell, whilst E5-1607 V3 is Haswell.
Likewise, E5-1620 V3 is Haswell and E5-1620 V4 is Broadwell.
So your 1607 and 1620, if they are both V3's, are likely the same general processor architecture but have different processing capabilities. And I think the architecture type matters more to the camera than the specific capabilities of a processor. So you should be okay in that regard.
Normally I wouldn't expect Haswell-architecture CPUs to work with the SR300. However, I have come to learn that Xeons are a strange and mysterious universe that do not always comply with one's expectations.
Thanks for your quick reply again!
So the Xeon's world is quite interesting .
I have also read in other discussions on the subject that sometimes there were issues with the power delivered by the USB3. Although I would be surprised to have such issue with this Dell, should it be investigated? I have already tried the camera on all the USB3 ports of the PC.
Otherwise I think the conclusion is that I just have to use a more recent CPU...
Many people have found that using a mains-powered USB 3.0 hub with their PC has been an instant fix for their camera problems. And as they you can get one for about $15, you haven't lost much if you are one of the unlucky few that it doesn't help.
You can search for a hub on sites such as Amazon with the search term 'powered usb 3.0 hub'.
Just to close the discussion, I have been lucky and I found such hub here (Amazon USB3 externally powered) ... and it works!
How can it be that a high-end Dell with a internal power supply of 600 Watts cannot run this camera ... I do not get it.
Anyhow, thanks again for your support and helping me to solve this issue.
I'm glad you had a powered hub laying around. I've been saved countless times myself by my random PC parts and cables bag.
It's not an issue with the power supply so much as the design of the USB ports. You would think that a standardized component like USB should behave the same across all devices, but individual design and choice of USB drivers by the manufacturer conspire to make things ... interesting.
Internal USB expansion cards placed in the PCI Express expansion slot tend to have a set of 5v "molex" pins, onto which you can attach a small power cable from the PSU. Ordinary USB ports can lack this extra juice though, and so whilst the port works fine for low-drain devices such as mice and keyboards, the camera can stall if it goes into a mode such as depth sensing that requires a greater amount of power to be drawn from the USB for the laser.
Sorry for my late answer and thanks for those explanations.
So in fact it worked once with the Amazon Hub ... and then it was not possible to have it working again (I am talking about the depth stream, the video stream always works). I wanted to try out different ways before posting again.
So using the Amazon USB 3 hub does not work anymore.
However, using a PCIe USB3 card (Inateck - 5-Port USB 3.0 PCI-E Card KTU3FR-5O2I, with the internal power connected), and installing the latest sdk and reinstalling the camera driver allows to get the camera and depth (from time to time) streams using the RawStreams.cpp.exe. But the HandsViewer.cpp.exe still does not work (I keep getting the same message, that the camera disconnects right after clicking the "start" button).
I do not know what I can try anymore ... However, Intel contacted me regarding this issue. I will keep you posted!
I found a forum thread dated from 2014 that also had problems with HandsViewer.cpp not working because of disconnection after pressing start. So it's not just you.
In that discussion, some of the commenters found that they got it working if they changed the name of their "PC user folder" to only have English characters in its name, and not characters such as cyrillic, Japanese Kanji symbols, etc. By 'PC user folder', I would guess they mean the folder that the computer user's personal files are stored in.
Other people who commented on the thread later on in 2016 found that it worked if they used a version of the SDK earlier than '2016 R1'. Unfortunately, '2016 R2' is now the newest SDK version available, as older SDKs were withdrawn due to possible security vulnerabilities. If the HandsViewer.cpp sample does indeed date as far back as 2014 then I can well understand why it may malfunction on a modern SDK.
I think the SDK version you are using is more likely to be the cause of your problems than language characters in your user folder name. Maybe you could find a more recent program that uses the hands and see how your camera behaves with it.