HackPerception

@eyetracker - This is also already included in the current SDK's .HTML. The .PDF is only part of the overall documentation, there is also HTML documentation included in each folder. This is located at: Unity: /SRanipal_SDK_1.0.1.0_Eye/Eye/02_Unity/Document/html/struct_vive_s_r_1_1anipal_1_1_eye_1_1_single_eye_data.html Unreal: SRanipal_SDK_1.0.1.0_Eye/Eye/03_Unreal/Document/html/struct_vive_s_r_1_1anipal_1_1_eye_1_1_single_eye_data.html

@Scottyg A colleague tipped on onto the fact that you can tell which ports are wired to which GPU via the Nvidia PhysX panel. I've copied a screenshot of what this looks like on my Razer - this USB-C port is not directly connected to the dGPU. Doesn't really help unless you have access to the laptop but I wanted to post here in case anybody finds it useful.

@Scottyg - That's very unfortunate to hear. There really is no good way to verify how the ports are wired - OEMs are sensitive about that messaging as not wiring IO ports to the dGPU is primarily a cost cutting measure. Verifying with the OEM is the only real way to take a stab at the question as there's unfortunately a massive number of laptop SKUs on the markets nowadays. That said, we've primarily see this specific issue with USB-C ports; if it has a dedicated MiniDisplayport that's usually a pretty good sign that it's wired to the dGPU. I would also note that your laptop model will also not be compatible with other modern HMDs (Index, Rift S, Pimax, ect) unfortunately.

@Tom17 - I flagged our community manager to look into why you weren't able to edit your posts and I've removed the extra space from the post you're flagging above. Our new forum system has been live for less than a week so we're still seeing a few bugs pop up - sorry they impacted your ability to edit your post.

@Nytra - Sorry for the slow reply, we're doing lots of backend work to support our new forum system and I'm just now catching up. It sounds like you've pretty much ID'ed the issue and have even narrowed it down to which laser is non-functional - one of your rotors isn't spinning or that laser source is not working. The unit will definitely need to be repaired or replaced. The fastest way to start a repair ticket with us is to collect the serial number of of the back of the unit and navigate to www.vive.com/support -> contact us -> contact us. This will start a chat with a live support agent who can process a repair ticket for you. In most regions, the 1.0 stations carry a 1 year warranty but there will be some variation depending on where you're based.

@Scottyg - I just looked at the spec sheet for the supplied model number and it seems like only one of the USB-C ports has the proper Displayport 1.2+ support. Cross referencing between their images and spec sheet, it looks like it's the port on the side of the laptop with the audio jacks. If you try on the other port, it simply isn't wired to support it. To confirm, you're using the club-3D adapter and the supplied Displayport cable that came with Pro? On some laptops - you may have to go into the BIOS and alter settings to ensure it's outputting DP and not trying to output Thunderbolt. See this thread on Razer's for reference.

@RandomGuyPlaysVR - ^ Pretty much what they said. You want them opposite of each other so that you have 360 tracking without blind spots. If using optical sync, you need them pointed towards each other so they can sync to each other. We recommend a diagonal setup because that's the best way to ensure 360 tracking coverage and achieve the maximum tracked volume that 1.0 stations can support.

Hello @Leoson I think they're are two potential layers at play. On the SteamVR layer, you can go into the in-HMD settings and find the power management tab to change the time it takes for SteamVR to send out a power off command. I've copied a screenshot of that menu layer below. That said, there may be a hard inactivity limit on the firmware of the tracker itself. These exist in order to prevent accidental battery depletion. I'm reaching out to additional team members to ask about any potential firmware component. Based off my experience with our MR bay, I believe they'll remain on if you have them plugged into a power source.

@NXT - Seconded, you should be equipped for the vast majority of titles but your CPU is not great for wireless. If you ever hit a performance issue, SteamVR will let you adjust the resolution you're rendering frames to the HMD via SteamVR -> Settings -> Video (for global) as well as SteamVR -> Settings -> Applications (per-application) so if you can't run an app at standard res, you can just down-sample it as a way to try and hit 90fps. Thanks @Wasted Potential!

@StephenLenser - No, Bluetooth is a core element of the Watchman tech stack. The HMD only has two RF radios in the form of two BT transceivers (one for each of the two controllers). We're not aware of any stable way to disable the receivers in software/firmware (especially a way that would pass a security audit) as those systems are tied to the Watchman Module's core systems. You'd likely need to physically remove the antenna's (which probably will kill the HMD) or alter the watchman module's firmware which is super proprietary to Valve. You could attempt to reach out to Valve as well to see what their say is on the matter but I suspect it will be similar.

@elnovio - Yes, the current iteration of the Vive Wireless Adapter requires an available PCI-E slot that can accommodate the desktop 1x PCI-E card/chipset. There really aren't ways to stably modify a PC/laptop that doesn't meet this requirement natively - it's considered to be a desktop only solution. Some community members have adopted m.2 slots to work with the adapter but those solutions are super janky at best and sometimes involve dangling the PCI-E card outside of the PC case which is very risky. The MSI VR One is not compatible with the current wireless solution unfortunately.

Hello Purna, The WaveSDK serves as the engine-side bridge that enables your build to communicate with the Wave run-time/compositor which serves as the VR run-time on Wave enabled devices. Currently, you must implement the WaveSDK as a fundamental requirement to get your content to render on a WaveSDK-enabled device like the Vive Focus, you cannot target the headset directly without the integration of the WaveSDK. The Wave run-time is the only VR run-time currently supported on the Vive Focus. @Tony PH Lin should be able to confirm this and speak to if there is any way to target the device without integration of the WaveSDK; that said, to my knowledge it's currently a hard requirement. Vive Wave SDK

@Rich_BBVR - Which team are you contacting at Vive for support on this? This is definitely an enterprise-use case scenario and not something standard support would be able to effectively support - it would fall to enterprise support at that scale (support.enterprise@htc.com). If you're truly trying to run 20 kits at once that would mean there would be upto 80 Bluetooth transceivers activated in the space (There are 2 per each HMD and 1 in each of the two 2 controllers). You're going to hit BT co-channel interference with that many Bluetooth devices in a room, regardless of what kind of BT devices you're deploying. BT all operates on a narrow slice of ~2.4-2.48Ghz spectrum - every single BT device in your environment is competing to broadcast over each other because the BT spec simply has a narrow RF spectrum upon which all devices are expected to operate. VR controllers are especially high bandwidth and have tight latency requirements. To add to the mix, 2.5Ghz is directly adjacent and any 2.5Ghz WiFi activity in your space will inherently decrease your signal to noise ratio and introduce additional noise in your environment - I'd recommend all commercial installations past a certain scale to disable all 2.5Ghz broadcasts they can control and strictly broadcast 5Ghz for WiFi as it will improve the stability of your bluetooth devices. Other control systems like Oculus and Knuckle controllers fundamentally use the same ~2.4Ghz BT protocol - they'll add to your maximum device count and add to the co-channel interference problem - any device that uses BT will contribute to co-channel interference if it's within range. Overall the max number of BT devices you can support in your space depends on the types of devices your using (their , your RF background (specifically 25Ghz WiFi and other BT devices), and the params and materials involved in the environment itself (which affects things like signal propagation). There isn't a lot of resources on this because few arcades and installations in the world are trying to drive this may devices in a singular space.

@10k - The best way to tell if a basestation is not functioning properly in absence of an error code is to test each station individually in "single channel mode" by ensuring only one station is plugged in at a time and set to channel A. Test this with one station, unplug it, and then test with the other station. You can use the quick calibration option in SteamVR -> Developer -> Quick Calibrate if SteamVR starts nagging you to preform roomsetup.

@Jakey - it entirely depends on which power source your charging from. The battery itself is a QC3.0 enabled battery - if you plug it into a QC3.0 (or 4.0) charger, it will rapidly charge and take 2-3 hours or so depending on depletion level. If you're plugging it into a 1-2A cellphone charger, it may take 3-6+ hours depending on the amperage. The slowest way to charge the device is by your PC's onboard USB ports - those are typically limited by OEMs to only output 0.4A and thus it could take 10+ hours to charge if you try to charge it via your PC's onboard USB.

@Jakey - the primary requirement is that it needs to be Qualcomm QC 3.0+ compatible. If it's not certified QC3.0 (or 4.0) the adapter & the HMD will not work. QC3.0 is more than a set of specifications surrounding voltage and current, it's an embedded technology stack that the wireless adapter is built around. Try only purchasing external batteries from reputable brands - that said, QC3.0 is a certification backed by Qualcomm which will eliminate most of the sketchy and questionable batteries.

@TheVelo - Testing each station individually in channel A mode is by and far the best way to isolate an issue to a specific station, it's what we would have recommended you try. Given the context provided here, my best guess is that the station was damaged during shipment/storage. The original base-station firmware didn't contain the error reporting / self-diagnostic tools required for the basestation to report to SteamVR that it's not functioning correctly, my guess is since it's a new kit that the basestation doesn't have the newer firmware images on it. If it's a new kit, this is definitely covered under warranty. The fastest way to get this fixed is to collect the serial number of of the back of the unit and navigate to www.vive.com/support -> contact us -> contact us to be connected to a real-time chat agent. You'll need to request a base-station RMA; they'll authorize the repair return and send you instructions on where to send it.

@Rekon In the bottom left hand corner of SteamVR settings, you can see a graph that you can use to try and isolate it to the GPU. If the number is above 11.1ms it means your rendering below 90FPS. You can use this to verify it's a frame-rate crash. You can get it to display in the HMD via SteamVR -> Settings -> Developer -> Display GPU Performance Graph in Headset. If you're below 11.1ms, you're running at 90FPS with zero re-projection/interpolation. The lower that number is, the more headroom you have. If you're getting into the 20's on a basic app, it's time for a HW upgrade. Generally speaking, VR doesn't use much RAM as the games are not drawing gigs of assets into RAM - most VR apps are under 4gb. Hope your GPU gives you the extra horsepower you're seeking!

@Rekon - Does it look like the screenshot below? If so, this is called the compositor fallback environment (aka "fade to grid"). SteamVR displays this when your render drops below 45FPS. It's there to keep you from getting motion sick If you're seeing it, it's usually telling you that your maxing one of your system resources (usually GPU).You can disable it via SteamVR -> Settings -> Developer -> Do not fade to grid when app hangs. Just note, you're opening yourself to some major stuttering by doing so. It can also indicate that the developer is not loading the scene into memory correctly but given that it's Pavlov I don't think that'd be the case.

@Louie99999 - I can't tell much of anything from that screenshot - it looks like a thru-lens photo? Please go into SteamVR -> Display VR View to activate the mirror and then take a screenshot from that via Window's Snipping tool or using "Window Key + Print Screen"

@Louie99999 Can you please provide a screenshot from your mirror so we can see what you're seeing?

- another thing would be to clean install a previous Nvdia driver (usually aim for a few versions behind the current). You can use this page to access the driver archive. When running the installer, use the advanced setup and opt for a clean install - this is an important step. The types of cases where "it used to work fine then suddenly stopped" are super tricky to pinpoint because it usually indicates a software problem and your PC is a rather dynamic environment. Based on your description, the GPU driver or the OS are what I immediately suspect followed by SteamVR which is also a tricky to troubleshoot in and of itself.

, I'd actually like to pop in a quick personal recommendation for Sager laptops. I don't have first hand experience with the newer models but I have lots of experience with running AV for large scale concerts and events with this brand. Sager is a a trusted brand in the VJ and lighting world and there's a pretty good chance you've seen concert visuals mixed off a Sager laptop. I was looking at their laptop lines earlier and their 20xx series is surprisingly cheap given their reputation. Something like this seems like it exceeds all of the reqs for VR/Vive Pro and has fantastic specs for the price point.

- Grey screen = Loss of tracking. As a first step in troubleshooting tracking issues, I always recommend going into SteamVR and generating a system report via SteamVR -> Generate system report. Save it as a .txt then search the document (usually ctrl-F) for the following term: back-facing. This is how you can tell if the base stations lasers are reflecting around your environment. A reflection looks like this within SteamVR. If you see it, you have something in your room that's adding uncertainty to the solve. Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4E33F709 H: Dropped 312432 back-facing hits, 2069 non-clustered hits during the previous tracking session

- What's your CPU usage when using wireless?