What is Harp
Harp is a standard for asynchronous real-time data acquisition and experimental control in neuroscience. It includes specifications for a lightweight and versatile binary communication protocol, a set of common registers for microcontroller firmware, and a clock synchronization protocol.
Commands and events processed by all Harp devices are hardware timestamped and streamed back to the host computer over USB with a one millisecond latency. The stateless and symmetric communication protocol allows temporally accurate logging while avoiding the need for fixed sampling rates and redundant processing. Harp devices can be connected to a shared clock line and continuously self-synchronise their clocks to a precision of tens of microseconds. This means that all experimental events are timestamped on the same clock and no post-hoc alignment of timing is necessary.
The Harp ecosystem currently includes devices to configure, control, and collect data from a wide range of peripheral devices such as cameras, LEDs, nosepokes, and motors. Combining Harp devices is an easy way to extend experimental setup functionality with integrated timestamp synchronisation across devices.
Why Harp was developed
Time is a critical variable in systems neuroscience experiments. As setups increase in complexity, temporally aligning multiple datastreams acquired from different devices rapidly becomes more difficult. Exploring how neural circuit activity relates to animal behaviour requires precise timestamping of experimental events, so that neural and behavioural data can be accurately ordered in time.
Harp is being developed as a cross-institutional collaboration to develop an ecosystem of high-performance devices that make it easy for scientists to synchronize and extend the functionality of their setups. Harp devices should be able to configure, control, and track a wide range of peripheral devices such as cameras, LEDs, nosepokes, and motors. Connecting an extra Harp device to add functionality to a setup should be straightforward and place no extra burden on researchers.
From an engineering perspective, we also want to accelerate the development process of extending the functionality of a setup, and make it easier to develop new devices, deciding how these devices communicate a computer, and how researchers interact with the device. By agreeing beforehand how the entire ecosystem works together, from signal acquisition to analysis, we can support engineers not having to reinvent or attune protocols each time they wish to develop a new device. This leads to faster, cheaper, and more robust development of scientific tools.