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