Casting, start to finish
How to cast a VR headset to a screen
Open the Minerva Hub on a computer that is on the same WiFi as the headset, select the headset, and press Cast. What the wearer sees appears on that computer, and from there on the room’s display. The picture travels across your own network — it never makes a round trip to a data centre, which is the whole reason it arrives as fast as it does.
What you need
- A Meta Quest or Pico headset with the Minerva application installed.
- A computer on the same WiFi network as the headset. That is the only connection between them — there is no capture card, no HDMI run and no dongle.
- A Minerva sign-in. Once someone is signed in, the session keeps working offline indefinitely; casting itself never needs the internet.
Casting a headset, step by step
- Sign in to the Hub. One tap on Sign in with Microsoft, then you choose Google or an email address on Microsoft’s own page, so no password ever reaches us. Your instructor station opens in the browser.
- Turn the headset on, on the same WiFi. It appears in the Hub by itself — there is no pairing code to type, no QR code to line up and nothing to plug in. The Hub keeps looking, so a headset that wakes up later joins the list on its own.
- Select it and press Cast. Pick one headset or several; the Hub casts each of them to your screen at once.
- Approve the prompt inside the headset. Android asks the wearer to confirm before anything can record the screen, and it asks again each time the application is started. No application can skip that prompt — ours included, and you should be sceptical of one that claims otherwise.
Shared headsets can be set up to skip that last step. A headset provisioned as a managed, single-purpose device can grant screen capture once, as part of setup, and then never ask again — including after it is powered off and back on. That is a property of how the device is provisioned, not something an application can grant itself. If you are running a bay of headsets that get handed from person to person, ask us to set it up that way.
Why it is fast
Speed here is not tuning. It is the path the picture takes.
- The video goes straight from the headset to your computer, peer-to-peer on your own network. It does not traverse a relay — ours or anyone else’s — so there is no journey to a data centre and back for every frame.
- Finding the headsets is automatic and quick. The Hub sweeps its own subnet — roughly 2,285 addresses in about 9 seconds, repeating every 45 seconds — so a headset that comes online is listed within a sweep rather than after somebody types an address.
- Nothing has to be plugged in or unplugged. No capture hardware sits in the path to add its own delay.
- An offline network does not slow it down, because casting never used your internet connection in the first place.
The one honest exception: at the start of a cast the two devices exchange a short list of
their own network addresses, and that step asks a public address-discovery server
(stun.l.google.com:19302) what it sees. No video, and nothing about a session,
crosses it. The detail — including the fact that we deliberately do not run a media relay —
is on the Network & security page.
Casting a Pico headset
A Pico headset casts through the same Hub, in the same four steps, with the same application. There is no separate Pico build to install and no second flow to learn.
Pico is also the configuration to specify if your site has to work with no internet access at all. Our software needs no route out on either device; what differs is the platform underneath — see the Quest note below.
Casting a Meta Quest headset
Identical steps, identical application. The difference is not ours: a Quest fleet enrolled in Meta’s managed services carries Meta’s own network requirements for enrolment, device updates and the store, and those apply whoever wrote the application on the headset. Our features run on a closed network; Meta’s platform functions do not. The exact hostnames are listed on the Network & security page.
When the picture does not appear
| What you see | What to check |
|---|---|
| The headset is not in the list | Both devices on the same network, and that network allowing devices to reach each other. Guest and public WiFi profiles usually isolate clients from one another, which blocks every device-to-device product, not only this one. The Hub connects out to headsets on TCP 5259; it never needs a route in from outside. Discovery repeats every 45 seconds, so give it a sweep before assuming the worst. |
| The prompt appears every time | That is the platform, not a fault — see the step above. Provisioned shared devices can be set up so it is granted once. |
| The picture is grey, or froze | The Hub watches for a cast that has stopped producing frames and rebuilds it without being asked. If several rebuilds in a row do not recover it, the Hub stops retrying and says so rather than flickering — stop the cast and start it again, and if it keeps happening, tell us. |
| Someone else already has it | A headset casts to one Hub at a time, deliberately: two instructors silently fighting over one headset is worse than being told. The Hub shows who holds it and offers to take it over. |
| Nothing happens at all | Check the headset is awake and the Minerva application is the one running on it. A headset that has gone to sleep reconnects when it wakes. |
Where the picture goes
Nowhere except your own network. The cast picture is peer-to-peer between the headset and the computer showing it. It is not recorded by us, not uploaded, and not routed through anything of ours on the way.
The two pages that answer this properly are Network & security, written for the person who has to approve it, and Privacy, for what this website itself collects. Other common questions are answered on the FAQ.
Still stuck?
Write to contact@minervaxr.com and say what you saw. It reaches the people who build Minerva, not a ticket queue.
← Back to minervaxr.com