View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002036||CCdciel||[All Projects] General||public||18-12-01 12:51||19-01-17 20:51|
|Reporter||Rowland||Assigned To||Patrick Chevalley|
|Priority||normal||Severity||feature||Reproducibility||have not tried|
|Platform||PC||OS||Windows||OS Version||10 64bit|
|Target Version||1.0||Fixed in Version|
|Summary||0002036: Suggestion: Monitor Cloud Sensor, suspend and resume session based on weather|
|Description||For unattended imaging, I'd like to set up multiple sequences for the night. Each sequence needs a start time and finish time (or object elevation could be used to indicate "image no sooner than" and "image no later than.") |
Weather information comes from AAG Cloudwatcher or similar devices.
If the weather information indicates conditions are "unsafe," imaging would be suspended.
When the weather information indicates conditions are "safe" again, after a configurable delay (to avoid stop / start / stop / start cycling), imaging would resume.
If the "run no later than" time has been exceeded for the object that was being imaged at the time weather became unsafe, execution would skip that object and proceed to the next in the sequence, also checking the "run no earlier than" and "run no later than" times. Repeat until an object is found that can be imaged, or the end of night processes are run.
|Tags||No tags attached.|
The part about object elevation is already implemented, the rise/set option of a target is relative to a user configurable horizon file.
The weather information can be handled in a similar way as already done for the "dark night without Moon" condition.
A limitation for this version of the program is the rater linear processing of the object sequence, this will be improved for version 2.0: 0001894
I have a question about the Cloudwatcher because I not use this device.
You say about safe/unsafe, so you use the SafetyMonitor driver that provide this single switch. For me this switch is more intended to stop all operations and close the roof because it rain.
The driver that provide information about good observing condition is ObservingCondition, it give values about cloud cover but also sky quality, humidity, wind, ...
What is good condition depend on the observing place and the kind of target you image. The threshold for good condition can be very different that the threshold for safe condition.
So it is maybe better I provide a configurable setting to define good observing condition with threshold for all this values and let the safety monitor do it's safety job.
Do this make sens for you?
Thanks Patrick. I have seen Cloudwatcher monitoring handled both ways that you discuss - both the ASCOM safety driver with a simple "safe" / "unsafe" condition, or a more configurable approach where all the variables from the Cloudwatcher are monitored and the user can choose the combinations that cause operations to suspend / resume, or terminate for the night.
The most complete implementation would be for CCDciel to monitor both safety and weather conditions (cloudiness, humidity, wind, rain, etc.) and let the user decide what should happen when conditions reach a certain value.
The software should be able to initiate a shutdown (park scope, close roof, etc.) or a simple suspension of imaging. It should continue to monitor both safety and weather conditions, and do what the user specifies if the either the weather conditions improve beyond a threshold, or the safety monitor goes from "unsafe" to "safe" again. The user may choose to do nothing (i.e. stay shutdown) or to resume imaging. Depending on what happened when imaging stopped, the software may have to reopen the roof, unpark the scope, etc., or just resume imaging with the first event that is still available (elevation, start/stop imaging time) after where things where when imaging stopped.
The full weather condition monitoring is the most complete implementation. But a lot of software just watches the "safety" driver and at least for the AAG Cloudwatcher, that is good enough - because the Cloudwatcher software lets you decide exactly which weather conditions should cause an "unsafe" condition. For me, the key is what happens once the weather improves - I want the ability to resume operations and to be intelligent about which object is available once imaging resumes. It sounds like CCDciel has the intelligence to know where to resume imaging, that is great!
Using the ASCOM ObservingConditions (with settable parameters) and SafetySwitch would be very good.
I guess the INDI equivalent would be the weather stations?
Rowland, thank you for all this information.
I think I can start to do something because there is a Ascom simulator for both Condition and Safety. This simulator are a great help for the development.
Fully intelligent resume of the sequence has to wait for the version 2.0, for now this is not the case, but at least this is planned.
Cedric, yes Indi support weather station and also the AAG Cloudwatcher. But this time I probably start with the Ascom driver because all the properties are well standardized. Then I will look how to map that to the Indi properties.
A new version 0.9.51 is now released and implement this functions.
Please read the new documentation for explanation how it work and how to configure :
I am very interested if you can test all of this and report if it work for you.
||That's all fine, let's close this one.|
Thank you for your testing Cedric.
I close this issue as the feature is now implemented but please open a new issue if there is problem or point that can be improved.
|18-12-01 12:51||Rowland||New Issue|
|18-12-02 10:54||Patrick Chevalley||Status||new => feedback|
|18-12-02 10:54||Patrick Chevalley||Note Added: 0005149|
|18-12-02 12:05||Rowland||Note Added: 0005150|
|18-12-02 12:05||Rowland||Status||feedback => new|
|18-12-05 20:35||Cedric Raguenaud||Note Added: 0005174|
|18-12-05 21:09||Patrick Chevalley||Note Added: 0005176|
|18-12-05 21:09||Patrick Chevalley||Assigned To||=> Patrick Chevalley|
|18-12-05 21:09||Patrick Chevalley||Status||new => assigned|
|18-12-05 21:09||Patrick Chevalley||Target Version||=> 1.0|
|19-01-09 13:50||Patrick Chevalley||Status||assigned => feedback|
|19-01-09 13:50||Patrick Chevalley||Note Added: 0005236|
|19-01-17 20:03||Cedric Raguenaud||Note Added: 0005245|
|19-01-17 20:51||Patrick Chevalley||Status||feedback => resolved|
|19-01-17 20:51||Patrick Chevalley||Resolution||open => fixed|
|19-01-17 20:51||Patrick Chevalley||Note Added: 0005246|