Minerva.

Ray Lab at Baylor College of Medicine runs cardiorespiratory experiments on neonate subjects using robotic rigs. The rigs produce continuous physiological signals (ECG, respiratory flow, pneumotachograph) at 1,000 Hz. Before Minerva, the lab had no unified interface for monitoring these signals in real time across multiple rigs during an active experiment.

Russell was brought in to design and build the monitoring platform from the ground up. The engagement is ongoing.

The problem

Lab experiments run in defined stages: baseline, challenge, recovery. Each stage generates a torrent of sensor data across multiple channels. Researchers need to see that data live, respond to it mid-experiment, and trust that what they're seeing is current. Lag is a research problem, not just a UX one.

The constraints were specific:

• Multiple rigs, each identified by MAC address, streaming independently
• Signals arriving at ~1,000 Hz, far too dense to push raw to a browser
• Researchers need to configure their own view layouts, not use a fixed dashboard
• The platform runs on hardware inside the lab, no cloud dependency, SSL required for browser camera access
• CI/CD pipeline so lab staff can pull updates without a developer on-site

Minerva is research infrastructure, not a commercial product. The case study describes the architecture and engineering approach without disclosing unpublished research data or experimental protocols.

What was built

Minerva is a full-stack web application running entirely on lab-owned hardware. The frontend is a configurable real-time dashboard. The backend brokers WebSocket streams from each rig's Python control system to connected browsers. Every deployment goes through a Jenkins pipeline.

Real-time signal streaming

Each rig runs a Python Peripheral Control Computer (PCC) that reads raw sensor data and publishes to a RabbitMQ queue every ~100ms. The Minerva API relays those messages over WebSocket to connected browser clients. Server-side downsampling reduces each signal from ~5,000 points to ~200 before transmission, preserving waveform fidelity while eliminating the bandwidth that would make the dashboard unusable.

Signal types supported: continuous waveforms (time_series), event markers overlaid on waveforms (timestamp), scalar metrics (single_value), boolean status indicators, duration timers with severity levels, and free-form debug strings. The payload schema is documented and versioned so the Python side and the React side can evolve independently.

Layout manager

Researchers don't all want the same view. Minerva's layout manager lets each user build a named configuration: which signals appear, where, and at what scale. Layouts are stored in PostgreSQL and restored across sessions. Y-axis scaling is per-signal, configurable through a side panel, and persisted so a researcher's tuned view survives a browser refresh.

Reference lines (static threshold markers defined in the Python config) are sent as part of the signal payload and rendered as labeled horizontal overlays on the corresponding chart. Researchers can see where detection thresholds sit relative to live data without context-switching to a config file.

Experiment control

Minerva includes a command palette for sending instructions to the rig (start experiment, advance stage, stream, stop). Commands that are destructive require explicit confirmation; non-destructive commands can be configured to execute immediately. Researchers also requested shortcut buttons, pre-configured one-click commands embeddable directly in the monitor layout, so common adjustments don't require navigating the palette mid-experiment.

Infrastructure

Engineering decisions worth noting

RedwoodJS over a custom stack. The lab doesn't employ software engineers full-time. RedwoodJS provides a full-stack framework with GraphQL, Prisma, and a React frontend in a single coherent repo, reducing the surface area of things that can drift out of sync. The tradeoff is framework opinion; the payoff is maintainability when the primary developer isn't on-site.

Server-side downsampling. Pushing 1,000 Hz raw to a browser isn't viable. Downsampling in the Python PCC before the message hits RabbitMQ keeps the browser fast without lossy compression in the front end. Target point counts are configurable per signal in the Python config, so the lab can tune the tradeoff between fidelity and stream latency as experiments evolve.

Local deployment over cloud. All compute stays on hardware inside the lab. No data leaves the building, no cloud bill, no dependency on an external provider's uptime during an active experiment. The Jenkins pipeline handles updates without requiring a developer physically present; the lab runs ./deploy.sh.

WebSocket reconnection. Network conditions in the lab are imperfect; WiFi-connected devices occasionally drop. A stale-closure bug in the early WebSocket reconnection logic caused connect/close cascades under intermittent connectivity. The fix was committed and verified under real lab conditions, not just local dev.

Status

Minerva is running in production in the lab. Active features include real-time multi-signal streaming, the layout manager, Y-axis scaling, reference line overlays, and the command palette. Ongoing work includes shortcut button layouts, conditional highlighting rules for signal boxes, and continued iteration based on researcher feedback gathered in weekly check-in meetings.

This is a long-horizon engagement. Research infrastructure doesn't ship once; it evolves with the science.

R.P.