In a well-designed school network, you should see roughly 50–120 ms end‑to‑end mirroring latency in real classrooms, with sessions often sitting under 100 ms when Wi‑Fi is strong and packet loss is near zero. ���˶��� Central flags RTT under 20 ms as “good,” 20–100 ms “average,” and over 100 ms “poor,” which tracks to how smooth mirroring feels on screen.

By default, no—students can’t put content on the display without teacher approval.

Here's how it works:

Students connect and can use learning tools in the app, but must request control to present. The teacher then sees the request as well as a preview of the student's screen and can then approve, deny, or simply select a student from the connected list to approve sharing.

If you need guest presenters, teachers can generate time‑boxed guest codes so visitors can present without broadening student permissions.

Yes. When an authorized user triggers an emergency, ���˶��� takes over every connected display in the selected scope within seconds and holds the alert on screen until it’s cleared. Admins can choose the type and location for the alerts and, once confirm, broadcast to all ���˶��� boxes in that area. Wardens can also get email/SMS with details for coordination.

���˶��� Emergency Alerts can be triggered from the ���˶��� app or ���˶��� Central.

Yes. ���˶��� integrates via API with leading safety/mass-notification platforms so alerts triggered there can automatically display on all connected screens.

Yes. From ���˶��� Central you can update, schedule, and target signage to any rooms or destinations across the district in real time, remotely. You can upload media or links to the Media library, build playlists, then use the Signage wizard to schedule, set precedence/priority, and push changes instantly or on a timetable. You can even toggle schedules on/off and edit them later from the central dashboard.

Users have two deployment options:

���˶��� Display Box (hardware receiver): This option requires one ���˶��� box per display, connected via HDMI and to your network (PoE or included power), and works with any HDMI projector/TV and non-compatible panels.

���˶��� Display App (software-only on supported panels): This option requires no extra hardware on most Android-based IFPs and many Promethean ActivPanels.

If a panel isn’t compatible, you can use the ���˶��� Display Box instead.

���˶��� works with essentially any HDMI display or projector and most modern IFPs.

Users have two clean paths:

HDMI projectors/TVs: Pair with a ���˶��� display box and you’re set. We see great results with Epson classroom projectors and standard flat‑panel TVs; ���˶��� gives you wireless casting, signage, and alerts on all of them.

Android-based IFPs: Many panels can run the ���˶��� Display App software‑only, including Promethean models. If a panel isn’t compatible, you can use the ���˶��� box instead.

Users have two easy paths for firmware updates:

Cloud scheduled updates: If your ���˶��� boxes are on firmware 3.4.0 or later, you can schedule updates from ���˶��� Central to run after hours or on weekends. Simply pick the target version, set a window of at least four hours, and apply it to one or many devices. Boxes must be online during the window to take it. You can set different windows per room and cancel or overwrite a schedule if needed.

Manual update: For a single box or one that’s off-network, you can upload the firmware file via the device’s web console.

If you’re on ���˶���’s subscription, replacement is covered. Our pricing is per classroom and includes the hardware, software, updates, support, training, and warranty, so you don’t buy a new unit out of pocket when one fails under warranty.

���˶���'s hardware lifespan is between 5 and 7 years in service for a ���˶��� box in typical K‑12 use, aligned to normal classroom display refresh cycles.

Standard manufacturer warranty applies; extended coverage and hardware refresh options are available as part of multi‑year agreements.

Guests and unmanaged devices can present without being on your domain.

Guest Wi-Fi + Guest Codes: Users can place visitors on their guest SSID, open the required ���˶��� ports to the ���˶��� receivers, and have the teacher generate a time-boxed Guest Code for that room. The guest logs into the ���˶��� app as “Guest,” enters the code, and can present for the allowed window. Admins may also precreate longer, multi-room guest access in ���˶��� Central.

Domain BYOD: Student or personal devices can authenticate normally (Google/Microsoft/SAML if enabled), while student permissions remain restricted—requiring them to request control and prompting teachers to approve in-room.

Key requirement: Guests must be able to reach ���˶��� receivers over the LAN from the guest VLAN/SSID according to your firewall rules. If the guest network is fully isolated, allow-listing for the ���˶��� subnets and discovery/streaming ports is required.

Screen-mirroring traffic stays on your local network. Devices stream directly to the ���˶��� receiver over LAN/VLAN and it does not hairpin through the internet. Internet is only needed for cloud features like authentication, signage sync, and emergencies – not for the actual casting path.

���˶��� keeps data collection minimal and purpose‑bound.

Here's what’s collected:

Account basics: name, email/SSO identifier, role (teacher, student, admin).

Device/app info: OS, app version, device type, ���˶��� device IDs.

Usage/telemetry: session starts/stops, feature usage, basic performance stats (e.g., latency, bitrate) to help support and improve reliability.

Optional classroom artifacts: if a teacher uses tools like Screenshot/Annotation or feedback features, those items are tied to the teacher’s account/room as part of the product’s functionality.

Here's what’s not collected:

No screen content is stored from normal mirroring sessions.

No student personal content is mined or sold to third parties.

How it’s stored/used:

Data is encrypted in transit and stored in secure cloud services with role‑based access. It's used for core functions (authentication, room control, signage/alerts) and aggregated analytics to help IT see adoption and troubleshoot.

Data retention follows operational needs and admin policy and districts can request export or deletion of organization data.

���˶��� slots into typical K‑12 network designs cleanly.

VLANs and subnets: Devices and users can live on separate VLANs. ���˶��� publishes the few ports/flows to allow, and it works across L3 with the right ACLs strategy. ���˶��� shares the network requirements doc before your tech setup call so you can pre-stage rules and tests.

Guest networks: Guests use the web app or lightweight client on your guest SSID. They do not need to be on the same subnet as receivers as long as the required outbound to ���˶��� cloud is open and your ACLs permit the discovery/control flow to the target rooms.

Security zones and egress: Receivers need outbound HTTPS to ���˶��� services. Best practice is a wildcard allow for *.vivi.io, with explicit fallbacks for api.vivi.io, storage.vivi.io, and downloads.vivi.io. Some proxies also require *.vivi-box.io. Avoid IP pinning since addresses can change. Application-layer allows are needed beyond generic 80/443.

Wired vs Wi‑Fi: Receivers can be hardwired or on Wi‑Fi, though most districts prefer wired on the AV VLAN and keep teacher/student devices on their existing SSIDs with QoS favoring 5 GHz where possible.

Student data privacy: ���˶��� is designed to be privacy-compliant. All transmissions are encrypted in transit.

Security recognition: ���˶��� has earned the Safer Technologies 4 Schools (ST4S) Product Badge, which assesses security, privacy, functionality, online safety, and integrations for K–12.

Enterprise posture: The platform and receiver are built to enterprise security standards, with secure firmware/software update practices.

���˶��� is very scalable for district-wide deployment.

���˶��� was built for district-wide scale: one receiver per display, all managed from a cloud admin console with SSO, room/location grouping, targeting, and analytics. Bulk tools handle firmware, configs, and power/display settings, so a small IT team can roll out and maintain hundreds to thousands of rooms with ease.

Analytics within ���˶��� Central fall into two categories: usage analytics and network/device health.

For usage and adoption: Activity and usage snapshots by location and room, stream/session counts, duration, platform/streaming method, who initiated sessions, and time/date per stream. You can drill from location to room to individual sessions to see how teaching use trends over time.

For performance and uptime: Network Stats with quality score, round‑trip time (RTT), packet loss, and unexpected disconnections, filterable by time range, location, and connection type. You can pivot into Wi‑Fi stats per device for signal, noise, SNR, and TX rate history to diagnose issues that affect uptime and stability.

Yes. ���˶��� Central gives IT a single, cloud dashboard to monitor device status across all schools in your organization, including online/offline counts, firmware versions, and usage snapshots. You can drill into locations, rooms, and individual boxes, push updates, and troubleshoot remotely.

���˶��� makes training easy and free.

For teachers: Leveled, self-paced courses with short videos, live webinars, and recordings are available.

For tech staff: Admin-focused courses are available on setup, ���˶��� Central, signage, announcements/emergency tools, troubleshooting, and organization customization. Plus, users have access to tutorial libraries, printable quick guides, and Vimeo/YouTube video playlists.

A dedicated Teacher Guide, digital signage training, and optional professional development sessions are also available.

Most districts land in the 6–10 week window from PO to full adoption.

Here's what to expect:

Hardware rollout: about 1–2 hours per 20 classrooms, once units arrive.

Program timeline: enterprise implementations typically run 50–70 days end to end, including kickoff, initial setup, rostering/SSO, and teacher enablement.

Actual timelines may vary depending on shipping/receiving needs, network changes (VLANs, DNS, certificates), SSO/MDM packaging, and training cadence.

���˶��� customers have two official support channels: tickets via ���˶��� Central and phone for high‑severity issues.

Here’s how it works:

Ticketing: IT admins open incidents in ���˶��� Central’s Support section. You’ll get email threads, status updates, and escalation to engineering as needed. SLAs run on business hours by region, with time to first response and time to resolution tracked per priority.

Phone: for P1/P2 only, IT admins can call:

Americas: +1 800 265 1560

APAC: +61 1300 920 555

EMEA: +44 (0) 800 014 8997

Teachers and students route issues to district IT. ���˶��� Support assists IT admins directly.

���˶���'s pricing is straightforward and all‑inclusive.

Our model is an annual subscription per classroom/display. Hardware receiver, software, support, updates, training, warranty, and the cloud admin console are included in one price. New features and firmware to our core solution ship under the subscription, so you don’t rebuy hardware to get capabilities. Multi‑year terms lock pricing and simplify renewals.

Support/training is included, so no add‑on maintenance contract is required.

Yes, you can! If you’re just exploring, we offer pilots at no cost and with no commitment. You can try all the features in your own environment before making any decisions.

���˶��� strengthens site-wide emergency communication by delivering instant, full-screen visual alerts across staff devices and classroom displays. This ensures clear, consistent instructions during evacuation, invacuation and lockdown scenarios.

To learn more about what Martyn’s Law means for schools and colleges, click here.

Yes. ���˶��� allows schools to create and save customised emergency alert templates in advance for key scenarios required under Martyn’s Law, including evacuation, invacuation and lockdown.

When an incident occurs, authorised users can select the appropriate alert type and broadcast it instantly across the entire site. Wardens can also receive supporting notifications via email or SMS to aid coordination.

Alerts can be triggered by authorised users from multiple locations, helping to reduce reliance on a single individual or device.

Emergency alerts can be displayed on:

Front of class displays: TVs, projectors and interactive flat panels via the ���˶��� Display Box or ���˶��� Display App.

Staff devices: Mac, Windows desktops and laptops and Chromebooks through ���˶��� Device Alerts.

This allows schools to transform existing technology into a comprehensive, site-wide communication system and helps prepare for Martyn’s Law.