SteamVR Developer Hardware

SteamVR Developer Hardware

Base station 2.0 channel configuration
I've been testing a setup with four base stations today and due to the lack of documentation been testing different channel configurations. I've ended up configuring the space with channels ranging from S-0 through S-3, but while the base stations are recognized during room calibration, I had some trouble with the game world suddenly flipping or tracking becoming very jittery, usually when I was in the relative center between the four base stations. Unlike the BS1.0 setup, controllers that started to fly away did not come back after a while, but stayed at a positional offset away from the hands.

Is the channel config relative to the spatial setup, do they need to be ordered in any specific way or what might cause this?

Something went wrong while displaying this content. Refresh

Error Reference: Community_9708323_
Loading CSS chunk 7561 failed.
(error: https://community.fastly.steamstatic.com/public/css/applications/community/communityawardsapp.css?contenthash=789dd1fbdb6c6b5c773d)
< 1 2 >
Showing 1-15 of 24 comments
bendotcom  [developer] May 4, 2018 @ 9:41am 
Can you share a diagram of your space? The "room overview" from the developer settings will draw the room for you if you don't have a sketch.

S-0 through S-3 are the right channels to choose for now. It doesn't matter how they are ordered.

The firmware supporting the full 16 channels as well as other improvements for BS 2.0 should be available soon. If you're working on a large space (10x10m, for example) then this update is probably relevant to your issues.

Right now the limitation for large tracked spaces is that you need to be able to track from all of the bases in some area (say in the middle of your play space) with the HMD. If you see persistent large offsets on a controller, that means that there is cached information about where the bases are that is wrong, but we haven't yet seen the corrected information. This can happen if you re-aim a base while SteamVR is running, or re-aim a base but then restart while in a corner (rather than in the center).
ErikGes May 4, 2018 @ 9:58am 
Hi there! First time I can see a talk about our matter ^^. We are working on a large space, a kind of Warehouse a little bit more higher than 10x10m. We just have received today four new HTC Vive 2.0 bundle with 8 BS 2.0. We have encounter the same issues as Holocafe... When I'm reading you bendotcom, I can only figure out that we have to wait for the next firmware from Steam :S... have you a date for this firmware? I figured out too that we should be finally able to use 16 BS 2.0 in the same space, depending of the channels distribution... is that right? Thanks for your answer ^^
Hi Ben!
I'm not in the office right now, but here's a sketch of how the space is configured: http://files.holocafe.de/temp/chaperone_space.png

The only thing that is probably uncommon is that we have placed two of the stations (S-2 and S-3) lower than the others (1vs3 meters height) as an experiment.

The controller offset wasn't there right from the start. I suddenly had the world tilting and a controller flying away while I was in the center. The controller came flying back, but never adjusted itself back to the actual physical position. But I noticed something that could well be connected to cached information. When I first did the room setup, the station S-1 was drawn at pretty much the same position as S-2. After I started walking around, the station suddenly snapped into the correct position and I've redone the room setup thereafter. But the tracking issues persisted. The controller offset (or a tilted game world) only reset when I restarted any VR application.

Some more general questions/remarks:
  • In the room setup, the maximum size appears to be capped at 4x4 meters. While this does not impact the correct positioning of a larger chaperone or the actually playable space, it might be useful to see the actual measurements after room calubration.
  • Since you're mentioning 16 channels: Is your plan to go beyond the four base stations and allow clustering of even more? Would this just be a matter of added redundancy / reduced occlusion for e.g. 10x10 meters or could I theoretically create four "tiles" of 4x setups that I could seamlessly walk in between?
ErikGes May 5, 2018 @ 6:16am 
We have currently made a test with 8 BS 2.0, in the same space.

If SteamVR recognize each base after a while... the more BS are connected, the more the drift we have... An awful motion sickness large drift in fact...

Due to the lack of informations we are not able to set the BS 2.0 channel, anyway it's seem's that it would have changed nothing...

Ben are you working on a SteamVR Pro with the opportunity for us to change each of the 16 BS 2.0 channel? In this way and as Holocafé is asking for... Will we be able to add more than 4 BS 2.0 in the same space, or will we be oblige to separate each of different 4 BS square to navigate through?
Well that wouldn't surprise me. To have multiple base stations in one space, each base station needs to be set to a different channel. Since there are currently only four channels available in the firmware, having twice the amount of base stations leads to multiple base stations sending the same station ID, which will confuse the sensors.

The BS1.0 used a fixed timing for sweeps so the sensors could always differentiate between the two stations. This method wasn't quite suitable for more base stations, since the timing between sweeps coming from one station would increase with every new station being added to the setup. If your sensors can only see one station (e.g. because of occlusion) and its tracking frequency becomes that low, the tracking wouldn't be good anymore.

Ben can certainly explain the details of the new tracking algorithm better, but the way I understand it is that each 2.0 station sends its ID (or channel) along the beam so the photodiodes are able to distinguish what station the beam is coming from.

Now imagine that your sensors located the position of two base stations which send the same identifier. The sensors see the first base station, correctly derive their own position in the room. Now you turn around and there's another base station that sends the same identifier, but has a different angle / distance than the sweep from the first base station. The sensors will still think it's the same origin coordinate and will thus offset your own tracked position accordingly. It's basically the same effect as multiple BS1.0 setups side by side without any occluder. Your tracked devices will always jump forth and back the different signals.
ErikGes May 5, 2018 @ 9:00am 
Thanks for your answer Holo! you're right about the Drift, you're explanation is clear and in consequence no needs to make more test with 6 or more BS 2.0 before SteamVr give us access to the 16 supposed channels of the BS 2.0.

In another hand, you seem's to have found a way to move the 4 actual channel of the BS 2.0 from S-0 to S-3... I can't figured out how to manage with the BS 2.0 to change this channel? Could you give me a short explanation or give me a link to a documentation, Holo?
I'm writing up an article on this this weekend with some graphics to make it clearer. Should be ready on Monday, I'll keep you posted :)
ErikGes May 5, 2018 @ 10:17am 
Great! thanks a lot Holo, I'm gonna stay aware about this article, please let a word on this page when you've done it!

Last thing about BS 2.0.

We assume that as the channel ID of the new BS 2.0 is only a modifed frequency of the laser, and since the new TS4231 in the HMD are able to detec infinite change in this frequency, we should be able to use more than 16 BS 2.0 in the same way ^^.

In my point of view those limitations are only due to the Valve Roadmap... But unfortunately, only profesional as us needs this kind of settings :s I'm curious about your point of view on this point?
I've been thinking about the same. Generally spoken, the TS4231 operates in the 1MHz to 10MHz range, but I couldn't find any information in its documentation about how many individual frequencies it can reliably distinguish. If you think about other electromagnetic signals such as the 5GHz band, it is often recommended to leave a gap of one channel between setups that shouldn't interfere with each other to have the frequencies far away from one another.

So I'm really curious as well about whether 16 channels are a hardware limitation or a software choice for the time being.
Brad_Herman May 9, 2018 @ 2:46pm 
HoloCafe: Did you end up making that document?
Ikrus May 9, 2018 @ 9:13pm 
We did, Sebastian wrote a blog post about it here: http://holocafe.de/en/blog/posts/how-to-set-up-multiple-steamvr-20-base-stations

Hope this helps :)
ErikGes May 13, 2018 @ 12:34am 
Thanks a lot for the Update Holocafe ^^. I appreciate the file. I wouldn't have imagine that this little hole could help so much ;)
ErikGes May 13, 2018 @ 3:58am 
Hi All, I have follow your tuto Sebastian, Unfortunately I can't figure out how to change the BS 2.0 channel :/ when I press the button in the small hole of the BS, the flash turn blue then white again, and when I check the channel on Steam VR nothing have changed :/ What must I waiting for? a sound a flashing light? it seem's that the BS have been reinitialized, and steam VR cannot see them again :/ did you met this kind of trouble.
I can figure out why Bendotcom didn't help us in our difficult process to Access 4 or more BS tracking :s
ErikGes May 14, 2018 @ 12:52am 
Hi there! Finally all is done! (thanks to the Sebastian document)

As there is no visual feedback when you press the button in the little hole behind BS 2.0, you have to increment them only one channel each time(one pression on the button), before checking in the SteamVR if the BS 2.0 increment really his channel from S-0 to S-3...

It's seem's that each time the BS are on the same channel as the first one, they didn't appear on the SteamVR.
We are currently meeting the same issues as Holocafe :/ the tracking is often instable and we encounter some drifting with the HMD and the controllers, even when we are in the center of our tracked square.

I hope that the next SteamVR update will resolve this issues quickly now Oo.
We did some further tests last week and the issue only occured when a base station was located in the false position. What helped for us was to cut power to the respective base station, power it up again and walk around with the HMD. Most of the time, the base station was then assigned the correct spatial position, but it took some try & error.

We're doing a stress test this weekend at DoKomi with 40.000 visitors, showing our latest common-space multiplayer game and so far, the tracking works like a charm after the initial setup: https://twitter.com/holocafe/status/997806661111812096
< 1 2 >
Showing 1-15 of 24 comments
Per page: 1530 50