HackPerception

Copying my reply to @Zephroth from another thread. @Adsim93 Base-stations are high precision mechanical devices - they often fail because the unit will have a part fail or the motors will be unable to satisfy the tight timing requirements of SteamVR's tracking system. A 1.0 base-station has two motors, each operating at 3600RPM which equates to ~216,000 revolutions per hour - per motor, all of which needs to happen within very tight timing constraints. As you can imagine, over a year or two these accumulate tens to potentially hundreds of millions of revolutions. Any base-station regardless of who manufacturers it is prone to wear and tear - it's a byproduct of the system being fully dependent on high-speed mechanics. It's why you see it on 1.0 stations manufactured by HTC as well as 2.0 stations manufactured by Valve. Valve has tried to reduce the overall complexity by removing one of the motors in the 2.0 stations but it's still mechanical. Until there are solid state base-stations, this is the trade-off for the increased tracking resolution provided by light-house. I'd recommend watching this presentation by one of the key inventors of base-station tracking to get a feel for how complex the system is and why these failures can occur: https://www.youtube.com/watch?v=75ZytcYANTA

@Zephroth Base-stations are high precision mechanical devices - they often fail because the unit will either have a part fail or the motors will be unable to satisfy the tight timing requirements of SteamVR's tracking system. A 1.0 base-station has two motors, each operating at 3600RPM which equates to ~216,000 revolutions per hour - per motor, all of which needs to happen within very tight timing constraints. As you can imagine, over a year or two these accumulate tens to hundreds of millions of revolutions. Any base-station regardless of who manufacturers it is prone to wear and tear - it's a byproduct of the system being fully dependent on high-speed mechanics. It's why you see it on 1.0 stations manufactured by HTC as well as 2.0 stations manufactured by Valve. Valve has tried to reduce the overall complexity by removing one of the motors in the 2.0 stations but it's still mechanical. Until there are solid state base-stations, this is the trade-off for the increased tracking resolution provided by light-house. I'd recommend watching this presentation by one of the key inventors of base-station tracking to get a feel for how complex the system is and why these failures can occur: https://www.youtube.com/watch?v=75ZytcYANTA

@Gary Schilling This is very confusing. Only the It sounds like you're talking about the HMD tether coming unplugged from the headset. For that, you remove the foam facial interface, gently remove the compartment cover by pulling it away from the HMD, and then you can remove and reseat the cable. The cable is oriented so that the circle should be facing upwards:

@msgbubba - I'm honestly extremely confused by your report - this is highly abnormal and I'm not following part of your report. Here are my current thoughts: Perhaps Steam's cloud-save features are carrying over a previous configuration? If it's a SteamVR software issue, this may be why it's surviving the clean install. You could try disabling cloud features for SteamVR via it's properties menu to prevent any API-dependent features. I'm extremely confused by this statement: " i cant even tell if its clicked cause its in night mode and too dark to tell" These features are all accessible via SteamVR -> Settings on your primary monitor. Don't access these via SteamVR but rather just access them via your keyboard, mouse and primary monitor. Both dark mode and enable VR dashboard are desktop UI features, not VR UI features. How are you unable to tell if these options are are aren't selected if you can't access the dashboard in HMD? Night mode? You can verify the controllers are receiving the button input via SteamVR -> Devices -> Controller Configuration -> Test controller. Please run this test and verify each of the two buttons are physically working. The odds of both of them being broke are extremely slim - this is the best way to confirm their functionality. @Synthesis

@Alex The Parallel - I tried posting to this thread yesterday but it doesn't look my post committed to the sever. I've flagged this post and your experience with the Vive X team and the Vive.com team and will follow up internally with the stakeholders to figure out what's going on. I know that ViveX@htc.com is working and monitored actively.

Can you generate a SteamVR system report via SteamVR -> Create System Report, save it as a .txt and PM it to me? I can take a look to see if anything stands out in the log. In the mean time, I would recommend testing each station individually by first unplugging one station, setting the remaining station into single channel mode by flipping it to channel A, testing the tracking, unplugging it, then repeating the process with the other station. That should let you test to see if both stations are outputting valid tracking data.

@Ramalam, I don't have hands on experience with Qualisys systems but everything I said in the linked thread would still apply here. It's not the operational frequency of the systems - it's that the Qualisys would be putting out high intensity IR signal which SteamVR sensors will treat as a persistent sync signal. If the cameras are outputting IR light in the exact frequencies that the sensors are sensitive to (Specifically ~800-850nM), that signal will be detected by the sensor and treated as a "IR flash" if the intensity of light is above the sensor's threshold of detection. Usually in these cases where you have a high precision IR tracking system, you would replace SteamVR's tracking system with the motion capture system by placing tracking fiduciaries on the headset and controllers and then integrating the supplier's (Qualisys') SDKs to drive software support. I've seen one case where someone was able to use polarizing filters on the cameras, the headset, and the stations to ensure the SteamVR tracking system's IR light was isolated from the tracking system's light but it's a janky solution at best - the controllers each have 24 sensors a piece for example and since they're moving around in 6DoF, as they rotate, the plane of light that's allowed to pass through the filter will shift. Vive is not camera based. Please watch the entirety of this video to get a better understanding of how SteamVR tracking works so you'll understand what I mean by "IR Flash" and what effect the cameras have on the system. You cannot modulate the frequency of the base-stations (which are 60hz a piece (3600RPM), 120 hz interleaved) and modulating the frequency wouldn't actually matter because it's the intensity and wavelength of the IR light, not the speed of the emission that's causing the interference.

@WorshipCookies - I can confirm that the Pro Eye is compatible with the wireless adapter. The Eye tracking data on that HMD is transferred back via USB protocols & the wireless adapter has full USB support.

@HappyCerberus - You're not really able to extend Displayport driven HMD's further than their specified tether lengths because Displayport 1.x protocols are only meant for short distances (primarily to connect UHD playback devices to TVs) - modern HMD's push the Displayport protocol to their limits. We know of a handful of higher quality cables that will net you 5 extra meters but anything over 5M is not really feasible with Displayport in the same way you could extend HDMI. Optical will only go so far - the only headset with native optical currently is the Varjo and even then it runs a 10M cable and it's heavily dependent on foveated rendering because the entire uncompressed signal would be too high bandwidth.

@SunGear I've responded to you via PM. Please check your inbox.

It looks like the attachment this post is referencing didn't survive our recent forum migration. I've pinged members of the Focus team to this thread to get it re-uploaded into the new forum system. @Cotta @Tony PH Lin

@boxjellyfish - I've flagged someone from our hardware support team to contact you. Which email address or form are you attempting to use? Vive hardware support for consumers has historically been entirely live-chat based (unless you're going through very specific channels that aren't publicly shared). In most cases, vive.com/support -> contact us -> contact us is the way to get ahold of a live chat agent. That said, we're currently implementing new support tools which will change that scenario up. @Synthesis

@bertieb - You'd need to integrate the SteamVR/OpenVR SDK and query the head-pose via OpenVR's APIs. If you're building the app from scratch, you'd specifically need to integrate OpenVR's C++ native libs into your project file. You're not finding these on our site because that layer of the tech stack, specifically SteamVR/OpenVR is owned and managed wholly by Valve. https://github.com/ValveSoftware/openvr https://github.com/ValveSoftware/openvr/wiki/API-Documentation https://skarredghost.com/2018/03/15/introduction-to-openvr-101-series-what-is-openvr-and-how-to-get-started-with-its-apis/

@juanyvos Can you please specify what Unity tool, SDK, or feature you're trying to enable foveation in? There's a number of ways to approach it nativley for Unity. I'm mostly a desktop developer but I believe that you need to enable foveation within the WaveSDK and not at the engine level as the Focus is not natively supported within Unity. This is the documentation for how to enable it via the WaveSDK. I've tagged members of the Focus/WaveSDK team to this thread to confirm my response.

@armin777 It's sorta complex because we license the core tracking technologies in Vive/Vive Pro from Steam who are the technology owners of SteamVR and SteamTracking. In short, Pro's commercial license would definitely cover your use case - the trick is getting the data out of SteamVR in a coherent and appropriate data set as the raw data itself is proprietary. In most cases, I've recommended Brekel OpenVR media recorder because it can output OBJ but it may not be high enough precision for your needs. Past a certain point, you need to be a SteamVR hardware licensee for lower level access. The best public resource on how base-station tracking works is this presentation by Alan Yates, one of the principal inventors of the technology. Otherwise, alot of the more advanced resources on 2.0 tracking Here are some other helpful resources: The Accuracy and Precision of Position and Orientation Tracking in the HTC Vive Virtual Reality System for Scientific Research Analysis and Accuracy Improvement - NASA CNLohr - This dev tried to reverse engineer SteamVR's tracking. SteamVR Hardware Advanced VR Rendering Advanced VR Rendering Performance

@SunGear - I've relayed this question to our hardware R&D team to see if I can get an official number. Generally speaking, MB driven USB ports fall around 0.4a but the headset has an external power source so that may be different.

@Yakko - The IPD range on the Pro is ~61.4mm - 70.8mm. This is a result of the screens used in Pro - they're a slightly larger from factor than the panels on the OG Vive and thus the lenses are not able to get quite as close together.

@bababread - I don't have firsthand experience with VRED - where and how are you targeting OpenVR via Python??? Unless you have direct access to binary's source code which enables the OpenVR integration or you have direct access to the Unity/Unreal project, trying to alter functionality via custom middle wear is going to be messy at best. The best thing to do in a situation where you don't have direct access to the source code or project files is to use SteamVR's input binding tool to customize the per-application bindings. That said, I'm honestly not sure how VRED is rending into the HMD via OpenVR - usually though, you can still rebind any .exe as long as SteamVR can see it. First you'd want to start VRED, and ensure it's running and that the controllers are both connected. Next, you'd go to SteamVR -> Devices -> Controller Settings. This will bring up the controller binding menu. You should see something like VRED.exe show up on the resulting page under "edit controller bindings". If you click it, it will tell you that it's using the default Vive controller bindings. Hit "create new binding" - configure your custom bindings, and then hit "save personal binding", give it a name, and ensure it's the active binding. In your case, you want to ensure mirrored mode is turned off so left and right controllers both have unique bindings. Bear in mind, that the input must correspond to an existing input that the developer has hard-coded within their build - a binding won't do anything unless the build is coded to support an action for the given binding - this menu effectively lets you map how those virtual bindings correspond to the physical controllers. I just tested this with a custom app which I'm 100% certain isn't on Steam and it worked fine. Steam never did detailed documentation for rebinding - this is the extent of their docu: Rebinding "Legacy" games for new controllers

@Havrefluff - I've responded to your thread and have generated a support ticket for you. You can also email customerservice@viveport.com for assistance with Viveport topics. Please avoid necro'ing old and unrelated posts - this thread is nearly 2 years old and is for a completely unrelated topic. Locking.

@gregdowning - Generation 1 devices are not compatible with 2.0 stations because 2.0 stations do not have the IR Sync LED array required for 1.0's basic functionality. For a device to work with 2.0 stations, it specifically needs to have TS4231 sensors. For Vive Products, that currently translates to Vive Pro, Vive Pro's controllers, and Tracker 2018; the sensors on Vive devices pre-date the TS4231.. You'll unfortunately need to have 2.0 enabled controllers (either Pro's controllers or Knuckles) to use them with the 2.0 stations or alternatively you can use your 2.0 enabled devices with 1.0 base-stations because the TS4231's are backwards compatible. I'd refer to this presentation by Alan Yates if you need a more in depth explanation of how 1.0 tracking works and how 2.0 tracking achieves sync on beam.

@Jakey The only company that makes aftermarket replacements for the back pad is VR cover - you can order them here. Internally, we wipe the HMD's down after each usage pretty religiously. Here are the rest of VRCover's products for Pro.

@PixiStudio What version is your firmware on the device? H.265 support was added with the 1.69.xx firmware update - it's not possible to decode that format on earlier versions of the OS/firmware.

@perha This sounds like it's likely a Windows policy or configuration issue on your workstations. SteamVR in the vast majority of deployment scenarios (i.e. every installation I've ever had firsthand experience with) will actually prevent the computer from locking when an active SteamVR session is rendering by default. Most users actually have the exact opposite problem wherein an idle SteamVR Window prevents windows from automatically locking the PC (when inactive) which creates a security vulnerability by preventing the PC from auto-locking. We actually have to commonly instruct enterprise users on how to configure SteamVR to shut down after an idle period to re-enable the computer from automatically locking (via SteamVR's power management settings panel). I'm honestly not sure what's occurring on your workstations, I've never heard of this specific problem as we're usually dealing with the compositor preventing the PC from locking which makes me believe it's related to your Windows policies or power management settings. It may also be related to your GPU driver and settings. With all of that said, SteamVR had a longstanding feature to enable the HMD to keep rendering when the headset is locked as this is a key requirement for developers and those who work in secured environments. You can enable locked rendering via SteamVR -> Settings -> Enable headset when computer is locked. That won't help you however if your Windows policies are forcing the computer to log out rather than simply lock the session. You should likely be locking your desktop when the HMD is in use if you're in a secured environment in any case. You may need to ask your sysadmin to adjust your policies on the machines in question to lock the PC rather than fully log-out due to inactivity.

@Niv Fisher - Valve has not publicly announced plans to add support for more than 4 stations per SteamVR instance - it is not currently on any public facing roadmaps. Currently, Valve's official stance (and thus our official stance) is that you can currently support upto 4 stations per a single SteamVR instance. They've hinted that it's something they're experimenting with in a few posts and comments but have never actually come out and said it's a targeted roadmap feature. If Valve were to add this to their release timeline, news of such would come initially from Valve rather than HTC as they manage the SteamVR hardware tech stack. You can try reaching out to Valve through your deverel channels there but they're usually pretty secretive.

@dombvn - I've pinged Jason via email about your post - it attachment was likely lost during the migration to our new forum platform. @Cory_HTC