Accessibility Request Support for Power Wheelchair Joystick and Bluetooth Mouse Inputs Meta Quest 3
Hello Meta Developer Community, My name is Rodrigo Sologaistoa. I am a biologist pursuing a master’s degree in bioinformatics, and I work at the Biomolecule Simulation Laboratory at the Institut Pasteur de Montevideo. I am also quadriplegic and a power wheelchair user. Because of my disability, I cannot use my hands to control the standard Meta Quest 3 controllers. However, in my daily computer setup, I use my Quantum power wheelchair joystick as an input device through Bluetooth, and I also use external right- and left-click buttons connected through a Bluetooth mouse setup. I would like to ask whether there is currently any way to connect this type of accessibility input setup to the Meta Quest 3. Ideally, I would like to use my wheelchair joystick and Bluetooth mouse buttons to navigate and control the headset instead of using the standard handheld controllers. Voice control is helpful for navigating parts of the Meta interface, but it is not enough for many apps. For example, I want to use Nanome, a molecular visualization and molecular dynamics application, for my research and academic work. Once inside the app, I need to move around, select, rotate, and interact with molecular structures, but I cannot do this with the standard Quest controllers. This kind of support would be extremely valuable not only for my own research and academic independence, but also for other disabled users who rely on alternative input devices instead of handheld controllers. I would appreciate any guidance from Meta developers or the community on the following questions: Can Meta Quest 3 currently recognize a Bluetooth wheelchair joystick or Bluetooth mouse-style input device as a control method? Are there any accessibility settings, experimental features, developer APIs, or workarounds that could support this? Can app developers, such as Nanome or other scientific/educational VR apps, implement custom support for external Bluetooth input devices? Is this type of alternative input support something Meta is considering for future versions of Horizon OS or Quest accessibility features? Thank you very much for any advice, technical suggestions, or direction on where to submit this as a formal accessibility feature request.
Questions regarding Shared Spatial Anchors Limits and large-scale deployments
Hi, we're an organization investigating whether using Meta's Colocation / Shared Spatial Anchors SDK will be feasible for large-scale VR/MR projects. I have found limited information in the documentation regarding this topic, mostly mentioning 'two or more' players are supported. We are building a prototype app that is planned to need to scale up to approximately 200 people in quite a large space. We'd like to know if there are any strict hardware limits to: A) the amount of headsets that can share spatial anchor data with one another (in our case, it's fine if one headset shares the spatial anchors and the others 'listen' to these anchors. e.g. how many concurrent users can accurately receive spatial anchors from a single headset? B) the maximum amount of physical space that the headsets' pointcloud can accurately track. e.g. an area of 200m2Questions Regarding Shared Spatial Anchors Limits and Large-Scale Deployments
Hello, We are evaluating the feasibility of using Meta's Colocation / Shared Spatial Anchors SDK for a large-scale VR/MR project and would appreciate some clarification regarding its scalability. While reviewing the available documentation, we found limited information about supported participant counts, with most examples referring only to "two or more" users. Our current prototype is intended to scale to approximately 200 concurrent users operating within a relatively large shared physical environment. To assess whether Shared Spatial Anchors are suitable for this use case, we would like to better understand any practical or hard limitations of the system. Specifically, we are interested in the following: A. Concurrent headset support * Are there any documented or recommended limits on the number of headsets that can share the same spatial anchor data? * In our scenario, a single headset (or a small number of headsets) could act as the source of the spatial anchors, while all other headsets only receive and localize against those anchors. * Is there a maximum number of concurrent devices that can reliably receive and use spatial anchor data from a single source? B. Physical environment size * Are there any limitations regarding the size of the tracked environment when using Shared Spatial Anchors? * For example, can the system reliably support a shared space of approximately 200 m², or are there recommended maximum dimensions/areas for accurate localization and alignment? * If limits exist, are they determined by the anchor system itself, point-cloud tracking capabilities, network considerations, or another factor? Additionally, if there are any best-practice guidelines, performance benchmarks, or case studies involving deployments with dozens or hundreds of simultaneous users, we would be very interested in reviewing them.
Question About Meta Quest 3 Display Latency and Timing Accuracy
Hello, I am a graduate student currently planning a research study that combines EEG recording with virtual reality, and I am considering using either the Meta Quest 3 or 3S headset. Because EEG analyses require precise synchronization between stimulus presentation and neural recordings, I am trying to better understand the timing characteristics of these devices. I was wondering whether there is a delay between: A visual stimulus being rendered or presented by a program running on a computer, and The stimulus actually appearing on the display inside the Quest headset. If such a delay exists, I would greatly appreciate any information regarding: The typical end-to-end display latency (measurable delay) for Quest 3/3S. Whether the latency differs between wired and wireless PC connections. The expected variability (jitter) in presentation timing. Any technical documentation, specifications, or user experiences related to display latency and timing accuracy that may be useful for research applications. The goal of this is to ensure accurate synchronization between EEG recordings and visual stimulus presentation, so any information regarding timing characteristics would be extremely valuable. I initially planned to contact Meta's technical support team directly, but I was unable to find an email address or another way to submit a technical inquiry of this kind, so I posted my question here instead. If anyone knows the appropriate channel for contacting Meta's technical support or engineering team about these questions, please let me know. I would greatly appreciate the information, all your answers and times.Updated Meta Horizon Link app to 85.0.0.239.552 and now USB Link breaks within a min or so.
Everything was working fine for months but after updating to 85.0.0.239.552, my USB link is broken. After a min or so, the video craps out. Images below, video attached. This is not while playing games or dev'ing in Unreal or Unity. This is simply connecting my headset and going into PC link via USB-C cable. I simply go into PC link, wait about a min, and it craps out. After this happens, I can exit out of Link. When I disconnect and reconnect the USB cable, the headset registers the connect and pops up the USB debug window. But if I go to Quick Settings, the Link button says no PC is connected. Link functionality is broken. The ONLY way to reset Link is to restart the headset. Then I can go back into PC Link, wait a min or so, and then it craps out again. This has completely stopped all development on my project.
Add a toggle or remove automatic boundary switching.
I noticed with the most recent firmware updates (yay, they get worse as a new one comes out that keeps breaking my headset), that Meta has literally made my headset unusable for me. Meta, I am disabled. I have issues where I have to take off the headset almost every 10 minutes, and it sucks, really it does. Life is already super hard for me, but what I DON'T need, is for my only source of entertainment, is to come back after a flare up episode of my disability, to find that just because I put my headset down, it switched the boundary from "Roomscale" to "Stationary". Now every single time my disability acts up, I have to take the headset off, deal with my disability, come back, put the headset on, minimize steamlink, go into my settings, turn off stationary and put it back to roomscale (if it lets me because sometimes the stationary boundary gets messed up and only asks me if I want the new stationary circle HERE), then get back into steamlink, only to get motion sick because my boundary changed when I put the headset back on, and once more when switching it back to roomscale, and then have another disability flare up 3 minutes after getting resituated back into VR. You turned my quest pro into a paperweight. I don't know what the hell is going on, but every firmware update after v71 has the quest experience worse an worse, to the point where I can no longer use the headset without it causing an extreme immense of mental anguish. I bought the quest pro to be happy and play games. Not to stress the hell out every time I put it on. Thanks for the $650 paper weight Meta. - A disabled customer
next gen full body tracking using native wifi drivers
i want to propose a hybrid tracking system using sensor fusion instead of wifi working alone it would complement the quest cameras the cameras track the upper body while the wifi csi data fills the blind spots for the lower body and legs this solves the messy data problem because the system already has the headset and controllers as a base meta could add a toggle for full body tracking or upper body only to save battery it would be an optional feature powered by a low level system driver what do you think about this integration with the current movement sdkExploring Body Tracking via Wi-Fi CSI – A Newbie's Proposal
Hi everyone! I’m new here in the community and I’ve been diving deep into how we can push the boundaries of standalone VR tracking. As a fan of the Quest ecosystem, I’ve been thinking about a challenge we all know: tracking parts of the body that are out of the cameras' line of sight. I’ve been researching Wi-Fi CSI (Channel State Information) and was wondering if we could use the wireless signal already present in the headset to help with body tracking. Since Wi-Fi signals are affected by human movement (even through walls or behind the back), could this data be used to complement the existing IMU and optical tracking? The idea would be to use the CSI amplitude and phase changes as a secondary data layer to "guess" limb positions when the cameras can't see them. I know it’s a technical challenge, but I’d love to hear from more experienced devs here: Does the current Quest hardware allow low-level access to CSI data for this kind of processing? Could this be a viable way to achieve "Full Body Tracking" without external sensors in the future? I'm just starting to develop this concept and would appreciate any feedback or pointers to existing documentation! Best regards, Vinícius (Jurusbango)Proposta: Rastreamento Corporal Total via Wi-Fi
Subject: Proposal: WiFi-based Full Body Tracking using CSI (Channel State Information) Message: Hi Meta Dev Team, I would like to propose a feature that could revolutionize body tracking on Meta Quest headsets without requiring external trackers or extra cameras: WiFi-based Motion Sensing using CSI (Channel State Information). The Concept: Every time a person moves between a WiFi transmitter (router) and a receiver (Quest), the signal undergoes phase and amplitude distortions. By accessing the CSI data from the Quest’s WiFi chipset, we can analyze these signal patterns to identify body posture and movement in real-time. Technical Implementation: Signal Analysis: Utilize the 5GHz/6GHz signal fluctuations to map the user's silhouette and limb positions. Machine Learning Integration: Use a lightweight neural network to translate CSI "shadows" into skeletal data, similar to how researchers have successfully used WiFi for "through-wall" sensing. Hybrid Tracking: Combine this WiFi data with the existing Inside-Out tracking and IMU data to fill in the gaps when the controllers or legs are out of the cameras' field of view. Why this is a game-changer: Zero Cost for the User: No need for Vive trackers or Tundra trackers. Privacy: It doesn't rely on optical images of the room, just radio frequency patterns. Lower Latency: Direct processing of signal data can be extremely fast on modern SOCs. I believe this would make Full Body Tracking accessible to everyone and put the Quest even further ahead in the VR market. Best regards, Vinícius
