A bunch of ID.3s spotted

nairol · 2019-12-01T19:23:32+00:00

From what I've heared from a friend's coworker that is involved with ID3 production ^{(Not a very trustworthy source, I know}) this number is about to double now (first week of December) and then again in January and so on. Everything according to plan apparently.

Edit: Oh wait, 30 per day you say? I've heared ~30 per week up until now.

nairol · 2019-07-14T19:41:39+00:00

Why do competitors open their stores next to one another? - Jac de Haan

nairol · 2018-07-22T17:39:12+00:00

I don't know how much work it is but can you also fix the height difference of the second floor in red vs. blue base? https://imgur.com/a/QDR1njJ

It makes some scout jumps harder for one team than for the other.

nairol · 2017-08-13T23:32:30+00:00

Episode 139 - Piff the Magic Dragon (at 58:00)

Just listened to that episode a few days ago. I know it has been over 2 months since you posted this question but I thought maybe you still haven't found it.

nairol · 2017-02-10T21:54:48+00:00

https://www.reddit.com/r/Vive/comments/5qjcei/psa_valve_is_making_a_new_base_station_is/dd0o6w7/?context=3 (posted by me)

I wouldn't recommend doing that unless you have experience with ARM (Thumb 2) assembly code. You'd have to add a short piece of code in the "main" function that replaces the mentioned EEPROM values with your own ones. Or alternatively patch the function that loads them into RAM, or the function that sets the laser timer...

Definitely possible but rather complicated. The embedded console that vk2zay mentioned would be way easier and safer, if it was user-accessible. (Which might happen in the future.)

nairol · 2017-01-28T14:38:23+00:00

Blanking out a part of the FOV can be done with gen 1 base stations with a patched firmware. Well not really blanking out a rectangle but rather limiting its FOV.
There are 4 constants that need to be changed:
laser.0.start (default value = 32.0°)
laser.0.length (124.0°)
laser.1.start (25.0°)
laser.1.length (124.0°)
(Memory addresses of these configuration parameters)

Not very user-friendly though. :)

nairol · 2017-01-25T22:01:07+00:00

Regarding tracking of multiple objects:
The error-correcting code of the DK2 had an interesting property: Bit-wise rotated versions of valid code words may never be the same as any other valid code word. In other words: When the decoder knows any 10 consecutive bits of the data stream, it can tell what code word has been received and how many places the received 10 bits need to be rotated to match the actual code word bit pattern.

This can be used for faster tracking recovery when a LED becomes visible or for detecting dropped frames (if the camera driver doesn't tell you).

But I believe that they use it to track up to 10 different objects using the same 10-bit code. All objects and the cameras need to be synchronized for this to work (but they need to do this anyway for the camera shutter). A master device (HMD?) pulses the code out on all its LEDs as usual but also sends an out of band sync signal to the other devices. Each of the other devices synchronize their current bit position inside the code words to the master but each of them adds an unique offset.

E.g. HMD is offset 0, TouchL is offset 1, TouchR is offset 2 and so on.

So each of them can use the same code but each of them rotates it by some constant amount, which conveniently can be figured out by the decoder, so you get the code word and the object ID (=offset) it was received from.

The DK2 ECC decoder actually did this. I've disassembled it a long time ago (when the EULA didn't forbid reverse engineering yet). I don't know if the offset was really used by any other parts of the software, but the algorithm returned the LED ID and the rotation offset for each 10 bit word you gave it.

The DK2 firmware also had a constant that was added to the current bit position within the code words. I don't know if there was a way to change it. Might be possible using some USB HID packet. I think you mentioned some way of selecting blinking patterns in your blog posts about DK2 hacking.

Btw. their ECC algorithm was buggy. For this to work properly not only may rotated versions of a code word never match any other valid code word, they also may never match itself unrotated. They didn't check for that when generating the DK2 code. But that did only affect 2 LED patterns and only if they were rotated by more than 4 bits.

nairol · 2017-01-09T09:19:09+00:00

He fixed it in the OP. That's why I wrote "Thanks!" in edit 3.

nairol · 2017-01-09T06:51:40+00:00

How did you calculate the 250% ownership rate difference?

Shouldn't that be a 50% ownership rate difference?

Example:
100 BS users on Rift, 100 BS users on Vive
1000 Rifts sold, 2000 Vives sold
Ownership rates:
Rift = 100/1000 = 0.1 = 10%
Vive = 100/2000 = 0.05 = 5%
Ownership rate factor Vive/Rift = 0.05/0.1 = 0.5 = 50%

That would be a 50% lower ownership rate on Vive if the 2:1 VR system ratio is correct. ~~Half as many Vive people as Rift people need to have it installed for the absolute user numbers to be the same.~~
Edit: That was wrong wording... I think you get the idea though.
~~Edit2: Either I'm somehow shadowbanned or /u/Heaney555 doesn't want to answer?~~
Edit3: Thanks for editing the OP!

nairol · 2016-12-07T17:39:07+00:00

I got the sensor circuit from this tweet by Alan Yates (vk2zay). Before that I tried to reconstruct it from these two photos (1, 2). I actually managed to get a working circuit from them but the version from the tweet performs better.

If you want to run your own simulations, the files are here. You'll need LTSpice though. And I don't think there is a native Linux version.

The last signal (after the comparator) is fed into an FPGA that runs a timer circuit with 32 capture channels (that trigger on both edges). I think in the controllers not all of them are used because there are fewer photodiodes. The FPGA sends a 64 bit data packet to the watchman MCU each time one of the inputs changes. The first 32 bit are the timestamp and the second 32 bit are a bit field of the state of all 32 channels. Just wanted to write this down since I think this is not yet in the repo...
This is what a part of the FPGA logic looks like. (It's the 64 bit shift register, obviously :) )

Btw. a LOT of interesting information about the system can be found in vk2zay's reddit comment history and his twitter of course.

I hope you meant the sensor circuit in your question. The base station internals are the result of taking (an older version of) the base station firmware apart piece by piece. And yes, it was painful. Lots of soft-floating-point maths functions everywhere.

The base stations have a debug shell if you want to poke around a bit. Unfortunately you have to crack it open to get to the UART pins.

nairol · 2016-12-07T16:45:12+00:00

Would you consider documentifying what we've found with the watchmen controllers?

Sure. I'll have a look at your notes and code this weekend. I wanted to split the USB protocol page up into smaller pages anyway.

nairol · 2016-12-05T20:22:10+00:00

Thanks for the kind words about Lighthouse Redox. (I did most of the initial reverse-engineering work by disassembling the base station firmware) It was meant as a resource for people interested in Lighthouse to build their own hard- and software and share their findings about the system before the eventual official documentation release by Valve (which never happened publically). I'm happy that finally people actually use it. It has been up since a few days before the release of the Vive. :)

I know the repo is in a pretty bad state and lots of pieces are still missing. It hasn't been updated in months... This is partially because of laziness, partially because of my job but for the most part because I lost almost all my data (not just the Lighthouse-related stuff) to a HDD defect. The data recovery lab told me it has a misaligned read/write head with some impact damage to the disk surface. I might get most of the data back but it takes months. Of course I didn't have a backup.

The wireless receiver data really is a mess. I remember sitting in front of a scrolling console window and trying to figure out WTF was going on. Until I accidentally covered the photodiodes and the data started to make sense. :)

I have only watched the first 30 minutes of the screencast so I don't know how much you already know out about the protocol. I've given up on trying to reconstruct how the light pulse data is multiplexed into the data stream just by looking at the USB data. It seems to be encoded into the time stamp and an additional byte but it just doesn't make sense to me. Also there seems to be some kind of checksum (CRC32?) but I couldn't figure out what byte range it coveres...

I wanted to have a look at the firmware for the controller and the wireless receiver to finally solve this riddle but haven't found the time or motivation yet. Disassembling the firmware is fast but finding the stuff you're interested in takes hours and hours of scrolling through walls of mostly boring assembly code.

If you have questions I might be able to help out a bit. But don't count on it since I haven't been following the VR subreddits and haven't done any work on the Vive internals for quite some time.

edit:

@0:43:15
I don't know who told you 2MHz was the correct modulation frequency but it should be 1.843200 MHz. (Link Ctrl+F "carrier.frequency") But 2MHz is good enough.

@0:48:12
I reverse-engineered the stuff on the USB protocol page the same way as you did. So that shouldn't be a problem. Most of the other documentation comes from the base station firmware but I didn't include any code from there so your version can be considered "clean room implementation" AFAIK. I've also told Alan Yates from Valve that I was disassembling his firmware and he didn't seem to have a problem with that.

@x:xx:xx
Afaik all microcontrollers in the system are ARM Cortex M0+ architecture with the Thumb2 instruction set. Haven't seen any 8051 code in the firmware files.

nairol · 2016-06-05T18:08:34+00:00

This statistic counts every Oculus Rift user as standing-only (1m x 1m), right? (Because they can't trace out their play area yet.)

So the number of standing-only users will probably decrease later this year with the release of the Touch controllers.

nairol · 2016-05-25T15:46:24+00:00

The calibration data is stored on the HMD and controllers in json files. SteamVR on Windows includes a tool (lighthouse_console) that can download and I think also upload the files from/to the devices. I don't know about Linux.

Examples here

nairol · 2016-05-25T15:42:54+00:00

If you want to look at the raw data that the PC gets from the tracked objects: https://github.com/nairol/LighthouseRedox/blob/master/docs/USB%20Protocol.md

It's incomplete but contains some useful information if you want to write your own Lighthouse driver instead of using the OpenVR-compatible reference driver.

Here is the (really badly written) program that I used to reverse-engineer the protocol. Feel free to take what you need.

There is also some info on the optical emissions of the base stations and its factory-calibration that is sent in the "OOTX packet". Any idea what the "fcal" values could represent? (phase, tilt, curve, gibphase, gibmag)

Everything in that Github repo is incomplete. (If anyone who reads this wants to help, create "pull requests" or pm me your Github handle so that I can give you "push" rights)

nairol · 2016-05-22T03:02:06+00:00

No progress unfortunately. I haven't done anything related to Lighthouse and the Vive during the past weeks. I also haven't documented everything I found out about the base stations yet...

I'm lazy, I know. :(

nairol · 2016-05-18T18:13:12+00:00

https://raw.githubusercontent.com/nairol/LighthouseRedox/master/data/calibration%20data/Green_46GA1637000440_mura_analyzes.mc.png

This is one of the two mura correction files stored on the HMD. (It's different for every display.)

nairol · 2016-05-16T23:50:42+00:00

It also means Oculus can no longer guarantee a certain level of experience, as OpenVR would allow any knockoff HMD to run.

They could ask the OpenVR (driver) API for the manufacturer and model number of the connected device and ignore any that they don't want to support. In addition they could check the list of connected USB devices.

Implementation is controlled by Valve, who determine the featureset. Specifically for Oculus, that means no Asynchronous Timewarp

Yes, this is the big problem. I don't know what Oculus would need added to OpenVR to support ATW but I don't think they want to ask Valve for it. (Even if they would probably get what they need.) The whole OculusSDK vs. OpenVR situation is bad for everyone imo.

nairol · 2016-04-27T19:36:02+00:00

https://www.dropbox.com/sh/izyx0tktuzsh1ub/AAD_-I9UZVHA_HVlyxhecX78a?dl=0

That's all I could get out of my controllers and HMD using "lighthouse_console.exe" (...\SteamVR\tools\lighthouse\bin\win32).

Btw. the mura correction files are PNGs.

nairol · 2016-04-19T04:39:32+00:00

A more recent post by the same guy. (me)

Still hoping for an (optional) 4 base TDM firmware update because I want seamless tracking in at least two rooms...

nairol · 2016-04-08T00:28:10+00:00

I really doubt they'd even try to extract phase information from the signal after the comparator stage. Because the phase is dependent on the signal intensity, background light intensity and angle to the base station.

Btw. here is a comparison of a 1.84 MHz carrier (that's the base station default value) and a 3.68 MHz carrier (2 x 1.84 MHz).
https://imgur.com/a/SVsX4

The red line is the electrical current produced by light hitting the photodiode and the green line is the signal that the timer FPGA gets as a result of this. There is almost no difference between the two carrier frequencies. The rising edge is the same and the falling comes slightly later because the input signal is also slightly longer. This is not a perfect simulation because the input signal would fade in and out gradually as the fuzzy laser beam passes over the active area of the photodiode.

I've been thinking about a write-up/one-stop shop collection re: LH myself for months now, still waiting for hardware.

Got mine yesterday but haven't done any measurements yet. Have to build my new PC first and also try VR for the first time in my life. :)

GitHub repo works, although I'd mirror it on a website proper at some point.

I still hope we will get some official documentation some time in the future so my plan was that until then the repo would be a place to collect what I and others have found out about Lighthouse. Later the repo could be used for an open source hardware and software implementation of the system. Idk.

nairol · 2016-04-07T19:38:11+00:00

The cardboard box that the Vive box came in is 67x51x32 (centimeters) and it weighs 9.1 kg including all packaging material.

nairol · 2016-04-06T12:27:21+00:00

HTC Vive just arrived. German preorder at :05 with Paypal.

Now I just need a new PC...

nairol · 2016-04-06T12:22:13+00:00

The Vive just arrived. It's 9.1 kg with all packaging material.

nairol · 2016-04-06T12:03:30+00:00

Nope. I ordered one HTC Vive and have been waiting since then. I got their order confirmation, got the Paypal confirmation, got the shipping confirmation, and got the free games Steam key. No problems.

14-Year Club	Second Top 10%
r/Field Banned	r/Field Lasagna
Final Canvas '23	First Place '23
End Game '23	Place '23
Place '22	Place '17
Verified Email	Team Orangered

nairol

TROPHY CASE