HackPerception

@jon.graham - Yeah, this is v confusing and tripped me up. Some people are seeing a default binding of CTRL + Tab, others don't have a defaulted value and need to assign one. It's an FS2020 sim thing that happens with every type of compatible headset - it's not specific to any single headset and is specific to flight sim. You may also find that you need to have SteamVR closed before attempting to start SteamVR from within FS2020.

@cusa123 - Unfortunately I can speak to specifics but in short, we had a plan and that plan unfortunately can't currently work at scale across a wide range of hardware from various manufacturers for a variety of reasons outside of our influence and control. The USB-C port can be used as a generic USB port and people commonly use that onboard port for headphones, microphones, camera mods, and other types of mods.

@kennyyek @andreas.braig, The problem both of you are facing is that the linkbox contains a special bluetooth radio that can work with Valve's proprietary "watchman" protocol. SteamVR isn't using a standard bluetooth protocol, it's using a special protocol that has a proprietary >90% compression protocol which is required to hit the high refresh frequency required for VR. You can update the device's firmware via micro-USB. When doing so, ensure that you plug the station in via USB, and then supply it power - to minimize movement of the station while it's spinning which can cause damage. When unplugging it, unplug the power first and let the station come to a stop before moving it around and unplugging the USB. You would also want to update the tracker's firmware as well. Basestation channel management's UI is entirely handled over bluetooth because Valve designed SteamVR systems to function as full "kits" with HMD, controllers, etc...There is a manual "pinhole" on the back of the unit you can trigger with a paperclip. Per my warning above about movement, you carefully plug in the device and then use the pinhole to cycle the channel while the station is on being careful not to jostle it too violently. The stations ship defaulted to channel 1. Each press of the pinhole will index the channel +1. There are 16 channels, on the 16th press of the button you'll cycle from S16 -> S1 and start the index cycle over again. If you hover over the basestation icon when there's a connected SteamVR device receiving data, it will show which channel that station is broadcasting but it does take a little while to update when you're manually changing channels. As long as you're using stations in a room by themselves it doesn't matter at all what channels you assign them just as long as no two stations are on the same channel in the same room. @andreas.braig

@errolt I'm not sure of what the situation in SA is before. I've never heard of this situation - it's sold as a kit and I'm not aware of any situation where we did not provide the battery but I'm used based and things can get very country specific. Sometimes we can't ship batteries across borders and other weird situations so it may be related to that. Electronics in South Africa is especially complex due to their import laws. Did you check with care to ensure this was the case and that you didn't just get a kit without the battery for some factory reason? You can use most QC3.0 enabled battery banks. It needs to specifically be Qualcomm 3.0 enabled otherwise it won't work. Anker and Ravpower make compatible batteries and are some of the most trustworthy brands. Avoid no-name batteries as they may damage your headset and adapter. Aim for 10000mAH. Larger ones will net you more playtime but be bulkier. If you're using Vive/Vive Pro - it needs to be able to output 18w which most QC3.0 batteries can handle. If you're using Cosmos - it needs to output a higher 21w otherwise it won't work.

@ttvbcbudsz You can have multiple headsets using data from a single pair of basestations. Each PC needs it's own If you're using 1.0 basestations - you cannot have more than 2 in a single room. You cannot have 1.0 and 2.0 basestations in the same room together. The original vive cannot work off 2.0 basestations. If you swap to 2.0 stations - your original vive will be invisible to their signals. The Index and Vive can both work off 1.0 basestations.

@alexander @russ_c Sorry, per the message that hangs out at the top of this forum most general hardware support is handled via www.vive.com/support -> contact us -> contact us I suspect both of you have faulty USB dongles - I would recommend requesting replacements from the live chat agent. If you hit any snags - post again here and I can try to

@TomCgcmfc - Screen door effect is a fixed physical value that primarily is determined by the display and the distance and layout of the different pixel and sub pixel elements on the display. It's a little more complex these days because some manufacturers add diffusers and other technologies. It's physically fixed value and switching between wireless and wired can't physically alter it. (Using a lense mod can technically alter your perception of the SDE because you're altering the entire optical chain). What you're seeing is probably a combination of two things: 1) Compression. Depending on what your CPU is and what your 60ghz wireless environment and receiver situation is - you may be seeing compression artifacts as the product tries to dynamically adjust to hit minimum data rate on the HMD. 2) Aliasing & jaggies. You may be seeing aliasing which is related to compression, or it could be related to your source app rendering at a lower resolution due to the higher hardware demands of wireless which is leading to more overall aliasing since there is less sample resolution for AA to try and smooth out. If your signal is being compressed due to not having enough CPU headroom, you'll probably see aliasing as part of the overall compression behavior. The standard example of testing for aliasing jaggies is to look at power lines in video games because the geometry is only a few pixels thick.

@MrWhitty2000 Make sure you have the Cosmos plugged in and then Open the Vive Console's menu tab and navigate to Settings. And then hit "report issue" and follow the on-screen prompts

@RjMelter - The Vive/Vive Pro are SteamVR tracked devices which mean they have Valve-designed integrated circuits and boards inside of them (known as the Watchman system). As such, all of that hardware's firmware updates is mediated by SteamVR's update system which is entirely controlled/managed/maintained by Valve. In these types of situations, all we can really do is funnel customer feedback towards Valve and ask for bugfixes. That said, there has been some evidence in the past that this can sometimes be related to various OEM's USB-controllers which dramatically increases the scope since there is a huge variety of OEM-specific USB-controllers. Vive Cosmos for instance, is built in-house and so the updates all happen within our software manager which is something we can directly apply bugfixes towards. It's probably safe to ignore the update prompt if the firmware version is remaining static. You can verify the firmware version on the headset is not updating between update cycles via C:\Program Files (x86)\Steam\steamapps\common\SteamVR\tools\lighthouse\bin\win32\lighthouse_console.exe. If it's a weird SteamVR related bug, that number will remain static even if the updater executes an update. (this is a shot for Vive Pro Eye but I believe the number is the same for standard Pro)

@Catavr It will technically work but your coverage will be around 180 degrees and you may hit blind spots if the tracker is facing away from the basestation or your body blocks the line of sight between the two. When using a single basestation, it's best to mount the basestation as overhead as possible so the station has a birds eye view - that will maximize what a single station could track. 2 basestations is obviously going to be alot more stable. When trying to use SteamVR tracked devices with non-steamVR tracked devices, you need to use OpenVR-Spacecalibrator to merge the tracking volumes. It's very janky at times and can break at a moments notice with a SteamVR update. It's definitely a more advanced setup and requires patience. We're unable to provide any support for you in trying to get the trackers working with any headset that's not a native SteamVR tracked device. Per decagear, it's a especially a risk to try and build these modified systems based on hardware nobody in the public has ever seen before until community members get their hands on the gear and verify that you can even use something like the space calibrator with it. Not to mention the other unknows about Decagear overall.

@Chocobo & @Yorker2005 - These types of issues are often PC-Specific which makes it very hard to remotely diagnose/troubleshoot it even with an RMA because you'd need access to the PC itself to rule out the PC. An RMA would result in the headset being tested and possibly returned to you without the actual behavior being fixed because there's a good chance that the problem is PC-side and not an HMD hardware issue. The odds of a microphone failing but still having this specific output aren't crazy high because it'd probably fail completely and not just pitch shift. Rebooting the linkbox is helpful when trying to troubleshoot between different changes because it reboots the DSP chip on the device. In most cases where this has been reported by the community, it usually relates to which audio driver is in use. There are generally two options for audio. 2 - Vive Pro Multimedia Audio - recommended to disable this unless Nvidia option doesn't work Vive Pro Nvidia High Definition Audio - recommended default default device In essence, the first one is USB-only audio. Because it's USB, it has limitations for the bandwidth it has to the use motherboard's USB-controller and drivers and also has to compete for bandwidth against the tracking/sensor data that's being shuttled towards the PC. The Nvidia one has a more robust set of drivers and more bandwidth and will provide higher quality audio in almost every scenario because Nvidia cards use tightly controlled uniform specifications whereas there is a huge amount of variety with motherboard hardware. Per microphone, you may often only see a USB-driver option. That said, you should try going into the advanced settings for the microphone and ensuring that your levels are high and that your "default format" is set to 16bit. There isn't a huge difference between 44k and 48k hertz but there is a huge difference in quality if you have it set to 8bit and it can cause the high pitch thing you're describing. I would also recommend turning off "listen to this device" on the "listen" tab and turning off power management. This being set to 8bit is the only somewhat reproducible way I've seen to induce a pitch shift.

@Xfrawg - You're likely talking about the Logitech Bridge. I'm not sure what the current status of that project is but not a ton of applications added support for their SDK so that's not really a consumer-ready option. There's no text input option for VRChat and you can map pretty much all of the possible controls to the controllers so I'm not sure what the benefit would be.

@qw3tfrlk;jbnaSWEGLIUAwerhg, The unit was likely damaged during shipping. The base-stations are high speed mechanical devices and physical shocks can cause internal damage. If you purchased the base-station through Vive, specifically through a Vive Pro kit - Vive provides your warranty. In order to request an RMA, you'd get the serial number off of the back of the affected unit and contact us via www.vive.com/support -> contact us -> contact us. If it's a new unit, it would definitely still be under warranty. If this is a second-hand unit, the warranty may not be applicable.

@Chris1000000 - Damage to displays are pretty individualized and case-by-case. Without opening the headset up, you can't really tell what the backside of the display looks like and when you have a component with millions of sub elements like a display, it's hard to predict what will happen to the overall display if only a portion is damaged. I've seen screens that hold out and keep working with the damage but I've also seen screens fail so it's a bit of a toss up. You can probably contact vive.com/support -> contact us -> contact us to get a quote on an out of warranty repair within your region. You can reference this thread with the agent for context. The display is one of the most expensive components so there may be some sticker shock though.

@BeaminB - Using that specific controller test UI is definitely the best way to isolate the problem between hardware/software. This definitely sounds like a hardware issue and that controller will need to be repaired/replaced. I would recommend collecting your order number and then contacting www.vive.com/support -> contact us -> contact us and requesting an RMA. It sounds like you're just getting the kit in the mail - if it's a new kit you're purchasing the warranty is definitely applicable in this case. If you're buying secondhand, it gets complicated and may be considered out of warranty.

Hello @intender, What beta are you specifically referring to? We occasionally push updates and betas to the Vive console but we follow a specific schedule which means that you'll see a potential update around once a month or less. SteamVR main and beta branch updates are handled by Valve, not HTC and we have no control over that. Valve only pushes a main branch update once a month usually. Same with Viveport - we try to update that one every two weeks at an absolute max. We have no influence over determining the update rate that individual developers employ - some reliably push multiple updates a month. We only control the Viveport client, and the Vive Console (Vive Cosmos runtime) and we don't push updates all that often. Companies utilize server side managed distribution because it dramatically reduces complexity. If you had a public installer package for each and every single version of your runtime/software, it rapidly becomes unmanageable when you scale across an entire userbase and it creates customer service nightmares. Server managed setups enable version lock where all of the userbase is using a common version. When you maintain a platform or a game, you may add/remove features and supporting older versions becomes extremely complex and expensive and slows your progress dramatically. Using server managed systems also enables a whole host of automation and security features. While it's not perfect, the current system is dramatically better than you'd see with version fractured ecosystems/platforms. Imagine trying to maintain a multiplayer game where your userbase is split across 5 different version numbers - it's a nightmare scenario. The same is true for the platform and the VR runtime itself. Modern gaming overall is not really suited for low bandwidth connections but the industry is pretty committed to the current digital distribution models because they work at scale. The best thing to do in low bandwidth situations is to avoid beta branches, stick to main branch updates, and boot the Steam client in offline mode to prevent the client from checking your software against the server's version and forcing automatic updates. Swapping between beta/non beta software is a PITA even with fast internet and it's better to just stick with what's stable unless you have time to tinker.

@johhnry - There isn't smoothing per say but there's a few things at play under the hood. All VR devices including basestation tracked devices experience something called "judder" in which the pose estimate of the device will shift slightly from frame to frame, even if the device is stationary. This a result of the sensors not being able to update fast enough and accurately enough to firmly anchor the pose IRL. On basestation tracked devices, the judder will depend on your basestation placement and your overall environmental conditions (e.g. shiny surfaces). In order to help reduce judder and to overall increase the device's tracking refresh rate, sensor fusion is employed in order to take IMU data from the controllers to supplement the basestation's fixed cycle rate. The IMUs can update much quicker and can be used from time to time to provide pose estimations for frames in which there isn't enough basestation data to derive an estimate, assuming that you eventually get basestation data in a future frame. This IMU update is a form of smoothing in a sense because it smooths out the pose estimate data and adds resolution but it's buried really deep inside of SteamVR's hardware stack so you can't modify it and the devices would have much greater judder without it. This is happening at hundreds of hertz per seconds - it's microsmoothing not macrosmoothing. So, overall - there isn't a high level of smoothing with SteamVR tracking data but there is some level of IMU-based smoothing using sensor fusion that occurs as a requisite for the system to be somewhat accurate since the IMUs have crazy fast refresh rate. If anything, the judder itself can pose a problem for virtual production and may require smoothing in and of itself. This is a helpful video on how to create a virtual steadycam in UE4 https://onsetfacilities.com/virtual-steadycam-in-unreal-engine-4-24/ This is the most detailed video in the public domain about how basestation tracking works and I highly recommend anybody working professionally with basestations to watch it. It explains some of what I alluded to in much greater detail:

@Fox_Alex - Beyond the blank SteamVR compositor/chaperones (what you get when SteamVR Home is disabled), VR performance is hyper specific to the application. If you're GPU bound, then you either need to go into SteamVR -> Video and reduce the per-application render resolution for your specific app to lower the resolution that the content is rendered within the game engine before being passed to the headset. A 1080 should run most VR apps decently but newer and less optimized games will definitely push and start to exceed that GPU. For instance, Star Wars Squadrons has a 1080 min requirement so we're starting to see some of the 10xx chipsets start to show their age against modern requirements. Your motherboard's specs may play into how much of the GPU you can actually use but it's hard to say without more info.

@Alter Rem - The SteamVR compositor/runtime can get into similar sounding infinite update loops where it reports that an update is required and may even try to preform the update but only pushes the same firmware image. We haven't published a major firmware update for Pro in quite some time - pretty much all of the functionality changes have been occurring at the SteamVR runtime level. You can verify the firmware version on the headset is via C:\Program Files (x86)\Steam\steamapps\common\SteamVR\tools\lighthouse\bin\win32\lighthouse_console.exe. If it's a weird SteamVR related bug, that number will remain static even if the updater executes an update. What numbers do you see here for firmware version and the watchman FPGA date? (this is a shot for Vive Pro Eye but I believe the number is the same for standard Pro)

@Aidan Are you using HDMI or Displayport? You can never use HDMI port with Displayport driven headsets like the Cosmos/Pro and doing so will certainly result in a 108 error. The QUSB_BULK message references a corrupt driver but that driver is specific to Qualcomm devices. @C.T.

@dxrova - These types of SteamVR errors are usually PC-specific issues which makes it very difficult to remotely troubleshoot without physical access to the PC to try and troubleshoot. Some common things that can help are: Preform a clean install of your Nvidia drivers using this guide. In this case, it may be helpful to use this page to find an older version of your driver. Sometimes new drivers jjust mess stuff up for some people. Double check your PC's power management settings and ensure you're on a "high-performance" plan and not an energy saver plan Uninstall/Reinstall SteamVR fully Try switching into the SteamVR beta branch. Your problem has been happening for a while so I don't think this is likely to help. ' Go into your task manager and see what your resource usage is. You could have a virus or a program in the background eating up your resources leaving non for VR. I've seen some cases where only a complete reinstall of Windows fixes this issue. Windows updates can really mess stuff up.

@poljot Can you please share more reproduction steps? We don't control SteamVR updates - Valve engineers and pushes those updates so if there's a problem, we need to investigate and then work with Valve for a fix. @C.T.

@Chris1000000 - It's definitely physical damage to the LCD. The shape is consistent with solar exposure damage. As said in previous posts, I would try to dispute the purchase or chargeback because that unit is definitely damaged. A repair like this is out of warranty and would be expensive since the LCD is one of the more expensive elements in the headset.

@itzdaniel483 - What letter is the little letter in the bottom left-hand displaying? Looks like it's in channel A? Hard to tell in this photo since you can only see part of the reflection. If so, channel A is single base-station mode. You'd want to hit the button on the backs of the unit until one of the units channel B and other is channel C. That said, you need to be very careful about not moving the units too much when pressing this button as the motors inside may be spinning at high speeds and jostling them too much can damage them.

@DanielePillan - The Viveport SDK only contains APIs which support the integration of Viveport store/platform features for titles which will publish to Viveport's content store (e.g. leaderboards, DRM, etc...). You're not able to derive SteamVR/OpenVR pose estimates from this SDK so I'm confused about what you're reporting. In order to derive the pose estimates and talk to SteamVR, you'll need to integrate OpenVR's native libraries into your binary. There are documents and samples on the SteamVR github. Valve is providing API access via C++ interlace classes. Integrating these libraries allow for both pose estimation data, I/O from the controllers, as well as video IO to the headset via a handful of compositing frameworks (DirectX, Vulcan, OpenGL...)