↗

NeuroNexus · neuronexus.com ↗ · Resources ↗

Radiens System Requirements#

Radiens sizing follows one number: how much data per second you are writing and processing. Channel count times sampling rate sets the throughput, and throughput sets the CPU, memory and storage you need. Everything below is that relationship, made concrete.

Research use only. NeuroNexus products and the procedures described here are for non-clinical research use, and must not be used in human or veterinary medical procedures.

Up to 64 channels#

At this scale a current laptop is adequate. Expect live spike detection and signal-quality monitoring, sessions of one to four hours, and post-hoc analysis without waiting.

256 channels and above#

At this scale expect live spike sorting, sessions beyond eight hours, simultaneous multi-probe recording, and browser-based monitoring through Radiens Web.

The NeuroNexus workstation#

NeuroNexus supplies a pre-configured workstation for high-channel-count work, tested against NeuroNexus acquisition hardware and shipped with Radiens configured.

The argument for it is not the parts list. It is that the configuration has been run against the DAQ hardware you are buying, so the first day is spent recording rather than diagnosing.

Sizing your own system#

CPU#

Cores track channel count:

≤ 64 channels    → 4+ cores
65–128 channels  → 6+ cores
129–256 channels → 8+ cores
257+ channels    → 12+ cores

Balance cores against clock speed. Live sorting uses the cores; interface responsiveness uses the clock. Verify ARM compatibility before purchase if you are considering an ARM system other than Apple Silicon.

Memory#

Session length does not size RAM. Radiens reads a recording from disk rather than loading it into memory, so a long session is bounded by storage rather than by RAM. Size memory from the channel count and what you run live — sorting and real-time metrics are what consume it:

≤ 64 channels     → 16 GB
65–256 channels   → 32 GB
257+ channels     → 64 GB or more

Use dual-channel or better. ECC is worth it where a session cannot be repeated.

What a session actually writes#

This is the number that sizes storage, and it is worth doing before the probes are ordered:

bytes = channels × sampling rate × 2 bytes × seconds

 64 ch @ 30 kHz, 4 h  →   3.8 MB/s  ≈    55 GB
256 ch @ 30 kHz, 4 h  →  15.4 MB/s  ≈   221 GB
512 ch @ 30 kHz, 8 h  →  30.7 MB/s  ≈   885 GB
1,024 ch @ 20 kHz, 8 h → 41.0 MB/s  ≈  1.18 TB

At 16-bit stored width. A dense cohort is a storage project: ten animals at 1,024 channels for two hours each is about 3 TB before anything has been analyzed.

Storage#

Two roles, and they have different requirements.

System and software. NVMe SSD, 500 GB minimum and 1 TB comfortable, at 3,000 MB/s or better.

Recording data. Sustained sequential write is the requirement — a drive that benchmarks well on bursts can still drop samples on a two-hour recording. Keep active datasets on fast local storage and move completed sessions to network storage.

Back up before you analyze. A recording exists once until it is copied.

Graphics#

4 GB VRAM is the floor and 8 GB is comfortable for dense heatmaps and 3-D views. Verify driver compatibility rather than assuming it; a professional card with a stable driver outperforms a faster card with an unstable one.

Operating systems#

Apple Silicon is natively supported. CentOS and RHEL work; for other distributions, confirm with support before you commit.

Two configuration items matter on any platform: exclude your data directories from filesystem indexing and antivirus scanning, and set the machine to a sustained-performance power profile. Both cause dropped samples when left at their defaults.

Network#

Gigabit Ethernet is the floor for multi-user installations; 10 Gigabit is worth it where recordings move across the network routinely. For browser access and cluster jobs, 100 Mbps of internet bandwidth is sufficient — your recordings do not leave your storage, so the bandwidth carries views and summaries, not data.

When performance falls short#

Dropped samples are almost always storage write throughput or an indexing service, not CPU.

Interface lag during recording is CPU contention. Check what else is running.

Slow post-hoc analysis is usually memory: the dataset no longer fits and the system is paging.

Visualization lag is the GPU or its driver.

Diagnose in that order. Each has a different fix, and upgrading the wrong component is the common outcome of guessing.

Support#

Specification review before purchase, installation, and configuration tuning are all available.

• support@neuronexus.com · +1.734.913.8858

Related documentation#

• Welcome to Radiens
• Choose the Right Radiens Package
• Introduction to Radiens Flyer
• X-Series XDAQ System