Free Interval Duration Mismatch – Stop Criterion Never Met Extends Interval to End of Track
Last updated: Oct 29, 2026
Problem
Users notice that their Free Interval duration values are unexpectedly long (e.g., hundreds of seconds) and do not match the In Zone time for the same zone. The Free Interval appears to run to the end of the trial rather than stopping when expected.
Details
Affects EthoVision XT users running Novel Object Recognition or similar zone-based analyses with Free Intervals that include a minimum in-zone duration start criterion and a separate stop criterion. Symptoms include Free Interval durations far exceeding In Zone time for the same zone, and results that seem to span the entire trial length. The most common cause is that the stop criterion is never satisfied during the trial, causing EthoVision to extend the interval to the end of the track by default.
Solution
1. Confirm that the Free Interval is intended to measure something distinct from In Zone time. A Free Interval starting after e.g. 1.3 s in the zone should always produce a value shorter than the raw In Zone duration — if it is longer, the stop criterion is likely never being met.
2. Open the Free Interval definition and review the Stop criterion carefully. Check whether the condition it relies on (e.g., leaving the zone, a time threshold, a state change) can actually occur during a typical trial.
3. If the stop criterion is never triggered, EthoVision will extend the interval to the end of the track. Correct this by either (a) revising the stop criterion to one that will be met during normal behavior, or (b) adding an unconditional time-based stop (e.g., 'trial ends') as a fallback.
4. Re-run analysis after correcting the Free Interval definition and verify that resulting durations are shorter than the corresponding In Zone time.
5. If nesting Free Intervals, confirm sub-interval start/stop logic is also correctly defined (see also: 'Analyzing Zone Dwell Time with a Minimum Duration Threshold Using Free Interval Nesting').