Incompatibility between Photodiode index 0 and address 256

[filcarv]

Photodiode 0 doesn't work reliably when using the NP in the nearest socket.

I don't see users using two probes with free-moving animals, so we can tell users to use the other socket for freely-moving animals.

This table of tests shows that Photodiode 0 (PD0) doesn't work reliably for some scenarios.

Plugged 257	Plugged 256	Stream 257	Stream 256	Bonsai 257	Bonsai 256	PD0
Yes	Yes	True	-	Enabled	Disabled	✅
Yes	-	True	-	Enabled	Disabled	✅
-	Yes	-	True	Disabled	Enabled	🗑️
Yes	Yes	True	False	Enabled	Enabled	🗑️

🗑️ - The data is garbage, and can’t be trusted. It still sends events even if the IR is not present.

[jonnew]

Thanks for the detailed report. This behavior is similar to an issue on the headstage-64 rev. 1.3 where the routing of the un-amplified photodiode (PD) signal passes under the BNO055 and is corrupted in the process. Even in revision 1.3b, where the PD traces pass under the BNO055 on a different layer, with ground plane in between the them and the BNO055, it does not function. These traces are obviously very sensitive to stray electric fields from digital processes around them. I have a feeling that some of the traces coming back from the neuropixels' parallel-serial bus (PSB) are doing exactly the same thing. This makes sense given that the TS4231 receiver is quite far from the PD. If we redesign this headstage, extreme caution will be used when laying out the un-amplified PD traces. Further, a guard ring can be employed to prevent leakage currents through the solder-mask.