Auto recovery is an attempt to handle situations in which perturbations or loss of signal drive the lock away from its set point. When enabled, auto recovery builds a historical record of the DAC output and reengages the lock at the running average if it notices a sudden jump. Auto recovery does not first engage until it has accumulated a sufficiently large history (set as 50 points, ~10s with .2s loop timer). The threshold for a "sudden" jump is anything plus or minus a user adjustable number of standard deviations (5 is default). As a further protection, there is also an option to restrict the DAC output limits based on the current recovery threshold. This reduces the extent to which a failed lock perturbs the rest of the system. As a visual aid to the user, the auto recovery threshold and DAC output limits are plotted as gray dotted and dashed lines along with the DAC output history. An additional benefit of this auto recovery is in ensuring continuity for systems which have multiple, accessible lock points (i.e. anything heterodyned with a comb) as the other set points will be rejected after a perturbation if outside of the recovery threshold.
As a diagnostic, while auto recovery is running, the program records the duration of the session (the continuous time in which both the lock and auto recovery are enabled) and any lost lock events. The first row of an hdf5 table gives the start and end of the session in POSIX timestamps (UTC) and subsequent rows show the times of each unlock event. The file can be read with either PyTables or Pandas to give a record of the lock's total uptime.
Also made some small changes to the layout, the format of displayed numbers, and the handling of user input in QLineEdits.
Below are screenshots of auto recovery in action. The first is a baseline view of a lock without perturbations, while the second and third are with perturbations. The last two show the behavior of auto recovery with the full DAC output limits and with the restricted.
Auto recovery is an attempt to handle situations in which perturbations or loss of signal drive the lock away from its set point. When enabled, auto recovery builds a historical record of the DAC output and reengages the lock at the running average if it notices a sudden jump. Auto recovery does not first engage until it has accumulated a sufficiently large history (set as 50 points, ~10s with .2s loop timer). The threshold for a "sudden" jump is anything plus or minus a user adjustable number of standard deviations (5 is default). As a further protection, there is also an option to restrict the DAC output limits based on the current recovery threshold. This reduces the extent to which a failed lock perturbs the rest of the system. As a visual aid to the user, the auto recovery threshold and DAC output limits are plotted as gray dotted and dashed lines along with the DAC output history. An additional benefit of this auto recovery is in ensuring continuity for systems which have multiple, accessible lock points (i.e. anything heterodyned with a comb) as the other set points will be rejected after a perturbation if outside of the recovery threshold.
As a diagnostic, while auto recovery is running, the program records the duration of the session (the continuous time in which both the lock and auto recovery are enabled) and any lost lock events. The first row of an hdf5 table gives the start and end of the session in POSIX timestamps (UTC) and subsequent rows show the times of each unlock event. The file can be read with either PyTables or Pandas to give a record of the lock's total uptime.
Also made some small changes to the layout, the format of displayed numbers, and the handling of user input in QLineEdits.
Below are screenshots of auto recovery in action. The first is a baseline view of a lock without perturbations, while the second and third are with perturbations. The last two show the behavior of auto recovery with the full DAC output limits and with the restricted.