PyDapsys: an open-source library for accessing electrophysiology data recorded with DAPSYS

Abstract

In the field of neuroscience, a considerable number of commercial data acquisition and processing solutions rely on proprietary formats for data storage. This often leads to data being locked up in formats that are only accessible by using the original software, which may lead to interoperability problems. In fact, even the loss of data access is possible if the software becomes unsupported, changed, or otherwise unavailable. To ensure FAIR data management, strategies should be established to enable long-term, independent, and unified access to data in proprietary formats. In this work, we demonstrate PyDapsys, a solution to gain open access to data that was acquired using the proprietary recording system DAPSYS. PyDapsys enables us to open the recorded files directly in Python and saves them as NIX files, commonly used for open research in the electrophysiology domain. Thus, PyDapsys secures efficient and open access to existing and prospective data. The manuscript demonstrates the complete process of reverse engineering a proprietary electrophysiological format on the example of microneurography data collected for studies on pain and itch signaling in peripheral neural fibers.

Keywords: FAIR; data management tools; electrophysiology; interoperability; microneurography; open data; pain; reverse-engineered.

Figure 1

(A) “ImHex” showing the start of a DAPSYS files’ table of contents section. Shown are the hexadecimal byte-values of the respective address and the interpretation of that byte as characters. Data fields of structures are shown in different colors. The address shown is in relation to the start of the table of contents. (B) Structure of the same file from panel (A) shown by the GUI of DAPSYS.

Figure 2

Simplified logical model of a DAPSYS file. Black arrows show to which other fields the value refers. Large unfilled arrows indicate that an entry extends another one. Gray types define shared header fields for a group of types, with extending arrows indicating the field and the value to identify the group of fields that follow the header (e.g., a “Folder” and a “Stream” both start with the fields of an generic “Entry.” Depending on the value of the field “entry_type,” the fields following the “Entry” will be either those of a “Stream” or a “Folder”).