You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our lab is using linien to do cavity length locking using PZTs. Thank you for your project! During the use, we find the following problems and more features might improve things:
offset and lock point
Set lock point offset to the middle cannot handle asymmetric signal
See following error signal. First, if linien only locks to the middle of max and min, shown as the blue line, there is a delock point close to the lock point. If there is any perturbation driving it there, the lock fails in a sudden. Second, for a PDH type of error signal, one wants to lock it to the level of far-detuned error (the orange line), so it is more robust to optical power fluctuation, RAM, etc.
We admit the asymmetric error is not right and we should adjust it in physics level. But there are difficulties for now doing that and we still want to lock it before everything is perfect. In a process of building an experiment, it is better to avoid any delock point even the PID is not optimized, so orange line is a better offset.
User-controlled feature of offset
Continue with 1, as a user, I prefer to have lower-level control of offset/lock point as many as possible. My suggestion is to add a input box in "Maunal" locking mode, and be able to move the error in y. If there is a dynamic line (as the orange line I added) showing the new lock point. A more complicated feature is linien automatically find this level as long as user can select larger area, but this can be hard: the can of Red Pitaya (RP) is limited to 2V which is sometimes not enough to see this level.
From my reading of linien's code, this offset is moved in get_lock_point() function in common.py, maybe also record_first_error_signal() method in autolock.py. I plan to add one argument or one more function in those parts.
To be continued.
The text was updated successfully, but these errors were encountered:
Thank you for your detailed issues and plans for adding this to the project in the future!
Manually moving the error signal would indeed be useful (a collegue had a similar issue recently). As a workaround, could an additional Bias-Tee and voltage source before the input help?
We are going to use Bias-Tee or some voltage divider circuit as an alternative. I just think to fix it in software is a cleaner and final solution eventually. :)
Our lab is using linien to do cavity length locking using PZTs. Thank you for your project! During the use, we find the following problems and more features might improve things:
offset and lock point
See following error signal. First, if linien only locks to the middle of max and min, shown as the blue line, there is a delock point close to the lock point. If there is any perturbation driving it there, the lock fails in a sudden. Second, for a PDH type of error signal, one wants to lock it to the level of far-detuned error (the orange line), so it is more robust to optical power fluctuation, RAM, etc.
We admit the asymmetric error is not right and we should adjust it in physics level. But there are difficulties for now doing that and we still want to lock it before everything is perfect. In a process of building an experiment, it is better to avoid any delock point even the PID is not optimized, so orange line is a better offset.
Continue with 1, as a user, I prefer to have lower-level control of offset/lock point as many as possible. My suggestion is to add a input box in "Maunal" locking mode, and be able to move the error in y. If there is a dynamic line (as the orange line I added) showing the new lock point. A more complicated feature is linien automatically find this level as long as user can select larger area, but this can be hard: the can of Red Pitaya (RP) is limited to 2V which is sometimes not enough to see this level.
From my reading of linien's code, this offset is moved in
get_lock_point()
function in common.py, maybe alsorecord_first_error_signal()
method in autolock.py. I plan to add one argument or one more function in those parts.To be continued.
The text was updated successfully, but these errors were encountered: