Overview

Synapse defines a standard protocol and toolbox for controlling neural processing devices. It combines a gRPC-based control plane API with a streaming API called Taps, giving applications a consistent way to configure devices, run processing workflows, inspect their state, and access data.

Synapse separates device implementations from the software used to control them. A Synapse server implements the protocol for a hardware or software processing device, while clients such as the CLI and GUI communicate with any compatible server through the same interface. This separation allows devices and clients to evolve independently without requiring a different control workflow for each implementation.

Synapse organizes data acquisition, processing, storage, and streaming into configurable signal chains. A signal chain connects standard nodes for operations such as acquiring, filtering, processing, or saving data. It can also include custom processing tools built with the Synapse App SDK.

See the Quickstart guide to learn how to control a Synapse device.

Signal Chain

A signal chain is a data-processing pipeline that runs on a Synapse device. It is composed of nodes, which represent operations such as acquiring data from a peripheral, processing data, or recording data.

Nodes can be connected into arbitrary directed acyclic graphs (DAGs), subject to the compatibility and resource restrictions enforced by the Synapse device. A signal chain can be linear, branch one source into multiple processing paths, or combine compatible inputs into a downstream operation. These connections define how data moves through the device from acquisition to processing, streaming, or storage.

See the Node Reference for the available node types, their configuration fields, and the operation each node performs.

Taps

Taps are ports for moving data into, through, and out of a signal chain. Every node has standard input and output Taps that act as connection points between nodes. These connections create linear or branching signal chains with discrete data sources and sinks.

Node output Taps can also stream data over the network to a client such as the GUI, synapsectl, or the Synapse Python client. Taps operate independently, so a client can stream from one or more nodes at the same time.

Data produced by a Tap can be:

• Passed to another node in the signal chain.
• Saved to device storage with a Disk Writer node.
• Streamed to a client computer for visualization, processing, or recording.

Tap streaming uses ZeroMQ and is separate from the gRPC control plane used to configure and control the device.

Peripherals

Peripherals are physical or virtual objects that a Synapse signal chain can read from or write to. Physical peripherals represent connected hardware, while virtual peripherals are software-defined data sources or destinations provided by the Synapse device.

A node binds a peripheral to a signal-chain operation. For example, a Broadband Source node can acquire data from a recording peripheral, while an Optical Stimulation node can send output to a stimulation peripheral. The node defines the operation and its configuration; the peripheral identifies the object that performs the acquisition or output.

See the Peripheral Reference for available peripherals and their supported configuration values.

Peripheral ID assignments are device-defined. See the Product Details for SciFi or SciFi 2.

Apps

Apps are user-written applications that run on a Synapse device as part of a signal chain. They perform custom processing that the standard node types do not provide, such as decoding, inference, or closed-loop control.

An Application node binds a deployed App to a signal-chain operation, in the same way that other nodes bind peripherals. The node names the App to run and can pass it key/value parameters that the App defines. An App receives data from its input connections and can publish its own Taps.

Apps are built and deployed separately from the signal chain, and they start and stop with the chain that contains them.

See the Synapse App SDK to build, deploy, and run one.

Device Lifecycle

The current DeviceState tells you what the device is doing and, more importantly, what you can do next. Read it with Info or from the state indicator in a client.

Choose Your Next Action

Typical Operation

A typical working session with a Synapse device follows the below pattern:

1. Inspect: Read Info and confirm the device is kStopped.
2. Prepare: Configure the nodes and connections that should run. If needed, update device settings while the device is still stopped.
3. Run: Start the saved signal chain. The device enters kRunning.
4. Observe: Read Taps, logs, and status while nodes perform their work.
5. Change or finish: Stop the device before editing its configuration or settings.

Configure temporarily moves the device from kStopped to kInitializing while it validates and constructs the signal chain. It returns to kStopped whether configuration succeeds or fails. Start moves a configured device to kRunning, and Stop returns it to kStopped.

Startup -> kUnknown -> kInitializing

kInitializing -- startup succeeds --> kStopped
kInitializing -- startup fails ----> kError

kStopped -- Configure -------------> kInitializing
kInitializing -- configure completes -> kStopped

kStopped -- Start -----------------> kRunning
kRunning -- Stop ------------------> kStopped

A failed Configure still returns the device to kStopped, allowing you to correct the configuration and try again. A startup failure enters kError instead and requires device recovery or restart.

Lifecycle operations are serialized; they cannot interleave with other lifecycle operation.

Settings

Settings are persistent, user-configurable values defined by each Synapse device, like device name or clock source. Settings are not signal-chain configurations. A signal-chain configuration defines the nodes and edges that process data and is applied separately with Configure.

The Synapse API defines how a device advertises, reads, validates, and updates settings, but it does not prescribe which settings a device must provide or what they do. Each device publishes a schema containing the accepted key, description, value type, default value, and any allowed values. Clients should query this schema instead of assuming that a setting is available. Updates are validated against the device's current schema and applied atomically: if any key or value is invalid, none of the requested changes are applied.

Read the current values and schema with the kGetSettings Query. Write values with UpdateDeviceSettings. The device must be kStopped to update settings.

See the Product Details for the settings currently exposed by SciFi and SciFi 2.

Filesystem

Each Synapse device provides a user-owned filesystem for storing and organizing files. You can interact with this filesystem through the Synapse file API to list, write, read, and delete files.

Some clients use another transport to access the same user-owned filesystem. For example, the GUI and synapsectl use SFTP, or SciFi 2 can expose files over a direct USB connection.

See the Product Details for reserved folders and access methods on SciFi and SciFi 2.

Storage Devices

Storage Devices represent locations to which a Disk Writer node can write data. When configuring a Disk Writer, select the Storage Device that corresponds to the desired physical storage location.

A Storage Device is a destination available to a Disk Writer, while the filesystem is the collection of files and folders that the user can browse and manage.

See the Product Details for the Storage Devices available on SciFi and SciFi 2.