sebastian_holocafe

Ah, was that the issue that would cause random controllers to be empty the next day even if they were connected to a charger and the headset was completely turned off?

Did you try wiggling around with the jack a little bit and see if you get any contact? There's a serial problem with the batteries that they aren't always getting proper contact. Happens both with the cables and the charging dock regularly. If you're using cables, make sure you use the original one. Other Vive power cables that are used e.g. for the link box or base stations on the other Vive models will only work when the device is powered off.

Do you have OFDMA enabled on the AP? TP-Link EAPs have that disabled by default, but it's one of the most important features in Wifi6 if you want to connect multiple streaming devices. Otherwise, devices wait for each other before receiving information and that's just not fast enough for VR. Also 5 GHz crosses over a whole lot of public services, such as ship, flight or weather radar. That part of the band is called DFS (dynamic frequency selection). So if the AP is using auto channels, it may randomly switch between channels that provide the most available bandwidth. Not just DFS, but also other networks in your vincinity can cause these channel swaps. These swaps take time and make VR unplayable. Which is why you should always define a specific channel for your AP and make sure it's wide enough (e.g. 80 MHz). You should always try to select a channel that is not crossing over with DFS cause that could shut your entire network down for something like 10 minutes.

Did you check if you have OFDMA activated? Some APs have this deactivated in their default config, but it's one of the most important features of Wifi6 in order to reduce latency. If it's not running, the AP will not be splitting streams and the headsets will be waiting for each other before sending packets.

Did you launch with VBMS or migrated from VBC + DMS? I can't really say anything on VBMS, since we've waiting since four months for the access and haven't heard any lifesign yet. But I did hear other operators talk about migration issues. Also, a word of warning: We've found the built-in boundary system to be quite buggy using the headset drawing approach. We're having headsets (basically all except the golden headset) where they are only drawn upon controller contact, but not HMD contact, which can lead to people bumping into things. So make sure you're testing that on all devices.

May I ask why? From a developer's perspective, logs are a really useful resource. We've been plagued with a couple of bugs recently in LBSS and to be honest, the support experience was abysmal. It's months of forth and back and support staff asking the same questions several times that have already been answered by us very concise before. We found repro cases that we submitted and it's still going forth and back. Part of that covered functionality that was security-critical. That whole experience could've possibly been much faster if we could just have had a look at the logs ourselves. Instead, we've been digging through the file system manually to find out what's wrong, because support didn't.

Yes, that's the exact issue! From your previous post, it sounded like you have multiple devices and the others work? If so, you should be able to find a working json file on any of the other devices.

We've observed this before as well. You may want to check if it's related to this issue, that solved it for us:

What settings in particular are you trying to change? VBS-related things? We've observed a file corruption on a couple of our devices that would prevent VBC from reading or writing VBS configs correctly. If that's your problem, a factory reset will not help, since for some reason we haven't figured out, that file corruption reappers on affected devices even after a factory reset. If you access your devices file system through adb, you should be able to find the following file: /sdcard/rrClient/config.json This file stores the configurations like server IP, silent mode, etc. for the VBS client. However, on corrupted devices, you will find this instead: /sdcard/rrClient where "rrClient" is not a folder, but a json file (without file ending) containing some of the configurations instead. If you have this, then that's the reason why VBC fails to write configs. Workaround: Copy the config.json from one of the working devices Customize it with a text editor to reflect the settings you want to have on the corrupted device (e.g. different server IP) Upload the file to the corrupted device and reboot it VBC should now be able to read and write settings from the device

We're using LBSS and VBC to synch maps for free-roaming installations. However, we want to make flexible use of our spaces as we could with the OpenVR API. Depending on the game, we want to be able to switch the point of origin and the boundary on the fly for different room configurations: Free-Roam: Origin in room center, boundary spanning the whole room Room scale: Players occupy quadrants of the physical room -> point of origin is offset to the center of the quadrant, each player have their own quadrant boundary In OpenVR, this is easily done by doing a room calibration, then reading out the universe and chaperone coordinates and saving them into a database. We can then calibrate multiple presets and load them when needed. On the Focus, I couldn't find any documentation on how to access this data or how to push it back to the device. While the map itself and the point of origin as well as the boundary appear to be different data models (as they can all be set separately from one another), they are all synched at once through VBC. What I want to do is to just access the origin point and boundary coordinates, save them in a preset and then mathematically manipulate them for room-scale configuration so I can toggle these presets over the air. Any ideas where these files are stored and how to access them? It's the most frequent use case our customers have and are thus hesitant to move to the Focus 3, which is otherwise better than previous systems for LBE.

This version activates passthrough when a controller loses tracking. That's pretty confusing to users, can this be deactivated anywhere?

Anything on the rrClient json file corruption that is present in the previous version or the rendering of the boundary that only shows on controllers, but not the head after synching a map through VBC?

While a 3x3 shouldn't give you tracking issues with two base stations already, 4 will definitely give you better coverage. For instance, we did 5x5 areas with four players with just two base stations with SteamVR 1.0 and it worked fine, but with SteamVR 2.0, got improved coverage when players were getting close to each other. Got any reflective surfaces nearby? You won't need the synch cable, the base stations will be modulated to different frequencies to allow the devices to differentiate what station the sweep is coming from. You wouldn't swap the wireless adapter (cause you'd have to untether and unmount it first). You'd simply swap out the power bank that's connected through USB. One important aspect, though: The wireless adapter is notoriously unstable. 60 GHz has a very limited range, so you need to be careful with the antenna placement. It works best when the signal is coming from the top, so you won't run into signal occlusion. However, the cable connecting the antenna with the PCI card is pretty short, which typically leads to having to mount to the computer to a wall, ceiling or truss. Furthermore, the power connection between adapter and power bank is a classic USB-A cable, which was never developed to be used in a moving system. Thus, any little movement happening on either socket frequently leads to micro disconnects, which will have the player white out. This can just be a brief connect with the HMD coming back after a few seconds. Pretty often, it cuts out completely and has to be replugged to re-initialize.

Update on this: The VBS problem was causes by a file corruption on one of the devices. Instead of /sdcard/rrClient/json.config The device had /sdcard/rrClient Where rrClient was not a folder, but a file. Manually replacing those files solved the problem. The Boundary issue may not necessarily be related to the firmware version alone. Upon further investigation, I noticed that the golden headset works fine. But the devices to which the map was synched through VBC show the issue.

Theoretically speaking: Once you have LBSS installed, you can define groups of devices that share a map. You can use a device to set boundaries and share that into the group you defined. Since you can move devices between groups, these devices will then update with the map that is assigned to the respective group. It's a bit of a hacky approach though, since you will need a group for each individual device + a shared group for co-located VR. And it will swap out the map, even though you really only want to swap out the boundaries and point of origin. It will also cause the headset to reboot with the new map after moving to another group, so it's not suitable for a realtime swap. We're currently looking into this issue and see if we can find a solution with Warpdrive VR, where we already have this functionality für SteamVR systems. But if this hacky approach works for you: Map each room-scale sector with its respective device and store that to an individual group, best name that group the same way as the device so you know which belongs to which Map the full area with one headset and allocate that map to a shared group that you can move all devices into when you need it

Typically, your router logs should indicate sweeps. Depending on the country you live in, different channels may be reserved for DFS. You can look that up online. Typically, some lower bands will be free of DFS. So unless you got significant interference from nearby devices on the same channels, you could try to configure your router to a static band that is outside of DFS range and see if that improves your issues. There is an environment scanner app to give you feedback on the environment quality for tracking, but I believe that is only for LBE customers. As a general rule of thumb: The tracking is particularly good with distinct geometric shapes. We use the devices for co-located VR in our venue where you have other moving people in the same tracking volume. We use high-contrast markers with geometric patterns on the floor and walls to give the headset something to latch onto.

Did you check for DFS sweeps? Just in case you have your router set to a channel that is intersecting with DFS, then radar sweeps will cause your router to shut down any signal temporarily. Cutting out to the black screen with loading bar can also be related to another issue: Tracking. If there are areas that the headset has problems tracking (e.g. tiling, blank walls), this could also be an indicator of a brief tracking loss.

Just a minor observation: Entering the active code for the enterprise tools often leads to the app not giving any feedback. Essentially, nothing happens and you can hit the submit button multiple times. If this is due to network lag, could maybe use a loading indicator or something. Right now, it's kinda unresponsive when you access these tools. Also, I don't know if this is technically possible, but it would be cool if the headset name that you set in VBC could be accessible through the interface. Especially when you have a large amount of devices, the internal name presented when pairing through blueetooth becomes confusing at some point, as you lose track of which headset is which.

I'm having two weird issues with this version that I did not encounter before. Boundary The boundary now only lights up in relation to the controllers, but not when you get close with the headset. Even though auto-passthrough is activated, it doesn't work anymore when passing through the boundary. VBS I'm trying to configure VBS through VBC. It does not work over the air at all, I'm always getting a "failed" when I try to set the config. While I am getting "success" on USB connection, it does not actually write the config, as it still asks me inside the headset which server I want to connect to. And indeed, once I try to load the config through VBC again, it's empty and hasn't stored any of my device settings. The map sharing over the air works, though.

With the hardware aging (4th year of use now), we are more and more frequently observing faulty battery telemetry coming from the Vive Pro controllers. They are typically displaying a state of 20% battery charge, but then go off just a few seconds after turning them on. Interestingly, once I plug them in to a different PC (not the one they're paired to), SteamVR shows me an actual charge of 1%. Strangely, this is not being displayed correctly on the computer that they're actually paired to. Is this a communication issue with SteamVR or is this a sign of aging hardware that reads out the wrong charge state?

There is a hidden section in this forum with all the setup tutorials and downloads. Reach out to your regional sales manager and request access.

I wish I had an answer on this. We get this completely randomly. We've got a four-player LBE setup. Even when there are no other players in the tracking volume, sometimes the device initializes within seconds and sometimes it takes like 10 minutes and several attempts before we get beyond the loading screen. We're actively moving the headset around the room so it can identify visual properties of the environment, but it remains random whether it takes seconds or minutes. I've also noticed two different cases: black screen with loading spinner black screen with loading spinner on top of app icon (e.g. lobby or business streaming) Would be helpful to know what these different states mean exactly. Maybe that helps tracking down the underlying issue. When I remote desktop onto the computer, I see angular, but not positional movement when I still see the loading state in the headset. To me that implies that the IMU tracking is already being transmitted, but positional is not - so that should have something to do with the map.

Same here. The configuration option to disable the headset buttons effectively bricks the device, since it cannot be onboarded without it. HTC does not have a workaround for this other than to call them and have your LBE config changed with the HMD button enabled. The Vive Manager is actually quite a handy piece of software that makes device management much more fluent than using the LBE tools on PC. But while they're adding features to it meant for LBE customers, LBE customers cannot connect with the Vive Manager app. I assume that will be fixed at some point, as the whole LBE system is still deep in beta.

During testing, I've noticed a strange behavior with VBS and SteamVR content: Whenever there's a Wifi disconnect (even briefly), in most of the cases the controller viewmodels disappear from the game or suddenly find themselves both attached to the left hand. Sometimes, restarting the controllers brings them back. Sometimes, a game restart is required. I suspect that the device IDs get somehow messed up when the streaming connection is re-established. I'm just not sure at which point in the communication chain this is happening. Is this between VBS and SteamVR or between SteamVR and the game? Are you expecting game developers to use a specific controller implementation to ensure the controllers stay where they are supposed to be? Cause there are several middleware components (e.g. Unity / SteamVR interaction system) in use to develop games.

So I understand correctly that the Vive LBE tools will be migrated over to the mobile app to manage the tracking volumes in late June? Right now, all's done through the SUELauncher. Would be a nice usability update 🙂