Guider binning

Eric Dejouhanet eric.dejouhanet at gmail.com
Thu Jun 4 13:03:55 BST 2020


Hello Jasem,

You raise an interesting point. Originally, I hadn't planned to do 
anything different than what the Options are doing now. That is, only 
offer the possibility to serialize the set of Options pertaining to a 
specific Module.

Then, from Scheduler, I would send those serialized settings (if any) to 
each module when initiating an Observation Step that involves them. 
Thus, because Scheduler is supposedly using a specific equipment Profile 
(which it actually may do only once at the beginning I think), we can 
say that the listed settings are tied to an equipment Profile. At least 
that was my intent, from the point of view of Scheduler.

Now, if I consider the point of view of the module alone, the user may 
choose to load Settings created with a different set of devices than 
what the current Profile is defined with. That currently happens in the 
Capture module, where one may create a Sequence file with the CCD and 
Filter Wheel Simulators, and load it with their real camera and filter 
wheel (which their Simulator is mimicking). There are sometimes 
incompatibilities, and the code currently does not handle that very 
well. We can expect the same situation to happen in other modules.

There is some sort of fallback method to design here in each module 
separately. Not the right camera device? We may just reject the 
settings, or pick the device currently in use and hope for the best, or 
default some fields, or define a blank "default" value that would reset 
a parameter to its default. Any ideas?

-- 
-Eric

mailto:eric.dejouhanet at gmail.com -- https://astronomy.dejouha.net



More information about the Kstars-devel mailing list