Spikeglx: use probe features from ProbeTable to infer Neuropixels type#1842
Conversation
I'll take it! |
h-mayorquin
left a comment
There was a problem hiding this comment.
Thanks @chrishalcrow for testing this and sorry for taking so long @alejoe91. Actually, I was not sure if it was ready so I delayed it, sorry for assuming wrong. I have some requests regarding the handling of warnings vs error but otherwise LGTM.
Metacommentary:
After #1839 and #1842 we have our own copy of the json of the probe library. This is fine as long as both releases stay in lockstep with billkarsh's ProbeTable, but the cadence is controlled by two independent actions and two independent release cycles. A user with neo==X and probeinterface==Y where X and Y bracket a ProbeTable update might see diferences depending on versios. Honestly, it would be been simpler to just use probeinterface here rather than python-neo carrying its own copy. I do understand the French reason you probably decided against it though.
|
TODO: find a more robust way to assess probe technology from probe features (maybe crossing description/databus/datasheet) |
|
@h-mayorquin I think this is ready now: I improved the logic to spot 1.0 probes and in case of fixed gain we use the probe features gain as fallback in case the gain is not in the meta file |
private now! I'll merge as soon as tests are done |
Following #1839, the SpikeGLX reader is updated to infer the 1.0/2.0 probe type from the
datasheetfield of the associated entry in thenoe/resources/neuropixels_probe_features.json.In case the datasheet is not 1.0/2.0, a warning is pronted and unitary gains are added.