HackPerception

@iMMERGENCE - Our enterprise team has seen this post and will contact you directly to dig into this

@A-Jey They're super popular in the photography world where they've been regarded as one of the highest quality brands available for over a decade. The quick charger they're bundling with nowadays (Panasonic BQ-CC55) is also best in class for it's price point.

@jawlingomes - There is no specific SKU for developers - any Vive headset can be used for development and playback.

@A-Jey - We use Eneloops internally, they're a very reliable and trusted battery.

@vierrr Depends on your development environment and what your end-use case is. I would recommend looking at this Unity blog post which covers how to target OpenVR to accomplish this at runtime within the Unity editor - it refers back to the OpenVR API that you need to target. You could theoretically create a custom Overlay to facilitate the trigger if you wanted to - all depends on your end-use case. I'd also note that there are several different pass through modes not covered within that Unity blog post.

@SonilGomes - Extensions are super hit and miss so we don't offer official advice as we wouldn't want to recommend that you go and spend $$$ something only to not have it work. There is a fairly comprehensive community-sourced list of cables here - this is the best resource there is for this kind of stuff. As you can see, some passive cables do work but mostly for shorter distances. Note that Pro/Cosmos (or any other DP1.2+ HMD) don't lend themselves to extensions due to the specifications and limitations of the Displayport standard.

@Annabell What's your development environment (Unity/Unreal)? On the OpenVR SDK side - you can query the pose via the tracking functions within IVRSystem: https://github.com/ValveSoftware/openvr/wiki/IVRSystem_Overview

@Brin Valve pushed a hotfix this morning to address this behavior via SteamVR 1.8.20 - release notes here.

@Brin - I'd recommend posting in SteamVR's bug reports forums - as this is a SteamVR function, only Valve can modify the behavior and the more people who report it to Valve, the higher priority it will be on their list. I can't say anything definitive about the update from Vive's prospective but in my personal usage in the last 24 hours I can say that I've triggered it by rapid movement while playing Pistol Whip - you're not going crazy, it's likely something just a feature addition that needs to be tuned further and direct feedback helps that process.

Adding in that creating a VR controller is 10/10 difficult and very $$$ if you're trying to enter production.

@Yann Leurent - It's super doable but it depends entirely off which base-technology you're selecting. If using SteamVR tracking (basestation tracking) - you'd need to purchase a SteamVR HDK from Triad Semiconductor - it looks like they're in between generations of kit right now: https://www.triadsemi.com/product/ts4112/. The type of tracking you're using will determine everything - it really depends on what your use case is which will determine your constraints. One of the hardest parts is getting your controller tracking to work with your HMD tracking. Overall, I'd recommend going with a SteamVR based solution as the technology is royalty free and there is a decent amount of activity around the HDK.

@joellipenta & anybody else who may be getting one soon - please remember that international & carrier regulations prevent us from shipping fully charged batteries so you'll want to get the battery plugged in and charging while you install the PCI-e card. It will charge fastest via a QC3.0 charger.

@schwaBAM - It sounds like you're hitting a limitation of SteamVR 1.0 tracking. SteamVR 1.0 tracking relies on "optical sync" - the basestations emit a bright "flash" in IR that tells the sensors on the HMD and controllers to reset their clocks to t = 0 which is followed by a "sweep" from a laser directly afterwards. The hardware and SteamVR are able to measure the time between when a flash is seen to when a laser sweep is seen which can then be used to mathematically solve for the position of the device relative to the stations. Here's a video that describes the system in detail if you're curious. The end result is that: You can't have more than 1 pair (2 units) of 1.0 basestations in the same room from each other unless they're physically partitioned away from each other by a material opaque to near-IR. The range of the IR flash is ~30+ feet (10+M) so you can only get away with not physically separating the tracked volumes if you're room is rather massive and the playspaces are far apart from each other. You can't have 1.0 and 2.0 stations operating simultaneously within line of sight of each other (in most deployment scenarios). Devices like Pro and Index can accept data from both 1.0 and 2.0 stations - as soon as it sees an IR sync "flash" it will anticipate BS 1.0 tracking data accordingly. It's super weird that's it's only affecting your controllers - the sensors in the controllers should be the same as in the HMD (discrete sensors) if they're the first gen controllers. Not sure what's up with that. That's more consistent with a reflection problem - you can ID reflection issues by generating a SteamVR system log, opening it up in a text-editor or in SteamVR's system report viewer, and searching (ctrl-F) for the term: "back-facing". Here's what a reflection looks like in logs: Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4E8EF209 H: Dropped 32312 back-facing hits, 2069 non-clustered hits during the previous tracking session The easiest solution would be to only use 1 set of 1.0 stations when using both devices at the same time - you'd have to squeeze the play volume for both HMD's into the supported range of a pair of 1.0 stations. The OG Vive can't accept signals from a 2.0 station so the 1.0 tracking is the limiting factor in this scenario.

@flobie Based on your description, my educated guess would be that the station is entering standby mode. You can try going into SteamVR -> Bluetooth -> and Power Management; disabling that feature, and seeing it it keeps the stations on. What channels are your stations in? When you switched over to using a sync cable, did you also switch to using channels A & B? The station that's in channel A mode is always going to be more aggressive about not going into standby - you can try ensuring that the station you're having problems with the is A station which may help.

Here are a few points of clarification: There are two SKU's relating to Wireless & Cosmos The Vive Wireless for Cosmos Kit: Contains everything you need including the PCi-E card, wireless linkbox, 21v battery bank, padding, and cabling. The Vive Wireless for Cosmos Attach Kit - This is an upgrade kit for existing wireless adapter owners which has the 21v battery bank as well as padding/cabling. The adapter package/attach kit is currently only fully approved for sale in some regions - most notably the EU. As sales are approved in new regions, they'll be added to vive.com. We can check in on Amazon availability. The Cosmos requires a 21v OC3.0 power bank - the battery that shipped with the original wireless adapter kit (for OG Vive/ Vive Pro) can only supply 17v and is thus incompatible with Cosmos. Attach kit for Cosmos Contents: headset cable, head pad cushion, velcro, cradle, and 21v battery bank Vive Wireless Adapter for Cosmos Contents: PCI-E card, wireless linkbox, wireless adapter, headset cable, head pad cushion, velcro, cradle, and 21v battery bank.

@mmorselli Are you referring to the Role Change tool we used to make available on this forum? If so, that's the only real way to fully get SteamVR to think a tracker is a controller - that tool modifies the watchman firmware on the device to change what device type it reports back to SteamVR.

@AGK - We do not release optical specifications for the lenses used within any of our HMDs. The screen to eye distance is not a fixed value is is highly variable depending on the following factors: Which eye relief setting the user determines via the HMD's ergonomic adjustments The user's facial morphology and the way their eyes are set into their eye sockets What type of facial interface the user is using (specifically if they're using a 3rd party foam replacement) There isn't a simple answer here - it will vary for each individual user overall and then there are several other factors which can impact that number.

@Juhle - This is a bit of confusing post - are you talking about the official Vive Wireless Adapter? If so, the chat support agent is correct. The wireless adapter is not WiFi - it's a very different technology that's in a completely different spectrum far away from the 2.4/5Ghz of WiFi. The wireless adapter is a very high-bandwidth and performance heavy solution - it has to shuttle around gigabites of data per second using signaling that's optimized for 60Ghz which has very specific limitations. There is no reliable way to extend the wireless linkbox's antenna beyond the length that's provided in the box. Extensions are officially unsupported due to the engineering hurdles that exist with 60Ghz. The Reddit community has reported that this cable can be used to extend the adapter ~2M - but it's simply not a 100% reliable solution and depending on the specific factors in your setup can result in alot of additional troubleshooting. Other community members have tried implementing PCI-E extenders but similarly, none of those solutions will be reliable or clean enough to actually recommend and any modification that you use to achieve a solution will be unable to hit parity with the adapter's designed use-case.

@Superman III - Adding in that you can always see the full image that's being rendered to the HMD regardless of what the application window is rendering by opening SteamVR -> DisplayVR view. The VR View mirror shows all layers of the VR render including the chaperone boundaries.

@A-Jey, You are correct - Viveport does not currently support cloud-save. Our SDK team is exploring how to architect the platform SDK and backend to support cloudsave features in the future but it will take some time for the core SDK to mature further.

@The Silent Jaguar - While it's not always required when swapping out a CPU, a clean installation of Windows is generally recommended if you end up hitting any unexplained stability issues after an upgrade. Similarly, when upgrading a GPU, it helps to enter the advanced installation settings on the Nvidia driver installer and checking the box to preform a "clean" installation which wipes out old configurations and settings allowing for a clean start. My mind immediately goes to the Windows install itself as the first potential cause. Have you tried any other stressful applications on your PC like traditional 2D gaming? If there were issues with the GPU itself, other demanding games should be affected. As far as Nvidia is concerned, the recommended power requirement for the GTX2080. Depending on your config you could be hitting your PSU's ceiling. @Synthesis

@VizionVR - SteamVR tracking is a proprietary Valve technology (alongside the SteamVR compositor and the SteamVR/OpenVR SDK) which means that Valve controls the overall hardware and software tech-stack and it's implementation. Valve hasn't really released any confirmed information about how 2.0 tracking works beyond the basics for in-home setup. At a high level, it would appear the current behavior is that it pulls data from the first 4 stations it sees but overall, the system is dynamic and those dynamic elements have not been documented publicly. We recommend training room setup with only the desired stations powered on to generate a clean lighthousedb file and essentially try to get the system to know which stations are essentially primary stations which are the desired ones for that specific tracking universe. Past a certain point, Valve is the only entity who can truly speak to the function and behavior of their algorithms. One of our engineers has created an open source tool for arcades that attempts to "lock" configurations. It specifically has a feature to prevent SteamVR from making changes to the lighthousedb file which may be useful in your case. You can access it here. Doing roomsetup with the desired stations and then applying this tool may help. I can see the behavior your describing in the logs - it looks like a bunch of this: Tue Oct 22 2019 15:09:58.061 - lighthouse: ... SOB: add S-8 also seeing S-9 S-11 S-13 Tue Oct 22 2019 15:09:58.208 - lighthouse: ... SOB: add S-12 also seeing S-3 S-4 S-10 Tue Oct 22 2019 15:09:58.477 - lighthouse: ... SOB: add S-3 also seeing S-8 S-9 S-11 S-13 Tue Oct 22 2019 15:09:59.047 - lighthouse: ... SOB: drop S-11 seeing S-4 S-8 Tue Oct 22 2019 15:09:59.277 - lighthouse: ... SOB: drop S-11 seeing S-3 S-8 S-9 S-13 Tue Oct 22 2019 15:09:59.326 - lighthouse: ... SOB: add S-13 also seeing S-4 S-8 Tue Oct 22 2019 15:09:59.885 - lighthouse: ... SOB: drop S-4 seeing S-3 S-10 S-12 Outside of the software/compositor side stuff, I would note that putting 2.0 stations in corners cannibalizes their horizontal FOV. They have a 150x110 degree FOV with the long axis being the horizontal axis (hence the curved front). When you mount in a right angle corner, you effectively reduce that 150 degree horizontal FOV to 90 degrees and can cause bounceback issues (although I'm not seeing bounceback in your file). Mounting them in locations that maximize the 150 degree horizontal FOV and are within 5.5m of each other will help you reduce your overall station count and maximize each stations coverage potential.

@VizionVR - A couple of notes: Bluetooth power management must be disabled on each and every single SteamVR instance. You can ensure it's disabled via SteamVR -> Settings -> Bluetooth as well as SteamVR -> Settings -> Developer -> Disable Power Management. If you do not disable this on each and every station, an idle command can be sent out from one SteamVR instance that can affect multiple stations used for tracking by another HMD/session. Based on your description, this is my primary suspect. Currently, a SteamVR instance can only accept signals from a maximum of 4 stations during a tracked session. You cannot track an HMD using more than 4 stations currently. SteamVR doesn't have the most robust UX/UI for multistation setups beyond the basic channel configuration tool and they haven't released any documentation on the topic. Here are some tips that can be used: When setting up advanced spaces like this, we'd generally recommend that you run roomsetup for each station with only the stations that will be used for that tracking session plugged in. For instance, if you plan to have an HMD tracked by 4 specific stations, ensure that those are the only ones that are plugged in when you run roomsetup and ensure all others in the space are unplugged. The basestation channel manager has an icon that denotes a station is "observed in a tracking session". This icon generally means that a roomsetup has been run with those stations used as the primary tracking stations. Use this to validate that roomsetup is being trained to the correct stations. "Reflective surfaces" in practice are extraordinarily hard to track down without specialized equipment because materials interact differently with IR light than optical light. A material may not be reflective in the visible spectrum but may be highly reflective in the IR spectrum; the same is true with opacity, some visibly opaque materials will be complete transparent in IR and vice versa. To detect reflections, generate a system report or open up the SteamVR web console and search for the term "back-facing". I'll post an example of what a reflection looks like in the logs below. Sun Jun 26 2016 23:02:09.676 - lighthouse: LHR-4E8EF209 H: Dropped 32312 back-facing hits, 2069 non-clustered hits during the previous tracking session I'll shoot you an email with some more information but I'd also generally recommend contacting support.enterprise@htc.com as this is an advanced use case.

@The_Donkey, See our offical blog post on tracking updates here: https://blog.vive.com/us/2019/10/18/vive-cosmos-release-notes/ There should be another beta channel release before the end of October.

@Doodle - Most likely the limitations would be cabling and heat dissipation/shielding followed by occlusion. The wireless adapter has unique output parameters - basically the output/signal is optimized for the short cable. You won't be able to use the stock ~5m long tether that ships with the HMD, you can only use the short cable with the wireless adapter. The kit ships with additional foam to help shield your skin from heat - any other mounting solution would need to have some sort of shielding. When mounted to your head, you have the least potential for occlusion - if it's mounted to one side of your body, you can fully occlude and block the signal from the PC side transceiver. The head-mounted design ensures 360 coverage.