Aeon3-Patch3 beambreak ghost breaks

[jkbhagatio]

Noticed this around 2024-02-02 15:15, without mice being near

[Dario55]

About this: I think this may still be happening even with the state machine business in the miceopyton if there is a pellet or some dust in front of the beam. The key is that this should not affect pellet counts anymore. I guess if this happen the rule should be go down and clean che chute

[jkbhagatio]

About this: I think this may still be happening even with the state machine
business in the miceopyton if there is a pellet or some dust in front of
the beam. The key is that this should not affect pellet counts anymore.
I guess if this happen the rule should be go down and clean che chute

Yes agreed. We cleaned the chute when we noticed this, and thereafter didn't notice this issue again, so closing now.

[Dario55]

Reopening because the issue came back. In order to tackle this problem new chute have been 3D printed in black. This has been tested with mice on 07/03/2024, aeon4, 4 mice experiment, black chute on patch1. Before we ran a dry test (but not full 1000 pellets test), that showed that the noise in the black chute cause bz occlusion (that we suspected was causing the feeder high FP rate, see plot below) was greatly diminished. Unfortunately that was not the case with real mice. After 24 h the same erratic behaviour appeared.

One action point i may suggest are to save the beam brake output both during real experiments and 1000 feeder test, to have a better sense of what the signal looks like when FP or FN occurs, and possibly increase the detection threshold to 55000, do be far from the range of the noise )currentlyI suspect might be 30000.

[glopesdev]

@Dario55 we can record the raw stream by adding a new USB cable to every patch and software timestamping the raw sensor values, but we probably should do this in a separate experiment.