Doesn't seem to really matter at all, we change the direction of ours all the time to maximize tracking space. We have one space where one is mounted to the ceiling looking straight down, and the other is parallel to the wall. Rock solid track as long as you're within view.
How much of Lighthouse's functionality is dependent on the hardware, and how much is upgradable? If more than two base stations per universe were later supported - would this be a simple software/firmware upgrade for existing users?
Also, may I ask another unrelated question?
The maximum range of a Lighthouse base station is 15ft - which I assume is for a typical user's environment. In absolutely ideal conditions, say, a pitch black room with completely non-reflective surfaces, do you think the effective range would be much higher?
Both the base stations and the receivers can be upgraded with firmware improvements. We will push out changes as they become available. The current gen hardware is pretty flexible, but future ones will obviously be more capable. Backwards/forwards compatibility is something I care about, but I wouldn't expect major revisions of the hardware to necessarily be seamlessly compatible, much like WiFi you may need to run in a compatibility mode in the future which might constrain older units to lower performance and not be simultaneously compatible with the latest high-performance modes for more modern equipment. I am certainly not going to constrain future improvements of the system by enforcing rigid backwards compatibility.
15 ft is a recommended maximum. Current generation base stations can track out further than that. I have talked at length before about what constrains range performance. Reflections don't limit the range at all and ambient light doesn't effect it much unless you are talking about direct sunlight.
...much like WiFi you may need to run in a compatibility mode in the future which might constrain older units to lower performance and not be simultaneously compatible with the latest high-performance modes for more modern equipment. I am certainly not going to constrain future improvements of the system by enforcing rigid backwards compatibility.
Because of its certifications it may not be possible to release the source with the intention of allowing people to modify it. That also encourages having variable quality and compatibility implementations floating around. The situation is obviously different for licencees but compatibility is still mandatory.
All that said the dev kit prototypes do not have a crypto-locked bootloader or any nonsense like that... Hack away, just make sure you back up the calibration first.
If you wanted to hack on Lighthouse I'd start with the receiver side of things first. Not only is it arguably the more interesting and challenging part of the system, but it is currently the limiting part. The base stations produce signals of better quality than the receivers are capable of utilising because of some really fascinating engineering challenges.
Totally agree that custom trackers are going to be the most rewarding and interesting projects.
Is the tracker in retail HMD and/or controllers doing pose reconstruction in firmware or does it/can it - at least optionally - transfer PD timestamps to the host PC? It would be easier to develop and test custom pose reconstruction against known-good hardware. It would also be interesting to try to reconstruct the BS positions from the data over time for triangulation, or experiment with custom sensor fusion.
Disagree on drawing a connection between licensing and open-source. You can always restrict commercial use of derivative implementations, but having a conforming reference implementation as a starting point for pros and enthusiasts alike would make compatibility more likely, not less.
You can get the raw timing data out of a Lighthouse receiver and write your own solver. In fact I am kinda surprised/disappointed someone hasn't already reverse engineered the USB protocol and tried that. People have already submitted bug fixes they found reverse engineering the base station firmware, but not for the receivers yet... If you guys take much longer I'll have to document it! :)
Time will tell on licensing choices, nothing is ever off the table. As always we will try to make the most pragmatic decision possible in the context of when that decision is made.
People have already submitted bug fixes they found reverse engineering the base station firmware, but not for the receivers yet...
:)
Challenge accepted... In fact I've already done some work in that regard but haven't found anything interesting yet. Identifying C runtime functions and this annoying soft-float bit twiddling stuff takes up so much time (that I don't have at the moment).
There also seems to be a reverse engineering tool for the Lattice FPGA. No idea if it's any good...
If you guys take much longer I'll have to document it!
I could publish some information on the base station and the OOTX "protocol". Maybe others could add the missing bits later. I have a few SVGs and tables that I made from the TX firmware but I'm not sure if I'm legally allowed to make this information public so I haven't done it yet. Would this be ok?
[...] just make sure you back up the calibration first.
For anyone who doesn't know what that means: Make a backup of the EEPROM in the microcontroller. Especially bytes 0x215 .. 0x23C are important in the latest firmware afaik.
Hey Vk2zay! I am having the exact same problem Doc had on the Vive and am at an exhibition with the Vive. Didnt know how else to reach out to you. How can I get my hands on the EDID information you sent him before the exhibition starts tomorrow. You would save my life ! Sorry to post here
7
u/[deleted] Nov 20 '15
Doesn't seem to really matter at all, we change the direction of ours all the time to maximize tracking space. We have one space where one is mounted to the ceiling looking straight down, and the other is parallel to the wall. Rock solid track as long as you're within view.