JoeJ

I am trying to use the VBConsole app to apply a new activation code to my headset. On the device settings tab, I select USB in the drop down and can see my headset without any issues. However over on the devices tab, I see my headset listed but it always shows as disconnected. Because it shows disconnected, I cannot apply a different group/activation code to my headset. If I do connect my device to wifi, it will show as connected and then I can update it with a different activation code. Is there a way around the requirement to be connected to wifi to apply these activation codes? Perhaps a manual process through adb or some other technique to get the activation code installed?

The add-on is still enabled. I re-installed it this morning to double check and included a screen print of the different components below. Based on the message in the steam logs it appears that they removed support for the older openvr interface version in the driver. Unfortunately i can't upgrade the steamvr version right now (a few of our games don't work quite right on the newer version).

Is there a minimum SteamVR version that is supported with business streaming? The 1.07.13a version worked with steamvr version 1.10.32. but this newere version of VBS does not work with that older version of steamvr (you get a error in the steam logs saying it could not init the business streaming driver).

I would love to know how to make this work also! It is incredibly slow and unproductive to build/deploy/test as that is a very slow process. For me the streaming server comes up, runs and is displaying valid log messages to the console window after I start up the device apk. But, when I run inside unity the game does not show the headset (or controllers) moving. I've tried via USB connection and wifi connection and neither works. If I look in the logs on the headset under /sdcard/DirectPreview I do see some errors messages popping up. But I can't figure out what is causing those so am pretty much stuck!

So.. I was finally able to get it to 5.0.999.558. The steps I had to follow were pretty odd: 1) go to Settings>Advanced>Beta then click quit beta program 2) it offers to install 5.0.999.514 so I installed that version and then it made me go through the full install process to setup vive manager, watch the training video, etc. 3) after reboot i checked advance>beta and can see that is offering to "Join" the beta but I did not click that (just did this to verify that i was not in the beta) 4) During this boot of 5.0.999.514, is offers to install 5.3.999.514. That is a beta version so I was hesitant to put it on but I went ahead and did it anyways 5) after reboot it offered to install 5.3.999.558. I went ahead and put that version on also 6) finally, after this reboot it offered to put on 5.0.999.558 which is the one I wanted so I installed that version also and rebooted 7) after reboot i checked advance>beta and can see that is offering to "Join" the beta but I did not click that (just did this to verify that i was not in the beta) 8. then i checked general>system update and can see that it is offering to install 5.3.999.558 again (which is the beta so i am not installing that) So in the end i was able to get it to 5.0.999.558 but I suspect this is not what the developers of the beta program intended. Also, I am guessing that I will not be able to get to the next public release of software without jumping through similar hoops again. Maybe it will all get straightened out before that version.

Yeah, that is the version i was expecting. When I opted out it offered 5.0.999.514 instead. So i went ahead and updated to that version thinking that after a reboot it would let me go to 5.0.999.558 but instead it is saying 5.3.999.514 (which i think is a beta version). So not really sure what I can do to get out of this loop and back to the 558 version.

I've been trying to get my headset out of the focus3 beta program but for some reason it is not working. I go to Settings > Advanced > Beta features, and click quit Beta program. It will re-install me back to 5.0.999.514 but then when the headset comes back up, it says the only update avaialable is 5.3.999.514 which drops me right back into the beta. Is there a way to get out of this beta?

Is there a way to determine if markers are actually being used when setting up a map with drift prevention markers? I can successfully create a map with markers using the android app. However, I can't visually see them in the headset nor does the android app give any indication that they are being used other than the fact that the map was succesfully created with them. So I "think" they are being used but there is no definitive way to prove this. Ideally there would be an app I can run that would paint the markers inside the virtual world so as I walk around I can see them. Does any such app exist?

I would love to know the answer to this also.

I have used the eventing api on Native Focus3 apps only and I do get battery events but there are other events I have always thought I should see but do not. It seems like they would have support on Cosmos for something this simple but perhaps they have not added support for that device type in the SDK.

I have been experimenting with Aruco Markers and Marker Based Location Sharing. After I start a scan and it detects the Aruco Marker, I would like to get the Pose of that Marker before it swaps the coordinate system origin over to that Aruco Marker. I can see in logcat where it prints the Matrix that is used to apply an offset but I cannot find any API or Event that will return the offset being applied to my application. Is there an API or some other creative way to get that pose for the Aruco Marker?

Here is another API I just ran across that looks a bit easier: Interop.WVR_GetDeviceBatteryPercentage(WVR_DeviceType.WVR_DeviceType_HMD);

You should be able to listen for the event. I think there are several different battery events you can get access to. The Wave.Essence.Events has this api but I think there are others in the legacy plugin. SystemEvent.Listen(WVR_EventType.WVR_EventType_BatteryPercentageUpdate, OnBatteryEvent);

I found a way around this problem -- I had to manually download the wave xr native plugin and then use Package Manager to import it as a tarball. Not sure why that got around this issue but I can include all of these packages now.

You should check into the Aruco Marker drift prevention & relocation markers as it should help if you play in a large space. I was also just experimenting with the Aruco marker location sharing features. That is probably a little different than what you are after but it does actually change the users origin once it sees a marker on the wall. Anyways, what I noticed is that there was an API in their Native sdk for a function that will recenter the space. I wonder if you might be able to use that or a similar call to SetParameters that will move the space around a bit on the x,z axis. key = "ClearRecenterXform"; Interop.WVR_SetParameters(WVR_DeviceType.WVR_DeviceType_HMD, Marshal.StringToHGlobalAnsi(key)); Interop.WVR_SetParameters(WVR_DeviceType.WVR_DeviceType_Controller_Right,Marshal.StringToHGlobalAnsi(key)); Interop.WVR_SetParameters(WVR_DeviceType.WVR_DeviceType_Controller_Left, Marshal.StringToHGlobalAnsi(key)); BTW - if you happen to find more detailed doco on the different key values you can send to that SetParameters function please let me know. I have not been able to find any detailed doco on it anywhere!

I have a need to use a few Native Library calls when dealing with Aruco Markers in the headset. However, I found that when I import both the "OpenXR Plugin - Android" & "OpenXR Plugin - Native" packages I get compile errors in the project. It looks like there is some type of conflict in the package definitions. Is this a known problem? Is there any way to get around this?

The app sounds pretty awesome. Lighthouse based tracking is quite accurate but the lighthouse driver can be a bit of a mystery at times. By dialing in the pose, I just meant that you can get slightly different poses for your root lighthouse during startup of the environment. If you watch the universe poses in lighthousedb.json between runs you may notice that the target pose from the root lighthouse at (0,0,0) to your secondary lighthouses may be slightly altered during startup or even after running for a period of time. Getting precise positioning highly depends on how well your tracker is seeing the lighthouses during startup, if there is any reflection in the enviornment, etc. You might want to copy off that file from one run to the next and compare them to see if there is any significant movement in the universe poses. Also, I have noticed that the initial pose that lighthouse driver calculates during startup can makes a difference on how accurate your position is. It would probably depend on whether your device is stationary, the calculated pitch/roll of the universe, etc. Theoretically the kalman should dial in that pose after a period of time but I've noticed that sometimes an initial pose or pitch/roll that is slightly off may cause a visual difference (i would check the logs between runs to see if there are any explainable differences).

Just out of curiosity, are you using lighthouse based tracking for this app? Seems like you would have to dial in a very precise pose in the universe for those lighthouses in order to get everything that accurate.

Here is a little more information on this topic -- I found up higher in logcat where it prints info about the tracking mode and also other features that are enabled. Assuming that I am reading this properly, it looks like I am in VO mode but the marker based location sharing appears to be disabled. Perhaps there is some other call I need to make to enable that feature? On a side note, I wonder what "tracking feature obstacle" is. Have not seen any talk of that in the forums.

I already have an activation code for VO mode on the focus3. But recently I've been trying to get aruco markers to be recognized using the bits of c# code mentioned in this pdf. https://forum.htc.com/applications/core/interface/file/attachment.php?id=4858&key=04586e354f1b896547c27ff449c8c973. And this link came from a doc by @HTC_Abby in another forum: [LBE features] Marker based location sharing - VIVE Enterprise - LBE service for Focus 3 - Community Forum (htc.com) It appears that even though I have an activation code for VO mode, I cannot init the markers using these bits of c#/unity code. During initialization I get a message in logcat from SLAM/ReadMarkerJson saying that the behavior is not supported. The initialization string I sent was the same as mentioned in the doc, the only difference being that I had to modify the size of it. If anyone has ANY info on how to get this feature or other focus3 Aruco based features working, please let me know. Even any tips or pointers on where I can find more detailed doco that is specific to programming the Focus3 headset would be appreciated.

What is the game? It seems like you would need to use LBE maps and drift prevention for an area that big.

I have always run my trackers wired since I was not trying to move my trackers around too much. At one point I did try to run that many of them wireless but seemed to hit a wall when I got over 8 or 9 of them. I am guessing there are limitations on the bandwidth available to a wireless tracker but am not sure of that. Also, the limit of 7 usb ports per hub was more related to how Windows itself dealt with my hubs rather than any physical limitations. Technically speaking a 13 port hub "should" work but I could never make it 100% reliable so that is why I would just get 2 hubs to plug all your devices into rather than one (plug them directly into a usb port on your pc btw, don't try to daisy chain the two hubs as that is the same as what a 13 port hub does)

I have same issue with direct preview In the log I can see some activity beforehand showing that it is talking to my PC, but I ultimately end up with the same packet NULL error that you are seeing.

I've connected about 30 trackers to a single machine for some testing and ran into issues using the 13 port hubs before. On "some" machines windows has an issue and they become unreliable. It all has to do with how many hubs are connected together internally in the machine, the boot sequence of drivers in the operating system, etc. It was very messy for me and hard to figure out when it did not start up properly. Anyways, I would recommend using 2 powered usb hubs with 7 ports rather than 1 hub with 13.

From a PCVR app, I need to detect whether the user has put on the headset. I currently do this with other headsets using the proximity sensor and event messages from driver lighthouse. However, I have not found a way in the openvr api to get information about the proximity sensor for the focus3 headset. Does anyone know how to access proximity sensor information through the htc streaming/rr driver to determine when a headset has been put on?