Pellet count

[Dario55]

I would proposed the way in which pellet count is defined. At the moment it is based on number of beam brakes. However as it is, even when a single pellet is delivered one can have multiple beam breaks event. This cause an overestimation of the pellet count. I would suggest to use the trigger to the motor or the threshold crossing as the metric to be used.

For example in the current experiment (AEON4-25/11/2023) the high number of pellets delivered on patch1 comes from multiple beam a broken states rather than actual number of delivered pellets.

[glopesdev]

@Dario55 no problem, this is easy to change. We did discuss this at the very beginning and I think we decided together to go for the beam break since we didn't expect so many false positives. I agree that clearly in practice the situation is different so it makes sense to go back and switch to considering just delivery commands, since at least these are guaranteed to have an upper bound.

[glopesdev]

For completeness, there is another hybrid option which is to count the number of beam breaks in a fixed time window around a delivery command. That way you could still count pellet failures or multiple pellet deliveries, but would avoid having unlimited pellet deliveries when the IR beam is clogged or broken.

Clearly regardless of our final choice for counting pellets I think we should still keep the exact same alert mechanism, since we do want to fix the dispensers when something like this happens (since it's either clogged, or flooded with IR light, etc).

[Dario55]

Yes I agree the alert are good as they are. I like the combined criteria. Yeah not sure actually what’s going on with this feeders. It might be related to the new implementation Grame made.

[glopesdev]

@Dario55 @jkbhagatio @lorycalca @aspaNeuro I have pushed the debouncing code that might fix this in the gl-dev branch here: SainsburyWellcomeCentre/aeon_feeder_fix.

If you have time just follow the steps to upload the code on the README.md file and test it with the B2 feeders. The protocol for testing the blocked chute situation would be:

• Plug in the Pi Pico to the patch (after updating firmware)
• Close the patch lid to protect against spurious IR beams
• Run the workflow
• Trigger manual deliveries and spin the wheel is the control (should give single pellets)
• Test is then trigger multiple manual deliveries without spinning and see if the workflow starts registering bursts of false positives (if not then issue would be fixed)

[jkbhagatio]

Closing this as completed. One final follow up question is where should the new micropython firmware live? Do you want to put it on the social branch? @glopesdev @aspaNeuro.

And feel free to add any additional comments below.