Repository navigation
Conversation
Ripple Trellis writes 2.2 files with electrode IDs by front-end port (1-128, 129-256, 257-384...). Spike packets of a 2.2 file were recognized only for IDs 1-255, so every spike on a higher electrode matched no packet type and was dropped without a warning. The 2.2 range is now 1-2048, as for 2.3. Also document next to the table which packet IDs of 3.0 files written by Central are ignored on purpose (preview packets, recording events).
|
@cboulay I've requested Heberto to review your PRs. Thanks for the continued contributions! |
h-mayorquin
left a comment
h-mayorquin
left a comment
There was a problem hiding this comment.
The approach looks good to me. I have one question, where does the 2048 come from? Your comment says it is the range of 2.3, but I traced the 2.3 value back to the first draft of the reader in 2014 and could not find a source for it.
The only limit I could find is 1 through 10000, in section 4.5 of LB-0110. But that is the 3.0 document, and that range would also take the Trellis stimulation packets (5120 plus the electrode) as spikes. I would like to keep those apart and I will do another PR for them. So I am fine with leaving 2048, but if you have a better number or a source (Ripple's 2.2 document maybe?) that would be great.
I added your sample.nev (thanks for sharing it!)
https://gin.g-node.org/NeuralEnsemble/ephy_testing_data/pulls/192
Once the gin PR is merged (@zm711) and the tests updated here we can move forward here. I will review the other PRs as soon as I can.
Addresses the dropped spikes in #1918: spike packets of a 2.2
.nevwere only recognized for IDs 1-255, so a Ripple Trellis recording with electrodes 257+ lost every spike. The 2.2 range is now(1, 2048), the same as 2.3.The test builds a 2.2 file from neo's 2.3 test file (spec byte changed, electrode 1 renumbered 300 in its
NEUEVWAVheader and spike packets) and checks that electrode 300's spikes equal electrode 1's in the original. It fails on the old range. I did not run the Trellis sample from the issue through this.This does not add the warning the issue also asks for when data packets match no known type. I also added a comment above
NEV_PACKET_IDENTIFIERS_BY_SPECthat lists the packet IDs of 3.0 files written by Central that are ignored on purpose, so a future warning does not need to treat them as surprises:0x8000 + channellive-protocol preview packets, and0xFFF9recording events (start/stop/pause/resume, per Central'sCNevFile30::AddRecordingEvent).@h-mayorquin you mentioned working on Blackrock this week: we are fine with whatever solution you come up with for #1918 (the range, the warning, or both). Feel free to close this in favor of yours, or push to this branch.