Understanding Retrieval_Time #2
Replies: 5 comments 3 replies
-
Hey Matias! Thanks for using the discussion! Sorry for the delay in responding. Yup the retrieval time is timing the duration from the pellet first being detected and the pellet first being removed, based on reading the pellet well itself. It's not the moment of actual eating because they could remove the pellet and wait 2 seconds before eating it, or even drop it on the floor, but it's the only information FED3 has about the pellet. I do know some labs are video-taping the mice from the bottom so they can confirm the mice eat each pellet, but this is because they are trying to understand what a neural population is doing during feeding and therefore want to be certain of the timing of eating. But that's a ton of work, so I think retrieval time can be used as a proxy for learning or motivation. For instance, when we train mice over their first experience with FR1, we find the retrieval time drops from ~10s on average to ~5seconds in the first night, demonstrating the quickening of pellet retrieval behavior after a successful poke (see Fig5 here: https://www.biorxiv.org/content/10.1101/2020.12.07.408864v1). I'm not entirely certain what this means in terms of motivation, but I think it's evidence of them learning to use FED3. To answer your questions, no there's not a reason we can't log the retrieval times >120s, I think I made a decision at some point that they weren't really meaningful, what does it mean if the mouse pokes and doesn't grab the pellet? I think it means he poked because he was exploring but either doesn't want the pellet or doesn't understand the link between the poke and the pellet. At any rate I probably shouldn't make this decision for other people, so I can change it to log the real retrieval time. I'll update that in the newer code. Also, in our FED3VIZ analysis program you can select different thresholds for this cutoff. I think a cutoff is important though, otherwise you will end up with some "retrieval time" values >1 hour, which don't make sense to average in. For your other question, I'm not sure where r1 is coming from. How are you calculating that? FED3 doesn't write the pellet detection time to the SD card, so you can't calculate it yourself from the poke timestamps. Are you subtracting the time from the previous pellet? It's also possible you found a bug in this calculation. Could you attach a snippet of the original data file highlighting the discrepancy you're seeing? Thanks! |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm currently using free feeding mostly, so for me, there's always a pellet on the well and there's no poke-eat sequence that we are looking into. I was trying to see whether there was any relationship between the If What was strange for me was the events with very high inter-pellet time and very low I should probably have posted the data in the previous post, but anyway here are the series of plots/data that got me confused on the first place. I renamed This is a plot of a cohort of animals running on free-feeding, From here, I went to look for my expected linear relationship plus noise given by the motor turns. Indeed, the following plot shows that. For I have been thinking about what hardware problems can be compatible with the data. What can trick the retrieval time to start over even though the animal did not take a pellet?
I can always be wrong in my math so feel free to check the raw data for one animal. |
Beta Was this translation helpful? Give feedback.
-
Right now, I am using Version 1.1.44. What you say about sleep time makes sense, not sure how the wake up works in free feeding mode, but this functionality seems like something that we actually want to be built-in, to save battery while the animals are not taking pellets or interacting with the device. |
Beta Was this translation helpful? Give feedback.
-
Hello again, sorry for the delay, we were running a cohort and I didn't want to switch libraries in the middle of it. I am using the library with 3 seconds timeout on FreeFeeding mode. I also included here 2 FEDs that were using the previous version. A few things I notice are,
I see some weird errors on the new library too, Here is the 120 seconds range, also most of the errors happen weirdly with I'm not sure the new library is recording retrieval time better than the old one. Here are some tables with examples
And here is a histogram of the differences between Finally, this is a separate comment. The column |
Beta Was this translation helpful? Give feedback.
-
Thanks for documenting this Matias! I opened "issues" for your comments on LibraryVersion and motor turn counting. I've fixed the Library_version typo and confirmed the bug you found with motor counts all being written as "0". I'll look into that bug this week. Thanks for pointing these out! I've also made some additional bug fixes and am now on version 1.2.3, can you update to that for additional testing? I think the timeout you noticed may be a "feature" :) I set a default timeout of 10s in the example FreeFeeding script, but you can disable it by removing line 21 (if you don't set a timeout it will default to 0). Can you check if this is the cause of what you're seeing? Your last issue is deeper. I wonder if the FED3 is somehow "missing" the pellet removal which may account for the huge time delays between the next pellet. Can you try downloading the latest library 1.2.3 and seeing if this is fixed? I made some adjustments to the dispensing function since 1.1.1. Also, how old are your 3D prints? We made some edits to the design in September to try to block off the pellet area more and inhibit mice from taking two pellets. The issue we found was that they could grab a pellet so quickly that the FED wouldn't detect it and would dispense a second one. Here is a photo of the newest design that has the two rectangular guards above the pellet well to prohibit pellet stealing. Does yours look like this? |
Beta Was this translation helpful? Give feedback.
-
I am trying to further understand the way
Retrieval_Time
is calculated and logged to file.If I understand correctly, these two snippets are crucial to calculating the time of retrieval of a pellet.
I would like to clarify if my understanding is correct here. If I understand the code correctly, the logged
Retrieval_Time
would be the time difference between a pellet was available in the well and the pellet is removed from the well. If so, the timestamps don't have real information about the retrieval time, they only show when a pellet was removed. However, these timestamps are as close as we can get to the actual moment of eating, is this correct? (I'm banging my head with the interpretation of retrieval time and the actual eating moment, and what would be my variable of interest for each experiment)For example, I have below a part of a dataset from FED3.
Retrieval_Time
andMM:DD:YYYY hh:mm:ss
come directly from FED3 logging,datetime
is the POSIXct conversion of the datetime andr_time
is the retrieval time calculated by me using a point to point difference of the timestamps.I understand
NA
values come from the 120 seconds threshold on the logger that are stored as "timed out" (if (retInterval >= 120) logfile.println("Timed_out");
inLogdata.ino
). Is there a reason why we would not log the actual value ?I guess the 3 seconds differences seen on some entries come from adjustment because of delay on free-feeding program, and that matches the differences in some rows (e.g, 65 vs 68 seconds). I am confused about the results for
Retrieval_Time
in cases where the time between pellets is big (e.g, 773 seconds) but FED seems to log 41 seconds. Where is this difference coming from? Looking at the data, it's not explained by motor turns either, this particular case had 1 motor turn and cases withMotor_Turns
> 1 are often just 3 to 5 seconds apart.Beta Was this translation helpful? Give feedback.
All reactions