Skip to content

Latest commit

 

History

History
52 lines (37 loc) · 7.01 KB

File metadata and controls

52 lines (37 loc) · 7.01 KB

10/28/2025 - Electronics Research

Because I want my headset to be a wireless PCVR headset, I need to transmit and receive data incredibly fast. DisplayPort 1.2 transmits 21.6 Gib/s, and I'd like each eye to be about 2k120fps. I found WiGig transceivers to be the best option for this, and the particular models I'm going to use are the HMC6300/6301 chips.

I need to have a chip to decode and encode DisplayPort data going to and fro the transmitter and receiver, and the ANX7497 seems to be the best option for what I need. It can also compress and decompress DisplayPort data, making video transmission faster, and less of a hassle.

For the displays, I have a lot of options. All I want is 2k120fps. A lot of companies sell displays catered to VR/AR on sites like Alibaba and Aliexpress, and I have found tons of displays that meet my needs.

For the inside-out tracking, I plan to use a dual OV9281 setup mounted into the front of the headset. In the controllers I will have an array of NIR (Near-Infrared) LEDs in a configuration similar to that of the Oculus Rift S controllers. The purpose of these NIR LEDs is to give the cameras points to track, and by arranging them in a certain configuration will allow me to determine the transform of the entire controller.

(Image from iFixit) image This image shows the LED configuration of the original Oculus Rift. Having a recognizable LED configuration makes tracking more precise.

The controllers and headset will all contain two BMI270 IMUs. The purpose of having two IMUs is for redundancy, reliability, noise reduction, and improved orientation tracking. Oculus and other high-end controllers typically use a single IMU in their controllers, but due to the fact that my inside-out tracking algorithms are likely not going to be on-par with theirs, I feel it is necessary to compensate by making IMU readings more accurate.

11/2/2025 - ECAD Sourcing & Controller Thoughts

I have found some ECAD models online for the connectors, and SMD components which will go on the motherboard of my headset. While researching datasheets and CAD models for parts, I discovered that Analogix does not manufacture or sell the ANX7497. Instead, they redirect to their distributors who also do not list the ANX7497 on their websites. I emailed their North American distributor to get information on the ANX7497, but in the meantime, I will be using the MCDP6150C1 instead. Below is a list of links to the CAD files I have found for the components that I know I will need.

ESP32-S3 HMC6300BG46P7 (Transmitter) HMC6301BG46 (Receiver) MCDP6150C1 (ANX7497 Replacement) BMI270 (IMU) CSI Connectors Display Connector Display connector goes to these displays image These displays do not have any CAD files that I could find, but this image is available on the AliBaba listing, and is what I will be referencing going forward.

I wanna take a second to talk about why I chose some of the parts I did, starting with the ESP32-S3. I considered using a Raspberry Pi CM4, but after some research, I didn't like how much space it took up. I decided that it would make more sense to go with an SoC. The first SoC I considered was one of the LPC11Uxx SoCs, but I decided that due to the lack of knowledge or online support for this processor, it was a poor contender for the main CPU for the headset. Instead I chose the ESP32-S3 due to how well known the ESP32 SoCs are, as well as the fact that it has built in WiFi, Bluetooth, and how much storage it has. This SoC should be easy to program in Rust, and easy for beginners to modify in an IDE like ArduinoIDE or PlatformIO. The reason for picking the BMI270 is that previous IMUs, such as the MPU6500, 6050, and 9250 have been discontinued, and are now considered obsolete. The BMI270 is a newer alternative, and it is an all-around a better IMU, with its only downside, being that it requires configuration and more careful calibration than the MPU IMUs. Since the ANX7497 is not available in a consumer-friendly way, I had to find an alternative. The closest chip I could find to the ANX7497 was the MCDP6150C1. It has very subtle differences to the ANX7497, but from what I've read, it can do exactly what I need.

I also want to share some of my thoughts on what I want to do about the controllers: I don't have any. While I do want this headset to have accompanying controllers, I don't want to think about them at the moment. The reason is that they're easy to make. The controllers would, more or less, function identically to a standard Oculus Rift controller. They will have analog sticks, regular triggers, grip triggers, and face buttons. The only difference is that the controllers will also have two BMI270 IMUs for spatial tracking. There's not a whole lot to think about on this front.

I also plan to make the controllers wireless (of course), and use Bluetooth. My Oculus Rift S controllers use Bluetooth, and I have never had any issues that a simple battery swap couldn't fix, so using Bluetooth will make everything incredibly easy.

Now with all that being said: I do want other non-conventional or homemade controllers to work as well. I like the idea of being able to build a VR glove, like the LucidVR gloves, and have it work perfectly, hopefully without drivers.