[ENH] microelectrode electrophysiology specification (BEP032) #1705

yarikoptic · 2024-02-14T15:24:13Z

Replaces #1352 submitted from a fork outside of bids-specification.

Add specification for microelectrode electrohpysiology datasets based on the BEP032 proposal. old google doc

Note

We meet regularly and everyone is welcome

Next meeting: insert date on URL to join

Communication channel: https://framalistes.org/sympa/info/neuroscience-data-structure

Tip

To use this WiP schema on sample datasets, see https://deno.land/x/[email protected]#modifying-and-building-a-new-schema on how to use "stock" bids-validator with a custom schema. (attn @TheChymera)

DONEs

TODOs

Issues this PR would likely to address

Fixes run node tests in github actions legacy-validator#1375

Issues to see being addressed while working on this BEP (likely to move above) or not (moved below):

Other issues which relate but not in scope here and provided for reference/backreference

Spreadsheet with correspondence to ProbeInterface: https://docs.google.com/spreadsheets/d/1O0bZzD-n4MjR68r1GlcH3d2JLXBLAU1PfsDceD3IPeo/edit?usp=sharing

… _acq-

src/schema/rules/files/raw/channels.yaml

src/schema/objects/columns.yaml

TheChymera · 2024-03-12T01:33:27Z

Also relevant if you'd like to comment. → https://docs.google.com/document/d/1oG-C8T-dWPqfVzL2W8HO3elWK8NIh2cOCPssRGv23n0/edit?disco=AAABIzHGpUU

TheChymera · 2024-03-12T01:57:39Z

Also I forgot to link to this when I wrote it → https://docs.google.com/document/d/1oG-C8T-dWPqfVzL2W8HO3elWK8NIh2cOCPssRGv23n0/edit?disco=AAABIGPAMOw

src/schema/rules/files/raw/ephys.yaml

…t was missing

src/schema/objects/datatypes.yaml

src/schema/objects/modalities.yaml

src/schema/objects/suffixes.yaml

yarikoptic · 2025-10-15T14:21:03Z

bids:: prefix means the file is inside the current dataset, and probes/neuronexus2.json is the root-relative path to the file.

@effigies so you suggest to establish yet another folder with structured data but which will not be formalized by BIDS in terms of schema/structure under it? or should we strive to come up with some consistent with BIDS overall and/or like e.g. BEP044 approaches to formalize under stimuli/ - https://bids.neuroimaging.io/extensions/beps/bep_044.html and consider making it probes/probe-<label>_probeinterface.json so we

have it explicitely stating to be in probeinterface format
have probe-<label> to be able to say probe_id (probe-<label>) eventually (and <label> here I think matches the "name")

effigies · 2025-10-15T15:00:29Z

@ree-gupta Apologies for the delay. I had unsubscribed so that I would see mentions but not other activity on this PR, so I did not see your response. Please @ me in the future, as I will be doing so again after today.

I had just a small question about how should the probes directory at root be correctly recognized by the schema/validator? Would you suggest adding it to src.schema.objects.files.yaml? like how stimuli directory is specified?

Yes, that or phenotype are the most direct parallels.

@yarikoptic

so you suggest to establish yet another folder with structured data but which will not be formalized by BIDS in terms of schema/structure under it?

The probes are a separate standard with their own contents and file-naming conventions. The intended progression appears to be:

Stick new probe definitions into /probes and refer to them with bids::probes/*.
Upload probes as-is to the global probe namespace.
Replace the bids::probes/ prefix with a full URL prefix.

Given that they already have a BIDS-incompatible naming convention (there are hyphens in the names), it does not seem particularly appealing to me to put an effort to come up with a mapping. Any tool that wants to find the probe definitions is going to need to resolve a URI in any case, so querying using BIDS entities doesn't seem like it adds much utility.

We can probably check that the file name follows probe interface conventions as a schema check, if not a normal filename rule.

That said, if making the directory more BIDSy feels like a good use of people's time, I'm not here to stop you.

yarikoptic

some recommendations

src/modality-specific-files/microelectrode-electrophysiology.md

yarikoptic · 2025-10-15T15:11:28Z

src/modality-specific-files/microelectrode-electrophysiology.md

+
+The Microelectrode Electrophysiology modality encompasses recordings made with micrometer-scale electrodes,
+distinguishing it from related BIDS modalities (EEG, MEG, iEEG) that use larger electrodes.
+This modality is primarily used in animal research.


TODO here -- add an image describing relation between probes electrodes and channels.

smth like

based on what is in the spikeinterfaces docs

I don't know. The issue is that electrodes exist in physical space and channels don't really. They are often the result of some sort of wiring configuration, but at the end of the day a channel is a data stream, not a physical object, and the attributes of that table describe information about the data and data transformations, not the physical device on which it was collected.

src/modality-specific-files/microelectrode-electrophysiology.md

yarikoptic · 2025-10-15T15:23:27Z

src/modality-specific-files/microelectrode-electrophysiology.md

+**Intracellular electrophysiology example:**
+
+```tsv
+name	type	units	sampling_frequency	recording_mode	gain	ground	status


in addition to recording_mode we need to describe how clamping is done following e.g. types described in OpenMINDS at https://github.com/openMetadataInitiative/openMINDS_instances/tree/main/instances/latest/terminologies/patchClampVariation which we can name patch_variation and describe permitted values. (might need extra value for jaxtracellulular patching... loose patch recording according to google search by @apdavison)

I would also vote to define all the values allowed explicitly so could be validated.

yarikoptic · 2025-10-15T15:25:55Z

src/modality-specific-files/microelectrode-electrophysiology.md

+### Recommended Channel Type Values
+
+For the `type` column we recommend to use the following terms (adapted from [iEEG](intracranial-electroencephalography.md#channels-description-_channelstsv))
+


TODO: make a macro from the schema! Tireless @ree-gupta promised to do that in a separate PR and adopt here to avoid hardcoding

yarikoptic · 2025-10-17T14:28:05Z

src/modality-specific-files/microelectrode-electrophysiology.md

+**Extracellular electrophysiology example:**
+
+```tsv
+probe_name	type	AP	ML	DV	AP_angle	ML_angle	rotation_angle	hemisphere	manufacturer	device_serial_number	electrode_count	width	height	depth	dimension_unit	coordinate_reference_point	associated_brain_region	associated_brain_region_id	reference_atlas	material


note: at our meeting Oct 15th 2025 we briefly touched on a possible topic of introducing probe-<label> entity! It would reflect that actual recordings directly from hardware do ATM store each probe separately and it could be that there are different manufacturers/types of probes. That would then mandate pretty much to have probe_id (probe-<label>) as the leading column in the *probes.tsv file (which would exist then to summarize across probes, potentially even may be benefitting from inheritance principle for common metadata?).

Here probe_name came from analogy to name of electrodes.tsv inherited from EEG. But the question remains whether we might want to standardize this right away. WDYT @effigies ? Should we may be right away introduce probe entity?

Sorry, I don't think I have enough to go on from this comment and the immediately surrounding text. I would probably need to read the BEP in some detail to form an opinion.

I'm not sure I understand. The primary key of the probes table should not map 1-1 with the json files. The probe jsons describe probe models. It is quite common for labs to use multiple of the exact same model in a session. In that case, multiple probes would map to a single probe model, which might be specified using a json. This is why we need a separate column to specify the model and can't use the probe_id.

Now if you wanted to have a separate tsv for probe models that would make sense from a relational perspective but I don't think it would be practical because the data we want to express about probe models does not fit well into a tabular structure and we would rather point to an external reference anyway.

yarikoptic · 2025-10-17T16:15:05Z

@effigies

so you suggest to establish yet another folder with structured data but which will not be formalized by BIDS in terms of schema/structure under it?

The probes are a separate standard with their own contents and file-naming conventions.

I do not think there is any particular filename convention outside of their internal library. Here we are to provide files in an alien to that library location, so then tools could load using their "standard" https://probeinterface.readthedocs.io/en/main/api.html#probeinterface.io.read_probeinterface function (correct @bendichter ?) . Then the question of filename sanitization is also not a problem, we could e.g. replace all - with now allowed +.

yarikoptic · 2025-10-17T16:32:14Z

src/modality-specific-files/microelectrode-electrophysiology.md

+### Default probe-relative coordinate systems
+
+When no [`space-<label>`](../appendices/entities.md#space) entity is specified in the filename,
+electrode positions in `*_electrodes.tsv` are **probe-relative coordinates**:


chatting with @CodyCBakerPhD who raises a good point (I think) that if we are to describe probe geometries , either standard, or custom under /probes, then why do we want this yet another way to describe coordinates for the electrodes on the probes, and in the _probes.tsv table in particular? they would not be different for the same probe manufacturer/model, so why to repeat across the files? if very custom, a file under /probes could still be used to describe it.

Yes, this is a bit redundant.

In the case where you are referencing a probe model in the probe interface library, the advantage would be that you have electrode positions in the BIDS dataset without needing to consult an external source. This is nice, because the electrode positions are very important for data analysis (much more important than the rest of the information in the probe specification files).

In the case where you are defining a custom probe, this is more redundant, since you would be able to extract this information directly from the probeinterface specification file. In this case, it's nice to have for uniformity with the library models, though I do appreciate this is creating redundancy that is undesirable.

src/modality-specific-files/microelectrode-electrophysiology.md

Co-authored-by: Ben Dichter <[email protected]>

bendichter · 2025-10-20T14:11:16Z

@effigies

so you suggest to establish yet another folder with structured data but which will not be formalized by BIDS in terms of schema/structure under it?

The probes are a separate standard with their own contents and file-naming conventions.

I do not think there is any particular filename convention outside of their internal library. Here we are to provide files in an alien to that library location, so then tools could load using their "standard" https://probeinterface.readthedocs.io/en/main/api.html#probeinterface.io.read_probeinterface function (correct @bendichter ?) . Then the question of filename sanitization is also not a problem, we could e.g. replace all - with now allowed +.

I don't feel strongly about filenames for the probe json files. The probe interface library is clearly adhering to a convention of [manufacturer]/[model]/[model].json but the standard really lies in the json, not in the filenames. Using the probe interface standard does not require any particular file naming convention. I'd be fine with trying to follow the probe interface library or with trying to do something BIDSy. I just don't want this to be a rabbit hole.

probes/probe-<label>_probeinterface.json where label is the model would be a perfectly reasonable choice IMO. We would just need to make sure that the model specifier strings from custom probe models don't have slashes or any other forbidden chars in them.

Co-authored-by: Yaroslav Halchenko <[email protected]>

bendichter · 2025-10-26T18:30:40Z

src/schema/objects/entities.yaml

    In the case of long data recordings that exceed a file size of 2Gb,
-    `.fif` files are conventionally split into multiple parts.
-    Each of these files has an internal pointer to the next file.
+    Files with a lot of data may be split into multiple parts.


Suggested change

Files with a lot of data may be split into multiple parts.

Large files of time series data may be split into multiple parts.

bendichter · 2025-10-26T18:31:37Z

src/modality-specific-files/microelectrode-electrophysiology.md

+e001	probe01	L	0	0	0	1.2	0	15	iridium-oxide	MOp
+e002	probe01	L	0	0	25	1.1	0	15	iridium-oxide	MOp
+e003	probe01	L	0	0	50	1.3	0	15	iridium-oxide	MOp
+e004	probe01	L	0	0	75	1.4	0	15	iridium-oxide	MOp
+e005	probe02	R	0	0	0	2.1	n/a	12	tungsten	CA1
+e006	probe02	R	0	0	15	2.3	n/a	12	tungsten	CA1
+e007	probe02	R	0	0	30	1.9	n/a	12	tungsten	CA1
+e008	probe02	R	0	0	45	2.0	n/a	12	tungsten	CA1


Suggested change

e001 probe01 L 0 0 0 1.2 0 15 iridium-oxide MOp

e002 probe01 L 0 0 25 1.1 0 15 iridium-oxide MOp

e003 probe01 L 0 0 50 1.3 0 15 iridium-oxide MOp

e004 probe01 L 0 0 75 1.4 0 15 iridium-oxide MOp

e005 probe02 R 0 0 0 2.1 n/a 12 tungsten CA1

e006 probe02 R 0 0 15 2.3 n/a 12 tungsten CA1

e007 probe02 R 0 0 30 1.9 n/a 12 tungsten CA1

e008 probe02 R 0 0 45 2.0 n/a 12 tungsten CA1

e001 probe01 L 0 0 n/a 1.2 0 15 iridium-oxide MOp

e002 probe01 L 0 25 n/a 1.1 0 15 iridium-oxide MOp

e003 probe01 L 0 50 n/a 1.3 0 15 iridium-oxide MOp

e004 probe01 L 0 75 n/a 1.4 0 15 iridium-oxide MOp

e005 probe02 R 0 0 n/a 2.1 n/a 12 tungsten CA1

e006 probe02 R 0 15 n/a 2.3 n/a 12 tungsten CA1

e007 probe02 R 0 30 n/a 1.9 n/a 12 tungsten CA1

e008 probe02 R 0 45 n/a 2.0 n/a 12 tungsten CA1

Change this to have the values be expressed in y instead of z and to have z be n/a when unused because:

This is a more common convention, e.g. in ProbeInterface

This is more consistent with the iEEG modality:

I would also be fine with moving position to x and having both y and z be n/a, but I think what I have proposed is the more common convention

bendichter · 2025-10-26T18:33:58Z

src/modality-specific-files/microelectrode-electrophysiology.md

+patch01	pipette01	L	0	0	0	5.2	K-gluconate	1.5	2.5	borosilicate-glass	VISp2/3
+patch02	pipette02	R	0	0	0	4.8	K-gluconate	1.5	2.5	borosilicate-glass	VISp2/3
+sharp01	pipette03	L	0	0	0	80	3M KCl	0.5	1.0	borosilicate-glass	PL5


I feel these should be n/a when position data is irrelevant

bendichter · 2025-10-26T18:38:44Z

src/modality-specific-files/microelectrode-electrophysiology.md

+ch001	ref01	LFP	uV	1000	HighpassFilter	LowpassFilter	500	good	n/a
+ch002	ref01	LFP	uV	1000	HighpassFilter	LowpassFilter	500	good	n/a
+ch003	ref01	HP	uV	30000	HighpassFilter	n/a	500	good	n/a
+ch004	ref01	HP	uV	30000	HighpassFilter	n/a	500	bad	high_noise
+ch005	ref02	LFP	uV	1000	HighpassFilter	LowpassFilter	500	good	n/a


Suggested change

ch001 ref01 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

ch002 ref01 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

ch003 ref01 HP uV 30000 HighpassFilter n/a 500 good n/a

ch004 ref01 HP uV 30000 HighpassFilter n/a 500 bad high_noise

ch005 ref02 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

ch001 e001 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

ch002 e002 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

ch003 e001 HP uV 30000 HighpassFilter n/a 500 good n/a

ch004 e002 HP uV 30000 HighpassFilter n/a 500 bad high_noise

ch005 e003 LFP uV 1000 HighpassFilter LowpassFilter 500 good n/a

These channels clearly correspond to recordings from electrodes, so reference should point to names of electrodes

src/modality-specific-files/microelectrode-electrophysiology.md

bendichter · 2025-10-26T18:43:31Z

src/schema/objects/columns.yaml

    "Units": "year",
    "Maximum": 89,
  }
+AP_angle:


Need to add anatomical_reference_point for when you want to use something other than begma

…ioactivity

bendichter · 2025-11-05T14:19:00Z

src/modality-specific-files/microelectrode-electrophysiology.md

+If electrode positions are known in multiple coordinate systems (for example, probe-relative, StereoTaxic,
+and AllenCCFv3), these spaces can be distinguished by the optional [`space-<label>`](../appendices/entities.md#space)
+field, see the [`*_electrodes.tsv`-section](#electrodes-description-_electrodestsv)
+for more information.
+Note that the [`space-<label>`](../appendices/entities.md#space) fields must correspond
+between `*_electrodes.tsv` and `*_coordsystem.json` if they refer to the same
+data.
+
+For examples:
+-   `*_space-StereoTaxic` (electrodes are localized in stereotactic coordinate system with bregma origin)
+  <!-- TODO: Add 'StereoTaxic', 'AllenCCFv3', 'PaxinosWatson', etc coordinate systems to appendix coordinate-systems.md under "Microelectrode Electrophysiology Specific Coordinate Systems" with appropriate definitions for each standard reference frame used in animal electrophysiology -->
+-   `*_space-individual` (electrodes are localized in subject-specific anatomical coordinate system)
+-   `*_space-AllenCCFv3` (electrodes are mapped to Allen Common Coordinate Framework v3)
+-   `*_space-PaxinosWatson` (electrodes are mapped to Paxinos-Watson rat brain atlas coordinates)


Suggested change

If electrode positions are known in multiple coordinate systems (for example, probe-relative, StereoTaxic,

and AllenCCFv3), these spaces can be distinguished by the optional [`space-<label>`](../appendices/entities.md#space)

field, see the [`*_electrodes.tsv`-section](#electrodes-description-_electrodestsv)

for more information.

Note that the [`space-<label>`](../appendices/entities.md#space) fields must correspond

between `*_electrodes.tsv` and `*_coordsystem.json` if they refer to the same

data.

For examples:

- `*_space-StereoTaxic` (electrodes are localized in stereotactic coordinate system with bregma origin)



- `*_space-individual` (electrodes are localized in subject-specific anatomical coordinate system)

- `*_space-AllenCCFv3` (electrodes are mapped to Allen Common Coordinate Framework v3)

- `*_space-PaxinosWatson` (electrodes are mapped to Paxinos-Watson rat brain atlas coordinates)

If electrode positions are known in multiple coordinate systems, these spaces can be distinguished by the optional [`space-<label>`](../appendices/entities.md#space)

field, see the [`*_electrodes.tsv`-section](#electrodes-description-_electrodestsv)

for more information.

Note that the [`space-<label>`](../appendices/entities.md#space) fields must correspond

between `*_electrodes.tsv` and `*_coordsystem.json` if they refer to the same

data.

For examples:



- `*_space-individual` (electrodes are localized in subject-specific anatomical coordinate system)

- `*_space-AllenCCFv3` (electrodes are mapped to Allen Common Coordinate Framework v3)

- `*_space-PaxinosWatson` (electrodes are mapped to Paxinos-Watson rat brain atlas coordinates)

stereotaxic coordinates are expressed in the probes.csv, and probe-relative are in the electrodes.csv and (optionally) (in the probeinterface_library OR in the custom probeinterface file). The different coordinate systems here would be useful for individual vs. common spaces, or if a brain was mapped to different common spaces

bendichter · 2025-11-05T14:20:05Z

src/modality-specific-files/microelectrode-electrophysiology.md

+      "sub-01_space-StereoTaxic_electrodes.tsv": "",
+      "sub-01_space-StereoTaxic_coordsystem.json": "",


Suggested change

"sub-01_space-StereoTaxic_electrodes.tsv": "",

"sub-01_space-StereoTaxic_coordsystem.json": "",

"sub-01_space-AllenCCFv3_electrodes.tsv": "",

"sub-01_space-AllenCCFv3_coordsystem.json": "",

bendichter · 2025-11-05T14:38:49Z

New appendix for coordinate systems: #2247

…ogy schema

yarikoptic · 2025-11-05T15:22:13Z

src/modality-specific-files/microelectrode-electrophysiology.md

+ch003	ref01	HP	uV	30000	HighpassFilter	n/a	500	good	n/a
+ch004	ref01	HP	uV	30000	HighpassFilter	n/a	500	bad	high_noise
+ch005	ref02	LFP	uV	1000	HighpassFilter	LowpassFilter	500	good	n/a
+ch006	n/a	SYNC	V	30000	n/a	n/a	1	good	n/a


we might see to add description for this value with the .json file to state where the SYNC comes from etc.

Add first BEP032 objects

7ec5d5e

yarikoptic requested review from erdalkaraca and tsalo as code owners February 14, 2024 15:24

yarikoptic mentioned this pull request Feb 14, 2024

[ENH] Add BEP032 (microelectrode electrophysiology) specification #1352

Closed

3 tasks

Add ephys modality, start adding _channels but ran into a question on…

2f393ca

… _acq-

yarikoptic commented Feb 14, 2024

View reviewed changes

src/schema/rules/files/raw/channels.yaml Show resolved Hide resolved

tsalo added the BEP label Feb 15, 2024

yarikoptic mentioned this pull request Feb 29, 2024

Allow for using an arbitrary suffix and/or arbitrary entity bids-standard/bids-2-devel#63

Open

yarikoptic and others added 2 commits March 5, 2024 19:56

Add _acq- to ephys, add _channels and _coords

648781a

Draft for probes TSV file

d3c9996

TheChymera reviewed Mar 6, 2024

View reviewed changes

src/schema/objects/columns.yaml Outdated Show resolved Hide resolved

TheChymera reviewed Mar 6, 2024

View reviewed changes

src/schema/objects/columns.yaml Show resolved Hide resolved

TheChymera closed this Mar 7, 2024

TheChymera deleted the bep032 branch March 7, 2024 22:13

TheChymera restored the bep032 branch March 7, 2024 22:15

TheChymera reopened this Mar 11, 2024

Fix preferably typo

08c92cd

yarikoptic mentioned this pull request Mar 15, 2024

[SCHEMA] Remove stale test comment -- test no longer fails! #1727

Merged

yarikoptic commented Mar 15, 2024

View reviewed changes

src/schema/rules/files/raw/ephys.yaml Outdated Show resolved Hide resolved

robertoostenveld mentioned this pull request Mar 21, 2024

Draft examples for BEP032 on animal electrophysiology bids-standard/bids-examples#430

Draft

yarikoptic mentioned this pull request Apr 2, 2024

Automatic generation of extra-fields template forms from yaml-based schema (BIDS standard) elabftw/elabftw#5023

Closed

Comment out not yet defined iephys and add ephys to datatypes where i…

e2030ac

…t was missing

yarikoptic commented Apr 17, 2024

View reviewed changes

src/schema/objects/datatypes.yaml Outdated Show resolved Hide resolved

dorahermes reviewed Apr 17, 2024

View reviewed changes

src/schema/objects/modalities.yaml Outdated Show resolved Hide resolved

dorahermes reviewed Apr 17, 2024

View reviewed changes

src/schema/objects/suffixes.yaml Outdated Show resolved Hide resolved

TheChymera force-pushed the bep032 branch from cde80a6 to e2030ac Compare April 17, 2024 21:26

Added probes file

53f1087

Remi-Gau changed the title ~~[ENH] Add BEP032 (microelectrode electrophysiology) specification~~ [ENH] microelectrode electrophysiology specification (BEP032) Apr 18, 2024

ree-gupta and others added 3 commits October 14, 2025 17:37

Minor formatting and style issues

73d3975

Fix mock data tsv and JSON

7fb3a28

Merge branch 'master' into bep032

8b39a2d

yarikoptic commented Oct 15, 2025

View reviewed changes

yarikoptic commented Oct 17, 2025

View reviewed changes

src/modality-specific-files/microelectrode-electrophysiology.md Outdated Show resolved Hide resolved

Apply various wording suggestions from code review

1cfa706

Co-authored-by: Ben Dichter <[email protected]>

bendichter and others added 2 commits October 26, 2025 14:24

Apply suggestion from @yarikoptic

ae05b3b

Co-authored-by: Yaroslav Halchenko <[email protected]>

Apply suggestion from @bendichter

d1835cf

bendichter reviewed Oct 26, 2025

View reviewed changes

src/modality-specific-files/microelectrode-electrophysiology.md Outdated Show resolved Hide resolved

bendichter reviewed Oct 26, 2025

View reviewed changes

bendichter added 2 commits October 26, 2025 15:47

add back type info that was accidentally removed from whole_blood_rad…

76ef60a

…ioactivity

Update link to iEEG stimulation documentation for clarity

8368d47

bendichter reviewed Nov 5, 2025

View reviewed changes

Merge branch 'master' into bep032

401ee96

bendichter added 2 commits November 5, 2025 09:54

Update src/modality-specific-files/microelectrode-electrophysiology.md

df637a4

feat: add anatomical reference point to microelectrode electrophysiol…

e970799

…ogy schema

yarikoptic commented Nov 5, 2025

View reviewed changes

Fix up units and clarify that we need TODO work on the units/space more

91e4cb8

		### Recommended Channel Type Values

		For the `type` column we recommend to use the following terms (adapted from [iEEG](intracranial-electroencephalography.md#channels-description-_channelstsv))

	Files with a lot of data may be split into multiple parts.
	Large files of time series data may be split into multiple parts.

		"sub-01_space-StereoTaxic_electrodes.tsv": "",
		"sub-01_space-StereoTaxic_coordsystem.json": "",

[ENH] microelectrode electrophysiology specification (BEP032) #1705

Are you sure you want to change the base?

[ENH] microelectrode electrophysiology specification (BEP032) #1705

Uh oh!

Conversation

yarikoptic commented Feb 14, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

TODOs

Uh oh!

Uh oh!

Uh oh!

Uh oh!

TheChymera commented Mar 12, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheChymera commented Mar 12, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yarikoptic commented Oct 15, 2025

Uh oh!

effigies commented Oct 15, 2025

Uh oh!

yarikoptic left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yarikoptic Oct 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yarikoptic commented Oct 17, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bendichter commented Oct 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bendichter Oct 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bendichter Nov 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yarikoptic commented Feb 14, 2024 •

edited

Loading

TheChymera commented Mar 12, 2024 •

edited

Loading

yarikoptic Oct 17, 2025 •

edited

Loading

bendichter Oct 26, 2025 •

edited

Loading

bendichter Nov 5, 2025 •

edited

Loading

bendichter commented Nov 5, 2025 •

edited

Loading