Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

South Gym Control Plan

Goals

  • Provide a fully AMX-controlled multi-purpose room
  • Keep day-to-day operation simple for volunteers via presets

Requirements

  • Single, simple control interface for volunteers
  • Presets for common scenarios (e.g., “School Gym,” “Wedding,” “Youth Night,” “Dinner Event,” “Presentation”)
  • Power on/off sequencing to protect equipment

Considerations

  • The control interface is an AMX MXD-1000-P 10.1“ Modero X wall-mount touch panel — the same model used successfully in previous installations. See equipment reference.
  • AMX is the primary controller: AMX manages the BLU-100 processors directly – recalling presets, adjusting volume, and selecting inputs (see equipment reference). Day-to-day operation is handled through AMX presets on a touch panel (e.g., “School Gym,” “Wedding,” “Youth Night,” “Dinner Event”).
  • M32R override: When the M32R is in use for a complex event, AMX switches the BLU-100 routing to pass through the M32R output to the amps (see audio plan for details). The M32R operator manages the mix; AMX handles the system-level routing.
  • Presets are a starting point: After recalling a preset, operators can adjust individual parameters (volume, lighting level, etc.) from the touch panel. Adjustments are temporary and reset on the next preset recall. On the Paradigm side, individual zone levels can be overridden via PSAP after a preset recall.
  • No time-based scheduling: There is no current requirement for scheduled preset transitions. The NX-4200 already uses NTP, so the capability exists if needed later.

Why use the existing facility AMX processor? The facility’s AMX NX-4200 (FG2106-04) can control the South Gym over the network via the fiber uplink, avoiding a dedicated processor purchase and keeping all AMX programming centralized. The NX-4200 has a 1600 MIPS processor, 1 GB RAM, and 8 GB storage – designed for large campus-scale installations with dozens of rooms. The South Gym’s ~8 IP devices is a trivial load relative to its capacity. Its LAN port connects to the facility network, giving it IP access to all South Gym devices (BLU-100s, SVSi, RLNK, VX4S, N4321) through the M4250 switch. See equipment reference for full specs.

Serial device limitation: The NX-4200’s 8 physical serial ports are in the IT room, not the South Gym. The ETC Paradigm ACP requires RS-232, so an AMX EXB-COM2 (FG2100-22) ICSLan serial expansion module will be placed in the South Gym rack on VLAN 21. The NX-4200 reaches it over the network — this is a proven approach used in other facility installations. The serial link runs at 9600 baud, 8N1, no handshake. The Paradigm uses the Paradigm Station Access Protocol (PSAP) – CR-terminated ASCII commands for preset recall, zone override, and status queries. Unlike the DFD 2322DMX, the Paradigm does not have a built-in heartbeat; AMX must implement a poll-based watchdog (periodic PSAP status queries) to detect a dead serial link. A single RS-232 connection on EXB-COM2 port 1 controls both the gymnasium layer (sACN to Response 0-10V Gateway) and event layer (DMX512 to SmartPacks). See equipment reference.

AMX Responsibilities

SystemAMX Role
Audio (BLU-100)Preset recall, volume, input selection via IP (HiQnet London Architect protocol)
Audio (M32R)Signal path switching between BLU-100 and M32R modes
VideoSVSi routing, projector power, motorized screen raise/lower (dry contact)
LightingScene recall via ETC Paradigm ACP (RS-232, PSAP protocol) for both layers. The Paradigm controls gymnasium fixtures (sACN to Response 0-10V Gateway) and event fixtures (DMX512 to SmartPacks) from a single unit. Presets are configured via ETC LightDesigner and stored in the Paradigm’s non-volatile memory. AMX recalls presets and overrides zones via PSAP commands on EXB-COM2 port 1. Button stations provide independent gymnasium control. See equipment reference.
Audio (N4321)Stream subscription control via TCP port 50002 (switchable by preset or tunable)
MonitoringPoll device status (SVSi encoder/decoder signal, VX4S) and display on touch panel

Device-specific integration notes:

  • ClickShare: AMX does not directly control the ClickShare unit. It constantly outputs to its SVSi encoder when powered on. AMX’s role is limited to RLNK power sequencing and SVSi routing — the user selects ClickShare as a video source from the touch panel to route it to the projector or LED wall.
  • LP10 (AirPlay/Bluetooth receiver): AMX does not directly control the LP10. It is user-operated (AirPlay/Bluetooth). AMX’s role is limited to RLNK power and BLU-100 input routing — the user selects the LP10 as an audio source from the touch panel to unmute it on the BLU-100.
  • Audio source selection: AMX allows the operator to select which audio source(s) are active from the touch panel. Multiple sources can be mixed simultaneously (e.g., wireless mics + LP10), but AMX enforces sensible restrictions (e.g., wireless mics and M32R cannot be active at the same time, since the M32R has its own mic inputs).

Device Status Monitoring

AMX polls key devices and displays their status on the touch panel. This gives operators visibility into system health without needing to check individual devices.

  • SVSi encoders: Source connected / no source (complements the HostPlay on-screen message)
  • SVSi decoders: Stream subscription active / stream not found on network
  • VX4S (long-term): Online / offline, brightness level
  • ETC Paradigm ACP: Poll-based watchdog via periodic PSAP status queries (the Paradigm does not have a built-in heartbeat like the DFD 2322DMX). AMX sends a status query at a regular interval and flags a fault if no response is received within the timeout window.
  • RLNK: Not monitored — the RLNK units in use don’t support overcurrent protection or external status polling.

This is a programming task – no additional hardware required. The SVSi API already supports status queries, and the VX4S responds to TCP polling on port 5200. Back-end device health monitoring is handled by existing facility infrastructure: Prometheus via SNMP for switch statistics and Uptime Kuma for device ping monitoring. AMX touch panel monitoring is limited to operator-facing status (SVSi and VX4S).

Error handling: The current facility behavior for command failures is silent failure. Improved error handling (retry logic, touch panel alerts) would be desirable but is limited by the NX controller’s programming capabilities. AMX’s newer Muse controller platform would simplify this, but it is not in scope for this project.

Failure & Fallback

The AMX processor and fiber uplink are a known single point of failure. If either fails, the touch panel becomes non-functional and devices hold their last state. A Raspberry Pi in the South Gym rack running Bitfocus Companion provides a fallback web UI capable of controlling all room gear independently of AMX. WiFi would be down if the fiber link fails, but a laptop can be plugged directly into the local M4250 switch to access Companion.

Component failure impact:

  • Primary BLU-100 failure: All audio processing is lost — no audio works. The second BLU-100 is for additional I/O only; if it fails, only the I/O routed through it is lost.
  • BLU-100 communication loss: The BLU-100 holds its last received settings.
  • M4250 switch failure: Audio continues to work (BLU-100 holds last settings, analog paths unaffected), but SVSi-routed audio/video is lost. RLNK units retain their last state but can’t be further controlled. The touch panel loses power (PoE). The Paradigm ACP holds both its last sACN and DMX output; the Response 0-10V Gateway also holds its last received sACN values (both lighting layers hold state). Button stations continue working independently of the network. Event presets are available from a button station if configured.
  • Paradigm ACP (lighting): Stores presets in non-volatile memory. Gymnasium layer: button stations outside the rack closet work independently of AMX and the network. Event layer: presets can be recalled from button stations if event presets are assigned to a station.

Future: Auditorium Feed Routing

The infrastructure supports routing audio and video from the Auditorium to the South Gym via AMX/SVSi if overflow capability is needed in the future. This is not a near-term requirement.

Open Questions

Preset Design

Deferred until the equipment list and usage needs are finalized.

  • Can a complete preset-by-subsystem matrix be defined? For each named preset (“School Gym,” “Wedding,” “Youth Night,” “Dinner Event,” “Presentation,” “Cleanup,” “Off”), what is the expected state of: audio (BLU-100 routing, volume, input), video (source, projector power, screen position), lighting (DMX scene), and power (which RLNK outlets are on)? Currently no single document maps a preset name to its complete multi-subsystem behavior. The preset names in control.md (5 names) do not match lighting.md (6 names – adds “Cleanup” and “Off,” omits “Presentation”).
  • How many presets will be stored in the BLU-100s, and what parameters does each preset control (input routing matrix, EQ, levels, limiter thresholds, zone assignments)? Are presets recalled as monolithic snapshots, or can individual parameters be adjusted independently (e.g., volume up/down within a preset)? Either zero or two — possibly one for standalone operation and one for M32R integration, or a single fixed setup with no presets at all. TBD.

Power Sequencing

  • What is the exact power-on and power-off sequence for the 9 RLNK outlets, and what are the inter-step delays? rack.md documents the outlet allocation but has no sequencing column.
  • Since the amps are on dedicated circuits (not RLNK), how are they powered on and off? Are they left permanently energized? If so, is that acceptable from a power and equipment longevity perspective? If they need to be switched, what mechanism is used (manual breaker, a second RLNK or relay, a smart outlet)? Currently control.md does not mention the amps and rack.md has no mechanism to control their power.
  • What does “system off” mean operationally? (a) All RLNK outlets off, amps left on dedicated circuits, lights off via DMX, projector off, screen raised? (b) Everything fully de-energized including amps (requiring someone to throw breakers)? (c) A “standby” state where infrastructure stays powered and only output devices are off?
  • Does the rack PC (Mac mini) need a graceful shutdown signal before RLNK power is removed? If so, does AMX send a network shutdown command (e.g., SSH) before killing power on outlet 7? (rack.md flags this as an open question.)

Subsystem Sequencing & Coordination

Deferred until the equipment list and usage needs are finalized.

  • When a user taps a preset on the touch panel, in what order does AMX issue commands to subsystems? For example: (1) lighting fades to scene, (2) audio switches to preset, (3) projector powers on, (4) screen lowers. Are there timing dependencies (e.g., lighting must reach dimmed state before projector image is visible)? (lighting.md explicitly flags this as unanswered.)
  • When AMX switches the BLU-100 routing from base mode to M32R passthrough, what is the exact BLU-100 command or preset recall? Is there a confirmation/feedback mechanism so AMX knows the switch completed successfully? What is displayed on the touch panel during and after the switch?
  • Can the system transition from M32R mode back to base mode (or vice versa) during an event without an audible interruption? audio.md asks whether there is a crossfade or mute during MUX transitions – what is the defined behavior?
  • How does AMX know the M32R is connected and ready? Is there a network presence check (M32R IP appears on the VLAN), a manual “M32R Mode” button on the touch panel, or automatic detection? What happens if an operator enables M32R mode but the M32R is not physically connected?
  • When the “Presentation” preset is recalled, what is the default video source (rack PC, ClickShare, or wall plate encoder)? video.md states “Presets default to the rack PC.” But for presentations, a guest may expect ClickShare. Does the system support split audio/video sourcing (e.g., AirPlay audio via LP10 + ClickShare video)?

Video & Projector Control

  • The VX4S defaults are documented as “all settings persist except brightness, which AMX should restore on every startup” (video.md). What is the target brightness value? Does it vary by preset? To be decided after LED wall installation. The VX4S can store a default power-on brightness persistently, so AMX restoration may not be needed.
  • What are the exact RS-232 command strings for projector power on, power off, and status query (stored in the SVSi decoder via sendser)? The projector make/model is unknown (video.md open question), so the serial protocol is also unknown. The programmer is blocked until this is resolved.
  • What is the physical relay device for the motorized screen dry contact? video.md lists two options (AMX REL8 via low-voltage wire, or Global Cache IP2CC-P via PoE Ethernet) but the decision is not made. Neither option appears in the networking port table, rack layout, or electrical plan. TBD — trade-offs to both approaches.

Touch Panel & User Experience

Deferred until the equipment list and usage needs are finalized.

  • Where will the touch panel(s) be mounted? Near the main entrance? Near the stage/front area? Near the rack closet? Multiple locations?
  • What pages/screens will the touch panel display? A minimum: (a) home page with preset buttons, (b) volume adjustment, (c) source selection, (d) status/diagnostics. Is that sufficient, or do stakeholders need more granular control (individual zone levels, individual lighting zones, per-device power)?
  • What volume control is exposed on the touch panel? Single master volume for the entire room, per-zone volume, or per-source volume? What are the minimum and maximum bounds?
  • Can a step-by-step operator workflow be documented for each event type? (e.g., Wedding: arrive 2 hours early, tap “Wedding,” connect M32R via umbilical, tap “M32R Mode,” sound check, etc.) The control plan defines what the system can do but not how operators use it.
  • Is there a requirement for printed or laminated quick-reference guides near the touch panel? Who is responsible for ongoing volunteer training as volunteers rotate?

Device Status Monitoring

  • For SVSi status, how is it displayed on the touch panel? Simple green/red indicator, or device name + specific error? What is the polling interval? What happens if polling itself fails? Deferred until touch panel UI design.

Failure & Fallback

  • Should a button station near the gymnasium entrance include event layer preset buttons (e.g., “Wedding,” “Dinner Event”) for non-technical fallback when AMX is unavailable?

Scheduling & Automation

  • Is there a requirement for auto-off after inactivity (occupancy sensing)? Almost certainly not, but to be confirmed.

Commissioning & Maintenance

Deferred until the equipment list and usage needs are finalized.

  • Is there a defined commissioning protocol for the control system? What constitutes “working” for each preset? Who signs off on acceptance? (e.g., “recall Wedding preset, verify lighting dims to target level within 5 seconds, verify audio preset is active, verify projector is on and screen is down.”)
  • Can the AMX programmer access the system remotely for diagnostics and updates? Is there VPN or remote access to the AMX processor, BLU-100s, or M4250? If so, is this documented and secured?
  • Who is responsible for firmware updates on each networked device (BLU-100, SVSi, M4250, RLNK, VX4S, ClickShare, LP10, Mac mini)? Is there a maintenance window policy?
  • Is there a manual workaround for routing the auditorium overflow feed without AMX involvement (e.g., manually subscribing the SVSi decoder to ross-01 via the SVSi web interface), given that the infrastructure is being installed now but overflow programming is deferred?