Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limited channel_id - contact_id mapping #110

Closed
JuliaSprenger opened this issue May 27, 2022 · 2 comments
Closed

Limited channel_id - contact_id mapping #110

JuliaSprenger opened this issue May 27, 2022 · 2 comments
Labels
question Further information is requested

Comments

@JuliaSprenger
Copy link

Currently probeinterface is expecting a 1-1 match of channel_ids and contact_ids. However in some cases multiple channels were recorded from a single contact (e.g. different frequency ranges). Is there a workaround from the probeinterface side. Do you recommend using a 2nd fake probe to link to the additional channel_ids?

@samuelgarcia
Copy link
Member

If you use probeinterface from spikeinterface, you always have a unique channel_id for a given recording which is a unique stream. So in that case the problem do not occurs.

In spikeinterface multi stream format like blackrock must be loaded as separate objects.

probeinterface do not have the concept of channel_id we have contact_id and for the wiring : channel_device_index.
In short when you want to link a probe and a channel set of a stream this is done with the indices and not the ids because probeinterface is not aware of the recording.

@alejoe91 alejoe91 added the question Further information is requested label Aug 23, 2023
@alejoe91
Copy link
Member

Seconding @samuelgarcia

From the probeinterface prospective, you'd need to load two different probes.

@JuliaSprenger let's move the discussion here: SpikeInterface/ndx-probeinterface#24

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants