Check num_chan_per_chip to avoid ZeroDivisionError

[MGAMZ]

In some scenarios, spikegadgets' recording have missing chanPerChip values, neo will default to 32 in this case.
In our practice, this value can be mistakenly recorded to zero, and will cause ZeroDivisionError while parsing header:

# around line:224
if num_ephy_channels % num_chan_per_chip == 0

This PR adds a simple check for num_chan_per_chip, when it appears to be non-positive, raise KeyError which will be caught and replace with the original default value for Intan chips.

try:
    num_chan_per_chip = int(sconf.attrib["chanPerChip"])
    if num_chan_per_chip <= 0:  # invalid value
        raise KeyError
    if num_chan_per_chip > 100000:  # abnormal large value
        raise KeyError
except KeyError:
    num_chan_per_chip = 32  # default value for Intan chips

Further Discussion

The related codes are introduced in #1496. In that PR, the @khl02007 assumes the num_chan_per_chip is reliable and it influces the channel mapping. But in fact this value can be wrong due to Trodes BUGs, It can be zero or an abormally large value.

If the value is mistakenly recorded as zero, a ZeroDivisionError will be triggered (as seen in this PR). If it is recorded as a large value (such as 1645402192), the condition num_ephy_channels % num_chan_per_chip == 0 is evaluated to True. Consequently, python-neo will treat it as a valid value and trigger the remapping of channel_ids. This is potentially dangerous because the data could be inaccurate without the user's awareness.

This PR only introduces some simple checks and overwrite the wrong value to defaults. However, the default values may still deviate from the actual situation. The judgment num_ephy_channels % num_chan_per_chip == 0 seems to be not good for robustness. But I am not sure how to improve this. Also hoping @jnjnnjzch can give some suggestions.

[Copilot]

Pull request overview

Adds a guard when reading SpikeGadgets XML headers to prevent a ZeroDivisionError during channel-ID generation when chanPerChip is present but set to a non-positive value.

Changes:

• Validate chanPerChip after parsing and fall back to the Intan default (32) when the value is non-positive.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jnjnnjzch]

Well, I think it may be OK to add a warning letting users know something is wrong... but I doubt the necessarity to “replace with the original default value for Intan chips”, replacing is a dangerous action.