Vive Tracking Woes: How Badly Do I Want VR?

My Vive has never really worked properly since I got it a few weeks ago. After talking to several friends with Vives and scouring the interwebs, I'm sure the flakiness I'm seeing is not representative of the average Vive user's experience, leading me to believe something is different/bad about my setup. Several friends and I spent a lot of time troubleshooting and trying all the standard fixes, but I still can't perceive a path to a working setup. I'll lay out what we've done so far. If you're reading this now, send help!
.·´¯`(>▂<)´¯`·.

The Problem

"Dang, I'm seeing a lot of grey screen flashes." (Googles for a while) "I think it means it's losing tracking...hmm, it seems to always happen when I'm turning around."

Test methodology rev. 1

Before things got "serious" and we were still troubleshooting like filthy casuals, we had a pretty hand-wavy way of reproducing the grey flashes, but we could consistently reproduce them.

• Stand in the middle of the play area and either wear the HMD or hold it by the head strap and watch the display mirror on the monitor.
• Rotate the HMD by doing an about-face (if worn), or by spinning it by the strap (if held).
• Rotate back and forth acrosanywhere from 5-20 times.
• If >1 grey screen flashes, conclude "It still has the problem."
• If 0 or 1 grey screen flashes, conclude "It's probably working fine."

Ruling out Vive hardware

Like any jaded consumer, especially one with a little bit of experience in the manufacturing industry, my first instinct was to blame crappy hardware. Hypothesis: My HMD or one of my lighthouses is faulty.

Conveniently, my brother lives across the street and also purchased a Vive. So we brought his HMD and lighthouses over to my place and swapped them in...and still observed the problem. Conclusion: My HMD and/or lighthouses are not the cause.

Ruling out lighthouse positioning and sync

Most tracking problems I read about online seemed to be solved by people tweaking their lighthouse positioning, aiming, or modes. Hypothesis: My lighthouse positioning is bad, or they're unable to sync.

I tried several things and still observed the problem every time:

• Used tripods to create an "ideal" setup with the base stations at exact opposite corners of the play area, ~85 inches off the floor, aimed directly at each other.
• Created an alternate "ideal" setup using the two other corners of the play area.
• Tried a wide range of lighthouse pitch angles.
• Swapped channels b and c.
• Deployed the sync cable and tried A-b mode.

The problem was still reproducible every time. Conclusion: It's probably not lighthouse positioning.

Ruling out PC hardware

A significant number of people complaining of tracking issues online seemed to narrow it down to USB problems, including certain USB controllers not working well with the Vive, USB being saturated when the HMD camera is turned on or set to 60Hz, problems using USB 3.0 ports, etc. But before we go nuts testing a thousand little things, let's try to rule out the PC hardware completely. Hypothesis: PC hardware is causing the problem.

We brought my PC (and breakout box for good measure) across the street to my brother's house and connected his Vive to it, with his lighthouses. We were not able to reproduce the problem. Conclusion: PC hardware is not the cause. It's also not a bad breakout box.

Ruling out cables

I'm using a (powered) USB extension cable and relatively long HDMI cable in my setup, because my play area is about 10 feet away from where the PC sits. Maybe they're borked. Hypthesis: Vive doesn't like my long USB and HDMI cables.

I removed the long cables and plugged the breakout box directly into the PC using the USB and HDMI cables that came with the Vive. The HMD cable was still long enough to reach the center of the play area, just not the far side. The problem persisted. Conclusion: My long cables aren't the cause.

Ruling out interference from my other electronics

A number of Vive users online have posted that wifi or bluetooth seemed to be the cause of their tracking problems. We were also suspicious of a number of other devices in the apartment that could be emitting IR that would be picked up by the HMD's sensors (the Wii U light bar on top of the TV, for instance). Again, let's try to shave off the biggest slice of the possibility space that we can. Hypothesis: Some other electronics in my apartment are causing the problem.

We went around the apartment and unplugged everything except for the PC and the Vive stuff. We even took the batteries out of a lot of devices and powered down everything with a wifi adapter. The problem was still just as reproducible as ever. Conclusion: My other electronics are not the cause.

Ruling out sunlight

My apartment is rather bright. I have three gigantic south-facing windows and one gigantic west-facing window. It might be the brightest apartment I've ever set foot in, to the point that even with the linen curtains drawn, we sometimes can't play certain video games for a significant portion of the day because it's too bright to see the image on the TV. Hypothesis: Sunlight is hitting and triggering the HMD sensors.

We've spent a good two full weekends and several weeknights troubleshooting this problem. There has never been a discernible difference in our ability to reproduce the problem during the day versus at night. Even during the most rigorous data gathering sessions, the rate of tracking disruptions remains consistent at high noon as well as midnight. Conclusion: Sunlight is not the cause.

What's left?

The remaining list of possible causes I can think of is relatively short, but everything on it is somewhat of a pain to test and narrow down. To recap:

• Vive/lighthouse hardware
• Lighthouse positioning/sync
• PC hardware
• Cables
• Other electronics in the apartment
• Sunlight
• RF sources outside of the apartment (unsure how to mitigate)
• IR sources outside the apartment (unlikely as closing the blinds doesn't help)
• IR sources that aren't electronic (like what?)
• AC line noise (a pain to eliminate; may try a mini UPS)
• Reflections (hard to narrow down)
• Stacking of multiple issues, including previously ruled-out ones (major pain)

Reflections seemed like the thing I had the best shot at narrowing in on, given the current state of my tools and knowledge. If reflections are causing the problem, I should be able to put up some barriers and get to a known-good state, then take away barriers one by one until I find the source/s of reflections.

Test methodology rev. 2

On order to be able to consistently narrow in on possible sources of reflection, I came up with a new test rig that would keep the HMD position and motion consistent between tests, and also allow me to establish "known good" and "known bad" scenarios I could easily re-test for sanity checking.

test rig

I mounted the HMD to a tripod in a designated position in the room. The new test procedure is as follows:

• Move to the operator position and crouch or kneel.
• Left hand braces the tripod.
• Right hand rotates the head as smoothly as possible so it "looks" back and forth across a designated arc. At the left and right extremes of the arc, the handle on the tripod should align with the corresponding tape line.
• Moving the head's gaze from the far left to the far right, and then back again to the far left, counts as one "full turn" (a double about-face).
• Complete 20 full turns for a full test run, 10 for a sanity check.
• A collaborator sits at the computer monitor with a notepad and makes a tally every time the display mirror shows a grey flash.
• Compute the rate of disruption for the test run as # flashes / # full turns

Attempting to close in on reflections

The general approach was to try to eliminate barriers  one by one to close in on sources of reflection. If we ever observed a test run with disruption rate > 0.2, we would usually revert to the last believed-good barrier configuration and do a quick sanity check. If the sanity check also had a disruption rate > ~0.2 we would revert barrier configurations until we got a passing sanity check, and throw out all newer results since that configuration was tested.

Test runs #1- 4

establishing the efficacy of barriers

The starting configuration. The side without the barrier is close to the wall, and there is no furniture there. The goal at the start was to establish the efficacy of barriers in eliminating the problem. Hypothesis: If reflections are causing the problem, putting a barrier between the HMD and any sources of reflection should result in good tracking. Raising the HMD vertically above the barrier while keeping everything else the same should result in the problem reappearing.

We ran tests at two HMD height positions, with all other factors remaining the same. For reference, the barrier height is 34" off the floor. In the lower HMD position, the lowest sensors on the HMD are 30" off the floor (2" below the barrier height). In the higher HMD position, the lowest sensors on the HMD are 38" off the floor (2" above the barrier height). All disruption counts are for test runs consisting of 20 full turns, and they were executed in the order listed.

Results:
#1 Lower position (30"): 0 disruptions (rate of 0.0)
#2 Higher position (38"): 20 disruptions (rate of 1.0)
#3 Lower position (30"): 2 disruptions (rate of 0.1)
#4 Higher position (38"): 19 disruptions (rate of 0.95)

Conclusion: The results support the idea that reflections are a major cause of the problem, and that barriers can be used to eliminate at least some of the reflections.

Test runs #5-17

barrier numbers

The second round of test runs was designed to narrow the barriers to the minimum and look for sources of reflection in the resulting arcs. All test runs were performed at the lower (30") HMD height. Results show the disruption count (and rate) for 20 full turns.

Results:
#5 Barriers 1 2 3 4 5: 0 (rate of 0.0)
#6 Barriers 1 2 3 4 _: 0 (rate of 0.0)
#7 Barriers 1 2 3 _ _: 15 (rate of 0.75)
#8 Barriers 1 2 3 4 _: 0 (rate of 0.0)
#9 Barriers 1 2 _ 4 _: 17 (rate of 0.85)
#10 Barriers 1 2 3 4 _: 0 (rate of 0.0)
#11 Barriers 1 _ 3 4 _: 0 (rate of 0.0)
#12 Barriers 1 _ 3 _ _: 27 (rate of 1.35)
#13 Barriers 1 _ 3 4 _: 0 (rate of 0.0)
#14 Barriers _ _ 3 4 _: 22 (rate of 1.1)
#15 Barriers 1 _ 3 4 _: 0 (rate of 0.0)
#16 Barriers 1 _ _ 4 _: 23 (rate of 1.15)
#17 Barriers 1 _ 3 4 _: 0 (rate of 0.0)

Conclusion: Th minimum working barrier configuration we have been able to achieve so far consists of barriers 1, 3, and 4. Taking away any one of these three barriers consistently results in a high disruption rate, whereas having all three in place consistently results in a low disruption rate. This suggests two arcs containing reflection sources: the small arc formed by barrier 1, and the larger arc formed by barriers 3 and 4 together.

Further narrowing

attempting to find sources of reflection

We decided to focus on the smaller arc formed by barrier 1. Hypothesis: Something in the arc formed by barrier 1 is reflecting laser light from one of the lighthouses onto the HMD sensors.

There is a small number of interesting features in the target area:
(1) Couch with shiny legs
(2) Cabinet
(3) Plant in glazed pot
(4) Pub table with stools
(5) Window
(6) Lotus lamp

We decided to perform a series of quick (10-turn) test runs to probe the possibility space. This did not result in any conclusive data, as results from one test run to the next were inconsistent. Our anecdotal observation was that uncovering any of the listed items except for the (6) lotus lamp resulted in a high disruption rate. In fact, even with every piece of furniture covered, the lamp turned off, and a generous further-away barrier in front of the window and wall, we weren't able to consistently achieve a disruption rate of 0 without barrier 1 in place. We did go back and confirm that replacing barrier 1 (to achieve the 1 _ 3 4 _ condition) once again dropped the disruption rate to 0.

Conclusion: Unfortunately our further attempts at narrowing in on the source of reflection yielded far from conclusive results. We weren't able to identify a solitary source of reflection, as removal of any of the furniture covers in the arc seemed to result in high disruption rates.

Conclusions

view from my window; nearby water tower
covered in what looks like cell antennas

I still don't have a solid understanding of why my Vive setup is so much flakier than any of my friends', and I'm quickly running out of ideas for how to proceed that don't require prohibitively expensive test equipment. It seems certain that reflections remain a huge problem, but it has been very difficult to identify individual sources of reflection. In addition, some obvious-seeming sources like the shiny couch feet are problematic in my apartment, yet fine in my brother's setup although he has the same exact type of couch. The disheartening truth is that it's simply not realistic for me to cover every piece of furniture and every patch of exposed floor in large sections of my apartment in order to use the Vive.

It also seems very possible that what I've been referring to and thinking of as a single tracking problem is really a combination of problems resulting in the symptom of flaky tracking. But I don't have a good idea yet for how to gain insight into this possibility.

If anyone has any ideas that might help, please let me know! I'm especially interested in information regarding:

• Susceptibility to RF in cellular frequency ranges; there's a water tower covered in what looks like cell antennas about a block away in open line-of-sight to one of my windows.
• How to log, parse, and interpret sensor data from the HMD.
• A general idea of how the math behind Vive HMD tracking works, and in particular any conditions that might make it more susceptible than normal to reflections.
• Idiot's guides to IR, RF, and/or interference. I'm not an EE, so anything that could bolster my knowledge in these areas might help me generate ideas.

Finally, if I'm not able to achieve decent Vive tracking, I guess there's always the backup plan; return the Vive and buy myself a nice new large, ultra-wide curved monitor as consolation. But I'm not quite ready to give up yet, so please leave a comment if you have any ideas!